• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category
  • Assigned To No-one
  • Operating System
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by lowlight - 2006-01-17
Last edited by lowlight - 2006-01-18

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

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.

Closed by  preglow
2006-04-27 23:27
Reason for closing:  Fixed
Project Manager

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?

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.

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


Available keyboard shortcuts


Task Details

Task Editing