I've refined procedures in pitch tracker [snac~] (based on Philip McLeod's Specially Normalized Autocorrelation function (SNAC)), and renamed the object in the honour of the great 19th century explorer in the world of sound and frequencies, Hermann Helmholtz. The guy who listened through resonators to isolate frequencies in a sound.

[helmholtz~] is by default deaf for noise, but hears periodic sound no matter how faint. As a result, analysis frames containing transients, note jumps, or other signal segments with low autocorrelation are ignored. It's better to have no pitch report than an erroneous pitch report. Pitch estimation is precise up to +/- 0.1 Hz.

While regular methods need at least two periods in the analysis frame for detection, [helmholtz~] can do with a minimum of 1.2 periods. As a result, a female voice can be pitch-tracked with a frame of 512 samples at SR 44100, that is ~11 milliseconds. For a male voice and most instruments, 1024 samples are sufficient, that is ~23 milliseconds.

Remember that a time domain method can not distinguish multiple pitches in a stream, so [helmholtz~] must be used with monophonic channels only.

The object uses 0.6% CPU time per instance on my 2GHz CPU, with default settings, no analysis overlap. Since it only needs fundamental frequencies, it can be used in downsampled time as well, for example with resampling factor 0.25. Then you can do four overlapping analyses for the price of one, making things smoother as you get analysis results at a faster rate. Don't forget to resize the analysis framesize accordingly, otherwise you get long latency times.

I've extensively tested [helmholtz~] with my voice and all sorts of sweeping and jumping test tones. It does not seem to make mistakes with these sources. That may be different for other instruments, I'm eager to hear comments.

Attached file helmholtz~.zip contains source code, makefile, 32 bit binaries for OSX, Windows and Linux, help file and test patches.

Thanks to elden, who posted so many useful links on pitch shifting and tracking on this forum. [helmholtz~] would not have existed without all the info's. Find Philip McLeod's thesis introducing the SNAC function here:

http://miracle.otago.ac.nz/postgrads/tartini/papers/Philip_McLeod_PhD.pdf

Katja

P.s. [snac~], the experimental predecessor of [helmholtz~], is now discontinued.

Edit: find the latest [helmholtz~] now on:

http://www.katjaas.nl/helmholtz/helmholtz.html

http://www.pdpatchrepo.info/hurleur/helmholtz~.zip

Thank you very much Katjav.
By the way, the link to McLeod's thesis seems to be cut. It is here:

http://miracle.otago.ac.nz/postgrads/tartini/papers/Philip_McLeod_PhD.pdf

The papers are here:
http://miracle.otago.ac.nz/postgrads/tartini/papers.html

Best regards to everyone.

Sumidero

@sumidero said:

the link to McLeod's thesis seems to be cut

I made a mistake with copy and paste, should work now. Thanks for supplying proper links, Sumidero.

Katja

Wow, it's quite *precise* (actually also accurate and *responsive*.

By looking at the help I would have said that "fidelity" parameter is associated
to "how good the pitch estimate is" (kind of variance of pitch estimate).
You say fidelity is "how periodic a sound is" (technically I see it is associated
to the three-points interpolation process). On the info you say that accuracy,
indeed, is ~0.1 Hz. Is it so despite the input wave complexity?
SNAC seems to be quite powerful, maybe it's time to get into the references.

Thanks Katia for sharing this external.

Alberto

Probably a silly question, but why - in the vibrato / frequency jumps example - don't any values come anymore when then input is below 102 hz?

@domien said:

Probably a silly question, but why - in the vibrato / frequency jumps example - don't any values come anymore when then input is below 102 hz?

Not at all silly, glad you mentioned it. I should have set limits to those numboxes. It's because 102 Hz falls below the scope of the analysis frame size set in that patch. I'll try to spend more attention to that aspect in the help file. Pitch trackers are not completely straightforward in their use.

@AlbertoZ said:

By looking at the help I would have said that "fidelity" parameter is associated to "how good the pitch estimate is" (kind of variance of pitch estimate). You say fidelity is "how periodic a sound is" (technically I see it is associated to the three-points interpolation process).

What I call fidelity has different names in other pitch tracker implementations. For example, Philip McLeod uses 'clarity', and Thomas Baran (in autotalent.cpp) uses 'confidence'. This hassle is all because the word 'periodicality' doesn't exist and is also too ugly to use. But all these words actually mean to indicate the extent to which a signal is periodical, as opposed to non-periodical, (noise, or more precise, components with inharmonic relation). Fidelity is nothing more than the normalized autocorrelation coefficient at the peak which is taken to indicate period length.

If there's much noise in a signal, fidelity values drop and may go below the threshold for reporting. You can lower the fidelity threshold to check what happens in the output plot and pitch messages.

@AlbertoZ said:

On the info you say that accuracy, indeed, is ~0.1 Hz. Is it so despite the input wave complexity?

Accuracy is not totally unrelated to the input wave complexity: it should be harmonic and not have strong high frequencies making the peaks too narrow to track them properly. It helps to filter an acoustic input signal, which is indeed done in the help patch.

Thanks for all your feedback. [helmholtz~] may be the first time-domain pitch tracker in Pure Data, and it's operation is quite different from [fiddle~] and [sigmund~]. I'll do some documentation on it shortly.

Katja

Sooooo nice !

How can i build this for linux x64 ? I changed the target to pd_linux and got this

 $ make
g++ -msse -DPD -DUNIX -DICECAST -O3 -funroll-loops -fomit-frame-pointer -fcheck-new -Wall -W -Wshadow -Wno-unused -Wno-parentheses -Wno-switch -fvisibility=hidden -I ./include -c *.cpp 
g++ --export-dynamic -shared -o helmholtz~.pd_linux *.o -lc -lm -lstdc++ 
g++: erreur: unrecognized option ‘--export-dynamic’
make: *** [helmholtz~.pd_linux] Erreur 1

Dwan, I have no 64 bit Linux computer myself so I 'm not sure. As it seems, the syntax for dynamic export option changes with every gcc version. Some people report that for gcc 4.6 it should be:

-Wl, -export-dynamic

It is a flag for the linker. Maybe this works for g++ as well. Furthermore, there should probably flag -fPIC or -fpic for 64 bit systems.

Will you try these things and post your findings? If you succeed I'll check if things can work the same for Linux 32 bit as for 64 bit, and change the makefile accordingly.

Thanks,

Katja

Katja, you're awesome! I just tried this with my guitar input, and so far it is truly a godsend. It ignores fret noise, and there are considerably less sudden jumps due to pick noise when compared to [fiddle~] or [sigmund~]. And when they do happen, they're much shorter lived and less noticeable. I also really like how it holds the last pitch when the input is cut instead of dropping to zero. Makes it easier to deal with the release part of an envelope when using it to control a synth.

Thanks!

It works ok with the changes you suggested, thanks ! I tried all the test patches with success.

pd_linux: $(NAME).pd_linux

.SUFFIXES: .pd_linux

LINUXCFLAGS = -msse -fPIC -DPD -DUNIX -DICECAST -O3 -funroll-loops -fomit-frame-pointer -fcheck-new \
    -Wall -W -Wshadow \
    -Wno-unused -Wno-parentheses -Wno-switch -fvisibility=hidden

LINUXINCLUDE =  -I ./include

$(NAME).pd_linux: 
    g++ $(LINUXCFLAGS) $(LINUXINCLUDE) -c *.cpp 
    g++ -Wl -export-dynamic -shared -o $*.pd_linux *.o -lc -lm -lstdc++ 
#strip --strip-unneeded $(NAME).pd_linux
    rm -f *.o ../$(NAME).pd_linux
    cp $(NAME).pd_linux ../$(NAME).pd_linux

Edit : x64 version attached, built on ubuntu oneiric.

http://www.pdpatchrepo.info/hurleur/helmholtz~.pd_linux

Wow Katja, this thing is absolutely very nice. I wondered what a tracked voice would sound like and uploaded it here:

Thanks for all the hard work (i guess )...

D.

Hi katjav,

I've included a patch to demonstrate why the 'snac function' doesn't seem to be suitable for polyphonic tracking.

It's extremely accurate and quick at following a single varying musical pitch, but becomes chaotic when trying to analyse a general musical piece.

At least, in my experience that is

the freq domain analysis, although requiring a greater fft point size, show distinct peaks, making it possible to differentiate one note from another.
ie. it's not so critical so less chaotic

I might be totally wrong here, but I can't get helmholtz to perform on Mp3's .. how about you?

http://www.pdpatchrepo.info/hurleur/helmholtz-test.pd

Moog1, you are completely right. To quote from my first post in this topic:

Remember that a time domain method can not distinguish multiple pitches in a stream, so [helmholtz~] must be used with monophonic channels only.

I see no way for polyphonic pitch tracking for arbitrary music in real time. There's a discussion going on about it:

http://puredata.hurleur.com/sujet-6795-detecting-chord-adc

As far as I understand, polyphonic pitch tracking can only be done by note separation. If the notes are in separate spectrum ranges, then it is not difficult. Isn't that the reason why [basspitch~] works well for bass? But to make a general purpose polyphonic pitch tracker, for instruments with overlapping ranges, would require a different approach. It is what Melodyne DNA does. Not in real time, because each analyzed note must be completed before it can be separated from the others. Melodyne DNA's technique is described in detail in the patent application:

http://www.google.com/patents/US8022286?printsec=description#v=onepage&q&f=false

It's interesting stuff. Probably you will understand all which is described, because it is not so much different from the things we do in Pd, it's only much more detailed.

Katja

P.s.
moog1, I like your zooming spectrum tools, they really help to clarify what's happening in a sound.

For those who are interested in time domain pitch tracking in general, and SNAC and [helmholtz~] in particular, I've done a reader-friendly page with lots of illustrations and a little bit of math:

http://www.katjaas.nl/helmholtz/helmholtz.html

From there, you can also download the freshest [helmholtz~]. I found that the noise gate in some patches, which blocked unwanted pitch reports from computer hum etc. had a nasty side effect, producing false triggers on it's own sometimes. I replaced that noise gate by a new trick in [helmholtz~], the 'perfect white noise equivalent floor'. Read all about it on mentioned page.

I'm not completely done yet with [helmholtz~]! The closer I look, the more options I see for improvement. But it's about small details. If anyone has found a bug or flaw, I'd like to hear about it. Also, I'd like to know for which instruments [helmholtz~] does actually work. Note that I won't be able to make [helmholtz~] analyze polyphonic music. But for monophonic periodic sound, I want to make it as perfect as possible.

Katja

@katjav said:

For those who are interested in time domain pitch tracking in general, and SNAC and [helmholtz~] in particular, I've done a reader-friendly page with lots of illustrations and a little bit of math:

http://www.katjaas.nl/helmholtz/helmholtz.html
Katja

Thanks for that .. a fascinating website .. good for absorbing reading and reference.
I can see that [helmholtz~] is more than ideal for playing an instrument triggering synth. Brilliant!

so will [helmholtz~] track the most prominent frequency in a given audio sample? for instance, with a human voice, the lowest tone?

sounds like this will be nice for pitch tracking slides on a fretless instrument.

Great work, Katja.

edit: I cannot believe how much better than [sigmund~] this is! Wow. I was going to use [sigmund~] in a research presentation next Tuesday. I am now using [helmholtz~]

It is also going in my performance system.

I have been sending some different oscillator banks to [helmholtz~] at specific frequencies (chromatic rise and fall from E0). I would like to convert the tracked frequency to MIDI note number with [ftom] but the resultant MIDI numbers are not stable, even after tweaking the parameters accordingly.

Anyone else having this problem?

edit: using [round] fixes this problem, but I thought I'd mention the result anyway.

Hey Ricky, thanks for your feedback. I almost forgot about [helmholtz~] since I do not use it (yet) in my own setups. In case you put it in a shared patch, note that [helmholtz~] is not part of Pd-extended and you have to supply [helmholtz~] binaries with the patch.

If [helmholtz~] is better than [sigmund~] for certain purposes, it probably should become part of Pd-extended (version 0.44 at earliest), but that is not a trivial thing.

Katja