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 rob@mars.org 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.