Message from discussion Iterative Match Filterings
Received: by 10.204.156.18 with SMTP id u18mr1278616bkw.3.1333510259710;
Tue, 03 Apr 2012 20:30:59 -0700 (PDT)
From: Bret Cahill <BretCah...@peoplepc.com>
Subject: Re: Iterative Match Filterings
Date: Tue, 3 Apr 2012 20:30:59 -0700 (PDT)
X-Trace: posting.google.com 1333510259 2678 127.0.0.1 (4 Apr 2012 03:30:59 GMT)
NNTP-Posting-Date: Wed, 4 Apr 2012 03:30:59 +0000 (UTC)
Injection-Info: h20g2000yqd.googlegroups.com; posting-host=184.108.40.206; posting-account=bakofAoAAABYuwcSytNgyu6NxN9dLoUi
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB7.3;
SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C;
SRS_IT_E8790570B6765E553EA090; Mueller RS 2.4; Mueller RS 2.4),gzip(gfe)
Content-Type: text/plain; charset=ISO-8859-1
> >> Instead of just taking the convolution of a signal with the reference
> >> or kernel once and then taking the square root in the frequency
> >> domain, why not match filter with the reference again and again to
> >> recover the original clean signal?
> >> Well, you _can_ do that if a wave form is all you want, but you can
> >> get that from the ref. alone _anyway_.
> >> If you want to keep the original magnitude of the signal, however, and
> >> if the kernel is a different magnitude than the original signal, then
> >> you will only be working your way back to the kernel with each
> >> iteration.
> >> The solution here is to convolve the signal with the kernel and then
> >> the kernel with the kernel and then comparing the magnitudes of those
> >> two convolutions.
> >> Apply that factor to correct the magnitude of the filtered signal.
> > One question is:
> > Is there anything to be gained with iterative match filterings as far
> > as recovering the correct magnitude is concerned?
> > Bret Cahill
> This answer is loaded with observer bias, but I find that application
> of any filter is almost guaranteed to change the magnitude of the result.
That shouldn't be a problem here as long as the % change is the same
for both filtered signals. The reason for this is because the result
is always the quotient of two filtered signals.
This works out ok for just the convolution but if you complete the
match filtering process by taking de convolutions to recover the
original wave forms, then the magnitudes of both signals move toward
the magnitude of the kernel and the quotient moves closer to 1.
> I've played with normalization* of the output signal back to the
> magnitude of the original and I don't detect any general pattern.
Normalization is inherent/automatic taking the quotient of the
Trying to recover the magnitudes of the original signals from the
match filtered signals requires 3 additional steps:
1. match filtering the kernel with itself and then,
2. comparing that with each match filtered signal for a factor.
3. applying that correction factor to it's respective signal.
> *almost always audio signals, and the measure of magnitude is
> almost always the RMS of the vector in question...
> If the mag. of the result is 0.5 dB down, then add 0.5 gain... this
> may or may not mean you can change the filter to do that
> for you... for convolution kernels, I belive it *can*, but IIR
> filters almost certainly don't work that way...