Re: MAD doesn't decode last frame in stream buffer unless it has 8 bytes extra

Rob Leslie <[email protected]>
Newsgroups gmane.comp.audio.mad.devel
Message-ID <[email protected]>
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.

-- 
Rob Leslie
[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.