lame 3.94b is available

Changelog
Download Source

notes:
This new beta is including better quality using default modes.
Lame is now using presets by default.
Speed of presets is now improved compared to previous versions.

I encourage all HA users to test this version so one of the next ones can become the recommended version.

This especially goes out to all the people who helped during the original --alt-preset tuning and know what samples are helpful/critical (any comment on this is appretiated).

dev0

Good to see a new public release again.

Will there be a new .dll version that supports the presets as default as well?

Is the ACM going to work?

The binary at rarewares it's the alpha 16 version (it's was compiled in 10-12-2003) only changes the filename. ¿?¿?¿?

Okay, better wait for someone to provide proper compiles before starting testing.

dev0

John33,

Would you please grace us with an ICL compile and post it.
Short of Dibrom, I trust you the most to be thorough.

Thank you

Ooops!! Really sorry about that. It's updated now.

And it's 50% faster than 3.93.1 at encoding APS!!!!!

Having a listen now...

I'm comparing against FLAC originals )

Damn tricky this Bjork stuff...is it meant to sound like this oh yeah it's Vespertine!

is it just me or has preset medium disappeared again... change log doesn't mention it but I can't find it...

Heh, I don't know if an artist like Bjork would be the ideal sample for testing codecs, with all the fuzz and such a lovely voice. I also noticed that the encoding was much faster than the reccomended 3.90.3 using the APS switch. I'm fairly new to the audio scene and ABXing and such, but this version seems promising. Hopefully more people can test, tweak and make a new standard for LAME.

I think it is a bug in lame 3.94 beta (it was in alpha 16 too, at least). In VBR mode (-V 0 to -V 9), with a mono source (or with -a switch) the output file it's always at a poor 32kbits/second rate.

Oops, I noticed that I used the "wrong" 3.94 beta (in fact alpha 16). I'm downloading the "new" one. Let's see...

Yep, the bug is right there, in 3.94 b.

If you will notice tuning was done to the presets. This includes preset standard. If I am not mistaken we have an all new alt preset standard.

Is this replay gain information actually applied?

Quoting the changlog:

Does that mean that lame calculates the replay gain value by itself?

From the Replay gain website:

Is replay gain turned on by default, or do I have to use a switch?
Is the default value 89db as other tools use this value as well?
or is the line from the lame project page misleading and only the tag is there to store replay gain info?

Yes.



If you didn't use a specific command for it, then I would assume yes.



Should be.



It states that it computes it, so one would assume then that the event of tagging it would be using the info it had just computed.

I guess you are looking for an official word on this. I'm sure it will come. Hope this helps though.

Slightly OT: Anybody interested in compiling a 3.94b binary for OS X? I really have no experience with XCode or compiling period, and my feeble attempts haven't yielded anything that runs. Guess that's why I am studying to be a clinician, not a programmer

If anybody is interested in doing this, make sure to set your CFLAG option to "-O3 -faltivec -mcpu=G4"....it results in a sizable speed increase on G4's, from what I have read on other boards. Blacktree's iTunes LAME uses this optimization, and it results in speed increases of 1-2x.

Thanks in advance, should anybody have the time to do this!

I didn't use any switches for replay gain. I used -aps. How can I turn this off?

Also if I select "file info" in fb2k it doesn't show any rg info.

The RG entry in the lame header is very new. I know that Gabriel asked the author of the LameTag tool to read this value rom the lame tag, too. so I guess that foobar doesn't read this value YET, because it is new in the lame header!

Edit: I think that it is a good decision to use the presets the Radio RG as defaults, cause there are less probabilities for newbies to mess up their MP3s.

Why do you need to turn it off? All it does is write som info in the lame tag. It wont change your files.
If you have a player that supports reading this info it is good to have the info there. If not then it makes no difference...

From the changelog for 3.93:


alt-preset == preset. standard == -V2 --vbr-old. That's not to say that alt-preset/preset tunings weren't merged into the different -V levels.

I would want to turn it off because I don't want Fur Elise to be as loud as Symphony #5.

Symphony #5: -6.7db
Fur Elise: +6.3db

IF I use replay gain I use Album and not Radio gain.

I don't want to side track this thread with something so minor. I just wanted to ask about it. I only use MP3 on my portable and it doesn't support rg anywayz.

Then it won't matter to you at all. Actually since no program currently reads the new replaygain info in the LAME tag this shouldn't matter right now anyway. Once applications start supporting this you should be able to simply turn replaygain off in that application.

how much do you guys think it's gonna take for LAME 3.94 to be a final vers?

hmm. proven better sound quality than 3.90, I guess, MADXvid

Use question: I currently transcode (typically from Musepack, at Q6+) to -aps -Y for portable use. I'm going to switch to 3.94, seeing as how I don't require archival-quality. What would be equivalent to -aps -Y in 3.94? -preset standard -Y? Should the filesize/quality be about the same? Or is there no -Y option?

Edit: Furthermore, would feedback at that setting be useful? Or should I drop the -Y altogether and just test standard?

Try --preset medium.

I'lll quote a message from lame-dev:

You don't need XCode to compile lame, in the lame source code directory in the Terminal, just type


Also, currently -faltivec and -mcpu=G4/G5 don't really do much for lame, because gcc doesn't auto-vectorize (yet ). Maybe some extra gains from different register usage between models, but I don't think there's any difference. The reason people have seen increases of '2x' speed is because they were comparing it to the fink version, which is half as fast as it should be if compiled in the way above.

As a side note I remember reading Ars Technica had vectorized code working in lame (for the dcts I think) and this is where the true speedup lies.

Thanks for the advice....it's been very helpful. I'm going to take a look at Apple's developer website, as suggested to me by Dibrom. I'm still quite uncomfortable in UNIX, so this will be a learning experience for me :-) I hope to eventually learn enough to start building some audio-related Carbon apps, but that won't be for a while, at this rate!

One particular entry in the LAME 3.94 change log caught my attention...

• removed Vorbis support

Since when did LAME support Ogg Vorbis?

It supported Vorbis input (transcoding) for a while as a compile time option.

xcLAME is a compile featuring this option.

@John33

Can you please post a version LAME 3.94 Beta 1 Modified and with APE & Cuesheet support on your rarewares site please?

@Other people, will this version be tested properly and announced as the new Hydrogenaudio Supported version?

Cheers and Merry Xmas,
Burgerings

If you help providing enough test results to prove it's as good or better than 3.90.3 it will, otherwise it won't.
I will try to set up some sort of coordinated testing later today, so results can be posted at one central place.

dev0

ACM codec still doesn't work (crashes with AV on address FF000011 or so)

BTW, I tried a codec that did work, the 3.92 version, but it's useless as well, since it will only encode and nothing wants to decode whatever the lame ACM encoded.

I will, but only if I'm reasonably assured that there are likely to be very few changes to the contents of the 'frontend' dir. The reason for saying this is that this is fairly significant editing exercise that I don't want to be repeating on a regular basis.

If the 'frontend' dir is pretty much stable, I'll do it, but not otherwise.

I don't think APE/CUE support should be added to a beta version, which is primarily ment for testing.

dev0

I have to agree, really. I'll wait for a stable release.

OK, testing ... but how?

Starting with some difficult test-samples? Compare 3.94b against 3.90.3 or against wav or both? Which quality-settings? Maybe ABR128, apm, aps, ape, api?
Regarding an upcoming 4.0, does an extensive testing of 3.94b makes sense?

I think there should be an advice what testing makes sense, to get the community involved a little better.

A bit OT here.

I have tried building LAME 3.94 beta with MinGW (GCC 3.3.1) and NASM. The speed, although not as fast as the ICL compile by John33, is quite good. On an Athlon XP 1800+, ICL build runs at about 6x while GCC build (-mcpu=athlon-xp -march=athlon-xp -mfpmath=sse -msse -m3dnow) runs at about 5.48x when encoding with --APS.

edit: typo

What about the issue with spreading function discussed by jianxin yan? Did it end up as a bug or he was wrong? If it was a bug indeed, is it fixed in this beta release?

I think this is the explanation.

I tested a bit the new version of lame this morning. I encode a metal song (Matos/Paeth - Blowing Away) in the new lame version (3.94b1) and the most populars versions (3.90.3 and 3.93.1). I just make the test with theses parameters: -b 192 -mj -q 5 (medium quality, good speed for my slow machine ) and --alt-preset standard. These was the results that I obtained in my old pentium 2 350 :S.

test -b 192 -mj -q 5

lame 3.90.3 - 1 min
lame 3.93.1 - 1:03 min
lame 3.94 beta 1 - 1:41 min

test --alt-preset standard

lame 3.90.3 - 2:57 min - 239 kbps average
lame 3.93.1 - 3:40 min - 237 kbps average
lame 3.94 beta 1 - 2:41 min - 206 kbps average

In CBR the new version is more slow, I think that the lame developers remap the -q settings and activated by default settings that not are activated in previus versions. With EncSpot I notice these differences:

test -b 192 -mj -q 5

Lowpass filter - 19300 (3.93.1) - 19500 (3.94b1)
Psycho-acoustic model - gpsycho (3.93.1) - nspsytune (3.94b1)
Safe Joint Stereo - No (3.93.1) - Yes (3.94b1)
ATH Type - 2 (3.93.1) - 4 (3.94b1)

test --alt-preset standard

Quality - 78 (3.90.3) - 77 (3.94b1)
Minimum Bitrate - 128 (3.90.3) - 96 (3.94b1)

Are these good or bad changes? I don't notice the difference between the aps test :S. In the cbr test the quality in 3.94b1 seems a little better, but to coast of the speed. If the quality of the files created with aps are to the level of the version 3.90.3, I believe that one could become the favorite version of lame, it's faster and use less bitrate .

dunno if this will be of any help but i just did a quick test with castanets and i was able to abx 12/12 from the original sample but i couldn't from the 3.90.3 encoded version (7/16), both encoded with --alt-preset standard

this is the info for 3.94:
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
253/255 (99%)| 0:03/ 0:03| 0:03/ 0:03| 1.8696x| 0:00
32 [ 3] ***
96 [ 2] **
112 [ 1] *
128 [ 11] %%*********
160 [ 38] %%%%%*******************************
192 [ 70] %*****************************************************************
224 [ 70] ******************************************************************
256 [ 41] ***************************************
320 [ 20] %%*****************
average: 210.6 kbps LR: 10 (3.906%) MS: 246 (96.09%)

and this is the info for 3.90.3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
253/256 (99%)| 0:03/ 0:03| 0:03/ 0:03| 1.7055x| 0:00
32 [ 3] ***
128 [ 7] *****
160 [ 63] %%%%%***************************************
192 [ 95] %%%%**************************************************************
224 [ 27] %%%****************
256 [ 24] *****************
320 [ 37] **************************
average: 208.4 kbps LR: 15 (5.859%) MS: 241 (94.14%)

It's odd, in my test the bitrate used in the 3.94b1 it's a lower than in 3.90.3, but in your test lame 3.94b1 have a higher bitrate :S

yeah, i thought it was strange too since 3.94 even uses 96 and 112 br, but castanets is a very short sample, more accurate results will come from encoding regular length songs like yours for example

When I talked about testing, I was thinking about ABX and maybe ABC/HR tests and using either known samples or at least posting the ones you used. "Tests" comparing bitrate or filesizes are highly uninteresting in this context.

<edit>
Maybe Gabriel can enlighten us about the changes he has done to the presets and give some instructions in regards of testing them (I already asked about this on lame-dev).
</edit>

dev0

danchr provided a MacOS X build of Lame 3.94 beta. Available here:

http://rarewares.hydrogenaudio.org/files/l...me_394b_osx.zip

He didn't mentioned it, but I guess it has no G4 or G5 optimizations, since danchr is on a G3 himself.

Also, it may only work on OS 10.3

Regards;

Roberto.