如何解释 KissFFT 的 Kiss_fftr(真实信号的 FFT)函数的结果
我正在使用 KissFFT 的 real 函数来转换一些真实的音频信号。我很困惑,因为我输入了带有 nfft 样本的真实信号,但结果是 nfft/2+1 复杂频率箱。
来自 KissFFT 的自述文件:
真正的(即不复杂)优化代码仅适用于偶数长度的 fft。它并行执行两个半长 FFT(打包为 real&imag),然后通过旋转将它们组合起来。结果是从 DC 到奈奎斯特的 nfft/2+1 复数频率档。
所以我不知道如何解释结果。我的假设是数据的打包方式类似于 r[0]i[0]r[1]i[1]...r[nfft/2]i[nfft/2],其中 r[ 0] 是 DC,i[0] 是第一个频率点,r[1] 是第二个频率点,依此类推。是这样吗?
I'm using KissFFT's real function to transform some real audio signals. I'm confused, since I input a real signal with nfft samples, but the result is nfft/2+1 complex frequency bins.
From KissFFT's README:
The real (i.e. not complex) optimization code only works for even length ffts. It does two half-length FFTs in parallel (packed into real&imag), and then combines them via twiddling. The result is nfft/2+1 complex frequency bins from DC to Nyquist.
So I have no concrete knowledge of how to interpret the result. My assumption is the data is packed like r[0]i[0]r[1]i[1]...r[nfft/2]i[nfft/2]
, where r[0] would be DC, i[0] is the first frequency bin, r[1] the second, and so on. Is this the case?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
是的。 Kiss_fftr 只制作 Nfft/2+1 bin 的原因是因为实际信号的 DFT 是共轭对称的。与负频率( -pi:0 或 pi:2pi ,无论哪种方式考虑)对应的系数是来自 [0:pi) 的共轭系数。
请注意,out[0] 和 out[Nfft/2] bin(DC 和 Nyquist)的虚部为零。我见过一些库将这两个真实的部分打包在第一个复合体中,但我认为这是违反合同的行为,会导致难以诊断、几乎正确的错误。
提示:如果您使用 float 作为数据类型(默认),则可以将输出数组强制转换为 float complex* (c99) 或 std::complex* (c++)。 Kiss_fft_cpx 结构的包装是兼容的。默认情况下不使用这些的原因是 Kiss_fft 可以与 float 和 double 之外的其他类型以及缺乏这些功能的旧版 ANSI C 编译器一起使用。
这是一个人为的示例(假设 c99 编译器和 type==float)
Yes. The reason kiss_fftr makes only Nfft/2+1 bins is because the DFT of a real signal is conjugate-symmetric. The coefficients corresponding to negative frequencies ( -pi:0 or pi:2pi , whichever way to like to think about it) , are the conjugated coefficients from [0:pi).
Note the out[0] and out[Nfft/2] bins (DC and Nyquist) have zero in the imaginary part. I've seen some libraries pack these two real parts together in the first complex, but I view that as a breach of contract that leads to difficult-to-diagnose, nearly-right bugs.
Tip: If you are using float for your data type (default), you can cast the output array to float complex* (c99) or std::complex* (c++). The packing for the kiss_fft_cpx struct is compatible. The reason it doesn't use these by default is because kiss_fft works with other types beside float and double and on older ANSI C compilers that lack these features.
Here's a contrived example (assuming c99 compiler and type==float)
fftr结果的r[1]和i[1]构成复向量。它们一起给出第一个频率仓的幅度(两个分量的平方和的平方)和相位(通过 atan2())。
r[1]and i[1] of the fftr result constitute a complex vector. Together they give you a magnitude (sqrt of the sum of the squares of the 2 components) and a phase (via atan2()) of the first frequency bin.