ビデオと字幕 · 字幕ツールキット
字幕タイムコードの比較: SRT カンマ、VTT ドット、および SMPTE フレーム
· 背景
字幕 タイムコード フレームレート
キャプション作品には、SRT の HH:MM:SS,mmm、WebVTT の HH:MM:SS.mmm、および SMPTE の HH:MM:SS:FF という 3 つの時刻の書き方が表示されます。この投稿では、それぞれの意味、変換方法、変換が失敗する場所について説明します。
同じ瞬間を 3 つの方法で書いた - 1 つのプロジェクトで編集者が遭遇するタイムコードの簡単なツアー
1 つのプロジェクトは、3 つの方法で書かれた同じインスタントを編集者に渡すことができます。字幕ファイルでは、時間、分、秒、およびミリ秒の前のカンマが使用されます。 Web キャプション ファイルでは、同じ位置にドットが使用されます。編集決定リストでは、分数の代わりにフレーム番号が使用されます。 3 つすべてが同じ瞬間の名前であり、その内容について他に何も知らなくても読めるのは 1 つだけです。
最後の点が重要です。これらの表記法のうち 2 つは絶対的であり、1 つは絶対的ではありません。違いが見落とされると、それらの間の変換は特定の方法で失敗します。
カンマ付きミリ秒: SRT — 書式規則となったヨーロッパの小数点表記の習慣
SRT は、時、分、秒、カンマ、および正確に 3 桁のミリ秒を書き込みます。カンマはヨーロッパの規約では小数点の区切り文字であり、SubRip にはそれを修正するための標準文書がなかったため、仕様ではなく使用法による形式規則になりました。この価値観については何もヨーロッパ的ではありません。句読点のみです。
ここのパーサーは、右側で見つかった数字を 3 桁に埋め込んでミリ秒を読み取るため、1 桁で終わるタイムスタンプは単位ではなく数百ミリ秒として読み取られます。これは重要です。なぜなら、手動またはルーズコンバーターによって作成されたファイルは常に 3 桁を提供するとは限らず、末尾の 1 桁を単位として読み取ると、キューがほぼ 1 秒早く配置されることになるからです。
ドット付きミリ秒: WebVTT — 同じ値、異なる区切り記号、およびパーサーにとってそれが重要な理由
WebVTT は同じ値をドットで書き込み、時間フィールドを完全に省略することを許可するため、SRT が 3 フィールドを想定している場合、2 フィールドのフォームが有効です。パーサーにとって、これらはまったく異なる文法であるため、ファイル内のすべての数値が正しいにもかかわらず、句読点だけでファイルが拒否される可能性があります。
実際のファイルでは常に 2 つが混合されるため、ファイルがどの形式であると主張しているかに関係なく、パーサーはどちらの区切り文字も受け入れます。その許容誤差は入力時のみです。出力時の区切り記号はターゲット形式、SRT の場合はカンマ、WebVTT の場合はドットによって選択されるため、変換されたファイルは、到着した不規則なもののコピーではなく正規のものとなります。
フレーム: SMPTE タイムコード — HH:MM:SS:FF、フレーム レートとドロップ フレームの複雑さへの依存
SMPTE タイムコードは、小数部分をフレーム番号に置き換えて、時、分、秒、およびフレームを示します。他の 2 つとは異なり、単独で解釈することはできません。フレーム 12 は、1 秒あたり 25 フレームの場合と 30 フレームの場合では異なる瞬間であるため、レートが宣言されていないフレームベースのタイムコードは、単に曖昧であるというよりもむしろ不完全です。
ドロップフレームは 2 番目の複雑機構を追加します。 29.97 フレーム/秒のマテリアルは、あたかも 30 フレームであるかのようにカウントされ、カウントをクロックに合わせるために、ほとんどの分の開始時に 2 つのフレーム番号がスキップされ、10 分ごとに除外されます。フレームはドロップされません。ラベルのみです。ドロップフレーム タイムコードはカウント規則であり、これを単純なフレーム カウントとして扱うと、プログラム全体で増大するエラーが発生します。
フレームをミリ秒に変換する — 小さいながら実際の誤差を生み出す算術演算と丸め処理
フレームをミリ秒に変換すると、フレーム レートで除算され、四捨五入により小さな誤差が生じます。フレーム インデックスをレートで割って 1,000 を乗じた値が 1 ミリ秒になることはほとんどないため、結果を格納するには丸める必要があります。内部的には、キューはゼロからカウントされた整数のミリ秒として保持されるため、その表現への変換はすべて 1 回丸められます。
1 つの丸めは無害です。注意すべきエラーは変換の繰り返しです。ファイルをフレームからミリ秒に変換し、異なるレートでフレームに戻し、再び転送すると、そのたびに丸めが蓄積され、それらのエラーはキャンセルされません。ファイルを複数のツールに渡すのではなく、信頼できるソースから一度変換します。
動作例: 25 fps と 29.97 ドロップフレームでの 1 つのキュー — 両方をミリ秒に変換して比較
1 分 30 秒と 12 フレームで 1 つのキューを取得します。 1 秒あたり 25 フレームの場合、12 フレームは 12/25 秒、つまり正確には 480 ミリ秒なので、この瞬間は 90,480 ミリ秒になります。
29.97 ドロップフレームでは、同じラベルが別のインスタントになります。フレームを数えます。公称 30 秒の 90 秒は、2,700 プラス 12 から、最初の 1 分でドロップされた 2 つのラベルを差し引いた、2,710 フレームになります。 1,000 対 1,000 の実際のレートで割ると、その瞬間は約 90,424 ミリ秒になります。 2 つのタイムコードはほぼ同一に見えますが、およそ 56 ミリ秒の差があります。これは、レビューに耐えられるほど小さく、タイトなキューで確認できるほど十分に大きいです。
これでカバーされないもの — 99 を超える時間、コンテナ メタデータの負の時間とタイムコード
これは、字幕ファイルが持つタイムコード表記について説明します。一部のシステムでは経過時間ではなくリールの識別に使用される 99 を超える時間フィールドはカバーされません。また、どちらの字幕形式でも表現できない負の時間もカバーされません。 1 を生成するシフトは 0 にクランプされます。
コンテナのメタデータに格納されるタイムコードも対象外です。ビデオ ファイルには、ファイル内のすべてをオフセットする開始タイムコードが含まれる場合があるため、プログラムに対して正しい字幕ファイルがファイルに対して間違っているように見える可能性があり、字幕のタイムスタンプをいくら調べてもそれが明らかになりません。
要点: どのクロックを読み取っているかを知る — 字幕ツールキットが SRT と WebVTT タイムコードの間で正確に変換する方法
どの時計を読んでいるかを把握します。カンマとドットは、異なるパーサー用に記述された同じ値であり、それらの間で変換を行うと、句読点だけが変更されるはずです。フレーム カウントは別の種類の数値であり、レートがなければ意味がなく、レートがドロップ フレームの場合は誤解を招きます。
ツールキットを使用して SRT と WebVTT の間で変換し、前後のタイムスタンプを比較します。区切り文字は変更されますが、数字は変更されません。数値が移動した場合、ファイルはどこかでフレームベースのステップを経ており、それが検査対象の変換です。