Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: LAME 3.98 Final (Read 231879 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME 3.98 Final

Reply #75 –
Yes.
lame3995o -Q1.7 --lowpass 17

LAME 3.98 Final

Reply #76 –
That's simply wonderful!

LAME 3.98 Final

Reply #77 –
Quote from: Agent69 on
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.

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

LAME 3.98 Final

Reply #78 –
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.

LAME 3.98 Final

Reply #79 –
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.

LAME 3.98 Final

Reply #81 –
Quote from: Gabriel on
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?

LAME 3.98 Final

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

LAME 3.98 Final

Reply #83 –
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)

LAME 3.98 Final

Reply #84 –
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?

LAME 3.98 Final

Reply #85 –
Quote from: Bad Monkey on
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?

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.

LAME 3.98 Final

Reply #86 –
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.

LAME 3.98 Final

Reply #87 –
Quote from: cabbagerat on
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

LAME 3.98 Final

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

LAME 3.98 Final

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

LAME 3.98 Final

Reply #90 –
Quote from: Agent69 on
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.

LAME 3.98 Final

Reply #91 –
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).
lame3995o -Q1.7 --lowpass 17

LAME 3.98 Final

Reply #92 –
Quote from: Serge Smirnoff on
So summing all of these factors I can predict slightly better results of Lame 3.98 over 3.97b2 in SE 128 kbit/s group which is not too informative due to increased bit rate. Comparison with other contenders will be more interesting as the competition is fairer now.

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.
I am arrogant and I can afford it because I deliver.

LAME 3.98 Final

Reply #93 –
3.98 V5 has higher bitrate on average (whole collection).

LAME 3.98 Final

Reply #94 –
Quote from: Lyx on
Quote from: Serge Smirnoff on

So summing all of these factors I can predict slightly better results of Lame 3.98 over 3.97b2 in SE 128 kbit/s group which is not too informative due to increased bit rate. Comparison with other contenders will be more interesting as the competition is fairer now.

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.

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.
keeping audio clear together - soundexpert.org

LAME 3.98 Final

Reply #95 –
Quote from: Bad Monkey on
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.

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.

LAME 3.98 Final

Reply #96 –
Quote from: krmathis on
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.

LAME 3.98 Final

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

LAME 3.98 Final

Reply #98 –
Quote from: robert on
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.

LAME 3.98 Final

Reply #99 –
Quote from: Bad Monkey 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

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!