SRT を VTT に変換

HTML の動画は track 要素を通じて字幕を受け取り、その要素が受け付ける字幕形式は WebVTT だけです。ブラウザーに SRT を渡すと何も起きません。コンソールにエラーは出ず、字幕メニューにも項目は現れず、ただ字幕なしで動画が再生されるだけです。この沈黙こそが、この変換にたどり着く人の多くが持つ経験です。ファイルは正しく、マークアップも正しく、間違っているのは形式ただ一つだからです。

二つの形式がとても近い親戚であることが、この失敗を必要以上にわかりにくくしています。構造として見れば、WebVTT ファイルはヘッダー行と異なる小数点記号を持つ SubRip ファイルです。ブラウザーは何か大きなことに異議を唱えているわけではなく、正しい形からわずか二つの機械的な編集で届く距離にあるファイルを拒んでいるだけで、この変換器はその両方を行います。

一つ目はタイムスタンプです。SubRip はミリ秒の前にカンマを置いて 00:01:32,500 と書き、WebVTT はピリオドを置いて 00:01:32.500 と書きます。1 つの字幕に文字 1 個の差が 2 回現れ、カンマを見つけたパーサーはそこで読むのをやめます。世界の多くは小数をカンマで書くため、手編集したファイルにこの不備がよく紛れ込みます。

二つ目はヘッダーです。WebVTT ファイルは最初の 1 行目に、他の何よりも先に WEBVTT という単語を書かなければなりません。これは説明文でも省略可能なものでもなく、それがないファイルはきっぱり拒否されます。ここで作られる出力は WEBVTT の後に空行を置いて始まり、すべてのタイムスタンプを、時・分・秒・ミリ秒の順で時をゼロ埋めし、小数点の前にピリオドを置いて書きます。

ほとんど誰もが最初に試すことで、無理もありません。ファイルはテキストで、構造は似ていて、拡張子を変えるのは 1 秒でできます。それでもうまくいきません。上記の二つの違いはどちらもファイル名の中には存在しないからです。結果は WebVTT を名乗り、WebVTT として配信されながら、1 行目でパーサーに捨てられるファイルです。

これが厄介なのは、失敗が別の何かのように見えることです。ファイルを改名した開発者は、track 要素やファイルパス、MIME タイプ、プレーヤーを次々確認しますが、どれも問題ではありません。きちんと変換しておけばこの可能性はまるごと消え、マークアップに午後をまるごと費やす前に済ませておく価値があります。

SubRip はすべての字幕に 1 から番号を振り、タイムスタンプの上の行に書きます。この変換器はその番号を読み取りますが、何にも使わず、VTT には書き込みません。出力はヘッダー、空行、そのあと空行で区切られたタイムスタンプと本文のブロックです。

これは損失ではなく設計上の判断です。WebVTT はタイムスタンプの前の行を、カウンターではなく任意の識別子として扱い、ブラウザーやプレーヤーの側でそれに依存するものはありません。個々の字幕に本当に付けたいもの——垂直位置、揃え、幅——は終了タイムスタンプの後に書く cue 設定であり、その前に番号を置いてもノイズにしかなりません。

すべての字幕本文は SRT から VTT へそのまま複製されます。何も取り除かれず、エスケープもされず、解釈し直されもしません。両方の形式は斜体や太字を同じ山括弧タグで表現するため、強調に使っているファイルはウェブページ上でもその強調を保ちます。

公開前に確認しておく価値があるのは、その先です。SRT の中でデスクトップソフトが解釈する独自コード——中括弧で囲んだ ASS 風の位置指定タグがよくある例です——も同じようにそのまま渡り、ブラウザーはその意味を知らないので、字幕の中に生の文字として表示してしまいます。ファンサブやメディアセンター向けのワークフローから来た SRT なら、出力の最初の数個の字幕を確認してください。

track 要素は video 要素の内側に置き、src にその .vtt を指す、kind を設定し、srclang に言語コードを設定し、字幕メニューに表示される label を付けます。動画の再生開始時から字幕を出したいなら default 属性を足してください。そうしないと視聴者はメニューを自分で探さなければならず、ほとんどの人はそこまでしません。

kind 属性は、コピーせずきちんと考える価値があります。subtitles は音声を聞き取り翻訳できる視聴者を前提とし、captions は音声を聞けない視聴者を前提として台詞以外の音も説明します。captions がアクセシビリティ上の義務である場面で、翻訳された台詞だけを含む track に captions と印を付けても、マークアップの要件は満たしますが本来の要件は満たしません。

ヘッダーとタイムスタンプが正しく、それでも字幕が出ない場合、残る原因はファイルではなくページ側にあります。track 要素に kind や srclang が抜けているか、default 属性がどこにもないため視聴者が字幕を一度も切り替えていない場合です。

いちばん時間を食うのはクロスオリジンです。ページと別のオリジンから配信された VTT——別のアセットドメイン、バケット、CDN ホスト名——は、正しいクロスオリジンヘッダーがない限り拒否され、その拒否は静かです。動画は再生され、メニューは空のままで、ページ上には理由を示すものが何もありません。字幕ファイルをページと同じオリジンから配信すれば、この種の問題全体を取り除けます。順番に一つずつ確かめてください。複数を同時に変えると、二つ直しても三つ目がまだ間違っていて、どちらも直っていないように見えます。いちばん早い切り分けは .vtt の URL を直接タブで開くことです。テキストとして表示されればパスとサーバーは問題なく、原因はマークアップかオリジンにあります。ダウンロードされるか 404 になるなら、track 要素の話はそもそも関係なく、残る作業はホスティングの問題です。

字幕編集ソフトや文字起こしサービス、デスクトップツールはこのサイトの他のどの形式より SRT を得意としていて、業界全体がそれを前提にしています。テキストとタイミングをそこで修正し、公開のタイミングで変換するのが理にかなった役割分担です。

避けるべき失敗パターンは両方を保守してしまうことです。同じ内容から始まった二つのファイルは、誰かがどちらかを開いて誤字を直した瞬間からずれていき、そのずれは視聴者が原稿にない字幕を読むまで見えません。VTT はビルド成果物として扱ってください。生成するもので、編集するものではありません。

ファイルは WebVTT のメディアタイプ text/vtt で生成され、最終的にホストするサーバーも同じものを送る必要があります。今どきの静的ホスティングは .vtt 拡張子を正しく扱いますが、古い設定の一部は汎用のバイナリ型や text/plain に落ちてしまうことがあり、誤った型で字幕ファイルを渡されたブラウザーはそれを拒否する権利があります。ヘッダーとタイムスタンプが正しいのに track が読み込まれないなら、次に確認すべきはレスポンスヘッダーで、いちばん早く確かめられる場所でもあります。

運用面で時間を節約できる細部が二つあります。字幕ファイルは小さくめったに変わらないのでキャッシュが効きやすいですが、あとで修正するファイルに長いキャッシュ期間を設定すると、修正が公開されたあとも視聴者の端末に誤りが残り続けます。パージに頼るのではなくファイル名をバージョン管理してください。ビルドパイプラインがフィンガープリントを付けたがっても拡張子は .vtt のまま保ってください。いくつかのプレーヤーやバリデーターは、トラックを取りに行く価値があるかどうかをメディアタイプではなく拡張子で判断しているためです。

ブラウザーの中で、JavaScript として、アップロードも待ち行列もなく動きます。ファイルはテキストとして読み込まれ、ミリ秒単位のタイミングを持つ字幕の一覧に解析され、WebVTT の形式で書き戻されます。サーバーは一切関わらないため、これが瞬時に終わり、登録も不要な理由です。

無料枠は 100 MB で、どんな字幕ファイルもそこに近づくことはありません。長編映画でもテキストとして数十キロバイトです。もっと実用的な保証は、出力が UTF-8 として書き出されるという点です。SubRip には自分の文字コードを宣言する手段がなく、それがアクセント付き文字がよく崩れる理由です。出力を UTF-8 に固定することがブラウザーの期待するものであり、変換の時点でその問いを片付けています。