終了が開始より前の字幕を検出
字幕テキストを貼り付けることもできます
オプション
タイミングを数える基準のフレームレートです。形式のページでは MicroDVD が必要とする値で、同形式は時間をフレーム番号で保存します。フレームレートのページでは、そのファイルがどのレートを前提に作られたか（字幕が合わせて作られた版）を指し、ページの2つ目の欄には実際に使う動画のレートを入れます。よく使われるのは 23.976、24、25、29.97、30、50、59.94、60 です。間違えると時間軸全体がずれます。フレームレートのページでは、ずれは固定量ではなく比率で生じます。
終了が開始より前にある cue は、成立し得ないタイムコードです。00:00:03,000 --> 00:00:03,000 のように長さがゼロか、さらに悪い場合は終了が開始より前になります。この頁は、そうした cue を含んでいたファイルを、読み込み側が行った修復の記録から報告します。その形のタイムコードはメモリ上にそのまま保持できず、ほかの何よりも先に実在する値へ置き換えられるからです。返るのはレポートであり、変更されたファイルではありません。
だからレポートは、読み込み中に失われたものを先に示し、その後に検出を並べます。終了が開始より後でない cue には 1 ミリ秒が与えられ、ファイルの残りを読んでプレビューし書き出せるようにします。その修復の件数がヘッダーに載り、下の検出は cue 番号なしのエラー 1 件として出ます。修復は読み込みながら数えているのであって、一覧として保持しているわけではありません。2 行は同じ壊れたタイムコードを両側から記述しており、だから 2 つのレポートではなく 1 つに属します。
この頁を書くうえでの落とし穴は、正当な 1 ミリ秒の cue が修復済みの cue と見分けられないことでした。そこで検査は表示時間をまったく見ず、修復の記録を見ます。本当に 1 ミリ秒続く cue はそのまま残ります。負の長さとゼロ長は同じ不具合としてまとめて数えます。2 つの形式は受け付けませんが、今回は両側とも理由が同じです。LRC は各行の終了を次のタイムスタンプから導くので、そこが逆転することはあり得ません。プレーンテキストには cue の時刻がありません。どちらを検査しても、その形式が持たない項目について問題なしというレポートが出ます。それは答えがないより悪い唯一の答え方です。
例
長さのない cue
字幕
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,000
I was working late.
レポートが検出するもの
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
終了が開始と等しい cue です。読み込み側はファイルを保持できるよう 1 ミリ秒を与えて修復を記録し、レポートはその両方を出します。ヘッダーの損失行と、その下のエラー 1 件です。修復が証拠であり、1 ミリ秒は証拠が取る形にすぎません。
本当に 1 ミリ秒続く cue
字幕
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,001
I was working late.
レポートが検出するもの
Cues ending before they start — Nothing found
Cues 2
Checks run 1
Lost while reading Nothing
手で 1 ミリ秒の cue として書かれたもので、報告されません。この判断が検査の形を決めています。修復されたゼロ長の cue も 1 ミリ秒になるので、ここで短い表示時間を検出する規則にすると、壊れたタイムコードを含むファイルを、あり得ないほど短い cue だらけのファイルと呼ぶことになります。
終了が開始より前にある
字幕
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:05,000 --> 00:00:02,000
I was working late.
レポートが検出するもの
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
5 秒から 2 秒へ。ゼロ長の場合と同じ不具合で、同じ規則で数えられ、同じように報告されます。ファイル内は何も書き換えられません。修復された時刻は読み込み側の複製にだけ存在し、残りを処理するためのもので、この頁が提供する修正ではありません。
よくある質問
この頁では、何を「開始より前に終わる cue」と数えますか？
終了時刻が開始時刻より後でないものです。00:00:03,000 から 00:00:03,000 のように等しい場合も、00:00:05,000 から 00:00:02,000 のように前にある場合も同じ不具合としてまとめて数えます。cue そのものではなく、読み込み側が行った修復から数えるのは、その形のタイムコードをメモリに保持できないからです。
レポートが該当する cue を名指ししないのはなぜですか？
これらの修復はファイルを読みながら数えられるもので、一覧には溜められないからです。レポートは件数だけを出し、エラー 1 件とヘッダーの損失 1 件は同じ事実の裏表です。正確な cue が必要なら、cue 番号ではなくタイムコードの並びをファイル内で検索してください。
1 ミリ秒しか続かない cue は問題ですか？
この頁では問題ありません。意図して書かれた 1 ミリ秒の cue は正当で、報告されません。報告されるのは修復が必要だったタイムコードで、その結果たまたま 1 ミリ秒として保持されているものです。修復ではなく表示時間を見る検査にすると、ゼロ長の cue を含むファイルを、あり得ない短さの cue だらけだと二重に誤判定します。
この頁は見つけたタイムコードを修正しますか？
いいえ。修復された時刻はブラウザ内にだけ存在し、残りを読んで報告するために使われます。投入したファイルは変わらず、この頁から修復版を保存する方法もありません。壊れたタイムコードを置き換えるのは、字幕ファイルを出力する操作であって検査ではありません。
どの字幕形式を「開始より前に終わる cue」の検査に使えますか？
12 形式のうち 10 形式です。SRT、WebVTT、ASS、SSA、SBV、SMI、MicroDVD、TTML、JSON、CSV が使えます。LRC は 1 行に 1 つの時刻しか持たず、読み込み側が次のタイムスタンプから終了を導くので逆転しません。プレーンテキストには cue の時刻がありません。その 2 形式なら先に変換してください。
壊れたタイムコードはどこから生まれるのですか？
入力されるというより、生成されることがほとんどです。丸めの向きを誤ったフレームレート変換、同じ cue に二重に適用されたシフト、終了列が空のまま 0 として読まれた表計算の書き出し、もともと長さのないマーカー付きのタイムドテキストから抽出した字幕などです。
複数のファイルを一度に検査できますか？
できます。好きなだけ投入すると 1 つずつ読み込まれ、それぞれにレポートが付き、まとめて zip でダウンロードできます。進捗はファイル単位で表示され、途中で中止でき、どの時点でもファイルはアップロードされません。