|
|
Dec 13, 2010 at 9:42pm
pfft~ bins
Hi, list,
Maybe it’s a stupid question, but haven’t figured it out this morning…
It’s about the bins or the third outlet of fftin~ object (in pfft~).
Say fft size is N, shouldn’t the real FFT have bins all the way from 0 to N/2?
Here fftin~ only gives bins from 0 to N/2-1, missing the highest frequency bin?
Thanks in advance
|
|
|
Dec 14, 2010 at 11:14am
well, because it starts at 0 …. just count:
fft 1024 -> 0 … 511 ==512 values.
-110
|
|
|
Dec 14, 2010 at 2:07pm
In pfft~ the nyquist bin in the fft is zeroed on input and output to make everything neat (you never see this value). Similarly, there should not actaully be an imag value for the DC bin (DC and nyquist are real-valued only) but it is simpler to deal with N/2 pairs rather than (N/2 +1) real values and (N / 2 -1) imag values.
Most of the time this doesn’t matter. If it really matters to you you can try the old-school fft~ approach and roll your own overlapping scheme – it’s a bit of a pain. fft~ also only goes up to 4096 points though so you can’t do more than that and keep the nyquist bin. In my experience the number of cases where this will make a difference are very few, and mostly relate to fft processing with no window function….
HTH
Alex
|
|
|
Dec 15, 2010 at 6:48pm
Thanks Alex for the detailed explanation, yeah I was thinking why it kept the DC bin and not the Nyquist bin.
Much clearer now :)
|
