Rockbox

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
frame.

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
http://www.mars.org/mailman/public/mad-dev/2001-
November/000391.html