Re: random seeking with MAD

Super.. now is there I way I can get the mad api to tell me how many 
frames back the bit pool goes from a given frame? I could store this along 
with the frame offsets to optimize.

On Fri, 28 Nov 2003 15:02:26 -0800, Rob Leslie <[email protected]> wrote:

> On Nov 27, 2003, at 8:57 AM, Jedediah Smith wrote:
>> How would I implement fast, sample-resolution random seeking with MAD? 
>> In other words, I need to be able to reposition the stream to a 
>> specific sample and get resynced in constant time and without too much 
>> overhead. The MP3 also needs to be streamed from disk rather than 
>> loaded entirely in RAM. I imagine the main problem would be 
>> reconstructing the bit pool at the seek point.
>>
>> From my understanding of the MP3 format, the furthest back bit pool 
>> data can be stored is 9 frames. So here is my idea:
>>
>> 1. On initial load, create an index of all the frame offsets in the mp3 
>> and cache it in RAM
>> 2. When seeking to sample N, calculate the containing frame number F as 
>> F=N/1152
>> 3. Use the cached frame index to find the file offset of frame F-9
>> 4. Seek to that offset in the file and begin decoding
>> 5. Decode 9 frames silently, ignoring any MAD_ERROR_BADDATAPTR
>> 6. Begin playing at sample N which is within the current frame
>>
>> Will this work? Is there a faster way that avoids decoding the audio 
>> data for the extra 9 frames?
>
> This seems a reasonable approach. Keep in mind the number of samples per 
> frame will only be 1152 for MPEG-1 Layer III or II. Likewise the 9 frame 
> reservoir limit only applies to MPEG-1. For MPEG-2 the theoretical 
> maximum is 29 frames.
>
> You don't have to fully decode each frame leading to your target frame; 
> you can skip the synthesis step for all but the frame immediately prior 
> to the target.
>