On 10/22/12 5:51 AM, Ulf Samuelsson wrote:
>
> TC Electronics is a professional audio company.

there is no doubt of that.

> (U2 is/was one of their
> customers) so it is not a cheap gizmo.
> They have applied for a lot of patents on this technology, which
> you would want to avoid.

the use of autocorrelation for pitch detection has existed long before 
TC existed as a company.  lotsa prior art.  but i believe, especially 
when they were involved with IVL and Helicon, that they developed some 
patented pitch detection techniques.

if anyone is experimenting with pitch detection, either with AMDF, ASDF, 
autocorrelation (which is ASDF turned upside down), feature detection 
and matching, zero-crossing (which i don't recommend), etc. there is 
little danger of stepping on someone else's *valid* patent.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

rickman skrev 2012-09-05 22:13:
> On 8/21/2012 1:41 PM, robert bristow-johnson wrote:
>> On 8/21/12 9:31 AM, rickman wrote:
>>> On 8/18/2012 11:40 PM, robert bristow-johnson wrote:
>>>> On 8/18/12 10:50 PM, rickman wrote:
>>>>>
>>>>> My current thinking is that no matter what method I go with, it
>>>>> needs to
>>>>> be very high "performance", meaning highly accurate and reasonably
>>>>> fast.
>>>>> I believe the market is not large for this particular device. So
>>>>> better
>>>>> to go Cadillac and charge a price premium than to try to find a
>>>>> spot in
>>>>> a crowded, high volume market.



>>>>
>>>> then i'm pretty sure that autocorrelation or AMDF or ASDF is what
>>>> you'll
>>>> want to do.
>>>
>>> I'll have to lookup the AMDF and ASDF.
>>>
>>
>> Average Magnitude/Squared Difference Function
>>
>>
>>>
>>>>> So that means, will an auto-corr approach do a good job of resolving a
>>>>> fraction of a cent for a tuner in less than say the two or three
>>>>> seconds
>>>>> a note will sustain? I would have to consider just how accurate the
>>>>> auto-corr might be.
>>>>
>>>> pretty accurate, but *any* pitch detector *can* possibly have octave
>>>> errors (it's what can happen if you have inaudible sub-harmonics). then
>>>> you need to program the thing to have a little bit of common sense to
>>>> avoid some of the dumber octave errors. i think that looking for energy
>>>> at the frequency of the fundamental is a dumb octave error because
>>>> there
>>>> could be more energy at the 2nd harmonic or the 3rd harmonic and your
>>>> alg might think that either of those is the fundamental frequency.
>>>
>>> Yes, but the harmonics will fall at certain ratios which won't match if
>>> you pick a harmonic in place of the fundamental. Also, won't the energy
>>> of the harmonics add into the lag for the fundamental?
>>
>> then you'll be sweeping some kinda comb on the data.
>>
>>>> does your DSP or whatever processor have conditional branch
>>>> instructions? you don't need to compute the whole autocorrelation (all
>>>> of the lags) for each and every sample. in fact, you might just compute
>>>> *one* lag per sample and have a couple of special states where you set
>>>> up the autocorrelation and where you process or scan the results of the
>>>> autocorrelation to come up with a period length. and you can do some
>>>> interpolation-like stuff to get the period to a precision of a fraction
>>>> of a sample period. i.e. look for the peak where it falls between two
>>>> integer lags. it's not hard.
>>>
>>> I get the interpolation thing, that's fairly obvious, but I don't
>>> understand the comment about the one lag per sample and special states.
>>
>> it's a programming issue. some samples you will compute *one* point of
>> the autocorrelation. and when you have filled up the table, you need to
>> examine what you computed, that is a special mode of your program and
>> you won't have time to compute a new point of autocorrelation and you
>> won't need to. it's a manner to distribute the work over many different
>> sampling periods to reduce the worst-case timing cost.
>>
>>> The problem with interpolation is that it can only interpolate to some
>>> extent. Essentially this is a method of measuring the period of signals.
>>
>> yup and that period may very well not be an integer number of samples.
>
> I did some simulations looking at a tone in the presence of harmonics
> and in the presence of noise using the autocorr, the ASDF and the AMDF
> with the sample rate far above what is required by the Nyquist
> criterion.  The autocorr gives big fat peaks that are hard to pinpoint.
>   The ASDF has somewhat fat valleys but is not much disturbed by the
> noise.  The AMDF without noise has very sharp valleys which are very
> easy to pinpoint, but with noise these get rounded.  But with even high
> amplitude noise the valleys of the AMDF are easier to distinguish than
> the ASDF.
>
> I read somewhere here that another poster preferred the ASDF in the
> presence of noise.  The values of the AMDF are more affected by the
> noise than in the ASDF, but it looks to me like pinpointing the proper
> peak (or is it anti-peak?) value is easier with the AMDF even with the
> noise.  I still have some other testing to do.
>
> Meanwhile I expect my customer to pick the low cost spread and not do
> the tuner option at all.  But who knows?  Customers can be strange beasts.
>
> Rick

Didn't see the beginning of the thread, but if anyone wants a Guitar
tuner you can get the PolyTune from TC Electronics.

http://www.tcelectronic.com/polytune.asp

It should retail below $100.

There is also an iPhone app at $3.99
http://www.tcelectronic.com/polytune-iphone-app.asp

TC Electronics is a professional audio company. (U2 is/was one of their
customers) so it is not a cheap gizmo.
They have applied for a lot of patents on this technology, which
you would want to avoid.

BR
Ulf Samuelsson

On 8/21/2012 1:41 PM, robert bristow-johnson wrote:
> On 8/21/12 9:31 AM, rickman wrote:
>> On 8/18/2012 11:40 PM, robert bristow-johnson wrote:
>>> On 8/18/12 10:50 PM, rickman wrote:
>>>>
>>>> My current thinking is that no matter what method I go with, it
>>>> needs to
>>>> be very high "performance", meaning highly accurate and reasonably
>>>> fast.
>>>> I believe the market is not large for this particular device. So better
>>>> to go Cadillac and charge a price premium than to try to find a spot in
>>>> a crowded, high volume market.
>>>
>>> then i'm pretty sure that autocorrelation or AMDF or ASDF is what you'll
>>> want to do.
>>
>> I'll have to lookup the AMDF and ASDF.
>>
>
> Average Magnitude/Squared Difference Function
>
>
>>
>>>> So that means, will an auto-corr approach do a good job of resolving a
>>>> fraction of a cent for a tuner in less than say the two or three
>>>> seconds
>>>> a note will sustain? I would have to consider just how accurate the
>>>> auto-corr might be.
>>>
>>> pretty accurate, but *any* pitch detector *can* possibly have octave
>>> errors (it's what can happen if you have inaudible sub-harmonics). then
>>> you need to program the thing to have a little bit of common sense to
>>> avoid some of the dumber octave errors. i think that looking for energy
>>> at the frequency of the fundamental is a dumb octave error because there
>>> could be more energy at the 2nd harmonic or the 3rd harmonic and your
>>> alg might think that either of those is the fundamental frequency.
>>
>> Yes, but the harmonics will fall at certain ratios which won't match if
>> you pick a harmonic in place of the fundamental. Also, won't the energy
>> of the harmonics add into the lag for the fundamental?
>
> then you'll be sweeping some kinda comb on the data.
>
>>> does your DSP or whatever processor have conditional branch
>>> instructions? you don't need to compute the whole autocorrelation (all
>>> of the lags) for each and every sample. in fact, you might just compute
>>> *one* lag per sample and have a couple of special states where you set
>>> up the autocorrelation and where you process or scan the results of the
>>> autocorrelation to come up with a period length. and you can do some
>>> interpolation-like stuff to get the period to a precision of a fraction
>>> of a sample period. i.e. look for the peak where it falls between two
>>> integer lags. it's not hard.
>>
>> I get the interpolation thing, that's fairly obvious, but I don't
>> understand the comment about the one lag per sample and special states.
>
> it's a programming issue. some samples you will compute *one* point of
> the autocorrelation. and when you have filled up the table, you need to
> examine what you computed, that is a special mode of your program and
> you won't have time to compute a new point of autocorrelation and you
> won't need to. it's a manner to distribute the work over many different
> sampling periods to reduce the worst-case timing cost.
>
>> The problem with interpolation is that it can only interpolate to some
>> extent. Essentially this is a method of measuring the period of signals.
>
> yup and that period may very well not be an integer number of samples.

I did some simulations looking at a tone in the presence of harmonics 
and in the presence of noise using the autocorr, the ASDF and the AMDF 
with the sample rate far above what is required by the Nyquist 
criterion.  The autocorr gives big fat peaks that are hard to pinpoint. 
  The ASDF has somewhat fat valleys but is not much disturbed by the 
noise.  The AMDF without noise has very sharp valleys which are very 
easy to pinpoint, but with noise these get rounded.  But with even high 
amplitude noise the valleys of the AMDF are easier to distinguish than 
the ASDF.

I read somewhere here that another poster preferred the ASDF in the 
presence of noise.  The values of the AMDF are more affected by the 
noise than in the ASDF, but it looks to me like pinpointing the proper 
peak (or is it anti-peak?) value is easier with the AMDF even with the 
noise.  I still have some other testing to do.

Meanwhile I expect my customer to pick the low cost spread and not do 
the tuner option at all.  But who knows?  Customers can be strange beasts.

Rick

On 8/13/2012 6:52 PM, rickman wrote:
> I am being asked to design a gadget that has some special features, but
> also includes a guitar tuner. I have looked at the web a bit, but not
> found any good references that show exactly how a tuner works. One paper
> I found talked about a rather complex "constant Q transform". I just
> don't think the $10 tuner I have uses anything that complex. I'm
> thinking they are doing a PLL sync to the input or something more like
> that.
>
> One reference I found talks about using a peak detect to measure period
> rather than frequency like an FFT. I would think the FFT has too little
> resolution unless it is very long.
>
> Anyone know how the commercial low end gadgets really work? Maybe I'll
> take mine apart, but my bet is they are using chip on board with the die
> under a dab of black goo.
>
> Rick

I've run some simulations on using auto-correlation to detect the pitch 
and it has some very desirable properties.  It seems to be relatively 
immune from noise and out of band signals.  It is not as sensitive to 
the exact frequency as I would like, but likely this is more a 
fundamental limitation of measuring frequency with a short time sequence.

I am going to try the measurement over a longer multiple of the 
frequency of interest.  I should be able to reason out the result, but 
it is easier to just give it a try...

Rick

keskiviikko, 22. elokuuta 2012 7.56.37 UTC+3 rickman kirjoitti:
> On 8/21/2012 10:41 AM, kalvin.news@gmail.com wrote:
> 
> > tiistai, 21. elokuuta 2012 16.27.20 UTC+3 rickman kirjoitti:
> 
> >>
> 
> >> Yes, I thought of that, but to make it as general as possible it would
> 
> >> need to accommodate alternate tunings.  I would like to make this a
> 
> >> chromatic tuner capable of tuning to any note on the scale.
> 
> >>
> 
> >>
> 
> >>
> 
> >> Rick
> 
> >
> 
> > The notes are at discrete frequencies anyway, so getting a coarse frequency from the highest FFT peak and then setting an appropriate (pre-computed, lookup-table) band-pass filter coeffs to the specific note. You would be able to attenuate noise and harmonics, and get a more sine-like signal which may be easier to analyse. Just an idea.
> 
> >
> 
> > - Calvin
> 
> 
> 
> Yes, but knowing which of the peaks is the fundamental is not so easy. 
> 
> The fundamental is not always the highest.  It would be better to find 
> 
> multiple peaks and find the common divisor.
> 
> 
> 
> Rick

Disclaimer: I am not familiar with the guitar (or any other instrument) vibration characteristics.

If you know that you what instrument you are tuning, maybe you can assume something about the fundamental's and the harmonics' relative characteristics and the set the bandpass filter to correct frequency in order to make the frequency analysis a bit easier.

- Calvin

On 8/21/2012 1:41 PM, robert bristow-johnson wrote:
> On 8/21/12 9:31 AM, rickman wrote:
>> On 8/18/2012 11:40 PM, robert bristow-johnson wrote:
>>>
>>> then i'm pretty sure that autocorrelation or AMDF or ASDF is what you'll
>>> want to do.
>>
>> I'll have to lookup the AMDF and ASDF.
>>
>
> Average Magnitude/Squared Difference Function

Yes, I found the name easily enough.  I need to read up on how to 
calculate it and why it is different from the auto-corr.


>>> pretty accurate, but *any* pitch detector *can* possibly have octave
>>> errors (it's what can happen if you have inaudible sub-harmonics). then
>>> you need to program the thing to have a little bit of common sense to
>>> avoid some of the dumber octave errors. i think that looking for energy
>>> at the frequency of the fundamental is a dumb octave error because there
>>> could be more energy at the 2nd harmonic or the 3rd harmonic and your
>>> alg might think that either of those is the fundamental frequency.
>>
>> Yes, but the harmonics will fall at certain ratios which won't match if
>> you pick a harmonic in place of the fundamental. Also, won't the energy
>> of the harmonics add into the lag for the fundamental?
>
> then you'll be sweeping some kinda comb on the data.

Not sure what you mean by this.  I am suggesting that with an 
auto-correllation the harmonics of the frequency that corresponds to the 
lag will also be added into the sum.  Any frequency with an integer 
multiple of its period being approximately equal to the lag should 
accumulate.  So when the lag is tuned to the fundamental of a note, all 
harmonics should add into the result giving this the largest peak, no?


>>> does your DSP or whatever processor have conditional branch
>>> instructions? you don't need to compute the whole autocorrelation (all
>>> of the lags) for each and every sample. in fact, you might just compute
>>> *one* lag per sample and have a couple of special states where you set
>>> up the autocorrelation and where you process or scan the results of the
>>> autocorrelation to come up with a period length. and you can do some
>>> interpolation-like stuff to get the period to a precision of a fraction
>>> of a sample period. i.e. look for the peak where it falls between two
>>> integer lags. it's not hard.
>>
>> I get the interpolation thing, that's fairly obvious, but I don't
>> understand the comment about the one lag per sample and special states.
>
> it's a programming issue. some samples you will compute *one* point of
> the autocorrelation. and when you have filled up the table, you need to
> examine what you computed, that is a special mode of your program and
> you won't have time to compute a new point of autocorrelation and you
> won't need to. it's a manner to distribute the work over many different
> sampling periods to reduce the worst-case timing cost.

Sorry, I'm not following this.  For each input sample, I need to 
accumulate a product for each of the lags being computed.  I don't think 
I will have a timing issue, if by timing you mean enough processor 
speed.  The device I am considering has 144 CPUs with >200 MIPS each.


>> The problem with interpolation is that it can only interpolate to some
>> extent. Essentially this is a method of measuring the period of signals.
>
> yup and that period may very well not be an integer number of samples.

Yes, but interpolation can only improve the resolution by some factor, 
what, 5x?  10x?  Noise and processing resolution will limit this at some 
point.

It seems the frequency resolution of the human ear is not as good as I 
thought.  One source says it is 1 Hz below 500 Hz and about 0.6% above 
1000 Hz.  They don't mention the range 500 to 1000 Hz, but I assume it 
is within this range.  That should be entirely workable without 
interpolation if the sample rate is high enough and I am pretty sure I 
can do that.

Rick

On 8/21/2012 10:41 AM, kalvin.news@gmail.com wrote:
> tiistai, 21. elokuuta 2012 16.27.20 UTC+3 rickman kirjoitti:
>>
>> Yes, I thought of that, but to make it as general as possible it would
>> need to accommodate alternate tunings.  I would like to make this a
>> chromatic tuner capable of tuning to any note on the scale.
>>
>>
>>
>> Rick
>
> The notes are at discrete frequencies anyway, so getting a coarse frequency from the highest FFT peak and then setting an appropriate (pre-computed, lookup-table) band-pass filter coeffs to the specific note. You would be able to attenuate noise and harmonics, and get a more sine-like signal which may be easier to analyse. Just an idea.
>
> - Calvin

Yes, but knowing which of the peaks is the fundamental is not so easy. 
The fundamental is not always the highest.  It would be better to find 
multiple peaks and find the common divisor.

Rick

On 8/21/2012 5:11 PM, glen herrmannsfeldt wrote:
> rickman<gnuarm@gmail.com>  wrote:
>
> (snip, someone wrote)k
>>> Hi Rick - although not a conventional technique you could use a short fft
>>> and then apply an interferometric measurement to improve the resolution ,
>>> this is a technique which is used a lot in somar and rader with phased
>>> arrays.  With phase arrays special,frequencies relate to beam direction.
>>> So to keep,the arrays short engineers useinterferometric  techniques. I
>>> simulated a guitar tuner using this technique a while back and it showed
>>> promise.
>
>> I'm not sure I understand what is implied by "interferometric
>> techniques".
>
> Good question. It first reminded me of the suggestion of using an LED
> flashing at a desired frequency, then I read the description.
>
> The general idea of interferometry is to add a delayed
> copy of a signal, then look for a maxima or minima.
> Sometimes varying the delay until the appropriate extrema is found.
>
>> I know what interferometry is, but how would I use that to
>> determine pitch of an instrument?  Are you suggesting that an array of
>> mics be used with the instrument at a known relative location and the
>> opposite of direction finding or beam forming be used?
>
> I am not so sure. Maybe subtract (or add) an appropriately
> shifted value, then see what it looks like?
>
> -- glen

Sure, that is what others mean by the auto-correlation.

Rick

rickman <gnuarm@gmail.com> wrote:

(snip, someone wrote)k
>> Hi Rick - although not a conventional technique you could use a short fft
>> and then apply an interferometric measurement to improve the resolution ,
>> this is a technique which is used a lot in somar and rader with phased
>> arrays.  With phase arrays special,frequencies relate to beam direction.
>> So to keep,the arrays short engineers useinterferometric  techniques. I
>> simulated a guitar tuner using this technique a while back and it showed
>> promise.

> I'm not sure I understand what is implied by "interferometric 
> techniques".  

Good question. It first reminded me of the suggestion of using an LED
flashing at a desired frequency, then I read the description.

The general idea of interferometry is to add a delayed
copy of a signal, then look for a maxima or minima.
Sometimes varying the delay until the appropriate extrema is found.

> I know what interferometry is, but how would I use that to 
> determine pitch of an instrument?  Are you suggesting that an array of 
> mics be used with the instrument at a known relative location and the 
> opposite of direction finding or beam forming be used?

I am not so sure. Maybe subtract (or add) an appropriately 
shifted value, then see what it looks like?

-- glen

On 8/21/12 9:31 AM, rickman wrote:
> On 8/18/2012 11:40 PM, robert bristow-johnson wrote:
>> On 8/18/12 10:50 PM, rickman wrote:
>>>
>>> My current thinking is that no matter what method I go with, it needs to
>>> be very high "performance", meaning highly accurate and reasonably fast.
>>> I believe the market is not large for this particular device. So better
>>> to go Cadillac and charge a price premium than to try to find a spot in
>>> a crowded, high volume market.
>>
>> then i'm pretty sure that autocorrelation or AMDF or ASDF is what you'll
>> want to do.
>
> I'll have to lookup the AMDF and ASDF.
>

Average Magnitude/Squared Difference Function


>
>>> So that means, will an auto-corr approach do a good job of resolving a
>>> fraction of a cent for a tuner in less than say the two or three seconds
>>> a note will sustain? I would have to consider just how accurate the
>>> auto-corr might be.
>>
>> pretty accurate, but *any* pitch detector *can* possibly have octave
>> errors (it's what can happen if you have inaudible sub-harmonics). then
>> you need to program the thing to have a little bit of common sense to
>> avoid some of the dumber octave errors. i think that looking for energy
>> at the frequency of the fundamental is a dumb octave error because there
>> could be more energy at the 2nd harmonic or the 3rd harmonic and your
>> alg might think that either of those is the fundamental frequency.
>
> Yes, but the harmonics will fall at certain ratios which won't match if
> you pick a harmonic in place of the fundamental. Also, won't the energy
> of the harmonics add into the lag for the fundamental?

then you'll be sweeping some kinda comb on the data.

>> does your DSP or whatever processor have conditional branch
>> instructions? you don't need to compute the whole autocorrelation (all
>> of the lags) for each and every sample. in fact, you might just compute
>> *one* lag per sample and have a couple of special states where you set
>> up the autocorrelation and where you process or scan the results of the
>> autocorrelation to come up with a period length. and you can do some
>> interpolation-like stuff to get the period to a precision of a fraction
>> of a sample period. i.e. look for the peak where it falls between two
>> integer lags. it's not hard.
>
> I get the interpolation thing, that's fairly obvious, but I don't
> understand the comment about the one lag per sample and special states.

it's a programming issue.  some samples you will compute *one* point of 
the autocorrelation.  and when you have filled up the table, you need to 
examine what you computed, that is a special mode of your program and 
you won't have time to compute a new point of autocorrelation and you 
won't need to.  it's a manner to distribute the work over many different 
sampling periods to reduce the worst-case timing cost.

> The problem with interpolation is that it can only interpolate to some
> extent. Essentially this is a method of measuring the period of signals.

yup and that period may very well not be an integer number of samples.

> The sample rate has to be fast enough to provide a decent resolution.
> There are also the same issues found in the FFT of energy splattering
> across bins. I suppose a window function can help with that.
>


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."