Forums

removing dc offset from 24-bit sound samples

Started by Arun Chandra April 11, 2015
>both you guys are a hoot. > > >-- > >r b-j rbj@audioimagination.com > >"Imagination is more important than knowledge."
Thank you, "superfluous syllabic excess to one's lexicographical utterances" is fun. Ced --------------------------------------- Posted through http://www.DSPRelated.com
"Cedron" <103185@DSPRelated> writes:
> [...] > One more point. The algorithm in the source code in this thread does > exponential smoothing with shift operations in lieu of multiplication and > division. If (as I assumed) the entire file is available before > processing, an exponential smoothing pass can be made in reverse. The two > smoothed curves should be averaged and then the result subtracted from the > signal. This will center the 'drift bumps' where they occur, rather than > lagged, which is what happens with a moving average. (Shameless self > promotion warning) I'll be addressing this technique in an upcoming blog > article. In the meanwhile, please check out the two I've already written > at dsprelated (dot) com.
Why not instead filter with a single, non-causal filter (assuming you're working with recorded samples)? If you filter forward and reverse, then average the two, you're degrading the estimate at the center. Not so with a single, non-causal filter. (Or at least "seems" that would be true from the hip..) -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
robert bristow-johnson <rbj@audioimagination.com> writes:

> both you guys are a hoot.
So we're hooters? -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
On 4/13/15 12:00 PM, Randy Yates wrote:
> robert bristow-johnson<rbj@audioimagination.com> writes: > >> both you guys are a hoot. > > So we're hooters?
i meant that Tim and Bob are the hooters. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
On Fri, 10 Apr 2015 20:14:51 -0700 (PDT), Arun Chandra
<arunc@evergreen.edu> wrote:

>hi folks, > >is there freely available C code to remove DC offset from 24-bit sound samples? > >I have tried modifying code that was released by robert bristow-johnson for use with 16-bit sounds, but I'm unable to modify it correctly for use with 24-bit sounds. > >any leads would be appreciated. > >Arun Chandra
Hello Arun, I wonder if the material at: http://www.dsprelated.com/showarticle/58.php would be of any use to you. [-Rick-]
Rick Lyons <R.Lyons@_BOGUS_ieee.org> writes:

> On Fri, 10 Apr 2015 20:14:51 -0700 (PDT), Arun Chandra > <arunc@evergreen.edu> wrote: > >>hi folks, >> >>is there freely available C code to remove DC offset from 24-bit sound samples? >> >>I have tried modifying code that was released by robert >> bristow-johnson for use with 16-bit sounds, but I'm unable to modify >> it correctly for use with 24-bit sounds. >> >>any leads would be appreciated. >> >>Arun Chandra > > Hello Arun, > I wonder if the material at: > > http://www.dsprelated.com/showarticle/58.php > > would be of any use to you.
Hi Rick, In that article I don't see a transfer function for your improved architecture, just the original. Do you have it readily available? I could derive it but I'm getting lazy... Specifically, I'd like to see how the width of the "DC notch" varies as a function of D. If we were applying this to a CD signal, D = 32 gives us a bottom passband start frequency of about 553 Hz - not good for audio! I wonder what it would take for something like 5 or 10 Hz. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
> >Why not instead filter with a single, non-causal filter (assuming >you're >working with recorded samples)? If you filter forward and reverse, then >average the two, you're degrading the estimate at the center. Not so >with a single, non-causal filter. (Or at least "seems" that would be >true from the hip..) >-- >Randy Yates >Digital Signal Labs >http://www.digitalsignallabs.com
First off, I'd like to say I am both relieved and disappointed that I'm not a hooter. I'll confess I had to look up "non-causal filter". I'll try to answer briefly as I understand things. If your desire is to have exponential smoothing, in a non-causal bidirectional manner, doing it in two passes, forward and reverse will be much more computationally efficient. Otherwise you would have to multiply your signal by a sliding window function at each point. I don't see a source of degradation anywhere. For the OP's original purpose, a centered sliding rectangular window moving average would probably work. The advantage of this is you can add the leading point and subtract the trailing point as the average moves without having to recalculate the whole sum at each point. I believe this is equivalent to the method in the Rick Lyons' cited article. These methods require additional storage for processing. The big advantage of the single pass exponential method is that it is quick and can be done in place. In all these methods, the operations can be recast as a matrix multiplication against a signal vector. In other words, they are all linear. (More shameless self promotion) I will cover the forward and backward exponential smoothing technique in great detail in a future blog article. I have at least four or five ahead of it. I think you will find them all very interesting. Two are already up. Ced --------------------------------------- Posted through http://www.DSPRelated.com
On 4/14/15 11:11 AM, Cedron wrote:
>> >> Why not instead filter with a single, non-causal filter (assuming >> you're >> working with recorded samples)? If you filter forward and reverse, then >> average the two, you're degrading the estimate at the center. Not so >> with a single, non-causal filter. (Or at least "seems" that would be >> true from the hip..)
...
> > I'll confess I had to look up "non-causal filter". I'll try to answer > briefly as I understand things. If your desire is to have exponential > smoothing, in a non-causal bidirectional manner, doing it in two passes, > forward and reverse will be much more computationally efficient. > Otherwise you would have to multiply your signal by a sliding window > function at each point. I don't see a source of degradation anywhere.
two passes means at least two sources of quantization error for every sample. might be okay.
> > For the OP's original purpose, a centered sliding rectangular window > moving average would probably work. The advantage of this is you can add > the leading point and subtract the trailing point as the average moves > without having to recalculate the whole sum at each point.
there is a generalization of this (the sliding sum or sliding average) called "Truncated IIR filters" (TIIR) which is another method of implementing a kind of FIR filter. you can do this sliding and subtract thing for exponentially decaying impulse response, too. i can send you a pdf doc i wrote that shows you exactly how to set up a TIIR for first or second-order IIR filters and with any arbitrary truncation length. for 1st order: y[n] = p*y[n-1] + A*( x[n] - q*x[n-1] + (p^L)*(q/p-1)*x[n-L] ) p = pole often A=1 and q=1-p, but doesn't have to be.
> These methods require additional storage for processing. The big > advantage of the single pass exponential method is that it is quick and > can be done in place.
and it's causal and it's IIR. so the DC getting subtracted is based *solely* on the present and past samples. it's likely okay (it's the sole method i have used to block DC) but won't be phase linear (unless you do the filtfilt() thingie).
> > In all these methods, the operations can be recast as a matrix > multiplication against a signal vector. In other words, they are all > linear. > > (More shameless self promotion) I will cover the forward and backward > exponential smoothing technique in great detail in a future blog article.
it's been done Ced. not that i have written anything about it. i'll send you that pdf regarding TIIR. see if that helps at all. (you'll be able to do perfect filtfilt since a TIIR is, strictly speaking, an FIR. L8r, -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."