タイムコードのセミコロンは結局何を意味するのか
タイムコードの末尾のセクションのコロンがセミコロンに変わっていたら、おおむね「この文字列はドロップフレームの記号で表示している」という知らせです。これは、いくつかの分数フレームレートでフレームの計数と人間の時計が長時間にわたれてずれて行く問題を扱うための表記です。ただし引き渡しのファイルを受け取るとき、セミコロンはヒントとしてだけ扱い、フレームの位置が実際にドロップフレームの規則で換算済みだと単独で証明してはなりません。表示の記号と計数の算法は分けて照合する必要があります。
セミコロンは「この文字列がドロップフレームの書き方を表したいのだろう」と教えますが、「この文字列のフレーム位置がすでにドロップフレームの規則で計算された」とは自動的に教えません。
なぜドロップフレームの計数表記があるのか
29.97 のような分数フレームレートでは、1 秒あたりに実際に進むフレーム数と、整数の 30 でタイムコードの番号を刻んだときのリズムは完全に同じではありません。連続した整数のフレーム番号を表示し続けて補正をしないと、タイムコードの読み上げは壁時計に対して徐々に遅れて行きます。
式で推算すると、29.97 のような連続計数は1日におよそ1分半のオーダーまで積み上がります。そこでドロップフレームの計数は、動画のフレームを本当に捨てるのでなく、タイムコードの番号付けの中で規則に従っていずれかの番号を飛ばし、表示の時計と実際に経過した時間を再び近づけます。
よく見るテキストの約束では、末尾の区切り文字をセミコロンで書きます。たとえば 01:00:00;00 です。この記号は役に立ちます。受け取り側は一目で、ファイルがドロップフレームの記号を表していると分かるからです。それでも記号はあくまで文字列の一部です。
表示の記号とフレーム位置の換算は別々のこと
本物のドロップフレームの計算は、フレーム番号と時・分・秒・フレームのあいだを行き来するときに跳号の規則を実行する必要があります。最後の : を ; に置き換えるだけなら、変わったのは外見だけで、元のあの数字の並びが表すフレームの位置は何も変わっていません。
SlateX の現在の引き渡しの経路では、この2つの動作のどちらも存在します。終り点が欠けていて、ソフトウェアが入り点と長さから出点を計算する場合は、実際のドロップフレームの算術に入ります。すでに存在する入り点または出点の文字列については、末尾のセクションの区切り文字をセミコロンへ変えるだけで、フレーム位置の換算は一切行いません。
これが本稿のハードな境界です。; を見たら、引き渡し層がこの文字列をドロップフレームの書き方として標識したと分かります。しかしこの記号だけからは、あの数字の並びが今までにドロップフレームの規則で得られたものかどうかを判断できません。
「29.97 に近い」を判定する2か所の許容差は同じではない
実時間側がカメラの名目のレートを基準レートへ換算するときの許容差は 0.013 で、エクスポート側が数値でドロップフレームかどうかを判定するときの許容差は 0.02 です —— 2 か所の判定対象は違い、許容差も同じ数ではありません。これは、縁にあるフレームレートの値が、2 つのロジックで違う分類になり得ることを意味します。
こうした差を受け取り側が気にしなくてよい実装の詳細として包装してはいけません。それがタイムコードにどの表示または計算の経路を取らせるかを変えるのであれば、検収のときにファイルの中の実際の FPS、タイムコードの文字列、素材を並べて照合すべきです。
同様に、「数値がよく見るフレームレートに近い」を、チェーン全体がすでに同じ計数規則を採用していることと直接等しくすることはできません。判断の入口が違えば、結論も変わり得ます。
受け取り側が検証するのは、実際の素材1本がどうタイムコードに対応するかであって、区切り文字の形だけでは検証できません。
App の実時間表示と引き渡しのファイルは同じ表現ではない
SlateX の実時間の鎖は現在、すべてコロンのタイムコードを出力し、セミコロンの表記を作りません。つまり、App の画面で現場に見えている実時間の文字列と、引き渡しのファイルに現れ得るセミコロンは、別々の段階の表現規則です。
実時間の鎖は分数フレームレートで分数の値に従って計数を進め、その後で整数のフレームレートを使ってフレーム数を文字列へ変換します。それ自体にドロップフレームの跳号の表記はありません。だから、引き渡しのファイルに後でセミコロンが現れたことから、現場の実時間表示がすでに同じ規則で動いていたと逆推してはなりません。
受け取るときはこの2層を分けてください。現場の記録の元の文字列がどこから来たのか、引き渡しのときに再計算があったのか、区切り文字がただ置き換えられただけなのか、最終的な素材との対応が成立するのか。いずれか1つでも欠けていれば、セミコロンを検収の結論として扱うことはできません。
セミコロンの付いたタイムコード1本を実際にどう照合するか
まずその行の FPS が素材と現場の記録に合っているかを見て、次に位置を特定できる素材を1本選び、実際の入点と経過時間と並べます。ファイルの中の終り点がソフトウェアの計算で出したものなら、それ相応の計数規則を通ったのかも別途確認する必要があります。
入り点または出点が既存の文字列なら、セミコロンが付いているかどうかだけを見るのはやめてください。受け取り側はフレームの位置そのものが素材と対応付けられるかを検証する必要があります。記号だけを変えた文字列は、見た目には正しいドロップフレームのタイムコードにとてもよく似ますが、その数字は別の計数方法から来ているままかもしれません。
したがって、セミコロンは「ここでドロップフレームの口径を確認する必要あり」というヒントとして扱い、「これは検証済みだ」というラベルとして扱うのには向きません。
FAQ
タイムコードの末尾がセミコロンなら、ドロップフレームの規則で計算済みと確認できますか？
できません。セミコロンは表示層の記号にすぎないことがあります。現在の引き渡しの経路は、既存のタイムコードの文字列に対して末尾のセクションの区切り文字だけ置き換え、フレーム位置を再計算しない場合があります。
ドロップフレームは実際の動画フレームを削除するのですか？
ここで論じている意味ではありません。ドロップフレームの計数が調整するのはタイムコードの番号付けの規則で、分数フレームレートの連続番号付けと壁時計の長時間のズレを補うために使われます。
なぜ同じフレームレートの値が2つのロジックで違う判断になり得るのですか？
現在の2か所の「29.97 に近い」の判定の許容差は、それぞれ 0.013 と 0.02 で違うためです。縁にある数値は違う分岐に入り得るため、受け取り側は実際のファイルと素材を照合する必要があります。
App の画面の実時間タイムコードもセミコロンを使いますか？
現在の実時間の鎖はすべてコロンの文字列を出力し、セミコロンの表記を作りません。引き渡しのファイルの中のセミコロンは別段階の表現で、実時間の鎖が同じドロップフレーム計数を使ったとは反推できません。
Axiom One LLC — SlateX。上の数字は 2026-09-24 時点のものです。