Improper AMDF updated

just in case anyone interested, i've just updated my pitch detector macro :
https://co.native-instruments.com/index.php?id=userlibrary&type=0&ulbr=1&plview=detail&patchid=9989

have fun

 

Can you go beyond melodyne editor? then separating drum loop from string ensemble and then remove synthesizers from choirs.


Just use EZFFT to a dynamic lookup harmonic table, and then sending it to sinebank module. And here we have something better than melodyne editor.


The dynamic lookup harmonic table, tracks multiple instruments at the same time by dividing the amplitude on all harmonics by using some advanced math logic as i don't know about how it works exactly.

 

Thanks! I've had decent success with this for what I need it for.

 

you're welcome

i think currently thats nearly impossible, i don't know, sounds too good to be true...

not to mention i have trouble understanding FFT.....

right now i'd rather try exploring possibilities on polyphonic detection, maybe i'll end up with something usable in realtime.

 

FFT uses latency for detecting multiple notes from different instruments at the same time by using a additional dynamic lookup harmonic table.

The dynamic lookup harmonic table module is like a dynamic convolution module that can load many wave samples like a kontakt instrument, load sf2 or dls files.
Then every wave sound is polyphonic harmonic analysed and splitted into many harmonics, like a hacked spectrum analyser. Then sended to Sine Bank module for futher tweaking.

 

BertAnt -- can you explain your algorithm for Improper AMDF?

 

hmmm, so polyphonic detection with one instrument only should be possible using EZFFT, right ?

i assume that we'll compare the harmonic content between the audio and the table then ? :S

sure

it's a result from my mistake applying the AMDF method - because i'm really confused with the formula, i thought it just simply subtracting the audio input with delayed version, i didn't understand that it has to be summed for several samples before looking for the minimum to find the pitch.. meanwhile, i discovered another interesting stuff - you can 'mute' a note by running the audio into a 'difference delay' - a delay that has delay time equals the period (one cycle length) of the note and inverted phase - it forms a perfect phase cancellation for the note only due to the delay time.

from there, with 'AMDF' in mind, i simply use multi tap delay with each tap delay time configured to match the period of each possible note, invert the delays output, then summing it with the dry signal...and after some smoothing, the pitch can be determined by simply looking for the output with shortest delay time that also has minimum amplitude among others.

 

Are you that smart? , And this is not only polyphonic pitch tracking but muting diffrent instruments
from a complete orchestral mix mp3 file.

Yes.

 

have you ever try building a pitch tracking ensemble ?

 

Yes, and it was only with many bandpass filters. It is called MeloChemy in Reaktor UL.

 

it's better described with this simple demo ensemble i guess

 

Note killer is just a inverted bandpass filter.

 

OK I get the general concept and Note Killer is killing as expected.

I'm curious about the formula for the delay time though. I'd think you'd want a half-cycle offset, but for example:

MIDI Note 69 (440Hz) raised to power of 1.05946 = 88.7538
122.228 / 88.7538 = 1.3772ms (726Hz)

That seems to be a few semitones off -- a half-cycle of 440Hz should be 1.1364ms (880Hz).

Also in your pitch detection implementation, how do you deal with distinguishing octaves?

 

Spectrum splitting.

 

about the formula, i was just simply modifying the P2F core macro...
1/F is the period, and in the P2F macro, the exp(1.05946) is multiplied by 8.17742, so 1/ F = 1 / ( exp(1.05946) * 8.17742 ) = 0.122288 / exp(1.05946) ... and then it's multiplied again by 1000 to get ms (please excuse any mistake if there's any :S )

and that was one cycle, i didn't go for half cycle because i find some waveform is not identical at both phases, unlike sine wave for example, and that caused detection error.

for the octave, i simply divided the detection for each octave, from there each of the result is routed to a schmitt trigger macro, so any invalid result will produce zero (for example, if the note is in the first octave, the result will be invalid for the rest of the upper octave), while 'carrying' its 'ID' (note number value) and finally all four 'ID' (because i made it for detecting pitch within 4 octaves only) is routed to a max-select router to find the largest note number - if the output is zero, then there's no pitch at all (although sometimes this doesn't work as expected).

 

OK thanks I had the math on the Core exponent module backwards :| You're right to use a full cycle (and I should have noticed the subtraction in Note Killer required one).

I'm just starting to try out ImproperAMDF. I'd read somewhere in the User Library that it was "rough" pitch detection, but it seems quite responsive. I'd say future work to be done would be in better smoothing/quantizing to stable MIDI notes. But with automatic/settable vibrato detection! :S

It's currently not too processor intensive -- would FFT really be able to do any better detection than this anyway? How does it compare to pitch detection in Max? If you look at the detected pitches flickering around in Autotune, I think the "roughness" may be singers' wobbly voices...

 

actually, in the update i've also included a zero-crossing tracker (check out the output from the 4p filter that goes to the HalfCycZ-Xer macro), which will track further to in between MIDI note numbers.... but, because the previous version of Improper AMDF doesn't have this, in the demo ensemble i still use the integer note number as pitch input for the synth (and also because i like the character, very synth-like, while using the tracked floating-point pitch sounded more like a synth FX - too 'analog'-like ). and also i leave further smoothing to the user, i think it's sufficient that i provide just the raw pitch data

the major disadvantage from my method is it's impossible to track polyphonically, just like the 'proper' AMDF - which is mainly used for speech recognition ... with FFT, it should be possible, although i haven't seen one (FFT pitch detector) in reaktor yet :S i haven't tried Max yet so i don't know which one is better, but i heard it's really good and people using Max are getting good results from it.

and yes, i agree, i think the flickering on autotune FX is not a detection failure at all - it's because the detection was too good, and it tracks even the singer failure to sing properly (or too deep vibrato perhaps)

 

the problem i've encountered in FFT pitch detection is that you are limited to detecting frequencies by bin number. using a 2048 bin FFT, each bin has a width of around 21-22 hz, so (for example) you can't tell the difference between a fundamental signal of 130 hz and one of 140 hz, they are the same . it's likely, that there is a way around this, but i'm not sure what it is.

 

thanks for sharing !

but how about for detecting just the nearest MIDI note number, maybe the 21-22 hz width will be sufficient probably ? i figure it's probably as simple as converting bins -> freq -> pitch value for starter, before further processing for determining the note number ?

edit : just checking with P2F module, seems like it wasn't enough...i'm getting used to working with note numbers so i didn't notice it at first..

 

at higher notes, there's better accuracy, but in the lower notes, the bins are too close together, even with 2048 bins (an extremely frustrating aspect of the available FFT algos is that they measure frequencies up to 44100 hz, so a whole half of the bins are full of useless information, which are just a mirror of the first half in reverse anyway. )

so there's only 1024 bins actually containing information

anyway, here's a simple example ensemble, it can take any input but for demonstration purposes i've hooked it up to a simple primary oscillator. hit a midi note, see the FFT info and the detected frequency / pitch. you'll notice, for example, that MIDI notes 48 and 49 return the same info.