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.