It's very unlikely that it will be released this year, because there are some issues with Debian and Cygwin/MSYS, which our confi-GURU wants to solve first.

That's good news as I'm away from Friday, 21 Dec until 2 Jan with only very limited Internet access. Happy hols everyone!!

so AFTER that, it will be released ?!?! ;-)

There is a lot of time left AFTER one particular point in time

... So dear LAME devs have a nice Christmas and a happy New Year! And thanks a real lot for your hard and excellent work

I get the impression that only LAME project is the most active against other codecs, followed by NERO Digital. Vorbis seems so abandoned, and not mentinoning the slug MPC...

Would it be the case that LAME heads on top against its competitors at some point?

thanks to the lame devs' hard work, it could very well happen. at 128 kbps, lame moved from last place here to tied at first place here. lame also tied with former champ mpc here.

You're wrong here. Vorbis may be abandoned, but Musepack isn't.

http://trac.musepack.net/trac/timeline

I guess active members on HA also expect activities on the most promising codecs, and if there are none many members consider a codec to be dead. Look at the discussion about MPC before the current MPC activities.
But this has nothing to do with the quality of a codec. Quality simply may be fine without real need for improvement (thinking about Vorbis for instance).

Anyway the great quality improvements of Lame are most welcome as mp3 is the most universally usable standard of audio compression.
Thanks a lot to the Lame devs who have made Lame mp3 competitive with newer codecs.

I just tried tried the official 3.98b6 at V0, and though my last test was with a version pretty close to this one eig has improved one more time. The 2 prominent impulses that have been a problem for so long were a pretty negligible problem with my last test, but now there is no problem at all with them for practical listening situations. I had a hard time to abx them - I had to listen over and over again before daring to abx.
Trained this way I was also able to abx harp40_1, but from previous tests I have the experience that with mp3 it only takes sufficient time to be able to abx harp40_1 with any mp3 encoder, even at very high bitrate. Again this is academic, for practical listening situations it's no problem at all.
I was also able to abx the tremolo problem of the artificial lead-voice sample. I could not do so with my last test, so I guess this is also due to my current abx training with eig. lead-voice isn't important however for practical purposes.
My other tremolo problem sample trumpet_myyPrince was fine, and this sample has a practical impact.
My other problem samples (Birds, trumpet, herding_calls) were all not abxable to me.

We'll get a great 3.98 version.

Any news about the B6 eating up the cpu bug? Would be nice if that was solved then i could use it.

That doesn't make much sense, B5 and B6 should behave the same. Are you using lame.exe or lame_enc.dll?

The dll.

More info:
https://sourceforge.net/tracker/?func=detai...mp;group_id=290

The lame_enc.dll frontend code hasn't changed from b5 to b6. The lame_enc.dll doesn't do any file IO, it's the calling application -- in your case totalrecorder -- that does all reading and writing from and to the files. The application calls lame_enc in a loop and passes the data in memory. So, it seems to be more of a compiler / compiling issue, than a change in LAME itself.

I just did a check with the official B6 (forgot wich site but it wasn't rareware this time) to see what happened. And gues what the problem is now gone i have a normal cpu % again.

So it could be indeed the compiler that rareware used.
What should i do with the bugreport?

Good to know, where did you get it from?


Nothing, I'll take care of it.

Stupid me, i always thought i got my non official beta's 6 builds from rarewares, but in fact it was from http://lame.bakerweb.biz/
I gues it read so much about rarewares that somehow it was printed in my head, sorry about that.

The official and working B6 however was dloaded from rarewares, sorry for the misunderstanding.

Sorry if this was asked in an earlier post, but around what time will the final version of 3.98 be coming out?

robert replied here:

Sorry if this has been discussed before, however from the changelog (here) it states:

Does this potentially mean multichannel MP3, or that LAME will be able to read/select certain channel from a WAVE_FORMAT_EXTENSIBLE *.wav file (and prodece a mono/stereo track from those)?

Cheers, Arite.

But there's a big gap between them. Nero digital devs keep on telling there's problems regarding putting up stuff onto the web page, but however. I lost trust in the codec because of some problems with classical, they soon told the source of the problem has been found, but this is some ages ago.

No.

Are there still planned features and bug fixes which affect quality before 3.98 goes stable?

OK, thanks for the reply - what does it mean then?

Cheers, Arite.

You can have normal mono/stereo wave files with WAVE_FORMAT_EXTENSIBLE format definition. Previously LAME did reject them or interpreted them as raw PCM files. Now LAME recognizes and may read them.

Musepack wears out with the long long lack of constant releases. But it's not just it, we're talking about here audio quality. Guruboolez once stated that he was so frustrated with MPC people that wouldn't even acknowledge a plain clear issue concerning audio quality, and that still was not looked into until today. And more... projects with no-dateline are pretty depressing, put everybody on hold and pain. It's easier to look forward to something when you see that there will be new releases in a time, that everything is moving on. But when a developer says "it's out when it's out" or "I just don't know when it's out... perhaps some day in life" is just so depressing... MPC have sinned in many ways like this.

Wrong about Vorbis. It is absolutely necessary to keep Vorbis I as stable and the codebase as constant as possible. This has to do with the lack of a formal "external" specification for Vorbis similar to the MPEG-specs so that it is necessary to keep everything as frozen as possible to allow hardware-vendors to trust Vorbis and to step in and to support Vorbis I on their devices (MP3-players). The exception is Aoyumi as he really does a fantastic job in optimizing the sound quality - actually without changing the already existing codebase (apart from adding a few possibilities).

As far as I know, the work on Vorbis II has started but I do not know more about the reasons to start it...

OK - thanks a lot .

Arite.

Vorbis I is not even the recommended Vorbis encoder in HA. All spotlight is directing to the only one aoTuV b5, which is good but without a release for almost a year. LAME had always been releasing betas and reaching one more final release early next year.

Ahem, the aoTuV versions are "just" patches to Vorbis I and these patches are now in the Vorbis I development branch...

Yes, lame releases one version each year but most important for these releases are sound quality improvements (if they happen). Lame 3.98 --vbr (especially the newest betas b5 and b6) is a true gem in that respect but between 3.90.3 and 3.97 I couldn't see that many improvements. In fact, 3.97 --vbr-new sounded quite bad to me (I was angry about -V2 several times) ) and I got the impression that --cbr and 3.90.3 is still a very good alternative. Now, how old is 3.90.3? It is from May 2003!

In your opinion, would you make the Vorbis I encoder the recommended encoder since it has been released a few weeks ago and has the aoTuV patches? Or is it only in development branch? If not why aoTuV keeps being the recommended encoder even with low level noise added to encoded files?

LAME 3.98b6 should be set as the default encoder now.
3.97b1/2 was the recommended encoder for a long while (no point saying HA likes only "final" releases as stated by a member).

2001

Sorry guys, I haven't been here for ages and I don't have time to read through all the posts...

I haven't used MP3 since 3.96.1 final but I bought my mom a new MP3 player and so I needed to grab her a few CDs.
I googled for "lame", picked the first download, it was version 3.98b6 (oct 22 2007). Then I accidentally listened to one of the ripped songs and it was a shock for me!

here is the sample
http://www.volny.cz/martel/mp3test/test.zip

I used lame -b 128 -h command line to encode the song. The 398b6 version produced real nasty mess in the beginning:
http://www.volny.cz/martel/mp3test/test398.mp3
I somewhat remembered mp3 quality over those years and this was too much. So I used the 3.96.1 version I had on disk and encoded with the same command line:
http://www.volny.cz/martel/mp3test/test3961.mp3
And here it goes - the mess was gone!

I don't care much about MP3 development anymore but imagine a normal user which googles for Lame and gets this junk, far inferior compared to several years old version!

I was like "WTF?!!!" myself. There should really be some warning attached to beta releases or the code should be somewhat restricted so normal people googling for LAME get the best version available, not some hocus-pocus junk like the version i got.

EDIT: Sorry, the links are down as my hosting got deleted without notice. Unfortunately, I don't have those files anymore.

Some regression is normal as long as overall quality is showing improvement. Also is CBR going through much tuning / testing ? I guess most people are interested in the vbr scale. Also -h is q2 and is not the default noise shaping - maybe different from 3.96 q2. Sometimes I got increased ringing from it.

Unfortunately premature and incorrect versions of 3.98b6 were compiled and published.
The 'real' 3.98b6 version was published december 17th and can be downloaded from Rarewares.
I guess everything is alright with this version, and you're welcome to try it.

Can't ABX these two. They sound identical to me.

If you mean this file
http://www.rarewares.org/dancer/dancer.php?f=186
then know that I tried it out now and it produces exactly the same mess as the previously mentioned version (oct 22).


No offense meant, but I sincerely hope that you or people like you don't help develop LAME.
If you don't know what to look for - the 398 version adds audible (pre?)echo to both audio channels (before vocals come in). 3961 adds only almost inaudible one.
I use Sennheiser HD 490 headphones and an integrated Realtek HD audio sound card (Asus P5K). And I can hear the mess despite the mediocre setup I have.
If noone else can confirm the fuzz, then there's no hope for you guys. LOL
I think I'm going to back up my 3961 version of Lame pretty good.

This new mp3 player should be able to play VBR mp3s. Try -V5 instead of -b 128 -h

No offense meant, but CBR (128, 160 and 192) is bread and butter of MP3. Is there really ANY reason to wreck it up in newer releases of LAME? I don't care about VBR as long as there is no two-pass encoding. And even if there was, I wouldn't trust a version that can't do CBR properly.

128k cbr is the most archaic thing and was notorious for giving mp3 a stigma. IMO its too unstable no matter what encoder. You need at least 160 or better yet 192 for steady cbr.

[/quote]Can't ABX these two. They sound identical to me. [/quote]



Same here. No "mess" in my ears, as well.





@Martel



Most probably your Mother won't hear the "mess" either. It must be a real curse and a burden to go through life with your incredible hearing.





Happy New Year!

Martel, beta is beta, you need to use 3.97 final.

I can confirm that the problem exists, I can ABX it without trouble. Will try the official 3.98b6 now to see if the problem still exists.

Edit: It's still a problem with the Dec 17 build. In fact, the created file is bit-identical with the problem file provided by Martel. The most obvious thing I can make out is a stereo problem; you can hear added stuff coming from the right in the 3.98 encode. Hard to describe this more clearly, sorry.

Edit2: An interesting point maybe, lame -V6 -b128 -B128 -F (with the Dec 17 build, also tried V0 with similar result) sounds better to me than any of the -b128 versions I listened to (i.e. also better than the "unproblematic" 3.96.1 encode). This is not encoding advice - it just seems to me that the VBR code can (at least sometimes) be better at cbr than the cbr code, which is kind of weird...

Martel is correct. The problem is obvious. I can hear the phenomenon easily with my crappy PC speakers. No need to switch to headphones or to my Hi-Fi system. This is something completely different than a minor artifact that can be reliably detected only by ABX testing.

The same problem exists already in the official v. 3.97. I didn't have 3.96.1 anywhere near but I tried the old reference 3.90.3 and it is clean similarly like Martel's 3.96.1 sample.

Here is a screenshot of Spectrum Laboratory's waterfall display. It contains the first three guitar chords (about 3 s.). The additional artifacts can be clearly seen in the 3.97 sample. The problem is more obvious in the left channel. The samples are (from top to bottom):

1. LAME 3.97 "release" @ -b 128 (which should use the optimized CBR presets automatically)
2. LAME 3.90.3 @ -b 128 -h (-m j is enabled by default)
3. original wave


Click to enlarge.


EDIT

Could you have the channels reversed? Looks like there's more additional stuff on the left.

Might be, but there's already the guitar there. It's easier to spot something when it comes from a previously "silent" direction I'd say.
Edit: I just listened to it with my speakers instead of headphones for the first time, now the distortion on the left is far more noticeable.

Yes, that's the link I meant. And like Med0 and AlexB I can confirm your finding: the -b128 encoding is real bad, kind of a long-lasting additional echo.

I agree with you that CBR should be fine as well (at least with this sample), and it seems to me too that general focus is too much on VBR in recent years. But I do think the Lame devs are willing to improve on problems found also with CBR. So your sample is valuable especially as not many people use CBR.
But shadowking's comment is true as well IMO: when using CBR a higher bitrate is necessary to get at real good results with mp3.
You can also see it the other way around: Lame 3.98b6 has become real good at VBR, and it's not a bad idea to use it.
Anyway it's up to you, and if you want to stick with CBR and want to use it right now, you may be better off using 3.96.1 or even 3.90.3.

I'm pretty sure my mother can hear the problem and she was born in the '30s.

You know, I gotta re-listen to these samples again when I get home from work, because I coudn't hear it on these PC speakers. When Martel used the word "mess", I imagined this ungodly unlistenable noise, and even if there is this echo that you all hear is it that terrible that it makes it unlistenable? That LAME is useless because of it? Do I need to get a doctor's referral for a hearing test? My 50 year old ears just don't hear the "mess" that Martel does.

If Lame is regressing (the sample sounds fine using 3.96 and 3.90) then it should be brought to the attention of the developers.

It's personal judgement how to feel about a problem.
Anyway it's a real problem that hopefully will be repaired.

No, there's no reason to wreck CBR quality and I hope this problem gets corrected. But why not care about VBR just because there is no two-pass encoding? And even if it butchers all samples with CBR, if it sounds better with VBR and works with your MP3 player then why not use it?

VBR doesn't need "two-pass encoding".
"two-pass encoding" is for ABR.