Pro Tools 遅延補正 虎の巻

こんにちは🙋‍♂️

Pro Toolsの遅延補正に関して、

絶対安心これ見れば全て理解🔅

という資料が欲しいので作ることにしました。


さて、

そもそも昔のPro Toolsに遅延補正機能はついてませんでした。

遅延補正機能が搭載されたverが出たころは
「待ってましたこの機能!」
と、みんないろいろ試して検証を行ったと思うので、
そこの過渡期を経験しているエンジニアの多くは仕組みを理解していると思います。
しかし遅延補正ネイティブの世代はわりと勘違いしている人が多いようです。
あと自分自身も人に
「こういうときはこうで、こういうときはこうだよ!」
って説明すればするほど自信がなくなってきたので🤣🤣🤣
実際に試して検証しましょう!


検証方法

まず、遅延補正はさまざまな要因で変化するので、
Pro Toolsとは完全にアイソレートされたもので検証するべきです🧐

ということでこいつ 👇

画像1

ZOOM F6にPro Toolsのアウトプットを録音して検証します。便利なポータブルレコーダーです。

以下のような回線図です。

画像2

ではやっていきましょう‼️

画像3

画像4

準備OK🙆‍♂️

※今回の実験はHDxで48kHzで行います



A1. 録音中

一番シンプルな状況です。

Pro Toolsはただのテープレコーダーとして機能している場合、遅延補正はon

画像5

AとBはパラったものを入れているので、当然同じものが録音されます。

いまのところ、このPro Toolsの画面には何の意味もありません。

なぜならPro Toolsが録音している最中にどういったアウトプットをしているかが重要なので、

画像6

PTが回ってる最中にこっちに録音された中身が重要👆

さてZOOMに録音されたものを見てみましょう

画像7

こちらになります。

画像8

こういうことです。

さて拡大🔍

画像9

DirectとABがズレてますね。
(今の段階ではクリックの波形は関係ないので無視してください)

DirectはHAから直行してるので、最速と捉えます🏃🏻
AとBはPro Toolsに録音中のトラックがアウトした音です。
Pro Toolsにinしてoutしてるぶん遅れてますね。あたりまえです。
その遅延は

81 sample

でした。


さて、これを基本として、考えられる疑問を潰していきましょう。



A2. inputの状態の時はどうなってるの?

シンプルにこうなっている時

画像15

ZOOMに録音します。

ZOOMの中身を見ます

画像16

PTは走ってないので、もちろんクリックはいません。

拡大🔎

画像17

当然ズレていて、このズレは

81 sample

録音している最中と同じですね。



A3. じゃあRec Ready + inputの時は?

いや、変わらないに決まってるじゃん😡

と思いますが、もうやろやろ、全部やろ😂

画像18

この状態。

結果

画像19

81 sample

あたりまえ!



A4. じゃあじゃあRec Readyだけ入ってる時は!?

えええー、こいつうざ〰笑😩

と思ってもこういう検証はこのくらい偏執的なほうがよい。

画像20

この状態

結果

画像21

81 sampleじゃ!!!

あたりまえ👍👍👍👍



バッファサイズ変えてみよう

では次、この81 sampleを揺らしてみたいな。
バッファサイズとかで変わるんでしょ〰

さっきまでは1024 sampleでした。

画像22

これを128 sampleに変更してみます!

そして1と同じことをします。

結果はこちら

画像23

これ

81 sample

そうです!変わりません!

HDxでHD IOで48kHzの場合において、音が入ってからモニターできるまでの遅延はバッファをどうしようと81 sample

ということです。
バッファが結果に影響を与えないことが分かったので、1024 sampleに戻します。



ここまでを踏まえて

ここまでの実験によって、
Pro ToolsのRec Trackにおいては、いかなるステータスであってもin / outの分の遅延が起きる。(81 sample)
ということがわかりますね。

エンジニア的に言うと、

音作りから、
いざ録音ファーストテイク
の間、録り音は一切変わらない。

という確認ができました。
そりゃそうですね。そうでないと困る。

また、この状況をプレイヤーの立場で理解しようとすると、

クリックを聴いて、
ベストなタイミングで演奏を行ったが、
自分の音は実際には81 sample遅れて再生されてしまっている。
(コントロールルームでもキューボックスでも81 sample遅れてモニターされている)

ということになります。
わかりますか?
重要ですこれ。



A6. 録音したものを再生する

さてさて、それじゃあさきほど1でPro Toolsに録ったものをRec Readyを外して、再生したものをZOOMに録ってみましょう。

画像24

こういうことね。
ここで今まで一緒に録ってたクリックの音が活きてきます。

まずPTに録音されていた状態

画像33

ここは150 sampleでした。

さて、それを再生してZOOMに録音します。

画像11

ZOOMに録音されたデータです。
PTを再生しただけなのでDirectはありません。

クリックとABの音のズレに変化が起きるかを見ましょう。

画像13

150sample

でした。

そりゃそうですね。

そしてA1の時、
PTを録音中に同時に録音していたZOOMを見ます。

画像12

の長さは

231sample


その差 81 sample

変わるのかよ!笑

そう、変わるのです。
つまり

録音トラックにおいて、録音中に鳴っている音とその後の再生したときとでは81 sample 前にズレている。

ということになります😲

これ超重要です。



B. 原因はI/Oセットアップのあのほら、、あれなんじゃないの……?


こういう人めっちゃ多そう笑

あれです、あれ、

画像10

さて、今までの実験ではここの設定をinもoutもオンの状態で行っていました。

それではまずはinput側をオフって検証してみます。



B1. 録音中

A1と同じことをI/O setupの "Compensate for input delays after record pass" をオフにしてやってみます。

こちらがZOOMの結果です。

画像24

この数

81 sample

うん、もうなにがなんでも変わらないね。




B6. 録音したものを再生する

B1の際にPTに録音されたものを再生してZOOMに録ります。

さてB1では

画像25

63 sample

B6では

画像26

131 sample

になっています。

お、縮んでいる。
その差68 sample

でもまだズレてますね。



C. それじゃあoutput側もoffに

画像27

これもオフってみます。inもoutもオフになりました。



C1. 録音中

A1と同じことをします。

こちらがZOOMの結果です。

画像29

81 sample



C6. 録音したものを再生する

C1の際にPTに録音されたものを再生してZOOMに録ります。

さてC1では

画像29

67 sample

C6では

画像30

77 sample

その差 10 sample!!

最小ですね。

録音中のモニターと再生時のモニターの差は10 sampleになったということです。



ここまでのまとめ

みなさんわかりましたでしょうか?
自分で言っててもわかりづらいと思ってますが、今よりわかりやすく検証する方法が思いつかなかった……

つまりどういうことかと言いますと

Pro Toolsは(HDX、HD IO、48kHzの場合)inputしてoutputすることで、アウトされる音は必ず81 sampleディレイしている。

これによりPTを通った音は、
プレイヤーの実際の演奏から
81 sample遅れて鳴っていることになる。

では果たしてクリップがプリントされるべき位置は
プレイヤーが実際に演奏したタイミングなのか
ディレイしてみんな(プレイヤー含め)が実際に聴いているタイミングなのか……

それを選択するために
"Compensate for input delays after record pass"
"Compensate for output delays after record pass"
の二つがある。

"Compensate for input delays after record pass"
"Compensate for output delays after record pass"

画像73

というもの。

オンだとこう

Skitch から

オンの場合は実際に演奏者が意図したタイミングにクリップをプリントするべく、
録音後に自動的にクリップを手前に81 sampleズラす。

オフだとこう

Skitch から 2

オフの場合はそれを行わず、モニターされているタイミングのままプリントされる。
(それでも録音モニター時とから
再生モニター時でなぜか10 sample手前にズレる)

そして

"Compensate for input delays after record pass"
"Compensate for output delays after record pass"
をオンにすることで、録音中にモニターしていた音と録音後に再生する音ではタイミングが変わるため、録音対象でないトラック(クリックやその他トラック)との関係性がズレて聞こえ方が変わる。

それと

81 sample遅れている音はコントロールルームのみならず、
演奏者本人も聴いている

ということも大事です!

ついてこれてますか……?😅

さて続けていきます。




D. 遅延補正なしでやってみよう

ここらでこの状態も把握しておきましょう。

画像34

これをオフって検証してみます。

ここをオフにすると

画像35

in / outのこいつらはグレイアウトするので、勝手にオフになります。



D1. 録音中

録音中の状態を見ます

画像39

この最中を録音したZOOMを見ます

画像37

81 sampleです。



D6. 録音したものを再生する

次はD1で録音されたものを再生してZOOMに録ります。
D1のクリックとの関係性と比べます。

D1では

画像38

1712 sample

D6では

画像39

1712 sample

です。

同じ!

録音中のモニターと、再生時のモニターが完全に一致しています。

遅延補正アリの時の
"Compensate for input delays after record pass"
"Compensate for output delays after record pass"
がオフのときは10 sampleのズレがありました、
しかし遅延補正をoffにするとその10 sampleのズレすらもなくなります😲

遅延補正はオンに戻します。


E. 録音トラック以外にプラグインを挿しているセッションでの挙動


実際に全てのトラックに何もプラグインが挿さっていない状況でダビングすることはほとんどないので、そういう場合の実験です。

画像31

ご覧の通り、clickにプラグインを挿して、録音対象でないトラックに遅延が発生するようにしました。

"Compensate for input delays after record pass"
"Compensate for output delays after record pass"

の二つはオンにします。


E1. 録音中

この状態での

画像40

ZOOMの結果です。

画像32

DirectとABの差は変わらず81 sampleでした。



E6. 録音したものを再生する

E1で録音されたものを再生してZOOMに録ります。
E1のクリックとの関係性と比べます。

E1

画像41

1639 sample


E6

画像42

1558 sample

その差81 sample

やはり再生時には録音時よりもタイミングが81 sample前にズレています。
"Compensate for input delays after record pass"
"Compensate for output delays after record pass"
がオンなためですね。

プラグインの遅延は影響を与えていません。



F1. 録音中

"Compensate for input delays after record pass"
"Compensate for output delays after record pass"
の二つをオフにして同様の検証をします。

画像43

この最中のZOOMの結果

画像44

DirectとABのズレはいつも通り81 sample


F6. 録音したものを再生する

F1で録音されたものを再生してZOOMに録ります。
F1のクリックとの関係性と比べます。

F1

画像45

2650 sample


F6

画像46

2640 sample

その差10 sample

C6の検証結果と同じですね。



G. では遅延補正をオフだと?

遅延補正をオフにした状態でもやってみましょう。



G1. 録音中

画像47

81 sample



G6. 録音したものを再生する

G1では

画像48

69 sampleで

G6では

画像49

69 sample

完全に一致!

D6のときと同じ結果ですね〰
録音中のモニターと再生のモニターでズレは発生しません。

プラグインで遅れててもなんにも関係ないのかぁ〜♨️♨️♨️♨️

って待て待てそんなわけないのです😡

G1の際にPTに録っていたものの、上記で探ったポイントと同じところを見てみましょう。

画像51

見比べます

画像52

クリックとの関係性がズレてる!


画像50


上記と同じポイントの距離を測ります。
314 sample

つまり上記の69 sampleのズレと合わせると

383 sample


実際にPTに置かれているクリップの位置から383 sampleクリックが遅れて鳴っているということです。

それってこれじゃない?

画像53

まぁ当然だけど。


E.F.G検証をふまえて

まず
"Compensate for input delays after record pass"
"Compensate for output delays after record pass"
の二つは不可避の81 sampleに対して働くものなので、
プラグインの有無によって動作は変わらなさそうなので無視します。

さて、クリックにプラグインが挿さってることで、クリックの発音が遅れます。
そのクリックに対して演奏をするので、録音中はみんなが後ろに遅れた状態です。

画像54

遅延補正をオフにしていると、これを停止した際には

Skitch から

こうしてプリントされることになってしまいます。

これではまずい。

遅延補正をオンにすると

Skitch から 2

ので

Skitch から 3

こうなるのです👏👏👏👏👏👏👏👏


もっと複雑に、複数のトラックに違う遅延が発生している場合(概ねの場合、これでしょう)
遅延補正がオフだと、

Skitch から 4

こうなってしまいますが、
オンにすることで

Skitch から 5

こうなります。

そして、録音停止することで

Skitch から 6

こうなるわけです。優秀〰👏👏👏👏👏👏👏👏



H. では録音しているトラックにプラグインを挿している場合は?

全てはここを確認しようということでこの記事始めたんですけど、果てしない道のりだったな……つらい……

録音するトラックにプラグインを挿しながら録音したい。

いまやふんだんにアウトボードを使えるわけでない、とか
余地を残したいから音を作り込みすぎないで、プラグインでモニターだけ調整したい。
とかいろいろな理由によって、録っているトラックにプラグインを挿しながら録音を進めることはそんなに珍しくはありません。

画像61

こうしてやってみましょう。
ここからやっとAとBトラックある意味が出てきます。

"Compensate for input delays after record pass"
"Compensate for output delays after record pass"

の二つはオン


H1. 録音中

まず今回はPTに録音されたものを見てましょう

画像64

ABのズレはありません。

プラグインを録りトラックに挿していても、プリントされるクリップのタイミングに影響はないことが確認できます(あたりまえ)

そしてPTが録音中のZOOMの結果です。

画像62

お、ほうほう🤔🤔🤔🤔🤔🤔

DirectとAのズレは81 sample。いつものですね。

AとBのズレは98 sample

画像63

これだ!

つまり、プラグインが挿さっているぶん、遅れている。

録りトラックにプラグインを挿していると、録音中の発音はプラグインの遅延分遅れて発音されている、ということになります。



H6. 録音したのを再生する

PTに録音されたものを再生してZOOMに録ります。すると

画像67

AとBが揃ってます😲

録音中にはプラグインの遅延がかかってしまってましたが、
停止してクリップがプリントされると、その遅延分を合わせてくれています。

それではこちらを確認

まず、PTに録音されたもの

画像65

10762 sample

その最中に録音していたZOOM

画像66

インサートなしのトラックは10843 sample
インサートありのトラックは10941 sample

差を計算すると
10843-10762 = 81 sample(不可避の遅延)
10941-10843 = 98 sample(プラグインの遅延)
と想定通り。

録音したPTを再生して録音したZOOM

画像68

10762 sample

想定通りです。



I. Hの内容はわかったけど、それって不便じゃない?

プラグインインサート時、録音中と、録音したものを再生した時で、録音トラック内の音が変わるのいやじゃないです?
録音中にも遅延補正でそろってくれる
(録音トラック内で一番遅いやつに合わせて他も遅らせる)
のがベストだけど、そうはならないようです。

まず一つ、遅延補正を大元からオフにするという手があります。
ただしこれだと、録音時の再生トラック達の相関関係も補正してくれないので、再生トラックたちの中でズレる場合があります。
再生トラックがシンプルな状況であればこれもアリですかね。
録音トラックはインサート分ズレて発音しますが、
そのまま遅延補正オフであれば、停止後に再生したときにも同じズレ方をするので、音が変わる、ということはありません。

次に、遅延補正をオンにした状態で録音トラックの

画像69

ここをイナクティブにする、という手が考えられます。

こうすることで、再生トラックたちの相関関係は揃って、録音トラックの相関関係は、録音時にもズレたまま、停止後再生してもズレたまま。

にすることができます。


でもそもそも録音時の録音トラックの相関関係もずれて欲しくないんだけど……位相とかあるんだけど……


G ex. これだ!!!!

はい、そんなみなさん。お待たせしました。
これです。

画像70

ここを青くするのです!!!!!!

こうすることでなんと、

PT録音時のZOOMの結果

画像71

録音中もABが揃っています!

そして再生を録音

画像72

してももちろん揃ったまま!

絶対みんな知らない。
(自分もゴニョゴニョ……)


あー疲れた……


まとめ

なんかもはや「つまりこうでこう」と言葉にする元気がなくなってきました笑
とりあえずこれだけ検証できていれば全ての状況が割り出せるのではないでしょうか。

重複しますがいくつかまとめます。

Pro Tools HDX、HD I/O、48kHzにおいて、バッファサイズに関わらず、
音が入ってから出てくるまでに81 sample遅れる。

"Compensate for input delays after record pass"
"Compensate for output delays after record pass"
がオンで、録音後にそのズレをなかったかのように、
録音クリップを81 sample手前にズラす。

"Compensate for input delays after record pass"
"Compensate for output delays after record pass"
がオンで、録音後に録音クリップを81 sample手前にズラすため、他トラックとの位置関係が変わり、聞こえ方が変わる

"Compensate for input delays after record pass"
"Compensate for output delays after record pass"
がオフで、録音中の発音タイミングと、停止後のクリッププリント位置は変わらない(なぜか10 sampleはずれる)

"Compensate for input delays after record pass"
"Compensate for output delays after record pass"
がオフで、演奏者が演奏したタイミングから81 sampleズレてクリップはプリントされる。

遅延補正をオフにした場合、
録音中の発音タイミングと、停止後のクリッププリント位置は変わらない。
(10 sampleのズレもなく、ぴったり)

再生トラックにプラグイン遅延が発生していても、
遅延補正がオンであればプラグイン遅延は補完される。

録音トラックにプラグイン遅延が発生している場合、
録音中のモニターには遅延によるズレが発生する。
停止後再生するときには、タイミングが揃って再生される。

録音トラックのあそこのあれを青くすることで、
録音トラック間の相関関係も補正される。
ただしセッション内の一番遅いトラックに揃えるので、演奏からモニターまでの遅延は大きくなる。


こんなところかと。



あとがき

大変すぎてわけわかんなくなりながらの走り書きでした。

こんなにセンシティブな要素をよくわからないまま使うなんてみんな気が狂ってるな!(自戒をこめて)

結局自分のワークフローの場合はどうするか、っていうのを考えてそこに向けた設定を考えるのが一番ですね。
こうして網羅しようとすると「そんで?どうしたらいいのー?」ってなりますよね。

とりあえず私はリズム録りの時にドラムに普通にプラグイン挿してやるので、
録音トラックのあそこのあれを青くして、
IOのあれはオフがいいかな。
聴いてるものから変わらないことの方が重要かと。
81サンプルって1msですからね、そこを気にするならアナログで録りましょうって話です。

反響と売り上げがあればもうちょっとわかりやすくまとめたり、HD Native、Hybrid Engineでもまとめたりします。

猛烈に強気の値段をつけておきますのでみなさんどうぞよろしくお願いします🙋‍♂️

買っても読める範囲は変わりませんがすごーくやる気が出ますよ!😂

ここから先は

0字

¥ 1,000

この記事が気に入ったらサポートをしてみませんか?