#404 Assembly Encoding Differences

Portability
closed-rejected
nobody
Libraries (86)
5
2013-06-11
2011-07-23
FireDragon
No

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

Discussion

  • FireDragon

    FireDragon - 2012-06-10

    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

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

     
  • Gabriel Bouvigne

    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).

     
  • Gabriel Bouvigne

    • labels: --> Libraries
    • milestone: --> Portability
    • status: open --> open-rejected
     
  • Robert Hegemann

    Robert Hegemann - 2013-06-11
    • status: open-rejected --> closed-rejected
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks