On 4 Sep, Ross Finlayson wrote:
> 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.
It doesn't help. For the first frame this number is 0, then for all
subsequent frames the number of greater than 0. That doesn't help to
find the point to break the stream.
--ruaok Freezerburn! All else is only icing. -- Soul Coughing
Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
