Pass a buffer to mad_stream_buffer which ends exactly on a frame boundary. mad_frame_decode will fail on the last frame and set the error to MAD_ERROR_BUFLEN even though entire frame is there. As much as 7 extra bytes can be added to the end of the buffer and the last frame decode will still fail. If 8 bytes are added, the frame decode will succeed.
Is this a bug or by design? If by design, how can I decode the last frame without adding padding after it?
On Dec 3, 2003, at 2:42 AM, Jedediah Smith wrote:
Pass a buffer to mad_stream_buffer which ends exactly on a frame boundary. mad_frame_decode will fail on the last frame and set the error to MAD_ERROR_BUFLEN even though entire frame is there. As much as 7 extra bytes can be added to the end of the buffer and the last frame decode will still fail. If 8 bytes are added, the frame decode will succeed.
Is this a bug or by design?
It is by design. MAD will not decode a frame unless it is followed by at least MAD_BUFFER_GUARD (8) additional bytes in the stream.
This was originally to protect against reading memory out of bounds in case of corrupt Huffman data, but it also turned out to be useful to require the next frame's main_data_begin to be available in order to decode the current frame.
If by design, how can I decode the last frame without adding padding after it?
You can append another frame. :-)
The real answer is you can't. If you want to decode the last frame, you'll have to add some padding. For an example of how to do this for both mmap()- and read()-based input, see madplay's decode_input_mmap() and decode_input_read() routines in player.c.