At 01:00 PM 8/19/99 -0700, you wrote:
>[EMAIL PROTECTED] discourseth:
>> 
>> OK, here is the scoop. Given that you are seeking to frame n, you may
>> need to back up m frames, decode and toss these m frames and then
>> docode and use frame n. The hitch is that m is not known a priori -- it
>> varies depending on the bitrate. It may be large with low bitrate
>> streams. I know where in the decoder to check to see if the decoder is
>> 'happy' with the decoded frame.
>> 
>> Given this, I suggest that we can modify the decoder to include this
>> check and then through empirical tests find out how many frames we need
>> to back up given a particular bitrate. We can implement the seek so
>> that it would be intelligent enough to catch when its guess as to how
>> far to back up was wrong, and have it back up further.
>
>Iterative deepening, doubling the backup each time would seem in
>order.  That way you're guaranteed that >50% of the time you spend in
>backup isn't `wasted'.

This kind of guesswork shouldn't be necessary.  The size of the 'bit
reservoir' (a back-pointer into previous frames) is given exactly by the
"main_data_begin" field that appears in the "side info" structure that
immediately follows the 4-byte MPEG audio header.

Unfortunately, extracting this information requires some knowledge of the
internals of MP3 data (but, OTOH, it's all documented in the MPEG specs).

        Ross.

Reply via email to