Weird built-in GraphFF Magnitude scaling

[steph_tsf]

I think that the Synthmaker/Flowstone built-in GraphFF component is not compliant with "The Scientist and Engineer's Guide to Digital Signal Processing" by Steven W. Smith. You can access the book online freely at http://www.dspguide.com/pdfbook.htm

The more you take samples (NS input to the Graph component that's preceding the GraphFF component), the bigger the Magnitudes. This is counter-intuitive, and possibly wrong. Is this coming from a speed optimisation?

Attached are two FFT-based Spectrum Meters, done using Flowstone and Ruby, maintaining the same readings when changing NS (256 samples, 512 samples, etc). Are these okay?

[MyCo]

GraphFF is an unscaled FFT. Have a look here:
viewtopic.php?f=2&t=1477#p6180

[steph_tsf]

Thank you so much, I will use the FFT component followed by MagPhase component.

[steph_tsf]

The FFT plot stabiliy gets degraded using the FFT component followed by the MagPhas component. Can somebody check the two attached .fsm? One is using the GrapFF component, and the other is using the FFT component followed by the MagPhas component. Are there practices to be obeyed, when processing Float arrays? For getting stable results, is it better to use GreenMath, instead of RubyMath?

[nix]

Sorry mate,
I had a look, but I'm terrible in the frequency domain.
The magnitude is certainly oscillating here comparative, in the examples.
Will poke around some more.

[MyCo]

@steph_tsf: You have to connect the "imag" output from the the FFT to the mag/phase, too. The magnitude gets calculated like this:

Code: Select all

mag = SQRT( real^2 + imag^2 )

[steph_tsf]

@MyCo : Ough, thanks .... that's a Monday thing.
I'm attaching corrected versions. Thanks again.

Getting a properly calibrated dB axis is not trivial.

1. You need to know how the FFT output gets scaled, as there is a fundamental scaling difference between GraphFF (method 1) and FFT followed by MagPhas (method 2).

2. GraphFF delivers magnitudes that do increase in proportion with the FFT length. The bigger the signal duration, the bigger the absolute energy. Sounds logic.

3. FFT followed by MagPhas delivers magnitudes remaining the same, the FFT being short or long. Kind of internal signal duration compensation, for delivering energy measurements easing comparisons.

4. In case you want to apply a window on the signal, that window needs to be normalized, otherwise the FFT magnitudes will exhibit a scaling error. The obvious choice is to scale the window in such a way that when applying the window, the DC gain remains equal to 1. The windows surface must equal 1. In other words, you need to scale the window in such a way that the sum of all window coefficients equals 1.

5. Consider a rectangular window. If the FFT length is equal to 64, all window coefficients will be the same and equal to 1/64. If the FFT length is 1024, all window coefficients will be the same, and equal to 1/1024. A very long FFT will thus appear as processing a winormalized signal having a tiny amplitude, and a very long in duration. Symmetrically, a very short FFT will appear as processing a winnormalized signal having a quasi-normal amplitude, and a very short duration. Please note that the "amplitude x duration" product remains the same.

6. Therefore, in case there is a normalized window applied to the audio signal, the GraphFF (method 1), will deliver steady magnitudes, the FFT being long or short.

7. And, in case there is a normalized window applied to the audio signal, the FFT followed by MagPhas (method 2) will get disturbed. The magnitudes will get smaller, when the FTT length increases. Thus, when there is a normalized window applied to the audio signal, and when such winormalized audio signal gets processed by FFT followed by MagPhas, one need to multiply the MagPhas magnitudes by the FFT length.

I'm sure MyCo and many other Synthmaker/Flowstone specialists know this. Surely this could be explained with better clarity in a tutorial. Please note I have coined "winormalized" as adjective in the context of FFT and windowing, for enabling a clear distinction between bare audio, normalized audio, and winormalized audio.

Steph

[MyCo]

There is one thing that I've mentioned in the thread above: you have to remove the DC offset from the input waveform before you put it into the FFT. When you don't do that you'll get a spike in the lowest bin, where you wouldn't expect to be one when you just measure AC. And it can get worse when you apply a window, then you'll get spikes on higher bins as well.
You can try that with your triangle FSM, just add a constant offset to your stream and your FFT display goes crazy. The Ruby code to remove the DC Offset in your "Apply Normalized Window" would look like this:

Code: Select all

val = []
dcoff = @signal.reduce(:+)/@len
@len.times do |i|
  val[i] = (@signal[i]-dcoff)*@window[i]
end
output("out", val)

[steph_tsf]

@ MyCo : thanks for pointing this. I have refined the .fsm, including a DC offset management :
- add some DC offset to the signal
- detect the DC offset within the Spectrum Meter (before any windowing)
- carefully observe the DC offset height now showing on the graph : it has a +6dB error
- apply a frequency that's very close to Fs/2 and observe the magnitude on the graph : it has a +6dB error

See the attached .fsm.
It is going to trigger an interesting discussion.

from http://www.dspguide.com/ch8/5.htm
by Stephen W. Smith : "As shown in the figure, the bandwidth can be defined by drawing dividing lines between the samples. For instance, sample number 5 occurs in the band between 4.5 and 5.5; sample number 6 occurs in the band between 5.5 and 6.5, etc. Expressed as a fraction of the total bandwidth, the bandwidth of each sample is 2/N. An exception to this is the samples on each end, which have one-half of this bandwidth. This accounts for the scaling factor between the sinusoidal amplitudes and frequency domain, as well as the additional factor of two needed for the first and last samples.
Many authors do not even include the 2/N scaling factor. Be prepared to find both of these missing in some discussions. They are included here for a tremendously important reason: The most efficient way to calculate the DFT is through the Fast Fourier Transform (FFT) algorithm, presented in Chapter 12. The FFT generates a frequency domain defined according to Eq. 8-2 and 8-3. If you start messing with these normalization factors, your programs containing the FFT are not going to work as expected."

Is Flowstone FFT + MagPhas obeying the standard, regarding the first and last frequency bin magnitudes?
What standard, actually?
Is is recommended to keep the first and last frequency bins "as is" from the FFT algorithm?
Is is recommended to include a correction factor on the first and last frequency bins, in the FFT algorithm, for streamlining the curve plot?
Is there a difference between GraphFF (method 1) and FFT + MagPhas (Method 2)?
What are the choices made by Synthmaker/Flowstone, and why?

[MyCo]

The FFT in FlowStone is just a straight implementation of FFT. It is not different at all. The FFT in GraphFF is just unscaled, because many time you don't need the scaling. eg. when you want to find the peak frequency it doesn't matter how high the peak is, you just need the index of the maximum in the FFT result. Also the Scaling isn't hard to implement, as I demonstrated in the schematic in the other thread. The FFT+magPhase implementation is exactly how you would implement FFT with complexe numbers. The results are correct.

Regarding the first and last bin: The Guide is a little bit confusing at this point.The lines in the plot are drawn between the individual FFT results. That's why the first and last bands are smaller. When you think about that, it is absolutely normal when you draw a graph. The first point is a x coordinate 0, the second at 1, third at 2 and so on, so the first boundary is always at 0.5 while the second boundary is always at 1.5
Unless you want to draw a band amplitude graph (like in a Graphic EQ) you can ignore that. Also for higher FFT-sizes, this doesn't matter because you draw them always as lines.

In your examples you measure the DC offset... with a more excessive code than the one I posted... but you don't remove/reject it. Why? The DC offset can be significant and the FFT is then just displaying wrong data.