60分きっかりの番組が、3.6秒はみ出す
60分の番組を組んだとする。進行表の最終行は「60:00 終了」。次の枠は、その時刻にぴったり始まる。
ディレクターはタイムコードの表示を見ながら進め、01:00:00:00に着いたところで締めに入った。ところが実際の時計では、その瞬間にすでに3603.6秒が過ぎている。次の枠の頭を、3.6秒食った計算になる。
演出が悪かったのではない。タイムコードを「ノンドロップ」という数え方で回し、進行表は実際の時刻で書いた。それだけで、1時間に3.6秒の差が生まれる（出典：Sonix「Drop Frame vs. Non-Drop Frame Timecode」）。3時間の生放送なら、3.6秒×3時間＝10.8秒。終了時刻が10秒以上、後ろにずれ込む。
秒のずれが入り込む入口は4つだけ
現場で「秒」が合わなくなる原因を洗い出すと、入口は4つに収まる。
- 時計そのもの 機器ごとに時刻が違う。LAN内で時刻をそろえた場合の誤差は数百マイクロ秒、公衆インターネットを挟むと数十ミリ秒、行きと帰りの経路が違うと100ミリ秒以上の誤差が出る（出典：RFC 5905 §1、Wikipedia「Network Time Protocol」）。
- 数え方 冒頭の3.6秒がこれだ。
- 届き方 拠点をまたぐと、映像と音声が届くまでに待ち時間が加わる。
- 読み方 「5秒前」を、5から数え始めるのか、5で動くのか。人によって解釈が分かれる。
日本の放送系の映像は毎秒59.94回の画面更新が基本だ（出典：ソニー業務用FAQ）。1回の更新は1÷59.94＝16.68ミリ秒。本稿ではこれを「1コマ」と呼ぶ。100ミリ秒のずれは、100÷16.68＝6.0コマに当たる。カットとテロップを同時に出す演出なら、はっきり目に見えるずれだ。
あなたの現場が悪いのではない
合唱団を思い浮かべてほしい。全員が同じ楽譜を持っている。ところが指揮棒が見える席と、音だけが届く席がある。さらに、楽譜の小節を数える癖が人によって違う。誰も間違っていないのに、入りの拍がばらばらになる。
映像の現場で起きているのは、これと同じ構造だ。楽譜（進行表）は1枚でも、指揮棒（時計）が複数あり、音の届く速さ（伝送）が違い、数え方（コール）の約束がない。個人の注意力で埋められる差ではない。仕組みで解くしかない。
解く方法はある。しかも手順は決まっている
時計を1本にそろえ、先の4つの入口に1つずつ手を打つ。やることは決まっていて、準備は1回で済む。一度作った進行表の型は、次の現場にそのまま持ち込める。
この先の有料部で手に入るもの
- 用途別の「許容ずれ」早見表（1秒、1コマ、1マイクロ秒の3段階）
- 現場でそのまま使える、時計をそろえる7ステップ
- 全機器のずれを動画1本で測る検証法と、合格ライン
- 拠点間の待ち時間を進行表に書き込む計算式
- 症状から原因を引ける、5項目のトラブル早見表
- 「N秒前」のコールを統一する書き方
次の現場の1時間は、取り戻せない
進行の秒がずれたまま迎える本番では、ずれの原因を探す時間が本番中には取れない。事前に潰せるのは、いまこの設計の段階だけだ。45年の現場で見てきた判断軸を、読んで30分で持ち帰れる形にまとめた。
コメント