Chris Myden http://www.chrismyden.com/bestmp3guide.php really gives the big push to 3.90.3 and then includes a link which takes you to http://wiki.hydrogenaudio.org/index.php?title=Lame_Compiles ; this link recommends 3.97b2 - the lame version recommended by The Coaster Factory http://users.pandora.be/satcp/eac-qs-en.htm

Of course, it's making my head spin.

Is there - dare I say it - a definitive answer to "what is the best lame version?" or is it simply a matter of personal preference?

I would assume Chris Myden's guide is just a few months out of date.

HA recommended 3.90.3 until the end of 2005.

The LAME wiki page is a good place to read about the current recomendations.

Edit: Bear in mind that Chris' guide also mentions EAC 0.9b4, while the lates version is 0.95b3. He also mentions that 3.90.3 is recommended by HA (which it no longer is).

Edit 2: None of this invalidates Chris' guide in any way - although you may want to update any references to the alt-presets using the wiki page I quoted above. This is not necessary though - the new version understands alt-presets.

Who is that Chris Myden?

What I mean is, I think all those "MP3 guides" that recommends LAME and EAC contains knowledges that originates from HA. So take the advice directly from HA is your BEST bet.

The official recommendation from HA and many others is to use LAME 3.97b2.

Chris Myden is the guy whos site introduced me to HA.org in the first place. Anyway, he is the founder of (a site that shall not be named), a site with a P2P network that swaps only files ripped using EAC secure mode and encoded using LAME 3.90.3 with one of the --alt-presets as the encoding parameters.

Well, I'm not sure that site not to be named will change their recommendation anytime soon. They're very concerned with quality, of course, but they also tend to be extremely conservative holdovers. The recommendation of the old version of EAC is not a mistake because of lack of updating, but rather because they don't trust the new version because it "hasn't been tested enough." At least, this was how things stood last I heard.

I thought it was because later versions of EAC had some "stuff" taken out that jeopardized the site-that-is-not-to-be-named's attempts at file sharing.

I believe I have mentioned that all their knowledge originates from HA. Otherwise, where do you think their knowledge of using LAME 3.90.3 come from?

It's personal preference. (my preference is 3.90.3)
I find that different versions are better for different bitrates.
The only way to determine which is best for you is to try them all.
Use the one that sounds the best to you at whatever settings you like to encode with.

Things generally evolve over time, and rarely go backwards. As such, I have a tendancy to say that whatever version stays "the new version" long enough is the best one. As such, the 3.97 beta2 branch has been alive and kicking for quite a while with only minor encoding changes. I'd say we're pretty close to perfection ;-) (Thanks LAME Devs )

It's a major human problem that we tend not to differentiate opinion.
When it comes to an 'attack' or 'defense' of a beloved encoder this seems to be especially true.

As for Lame we've seen in recent 128 kbps listening test 3.97b came out great.
Does this tell us 3.97b is better than 3.90.3?
In a way it does cause we can't expect 3.90.3 having behaved better in this test. (I guess 3.90.3 would have gotten considerably worse results.)
This tests (as well as other listening experience) tells us Lame is still being developed and the Lame devs are doing a very good job.

But we cannot generally say: 3.97b is better than 3.90.3.
The problem is the meaning of 'better'.

We can expect from the test that most listeners will rate most of the music encoded with 3.97b -V5 --vbr-new as being transparent or near-to-transparent.
If this is all we are out for 3.97b is better than 3.90.3.

But especially with Lame there's more than that. As we can learn from Gabriel's problem sample thread there are samples which are encoded badly with 3.97b even at high bit rates.
The Lame devs are working on it, so hopefully soon this will be overcome.
But at it's current state 3.97b has this issue. Of course everything depends on how we think about these samples. We can consider them as being 'just a few samples'. To me personally they are not isolated samples but show up a certain flaw with 3.97b's behavior.
The problem is not totally specific to 3.97 but more or less to the behavior of the Lame versions that have emerged recent years. The problem has gotten worse from version to version.
Details from which these problems might emerge are
- Lame's VBR behavior. It's bad for these problem samples (and has already been bad with 3.90.3)
- Lame's transient behavior.
This might have become worse when changing the underlying psy
model or its usage from plain GPSYCHO to NSPSYTUNE to NSPSYTUNE2 (my personal suspicion).

When the goal is to prevent bad encodings
Lame 3.90.3's ABR modes used with target bit rates way beyond 200 kbps
are fine to use (ABR means unintelligent safe VBR, and with 3.90.3 it means using GPSYCHO. Unfortunatey it also means to not use Joint Stereo, but with high bit rates this shoild be OK.)

So is 3.90.3 better than 3.97b? Sure not.
As we've seen everything depends on our understanding of 'better'. That's the key issue (besides looking at current development and how it improves on the issues).

Beware of plain judgement of the kind 'A' is better than 'B'.

You should probably just ignore Chris Myden and instead listen to the LAME developers. 3.97b2 is the recommended version.

Please don't imply that ABR mode is better at "preventing bad encodings" than the heavily developed VBR modes without proof. You should at least show the ABX results that proves ABR mode to be better than VBR mode with certain samples to support your claim.

Otherwise, one should listen to the LAME devs. They know LAME much better than anyone else.

Sorry, see Problem sample thread, Problem sample discussion thread, 'Insane' settings thread, transients test thread.

Only 1 of those actually has any LAME 3.90.3 ABX scores, and that thread is 9 pages of mostly pure crap on some other topic. Maybe you could link to the part with the scores in question?

I am agree with halb, at very high bitrate (>200-250) ABR preserves higher quality than VBR, like cbr 320 preserve more quality than vbr. For me the reason is "surround" channel, i.e. substraction of left and right or right and left signals. In VBR mode this virtual channel almost totally destroyed, a lot of ringing often louder than useful signal is present. And i descovered that vbr-new mode destoy it much more than vbr-old. In ABR 256 mode that i am usually use there is almost no differences to original sample like in cbr 320 mode.

It is no need to send example samples, because it is very easy to ABX even at "extreme" preset almost at all songs that a have, and i think you to.

To hear what i am talkin about put at end in DSP manager in foobar "Phase inverter" and than "Downmix channels to mono".

And i know than music is more preferably listen in stereo mode and i do it such way, left and right front speakers plays plain stero but thers is an additional speaker with hpf and lpf behind the sofa. And there is similar scheme in auto. I'd like to speak this scheme is more widely used in auto sound installations. It's have own name but i can not remember it.

edit: typo

im guessing this change was in lame 3.94 beta (i never knew there was an nspsytune2 )

myself i like to use gpsycho for cbr 128 or higher, and nspsytune for lower cbr rates and for vbr.

i haven't been all to impressed with lame 3.94 and higher
(unless there is some hidden setting that makes it better below 128kbps )

Sounds like BS to me. You are saying LAME vbr-new is destroying music, but I think you should read the listening test that is just finished.

Again, if you are sure that you are the exception, give proofs, i.e., samples with ABX results. No vague words please.

I already know all of those threads. But would you please tell me which specific samples you are referring to?

P.S. I have tried samples uploaded by Wombat but I cannot hear the artifacts. Maybe my ear is not sensitive enough.

MP3 and the likes are not designed to be played back with (heavy) post-processing. There is no special "preserve surround channel" mode in Lame. It is designed to operate on regular stereo (and mono) only. Look at it this way: the surround channel is supposed to be inaudible in a stereo playback situation. And those inaudible places is where any lossy psychoacoustic encoder hides its quantisation noise. No wonder it's all bubly. High bitrate ABR probably preserves this information because it is being inefficient. What you are doing is complaining that a car doesn't swim.


I'm not sure what you're talking about. hpf = high pass filter? In a car the rear speakers get the same signal as the front speakers. You can do the same with the speakers behind the sofa, copy the signal that is (beware of phase problems). Of course if you have a dedicated low frequency unit, you should use a frequency crossover. Maybe that is what you mean?

hmhm,
I wouldn#t say, that every post-processing is equal.

It is standard these days, to listen to stereo material via Logic7 or DPl2 decoders. Either you like it, or you don't, depends also on the music and your mood.

So, a good performasnce of a lossy format should also consider these Logic7/DPL2 decodings.
At least in higher bitrate/quality modes.
When i did tests on mp3, simple rear channel signals were also preserved fairly by 128k lame 3.90.x encodings, though lame extreme & 320k 'rocked'.



Regarding Mydens recommendation of old EAC 0.9b4 or EAC 0.95pb3 , I guess, it is because of necessary special features, if you wanna extract flawlessly weird CDs in EACs secure mode. I use still myself eac 0.9b4, and haven't found a reason to update. Maybe I would update or at least would install a 2nd modern EAC version, if the annoying popping window behaviour is solved ? Any news ?

There's a lot of discussion between LAME 3.90.3 and 3.97b2 (yes, I know it's the title of this thread). But how about LAME 3.96.1, which is the official recommendation of The LAME Project (as hosted on sourceforge.net)?

What annoying popping window? Sorry I don't understand this issue.


It is because 3.97 is still beta after all, and the front page only shows the official release version.

The trumpet sample is still the most obvious to me, next comes herding-calls, but there are quite a lot more you've certainly read of in the threads. Some are very interesting like atem-lied, and Wombat has contributed with quite a lot of samples.

Try trumpet starting with 3.97 -V5 to obviously hear what it's about. Continue with -V2 and -V0 to see that the problem is still there.
Then try 3.90.3 --abr x -h with x=192, 224, 256. Hear how the problem is not a big one even at 192 kbps, and goes away at 256 kbps.

Be careful with thinking like 'VBR is better than ABR'. While there is truth in it, with a statement like this there is a big danger of over-simplification. The statement is true when taking as a principle. But the principle has to be implemented. Implementation may not be easy, the machinery cannot really know what's good enough. In fact everything depends on implementation. Implementation may be advantagous for certain areas of application, whereas in other areas the disadvantages may be more serious. For achieving high quality in the 128 kbps average bitrate area Lame's VBR to me is very advantegous. Things are totally different however when I'm in the 256 kbps target average bitrate area. Compared to simpler ABR VBR has a good chance to worsen things due to limitations on quality estimations and chosing bitrate too low whereas it can't have a very positve effect quality wise against ABR since we're close to maximum bitrate with average bitrate. The advantage/disadvantage ratio simply gets worse with VBR when average bitrate gets closer to the 320 kbps limit.
With current Lame's VBR things look like that. But look at the Helix thread. Helix' VBR implementation looks like being more reliable in the very high quality area.
Implementation is as important as principle - if not more.

Read for what, it is better to listen isn't it?


It is not vague words. Just try to listen in the way i propose. It is very easy to hear at almost all songs.

What I am confident is that, if this is merely programming bug/regression or error in the algorithm that produce such issues, it can be solved.

What I see the issue is that, these problem samples are exceptions rather than the norm.

Trumpet is a famous problem sample iirc, I think I should do a listening test too.



I don't understand why you need to listen to manipulated music. Any special purposes?

Read the report of course. For normal listening conditions all encoders are virtually problem-free.

Or am I mis-understanding something? You need to listen to specially manipulated music?

Is it postprocessing? - Yes. Heavy? - Think not. It is just a pair of wires conected other way. And i prefer ABR 256 because it sounds like CBR 320 with more efficient bitrate. But the only mode that destroy surround is VBR. --preset-extreme (or -V 0) destroys surround much more than CBR 128 is what the main thing i am talking about.


(edited)High Pass Filter at about 200 Hz and Low Pass Filter at about 5 KHz.
In a car the rear speakers get the same signal as the front speakers in one case you connect that such way but there is another way. One speaker connects to left plus wire and right plus wire of your headunit/amplifier another speaker connects to left minus wire and right minus wire. It is almost plain surroud.

In the way i propose you may hear from your front speakers without any wire manipulations what i am hear from my surround channel.


Manipulated - no. Just some kind of not plain stereo speaker set like many other. And i points to the fact that you don't want to hear - the only mode that heavily destroys virtual surroud channel is VBR.

You're very much welcome to do so cause this is experience not just reasoning.

Of course I do hope these problems will be overcome with current Lame development, and with the experimental lame_attack version (see his transient thread) I think Gabriel has taken a good step in the right direction.

What I tried to say in my first post here was: beware of a generalized black-and-white thinking (old vs. new, vbr vs. abr, ....). Try to differentiate.

From what I understand, you are not talking about the same issue as halb27 says. halb27 mentions the weakness in the current LAME. What you are referring to is a usability issue, that VBR algorithm destroys the way you listen to music.

I am thinking of 3 things:

1) I think VBR (variable bit rate) by itself means that the bit rate is not constant for all the frames. It should have nothing to do with "destroying" your "virtual channels". Maybe the algorithms that is used by the LAME VBR modes (but not in CBR/ABR modes) cause this issue.

2) Does it happen in all versions of LAME up to 3.97 beta? I have an impression that it happens somewhere in the development, as VBR was heavily developed in recent years.

3) I am not sure if custom manipulation of channels can be supported, or even considered. However, seeing that CBR/ABR modes work correctly, I guess it can be done, except if there are some limitations exist somewhere else in VBR modes.

And in addition: "lame -V 0 -b 192" much worse than "lame -b 192". And in that meaning there are almost no differrences between 3.90.3 or 3.97b.

You mixed different parameters to draw the conclusion you wanted to draw, and you probably know it.
You are comparing 2 versions using 2 different encoding modes using 2 different psymodels, and you are able to use this to conclude that abr is better than vbr at high bitrates?
The problem with trumpet.wav is in the attack detection, part of the psymodel. 3.90.3 with -V0 would also reduce the trumpet.wav problem because 3.90.3 is using gpsycho by default. This is not a vbr vs abr case.

Of course I understand this. That's why listening test is important. However what I concern is how severe the issues are in real world music. Can it be generalized that LAME VBR is inferior to ABR in all music? Of course not. And I think nobody disagrees that LAME 3.97b2 is recommended over 3.90.3 in most cases.

What "recommendations" mean is that generally speaking, you should not go wrong if followed properly. Of course realizing that LAME is lossy codec, it has its problem samples. How frequent you encounter the samples is another matter.

It is definitely the same with 3.90.3 and up.

There is one workaround is to use -m s switch. In case of surround channel in VBR stereo mode sound much better than plain VBR but worse that CBR but stereo signal itself starts to have much preecho effects and noise and it is practically useless even in -V 0.

Yes, things are mixed up in this statement.
Attention in the recent posts has been drawn towards VBR/ABR and I've answered quoting my experience which adresses more than just VBR/ABR.
As you can read from my first post here my suspicion concerning the problem is
- psymodel or psymodel usage (what you just actually confirmed)
- VBR. Well, your post makes me really wonder what my suspicion is based on. IIRC all my negative VBR experience was with the alt-presets or -Vx in current versions. I can't remember having tried -Vx with Lame 3.90.3. I do well remember other well-respected members like guruboolez were talking about certain negative experience with VBR that is cases where bit rate was chosen too low. So I will be cautions talking about VBR flaws. And will try 3.90.3 -Vx tonight.

Sorry for talking too loud about potential VBR flaws.

@Gabriel:

As for the samples on your problem sample thread:
Are the problems all due to attack detection problems?
(Acoustically to me some problems share similarities, for instance herding_calls and trumpet).

Well, blaming VBR for badly encoded samples like trumpet and herding_calls was quite allright.

I just tested 3.90.3 gpsycho usage -Vn -h against --abr x -h, exactly speaking
- -V2 -h against --abr 192 -h
- -V1 -h against --abr 224 -h
- -V0 -h against --abr 245 -h
which should be quite a fair comparison as far as generally expected average bitrate is concerned.

All the VBR modes did an extremely bad job on herding_calls and a very bad job on trumpet whereas the ABR modes are very satisfying from 224 kbps on, and not too bad with 192 kbps.

Average bitrate on herding_calls:
- -V2 -h: 113 kbps !!!
- -V1 -h: 119 kbps !!!
- -V0 -h: 127 kbps !!!
And you absolutely hear that. Awful!

Trumpet is a bit better and achieves the same quality with -V0 as does --abr 192.

Horrible results for VBR.
I know it's not the only issue cause current Lame versions behave even worse due to nspsytune usage as Gabriel said (or more complex combinations of all these things).

So I stick with my advice:

For rock-solid high quality encodings if disc space isn't a problem (in many cases it isn't) use

Lame 3.90.3 or Lame 3.91 with something like

--abr 256 -h.

It's not necessarily 256 kbps, but should be at least 224 kbps.

It's not a bad idea to lowpass additionally according to your likings.

Restricting lowest bit rate used by means of the -b switch is a further possibility to do everything to ensure quality. (But I don't know any samle where this is necessary).

Processing which makes the inaudible audible is what I consider heavy (and almost everything will qualify). It is highly likely that you will uncover quantisation noise this way. I'm sure you could develop an encoder which also takes into account the distortion added to any surround or matrixed channel without breaking the format standard. However no such encoder exists. If one codec should happen to preserve this part of the signal it is "by accident" an inefficient. Solution: Pre-process the signal and use a proper multi-channel codec.

I would also say that listening to music via Pro Logic and the likes is far from standard. Especially in a purist environment. You can of course do whatever you like, but you can't complain if you are using something outside of the design specs.

Thank you for explaining. What you are doing here is uncovering a part of the signal which was not regarded during encoding. It is bound to sound awkward. (See above)

Claiming "rock-solid" with merely 2 problem samples is unwise. You must prove this statement across a wide range, if not all, samples at this bitrate in order to draw the conclusion. I think you cannot do so, seeing that LAME is generally achieving transparency at 128kbps for a lot of music samples.

What I would rephrase is that "for those music that you find suffering in current VBR modes like (problem samples here), try ABR."

Of course it would be better if the cause is found and fixed.

a) Lame 3.97b -V5 is great for most of the music.
b) Of course you can always use a method that works most of the time and switch to another method when you encounter problems.
c) I do hope so.

Everything is fine doing so.
Just a personal decision.
I personally like using a method which is guaranteed to be reliable to a very great extend. I can never have security, but with 3.90.3 --abr 270 -h -b224 --lowpass 18600 I feel very much on the safe side. All my productive mp3 music is encoded this way (so far - for the next future I will try Helix just out of curiosity). I've never encountered a problem neither with 'normal' music nor with all the problem samples I tried. And as I don't have to care about disc space neither on PC nor on my iRiver H140 this is my way to go.
I'll switch back to current Lame as soon as the problems are reliably solved.

@Gabriel:

What is strange is:

I had a suspicion against nspsytune in the early days of my occupation with the problems.
You were arguing against that but you concentrated more on the formal things (my kind of writing) than giving insight to the issue.
After realizing that 3.90.3 api works fine on trumpet I didn't talk about nspsytune any more though my suspicion remained.
After testing 3.90.3 --abr x and --alt-preset x for finding what x should be good enough I found quality difference is there for x=224 and especially x=192 (in favor of --abr x), but was neglegible to me at 256 kbps.

So as for 3.90.3 and these problems gpsycho is preferable, but at very high bit rates it's not so essential any more.
VBR problems are more essential with 3.90.3.

With Lame 3.96/3.97/3.98 however psymodel or it's usage has become more unreliable. trumpet isn't transparent even at cbr 320.

Probably because you are often drawing "formal" conclusions based a only 1 or two tests mixing different parameters at once, thus hindering ability to find real conclusions.

Example:
In this thread I told you that the problem with trumpet.wav is not a vbr vs abr problem but instead a psymodel problem.
You then tested tested 3.90.3 gpsycho usage -Vn -h against --abr x -h using herding_calls, which a different sample, to conclude on abr superiority against vbr.
To me this is simply flawed.

Well, it isn´t worth to waste so much energy to find the "new" best lame setting with old versions and 2-sample bettering command lines.
I have a good feeling about some BIG improvements happening atm, i heard. Soon we all can spend our time finding new samples cause much of the older will be clean

???
I was testing trumpet and herding_calls (those samples I do know suffer most from the problems).
trumpet showed bad VBR behavior as well, it just wasn't so extremely bad as herding_calls. So I reported more on herding_calls.

Apart from that I feeled obliged having to test VBR behavior as I really couldn't say what my opinion was based on. It has emerged over time but that doesn't say it has a real background. I felt obliged to test 3.90.3 -Vn, I felt not obliged to test specifically trumpet for the only reason you were talking about trumpet.

Sure I always test trumpet, and -V2, -V1, -V0 were all bad on it, much worse than the competitive --abr 192, --abr 224, --abr 245.

OK, let's look forward for it.

erm, please reread what i wrote above.
No simple ProLogic.
I wrote about Logic7/DPL2. Very different from ProLogic in practical terms.
It is stereo, stereo is standard, there are specs, howto mix DS2 stereo stream doing yourself by freeware, developed originally by DarkAvenger for HeadAC3he, even mp2 can save DS2, and Besweet has implementation of DS2 also.

Though this stereo offers a nice possibility to get good surround.
Lossy stereo formats don't have general problems encoding this, see Lame 128k or mp2. Only certain modes might get in trouble or perform worse or better on this.
So, it is interesting to point out flaws, as there are also examples, where lossy works well. So the developers can see, which modes could be tuned, and which things result to which effects.
No need to discuss about "purist environment" in music listening, and concentrating in "pure stereo". Lossy stereo is especially not for purists, those would go Lossless only, or even swear, that original CD is better than Lossless, whatever.
Lossy/mp3 is common, also common are capable Logic7/DPL2 amps. No probs. I think, it is obvious, that developers might not have Logic7/DPl2 as most important issue on their ToDo-lists, but it is also unnecessary to argue against this feature by "purists arguments", as it is really well possible in Lossy.

Prologic sucks with music content i'm talking about something closer to "simple" surround.

The question is why we are talking about vbr as a most quality and compromise mode if it's not true in special needs? I understand you point but more logically to use abr and cbr instead of multichannel codec or vbr and not to talk to use vbr in this case.

I think the good idea is to describe recommendations to this situation at "Recommended LAME settings".
And i hope the LAME developers draw an attention to this fact. And it'll be interesting to hear from developers why only vbr corrupts surround "channel" even with high lower bitrate floor (-b). And of cause it will be good to have something like "surround preserve switch" in vbr mode.

Thanks.