A new stable release, a new P4 build from your Intel-loving friends at NebobCo.

Lame 3.93

Or, if you're the paranoid type, Lame 3.92 is still available.

In my tests, the new release is 44% faster than the old. The same optimization options were used for both, and these are still, as far as I know, the fastest P4 binaries available.

Enjoy!

Edit: You may also need libmmd.dll

Big Fat Disclaimer: According to Dibrom bellow, fftsse.nas and fftfpu.nas will steal your girlfriend, kill your dog, fry your computer then make off with all your money giggling like L. Ron Hubbard on crack. Use this build at your own risk. <ominous organ music>

are there any builds for pentium 3? how would i find them?

I tried using both versions of lame 3.93 on my p4 1600 MHz encoding KMFDM - mercy, track 5 on the symbols cd and here are the results between the two:

lame 3.93 w/ optimizations: avg bitrate - 129k/bit filesize 4,711kb length 4:59
lame 3.93 w/out optimizations : avg bitrate 148k/bit filesize 5,406k length 4:59 etc...

why the huge difference in filesize and bitrate when i use identical options? I have a p4 so the optimizations should work w/ speed but do they make that much a difference in bitrate too, or is there a drop in quality when I use this v3.93 optimized, vs. the unoptimized version?

-Jeff

This is strange... what exactly are the optimization flags being used? File size differences like this are kind of suspect IMO. I wouldn't really trust using something with such a variance in bitrate without proper listening tests.

OT:

frozenspeed, you wouldn't happen to have gotten that avatar from the pre-installed avatar section would you? Unfortunately, I forgot to change something when I uploaded the new software.. that avatar was originally Jon Ingrams IIRC....

I did get the avatar from the pre-installed list, at random it was the first one i picked. More on topic though...

Yes, this filesize is quite different and I'd like to see the compiler command line used for this compile of lame too because it is such a huge difference... If anyone can elaborate or explain please do...

-Jeff

Ok.. well this is my fault, I fixed the problem. At any rate, you might want to ask Jon Ingram if he minds (these were not supposed to be publically selectable).. sorry about all this confusion.



I suspect that part of the issue is probably related to a flag affecting rounding precision of some sort. Anyway, I simply wouldn't recommend using this until there is further testing. Unfortunately, I don't have a P4 available to me atm or I'd do some testing of my own.

As for optimized builds in general, the compile I posted should be pretty fast.. I wouldn't imagine this compile would be too much faster (I'm already using ICL with vectorization, etc). Could we maybe see some benchmarks or something?

Test track: 27:19, lame 3.93

Mitiok time taken: 341s
Nebob time taken: 275s
=================
Difference: +19.35%

Mitiok bitrate: 184kb/s
Nebob bitrate: 195kb/s
================
Difference: +5.64%

Compiler: Intel C++ 6.0.1.305
Options: /O3 /G7 /QxW /Qwp_ipo /Qrcd /Qsox- /MD
Source modifications: Added linkage for fftsse.nas and fftfpu.nas. These are not linked by default.
Notes: Yes, I am aware that /Qrcd is an evil baby-eating compiler flag in league with the scientologists. I can't tell the any difference between the two encodes above, but hey, it's a free country, use what you want.

I'd love to use a compiled version that would produce smaller, more efficient files but I am not versed enough in the c/c++ world of compilers to know what this command line will or will not do to a proggie such as lame. I will have to perform some listening tests to confirm this =)

-Jeff

Hrmm... well I've used /qrcd in 3.90.2, so that's not so much the problem. I thought perhaps maybe you were using some other flags also. I think the real issue is the fftsse.nas. I'm pretty sure this was never enabled for a reason... (as in, it hasn't been tested, or it doesn't work properly, or it's lower quality). I'm wanting to think that I remember a discussion about it on the lame-dev a long time ago, but I'm not sure.

At any rate, I think it's always a little dangerous to simply enable options which drastically change output without really having tested them. It's great that you've provided this build for people and everything, but you might want to put a big fat disclaimer on it.

/qrcd, while it changes the output, doesn't seem to cause problems (I've tested this very extensively), and it doesn't seem to change the output *that* significantly -- the most I've ever seen is really 5-10kbps difference. The fftsse code is a different story entirely though.. a 10-19kbps difference (just on these two samples) is a little worrisome, especially when it involves code which is probably not enabled for a reason.

fftsse.nas and fftfpu.nas should not be used.

Yes , they are faster. But the result is different from the expected result. They are from Gogo, and were never ready to be included into Lame.

And You don't use -Qrcd. This is FAQ.

Dibrom would you please drop the 3.93 compile you made in the http://static.hydrogenaudio.org/extra/LAME/ directory?

Thanks
David

Sorry, but no.

I don't recommend using the 3.93 version of LAME so it wouldn't make sense for me to distribute it on HA.

Oh fine. If you have to be quality oriented and all. Rev 3.90.2 is serving me well. I am suffering from update fever. I really want to hear Tak's work once it is 'blessed.'

Thanks,
David

Takehiro's new changes aren't in 3.93 anyway. There are really no significant quality improvements with this release. As mentioned elsewhere, the whole point of it's release is that it fixed some obscure bug that hardly ever happens. On the other hand, it broke the fast presets (and who knows what else).

If you want to hear Takehiro's new work, then download the 3.94 alpha 2 release I have here. Not only is it higher quality than the standard 3.93 release, but it's much more significantly tested. This is part of the reason I have issues with the 3.93 release btw -- that it fixes an obscure bug yet breaks widely used presets (I don't exactly think of that as progress btw, and certainly not "release" worthy), and it's not tested properly. 3.94 doesn't have issues on any of these points. There was however discussion of some bug in the 3.94 alpha 2 build for cbr encoding or something, so I'd only recommend using the alt-preset vbr modes with it...

I would like to have the full command line for ICL. I downloaded the 30 day trial of ICL 7.0 and want to build a few on my own. A starting point would be helpful. I pulled down the 3.90.2 plain and regular. Thanks.

David

OT discussion of avatars split to the off-topic section..

3.93.1

Nebob: What kind of P4 improvements do you show without the files from gogo linked? Is it still anywhere near 44%?

The 44% figure refers to the difference between 3.92 and 3.93. The difference between 3.93.1 generic and 3.93.1 P4 is about 20%. When the gogo FFTs are not linked, this becomes negligible (less than 3%) so you may as well use Mitiok.

You are right, 3% i'm test my own P4 / ICL7 compile and compare it with compile from mitiok.

and what keys are you using to compile Lame for P4 without gogo FFTs ???

i'm try with this one /O3 /G7 /QxW /QaxiMK