So I've been reading up on Lame's -V switches, and have learned that -V4 matches up to --preset medium (in Lame 3.95 and beyond), and -V2 is the same is --preset standard. Also, --vbr-new enables the new vbr algorithm that is equivalent to "fast" preset, so that -V2 --vbr-new is equivalent to --preset fast standard.

Lame documentation says that the new vbr algorithm, while being much faster "may" be slightly lower quality.
What I'm wondering is, what are the differerences?
As I understand it, the --vbr-new algorithm has been around since 3.89 or 3.90. Has it improved since then, or stayed static and is just a faster but slightly less reliable option?

I've encoded a few wav files and found that --vbr-new (or "fast" preset, whether on standard of medium) produces somewhat lower bitrate, usually 8-10 kbps difference.
Also, the bitrate isn't "spread out" as much - that is, if a vbr file's average birate is 160, --vbr-new will produce more 160 kbps frames and fewer 128 and 192, in comparison with the standard default (aka --vbr-old) algorithm.

My main question is, is --vbr-new any worse than the original vbr algorithm, beyond what would be expected with an 8-10 kbps drop in bitrate?

The related question is, how many people use "fast" preset aka --vbr-new?
Aside from the quality question, I've got a relatively slow machine (encodes 3.96.1 --preset standard at around 1x) and the speed gains would be nice for when I'm not batch encoding overnight.

Well, VBR New seems to be better than old on the newer LAME versions, namely, the 3.97 alphas.

See here, and here.

On older versions, I would say that the old VBR mode should be better.

Thanks. I'd read those threads before, but hadn't noticed the stuff about new vbr (b/c I'd not been interested in it then).

Anyway, is --vbr-new aka --preset fast XX thought to be as good or better than the regular/old algorithm with 3.96, or just with the development of 3.97?

According to Guruboolez' tests it seems that it is only better for LAME 3.97

But according to the documentation that comes with 3.96.1:

Did I test 3.96.1 VBR against 3.96.1 VBRNEW? Were they tied at the end? Honestly, I can't remember...

I don't recall seeing those results, and I read almost every test result you post. I only recall seeing 3.96.1(vbr-old) vs. 3.97a7(vbr-new).

According to Guruboolez' Nero AAC test and LAME fast vs old

"fast" is better "normal" most of the time

LAME vbr-new = Nero Fast
LAME vbr-old = Nero Normal

The conclution I can make from several test by guruboolez is that "fast" technique will produce smaller file size and better quality than the "old" slow technique

Please note that I've never compared Nero AAC 'fast' encoder (which isn't faster than 'high' mode) on anything else than classical music and moderate bitrate (130~kbps). Therefore, I wouldn't say that Nero AAC fast is better most of the time. I simply don't know how it would perform with other musics and other bitrate range.

Yeah...tested! the fast mode is slower than the high mode?????? weird!

but i remember someone said that fast mode is something like using scale factor....is it Gabriel who said that?...oh I've forgotten

vbr-new also use that method.......

Guess have to wait for Gabriel to explain this

Thanks

"Fast" in Nero AAC is trying to directly compute the optimal scalefactors. The inherent difficulty with this method is, in my opinion, the bias introduced by the non-linear quantization.

So my guess is that Nero "fast" is doing a direct scalefactor computation, but also a few iterations around the computed values to check if the result is optimal.

Now I am lost. Weren't we talking about LAME here?

so do LAME --vbr-new also use direct scalefactor computation?
actually I don't really know what scalefactor computation means.......but "direct" should be fast?

since this topic is about fast preset compared to old:-

What is the main difference between --vbr-new & --vbr-old?
is it only the way it calculates bitrate allocation, curve?
other things such as psymodel..lowpass and other filters are the same between new & old

bad english...hope you understand my sentences, because it is a bit hard for me to express it clearly
thanks

No.
Psy model is the same between vbr modes.

If I'm reading this thread correctly, --vbr-new has tested better in quality for the new 3.97 alphas, but not necessarily for 3.96.1. What I would like to know is, while --vbr-new may not be any better in quality for 3.96.1, is it (or should it be) any worse?

Regards,
Madrigal

- from the LAME 3.96.1 documentation.

Does everyone agree with this part of the documentation?
Anyone disagree?

Regards,
Madrigal

make your own tests or stick with the presets...you can also wait for LAME 3.97 final and see if anything changed...

Madrigal's question: is 3.96.1 --vbr-new any worse than --vbr-old, is the one I'm especially interested in as well. And while it's true that we can always make our own tests, it's very useful for me to hear what people with better ears and equipment think, as I want encodes that sound good not only to me... The general consensus, to the extent that there is one, seems to be what shadowking said in this thread: there's not much difference, and it goes both ways.

Thanks for that link, it was very helpful. 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.

Regards,
Madrigal

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: 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.

so where does this leave the vbr mtrh setting ? [using cdex]

Both vbr new and vbr mtrh are the same in current lame releases. I think one of them was scrapped some time ago because of lower quality and both switches now default to the same mode.

i encoded a track the other day and started playing around with the q value. here's what i found with my equipment:

3.90.3 [razorlame]

-V 2 -q 0 2m5s 7.68MB[7866KB]
-V 2 -q 1 2m5s 7.68MB[7871KB] *
-V 2 -q 2 1m39s 7.67MB[7863KB]
-V 2 -q 5 1m6s 7.59MB[7780KB]
-V 2 --vbr-new -q 0 1m50s 7.98MB[8174KB]


3.92 [encoded thru cdex]

-V 2 -q 0 2m22s 7.70MB[7894KB]
-V 2 -q 2 1m50s 7.70MB[7890KB]
-V 2 -q 5 1m15s 7.62MB[7812KB]
-V 2 -q 9 1m15s 7.62MB[7812KB]
-V 2 --vbr-new -q 0 1m17s 8.01MB[8212KB]
-V 2 --vbr-new -q 5 1m17s 8.12MB[8316KB]


3.96.1 [razorlame]

-V 2 -q 3 2m5s 6.95MB[7121KB]
-V 2 -q 4 2m5s 6.97MB[7147KB]
-V 2 -q 5 2m5s 7.08MB[7257KB]


3.97 [BluRazorLame]

-V2 -q 0 2m35s 6.97MB[7139KB]
-V2 -q 1 1m48s 6.97MB[7142KB]
-V2 -q 2 1m35s 6.98MB[7156KB]
-V2 -q 3 1m35s 6.98MB[7156KB]
-V2 -q 4 1m40s 7.00MB[7179KB]
-V2 -q 5 1m40s 7.12MB[7297KB]
-V2 --vbr-new -q 0 1m20s 8.32MB[8527KB]
-V2 --vbr-new -q 1 1m32s 8.32MB[8527KB]


from what i can gather, the 3.90.3 and 3.92 compiles behave in about the same manner for this .wav file. the 3.92 creates a slightly bigger file size than the 3.90.3 but it is quite marginal. both produced smaller filesizes as i raised the q value when using --vbr-old. on the other hand, when using --vbr-new, the files increased in size as the q value went up towards 9.

the 3.96.1 and 3.97 both create much smaller[bout .5 MB] file sizes than the previous two when using --vbr-old, but when raising the q value towards 9 the file sizes increased. this increase took place whether using --vbr-old or --vbr-new.

One would assume that when increasing the quality setting the file would end up smaller. not the case with this particular .wav file. i found some of these "read me's" in some of the downloadable compiles here RareWares


* -q 0..9 algorithm quality selection

Bitrate is of course the main influence on quality. The higher the bitrate, the higher the quality. But for a given bitrate, we have a choice of algorithms to determine the best scalefactors and huffman encoding (noise shaping).

-q 0: use slowest & best possible version of all algorithms. -q 0 and -q 1 are slow and may not produce significantly higher quality.

-q 2: recommended. Same as -h.

-q 5: default value. Good speed, reasonable quality.

-q 7: same as -f. Very fast, ok quality. (psycho acoustics are used for pre-echo & M/S, but no noise shaping is done.

-q 9: disables almost all algorithms including psy-model. poor quality.


* --vbr-new new VBR mode

Invokes the newest VBR algorithm. During the development of version 3.90, considerable tuning was done on this algorithm, and it is now considered to be on par with the original --vbr-old.
It has the added advantage of being very fast (over twice as fast as --vbr-old).

"fast" - Enables the new fast VBR for a particular profile. The
disadvantage to the speed switch is that often times the
bitrate will be slightly higher than with the normal mode
and quality may be slightly lower also.



* --vbr-old older VBR mode

Invokes the oldest, most tested VBR algorithm. It produces very good quality files, though is not very fast. This has, up through v3.89, been considered the "workhorse" VBR algorithm.


these text files seem to clear it up a bit for me i think. apparently in layman's terms when u lower the quality [raise the q value] the encoder starts slinging bits whether it's actually needed for better quality or not. vbr new just seems to make bigger files, whether the quality is better i know not. the exception to this was the two older encoders while using --vbr-old. they maintained and actually lowered the file size as u raised the q value [lower the quality]

Expected behavior for current versions:

Increasing the quality (ie lowering the -q X value) is enabling some more efficient methods. It means that for a VBR file, your filesize will decrease a little, and for a CBR file, the size will of course be the same but quality will be a little better.

Wouldn't this be because, due to better tuning, it doesn't need to jump up to higher bitrates for problem areas. By not jumping up the scale so often, and while attempting to attain a near-average bitrate, it doesn't need to jump down the scale to compensate.

I say this not out of any knowldege, but it just seems logical.

So, in fewer words: perhaps it's improved tuning.

I think it would depend a lot on the source material. If the source has segments of near-silence, then the encoder should drop to very low bitrates. But on the average rock song it is probably better off remaining more constant, in line with your analysis. If the encoder is trying to maintain an average bitrate of 160, every 320 frame requires two 96s and a 112 to compensate. On the other hand, APS isn't trying to stick to any specific average, so it shouldn't care.

To know what is really going on we would need several more test samples with varying dynamics. Personally, I trust the Lame devs and will be moving over to vbr-new whenever they give the official word that it's better than vbr-old. It would be interesting to know more about what the encoder it doing and why. Even though I only use mp3 for my portable, I always turn on verbose and watch the ####'s bounce around.

Agreed.

But there must be some guidance there, otherwise APM would be the same as APE.

This is why I used the term "near-average" - but I knew it would get me in trouble.

As you say, I'm still interested in hearing a response from someone who knows, and isn't merely hypothesizing. I am also looking forward to the switch to vbr-new.

Ciao now brown cow.

There is nothing scientific about what I'm going to say, but here it goes:

I've been using the --vbr-new algorithm for some time now and the results are pretty fair. I can't spot any difference qualitywise with --vbr-old at least for the preset I'm using (medium). I don't use mp3 for archiving, so I can live with some-possible-but-unproven quality degradation...

I'd made this switch earlier, but was bothered by the narrower bitrate range that I noticed above, and then happened to run across an obvious artifact in one of my -V4 --vbr-new encodes. This artifact did not show up in -V4 (--vbr-old), and while it's just one example, I've switched back to using just -V4 (which defaults to --vbr-old) for the time being. The discussion of that sample which messes up --vbr-new but not --vbr-old is here.

Synthetic Soul: I expect better vbr algorithms to jump around relatively more than less. Not at random, but even in regular rock music there's enough variation in complexity from frame to 1152-sample frame. Also, to clarify, the Lame presets aren't trying to maintain an average, abr-like, so there's no need for "compensation" as there would be in an abr encoding algorithm. The generally similar average bitrate on the presets is due entirely to their aiming for a certain quality, and most music requires a bitrate within a certain average range to meet that quality level.

So basically what is the final answer??

Which one is better than the other???

I kinda agree with beto since i have used -V 0 --vbr-new as well as -V 0 --vbr-old for encoding my cds, but the only part it effects is in the size of the mp3 files. VBR old does create a bit larger file than compared to VBR new.

Read the stickies. And don't do unneccesary archeology.