Help - Search - Members - Calendar
Full Version: V4 --vbr-new vs --vbr-old in Lame 3.96.1
Hydrogenaudio Forums > Lossy Audio Compression > MP3 > MP3 - Tech
Dologan
I recently encoded the "Best of the Doors" album (one of the several very similar compilations there are) in Lame 3.96.1 with both the -V4 --vbr-new and -V4 --vbr-old switches, and to my surprise, there was a ~25% difference in bitrate between them. The 'old' encode has an average bitrate of 189 kbps (quite high for -V4, IMO), while the 'new' one is 165 kbps (more like what I was expecting). V3 fast, BTW, produces an avg. bitrate of 176 kbps for the album, also more or less in line of what I expect.
I don't think the bitrate should be that different between the two VBR routines. What could be the cause of this? Is there something about the sound of the Doors that might cause this?
BTW, I haven't had time to ABX the different encodes or even to listen to them carefully, although its likely that there won't be too much of a difference for me, since the settings are near my transparency threshold.
evereux
I encoded three random albums with -V4 and -V4 --vbr-new:

[1] Gang Starr (2003) The Ownerz
[2] Bent (2004) Ariels
[3] The Prodigy (2004) Always Outnumbered, Never Outgunned

The resultant bitrates:

[1] -V4 = 140kbps
[2] -V4 = 172kbps
[3] -V4 = 175kbps

[1] -V4 --vbr-new = 150kbps +7.1%
[2] -V4 --vbr-new = 159kbps -8.1%
[3] -V4 --vbr-new = 161kbps -8.7%

Totals
-V4 = 162kbps
-V4 --vbr-new = 157kbps -3.1%

Yours doesn't appear to represent the consistent behaviour of the encoder so I don't believe there's anything to be concerned about regaring file sizes.
Dologan
I've tried ABXing the two at a random place and I haven't been able to, also because I am not sure exactly where to look.
What could possibly be about the Doors sound that causes such bitrate inflation with the 'old' VBR routine? Is there anything known which both routines handle in different ways?
earphiler
Yeah , i have a question about this as well. What is is the Deal with "-V4 --vbr-new" ? Why do people like this over "--alt-preset standard" and why isn't in the LAME settings thread that user created? thanks!
Lyx
QUOTE(earphiler @ Feb 28 2005, 08:29 PM)
Yeah , i have a question about this as well. What is is the Deal with "-V4 --vbr-new" ? Why do people like this over "--alt-preset standard" and why isn't in the LAME settings thread that user created? thanks!
*



It is (almost) the same as using "fast".

edit: the reason why it is mentioned unusually often recently has to do with the work-in-progress lame 3.97. The main difference is that the "normal" method uses the old VBR-algorithm and "fast" uses the new VBR-algorithm. In the past, the new VBR algorithm would be much faster but often create slightly higher bitrares and sometimes slightly lower quality. However, recently there have been talks that in the meantime the new VBR algorithm in the newest in-development lame-versions may be just as good as the old one quality-wise while being much faster - and thats why there is some interest going on with it right now - to check if its indeed worthy to replace the old-VBR method.

Short version of the story: for now, the info in the recommended settings thread is still valid. But it may be possible, that soon there could be a lame-encoder which uses the "fast" setting by default without any disadvantages compared to "old default method".
jaybeee
QUOTE(earphiler @ Feb 28 2005, 06:29 PM)
Yeah , i have a question about this as well. What is is the Deal with "-V4 --vbr-new" ? Why do people like this over "--alt-preset standard" and why isn't in the LAME settings thread that user created? thanks!
*



The reason that I'm interested in the '-V 4' setting is that it'll be used for my portable DAP. It results in smaller files when compared to '--preset standard' and so I can fit more files onto my player. And the quality is good enough for me. I think many others are interested for the same reasons. Judging by this poll and this newer poll it seems that MP3 is still very popular and seems to be mainly because of it's hardware support... Digital Audio Players!

I agree with Lyx about the '--vbr-new' part.
earphiler
I guess I wanted to figure out more what the deal was on -V4. thanks a bunch for the responses and I think I will use -V4 --vbr-new for speed and good quality/filesize ratio to cram tons of songs on my iPod photo 30GB that I ordered today (and will hopefully be here early next week).

My other question is this -- and it's rather opinionated -- I have 40GB of mp3s that are all in different quality. Most of them were ripped with aps setting, so I was just wondering , what do you think I should do with these? Re-encode them all or leave them as is and rip at this new setting from now on?

For numerous albums I could re-rip them so that I wouldn't have one lossy format converted to another, but there are some that I have no clue where they are anymore.

EDIT-- also for bitrate i choose in EAC below the commandline, it makes a difference in the avg bitrate. Shouldn't it be that if I enter my own commandline, the bitrate scaler should not interfere? I am v. confused by this (this is for -V4 --vbr-new)
jaybeee
QUOTE(earphiler @ Feb 28 2005, 08:54 PM)
...

My other question is this -- and it's rather opinionated -- I have 40GB of mp3s that are all in different quality. Most of them were ripped with aps setting, so I was just wondering , what do you think I should do with these? Re-encode them all or leave them as is and rip at this new setting from now on?

For numerous albums I could re-rip them so that I wouldn't have one lossy format converted to another, but there are some that I have no clue where they are anymore.

...
*



If you have the disk space then I would highly recommend re-ripping your CDs to produce lossless copies. FLAC is my personal choice. Look here for a great guide on whoch lossless format to choose.

If you haven't got the space, then I think it would be a waste of your time to re-encode from --aps to -V4. Maybe just re-encode the ones that are not encoded using LAME and/or in --aps.
timcupery
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.
Dologan
Wow, that graph is actually quite surprising. Vbr-new barely uses any frames above 256 (and under 160) for the samples you provided. I don't think a narrower distribution has to be necessarily bad, although this would make the vbr-new more like a quasi-ABR than full VBR, which makes kinda sense with my observation that vbr-old encodes tend to have a wider bitrate fluctuation than vbr-new does.
timcupery
QUOTE(Dologan @ Feb 28 2005, 07:47 PM)
Wow, that graph is actually quite surprising. Vbr-new barely uses any frames above 256 (and under 160) for the samples you provided. I don't think a narrower distribution has to be necessarily bad, although this would make the vbr-new more like a quasi-ABR than full VBR, which makes kinda sense with my observation that vbr-old encodes tend to have a wider bitrate fluctuation than vbr-new does.
*

Yeah, quasi-abr is pretty much what I thought of when I first saw the distribution.
Btw, I like your quote.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.