Joshua Haberman wrote:
Each time you refill your buffer, you need to preserve the data in your existing buffer from stream.next_frame to the end.
This usually amounts to calling memmove() on this unconsumed portion of the buffer and appending new data after it, before calling mad_stream_buffer().
Wonderful, that took care of the seaming problem! How can I determine the optimal buffer size to keep memmove()ing to a minimum? Should I hard-code a size that corresponds with a common mp3 frame size, or should I try to determine it a runtime?
The size of an MP3 frame varies with the bitrate, sampling frequency, and time (on account of occasional "padding" slots), so trying to guess the frame size is unlikely to be beneficial. Since you'll only be calling memmove() on less than a full frame, for best results, I recommend a buffer size large enough to hold several frames.
Frames are relatively small. A 128 kbps 44100 Hz MP3 frame alternates between 417 and 418 bytes. Size can vary from 24 bytes (8 kbps 24 kHz) to 1440 bytes (320 kbps 32 kHz). The absolute minimum buffer size is a single frame, plus MAD_BUFFER_GUARD bytes.
Another way to consider it is that a 40000 byte buffer holds enough MP3 data for 2.5 seconds at 128 kbps, or 1 second at 320 kbps. This is a reasonable buffer size and is one that I often use.
It seems like the worst case would be having the buffer length just short of two frames -- then you'd copy almost all of the second frame in each run. Best case would be three or four frames at once...?
The larger the buffer, the better...
Cheers, -rob