VTT を SBV に変換

WebVTT は余白のある文書形式です。必須のヘッダー、任意のキュー識別子、コメントのブロック、スタイルのブロック、タイミング行に付け足せる設定、本文の中のインラインタグ。これらはすべて理にかなった理由で存在していますが、欲しいものが瞬間の一覧とそこで何が話されたかだけなら、すべて邪魔になります。

SBV にはそのどれもありません。タイミング行、文字、空行、次のエントリ。それだけです。だからこそ、作られた道具の形が変わったあとも作業用ファイルとして生き残り、次にすることが人による全行の確認や、カンマで分割するスクリプトであるときの、理にかなった変換先になります。

ヘッダーは消えます。SBV にはないからです。キュー識別子も消えます。SBV には番号付けや命名の仕組みが一切ないからです。NOTE と STYLE のブロックも消え、これは構造上の理由があります。あるブロックがキューだと認識されるのはタイムスタンプの矢印を含んでいるからで、この二つはどちらもそれを含まないため、字幕の本文として誤読される代わりにそのまま読み飛ばされます。

キュー設定も消えます。終了時刻のあとに書かれた line、align、position、size といった設定は、最初の空白まで読まれてそこで捨てられます。トラックが画面上の文字を避けるために配置を利用していたなら、その配置は出力から復元できず、WebVTT ファイルだけがその唯一の記録です。

1 行に両方の時刻がカンマで区切られて入ります。0:04:12.500,0:04:15.100 のようにです。ミリ秒の前のピリオドは WebVTT と同じなので、そこは考える必要がありません。変わるのは時間の桁で、SBV はゼロ埋めせずに書きます。この違いこそが、リネームでは失敗し、変換すれば成功する分かれ目です。

時刻の数値そのものは触れられていません。すべての値はミリ秒単位で保持されたまま変換され、ミリ秒精度で書き戻されるので、各エントリは VTT にあったのとまさに同じ瞬間に始まり終わります。何も丸められず、切り詰められず、ずらされません。数字の周りの句読点だけが変わります。

これがこの削ぎ落としの限界で、はっきり書いておく価値があります。字幕の本文はそのままコピーされます。斜体タグ、太字タグ、話者名を示す voice タグ——そのすべてが WebVTT から SBV へ、ただの文字として運ばれます。字幕の中身を解釈する仕組みが何もないからです。

SBV にはスタイルという概念が一切ないので、それらのタグは適用されるのではなく画面にそのまま表示されます。目的が本当に何も入っていないファイルだったなら、検索置換一回で作業は終わります。WebVTT の側で先にやっておくほうが良い習慣です。そちらのファイルこそ、来月また誰かが変換するものだからです。

流通している WebVTT ファイルの多くは自動文字起こしから来ており、SBV の構造はその修正作業に向いています。タイミング行は読み飛ばせるほど短く、本文は独立した行にあり、字幕を分割・結合しても振り直す番号がありません。

直す価値が高い順に並べると、まず固有名詞と専門用語です。認識器が最も間違えやすく、その間違いが意味を変える部分です。次に改行で、機械の出力はバッファーが吐き出したところで区切られ、意味の切れ目とは限りません。最後に字幕の長さで、認識器には視聴者が読むのにどれだけ時間が要るかという感覚がありません。どれも形式の問題ではなく、それこそが自動文字起こしが流し読みには十分でも公開には向かない理由です。

ひと手間省くこつは、始める前に固有名詞を集めておくことです。話者名、社名、商品名、地名、その録音が前提にしている略語を、説明文やスライドから書き出し、字幕ファイルの中で一つずつ検索してください。認識器はランダムにではなく一貫して間違えるので、一度間違えた名前は毎回同じように間違えており、一回の検索置換で三十か所を直せます。上から下へ読んで探すのは、同じ作業を一時間かけて行うのと同じことです。

SBV は Google 独自の形式で、2008 年から YouTube の字幕エディターが書き出してきた形式です。それをアップロードすると、動画のタイムラインに沿って編集し直せる状態に戻り、本文よりも時刻を直す作業にはいちばん速い方法です。

ただし正直に言えば、YouTube は WebVTT を直接受け付けるので、この変換は動画に字幕を付けるための前提条件ではありません。この形式が意味を持つのは、作業の場がそのエディターであるとき、ワークフローの中のスクリプトが書き出し形式を前提にしているとき、あるいは既存の字幕アーカイブがすでに SBV で、そこに WebVTT で届いた新しいファイルだけが浮いているときです。

字幕ファイルへの需要のかなりの部分は、字幕そのものとは無関係です。人々が欲しいのは文字です。講演を記事にする、話者の発言を正確に引用する、二時間の録画から必要な四分間を検索する、といった用途です。それらにとって時刻は雑音で、SBV は目的地というより通過点です。

そのために整理されたファイルは、最後の一歩を簡単にします。二つのタイムスタンプに挟まれたカンマを含む行を全部消せば、残るのは文字起こしです。正規表現の使えるエディターでも、どんなスクリプト言語でも三行で済みます。どの変換も直してくれないのは、元になった言葉そのものの信頼性で、認識器から得た文字起こしは引用する前に音声と突き合わせる必要があります。

次の工程が人ではなくコードなら、ファイルの形がコードの量を左右します。WebVTT のパーサーは、任意のメタデータを伴う任意のヘッダー、識別子が付くこともあれば付かないこともあるブロック、設定を伴うこともあるタイミング行、そしてキューではなくコメントやスタイルであるブロックを処理しなければなりません。

SBV のパーサーは空行で分割し、最初の行をカンマで分割し、残りを本文として扱うだけです。この違いは実質的なもので、スクリプト作業のためにこちらへ変換する正直な理由です。同時に、保守されている WebVTT パーサーを使うという選択肢とも比較する価値があります。そちらは面倒な例外を正しく処理してくれ、コストは一つの依存関係で済み、半日分の例外処理を書く手間より安く済みます。

字幕ファイルの修正はたいてい、文字を直すだけでなく境界を変える作業でもあります。文中で途切れているエントリは分割したく、認識器が分けてしまった断片は結合したくなります。SubRip ではそうした編集のたびにその先の番号がすべて無効になり、テキストエディターで直したファイルは、214 番が二つある、あるいは 300 番の次が 302 番に飛ぶといった具合になります。

SBV には壊れる番号がありません。エントリの分割はタイミング行と空行を足すだけ、結合はそれらを削るだけです。編集後に触るべきものは何もなく、数えているプレイヤーも配信先もありません。これは SBV が得意とする唯一の仕事における確かな利点で、ここで修正して変換し直すほうが、SubRip のファイルに直接手を入れるより誤りが少ないことが多い理由です。

アーカイブとしては、ありません。YouTube の外ではほとんど読まれず、WebVTT や SubRip が持たない情報を運ぶわけでもなく、字幕がどこから来たのか、何を避けるために配置されたのかという記録も何も残りません。SBV ファイルだけのフォルダーは、いろいろなことを忘れてしまったフォルダーです。

1 回きりの作業用ファイルとしては優秀で、この違いは覚えておく価値があります。変換し、修正し、アップロードするか解析し、WebVTT のほうを立ち戻る先として残してください。修正を SBV 側で行ったなら、二つのコピーを食い違わせたままにせず変換し直してください。言葉自体はどちらの形式でも同じなので、どちらの方向へ動かしても何も失われません。