Joshua Haberman wrote:
Currently Audacity uses a 64k input buffer when reading mp3s with libmad. This has worked great for the most part, but I've received a report that one particular mp3 will put Audacity into an infinite loop upon import. Since a trace revealed that the input callback was looping endlessly, I suspected that the buffer wasn't big enough to hold an entire frame, and the input callback was sending libmad the same partial frame over and over.
I suggested that this user double the input buffer size, and that fixed the problem.
Earlier when I asked you about this issue, you said mp3 frames are relatively small (around 418 bytes) so I'm very surprised that 64k wasn't big enough to hold an entire frame. Can you think of any other reason why increasing the buffer size would solve this problem?
Sounds like it could be a bug in your input/streaming code, triggered by the unlucky buffer size? Out of curiosity, what bitrate and sampling frequency was the mp3 that caused problems?
Is there a maximum size for mp3 frames that I could safely set as the buffer size, or would I have to dynamically size the buffer to be completely safe?
The absolute theoretical maximum frame size is 2881 bytes: MPEG 2.5 Layer II, 8000 Hz @ 160 kbps, with a padding slot. (Such a frame is unlikely, but it was a useful exercise to compute all possible frame sizes.) Add to this an 8 byte MAD_BUFFER_GUARD, and the minimum buffer size you should be streaming to libmad in the general case is 2889 bytes.
Theoretical frame sizes for Layer III range from 24 to 1441 bytes, but there is a "soft" limit imposed by the standard of 960 bytes. Nonetheless MAD can decode frames of any size as long as they fit entirely in the buffer you pass, not including the MAD_BUFFER_GUARD bytes.
A 64K buffer is surely large enough, which makes me think you have a different kind of problem...