Overlap add for signal synthesis

0
votes

I apologize if this question is very basic.

I'm transforming an audio signal (currently a plain sine wave) from the time-domain to the frequency-domain using FFT, and then back to the time-domain to compare the difference to the original signal.

Currently I do:
- Take a non-overlapping frames (e.g. 1024 samples per frame).
- FFT that frame
- iFFT the freq-domain information
- send output to speakers

EDIT (1):
This seems to work now (see images without and with a window, where input=brown, output=blue).
enter image description here
enter image description here
END EDIT (1)

Now I want to perform the overlapp-add method:
- Take frames with 50% overlap (samples 0-1023, 512-1535, 1024-2047...)
- Apply a Hanning window to ecah frame
- FFT
- iFFT
- ??? This is my question!!

So at the end of my iFFT I have an output frame of 1024 samples. Does that mean that I need to send the first 512 samples to the speakers, and the other 512 samples (512-1023) should be kept in a buffer to be added to the first 512 samples of the next frame? Is that as simple as that or am I misunderstanding something?

Thanks!

1
signal-processingfftifftvdsp
Why would you expect the output to be a bad quality copy of the original sine wave (aside from the fact that you didn't window it)? – jaket
@jaket I attached an image. The input sounds continuous while the output sounds like short pulses. To my limited understanding, the output is different because of the spectral leakage, the input frequency doesn't exactly match any FFT frequency bin. – Merlevede
You have a bug in your code. The IFFT of an unmodified complex FFT result should return the exact original data (minus tiny numerical rounding issues). So somewhere you are trashing your data. For instance: throwing away phase information will greatly distort your result. – hotpaw2
As to the last question: Yes, keep the second half in the buffer and add to if the first half of the next frame. To be sure, check that the window functions for successive frames add to 1 in the overlap area. – Lutz Lehmann
@hotpaw2 You were right about the bug, as you can see I corrected it. Feel welcome to post your suggestion as answer so I can at least upvote. – Merlevede

1 Answers

1
votes

Normally, when you do overlap-add, you zero-pad the data before the FFT, and save the left-over tail to later add to the result of the next frame processed.

Your initial "bad quality" problem is probably due to some bug where you don't preserve the exact phase information (the full complex FFT result) between the FFT and IFFT. You will have to fix this, whether or not you do overlap-add or overlap-save fast convolution or other processing.