Brett Paterson wrote:
Ive been having a bit of trouble trying to use mad in the normal manner I usually decode mpeg, because mad has introduced this stream api which I am finding getting in the way somewhat as it seems to dig into the lower levels of logic such as frame.c I usually do decoding 1 frame at a time in this manner:
Read 4 byte header Decode header Read single mpeg frame - size based on previous header. Decode single frame (then synth etc) to 1152 samples. Repeat
My own (fpu) decoder and intel's IPP for arm decoder allows this, but mad seems to want the 'next' frame with the stream stuff, which can mess up my logic a bit when I don't want to or cant give it another frame. Is it simple enough to do the above method with mad?
MAD uses a stream API because frames don't always begin and end at frame boundaries. Reading the main_data for Layer III is quite messy: in order to determine where the next frame's main_data begins (and thus, where the current frame's main_data must end), it's necessary to read the next frame's main_data_begin pointer, which lies after the next frame header. So, MAD requires the beginning of the next frame to be present in the stream.
And anyway, you don't really want to be grubbing around in the MPEG frame headers, do you? That's what the decoder library is *for*. A call to mad_header_decode() will neatly fill a data structure with all the info from the next frame header, and also set stream->this_frame and stream->next_frame with pointers to the frame's boundaries (ignoring main_data).
There's actually a second reason MAD needs the next frame present in the stream buffer, having to do with a technicality of Huffman decoding. If the Huffman data is corrupt, it's possible MAD may inadvertently read a few bytes past the end of the frame before discovering the error. To prevent this from crashing your application, MAD requires the stream buffer to extend a few bytes past the end of the current frame.
-rob