2

そこで私は、特定の音の検出とフィルタリングを含むプロジェクトの前兆として、リアルタイムオーディオアナライザーとして機能するAndroidアプリを構築しようとしています。

ですから、離散フーリエ変換の基本は理解できたと思いますが、リアルタイムの周波数解析を行うために最適なパラメーターは何かわかりません。

理想的な状況（無制限の計算能力）では、AudioRecordクラスから取得した44100サンプル/秒のPCMストリームからすべてのサンプルを取得し、44100要素のFIFO「ウィンドウ」（ 2 ** 16は0で、おそらくテーパー関数ですか？）、新しいサンプルが入るたびにウィンドウでFFTを実行します。これにより、（私は）0〜22KHzのスペクトルが1秒あたり44100回更新されます。 。

これはスマートフォンでは起こらないようです。問題は、可能な限り多くの品質を維持しながら、Galaxy Nexusで扱いやすくするために、計算のどのパラメーターを減らす必要があるかわからないということです。最終的には、より感度の高い外部マイクを使用したいと思います。

FFTを取得する間にウィンドウを複数のサンプルで移動する必要があると思いますが、どの時点で、これが小さいウィンドウでFFTを実行するよりも、精度/エイリアシング/その他に悪影響を与えるかどうかはわかりません。私が見落としているオプション。

libgdxから使用しているネイティブに実装されたKissFFTを使用すると、44100サンプルあたり30〜42の44100要素FFTを実行でき、それでも応答性があります（つまり、AudioRecord.readを実行しているスレッドからバッファーがいっぱいになります） （）は、fftを実行しているスレッドがそれを排出できるよりも速くいっぱいになりません）。

だから私の質問は：

  1. 私が現在得ているパフォーマンスは、私が得ようとしている最高のものでしょうか？それとも、はるかに速い速度が可能であるため、私は何か愚かであるに違いないように思われますか？
  2. これに対する私のアプローチは少なくとも根本的に正しいですか、それとも私は完全に間違った木を吠えていますか？

質問に答えるのに役立つコードがあれば喜んで表示しますが、たくさんあるので、すべてを投稿するのではなく、選択的に表示することにしました。

4

1 に答える 1

2

私が見落としている3番目のオプションがある場合

はい：両方を同時に実行すると、FFTサイズが小さくなり、ステップサイズが大きくなります。コメントの中で、「口で嗅ぐ/噛む」を検出したいという指摘がありました。したがって、あなたがやりたいことは、音声認識の典型的なタスクに似ています。そこでは、通常、10msのステップで特徴ベクトルを抽出し（つまり、441サンプルごとにFs = 44.1kHz）、変換する信号ウィンドウはステップサイズの約2倍のサイズであるため、20msは2 ^XFFTになります。 1024サンプルのサイズ（2の累乗であるFFTサイズを選択するようにしてください。これは、より高速です）。

ウィンドウサイズを大きくしたり、ステップサイズを小さくしたりすると、データは増加しますが、主に冗長性が追加されます。

追加のヒント：

  • @SztupYは、FFTの前に、通常はハミングワンダウを使用して信号を「ウィンドウ処理」する必要があることを正しく指摘しました。（ただし、これは「フィルタリング」ではありません。結果を累積せずに、各サンプル値に対応するウィンドウ値を乗算するだけです）。

  • 生のFFT出力は、「口でのスニッフィング/咀嚼」の認識にはほとんど適していません。従来の認識機能は、MFCCとそのデルタのシーケンスを処理するHMMまたはANNで構成されています。

私が現在得ているパフォーマンスは、私が得ようとしている最高のものでしょうか？それとも、はるかに速い速度が可能であるため、私は何か愚かであるに違いないように思われますか？

最高に近いですが、非常に冗長なデータを推定するためにすべてのCPUパワーを浪費しており、レコグナイザーにCPUパワーを残していません。

これに対する私のアプローチは少なくとも根本的に正しいですか、それとも私は完全に間違った木を吠えていますか？

私の答えを検討した後、あなたはあなたのアプローチを再考するかもしれません。

于 2014-01-30T06:28:36.577 に答える