jamiebullock
commented
10 years ago That peak detection algorithm looks good, nice and simple. However, it would certainly also be possible to use the GRT peak detector in this way: it would just mean internally iterating over each element in the input vector, rather than using a continuously updated value, which is what peakdetect does. If you wanted we could introduce a "mode" attribute, which switches between these two types of operation. Perhaps we could try using GRT first, and if you're not happy with the results, look at contributing a new algorithm to GRT based on the peak detect code?
One question is, in "vector mode", how do you want the output data to be formatted? Some options are:
(for input .1 .7 .2 .5 .1 .1 .1 .8 0)
- zero-indexed location value pairs: 1 .7 3 .5 7 .8
- zero-padded values: 0 .7 0 .5 0 0 0 .8 0
- values only: .7 .5 .8
- locations only: 1 3 7
For spectral data (as in your example), I normally use interpolated peak position. This is what is done in the LibXtract xtract_peak_spectrum() function. That is we don't just get the beak bin magnitudes, but the interpolated frequency and magnitude pair. This is nice if you're building a visualiser. I'm not sure how useful it is for characterising the audio though. Most timbre classification tasks just take something like the magnitudes of the first 10 bins or something like the MFCC.
batchku
this is a useful class. however, what i really need is a peak detector that works on vectors of data as opposed to streams. here's an example: you do an fft and have the bin magnitudes for an audio signal; now you want to find the peaks in this series so that you can feed them to SVM for training and classification. we spoke about this before; our research showed that the best algorithms where actually from chemistry (lots of noisy data there).
this was among the best we found: https://github.com/xuphys/peakdetect?source=c
what do you think?