I am currently working on a frequency domain real-time application on a digital signal processor. Currently for one time frame of my algorithm I read in time domain data into a buffer, perform a Fourier transform with a Hanning window (win), which I generate using MATLAB with the following code:

win = 2*hanning(N,'periodic')/N;

where N is my transform length, (usually 2048 in my case). The window coefficients are then stored in a header file as single floating point data to be included into a C project.

In the frequency domain I execute my algorithm, then convert it back to the time domain to be outputted in a third buffer. I am certain the forward and reverse transforms work correctly having thoroughly tested them (and having used them for several months).

However when I output the data I use the following 'window' to reverse the effects (i.e. the energy level of the time domain signal to remove the 'oscillating' effect of the reconstructed signal) of the original window that I applied (in MATLAB code):

win_out = win ./ (win.^2);

I've seen the divide by energy (win.^2) in other peoples code, and assume that the line of MATLAB code above is equivalent to (it gives the same result of course):

win_out = 1./ win;

When I implement this in my real time application the values on the edge of my 'output' window (win_out) are very large (of the factor x10^8, see image below) and are in fact too big. This results in the edges of my time period being amplified too much resulting in a 'clippy' effect in my time domain signal when I listen to it.

I've illustrated the problem below

Original reconstructed time domain signal

Above is the original reconstructed time domain signal, if this was to be outputted it would have an oscillating effect on the output, which I try and fix by applying an 'inverse' window.

'Inverse' window (zoomed in)

This is the inverse window that generated by the above MATLAB code.

T-domain with window zoomed out

Time domain signal with my 'inverse' window (note: spikes at each end).

T-domain with window zoomed in

First spike zoomed in.

NB: I don't use overlapping (yet!)

My question is: how do a choose an 'inverse' (if that is the correct term?) window to ensure those spikes aren't present in fully reconstructed time domain signal with window?

Many thanks !

  • $\begingroup$ first thing, it's called either the "Hann window" (or maybe "von Hann") or maybe it's the "Hamming window", which is slightly different from the Hann window. there is no "Dr. Hanning" to name the window after. second thing, assuming it's the Hann window, division by zero is a bitch. better not do it. $\endgroup$ Oct 15, 2014 at 3:28

1 Answer 1


You should be using overlap. That ought to take care of the "oscillating" and make it unnecessary to undo the Hanning window.

The effect you are seeing comes about because the window values at the edges get very close to (and may even be) zero. The window edges won't line up perfectly with the signal after you've done your processing in the frequency domain, so dividing by those very small values will cause the peaks you see.

In your place, I would first make sure that I could do the windowed FFT/IFFT and recover the original signal. When you can do that without getting the "oscillation" you can put your processing back in.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.