Chris Sidi schrieb am Son, 11 Jun 2000:
> In my case, the CPUs are identical (at least they should be - I should
> double check the company who built them got it right), only the platforms
> (and I guess the compilers used) are different. Do different platforms
> get slightly different results fo
On Fri, 9 Jun 2000, Alex Broadhead wrote:
> 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)
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
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 wou
> 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
> ev
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 qual
