Quote:
Originally Posted by Tale
Anyhow, have I already mentioned that exact alignment doesn't matter for FFT and alike?
|
So by this buffering I'll be able to do:
audio input -> 50% overlapping Hamming -> FFT -> processing -> iFFT -> combine windows -> output audio processed. And there's no loss of data. I.e. the output audio matches exactly the input audio processed exactly as I programmed it (and not relative to some host stuff).
The problem still doesn't make sense though. If I wanted to make that plug-in that only does hamming, then it wouldn't make sense to tell the user "oh but you have to check that your playhead is in the correct position". Does it make sense that the libraries haven't implemented that kind of "sensing" of the beginning of the audio? Might try to make it though, because I'm kind of afraid that the combining of the overlapped windows just might screw up. Not in the program, but in the output (i.e. it outputs wrong audio).