Reply by robert bristow-johnson●April 14, 20152015-04-14
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."
Reply by Cedron●April 14, 20152015-04-14
>
>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
Reply by Randy Yates●April 14, 20152015-04-14
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
>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
> [...]
> 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
Reply by Cedron●April 13, 20152015-04-13
>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
Reply by robert bristow-johnson●April 13, 20152015-04-13
both you guys are a hoot.
--
r b-j rbj@audioimagination.com
"Imagination is more important than knowledge."
Reply by Cedron●April 12, 20152015-04-12
>"Cedron" <103185@DSPRelated> writes:
>> [...]
>> r b-j's point about localized DC is well taken (and much more
>> interesting). I have seen some serious centerline drift in live
>> recordings. It doesn't seem to impact playback too much though.
>
>If you are playing back without switching sources, I can see where you
>wouldn't notice too much. What happens when you switch the source in
>such scenarios?
>
>And why in the world would "live" versus studio make a difference
>in DC offset drift?
>--
>Randy Yates
>Digital Signal Labs
>http://www.digitalsignallabs.com
Well, I've never owned a studio, but I would record bands live with two
condenser mics, left and right channel. I never switched sources either,
so I can't answer that either, I'm sorry. I would record shows and burn
them to CDs for the bands. I also examined the recordings with software,
which is where I noticed the drift. I suspect that any coupling
capacitors in the playback circuits would not allow the DC (or minor slow
fluctuations) to pass to the speakers.
I have also written software in the past to generate tone files. I am
familiar with the 'click' effect that r b-j referenced when there is a
discontinuity in the sound samples. So, if you were to do a whole file
pure DC adjustment, you would definitely want to put ramps on the ends.
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.
Ced
---------------------------------------
Posted through http://www.DSPRelated.com