@Bad Monkey

Using Visual C++ Express Edition with the Microsoft Platform SDK

Nmake is one of the executables in PSDK bin directory.

To setup build environment from the command line, call the batch files vcvarsall.bat from Visual Studio and SetEnv.cmd from PSDK. They will set PATH, INCLUDE and LIB environment variables for you.

See if the lowpass filter is filtering higher frequencies than before. This may be one of the reasons for the bitrate inflation.

I for one, am perfectly happy with lame 3.98 and "-V 5" (or even lower than that, as I already mentioned that I can't abx "--resample 44100 -V 7" from the original). I guess that I don't have the golden ears that you guys have.

I'm using the misc/abx tool that I fixed. Oh, and I started committing some cosmetic changes to the repository. In particular, I will take care of some of the expopt=full things, but I don't have access to a MacOS X running Leopard.

My iBook G3 (yes, G3) can only run MacOS X Tiger and I'm switching to Debian (goodbye, Apple) as soon as I can finally debug the rt2500usb driver for PowerPC.


Regards, Rogério Brito.

P.S.: I don't know if this is still the case, or if I am dreaming, but if I pass "--resample 44100" to a "-V 7" encoding process, then the lowpass filter allows higher frequencies to be encoded... I will have to check our sources.

Indeed, it seems that the development will be on the 3.x front for some time. But who cares? Version numbers are not decimal numbers (or numbers in any other base ) in general, at least.

Anyway, we haven't seen messages from Takehiro for the past 6 months or so. A pity, since I planned on doing things with him (as he is a Debian user like me).

And doing a benchmark regarding his hack (like the guy from Intel asked us) on other platforms than Windows would be a good thing... I think that I will have to make things systematic here with many compilations and GCC options.

(BTW, if any Debian/Ubuntu user feels that lame should be a bit faster and you have a recent CPU, I would recommend that you base your own compilations on the switches that I've put on Makefile.unix from the recent CVS trunk---it will quite possibly have some improvements related to what you get if you compile with expopt=full).

Oh, you should have GCC 4.3, as we were discussing on lame-dev that versions from Red Hat may not work correctly with the -ffast-math switch (Robert found a funny case of miscompilation).

Regards, Rogério Brito.




How did you compile it? With the macosx directory present on the sources? I guess that some ia32 code could be improved, depending on the options you've used.

Regards, Rogério Brito.

P.S.: I have not checked your .dmg file since I am on Ubuntu, but do you provide dynamic libraries also? It would be a good thing for those that use audacity to export their files...



A used/old (traditional, not extreme) Apple Airport card for G3 iBooks would be much appreciated. I have problems drinking and coding.


Regards, Rogério Brito.

P.S.: Actually, I'm moderately serious here: if anybody in the US or Europe can get one such a card and send me as a "gift" (so that I don't have problems with customs, like I did for ordering a US$9 "The Gathering" DVD from amazon, when I ordered books on Abstract Algebra), I would be quite grateful.

We can see how I can pay back for the card and shipping (most probably, places like Otherworld computing or www.smalldog.com would have such a card).

I (cross)compiled static binaries in three stages (one for each architecture), which I later merged to one universal binary with 'lipo'.
Just a plain "./configure [flags here] && make" in the source directory. No magic...

Would be interested in improvements which would make it more effective.

Edit: Think I used GCC 4.2.1. Have GCC 4.0.1 installed as well, hence why I am not 100% sure.

libsndfile allows lame to take much more input formats than "bare" lame.

Version 1 of the library (as opposed to version 0, which was available earlier, in lame 3.97 and previous versions) still allow one to grab input from the standard input, while allowing one to take a FLAC file directly as input (just to name one popular format that I know that works) and (this one is particularly important to me, since I record my classes) to take "wav" audio in IMA ADPCM (like those generated by the very popular S1MP3 recorders/players), all without many gymnastics.

The libsndfile1 ability of lame came directly from Erik de Castro Lopo's (the upstream author of libsndfile). That is, from the horse's mouth.

Hope this clarifies a bit, Rogério Brito.

Apple ships their own "instrumented" GCC 4.0.1, which makes it hard to detect the features based on the version alone (grrr...). Anyway, you could try to compile things with (Apple's) options --arch, like "--arch powerpc --arch i386 --arch ppc64". Pass it, in the configure step, as:

CFLAGS="--arch powerpc --arch i386 --arch ppc64" ./configure && make

It should work. If not, please, file a bugreport on our tracker. But using "lipo" is fine also. Just thought you would like to know about an easier method.

You might want to see what I posted here: My (outdated) diary/blog.

Anyway, it would be worth it to grab the sources from the FSF of GCC 4.3.1 (and of two libraries that are required now) to benefit from some newer features and fixes. Just enable C, if you have a slow machine or if you are impatient.

BTW, I've been crosscompiling kernels for PowerPC with a x86-64 machine, generating a .deb package and everything with a similar recipe.


Regards, Rogério Brito.

Ah, this explains why he mentioned lately that there was a lack of manpower in the lame project (citing that once that the core people working on lame hasn't changed in the last 8--10 years, with Robert doing a lot of work), while he mentioned that some people were getting paid on other Open Source projects like x264... Hummm...

But, actually, he is correct. Lame is next to its limits (Robert can prove me wrong here ), as I see it, while other progeny from the newer MPEG specifications should be improved. And his work on x264 is greatly appreciated (actually, the projects developed/communicated/hosted at mplayerhq.hu are so welcome that I can't even start thanking them). One has got to love the ffmpeg project, for instance.

Regards, Rogério Brito.

Yes, but it only had libsndfile0, while, now, lame has support for libsndfile1, which includes flac files and IMA ADPCM files to be used as input.

The patch was sent by Erik himself about the time of lame 3.98 beta 1, according to our changelog.

Regards, Rogério Brito.

The changelog is valid HTML 4.01 Transitional, soon to be XHTML 1.0 Transitional.


Regards, Rogério.

Thats basically what I did. Add "--arch powerpc" etc. But one architecture at a time, since I had to cross-compile and thought that were the only way. Works like a treat, so guess I stick with it. After all it end up identical...

Will head over to take a look.

Well, I just installed Xcode 3.1 today. With two compilers installed already I stay clear of installing a third one. Its a shame that Apple lay so far behind with their GCC version, but guess they have their reason...

Thanks Robert, that got me along a bit. It's built some libraries, but now failed with an error along the lines of x86 when x64 is needed.

Backing up a bit, in my VC/bin/ dir, there is only a "vcvars32.bat". Running "vcvarsall.bat x64" (as I understand I need to) fails, configuration data unavailable. None of the 64-bit bats exist.
A bit of a look later, and I see this: http://msdn.microsoft.com/en-us/library/hs24szh9.aspx
Does this mean VS Express is incompatible with ICL 64-bit?
Or am I doing something stupid again.

I took a look at the version in the CVS Head (dated 12 July) and have a couple of comments for you:


-ftree-vectorize-version is the default, and might or might not make faster code. It makes some of my code slower, but I couldn't get a significant result either way with LAME.
-mtune=nocona is not needed because -march= implies -mtune
-march=nocona could probably be replaced with -march=native, which would be better for a wider range of people

On x86_64 you can drop -malign-double and -mfpmath=sse because these are default.

Thanks again for the development effort, and good luck with future releases.

Yeah, why in the Hydrogenaudio Knowledgebase the currently recommended LAME version is still 3.97?

Because we should verify first that 3.98 is superior generally and shows no serious regressions over 3.97. What use is the recommendation if it always just indicates the latest stable version? I don't doubt the ability of the devs here, but everyones ears are different, and testing the new recommended version and settings against the old ones in a public listening test is important to ensure it really sounds better for most people.

Lame 3.97 is still the recommended version as 3.98 hasn't been through any public listening tests (or multiple individual tests). People are setting up a public listening test right now. They have narrowed down the list of encoders and settings to use (mainly 128kbps VBR with a variety of mp3 encoders including Lame 3.98) and are now working on the samples that will be used.

Edit: MedO beat me to it.

I remember this discussion when 3.97 was new...

3.98 should be Hydrogenaudio's new recommended MP3 encoder. Every "stable" version should be automatically recommended. Why? Over two years there were many beta versions... all of which were (or at least should have been) tested for improvement and/or regression. A listening test now is nothing more than just a formality. I don't believe that 3.98 would turn out worse than 3.97... and if it did, it could mean just two things: either the developers didn't do a good job (which is of course extremely unlikely), or the community feedback wasn't good enough in those two years in which case any "Hydrogenaudio recommendation" would lose its authority completely.

While the public listening tests are useful, on balance, I have to agree with Raiden. It is certainly true to say that considerable testing has been done via this board over the development period. The 'golden ears' have already done their job!

I totally agree, but in the end this means that there's no use in recommending a Lame version. The latest verison always is considered best. We never know something for sure, especially as we can't have encoder experience with the universe of music, but as long as there's no experience of serious regression (which hopefully would trigger further Lame improvement) just using the latest version is the most promising strategy.

For me, i use 3.98 betas since beta 3 if i´m right. From there on the added noise i disliked from version 3.97 was much improved or gone at high bitrate V values.
One thing is that most 3.98 testing i read over here was done at relative high bitrates. I don´t know how 3.98 behaves on low bitrates. This may be the main unknown atm.

maybe it is time for some changes
a. i wouldn't recommend any particular version
b. just update the thread with recommended usage command line(s)/switches when there is a decently different/newer version out there

I found a track that LAME 3.98 seems to perform better then 3.97 at V2.



At around 0:47 - 0:48, there is a nasty smear on the drums. The track's bitrate is at 237kbps and its still not transparent, and my V0 encode was at 293 and managed to get a 8/10.

I have tested it on 3.98 at V2 (7/10), but sometimes I could hear a "psst" (precho) sound at the same area, but it was harder to notice unlike the 3.97 encode. The bitrate on the 3.98 encode was a tad lower at 234kbps (-3).

This track is a bad example of the sfb21 issue, such as being bloated and not transparent, and one of the main reasons I do not use V0.

Hey Gabriel,

thanks for the x64 build!



Best,

Stevie

Hi
Could someone advise whether to get the very best mp3 quality I should be using -b 320 or v0 with Lame 3.98. Storage space is not an issue for me so the increased file size with CBR is fine, but I want the best quality.

TIA

If space is not an issue, I would recommend going with lossless (FLAC, or similar). That way you can be sure you have no audible artifacts, and you can transcode (for an iPod, for example) at will. I'm not an MP3 hater, but lossy compression only makes sense in situations where space is an issue. Do you have any reason to prefer very large MP3s to lossless?

Why not use a blacklist instead of a whitelist? That is, do not "recommend" a specific version, but instead "unrecommend" significantly suboptimal verions.

Yes, sorry I did not make that clear in my initial post. I want to use the mp3's for my iPod. I already use flac to stream music within the home, but lossless files (flac or aac) are going to limit the amount of music I can get on the iPod.

Rgds

AAC is not lossless, you mean ALAC.

That said, if it's just for the iPod and you don't need the better general compatibility of MP3s, use AAC instead of MP3; for the same quality the files are smaller. Only drawback is the encoder is half the speed of LAME.

Thanks

This is a good idea, i thought about that as well. I updated the Wiki accordingly.

Hi John,
Whenever you get around to updating the "lame_enc.dll modified to use INI File" for 3.98, is there any way you can add more options to what you can specify in the INI file? for example, Mono/JStereo switch, CBR/ABR switch, CBR/ABR bitrate value (and these would be ignored when a LamePreset is used)? I think these additional switches would make the binary more useful to more people. I would appreciate it if you could consider implementing some or all of these switches. Thanks

I have uploaded a sample, that both LAME 3.97 and 3.98 struggle at -V3 and -V2. I got 10/10 with 3.97, since there's a smear at 0:13. The smear seems to have gone on 3.98, but there is a warbling noise on the distorted guitar riff at the start of the track.

Linchpin Sample

Sorry, I've not been ignoring this but I was away when you posted it! I plan to take a look at this over the next week, or so.

There is new version of the modified dll now at the Lame Libraries page at Rarewares. This is a 3.98 ICL10.1 compile and contains much more flexibility than previously. From the new .ini file:

@ john33: Thanks a million!

Thank you very much, John! I was away for a while also, and when I visited HA today, I was amazed how much work you have done for my request! Thank you again!!

I've compiled it long time ago on my G5 myself, but I just tried your universal binary: I get a bus error on my iMac G5 Maybe it's not realy "universal"?

I'm a Linux newbie.

Where and how I can get Lame 3.98 for Ubuntu Linux 8.04 LTS ?

Now it's too early to puzzle with compiling my own stuff from the source code...

You will have to :

- wait for a hardy backport
- wait for intrepid release
- use win32 binary through WINE
- backport source from intrepid , then build a .deb for your release.
- download build-essential & compile the old way ./configure [options] && make && sudo make install

Friend of mine has suggested me to add a custom repository. I've added those mentioned there and there was Lame 3.98 available.

Unfortunately I don't have any idea if I would brake something by that or cause any problems...

Thats the debian repo i use but its not for ubuntu. I think the lame package is okay for you since it won't pull in harmfull stuff - if you want to be safe download the .deb only .

For the benefit of those who have been after a 64 bit compile, I've just tested a 64 bit Intel compile against the standard 32 bit version, as posted on Rarewares. It is important to remember that the 64 bit compile is NOT using the nasm routines as they are incompatible, at least currently. This test was run under WindowsXP Pro x64, the system comprising: e6700 @ 3.2GHz, 4GB OCZ Reaper PC2 6400, Asus P5W-DH De Luxe.

As you can see, although the 64 bit compile comes close, the standard 32 bit compile is still faster. The small encoding discrepancies are inaudible, to my ears at least!

It's also important to bear in mind that the 64 bit compile is using compiler optimisations alone, no code changes have been made other than to exclude the nasm routines from the build.

LAME 3.98.2 source are available on SF.net, dated 2008-09-22.

The following notes are attached to the release:

I've not been at home since late Friday, and I will not be back until later this evening so, sorry about the absence of new builds on Rarewares, but I'll attend to it on my return either later tonight, or tomorrow.

Thank you for your consistent dedication, John. It is much appreciated

A full set of compiles is now on Rarewares.

Thanks

Thnx for the new complies john33

Thank you Mr. John33

Good news!
But history.html (http://lame.cvs.sourceforge.net/*checkout*...RELEASE__3_98_2) still says "LAME 3.98.1 not yet released"

and 3.98.2 is somehow broken. It doesn't compile on OS X. Neither with gcc 3.3 nor with 4.0.1 :