Olahdeoja

I'm having trouble with implementing cross correlation using pfft. Helped by math-minded collegues, I'm using a pfft subpatch which performs "amplitude x amplitude, phase - phase" operation.

The outcome does not correspond to the cross correlation of two sample soundfiles calculated in mathlab.

Would anyone have an idea what is wrong with the calculus I'm using (or in the way max/msp handles fft)?

I'm having trouble with implementing cross correlation using pfft. Helped by math-minded collegues, I'm using a pfft subpatch which performs "amplitude x amplitude, phase - phase" operation.
The outcome does not correspond to the cross correlation of two sample soundfiles calculated in mathlab.
Would anyone have an idea what is wrong with the calculus I'm using (or in the way max/msp handles fft)?

cross-correlation-using-pfft

Olahdeoja wrote on Fri, 27 February 2009 14:01

us I'm using (or in the way max/msp handles fft)?

For a start pfft~ is windowing using a von Hann window, which will mess up the cross correlation.

Secondly, I don't think you want to overlap at all, because when the windows get added back together that is also going to cause problems with the results.

On a efficiency note, I really wouldn't bother converting to polar values here - you can get the result by doing a complex multiply between the two inputs, taking the conjugate of one input I believe. It'll be a lot more efficient.

My advice would actually be not to use pfft~ for this. Look at using fft~ (unless you need an fft size of over 4096), or alternatively use jit.fft. It's a bit of a faff to get the audio into jitter, but it's easier to make sure you're dealing with entire frames that have come from one analysis frame only. I recently mocked up an autocorrelation routine in jitter and it worked pretty well.

Actually, looking back at your patch, if you're not going to use realtime signals (ie. you are actually going to use buffers in the final usage) then I'd strongly recommend jit.buffer~ and jit.fft along with jit.op - the code will be cleaner and easier to understand. I seem to remember the scaling of jit.fft being different to what I was expecting, but I may be mis-remembering that.

JF Charles has some tutorials on audio spectral processing with jitter that changed the way I thought about certain spectral applications within max - you might want to look at them - before that I'd never thought of using jitter for this purpose, but it makes a lot of sense, especially for non-realtime stuff.

Olahdeoja wrote on Fri, 27 February 2009 14:01Hello forum,

Thank you Alex, this is very informative,

I figured the overlap causing problem but did not think of the windowing function. 

The final use woud be realtime comparaison of an incoming signal with a database of soundfiles (different types of impacts), so I guess I should stay in max. Although the jitter spectral processing topic seems highly interesting.

I figured the overlap causing problem but did not think of the windowing function. 
Gotta look into fft~!
The final use woud be realtime comparaison of an incoming signal with a database of soundfiles (different types of impacts), so I guess I should stay in max. Although the jitter spectral processing topic seems highly interesting.

Olahdeoja wrote on Fri, 27 February 2009 15:02

The final use woud be realtime comparaison of an incoming signal with a database of soundfiles (different types of impacts), so I guess I should stay in max. 

Realtime stuff is possible with jitter, it's just a case of passing the audio into jitter, but once that is done it makes it simpler to deal with the data in frames..

Olahdeoja wrote on Fri, 27 February 2009 15:02
The final use woud be realtime comparaison of an incoming signal with a database of soundfiles (different types of impacts), so I guess I should stay in max. 
cheers!

Would it be possible to get a running patch from you. I'm new to MAX and I really need to do some IACC measurements (preferentially in real time).

Cross correlation using pfft?