where can i get the official LAME 3.90.3 source to build my own compile on Linux?

there are no sources on http://mp3dev.org for this version and those on the rarewares site are don't compile on my system (SuSE 8.2).

thank you
BadHorsie

Ask Dibrom?

http://rarewares.hydrogenaudio.org/files/l...modifiedsrc.zip
(slightly modified, but it doesn't matter)

/EDIT\ I'll see if I can compile these on my Gentoo GNU/Linux.
(Glibc-2.3.2, GCC-3.2.3 with propolice&other patches) /EDIT\

Here.



Edit: Sorry, that link is for LAME 3.90.1

Eeh, I don't think you can download 3.90.3 source from there..

this one don't work! it looks like the sources are completely modified under windows. all linebreaks are in windows format. i tried to fix them, but with no success. nearly all shell scripts are broken.

BadHorsie

You know, that's why they're called 'modified', sorry.

http://rarewares.hydrogenaudio.org/files/l...e-3.90.3src.zip
Try the one above (don't know if you have to apply it to 3.90.1 or 3.90.2...)

no!

it is strange that you guys link to precompiled windows binaries but not to Linux binaries or the sources in the sticky threads. since the recommended LAME version for the --alt-presets are 3.90.3, this version should be available for all supported platforms. not only for wintendo.

BadHorsie

this one's only 20kb! it lookes like only the patches for the -Z switch.

but thanks for your help.

BadHorsie

i have send Dibrom a short PM. maybe he know's what to do

but i would suggest that the sticky threads would be modified and the sources are added to the compiles. at least LAME are not an MP3 encoder but rather "an educational tool to be used for learning about MP3 encoding"

BadHorsie

I made the changes to 3.90.2 to produce 3.90.3 using win2k/XP systems using MSVC6/Intel4.5. I don't use Linux nor do I use GCC (usually) so, if any of this is broken from a Linux perspective, I'm sorry, but I have no way of dealing with it.

"dos2unix" usually does DOS text file convesions to UNIX files.

Yes it does. And then adding presets* to the correct makefile in all the right places (BTW, I have now learned to hate automake) will get it to compile. But then it segfaults immediately, apparently during command line processing. At that point I gave up

That was last week... maybe I'll try again.

--John

what about the 3.90.2 sources?

BadHorsie

3.90.x series doesn't compile on GCC 3.x AFAIK. This is one of the fixes added in 3.92 or 3.93 I believe. You should be able to compile it with gcc 2.95.3.

Found it at http://homepage.ntlworld.com/jfe1205/lame-...-3.90.2.tar.bz2. Still had to run everything through fromdos and make a few files executable (configure, configure.sub, and ltconfig IIRC), but I was able to get it compiled and working.

--John

With GCC 3.x?

So you can just patch it up to 3.90.3 easily,
but the difference is very small - search for -Z switch.

I'll try to compile it later today. (it's half past midnight here right now)

No, I used gcc 2.95.4.

I'm going to try applying the 3.90.3 patch next. But I'm not going to spend a whole lot of time if it doesn't work--3.90.2 ought to be good enough for me.

--John

I'll try to compile 3.90.3 with patched GCC 3.2.3 anyway.
(or maybe I'll dig up the fixes in CVS and port them back)

ChangeLog entry for 3.92:

Might be not necessary with GCC 3.2.3 (bug with -O3 and -funroll-loops combined)

ChangeLog entry for 3.93:

These fixes should be easy to port back to 3.90.x

The most important fix is #including <stdint.h> header in places which use *int*_t types.
Of course safeguarded with #ifdef HAVE_STDINT_H
There were also configure.in and config.h.in fixes.

There is a nice patch by ALeidinger in the mailing list archives. I'll try it.

If all else fails, I'll just install GCC 2.95.x

I patched 3.90.2 --> 3.90.3 with no difficulty. I've uploaded the binary here and a linux-friendly source tarball here.

I still don't know why the 3.90.3modified was giving me so many problems, but I can live with 3.90.3.

--John

... i compiled the sources with gcc 3.3. no errors so far. nice job, thank you.

"make test" shows me 434. is this "good enough" for daily use?

thx for the sources
BadHorsie

This means that your LAME doesn't return files identical to reference.
Try to ABX file testcase.new.mp3 vs testcase.mp3

Would you like these to be added to the Rarewares MP3 page?

... hm ok. abx for Linux?

BadHorsie

abx: look into the misc folder from LAME tarball.

BadHorsie

Use it like this:

abxtest "mpg123 testcase.new.mp3" "mpg123 testcase.mp3"

This script only launches proper commands!

Sure, that would be good.

--John

Done.

Just like to add that the Linux source code for 3.90.3 compiles just fine on Mac OS X. I downloaded the source for Linux from rarewares and ran the typical ./configure, make, sudo make install commands. I got an error the first time I ran ./configure and had to remove the config.cache file for it to run properly.

thx, i will give it these days a try. i have to install mpg123 first.

BadHorsie

Better use mpg321. It has more features and plays MP2 files too.

ok,

i've compiled the 3.90.3 sources again and did a "make test". result was 434 again. then i ABXed testcase vs. testcase.new. results was 9/16 (56%). thx to AstralStorm.

BTW: how to compile the sources optimised for my CPU? i read something about the -march switch. but i don't know how to use them. must i use them as a parameter for the configure script? or must i change the make file?

thx so far
BadHorsie

So, you've failed the ABX test, so probably this LAME compile is good enough to use.
Did you use -ffast-math? This might explain differences...
(try it with -ffloat-store to keep speed gain and switch back to 64bit doubles)
I'll try compiling it with GCC 3.2.3 & Glibc 2.3.2 + some custom (quite safe) optimizations.
(not today, because I'm going to buy a new soundcard
and will spend most of my time revelling in good sound)

no switches used. just ./configure, make install.

thx and have fun with your new sound card

BadHorsie

well, to optimize the compilation normally you have to set the CFLAGS using this command:
set CFLAGS="-march=athlon-xp -O3 -mmmx -msse -m3dnow -mfpmath=sse"
etc. (if your cpu is athlon, apparently).
However,the makefile sometimes provides its own CFLAGS,so you must edit it and enter yours if this is the case.

btw,if you notice any difference after and between optimizing the lame compilation, spit it out, I'm curious

Damn, the soundcard didn't arrive! They've said that the transport ougth to arrive today,
but has stopped at another town and will arrive in Tuesday.
BTW the new soundcard is Terratec Aureon 7.1 - costs here 342 zl (around 90$)
I think I'll notice major difference between it and SB Live! Value from 1996.

On the other hand, I might find time to tinker with the sources today.
I'll post my findings here. (and Gentoo Portage ebuild)
The binary produced by the ebuild will have name lame-dibrom - what do you think about it?


el00343, your flags are suboptimal - especially -mfpmath=sse, which slows down on Athlons.
You should rather use -mfpmatch=sse,387, but I found it to be unstable.
3dnow and mmx are already turned on by the 'march'. You should add -pipe to speed up compilation at no cost.

-fomit-frame-pointer, -maccumulate-outgoing-args (which is turned on by 'march' with GCC 3.3),
-fsched-spec-load, -fprefetch-loop-arrays, -funroll-loops are also good and safe.
-ffast-math is also believed to be safe,
but if you don't want to have excess double type precision (80-bit),
you need to use -ffloat-store, which makes code slightly slower,
but still faster than one without -ffast-math. LAME before 3.93 expected 64-bit doubles.
I prefer not to use inlining - it tends to make problems in some of the packages
(-O3 implies it) and instead use -O2 -frename-registers, which is -O3 without -finline-functions

/EDIT\
My CFLAGS = '-march=athlon-xp -O2 -pipe -fomit-frame-pointer -frename-registers -ffast-math -funroll-loops -fforce-addr -fsched-spec-load -fprefetch-loop-arrays -maccumulate-outgoing-args -fPIC -fstack-protector'

I use -fPIC to increase efficiency of GRSecurity and -fstack-protector because I have propolice-patched GCC.
It makes code invulnerable to stack-smashing attacks, but doesn't work on few packages (kernel included).
There exists a kernel supporting stack protection, but I don't use it, because it has too little features.

I have whole Gentoo GNU/Linux system compiled with these flags, it is stable and FAST.
Of course few packages filter out things (especially Glibc, which strips flags just to '-march=athlon-xp -O2 -pipe -fprefetch-loop-arrays -fPIC -maccumulate-outgoing-args -fstack-protector'
It uses kernel 2.4.21-pfeifer-r1_pre1 - Gentoo beta kernel patchset.
\EDIT/

oh my...

this whole optimisation stuff hurts me

i need three different compiles. i have a PIII 533MHz, a P4 2000MHz and a AthlonXP 1800+ 1500MHz. quality is more imortant then speed for me. but my own compile (without optimisations) reaches 0.9...x and Vectors i686 compile reaches 1.6...x for example. so a little bit tuning should be useful i think.

so how should the switches look like?

BadHorsie

do you have NASM installed ?

yes. nasm 0.98.35

BadHorsie

I have compiled LAME 3.90.3 today with optimization options above.
Got 36 samples different in 'make test' with -ffloat-store. 39 without it.

All files compressed only with --alt-preset standard.

My specs: Athlon-XP 1700+, 256 MB DDR 266, overclocked system bus to 140.
HDD isn't important, because the files were in the cache.
(I've made one additional run before taking the results)

My optimized LAME (Linux) with -ffloat-store log:


My optimized LAME (Linux) without -ffloat-store log:


LAME stable bundle from RareWares (Windows) log:


Foobar2000 0.7b3 bit comparision result between test1 and test2:


The files compressed by both of my compiles do not differ.

As to the switches, you only need to change -march option
DON'T USE -march=pentium4 with GCC <3.3, it's broken!
You may want to add -mfpmath=sse for Pentium >=III, because it is faster for these processors.

/EDIT\ MAJOR update. \EDIT/

... me too.

the config.cache file should be removed from the tarball at the rarewares site. otherwise lame will compile with no nasm support when just run "./configure && make && make install".

BadHorsie

i did another compile session:

my sys: Pentium III 533 MHz on SuSE Linux 8.2 with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux)

first i removed the file config.cache from the unpacked tarball. then i compiled different versions using

set CFLAGS="XXX"
./configure --enable-nasm
make
su (Password)
make install

for each version i made a "make test" and encoded System Of A Down - Aerials with --alt-preset standard.

-------------------------------------------------

CFLAGS="-march=pentium3"

make test:



lame --alt-preset standard tmp.wav aerials.mp3:



CFLAGS="-march=pentium3 -mfpmath=sse"

make test:



lame --alt-preset standard tmp.wav aerials.mp3:



CFLAGS="-march=i686"

make test:



lame --alt-preset standard tmp.wav aerials.mp3:



CFLAGS="-march=i686 -mfpmath=sse"

make test:



lame --alt-preset standard tmp.wav aerials.mp3:



the -march=i686 without the -mfpmath=sse switch was the fastest compile on this song. are there other switches to play with or should i stay with this compile?

BadHorsie

1. You can try --mfpmath=sse,fpu with >GCC 3.2.2 (I've found it isn't unstable).
2. Did you do at least three runs with an encoder before testing? If not, the results might be flawed
3. That GCC 3.3 is an OLD, PRERELEASE version... buggy as hell! Try GCC 3.2.3 or GCC 3.3 release.
4. I will soon add the version of my compiler.

/EDIT\
gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)
\EDIT/