I created a series of Music Notes with Guitar Pro 6 [[ Consisting of half notes at 74 bpm from E2 through E7 as played by a Nylon Guitar ]].
Audacity 2.0.6 successfully detects each of these Notes and Frequencies as expected EXCEPT for G3 (196 Hz).
This particular note is detected as F10 with a frequency of 22,050 Hz.
My only conclusion is that Audacity has a glitch when detecting this particular frequency. The strange situation is that the notes below and above G3 work as expected.
Those notes are: F#/Gb3 (185 Hz) and G#/Ab3 (207.65 Hz).
I don’t know, but pitch detection is tricky business because of the harmonics & overtones… I wouldn’t expect perfection unless you’ve got pure sine waves. If you generate a 196Hz sine wave , which you can do with Audacity, I’ll bet it works.
I suppose some “fuzzy logic” would help, since 22,050 is obviously not a valid “note” (except maybe on a synthesizer). I assume guitar tuners are optimized for guitar harmonics & overtones.
Do you detect the notes with the change pitch effect?
The algorithm used is somewhat crude, especially for higher frequencies. It is based on auto correlation. It looks where this function has its peak, which corresponds to a certain lag (sample delay).
The highest peak is at zero (which has to be ignored). Lag one sample= 22050 Hz, 2 samples= 14700, 3 samples= 11025 Hz.
Detectable frequencies are therefore at sample rate / (1 + delay in samples).
At 176 Hz, the grid is fairly refined though:
22050 Hz means that no peak is over the threshold and hence the first sample is taken as peak.
You could resample the notes and see if this helps. It’s also advisable to exclude the pluck of the note because it has equal strength at all frequencies and blurs the correlation towards 22.05 kHz. The longer a note lasts, the lesser high frequency content it has.
So is the fact that 2.0.6 (and 2.1.2 which is the current version) detects a 196 Hz sine tone at 44100 Hz as 197.758 Hz and not 44100/225=196 Hz because we make compromises for low frequencies to make high frequency detection less bad, or some other reason?
2.0.6 / 2.1.2 still see that 196 Hz at 44100 Hz as G3, which is the correct “note”, whereas 2.0.0 detected 196 Hz at 44100 Hz as 204.167 Hz (G#3/Ab3).
There might be a calculation bug since 44100/197.758 =223.0
I’ve once implemented the algorithm in LISP in order to compare different algorithms.
The best results are achievable with YIN for sounds with strong harmonics.
For high frequencies, the zero crossing rate works best because a < 22050 Hz tone has <n/2 crossings over n samples.
The Helsinki algorithm works best at very low frequencies, as explained above. However, the latter algorithms are usually best suited for signals without harmonics (or at least with low energy in the harmonics).
I found that the current algorithm in Change pitch can be tremendously be improved by quadratic interpolation around the peak. Thus the dividend would be 44100 and the divisor would be e.g. 224.34 instead of a whole sample number.
I have to review the current code in “Change Pitch”.
How was the detection done?
This was accomplished with the “Pitch Change Feature” under “Effects” and reading the change from display boxes.
I tried generating a 196 hz sine wave with Audacity and then detecting it. This yields G3 and not F10. So a pure sine wave is detected properly.
The TEST WAVEFORM originally described was made with “Guitar Pro 6” which generates musical notes (including harmonics) by placing notes on a staff. It was puzzling that everything worked as expected except the G3 note.
Did you use the real samples engine (I think it’s called something like RSE) in Guitar pro, or just the MIDI instruments?
Tip: “Change Pitch” bases its pitch deduction (it’s called like that in the source code) on the first 0.2 seconds of the selection.
I think that this value, along with the window size should slightly be increased.
I’m still puzzled why the autocorrelation function yields 44100/223 instead of 44100/225 for a pure sine tone at 196 Hz–whereas other whole divisions are recognized correctly.
A quick check with Octave (Matlab clone) yielded the correct result.
However, Audacity uses a non-standard calculation of the auto correlation:
two FFTs instead of FFT/IFFT
Cyclic instead of linear
third root on the power spectrum instead of real coeffs * conjunction(imaginary coeffs).
We’ll see what is responsible for the slight round-off error.