* Rob Leslie (rob@mars.org) wrote:
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?
You're right, it was a bug in my input callback. I've looked over that routine several times but I missed the problem up until now. Though I was preserving the data left over from the previous frame, I passed to mad_stream_buffer() only the length of the data I had just read from the file, instead of adding that length to the length of the leftover data. It was a subtle bug that rarely manifested itself.
We seem to have come across another instance of strange behaviour dealing with libmad. Quoting Dominic Mazzoni, Audacity's main author:
All this time I thought that libmad was just slow compared to xaudio, but I just realized that importing a 1-minute song takes exactly 1 minute, importing an 11-second song takes exactly 11 seconds, and importing a 3:04-minute song takes exactly 3:04.
BTW, I'm doing this on an Athlon/1.2 GHz, so it should be decoding at something like 10x real time.
Any idea what this would be?? Does libmad have built into it internal timekeeping that would cause this kind of behaviour?
Thanks much, Joshua