デジタル信号処理の品質 / パフォーマンス【DSP】

ソフトウェア（プラグイン）や、DSP 等のプロセッサーを搭載したハードウェア（製品）では、アナログ信号をデジタルに変換して処理していますが、その処理の品質やパフォーマンスについて説明します。

 DSP とは

デジタル信号処理は英語だと Digital Signal Processing となり、略して DSP と呼ばれます。
少しややこしいのですが、Digital Signal Processing に特化したプロセッサーは Digital Signal Processor なので、こちらも DSP と表現されます。
※ 本記事では混乱を避けるため Processing の方は （デジタル）信号処理、Processor の方を DSP と記載します。

ハードウェアの場合は信号処理専用の DSP を搭載している場合が多いですが、（シムテム用の）マイコン / SoC の CPU で担ってしまう場合もあります。

ソフトウェアの場合は PC の CPU を使います。プロセッサーの処理能力や使えるメモリの制約的に、ハードウェアの DSP で動く処理が PC の CPU では動かないということは無いと思います。

ただ、CPU は信号処理専用ではないためバッファーを大きく取る必要があり、レイテンシー（リアルタイム性）については DSP を搭載したハードウェアよりも劣ります。

デジタル信号処理による音の品質

デジタルにおける品質とは、サンプリング周波数とビット深度です。

ビット深度の影響

ビット深度については、内部処理は浮動小数点（floating-point）で、wav フォーマットの 16/24/32 bit 固定小数点よりも圧倒的に精度が高いので、あまり気にする必要はありません。プラグインの場合は基本は 32 bit float で、64 bit float にも対応している製品もあります。

ここでもややこしいのですが、ソフトウェアや OS の 32 bit / 64 bit 版と、信号のビット深度は同じ bit という単位ですがそれぞれ別物です。
例えば、64 bit 版 OS の 32 bit 版 DAW で 32 bit 版のプラグインを 64 bit float で動作させるという事もあり得ます。

サンプリング周波数の影響

サンプリング周波数については、何 Hz で内部処理を動作させるかで大きく品質が異なってきます。サンプリング周波数の半分の周波数までしか扱えない（ナイキスト定理）というのはご存知の方も多いと思いますが、ナイキスト周波数を超えた成分は、消滅するのではなく誤認識されます。

車の映像でタイヤが逆回転しているのを見たことがあるかと思いますが、あれは実際の回転速度がフレームレート（映像のサンプリング周波数）のナイキスト周波数を超えているので、全然関係のない回転が見えているという現象です。

その音声バージョンが起こりますので、全然関係ない音程の音（正確には、ナイキスト周波数で折り返した音＝エイリアス）が鳴ります。折り返しが奇数回（1 回）だと変化が逆になるので、ギターのチョーキングで音程が下がる音が聞こえたりします。

これを防ぐためには、ナイキスト周波数以上の成分をカットするか、オーバーサンプリングで動作させる周波数を上げてエイリアスが可聴域に入らないようにするといった対応が必要です。

また、ナイキスト周波数はあくまで正しく認識できる限界値なので、ナイキスト周波数に近づくと EQ やアナログ回路のモデリングなどで使用するデジタルフィルターの精度は徐々に怪しくなっていきます。

上の図は、サンプリング周波数 48 kHz と 192 kHz での、カットオフ周波数 4 kHz の LPF の周波数特性です。 青色がアナログ（理論値）で、赤色がよく使われる双一次変換によるデジタルフィルター、黄色は前進 / 後退オイラーで変換したデジタルフィルターです。

192 kHz と比べて、48 kHz だと高い周波数の特性が青色の理論値からズレてしまっているのが分かります。このズレの影響を考慮して設計しないとサンプリング周波数によって音が変化してしまいます。

デジタルフィルターの設計（双一次変換 / オイラー法）については、↓ のサイトにある近似の図が分かりやすいです（近似の横幅がサンプリング周波数です）。

デジタル信号処理のパフォーマンス（処理負荷）

デジタル信号処理に限りませんが、同じ結果を得るためのプロセスは 1 つではなく、効率良く処理できればパフォーマンスは上がりますし、無駄な処理が多ければ下がります。

コンパイラによる最適化

コンパイラは人間が書いたプログラムを CPU の命令などに変換（コンパイル）する際に、高速に処理できるように色々と最適化（無駄な処理を削除したり、効率的な処理に置き換える）をしてくれます。

ただ、コンパイラの最適化は万能ではないので、パフォーマンスを追求するのであれば、人間には分かりづらい（2 進数の処理で考えるなど）けど速いプログラムを書くスキルと試行錯誤（実際に動かして速い方を選ぶ）が必須になります。

SIMD の使用

1+2, 3+4, 5+6, 7+8 の 4つの計算をする場合、普通にプログラミングすると足し算を 4 回繰り返す処理になりますが、CPU には複数の足し算（演算）を一気に処理する命令（SIMD）が搭載されていて、上手く使えばパフォーマンスを一気に上げる事ができます。

先程の 4 つの計算の場合、
　01030507 + 02040608 = 03071115
という SIMD 命令を使うようにプログラミングして、結果を 03|07|11|15 と分割すれば 4 つの計算結果を効率的に得られます。

（SIMD で書かれていないプログラムを）コンパイラが最適化で SIMD 化してくれる事はほとんど期待できず、SIMD を使ったパフォーマンスの向上はプログラマーの頑張りに委ねられているのが現状です。

プラグインにおけるパフォーマンスの改善

ハードウェアの場合はリソース（DSP）の制約があるので、軽くした分だけ別の処理を追加できるといったメリットがありますが、リソース（CPU）を分け合って使用するプラグインでは、パフォーマンスの改善は開発する側にとってはあまりメリットがありません。

まず、音は変わらない（改善されない）のに時間だけが浪費されます。加えて、多くの場合はバグのリスクが高まりますし、読みづらいプログラムになればメンテナンス性も悪くなります。
また、処理の中身（複雑さ）が想像できない＆音の好き嫌いで判断される製品の場合は特に、「動作が軽い分、処理もショボいだろうから音もショボいだろう」という負のバイアスがかかってしまうリスクもあります。

私が開発したアンプシミュレーター Vanish では、私自身がプログラムの高速化に興味があるという事もあって、パフォーマンス改善にはかなりの時間を割いています。仕事だとなかなかこうはいきませんので、こういった点は個人開発の強みだと感じています。

必要十分な品質で処理されているかの確認方法

歪み系のエフェクトでは、内部処理のサンプリング周波数が低いと、割とすぐに可聴域にエイリアスが入ってきてしまいます。
エイリアスが発生しているかどうかは、サイン波を周波数を変えながら入力すると簡単に分かります。

この記事で比較したアンプシミュレータープラグインからいくつか抜粋して、DAW のサンプリング周波数を 48 kHz にして試した結果です ↓

エイリアスが少ない順に、
　Guiter Rig ＞ Vanish ＞ BIAS FX ＞ AmpliTube
です（補足ですが、AmpliTube についてはハイゲインモデルはもっとちゃんと対策されています）。

Vanish は OVERSAMPLING = 384 kHz の設定で動作させていて、リサンプリングの時以外はエイリアス防止の LPF は入れていません。
Guitar Rig も（処理負荷の変化から推測して）384 kHz で処理しているのは間違いなさそうですが、Vanish よりもエイリアスが少ないので、オーバーサンプリング以外にもエイリアス対策を施しているのかも知れません。

ちなみに、サイン波でエイリアスが出たとしてもギターの音なら問題ない場合も多いです。ですので、エイリアス注意なエフェクトなのかどうかの判断基準として試してみていただければと思います。

プレキシのアンプシミュレーターを無料配布しています ↓

ピッチシフター / ハーモナイザープラグインを無料配布しています ↓