オーディオのサンプリング

動画

サンプルレート: 意見が分かれる理由

動画

「浮動する」のか - 浮動小数点オーディオの栄光と恥

Android におけるオーディオのサンプリング

Android 5.0(Lollipop)より、オーディオ リサンプラーは、Kaiser windowed-sinc 関数から派生した FIR フィルタを完全にベースとするようになりました。 Kaiser windowed-sinc 関数には、次のような特性があります。

  • 設計パラメータ(阻止域リップル、遷移帯域幅、遮断周波数、フィルタ長)の計算が簡単になる。
  • 総合エネルギーと比べ、阻止域エネルギーの削減にほぼ最適である。
P.P. Vaidyanathan 著『マルチレート システムとフィルタバンク』の 50 ページで、Kaiser 窓とその最適性、および Kaiser 窓と偏長回転楕円体窓の関係について扱っています。

設計パラメータは、内部の品質測定と、希望のサンプリング比に基づいて自動的に演算されます。 設計パラメータに基づいて、windowed-sinc フィルタが生成されます。 音楽に使用する場合、44.1~48 kHz のリサンプラー(逆の場合も同様)は、任意周波数変換よりも高品質で生成されます。

オーディオ リサンプラーは、この品質を達成するために、さらに高い品質と速度を実現します。 ただし、リサンプラーは阻止域リップルとエイリアシング高調波ノイズを少々発生させることがあり、遷移帯域幅に高周波低損失が生じる可能性があるため、必要以上に使用することは避けてください。

サンプリングとリサンプリングのベスト プラクティス

このセクションでは、サンプリング レートに関する問題を回避するためのベスト プラクティスをいくつか紹介します。

端末に合ったサンプリング レートを選択する

一般的には、端末に合ったサンプリング レートを選択するのが最適です(通常は 44.1 kHz~48 kHz)。 リサンプラーはファイルの再生に使用する必要があるため、48 kHz よりも大きいサンプル レートを使用すると、一般的に品質が低下します。

単純なリサンプリング比を使用する(固定ポリフェーズと補間ポリフェーズ)

リサンプラーは、以下のいずれか 1 つのモードで動作します。

  • 固定ポリフェーズ モード。各ポリフェーズのフィルタ係数が事前に演算されます。
  • 補間ポリフェーズ モード。各ポリフェーズのフィルタ係数が、最も近い 2 つの演算済みポリフェーズから補間される必要があります。

リサンプラーは、入力レートと出力レートの比率 L/M(最大公約数を除外)で M が 256 未満の場合、固定ポリフェーズ モードで最速になります (たとえば、44,100 から 48,000 の変換で、L = 147、M = 160 の場合)。

固定ポリフェーズ モードでは、サンプリング レートはロックされ、変更されません。補間ポリフェーズ モードでは、サンプリング レートはおおよそのものになります。 48 kHz の端末で再生するとき、サンプリング レートのドリフトは通常、数時間で 1 つのサンプルになります。 近似誤差は、内部の水晶振動子、熱ドリフト、またはジッター(通常は数十 ppm)による周波数誤差よりもずっと少ないため、基本的に問題になりません。

AudioTrack で他のサンプリング レートとサンプリング比が使用可能な場合でも、48 kHz の端末で再生する場合は 24 kHz(1:2)や 32 kHz(2:3)などの単純な比率のサンプリング レートを選択するようにしてください。

サンプル レートを変更する際、ダウンサンプリングではなくアップサンプリングを使用する

サンプリング レートは即時変更することができます。このような変更の粒度は、サンプルごとではなく、内部バッファリング(通常は数百個のサンプル)に基づきます。 これは、エフェクトに使用することができます。

ダウンサンプリングする際、サンプリング レートを動的に変更しないようにします。 オーディオ トラックが作成された後にサンプルレートを変更すると、元のレートから約 5~10% 変更されることにより、ダウンサンプリングの際にフィルタの再演算が行われる場合があります(エイリアシングを適切に抑制するため)。 これにより、演算リソースが消費される可能性があります。また、フィルタがリアルタイムに交換される場合、クリック雑音が発生する場合があります。

ダウンサンプリングを 6:1 未満に制限する

ダウンサンプリングは通常、ハードウェア端末の要件によってトリガーされます。サンプルレート コンバーターをダウンサンプリングに使用する場合、エイリアシングを適切に抑制するためにダウンサンプリングの比率を 6:1 未満に制限するようにしてください(たとえば、48,000 対 8,000 以上のダウンサンプリングは避けるなど)。 フィルタ長は、ダウンサンプリング比に一致するよう調整されますが、フィルタ長が過度に増加するのを避けるために、ダウンサンプリング比が高い場合は犠牲にする遷移帯域幅が多くなります。 アップサンプリングには、エイリアシングに関する同様の問題はありません。 オーディオ パイプラインの一部によって、2:1 より大きいダウンサンプリングが妨害される場合があることに注意してください。

レイテンシを懸念する場合は、リサンプリングしない

リサンプリングを実行すると、トラックが FastMixer パスに配置されなくなるので、通常の Mixer パスに大きなバッファが追加され、非常に大きなレイテンシが発生することになります。 さらに、リサンプラーのフィルタ長から暗黙的なレイテンシが発生しますが、基本的にこれは約 1 ミリ秒未満で、通常の Mixer パスの追加のバッファ(一般的に 20 ミリ秒)より大きいことはありません。

浮動小数点オーディオを使用する

オーディオ データを表すのに浮動小数点数を使用すると、高パフォーマンスのオーディオ アプリの音質を大幅に向上することが可能です。 浮動小数点を使用すると以下の利点があります。

  • ダイナミック レンジが広くなる。
  • ダイナミック レンジ全体で精度が一貫する。
  • ヘッドルームが増えるので、中間計算中のクリッピングと過渡応答を回避できる。

浮動小数点は音質を向上することが可能ですが、以下のような欠点もあります。

  • 浮動小数点数は消費メモリが多い。
  • 浮動小数点演算には予期しない性質がある(たとえば、加算が結合的ではないなど)。
  • 浮動小数点計算は、丸めアルゴリズムや数値的に不安定なアルゴリズムが原因で、ときに演算精度を失うことがある。
  • 正確で再現可能な結果を得るためには、浮動小数点を深く理解して使用する必要がある。

浮動小数点は以前、使用できなかったり、動作が遅かったりすることでよく知られていましたが、今でもローエンドのプロセッサや埋め込みのプロセッサには同じことが言えます。 ですが、最新のモバイル端末には、整数と類似した(場合によっては整数よりも速い)パフォーマンスを持つハードウェア浮動小数点が使われています。 最新の CPU は SIMD(Single Instruction/Multiple Data)もサポートするので、パフォーマンスをさらに向上することができます。

浮動小数点オーディオのベスト プラクティス

以下に、浮動小数点計算で生じる問題を回避するためのベスト プラクティスを紹介します。

  • フィルタ係数の演算など、頻度の低い計算には倍精度浮動小数点数を使用する。
  • 演算の順序に配慮する。
  • 中間値に明示的な変数を宣言する。
  • かっこをたくさん使用する。
  • NaN または infinity の結果を受け取った場合、その原因となる場所を探すためにバイナリ検索を使用する。

浮動小数点オーディオについては、AudioFormat.ENCODING_PCM_FLOAT をエンコーディングするオーディオ形式が、AudioTrack データ形式を指定するために ENCODING_PCM_16_BIT または ENCODING_PCM_8_BIT に同様に使用されます。 対応するオーバーロードされたメソッド AudioTrack.write() は、データを提供するために浮動小数配列を取り込みます。

   public int write(float[] audioData,
        int offsetInFloats,
        int sizeInFloats,
        int writeMode)

詳細情報

このセクションでは、サンプリングと浮動小数点に関する追加リソースをいくつか紹介します。

サンプリング

サンプルレート

リサンプリング

高ビット深度と高 kHz に関する議論

浮動小数点

以下の Wikipedia のページは、浮動小数点オーディオについて理解するのに役立ちます。

コンピュータ システム設計者に直接影響する浮動小数点の側面について、以下の記事で関連情報が提供されています。