Now the related buffering problem:
LAME buffers input data until it has at least 1904 samples. It then
starts processing them.
The old MDCT routines processed 1728 samples and had a delay of 528.
(introduced in 3.54) But the new MDCT routines, because the delay is
so small (48 samples) actually need 2014 samples to be in the buffer!
If you use the lame command line encoder, for MPEG1, this bug would
not be found because the buffer always has well over 2014 samples
in it. But it was possible to trigger it in MPEG2 encodings.
It would also be possible to trigger this bug in programs
that use lame_enc.dll and pass LAME data that is not in
chunks of 1152 samples. (all programs I know about which use
lame_enc.dll do pass in 1152 samples at a time, so they are ok)
This bug is now fixed in CVS. I will put out another beta release
with this (and those VBR fixes) later today.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
