DSPRelated.com
Forums

Dthering....

Started by Piergiorgio Sartor October 10, 2003
> Jon Harris wrote: > > [...] > > In audio, dithering can be used to make "digital" sound more like "analog". > > Consider a fading out (decaying) sine wave. When recorded on analog tape, > > the signal gets progressively softer until it dips below the noise floor. > > Regardless of the level, it always sounds like a sine wave + noise. With > > (undithered) digital, as the number of available bits diminishes, the sine > > wave starts to look more and more like a triangle or square wave. This > > sounds like a distorted sine wave (often described as "grainy"),
actually (really IMBO), the distorted, undithered sine wave (fading into the LSB of the undithered quantizer) sounds more "cool" distorted (as in buzz) than "grainy" but other more complex audio would not sound very good at all (like quiet or soft sections in classical music) and that can be called "really bad" or "crappy" or "grainy" or a any of a bunch of other descriptions. ...
> > Adding appropriate dither makes it again sound like a sine wave + noise.
Randy Yates <yates@ieee.org> wrote in message news:<iniib.24587$Eo2.10343@newsread2.news.atl.earthlink.net>...
> > I would say that anyone who isn't using dither when digitizing a signal > isn't doing digital "right."
unless there is something inherent in the algorithm function that it does no quantization. two examples: moving sum (not average) filter or a mean-square function that returns a double word width relative to that of the input and window coefs.
> There is no difference between digital and analog as long > as sample rate and resolution are chosen so that bandwidth > and SNR are the same (or better) as the analog counterpart.
oh, i dunno, Randy. i am skeptical of the notion of every analog function that is good to just under Fs/2 being identical to a digital function that sampled at Fs. maybe if you left out things like resources related to filter order (number of delay elements vs. number of integrators), then you could probably *virtually* emulate every well-defined analog function with a digital one. i mean the s->z mapping (e.g. bilinear) for equal order non-oversampled linear filters is one counter-example. ain't it? r b-j "B" stands for Biased.
robert bristow-johnson wrote:

>>Jon Harris wrote: >> >>>[...] >>>In audio, dithering can be used to make "digital" sound more like "analog". >>>Consider a fading out (decaying) sine wave. When recorded on analog tape, >>>the signal gets progressively softer until it dips below the noise floor. >>>Regardless of the level, it always sounds like a sine wave + noise. With >>>(undithered) digital, as the number of available bits diminishes, the sine >>>wave starts to look more and more like a triangle or square wave. This >>>sounds like a distorted sine wave (often described as "grainy"), > > > actually (really IMBO), the distorted, undithered sine wave (fading > into the LSB of the undithered quantizer) sounds more "cool" distorted > (as in buzz) than "grainy" but other more complex audio would not > sound very good at all (like quiet or soft sections in classical > music) and that can be called "really bad" or "crappy" or "grainy" or > a any of a bunch of other descriptions. > ... > >>>Adding appropriate dither makes it again sound like a sine wave + noise. > > > > Randy Yates <yates@ieee.org> wrote in message news:<iniib.24587$Eo2.10343@newsread2.news.atl.earthlink.net>... > >>I would say that anyone who isn't using dither when digitizing a signal >>isn't doing digital "right." > > > unless there is something inherent in the algorithm function that it > does no quantization. two examples: moving sum (not average) filter > or a mean-square function that returns a double word width relative to > that of the input and window coefs.
Wouldn't dither be useful in these examples too? E.g., in the moving sum, not dithering may hide an offset that is < 1/2 LSB that would otherwise be picked up. No?
>>There is no difference between digital and analog as long >>as sample rate and resolution are chosen so that bandwidth >>and SNR are the same (or better) as the analog counterpart. > > > oh, i dunno, Randy. i am skeptical of the notion of every analog > function that is good to just under Fs/2 being identical to a digital > function that sampled at Fs.
You misunderstood the intention of my remark. I meant that, as a medium, there is no difference between analog and digital. There certainly can be differences in processing methods. maybe if you left out things like
> resources related to filter order (number of delay elements vs. number > of integrators), then you could probably *virtually* emulate every > well-defined analog function with a digital one. i mean the s->z > mapping (e.g. bilinear) for equal order non-oversampled linear filters > is one counter-example. ain't it?
Yes. As I said, I didn't intend for the remark to apply in this sense. However, who said we had to compare integrators to delays? -- % Randy Yates % "...the answer lies within your soul %% Fuquay-Varina, NC % 'cause no one knows which side %%% 919-577-9882 % the coin will fall." %%%% <yates@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO http://home.earthlink.net/~yatescr
In article Xi6jb.56767$mQ2.43304@newsread1.news.atl.earthlink.net, Randy
Yates at yates@ieee.org wrote on 10/15/2003 03:03:

>> Randy Yates <yates@ieee.org> wrote in message >> news:<iniib.24587$Eo2.10343@newsread2.news.atl.earthlink.net>... >> >>> I would say that anyone who isn't using dither when digitizing a signal >>> isn't doing digital "right." >> >> >> unless there is something inherent in the algorithm function that it >> does no quantization. two examples: moving sum (not average) filter >> or a mean-square function that returns a double word width relative to >> that of the input and window coefs. > > Wouldn't dither be useful in these examples too? E.g., in the moving > sum, not dithering may hide an offset that is < 1/2 LSB that would > otherwise be picked up. No?
how would that offset exist in the moving sum filter? i am assuming that there is no quantization. is my assumption faulty? r b-j (finally home and detoxing from AES trip to NYC. and i didn't get killed in the ferry accident, but the wind was so bad that the wingtip of the Jet Blue A-320 came within 12" of the ground upon landing at Burlington.)
On Mon, 13 Oct 2003 21:55:32 -0400, Jerry Avins <jya@ieee.org> wrote:

>Eric Jacobsen wrote: > >> >>> >>>The process is similar to remainder saving when accumulating the results >>>of successive divisions. We played with that one in a thread some time >>>ago. R.B-J. described the process as a way to avoid limit cycles in >>>IIRs, I described its use in a lossy accumulator (same thing, really), >>>and Randy Yates provided the name. I think it should work wherever >>>truncation is needed. Call it "noise shaping" if you like, except >>>there's no oversampling. >> >> >> In practice I usually handle this by rounding after truncating, in >> other words, add the LSB-1 bit to the new LSB. This goes a long way >> toward eliminating bias, etc., and reducing truncation errors. >> >> >Don't you mean add the MSB of the truncated part to the LSB of what's >left?
Yes, I'm calling the MSB of the lopped-off part LSB-1 relative to the new, truncated word. Does that makes sense? In other words, I think we're talking about the same bit.
>Adding the whole remainder does the same thing, but sometimes rounds up >when your way wouldn't', sometimes actually rounds down, and in general >makes the average error (DC) exactly zero. You must have read >http://www.dspguru.com/comp.dsp/tricks/alg/dc_block.htm Am I mistaken >that it applies here? > >Jerry
I seem to recall proving to myself long ago that only the one bit below the new LSB (your MSB) matters in this rounding process. The rest are "don't cares" unless some further means to use (and accumulate) them is afforded (I think rb-j's feeback method is one, but I almost never use feedback). Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://www.ericjacobsen.org
Eric Jacobsen wrote:

> ... I think we're talking about the same bit.
Yes.
> >>Adding the whole remainder does the same thing, but sometimes rounds up >>when your way wouldn't', sometimes actually rounds down, and in general >>makes the average error (DC) exactly zero. You must have read >>http://www.dspguru.com/comp.dsp/tricks/alg/dc_block.htm Am I mistaken >>that it applies here? >> >>Jerry > > > I seem to recall proving to myself long ago that only the one bit > below the new LSB (your MSB) matters in this rounding process. The > rest are "don't cares" unless some further means to use (and > accumulate) them is afforded (I think rb-j's feeback method is one, > but I almost never use feedback).
Adjusting according to the MSB of the lopped part only is feedback too. If you don't save the rest for later, one bit is the best you can do, as you concluded. I first ran into this when accumulating energy over a long period of time to calculate the internal temperature of a motor accurately enough to know when to shut it down. 16-bit integer quotient wasn't precise enough. The values calculated with rounding showed a random walk away from The One True Value. Mr. Fixit -- me -- got called in, and I came up with the scheme of accumulating the entire 8-bit remainder, and adjusting the accumulated quotient whenever the remainder register overflowed. (Two's complement with truncating toward negative infinity makes that easy -- no need to round.) That's why I called it "remainder saving" until Randy's more general "fraction saving" came to my attention. However you look at it, it keeps all of the information in the original signal as quantized, instead of giving some away in the gain divider. When forcing the signal to fewer bits, it keeps the original precision on average, yielding the closest possible to how the signal would have looked had it been originally sampled with the lower bit count. Had this been clear to me before, I would have trumpeted it loudly. It was just one of those things I knew in another context and didn't think much about. After all, it was a quick and dirty trick I dreamed up in the days before you guys taught me DSP. That said, I'm convinced of its utility. I think we're onto something. Jerry -- When a discovery is new, people say, "It isn't true." When it becomes demonstrably true, they say, "It isn't useful." Later, when its utility is evident, they say, "So what? It's old." a paraphrase of William James &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
robert bristow-johnson wrote:

> In article Xi6jb.56767$mQ2.43304@newsread1.news.atl.earthlink.net, Randy > Yates at yates@ieee.org wrote on 10/15/2003 03:03: > > >>>Randy Yates <yates@ieee.org> wrote in message >>>news:<iniib.24587$Eo2.10343@newsread2.news.atl.earthlink.net>... >>> >>> >>>>I would say that anyone who isn't using dither when digitizing a signal >>>>isn't doing digital "right." >>> >>> >>>unless there is something inherent in the algorithm function that it >>>does no quantization. two examples: moving sum (not average) filter >>>or a mean-square function that returns a double word width relative to >>>that of the input and window coefs. >> >>Wouldn't dither be useful in these examples too? E.g., in the moving >>sum, not dithering may hide an offset that is < 1/2 LSB that would >>otherwise be picked up. No? > > > how would that offset exist in the moving sum filter? i am assuming that > there is no quantization. is my assumption faulty? > > r b-j > > (finally home and detoxing from AES trip to NYC. and i didn't get killed in > the ferry accident, but the wind was so bad that the wingtip of the Jet Blue > A-320 came within 12" of the ground upon landing at Burlington.) >
Divide by N? Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
In article bmkvk1$sfj$2@bob.news.rcn.net, Jerry Avins at jya@ieee.org wrote
on 10/15/2003 22:26:

> robert bristow-johnson wrote: > >> In article Xi6jb.56767$mQ2.43304@newsread1.news.atl.earthlink.net, Randy >> Yates at yates@ieee.org wrote on 10/15/2003 03:03: >> >> >>>> Randy Yates <yates@ieee.org> wrote in message >>>> news:<iniib.24587$Eo2.10343@newsread2.news.atl.earthlink.net>... >>>> >>>> >>>>> I would say that anyone who isn't using dither when digitizing a signal >>>>> isn't doing digital "right." >>>> >>>> >>>> unless there is something inherent in the algorithm function that it >>>> does no quantization. two examples: moving sum (not average) filter >>>> or a mean-square function that returns a double word width relative to >>>> that of the input and window coefs. >>> >>> Wouldn't dither be useful in these examples too? E.g., in the moving >>> sum, not dithering may hide an offset that is < 1/2 LSB that would >>> otherwise be picked up. No? >> >> >> how would that offset exist in the moving sum filter? i am assuming that >> there is no quantization. is my assumption faulty? >>
> Divide by N?
then it would be a moving *average*, not a moving sum. of course the moving average would normally have quantization and dithering and/or noise-shaping would be useful, but if there is no quantization in a digital operation, why would either dithering or noise-shaping be necessary? r b-j
robert bristow-johnson wrote:

> In article bmkvk1$sfj$2@bob.news.rcn.net, Jerry Avins at jya@ieee.org wrote > on 10/15/2003 22:26: > >
...
> > >>Divide by N? > > > then it would be a moving *average*, not a moving sum. of course the moving > average would normally have quantization and dithering and/or noise-shaping > would be useful, but if there is no quantization in a digital operation, why > would either dithering or noise-shaping be necessary? > > r b-j >
Why? It wouldn't. Sometimes -- this is one of them, -- I see what I'm thinking, instead of what's on the page. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
A neat extension gives you more control over the effect of this dithering:
First, make a minimum phase hi-pass filter and calculate its impulse
response.  Then, before quantizing a sample, add that response to the
pending input, scaled to make the quantization error come out to zero for
the current sample before you quantize it.  When you're finished with all
the input, you know that the total error you added to the signal had no
low-frequency components, because you explicitly constructed it out of
high-pass responses.  Many sigma-delta modulators can be characterized this
way.



This is a multi-part message in MIME format.
--------------060709020103080707070008
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

robert bristow-johnson wrote:

>eric.jacobsen@delete.ieee.org (Eric Jacobsen) wrote in message news:<3f8b2809.432701556@news.west.earthlink.net>... > > >>On Sun, 12 Oct 2003 01:12:58 -0400, Jerry Avins <jya@ieee.org> wrote: >> >> >> >>>Eric Jacobsen wrote: >>> >>> >> >> >> >>>>Jerry, you've stumped me. What's "fraction saving"? >>>> >>>> > >the way i would describe it is: 1st-order noise shaping with a zero >exactly on z=1 and the quantizer is always in round-down (floor(x)) >mode. as Jerry says, it is taking whatever bits your quantizer >dropped, zero extending them, then feeding them back (positively) and >adding them into the next sample before it is quantized. > > > > >>>The process is similar to remainder saving when accumulating the results >>>of successive divisions. We played with that one in a thread some time >>>ago. R.B-J. described the process as a way to avoid limit cycles in >>>IIRs, I described its use in a lossy accumulator (same thing, really), >>>and Randy Yates provided the name. I think it should work wherever >>>truncation is needed. Call it "noise shaping" if you like, except >>>there's no oversampling. >>> >>> > >it is "noise-shaping". > >r b-j > >
Robert, Taking Jerry's description and your comments together, particularly the comment about 'noise-shaping', it occurs to me that the process is virtually the same as delta modulation. Granted, the quantisation will probably be 16 bits, whereas delta modulation quantisation is commonly one bit, but apart from that, all the elements are the same. The main difference is that the high-precision signal sample is already digital instead of analog, so I refer to it as 'analog-ish'. The process as described is: 1. The high-precision ('analog-ish') signal sample is quantised. 2. The exact value of the quantised sample is subtracted from the high-precision ('analog-ish') sample. 3. The quantised part is stored or transmitted. 4,. The difference, or 'error' is saved ('integrated'). 5. The next high-precision signal sample is then added to the integrated error and the process repeats. I like the idea that Jerry describes of not discarding the left-over bits when you truncate, and it appears to be a big improvement on simple rounding, with or without dithering. Regards, John --------------060709020103080707070008 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> robert bristow-johnson wrote:<br> <blockquote type="cite" cite="mid4cbb922e.0310140622.33673e6c@posting.google.com"> <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:eric.jacobsen@delete.ieee.org">eric.jacobsen@delete.ieee.org</a> (Eric Jacobsen) wrote in message news:<a class="moz-txt-link-rfc2396E" href="mailto:3f8b2809.432701556@news.west.earthlink.net">&lt;3f8b2809.432701556@news.west.earthlink.net&gt;</a>... </pre> <blockquote type="cite"> <pre wrap="">On Sun, 12 Oct 2003 01:12:58 -0400, Jerry Avins <a class="moz-txt-link-rfc2396E" href="mailto:jya@ieee.org">&lt;jya@ieee.org&gt;</a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Eric Jacobsen wrote: </pre> </blockquote> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Jerry, you've stumped me. What's "fraction saving"? </pre> </blockquote> </blockquote> </blockquote> <pre wrap=""><!----> the way i would describe it is: 1st-order noise shaping with a zero exactly on z=1 and the quantizer is always in round-down (floor(x)) mode. as Jerry says, it is taking whatever bits your quantizer dropped, zero extending them, then feeding them back (positively) and adding them into the next sample before it is quantized. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">The process is similar to remainder saving when accumulating the results of successive divisions. We played with that one in a thread some time ago. R.B-J. described the process as a way to avoid limit cycles in IIRs, I described its use in a lossy accumulator (same thing, really), and Randy Yates provided the name. I think it should work wherever truncation is needed. Call it "noise shaping" if you like, except there's no oversampling. </pre> </blockquote> </blockquote> <pre wrap=""><!----> it is "noise-shaping". r b-j </pre> </blockquote> Robert, <br> Taking Jerry's description and your comments together, particularly the comment about 'noise-shaping', <br> it occurs to me that the process is virtually the same as delta modulation.&nbsp; <br> <br> Granted, the quantisation will probably be 16 bits, whereas delta modulation quantisation<br> is commonly one bit, but apart from that, all the elements are the same.&nbsp; The main difference is that the<br> high-precision signal sample is already digital instead of analog, so I refer to it as 'analog-ish'.<br> <br> The process as described is:<br> 1.&nbsp; The high-precision ('analog-ish') signal sample is quantised.<br> 2.&nbsp; The exact value of the quantised sample is subtracted from the high-precision ('analog-ish') sample.<br> 3.&nbsp; The quantised part is stored or transmitted.<br> 4,.&nbsp; The difference, or 'error' is saved ('integrated').&nbsp; <br> 5.&nbsp; The next high-precision signal sample is then added to the integrated error and the process repeats.<br> <br> I like the idea that Jerry describes of not discarding the left-over bits when you truncate, and it<br> appears to be a big improvement on simple rounding, with or without dithering.<br> <br> Regards,<br> John<br> <br> <br> </body> </html> --------------060709020103080707070008--