Closed faroit closed 9 years ago
PitchYinFFT is implemented based on the PhD thesis by Paul Brossier, in which he did provide evaluation details (see the thesis, page 91), but we did not carry out any further in-house evaluations. Looking at those graphs, we can expect YinFFT to work worse than Yin on lower notes.
It will be so great to compare the plot you made for YinFFT to the one for the original Yin. I wonder if you are interested in running this evaluation. This will be very useful, as we are trying to understand if it's really worth implementing original Yin.
Sure, I can make this comparison. Might happen next week.
I made a comparison using http://aubio.org/ and a script based on the one used by @faroit.
It looks like the Yin is much better than its frequency-based version for lower frequencies, although the aubio implementation gives very bad result for the very first frames. I think faroit is using this implementation. We'll see if it gives similar results
I compared with a CFFI interface to https://code.google.com/p/pysnail/ which is based on a modified version of fixed point implementation that is used here, as @oriolromani guessed. It's not even worth showing the results. They are a lot more unstable than essentia and the version interfaced in aubio and have jumps all over the place.
Next up could be: pYin which includes a Yin implementation. I will try to interface it soon using CFFI. Other than that there is a bunch of MATLAB implementations but I'm sick of those matlabwrappers ;-)
I've tried the pYin Vamp plugin in Sonic Visualizer and it gives pretty good results for low frequencies but I still don't have comparable results.
It looks like the Yin is much better than its frequency-based version for lower frequencies, although the aubio implementation gives very bad result for the very first frames.
So, the implementation of Yin in aubio looks like the most promising. Are bad results in the first frames due to the specifics of how Yin algorithm works?
The script in gist is not entirely correct, you should use FrameGenerator with startFromZero=True, othewise the first frame is centered aroudn zero-th sample
I have added a new PitchYin algorithm (a1cd07573feba8c7cc275a7f4b82ed898688cd25). It works already although results are not that good in higher frequencies compared to the plot by @oriolromani
@dbogdanov thats right, thanks. (I updated the gist). I'm still working on interfacing the pYin so we can have an ultimate yin shootout.
Finished implementing PitchYin. Here are the evaluation results agains PitchYinFFT (using this test script: https://gist.github.com/dbogdanov/a7b78caa7c2df5cf45f3). Looks pretty good.
Hi @dbogdanov, when I try to implement PitchYin i get the following error
AttributeError: 'module' object has no attribute 'PitchYin'
I am trying to implement the Inharmonicity module and I need to detect the pitch beforehand. Do you have any idea why python can't find this module? It works fine with PitchYinFFT.
It is in the master branch. You'll need to do ./waf install
in order to make this algorithm available in python.
Unit tests for PitchYin are not finished yet, we still need to make sure it all works ok.
Finished unit tests and did some fixes in the implementation.
Hello
lately we used the YIN implementation in essentia a lot. However for many applications (speech, instruments) I found an constant error compared to other pitch estimators like RAPT.
I tried to produce some more systematic results by running a simple test script (https://gist.github.com/faroit/2ebcf956633f63d92ace) which generates a stationary sine wave of constant f0. The signal then is processed by the YIN algorithm and the mean of the estimate is compared to the (constant) ground truth.
This is what I get:
Obviously the estimation error is frequency depended, which is expected. Over 1 Khz, however, the estimate looks to be unstable.
Did anyone have tested the estimate in comparison to the original C Yin implementation?