Re: [music-dsp] Sliding Phase Vocoder (was FIR blog post & interactive demo)

[Corey K]

You don't have to sample the STFT that often. In fact block based FFT
convolution uses non-overlapping blocks on the input (although the output
windows do overlap). Anyway, I digress...

On Wed., Jun. 24, 2020, 1:06 p.m. Zhiguang Eric Zhang, 
wrote:

> It's not just about zero-padding.  Say you could sample the signal and
> window at, say, fs, but why the hell would you want to window at fs?  At
> any rate, if you look at the Hamming window, the ringing artifact is rather
> negligible.
>
>
> On Wed, Jun 24, 2020, 11:15 AM STEFFAN DIEDRICHSEN 
> wrote:
>
>> Phew, thank you for confirming that! We use it in several products.
>>
>> Cheers,
>>
>> Steffan
>>
>> On 24.06.2020|KW26, at 17:07, Corey K  wrote:
>>
>> But the end result is that we can perform filtering using STFT
>> filterbanks just fine, there are no artifacts.
>>
>>
>> ___
>> 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=yZ5_ZeKmy3sswDToK2aeereR1JOnaPvsIiQIFV61n3s&s=CCun327jvXB9hliV_3DHUKwKgRVRi8xdsZyOtqHPAfw&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

Re: [music-dsp] Sliding Phase Vocoder (was FIR blog post & interactive demo)

[Corey K]

(when I say satisfy the left hand side, I mean make the sum of shifted
windows add up to a constant)

On Wed, Jun 24, 2020 at 12:37 PM Corey K  wrote:

> Regarding e.q 4.5 it is easy to satisfy the left hand side of that
> equation exactly (which is all that is needed) -- any COLA window will do
> it.
>
> Steffan's point is critically important. The FFT has to be appropriately
> zero-padded so the convolution is linear rather than circular.
>
> But the end result is that we can perform filtering using STFT filterbanks
> just fine, there are no artifacts.
>
> On Wed, Jun 24, 2020 at 12:30 PM STEFFAN DIEDRICHSEN 
> wrote:
>
>> Here’s the beef from that paper:
>>
>>
>> (The reader should realize that an appropriate change
>>
>> must be made to the analysis-i.e., padding the windowed
>> in- put signal with a sufficient number of zero valued samples-to prevent
>> time aliasing when implementing the analysis and syn- thesis operations
>> with FFT's, which have length L . If a modification P(eJWk) has a time
>> response which is effectively No points long, the analysis length L must be
>> at least N +No - 1 where the window length is N.)
>>
>> That’s more or less describing the limits of that approach by using the
>> identity of spectral multiplication and time-domain convolution. For a
>> convolution of N input samples with M filter samples, the result is L=
>> N+M-1. So, if you use an FFT with size L, you can use M-1-L input samples.
>> So you need to zero-pad to avoid artefacts.
>>
>> Best,
>>
>> Steffan
>>
>> On 24.06.2020|KW26, at 16:10, Corey K  wrote:
>>
>> I think you're mistaken, unfortunately. Block FFT convolution has been
>> around for 30+ years. In 1977 (43 years ago now), Jont Allen showed in his
>> paper "A Unified Approach to Short-Time Fourier Analysis" how you can
>> perform FIR filtering perfectly with the FFT, of COLA windows are used. See
>> equation 5.2.5 in that paper, and the analysis that precedes it.
>>
>>
>>
>>
>>
>> On Wed, Jun 24, 2020 at 11:16 AM Zhiguang Eric Zhang 
>> wrote:
>>
>>> that's not true.  with FFT/COLA you will necessarily have the Gibbs
>>> phenomenon / ringing / ripple artifacts.  certain window types will
>>> minimize this but you will get this phenomenon nonetheless.
>>>
>>> On Wed, Jun 24, 2020 at 9:44 AM Corey K  wrote:
>>>
>>>> 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 
>>>> 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
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__matlab.izmiran.ru_help_toolbox_signal_filterd8.html&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=LVW8eOM2POVbM1MauwqppWYiBwmnAs5_i7qiMOEK0-o&s=XefFmTg_gx0qQrZnZTOJDTlaqMl3xt5WBzqxYAkoMKA&e=>
>>>>>
>>>>> i'm not referring to any equivalency between time/freq domain filtering
>>>>>
>>>>>
>>>>> On Wed, Jun 24, 2020 at 9:21 AM Corey K  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 
>>>>>> wrote

Re: [music-dsp] Sliding Phase Vocoder (was FIR blog post & interactive demo)

[Corey K]

Regarding e.q 4.5 it is easy to satisfy the left hand side of that equation
exactly (which is all that is needed) -- any COLA window will do it.

Steffan's point is critically important. The FFT has to be appropriately
zero-padded so the convolution is linear rather than circular.

But the end result is that we can perform filtering using STFT filterbanks
just fine, there are no artifacts.

On Wed, Jun 24, 2020 at 12:30 PM STEFFAN DIEDRICHSEN 
wrote:

> Here’s the beef from that paper:
>
>
> (The reader should realize that an appropriate change
>
> must be made to the analysis-i.e., padding the windowed
> in- put signal with a sufficient number of zero valued samples-to prevent
> time aliasing when implementing the analysis and syn- thesis operations
> with FFT's, which have length L . If a modification P(eJWk) has a time
> response which is effectively No points long, the analysis length L must be
> at least N +No - 1 where the window length is N.)
>
> That’s more or less describing the limits of that approach by using the
> identity of spectral multiplication and time-domain convolution. For a
> convolution of N input samples with M filter samples, the result is L=
> N+M-1. So, if you use an FFT with size L, you can use M-1-L input samples.
> So you need to zero-pad to avoid artefacts.
>
> Best,
>
> Steffan
>
> On 24.06.2020|KW26, at 16:10, Corey K  wrote:
>
> I think you're mistaken, unfortunately. Block FFT convolution has been
> around for 30+ years. In 1977 (43 years ago now), Jont Allen showed in his
> paper "A Unified Approach to Short-Time Fourier Analysis" how you can
> perform FIR filtering perfectly with the FFT, of COLA windows are used. See
> equation 5.2.5 in that paper, and the analysis that precedes it.
>
>
>
>
>
> On Wed, Jun 24, 2020 at 11:16 AM Zhiguang Eric Zhang 
> wrote:
>
>> that's not true.  with FFT/COLA you will necessarily have the Gibbs
>> phenomenon / ringing / ripple artifacts.  certain window types will
>> minimize this but you will get this phenomenon nonetheless.
>>
>> On Wed, Jun 24, 2020 at 9:44 AM Corey K  wrote:
>>
>>> 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 
>>> 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
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__matlab.izmiran.ru_help_toolbox_signal_filterd8.html&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=LVW8eOM2POVbM1MauwqppWYiBwmnAs5_i7qiMOEK0-o&s=XefFmTg_gx0qQrZnZTOJDTlaqMl3xt5WBzqxYAkoMKA&e=>
>>>>
>>>> i'm not referring to any equivalency between time/freq domain filtering
>>>>
>>>>
>>>> On Wed, Jun 24, 2020 at 9:21 AM Corey K  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 
>>>>> 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  wrote:
>>>>>>
>>>>>>>
>>>>>>> of course it won't have the ripple artifacts associated with 

Re: [music-dsp] Sliding Phase Vocoder (was FIR blog post & interactive demo)

[Corey K]

Ok, if Allen can't convince you, how about Julius Smith:
https://ccrma.stanford.edu/~jos/sasp/FFT_Filter_Banks.html ?



On Wed, Jun 24, 2020 at 12:13 PM Zhiguang Eric Zhang  wrote:

> Thank you.  Yes it seems very theoretical and math heavy.  In practice you
> will get this frequency response artifact no matter how small.  It should
> factor into the math in some way, perhaps they are not looking at the
> laplacian
>
> On Wed, Jun 24, 2020, 10:41 AM Corey K  wrote:
>
>> It's a classic paper. Google scholar shows it has been cited over 1000
>> times. There's a link to it here here:
>> https://jontalle.web.engr.illinois.edu/uploads/537/Papers/Public/AllenRabiner77-ProcIEEE.pdf
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jontalle.web.engr.illinois.edu_uploads_537_Papers_Public_AllenRabiner77-2DProcIEEE.pdf&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=EIWxvlh8qpdcU_coPNdiZxhQaqJEihTl-BcA8WN1eWw&s=e-NKtVrjHEINB5kEwTE3d4g9q2bZGxjnso8yyBhaUUM&e=>
>>
>>
>> On Wed, Jun 24, 2020 at 11:56 AM Zhiguang Eric Zhang 
>> wrote:
>>
>>> unfortunately, i'm not familiar with that paper.  could you please
>>> attach it or provide a link for reference?  the Gibbs phenomenon is
>>> actually a very well-known and thoroughly characterized signal processing
>>> artifact that has been approached from a variety of angles as far as trying
>>> to find a solution.  iit can be thought of as an unavoidable digital filter
>>> response of having to take X number of samples in one snapshot while
>>> capturing a finite instance in time (as you might know the Dirac delta is
>>> centered on DC)
>>>
>>> https://en.wikipedia.org/wiki/Ringing_artifacts
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Ringing-5Fartifacts&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=EIWxvlh8qpdcU_coPNdiZxhQaqJEihTl-BcA8WN1eWw&s=XkZObRCqtj2hzKnIyyVYQqrxJYhSfTrXnDzaDFzTsw4&e=>
>>>
>>> On Wed, Jun 24, 2020 at 10:12 AM Corey K  wrote:
>>>
>>>> I think you're mistaken, unfortunately. Block FFT convolution has been
>>>> around for 30+ years. In 1977 (43 years ago now), Jont Allen showed in his
>>>> paper "A Unified Approach to Short-Time Fourier Analysis" how you can
>>>> perform FIR filtering perfectly with the FFT, of COLA windows are used. See
>>>> equation 5.2.5 in that paper, and the analysis that precedes it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jun 24, 2020 at 11:16 AM Zhiguang Eric Zhang 
>>>> wrote:
>>>>
>>>>> that's not true.  with FFT/COLA you will necessarily have the Gibbs
>>>>> phenomenon / ringing / ripple artifacts.  certain window types will
>>>>> minimize this but you will get this phenomenon nonetheless.
>>>>>
>>>>> On Wed, Jun 24, 2020 at 9:44 AM Corey K  wrote:
>>>>>
>>>>>> 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 
>>>>>> 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
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__matlab.izmiran.ru_help_toolbox_signal_filterd8.html&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=LVW8eOM2POVbM1MauwqppWYiBwmnAs5_i7qiMOEK0-o&s=XefFmTg_gx0qQrZnZTOJDTlaqMl3xt5WBzqxYAkoMKA&e=>
>>>&g

Re: [music-dsp] Sliding Phase Vocoder (was FIR blog post & interactive demo)

[Corey K]

It's a classic paper. Google scholar shows it has been cited over 1000
times. There's a link to it here here:
https://jontalle.web.engr.illinois.edu/uploads/537/Papers/Public/AllenRabiner77-ProcIEEE.pdf


On Wed, Jun 24, 2020 at 11:56 AM Zhiguang Eric Zhang  wrote:

> unfortunately, i'm not familiar with that paper.  could you please attach
> it or provide a link for reference?  the Gibbs phenomenon is actually a
> very well-known and thoroughly characterized signal processing artifact
> that has been approached from a variety of angles as far as trying to find
> a solution.  iit can be thought of as an unavoidable digital filter
> response of having to take X number of samples in one snapshot while
> capturing a finite instance in time (as you might know the Dirac delta is
> centered on DC)
>
> https://en.wikipedia.org/wiki/Ringing_artifacts
>
> On Wed, Jun 24, 2020 at 10:12 AM Corey K  wrote:
>
>> I think you're mistaken, unfortunately. Block FFT convolution has been
>> around for 30+ years. In 1977 (43 years ago now), Jont Allen showed in his
>> paper "A Unified Approach to Short-Time Fourier Analysis" how you can
>> perform FIR filtering perfectly with the FFT, of COLA windows are used. See
>> equation 5.2.5 in that paper, and the analysis that precedes it.
>>
>>
>>
>>
>>
>> On Wed, Jun 24, 2020 at 11:16 AM Zhiguang Eric Zhang 
>> wrote:
>>
>>> that's not true.  with FFT/COLA you will necessarily have the Gibbs
>>> phenomenon / ringing / ripple artifacts.  certain window types will
>>> minimize this but you will get this phenomenon nonetheless.
>>>
>>> On Wed, Jun 24, 2020 at 9:44 AM Corey K  wrote:
>>>
>>>> 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 
>>>> 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
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__matlab.izmiran.ru_help_toolbox_signal_filterd8.html&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=LVW8eOM2POVbM1MauwqppWYiBwmnAs5_i7qiMOEK0-o&s=XefFmTg_gx0qQrZnZTOJDTlaqMl3xt5WBzqxYAkoMKA&e=>
>>>>>
>>>>> i'm not referring to any equivalency between time/freq domain filtering
>>>>>
>>>>>
>>>>> On Wed, Jun 24, 2020 at 9:21 AM Corey K  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 
>>>>>> 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  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
>>

Re: [music-dsp] Sliding Phase Vocoder (was FIR blog post & interactive demo)

[Corey K]

I think you're mistaken, unfortunately. Block FFT convolution has been
around for 30+ years. In 1977 (43 years ago now), Jont Allen showed in his
paper "A Unified Approach to Short-Time Fourier Analysis" how you can
perform FIR filtering perfectly with the FFT, of COLA windows are used. See
equation 5.2.5 in that paper, and the analysis that precedes it.





On Wed, Jun 24, 2020 at 11:16 AM Zhiguang Eric Zhang  wrote:

> that's not true.  with FFT/COLA you will necessarily have the Gibbs
> phenomenon / ringing / ripple artifacts.  certain window types will
> minimize this but you will get this phenomenon nonetheless.
>
> On Wed, Jun 24, 2020 at 9:44 AM Corey K  wrote:
>
>> 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 
>> 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
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__matlab.izmiran.ru_help_toolbox_signal_filterd8.html&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=LVW8eOM2POVbM1MauwqppWYiBwmnAs5_i7qiMOEK0-o&s=XefFmTg_gx0qQrZnZTOJDTlaqMl3xt5WBzqxYAkoMKA&e=>
>>>
>>> i'm not referring to any equivalency between time/freq domain filtering
>>>
>>>
>>> On Wed, Jun 24, 2020 at 9:21 AM Corey K  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 
>>>> 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  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 give

Re: [music-dsp] Sliding Phase Vocoder (was FIR blog post & interactive demo)

[Corey K]

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  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  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 
>> 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  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 achie

Re: [music-dsp] Sliding Phase Vocoder (was FIR blog post & interactive demo)

[Corey K]

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  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  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 
>>> 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

Re: [music-dsp] Sliding Phase Vocoder (was FIR blog post & interactive demo)

[Corey K]

> 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 
> 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

Re: [music-dsp] Real-time pitch shifting?

[Corey K]

"Phase Vocoder Done Right" is a fairly interesting new paper I came across,
that talks about a strategy to preserve both vertical and horizontal phase
coherence. Examples (which sound pretty good) and link to paper are here:
http://ltfat.github.io/notes/050/

-Corey

On Mon, May 21, 2018, 06:46 Chris Cannam 
wrote:

>
> On Sat, 19 May 2018, at 21:34, RJ Skerry-Ryan wrote:
> > It may not be the state of the art, but RubberBand
> >  is, I believe, the best open
> source
> > pitch shift / time stretch library out there at the moment, and can run
> in
> > realtime on modern CPUs.
>
> See here for a page very briefly summarising how Rubber Band works:
> https://breakfastquay.com/rubberband/technical.html
> In short, it's a phase vocoder that uses a handful of the available tricks
> to try to reduce phasiness, without doing any very expensive analysis such
> as sinusoidal modelling.
>
> There is actually a fine sinusoidal-modelling time stretcher hiding in
> Audacity, using the SBSMS library by Clayton Otey. This isn't a real-time
> method as far as I can see, and is slow to run, but it's worth checking out
> -- you activate it by selecting the Change Tempo or Change Pitch effect and
> checking the option labelled "Use high quality stretching". Code at
> https://github.com/audacity/audacity/tree/master/lib-src/sbsms.
>
> Stephan Bernsee's old post is a bit of a puzzle, since it contains quite a
> lot about analysis/resynthesis but very little about actual pitch shifting.
>
>
> Chris
> ___
> 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

Re: [music-dsp] (Novel?) "Modal Phase Rotation Synthesis"

[Corey K]

Yes, I think you can do phase modulation with those filters. They are
referred to colloquially as "phasor filters", because their phase is
manipulated in order to rotate a vector around the complex plane...

On Tue, Apr 3, 2018 at 8:16 AM, gm  wrote:

>
> Yes it's related, I dont recall if I used one of these filters
> in my first implementation which was several years ago.
> I used a complex filter before I used the SVF and AP.
>
> But I think you can't do full phase modulation with such filters?
> I think that was my motivation to apply the rotation outside of the filter.
>
> Either way it seems lighter on cpu when you use the external rotation with
> parabolas instead of trig operations since you dont have to constantly
> adapt the internal state of the filter.
>
> A drawback of the method in general with either filter is that
> you can cancel the internal state with an impulse.
>
> I havent figured out what the best excitation signal is.
>
> The paper you linked suggests to delay the impulse until a zero crossing
> but that is not an option in my use cases.
>
> Am 03.04.2018 um 01:46 schrieb Corey K:
>
> Your idea seems to bear a few similarities to this (just in case you
> haven't seen it already):
> https://ccrma.stanford.edu/~jos/smac03maxjos/
>
>
>
> On Mon, Apr 2, 2018 at 2:46 PM, gm  wrote:
>
>>
>> I don't know if this idea is new, I had it for some time but have never
>> seen it mentioned anywhere:
>>
>> Use a filter with high q and rotate it's (complex) output by the (real)
>> output
>> of another filter to obtain a phase modulated sine wave.
>> Excite with an impulse or impact signal.
>>
>> It's basically crossed between modal and phase modulation synthesis.
>>
>> Now there are some ideas to this to make it practical and a useful
>> substitute for phase modulation and FM:
>>
>> You can use a state variable filter with an additional allpass instead of
>> the complex filter to obtain a filter you can pitch modulate in audio
>> (useful for drum synthesis ect) (or maybe the 90 shift can be designed
>> more efficiently
>> into the SVF IDK.)
>>
>> Instead of expensive trig calculations for the rotation, or using
>> the normalized complex signal form the other filter (also expensive)
>> just use a very coarse parabolic sine/cosine approximation and the real
>> signal,
>> the difference is really very small sonically, since the modulator is
>> still sine
>> and the radius stays around 1 so it's the effect of a small amplitude
>> modulation on the modulator
>> caused by the slight deviation of the circle.
>> I couldnt tell the difference when I tested it first.
>>
>> You need 7 mults and 4 adds in addition to the SVF for the AP and
>> rotation per carrier.
>>
>> But you save an envelope for each operator and have a pretty efficient
>> sine operator with the SVF.
>> And you get all the benfits of phase modulation over frequency modulation
>> of the
>> filter cutoff.
>> It's very useful for drum synthesis but also useful for some other
>> percussive sounds like "FM" pianos etc.
>>
>> Here is an audio demo, with cheap "soundboard" and some other fx added:
>> https://soundcloud.com/traumlos_kalt/smoke-piano-test-1-01/s-W54wz
>>
>> I wonder if this idea is new?
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>>
>
>
> ___
> dupswapdrop: music-dsp mailing 
> listmusic-dsp@music.columbia.eduhttps://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
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] (Novel?) "Modal Phase Rotation Synthesis"

[Corey K]

Your idea seems to bear a few similarities to this (just in case you
haven't seen it already):
https://ccrma.stanford.edu/~jos/smac03maxjos/



On Mon, Apr 2, 2018 at 2:46 PM, gm  wrote:

>
> I don't know if this idea is new, I had it for some time but have never
> seen it mentioned anywhere:
>
> Use a filter with high q and rotate it's (complex) output by the (real)
> output
> of another filter to obtain a phase modulated sine wave.
> Excite with an impulse or impact signal.
>
> It's basically crossed between modal and phase modulation synthesis.
>
> Now there are some ideas to this to make it practical and a useful
> substitute for phase modulation and FM:
>
> You can use a state variable filter with an additional allpass instead of
> the complex filter to obtain a filter you can pitch modulate in audio
> (useful for drum synthesis ect) (or maybe the 90 shift can be designed
> more efficiently
> into the SVF IDK.)
>
> Instead of expensive trig calculations for the rotation, or using
> the normalized complex signal form the other filter (also expensive)
> just use a very coarse parabolic sine/cosine approximation and the real
> signal,
> the difference is really very small sonically, since the modulator is
> still sine
> and the radius stays around 1 so it's the effect of a small amplitude
> modulation on the modulator
> caused by the slight deviation of the circle.
> I couldnt tell the difference when I tested it first.
>
> You need 7 mults and 4 adds in addition to the SVF for the AP and rotation
> per carrier.
>
> But you save an envelope for each operator and have a pretty efficient
> sine operator with the SVF.
> And you get all the benfits of phase modulation over frequency modulation
> of the
> filter cutoff.
> It's very useful for drum synthesis but also useful for some other
> percussive sounds like "FM" pianos etc.
>
> Here is an audio demo, with cheap "soundboard" and some other fx added:
> https://soundcloud.com/traumlos_kalt/smoke-piano-test-1-01/s-W54wz
>
> I wonder if this idea is new?
>
> ___
> 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

Re: [music-dsp] tracking drum partials

[Corey K]

Ian, do you have some references for the time-varying methods? Just
curious...

On Jul 31, 2017 12:04 AM, "Ian Esten"  wrote:

> That would also be my first choice. It might also be worth looking at
> modern algorithms in that family of methods. A lot of effort has gone into
> designing exponentially damped sine methods for voice compression and
> transmission. They will be more robust to noise than Prony's method. Some
> methods can even handle arbitrarily coloured noise, not just white. Some
> methods also deal with time-varying damped sinusoids, which would be
> interesting if your drums can change their resonant modes over time, as
> happens with the tabla, timpani and others.
>
> Best,
> Ian
>
> On Sun, Jul 30, 2017 at 12:14 PM, Corey K  wrote:
>
>> You might want to look into a parametric method of estimating the
>> partials as well, e.g., Prony's method, which could give you much higher
>> resolution than the FFT.
>>
>> Best,
>>
>> Corey Kereliuk
>> www.reverberate.ca
>>
>>
>> On Jul 28, 2017 12:47 PM, "Thomas Rehaag" 
>> wrote:
>>
>> see below.
>>
>>
>>>  Original Message
>>> 
>>> Subject: Re: [music-dsp] tracking drum partials
>>> From: "Thomas Rehaag" 
>>> Date: Thu, July 27, 2017 4:02 pm
>>> To: music-dsp@music.columbia.edu
>>> 
>>> --
>>>
>>> >
>>> > @Robert:
>>> > I didn't quite get "for analysis, i would recommend Gaussian windows
>>> > because each partial will have it's own gaussian bump in the frequency
>>> > domain ..."
>>> > Looks like you wouldn't just pick up the peaks like I do.
>>> >
>>>
>>> well, i *would* sorta, but it's not always as simple as that.
>>>
>>> ...
>>>
>>>
>>> > Next the highest peaks are taken from every FFT and then tracks in time
>>> > are built.
>>> >
>>> > And it looks like I've just found the simple key for better results
>>> > after putting the whole stuff aside for 3 weeks now.
>>> > It's just to use samples from drums that have been hit softly.
>>> > Else every bin of the first FFTs will be crossed by 2 or 3 sweeps which
>>> > leads to lots of artifacts.
>>>
>>> are you using MATLAB/Octave?  you might need to think about  fftshift() .
>>>
>>> suppose you have a sinusoid that goes on forever and you use a **very**
>>> long FFT and transform it.  if you can imagine that very long FFT as
>>> approximating the Fourier Transform, you will get better than a "peak", you
>>> will get a *spike* and +/- f0, the frequency of that sinusoid (the
>>> "negative frequency" spike will be at N-f0).  in the F.T., it's a pair
>>> dirac impulses at +/- f0.  then when you multiply by a window in the time
>>> domain, that is convolving by the F.T. of the window in the frequency
>>> domain.  i will call that F.T. of the window, the "window spectrum".  a
>>> window function is normally a low-pass kinda signal, which means the window
>>> spectrum will peak at a frequency of 0.   convolving that window spectrum
>>> with a dirac spike at f0 simply moves that window spectrum to f0.  so it's
>>> no longer a spike, but a more rounded peak at f0.  i will call that "more
>>> rounded peak" the "main lobe" of the window spectrum.  and it is what i
>>> meant by the "gaussian bump" in the previous response.
>>>
>>> now most (actually all, to some degree) window spectra have sidelobes
>>> and much of what goes on with designing a good window function is to deal
>>> with those sidelobe bumps.  because the sidelobe of one partial will add to
>>> the mainlobe of another partial and possibly skew the apparent peak
>>> location and peak height.  one of the design goals behind the Hamming
>>> window was to beat down the sidelobes a little.  a more systematic approach
>>> is the Kaiser window which allows you to trade off sidelobe height and
>>> mainlobe width.  you would like *both* a skinny mainlobe and small
>>> sidelobes, but you can't get both without increasing the window length "L".
>>>
>>> another property that *some* windows have that are of interest to the
>>> music-dsp crowd is that of being

Re: [music-dsp] tracking drum partials

[Corey K]

You might want to look into a parametric method of estimating the partials
as well, e.g., Prony's method, which could give you much higher resolution
than the FFT.

Best,

Corey Kereliuk
www.reverberate.ca

On Jul 28, 2017 12:47 PM, "Thomas Rehaag"  wrote:

see below.


>  Original Message 
> Subject: Re: [music-dsp] tracking drum partials
> From: "Thomas Rehaag" 
> Date: Thu, July 27, 2017 4:02 pm
> To: music-dsp@music.columbia.edu
> --
>
> >
> > @Robert:
> > I didn't quite get "for analysis, i would recommend Gaussian windows
> > because each partial will have it's own gaussian bump in the frequency
> > domain ..."
> > Looks like you wouldn't just pick up the peaks like I do.
> >
>
> well, i *would* sorta, but it's not always as simple as that.
>
> ...
>
>
> > Next the highest peaks are taken from every FFT and then tracks in time
> > are built.
> >
> > And it looks like I've just found the simple key for better results
> > after putting the whole stuff aside for 3 weeks now.
> > It's just to use samples from drums that have been hit softly.
> > Else every bin of the first FFTs will be crossed by 2 or 3 sweeps which
> > leads to lots of artifacts.
>
> are you using MATLAB/Octave?  you might need to think about  fftshift() .
>
> suppose you have a sinusoid that goes on forever and you use a **very**
> long FFT and transform it.  if you can imagine that very long FFT as
> approximating the Fourier Transform, you will get better than a "peak", you
> will get a *spike* and +/- f0, the frequency of that sinusoid (the
> "negative frequency" spike will be at N-f0).  in the F.T., it's a pair
> dirac impulses at +/- f0.  then when you multiply by a window in the time
> domain, that is convolving by the F.T. of the window in the frequency
> domain.  i will call that F.T. of the window, the "window spectrum".  a
> window function is normally a low-pass kinda signal, which means the window
> spectrum will peak at a frequency of 0.   convolving that window spectrum
> with a dirac spike at f0 simply moves that window spectrum to f0.  so it's
> no longer a spike, but a more rounded peak at f0.  i will call that "more
> rounded peak" the "main lobe" of the window spectrum.  and it is what i
> meant by the "gaussian bump" in the previous response.
>
> now most (actually all, to some degree) window spectra have sidelobes and
> much of what goes on with designing a good window function is to deal with
> those sidelobe bumps.  because the sidelobe of one partial will add to the
> mainlobe of another partial and possibly skew the apparent peak location
> and peak height.  one of the design goals behind the Hamming window was to
> beat down the sidelobes a little.  a more systematic approach is the Kaiser
> window which allows you to trade off sidelobe height and mainlobe width.
> you would like *both* a skinny mainlobe and small sidelobes, but you can't
> get both without increasing the window length "L".
>
> another property that *some* windows have that are of interest to the
> music-dsp crowd is that of being (or not) complementary.  that is adjacent
> windows add to 1.  this is important in **synthesis** (say in the phase
> vocoder), but is not important in **analysis**.  for example, the Kaiser
> window is not complementary, but the Hann window is.  so, if you don't need
> complementary, then you might wanna choose a window with good sidelobe
> behavior.
>
> the reason i suggested Gaussian over Kaiser was just sorta knee-jerk.
> perhaps Kaiser would be better, but one good thing about the Gaussian is
> that its F.T. is also a Gaussian (and there are other cool properties
> related to chirp functions).  a theoretical Gaussian window has no
> sidelobes.  so, if you let your Gaussian window get extremely close to zero
> before it is truncated, then it's pretty close to a theoretical Gaussian
> and you need not worry about sidelobes and the behavior of the window
> spectrum is also nearly perfectly Gaussian and you can sometimes take
> advantage of that.  like in interpolating around an apparent peak (at an
> integer FFT bin) to get the precise peak location.
>
> now you probably do not need to get this anal-retentive about it, but if
> you want to, you can look at this:
> https://www.researchgate.net/publication/3927319_Intraframe_
> time-scaling_of_nonstationary_sinusoids_within_the_phase_vocoder
> and i might have some old MATLAB code to run for it, if you want it (or
> anyone else), lemme know.
>
> big thanks for the elaborate explanation!
Looks like you've turned my head into the right direction.
Had a look at the spectrum of my window: a 4096 Hann win. in the middle of
64k samples.
A big sidelobe party!
A 64k gaussian window that just sets priority to an area of ~4096 samples
will of course fix that.

Btw.: no Matlab here. C++ only.

Best Regards,

Thomas



__

Re: [music-dsp] Oversized FFT windows --- why so little literature?

[Corey K]

I'm not sure how using IIR filters would improve latency? You still have to
worry about the duration of the filters transient response, no?

There are also the matters of 1) perfect reconstruction; and, 2)
subsampling that are often important considerations



On Sat, Aug 27, 2016 at 12:08 AM, Andy Farnell 
wrote:

>
> Hi Evan,
>
> On Fri, Aug 26, 2016 at 03:17:25PM -0500, Evan Balster wrote:
> > In the days since my first post, I've had a background train of thought
> > going on about this...
> >
> > So, the value of a DFT bin when using a window of size N is proportional
> to:
> > [image: Inline image 2]
> > Where omega is the complex frequency of the bin and K is an arbitrary
> time
> > offset.
>
> Its not a strict list etiquette here, but it would be helpful
> to a whole lot of people and to posterity of archived posts
> if you might use text. Either TeX or freehand style ascii equations
> will do fine. Otherwise a whole lot gets lost in translation
> as you can see above.
> many thanks
> Andy Farnell
>
> ___
> 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

Re: [music-dsp] Oversized FFT windows --- why so little literature?

[Corey K]

It's not done because it causes time-domain aliasing. You can think of the
DFT (or FFT) as a sampled version of the continuous frequency DTFT. If the
samples aren't dense enough, you get aliasing in the dual domain (the
time-domain in this case). This aliasing can be perfectly cancelled during
synthesis in some carefully designed filterbank implementations (e.g.,
Princeton and Bradley's technique:
http://www.sm.luth.se/csee/courses/sms/047/2004/lectures/MDCT_Princen96.pdf),
but I would venture this is more useful for codecs than audio effects or
content analysis, since the spectral data comes from the aliased
time-domain waveforms (which is probably not what you want).

-Corey​
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Time-domain noisiness estimator

[Corey K]

I don't have any links on the use of autocorrelation in this context, and I
don't even know if it would work. My basic thought, however, was that the
autocorrelation of white noise should be zero at all time lags other than
0. Pitched signals, on the other hand, should have peaks at multiples of
the pitch period. So the idea would be to see if your autocorrelation has
many prominent peaks (e.g., is a pitched sound), or is flat and small
(e.g., a noisy sound).

Best,
Corey


On Mon, Feb 22, 2016 at 12:01 AM, Dario Sanfilippo <
sanfilippo.da...@gmail.com> wrote:

> Hello.
>
> Corey: I'm honestly not so familiar with auto-correlation; I'm aware that
> it is implemented for pitch-detection but I didn't know about those other
> features; would you have a reference or link to a document I could check
> out?
>
> Evan: I get your point; in my case I was following more of a low-level and
> context-independent approach, namely that of trying to distinguish between
> periodic and non-periodic signals; indeed that's why I thought that varying
> ZCR could have worked out.
>
> James: do you mean that frequency modulated sounds and bell sounds are
> perceived as noisy although they have a non-varying ZCR? A noisy signal
> with a DC-offset would also make the algorithm faulty.
>
> Would you say that the most reliable estimation if that of the FFT-based
> flatness?
>
> Best,
> Dario
>
> On 21 February 2016 at 21:03, James McCartney  wrote:
>
>>
>> wouldn't using varying ZCR be defeated by frequency modulated or bell
>> tones?
>> One could also craft a very noisy signal with a perfectly periodic ZCR.
>> James McCartney
>>
>>
>> On Feb 19, 2016, at 04:49, Dario Sanfilippo 
>> wrote:
>>
>> Hello everybody.
>>
>> Following on a discussion about cheap/time-domain spectral centroid
>> estimators, I thought it could have been interesting to also discuss
>> time-domain noisiness estimators.
>>
>> I think that a common approach is the FFT-based spectral flatness
>> algorithm. In the time-domain, zero-crossing rate is another common
>> approach, although it seems to only work for specific cases like voiced Vs.
>> unvoiced sounds, or percussive Vs. non-percussive. A very high frequency
>> sinewave would also have a high ZCR, although it is not noisy.
>>
>> I tried implementing a rudimentary noisiness estimator based on the idea
>> that a noisy signal is characterised by a varying ZCR, rather than a high
>> ZCR. What I did was to use a differentiator on successive averaging windows
>> of ZCR, and then I averaged the absolute value of differentiator's output
>> to obtain an index.
>>
>> The algorithm seems to work fine for most cases, although some particular
>> frequencies of a sinusoidal input result in unexpected indexes. I guess
>> that a problem here is to find a good compromise in the averaging windows
>> of the ZCR. I am using 10-msec windows which seemed to work OK. I was also
>> thinking that I could make the averaging window time-variant, piloting it
>> based on a centroid estimation in order to optimes it according to the
>> spectral content of the signal.
>>
>> Does any of the above make sense for you? Are you aware of other
>> algorithms using a similar technique?
>>
>> If you're familiar with the Pure Data audio environment, you can have a
>> look at the patch here:
>> https://dl.dropboxusercontent.com/u/43961783/noisiness.jpg
>>
>> Thanks,
>> Dario
>>
>> ___
>> 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
>>
>
>
> ___
> 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

Re: [music-dsp] Time-domain noisiness estimator

[Corey K]

I haven't researched this at all, so take the following with a grain of
salt. But, how about looking at different features of the auto-correlation
(e.g., flatness, peakiness, ...)?

On Fri, Feb 19, 2016 at 1:49 PM, Dario Sanfilippo <
sanfilippo.da...@gmail.com> wrote:

> Hello everybody.
>
> Following on a discussion about cheap/time-domain spectral centroid
> estimators, I thought it could have been interesting to also discuss
> time-domain noisiness estimators.
>
> I think that a common approach is the FFT-based spectral flatness
> algorithm. In the time-domain, zero-crossing rate is another common
> approach, although it seems to only work for specific cases like voiced Vs.
> unvoiced sounds, or percussive Vs. non-percussive. A very high frequency
> sinewave would also have a high ZCR, although it is not noisy.
>
> I tried implementing a rudimentary noisiness estimator based on the idea
> that a noisy signal is characterised by a varying ZCR, rather than a high
> ZCR. What I did was to use a differentiator on successive averaging windows
> of ZCR, and then I averaged the absolute value of differentiator's output
> to obtain an index.
>
> The algorithm seems to work fine for most cases, although some particular
> frequencies of a sinusoidal input result in unexpected indexes. I guess
> that a problem here is to find a good compromise in the averaging windows
> of the ZCR. I am using 10-msec windows which seemed to work OK. I was also
> thinking that I could make the averaging window time-variant, piloting it
> based on a centroid estimation in order to optimes it according to the
> spectral content of the signal.
>
> Does any of the above make sense for you? Are you aware of other
> algorithms using a similar technique?
>
> If you're familiar with the Pure Data audio environment, you can have a
> look at the patch here:
> https://dl.dropboxusercontent.com/u/43961783/noisiness.jpg
>
> Thanks,
> Dario
>
> ___
> 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

[music-dsp] Audio freelance and consulting

[Corey K]

Hello music dsp list,


I have started a side-business as an independent audio consultant and
freelance developer. If there is anyone needing help with their audio
software development, signal processing, machine learning, or sound design,
please get in touch. My website has more information and some fun webaudio
demos:


http://www.reverberate.ca/


Cheers,
Corey Kereliuk
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp 
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp