Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: LAME 3.97 beta recommendation (Read 108847 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME 3.97 beta recommendation

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

http://wiki.hydrogenaudio.org/index.php?title=LAME  <-- this page needs some slight updates, too.
[{POST_SNAPBACK}][/a]


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 3.97 beta recommendation

Reply #101
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.

LAME 3.97 beta recommendation

Reply #102
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.

LAME 3.97 beta recommendation

Reply #103
Quote
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]

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.

Quote
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).


Quote
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).

LAME 3.97 beta recommendation

Reply #104
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 to RareWares' and LAME's link pages. That should help increase Google's page rank a little, and also draw more visitors to it.

LAME 3.97 beta recommendation

Reply #105
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.

LAME 3.97 beta recommendation

Reply #106
Quote
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]

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.

Quote
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]

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.

Quote
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]

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.


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

LAME 3.97 beta recommendation

Reply #107
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 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 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 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]
I'm on a horse.

LAME 3.97 beta recommendation

Reply #108
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 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.

LAME 3.97 beta recommendation

Reply #109
Quote
Quick Start

Best Quality : 'archiving'

--cbr 320.

--cbr 320 ???

LAME 3.97 beta recommendation

Reply #110
Quote
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 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 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 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 quality

Of 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 != 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.


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

LAME 3.97 beta recommendation

Reply #111
Quote
Whereas the sticky topic has only 1 mistake:
The wrong title.
This is what confuses you.
Quote
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.

Quote
  • 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'm on a horse.

LAME 3.97 beta recommendation

Reply #112
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.

LAME 3.97 beta recommendation

Reply #113
Quote
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.

LAME 3.97 beta recommendation

Reply #114
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. 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 is broken. *edit* Seems like is down completely.



LAME 3.97 beta recommendation

Reply #117
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) 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?

LAME 3.97 beta recommendation

Reply #118
Quote
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) 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.

LAME 3.97 beta recommendation

Reply #119
Quote
quality may be slightly lower also

"May be", not "will be".
So may be, may not be

LAME 3.97 beta recommendation

Reply #120
Quote
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]

LAME 3.97 beta recommendation

Reply #121
**edit: removed comments on ^"redundant" text^**

a windows-free, linux user since 1/31/06.

LAME 3.97 beta recommendation

Reply #122
The word "beta" can be removed from the topic now (or whenever John gets around to compiling binaries  ).

LAME 3.97 beta recommendation

Reply #123
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
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'