[ lame-Bugs-3376087 ] Assembly Encoding Differences

SourceForge.net <[email protected]>
Newsgroups gmane.comp.audio.mp3.lame
Message-ID <[email protected]>
Bugs item #3376087, was opened at 2011-07-23 00:46
Message generated for change (Settings changed) made by bouvigne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100290&aid=3376087&group_id=290

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Libraries
>Group: Portability
Status: Open
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Michael Lee Finney (dragonnet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assembly Encoding Differences

Initial Comment:
I have found what appear to be encoding errors using lame 3.84.4.
My source file is Anam.waw which was ripped from a reference CD
using EAC. I got exactly the same file using different machines.

I used the command lines shown below to convert the .wav to .mp3.
These give different results on different machines. The only
difference in the parameters is the use of assembly. That should
be transparent to the results. All command lines should result in
identical output files.

Test machines 1 and 3 are Intel and give the same results. Test
machine 1 is very old and runs Windows 2000. Test machine 3 is
fairly new and runs Windows XP. Test machine 3 is an Athelon and
runs Windows XP.

Output files of the same length are identical. I also used MP3
Checker to validate the output files. All output files passed
validation in this test.

However, I was lead to this by output files which failed validation
and found that the difference was the use of assembly. Since I
don't remember the exact parameters or source files I used for
that I can't give repeatable examples for that. However, this
should suffice to illustrate the differences in encoding that
result from using different assembly options.

Command lines:

   lame -q 0 -V 0 -b 64 -B 320 -t --noasm mmx --noasm 3dnow --noasm sse Anam.wav Anam-0.mp3
   lame -q 0 -V 0 -b 64 -B 320 -t --noasm mmx --noasm 3dnow             Anam.wav Anam-1.mp3
   lame -q 0 -V 0 -b 64 -B 320 -t --noasm mmx               --noasm sse Anam.wav Anam-2.mp3
   lame -q 0 -V 0 -b 64 -B 320 -t --noasm mmx                           Anam.wav Anam-3.mp3
   lame -q 0 -V 0 -b 64 -B 320 -t             --noasm 3dnow --noasm sse Anam.wav Anam-4.mp3
   lame -q 0 -V 0 -b 64 -B 320 -t             --noasm 3dnow             Anam.wav Anam-5.mp3
   lame -q 0 -V 0 -b 64 -B 320 -t                           --noasm sse Anam.wav Anam-6.mp3
   lame -q 0 -V 0 -b 64 -B 320 -t                                       Anam.wav Anam-7.mp3

Test.1 Output Directory

   6,562,849 Anam-0.mp3
   6,562,739 Anam-1.mp3
   6,562,849 Anam-2.mp3
   6,562,739 Anam-3.mp3
   6,562,849 Anam-4.mp3
   6,562,739 Anam-5.mp3
   6,562,849 Anam-6.mp3
   6,562,739 Anam-7.mp3

Test.2 Output Directory

   6,562,849 Anam-0.mp3
   6,562,739 Anam-1.mp3
   6,562,741 Anam-2.mp3
   6,562,741 Anam-3.mp3
   6,562,849 Anam-4.mp3
   6,562,739 Anam-5.mp3
   6,562,741 Anam-6.mp3
   6,562,741 Anam-7.mp3

Test.3 Output Directory

   6,562,849 Anam-0.mp3
   6,562,739 Anam-1.mp3
   6,562,849 Anam-2.mp3
   6,562,739 Anam-3.mp3
   6,562,849 Anam-4.mp3
   6,562,739 Anam-5.mp3
   6,562,849 Anam-6.mp3
   6,562,739 Anam-7.mp3


Michael Lee Finney


----------------------------------------------------------------------

>Comment By: Gabriel Bouvigne (bouvigne)
Date: 2012-06-12 06:05

Message:
Thank you for this report.

Actually, this behavior is well-known to developers of the project.
Lame is using mostly floating point computations, and those operations
might produce slightly different results between assembly (mostly 3dnow and
SSE) and x87 code, due to some precision differences.
You might also witness the same behavior using Lame built with different
compilers.

Anyhow, when introducing assembly code we checked that the difference was
very low (and not that different from the differences you get when using
different compilers).

----------------------------------------------------------------------

Comment By: Michael Lee Finney (dragonnet)
Date: 2012-06-09 23:59

Message:

I have replicated this problem using 3.99.5. The size of the .mp3 files
are
slightly different, presumably due to the changes to the .mp3 encoding
algorithm. Using exactly the same command lines, here are the current
results
for Test.1 and Test.2.

Test.1 Output Directory

7,230,062 Anam-0.mp3
7,229,957 Anam-1.mp3
7,230,062 Anam-2.mp3
7,229,957 Anam-3.mp3
7,230,062 Anam-4.mp3
7,229,957 Anam-5.mp3
7,230,062 Anam-6.mp3
7,229,957 Anam-7.mp3

Test.2 Output Directory

7,230,062 Anam-0.mp3
7,229,957 Anam-1.mp3
7,230,055 Anam-2.mp3
7,229,957 Anam-3.mp3
7,230,062 Anam-4.mp3
7,229,957 Anam-5.mp3
7,230,055 Anam-6.mp3
7,229,957 Anam-7.mp3


Michael Lee Finney


--------------------------------------------------------------------------------


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100290&aid=3376087&group_id=290

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.