These issues do not have any effect on the quality of the mp3's,
but they do make it hard to validate a compiled version of
lame. Using different compilers or just different
optimizations or OS's will produce different results.
This is why LAME has the "--nores" option.
It will disable the bitreservoir (also very senstive to
small differences in rounding) and disable all padding.
If you create two mp3s with this option, the output should
be close to identical.
if you run "make test" in the lame source code directory, it
will run such a test, and compare your mp3 with the "official"
mp3. It compares them with:
cmp -l file1.mp3 file2.mp3 | wc
and the first number output is the number of bytes where the
files differ. It should be zero, or very small.
Mark
(and yes, LAME still uses the original dist10 padding algorithm :-)
>
> 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/ )
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
