I see what you're getting at, I suppose. However, in the context of FIR
filtering I wouldn't refer to this as an artifact. Let's say you gave me an
FIR filter with N-taps and asked me to write a program to implement that
filter. I could implement this using a direct form structure (in the
time-domain), or with the FFT using OLA. Both would give the exact same
results down to numerical precision, with no "artifacts". That's why it
intrigued me when you said "of course it won't have the ripple artifacts
associated with FFT overlap windowing" when referring to software that does
filtering.


On Wed, Jun 24, 2020 at 10:59 AM Zhiguang Eric Zhang <zez...@nyu.edu> wrote:

> ripple is just a known artifactual component of a windowing operation.
> it's also known as the Gibbs phenomenon
>
> http://matlab.izmiran.ru/help/toolbox/signal/filterd8.html
>
> i'm not referring to any equivalency between time/freq domain filtering
>
>
> On Wed, Jun 24, 2020 at 9:21 AM Corey K <corey...@gmail.com> wrote:
>
>> Not totally understanding you, unfortunately. But if what you are
>> describing is part of the normal filter response/ringing I guess I wouldn't
>> refer to it as "artifacts"? FIR filtering can be performed equivalently in
>> the time or frequency domain. Do you disagree with that statement?
>>
>> On Wed, Jun 24, 2020 at 10:02 AM Zhiguang Eric Zhang <zez...@nyu.edu>
>> wrote:
>>
>>> yes but any windowing operation is akin to taking a dirac delta function
>>> on X number of samples and thus you will get ringing/ripple artifacts as a
>>> necessary part of the filter response
>>>
>>> On Wed, Jun 24, 2020 at 6:30 AM Corey K <corey...@gmail.com> wrote:
>>>
>>>>
>>>> of course it won't have the ripple artifacts associated with FFT
>>>>> overlap windowing
>>>>>
>>>>
>>>> What is the ripple artifact you are talking about? When using constant
>>>> overlap add (COLA) windows the STFT is a perfect reconstruction filterbank.
>>>> Likewise block FFT convolution can be used to implement any FIR filtering
>>>> operation.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> cheers,
>>>>> -ez
>>>>>
>>>>> On Mon, Apr 13, 2020 at 4:55 PM Andreas Gustafsson <
>>>>> g...@waxingwave.com> wrote:
>>>>>
>>>>>> Hello Spencer,
>>>>>>
>>>>>> You wrote:
>>>>>> > A while ago I read through some the literature [1] on implementing
>>>>>> > an invertible CQT as a special case of the Nonstationary Gabor
>>>>>> > Transform. It's implemented by the essentia library [2] among other
>>>>>> > places probably.
>>>>>> >
>>>>>> > The main idea is that you take the FFT of your whole signal, then
>>>>>> > apply the filter bank in the frequency domain (just
>>>>>> > multiplication). Then you IFFT each filtered signal, which gives you
>>>>>> > the time-domain samples for each band of the filter bank. Each
>>>>>> > frequency-domain filter has a different bandwidth, so your IFFT is a
>>>>>> > different length for each one, which gives you the different sample
>>>>>> > rates for each one.
>>>>>>
>>>>>> That's the basic idea, but the Gaborator rounds up each of the
>>>>>> per-band sample rates to the original sample rate divided by some
>>>>>> power of two.  This means all the FFT sizes can be powers of two,
>>>>>> which tend to be faster than arbitrary sizes.  It also results in a
>>>>>> nicely regular time-frequency sampling grid where many of the samples
>>>>>> coincide in time, as shown in the second plot on this page:
>>>>>>
>>>>>>
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.gaborator.com_gaborator-2D1.4_doc_overview.html&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=4rIFY1X4fS1G8-882xM72jF9DvsY6-Z2ckeHxjPPfTY&s=FG-ZGfFa09T-Y7nLajB8evbCy9WIADFrUqPwjz-LHow&e=
>>>>>>
>>>>>> Also, the Gaborator makes use of multirate processing where the signal
>>>>>> is repeatedly decimated by 2 and the calculations for the lower
>>>>>> octaves run at successively lower sample rates.  These optimizations
>>>>>> help the Gaborator achieve a performance of millions of samples per
>>>>>> second per CPU core.
>>>>>>
>>>>>> > They also give an "online" version where you do
>>>>>> > the processing in chunks, but really for this to work I think you'd
>>>>>> > need large-ish chunks so the latency would be pretty bad.
>>>>>>
>>>>>> The Gaborator also works in chunks.  A typical chunk size might be
>>>>>> 8192 samples, but thanks to the multirate processing, in the lowest
>>>>>> frequency bands, each of those 8192 samples may represent the
>>>>>> low-frequency content of something like 1024 samples of the original
>>>>>> signal.  This gives an effective chunk size of some 8 million samples
>>>>>> without actually having to perform any FFTs that large.
>>>>>>
>>>>>> Latency is certainly high, but I would not say it is a consequence of
>>>>>> the chunk size as such.  Rather, both the high latency and the need
>>>>>> for a large (effective) chunk size are consequences of the lengths of
>>>>>> the band filter impulse responses, which get exponentially larger as
>>>>>> the constant-Q bands get narrower towards lower frequencies.
>>>>>>
>>>>>> Latency in the Gaborator is discussed in more detail here:
>>>>>>
>>>>>>
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.gaborator.com_gaborator-2D1.4_doc_realtime.html&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=4rIFY1X4fS1G8-882xM72jF9DvsY6-Z2ckeHxjPPfTY&s=uuRzi0taGcXI9Sq63G_xTTrCjaz9cu3ewu8jfzIUcVc&e=
>>>>>>
>>>>>> > The whole process is in some ways dual to the usual STFT process,
>>>>>> > where we first window and then FFT. in the NSGT you first FFT and
>>>>>> > then window, and then IFFT each band to get a Time-Frequency
>>>>>> > representation.
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> > For resynthesis you end up with a similar window overlap constraint
>>>>>> > as in STFT, except now the windows are in the frequency domain. It's
>>>>>> > a little more complicated because the window centers aren't
>>>>>> > evenly-spaced, so creating COLA windows is complicated. There are
>>>>>> > some fancier approaches to designing a set of synthesis windows that
>>>>>> > are complementary (inverse) of the analysis windows, which is what
>>>>>> > the frame-theory folks like that Austrian group seem to like to use.
>>>>>>
>>>>>> The Gaborator was inspired by the papers from that Austrian group and
>>>>>> uses complementary resynthesis windows, or "duals" as frame theorists
>>>>>> like to call them.  The analysis windows are Gaussian, and the dual
>>>>>> windows used for resynthesis end up being slightly distorted
>>>>>> Gaussians.
>>>>>>
>>>>>> > One of the nice things about the NSGT is it lets you be really
>>>>>> > flexible in your filterbank design while still giving you
>>>>>> > invertibility.
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>> In a later message, you wrote:
>>>>>> > Whoops, just clicked through to the documentation and it looks like
>>>>>> > this is the track you're on also. I'm curious if you have any
>>>>>> > insight into the window-selection for the analysis and synthesis
>>>>>> > process. It seems like the NSGT framework forces you to be a bit
>>>>>> > smarter with windows than just sticking to COLA, but the dual frame
>>>>>> > techniques should apply for regular STFT processing, right?
>>>>>>
>>>>>> I'm actually not that familiar with traditional STFTs and COLA, but as
>>>>>> far as I can tell, the STFT is a special case of the NSGT and the same
>>>>>> dual frame techniques should apply.
>>>>>> --
>>>>>> Andreas Gustafsson, g...@waxingwave.com
>>>>>> _______________________________________________
>>>>>> dupswapdrop: music-dsp mailing list
>>>>>> music-dsp@music.columbia.edu
>>>>>>
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=4rIFY1X4fS1G8-882xM72jF9DvsY6-Z2ckeHxjPPfTY&s=br6gIADk3PB9_kF8YoA7aZdcf5McFvCCOlyYso5D2BI&e=
>>>>>>
>>>>> _______________________________________________
>>>>> dupswapdrop: music-dsp mailing list
>>>>> music-dsp@music.columbia.edu
>>>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=0Zfr9NX2z_qbqorZ4mvWlKWdhvCOnws4tZKFE3J0lxI&s=_0-DUAEnNzJ0nyrUgGHozY0ob4n_-0OWpipEf-p2Bps&e=>
>>>>
>>>> _______________________________________________
>>>> dupswapdrop: music-dsp mailing list
>>>> music-dsp@music.columbia.edu
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=0Zfr9NX2z_qbqorZ4mvWlKWdhvCOnws4tZKFE3J0lxI&s=_0-DUAEnNzJ0nyrUgGHozY0ob4n_-0OWpipEf-p2Bps&e=
>>>
>>> _______________________________________________
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=ggIGGD37NXAIrRak00WIRysmpvCxdGGCHkoma2TGgxc&s=2aCxaadCSRm8GtUxELE7DhnWmqkKUkkAymUl19tD-v4&e=>
>>
>> _______________________________________________
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=ggIGGD37NXAIrRak00WIRysmpvCxdGGCHkoma2TGgxc&s=2aCxaadCSRm8GtUxELE7DhnWmqkKUkkAymUl19tD-v4&e=
>
> _______________________________________________
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
_______________________________________________
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Reply via email to