> I'm been encoding some wavs off of CDs using the builds on
> dkutsanov's website. I found an odd change in lame encoding when
> going from lame383a1_f to lame383a1_f. (day before yesterday to
> yesterday).
>
> I am encoding my files with -m j -h -v -V 2 -b 96
>
> On all previous builds of lame, in VBR encoding I have never gotten
> frames requiring bitrates greater than 256. As of yesterday evening,
> just after the announcement of the 383 beta, the version I pulled down
> has been encoding more than 1% of all my wavs frames with a bitrate
> of 320.
>
The default max bitrate was changed to 320 for a couple of reasons:
1. This was something I only just realized:
A CBR bitstream will make use of the bit reservoir, which will allow
some of the frames to be as large as a 320kbs frame with 0 reservoir.
In VBR mode, LAME tries to keep the bitreservoir close to 0. Thus
limiting the max bitrate to 256 will not allow frames as large as
would be possible in a CBR stream. With 256kbs max, VBR actually was
not capable of achieving the same quality is a 256CBR.
2. Another reason not to allow 320kbs frames was that, with strict
adherence to the ISO standard, a 320kbs ends up wasting bits
(all the bits in reservoir, and all bits that would be
put in the reservoir for the next frame). Now that we ignore
this ISO restriction, we dont waste any bits by using 320kbs frames.
> If I understand correctly (and I probably dont) cd ripped wavs are by
> definition using a bitrate of 256. So... there should never be call to
> need a bitrate of 320 to encode frames - correct?
>
cd ripped wavs are actually 1411 kbits/s!
I think you are refering to the fact that a 256kbs CBR MP3
is statistically indistinguishable from the original by most
people. But because of the bit reservoir, a 256kbs CBR MP3 will
actually have about 10% of the frames use as many bits as
in a 320kbs+0 reservoir frame.
Mark
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
