LAME 3.97beta (http://www.rarewares.org/dancer/dancer.php?f=3) is now the officially recommended LAME version (http://www.hydrogenaudio.org/forums/index.php?showtopic=28123) 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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=28124) 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?
LAME 3.97beta (http://www.rarewares.org/dancer/dancer.php?f=3) is now the officially recommended LAME version (http://www.hydrogenaudio.org/forums/index.php?showtopic=28123) 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.
[a href="index.php?act=findpost&pid=331450"][{POST_SNAPBACK}][/a]
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 ;-)
A "beta" is the new recommended version? How will you tell in future anyone not to use beta versions until they are final?
[a href="index.php?act=findpost&pid=331456"][{POST_SNAPBACK}][/a]
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=28125)
Might want to update this?
edit: those who complain about beta-status obviously did not follow up on what happened in the recent months and weeks.
[a href="index.php?act=findpost&pid=331459"][{POST_SNAPBACK}][/a]
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...
[span style='font-size:8pt;line-height:100%']
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![/span]
http://www.hydrogenaudio.org/forums/index....showtopic=28125 (http://www.hydrogenaudio.org/forums/index.php?showtopic=28125)
Might want to update this?
[a href="index.php?act=findpost&pid=331467"][{POST_SNAPBACK}][/a]
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
http://www.hydrogenaudio.org/forums/index....showtopic=28125 (http://www.hydrogenaudio.org/forums/index.php?showtopic=28125)
Might want to update this?
[a href="index.php?act=findpost&pid=331467"][{POST_SNAPBACK}][/a]
Done.
[a href="index.php?act=findpost&pid=331471"][{POST_SNAPBACK}][/a]
@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.
...
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.
...
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.)
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
[a href="index.php?act=findpost&pid=331489"][{POST_SNAPBACK}][/a]
I beg your pardon? Could it be that you haven't been following HA much lately? IMO there was nothing "sudden" about it.
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
[a href="index.php?act=findpost&pid=331489"][{POST_SNAPBACK}][/a]
I beg your pardon? Could it be that you haven't been following HA much lately? IMO there was nothing "sudden" about it.
[a href="index.php?act=findpost&pid=331499"][{POST_SNAPBACK}][/a]
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=33208&view=findpost&p=290263)
Some members would consider waiting for the beta a delay rather than an decision out of nowhere.
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 no(w) the recommended encoder.
Kristian
[a href="index.php?act=findpost&pid=331501"][{POST_SNAPBACK}][/a]
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.
A "beta" is the new recommended version? How will you tell in future anyone not to use beta versions until they are final?
[a href="index.php?act=findpost&pid=331456"][{POST_SNAPBACK}][/a]
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 )
[a href="index.php?act=findpost&pid=331461"][{POST_SNAPBACK}][/a]
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.
If you think, that 3.97 has no bugs
There is no software which has no bugs, except maybe a 64kb-app :)
...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.
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?
If you think, that 3.97 has no bugs
There is no software which has no bugs, except maybe a 64kb-app
Yes I know. But you know that this is not the point, don't you?
...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.
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?
[a href="index.php?act=findpost&pid=331526"][{POST_SNAPBACK}][/a]
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.
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?
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
They must have reasons, why they call it a Beta. Otherwise they would call it Release-Candidate or Final.
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.
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...
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:
-V 0 --vbr-new = --preset fast extreme 245 230…260
-V 0 = --preset extreme 245 230…260
-V 1 --vbr-new 225 200…250
-V 1 225 200…250
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=37011&view=findpost&p=328377).
but lame is running out of version-number-space for 3.xx :-)
they can just add another number, like in lame 3.99 -> 3.100
but lame is running out of version-number-space for 3.xx :-)
they can just add another number, like in lame 3.99 -> 3.100
[a href="index.php?act=findpost&pid=331550"][{POST_SNAPBACK}][/a]
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.
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.[a href="index.php?act=findpost&pid=331548"][{POST_SNAPBACK}][/a]
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.
but lame is running out of version-number-space for 3.xx :-)
they can just add another number, like in lame 3.99 -> 3.100
[a href="index.php?act=findpost&pid=331550"][{POST_SNAPBACK}][/a]
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!
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.
good idea.
Give me the reason, why you call it beta AND recommend it.
[a href="index.php?act=findpost&pid=331522"][{POST_SNAPBACK}][/a]
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
Give me the reason, why you call it beta AND recommend it.[a href="index.php?act=findpost&pid=331522"][{POST_SNAPBACK}][/a]
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.
Etc, etc.
[a href="index.php?act=findpost&pid=331628"][{POST_SNAPBACK}][/a]
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
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[a href="index.php?act=findpost&pid=331641"][{POST_SNAPBACK}][/a]
There is someone out there who understands me!
Thanks god, I'm not alone.....
You made my day.
IMO this is very clear programming practice. Alpha > Beta > Final.
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!
Now, now, let's not get carried away. "LAME Mars Edition pre-alpha-very-dangerous-dontuseme-toxic", all fine for me, but "Microsoft"? The words "microsoft" and "alpha" in the same sentence should be enough to send any sensible being running away, screaming.
As long as it doesn't say "Creative Labs" anywhere ...
IMO this is very clear programming practice. Alpha > Beta > Final.
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_!
[a href="index.php?act=findpost&pid=331702"][{POST_SNAPBACK}][/a]
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.
[span style='font-size:14pt;line-height:100%']13 entries found for beta.[/span]
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.
[span style='font-size:14pt;line-height:100%']beta[/span]
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!
Jesus, do you guys need to worry about SEMANTICS? It's just a frikkin' word!
Please, worry about quality and encoding speed, instead.
[a href="index.php?act=findpost&pid=331714"][{POST_SNAPBACK}][/a]
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.
Jesus, do you guys need to worry about SEMANTICS? It's just a frikkin' word![a href="index.php?act=findpost&pid=331714"][{POST_SNAPBACK}][/a]
Tonight 'Spectrum' examines the whole question of frothing and falling, coughing and calling, screaming and bawling, walling and stalling, galling and mauling, palling and hauling, trawling and squalling and zalling. Zalling? Is there a word zalling? If there is what does it mean...if there isn't what does it mean? Perhaps both. Maybe neither. What do I mean by the word mean? What do I mean by the word word, what do I mean by what do I mean, what do I mean by do, and what do I do by mean? What do I do by do by do and what do I do by wasting your time like this? Goodnight.
Thanks go out to the LAME developers and the (few) members of this site, who helped testing recent LAME versions
where exactly did this tests take place? (what tests?)
(edit: iam using 3.97 for a while now, just wonder...)
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?
Give me the reason, why you call it beta AND recommend it.
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.
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.
[a href="index.php?act=findpost&pid=331790"][{POST_SNAPBACK}][/a]
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.
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?[a href="index.php?act=findpost&pid=331794"][{POST_SNAPBACK}][/a]
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)
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)
[a href="index.php?act=findpost&pid=331812"][{POST_SNAPBACK}][/a]
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.
Vietwoojagig:
What exactly do you want?[a href="index.php?act=findpost&pid=331794"][{POST_SNAPBACK}][/a]
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...
Wait until the beta-flag is removed and then recommend it.
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
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
[a href="index.php?act=findpost&pid=331834"][{POST_SNAPBACK}][/a]
The carrots-thing sound interesting.
I will try it!
OFF-TOPIC
Now, now, let's not get carried away. "LAME Mars Edition pre-alpha-very-dangerous-dontuseme-toxic", all fine for me, but "Microsoft"? The words "microsoft" and "alpha" in the same sentence should be enough to send any sensible being running away, screaming.
[a href="index.php?act=findpost&pid=331695"][{POST_SNAPBACK}][/a]
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?
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!
[a href="index.php?act=findpost&pid=331722"][{POST_SNAPBACK}][/a]
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?
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 128 of 3.90.3?
[a href="index.php?act=findpost&pid=331962"][{POST_SNAPBACK}][/a]
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.
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!
[a href="index.php?act=findpost&pid=331722"][{POST_SNAPBACK}][/a]
What settings do you use for the "birds" sample?
[a href="index.php?act=findpost&pid=331924"][{POST_SNAPBACK}][/a]
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...
I just added LAME 3.97b compiles for several esoteric platforms to RareWares.
Hohoho
[a href="index.php?act=findpost&pid=331956"][{POST_SNAPBACK}][/a]
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
Any chance of putting up new 3.97b versions of the special packages, i.e.
"lame_enc.dll modified to use INI File Setup"
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.
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.
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?
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 128 of 3.90.3?
[a href="index.php?act=findpost&pid=331962"][{POST_SNAPBACK}][/a]
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.
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.[a href=\"index.php?act=findpost&pid=331548\"][{POST_SNAPBACK}][/a]
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.
[a href=\"index.php?act=findpost&pid=331557\"][{POST_SNAPBACK}][/a]
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.
I just added LAME 3.97b compiles for several esoteric platforms to RareWares.
Hohoho
[a href="index.php?act=findpost&pid=331956"][{POST_SNAPBACK}][/a]
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
[a href="index.php?act=findpost&pid=332044"][{POST_SNAPBACK}][/a]
Yes. Actually, I was wondering when someone was going to ask!! I'll post them later.
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
[a href="index.php?act=findpost&pid=332044"][{POST_SNAPBACK}][/a]
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.
- How do the old presets translate to V commands and how is their quality supposed to be?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=332128")
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=18091]http://www.hydrogenaudio.org/forums/index....showtopic=18091[/url]
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.
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.
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?
[a href="index.php?act=findpost&pid=332064"][{POST_SNAPBACK}][/a]
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
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 :)
[a href="index.php?act=findpost&pid=332199"][{POST_SNAPBACK}][/a]
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
- Does the fact that this version now has the recommended status mean in practice that there will be no more 3.97.* versions?
[a href="index.php?act=findpost&pid=332128"][{POST_SNAPBACK}][/a]
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)
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.
[a href="index.php?act=findpost&pid=332199"][{POST_SNAPBACK}][/a]
So, if the quality of V0 has not degraded, but the bitrate went down..... then do you know what that is? An *improvement*.
[a href="index.php?act=findpost&pid=332202"][{POST_SNAPBACK}][/a]
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.
--abr 270 and you will be happy.
[a href="index.php?act=findpost&pid=332314"][{POST_SNAPBACK}][/a]
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?
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's the way it is
P.P.S What about updating the Wiki?[a href="index.php?act=findpost&pid=332366"][{POST_SNAPBACK}][/a]
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 (http://wiki.hydrogenaudio.org/index.php?title=Recommended_LAME)
@rjamorim, I was refering to this
http://wiki.hydrogenaudio.org/index.php?ti...ecommended_LAME (http://wiki.hydrogenaudio.org/index.php?title=Recommended_LAME)
[a href="index.php?act=findpost&pid=332377"][{POST_SNAPBACK}][/a]
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.
Use -V0 and pretend you're using --abr 270, and you'll probably be just as happy .
[a href="index.php?act=findpost&pid=332341"][{POST_SNAPBACK}][/a]
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 (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 (http://wiki.hydrogenaudio.org/index.php?title=LAME) <-- this page needs some slight updates, too.
@ guruboolez
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.
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).
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.
[a href="index.php?act=findpost&pid=331489"][{POST_SNAPBACK}][/a]
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
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.
That would be the consequential next step.
http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame (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 (http://wiki.hydrogenaudio.org/index.php?title=LAME) <-- this page needs some slight updates, too.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=332478")
Done. I am planning to redirect the sticky to [a href="http://wiki.hydrogenaudio.org/index.php?title=Recommended_LAME]http://wiki.hydrogenaudio.org/index.php?ti...ecommended_LAME[/url]
instead of having to things at several places... Once I'm sure nothing isn't also at the wiki I'll remove the currect stricky thread is noone minds.
After all it contains a lot of information not really related to the recommended settings.
LAME developers already answered to this. If --vbr-new is not currently set as defaulted mode, it's because there are not tests enough. It's likely that --vbr-new is on average better the the current VBR mode with highest VBR modes (from V0 to V4), but for lowest VBR modes there are no public tests (AFAIK).
If people are requesting --vbr-new to become the new default mode, it would be better for LAME, LAME's users and also LAME's developpers to see ABCHR/ABX results.
Hi Jan S.,
I'd like to keep the content of the current sticky in that post at HA, and vote even for keeping it sticky.
As I reasoned some posts before, I recall 1st page of the topic [RFC] recommended settings.., it is nice to have the stuff not only in the wiki, as it isn't found by all newbies.
The link to wiki is already at top of the sticky topic.
This topic is high on google search results for mp3, if the url is changed, or content is changed, then we lose the possibility to spread the word.
I vote for keeping it as it is with the easy possibility to adapt to future changes.
For the additional content of the sticky compared to wiki, it is on purpose, to have a quickstart.
Hi Jan S.,
I'd like to keep the content of the current sticky in that post at HA, and vote even for keeping it sticky.
As I reasoned some posts before, I recall 1st page of the topic [RFC] recommended settings.., it is nice to have the stuff not only in the wiki, as it isn't found by all newbies.
The link to wiki is already at top of the sticky topic.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=332940")
There should be a sticky thread that redirects directly to the wiki page so everybody that finds the sticky as it is now will be directly directed to the wiki page so there should be no problem.
This topic is high on google search results for mp3, if the url is changed, or content is changed, then we lose the possibility to spread the word.
[a href="index.php?act=findpost&pid=332940"][{POST_SNAPBACK}][/a]
This is a valid point but I think it is an ok price to pay to avoid redundancy, everybody being able to help with the page and integration with the knowledge base material.
I have now updated the wiki to contain everything that is in the thread apart from the links (which I think should go in each appropriate section) and the credits (which is quite useless and preposterous in size IMO. I would much rather have a section that explains how testing was done and who was involved in teh development) so it should be able to get high on google rating too (even higher since I suspect it will be updated more frequently).
I vote for keeping it as it is with the easy possibility to adapt to future changes.
For the additional content of the sticky compared to wiki, it is on purpose, to have a quickstart.
[a href="index.php?act=findpost&pid=332940"][{POST_SNAPBACK}][/a]
The wiki is even more easy to update IMO.
The wiki now contains everything in the thread (apart from what mentioned) so that should not be an issue.
For example the EAC guide is added by insertion of the page [a href="http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame]http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame[/url] so that when that page in changed the recommended page changes also. And the guide can be accessed seperately too in the wiki.
I hope we can find an agreement that works for everybody on this issue.
Let us know what you think (you being any reader).
I agree the Wiki is a much cleaner solution than a forum thread sticky.
Besides, it's a much more democratic solution. That's why I moved my Lossless comparison to the wiki. That way, anyone can contribute, and not just some enlightened few that have access to the post's Edit button. Power to the people and all that.
Also, there are other advantages in pointing users to a wiki instead of a forum sticky. If a guy finds the sticky through google and ends up with some doubt about the settings, he'll probably start a new thread. In the wiki, he's encouraged to look for the answers himself.
Besides, the Wiki's linkage structure makes it easier to direct readers to related topics of interest. Keeping the sticky linked to interesting stuff in the forums would be a very boring task.
Therefore, pointing people to the wiki will not only introduce them to a cleaner, streamlined version of the recommended settings list, it'll also be an invitation to keep browsing and learn more about audio coding in general.
I would go so far as claiming a tread is not the appropriate place to host the recommended settings article. A wiki is much, much more appropriate for that purpose.
Case study: moving the lossless comparison sticky to the wiki
Advantages:
+ Everybody can contribute
+ Links will point interested people to pages dealing in depth with each format, or explaining some of the terms being used. That would be pretty much impossible in a forum structure.
+ The comparison table was built using Wiki structures. That would be absolutely impossible at a forum.
+ Visual is much more pleasing thanks to good formatting routines not available in bbcode.
+ Editing is much, much easier
Disadvantages:
- Any?
Other interesting details:
- The lossless article at the Wiki, according to the Wiki software, had 20000 views. The sticky that links to it, OTOH, had 6000 views.
- I just added links to the Wiki article (http://wiki.hydrogenaudio.org/index.php?title=Recommended_LAME) to RareWares' and LAME's link pages. That should help increase Google's page rank a little, and also draw more visitors to it.
I vote for both, wiki and a sticky topic.
Then you should read the current sticky topic,
it refers directly for more informations to the wiki.
Moreover, some key words are linked to the corresponding wiki pages,
not to some "boring forum topics".
Jan S. told me, that one advantage of the wiki would be, that everybody can participate directly.
Well, as disadvantage he told also, that then a close monitoring needs to be done of the wiki content.
That is extra work,
and especially boring work.
About redundancy:
Having important informations redundant,
is a good thing.
Everybody backups his important data on a different medium, in case the main medium gets broken.
So, it is not about counting numbers of visitors of the 2 possible locations,
as it is done, a good thing, that the sticky topic directs to the wiki,
but also, to have a 1-page-extract of the most important informations to get started with ripping & lame in a high quality way.
As the wiki pages are now, you have 1 page only for the settings,
but there you offer too much informations already for a newbie.
In the following, the newbie is forced to browse to several pages to find eac etc.
So, in the end, the newbie will stay with musicmatch, wmp, easy-cd-extractor etc., as he is puzzled.
Regarding the participation on wiki edits, how much has happened there ?
Eg. was the Lossless wiki page edited not only by Roberto, but also by others ?
For the lame pages, the answer is easy, as I watched now the "progress" at wiki a long time. There was progress only in the recent days.
I asked during the developing of the 3.97 update of the sticky topic, that updates at wiki are also carried out, but nobody did the major update (until it came up in this topic).
The wiki is a good thing in itself, and it is a perfect thing to host even detail informations in several structured pages.
Though a sticky topic is a good thing also, to have something on 1 page, simple, straight forward.
And as the sticky topic is highly linked with the wiki, I see no reason against a sticky topic.
I don't see any reason also against a wiki.
And what should be a reason against having a sort of redundancy (in fact, as I proved above, the sticky is different from wiki content, it is not redundant),
ie. having wiki and sticky topic ?
Jan S. and Roberto suggest, having a sticky only with a link to wiki.
My suggestion is, having the sticky with link to wiki, and providing the quickstart informations on 1 page.
edit:
In the meantime, the wiki page was so edited, that it contains the sticky post content nearly completely.
addon:
Even, if 1 wiki page hosts now all quickstart information on 1 page,
a sticky topic does not hurt, as explained: redundancy is a good thing,
especially, as a forum and awiki are 2 different structures.
I vote for both, wiki and a sticky topic.
Then you should read the current sticky topic,
it refers directly for more informations to the wiki.
Moreover, some key words are linked to the corresponding wiki pages,
not to some "boring forum topics".
Jan S. told me, that one advantage of the wiki would be, that everybody can participate directly.
Well, as disadvantage he told also, that then a close monitoring needs to be done of the wiki content.
That is extra work,
and especially boring work.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=333214")
Don't worry. I will take care of monitoring. It is very easy to see if something was changed using the [a href="http://wiki.hydrogenaudio.org/index.php?title=Special:Recentchanges]recent changes[/url] page and seeing the changes using the page history (http://wiki.hydrogenaudio.org/index.php?title=Recommended_LAME&action=history).
About redundancy:
Having important informations redundant,
is a good thing.
Everybody backups his important data on a different medium, in case the main medium gets broken.
So, it is not about counting numbers of visitors of the 2 possible locations,
as it is done, a good thing, that the sticky topic directs to the wiki,
but also, to have a 1-page-extract of the most important informations to get started with ripping & lame in a high quality way.
As the wiki pages are now, you have 1 page only for the settings,
but there you offer too much informations already for a newbie.
In the following, the newbie is forced to browse to several pages to find eac etc.
So, in the end, the newbie will stay with musicmatch, wmp, easy-cd-extractor etc., as he is puzzled.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=333214")
You are linking to the LAME page in the thread. Not the recommended settings page that is quevalent and contains exactly the same unless I missed something.
If you take a look at [a href="http://wiki.hydrogenaudio.org/index.php?title=Recommended_LAME]http://wiki.hydrogenaudio.org/index.php?ti...ecommended_LAME[/url] you will see that it is very much the same. In fact it should be almost identical part from teh credits and links. So you still have the same. 1 page that tells you all you need to know.
I don't agree that redundancy is a good thing. It is more work to update both and the people updating the wiki have no way to know when the sticky thread is updated.
Also it is, as you said earlier, important to have the most hits at one page to get a better google rating.
Regarding the participation on wiki edits, how much has happened there ?
Eg. was the Lossless wiki page edited not only by Roberto, but also by others ?
For the lame pages, the answer is easy, as I watched now the "progress" at wiki a long time. There was progress only in the recent days.
I asked during the developing of the 3.97 update of the sticky topic, that updates at wiki are also carried out, but nobody did the major update (until it came up in this topic).
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=333214")
You can check the [a href="http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison&action=history&limit=500&offset=0]history of the lossless comparison[/url]. You will see that 8 different people contributed. Not only Roberto.
That the wiki was updated last is exactly the reason there needs to be one place where things are updated in a timely manner. If there were only the wiki, the only place people will go, it would have been up to date.
It can't be any suprise that the update is last at the wiki when the development happens in a thread control by one guy.
The wiki is a good thing in itself, and it is a perfect thing to host even detail informations in several structured pages.
Though a sticky topic is a good thing also, to have something on 1 page, simple, straight forward.
And as the sticky topic is highly linked with the wiki, I see no reason against a sticky topic.
I don't see any reason also against a wiki.
And what should be a reason against having a sort of redundancy (in fact, as I proved above, the sticky is different from wiki content, it is not redundant),
ie. having wiki and sticky topic ?
Jan S. and Roberto suggest, having a sticky only with a link to wiki.
My suggestion is, having the sticky with link to wiki, and providing the quickstart informations on 1 page.
[a href="index.php?act=findpost&pid=333214"][{POST_SNAPBACK}][/a]
You have not proven a difference. I suspect you haven't read the page since yesterday when I copied what was missing and made sure it was the same.
Again: you have all in one page at the wiki and redundancy makes more work and at the wiki the work that is there can be spread across more people making it less work for one person and much more people and time to improve the content.
My vote goes for the forum thread to
only point to the wiki.
I have just followed the thread to the wiki and was quite disturbed by my experience. While writing up my findings I see Jan has highlighted one of my key points above - i.e.: the LAME page should be about LAME - not HA's recommendation. HA != LAME.
- The page title/wiki id is "LAME". This page doesn't seem the right place to put the recommended settings. The page should be about LAME, not recommendations - although there should be an obvious link!
- The VBR table has "-b 320" at the top. I can see that it is useful for comparison but it is not a VBR setting. Perhaps some distinction should be made in the table?
- The Technical data for recommended LAME settings (http://wiki.hydrogenaudio.org/index.php?title=Technical_data_for_recommended_LAME_settings) has different target bitrates, and doesn't list the ranges.
- The "Quick Start" is stuck down in the middle of the document.
- Why does the LAME page (see 1) have an EAC setup guide? Shouldn't that be on the EAC and LAME (http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame) page?
- The "Quick Start" needs some clearer formatting - it's not very quick to start.
- In the EAC Setup Guide I find Recommended LAME Version (http://wiki.hydrogenaudio.org/index.php?title=Recommended_LAME) which points to another page. So, on the recommendations page linked to from the forum thread, which is called LAME and should be about LAME but has recommendations, there's a link to the recommendations page. Ummm... I'm lost.
I think the current experience proves that duplication is certainly not good.
I guess, in others' defence, it is early days and hopefully this confused state is simply down to multiple pages being updated. Again though - proof positive that redundancy confuses matters.
[span style='font-size:8pt;line-height:100%']Edit: spelling/clarity[/span]
about my term of redundancy
(and redundancy has more advantages than disadvantages in general):
wiki and forum are 2 locations,
newbies will go to forum to read and write.
So, if they find the forum, they find the sticky,
and if the sticky contains easy but complete informations, and also the wiki link at top,
every newbie gets an answer, either a quick (and complete one), or the complete HA knowledge at the whole wiki.
1. ok,
you have shown yourself the difficulty of the wiki,
we saw it also here in this topic,
we have (had?) several wiki pages dealing with lame, eac+lame, settings etc etc.
the more knowledge you offer, the more time or responsible people you need, to keep the knowledge uptodate.
Until about yesterday, the wiki was not really uptodate regarding lame.
Then, you have copied more or less the sticky topic.
That was easy now, but who will be responsible in future for the content of the wiki ?
Answer:
Of course, every member of HA, so to say. But as always, as everybody is responsible, nobody will work ?
ok, little bit kidding, but it seems, it was so in past, as especially the mp3 topic sems not to be so interesting for the active and knowledgeable HA experts.
This is opposite to the Loslsess pages probably, as the Lossless themes got more attention in recent times.
So, if you have a sticky, the member who posted there, will feel obliged to keep his post updated. (at least, I feel so, or am I only old-fashioned ?)
All in all, as reasoned now several times, the combination of wiki (with ability to make chnages for every member) together with sticky post is best solution, as you have both worlds combinnated, personal responsibility with the everybodies abilities.
2.:
You are linking to the LAME page in the thread. Not the recommended settings page that is quevalent and contains exactly the same unless I missed something.
If you take a look at http://wiki.hydrogenaudio.org/index.php?ti...ecommended_LAME (http://wiki.hydrogenaudio.org/index.php?ti...ecommended_LAME) you will see that it is very much the same. In fact it should be almost identical part from teh credits and links. So you still have the same. 1 page that tells you all you need to know
no problem,
I hope you noticed, that several key words are linked with corresponding wiki pages,
not only the general link to wiki.
I will of course update the sticky again with the new link.
Quick Start
Best Quality : 'archiving'
--cbr 320.
--cbr 320 ???
My vote goes for the forum thread to only point to the wiki.
I have just followed the thread to the wiki and was quite disturbed by my experience. While writing up my findings I see Jan has highlighted one of my key points above - i.e.: the LAME page should be about LAME - not HA's recommendation. HA != LAME.- The page title/wiki id is "LAME". This page doesn't seem the right place to put the recommended settings. The page should be about LAME, not recommendations - although there should be an obvious link!
- The VBR table has "-b 320" at the top. I can see that it is useful for comparison but it is not a VBR setting. Perhaps some distinction should be made in the table?
- The Technical data for recommended LAME settings (http://wiki.hydrogenaudio.org/index.php?title=Technical_data_for_recommended_LAME_settings) has different target bitrates, and doesn't list the ranges.
- The "Quick Start" is stuck down in the middle of the document.
- Why does the LAME page (see 1) have an EAC setup guide? Shouldn't that be on the EAC and LAME (http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame) page?
- The "Quick Start" needs some clearer formatting - it's not very quick to start.
- In the EAC Setup Guide I find Recommended LAME Version (http://wiki.hydrogenaudio.org/index.php?title=Recommended_LAME) which points to another page. So, on the recommendations page linked to from the forum thread, which is called LAME and should be about LAME but has recommendations, there's a link to the recommendations page. Ummm... I'm lost.
I think the current experience proves that duplication is certainly not good.
I guess, in others' defence, it is early days and hopefully this confused state is simply down to multiple pages being updated. Again though - proof positive that redundancy confuses matters.
[span style='font-size:8pt;line-height:100%']Edit: spelling/clarity[/span]
[a href="index.php?act=findpost&pid=333220"][{POST_SNAPBACK}][/a]
I see only the (old ?) redundancy at wiki with several mp3/eac/lame/settings pages as problem.
by nature, the wiki should contain more detail info of course.
Whereas the sticky topic has only 1 mistake:
The wrong title.
This is what confuses you.
Today i would name the title of the topic as following:
Quickstart to MP3 in highest possible qualityOf course, then the topic needs to contain
dl source for recommnded lame compile,
best mp3/lame settings,
quickstart to eac+mp3/lame.
Unfortunately, i cannot edit the title.
i.e.: the LAME page should be about LAME - not HA's recommendation. HA != LAMEI don't understand what you mean by this sentence.
IMO, mp3 topic should be about lame (at least, until other encoder might be better than lame;) ) , should be about best settings. That we are here at HA, is just random coincidence if it were Project Mayhem, we would call it "Project Mayhem's recommended mp3 ways/settings/quickstart" or whatever.
- a vbr table cannot have -b 320 at top, of course, I agree.
But probably, the recommnded settings table has -b320 at the top, simply, as with -b320 you get the (theoretical) best standard conform quality from mp3/Lame.
And, the table has the hint, that settings go down regarding quality.
If you go further to the remarks section, you find recommnedations of various settings for various usages, from portable to home-HiFi.
Of course, the -b320 setting competes with -V0,1,2 in a certain way.
So we have a graph, which shows effieciency, quality increase vs. size/bitrate increase of the settings. If soembody sees the graph, he will select a -V setting, not -b320, besides he has other reasons to select -b320.
- The "Quick Start" is stuck down in the middle of the document.
Yes, the topic/page is about quickstart to mp3, you can encode waves to mp3 via other guis, or dos window by lame commandline, or copying the commandline to foobar2000, so the quickstart to eac+mp3 is at lower priority, after the settings overview.
This needs to be so, logical reason, in the eac setup, there is mentioned -V2 --vbr-new as example setting, and the hint, that this text/setting can be replaced by any other setting mentioned before.
Whereas the sticky topic has only 1 mistake:
The wrong title.
This is what confuses you.
i.e.: the LAME page should be about LAME - not HA's recommendation. HA != LAME
I don't understand what you mean by this sentence.
IMO, mp3 topic should be about lame (at least, until other encoder might be better than lame;) ) , should be about best settings. That we are here at HA, is just random coincidence if it were Project Mayhem, we would call it "Project Mayhem's recommended mp3 ways/settings/quickstart" or whatever.
I believe a wiki page entitled "LAME" should be about the LAME encoder, project, history and developers.
A page that discusses Hydrogen Audio's recommendations for creating high quality MP3s should be entitled "Recommended MP3 Settings". Will LAME always be the recommended encoder? Probably. Is LAME the same as MP3? No. I agree that there should be an important link from the LAME page to the "Recommended MP3 Settings" page, but the two are simply
not synonymous.
- The "Quick Start" is stuck down in the middle of the document.
Yes, the topic/page is about quickstart to mp3, you can encode waves to mp3 via other guis, or dos window by lame commandline, or copying the commandline to foobar2000, so the quickstart to eac+mp3 is at lower priority, after the settings overview.
This needs to be so, logical reason, in the eac setup, there is mentioned -V2 --vbr-new as example setting, and the hint, that this text/setting can be replaced by any other setting mentioned before.
I mean that the Quick Start section (2.5.1), is buried in the document. I would have thought a Quick Start section should be right at the top of a document.
The EAC guide simply shouldn't be on a "Recommended MP3 Settings" page. It should be on a page called "Using LAME with EAC" (currently called "EAC and LAME").
To conclude:
A page called "LAME" should be about LAME.
A page called "Recommended MP3 Settings" should be about the recommended encoder ("The recommended encoder is LAME [link to LAME page]"), encoder version, and the recommended settings for that encoder.
A page called "Using LAME with EAC" should detail how to set up EAC to use LAME.
Links should be made between all pages (and others). Information should not be duplicated on any page.
Edit: The above makes logical sense to me. However I can see that I have confused the issue here slightly. I guess what I would say is - remove any recommendations from the LAME page, and put them on a recommendations page. Keep the information about ABR/CBR and VBR on the LAME page, as that is related to LAME encoding. The current page is a confused mixture of three topics: LAME (1, 2.2, 2.3, 2.4, 2.7, 3), recommended settings (2, 2.1, 2.5, 2.5.1), and EAC (2.6).
I vote for both. Forum and Wiki. A forum sticky shouldn't only link to another page; that's somehow pointless. I don't see any problems to let the recommended settings there, but ALSO to include a link to Wiki right at the top of the page. It would be good to have ONE person to update both, the sticky and the page at wiki, at the same time.
What I really would like to see is better text in overall (arn't here native english speakers) and for the sticky a more clear design -> I already sent user a suggestion.
I vote for both. Forum and Wiki. A forum sticky shouldn't only link to another page; that's somehow pointless. I don't see any problems to let the recommended settings there, but ALSO to include a link to Wiki right at the top of the page.
[a href="index.php?act=findpost&pid=333267"][{POST_SNAPBACK}][/a]
I agree with some of that. First, the contents of the wiki should be brought fully up to date with all the "recommended settings" lists, then we should see how we can streamline the sticky posts and put more emphasis on the wiki entries. Jan thinks that the links from the stickys don't belong on the wiki, so that's one thing that could stay in the sticky posts, for instance. I also agree that we shouldn't auto-forward to the wiki directly, i'd rather have the sticky threads serve as the main discussion threads for the wiki/sticky post content, so that it's not scattered around everywhere. The wiki needs some dedication, perhaps more dedication than the stickys had, and above all, more communication. We must also take care that the contents don't become too technical; the goal must be to make it the first and best contact point for a newbie that searches Google, for instance. This requires that it's constantly discussed and held up-to-date, not so much as a full-on technical reference, but more of a guide that's kept simple, yet comprehensive.
After reading the Wiki article I have to agree the structure and text is a little better than in the sticky. I still think we should keep both, but the sticky post have to be updated (with less background information (eg. history) but while keeping the useful links and the quickstart). I suggest this (http://www.animeplanet.de/haorg.txt). It's not my intention to change to much or to copy the entire text from Wiki, I just would like to see a clearer sticky.
btw, the download link for the List of recommended LAME compiles (http://www.hydrogenaudio.org/forums/index.php?showtopic=28123) is broken. *edit* Seems like is down completely.
Insane settings discussion split here:
http://www.hydrogenaudio.org/forums/index....showtopic=37989 (http://www.hydrogenaudio.org/forums/index.php?showtopic=37989)
Insane settings discussion split here:
http://www.hydrogenaudio.org/forums/index....showtopic=37989 (http://www.hydrogenaudio.org/forums/index.php?showtopic=37989)
[a href="index.php?act=findpost&pid=335181"][{POST_SNAPBACK}][/a]
Thank you !
Regards,
Madrigal
Am I to understand that 'fast' and '--vbr-new' are synonymous? If so, then I'm still a bit confused as to the verdict regarding the quality of the new VBR.
The recommended settings post (here (http://www.hydrogenaudio.org/forums/index.php?showtopic=28124)) places '--vbr-new' ahead of the standard in the quality chart. So I thought it was better. As I read further I see:
"The --vbr-new switch enables the new VBR mode:
LAME will encode much faster compared to old/default vbr mode. Current knowledge qualitywise comparing vbr with --vbr-new is, that --vbr-new might even be better qualitywise than the default vbr mode, but there are also reports about artefact, which is worse in --vbr-new compared to default. Though the general impression is, that --vbr-new should be recommended over vbr-default. --vbr-new can be faster and at equal/better quality at same time, because it uses a different algorithm than old/default vbr mode."
A bit less certain, but still largely in favor of the new. Then I decided to consult 'lame.exe --longhelp' which states:
"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.
This statement seems quite certain that the new VBR is of a lesser quality. Have I missed something?
Am I to understand that 'fast' and '--vbr-new' are synonymous? If so, then I'm still a bit confused as to the verdict regarding the quality of the new VBR.
The recommended settings post (here (http://www.hydrogenaudio.org/forums/index.php?showtopic=28124)) places '--vbr-new' ahead of the standard in the quality chart. So I thought it was better. As I read further I see:
"The --vbr-new switch enables the new VBR mode:
LAME will encode much faster compared to old/default vbr mode. Current knowledge qualitywise comparing vbr with --vbr-new is, that --vbr-new might even be better qualitywise than the default vbr mode, but there are also reports about artefact, which is worse in --vbr-new compared to default. Though the general impression is, that --vbr-new should be recommended over vbr-default. --vbr-new can be faster and at equal/better quality at same time, because it uses a different algorithm than old/default vbr mode."
A bit less certain, but still largely in favor of the new. Then I decided to consult 'lame.exe --longhelp' which states:
"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.
This statement seems quite certain that the new VBR is of a lesser quality. Have I missed something?
[a href="index.php?act=findpost&pid=335569"][{POST_SNAPBACK}][/a]
No, you've not missed anything, it's just that things like the 'help' and the documentation sometimes lag behind the real development. The rest of what you've read reflects the current thinking.
quality may be slightly lower also
"May be", not "will be".
So may be, may not be
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.
[a href="index.php?act=findpost&pid=332128"][{POST_SNAPBACK}][/a]
Same here. Congrats to both the LAME developers and the HA testers for this achievement. It was about time. @Gabriel: although I personally don't care much, it might be a good idea to drop the "beta" tag. I'm sure the HA community has already conducted quite an elaborate round of "beta-testing".
[span style='font-size:7pt;line-height:100%']
Edit: removed some redundant text.[/span]
**edit: removed comments on ^"redundant" text^**
The word "beta" can be removed from the topic now (or whenever John gets around to compiling binaries ).
The word "beta" can be removed from the topic now (or whenever John gets around to compiling binaries ).
cool. has Lame 3.97 been released? I just noticed the new website, but it still says "The most recent beta release of LAME is 3.97beta3"
Edit: ok, I just saw it in the changelog. Btw. the link to the changelog site is wrong: http://lame.sourceforge.net/sitemap.php (http://lame.sourceforge.net/sitemap.php)