lame 3.98.4, 3.99 alpha, 32- and 64-bit builds Options

[shadowking]

I dunno. Years ago i encoded with mpc -standard. In recent times I tried lame -V3. Very similar bitrate to mpc / nero 0.5 and you what: its not too bad at all. Most tracks are transparent with headphones or close to it. It doesn't have the annoying scfb21 issue , its VBR and unlike mpc , its compatible with nearly anything out there Mp3gain works on all hardware too. I guess i still really like efficiency .

So What i'm saying is that everything now is 250~300k. So why not just 256-320 CBR using lame from 2000 ? Its virtually the same. We have advanced so much yet ended up in the same place.

This post has been edited by shadowking: Sep 14 2011, 11:47

[halb27]

I came back to mp3 for the same reasons you've mentioned. And it's good enough for me.
Sure moderate bitrate users take better profit from Lame improvements. Whether or not that's essential is personal judgement.

This post has been edited by halb27: Sep 14 2011, 18:31

[halb27]

...
Sample14 (trumpet)

ABC/HR for Java, Version 0.53a, 12 September 2011
Testname:

Tester: IgorC

1L = sample14_3984_V0_2.wav
2R = sample14_399b0_V0_VNEW_3.wav
3L = sample14_397_V0_1.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: sample14_3984_V0_2.wav
1L Rating: 3.6
1L Comment:
---------------------------------------
3L File: sample14_397_V0_1.wav
3L Rating: 4.3
3L Comment:
---------------------------------------

ABX Results:

3.98.4 has an artifact which was known as paper sound in past (?)

...

Oops, I didn't read carefully. Where's the result for 3.99? 3.97 -V0 better than 3.98.4 -V0 on trumpet? That can't be true. 3.97 had the sandpaper noise issue which 3.98 improved upon, and for 3.97 trumpet was a problem, whereas at least I am pretty content with 3.98.4 -V0 on it.

There must have gone something wrong.

[IgorC]

That can't be true.

Different conditions: listener, hardware, room, time, mood and ... familiarity with sample and/or artifact (see below)

Also it's something related to it
http://www.hydrogenaudio.org/forums/index....st&p=743184

In other words You can perform the blind tests for some particular sample again and again during one day but it doesn't guarantee the same results if you will perform it next day/week. I think what really counts it is a tendency (many results) not particular one result.

Where's the result for 3.99?

It wasn't. The absense of the score in ABX log means 5.0. But as I said it _was_. Now I listened it the second time and alter the initial perception completely. The results have changed drastically. That's why I did quite a lot of samples (18 actually but didn't post them here) . It reveals the average tendency because most of all I care about average score. While there can be a statistical noise on single results.

This post has been edited by IgorC: Sep 14 2011, 21:26

[halb27]

...
Different conditions: listener, hardware, room, time, mood and ... familiarity with sample and/or artifact (see below)
...
The absense of the score in ABX log means 5.0. But as I said it _was_. Now I listened it the second time and alter the initial perception completely. The results have changed drastically. That's why I did quite a lot of samples (18 actually but didn't post them here) . It reveals the average tendency because most of all I care about average score. While there can be a statistical noise on single results.

I know the problem of different results with different tests very well. Ran upon it when testing lossyWav. It's annoying.
But in cases where I get totally different perceptions I'd rather not use the results. I'd only use results for those samples for which I can get perceptions which more or less reliably differentiate encoder versions.

If the a priori preferred encoder result of a sample is harder to ABX against the original (if in doubt because of equal or near-equal scores use the time it takes for ABXing as a measure for it) than is the alternative, this is kind of a confirmation for your initial perception. This is not foolproof of course, but it makes judgements on encoder results a little bit less personal.

As for my favorite mp3 problem sample trumpet I'd love to learn about your new results.

This post has been edited by halb27: Sep 14 2011, 23:04

[IgorC]

As for my favorite mp3 problem sample trumpet I'd love to learn about your new results.

I have no problem to provide the results. The problem is that they are variable.
During the day I have made 5 times the same trumpet sample. Now 3.98.4 was the best. All 5 times it was 3.98.4>3.97>3.99b0. When I got back home at night and made the same test twice and twice time it was 3.98.4>3.99b0>3.97.


Possible explanation is the the conditions of the test have changed.
During the day the level of noise was quite high at home (cars). The night was quite.

For now it's the last time for me I test trumpet sample. I remember I have the same experience with sample Take Your Finger From My Head.

P.S. Additional comparison codec A vs codec B (besides of codec A vs lossless, codec B vs lossless) doesn't help for these samples.
http://www.hydrogenaudio.org/forums/index....st&p=743197

This post has been edited by IgorC: Sep 15 2011, 06:13

[halb27]

Thanks a lot for your efforts.
As far as 3.98.4 is concerned your overall results on trumpet agree with mine (definitely compared to 3.97, but I can't talk about 3.99b0 which I have no experience with, just with early alpha versions with which I could not hear an improvement on trumpet).

This post has been edited by halb27: Sep 15 2011, 06:54

[IgorC]

Thank You too for bringing this out.
It makes me remember of the previous issues and re-think, improve some technics.

[DigitalDictator]

As for my favorite mp3 problem sample trumpet I'd love to learn about your new results.

I have no problem to provide the results. The problem is that they are variable.
During the day I have made 5 times the same trumpet sample. Now 3.98.4 was the best. All 5 times it was 3.98.4>3.97>3.99b0. When I got back home at night and made the same test twice and twice time it was 3.98.4>3.99b0>3.97.


Possible explanation is the the conditions of the test have changed.
During the day the level of noise was quite high at home (cars). The night was quite.

For now it's the last time for me I test trumpet sample. I remember I have the same experience with sample Take Your Finger From My Head.

P.S. Additional comparison codec A vs codec B (besides of codec A vs lossless, codec B vs lossless) doesn't help for these samples.
http://www.hydrogenaudio.org/forums/index....st&p=743197

I've been meaning to ask about this "phenomenon" before. Does this indicate that, for example, the last public test @96 kbps would come out differently if the same people did the tests a second time? I mean, if the artifacts are so subtle and it has a lot to do with your own personal state of mind (eg. tired, bored, stressed out etc.), the outcome is mererly a result of the testers' shape that day, and not so much the encoder itself? Just a thought...

[halb27]

The outcome can change, but as there are many testers who contributed to the listening test, I can't imagine things would change significantly.
The exact numerical outcome shouldn't be taken too serious anyway, and the confidence intervals should be respected.

The main outcome of the test can be trusted IMO which is:
- Apple Quicktime is better than Nero
- Apple Quicktime TVBR is not better than CVBR
- new FhG encoder is in the quality range of Apple Quicktime
- CT encoder is between Apple Quicktime and Nero qualitywise
- looking at the outcome of the individual samples there is no significant deviation of relative encoder quality from the average outcome over all the samples.
  As a consequence looking at the average result is sufficient for comparing encoder quality (with the last mp3@128 kbps test it was a different story).
- at least for the better encoders quality is very high for 96 kbps encodings - with sample 3 being an exception to this.

This post has been edited by halb27: Sep 15 2011, 16:02

[IgorC]

Does this indicate that, for example, the last public test @96 kbps would come out differently if the same people did the tests a second time?

No, it wouldn't be different at all. This phenomenon is canceled between different results of the listeners. It will be already canceled on large number of the samples for the same listener.
Testing AAC at 96 kbps isn't the same thing as testing LAME V0 (far from that). The correlation between the average results and results of particular listener was quite high (70%).

Also this phenomenon doesn't happen for each sample and listener.

This post has been edited by IgorC: Sep 15 2011, 20:14

[john33]

3.99beta1 x86 and x64 compiles now at Rarewares.

[Fishman0919]

WOOT

[viktor]

3.99beta1 x86 and x64 compiles now at Rarewares.

interesting results:

- 3.98.4 x86: 4:20
- 3.98.4 x64: 4:32
- 3.99b1 x86: 6:06
- 3.99b1 x64: 3:15

on the same sample with default settings.

[lvqcl]

Maybe 32-bit version was compiled with optimizations for Intel processors only.

[viktor]

Maybe 32-bit version was compiled with optimizations for Intel processors only.

maybe, but only the beta one?

[robert]

John, there is something very odd with your x86-32 build, it's way too slow.
Just for comparison, mine compiled with VC9 Express edition (32 bits, haven't figured out how to set it up for x86-64 builds), running on AMD Athlon 64 X2, Win7-64:

Debug: 51
Release: 19
NASM: 17
SSE2: 14

now John's (Intel?) builds:
x86-32: 22
x86-64: 12

[john33]

Robert, having just tested the 32bit compile on a 1075T, hex core @3.6, it runs at about half the speed of the 64 bit compile, which is bizarre to say the least! I can't immediately think of anything that may be responsible, but I'll look into it and report back.

This post has been edited by db1989: Oct 3 2011, 17:23

Reason for edit: deleting pointless full quote of last post

[john33]

OK, having recompiled using VS2008, not Intel, it would seem that this is the Intel screwing AMD issue! Here are two compiles x86 and x64, both non-Intel that I would like to be tested please:

x86 - http://homepage.ntlworld.com/jfe1205/LAME/lame3.99.b1_1.zip

x64 - http://homepage.ntlworld.com/jfe1205/LAME/....99.b1-64_1.zip

The testing I have done suggests that the speed of these is very little different on Intel CPUs to what it was using the Intel compiler. However, on AMD (I only have the hex core 1075T to test on) the x64 compile is around the same speed as before, but the x86 compile is around 50% faster.

I'd be interested in other peoples experiences and any other comments.

[Alex B]

A quad-core AMD Phenom II, XP Pro 32-bit, foobar2000, four simultaneous encoding processes, -S -V2 --noreplaygain - %d, source: 25 various wave tracks.

3.99b1 (x86)
Total encoding time: 1:23.719, 65.66x realtime

3.99b1_1 (x86)
Total encoding time: 0:53.688, 102.40x realtime

3.98.4 (the main bundle from Rarewares)
Total encoding time: 0:40.922, 134.34x realtime

3.98.4 (the VC6 compile from Rarewares)
Total encoding time: 0:41.625, 132.07x realtime

[john33]

New Intel compiles with the 'icc-patcher' applied to both compiles. Seems to have no effect on running on Intel CPUs, but improves AMD CPU performance.

x86 - http://homepage.ntlworld.com/jfe1205/LAME/lame3.99.b1_1.zip

x64 - http://homepage.ntlworld.com/jfe1205/LAME/....99.b1-64_1.zip

Comments, etc., would be appreciated.

[robert]

Your new Intel compiles seem OK, the x64-32 improved from 22 to 15 seconds in the same test as before.
I couldn't test your VS2008 ones, I was too late to the party, as you already replaced them with the IC ones.
Thanks John.

[john33]

Thanks guys, I'll replace the compiles on Rarewares with these.

[Alex B]

The 'icc-patcher' compile (x86):
Total encoding time: 0:51.359, 107.04x realtime

It is slightly faster than the VS2008 compile. 3.98.4 is still quite a bit faster, but perhaps that is caused by the differences in the encoders.

I don't have a 64-bit OS installed so I can't compare the x86 and x64 versions.

[john33]

Thanks, Alex. I have the opposite problem, all my systems are now running Windows 7 x64!