Howdy,
I was wondering if/when someone would notice this. When I first got the
'dist10' distribution of the ISO code (or maybe it was 8hz' hack of it) it
compiled and ran it on both my NT4 box and a Red Hat Linux box and was
surprised to get different output bitstreams from the encoders. (I wouldn't
have noticed/cared if there was a speed difference, as the CPUs and load
levels were not really comparable between the machines.)
I traced the problem to the code for computing whether to insert a padding
slot or not, which is written using floating point arithmetic. The two CPUs
were getting different values in about the 15th place after the decimal
(18th significant digit) on a floating point divide, and then accumulating
that error frame by frame and using it to test for padding. I suppose that
if both compilers were equally diligent in their adherence to IEEE standards
(and both CPUs had no problems with floating divide...), this should not
happen - but it doesn't really matter, as this is a terrible way to handle
padding in any case. I spent an hour or so coming up with a simpler,
integer method for doing the same thing, and then happened upon a
functionally identical method _in the #^@%& ISO spec_!!! That's right,
ISO/IEC 11172-3, p.22 gives a perfectly reasonable algorithm, which the ISO
code _does not use_. And the FhG code is (probably) a branch off of the ISO
code.
I haven't looked at this issue in the Lame source; I hope someone else
has...
Alex
> > I searched the archives and I don't think this has been mentioned
> > before.
> > I downloaded mp3encdemo31 [0] onto two 450Mhz pIII computers with
> > identical hardware, one running NT4, one running red hat linux 6.0.
> >
> > The NT version seems about twice as fast, and they output
> different mp3s
> > even if the quality setting is specified. But you'd think
> they were the
> > same as they both output the same version info:
> <snip>
> > Thanks,
> > Sidi
>
> for the speed difference:
> they used different compilers on both systems,
> with different settings
>
> for the file difference:
> they maybe didn't configure the compilers
> to use IEEE floating point numbers
>
> Robert
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
