xtract_f0 input vector and results

[jamiebullock]

xtract_f0 input vector and results

[jamiebullock]

Nope, in fact, xtract_f0(), xtract_failsafe_f0() and xtract_wavelet_f0() all take a block of audio samples, not the magnitude coefficients as input. I've found xtract_wavelet_f0() to be the most reliable method.

[q-depot]

f0 works properly with the pcm data thanks to clarify this, I'll have a go witht the wavelet method too.
I reckon generally it would be good if the doc could specify the input type for each function, some of the functions already do it, some other are a bit more confusing.

thanks.

[q-depot]

none of the f0 functions work with frequencies below 100Hz, wavelet_f0 flicker between 0 and the frequency value(in this case 65Hz), is it a bug? they all work find with frequencies above 100Hz.

[jamiebullock]

Have you tried increasing the block size? The accuracy of F0 detectors is generally a function of block size, where larger block size means more accurate detection, and better ability to detect lower frequencies. To go below 100Hz, you probably need a blocksize of 2048. This isn't unique to LibXtract, you will find this issue with other pitch detectors also.

If you're worried about introducing latency, you could overlap blocks for the f0() functions.

[q-depot]

this is quite interesting, at the moment I'm using a blocksize of 1024 which also lead me to a question, does the Xtract blocksize has to match the input PCM sample count or can I just take half of it?

The blocksize from the Cinder audio pcm buffer is usually 2048, but the blocksize I'm using in libxtract is 1024, which means I only take the first 1024 values from the pcm buffer, is this a problem?
Also does the fft size need to be half of the blocksize or can it be anything power of 2?(128, 256 ..)

Going back to the issue above, using 2048 as blocksize is not ideal, in theory I want to use the smallest useful blocksize to boost the performance, can you please explain what you mean with overlapping blocks?

thanks.

[q-depot]

.. and one more question, how bad/inaccurate do you reckon is to cut off all the frequencies below 100Hz from the F0 functions?
Do you think this is an acceptable trade off or should I do something about?

[jamiebullock]

OK...

• You can use any block size N with most of the xtract functions. xtract_spectrum() needs a power-of-two though
• If you have an audio buffer of, say, 2048 samples, and you pass that buffer as *data to e.g. xtract_spectrum() with an N of 1024, you will get the spectrum of half of your audio block. Unless you have an overlapping scheme in place (see below) this is probably not what you want
• The FFT size can technically be any power-of-two, however typically you will want to do something like:

double spectrum[BLOCKSIZE] = {0};
xtract_init_fft(BLOCKSIZE, XTRACT_SPECTRUM);
xtract[XTRACT_SPECTRUM](windowed, BLOCKSIZE, &argd[0], spectrum);

• Here spectrum will contain N/2 magnitude coefficients and N/2 frequencies
• If you want to improve F0 resolution without compromising latency, you can use a blocksize of e.g. 1024 for all features except F0, for which you use 2048. For your very first block you don't compute F0 (or compute it with N=1024). For all consecutive blocks, you compute F0 using 2048 samples taken from the previous block + the current block. You therefore need to always retain the previous audio block for this purpose

Regarding the Cinder blocksize of 2048 — is there a way to adjust this? You aren't reducing latency by using 1024 for libxtract if you're getting blocks of 2048 samples from your audio callback, you're just missing data. Basically you need to find a way to reduce the Cinder blocksize.