FFT/IFFT - time/frequency trade off

Hi all,

I am converting an audio signal to freq domain and back to time domain at different fft sizes to see the trade-off between time and freq resolution.

I thought that if I take the FFT of a very large window, I will get good frequency resolution but smear the time resolution. But when I take the FFT of a very long window (say 2^17 samples, which is roughly 3 sec), the following conversion reconstructs the signal nearly perfectly:

s = fft(x); % d contains 2^17 samples x2 = ifft(s);

I know these are inverse functions, but shouldn't there be some loss incurred? I expected the result to sound like a bank of sinewaves but playing back x2 it sounds like the original. What am I doing wrong? Thanks!

Answer 1

[Walter Roberson]

Total number of samples is time resolution multiplied by the sampling period. The more total samples you have, the more frequency resolution you get. fft() cannot, however, tell the difference between a low time resolution sampled for a long duration, and a high time resolution sampled for a short duration: it will produce the same output as long as the product of the two is constant. Likewise, if you use a lower time resolution but keep the duration the same, the effect will be identical to having kept the same time resolution but reducing the duration by the same ratio.

[Eugene Kogan]

My code is below. The problem is as I vary the exponent on segsize and hop, I do not hear any difference. I expect that when I increase segsize (always keeping hop at half of it), I am reducing my time resolution, but increasing frequency. But instead, the signal is not blocky or smeared, it is perfect as it was before I processed it...

segsize = 2^17;

hop = 2^16;

window = hamming(segsize);

i=1;

while( (i-1)*hop + segsize<length(d)-segsize) % while enough samples left

idx = 1 + (i-1)*hop : (i-1)*hop + segsize; % index of samples for frame

spec = fft(d(idx),segsize);

d2(idx) = d2(idx) + (ifft(spec,segsize).*window')';

i=i+1;

end

[Eugene Kogan]

Note that the current coefficient for segsize is obviously very high at 17. At sample rate of 44.1k, that corresponds to a frame of about 3 seconds... Yet it sounds the same as it does for a "typical" frame length of 1024 samples.