DAWを使用したレコーディング・楽曲制作を行う上で避けて通れないレイテンシー。できれば最小限に留めたいところですが、DAWを使用している以上、残念ながら完全にレイテンシーの影響を取り払うことは不可能です。
以前の記事でレイテンシーの基本的な対策についてご紹介してきましたが、今回はもう少し突っ込んだ、ProToolsを使用する際にレイテンシーの影響を抑える方法についてご紹介して行きます。
本ページでは、[プレイバックエンジン]の設定とレイテンシーの関係をわかりやすくするために、設定を変更しながら簡単な検証を行い波形を比較することで、視覚的にもレイテンシーの影響を確認しながら進めていきます。
以前ご紹介したレイテンシーに関する記事は以下になります。
本ページではレイテンシーに関する基本的なところを飛ばして解説させていただくので、上記記事を先にご覧になることをオススメいたします。
目次
設定別レイテンシー検証
まずは、プレイバックエンジンの設定状況がどの程度レイテンシーに影響を及ぼすのか、簡単に検証を行っていきます。
使用しているオーディオインターフェースやPC/Macなどの環境によっても誤差が生じる場合も大いに考えられますが、参考までに考えて頂ければと思います。
検証機スペック
検証に使用したマシンは15インチMacBook Proの2015年モデルです。2.8GHz4コア8スレッドのCPUとDDR3メモリを16GB積んでいます。
Macに接続されているデバイスは、オーディオインターフェース・Universal Audio apollo 8pと外部のHDMIディスプレイ1台、録音用HDD、iLokと標準的なものです。
実際には、画像のキャプチャーソフトも並走していますが、以下の検証において各項目で同様のアプリケーション稼働状況であるため、影響は無視できると考えます。
レイテンシーの検証方法
BPM=120のクリックをオーディオ化し、Sendスロット経由でapollo 8pからアナログ出力を行い、その出力ケーブルを再びapollo 8pに入力し録音していきます。今回はより実戦的に、CUE送りをする場合を想定しています。
オプションの[低レイテンシーモニタリング]はメイン出力のみに有効なので、このようにメイン出力以外からCUE送りをする場合には効果的に作用しません。Sendアサインからの出力も止まってしまいます。
この検証により、元のオーディオデータと、録音されたオーディオデータを見比べて波形のスタート位置の差が[SendからのD/A→アナログ出力→アナログ入力からのA/D→録音データ]の部分のレイテンシーになると考えられます。
また、検証結果をブレさせる要素を極力排除するために、一切のプラグインを使用していない状態で検証を行っています。
実際には録音と、録音データの再生の間にもレイテンシーがあるので体感上のレイテンシーはこの限りではないのですが、それについては後述します。
本記事ではサンプリングレートは96kHz、ビット深度は24bitの環境で検証を行います。また、ディスクプレイバックの値は標準に固定し、その他の設定を比較していきます。
検証方法まとめ
- オーディオ化したクリックをSendアサインし、オーディオインターフェースからアナログ出力
- オーディオインターフェースのアナログ出力とアナログライン入力をケーブルで接続
- 別のオーディオトラックの入力に2.のアナログライン入力をアサイン
- 各種設定でレコーディングを行い、波形のズレ(レイテンシー)を比較する
レイテンシーの検証結果
概ね想定通りのデータが取れました。
まとめた画像ではわかりづらいので、以下設定ごとに見て行きます。
バッファサイズ=1024サンプル
標準的なプレイバックエンジン設定のバッファサイズ=1024サンプル設定での検証結果です。
MIX時の基本的な設定で、多くの場合に初期設定になっている1024サンプル設定ですが、レコーディング時には少々大きすぎる設定に感じます。
以下、検証結果の波形です。
以下の検証結果でも共通ですが、上が元波形、下が録音データの波形です。
視覚的にも遅れが出ているのがわかると思います。
ちなみに、波形の頭をタブトゥトランジェントで捕まえると、その差は1025サンプルでした。誤差もあるとは思いますが、概ねプレイバックエンジン設定値そのままのレイテンシーが発生しています。
それでは、96kHz設定時の1024サンプルとはどれ位の時間なのでしょう。
まず、96kHz=96000Hzです。また、サンプリングレート96kHzとは、1秒間に96000回サンプリングを行っていることを示しているので、1サンプルあたり1/96000秒と言うことができます。つまり、1024サンプルは1024/96000秒=0.01066666…秒となり、おおよそ11ms程度のレイテンシーが出ていることになります。
人間が2つの音源を知覚可能な時間差は15ms〜20msと言われています。30msともなると確実に2つの音として聞こえます。
1024サンプル設定では11msのレイテンシーが出ている状態で、この数値だけを見るとギリギリ知覚不可能なズレのハズですが、実際には他の部分でもレイテンシーが発生しているため明確に2つの音として聞こえてきます。
バッファサイズ=512サンプル
続いてはバッファサイズ=512サンプル設定時の検証結果です。
縮尺は1024サンプル時のものと同尺です。
1024サンプル設定時と比べて、レイテンシーが抑えられているのがわかると思います。参考までに波形の頭の距離を測ったところ、512サンプルぴったりでした。
512サンプルは96kHz環境下で、およそ5msのレイテンシーとなって現れます。
バッファサイズ=256サンプル
さらに半分のバッファサイズ=256サンプルでは、以下のようなサンプルが取れました。
512サンプル設定時よりもさらに半分のレイテンシーに抑えられています。実測でも波形のスタート位置の差は256サンプルでした。
256サンプルは96kHz時に2.5ms程度のレイテンシーになって現れます。
どんな設定でもそうですが、発音タイミングの差は位相差にもなって現れます。同じ音を重ねている状態で位相がズレていると、帯域によって聞こえづらくなる場合があります。
実際に今回の検証結果を元波形と合わせてヘッドホンでモニタリングしてみたのですが、256サンプルズレているクリックはタイミングの問題よりも位相干渉が原因で聞きづらく感じました。
再生/録音中はエラーを無視=OFF
さて、今度はバッファサイズ設定ではなく、ホストエンジン設定について比較して行きます。
と言っても、ダイナミックプラグインプロセッシングはプラグインのCPU負荷やメモリリソースを設定する項目なので、今回の検証には影響がありません。
[再生/録音中はエラーを無視]の設定項目は、デフォルトでONになっている上、(クリックやポップの原因になる可能性あり)とか恐ろしいことが書かれているのでONのまま使用している方がほとんどだと思います。
話はそれますが、万が一、録音中にエラーが発生した場合、アプリケーション側で無視されて気づかないよりもクリックノイズやポップノイズとして表面化したり、再生が止まってくれる方がよっぽど安心出来るのではないでしょうか。そう思って、私はかなり以前からこのチェックをOFFで使用していました。
さて、512サンプル設定で、チェックボックスがOFFの状態での検証結果が以下になります。
上記の画像を見ていただいてもおわかりかと思いますが、ほとんどズレが生じていません。波形の開始地点の差はなんと1サンプルでした。さらに、バッファサイズを1024などに変更しても録音されたオーディオデータの波形の位置は変わりませんでした。
Avidの公開している情報をいろいろ見てみたのですが、この設定項目に関してはあまり詳しく解説しているものを発見できなかったため、以下推察です。
エラーを無視しない場合、1サンプルの誤差の範疇でしか録音データにレイテンシーが現れなかったことから、ProToolsがエラーチェックをするタイミングはオーディオデータが出力される前、または入力信号がオーディオデータ化される前、あるいはその両方と考えられます。
そして、D/A段あるいはA/D段でのエラーチェックをする際にもH/W バッファサイズを参照して、そのバッファ中にチェックを行っていることが推察されます。
検証結果まとめ
それでは、今一度検証冒頭の画像に戻って解説していきます。
この画像は上から以下の順で波形を並べたものです。
- 元のクリックの波形
- バッファサイズ=512 エラーを無視=OFFの波形
- バッファサイズ=256の波形 エラーを無視=ONの波形
- バッファサイズ=512の波形 エラーを無視=ONの波形
- バッファサイズ=1024の波形 エラーを無視=ONの波形
また、[録音/再生中はエラーを無視する]がONのデータは、その追加項目の[I/Oレイテンシを最小限にする]の項目も合わせてONにしてあります。
今回行った検証では、検証の条件下で録音されるデータのレイテンシーは、まず、[録音/再生中はエラーを無視する]の設定状況により変化する、ということがわかりました。
今回の検証で判明したことは、[録音/再生中はエラーを無視する]のチェックがOFFの場合には、再生/録音されるデータにはレイテンシーがほぼ生じない点が一点、[録音/再生中はエラーを無視する]のチェックがONの場合には、H/Wバッファサイズの設定状況により、再生/録音されるデータに設定値分のレイテンシーが発生する点がもう一点です。
それでは、[録音/再生中はエラーを無視する]がOFFに設定されていればモニタリングレイテンシーは発生しないのか、と言うとそうではありません。
あくまでも上記のレイテンシーは、今回の検証で録音されたデータのレイテンシーで、モニタリングレイテンシーは別に発生しています。録音用トラックのインプットモニターとレコード待機状態の元トラックを合わせて聴いた際にレイテンシーの影響が出ていることは確認できています。
残念ながら、その状態を波形で表すことが1台のDAWでは不可能であるため今回は検証できていないのですが、聴感上では、[録音/再生中はエラーを無視する]をOFFにすることでモニタリングレイテンシーも軽減しています。
モニタリングレイテンシーに関しては、上記設定だけでは実使用上不十分なので、以前の記事通り、ダイレクトモニタリングやDSPミキサー付きのオーディオインターフェースを使用したり、H/Wバッファサイズを下げるなどの対策が不可欠になります。
当然ですが、バッファサイズの設定が小さければ小さいほどこのモニタリングレイテンシーの影響は少なくなります。
バッファサイズの影響
実戦的な対策として、[録音/再生中はエラーを無視する]をOFFにすることと、バッファサイズを小さくすることが有効なことが検証で判明しました。
バッファサイズを下げることでレイテンシーが小さくなる、というメリットがあるのですが、逆にデメリットも発生します。バッファサイズが小さい状態ではCPUの処理に負荷が多くかかるようになります。
そのため、多くのプラグインを使用するMIXの段階ではこのバッファサイズを大きくし、プラグインを使用する分のCPUパワーを用意してやる必要があります。
それでは、ここからは第二の軽い検証として、バッファサイズを下げた場合にレコーディングにどれほどの影響が生じるのか、を確認して行きたいと思います。
検証方法・結果
H/Wバッファサイズ=128サンプル設定で、オーディオ化したホワイトノイズをSendアサインからアナログ出力し、24トラックのオーディオトラックに同時にレコーディングした際のCPU負荷を確認する、という方法です。見辛いですが、上記画像の状態ですね。
この状態で5分間24トラック分のホワイトノイズを録音した際のCPUメーターを監視してみました。
システム使用状況のCPUメーターが20%〜60%をふらつくなど、終始不安定な動きを見せていましたが、録音が止まることはありませんでした。
レコーディングが長時間に渡った際や、それによりマシンの温度が上昇した場合にはエラーが発生することも考えられますが、検証用マシンのスペックにおいて96kHz/24bit環境、24トラックのレコーディングをバッファサイズ=128サンプルで5分間行ってもトラブルは発生しませんでした。
以下、実際のCUEの使用状況を考えて、出力数を増やしてみました。
先ほどホワイトノイズを録音した中から14オーディオトラックを残し、出力をそれぞれアナログ6出力・ADAT8出力にSendアサインしました。
入力用のオーディオトラックも14トラック作成し、アナログ6入力・ADAT8入力の同時録音を5分間行いましたが、CPUの動作状況には大差ありませんでした。
CPUメーターについては、バッファサイズが大きい時の方が振れが少ない印象ですが、14出力・14入力の同時録音も可能でした。
検証まとめ
せっかく検証をしたんだから、止まって欲しくていろいろやって見たのですが、128サンプル設定では止まりませんでした。Macのファンがかなり高速回転をしていたので、CPUに負荷がかかっていることは間違いないのですが…。
こちらの検証でわかったことは、レコーディング時にモニタリングレイテンシーの影響を抑えるためにはバッファサイズを小さくするのがよい、というごく当たり前の点と、そこそこのマシンスペックがあればバッファサイズを小さく設定しても多くのトラックを同時録音することが可能、という点です。
ちなみに、私はバッファサイズの設定をレコーディング時には128サンプル、MIX時には1024サンプルと使い分けています。実使用を考えると、Native環境では16トラックほどの同時レコーディングが現実的なところですが、128サンプル設定で問題は生じていません。
実戦的なレイテンシー対策
今回の総まとめとして、表題=ProToolsでの実戦的なレイテンシー対策について考えてみましょう。
まず、[録音/再生中はエラーを無視する]の設定項目については、特に問題がなければOFFにするのが望ましいです。Avidのフォーラムでも安定性の面で同様の議題が上がっていたのですが、ユーザーはOFFで問題ない、サポートはONを推奨と、結局解決はしていない模様です。
実際に経験がないのですが、万が一のエラーの際の挙動としてエラーを無視されてしまうのも困りものです。停止するにせよ、録音を続行するにせよ該当部分に関しては録音し直すことになるのは間違いないと思うところです。
当記事をご覧の方には当たり前のことで恐縮ですが、バッファサイズを可能な限り小さく設定することでレイテンシーを抑えることが可能です。お使いのマシンスペックを考えて小さめのサイズを設定していくのが好ましいです。
また、レコーディング中に録音が停止しないように、バッファサイズ設定後にある程度の負荷をかけて試験運転をすることが望ましいです。レコーディングスタジオに機材を持ち込んでレコーディングを行う場合、時間幾らで料金が発生し続けます。スムースな進行と経済的な面の両面から事前準備をしっかりと行うようにしましょう。
今回ご紹介したのは、DAWでのバッファに伴うレイテンシーに関しての対策になります。オーディオインターフェースでのA/D、D/Aに関わるレイテンシーや伝送系でのレイテンシーがあるため、DAW上でのレイテンシーを0に近づけてもレイテンシー自体は必ず発生します。
レイテンシーは信号経路の遅延の積み重ねになるため、各部で可能な限りレイテンシーを抑える対策を講じることで、結果として最終的なレイテンシーを抑えることが可能になります。
3行でまとめると
- [録音/再生中はエラーを無視する]をOFFに！
- レコーディング時にはバッファサイズを小さく！
- 必ず試験運転を行うこと！
最後に
今回はProToolsを使用する上で実戦的なレイテンシー対策を考えてみました。
実は今回検証を行うきっかけとなったのは、「DAWをProToolsに乗り換えてからいままで発生しなかったレイテンシーが発生するようになった」という相談があったからなのです。
参考までに他のDAWの設定項目をいくつか確認したところ、録音中のエラーチェックに関する設定項目がないDAWが多く、ProTools特有の設定という部分だったのが一因となったようです。
他社のDAWに比べてProToolsは、スタジオ標準のProTools Ultimate(旧HD/HDX)が基準になっているため、どうしてもNative版は機能制限版といった位置づけになりがちです。
そのため、Native環境のProTools(旧LE)を使っていてレイテンシーが気になるならHD Nativeを使用すれば良い、と言われてしまいそうですが、なかなかに厳しいところですよね。
当ブログのFacebookページです。
少しでも皆様のお役に立てたら「いいね！」していただけると歓喜します。
とても参考になる素晴らしい記事でした。
ありがとうございました。