As well as the LAME 3.90.3 Stable Bundle on Rarewares there is the 3.90.3 Modified Bundle, which is described as "modified to allow use of --preset as well as --alt-preset, also includes MEDIUM and FAST MEDIUM presets".

I have used lame.exe from the "modified bundle" for a long time because I occasionally use preset medium, and also because in september john33 enhanced this compile so it writes the preset into the lame tag.

Recently I downloaded the "stable bundle" and was surprised to find that the lame.exe compile in there also allows the use of --preset instead of --alt-preset and also includes "preset medium". This surprises me because I thought the whole idea of 3.90.3 stable was for it to be identical to 3.90.2 except it adds -Z. And 3.90.2 does not allow --preset or include preset medium.

So I was just wondering why the modified bundle is described as being modified in this way, if the standard bundle is like this too? What really is the difference between the lame.exe in the stable bundle and the one in the modified bundle? Is it just that the modified one writes the preset to the lame tag?

Sounds strange. Another difference should be that -preset x, where x <80 is enabled.

Hmm.. both the "stable bundle" and the "modified bundle" lame.exe can encode --preset 56, whereas 3.90.2 can't. I hope I haven't got my files mixed up. I don't think so, I downloaded twice to make sure. If I have I'll feel very silly.

The only thing I can guess at is that by mistake the zip file on Rarewares labelled "stable bundle" (which is the one linked as the recommended HA compile) is actually just an old compile of the modified bundle.

Hmmm, I think it's me that screwed up somewhere!!

However, the additional features have absolutely no effect on the encoding quality. I can do a fresh compile of an unmodified 3.90.3 if anyone believes it's worthwhile, but no one is disadvantaged and nothing is compromised as things are currently.

As far as I'm concerned it is not a problem. Just a little confusing. Perhaps the description on the modified bundle should be changed to say "modified to include writing the preset to the LAME tag", so the difference between this and the stable bundle is clearer.

While you're here and reading (presuming you still are), I don't know if you noticed this thread when it was active a couple of weeks ago, but I would appreciate your views. To summarise so you don't have to read through the thread, I found that lame.exe from the modified bundle was handling the following command line differently to lame.exe from the stable bundle. The command line in question is:

lame.exe -b 56 --alt-preset standard ...

I don't think the specific bitrate value or preset are relevant. The difference between the two 3.90.3 compiles is that the stable bundle compile ignores the bitrate setting because it comes before the preset and is therefore overridden by it. It does write the bitrate value into the lame tag (in my view wrongly, but that is another issue) but the audio part of the file is identical to simple --alt-preset standard. The file sizes are the same, the Music CRC in the lame tag is the same. In fact the files are bit identical apart from a few bytes in the lame tag. This is the same behaviour as 3.90.2 (and 3.95.1).

But with the modified bundle compile the audio part of the file is not the same as simple --alt-preset standard. It is also not the same as --alt-preset standard -b 56. Would you be so kind as to look into why this is the case?

You may be wondering why this is an issue. It was highlighted because EAC sticks a "-b nn" setting onto the beginning of the command line if Lame MP3 Encoder is chosen instead of User Defined Encoder. The fact that this makes no difference to the audio means that in the HA FAQ it is suggested that it doesn't matter whether you select User Defined Encoder or not. But with the latest modified bundle unfortunately it does matter.

I can confirm that I can see the problem. I'll look into it and get back to you.

Much appreciated. And thanks for creating these compiles for us in the first place too.

It's taken me a little while to get my head back round this!!

Although I haven't gone down to the level of being able to tell you precisely which setting is causing this, I can tell you why it's occuring. In the modifed version, I attempted to force the use of --preset ABR/CBR when a simple bitrate was selected. In other words, '-b' forces the use of an ABR/CBR preset, so its behavior has been completely changed. I am assuming, therefore, that using '-b 56' ahead of --aps, is setting a switch that is not reversed by --aps. I have to admit that I hadn't considered this consequence. If the consensus is that this should be reversed, I am more than happy to do so.

Oh, I see, that makes sense. I can confirm that modified lame.exe produces an identical file with "-b56 --preset standard" as stable bundle lame.exe does with "--preset 56 --preset standard", apart from the fact that the modified one writes the preset into the lame tag.

My view is that this is undesirable behaviour. For me the modified bundle is an advantage because it adds functionality such as writing the preset. However, I would say this behaviour removes functionality as it doesn't allow the user to choose between using "--preset nn" or "-b nn". And of course there is this unexpected side effect with EAC which might catch a newbie.

I don't care too much from a personal point of view though, as apart from testing purposes I don't use anything except --preset standard and occasionally medium, and I use User Defined Encoder in EAC which overcomes the problem.

OK, I think it makes sense to remove this behavior as it clearly is possible cause for confusion. I'll post when this is done.

Thanks. Would you be happy to make a list of any other differences between the modified and stable bundle versions? Or is it just this behaviour with -b and the preset writing to the lame tag?

Also are there other any differences between what is now the stable bundle and 3.90.2 other than -Z, the medium presets and allowing --preset in place of --alt-preset?

I'll put together a list for the differences for each. From memory, I think your list of differences regarding the stable bundle is complete. The modified version defaults to --preset standard if no other settings are specified.

Revised 3.90.3 Modified compiles now posted at Rarewares. The '-b' behavior is now reversed and consistent with other compiles.

Just for the record, I've recompiled the 3.90.3 Stable bundle such that the only difference between that and 3.90.2 is the addition of the '-Z' switch, as it was originally.

Thanks. I can confirm that the -b behaviour is now as you describe.

Is there any reason why lame.exe in this new compile of the modified bundle is 520 KB in size, when the previous modified bundle lame.exe was only 184 KB, and also the standard bundle lame.exe is 184 KB?

I don't know whether this takes a little while for the file to be updated on Rarewares for some reason, but although the description now says "LAME 3.90.3 stable bundle 2004-02-06", the actual zip file has not changed.

...can't confirm that, i got the right one.

While reading this thread i started to play around with some other modified LAME versions by john33, also not becuase i need it but just that i could recommend it to friends that know almost nothing and dont want to know anything more about audio compression.
[EDIT] ... better: that know almost nothing about audio compression and dont want to know anything more about it.[/EDIT]

So i tried the LAME 3.90.3 dll modified to encode PRESET STANDARD ONLY from the Rarewares page.

I tried to use it within EAC (i've put it in the EAC folder btw) and it works, but unfortunetely not the way it was meant to be.

The settings for the LAME dll that you can adjust in EAC DO have an effect for the final mp3.

I guess it was not meant to be like that, anyone else who tested it and got the same problem? Or is it me again having done something wrong like having downloaded the wrong version or something else stupid?

I've noticed a strange behaviour, the following commandline gives a mix between insane and standard preset:
-b 320 --alt-preset standard
The files are CBR 320 encoded but the lowpass @19kHz and the use of --nspsytune and --nssafejoint make me suspect about something of --alt-presets. I checked with these versions:
- Dibrom's 3.90.2 compile.
- John33's 3.90.2 and 3.90.3 (all the three versions) compiles
- Mitiok's 3.95.1 stable compile
So it should be present even in all the other past 3.9x versions.

Looks like this is a caching issue with my PC. I downloaded it to another PC to check, and got the new version. Back to this PC and download again, and get the old version again. Very annoying... sorry to have caused confusion.

The question about the lame.exe file size in the modified bundle still stands though.

This is already a known issue. See the thread Does EAC add aguments to --alt-preset standard which is linked from the FAQ:



I agree that it is rather unexpected behaviour though.

I clearly forgot, in the rush, to UPX that particular .exe!! I'll fix that. It has no effect other than to reduce the size if the .exe. The UPXed file is decompressed in memory just prior to execution. Except on a very old, slow machine, the time this takes is imperceptible.

Edit: Fixed.