Re: [music-dsp] Recognizing Frequency Components

[robert bristow-johnson]

 Original Message 

Subject: Re: [music-dsp] Recognizing Frequency Components

From: "Nigel Redmon" 

Date: Sat, January 28, 2017 2:38 pm

To: "A discussion list for music-related DSP" 

--



>> Always fun to extrapolate into the blue, huh ? Not so much

>

> I think people participate because they enjoy discussing audio DSP topics, so 
> things often diverge from the original question—this isn’t simply 
> an answer forum.

>
well, it was when Steffan mentioned "gaussian window" in the context of finding 
this parameter called "frequency", given a bunch of samples.
gaussian windows are tits because gaussian functions are really cool for a 
variety of reasons.


>> I read only a part fo the RBJ "From zero to first order principal component 
>> synthesis" article yet, but am aware that, just like some other 
>> generalizations, drawing from general mathematics of the last century all 
>> too enthusiastically

>

>

> Published on only the second month of the current century, I’d expect 
> Robert’s paper to draw enthusiastically on the last century ;-)

>

> Having trouble parsing that last paragraph, please excuse me if I 
> misinterpreted.

>
i can't always figure out what Theo is saying either.
i don't think of this in the context of which century. �more of an example of 
the parameter extraction problem that they teach us about in grad school. �the 
approach *was* to extract the parameters out of the
frequency-domain data. �i s'pose you can do a brute-force approach in the time 
domain and posit a slew of sinusoids with different frequencies. �for each 
proposed frequency, it is pretty straight forward to extract the amplitude and 
phase of a sinusoid of that frequency that has the
least-mean-square error (you get the amplitudes on the cosine and sine 
component).
you do that for each proposed frequency and pick the frequency that has the 
smallest mean-square error. �then maybe do some searching around that "best" 
frequency to find an even better frequency
that is close by.
the sinusoidal modeling proposed in the paper essentially can come to a best 
guess of the frequency (and the sweep rate and the amplitude ramp rate) without 
trial-and-error searching. �it chooses those three parameters in such a way to 
best match the quadratic exponent
of the gaussian pulse in the frequency domain that each sinusoid will leave. 
�that's what it's for. �then, i s'pose, you can get the amplitude and the phase 
of the chirpy sinusoid similar as before now that you have a frequency to work 
with. �then you have a full description of the
sinusoid (to the extent of its frequency and sweep and ramp rates, but not 
higher-order terms) that you can use in modification and reconstruction.

--
r b-j � � � � � � � � �r...@audioimagination.com
"Imagination is more important than knowledge."
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Recognizing Frequency Components

[Nigel Redmon]

> Always fun to extrapolate into the blue, huh ? Not so much

I think people participate because they enjoy discussing audio DSP topics, so 
things often diverge from the original question—this isn’t simply an answer 
forum.

> I read only a part fo the RBJ "From zero to first order principal component 
> synthesis" article yet, but am aware that, just like some other 
> generalizations, drawing from general mathematics of the last century all too 
> enthusiastically


Published on only the second month of the current century, I’d expect Robert’s 
paper to draw enthusiastically on the last century ;-)

Having trouble parsing that last paragraph, please excuse me if I 
misinterpreted.


> On Jan 28, 2017, at 10:19 AM, Theo Verelst  wrote:
> 
> 
> Always fun to extrapolate into the blue, huh ? Not so much, while it's 
> interesting to look at FFTs and try to form an opinion on using some (maybe 
> readily available) form of it to analyze a frequency, and maybe even 
> interesting parallel/pipe-lined versions are FOS available, it's not just a 
> lot of computations (your DSP maybe doesn't have time for) for the purpose, 
> it's also not the best averaging function for determining precise 
> frequencies. Apart from errors stemming from the fact that the FFT interval 
> often won't match the length of the waveform (like our sine wave)  being 
> measured, any further reasoning on the basis of the used FFT's main interval 
> will be biased in that it is assumed the actual waveform is being 
> transformed. This is not true, there is no inherent reconstruction of the 
> waveform going on in the FFT, and "averaging" batches or streaming 
> measurements doesn't accurately remedy this. The Hilbert transform of the 
> required integral of sinc functions isn't a constant, it can not be 
> ultimately accurate unless in this example we measure smarter, or perform 
> (costly and high latency) reconstruction computations.
> 
> Having used the correct hypothesis that our sampled sine has the form
> 
>  A*sin(f*x+p)
> 
> It should be possible to check samples across the proposed 10 seconds (e.g. 
> 44,100 * 10 samples) of "measurement" and arrive at pretty stunning accuracy! 
> Using various types of measurement might be interesting to prevent the 
> incircumventable additions of errors from getting a standard type of bias 
> that will make future audio computations on the basis of the results subject 
> to a character that is hard to remove, once it has entered. It (in know from 
> experience) is easy to add (and find) components in audio signals that come 
> up relatively clear in FFT type of computations, and can send that peak up 
> and down and a bin back and forth easily. Other filters have their own 
> character as well. Arriving at a overall as neutral as possible digital 
> signal path, for instance int the sense of sensibly taking care of errors 
> staying statistically independent and/or  not easily accumulate to sound of 
> certain modern audio products is a real challenge!
> 
> I read only a part fo the RBJ "From zero to first order principal component 
> synthesis" article yet, but am aware that, just like some other 
> generalizations, drawing from general mathematics of the last century all too 
> enthusiastically, making a number of possibly incorrect assumptions will not 
> necessarily create a strong or mathematically sound proof set of theorems.. 
> Wavelets, (semi-) orthogonal filter banks, and wonderful Gaussian summings 
> are no exception, even though it is an interesting and challenging subject.
> 
> T.V.
> ___
> 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] Recognizing Frequency Components

[Theo Verelst]

Always fun to extrapolate into the blue, huh ? Not so much, while it's interesting to look 
at FFTs and try to form an opinion on using some (maybe readily available) form of it to 
analyze a frequency, and maybe even interesting parallel/pipe-lined versions are FOS 
available, it's not just a lot of computations (your DSP maybe doesn't have time for) for 
the purpose, it's also not the best averaging function for determining precise 
frequencies. Apart from errors stemming from the fact that the FFT interval often won't 
match the length of the waveform (like our sine wave)  being measured, any further 
reasoning on the basis of the used FFT's main interval will be biased in that it is 
assumed the actual waveform is being transformed. This is not true, there is no inherent 
reconstruction of the waveform going on in the FFT, and "averaging" batches or streaming 
measurements doesn't accurately remedy this. The Hilbert transform of the required 
integral of sinc functions isn't a constant, it can not be ultimately accurate unless in 
this example we measure smarter, or perform (costly and high latency) reconstruction 
computations.


Having used the correct hypothesis that our sampled sine has the form

  A*sin(f*x+p)

It should be possible to check samples across the proposed 10 seconds (e.g. 44,100 * 10 
samples) of "measurement" and arrive at pretty stunning accuracy! Using various types of 
measurement might be interesting to prevent the incircumventable additions of errors from 
getting a standard type of bias that will make future audio computations on the basis of 
the results subject to a character that is hard to remove, once it has entered. It (in 
know from experience) is easy to add (and find) components in audio signals that come up 
relatively clear in FFT type of computations, and can send that peak up and down and a bin 
back and forth easily. Other filters have their own character as well. Arriving at a 
overall as neutral as possible digital signal path, for instance int the sense of sensibly 
taking care of errors staying statistically independent and/or  not easily accumulate to 
sound of certain modern audio products is a real challenge!


I read only a part fo the RBJ "From zero to first order principal component synthesis" 
article yet, but am aware that, just like some other generalizations, drawing from general 
mathematics of the last century all too enthusiastically, making a number of possibly 
incorrect assumptions will not necessarily create a strong or mathematically sound proof 
set of theorems.. Wavelets, (semi-) orthogonal filter banks, and wonderful Gaussian 
summings are no exception, even though it is an interesting and challenging subject.


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

Re: [music-dsp] Recognizing Frequency Components

[Nigel Redmon]

OK, I see the idea has been brought up—here’s a 15-minute video from the course 
that gets to the point (“peak detection” refers to frequency peaks/centers in 
the FFT data):

https://www.coursera.org/learn/audio-signal-processing/lecture/cJmOi/peak-detection


> On Jan 28, 2017, at 9:44 AM, Nigel Redmon  wrote:
> 
> I haven’t had time to follow, maybe don’t understand the request or have 
> missed similar replies…I took the debut session of this free course in 2015, 
> excellent:
> 
> https://www.coursera.org/course/audio 
> 
> The usual overlapping FFTs, the trick that I hadn’t thought of is fitting a 
> parabola (window shape) to find frequency centers between “bins”. The goal 
> being not just the fundamental, but harmonics (so you can operate notes out 
> of music, including tracking of pitch modulation, etc., for resynthesis). The 
> course includes the use of a Python toolkit, sms-tools, which you can work 
> with without taking the course:
> 
> https://github.com/MTG/sms-tools 
> 
> 
>> On Jan 28, 2017, at 3:09 AM, Andrew Simper > > wrote:
>> 
>> I thought the common way to do it was to take two FFTs really close to each 
>> other, one or more samples depending on which frequencies you want the best 
>> resolution for, and do phase differencing to work out the frequency. Seems 
>> to work pretty well in the little test I just did, and is robust in the 
>> presence of additive gaussian noise. Also long as you have at least four 
>> cycles of your sine wave in the FFT block you can get to around a cent 
>> accuracy, more if you have more cycles.
>> 
>> Cheers,
>> 
>> Andy
>> 
>> On 27 January 2017 at 19:32, STEFFAN DIEDRICHSEN > > wrote:
>> Here it is from our nuclear friends at CERN:
>> 
>> https://mgasior.web.cern.ch/mgasior/pap/FFT_resol_note.pdf 
>> 
>> 
>> 
>> Steffan
>> 
>> 
>> 
>>> On 26.01.2017|KW4, at 20:01, robert bristow-johnson 
>>> mailto:r...@audioimagination.com>> wrote:
>>> 
>>> i thought Steffan mentioned something about using a Gaussian window.  he 
>>> mentioned a paper he found but did not identify it.  i am a little curious.
>>> 
>>> 
>> 
>> 
>> ___
>> 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] Recognizing Frequency Components

[Nigel Redmon]

I haven’t had time to follow, maybe don’t understand the request or have missed 
similar replies…I took the debut session of this free course in 2015, excellent:

https://www.coursera.org/course/audio 

The usual overlapping FFTs, the trick that I hadn’t thought of is fitting a 
parabola (window shape) to find frequency centers between “bins”. The goal 
being not just the fundamental, but harmonics (so you can operate notes out of 
music, including tracking of pitch modulation, etc., for resynthesis). The 
course includes the use of a Python toolkit, sms-tools, which you can work with 
without taking the course:

https://github.com/MTG/sms-tools


> On Jan 28, 2017, at 3:09 AM, Andrew Simper  wrote:
> 
> I thought the common way to do it was to take two FFTs really close to each 
> other, one or more samples depending on which frequencies you want the best 
> resolution for, and do phase differencing to work out the frequency. Seems to 
> work pretty well in the little test I just did, and is robust in the presence 
> of additive gaussian noise. Also long as you have at least four cycles of 
> your sine wave in the FFT block you can get to around a cent accuracy, more 
> if you have more cycles.
> 
> Cheers,
> 
> Andy
> 
> On 27 January 2017 at 19:32, STEFFAN DIEDRICHSEN  > wrote:
> Here it is from our nuclear friends at CERN:
> 
> https://mgasior.web.cern.ch/mgasior/pap/FFT_resol_note.pdf 
> 
> 
> 
> Steffan
> 
> 
> 
>> On 26.01.2017|KW4, at 20:01, robert bristow-johnson 
>> mailto:r...@audioimagination.com>> wrote:
>> 
>> i thought Steffan mentioned something about using a Gaussian window.  he 
>> mentioned a paper he found but did not identify it.  i am a little curious.
>> 
>> 
> 
> 
> ___
> 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] Recognizing Frequency Components

[Andrew Simper]

I thought the common way to do it was to take two FFTs really close to each
other, one or more samples depending on which frequencies you want the best
resolution for, and do phase differencing to work out the frequency. Seems
to work pretty well in the little test I just did, and is robust in the
presence of additive gaussian noise. Also long as you have at least four
cycles of your sine wave in the FFT block you can get to around a cent
accuracy, more if you have more cycles.

Cheers,

Andy

On 27 January 2017 at 19:32, STEFFAN DIEDRICHSEN 
wrote:

> Here it is from our nuclear friends at CERN:
>
> https://mgasior.web.cern.ch/mgasior/pap/FFT_resol_note.pdf
>
>
> Steffan
>
>
>
> On 26.01.2017|KW4, at 20:01, robert bristow-johnson <
> r...@audioimagination.com> wrote:
>
> i thought Steffan mentioned something about using a Gaussian window.  he
> mentioned a paper he found but did not identify it.  i am a little curious.
>
>
>
> ___
> 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] Recognizing Frequency Components

[robert bristow-johnson]

�
thanks Steffan.
i am looking cursorily�at the paper. �about 15 years ago i did some work in 
sinusoidal modeling and noticed a useful feature of the Gaussian: that the 
Fourier transform of a gaussian is time domain is a gaussian in the frequency 
domain. � and
similarly for a linearly-swept frequency chirp. �and the similarity between the 
gaussian and the chirp.
they are both e^(-a t^2), but for the chirp the "a" factor might have a "j" or 
an "i" in it.
i got some nice results for how, using a gaussian
window, you can extract the frequency, the sweep rate on the frequency, and the 
ramp rate on the amplitude of a sinusoidal chirp. �it's in an IEEE WASPAA 
(Mohonk) paper from 2001.
�http://ieeexplore.ieee.org/document/969581/�
you might get a free copy
at
�https://www.researchgate.net/publication/3927319_Intraframe_time-scaling_of_nonstationary_sinusoids_within_the_phase_vocoder�
if the researchgate doesn't get you the doc, lemme know and i will email it to 
you.
anyway, i want to make one observation regarding the CERN
paper and the parabolic interpolation to find the "true" peak from the discrete 
peak and the two neighboring points. �while it is true that when using 
parabolic or quadratic interpolation on the *magnitude* or *magnitude-squared* 
can result in some small error (and different window
functions may be compared), there is no theoretical error if you're using a 
gaussian window *and* you are observing the logarithm of magnitude. �using a 
gaussian window in the time domain results in a gaussian function in the 
frequency domain for a single sinusoid. �and in the
log-magnitude domain, the curve is precisely a quadratic, so the 3-point 
interpolation works perfectly well in that case. �perhaps the CERN paper says 
that also, but it looked like they were comparing this interpolation error in 
the not-logged magnitude given a few different windows.

--
r b-j � � � � � � � � �r...@audioimagination.com
"Imagination is more important than knowledge."




-------- Original Message --------

Subject: Re: [music-dsp] Recognizing Frequency Components

From: "STEFFAN DIEDRICHSEN" 

Date: Fri, January 27, 2017 6:32 am

To: r...@audioimagination.com

music-dsp@music.columbia.edu

--



> Here it is from our nuclear friends at CERN:

>

> https://mgasior.web.cern.ch/mgasior/pap/FFT_resol_note.pdf 
> <https://mgasior.web.cern.ch/mgasior/pap/FFT_resol_note.pdf>

>

>

> Steffan

>

>

>

>> On 26.01.2017|KW4, at 20:01, robert bristow-johnson 
>>  wrote:

>>

>> i thought Steffan mentioned something about using a Gaussian window. he 
>> mentioned a paper he found but did not identify it. i am a little curious.

>>

>>

>

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

Re: [music-dsp] Recognizing Frequency Components

[Theo Verelst]

Some serious articles !

From a dry but hopefully somewhat interesting scientific point of view I'd think you need 
only 4 samples of the original example (accurate quantization, perfectly equal sample 
distance, noise and distortion-free sine samples), because you need to estimate amplitude, 
frequency, phase and offset, or 3, if you allow the latter to be zero. 3 Unknowns with not 
too wild non-linear equations, should be solvable system with 3 or just a few more points 
of data (the few more for possible coinciding data points as a consequence of getting a 
repeat or phase problem wrong, I didn't think that through). Every doubling of data length 
from henceforth should double vertical resolution (presuming computations way more 
accurate than the sample data). In an new fashioned system, maybe very fast intelligent 
associative memory could be used to simply look up wave patterns from a small database in 
parallel to find a close match without computations, but containing low vertical match 
accuracy..


Many DSP methods can apply, I'm sure something can be done with an FFT, certainly a 
(convergent ?) variable length one, or a Discrete Fourier Transform with a length which 
isn't related to sample frequency in some way. Fouriers have the advantage of the 
orthogonal basis such that pure harmonics can be instantly and uniquely quantified as well 
as the fundamental, which is the only tone present in my example.


An octave filter bank, just like a single low-cut filter, either analog (if we would have 
an analog signal source to work with) or digital could give a pretty fast estimate of the 
octave the tone is in. An iterating, calibrated digital resonant filter, or a "parallel 
running" sine wave generator algorithm subtracting from the signal with iterating 
parameters might work well. It's not easy to get, say, a 1 cent (1 percent of a semi-tone 
interval) frequency measurement resolution, but using a long sample of good purity testing 
shouldn't be overly problematic.


A fun solution IMO woudl be to use some interesting (streaming, special chip enhanced) 
method to upsample the example to much higher sampling frequency with a real accurate sinc 
filter, say for the middle 3 seconds with a filter width of 3 seconds (or more !), and 
fill a significant portion of a modern PCs main memory with the result and imitate fast 
frequency recognition methods from analog (measurement) domain in their equivalent (..) 
digital form.


Theo V.

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

Re: [music-dsp] Recognizing Frequency Components

[STEFFAN DIEDRICHSEN]

Here it is from our nuclear friends at CERN:

https://mgasior.web.cern.ch/mgasior/pap/FFT_resol_note.pdf 



Steffan



> On 26.01.2017|KW4, at 20:01, robert bristow-johnson 
>  wrote:
> 
> i thought Steffan mentioned something about using a Gaussian window.  he 
> mentioned a paper he found but did not identify it.  i am a little curious.
> 
> 

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

Re: [music-dsp] Recognizing Frequency Components

[Greg Berchin]

>>As a first main question, seeming a bit overly boring: how do we determine, 
>>or measure, 
>>the frequency of this component, and as accurate as possible or to a certain 
>>good enough 
>>error bound, the initial phase and amplitude ?

"EVALUATION OF A STANDARDIZED SINE WAVE FIT ALGORITHM"; Peter Händel

"Improved Determination of the Best Fitting Sine Wave in ADC Testing";
István Kollár and Jerome J. Blair

"Standardized sinus-wave Fitting algorithms, extensions and
applications"; Tomas Andersson and Peter Händel

===

"Flight, try SCE to 'AUX'."

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

Re: [music-dsp] Recognizing Frequency Components

[Alan Wolfe]

As things change hands, or go through multiple layers of translation and
sanitation, sometimes < becomes < and then gets stripped by the next
thing.

Might try something like this hehe: <

Let's be honest, the web is a mess :P

On Thu, Jan 26, 2017 at 2:38 PM, Bjorn Roche  wrote:

>
>
> On Thu, Jan 26, 2017 at 2:40 PM, Martin Klang 
> wrote:
>
>> try putting < instead of less-than.
>>
> That's exactly what I did last time. My impression is that Blogger doesn't
> have a canonical data representation.
>
>
>> On 26/01/17 19:28, Bjorn Roche wrote:
>>
>> On Thu, Jan 26, 2017 at 2:09 PM, Alan Wolfe  wrote:
>>
>>> It's some HTML filtering happening somewhere between (or including) his
>>> machine and yours.
>>>
>>>
>> It's Blogger. I've fixed this before and apparently it comes back :(. I
>> think Google's more or less abandoned Blogger. I'd switch to something else
>> if I ever blogged anymore.
>>
>> bjorn
>>
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
>
> --
> Bjorn Roche
> @shimmeoapp
>
> ___
> 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] Recognizing Frequency Components

[Bjorn Roche]

On Thu, Jan 26, 2017 at 2:40 PM, Martin Klang  wrote:

> try putting < instead of less-than.
>
That's exactly what I did last time. My impression is that Blogger doesn't
have a canonical data representation.


> On 26/01/17 19:28, Bjorn Roche wrote:
>
> On Thu, Jan 26, 2017 at 2:09 PM, Alan Wolfe  wrote:
>
>> It's some HTML filtering happening somewhere between (or including) his
>> machine and yours.
>>
>>
> It's Blogger. I've fixed this before and apparently it comes back :(. I
> think Google's more or less abandoned Blogger. I'd switch to something else
> if I ever blogged anymore.
>
> bjorn
>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>



-- 
Bjorn Roche
@shimmeoapp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Recognizing Frequency Components

[Martin Klang]

try putting < instead of less-than.


Martin


On 26/01/17 19:28, Bjorn Roche wrote:
> On Thu, Jan 26, 2017 at 2:09 PM, Alan Wolfe  > wrote:
>
> It's some HTML filtering happening somewhere between (or
> including) his machine and yours.
>
>
> It's Blogger. I've fixed this before and apparently it comes back :(.
> I think Google's more or less abandoned Blogger. I'd switch to
> something else if I ever blogged anymore.
>
> bjorn
>

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

Re: [music-dsp] Recognizing Frequency Components

[Bjorn Roche]

On Thu, Jan 26, 2017 at 2:09 PM, Alan Wolfe  wrote:

> It's some HTML filtering happening somewhere between (or including) his
> machine and yours.
>
>
It's Blogger. I've fixed this before and apparently it comes back :(. I
think Google's more or less abandoned Blogger. I'd switch to something else
if I ever blogged anymore.

bjorn


-- 
Bjorn Roche
@shimmeoapp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Recognizing Frequency Components

[Alan Wolfe]

It's some HTML filtering happening somewhere between (or including) his
machine and yours.

The less than of the for loop is being seen as the start of an HTML tag, or
just possibly part of the start of an HTML tag and being stripped away.

A common problem when providing code snippets on the web via email or in
forums etc. Generally due to software not doing proper sanitizing at some
step along the way :P

On Thu, Jan 26, 2017 at 11:06 AM, robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
>  Original Message --------
> Subject: Re: [music-dsp] Recognizing Frequency Components
> From: "Bjorn Roche" 
> Date: Thu, January 26, 2017 10:57 am
> To: "A discussion list for music-related DSP" <
> music-dsp@music.columbia.edu>
> --
>
> > I wrote a blog post a while ago about how to use FFT to find the pitch of
> > an instrument. As I mention in the post, this is hardly the best way,
> but I
> > think it's suitable for many applications. For example, you could write a
> > perfectly serviceable guitar tuner with this.
> >
> > The post links to code and includes some discussion of specific issues of
> > time/frequency resolution and so on.
> >
> > I've been wanting to write about other methods, but... maybe when I
> retire
> > :)
> >
> > http://blog.bjornroche.com/2012/07/frequency-detection-
> using-fft-aka-pitch.html
> >
>
> Bjorn, you *must* be aware of this because it appears 3 times, but why are
> your for() statements truncated?
>
> e.g.
>
> void applyWindow( float *window, float *data, int size )
> {
>for( int i=0; i
>   data[i] *= window[i] ;
> }
>
>
> --
>
> r b-j  r...@audioimagination.com
>
> "Imagination is more important than knowledge."
>
> ___
> 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] Recognizing Frequency Components

[robert bristow-johnson]

 Original Message 

Subject: Re: [music-dsp] Recognizing Frequency Components

From: "Bjorn Roche" 

Date: Thu, January 26, 2017 10:57 am

To: "A discussion list for music-related DSP" 

--



> I wrote a blog post a while ago about how to use FFT to find the pitch of

> an instrument. As I mention in the post, this is hardly the best way, but I

> think it's suitable for many applications. For example, you could write a

> perfectly serviceable guitar tuner with this.

>

> The post links to code and includes some discussion of specific issues of

> time/frequency resolution and so on.

>

> I've been wanting to write about other methods, but... maybe when I retire

> :)

>

> http://blog.bjornroche.com/2012/07/frequency-detection-using-fft-aka-pitch.html

>
Bjorn, you *must* be aware of this because it appears 3 times, but why are your 
for() statements truncated?
e.g.
void applyWindow( float *window, float *data, int size ){� �for( int i=0; i� � 
� data[i] *= window[i] ;}


--
r b-j � � � � � � � � �r...@audioimagination.com
"Imagination is more important than knowledge."
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Recognizing Frequency Components

[robert bristow-johnson]

 Original Message 

Subject: Re: [music-dsp] Recognizing Frequency Components

From: "Evan Balster" 

Date: Thu, January 26, 2017 12:36 pm

To: music-dsp@music.columbia.edu

--



> Philosophy rant: Frequency is a model. You can use tools that build on

> that model to describe your signal in terms of frequency, but none of them

> are going to be perfect. A pure 10hz tone is a mathematical abstraction

> which you'll not find in any digital signal or measurable phenomenon.
uhm, once a sinusoid is isolated (and in the OP's case there is only this 
single sinusoid), frequency is not merely a mathematical abstraction. �it has a 
definite mathematical definition and it is the time rate of
change of phase of that sinusoid.

> But, *ooh�boy!* is that abstraction useful for modeling real things.

>

> If you have an extremely clean signal and you want an extremely accurate

> measurement, my recommendation is to forgo fourier transforms (which

> introduce noise and resolution limits) and use optimization or measurement

> techniques in the time domain. In your example, *zero crossings are the

> easiest and best solution* as Steffan suggests.
certainly the easiest. �might have to do something in between samples at the 
zero crossing.
i thought Steffan mentioned something about using a Gaussian window. �he 
mentioned a paper he found but did not identify it. �i
am a little curious.
there were a few folks doing sinusoidal modeling, and folks in this group 
probably don't think of sinusoids as static but with changing frequency and 
changing amplitude. �turns out that windowing with Gaussian leads to some very 
nice analytic results for obtaining
instantaneous frequency, sweep rate on the frequency, and ramp rate on the 
amplitude (as well as the amplitude and phase of the sinusoid in the center of 
the window).

> Another interesting approach, which I mention for scholarly purposes, would

> be to design a digital filter with a sloping magnitude response (even the

> simplest one-pole lowpass could do) and apply it across the signal. You

> can measure the change in the signal's power (toward the end, because the

> sudden beginning of a sine wave produces noise) and find the frequency for

> which the filter's transfer function produces that attenuation. This

> filter-based technique (and related ones) can generalize to other problems

> where zero-crossings are less useful.

>
*only* once (when i was sorta copying an idea patented in the AXON pitch 
detector, which is really fast, like 12 or 13 ms) have i ever used 
zero-crossing for any pitch or frequency measurement. �attacks are a problem, 
but outside of the attack of a note, i can't think of
zero-crossings as useful for anything. �(some people have written that they 
apply gain changes at zero-crossings to reduce the zipper. i don't think it's 
such a good idea.)
�
--
r b-j � � � � � � � �
�r...@audioimagination.com
"Imagination is more important than knowledge."___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Recognizing Frequency Components

[Bjorn Roche]

I wrote a blog post a while ago about how to use FFT to find the pitch of
an instrument. As I mention in the post, this is hardly the best way, but I
think it's suitable for many applications. For example, you could write a
perfectly serviceable guitar tuner with this.

The post links to code and includes some discussion of specific issues of
time/frequency resolution and so on.

I've been wanting to write about other methods, but... maybe when I retire
:)

http://blog.bjornroche.com/2012/07/frequency-detection-using-fft-aka-pitch.html

On Thu, Jan 26, 2017 at 12:36 PM, Evan Balster  wrote:

> Philosophy rant:  Frequency is a model.  You can use tools that build on
> that model to describe your signal in terms of frequency, but none of them
> are going to be perfect.  A pure 10hz tone is a mathematical abstraction
> which you'll not find in any digital signal or measurable phenomenon.  But, 
> *ooh
> boy!* is that abstraction useful for modeling real things.
>
> If you have an extremely clean signal and you want an extremely accurate
> measurement, my recommendation is to forgo fourier transforms (which
> introduce noise and resolution limits) and use optimization or measurement
> techniques in the time domain.  In your example, *zero crossings are the
> easiest and best solution* as Steffan suggests.
>
> Another interesting approach, which I mention for scholarly purposes,
> would be to design a digital filter with a sloping magnitude response (even
> the simplest one-pole lowpass could do) and apply it across the signal.
> You can measure the change in the signal's power (toward the end, because
> the sudden beginning of a sine wave produces noise) and find the frequency
> for which the filter's transfer function produces that attenuation.  This
> filter-based technique (and related ones) can generalize to other problems
> where zero-crossings are less useful.
>
> – Evan Balster
> creator of imitone 
>
> On Thu, Jan 26, 2017 at 9:20 AM, STEFFAN DIEDRICHSEN 
> wrote:
>
>> At that length, you can count zero-crossings. But that’s not a valid
>> answer, I’d assume.
>> But I found a nice paper on determining frequencies with FFTs using a
>> gaussian window.  Pretty accurate results.
>>
>> Best,
>>
>> Steffan
>>
>>
>> On 26.01.2017|KW4, at 15:24, Theo Verelst  wrote:
>>
>> Say the sample length is long enough for any purpose, like 10 seconds.
>>
>>
>>
>> ___
>> 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
>



-- 
Bjorn Roche
@shimmeoapp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Recognizing Frequency Components

[Evan Balster]

Philosophy rant:  Frequency is a model.  You can use tools that build on
that model to describe your signal in terms of frequency, but none of them
are going to be perfect.  A pure 10hz tone is a mathematical abstraction
which you'll not find in any digital signal or measurable phenomenon.
But, *ooh
boy!* is that abstraction useful for modeling real things.

If you have an extremely clean signal and you want an extremely accurate
measurement, my recommendation is to forgo fourier transforms (which
introduce noise and resolution limits) and use optimization or measurement
techniques in the time domain.  In your example, *zero crossings are the
easiest and best solution* as Steffan suggests.

Another interesting approach, which I mention for scholarly purposes, would
be to design a digital filter with a sloping magnitude response (even the
simplest one-pole lowpass could do) and apply it across the signal.  You
can measure the change in the signal's power (toward the end, because the
sudden beginning of a sine wave produces noise) and find the frequency for
which the filter's transfer function produces that attenuation.  This
filter-based technique (and related ones) can generalize to other problems
where zero-crossings are less useful.

– Evan Balster
creator of imitone 

On Thu, Jan 26, 2017 at 9:20 AM, STEFFAN DIEDRICHSEN 
wrote:

> At that length, you can count zero-crossings. But that’s not a valid
> answer, I’d assume.
> But I found a nice paper on determining frequencies with FFTs using a
> gaussian window.  Pretty accurate results.
>
> Best,
>
> Steffan
>
>
> On 26.01.2017|KW4, at 15:24, Theo Verelst  wrote:
>
> Say the sample length is long enough for any purpose, like 10 seconds.
>
>
>
> ___
> 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] Recognizing Frequency Components

[STEFFAN DIEDRICHSEN]

At that length, you can count zero-crossings. But that’s not a valid answer, 
I’d assume. 
But I found a nice paper on determining frequencies with FFTs using a gaussian 
window.  Pretty accurate results. 

Best,

Steffan 


> On 26.01.2017|KW4, at 15:24, Theo Verelst  wrote:
> 
> Say the sample length is long enough for any purpose, like 10 seconds.
> 

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