Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: Iain Sandoe (iain_AT_sandoe.co.uk)
Date: Wed Mar 22 2000 - 18:02:41 EET
>
>>> I'd like to see a real world example where you have a signal that is full 24
>>> bits peak to peak and you can hear some distortion in the low 4 bits.
>>> Because other than full scale peak to peak signals you will not lose the
>>> lower bits using 32 bit FP.
>>
>> Very true, but sadly irrelevant. As Bill Gribble put it to me: the
>> bits-in == bits-out test is fundamental. If you can't record a digital
>> data stream and reproduce it bit-for-bit, then you're in trouble from
>> the start. a 32 bit float is in extreme danger of failing to do this
>> if there are any attempts at symmetric transforms on 24 bit integer
>> data that require use of the exponent in an intermediate value. Given
>> the tendency of engineers to want to do tracking with a hot signal, it
>> doesn't take much to get a 24 bit signal to the point where mixing,
>> say, 10 of them together gets a value that when doubled, exceeds the
>> capacity of the mantissa. When you halve it again, there's a good
>> chance that bits-in != bits-out.
>
> (Doubling and halving have no effect on the mantissa at all...?)
>
> I still think that the only reason we have a 24 bit integer is to overcome
> the limitations in SNR of integer signals at low amplitude. So lower order
> bits on full scale signals are irrelevant. They can be lost with no loss of
> quality. It is the very quiet signals in the 24 bit integer format that
> cause the loss of quality. and that happens before you get into FP.
If LADSPA is to be usable for 'other' apps (e.g. instrumentation - for which
there was a thread on either this or the ASLA list), this could be a
requirement anyway - it IS possible to achieve real microphone/acquisition
systems that approach 24 bits - although we are in the realms of
instrumentation gear mostly, I think.
It is definitely my intention to make scientific/instrumentation apps for
Linux - in addition to the more usual studio types - so I would like to see
the option of wider number formats supported.
Apropos dynamic range:
In my previous existence we found the following two terms quite helpful to
avoid ambiguity:
1/
Instantaneous dynamic range: In the case of 32 FP 24 bits [140-ish dB -
knock off what you will for a sensible representation]
The ability to represent a small signal faithfully in the presence of a
larger one... (applies even if there is no noise other than the quantization
noise).
This is usually what really matters to DSP processes.
2/
Total Dynamic Range: the ability of the representation to accommodate widely
differing signal levels: In the case of 32 bit fp [+/- 10**38 => 1520 dB or
did I slip on the calculator ;-)]....
This makes silly specifications for fp numbers - but has more sensible roots
in AGC systems.
for any (non-denormalised) 32bit fp number the instantaneous dynamic range
stays at 24 bits - assuming you haven't lost some owing to numerical issues
in a process you are applying.
This terminology also works OK with systems with AGC - like the ear ;-)
Iain.
This archive was generated by hypermail 2b28 : Wed Mar 22 2000 - 16:51:50 EET