FFT不准确的C#

我一直在试验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,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;对它们的信用).

所以这里是时域中频率峰值的结果：

SpectraPLUS

和FFT属性：

这是使用A2的测试笔记(大约110Hz)完成的.在查看图像时,它们在SpectraPLUS范围内具有102-112 Hz范围内的频率峰值以及FFT属性的频率峰值为108 Hz.在我的代码,我得到104Hz(我使用8192块,采样44.1khz … 8192然后加倍,使其复杂的输入,所以最终,我得到约5Hz的binsize,与10Hz binsize的SpectraPLUS ).

所以现在我有点困惑,因为在软件上,他们似乎返回正确的结果,但在我的代码上,我总是得到104Hz(注意我已经比较了我使用的FFT函数,如Math.Net,正确)

你认为这个问题可能与我对数据的解释有关吗？或者在显示频谱之前先做软件做其他事情吗？谢谢！

解决方法

听起来你的FFT输出可能会有一个解释问题.几个随机点数：

FFT具有有限分辨率 – 每个输出槽具有Fs / N的分辨率,其中Fs是采样率,N是FFT的大小
>对于音阶较低的音符,连续音符之间的频率差异相对较小,因此您将需要足够大的N来区分间隔的音符(见下面的注释1)
>第一个bin(索引0)包含以0Hz为中心的能量,但包括来自/ Fs / 2N的能量
> bin i包含以i * Fs / N为中心的能量,但包含该中心频率两侧的/ Fs / 2N的能量
>您将从相邻的箱子获得spectral leakage – 这取决于您使用的window function有多糟糕 – 无窗口(==矩形窗口)和光谱泄漏将非常差(非常宽的峰值) – 用于频率估计,您要选择一个窗口功能给您带来尖峰
音调与频率不同 – 音调是一种感知,频率是物理量 – 乐器的感知音调可能与基本频率略有不同,具体取决于乐器的类型(有些乐器甚至不会产生显着的能量在其基本频率,但我们仍然认为他们的音调,如果基本存在)

从有限的信息可以看出,我最好的猜测是,您可能会在您将bin索引转换为频率的某个地方“脱离一个”,或者您的FFT太小,无法为低音符提供足够的分辨率,您可能需要增加N.

您还可以通过几种技术(如倒谱分析)或通过查看FFT输出的相位分量并对其进行连续FFT进行比较来提高音高估计(这允许在给定FFT大小的一个bin内更准确的频率估计).

笔记

(1)只要放一些数字,E2是82.4 Hz,F2是87.3 Hz,所以你需要一个比5 Hz更好的分辨率来区分吉他上最低的两个音符(如果你实际上比这更好,想做,说,准确调整).在44.1 kHz采样时,您可能需要至少N = 8192的FFT来给出足够的分辨率(44100/8192 = 5.4 Hz),大概N = 16384会更好.

解决方法

相关推荐