Re: random seeking with MAD

Thanks Rob, helpful stuff!

But doesn't the main data pointer of the current frame come after the 
header of the previous frame? That's how I read the ISO spec:

"main_data_end - The value of main_data_end is used to determine the 
location in the bitstream of the last bit of main_data for the frame. The 
main_data_end value specifies the location as a negative offset in bytes 
 from the next frame's frame header location in the main_data portion of 
the bitstream."

So:
  main_data_end for frame N-1 comes immediately after the header for frame 
N-1
  main_data_begin for frame N is equivelant to main_data_end for frame N-1
  thus main_data_begin for frame N comes immediately after the header for 
frame N-1

is that right?

On Sun, 30 Nov 2003 12:45:34 -0800, Rob Leslie <[email protected]> wrote:

> On Nov 28, 2003, at 4:47 PM, Jedediah Smith wrote:
>> 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.
>
> Not simply. You can poke around in the frame yourself, if you like:
>
>    unsigned int main_data_begin;
>
>    {
>      struct mad_bitptr peek;
>      unsigned long header;
>
>      mad_bit_init(&peek, stream->this_frame);
>
>      header = mad_bit_read(&peek, 32);
>      if (!(header & 0x00010000L))  /* protection_bit */
>        mad_bit_skip(&peek, 16);  /* crc_check */
>
>      main_data_begin =
>        mad_bit_read(&peek, (header & 0x00080000L) /* ID */ ? 9 : 8);
>
>      mad_bit_finish(&peek);
>    }
>
> This reads the current frame's main_data_begin which tells you how many 
> bytes before the frame its main_data begins. Note however that this 
> count does not include header or side info bytes of previous frames. 
> Headers are 4 or 6 bytes depending whether protection_bit is clear (see 
> above). Layer III side information has the following number of bytes:
>
>    lsf = frame->header.flags & MAD_FLAG_LSF_EXT
>    nch = MAD_NCHANNELS(&frame->header)
>
>                  lsf  !lsf
>                +----------
>      nch == 1  |   9    17
>      nch != 1  |  17    32
>
> The total byte size of the frame is stream->next_frame - 
> stream->this_frame. This should be enough information to calculate the 
> number of frames prior the current frame's main_data begins and thus 
> where to start decoding in order to fully decode the current frame.
>
> Note that with the exception of total frame byte size, the above 
> discussion is only applicable to Layer III. Layers I and II have 
> different frame structures but do not use a bit reservoir so they can 
> always begin decoding at any frame.
>