I've raised a lot of the issues here, in
this thread. I've noticed that --vbr-new sometimes has a
much lower bitrate (especially with -V4), and this happens mainly on samples where the bitrate in -V4 (--vbr-old) balloons, either in crunchy-guitar metal music or in live recordings with lots of high-frequency audience noise. Generally, --vbr-new seems to stick to a narrower distribution of bitrate, and -V4 --vbr-new likes to stay closer to 160 kbps.
Especially look at the visuals in my final post at the bottom of the above thread, giving you a good sense of that "narrower range." I've reproduced those here:
QUOTE(timcupery @ Feb 26 2005, 10:17 AM)
QUOTE(Madrigal @ Feb 25 2005, 06:00 PM)
Unless anyone knows of a clear reason not to, I'll be sticking with 3.96.1 -V1 --vbr-new --scale x.xxxx at least until 3.97 stable comes out.
Yeah, I've switched to using -V4 --vbr-new instead of -V4 (which defaults to --vbr-old). I've had bitrate differences as large as 20 kbps, always with --vbr-new being lower bitrate. The only thing that bugs me is, why does --vbr-new have much less variation in the bitrate of given frames?
In the old vbr mode, there's much wider distribution of frame bitrates. This holds for multiple -V settings, and over a lot of samples of music (all "pop" and rock music, though). Here's an example of what I'm talking about; these distributions are pretty typical:
QUOTE(Lame 3.96.1 output)
-V2
32 [ 1] **
128 [ 17] %%%%%%%%%%%%%%%%%%%%%%**
160 [ 43] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
192 [ 25] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******
224 [ 28] %%%%%%%%%%%%%%%%%%%%%%%%%%**************
256 [ 47] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%***********************
320 [ 31] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%****
average: 219.3 kbps LR: 154 (80.21%) MS: 38 (19.79%)
-V2 --vbr-new
32 [ 1] *
128 [ 0]
160 [ 13] %%%%%%%%**
192 [ 95] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%***************
224 [ 80] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%********
256 [ 3] %**
320 [ 0]
average: 203.3 kbps LR: 154 (80.21%) MS: 38 (19.79%)
-V4
32 [ 2] %%%
- - - - -
96 [ 1] **
112 [ 9] %%%%%%%%%%%%%
128 [ 18] %%%%%%%%%%%%%%%%%%%%%%%%%
160 [ 48] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*
192 [ 23] %%%%%%%%%%%*********************
224 [ 48] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%***********************************
256 [ 41] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*************
320 [ 2] %%%
average: 195.1 kbps LR: 138 (71.88%) MS: 54 (28.13%)
-V4 --vbr-new
32 [ 1] *
- - - - -
128 [ 1] %
160 [ 83] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%***********
192 [ 70] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**********************
224 [ 37] %%%%%%%%%%%%%%%%%%%%%%********
256 [ 0]
320 [ 0]
average: 183.2 kbps LR: 138 (71.88%) MS: 54 (28.13%)
Anyway, I don't know if this is reason to worry about --vbr-new, but it seems to me that a better vbr algorithm should have a
wider distribution of frame bitrates, not a narrower one.