My earlier post regarding the dither problem in Csound5 was started before I found out there is no dither currently in Csound5. While it has been implied that dither is not needed on a floating point system, that viewpoint is at odds with the following from the renowned mastering engineer Bob Katz: 

"But one programming mistake, or a few cost-saving shortcuts, can ruin ether fixed or floating point work, especially if shortcuts are taken at the most critical time, when the final output number is converted to fixed point 24 bit at the end. If those numbers are not converted (and properly dithered to 24 bits) at that time, then the sound of the entire system can be compromised."

  Bob Katz "Fixed versus Floating Point Notation" (an answer to a question on his Audio FAQ)

"When feeding processors, DAWs or digital mixers to your recording unit, dither the output of the processor to a 24-bit word. Dithering always sounds better than truncation without dither."  

Bob Katz' article "Dither"  Full article at:  http://www.digido.com

So the real problem is more accurately a truncation problem.

As the contention is about dithering floating point, I e-mailed Bob Katz with the following question:

Jim Bates wrote:

> My earlier post regarding the dither problem in Csound5 was started  
> before I found out there is no dither currently in Csound5. While it  
> has been implied that dither is not needed on a floating point  
> system,

If the audio stays in floating point that is 100% correcct.

The only time it *may* be worthwhile dithering is when converting from
floating point to integer (8, 16 or 24 bit integer) formats, or when
converting from a higher bitwidth integer to a smaller bit width integer.

> that viewpoint is at odds with the following from the  
> renowned mastering engineer Bob Katz:
> 
> "But one programming mistake, or a few cost-saving shortcuts, can  
> ruin ether fixed or floating point work, especially if shortcuts are  
> taken at the most critical time, when the final output number is  
> converted to fixed point 24 bit at the end. If those numbers are not  
> converted (and properly dithered to 24 bits) at that time, then the  
> sound of the entire system can be compromised."

Saying that when converting from float to 24 bit integer PCM without
dither "then the sound of the entire system can be compromised." is
*vastly* overstating the case.

For 24 bit audio the audio samples range from -8388608 to 8388607
and the dither that is added (before truncation) is at most about
-2.0 to 2.0 (I've been generous here) with reference to the range
-8388608 to 8388607.

That means that the level of the dither is

    20 * log10 (2 / 8388607)

which is -132dB below the reference level. I repeat, there is no
digital-to-analogue converter on the market today that comes
anywhere near this in signal to noise ratio.

Remeber what the dither is there for. Its added noise which masks
low level artifacts that are the result of truncation. When the
dither is at -132dB, the stuff that it is masking is below that.

If you look at this:

    http://en.wikipedia.org/wiki/Sound_pressure#Examples_of_sound_pressure_and_sound_pressure_levels

with 0db being the threshold of hearing, 120dB is where you start
getting hearing damager and 130dB is the threshold of pain.

> As the contention is about dithering floating point, I e-mailed Bob  
> Katz with the following question:
> 
> Do you know of any current (or past) algorithm for dithering floating  
> point audio files?
> 
> Here is his reply:
> 
> Floating point is not the ideal medium for dithering as you don't  
> know where the reference level is, it's "floating" :-).  Some people  
> argue (probably correctly) that dithering makes no sense with  
> floating point. So most algorithm designers convert to fixed point  
> and then dither.  Does that answer your question?

Thats a totally appropriate answer to someone who may not know
how numbers are represented in floating point, but it is far
from a definitive answer.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"C++ is an atrocity, the bletcherous scab of the computing world,
responsible for more buffer overflows, more security breaches,
more blue screens of death, more mysterious failures than any
other computer language in the history of the planet Earth."
-- Eric Lee Green

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Erik de Castro Lopo wrote:
..
> For 24 bit audio the audio samples range from -8388608 to 8388607
> and the dither that is added (before truncation) is at most about
> -2.0 to 2.0 (I've been generous here) with reference to the range
> -8388608 to 8388607.
> 
> That means that the level of the dither is
> 
>     20 * log10 (2 / 8388607)
> 
> which is -132dB below the reference level. I repeat, there is no
> digital-to-analogue converter on the market today that comes
> anywhere near this in signal to noise ratio.
> 

As an example I have here, my M-Audio Firewire 410  cites a dynamic 
range of 108dB; i.e. the quiescent noise is significantly above what 
would be the 24bit dither level. Top-level systems may manage 120dB, and 
top-end mic preamps may even cite a range of 130dB - still above the 
theoretical 24bit dither level. To improve on that would need 
liquid-cooled circuitry  (and probably liquid-cooled ears and 
loudspeakers too).

A simple answer to all this is to use f/p soundfiles ~always~, and 
reduce to 24bit (or 16bit) only at the very end, as part of the final 
mastering stage (or output to speakers).  Note that normalized 32bit f/p 
actually gives you an equivalent 25bit  range  (the format provides what 
is referred to as a "hidden bit").  The best dithering we can reasonably 
expect in Csound is plain TPDF (triangular); which is actually pretty 
good. Commercial mastering tools will offer more sophisticated (and 
mostly proprietary) noise-shaped dither. Until such time as users 
seriously expect to send the output of perf directly to CD manufacture, 
i.e. do all final mastering in Csound itself,  all we really need is 
some token dither for direct audio rendering.  Windows  already adds 
tpdf dither to audio streamed through the kernel mixer, and I think OS X 
CoreAudio does something very similar. SO if dither is added to Csound, 
  it must be possibel to turn it off. There is of course absolutely no 
reason to reduce to 16bit for rendering, these days, unless you are 
still using SoundBlasters, in which case of course the analog dynamic 
range still comes to your rescue.


In short, you may need to deliver in 24bits (or 16 bits for the 
venerable CD etc), but  work in progress should always be kept as at 
least 32bit f/p.  We have no excuses  with regard to file sizes these 
days, except for high channel counts and high sample rates, and even 
WAVE itself can support 64bit doubles (I am pretty certain libsndfile 
supports that - Eric?).

People  can practise this radical worldview by setting 0dbfs=1 in all 
their orc files, rather than the historical but otherwise pointless and 
irrelevant 32768!

Richard Dobson


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Richard Dobson wrote:

> The best dithering we can reasonably 
> expect in Csound is plain TPDF (triangular); which is actually pretty 
> good.

I do mean to (optionally) add the ability to dither appropriate
conversions to libsndfile at some time. Unfortunately, my spare
time is rather limited.

> We have no excuses  with regard to file sizes these 
> days, except for high channel counts and high sample rates, and even 
> WAVE itself can support 64bit doubles (I am pretty certain libsndfile 
> supports that - Eric?).

Yes, libsndfile supports writing IEEE double floats to WAV, AIFF, AU
and a number of other formats.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Indeed, I am impressed that Google runs an 8,000 node Linux
cluster, 5 data centers, an extensive network, and a rapidly
evolving application all with a staff of 12."
  -- http://research.microsoft.com/~gray/papers/FAAMs_HPTS.doc

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net