我一直在试验 FFT 算法。我使用 NAudio 以及来自互联网的 FFT 算法的工作代码。根据我对性能的观察,生成的音调不准确。
我将 MIDI(从 GuitarPro 生成)转换为 WAV 文件(44.1khz,16 位,单声道),其中包含从 E2(最低吉他音符)开始到大约 E6 的音高级数。较低音符(E2-B3 左右)的结果通常是非常错误的。但是达到 C4 有点正确,因为您已经可以看到正确的进程(下一个音符是 C#4,然后是 D4,等等)。但是,问题是检测到的音高比实际音高低半个音符(例如,C4 应该是音符,但显示的是 D#4)。
您认为可能有什么问题?如有必要,我可以发布代码。非常感谢!我还在开始掌握DSP领域。
编辑:这是我正在做的事情的粗略描述
byte[] buffer = new byte[8192];
int bytesRead;
do
{
bytesRead = stream16.Read(buffer, 0, buffer.Length);
} while (bytesRead != 0);
然后:(waveBuffer 只是一个用于将 byte[] 转换为 float[] 的类,因为该函数只接受 float[])
public int Read(byte[] buffer, int offset, int bytesRead)
{
int frames = bytesRead / sizeof(float);
float pitch = DetectPitch(waveBuffer.FloatBuffer, frames);
}
最后:(Smbpitchfft 是具有 FFT 算法的类......我相信它没有任何问题,所以我不会在这里发布它)
private float DetectPitch(float[] buffer, int inFrames)
{
Func<int, int, float> window = HammingWindow;
if (prevBuffer == null)
{
prevBuffer = new float[inFrames]; //only contains zeroes
}
// double frames since we are combining present and previous buffers
int frames = inFrames * 2;
if (fftBuffer == null)
{
fftBuffer = new float[frames * 2]; // times 2 because it is complex input
}
for (int n = 0; n < frames; n++)
{
if (n < inFrames)
{
fftBuffer[n * 2] = prevBuffer[n] * window(n, frames);
fftBuffer[n * 2 + 1] = 0; // need to clear out as fft modifies buffer
}
else
{
fftBuffer[n * 2] = buffer[n - inFrames] * window(n, frames);
fftBuffer[n * 2 + 1] = 0; // need to clear out as fft modifies buffer
}
}
SmbPitchShift.smbFft(fftBuffer, frames, -1);
}
并解释结果:
float binSize = sampleRate / frames;
int minBin = (int)(82.407 / binSize); //lowest E string on the guitar
int maxBin = (int)(1244.508 / binSize); //highest E string on the guitar
float maxIntensity = 0f;
int maxBinIndex = 0;
for (int bin = minBin; bin <= maxBin; bin++)
{
float real = fftBuffer[bin * 2];
float imaginary = fftBuffer[bin * 2 + 1];
float intensity = real * real + imaginary * imaginary;
if (intensity > maxIntensity)
{
maxIntensity = intensity;
maxBinIndex = bin;
}
}
return binSize * maxBinIndex;
更新(如果有人仍然感兴趣):
因此,下面的一个答案表明 FFT 的频率峰值并不总是等于音调。我明白那个。但如果是这样的话,我想为自己尝试一些东西(假设有时频率峰值是最终的音调)。所以基本上,我得到了 2 个能够显示音频信号频域的软件(DewResearch 的 SpectraPLUS 和 FFTProperties;归功于它们)。
下面是时域中频率峰值的结果:
光谱增强版
和 FFT 属性:
这是使用 A2 的测试音符(大约 110Hz)完成的。查看图像时,SpectraPLUS 的频率峰值在 102-112 Hz 左右,FFT Properties 的频率峰值在 108 Hz 左右。在我的代码中,我得到 104Hz(我使用 8192 个 block 和 44.1khz 的采样率......然后将 8192 加倍以使其成为复杂输入,所以最后,与 SpectraPLUS 的 10Hz binsize 相比,我得到大约 5Hz 的 binsize ).
所以现在我有点困惑,因为在软件上它们似乎返回了正确的结果但在我的代码中,我总是得到 104Hz(请注意我已经将我使用的 FFT 函数与其他函数(如 Math.Net 和这似乎是正确的)。
您认为问题可能出在我对数据的解释上吗?或者软件在显示频谱之前会做一些其他事情吗?谢谢!
最佳答案
听起来您的 FFT 输出可能存在解释问题。一些随机点:
FFT 具有有限分辨率 - 每个输出 bin 的分辨率为
Fs/N
,其中Fs
是采样率,N
是 FFT 的大小对于音阶较低的音符,连续音符之间的频率差异相对较小,因此您需要足够大的 N 来区分相隔半音的音符(请参见下面的注释 1)
第一个 bin(索引 0)包含以 0 Hz 为中心的能量,但包含来自
+/- Fs/2N
的能量
bin
i
包含以i * Fs/N
为中心的能量,但包含来自+/- Fs/2N
任一侧的能量这个中心频率的你会得到 spectral leakage来自相邻的垃圾箱 - 这有多糟糕取决于什么 window function你使用 - 没有窗口(== 矩形窗口)和频谱泄漏会非常糟糕(非常宽的峰值) - 对于频率估计,你想选择一个能给你尖峰的窗口函数
音高与频率不同 - 音高是一种感知,频率是一种物理量 - 乐器的感知音高可能与基频略有不同,具体取决于乐器的类型(一些乐器甚至不会在其基频上产生显着的能量,但我们仍能感知到它们的音调,就好像基频存在一样)
根据有限的可用信息,我最好的猜测是,也许您在将 bin 索引转换为频率的某个地方“偏离了一个”,或者您的 FFT 太小而无法为低音提供足够的分辨率,并且你可能需要增加 N。
您还可以通过倒谱分析等多种技术改进音调估计,或者通过查看 FFT 输出的相位分量并将其与连续的 FFT 进行比较(这允许在一个 bin 内更准确地估计一个频率给定 FFT 大小)。
注释
(1) 只是给出一些数字,E2 是 82.4 赫兹,F2 是 87.3 赫兹,所以你需要一个略高于 5 赫兹的分辨率来区分吉他上最低的两个音符(比这更精细如果你真的想做,比如说,精确调整)。在 44.1 kHz 样本下,您可能需要至少 N = 8192 的 FFT 才能获得足够的分辨率(44100/8192 = 5.4 Hz),可能 N = 16384 会更好。
关于c# - C# 的 FFT 误差,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4966124/