Dear Sir,
Is there a maximum size for mp3 frames that I could safely set as the buffer size?
According to "Bertrand Petit" who wrote madlld (mad low-level demonstration): (can found in MAD main page)
* When this occurs, the remaining unused bytes must be * put back at the beginning of the buffer and taken in * account before refilling the buffer. This means that * the input buffer must be large enough to hold a whole * frame at the highest observable bit-rate (currently 448 * kb/s). XXX=XXX Is 2016 bytes the size of the largest * frame? (448000*(1152/32000))/8
Yick Hong Kong, China
joshua@haberman.com 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?
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?
Thanks, Joshua