gte nico wrote:
I am using mad0130b in order to compare the pcm output with my decoder. When I decode the sin1k0db.bit mp3 file (test bitstream package v2.2 from fraunhofer), I can not decode :
The first frame (like MAD) because of the main_data_begin which point out of the file.
The second frame : I decode it because the main_data_begin is valid and I can not understand why this frame is not decoded by MAD.
If the main_data_begin is invalid for the first frame, MAD will be unable to determine where the first frame's main_data ends, and therefore will also be unable to verify the validity of the second frame's main_data_begin. Thus MAD does not decode either frame but queues unused data from the end of the second frame for the following frame's main_data.
Perhaps this is a bit overzealous, but it explains the behavior.
The third frame and the others are well decoded.
The last frame can be decoded, but MAD does not do it.
MAD will not decode the last frame unless it is followed by at least MAD_BUFFER_GUARD additional bytes. Both `madplay' and the plug-in for Winamp ensure this is the case as of version 0.13.0b, so I would be very interested if you find the last (complete, incorrupt) frame is still not decoded.
I would like to understand the behaviour of the MAD decoder. Which decision permit the decoding of one frame. What is the parsing principle ? and is it normal to avoid decoding these two frames ?
The general parsing principle is to assume nothing, and to ensure the validity (or indemnity) of all parameters before proceeding. If the data you pass for decoding is corrupt in any way, I think it is acceptable for the decoder to skip one or more frames until it has regained confidence in the stream. That has been my philosophy writing MAD, but it's certainly not the only valid one.