Lame version 3.97 beta 1 is available at rarewares, this is good news for all those alphaphobes around here.

Excellent.
Great work from the LAME devs.
And thanks for the early heads-up skelly831.

Would I be correct in assuming that there is actually no difference in the encoder bewteen 3.97a12 and 3.97b1?

Great!


I'd like to know too.

I see no differences apart from the version tags after comparing the mp3's produced with -apfs

Actually the a12 .exe is 181kb while the b1 .exe is 163kb.

jaybeee

Supposedly, it isn't out yet (or the CVS changelog isn't up to date?)

LAME 3.97 alpha (CVS)

Robert Hegemann:

Fixed and out of array access
Fixed some small rounding problem in vbr-new quantization routines
Updated scalefactors allocation scheme in vbr-new
Fixed mingw32 configure problems
Resolved some compiler warnings

Gabriel Bouvigne:

Changed some FLOAT8 to FLOAT
Reworked -q1 and -q0
Updated presets
Fixed an error in ISO quantization on systems not using the IEEE754 hack
Faster quantization
SSE version of init_xrpow

See the 'history.html' in the download. In quality terms, I believe there is little, or no, difference between a12 and b1.

BTW, this is a great present for my birthday. Thank you very much, dear developers

Can you prove this is a "great" present, do you have ABX results?

JK, Happy Birthday, Leo 69!

i was just thinking the same thing! today is my birthday as well.

edit: btw, shouldn't this be an official announcement?

i didn't feel like starting a new thread for such a simple question, but i was wondering if it made any sense to use -q 0 with -V2 --vbr-new. I know it will slow down encoding time, but if in some cases it will pinch out some extra quality or cut out some bits, it may be useful to me.

AFAIK they fixed the old bugs in -q0 and -q1 during 3.97's alpha stage so assuming there aren't any more unknown bugs it should be safe. Now whether or not you should use them is an entirely different matter

Is vbr-new default for "vbr" mode in beta1?

the apelllation beta affords some psychological comfort ;-)
The regression report inclines me to use V0, q remaining the same.

No. Could one of the developers please explain what is planned in this regard?

I see that there is a slight speed drop in vbr_new on my machine:
397a12 --vbr-new: 16.2x
397b1 --vbr-new: 15.5x

The differences down to vbr_old is getting narrower:

397b1 --vbr-old: 11.0x

It varies slightly on different music.


edit: When I ran another sample, I still found the speed drop, but also bigger differences between old and new (which it should be).
397a12 --vbr-new: 17.2x
397b1 --vbr-new: 16.5x

397a12 --vbr-old: 10.2x
397b1 --vbr-old: 10.2x

w00t!

Lets hope for a final soon.

Edit: If --vbr-new is said to produce the same, and in some cases slightly better, results at a faster encoding speed than the standard vbr algorithm, then why is the standard algorithm even included? It makes much more sense to just remove it and set --vbr-new to default, IMO.

Vbr-new will probably NOT be defaulted in 3.97. While this vbr mode itself seems fine, defaulting it is not tested enough and would require differing release.

As it has been a long time since last release, and as 3.97 should bring significant improvements compared to previous release, it is released but featuring the legacy vbr mode as default.

I think --vbr-new should be recommended in the new "Recommended Settings" thread, so people start using it and report failure/problem cases.

Is it now "safe" to use 3.97b1 instead of 3.96.1?

the newer vbr code hasn't changed for quite some time, so there should be no speed decrease. what exactly is your commandline at full length?

Sorry, guys, I had compiled using the stock options rather than those that I normally use. I've recompiled and uploaded again. The speed should now be as before.

What about this issue?
http://www.hydrogenaudio.org/forums/index....topic=37003&hl=

No change.

There will always been samples that certain encoders or encoder switches will not be able to cope with in comparison to other encoders or similar switches. Whilst it is an interesting sample and one that should be looked at, there seems to have been more positive feedback on --vbr-new than negative.

I believe this issue can be corrected.

when using --vbr-new the -q switch produces exact same results, no matter if i use q0,q1,q2,q3 or q4. is that intended?

-andy-

Should we start thinking about doing large-scale sample/regression testing of 3.97 --vbr-new against 3.90.3, towards making it the recommended encoder? I'm a little leery of just calling it done just yet, given the extremely high standard of testing that is previously established.

based on the tests that have already been conducted, it has already been decided that when 3.97 stable is out, it will become the new recommended version.

http://www.hydrogenaudio.org/forums/index....ndpost&p=289316

I had a serious issue with the lame ACM from the 3.97b1 compile from RareWares. After installing it EAC, the software with my Bluethoot device and some other programs could no longer be opened. I got "Access violation" messages and such. When reverting to the 3.96.1 Lame ACM, all those issues was resolved. (Using XP sp2, BTW.)

I had the same issue with lameACM. EAC won't start but i got an error message with an "access violation".
But i deinstalled lameACM because i don't need it anymore
I only used lameACM for filmsoundtrack in the past, but i changed to mp4 or mkv and use other audioformats instead of lame now.
The main-thing is that the lame.exe works great and gives excellent results.

But i have another question:
I didn't followed the hole development of 3.97alphas.
Now i wanted to test all the properties of lame397b1 like i did with 3.96.1.
In 3.96.1 there were ATH-Settings available. Now in the 3.97b1 it doesn't take any effect, when playing with this settings. Are they removed?

Regarding the ACM interface:
Source code did not changed between a12 and beta, but some people are reporting crashes with beta while a12 was working.
Some of those people downloaded the binaries from Rarewares, so the question is:
Is the compiled beta ACM available on Rarewares using the same compiler switches are the previously available a12?

Is it possible, that there will be a Mac-Version of this beta?
Would be very nice
I've found a Mac-Version of alpha11, very comfortable in combination with iTunes and Synergy (automatic coversearch).

Hmmm, I don't know what happened with the previous build, but I've rebuilt the ACM and I think it's OK now. I've uploaded again to Rarewares and added a note to the narrative indicating that it's only the ACM that's changed.

Hey john33, may I suggest making a fresh version of LamedropXPd based on you-know-what?

You may, indeed!! I'll get right on it.

Thanks a lot john33, now i can finally show my friends, who can't be bothered with commandline settings, how good the new lame 3.97 is

Now available at Rarewares. The version I've posted is the one with the revised encoder dialogue interface.

The Developer Tools come free with Mac OS X, and can also be downloaded (http://connect.apple.com), and you only need to type 3 simple lines in the Terminal to build and install LAME. A quick reference to this is available with the iTunes-LAME software. It's even easier now with the beta, because there's a source code file download on LAME's sourceforge page, instead of just pulling from cvs.

I'm not sure I understand the scale of 10-100 for the encoder dialogue, how does it correctly correspond to the new presets, such as -V0. Also, please explain what the encoding engine quality does. Thanks for the update to LameDrop, always handy.

After encoding using the newly posted LameDrop for 3.97b1, encspot & audio identifier show the lame version as 3.96r. Not sure what causes this, when I encode using speeks front end I get the proper version tag for 3.97b1.

Hmmm, I don't quite know how that happened, but I've recompiled and uploaded again and it now reads '3.97b', as it should. Thanks for reporting this, BTW.

http://lame.sourceforge.net/lame_ui_example.html

Just curious as to why EncSpot report lowpass filter at 18600 for -v 2 --vbr-new?

This is because for -V 2, the old -preset standard, the vbr quality is set to 2 and this in turn sets a lowpass of 18600. It has been this way for some time.

OK. Thank you john!

Yay, thanks John!

By the way, bitrate corresponding table is a bit, well, misleading in LamedropXPd v.2: while quality 70 is a perfect 176 kbps, quality 60 is more like 144 (150 kbps, to be more precise) and 40 is almost perfect 128 kbps. That is because of -Y switch that gives a massive boost to bitrate starting with -V3, so the progression is non-linear here.
Well, it's not a bug, nor a serious issue… just a minor note.

Always a difficult one, this, as it does very much depend upon the material used. However, if one can generalise, I think that it should be revised as follows:

Anyone else have a view on this?