ABX test: Nero vs. Nero SSE encoder, the difference is audible at -q 0.2 Options

[Alex B]

I noticed that the Nero AAC Win32 and Nero AAC Win32 SSE encoders produced files with different replay gain peak values when I test encoded rootkit's "Sunny" sample for another thread and became curious.

I encoded the original sample using the plain -q 0.2 setting with both CLI encoder versions on a 2.8 GHz P4 & XP SP2. Then I converted both AAC-HE files to wave with Nero CLI decoder and created a difference file with Audition (phase inverted the SSE file and mix pasted into the standard file). The difference file contained considerable amount of stuff and I decided to try an ABX test, which was succesful.

Nero encoder vs Nero SSE encoder (v. 1.1.34.2):

CODE

foo_abx 1.3.1 report
foobar2000 v0.9.4.5
2007/10/29 13:44:00

File A: E:\X\nero\NeroDigitalAudio\win32\sunny.wav
File B: E:\X\nero\NeroDigitalAudio\win32\sunny_sse.wav

13:44:00 : Test started.
13:45:30 : 01/01  50.0%
13:45:46 : 02/02  25.0%
13:46:38 : 03/03  12.5%
13:46:57 : 04/04  6.3%
13:47:16 : 05/05  3.1%
13:47:41 : 06/06  1.6%
13:48:16 : 07/07  0.8%
13:48:46 : 08/08  0.4%
13:49:10 : 09/09  0.2%
13:50:10 : 10/10  0.1%
13:50:12 : Test finished.

----------
Total: 10/10 (0.1%)

I tested the passage were the difference was biggest at about 17.0 - 18.5 s.

I can't say which file has better quality and I don't know if my finding is useful for the developers, but I'd be interested to hear their comments.

rootkit's original sample is available here: http://www.hydrogenaudio.org/forums/index....ost&id=3931
and my MP4 test files here: http://www.hydrogenaudio.org/forums/index....st&p=526235

[menno]

Yeah, we know about these differences. It's all the compiler's fault! I'm sure you can do similar tests when compiling LAME with the Intel and with the MSVC compiler.
SSE version will be dropped for the next release, as the normal version is already so optimized that there doesn't even seem to be a significant speed advantage anymore.

[Alex B]

Yeah, we know about these differences. It's all the compiler's fault! I'm sure you can do similar tests when compiling LAME with the Intel and with the MSVC compiler.

Yes, I know that different compilers often produce slightly different results. I just didn't expect the difference to be audible.

SSE version will be dropped for the next release, as the normal version is already so optimized that there doesn't even seem to be a significant speed advantage anymore.

For now, would you say that the standard version works more correctly or more like intended by the developers?

[menno]

SSE version will be dropped for the next release, as the normal version is already so optimized that there doesn't even seem to be a significant speed advantage anymore.

For now, would you say that the standard version works more correctly or more like intended by the developers?

MSVC compiler is what we test with and work with during development, so, yes

[benski]

SSE's limited precision (32 bit internal precision in comparison to the x87's 80bit internal precision) can cause these sorts of differences, also.

[slks]

Do SSE2 and SSE3 have the same limitation? Or can they use 80-bit precision?

[benski]

Do SSE2 and SSE3 have the same limitation? Or can they use 80-bit precision?

SSE2 has 64bit precision, but only allows 2 simultaneous operations (SSE allows 4)

[Egor]

Now I'm curious if other lossy encoders (e.g., Lame) could be affected by the same "precision issue"?

[Junon]

Now I'm curious if other lossy encoders (e.g., Lame) could be affected by the same "precision issue"?

This discussion is often led concerning aoTuV and its SSE-enhanced Lancer derivate. Common conclusion has always been that there definitely are differences in precision because of the 80-bit FPU vs. 64-bit SSE2 issue. But up to this day no one seems to have been able to ABX the results from each other, at least I can't remember ever having seen any logs. Therefore the much faster Lancer encoder is generally accepted to be of equal quality to the aoTuV one, making it the best possible solution for Vorbis encoding out there.

This post has been edited by Junon: Oct 31 2007, 15:53

[benski]

Now I'm curious if other lossy encoders (e.g., Lame) could be affected by the same "precision issue"?

This discussion is often led concerning aoTuV and its SSE-enhanced Lancer derivate. Common conclusion has always been that there definitely are differences in precision because of the 80-bit FPU vs. 64-bit SSE2 issue. But up to this day no one seems to have been able to ABX the results from each other, at least I can't remember ever having seen any logs. Therefore the Lancer encoder is generally accepted to be of equal quality to the aoTuV one, making it the best one out there.

I've reached the same conclusion from informal testing. Measurable differences (as high as -80dB of difference at times). You usually don't hear any difference due to precision until you get into 4th order of higher resonant IIR filters, which are popular in pro-audio effects processors but not in lossy transform codecs