I wanna ask you a dumb question.
I have downloaded the latest recommanded Lame version.
I am encoding to mp3 usind CDex or Razorlame. usually i use --alt-preset insane.
but now i read that the "--alt-preset" thing is dead.
Updating to the latest recommanded Lame version should change me any settings in CDex for example? I have 3.97 in CDex right now but there are still --alt-preset. Mr. Questionman is reconizing the rezulted file as encoded with --alt-preset insane (?).
So, in conclusion. The ultimate Lame must change something in the programs we use or is just an internal thing.
Sorry for this stupid question

Vietwoojagig:

What exactly do you want?

Because HA is recommending a Lame version labeled as beta, you want the Lame devs to remove the beta tag? Or do you want the HA recommendation be reverted to another (marked as stable) version. What, what?


As Lyx already pointed out, the "you" you use here doesn't exist. HA and the LAME devs are not the same thing. If you only trust developers on what is the recommended version then why would you care about the HA one? But if we all must trust devs on their recommendations (or nomenclature) then there wouldn't need to be a HA recommendation at all, because it would only be redundant. The opinions of stability of this LAME version just differs between HA and Lame. If you have found any major flaws in this version, I'm sure people would be happy to hear about it.

Basically what you are saying is that HA shouldn't make any recommendations at all (or at least that those would be superfluous) and that many of the audio encoders and even software people are using for back-up shouldn't be used at all. But IMO it doesn't make sense to attach such high consequences on what is just a word with a very ambiguous meaning.

alt-presets aren't dead - they just aren't recommended any more because there is a more clear and more compact way of specifying the intended encode quality. The -V flags replace the functionality of the --alt-presets.

alt-presets still work (AFAIK), but map to -V numbers.

As I already said in my very first post: Wait until the beta-flag is removed and then recommend it. Why getting hectic so close to the final version?

I was surprised to see -V 3 -vbr new recommended as a transparent setting. This is the 1st time I have ever seen an MP3 bit rate average that low (175 avg) recommended as transparent. Previously, APS which is now -V 2 was always the standard for minimum transparency.

Is there a testing thread that supports the -V 3 recommendation? If it is indeed transparent, and sinc eit is officially recommended as such I assume it is, this is great news! It's about a 10% reduction in file size from -V 2 (APS) !

What is the difference between -V 2 and -V3? Is it primarily in limiting the high frequencies? (similar to the old APS with the Y switch)

The main bitrate savings come from the Y switch, but V3 also uses slightly more aggressive compression for lower frequencies, as can be seen from comparing -V2 -Y to -V3.

To stir controversy and create polemic.

There's no other reason to focus so much in four letters. Specially considering everything else here that is also beta AND recommended. Some people have too much free time on their hands, and need to find the most meaningless things to worry about.

Sigh...

Stephan explained that very clearly. HA recommended it. HA is free to recommend anything. You are free to don't follow it. It's win-win situation, no need to worry or discuss anything.
If I recommend you to stick carrots up your ssa, I'm free to do it and you are free to don't follow my recommendation.
But never, never try to pursue me that I should not recommand it 'cause you think you've got smarter way how to use carrots..
Geeez

The carrots-thing sound interesting.
I will try it!

Microsoft doesn't use the term "alpha". They use "Version 1.0" instead.

Let's change the beta to gamma and we can get over this 'huge' problem.

Encspot says that 3.97 -V0 encoded file has 58% ss (joint stereo) blocks, when the same file, but 3.96 ape encoded has 73%
3.97 -V2 and -V1 gives only 7%-10% ss blocks on that file (Madonna - Secret).

Is it OK?

What settings do you use for the "birds" sample?

I believe that the developers of LAME are the only ones that can say why they call it beta, and so far have opted to not add fuel to the fire.

That said, It has to be understood that they don't see this as a bad practice. Apha versions were advised to not be used for real encodings, and have received much testing. This testing is the one that has allowed the versioning to become beta instead of alpha.

I have no clue if there are new features expected to be added before the stable version, nor if any of them is incomplete or misbehaving. In any case, it wouldn't be the first time that a LAME version has been labeled beta, and no final version of that branch has come.

So, in the end, if the developers don't tell us (the readers of this post) not to use the version and/or recommend it, it can be understood as in being "complete enough".

God, since Lame devs already have a 3.98alpha branch please make 3.97 stable and we can end this discussion!! What harm could it bring??
I personally believe that enough testing was made in 3.97, but I also believe that some best practices in software versioning should be observed as well.
Lame can always be patched afterwards if some strange-hidden-unknown problem(s) show up.
And differently from what most people here might think coherent software versioning does make a difference for the wider audience.

Bottom line: make 3.97 final and end the discussion.


just my 2c

I just added LAME 3.97b compiles for several esoteric platforms to RareWares.

Hohoho

There shouldn't be a problem to recommend a beta as long as it's the current best version. It was about time to replace the old version because there was a lot of effort from the developers. I'm glad the new vbr model seems stable and good.

I would like to see new listening tests from Roberto with different codecs and then compare it with old tests. Maybe with 3.90.3 and 3.97b1 both in, to see the difference one more time.

The only thing I don't like about the new recommend version/settings is the very unpredictable file size. I'm not satisfied to get an 80kbps MP3 with -V 5 while aiming for 128kbps. It's a strange feeling... Quality should matter, but size too. Let's say i would like to get the best quality around 192kbps. How good is the new ABR model in comparison to the old preset 192 of 3.90.3? If ABR is recommend for use up to 100kbps (see remark), is it included in the -V switches 8 and 9?

Whenever I got files sizes much smaller than expected, I re-encode at a higher V level. This is probably a silly thing to do.

I used -V2

I am also intrigues by the big variations in file sizes and bit rates with the new -V settings. It's a paradigm shift from the old -alt preset regime.
Could an expert please comment on that, because this is throwing up unexpected issues for people who had gotten used to the results with the older versions. Quality is not an issue, as it's superiority has become an established fact.
P.S. I missed all the fun in the beta wrangles, so my 2c. All the google products except the plain vanilla search are beta. So, there...

Any chance of putting up new 3.97b versions of the special packages, i.e.
"lame_enc.dll modified to use INI File Setup"

thx.

jb

IMO, set the default configuration into 'INI' is benefit even for command line version, it means no need to create an extra ".BAT" file.

The advantage is everyone can change the 'INI' according to their needs, if they want other parameters occasionally, just override it by giving command line parameters.

Are you complaining that -V is a vbr setting, and thus produces variable bitrate?
Old vbr alt-presets were also variable in bitrate, there is no shift there (even less "paradigm shift"). If you do not want the result to be variable in bitrate, then why are you using vbr?

Well, if the encoder only needed an average of 80kbps to attain the 'quality' that you specified, why should it use any more? It would be a waste, right?

In the end, the ultimate test should be with your ears.

It's not exactly what I'm asking for. There's a problem with -V0 minimal bitrate, not the average one. For all other -V setting, the min. value on the current tables seems OK. But 230 kbps as minimal bitrate for -V0 seems to be wrong. The bitrate doesn't jump that high with musical stuff having few informations (or noise) in the highest SFB. Tested on my 150 reference full tracks (classical only): 80% of them have a bitrate inferior to 230 kbps. 31 tracks only get a higher bitrate.
That's why I'd change the bitrate range for -V0:
230...260 -> 210/220 [I let you choose]...260.

Yes. Actually, I was wondering when someone was going to ask!! I'll post them later.

3.97b1 compiles of the dll and the exe now at Rarewares mp3 section.

Nice to have a new recommended version, thanks for the effort, guys! I personally belong to the camp who find the beta term here odd but enough has been said regarding it.

Two questions:

- Does the fact that this version now has the recommended status mean in practice that there will be no more 3.97.* versions?

- How do the old presets translate to V commands and how is their quality supposed to be? I know we should use the Vs from now on, but the Frontah frontend that I use to transcode from FLAC to MP3 has the old preset commands built-in and I wouldn't want to start using a new frontend at the moment.

http://www.hydrogenaudio.org/forums/index....showtopic=18091

There's no need for people to become paranoid about the settings. The use of the old presets may be deprecated, but they still continue to work as they have throughout the life of the 3.97 branch.

No, i am not complaining. I said i was intrigued. But, paradigm shift is true strong a word, i suppose.
1. My point was that the variation in file sizes and bit rates are much larger than with the older lame version.
2. With the classical samples i use, i rarely get above 220 kbps VBR with V0 Not so with other genres.
As a corollary to this, isn't there room for a higher than V0 vbr setting because 320 kbps is so much farther away.
The older vbr alt-presets didn't produce this much of a disparity between the highest quality vbr settings which would yield bitrates in the range of 270, 280 kbps for most classical music.
I could add some examples, if you'd like to, but i'm sure you already know this. Again i should stress that i am not complaining

In all those cases you are only pointing out varying bitrates. Bitrates are irrelevant in VBR (at least in terms of the "target") - only quality matters. Do you have any evidence, that the different bitrate-behaviour has a bad influence on quality? Do you have any evidence, that V0 in 3.97 is worse than --preset extreme in earlier versions?

So, if the quality of V0 has not degraded, but the bitrate went down..... then do you know what that is? An *improvement*.

- Lyx

This is a very good question, one that I hope can be adressed by LAME devs.

About your second question: maybe you could try foobar2000?
(Although I think Frontah allows you to input your own command lines)

I do not dispute the fact that the quality has really improved and that quality is what vbr targets. But i think you missed my point. Ah well, forget it

--abr 270 and you will be happy.

thank you, gabriel. i guess that is one solution

Use -V0 and pretend you're using --abr 270, and you'll probably be just as happy .

Feel free to have a go at me..
But WHY can the NEW settings not be edited to match the existing ones?
To keep it SIMPLE..
EG LINK -V2 to --preset standard in Lame...
That way we can have the new stuff with the old setting..
Cheers

P.S is the -V2 --vbr-new the NEW --alt-present standard?
P.P.S What about updating the Wiki?

That's the way it is

What is still missing there?

I updated most of it based on the recommended settings thread.

@Gabriel, So for instance --alt-preset standard links to the NEW one ie -V2?
(Actually -V2 is better..can the documentation be put in a way, so it just says that -V2 is the recommended "transparent" setting?)
@rjamorim, I was refering to this
http://wiki.hydrogenaudio.org/index.php?ti...ecommended_LAME

Egad! A redundant page!

Thanks for pointing that out. I just updated it. Later I'll talk to Jan about merging it with the LAME page.

i have no problems with V0 per se, of course.
but i think i'll use --abr 256, instead of --abr 270.. don't want to waste too many bits

yeah those 14 kbps really make the difference...

http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame
^^EAC + Lame guide needs update at wiki.

http://wiki.hydrogenaudio.org/index.php?title=LAME <-- this page needs some slight updates, too.

@ guruboolez



I'm just playing around with the new 3.97b1 (I preferred 3.90.3 up to date). I agree (but of course classical music is a large field); some types of classical (e.g. piano solo which compresses almost transparent at bitrates ~ 175 kbit/s) don't need such a high minimal bitrate by far. But try aggressive contemporaries (Xenakis!) or baroque with cembalo you'll see that bitrates won't fall <192 kbit/s often. But 230 kbps seems to be a little bit too high...

In my opinion it would be a better idea to implement a simpler way to change the transition band for the polyphase lowpass filter used (only classical recordings are using today DDD in general - the actual transition band of -V 0 seems to be o.k. for this purpose; for older ADD or AAD recordings I would prefer a setting with a transition band ~ 18 kHz and thus using more compressing bandwidth for additional transparency below 18kHz instead for reproducing perfect noise).

Hardly. I got flamed by guru (quite deservedly) for being unaware of the quality tuning going on behind the scenes by the LAME crew. The new version's really great. I'm really content with it myself. Never less than completely transparent to my ears. I've tried it, tried ABXing, etc, and have failed consistently. I think I got castanets down to under 1% chance of guessing after like an hour of work, but I can't be bothered to do that again to train my ears to the artifacting. I'd prefer to be content with transparency.

In my opinion it's irritating to recommend -V 2 --vbr-new and -V 2 vbr-default at the same time, especially while comparing them with --alt-preset standard and --alt-preset standard fast.

In the past --alt-preset standard was the main recommended switch and should be better than --alt-preset standard fast.

In "Remarks" we can read: --vbr-new is faster and has equal or better quality -> "though the general impression is, that --vbr-new should be recommended over vbr-default".

I think if the generell impression is, that --vbr-new should be recommended over vbr-default and it's faster, there's no need to recommend vbr-default anymore. It would be better to put the vbr-default to the remark, not to the "Recommended encoder settings".

We had faith to change the recommended lame version, now we should have faith to recommend one/the new vbr method, to minimize confusion and to make a standard.

If everyone thinks that vbr-new is generally better, it shouldn't take much to take the L.A.M.E source code, change default behaviour to include vbr-new, and have a vbr-old switch instead, and then host this binary on Rarewares, along with the modified source code, and call it the HA branch. This could be kept until such a time, that people think the defualt behaviour is better again, and then just host the origional source.

To aviod confusion, perhaps a different encode string could be added, statingit was made with the HA compile??


Just a few random thoughts.

Kristian

That would be the consequential next step.