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).


Reply via email to