SBV を VTT に変換

その動画にはたいてい理由があります。ファイルそのものを求めるコース配信サービス、外部の埋め込みを避けたいサイト、YouTube プレイヤーをブランド規定が許さないクライアント、あるいはそもそも公開の場に置くべきではない収録内容。動画自体はエンコードとアップロードで済みます。字幕だけが止まります。

SBV は Google 独自の形式で、YouTube の外ではほとんど誰にも読まれず、当然ブラウザーも読めません。HTML の動画は track 要素で字幕を受け取り、対応するのは WebVTT だけです。元のプラットフォームでは完璧に動いていた字幕ファイルが、移した先のページでは字幕メニューが空のままになります。

WebVTT ファイルは、何よりも先に、独立した 1 行目に WEBVTT という語がなければなりません。これは注釈ではなく必須事項で、パーサーはそれを見つけられなければそれ以上読まずにファイルを拒否します。SBV にはヘッダーの構造そのものがなく、ファイルの 1 行目は最初のタイミング行です。

つまり変換の元になるものがなく、書き足すしかありません。変換ではヘッダーと空行を書いてから字幕を続けます。これがリネームで済ませられない理由であり、手作業での書き換えで最も見落とされやすい部分です。元のファイルにまったく対応がない唯一の要素だからです。

SBV は両方の時刻を 1 行にカンマ区切りで書きます。WebVTT は 1 行にアロー区切りで書き、時間の部分は 2 桁のゼロ埋めになります。ミリ秒の部分はどちらもすでにピリオドの後ろに 3 桁で書かれているので、そこは変更不要です。

時刻の数値そのものは正確です。すべての値はミリ秒単位で保持されたまま変換されるので、SBV で 0:04:12.500 だった字幕は VTT で 00:04:12.500 になります。何も丸められたり、切り詰められたり、ずれたりせず、両者は同じ精度で同じものを測っています。違うのは数字の周りの表記だけです。

SBV ファイルの多くは自動文字起こしで、変換しても言葉そのものが良くなるわけではありません。音声認識は普通の会話には強い一方で、固有名詞や地名、商品名、専門用語には弱く、しかもそれらは文の意味を運ぶ言葉です。

自分のサイトに載せる段になると、この点がより重く効いてきます。日本でも 2024 年の障害者差別解消法の改正で、事業者にとって合理的配慮の提供が努力義務から義務へと変わり、動画の字幕はその対象になり得ます。確認していない機械の文字起こしをそのまま公開するのは、その配慮を満たしたことにはなりません。しかも精度だけの問題ではなく、字幕には本来、画面外の話者や音楽の始まりといった非音声の情報も含まれるべきで、認識エンジンはそれらを一切生成しません。

すべての WebVTT の字幕は、終了時刻の後ろに設定を書き加えられます。縦位置を動かす line、横位置を動かす align、position や size もあります。SBV にはこの仕組みが一切ないので、変換直後のファイルには設定が何もなく、すべての字幕が画面の下に置かれます。

これを書き加えることは、自分のサイトで動画を配信するときに最初にやる価値のある改善です。画面の下はプレイヤー自身のコントロールが置かれ、映像制作者がロワーサードを置く場所でもあり、そこに重なる字幕がいちばん多い苦情の種です。タイミング行に数語加えるだけで、その数秒だけ字幕をずらせます。どんな CSS を書いても同じことはできません。

SBV には話者を示す仕組みがないため、それが必要な字幕ファイルは慣習で対処してきました。名前とコロン、あるいは放送字幕が昔からしてきたように行頭のダッシュです。それらの文字は WebVTT にそのままコピーされ、入力した通りに画面に表示されます。

WebVTT には話者を示す正式な仕組み、voice タグがあり、ブラウザーは話者ごとに見た目を変えられ、スクリーンリーダーはそれを本文ではなく話者情報として読み上げられます。打ち込まれた慣習を voice タグに置き換える作業は検索置換で済み、変換された字幕ファイルに対して価値のある数少ない手作業の一つです。

ページと違うオリジンから取得された WebVTT ファイルは、適切な CORS ヘッダーがない限り拒否され、しかもその拒否は静かに起こります。動画は再生されるのに字幕メニューは空で、コンソールには理由が何も出ません。原因の切り分けが最も難しい失敗で、ほかのどの原因とも見分けがつかないように見えるからです。

.vtt を HTML と同じオリジンから配信すれば、この種の問題を丸ごと避けられます。字幕ファイルを別のアセット用ドメインやバケットに置かず、ページのそばに置いておく理由がここにあります。どうしても別の場所に置くなら、CORS ヘッダーと video 要素の crossorigin 属性の両方を正しく設定し、ブラウザーで実際に確かめる以外に確認する方法はありません。もう一つよく見落とされるのが media type で、.vtt は text/vtt として配信されるべきです。汎用のバイナリ型や text/plain にフォールバックする設定では、ブラウザーが無視する根拠になります。.vtt の URL を直接タブで開いて、ページと同じオリジンからテキストとして表示されれば、ファイルと配信設定の両方に問題はなく、原因はマークアップ側にあります。

動画を YouTube にも残したまま自分のサイトにも置くと、字幕ファイルは 2 つになります。最初は同じでも、どちらか開いていたほうで誤字を直した瞬間から食い違い始め、どちらが正しいかはどちらのファイルにも記録されません。

どちらか一方を正本と決め、もう一方をそこから生成してください。修正がまれで、チームがすでに YouTube 上で作業しているなら、YouTube 側を編集して再ダウンロードする運用が現実的です。自分のサイトが主な公開場所なら、WebVTT を編集して YouTube にアップロードする——YouTube は WebVTT を直接受け付けます——ほうが良く、その場合維持するファイルには位置指定や voice タグが入ったままになり、それらは再ダウンロードでは失われてしまう情報だからです。

kind 属性には subtitles や captions 以外の値もあり、同じ WebVTT の記法をそのまま使えます。chapters は対応するプレイヤーで章の一覧として扱われます。descriptions はスクリーンリーダー向けの音声解説用の文章を運びます。metadata は画面に表示されない任意のタイミング付き情報を運び、再生位置がそこに達するたびに JavaScript が反応できます。

最後のものは、インタラクティブな文字起こしやスライドとの同期、タイミング付きの注釈を作る仕組みで、自分のサイトで配信するときに知っておく価値があります。元のプラットフォームにはその機能があり、こちらのページにはまだありません。kind を chapters にした二本目のトラックファイルは数行の WebVTT で済み、長い収録に対して視聴者が本当に望むもの——見たい場面まで飛ばす手段——を提供できます。