我一直在试验 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/