VTT を SRT に変換

WebVTT はブラウザーのために存在し、その仕事をとてもよくこなします。それがこの形式の限界でもあります。デスクトップのプレイヤー、テレビ、メディアボックス、USB メモリーから字幕を読み込むほとんどのハードウェア、多くのアップロードフォームは SubRip を期待し、それ以外を未知のファイルとして扱います。この変換への需要は、ほぼすべて同じ 1 文の言い換えです。字幕ファイルは、それが出てきた Web ページの上でしか動きません。

よくある由来を名指しておく価値があります。あとで確認すべきことが変わってくるからです。Web のプレイヤーからダウンロードされた VTT はキューの設定を運んでいる可能性が高いです。文字起こしサービスから書き出されたものは、各話者を示す音声タグを運んでいる可能性が高いです。字幕エディターで作られたものはたいてい素朴で、掃除するもののないきれいな SRT に変換されます。

WebVTT のタイミング行は、終了時刻のあとに設定を持てます。キャプションをフレームの上部へ押し上げる行番号、位置揃え、幅など。変換ツールは終了タイムスタンプを最初のスペースまで読み、それ以降を捨てます。SubRip にはそれを持てる構文がないからです。

これがこの変換における唯一の本物の損失で、出力を見ても気づけません。字幕が意図的に配置されていた場合——下段のテロップが表示される数秒間だけ上部に移動されていた、あるいは焼き込まれた文字とぶつからないよう幅が狭められていた——SRT は正しく見えても、すべての行を下段に置いてしまいます。位置指定が重要な場合、正直な答えは VTT をマスターとして保ち、SRT は、より良い扱いができないプレイヤー向けの納品用コピーとして扱うことです。

キューの文字は解釈されずにそのままコピーされます。これはイタリックには正しい振る舞いです。どちらの形式も同じ書き方をするからです。行の前に山括弧で話者名を記す WebVTT の音声タグには、間違って見える振る舞いになります。SubRip にはそれに相当する構文がないので、タグは翻訳もされず削除もされません。

プレイヤーはそれをそのまま表示します。字幕は、山括弧に入った話者名のあとにセリフが続く形で読めてしまい、誰も意図していないものです。文字起こしの書き出しがよくある由来で、直すには、できあがった SRT に対して検索置換を行い、タグを削除するか、SubRip が昔から複数話者を扱ってきた方法であるコロン付きの話者名の慣習に変えるかのどちらかです。

どちらを選ぶかは、誰が見るかによります。タグを削除するのは、翻訳されたセリフのトラックにとって正しい選択です。話者が画面に映っており、名前を記すことは読む時間を無駄にするだけだからです。名前に変換するのは、聞こえない視聴者向けのキャプションや、画面外で交互に話す 2 人の声を視聴者が本当に聞き分けられないインタビューやパネルディスカッションにとって正しい選択です。後者の場合、タグは本物の情報を運んでいたので、それを黙って取り除くことは、誰にも報告されない小さなアクセシビリティの後退になります。

WebVTT ファイルは NOTE で始まるコメントブロックや、キューの疑似要素向けの CSS を運ぶ STYLE ブロックを含むことがあります。どちらもタイムスタンプの矢印を含まず、パーサーは行数を数えるのではなくその矢印を探してキューを見分けるので、どちらも文字と間違われることなく読み飛ばされます。

この実務上の価値は、何もないという形で表れます。SRT には本物のキューだけが含まれ、VTT の制作層からは何も漏れてきません。それに伴うコストは、そのブロックで定義されていたスタイルが失われることで、読みにくい色を読みやすくするといった、機能上重要な役割を果たしていた場合には問題になります。SubRip は見た目の判断をすべてプレイヤーに委ねる設計です。

WebVTT のキューは通常番号を持たず、タイムスタンプの上に行が現れる場合、それは連番ではなく識別子——スタイルシートやスクリプトが参照できる名前——です。SubRip は連番を期待するので、変換ツールは元データが何を持っていたかにかかわらず、1 から始めて数え上げた番号を書きます。

これは手作業で編集されたファイルにとって望ましい副作用を持ちます。識別子が不揃いだったり重複していたり欠けていたりする VTT は、最初から最後まできれいに番号付けされた SRT になります。同時に、頼っていた識別子は失われるということでもあります。スクリプトがキュー名で参照していたなら、この変換のあとは別の目印が必要になります。

すべての時刻は内部でミリ秒として保持され、時、分、秒、ミリ秒として書き戻されます。時は 0 埋めされ、小数部の前にはカンマが付きます。どちら方向にも丸めは発生しないので、VTT で 00:04:12.500 から始まったキューは、SRT でミリ秒単位まで正確に 00:04:12,500 から始まります。

これを正確に述べておく価値があります。カンマこそ、誰かがファイルを編集したあとに字幕ファイルが拒否される典型的な原因だからです。どちらの形式も同じものを同じ精度で計測しており、違うのは小数点の記法だけです。この 2 つの間の変換がタイミングをずらすと主張するものは、別のバグについて語っています。

出回っている WebVTT ファイルの多くは自動文字起こしで作られており、この変換はそれを改善しません。自動出力はざっと目を通すには十分ですが、公開するには不十分で、間違えがちなのは、文の意味を運ぶ固有名詞や専門用語です。

もう 2 つ、機械的な欠陥も見ておく価値があります。機械の書き起こしは、文節の切れ目ではなく認識エンジンがバッファーを吐き出したタイミングで行を分けがちで、読者が追いきれないほど長かったり短かったりするキューを作りがちです。SRT の中でそれらを直すのは簡単です。構造が明快なテキストだからです。それが、読める字幕と、読むのをあきらめる字幕の違いになります。

ほとんどのプレイヤーは、字幕ファイルが動画と同じベース名で隣に置かれていれば自動的に読み込みます。film.mp4 と film.srt が同じフォルダーにある形です。1 文字でも違えば何も表示されず、これが「変換が失敗した」という報告の多くの原因で、実際には失敗していません。

複数の言語がある場合、film.en.srt のように拡張子の前に言語の接尾辞を付けるのが慣習で、一般的なプレイヤーはそれを理解します。それ以上になると、テレビやメディアボックスはデスクトップのソフトより気難しく、多くは動画と同じパーティションからしか字幕を読まず、かなりの数が SubRip しか読みません。これがこの変換が存在する理由です。

変換ツールは空の SRT を返すのではなく拒否します。ファイルの解析結果が何もなければ、それはエラーとして扱われ、そう伝えられます。キューが 0 個の字幕ファイルは問題なくダウンロードでき、問題なく読み込まれ、何も表示しません。視聴者は、変換が静かに失敗したのだとは考えず、単に動画に字幕がないのだと合理的に結論づけてしまいます。

原因の大半は 2 つに集約されます。1 つは、そもそも WebVTT ではないファイルです。上流の誰かがリネームしたキャプションファイルや、ストリーミング URL からのダウンロードが失敗したときによくある、.vtt という拡張子で保存された HTML のエラーページなどです。もう 1 つは改行コードです。キューは空行で区切られ、パーサーは Unix と Windows の慣習を認識します。昔ながらの Mac の復帰のみの改行で保存されたファイルは、この処理から見ると、非常に長い 1 行だけで空行が 1 つもない状態になります。現代的なエディターで保存し直せば一発で直ります。

圧倒的多数のファイルにとっては正確です。素の WebVTT トラックの中身は文字とタイミングだけで、どちらもミリ秒単位、文字単位で残ります。この変換が瞬時に終わり、誰も出力を確認する必要がない理由です。

例外は上で名指した 3 つで、まとめて言い直しておく価値があります。それらについて何も言わない変換ツールのほうが心地よく見えて、役に立たないからです。位置指定は捨てられ、音声タグは見える文字になり、キューの識別子は番号に置き換えられます。ファイルがこの 3 つのどれも使っていなければ——実際、ほとんどのファイルはそうです——SRT は句読点が違うだけの同じ字幕です。