mp3 seeking

mp3 seeking

[est]

Andy Lo A Foe discourseth:
> A segment holds a number of decoded frames (usually 2 or 3) and also
> remembers the number of the first frame. So lets say we want to play 
> a mp3 backwards starting at frame 1000. The tricky part is to keep the
> ringbuffer full with the right frames all the time. As soon as one segment
> is used up by the audio reader thread it releases a semaphore on which the
> audio decoder thread is blocking on. The audio decoder thread wakes up and
> check if there are any segments that needs to be filled. But wait you say,
> what if you need to fill a segment with frames 1000 to 998? Decoding frame
> 1000, then 999 and then 998 won't work because of the way mp3s are
> encoded. What do you do then? You seek to frame 995 and start decoding
> from there. You throw all data away up to and including frame 997. By this
> time your mp3 decoding engine is recovered from the 'seek' operation.

Andy,

First, I must thank you for alsaplayer since I'm using an adaptation
of your adaptation of the mpg123 code in the next major release of
oolaboola.  I'm encapsulating it in a separate process (called
mp3serv) to get re-entrancy.  I may move to the xing decoder but the
process interface will remain the same.

Now to the question of seeking. :)

My understanding was that it *may* take more than 3 frames of priming
to resynchronize.  One of the xing/freemap people got me the logic but
I haven't implemented it yet.

Another issue is how to find a given frame in the first place.  Given
that each frame may have an extra byte of padding, a multiplication is
(audibly!) unreliable.  I've implemented a table-of-contents mechanism
to deal with this.

Best,

Eric

Re: mp3 seeking

[Andy Lo A Foe]

On Tue, 26 Oct 1999 est@hyperreal.org wrote:

> First, I must thank you for alsaplayer since I'm using an adaptation
> of your adaptation of the mpg123 code in the next major release of
> oolaboola.  I'm encapsulating it in a separate process (called
> mp3serv) to get re-entrancy.  I may move to the xing decoder but the
> process interface will remain the same.

Very interesting. I'm thinking about a similar solution for doing
reentrancy with plugins that don't support it, something like a proxy
plugin interface with IPC and shared memory. Where can I get the latest
version of oolaboola?

> My understanding was that it *may* take more than 3 frames of priming
> to resynchronize.  One of the xing/freemap people got me the logic but
> I haven't implemented it yet.

I'm using 3 right now. You need a bit more for lower bitrates it seems.
I've never really looked into the encoding algorithm so... :)

> Another issue is how to find a given frame in the first place.  Given
> that each frame may have an extra byte of padding, a multiplication is
> (audibly!) unreliable.  I've implemented a table-of-contents mechanism
> to deal with this.

Yes, if you want 100% correct seeking the best thing you can do is to
store the frame start positions while decoding. It is a bit slow though.
Is that what you're doing? (for VBR encoded files I don't see any other
(simple) method to support seeking BTW)...

Regs,

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/