We all know from guru's test that --vbr-new is performing better. and most of us are using it anyway.
so should it be default in upcoming releases?
(so that we have to write -V2 only in commandline)
and for old vbr method we can use -V2 --vbr-old

While the -vbr-new tag is still in testing, I don't really see any reason to make it as a default yet. From what I have read it seems to perform great, but it's still got a ways to go before being a default setting like APS and others.
J

I know from guru's tests that 3.97a -V2 --vbr-new is better than -V2, and is also better than 3.96.1 -V2.

I'm not sure that -vbr-new is better on other -V values, and in 3.96.1 it seems to be worse on -V4. (That is, I've found artifacts that show up on 3.96.1 -V4 --vbr-new, that don't show up on 3.96.1 -V4.)

I don't know if --vbr-new should become the default. However, I'm currently using it, encoding with Lame 3.97a11. In some sense, it doesn't matter if it becomes the default - it's easy enough to type "fast" in between "preset" and "standard", or to specify --vbr-new.

edit: clarification of wording.

--vbr-new is a technology improvement; such things happen all the time (hopefully). It would seem sensible to roll improvements in to subsequent releases of products. If there is no identified quality or compatibility regression (which may not yet be determined) then what is the argument for not making it the default?

Correct me if I'm wrong, but in older version (prior to 3.97a), vbr-new leads to more speed and less quality, in general. In 3.97a, it looks like vbr-new leads to better quality on all -V values, after a couple of tests.

I think we're close to the conclusion that vbr-new is definitely better and can be made default. However, I also think it's a little to early to make final conclusions yet.

vbr-new should be standard in 3.97.

If its not desired, you could use Lame 3.96.1.
But more testing have to done.

Personally I use APS with 3.96.1, avg. bitrate is lower than using v2 vbr-new with 3.97.a11. I'm still using lossy codecs to save discspace
So vbr-new isn't for me such a great improvement in this case.

I think that guruboolez has indicated that 3.97a11 --vbr-new with -V2, -V5, -V6 and -V7 is state of the art at each target bitrate. It means -V3 and -V4 is better with --vbr-old right now.

Double speed with practically same bitrate and quality is a great improvement in my eyes.

Does this commandline include vbr new? The thing is that I do not know about vbr new or old, but I think that vbr new would be better.

If the above commandline does not include vbr new, how can I make it include it? Just by adding -vbr new at the end?

Excuse me, for my rather stupid question but I have no previous experience with commandlines.

or



See here


Sergio

Or even --preset standard --vbr-new

At least thats what ive been using.

That makes me think of one thing: if vbr-new is made the deafult, how do we remap "--preset standard" and "--preset fast standard"? Should they be the same thing and introduce something like "--preset old standard" or "--preset slow standard"?

Sergio

According to this post by Gabriel, that is not exactly the same as -V2 --vbr-new, which is the recommended use for this switch.


I would say "preset old standard", because the word "slow" can be misleading. People might think that slow = better quality.

I totally agree with you. And, yes, that issue is already addressed in the thread you pointed to, which I think would be a good think if it will be merged with this one.

I remember seeing a test by bug80 (when he's testing the new Helix encoder against Lame) where 3.96.1 -V5 and 3.97a11 -V5 --vbr-new are not statistically different, but 3.96.1 -V5 had the slightly higher score.

edit: had quoted the wrong text

That test can be found here.

Note, that 3.96.1 -V5 and 3.97a11 -V5 --vbr-new were not statistically different to my ears.

Bug80. In your listening test comparing 3.97 APS vbr new to 3.96 APS it appears you used the command line --alt-preset standard --vbr-new. Can you confirm this? If so, are your results now invalid

The post you pointed me to doesn't really clear things up properly. Is using -APS --vbr-new suboptimal compared to -V2 --vbr-new. How do we know exactly whos listenting tests were using the "correct" command line?

If I remember it correctly, yes I did

It sucks, I currently don't feel like doing the test again. Maybe later. However:

1) The difference between -V2 --vbr-new and --aps --vbr-new is marginal. I've just re-encoded a CD and the difference was only 1% in file size.

2) If -V2 --vbr is really better than --aps --vbr-new on all samples, than my final conclusions will still hold.

so it can be done like this.
for -v0 to -v2 --vr-new default
and for v3 & v4 old is default
so ultimately we get highest quality by using simply -V n

Based on my own experience, I'd like to see --vbr-new being the defaulted VBR mode. But I would also see more blind comparison between both VBR modes.
I'm now using --vbr-new for all my encodings, and it's not only for speed. It doesn't matter for me which VBR mode is used by default: I'm knowledged enough to set LAME. But I guess that most LAME users don't know what --vbr-new exactly is.
Changing the defaulted VBR mode could be worth for many people. They would probably appreciate the gain in speed with this hypothetical future LAME version. It's clearly more noticeable that all progress done in the quality domain.

My wish is not to see the current VBR mode removed from LAME code, but rather to see it remapped into something like "--vbr-legacy". I'm pretty sure that this new switch will become the must-have command line for several P2P oriented guide, exactly like CBR192 dual stereo in the past and apparently 3.90.3 now. But for rational users, basing their opinions on tests rather on rumors or fuzzy feeling, the current VBR mode has apparently no advantage at all. --vbr-new is now mature, and could IMO be used without moderation

Here's a (somewhat) related question --

--preset standard

OR

-V 2 --vbr-new

Hehe...try it out and find out for yourself...this entire thread is basically asking that exact question.
J

@tycho: Could you provide a link to the relevant post? Can't seem to find it via search.

@AudioRedbear: --vbr-new seems to work well only with 3.97 alpha. --preset standard is more appropriate for 3.96 and 3.90.3.



Link

Summary & links here.

For the first time I am aware of, I disagree with guru.

I think that as soon as --vbr-new can be shown to be at least equal in quality to --vbr-old with all -Vn levels, and perhaps even better with some levels, --vbr-old should be discontinued entirely, so that no --vbr-xxx switch is needed, or even available.

Screw the P2P guides and their pompous anality.

Regards,
Madrigal

I feel slightly embarrassed to respond to this* as the sole basis of whether vbr-new is better than the current default is based on other users' listening tests - generally referring to the tests performed by the remarkable guruboolez. On this subject, I am glad to see bug80 taking an active role in recent weeks. Apologies to those other active testers, but before bug80, guruboolez was the only tester that I was really aware of. Where's the "Let's buy guruboolez a pair of silk-lined ear-protectors" thread?

Anyway, it appears to me that vbr-new has reached maturity, and along with the fact that 3.97 will be the new HA recommended version, it seems fitting for LAME to discard its other aged legacy, and go with vbr-new as the default.

I don't see why the current model needs to be dropped. --vbr-old is a valid LAME switch already.

LAME is dead, long live LAME!

--
* ... but the fact that I don't know what I'm talking about has never stopped me before, so...

Agreed. My comments about dropping it were intended only as one small step towards the simplification and tidying up of an infamously cluttered and dangerously open front end.

Regards,
Madrigal

On one sense I agree but it seems that LAME code has several things that are maybe not needed anymore (LAME devs may correct me if I'm wrong). IIRC, one part of the work of Takehiro is to dust LAME 3.x branch and removing all unecessary code.
On the other side, the current VBR mode could offer some improvements with some samples. Some people might be still interested to play with switches.

Unfortunately, yes. That is exactly what I meant by "dangerously open" in my previous post.

Also, if --vbr-old really could offer some improvements with some samples, as you suggest, then one of my main criteria for dropping it would be at least partially invalidated; namely "as soon as --vbr-new can be shown to be at least equal in quality to --vbr-old with all -Vn levels". It would of course be pointless to add "and with all samples" to this, owing to the sheer volume of presently possible samples, and to the fact that none of us knows what the future may bring our way.

That said, if this kind of "dusting" simply must wait for version 4, then so be it. I'm only a user, not a developer.

Regards,
Madrigal

i think this poll is premature, given the testing nature of 3.97 atm

now, if this poll was started just before 3.97 went final, or perhaps included more testing to validate it, then i could see it being useful


later

It will be gone in 4.0 afaik, but you can't remove backwards-compatible flags from a minor-version release. That's why --r3mix is still in there!

Although --r3mix at least refers to a better setting now - I think it's -V3 or so.

I agree that this thread is a bit premature. For chrissake, this is an alpha, notwithstanding the fact that a lot of HA members are using the 3.97a for their default encodes.
We are getting carried away with guruboolez' enthusiasm for the new lame, with good reason too ;-)

:unrelated: what's the current state of --r3mix, anybody?

Same goes for aoTuV and MPC Not to mention EAC
Note that the alpha11 will soon be labeled as "beta" and therfore bring much piece of mind to cautious users.


The former --r3mix doesn't exist anymore. The preset was kept in LAME code for compatibility reasons (several GUI still propose this preset) but now call the new -V3 --vbr-new command line.