why the amplitude of fft is not the same as input signal?

I am doing fft processing on my input audio signal. But FFT amplitude is not equal to the amplitude of signal which I input to the FFT. my code is as following:

 fftsizw=4096;
 FS=48000;
 OverlapStep = 50;
 WindowType = @hamming;
 Overlap = floor((OverlapStep*fftSize) / 100);  % Number of samples shared each consecutive fft block
 Window = WindowType(fftSize); 

 %%process FFT
 numsamples = length(InputSignal);  

 k=1;
 h=0;
 Ymean = zeros(4096,1);              % vector to hold mean
 while ( (k+fftSize-1) <= numsamples )
    h=h+1;
    SignalFrame = InputSignal(k:k+fftSize-1);
    winsignal = SignalFrame.*Window;
    Y = fft(winsignal,fftSize);
    Ymean = Ymean+abs(Y);         % update mean
    k=k+(fftSize-Overlap);
end
Ymean=Ymean./(h*length(InputSignal));

 freq =linspace(0,FS/2,fftSize/2);
 plot(freq,FF(1:fftSize/2));

is not correct what I have done? what is the problem of the difference of amplitudes?

[hoda kazemzadeh]

nobody helps me?

Answer 1

[dpb]

See the extensive discussion previously at Answer_324924

Continuing the previous example...we had

S = 0.7*sin(2*pi*50*t) + sin(2*pi*120*t);

If we introduce a windowing function in addition

>> S=S.*hamming(L).';
>> Y = fft(S);
>> P2 = abs(Y/L);
>> P1 = P2(1:L/2+1);
>> P1(2:end-1)=2*P1(2:end-1);
>> [pk,fpk]=findpeaks(P1,f,'minpeakheight',0.3);
>> [pk; fpk].'
ans =
  0.3778   50.0000
  0.5397  120.0000
>> pk./[0.7 1]        % compare to known theortical
ans =
  0.5397    0.5397
>> mean(hamming(L))   % mean value of window applied is...
ans =
  0.5397
>>

TADA! the same difference. What you did when windowing is reduced the magnitude of the signal in the time domain by that amount on average; hence there's that much less energy in the frequency domain so have to make it up by including the factor in the normalization.

NB: If the signal isn't stationary in frequency with time over the sampled window, there may be some effect of the tapering applying different amplitudes across the window than the average. That violates the assumption of stationarity inherent in base FFT.

The actual mean for the window changes slightly as a function of window length until approaches a limiting value specific to the window function. For Hamming it is ~0.54.

>> L=32;for i=1:11,fprintf('%6d %0.5f\n',L,mean(hamming(L))),L=L*2;end
  32 0.52563
  64 0.53281
 128 0.53641
 256 0.53820
 512 0.53910
1024 0.53955
2048 0.53978
4096 0.53989
8192 0.53994
16384 0.53997
32768 0.53999
>>

NB2: Some implementations normalize the windowing function to unity mean itself in which case there is no further correction needed in the frequency domain. This has the effect of amplifying the time signal peak to be larger than measured, however. "There is no free lunch."

[hoda kazemzadeh]

It didn't help me because I do fft windowing and I dont have the same problem as the discussion (size of windowed signal and fft points).

[dpb]

It's generic; simply multiply by the average window factor in addition for the window used.

[hoda kazemzadeh]

what do you mean by the average window factor?

[dpb]

See augmented Answer...

[hoda kazemzadeh]

Thanks for your answer but that is not the case, the code you have written is correct and is working but in my code the FFT is the average of fft’s over 4096-point fft performed on the windowed signal using Hanning windowing and over whole signal. So hanning size should be equal to the fft points (4096) and not the length of input signal, I divide my signal into frames with 4096 points and also with 50 % overlapping. I dont know if the problem is with the averaging the fft's over entire signal or somewhere else. (even when I apply the windowing factor, I dont get correct amplitude even for a sin input signal).

numsamples = length(InputSignal);  
k=1;
h=0;
Ymean = zeros(4096,1);              % vector to hold mean
while ( (k+fftSize-1) <= numsamples )
  h=h+1;
  SignalFrame = InputSignal(k:k+fftSize-1);
  winsignal = SignalFrame.*Window;
  Y = fft(winsignal,fftSize);
  Ymean = Ymean+abs(Y);         % update mean
  k=k+(fftSize-Overlap);
end
Ymean=Ymean./(h*length(InputSignal)*mean(hanning(fftsize)));
peak=2*max(Ymean)

[dpb]

That's all tied up in the previous thread and referenced -- what you normalize over is the length of the time signal for the FFT; that's where the energy is; the augmentation of points for the actual FFT are all zero energy so there isn't any power contributed by them.

The windowing function otoh, depends on where you place in the code; it should be applied to the time signal itself and therefore use its length; then the average factor for it will be based on that length instead of the FFT length.

If you're using nextpow2(), then it may be the simplest coding would be to do as in the note; normalize the windowing function to return mean==1 or iow, apply that normalization prior to doing the FFT.

Either way, the above discussion has the necessary info whichever way you choose to actually implement it.

[dpb]

...
Ymean=Ymean./(h*length(InputSignal)*mean(hanning(fftsize)));

In the above the length(InputSignal) is wrong; it should be nEnsembles*|fftSize| because you're only using a portion of the overall time domain signal on each pass. Each FFT is done independently of the others and as far as it knows, that's all the signal there was; only you know you're actually averaging ensembles.

peak=2*max(Ymean);

This has the problem outlined in the discussion linked to -- to get the proper one-sided PSD from the two-sided FFT, you need to pick the positive frequency half and then only double the (2:end-1) entries; there is only one DC and one Fmax bin in FFT; the above doubles those two bins as well. If the input signal is zero mean or very nearly so, it may not make much difference but if there is any significant DC component, that will often be very observable; may as well do it precisely since it's not that much harder, just an indexing expression.

It's commented clearly in my sample code what sections to take and why.

PS: Perhaps it would be more clear if you were to put the normalization inside the loop first for debugging and get it right on an individual ensemble first; then you should be able to see how to generalize to the overall...

[hoda kazemzadeh]

I changed my code to the following:

fftSize = 4096;
FS = 48000;
OverlapStep = 50;
DisplayRate = 1;
WindowType = @hanning;
Overlap = floor((OverlapStep*fftSize) / 100);  % Number of samples shared each consecutive fft block
Window = WindowType(fftSize); 

 %%process FFT
numsamples = length(InputSignal);        % Number os samples in one second

 k=1;
 h=0;
 Ymean = zeros(fftSize,1);              % vector to hold mean
while ( (k+fftSize-1) <= numsamples )
    h=h+1;
    SignalFrame = InputSignal(k:k+fftSize-1);
    winsignal = SignalFrame.*Window;
    Y = fft(winsignal);
    Ymean = Ymean+abs(Y); % update mean
    k=k+(fftSize-Overlap);
    result(:,h)=Y;          
end
fftmean=2*Ymean/(h*fftSize*mean(hanning(fftSize)));

for a sine signal with the amplitude of S= 3*sin(2*pi*50*t);, I get 46.89, 2.86 for the frequency and amplitude respectively. I dont know where it comes this small difference.

[dpb]

That's precisely the question the initial link addresses -- your input frequency is 50 Hz but the sampling rate/FFT resolution doesn't return a bin in the frequency domain precisely centered on 50 Hz so some energy is "bled off" into surrounding bins. See the illustrative plots and examples there and how results are affected by the FFT resolution as compared to input signal frequency.

Your code still also has the issue of doubling the DC and Fmax bins; this may corrupt those to specific values but won't effect the peak. Not sure why you're so reluctant to fix this detail as well while you're at it.