trying to understand the FFT converter

[tester]

I'm trying to figure out how the FFT converter works here. I don't want to use "normalize" prim, because it always will seek for the highest value, and make it on top.

Why the top value is around 70dB (at least on my PC) and not stable (depends on frequency)? What are the rules for bottom value? I mean - I guess this depends on both - decibel setting/conversion and output bit depth, but I suppose the bit depth defines realistic minimum. But if bit depth - where from take the current depth value?

[MyCo]

To get a realistic value from the FFT, you have to divide the output of Graph-FFT primitive by the size of the FFT, or 1/2 of the FFT size (not sure right now). When you pass the resulting array through the decibel primitive, you should get values below zero.

[tester]

View size /2, just checked, and tested on various FFT wndows; thanks.

Another question comes to my mind. In order to have greater accuracy in picking peaks (narrowing bands; prim limitation at 16kpts offers too wide frequency windows), I was thinking to extend this basic FFT formula into 32kpts or 64kpts. Help me to determine If this is right idea.

What I was thinking about is this.
1. Split the main array into 2 or 4 parts.
2. For each 4k array - use the resample module (with interpolation), to extend it into 16k again
3. Either
a) combine these 4 arrays into larger one, and then feed the graph with 32k or 64k size (depending on choice)
b) split graph into 4 parts, each one would use one of resampled arrays.

Regarding p.3. variants - I don't know if FS can correctly handle (live) arrays greater than 16k.

Anyone playet with it that way? Worth of effort?

[trogluddite]

I don't think the FFT will work quite the way you expect doing that, for a couple of reasons...

1) To get an accurate value at a given frequency there need to be multiple cycles contained within the FFT window. So by chopping up the audio, you would make low frequencies more inaccurate, as fewer cycles would fit inside the window.

2) Whatever the window size, you get a max. freq bin related to the size of two samples - around 22kHz for the usual sampling rate (i.e. Nyquist). Once 'stretched' you have effectively lowered all of the frequencies in the signal - so the upper bins will, in theory, contain nothing (anything that is there would just be interpolation errors).

But the fundamental problem is that by dividing the input array, you would be splitting the audio in TIME not frequency - so each of the 'slices' would be analysing exactly the same frequencies. You would get better time resolution for determining when a frequency occurred, but no extra frequency resolution.

The upsampling might give you a little extra resolution, I'm not quite sure; but if it did, it would only be over a narrower band width - and you can't simply recombine the slices to regain the original full spectrum.

[tester]

Something is wrong with what you said. I'm not stretching anything, I'm adding more points for graphs/processing, to make it more accurate. FFT is done earlier. What I need - are bigger arrays, to make the "image" sharper so to speak. Interpolation should help to "sharpen" the graph.

Generally - quality at these speeds should not be a problem. Green Tick is not regular anyway.

If I have two neighbouring values 1 and 2, then I can get either 1 or 2 (ending with outputs like 1/1 and 1/2), but if I divide and resample, then I can get something between 1 and 2 (getting outputs like 1/1.5 and 1.75/2). Does it matters? Well - if I use then nonlinear rescaling, then these fractional values between 1 and 2 - should give better feedback.

So I think we speak about two different things Trog.

One thing I wonder about - is how to use different interpolation type for an array; someone said about parabola-something.

This one is for 44.1k; I haven't modified yet the rescaler.

[tester]

Okay, above are some errors, but I think I did it. Works pretty nice. Adding now curve for linear rescaling, and some sliders for min-threshold, and scaling+, to fit the view better. Generally it appears, that after rescaling the view to 64kpts, only first two arrays are needed to fit the usable range (instead of resamppled third - left trafic can be added, to indicate noise above 10-11kHz), so +1 towards optimization. But without such rescaling, my 2-days-long project would not work in lower ranges. And now it's tasty