FFT with different orders and their results

Development
1

Hey.

I am currently developing a realtime FFT-analyzer and want to use the juce fft. Great and easy to use like all the other juce stuff. Thanks! :slight_smile:
But there is a little thing, I don’t understand. For testing, I use a simple sawtooth signal and pass it through the fft and for the tests I choosed different fft-orders.

Actually, I have expected results that are similar only that they have different resolutions, but they differ more than expected. especially the amplitudes are quite noticeable.Take a look at the image.

fftAmps
fftAmps.png1992Ă—574 235 KB

the left uses the fft order 10 and the right the fft order 14. The aplitudes with order 14 are much higher. First I thought, it was my window function and I deactivated it. so the signal is as pure straight saw. Why is the right one much higher?

2

Did you scale the magnitudes?

IIRC the magnitude of a frequency is the real part divided by the number of bins, but please double check.
It would explain, why you got a higher magnitude with a higher order FFT.

EDIT: I found the post that helped me back then: In what units does frequency fft return values?

2 Likes
3

thanks for your anwser but… i don’t get it. so I have…

.....
    fft.perform(source, output, false);

    for (int j = 0; j < frame->getSize(); j++)
    {
        mags[j] = getMagnitude(output[j]);
        phases[j] = getPhase(output[j]);
    }
....

and to get the mags and phases I am using the standard functions…

forcedinline static float getMagnitude(dsp::Complex<float>& harmonic)
{
	const float re = harmonic.real();
	const float im = harmonic.imag();
	return std::sqrt(re * re + im * im);
}

forcedinline static float getPhase(dsp::Complex<float>& harmonic)
{
	const float re = harmonic.real();
	const float im = harmonic.imag();
	return std::atan(im / re);
}

What do you exactly mean? If I divide the real by the nums of bins before I convert it into mags and phases, the mags in the visualizer are moving up and down over time (sure, i decreased the width of the circle in the img-real field). I also tried to divide the magnitude by the number of bins (and multiplied it with a factor, to see them again on the screen, cause they’re getting very tiny :smiley: ). So it doesn’t work for me. Something is missing. :thinking:

4

Divide the magnitude (both real and imaginary part) by the number of bins which is 2^order. Then your result should be scaled correctly.

5

By the way, did you know that you can simply use std::complex<float> as complex data type? Nothing technically wrong with what you are doing, but if you look into the juce dsp header you’ll find

namespace dsp
    {
        template <typename Type>
        using Complex = std::complex<Type>;
//...
    }

so dsp::Complex<float> is in fact a std::complex<float>. This means that you can simply use std::abs and std::arg instead of your own getMagnitude and getPhase implementations – no need to reinvent what’s already existing and often it is a good idea to use the std library implementations which might be optimized to the maximum :wink:

6

Okay. I get it. :man_facepalming: Thanks a lot, now the magnitudes are looking the same with different orders.

7

Thanks you. Will take a closer look at it. :wink: