FS#2926 - Iriver bugfix: libmad won't decode the last frame

Attached to Project: Rockbox
Opened by Mark Arigo (lowlight) - Tuesday, 17 January 2006, 21:48 GMT
Last edited by Mark Arigo (lowlight) - Wednesday, 18 January 2006, 16:59 GMT
Task Type Patches
Status Closed
Assigned To No-one
Operating System
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Libmad will not decode the last frame unless there
are 8 bytes of padding. See:

The easiest way I could think of to add the padding
was during the buffering in playback.c where it's
easy to find the end of the file.

This patch applies on top of patch #1408536 since we
need the id3v1 tag properly stripped.
This task depends upon

Closed by  Thom Johansen (preglow)
Thursday, 27 April 2006, 23:27 GMT
Reason for closing:  Fixed
Comment by Linus Nielsen Feltzing (linusnielsen) - Wednesday, 18 January 2006, 14:38 GMT

If I understand correctly, this is only a problem when
playing the very last frame in the audio buffer, not when
there is another MP3 track in the buffer after the current
one. Right?
Comment by Mark Arigo (lowlight) - Wednesday, 18 January 2006, 16:04 GMT

Correct, if you streaming the mp3's together, but the
rockbox playback engine doesn't appear to do that.

To explain, look at mpa.c lines 170 (request_buffer) and
173 (mad_stream_buffer). The buffer size returned from
request_buffer and sent to mad_stream_buffer is smaller of
the either requested buffer size or the bytes left in the
current track. For the last frame, request_buffer returns
the framesize and mad_stream_buffer generates an error
because it needs the extra padding to properly decode the

Unless I'm mistaken, this happens for every mp3 (maybe mp2
& mp1 too).

Should you investigate this problem, be sure to comment
out the gap removal parts in mpa.c, because the final
frame is often skipped if there's a lame header with the
encoder padding.

Coincidently, when the id3v1 tag was not properly stripped
the extra 128 bytes of the tag allowed for the decoding of
the final frame.
Comment by Mark Arigo (lowlight) - Wednesday, 18 January 2006, 16:59 GMT

Upon further reflection...if we are sure that the end of
the inputbuffer is not the end of the file buffer (how?),
then we can just increase size + 8. However, it's not
clear if those extra 8 bytes have to be zero, or the start
of a valid mp3 frame (if an mp3 is the next track), or
anything (if the next track is an ogg, flac, etc). There's
talk of zero padding here