TPDF dither should have a peak amplitude twice that of RPDF-dither, if not it won't work according to the theory (remove harmonics and noise-power modulation caused by quantizing).

Denote the quantizer step size Q. If the quantizer re-quantizes from 16 to 8 bits, Q is 255 lsb's referred to the quantizer's 16-bit input.

It can be proved mathematically that if dither is used with an RPDF-distribution of width Q, i.e. +/-0.5*Q, the first statistical moment of the error (error mean) is rendered conditionally independent of the input signal. Since the error mean is rendered input independent => no harmonic distortion.

It can further be proved that TPDF dither will render the first and second error moments conditionally independent of the input (mean and variance), but only if the PDF has a triangular distribution of width +/-Q. Since the error variance is also rendered input independent => no noise power modulation.

Using RPDF dither of less width than +/-0.5*Q will not make the first error moment conditionally input-independent. It will reduce distortion, but not eliminate it.

Using TPDF dither of width +/-0.5*Q will render neither the first nor the second error moment conditionally input-independent. TPDF dither of width +/-0.5*Q will in all likelyhood perform worse than RPDF dither of width +/-0.5*Q. I have not looked at the math for this case, but I'm quite sure one is better off using the right amount of RPDF than the wrong amount of TPDF.

It's much easier to get the right levels if the scaling is consistently referred to the quantizer step size. Then there is only one reference "size" to deal with. RPDF: +/-0.5*Q, TPDF: +/-Q. IIRC, if N RPDF sources of +/-0.5Q are added, the first N error moments are rendered conditionally independent of the input. But the added noise power increases and Wannamaker did listening tests showing that only the first and second error moments, mean and variance, are audible. The third and fourth statistical moments of a PDF are skew and kurtosis.

@ilo,

that sounds quite interesting, but honestly, it's a bit over the top of my head. Especially the phrase "Q is 255 lsb's referred to the quantizer's 16-bit input" just makes me confused. Would you mind posting a line of source code (doesn't matter which programming language) which does proper TPDF, so that those of us who are not mathematical masterminds can still understand how to do it correctly?

Thanks much!!!

In this case it isn't. It was not clear from your post what you were comparing. I thought you were comparing
" (rand(256)-rand(256)) >> 4 " versus " rand(16)-rand(16) "
Their distributions differ.


You're right. They are mathmatically equivalent. Pick your favorite.

Cheers!
SG

@ madshi:

I think the stuff already posted will do the trick, although the rand functions are probably only so-so PRNG's (most material on PRNG quality seems to be found in the computer security literature). I don't have any code readily available, I just tried to clarify what appears to be an issue of confusion without going much into the maths.

What I meant with the confusing (?) sentence is that one quantizer step, that is one LSB at the quantizer's (8-bit) output, equals 255 LSB's at the quantizer's (16-bit) input. And that the quantizer step size is what matters WRT to dither PDF width.

Thanks!


Ok. The bit of your post where I'm stumbling is how to correctly translate the "LSB" stuff into the right random range. Could you please check if the following is correct?

If I want to reduce bitdepth of an audio track from 24bit to 20bit, I'm doing this:

(1) add a random value of [0..15] (where 0 and 15 are possible random values)
(2) substract a random value of [0..15]
(3) round down to 20bit

Are these the correct random ranges? Right now I'm not totally sure whether it should be 0..15 or 0..16.


I have some random functions from security related code, so that should be fine.

It should be 0..16 as that is (0.0 .. 1.0) x 2^4. If you use 15 then your amplitude is only 15/16.

Well, I could switch to floating point, but IIRC the random function I'm planning to use (which is better than the usual RTL function) is based on integer, too.

If you're really wanting to use integers, why not shift your 24 bit sample left 8 bits and add a random number (0.. 2^12) then subtract another? This would give 4096 x 4096 possible outcomes rather than 16 x 16. Then shift right 12 bits.

Yes, I was planning to do something like that (haven't decided on the details yet). I've written about [0..15] just to make things easier to understand.