DSPRelated.com
Forums

DC offset when truncating signal

Started by dtsao March 14, 2007
Why is it that a small DC offset appears when I truncate a 2'compliment
signal? (My signal is 28 bits, I and take the top 12 bits)
Also, what is the best way to avoid or get rid of this DC offset?
dtsao wrote:
> Why is it that a small DC offset appears when I truncate a 2'compliment > signal? (My signal is 28 bits, I and take the top 12 bits) > Also, what is the best way to avoid or get rid of this DC offset?
Consider the nature of 2's complement numbers. Truncation either leaves them intact or makes them algebraically smaller. It would be an unusual series of numbers that didn't accumulate a negative offset as a result of truncation. (If your offset is positive, write a paper about it.) Clearly, the offset can't be avoided if you must truncate. If you can round, you're home free. To round, add 32,768 before truncating. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
On Mar 14, 6:33 pm, Jerry Avins <j...@ieee.org> wrote:
> dtsao wrote: > > Why is it that a small DC offset appears when I truncate a 2'compliment > > signal?
because truncating, all by itself, is always adding a non-positive number (whatever number you have to add to make those bottom bits go to zero). if you're adding a number that is nearly always negative (and very rarely zero, but never positive), you are adding a signal with a DC component.
> (My signal is 28 bits, I and take the top 12 bits) > > Also, what is the best way to avoid or get rid of this DC offset?
rounding is okay, but i would recommend "fraction saving" a.k.a. "first-order noise shaping with a zero at z=1". in this quantization technique, whatever bits you drop (in your lower 16 bits) when truncating, you put into a memory state and add those bits in (zero extended to the left) the next sample before that sample is truncated.
> Consider the nature of 2's complement numbers. Truncation either leaves > them intact or makes them algebraically smaller. It would be an unusual > series of numbers that didn't accumulate a negative offset as a result > of truncation. (If your offset is positive, write a paper about it.) > > Clearly, the offset can't be avoided if you must truncate.
that is truncating and doing nothing else. rounding is, as Jerry pointed out, adding a constant (which is positive and likely virtually equal in magnitude to the mean DC offset from truncating) before truncating. r b-j
robert bristow-johnson wrote:
> On Mar 14, 6:33 pm, Jerry Avins <j...@ieee.org> wrote:
...
>> Clearly, the offset can't be avoided if you must truncate. > > that is truncating and doing nothing else. rounding is, as Jerry > pointed out, adding a constant (which is positive and likely virtually > equal in magnitude to the mean DC offset from truncating) before > truncating.
It turns out to be very nearly the offset. To compute it, when lopping off k bits, first add 2^(k-1). I.e., add 1 to the most significant of the removed bits. Fraction saving works well, but the extra complexity compared to adding a pre-compiled constant hasn't been justifies in any application I've had. Jerry -- Engineering is the art of making what you want from things you can get. &macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;
Jerry Avins wrote:

> robert bristow-johnson wrote: > >> On Mar 14, 6:33 pm, Jerry Avins <j...@ieee.org> wrote: > > > ... > >>> Clearly, the offset can't be avoided if you must truncate. >> >> >> that is truncating and doing nothing else. rounding is, as Jerry >> pointed out, adding a constant (which is positive and likely virtually >> equal in magnitude to the mean DC offset from truncating) before >> truncating. > > > It turns out to be very nearly the offset. To compute it, when lopping > off k bits, first add 2^(k-1). I.e., add 1 to the most significant of > the removed bits. > > Fraction saving works well, but the extra complexity compared to adding > a pre-compiled constant hasn't been justifies in any application I've had. > > Jerry
Simple rounding (add 0.5 and truncate) doesn't completely eliminate the DC bias either, but it does make it much smaller. The remaining offset is due to rounding of numbers with fractional parts exactly equal to 0.5. Since 0.5 is equally far from 0 and 1 and simple rounding always adds 0.5 you get a bias equal to weight of the LSB of the data before rounding. You can eliminate that small remaining bias by either rounding to even or odd (round 0.5 up, 1.5 down) or by using symmetric rounding where positive numbers round 0.5 up and negative numbers round 0.5 down. The latter is easier to do in hardware, but is also sensitive to having a balance between positive and negative values (ie no DC bias in the signal). IEEE floating point does a symmetric round naturally because the significand is represented as a sign-magnitude value rather than 2's complement.
Ray Andraka wrote:

> Simple rounding (add 0.5 and truncate) doesn't completely > eliminate the DC bias either, but it does make it much smaller.
> You can eliminate that small remaining bias by either rounding > to even or odd (round 0.5 up, 1.5 down) or by using symmetric > rounding where positive numbers round 0.5 up and negative > numbers round 0.5 down.
> IEEE floating point does a symmetric round naturally because the > significand is represented as a sign-magnitude value rather than > 2's complement.
From http://docs.hp.com/en/B3906-90006/go01.html#d0e21238 : | rounding mode | | One of four rounding methods specified by the IEEE standard: | round to nearest (the default), round toward +INFINITY, | round toward -INFINITY, and round toward zero. Where "to nearest" really means "to nearest with even LSB". Martin -- Quidquid latine scriptum est, altum videtur.
On Mar 15, 5:44 pm, Martin Eisenberg <martin.eisenb...@udo.edu> wrote:

> > Where "to nearest" really means "to nearest with even LSB". >
i thought that happened only when the fractional part was precisely 1/2. then rounding up is equivalent qualitatively (and quantitively in magnitude) to rounding down. always rounding up would be a very small bias because of the few times your word lands precisely halfway between two quantization levels. "rounding to nearest even" happens only when you are precisely halfway (and then it will round down about as often as it rounds up). when you're slightly higher than halfway, it rounds up and slightly lower than halfway it rounds down. r b-j
On Mar 15, 3:41 pm, Jerry Avins <j...@ieee.org> wrote:
> robert bristow-johnson wrote: > > On Mar 14, 6:33 pm, Jerry Avins <j...@ieee.org> wrote: > > ... > > >> Clearly, the offset can't be avoided if you must truncate. > > > that is truncating and doing nothing else. rounding is, as Jerry > > pointed out, adding a constant (which is positive and likely virtually > > equal in magnitude to the mean DC offset from truncating) before > > truncating. > > It turns out to be very nearly the offset. To compute it, when lopping > off k bits, first add 2^(k-1). I.e., add 1 to the most significant of > the removed bits. > > Fraction saving works well, but the extra complexity compared to adding > a pre-compiled constant hasn't been justifies in any application I've had.
it's needed (to eliminate that DC limit cycling) in that fixed-point DC blocking filter as well as many other audio filters. it is disconcerting to have your input to the filter go to dead silence and (although the output *sounds* like dead silence) have the meter on the output get stuck at -65 dB FS. r b-j
robert bristow-johnson wrote:

> On Mar 15, 5:44 pm, Martin Eisenberg <martin.eisenb...@udo.edu> > wrote: > >> Where "to nearest" really means "to nearest with even LSB
in case of a tie
>> ". > > i thought that happened only when the fractional part was > precisely 1/2.
Right, thanks. Martin -- The more you can say with a language, the less you can say about the language. --Kathy Yellick
"robert bristow-johnson" <rbj@audioimagination.com> writes:

> On Mar 15, 5:44 pm, Martin Eisenberg <martin.eisenb...@udo.edu> wrote: > >> >> Where "to nearest" really means "to nearest with even LSB". >> > > i thought that happened only when the fractional part was precisely > 1/2.
Right. I was going to comment that the bias is 1 LSB * P(roundoff error = 0.5) -- % Randy Yates % "Midnight, on the water... %% Fuquay-Varina, NC % I saw... the ocean's daughter." %%% 919-577-9882 % 'Can't Get It Out Of My Head' %%%% <yates@ieee.org> % *El Dorado*, Electric Light Orchestra http://home.earthlink.net/~yatescr