29.97fpsとドロップフレーム|タイムコードがズレる理由

1時間の番組を書き出したのに、タイムコードの終わりが01:00:00:00にならない。手元のストップウォッチとも合わない。数秒の話なので進行には響かないのですが、数字が合わないという事実だけが残ります。

このズレは不具合ではありません。29.97という半端なフレームレートを、30という切りのいい数え方で数えているせいで出てきます。

数え方が2種類あって、どちらを使っているかで結果が変わる。そういう話です。

なぜ30fpsではなく29.97fpsなのか

白黒テレビの時代、アメリカのNTSC方式は毎秒30フレームでした。そこへカラーの信号を足すことになったとき、色情報を載せる搬送波が音声の信号と干渉する問題が出ます。

解決策として選ばれたのが、フレームレートをわずかに下げることでした。30に1000/1001を掛けて、29.97002997…にする。約0.1パーセントの変更で、白黒受信機との互換を保ったまま干渉を避けられます。

だから29.97は、正確には30000÷1001です。29.97という表記は丸めた呼び名で、実際には割り切れません。ここが後のすべての面倒の出発点になっています。

同じ理由で、24fpsは23.976(24000÷1001)に、60fpsは59.94(60000÷1001)にずらされました。映画由来の素材をテレビに載せるときの数字が半端なのも、出どころは同じです。

割り切れる行と割り切れない行が交互に並びます。ドロップフレームという数え方があるのは、割り切れない行のうち放送で使うものだけです。23.976に無いのは、映画の尺が実時間との一致を前提にしていないからです。

1時間で3.6秒ズレる

タイムコードは映像の各フレームに時分秒とフレーム番号を振る仕組みで、SMPTE 12Mで規定されています。表記は時:分:秒:フレームの4組です。

問題は秒の繰り上がりです。29.97fpsの素材でも、フレーム番号は0から29まで数えて、30になったところで秒を1つ進めます。つまり数え方は30fpsのままです。

計算してみます。1時間ぶんのフレーム番号は30×3600で108000。いっぽう29.97fpsで1時間に実際に流れるフレームは107892.1本です。番号のほうが約108本多い。この差を実時間に直すと約3.6秒になります。

素直に数えるだけで、1時間ごとに3.6秒ずつ実時間から離れていく。この数え方をノンドロップフレームと呼びます。

ドロップフレームが落としているのは映像ではない

名前のせいで、フレームを間引いていると受け取られることがあります。ドロップフレームは映像を捨てていません。捨てているのは番号だけです。

規則はこうです。毎分の先頭でフレーム番号の00と01を飛ばし、01;00;01;02のように02から数え始める。ただし10で割り切れる分は飛ばしません。1時間なら60分から6分を除いた54分ぶん、2本ずつで108個の番号が消えます。

さっき出した差がちょうど108本でした。つまりドロップフレームは、番号を108個間引くことで実時間とタイムコードを合わせています。映像は1コマも減りません。

完全に一致するわけではなく、1時間あたり0.1フレームほどの残差が出ます。丸1日回して2.6フレーム、実時間で0.09秒。放送の尺管理では問題にならない水準です。

59.94fpsも同じ考え方で、こちらは毎分4個の番号を飛ばします。フレームレートが倍なので、飛ばす数も倍になる。規則そのものは変わりません。

表記の見分け方も決まっています。ドロップフレームは最後の区切りをセミコロンにして01;00;00;02と書き、ノンドロップはコロンで01:00:00:00と書く。素材を受け取ったとき、まずここを見ます。

どちらを使うのかは、出口が決めている

放送で使うのはドロップフレームです。番組の尺は実時間で決まっていて、CMの入る位置も秒で管理されています。タイムコードが実時間からずれていくと、尺表と突き合わせられません。

いっぽう編集の途中や、フレーム単位の管理を優先する工程ではノンドロップが使われます。番号が飛ばないぶん、フレーム数の計算がそのままできる。

厄介なのは混在したときです。ノンドロップで編集した素材をドロップフレームのタイムラインに置くと、表示される時刻が変わります。中身は同じなのに、頭の位置が数秒ずれて見える。

完パケの頭を01:00:00:00に合わせる約束事も、どちらの数え方で01:00:00:00なのかまで含めて指定されているものです。

字幕がズレるのは、数えている軸が違うから

字幕の時刻は、タイムコードとは別の軸で持たれていることがあります。SRTファイルの時刻は00:01:23,456という実時間の表記で、フレーム番号を持ちません。

ここで変換が挟まると誤差が入ります。実時間からフレーム番号を出すには29.97で割る必要があり、割り切れないので端数が出る。1か所なら1フレーム未満でも、番組の後半まで積み上がると目に見える遅れになります。

もっと単純な事故もあります。素材の頭が01:00:00:00で、字幕ファイルの頭が00:00:00,000。この1時間ぶんのオフセットを引き忘れると、字幕はまったく出ません。出ないほうがまだ良くて、片方だけ引かれていると微妙にずれた状態で通ってしまいます。

放送に出す字幕はARIB STD-B36の形式で送出側へ渡しますが、そこでも時刻の基準は素材のタイムコードです。制作の途中で数え方が変わっていないかは、渡す前に確かめる必要があります。

ズレは仕様なので、確認を手順に入れる

29.97fpsが半端なのはカラー化の都合で、いまさら変えられません。ドロップフレームはその半端さを吸収する数え方であって、映像に手を触れるものでもありません。

だから対処は、直すことではなく確かめることになります。素材のフレームレートは何か。タイムコードはドロップかノンドロップか。字幕の時刻は実時間かフレーム番号か。頭は00:00:00:00か01:00:00:00か。

4つとも、素材を受け取った時点で分かります。分かるのに確認が飛ばされるのは、たいてい前回と同じだろうと思うからです。書き出しの設定と一緒に、渡す側と受ける側で書き残しておくほうが早い。

ところで、配信だけで完結する番組にドロップフレームは要るのでしょうか。実時間と一致させる必要が薄れたとき、この数え方がどこまで残るのかは、まだはっきりしていません。

NAXAの取り組み

NAXAのSubtitle Generatorは、音声認識から字幕への整形までを扱い、素材のタイムコードに合わせた時刻で字幕ファイルを書き出せます。放送素材の頭合わせやフレームレートの前提を、運用に合わせて設定できる形にしています。