I've found that Lame 3.95.1 is clearly better than 3.97 comparing 128 bitrate CBR. Has anyone else reported this? Why is this? Sonar, an audio recording program, has had a version of Lame built into the program's EXE file for many years. Sonar 6 has 3.95 and Sonar 7 has 3.97. The mp3 encoding defaults to 128 CBR and for years this default has worked ok for me emailing my clients' music works in progress. The small file size and fast encoding has worked well for this purpose.

When version 7 came out in the fall I noticed a big difference in quality for the mp3's, so I started using an external encoder that can be intergrated into the program without having to use a standalone mp3 encoder. This external encoder was 3.97 and surprisingly produced far better results than the 3.97 built into Sonar 7. I don't know what caused this.

Later I discovered that using 3.97 as an external encoder in Sonar still produced a less quality mp3 at 128 CBR as Sonar 6, which uses 3.95. In fact 3.95's 128 CBR sounds as good as 3.97's 192 CBR . I then installed 3.95 as an external encoder in Sonar 7 and found that worked as well as the 3.95 built into Sonar 6.

Here's a link to the Sonoar Forum where posted this problem a week ago.
http://forum.cakewalk.com/tm.asp?m=1365461...page=1&key=

Can anyone shed light on what's going on here?

Gerry Peters
Midi Magic Studio
http://gprecordingstudio.com

Did you "ABX" (double blind test) the difference?

Otherwise you couldn't tell fore sure.



billruys and brundlefly are talking nonsense in the cakewalk forum. Don't believe them.

It's possible that they've accidently disabled the bit reservoir in the LAME API. Pure speculation, of course.

The forum link you give, however, is the biggest bunch of nonsense I've ever read. The statistical proof that LAME is better is here
http://www.rjamorim.com/test/mp3-128/results.html

There has been at least one documented instance of regression in CBR quality with Lame 3.97:
http://www.hydrogenaudio.org/forums/index....mp;#entry537861

As much as I agree with you regarding the nonsense in the forum link, note that the LAME version in this test was 3.95, and it compared with FhG encoder v1.0 using VBR. Comparing LAME 3.97 CBR 128 with a newer FhG CBR 128 encoding could easily give a quite different result...

The problem with all these listening tests is that they (necessarily) look at a very restricted set of samples. It's very welcome for learning about the encoders' quality, but it's a serious mistake to take the results too important. And the biggest problem is that many people (like you) misunderstand the reliability statistics for the results of the samples tested as a reliability statistics for the quality of the encoders which is a totally different thing.
What I dislike most as well is the 'zoomed' view of the statistics which exaggerate differences in a way that's not relevant in practice.

That is true, however it is only a single problem sample. Back then I tried to find other similar samples that would trigger the same problem, but couldn't.

BTW, Martel just said in another thread that his sample is not available anymore. My version of the same sample (from a different recording) is still available at HA uploads: http://www.hydrogenaudio.org/forums/index....st&p=538310

Please provide some proof.

In any case it would be better to say that it is slightly better or worse with certain samples.

IMHO, "clearly" means that you can encode just about anything (that is not way too easy for the encoders) and without doubt be able to say which encoder was used just by listening to the samples in a casual situation.

For example, I have provided reasonable proof that the current FhG encoders in CBR and VBR mode are not better than GoGo in ABR mode at about 128 kbps, at least not to me. (GoGo is a special assembler coded version of the old LAME 3.88. It was specifically created to provide much better speed at the expense of some quality degradation.)

My proof is here: http://www.hydrogenaudio.org/forums/index....st&p=515992

The 30 reference samples and my complete ABX test logs are available in the link.

This does beg the question, from me at least, as to why the OP isn't using LAME in VBR. It's been heavily optimised for VBR for some time now and it's a total mystery to me why so many people still use it in CBR.

Cheers, Slipstreem.

Ignorance?
Incompatible hardware?
Compatibility with a file-sharing group?

I think that if ones goal is 128 k CBR then there are 'better' and certainly faster options out there - FHG, Gogo, WMP etc.

Thanks everyone for the posts, it's been informative and has filled in some gaps of my understanding of mp3's. It's nice to find a forum that has this depth of understanding with it's members.

Since I've had these problems, I've experimented with ABR and VBR and have seen the light and have moved away from CBR. Since I've had problems with 3.97 that may somehow be related to Sonar, I think I better stay with 3.95 until I have a chance to test more.

It looks as though maybe -V 3 --vbr-new looks like a good choice that I hope will yield a similar file size that 128 or 160 CBR yield. Since I use mp3's for emailing clients, I'm reluctant to use file sizes above about 7.5 meg, because in the past I've run into file size restrictions in emails. Can I use -V 3 --vbr-new with 3.95 or is that only for 3.97?

Any suggestions?
Thanks so much for the advise.

Gerry Peters

-V3 is likely to produce a bitrates in the range of 155...195 kbps often averaging at about 175 kbps with big file libraries of various musical genres.

-V4 would be more like a VBR equivalent of 160 kbps CBR and -V5 of 128 kbps.

I think the general consensus here at HA is that -V (x) --vbr-new wasn't as good a plain -V (x) switch before the release of LAME 3.97. During the LAME 3.97 development cycle the --vbr-new mode was improved.

LAME 3.97 beta 2 -V5 --vbr-new was included in this public multiformat listening test:
http://www.listening-tests.info/mf-128-1/results.htm
It was found to be as good as the other VBR codecs (within the test's error margin).
There were no significant changes between the beta 2 and beta 3 versions and the final release version is practically the same as beta 3.

You can find the recommended LAME settings at HA's wiki: http://wiki.hydrogenaudio.org/index.php?title=LAME

Maybe you could save & archive your 16/44.1 downmixes in FLAC format (If I recall correctly Sonar 7 has FLAC support) and use an external application for lossy file conversions on the need basis. Foobar2000 + LAME 3.97 would be fine for creating LAME VBR files.

EDIT

Actually, you coud use the quite matured LAME 3.98 beta 8 and report if you find any quality problems. You can easily configure profiles for different encoder versions in foobar2000. In general, LAME 3.98 VBR encoding should be improved or at least as good as before. Your help in developing the LAME codec would be greatly appreciated.

... and fixed a typo.

I'm sorry if this is slightly deviant from the main topic, but when we speak of using LAME VBR modes, which is generally accepted to yield superior results with the latest versions (3.97 and 3.98b8)?


Were there actually any listening tests performed recently to compare the two (in quality, not speed)? If not, what is the general consensus or, in that case, developers' intentions on the matter? In the interest of sheer quality at these bitrates (128 or 160), this might have even more impact on your decision.

--vbr old vs new should be similar with vbr-new having a slight edge (guruboolez has documented it in several tests even with 3.98) .. -q0 who knows .. only relevant to vbr-old. With V4 or better I don't think which version of lame matters much.

Thanks, could you point to these tests?