字幕ファイル形式の早見表|SRT・WebVTT・TTML・ARIBの使い分け

納品先から「字幕はIMSCで」と指定されて、手が止まったことがあります。手元にあるのはSRT。拡張子を変えれば済む話なのか、作り直しなのか、その場では判断がつきませんでした。

字幕のファイル形式は、動画の形式ほど話題になりません。それでいて、指定を間違えると受け取り側で開けないか、開けても表示が崩れます。しかも崩れ方が分かりにくい。文字は出ているのに、ルビだけが本文と同じ大きさで行の中に紛れ込んでいる、といった壊れ方をします。

ここでは実務で出会う4系統を並べて、どれをどこに出すのかを整理します。先に結論を書いておくと、選ぶ基準は機能の多さではありません。

形式が分かれているのは、再生する場所が違うから

字幕ファイルは、映像に文字を焼き込む代わりに、いつ・どこに・何を出すかを別ファイルに書き出したものです。この「どこに」と「どう見せるか」をどこまで書けるかが、形式ごとの差になっています。

そして書ける量は、再生する場所の都合で決まってきました。HTMLの動画プレーヤーで再生するなら、CSSに近い考え方で位置や色を指定できたほうが都合がいい。テレビの受信機で表示するなら、受信機側が解釈できる符号の範囲に収めないといけません。同じ「字幕」でも要求がまるで違う。

つまり形式の違いは、機能の優劣ではなく出口の違いです。ここを取り違えると、多機能な形式を選んでおけば安全という判断をしてしまいます。実際には、受け取り側が解釈できない情報は無視されるか、エラーになるだけです。

4系統の早見表

表にすると右へ行くほど高機能に見えます。ただ、この並びは能力の順位ではありません。左の2つはテキストエディタで開いて中身を直せる形式で、右の2つは専用のツールがないと実務にならない形式です。直せることは、それ自体が現場での価値になります。

SRTファイルの中身と書き方は行番号とタイムコードとテキストの3要素だけでできていて、壊れたときに原因を目で追えます。障害対応の速さが効く現場では、この素朴さが選定理由になることがあります。

変換で落ちるものは、開いても分からない

SRTとWebVTTは似ています。似ているせいで、変換すれば済むと思われがちです。

分かりやすい落とし穴はタイムコードの区切り文字です。SRTはミリ秒の前がカンマ、WebVTTはピリオドを使います。ここを直さないまま拡張子だけ変えると、多くのプレーヤーが読み込みに失敗します。冒頭にWEBVTTの1行が要る点も含めて、WebVTTとSRTの変換で注意する点は数が限られていて、機械的に潰せます。

やっかいなのは逆向きの変換です。WebVTTで位置や色を指定していた字幕をSRTに落とすと、その指定は消えます。ファイルは開けますし、文字も出る。消えたことに気づくのは、画面を見たときです。

同じことが、もっと大きな落差で起きるのがルビです。IMSCで組んだルビ付きの字幕をSRTへ渡すと、ルビは行内の文字として残るか、まるごと消えるかのどちらかになります。前者のほうがたちが悪い。読み仮名が本文と同じ大きさで台詞に混ざり込み、文字数チェックだけを見ていると異常として引っかかりません。

文字コードも落ちどころです。UTF-8のBOMをどう扱うかはプレーヤーによって違い、先頭のキャンセル番号だけが読めないという症状で出ることがあります。1つめの字幕だけが出ない、という報告が来たらここを疑うと早いはずです。

つまり変換の検証は、ファイルが開けたかどうかでは足りません。装飾を持つ形式から素朴な形式へ落とすときは、落ちたものの一覧を先に把握しておくしかない。

日本語の字幕でTTMLが出てくる理由

TTMLはW3Cが策定したXMLベースの形式で、その実運用向けのプロファイルがIMSCです。日本語の字幕納品でこれが指定されるのは、ルビと縦書きが書けるからです。

Netflixは日本語のタイムドテキストについて、IMSC 1.1をxml拡張子で納品するよう求めています。ルビはtts:rubyという属性で表現し、値はcontainer、base、textの3つに限られます。ルビを2行にまたがって配置してはいけない、といった運用上の決まりもあります。

こうした細かい規定があるということは、逆に言えば受け取り側がその通りに解釈すると決めているということでもあります。表現力の高い形式ほど書き方の自由度も上がるので、プロファイルで範囲を絞らないと相互運用が成り立ちません。IMSCという名前が指しているのは、そこで絞られた後の範囲です。

このあたりは、日本語字幕が長く抱えてきた問題そのものです。ルビ、傍点、縦書き、縦中横。欧文向けに作られた形式では表現できないものが日本語には多く、国内では独自の納品形式が使われてきました。IMSCの普及は、その独自形式を国際規格の側へ寄せていく動きとして見ると分かりやすくなります。

放送に出すものだけは、系統がまるごと違う

ここまでの3つは、突き詰めればテキストとその修飾です。放送はそこから外れます。

地上デジタル放送で視聴者が切り替えるあの字幕は、受信機が解釈する符号として送られています。文字コードも放送独自のものが使われ、外字の扱いも決まっています。制作側から送出側へ字幕ファイルを渡すときの交換フォーマットがARIB STD-B36で、放送波に乗せる側の符号化などを定めているのがSTD-B24です。同じ字幕の話でも、規格が受け持つ工程が違います。

そのため、Web用に作ったSRTを放送にそのまま流用することはできません。逆も同じです。放送用に整えた字幕は、行分割の規則も表示時間の考え方もWeb向けとは違っていて、放送字幕とWeb字幕の作り方の違いは最終的な出口の要求から来ています。

素材がMXFに多重化されて渡ってくる形もあり、その場合はファイルとして字幕を受け取ることすらありません。

決めるべきは形式ではなく、原本をどれにするか

指定された形式に合わせるだけなら、変換で足ります。難しくなるのは、同じ番組をテレビにも配信にもSNSにも出すときです。

出口ごとに形式が違い、それぞれで求められる装飾も違う。ここで出口の数だけ字幕を作り直すと、修正が入るたびに全部を直すことになります。台詞のひとことを直すのに、4つのファイルを開く。

そうならないように、最も情報量の多い形式を原本にして、そこから各出口へ書き出す形にしておく。ルビや位置指定を持つ形式を原本にすれば、落とすことはできても、失われたものを後から足すことはできないという非対称性を味方にできます。

AIで字幕を作る場合も同じで、認識結果をどの形式で保持しておくかは、後工程の手戻りの量を決めます。認識の精度を上げる話と、その結果をどう持ち回るかの話は別のもので、後者を決めないまま運用に入ると、出力のたびに手作業が挟まります。

では、その原本を何で作るのでしょうか。ルビと位置指定を持ったまま編集できるツールは限られていて、多くの現場ではそこが実質的な制約になっています。形式の一覧より先に、手元のツールが何を保持できるかを確かめたほうが早いかもしれません。

NAXAの取り組み

NAXAのSubtitle Generatorは、音声認識から字幕への整形までを扱い、SRTをはじめとする字幕ファイルとして書き出せます。放送とWebで求められる形が違うという前提に立って、出口に合わせた出力を設計しています。