On Mon, 18 Oct 1999, DAVID BALAZIC wrote:
> >From: Takehiro Tominaga <[EMAIL PROTECTED]>
[...]
> >An input file (like .wav file) has only 16 bit precision and dynamic
> >range(this value is selected from human hearing ability). And the
> >IEEE768 says single precision has 24 bit precision.
> >
> >Current release of lame is mixed use of FLOAT(=float) and double.
> >I think this is not good because it takes type conversion.
> >
> >See my version of lame. I changed all "double" into "FLOAT".
> >And we can select FLOAT from double and float depending on your
> >architechture. I think some architechtuer, like ALPHA chip, we will
> >get faster conversion defining FLOAT as double. On my linuxbox with
> >celeron 464MHz, I got about 10% speedup from defining FLOAT as float.
>
> AFAIK , C compilers do all floating point operations with doubles,
> even when adding two floats they are converted to doubles and then
> the result is converted back to float, so using doubles should be faster,
> but modern compilers may behave differently.
>
Is double not a good/ the needed thing for high quality/accuracy; if I
remember correctly IEEE-float only has 23 mantissa bits, which is an
accuracy of only approx 1e-7 or 1e-6 ?
Making sum/multiply loops collects these errors into ""considerable""
worst case error ?
And, if you look at the anal.window filtercoeffs they are specified with
1e-9 accuracy.
But ???, final quantization of the sbsamples/freq lines degrades anything
to only-less-than-float-remaining accuracy anyway ? So why worry ?
Or, should a "theoretical" investigation still be done ? But, maybe this
would a waste of time, sound quality is the only thing that counts ???
I don't know, only my $0.02 questions and doubts.
regards,
Patrick.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
