引き渡しと交換 / X2 · フレームレートの 2 つの数

同じフレームレートに計数レートと表示基数の 2 つの数を置くのはなぜか

同じ 1 つのフレームレートの選択肢が、ここには 2 つの数を同時に抱えています。ただし担っている仕事は別々です。片方は壁時計の時間をフレーム数へ進めるときに使う計数レートで、小数を交ぜることができます。もう片方はタイムコードの文字列とフレーム数を互いに換算するときの整数の表示基数です。

29.97 が見えているのに 30 でタイムコードの目盛りを刻んで書くのは、2 つのフレームレートを混同しているのではなく、計数レートと表示基数が別々の 2 つの仕事をしています。

なぜ 1 つのフレームレートに 2 組の数を残すのか

29.97 のような段階を例に取ると、計数レートは「壁時計がこれだけ進んだとき、何フレーム進めるべきか」に答え、表示基数は「そのフレームを時・分・秒・フレームの文字列にどう切り分けるか」に答えます。前者は小数を許す、経過時間の尺度です。後者は整数でなければならない、タイムコードのフレーム桁をグループ化する基数です。この 2 つを 1 つの数に混ぜると、進む速さと文字列の番号付けの規則を同じものだと誤読することになります。

23.976 も同じ構造です。進めるときは小数付きの計数レートを使い、文字列への変換では整数の表示基数を使います。24、25、30 のような整数の段階ではこの層の差がなく、計数レートと表示基数が同じ値だからです。ここで論点にしているのはどちらの数のほうがより「本物」かではなく、2 組の数が別々の計算に奉仕しているということです。

2 つの数が不一致だと時間の差がどう積み上がるか

これらの非整数段階では計数レートが表示基数より約 1000 分の 1 遅いので、タイムコードの番号を刻むテンポと壁時計の進み方は同じになりません。29.97 に 30、23.976 に 24 を組み合わせると、文字列は引き続き整数の表示基数でグループ化されますが、実際の推進はより遅い計数レートで行われます。結果はたまに番号が 1 つ足りないという形ではなく、同じ差が積み上がり続けます。

この枠組みでは、タイムコードは壁時計に対して徐々に遅れて行き、そのオーダーは 1 時間に数秒です。この速さで換算すると 1 時間に約 3.6 秒の遅れ、同じ速率を 24 時間に乗すと 86.4 秒で、1 分半という段階にあたります。この差は「近くに見えるから」という理由で帳消しにできません。この差はまさに 2 組の数の責務の分離から生まれているからです。

非整数段階で押さえるべきは、小数の形が整数に似ていることではなく、計数レートが推進速度を、表示基数が番号付けの構造を決めて、両者の差が時間とともに積み上がるという点です。

カメラ記録のフレームレートはどの基準レートに落とし込まれるか

あるカメラの記録に残ったフレームレートが、基準より上のオーバークランク値である場合、換算のロジックは除数を 1 つずつ試し、その結果を利用できる基準レートと比較します。極めて小さい許容差に最初に入った候補が基準レートとして採用され、候補が 1 つも当たらなければ 24 にフォールバックします。ここで小さい許容差を使っているのは、近い値のオーバークランク数値を対応する基準へ戻しつつ、隣り合う正常な段階まで一緒に混ぜないためです。

たとえば 24 と 23.976 の差は 0.024 なので、許容差はこの距離より小さくなければ、24 は 24 のままで 23.976 に吸い寄せられません。オーバークランク素材を基準レートでカウントするのは業界でよく見られる処理ですが、それが受け取り側が必ず採用しなければならない単一の経路だという意味ではありません。受け取り側は実際の納品物と自分のメディア側の記録にしたがってフレームレートのラベルを引き続き照合する必要があります。

なぜこの実時間のカウントが依然として NDF なのか

非整数段階の実時間側では、フレーム番号は連続して増えるだけで、一部の番号を飛ばして壁時計に追いつこうとはしません。したがってここでは非ドロップフレーム、つまり NDF のカウントです。NDF が表すのは実時間側がどう番号を付けるかという点で、エンドツーエンドの引き渡しチェーンが同じ表示ルールを持つと宣言したものではありません。「番号を飛ばさない」を「タイムコードが壁時計に追いつく」と理解するのはちょうど逆で、前に書いた積み上がった差はそのまま残っています。

エクスポート側にはドロップフレームの表示に関する別の裁定があり、このセミコロン表記は現在 ALE と CSV のタイムコード列にだけ現れます(日報 PDF の表組みにはタイムコード列がありません)。なので実時間側とエクスポート側の口径は一致していません。ここから、この App が現場から引き渡しまで通しでドロップフレームタイムコードの能力を持つとは主張できず、タイムコードが壁時計と同期しているかのように書くこともできません。納品物の中のセミコロンの意味については、実時間側の NDF からエクスポート結果を逆推するのではなく、『タイムコードのセミコロンは結局何を意味するのか』を別途ご覧ください。

引き渡しのときにラベルと区切り文字をなぜまだ見るのか

フレームレートのラベルは、その行の納品物がどの速さを申告しているかを受け取り側に伝え、タイムコードの区切り文字はエクスポート側がどの表示表記を選んだかを反映します。この 2 つの情報はいずれも元の記録そのものの検証の代わりにはなりません。特に実時間側とエクスポート側の裁定が統一されていない場合はなおさらです。ある列の値がどこから来たのかを追いたいときは、『ALE の各列の値はどこから来るのか』と合わせて列ごとに照合するのであって、タイムコードを知った顔の見た目をしているかどうかだけを見るのではありません。

したがって受け取り側は、納品物の中のフレームレートのラベルとタイムコードの区切り文字を自分で照合し、現場の記録やメディア側の情報と並べて判断する必要があります。計数レートは推進を、表示基数は文字列への変換を担い、そのうえでエクスポート側が表示形式を決めます。この 3 層は互いに代わり合いません。層を分けて考えれば、29.97 と 30 が同時に出てくることは、もはや自己矛盾する 2 つの答えではなくなります。

FAQ

29.97 でなぜ 30 という数が見えるのですか?

29.97 は計数レート、30 は表示基数で、それぞれフレーム数を進めるときとタイムコードの文字列を切り分けるときに使われます。2 つが同時に現れるのは計算の分担のことで、1 つの段階を一時的にもう 1 つの段階へ改めたという意味ではありません。

23.976 も同じ 2 つ数の構造ですか?

はい、23.976 は小数付きの計数レートで進め、タイムコードの文字列の換算には整数の表示基数を使います。計数レートは表示基数より約 1000 分の 1 遅いので、タイムコードは壁時計に対して徐々に遅れて行きます。

実時間側の NDF は、エクスポートも NDF で書かれることを意味しますか?

そうは導けません。実時間側はフレーム番号を飛ばさない NDF のカウントですが、エクスポート側にはドロップフレームの表示の裁定が別にあり、エンドツーエンドの口径は一致していません。

受け取り側は最終的に何を照合すべきですか?

受け取り側は納品物の中のフレームレートのラベルとタイムコードの区切り文字を自分で照合し、現場の記録およびメディア側の情報と突き合わせる必要があります。1 つの数またはある種の区切り文字だけで、チェーン全体が検証済みだとして扱うことはできません。


Axiom One LLC — SlateX。上の数字は 2026-09-24 時点のものです。