タイムコードのセミコロンは結局何を意味するのか

タイムコードの末尾のセクションのコロンがセミコロンに変わっていたら、おおむね「この文字列はドロップフレームの記号で表示している」という知らせです。これは、いくつかの分数フレームレートでフレームの計数と人間の時計が長時間にわたれてずれて行く問題を扱うための表記です。ただし引き渡しのファイルを受け取るとき、セミコロンはヒントとしてだけ扱い、フレームの位置が実際にドロップフレームの規則で換算済みだと単独で証明してはなりません。表示の記号と計数の算法は分けて照合する必要があります。

セミコロンは「この文字列がドロップフレームの書き方を表したいのだろう」と教えますが、「この文字列のフレーム位置がすでにドロップフレームの規則で計算された」とは自動的に教えません。

なぜドロップフレームの計数表記があるのか

29.97 のような分数フレームレートでは、1 秒あたりに実際に進むフレーム数と、整数の 30 でタイムコードの番号を刻んだときのリズムは完全に同じではありません。連続した整数のフレーム番号を表示し続けて補正をしないと、タイムコードの読み上げは壁時計に対して徐々に遅れて行きます。

式で推算すると、29.97 のような連続計数は1日におよそ1分半のオーダーまで積み上がります。そこでドロップフレームの計数は、動画のフレームを本当に捨てるのでなく、タイムコードの番号付けの中で規則に従っていずれかの番号を飛ばし、表示の時計と実際に経過した時間を再び近づけます。

よく見るテキストの約束では、末尾の区切り文字をセミコロンで書きます。たとえば 01:00:00;00 です。この記号は役に立ちます。受け取り側は一目で、ファイルがドロップフレームの記号を表していると分かるからです。それでも記号はあくまで文字列の一部です。

表示の記号とフレーム位置の換算は別々のこと

本物のドロップフレームの計算は、フレーム番号と時・分・秒・フレームのあいだを行き来するときに跳号の規則を実行する必要があります。最後の : を ; に置き換えるだけなら、変わったのは外見だけで、元のあの数字の並びが表すフレームの位置は何も変わっていません。

SlateX の引き渡しファイルでは、この2つの書き方が別々の欄に収まります。すでに記録されている入り点または出点の文字列は、2通りのいずれかをたどります。録音チェーンが停止の瞬間に画面から取り込んだ読み取り値は、有効なドロップフレームの住所に組み替えられます。末尾の区切り文字だけをセミコロンへ変えると ;00 や ;01 のような、SMPTE が定義していない値になってしまうからです。機械の画面やパネルからスクリプターが書き写した読み取り値は、1文字も動かさず、末尾の区切り文字だけをセミコロンに変えます。出所が宣言されていない場合は推測しません。数字は一切変更せず、宣言の欠落はラップ照合表が TC_SOURCE_UNDECLARED として名指しします。Duration は開始と終了の2つの読み取り値のあいだのフレーム精度の範囲（末尾のフレームは含まない）で、DF を宣言した行ではその欄がセミコロンの形で書かれます。

これが本稿のハードな境界です。; を見たら、引き渡し層がこの文字列をドロップフレームの書き方として標識したと分かります。しかしこの記号だけからは、あの数字の並びが今までにドロップフレームの規則で得られたものかどうかを判断できません。

29.97 に近い値はドロップフレームを宣言しない

29.97 に近いフレームレートだからといって、それだけでチェーン全体が同じ計数規則を使っている証明にはなりません。境界上の値には特に注意が必要です。画面に表示されるものと引き渡しファイルに書き込まれるものは、別の分類に落ちることがあります。確認できるのは、ファイルのその欄が最終的に何と書いているか、そしてその行の実際の FPS、タイムコード文字列、素材が互いに合うかどうかです。

受け取り側が検証するのは、実際の素材1本がどうタイムコードに対応するかであって、区切り文字の形だけでは検証できません。

App の実時間表示と引き渡しのファイルは同じ表現ではない

画面に表示される実時間のタイムコードは、すべてコロンで区切られた文字列で、セミコロンはありません。つまり、App で現場に見えているものと、後で引き渡しファイルに現れ得るものは、別々の表現規則から来ています。

後から引き渡しファイルにセミコロンが現れても、現場の実時間表示がすでに同じ計数規則に従っていたと逆推することはできません。

受け取るときは、この2つの層を分けておく必要があります。画面で読んだのはどの文字列か、引き渡しファイルが書くのはどの文字列か、既存の文字列で区切り文字だけが置き換えられたのか、最終的な素材の位置が実際に合っているのか。どれか1つでも欠ければ、セミコロンを検収の結論としては不十分です。

セミコロンの付いたタイムコード1本を実際にどう照合するか

まずその行の FPS が素材と現場の記録に合っているかを見て、次に位置を特定できる素材を1本選び、実際の入点と経過時間と並べます。出点は書き写された読み取り値なので、あの欄で確かめるのは「そもそも書き写されたかどうか」です。算出された範囲は Duration であり、それを検証するには、開始と終了の2つの読み取り値と、それらを読み取る際に使われた計数規則に戻る必要があります。

入り点または出点が既存の文字列なら、セミコロンが付いているかどうかだけを見るのはやめてください。受け取り側はフレームの位置そのものが素材と対応付けられるかを検証する必要があります。記号だけを変えた文字列は、見た目には正しいドロップフレームのタイムコードにとてもよく似ますが、その数字は別の計数方法から来ているままかもしれません。

したがって、セミコロンは「ここでドロップフレームの口径を確認する必要あり」というヒントとして扱い、「これは検証済みだ」というラベルとして扱うのには向きません。

FAQ

タイムコードの末尾がセミコロンなら、ドロップフレームの規則で計算済みと確認できますか？

できません。セミコロンは表示層の記号にすぎないことがあります。現在の引き渡しの経路は、既存のタイムコードの文字列に対して末尾のセクションの区切り文字だけ置き換え、フレーム位置を再計算しない場合があります。

ドロップフレームは実際の動画フレームを削除するのですか？

ここで論じている意味ではありません。ドロップフレームの計数が調整するのはタイムコードの番号付けの規則で、分数フレームレートの連続番号付けと壁時計の長時間のズレを補うために使われます。

なぜ同じフレームレートの値が違う結果になり得るのですか？

画面の表示と引き渡しファイルは別々の段階に属するため、境界上の値は違う結果になり得ます。実際のファイルと素材を照合し、その欄が最終的に何と書いているかを確認してください。

App の画面の実時間タイムコードもセミコロンを使いますか？

現在の実時間の鎖はすべてコロンの文字列を出力し、セミコロンの表記を作りません。引き渡しのファイルの中のセミコロンは別段階の表現で、実時間の鎖が同じドロップフレーム計数を使ったとは反推できません。

Axiom One LLC — SlateX