Do you guys recommend -V5.7 to be used in my test?

This LAME build will work with official pre versions of libsndfile 1.0.18 with FLAC support:

http://www.mega-nerd.com/tmp/?M=D

Direct links - libsndfile-1-0-18pre22a-setup.exe (installer), libsndfile-1.dll (extracted)

Thanks ZinCh!
The strange part of this is the fact that FLAC support is explicitly mentioned in the table
http://www.mega-nerd.com/libsndfile/

I think NO coz there is no possibility to make all participating coders to produce equal resulting bit rates. So the use of real-life settings (resulting in acceptable bit rates) seems to be a reasonable compromise.

Brilliant, thanks. I'll add this to the Rarewares download. I'll do this momentarily as I'm just about to do a lamedropXPd build that should work with this too, but I'll let you know.

OK, I've updated the lame.exe download now compiled to use the libsndfile 1.0.18pre22a dll and I've also added a build of lamedropXPd that works with the same dll and both now accept FLAC files as input and process accordingly.

(Both builds include the new dll.)

Whoa! I've been waiting 3 years for this day! Whoo hoo!

Just downloaded and tested. Finally can drop a FLAC and get a MP3.

One note: On the Encoding Options screen is showing "Using L.A.M.E. v3.98 beta 8 encoding engine"....is this a typo, or is this still using beta 8 and not the final version?

Also - is the Variable Bitrate Mode relevant anymore? Doesn't 3.98 use --vbr-new as default? Wasn't that what this setting changed, the old vs. new VBR mode? I'm assuming Standard is now --vbr-new. Can you clarify?

Lastly - is there anyway to show the -V settings along the slider so we know where along the scale we're locked in on say -V2 -V3 -V4 -V5, etc. I'm finding it impossible to tell where -V4 is so I can compare LameDrop files with the output of foobar. If this can't be done, don't sweat it.

Anyway, thank you so much for getting LameDropXPd to work with FLAC.

Your right, it was a typo! I've fixed that and uploaded again. This version does not accept ogg files for input as it uses libsndfile exclusively for input purposes. If you want to drop ogg files as well, you'll need both versions, but they can share the same ini file and co-exist quite happily.

OK, looks like we still need to toggle "Fast" on Variable Bitrate Mode to get --vbr-new. Is the old vbr mode still an option in 3.98 because it looks like the "Standard" setting is still using the old mode. I thought I read that --vbr-new is now the default.

Hi John, thanks for the release with flac support.


You're right, with "Standard" setting lamedrop uses the old mode. I converted few flacs to mp3's and encspot shows in Lame Tag: "VBR Method - vbr-old / vbr-rh". If i encode wav's with normal 3.98 lame, encspot shows in Lame Tag: "VBR Method - vbr mtrh".

Also, LamedropXPd doesn't copy tags from flacs to mp3 like oggdropXPd does. But i guess this is because of libsndfile...

You're right, I forgot to change the default on the Method. I've changed it for subsequent compiles, but it's probably not worth uploading again.

And, Kim_C, you're also right, as the FLAC routines are courtesy of libsndfile, tag copying is not catered for, but still a step in the right direction, I think.

Wow

As always, thanks !

I want to see a comparison of different encoders in mostly equal bitrate ranges. So if -V 5 now produces ~150kbps in a 128kbps test ist's not ok in my opinion. I also would like to see lame 3.98 and 3.97; so we may get a new recommended encoder + setting with lame 3.98 after the test.

Thanks to the Lame devs for the new version and many thanks to John33 for finally including FLAC support into LamedropXPd

I have seem to have ripped a NES video game music sample that LAME 3.97 sounds worse then 3.98 at -V5.

LAME 3.97 -V 5 --vbr-new



LAME 3.98 -V 5



I have to seem to have more trouble doing a ABX on the 3.98 encode. At the moment am having trouble doing any tests, since I can not barely hear much at of my right ear, which is likely to be a bad ear wax build up hopefully.

The sample was a 30 sec preview, produced on foobar2000 with the Game Emu music plugin. from a NSF file of a NES and MSX game called Metal Gear. The source was a FLAC preview trancode with the Mono to Stero DSP plugin enabled.

EDIT:

I have uploaded the sample

Thanks, another great release

BTW, I'm not sure if anyone's noticed but many of the pages on the official LAME sourceforge website are not valid XHTML 1.0 Transitional.

john33, a big thank you for the LAME 3.98 compile(s) on Rarewares! Many thanks brother.

Is there a 64 bit compile available from anyone yet?

I know that there are 64bit versions of LAME out there for Unix, such as the version that I run on my x64 Arch Linux box, but I can't recall ever seeing one for Windows. Is a 64 bit version possible for Windows?

There's an old one out there, apparently it was slightly faster, in the order on 10%, in 64-bit. I'm hoping someone has or will do a binary for 3.98.

My LAME binary contain 64-bit code.
http://www.rarewares.org/files/mp3/Lame%203.98.dmg

Is that a Mac binary? Why DMG?
I see it is. Very funny. Do a 64-bit version for the OS that most people use and I'll be your best friend.

Disk images are the standard way of distributing programs in the Mac world (or at least it was when I sold my Mac and bought a PC in 2006). Sadly, in Windows almost every app maker seems to think you need an installer when a simply zip file would suffice.

But back on topic, I gave 3.98 a try and it seems very nice. I embedded cover art into a test file and Foobar and iTunes both picked it up fine. I also noticed in the command help that you can now supply not just the track number but also total tracks of the album. All in all, a nice update I'd say.

I can't wait to update my apps.

I am a alt preset extreme kind of sort . I guess this is still V0?

Has this improved any over the early 3.98 betas?

Thanks!

Since the "newer VBR code is now LAME's default VBR routine", does that mean that



now simply becomes

Yes.

That's simply wonderful!

Yeah I get it. Just want a 64 bit binary for Windows

Doesn't 64-bit not allow you some ASM features? ie. MMX/SSE? And I seem to recall encoding was actually slower due to that. Seems like a novelty with no real benifit.

There is some info on this here:
http://www.hydrogenaudio.org/forums/index....showtopic=47244
...actually one of the reasons I'm asking.

I am no expert, the LAME devs can shoot me down if they want, I just like the sound of ~15% improvement. Whenever I use a LAME compile, it's usually to generate a CD full of MP3s and I tend to end up waiting on it, so any improvement in performance is important to me for one.

I tried the x64 build by Gabriel in the above thread, which is dated 09-Aug-2006. On my Q6600 it's actually considerably slower than 32-bit 3.98 from rarewares.org, but I'm putting that down to the version, and hoping that a similar x64 build of 3.98 will be quicker.

http://gabriel.mp3-tech.org/lame/x64/

Compiled with VC8

Thanks Gabriel, I take it that's 3.98 as there's no version info anywhere.

I just did a few tests with that plus the 32-bit rarewares version. I got very inconsistent results with smaller tracks, I imagine on account of Foobar waiting on the HDD, so I did a second round with much longer tracks. However on these settings at least, the 32 bit version is consistently faster.

==========================
FLAC to MP3 via Foobar2000 on Intel Core 2 Quad 6600
-S --noreplaygain -V 2 --vbr-new - %d

33 radio length tracks:

Gabriel's LAME x64
1st run - 1m 57s
2nd run - 1m 45s
3rd run - 1m 56s
(total 338s)

rarewares LAME 32
1st run - 1m 39s
2nd run - 1m 43s
3rd run - 1m 41s
(total 303s)

x64 is 9.9% slower

4 half album length tracks:

Gabriel's LAME x64
1st run - 1m 09s
2nd run - 1m 12s
3rd run - 1m 09s
(total 210s)

rarewares LAME 32
1st run - 1m 03s
2nd run - 1m 03s
3rd run - 1m 03s
(total 189s)

x64 is 11.1% slower
==========================

Gabriel, are these results to be expected? Would any different command parameters give a different result? Any comments at all?

I would guess the rarewares compiles are made with Intel compiler and Gabriel uses Microsoft VC8.

As pointed by Robert, you only tested that the x86 version from Rarewares is faster than the x64 vc8 version, so you can't draw any x86 vs x64 conclusion from this.
You have to make comparisons with the same compiler being used (which is why I also provided an x86 version)

Well like most users I am only interested in real world results. If the 64-bit version is slower than the fastest available 32-bit version, it is a bit pointless, no?
Is it possible to compile an x64 exe optimized for Intel?

I thought that you were interested to know if it could be faster in x64 vs x86. In this case, it would not have been pointless to report speed tests done on your computer, comparing x86 vs x64 binaries produced by the same compiler (it might even have been helpful).

If you are only interested in the fastest binary available, then you will have to wait for someone else to report test results, so we could start gathering data about it.

It would probably be possible to compile an x64 version with vc8 or icc 10.x, but I don't have any of those compilers.

note:
On my k8, the x64 vc8 version is faster than the x86 vc8 version.

I benchmarked 32 bit lame 3.98 with nasm versus 64 bit lame on a Q6600 (Intel Core 2 Quad Q6600, 6GB DDR2) running stock Ubuntu 8.04 (not that it should make a big difference). Both were compiled with gcc 4.2.3 with the flags given by the ./configure. The results are the average of four runs, discarding to the first run to make sure the file was in cache.

Flags: --noreplaygain -V2
File: Ravel's Bolero, 16:10

32bit: 57.8 seconds
64bit: 50.61 seconds

This puts the 64bit compile in the lead by about 14%. It's probably due to better register allocation (x86_64 has more registers) more than the 64bit-ness of the platform.

Congrats to the Lame devs for putting out a new release.

Eeeeek damn you all gimme an optimized win 64 compile already
lol

Yeah, I'd at least be interesting in testing 3.98 for Win64 compiled with ICL 10.

From your comment, can I assume that the Intel compiler is more optimized than Microsoft's is?

Yes, for many programs ICL generates faster executables than wither MSVC or gcc. Most of the time these differences are pretty small - and the changes are on the order of a couple of percent. Unless you are converting large batches, these won't matter - but can becomes significant over a long batch job.

Last night I did a very high bitrate listening test with my usual problem samples.
I used -V0 as it's the best VBR quality setting, as well as ABR 270 and CBR 320.
I don't care about the bitrate differences: if the philosophy behind VBR and ABR works well, the quality of these settings should be identical. I wanted to find out if the philosophies are right, or whether it makes sense qualitywise to pay some bitrate and go the brute force way using CBR 320 in the extreme case.

I started with my moderate problems herding_calls, Birds, trumpet, trumpet_myPrince. With these very high quality settings these problems were expected to be transparent to me.
Well, they are to me with last night's ABXing, with all the settings, though there is sime suspicion that herding_calls and trumpet_myPrince aren't perfect. With herding_calls I started quite well and arrived at 5/6 resp. 4/5 (depending on encoding setting) before I failed and ended up 6/10 resp. 7/10.
With trumpet_myPrince I arrived at 8/10 (-V0) to 5/10 (--abr 270).
If at all the isssues are very subtle though, and I can't really differentiate the quality of the various settings.

With the serious problems castanets, eig, and harp40_1 I can't differentiate the quality of the various settings either. This time I had no problem abxing castanets clearly, and eig of course is easy to abx.
But to me quality of the encodings is very good, with any of the settings.
harp40_1 was hard to abx, and it was only with ABR 270 that I got a decent result of 9/10 (7/10 with the other settings). But I don't think ABR 270 is worse - as with the other test samples with subtle issues if at all there's some randomness in my ABX results). Which shows of course that quality is very high.

So in the end quality is identical to me with my samples tested, no matter whether -V0, --abr 270, or -b320 is used. Quality is very high, remarkably high with very bad problem eig.

So according to this test -V0 is the most attractive way to go, and taking it together with my last -V3 test, everything is fine from -V3 to -V0 depending on personal quality demand.

BTW the strong error of herding_calls at sec. ~3.8 is so strong just with --abr 170. With --abr 175 it's a lot better, and it disappears for me when using --abr 180 (though herding_calls as an entire track is not transparent using --abr 180).

That sounds like a surprisingly old flaw in thinking. Practically relevant isn't the bitrate of the TEST-SAMPLES, but the average bitrate of MUSIC COLLECTIONS. If an encoder is "smart" enough, to increase bitrate for a difficult sample, then thats a good sign, not something which needs to be "handicapped". While from current observations, 3.98 average bitrate on collections seems to be a bit higher, it isn't as high as test-samples would make one asume. So to summarize: Test should be calibrated to average bitrates of music collections, not to the average bitrate of the test-samples.

3.98 V5 has higher bitrate on average (whole collection).

Unfortunately there is no any best way of listening test "calibration" for VBR encoders. So different approaches are possible. SoundExpert has its own (quoted text refers to SE tests). This was discussed to death at HA forums.

Yes, it is a Mac OS X binary.
Sorry if its not for you. But you did not mention which OS you run, hence why I responded.

Hint. Next time mention which OS you want the binary to run on.

Now come on, nobody actually uses Macs these days. What sort of weird creature are you? If you'd linked to some x64 *nix binary you'd have a point.

I actually wasted several hours of my life monkeying around with MS VS Express and the evaluation Intel compiler, but ICL won't recognize the Visual Studio install (even though it's supposed to) and all the LAME C code fails on trying to compile, unable to find its includes etc. Maybe somebody above my level of proficiency (complete moron) will eventually try. C'mon haxors, bet you can't do it.

What about the chimps that did the RareWares x86 compiles, don't they realize that the 64-bit world is here now and ain't going away?
Having said that, the makefile.msvc wasn't prepared for modern CPUs either, ICL kept failing with some strange /QaxK or /QxK switches being passed to it (with CPU=P3 or not, respectively). No such switches according to icl /help - the one I wanted was /QaxT, which apparently is optimizations for Core 2, so I had to mod the makefile myself. So it seems strange that the LAME devs release source code that won't compile out-of-the-box for native execution on half of today's processors. Obviously nobody cares, I shudda stuck with my 32-bit WinXP on my old Athlon. Sob.

If you are trying to build native Windows applications with VS Express, you need to install a recent Microsoft Platform SDK too.

Yeah I have. I got Windows SDK 6.1. First time I installed VS with a modified install directory, and ICL kept failing when called from nmake, unable to find all the includes. Then I tried reinstalling to default dir, and the ICL component for VS integration now fails upon trying to reinstall, saying that VS can't be found.
By the way, even the first time, from the Intel C++ Build Environment, the system didn't know where nmake was - I had to add the dir to PATH. In retrospect I'm guessing that's not normal.

Let me tell you. A LOT of people use Mac's these days, including me. So don't even go there...
I linked to an x64 *nix binary. Mac OS X is UNIX, GNU/Linux is not.

Oh well!