I've been trying to equalize my MP3 encodes using EAC and LAME 3.90.3 across different computers and different drives.

Machine 1: AMD Athlon 3200, Lite-On LTR-40125S, Win2000 Pro SP3
Machine 2: Intel Pentium 4 2.4GHz, Afreey CD-2050E, Win2000 Pro SP3

The EAC configurations are identical across the two machines based on registry/bytewise file compares. The LAME software is identical across the two machines based on bytewise file compares (C:\apps\LAME, where I initially extracted it, was actually copied from one computer to the other).

The two machines (EAC) produce bytewise identical .WAV files for the same CD.

However, from these WAV files, the two machines produce bytewise different MP3 files, for 16 bytes in three different sections (offsets) of the files (files are identical in size).

I've been researching this on the net and haven't found much on this subject. I'm just trying to verify if this is because of the processors and not something else that I'm missing.

It seems so, because if I just run lame -h test.wav test.mp3 on the two machines for an identical .wav file, the resultant MP3 files are even more bytewise different than what EAC produced.

Thanks for any input on this...

Your amd is using 3dNow code. This is producing a slightly different output. (however it is not a problem)

You could try adding "--noasm 3dnow" to check if files are identical

Why would you want to throw in a variable such as using 3DNow? I would think it would make a lot more sense to have it standard across the board...

I'm not sure I truly understand your question, but adding 3DNow support would decrease encode time on AMD processors without noticably affecting the sound. It makes sense to me.

Various processors have special instructions that are specific to that architecture, and it makes sense to take advantage of these.

In my opinion, there shouldn't be any differences between the 2 types of processors for the same set of codes! We are using basic arithmetic / mathematical functions here.. Hmmm.. this is serious..

Why would the processor be using special instructions if the codes isn't compiled to use them in the first place? 3DNow would not even be invoked unless you are coding in those instructions.

When running over a processor featuring 3dnow, Lame is using a 3dnow optimized fft transform to speed up the process.

So when running on an Athlon, the 3dnow fft is used, and while running on a p4, the regular fft is used.

Those two fft do not produce bit identical results.

In your case your have two different (slightly) output files because you are using 2 different encoding routines.

If you disable 3dnow when running Lame on your Athlon (by adding "--noasm 3dnow") you would then use the same encoding routines, but the speed will be lower.

Lame is specifically using 3dnow if available.

Did as you suggested with LAME v3.96. Resultant files were identical. Thanks for helping me figure this one out...

Just a curious question.

What optimiziation is used when a have a Athlon64 CPU in my PC?
The A64-CPU has MMX, 3DNow!, SSE and SSE2 instruction sets.

In 32 bits mode, mmx and 3dnow, as Lame is only able to use those right now.
In 64bits mode your SSE unit, but in the same way as any other x86-64 application (no assembly stuff)