IPB

Welcome Guest ( Log In | Register )

9 Pages V  < 1 2 3 4 > »   
Closed TopicStart new topic
lame 3.98.4, 3.99 alpha, 32- and 64-bit builds
john33
post Mar 23 2010, 17:50
Post #26


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (Steve Forte Rio @ Mar 23 2010, 15:58) *
Can someone tell me why I'm getting different audiostreams with compiles by tsnr and john33??

QUOTE
Differences found: 4389914 sample(s), starting at 2.1563265 second(s), peak: 0.0983066 at 149.9082993 second(s), 2ch


Also encoding is about 1.5x faster with tsnr's compile blink.gif

Parameters (foobar2000):

--silent -b 320 -q 0 --noreplaygain - %d

As already mentioned, different compilers and compiler options will produce differing results, but I don't believe anyone yet has been able to hear a difference.

I'd love to know what the compiler options used were that make that compile 1.5 times faster.

Edit: Well, having just run tsnr's 32 bit compile on my development system (e4300 @ 3.0GHz, 4GB RAM, XP Pro SP3) there is virtually no difference in speed between that compile and my own. What system are you using to get 1.5x faster running?

This post has been edited by john33: Mar 23 2010, 18:19


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Steve Forte Rio
post Mar 23 2010, 18:36
Post #27





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



QUOTE
different compilers and compiler options will produce differing results


But I thought that the same LAME version/parameters will result in absolutely the same stream ohmy.gif
And now I wonder what the differences (absolute, not audible!) can be between streams produced by different compiles...

QUOTE
What system are you using to get 1.5x faster running?


Pentium 4 631 3,75 GHz (MMX, SSE3), 2Gb DDR2-667 RAM, XP Pro SP3 32bit

This post has been edited by Steve Forte Rio: Mar 23 2010, 18:40
Go to the top of the page
+Quote Post
Alex B
post Mar 23 2010, 18:41
Post #28





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



It is important to minimize all external factors that may affect the encoding speed before making any conclusions.

Just a few days ago I compared the encoding speeds of two 3.98.2 compiles: the MS compile from http://lame.bakerweb.biz and John's Intel compile from rarewares.

I used foobar2000 on XP SP3 for encoding a set of 50 various FLAC tracks. The destination folder was set to be on a separate drive. Foobar was set to use all four cores of my AMD Phenom II CPU. Before testing I disabled the virus scanner and closed all other programs. I encoded the complete set with both encoders twice in a row and noted only the latter runs in order to avoid differences that could be caused by cached file data.

The results:

Rarewares
Total encoding time: 1:04.188, 118.47x realtime

Bakerweb
Total encoding time: 1:23.828, 90.71x realtime


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
lvqcl
post Mar 23 2010, 18:43
Post #29





Group: Developer
Posts: 3382
Joined: 2-December 07
Member No.: 49183



WinXP 32bit. Core2 Duo E4600. lame -S --noreplaygain -b320 -q0.

rarewares:
QUOTE
Kernel Time = 0.140 = 00:00:00.140 = 0%
User Time = 30.156 = 00:00:30.156 = 98%
Process Time = 30.296 = 00:00:30.296 = 99%
Global Time = 30.531 = 00:00:30.531 = 100%


tsnr:
QUOTE
Kernel Time = 0.156 = 00:00:00.156 = 0%
User Time = 23.875 = 00:00:23.875 = 98%
Process Time = 24.031 = 00:00:24.031 = 98%
Global Time = 24.328 = 00:00:24.328 = 100%


1.25x faster.
Go to the top of the page
+Quote Post
Alex B
post Mar 23 2010, 18:52
Post #30





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



OK, I'll repeat the my test using the new 32-bit 3.98.4 compiles. I still have the test files ready for use. Give me a few minutes.


john33,

Regarding AMD vs Intel, do you think that your binaries favour Intel processors?

This post has been edited by Alex B: Mar 23 2010, 18:57


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
robert
post Mar 23 2010, 19:10
Post #31


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



Interesting read:
Does Intel's compiler cripple AMD performance?
Go to the top of the page
+Quote Post
john33
post Mar 23 2010, 19:15
Post #32


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



I just re-tested on a q6600 with 8GB and XP x64 and, again, the speed difference was minimal. My compiles use the /arch:IA32 command line option.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Steve Forte Rio
post Mar 23 2010, 19:18
Post #33





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



Everyone talks about the differences in performance but nobody cares, what is the difference between the output files and where it come from??

This post has been edited by Steve Forte Rio: Mar 23 2010, 19:22
Go to the top of the page
+Quote Post
Alex B
post Mar 23 2010, 19:48
Post #34





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



The results using -V2 --noreplaygain. I forgot to mention in my above description that I also always deleted the resulting files before each new run so that the destination drive would be in about the same state.


tsnr's compile:

The first run: Total encoding time: 1:03.266, 120.19x realtime

The second run in a row: Total encoding time: 1:01.578, 123.49x realtime


john33's compile:

The first run: Total encoding time: 1:02.015, 122.62x realtime

The second run in a row: Total encoding time: 1:00.484, 125.72x realtime


On my PC john's compile was slighly faster, but the difference is not significant. It may be caused by anything.


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
john33
post Mar 23 2010, 19:59
Post #35


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (Steve Forte Rio @ Mar 23 2010, 18:18) *
Everyone talks about the differences in performance but nobody cares, what is the difference between the output files and where it come from??

From the fact that different compilers produce different object code. In this particular case, I believe that the difference is mainly due the use of different compiler options. Changing the compiler options allowed me to generate a compile that produces an encoded mp3 that is more similar in characteristics, according to the histogram, to tsnr's compile. Basically, the results of math calculations vary slightly when using SSE, SSE2, SSE3, SSSE3, etc.

The differences in encoded files resulting from encoders generated with different compilers has long been discussed but, as I said, I don't believe anyone has ever claimed to hear a difference and that is all that matters.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
timcupery
post Mar 23 2010, 21:38
Post #36





Group: Members
Posts: 780
Joined: 19-December 01
From: Tar Heel country
Member No.: 683



does the audio stream itself differ between the two compiles? and by this I mean, if you decode both files to wav files and compare those, are the wav files bit-for-bit equal?


--------------------
God kills a kitten every time you encode with CBR 320
Go to the top of the page
+Quote Post
db1989
post Mar 23 2010, 21:45
Post #37





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



See post #24.
Go to the top of the page
+Quote Post
Steve Forte Rio
post Mar 23 2010, 21:45
Post #38





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



Audio steams are different, so the wave files will be different too and they can not be "bit-for-bit equal".

This post has been edited by Steve Forte Rio: Mar 23 2010, 21:48
Go to the top of the page
+Quote Post
john33
post Mar 23 2010, 22:33
Post #39


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



Whether, or not, the decoded streams are identical is somewhat irrelevant. People are getting hung up on whether the encoded files are identical and, as has been said many times before, different compilers and compiler options will necessarily produce different encoded results. The only concern is whether, or not, that difference can be heard and, so far, no one has even attempted to claim that.

At the end of the day, take a wave file and encode it with a variety of different encoders - different codecs - and each of them will lack a significant amount of data when compared with the original wave file. That is a given and no one would contest that. At the expense of repetition, the only issue is whether a difference can be heard under reasonable listening conditions.

If paranoia has truly set in, then use a lossless codec, otherwise demonstrate via testing that you can discern a difference. We are dealing with a lossy codec here! A lot of data is being thrown away and only when you can genuinely hear that something is lacking is there an issue!


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
db1989
post Mar 23 2010, 23:08
Post #40





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



QUOTE
People are getting hung up on whether the encoded files are identical

I mean no offence to Steve, but he seems to be the only person who is concerned.
Go to the top of the page
+Quote Post
Light-Fire
post Mar 24 2010, 01:12
Post #41





Group: Members
Posts: 420
Joined: 5-August 06
From: Canada
Member No.: 33645



QUOTE (timcupery @ Mar 23 2010, 15:38) *
does the audio stream itself differ between the two compiles? and by this I mean, if you decode both files to wav files and compare those, are the wav files bit-for-bit equal?

QUOTE (Steve Forte Rio @ Mar 23 2010, 15:45) *
Audio steams are different, so the wave files will be different too and they can not be "bit-for-bit equal".


We are talking LOSSY encoding here kids. It doesn't matter if the compiles differ and streams are not bit-for-bit equal. What counts is:

QUOTE (john33 @ Mar 23 2010, 16:33) *
...whether, or not, that difference can be heard and, so far, no one has even attempted to claim that...

Go to the top of the page
+Quote Post
saratoga
post Mar 24 2010, 01:23
Post #42





Group: Members
Posts: 4966
Joined: 2-September 02
Member No.: 3264



QUOTE (Steve Forte Rio @ Mar 23 2010, 16:45) *
Audio steams are different, so the wave files will be different too and they can not be "bit-for-bit equal".


If you want bit for bit identical, you need to use lossless. Lossy codecs use floating point values, which are only approximate. Different compiles, different CPUs, different operating systems, etc can and do give different output. Thats how computers are supposed to work smile.gif

If you don't like it, don't use MP3.
Go to the top of the page
+Quote Post
gottogo99
post Mar 24 2010, 02:47
Post #43





Group: Members
Posts: 105
Joined: 13-April 07
Member No.: 42452



Another question, for john33: why are there two slightly different versions of lame.exe in the new 3.98.4? The one with libsndfile is one minute newer and 5KB smaller. Seems like they should be the same but I'm no programmer.
Go to the top of the page
+Quote Post
Andavari
post Mar 24 2010, 05:35
Post #44





Group: Members
Posts: 935
Joined: 3-June 02
From: USA
Member No.: 2204



QUOTE (Alex B @ Mar 23 2010, 01:24) *
http://www.virustotal.com didn't find anything scary in the exe files. Only "Symantec 20091.2.0.41, 2010.03.23" thinks that the files are suspicous.

The Symantec scanner on VirusTotal tags allot of stuff as "Suspicious.insight" for some particular reason, even if it's deemed clean by all the other scanners.

I wonder if those "MediaFire" compiles were just taken from Rarewares to begin with since LAME 3.98.4 is on Rarewares right now.


--------------------
Complexity of incoherent design.
Go to the top of the page
+Quote Post
viktor
post Mar 24 2010, 09:46
Post #45





Group: Members
Posts: 297
Joined: 17-November 06
Member No.: 37682



sadly x64 is about 15% slower than the x86 built with asm optimizations. it would be great if we could take advantage of the advanced architecture sometime.

http://www.phoronix.com/data/img/results/m...910_final/4.png

xvid x64 is 20% faster than x86, x264 x64 is 15% faster, but that could be due to the lack of optimizations in the x86 version...
Go to the top of the page
+Quote Post
john33
post Mar 24 2010, 09:51
Post #46


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (Andavari @ Mar 24 2010, 04:35) *
.....
I wonder if those "MediaFire" compiles were just taken from Rarewares to begin with since LAME 3.98.4 is on Rarewares right now.

No, they weren't, they were made available during the night (my time) before I'd even begun to build them. wink.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
john33
post Mar 24 2010, 10:01
Post #47


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (gottogo99 @ Mar 24 2010, 01:47) *
Another question, for john33: why are there two slightly different versions of lame.exe in the new 3.98.4? The one with libsndfile is one minute newer and 5KB smaller. Seems like they should be the same but I'm no programmer.

There are, in fact, three versions currently offered:

The standard build with the dll and the documentation, a modified, unofficial build that will accept flat wav input and the version that uses the libsndfile dll that accepts FLAC input in addition to the usual inputs. The option to compile against libsndfile libraries to extend the input file options has existed for many years. It recently became more useful as it now takes FLAC input, along with many others. The .exe files differ because the standard one uses the native file reading routines provided within LAME whereas the libsndfile version hands input file handling to the libsndfile-1.dll. For like-for-like input files, the output will be identical for all versions.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Steve Forte Rio
post Mar 24 2010, 11:25
Post #48





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



Ok, people. Now I see that really getting too worried about such negligible things smile.gif And it really looks like some kind of paranoia biggrin.gif
But it was a metter of principle for me.
Well, now I understand where those differences come from (floating-point values, approximation, etc.), so they are absolutely inaudible (maybe you will find it ridiculous, but I even tried to ABX them biggrin.gif )
Thank you smile.gif

This post has been edited by Steve Forte Rio: Mar 24 2010, 11:26
Go to the top of the page
+Quote Post
john33
post Mar 24 2010, 11:41
Post #49


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (Steve Forte Rio @ Mar 24 2010, 10:25) *
...(maybe you will find it ridiculous, but I even tried to ABX them biggrin.gif )
Thank you smile.gif

Not ridiculous at all, the best way to establish whether the differences matter. wink.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
gottogo99
post Mar 24 2010, 12:16
Post #50





Group: Members
Posts: 105
Joined: 13-April 07
Member No.: 42452



QUOTE (john33 @ Mar 24 2010, 04:01) *
There are, in fact, three versions currently offered:

The standard build with the dll and the documentation, a modified, unofficial build that will accept flat wav input and the version that uses the libsndfile dll that accepts FLAC input in addition to the usual inputs. The option to compile against libsndfile libraries to extend the input file options has existed for many years. It recently became more useful as it now takes FLAC input, along with many others. The .exe files differ because the standard one uses the native file reading routines provided within LAME whereas the libsndfile version hands input file handling to the libsndfile-1.dll. For like-for-like input files, the output will be identical for all versions.

Thanks for clearing that up. I figured there was a reason.
Go to the top of the page
+Quote Post

9 Pages V  < 1 2 3 4 > » 
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 19th September 2014 - 17:05