Please please. I know this was a long article, but I need this :-).
Reply by jungledmnc●November 19, 20082008-11-19
yet another question about DFT/IDFT processing. Here's what I do (assuming
1) Take let's say 4096 source samples.
2) Perform windowing (using Hann).
3) DFT the result.
4) Here should be some spectral processing, but now it is not.
5) IDFT the result.
6) Perform windowing again (could this be omitted?)
7) Multiple each resulting sample by 2.0 / 4096. I don't remember why, but
it is caused by FFT algorithm (to be same for DFT and IDFT).
8) Multiple each resulting sample by 1.0 / 5.0 (80% overlapping).
9) Add the result to our temporary output buffer, which is also 4096
samples long and accumulates the result. First 20% (about 700 samples I
guess) of it is final, the rest is moved, so that output overlapping can be
performed. Similarly input temp is moved by 20% to the left and incoming
data cover the last 20%.
I somehow copied this code from Stephan Bernsee pitch transposition
This should obviously do nothing except the introductory fade-in caused by
windowing. It really does nothing (when I tried some equalization, it
worked too), but I have a few questions:
1) Why does it work?
Originally I thought each window should have some predefined overlap size,
which equals to the sample with 0.5 value, so that when I apply windowing
and overlapping to two successive blocks, they would generate the original
signal. Which means:
window[i] + window[i + overlapsize - fftsize] = 1 for every i
But this code applies the overlap-adding by any constant, so on the first
sight it seems, that if I choose really bad overlap size, it would generate
waves in the output amplitude (e.g. overlap = 10%). Or am I missing
2) If the code is correct, how should I ensure the same signal power on
Without windowing it would be correct, since each target sample would be
generate from five source samples (the same ones) divided by 5. But with
the windowing each sample might be created from different ratios. I tried
to approximate by :
(1.0 - OverlapSize) / WindowSum
(which is from ((1.0 - OverlapSize) / fftsize) * (fftsize / WindowSum)
The result is not so bad, but still 20% lower in amplitude.
Thanks guys again!