LAME 3.97beta is now the officially recommended LAME version and switching is recommended to everybody.

This recommendation marks the death of the 3.90.X branch of LAME and the --alt-presets (or --presets) developed and tuned by Dibrom with help of many original members of this site in late 2001 establishing "the most concise, well tuned, and most thought out MP3 quality "paradigm" at the time.

The --alt-presets are now being abandoned in favour of the more flexible -V settings.

Thanks go out to the LAME developers and the (few) members of this site, who helped testing recent LAME versions. An outstanding amount of that work has been done by Guruboolez, whom this community owes a lot for all the days and nights he spent testing and discussing.

The recommended settings thread already accomodates this anticipated change and should answer most questions about the new -V system and --vbr-new.

Congratulations!

Just one thing, isn't it time for it to finally lose it's beta status? It seems a bit odd (and confusing to less experienced users) to have a piece of software that has been declared safe and even highly recommended after rigorous testing and tuning by experts to have a beta status. The whole purpose of beta-status is being a warning actually. All mp3's made by this lame-build will show up in Encspot c.s. as being build by the beta version of an encoder...

Any idea when the developers might agree on removing the beta-tag?

A "beta" is the new recommended version? How will you tell in future anyone not to use beta versions until they are final?

To wait the one or two weeks until 3.97 is final was not possibe?
And what about the testing of the beta? An overview of tests that shows the improvements towards 3.96 and 3.90 would make me feel much better.

Yay! It was about time....... back to reality, from now on.

edit: those who complain about beta-status obviously did not follow up on what happened in the recent months and weeks. Besides, a beta is not that bad..... i would begin to worry if it would be an alpha, but beta nowadays doesnt mean that much..... unless its foobar2000 ;-)

3.90 alpha was originally recommended, and nobody complained about it. The DON'T USE ALPHA/BETA attitude is very specific in recommendations (it didn't apply to 3.90, it still doesn't apply to mppenc, and nobody is worrying about using EAC which is/was/will be in alpha, pre-beta, sub-alpha or beta stage )

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

Might want to update this?

I know it's safe to use, I know it 'took' 12 beta-versions to get up to this point, I know why it should be recommended. I followed it's stages to reach this point.

The question is whether the name reflects this and whether it's wise to keep on calling it a beta when it's obviously safe to use. People who haven't followed it's development will have a choice between 3.90.3, 3.96.1 and 3.97beta, the 3.90.3 numbering-issue (with the code-fork) is hard enough as it is. We all want everyone to use this, not just frequent HA-visitors, don't we?

I am aware though that its up to the developers to decide, not to the people on HA making recommendations, it was merely a question as to when the word beta gets stripped...


EAC is a funny example but don't forget there are no non-betas to obtain of EAC whereas there are a lot of non-betas available for Lame, even the dreaded 3.93 is a non-beta!

Done.

Just curious how any why it suddenly became recommended, was there a disscussion between the mods in the background. Just wondering as it seemed to leap out of nowhere that it became recommended.

Kristian

@devo - the 'LAME Versions' updated date at the top of this post could also do with being updated.
Also, it would be useful, I think, to have dates alongside each of the LAME version updates. Is that possible or is that gonna be a hassle?

Thanks

Ha, I've been using LAME 3.97 for a while.

Alpha and Beta, but this is great news. 3.97 is faster, and results are really close in my opinion, with no quality loss and even smaller files.

Probably it should be renamed to 'Release Candidate' or 'Technical Preview' not to confuse people. Descriptive wording would certainly result in increased attraction and therefore intense usage. (I assume the change of the recommended version was a measure to put release candidate to mass testing.)

I beg your pardon? Could it be that you haven't been following HA much lately? IMO there was nothing "sudden" about it.

Of course I have been following the related threads closely, there has been lots of discussion over the new stickies, etc. But not much talk, that I noticed, about wether it should or should not be accepted? Maybe i have missed something, hence my question, but don't worry about it, I'm not overly fussed, just curious. It just seemed to me, like people were pre-empting its acceptance, by planning stickies, etc, and then suddenly, a new thread pops up, saying its not the recommended encoder.

Kristian

Then you know this would become the recommended version when it finally reached beta.

I can't find any earlier information, but I announced that 3.97 would become the recommended version once it's released in April 2005:
http://www.hydrogenaudio.org/forums/index....ndpost&p=290263

Some members would consider waiting for the beta a delay rather than an decision out of nowhere.

Umm, you really think multiple forums members would put that much effort and detailed planning into a *fictive* event?!? Wow, that would be incredible.... not even most real events on ha.org get that much care.

Great work. Thanks to developers, testers, and all people involved, for the great amount of time and effort put into achieving this.

Sorry, but obviously I do have a different attitude on how to label different versions of software. I don't think we should make the worst examples to our model.

1. Alpha-Version: Early version of software. Feature-set not fixed. Features not complete. Bugs and errors possible and known. Accessible only by developers. Stability not guranteed.
2. Beta-Version: Feature-Set fixed. Bugs and errors possible and maybe not known. Assessable by Beta-testers. Stability unknown.
3. Gamma-Version/Release Candidate: Bugs and errors fixed. Available for publicity to find the latest unknown bugs and errors. Stable.
4. Final-Version: Latest bugs and errors fixed. Stable.
5. Patch-Version: Fixing of further bugs and errors. Stable.

If you think, that 3.97 has no bugs, than make it a final or a relase candidate. If you think it is a beta and has bugs, than do not recommend it.
Give me the reason, why you call it beta AND recommend it.

There is no software which has no bugs, except maybe a 64kb-app :)


Who is "you"? You, the lame-devs? You, the majority of ha.org-users who dont used the recommended version anymore? You, who took part in testing 3.97x? You, the ha.org-staff?

Yes I know. But you know that this is not the point, don't you?OK, let me try it that way:
It's all about trust and how this trust has been derived.
I am not able to judge the quality of the current version. So I have to trust someone who is able to do this.

Personally I trust the developers to make heavy testing and doing a great job.
So why shouldn't we accept their own reservations against their current version? They must have reasons, why they call it a Beta. Otherwise they would call it Release-Candidate or Final.

But maybe someone has asked, and the answer was: "We are planning to release in near future the final version and this version has no differences to the current beta because we couldn't find any more bugs and errors."
Who knows? But then I would shut my mouth and would not say any more word.

Then the recommendet compiles and settings of ha.org are irrelevant to you. The lame developers AFAIK recommend to use the latest stable version - which is 3.96.1. Before that, they recommended 3.95, and so on. T


Or maybe they simply have a few more improvements and ideas which they would like to try out. Or maybe they are currently short on time to do the finishing strokes. Or maybe........ it doesn't matter. Lame developers dont make the ha.org recommended settings - their input is taken into consideration and valued, but they are not responsible for the ha.org-recommended versions. Else you would not have had 3.90.3 for so long(if i remember right, the lame devs were quite dissatisfied with ha.orgs "conservative"-views). In the end, it doesnt matter...... all which matters are test-results and propabilities. And currently, its most probable that 3.97b1 is better than 3.90.3. That was already the case with 3.97alpha, and there was considerable pressure to make one of those alphas the recommended version...... but simply because of the word alpha - NOT because of the stability of the code - the recommendation was postponed.... just to get a more nice name.

By your logic, the person which is currently the most responsible for vorbis-improvement has never trusted his code - because his code never left beta-stage :) And this "beta"-code is now part of the "stable" vorbis version.

Sometimes I doubt the usefulness of the whole 'alpha-beta-rc-final' naming convention. Many developers are just so much more scrupulos than others about naming their product 'final'. If I just think about XviD 1.0 for example which many people didn't use because of the 'beta-tag' although it had been clearly superior to the 'stable' version - while so many of us have been using beta-versions of Windows labeled 'final' for years...

No, I find it absolutely rectified that those dignified members and mods of the forum recommend a beta version that simply is better than the stable one.

I guess the reason is not just different scales of "quality" but also conflicting interpretations: Some - at least subconsciously - equal "final/stable" to "done".... but what if the code is stable and good, but you dont consider it done yet? You could call it something like "preview" then...... but lame has never done "preview"-releases. Or you could just do a quick stable release, and another stable afterwards..... but lame is running out of version-number-space for 3.xx :-)

From the current recommendation:



May I suggest you to lower the minimal bitrate for -V0, which looks exagerated?
For classical music 230 kbps is a pretty high value (on average I obtained 221 kbps, with a minimal value corresponding to less than 180 kbps). 215...220 is more reasonable in my opinion.

See my table.

they can just add another number, like in lame 3.99 -> 3.100

Hmm, wasn't there some limitation in the headers? That was AFAIK also the reason why you can only see the 3.96 in an mp3-header which was encoded with 3.96.1.

It's hard to guess averages for LAME's VBR modes. I just encoded one of my favourite albums using -V2 --vbr-new and it ended up at 257kbps average.

Its great to finally see this as the new recommendation, congradulations to the LAME developers and a huge thanks to the dedicated testers here on hydrogenaudio

It's never twigged before... but why is the '-V 0' VBR average bitrates so much lower than the max of 320? I know 320 is for CBR and I know that at such a high bitrate I couldn't tell the difference. I think what I'm trying to get as is, is if you look at the VBR bitrate ranges you could say there's at least one setting missing from the VBR switches - one that may get you between 270 - 300.

Again, I don't think this is a problem and it doesn't seem necessary given the excellent results with the lower 'V' settings, just wondered that's all.

Sorry if this has been discussed somewhere before, as it is a little off topic.

There were rumours that 3.97 would be the last stable version in the 3.x series and then development would move on to 4.0

But now there is a 3.98a branch, so I don't know what to think anymore.


I will now go about removing 3.90.3 from RareWares. All special builds and the load-balanced version will be removed. I'll probably keep the bundle for a few more weeks, and then move it ro RRW.

Cheers!

good idea.

you've got very bad day, right ?

me personally, I will be glad to use it even if someone call it "Microsoft LAME Mars Edition pre-alpha-very-dangerous-dontuseme-toxic" as far as I know it's best what we've got.

so if you don't believe betas, dont use it. simple and elegant solution

Musepack beta 1.14 was widely recommended around here.

auTuV is beta to this day, and is the recommended vorbis version as well.

Etc, etc.

Exact Audio Copy

Note: is no one is using the beta, we will not be able to know if it should be promoted to release.

Just throwing in my few cents.

If it's seen as stable, the please drop the Beta.

If it's seen as 'beta' and needs more testing then please keep the Beta tag, but then please drop the recommendation.

IMO this is very clear programming practice. Alpha > Beta > Final.

Why it's not used here I don't know, but can just speak for myself and I would appreciate if it was.

Regarding all the comments about 'other software' where the situation was the same, I can't only say that two wrong don't make a right.

Why someone could feel different I just can't comprehend. Beta is not supposed to be listed and afaik has never been seen as something that was final, stable and recommended.

Still lots of props and thanks to the developers and testes on L.A.M.E. project, it's greately appreciated.

Thanks

There is someone out there who understands me!
Thanks god, I'm not alone.....
You made my day.

That would be Alpha > Beta > Public release. In any case, we are a closed group, whose testing is important to the LAME release.. think about it this way : if no one tested 3.90, it would have remained 3.90 beta forever..

If you want to use an obsolete version, knock yourself out, but just because the tag "beta" is on a piece of software, doesn't mean that it's buggy : counter-strike was a beta for a LOOOOOOOONG while; EAC is _still_ a beta, and I'll bet you use _that_!

Admittedly, microsoft betas are usually buggy, but generally, in the open-source market, where bugs get corrected the minute they're seen, a beta-status poses no problems (eg. mysql, php, apache, lame, etc..)

FYI : Used in software publishing, "beta" is the name given to a pre-release version of a software product. This beta version is used for testing purposes, is sometimes problematic and thus only available to specific users who are encouraged to provide feedback for improvement. Beta versions are commonly found on company websites and can be downloaded. Many include expiration dates to eliminate proliferation of flawed software.

Thanks again to the LAME team!
T.

Yay!

This is great news, awesome work and thanks to the devs and everyone involved!



As long as it doesn't say "Creative Labs" anywhere ...

One last try:
Life is getting easier, if people who use words have the same understanding of the meaning of the words. If I say "car", people hopefully think of something with four weels and seats inside, powered by an engine and which is used to move people from one place to another.
Software-developers and software-users hopefully have the same understanding in the word "beta" in conjunction with software. You can give me as many examples you like of software, which includes the word "beta" in its versioning and which is used by many people. Even if it is the best available software at that time, it does not care: The "beta"-flag gives a clear indication, that something is missing or uncertain. If nothing is missing or (under a certain probability) uncertain, the beta flag should be removed. OK, there is no clear line, when this should happen, but each software-developer must have an idea, when to say: OK, enough tested, let's make it a final. I hope, developers of software have an idea of what to reach with the next final version. And if this has been reached it is totaly fine to call such a version a final version. And then start again to find new targets for the next final version. That's the way things (should) go.

13 entries found for beta.
be·ta Audio pronunciation of "beta" ( P ) Pronunciation Key (bt, b-)
n.

1. The second letter of the Greek alphabet. See table at alphabet.
2. The second item in a series or system of classification.
3. A mathematical measure of the sensitivity of rates of return on a portfolio or a given stock compared with rates of return on the market as a whole. A beta of 1.0 indicates that an asset closely follows the market; a beta greater than 1.0 indicates greater volatility than the market.
4. Physics.
1. A beta particle.
2. A beta ray.
5. Chemistry.
1. The second position from a designated carbon atom in an organic molecule at which an atom or a radical may be substituted.
2. An isomeric variation of a chemical compound. Used in combination: beta-estradiol.
6. Computer Science. A beta version.

beta

adj 1: second in order of importance; "the candidate, considered a beta male, was perceived to be unable to lead his party to victory" 2: preliminary or testing stage of a software or hardware product; "a beta version"; "beta software" n 1: the 2nd letter of the Greek alphabet 2: beets [syn: Beta, genus Beta]

Seems we need to redefine the word beta....

Jesus, do you guys need to worry about SEMANTICS? It's just a frikkin' word!

Please, worry about quality and encoding speed, instead.

Just tried one sample, the good old "birds" and it degraded to 3.96 builds. Didn´t encode anything in awhile. Is there a thread for bringing in testing for 3.97b? Excuse me but i haven´t been around here for a while until i heard about this build. Cheers to all the ones still very active around here!

LOL....I was just cracking a joke....

I concur, let's get on with our lives...

Is the recommended build of 3.97b a build of the 3.97beta source off sourceforge or are there some other patches applied?

wow! Finally...

I always think of beta versions as 'unfinished'.

In the case of Nero, software is continually updated and recognised purely by its version number - in other words each version stands alone as a finished product [some may disagree with this!] but can be updated by later versions. Thus these are not betas.

I thus have some sympathy for the view that retaining the beta tag is confusing for some users, but at the end of the day if it works WTF does it matter.

where exactly did this tests take place? (what tests?)
(edit: iam using 3.97 for a while now, just wonder...)