Peak (multiple) frequency detection/measurement

[tester]

This is an old topic I'm interested in, and while it was probably rather difficult to get in SM, maybe in FS it could be better; yes dearest dear Troggie - I accept ruby

I'd like to get peak frequencies of sounds like this one (with removed the let say 300ms hit part). Does not have to be real-time. But let me specify what I mean, to avoid unnecessary variations. These sounds will always have constant frequencies over time. These sounds are always fading down (no dynamic changes).

I'd like to get the measurements (automatic peak freq/gain detection to be precise):

- at c.a.0.1Hz accuracy.
- in user-specified bands (from - to [Hz]; usually there will be 2-4 peaks per frequency band)
- above user-specified threshlod (in general these peaks will always be at least 6-12 dB over surrounding spectral background, and I guess in context of some averaging/smoothing in time)

p.s.: I have no experience in FFT things. I just would like to do some automated measurements on thousands of files I have to analyze...

Anyone could help?

[tester]

Martin started showed on SM:
http://synthmaker.co.uk/forum/viewtopic ... 998#p91241
and please also follow my questions there.

I'd like to continue here a little bit, with maybe ruby alternatives, and with the hope that someone can help.

I don't know - is this ruby-related to my question on multiple peak detection in FFT spectra?
http://rhic.physics.wayne.edu/~pavlinov ... aks.C.html
http://meccablog.ing.unitn.it/articles/ ... -algorithm
And what to do with that if it is?

[trogluddite]

The links certainly seem in the right area, but personally I'd go with Martin and Kohugaly's methods in the first instance.
Ruby might help later on with the file processing for batch conversion, but the audio analysis would only be improved significantly if the FFT size could be increased.

I have seen several "psuedo-code" versions of FFT on the internet, and Ruby includes everything that is needed, so such a thing could be made. However, IMHO...

- Still a pretty tough bit of coding.
- It would be much slower than the FFT primitive, especially for large data sets. For "off-line" file processing, time is maybe not a problem, however...
- It is quite likely that it would trigger the "excessive processing" protection on the Ruby component - as mccy has already found with his sound-font parser. The dev's do seem to be aware that it can cause problems, and there will hopefully be an update to correct this - but I would be wary of embarking on such a serious bit of number-crunching until sure that the processing limit is sorted out.

Plus, Martin and Kohugaly really know their stuff in that particular subject; as shown by many previous SM schematics - unless some other "Rubyist" with experience of this shows up, those guys are the ones most likely to find a good solution.

Troggie - I accept ruby

He he - ironic, now I'm telling you not to!!
Well, not really - but I do think that this is one area where it may not be very suitable just at the moment.

[tester]

Trog -

My signals are periodic, fading and long (collection of audio files, in which I'd like to determine patterns), at least 20 seconds per file (usually more than 30-40). These sounds contain 8-16 correlated bands, in each band there is a set of 2-4 peaks, and difference between peaks in pack are between 0.1Hz to 40Hz. What I need to determine are the peak frequencies, frequency differences in packs (vibrations), and gains relationships between packs. So it's offline, batch processing, not real-time synth.

[trogluddite]

Yes, I understand your intention - the trouble is that the Ruby "excess processing" protection seems to assume that we DO always want to do things in real time.
I don't mean that the Ruby processing itself is intended for real-time streams - rather that there is a limit to the amount of time that any Ruby 'event' is allowed to utilise the CPU, in order to prevent the interruption of audio streams. But that protection behaves in the same way even when there are not any stream components in the schematic.
IMHO, the idea of having some protection is not inherently bad - but the developers seem to have made a rash assumption about what we might want to use Ruby for - and they have now acknowledged this.

This is why mccy seems to have had problems with his file parser - that too is intended only for off-line processing. But when the file he wants to parse is too long, the Ruby primitive appears shut down because the result is not returned quickly enough. And this is very much a similar situation to what you are wanting to do with your audio files - which would likely contain much more data than the text files that mccy tries to process.

No doubt you will notice that what I have said includes many "seems" and "appears" - and it is true that our understanding of the Ruby protection is very limited at the moment. But IMHO, it would be prudent to avoid very heavy Ruby processing until it is better understood, or its behaviour is modified by the developers.
I will continue to experiment with this myself, as I also have some applications in mind that require processing of large files - and possibly those experiments will show that we have misunderstood how the "protection" is working. Either way, I'll post up any conclusive results that I find.

[tester]

Do the audio/file needs to be treated as an audio stream instead of green array of samples? Or - does the ruby needs to know "what is real time" of the stream/audio data? The stream can be processed slower, i.e. "rescaled".

Anyway - thanks for seeing this topic.

Maybe support could add something here? Multiple peak finding and higher FFT resolutions are rather something of value, for both - audio and non-audio signal processing. It's one of these little things that makes the difference between toys and professional environments, I think.

[trogluddite]

The form of the data has little impact on the problem, unfortunately.
Mccy's schematic illustrates this - he is reading his file data directly using Ruby's own file commands, so it is neither stream nor green data. Yet it still incurs the "high-processing" protection - it appears to be the quantity of data points, and complexity of processing, that ultimately causes problems. However, it is possible that the Ruby file reading contributes to the problem - loading the data into an array outside Ruby may help with this.

But now for some more hopeful news!
I have located a code example of the FFT algorithm - although it is in 'C' rather than Ruby, it is much simpler than I recall, and the programmer has described the process in programming terms rather than esoteric mathematics.
I am rather busy this weekend, but I will try to port the code into Ruby when I have the opportunity (or maybe another kind soul will do this sooner!).

EDIT) Aha, found a proper Ruby version.

This at least will put us in a position to try some empirical tests, and see if my warnings are justified.

Maybe support could add something here?

Yes, I totally agree, these are much used techniques in a wide variety of applications. Even if we can do it in Ruby, the dev's have the tools to do it much more efficiently and in a simple to use "primitive" format.

[tester]

FFT primitive (graphFFT) has window size / resolution limitation to 16k pts (just checked). It would be nice to have user selection input for how big the window should be, up to at least 256k pts.

Regarding the code you found, I don't know what to do with it. Copy/paste and see if it works? If something more, then I'm cooked Can you do some checkups for me?

Have a general thought. Generally - ruby or not - the module requires only a "window size" of samples, not the whole file. So specified window size can be provided via the same theme as Martin provided on SM (mono to graph - this one seems to be limited by the samplerate - at 44.1k takes 44.1k samples max; another primitive to unlimit), and sent for static 1-shot FFT transformation.

[trogluddite]

Regarding the code you found, I don't know what to do with it.

Don't think it will work in the current form - needs adapting to suit the FS inputs and outputs. I suspect also a few other tweaks, a couple of things look like maybe an older version of Ruby. Will be much easier than translating 'C' code though!

Re: window size.
I see Martin's comments on the SM thread - for 0.1Hz resolution, he says approx. 10s maximum window size. Good to have an indication of the max. window size that could be needed.
Those primitive limits are rather annoying. Hopefully, a larger window can be achieved when working from a .wav file rather than sampling live audio.

[tester]

Regarding window sizes, they are in samples, and (typically?) they are expression of 2^N. These numbers represent the amount of samples needed to analysis at certain resolution. You divide the window size through the sample rate, and you have the required time lenght of the audio. If you divide the sample rate through window size - you get the accuracy in Hz. For example:

2^11 = 2048 @ 44100Hz => ~0.05s => ~21.53Hz
2^12 = 4096 @ 44100Hz => ~ 0.09s => ~10.78Hz
2^13 = 8192 @ 44100Hz => ~0.19s => ~5.38Hz
2^14 = 16384 @ 44100Hz => ~0.37s => ~2.69Hz
2^15 = 32768 @ 44100Hz => ~0.74s => ~1.35Hz
2^16 = 65536 @ 44100Hz => ~1.49s => ~0.67Hz
2^17 = 131072 @ 44100Hz => ~2.97s => ~0.34Hz
2^18 = 262144 @ 44100Hz => ~5.94s => ~0.17Hz
2^19 = 524288 @ 44100Hz => ~11.89s => ~0.08Hz
2^20 = 1048576 @ 44100Hz => ~23.77s => ~0.04Hz

I wasn't sure if the same rules are for SM/FS processing, but Martin confirmed. Anyway, what Martin's work does - it will work great for single peaks, but with multiple peaks - rather the higher resolution is required and one of below described features.

*

Quoting about the overlap:

"This feature allows the time axis plot to be stretched by re-processing portions of the time series. The setting determines what percentage of the FFT size block of data points is re-used for the next trace. High overlap percentages (90+%) and low FFT block sizes provide the highest time resolution but take longer to process the data file. This feature is only used in Post-Processing mode. Large FFT sizes produce high frequency resolution but poor time resolution while low FFT sizes have the opposite effect. Overlap processing can be used to provide high resolution in both the frequency and time axis. For example, if a signal contains two discrete tones separated in frequency, only one of which is on at a time, it is difficult to discern the relative timing of each tone because both frequencies are often contained within a single FFT size time series block. If we perform an FFT and, instead of moving forward a whole FFT size block in the series, move forward only a small amount then we can isolate the pulse timing for each tone."

* Seems to be good for anything. On the picture looks like this. When you take a N portion of samples (let say N=1024), then normally you follow this theme. Block of N samples, next N samples, next N samples and so on. With overlap - you take N samples, but your step is less than N. So you take 1024 samples, and instead of making 1024-samples step - you take 100 samples step and take 1024 samples from that point.

Quoting about the declimation ratio (and as far I remember - this one rather takes CPU):

"This feature allows you to reduce the sampling rate (decimate) of the current .WAV file by a user specified ratio. You may wish to apply a low-pass filter to the data prior to decimating. The decimation ratio value controls the ratio with which the digitized audio is down-sampled. This feature is used to achieve a lower sampling rate than that supported by the sound card. This will allow greater frequency resolutions at low frequencies for vibration measurements and similar applications. For instance, if your sound card's lowest supported sampling rate is 11025 Hz, decimating by a factor of 10 will effectively reduce this to 1102.5 Hz. The resulting measurement range will then be 0 to 551.25 Hz. Decimation is actually a very simple process. Let's say we want to down-sample by a factor of 8:1, all we need to do is to throw away 7 out of every 8 samples. You need to be careful when decimating to make sure that the original signal contains no energy above the 'new' Nyquist frequency otherwise aliasing will occur. If this is not the case you should use a low pass filter."

* Seems to be good only if the sound has low upper limits.