New compiles at Rarewares.

??? You are quite fast, I have not yet released the files on sourceforge

Amazing

ah excellent
that was quick, thanks

The files were picked up under the tag you sent me. 5 hours old? Is that correct?

It is probably ok, but to be on the safe side you should try the package released on sourceforge

OK, just to be sure, downloaded as per above, recompiled and uploaded again.

@John33

John,

What difference is there with your compiles, as opposed to Mitiok's compiles. Just curious. I'm not a developer, so I really don't know. I'm guessing cpu optimizations.

I really don't know what compiler settings he uses, but for 3.95.1, I'm using ICL 7.1 whereas I think Mitiok is using ICL 4.5. ICL 4.5 was certainly relevant for 3.90.x as that was the compiler Dibrom used, but since the composition of the presets is now completely different, it probably makes little, or no, difference. The last time I checked output from the later versions of LAME, ICL 4.5 and 7.1 compiles generated bit identical encodes.

Are the new presets better than Dibrom's?

That's the million dollar question!! Only testing will prove that one way, or the other.

Please keep in mind that they are not completely new. AFAIK Gabriel only changed some small settings like the minimal bitrate. How the other tunings affected the presets is a completely different matter.

dev0

Sorry if this is dumb, but wouldn't it be better to incorporate Dibrom's presets in 3.95.1?

Given the bitrate savings I'm seeing with the bloating fixes, I'll be happy if the quality is considered to be equal.

Guys lame is *the* tool and a huge thanx for that, but I think before naming a version stable ... well it should be stable.
We saw a jump from 3.94 to 3.95 something..., quite soon and this only produces disbelief about the stability, so a lot of people including myself will have second thoughts about using it for a while... well until a version does not pop out for about 5-6 months.
And just out of sheer curiosity, why don’t you provide binaries ? you have to compile the thing to test it correct?
Again thanx for a hugely great tool

Is there a changelog from 3.94 to 3.95?

I think due to patent issues, but don't quote me on that. I heard that providing compiled versions of MP3 encoders requires you to pay some money to Thomson.

It's included in in the zipfile package on Rarewares.

MP3 is a heavily patented technology. Thompson owns the patents and could ask for fees for each mp3 encoder download, though that has never happend so far AFAIK. The lame devs don't want to take chances though, but there are enough people who do. Just take a look at rarewares or google for mitiok+lame.

uhm, yes?! it's included in the docs comming with lame.
here you go:
changes from lame 3.94b to 'stable' 3.95:
Fixed lowpass values when using vbr with mono files
Faster quantization loops
Faster count_bits
Fixed a buffer requirement error in ACM codec
Fixed mpglib and other decoding support code to prevent the crash when invalid mp3 input
Removed Layer I decoding support
Use FastLog and IEEE 754 hack on PowerPC too (approx. 10 percent faster)

edit: ah, indybrett got it first...

How would that make any difference? There are considerable changes to psychoacoustics anyway.

I found this LAME 3.95.1 user review amusing (better look into LAME's lower bitrate handling ):



http://fileforum.betanews.com/detail.php3?fid=955435184

@John33, Can you PLEASE make a "LAME 3.95.1 Modified and with APE & Cuesheet support"
Thanks so much
Burgerings

Bad idea. We'll have 3.95.2 any time now with fixed decoding.

I think you should wait at least a week after the latest version has been released to see if it stabilized.

It would seem that the ACM codec is broken in this version. I'm not sure if it was broken in 3.95.0

The problem is after installing the latest acm codec (via inf file) that when trying to select an audio codec in VirtualDub, it completely crashes giving some error about can't find referenced memory. You can't even see or select any codec at all. If I revert to the previous version I had (3.90.2) everything goes back to normal.

Sorry if this is a known issue, but I couldn't see it in any recent topics.

System: AMD Athlon 3000+, 512MB RAM, WinXP all updates as of yesterday, Audigy 1 latest official drivers and programs.

I just compiled a 3.95.1 binary for MacOS X; if there are any other Macintosh users that are interested in it, feel free to send me a PM.

I send my thanks to all of the LAME developers for another great release! I'll look forward to testing it in the next few days.

can the CLI say so? when you run it it says 3.95, and when 3.95.2 appears, do the same please

if dificult to know what lame.exe are running if not ...

Seconding kwanbis's request, and if that version string could also be present in the data itself - both the 9-byte version string as "LAME3.95." (instead of "LAME3.95 " as it is now - that is trailing period instead of trailing space), and the full "LAME3.95.1" in the padding dump at the end of the file (rather than the plain "LAME3.95" that is there now). Without this it is impossible to differentiate between versions, which is not good.

For those experiencing ACM problems, I strongly believe that this is a compilation issue.

Try http://gabriel.mp3-tech.org/lame and report your results.

So there are binaries after all from the original developers

from --longhelp:

Is the --substep switch disabled ? I get the following error when trying to use it:

I'm using the executable compile hosted at Gabriel's site.

It is only available in debug mode or when using alpha versions. It should be removed from the general help.

Btw it is enabled with q2.

would it be safe to say that this is "Better" than 3.90.3, and is ready for use with -aps?

http://www.hydrogenaudio.org/show.php/showtopic/17499

grab some test samples and help find a decision

Can anyone list the current known issues with encoding -aps with 3.95.1, i want to know if it's safe to release an album or not. edit: I only want to know if there's some huge problem been spotted since release, thanks edit2: and i'm not asking you to sign a liability form for any & all future bugs

there is another thread on HA where 3.95.1 vs 3.90.3 test results are posted.

the non surprising result: some samples are improved, some behave worse. but it seems that nothing is severely broken...

EDIT: BTW, the mentioned thread is http://www.hydrogenaudio.org/forums/index....topic=17499&hl=

Only three persons have been testing yet:

AstralStorm couldn't ABX 3.90.3 vs. 3.95.1 on the velvet sample (aps) between themselves.

Sony666 found 3.95.1 on par or noticably better on some sample/bitrate combinations (fatboy sample, velvet sample) and both nearly equally bad with harpsichord.

ViPER1313 found 3.95.1 to be slightly better with the waiting and fatboy sample (all aps), and 3.90.3 slightly better with preset fast standard (on waiting again). Only the DaFunk sample at 128 kbitps CBR seems to be noticeably worse with 3.95.1 for him (a little surprise for me that a low bitrate CBR would behave worse. I would thought otherwise).

It is difficult to judge which encoder behaves better, but 3.95.1 certainly behaves well so far.

I've been using Ogg Vorbis, so I haven't been keeping up with LAME's development. Am I correct in my belief that there are no longer "alt presets" (as in --alt preset standard)? The help only shows "presets" ( as in --preset standard); it appears the term "alt" has been dropped.

That's right. Alt has been dropped. Now nearly every combination of cbr/abr value or vbr value are stored in some kind of --preset.

amano,
thanks a lot

brainzelda,
wtf? switchs.html from 3.95.1 reads:


yet presets.html reads:


so alt-preset may be depreciated but it still works fine in 3.95.1 right? So --alt-preset standard is exactly equivalent to --preset standard but the former may be dropped in future? right?

yeh, i think they just haven't updated that text.

they actually replaced the former "--presets" with the former "--alt-presets". For compatibillity reasons, they kept the alt-presets as well

So using "--preset x" and "--alt-preset x" will give you the same result now, but only with lame 3.93+ IIRC. This change was done, because the alt-presets are no alternative the formerly existing --presets, but definitely THE switches to use.

I have confirmed that --alt-preset still works in 3.95.1, but lame's --preset help does not mention it. So you can continue using alt if you want, but frankly --preset seems to be coming to power.

Why is --preset cbr 128 still "recommended"?
Can't that be changed to say "--preset standard" instead of "-h", please?

Any chance to see LameDropXPd updated to this new lame version may be with the addition of the Windows Priority feature if possible? Intel 8.0 compiler???


Thank you.

Then the lame team would get complaints like, my MP3 Discman won't play these files, why is the bit-rate so high? why is encoding so slow? I don't hear any difference, hey guys I'm using Xing, it's faster & smaller, let's all use it.

preset standard is not for the average user.

do you really think so? Most people who actually go to the trouble of locating or compiling LAME, and then using it from a command-line, are also probably interested in making quality MP3s. I'd say make --preset standard the recommended, then let people choose CBR if they insist.

Try the post directly above yours

@RyanVM:
What the hell does that have to do with my post? Fixed decoding soon? That won't help the problem. Wait a few weeks for a stable version? If no one tested the latest versions then there would be heaps of bugs in so called "stable" releases.

@Gabriel:
Thankyou Gabriel, the version you suggested works fine. If the versions are the same then I guess it is a compile issue. The version I originally used was from Rarewares.

Yes, it is the same version. I guess it is time to start a new thread.

If the LAME dev team wants to leave --preset cbr 128 as the default for when no parameters are specified, that's probably acceptable (for historical reasons and the reasons you mention). However, if you look under help and it says something about "recommended", implying "better quality than default", then it should have a good-quality commandline in there. Would you recommend --preset cbr 128 to anyone for anything? I didn't think so. --preset 128, --preset medium, --preset standard, etc are all better than CBR128, and when settings are "recommended" they should be better than what is supplied by default, and should be of reasonably good quality.