前 8 - 12 P ｜ 
もくじ I ｜ 次 8 - 14 N 
SSAは強力なスタイリング能力を持つ字幕データのファイル形式です。 AVI、OGM、MKVなどの動画ファイルは、映像の一部、または別ストリームとして、SSA形式の字幕を含むことができます。 SSAファイルの作成自体については、 「SSA入門 タイミング編」を見てください。
狭義の SSA は Advanced SSA (ASS) のサブセットですが、一般的な用途にはほぼ十分な表現力を備えています。 ASS では、さらに強力で柔軟なさまざまエフェクトを使えます。
この記事では、SSAファイルを編集して字幕の表示を制御する「スタイリング」作業（typesetting）の初歩を説明します。 さらに進んだ作業については「字幕作成 SSA中級編」を見てください。 エフェクトを使いこなすには「ASSについて」も研究する必要があります。 カラオケは奥が深いため、 （SSAではなく）ASSの技法として、別に説明します。 簡易的な（といっても実用上は十分な）カラオケ字幕については、 「むびカラ」 「アニカラのススメ」 「カラオケしようぜ！！」などをごらんください。 SweetKaraoké - Sous-titrage de karaokés。
このリファレンスの最新版は下記URLにあります。
フィードバックは、掲示板にお願いします。
http://www.faireal.net/articles/8/13/
今回のテーマは「SSAの作成」（タイミング）ではなく「SSAの編集」（タイプセット）で、 既に存在しているSSAをテキストエディタで開くところから始めます。
タイミングとタイプセットは切り離し可能な別分野であり、 「タイミング編」の知識は必ずしも必要ありません。 既存のSRTやSSAから出発するなら、スタイリングだけで十分です。 逆に、スタイリングにこだわらないならタイミングだけで十分です。
このドキュメント内では、SSAという語は常にテキストファイルとしてのSSAを指し、 プログラムの Sub Station Alpha はフルスペルで記述します（Sub Station Alphaについての知識は必要ありません）。
ASSとは、拡張SSAフォーマットであり、 SSAとは異なるファイル形式です。 今回、ASSは扱わず、ASSについての知識も必要ありません。
本家SSA は Sub Station Alpha 仕様の旧SSAを、 Gabest系SSAは、 Vobsub系各ツール、Media Player Classic、VSFilterなど Gabest のツールでサポートされるSSAを意味します。 — Matroska動画（MKV）と新OGM動画（0.9.9.6以上）は VSFilter を使って SSA を解釈しますから、 MKV/OGM動画作成の観点からは、この「Gabest系」SSAが事実標準です。 — 「本家SSA」と「Gabest系SSA」は基本的には同じデータフォーマットで、 細部がわずかに違うだけなのであまり神経質に考える必要ありませんが、 注意すべき非互換については本文で注記してあります。
Gabest系SSAでは本家SSAの記述はすべて可能ですが、 逆は不可能であり、 Gabest系特有の記法を使うとそのSSAファイルは Sub Station Alpha やそれに準拠するソフトで正しく処理できなくなる場合があります。 通常、このことは問題になりません。 タイミングが済んでしまえば Sub Station Alpha は使わないので、 Sub Station Alpha で読み込めなくなっても、実害はないからです。
VirtualDubMod (VDM) と記述してある部分は、 すべてノーマル版の VirtualDub でもまったく同じ作業ができるので、 適宜「VDMまたはVD」と読み替えてください。
SRTなら、タイミングが決まれば字幕はほとんど完成ですが、 SSAでは、さらに「プレインテキスト＋タイミング＋スタイル」を指定することで、 字幕データの見栄えを細かく制御できます。
タイプセットには、ソース編集用のテキストエディタと、 表示確認用の VirtualDub(Mod) を使ってください。
Sub Station Alpha 自体もタイプセットに利用可能ですが、 中途半端に WYSIWYG 的で小回りが利かず、 そのやり方ではASSへの自然な拡張もできません。 テキストベースでのSSA編集に入ったら、 そのSSAファイルはもうSub Station Alphaで開いてはいけません。 Sub Station Alphaで読み込んで何もせずに上書き保存するだけで、PlayResX/Yを初め編集結果の一部が破棄されてしまいます。 Time from WAV をやり直す必要がある場合は、 ファイルをコピーして、一時作業用のコピーのSSAをSub Station Alphaにロードします。
「SSAのテキストベースの編集」には、いくつかの側面があります。
この項では Huffyuv についてと、 基本的なスタイリング作業の進め方について、説明します。 字幕作成における Huffyuv の必要性は2点です。
注: 簡単なタイプセットだけなら（フォントの種類と色を選ぶだけ、など）、作業用の Huffyuv を用意しなくても、 DivX、XviDなどのビデオで作業しても、問題ありません。 シーンチェンジなどフレーム単位でタイミングを厳密に決めたり、細かいところまで入念にタイプセットを行う場合は、 自由自在に前後にコマ送りできる Huffyuv が便利です。
Huffyuvは、DivXやXviDなどと同じ「コーデック」の一種ですが、ロスレス（可逆）です。 Huffyuvでエンコードするとサイズが大きくなりますが（30分アニメで6～8GB程度）、 そのかわり、Huffyuvのエンコードは、何度繰り返しても、劣化が起こりません。
Huffyuvの本質は、フィルタリングやコマ送りという時間コストがかかる処理を、 「巨大ファイルによる結果のキャッシュ」という空間コストに転換することです。 詳細は付録 1をごらんください。
字幕を含む動画を作るには、 ソースを（必要ならノイズ除去などの加工をして）いったんHuffyuv形式で中間出力し、 以降の作業はそのHuffyuvに対して行うようにします。 タイプセットでは映像に対する字幕位置を決めるので、 クリッピングやリサイズは完成品と同じになっていなければなりません。
何らかの理由でソースが最初からXviDなどの場合でも、ある程度のタイプセットを行うなら、 作業用にいったんHuffyuvに展開します。 その方がVDMでのシークがラクです。 ソースが低画質のDivXやXviDだとしても、 それをHuffyuvに変換しても、画質的には何も損はなく、 変換前と完全に全フレームが等価です（もちろんHuffyuvに変換することそれ自体で画質が向上することもありません）。
スタイルを1つだけ定義するようなシンプルな作業なら、 ソースがXviDなどの場合、それをそのままVDMで読み込むのでかまいません。
Huffyuvのコーデックをまだ導入していない場合は、インストールしてください。 2003年10月現在の最新版は、 huffyuv-2.1.1.zipです。 更新について確認するには、公式ページをごらんください。pre-built DLLがバイナリーです。
インストールは簡単で、ZIP書庫を解凍すると huffyuv.inf というファイルがあるので、 右クリックして「インストール」を選ぶだけです。
huffyuvには上記より新しいバージョン（非公式？）もありますが、クラッシュなどの不具合の報告も耳にします。 2.1.1で何も問題ないので、特に何らかの目的意識があるのでない限り、一般的なバージョン2.1.1をお勧めします。 なお、軽さ（その分、圧縮率は低いが）や広く用いられてきた実績の他に、 そもそも huffyuv を使う本質的な必然性はなく、RGB色空間が使える可逆圧縮であれば、何でもかまいません。 このシリーズでは、単に一般的であるという理由で Huffyuv を使っています。
AviUtlを起動して、メニューの設定｜圧縮の設定｜ビデオ圧縮の設定で、 「圧縮プログラム」として Huffyuv v2.1.1 を選び、[設定] をクリックします。
Huffyuv configuration dialogという別のダイアログが開くので、 YUY2 compression method と RGB compression method の二か所を設定します。
圧縮率重視なら、 (best) の設定（Predict median (best) と Predict gradient (best)）、 速度重視なら、 (fastest) の設定にします（Predict left (fastest) と Predict left/no decorr. (fastest)）。
SSAスクリプトは、基本的に、RGBの色空間を使います。 AviUtl から出力する場合など、RGB形式で出力することを推奨します。 （ファイル→環境設定→コーデックの設定→Huffyuvにて、 「YUY2で展開する」「YUY2で圧縮する」のチェックを外す）
注意: HDの転送速度が遅いとそこがボトルネックになって、結果的に (fastest) にしても速度が出ない可能性もあります。 その場合、fastestにしてCPU負荷が100%まで上がらないようならば（CPU的にはもっと速くエンコできるのに、 エンコ結果をHDに書き込むのが遅いのでCPUが全力を発揮できていない状態）、 圧縮設定をbestにした方がかえって高速になる可能性もあります。
DVDやキャプチャーなどのソースを、AviUtlでインタレース解除・ノイズ除去などの加工をするまでは 「DVD→AVI・OGM・MKV入門」と同じですが、 出力形式をXviDの代わりにHuffyuvにします。 ソースがDivX/XviDのときも同様ですがインターレース解除やフレームレート変更は必要ないはずです。
SSAのテキストベース編集は、 結果を随時VDMで確認しながら行います。
VirtualDubMod (VDM) で Huffyuv形式のAVI映像を読み込み、 同時にTextSubプラグイン経由でSSAを読み込み、 メニューの Options で Swap input/output panes にチェックを入れます。 これで左側のペインに字幕と合成された結果が現れます。 プラグインの使い方の詳細は「SSAハードサブ」を見てください。
SSAの修正結果が、特定フレームの字幕表示にどう反映されるか確認するには、 VDM側で、問題のフレームに移動すれば良く、 すでにそのコマにいる場合には1コマ進んで1コマ戻れば修正結果が「リロード」されます。 エディタでHTMLのソースを編集しながら、結果をブラウザでリロードして確認するのと同じ感覚です。
VDMでフレームを移動するには矢印キーを使います。
左右矢印キーで1コマずつ移動します。Altを押しながら矢印キーを使うと、 50コマずつ移動します。スライドバーをマウスで動かすことで、 任意の場所に移動できます。 映像がHuffyuvであれば、どの移動も滑らかでストレスを感じません。
このほかに、Shiftキーを押しながら左右矢印キーを使うと、キーフレームだけをたどる形で移動できます。 Huffyuvでは全フレームがキーフレームなので、意味がありません。 Ctrlと矢印キーを併用するとファイルの頭・末尾にジャンプします。
SSAファイルのフォーマットを、次の5つに分けて説明します。
これらの要素をテキストエディタで書き換えたり、書き加えたりすることで、 タイプセットの目的が達成されます。
[Script Info] セクションのことで、ファイルの最初になければなりません。 注意すべき項目は、
SSAでは、v4.00 が指定されています。 ASSでは v4.00+ とプラスが付きますが、 ここを v4.00+ にしただけでASSになるわけではないので注意。
必ずその動画の表示解像度を指定します。640x480なら次のように指定します。
PlayResX: 640 PlayResY: 480
PlayResXフィールドがない場合（Sub Station Alphaの生成するSSAファイルなど）、 自分で追加してください。
この解像度が実際の動画の解像度と一致していないと、 以下のすべての指定において数字の1が1ピクセルと異なる長さになってしまいます。 以下では、PlayResX/Yが正しく指定されているという前提で話を進めます。
スタイル定義は [V4 Styles] セクションにあり、1行めは、
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, TertiaryColour, BackColour, Bold, Italic, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, AlphaLevel, Encoding
となっています。これは必要なヘッダであり、
以下に続くカンマ区切りのデータの各フィールドの説明にもなっています。
フォントの名称（内部名）は、フォントのファイル名とは別のものです。 一般には、後述の Font properties extension の Names タブで確認できます（掲示板での質問1921）。 SSAを Unicode (UTF-16) で作成すれば、 日本語を含む各国語のフォント名（みかちゃんPBなど）をそのまま用いることができ、 ASCII表記の内部名を知る必要はありません。
シャドウは技術的にはフォント表面の「裏」（Z方向下側）に投影されるその文字の影で、 フォント自身とずれて描画されると、影の一部がはみ出してZ方向上から見えるようになります。 1以上のShadow値は、このずれを表します。 本体と影がずれればずれるほど見える影部分が大きくなるので、 「影の太さ」と理解してかまいません。ただし、見えないだけで、概念上、 フォント自身の真下にもシャドウが存在しています。 プライマリーを透過させると、シャドウが0でなければ、裏にあるシャドウが透けます。
HTML3.2のRRGGBB方式と同様、 赤、緑、青の3つの成分をそれぞれ0（16進数00）から255（16進数ff）までの256段階で指定します。 RRGGBB方式をご存じないかたは、とほほの色入門・色見本、 ＨＴＭＬの色指定についてなどをごらんください。
HTMLでは #rrggbb と書きますが、SSAでは &Hbbggrr& と書きます。
３原色の並ぶ順番が逆になります。
頭にHをつけ、全体を2つの&で挟みます
（Gabest系SSAでは末尾の&は省略可能だが、仕様書には明記されていない）。
上の「とほほのページ」の表によると金色（gold）は #FFD700 とあるので、
SSAでは、FF、D7、00の3要素を逆順にして、
&H00D7FF& と指定できます。
16進数の大文字・小文字は区別されません。
このカラーコードは、SSAのタグで使うほか、Gabest系ではスタイル定義の色指定として、 そのまま書くこともできます。
Style:Song,TheLittleBirdFont,40,&H00D7FF&,0,0,&H808080&,0,0,1,1,3,2,30,30,30,0,128 ; または末尾の & を省略して Style:Song,TheLittleBirdFont,40,&H00d7ff,0,0,&H808080,0,0,1,1,3,2,30,30,30,0,128
「ことり文字ふぉんと」40ピクセル、色は&H00D7FF&（金色?）、 文字の輪郭と影は&H808080&（灰色）で、ボーダーの太さ1ピクセル、 シャドウの太さ3ピクセルです。
SSAのタグでは、常にこのカラーコードを使えますが、 スタイル定義でカラーコードを使うと、本家SSAの標準と異なり、 Gabest系以外のソフトではうまく処理できない可能性があります。 （Gabest系でもドキュメント化されていない裏技にあたる。）しかし、 この書き方のほうが色の３成分を簡単にコントロールでき、便利です。
本家SSAと互換になるようにするには、16進数の部分を10進数になおして、 数字だけ書きます。16進数と10進数を変換するには、アクセサリーの電卓が便利です。 電卓を起動したら [F5] を叩いて16進モードにし、問題の数値（ここでは00D7FF）をタイプまたはペースト、 [F6] を押せば、10進数になります（この例では55295）。Ctrl+Vでクリップボードにコピーされます。
; 上と同じ意味の、より互換性の高い記法 Style:Song,TheLittleBirdFont,40,55295,0,0,8421504,0,0,1,1,3,2,30,30,30,0,128 ; 55295 = h00d7ff ; 8421504 = h808080
例えば「青成分をh10増やそう」といったとき、 最初の方法では 00D7FF を 10D7FF に変えるだけですが（00を10にする）、 互換性のある方法では、いちいち16進数に変換してから、 また10進数に戻さねばなりません。 Sub Station Alpha では、色はメニューの Styles からGUIのパレットで作るようになっているため、 SSAファイルは直接編集には不便な部分があります。
字幕データは [Events] セクションにあって、次のような書式です。
Dialogue: Marked=0,0:00:18.46,0:00:21.28,Song,,0000,0000,0000,,声をたてないでね
SSAでは、データの書き出しは、Dialogue: Marked=0, となります。
（ASSでは少し違う書式になります。）
そのあとのカンマ区切りの2つの数字がその字幕の表示開始と終了のタイミングであり、
1:23:45.67 は開始後1時間23分45秒67の時点を意味します。
テキストエディタからタイミングを修正したいときには、ここをいじるわけです。
VirtualDub(Mod) ではステータスバーの上に今表示しているフレームの開始タイミングが1000分の1秒単位で表示されますから、映像と字幕のタイミングを考える場合には、その数字を見てください。SSAでは100分の1秒単位なので、勘違いしないように注意。
時間の次の文字が、そのデータに適用すべきスタイルで、 必ず [Styles] セクションであらかじめ定義したもののいずれかを指定しなければなりません。 この指定により、その行がどんな表示のされ方をするのかが決まります。 例えばフォントのサイズを変えたいとき、 スタイル定義を変更することで、 そのスタイルの適用されている全行のフォントサイズをまとめて変更できます。
スタイルの次は「話者」です。Sub Station Alpha でtxt形式のファイルを読み込むとき、次のような形式になっていると、 自動的に話者がその欄に入ります。
話者1: せりふ1 話者2: せりふ2
話者が指定されているほうが便利なので、
翻訳などしてスクリプトを作るときには、なるべく
話者: せりふ
のように書きます。話者が不明のデータでは、そこのデータは空っぽなので、
スタイル指定のあとにカンマが2個並びます。技術的には、それで問題ありません。
0000,0000,0000, となっているのは、文字表示位置の調整で、
それぞれ画面の左・右および下の端（表示位置が上部の文字では上の端）からのピクセル数を表します。
「文字位置」でなく「余白」を変更することで間接的に文字位置を変更します。
0000 の場合は、スタイル定義で指定したマージンがそのまま適用されます。
その次に「エフェクト」を指定するフィールドがありますが、ほとんど使われません。 0000が3つ続いた後カンマが2個並ぶのは「エフェクト欄」が空だからです。 最後に字幕のテキストそのものです。
Dialogue: Marked=0,0:04:08.50,0:04:10.16,Style1,Serio,0000,0000,0000,,It's not good for your health.
この例では、4分8秒50から4分10秒16まで It's not good for your health. という字幕が表示され、 そのスタイルは Style1 であり、参考情報として話者は Serio です。
タグは、スタイル定義を無視して臨時でそこだけ表示を変更したいときに使うもので、 1文字単位で指定できます。 タグの頭には\（半角のバックスラッシュ、SJISでは半角の￥）がつき、原則として二つの半角中括弧 {} で囲みます。
| {\i1} | ここでイタリックにする |
|---|---|
| {\i0} | ここでイタリックでなくする |
| {\b1} | ここで太字にする |
| {\b0} | ここで太字でなくする |
| {\fnフォント名} | ここでフォントを変える。例、{\fnTimes New Roman} |
| {\fs数字} | ここでフォントサイズを変える。例、{\fs24} |
| {\c&Hbbggrr&} | ここで色（プライマリー）を変える |
| \N | ここで強制改行。{}は付けない |
複数のタグをまとめて指定する場合、一個ずつ中括弧に入れても、 2つ以上または全部をひとつの中括弧に入れても、 どちらでもかまいません。
; フォント名、フォントサイズ、色を同時に指定した例
{\i1}Translated by:{\i0} {\fnPalatino Linotype}{\fs44}{\c&H88eedd&}John Doe
; これでもいい
{\i1}Translated by:{\i0} {\fnPalatino Linotype\fs44\c&H88eedd&}John Doe
SSA本来のタグはこの程度です。 カラオケを含むさまざまなエフェクトはASSのタグです。 ASSについては後日説明します。
以上でSSAの基本的要素を見たわけですが、初めての人がこのリファレンスを見ても、 「実際問題何をどう指定すればいいのか」と迷われると思います。 実際的な注意点をいくつか書いておきます。
基本的には同じことができるのですが、不具合があります。 詳細は「AVSによるハードサブ」。
何より日本語字幕で注意したいのは、文節などの切れ目に適当に半角スペースを入れることです。 通常、日本語の文は文字を全部つなげて書き「分かち書き」しません。 句読点の前後さえスペースを入れないことが普通です。 しかし、これではどこでワードラップしていいのかレンダラーが困るので、 文の切れ目などで適当に半角スペースを入れておこう。
本当は改行禁則文字が関係しなければどこで改行してもいいのが日本語ですが、日本語に特化してるわけではない汎用字幕レンダラーに、現状、禁則処理うんぬんを要求することはできません。 自動ワードラップには各言語に応じた複雑な要素（日本語なら禁則文字、英語なら自動ハイフン処理など）があるため、 世界的な規格であるはずの MPEG-4 標準でさえ、 字幕の自動ワードラップは標準準拠の「義務」にはならない見通しです。 最も基本的なワードラップ処理（半角スペースで改行可能）を使えるようにしておくのが、賢明です。 マンガのセリフもそうですが、適度にスペースがあるほうが、読みやすくもあります。
翻訳者と分業した場合、翻訳者が半角スペースを入れていなければ、タイプセッターの責任で入れるべきです。
よくある質問ですが、どちらでもかまいません。 単なるスタイルの問題（趣味の問題）です。 日本語の場合、句読点のかわりにスペースを使うほうが見やすいかもしれません。 漫画のふきだしのせりふのスタイルが参考になります。
日本語の場合、分からなければ、とりあえず、MS UI Gothic を指定すれば良いでしょう。 Windows 98以降なら、何語版でも MS UI Gothic は存在する可能性が高いので、 ソフトサブの場合、無難な選択です。
ハードサブの場合、漢字を含む日本語フォントとしては、 みかちゃんフォント（太字と細字あり）、 ことり文字ふぉんと、 あくあフォントが完成度が高いです。 発展中のものとしては、あくびん、たれフォントなどがあります。 これらは誰もがインストールしているフォントではないので、 ソフトサブで指定してもマシンによってはそのフォントで再生できません（フォント埋め込みや、 画像字幕を使えばまた別です）。
ぱうフォントには不明の不具合があり、SSAでは利用できません。 （Textsub.vdf でも Subtitler.vdf でも駄目。）
字幕のスタイリング（タイプセット）に興味ある方は、 日頃からフォント系サイトをぶらぶらと眺めて、どんなフォントが利用できるか、見ておきましょう。 1001 Free Fontsや、 フランスのdafont.comを訪ねてください。 基本的には、あまり細いものより、太字、エクストラボールドのものが字幕に適します。
インストールされている全フォントの字形見本や情報がまとめて表示されるフォントビュアーがあると、 フォント選びのときに便利です。 X-Fonterは、4.6が最後のフリー版で、それ以降はシェアウェアなので注意。
Microsoftが配布しているシェル・エクステンション Font properties extension の導入もおすすめします。フォントファイルのプロパティで詳細情報が見れるようになります。
しゃべる人ごとに違った色などを指定したり、 あるいは、同じ人でもオフスクリーンのときは色を変えたり、 心の中の声、独り言のときは色を変えたり、などと、スタイルの適用の仕方は、 いろいろあり得ます。また、西欧語などでは、強調される言葉をイタリックにしたり、 といった臨時的なスタイリングもあります。
色は、最初のうちは、白、明るい黄色、明るい水色、明るい黄緑などにして、 バックカラーを灰色～黒にして、 ボーダー、シャドウとも1～3ピクセルにすれば、無難でしょう。
同じプライマリー・カラーでも、ボーダーの色などによって、見え方が大きく変わる場合があります。 対比、 同化などの現象のためです。
より詳しく学びたいかたは、 理論面では色彩入門、 実践面ではIRO-UZUをごらんください。
「色の視認性」の良否は、背景色と図色の明度差・彩度差・色相差の順に大きく影響
といった記述をSSAに当てはめるとき、背景色とはシャドウ、図色とはプライマリーですが、
それとは別に字幕全体が図で映像が地でもあります。
背景の映像はフレームによって異なるので、字幕はどこに置いても視認性が高いものになるように注意します。
まぶしい白のフレームや真っ黒のフレームにいて、そこでは字幕がきれいに見えても、
その配色が他でも通用するとは限りません。
SSAはユニコードで作成するほうが何かと便利です。何より日本語のフォント名が普通に使えます。 多言語を扱いたい場合は特にそうですが、日本語だけを扱う場合でも、 ユニコードを使ったほうが字幕の文字化けが起きにくいです。 ユニコードはもはや標準ですので、日ごろからUTF-8や16で保存できるエディタを使うようにするといいでしょう。 エディタとしては一般にはUTF-8Nが使えないと不便ですが、 SSAに限っては、UTF-8Nが使えないエディタでもかまいません。
ユニコードのSSAは通常、BOMをつけます。 MKVMergeなどは、BOMによってユニコード系の文字エンコーディングを自動認識し、 UTF-8でも16でも使えます（その他、指定すれば、ほとんどすべての文字エンコーディングが使えます）。
しかし、VirtualDubフィルター textsub.vdf はユニコードとしてUTF-8ではなくUTF-16を使います。 作業上、VirtualDub上で確認する必要がありますから、 ユニコードのSSAは、BOMのあるUTF-16がベストです。
ユニコードに興味あるかたは、 Alan Wood’s Web Site、 特にAlan Wood’s Unicode Resourcesから、 理論面では Unicode Technical Reportsから、 読み始めると良いでしょう。 多言語字幕と特に関係深いのが bidirectional の問題です。
通常の字幕部分についての理念は、こうです。 「視認性が高いという意味で字幕は目立つ（読みやすい）が、 うるさくないという意味でデザイナーの存在は目立たない」
通常、映画やアニメを見る人は、話が理解できれば良いのであって、 字幕の細かいデザインなどどうでもいいのです。 一方、サバーのなかには字幕作成自体を半ば趣味にしているマニアもいるかもしれません。
タイプセッターは字幕が目立ちすぎてはいけないという大原則を心に留めてください。 理想は、字幕が存在することが意識されないような自然で心地よいタイプセットです。 字幕はあくまで原作を理解するための裏方的な要素であり、 しかもその本質は翻訳にせよろう者のための文字字幕にせよ、 テキストの内容です。 見た目は華やかで特殊効果を使いまくって目立ちまくっていても、翻訳が間違いだらけのような字幕より、 白一色でも正確で良いテキストの字幕のほうが、優れています。
「センスがない」とか「平凡」と思われることを恐れる過剰な自意識のせいで、 いたずらに奇矯なデザインをしてはいけません。 フォント／色彩／空間設計のどれについてもです。 そもそも一般の人は字幕のデザインになど大して注意を払っていません。 タイプセッターは「デザインのセンスを見せるため」ではなく、 「字幕の見やすさのため」に仕事をするべきです。
見やすい字幕こそがセンスのある字幕であり、 字幕が見やすければ見る人の注意はそこに行かないので、 あなたのセンスも意識されません。これが正しいあり方です。
タイプセッターは、字幕という文字のせいでオリジナルの映像を破壊しているのだ、 ということも意識しなければなりません。
タイプセッターはディープな仕事をしてはいけない、と言っているわけではありません。
タイプセットの極意はこれ見よがしにエフェクトを使いまくることではなく、 反対に「これ見るなよがし」にエフェクトを使うことです。 必要とあらばどんな面倒なことでもやるが、 大変な仕事をやりました、と、素人目にも分かるようでは本当ではなく、 理想は、処理の跡が誰にも気付かれないようにしてしまう、 ということです。 例えば日本語の題字の下に英訳が出ているとしても、 その英訳がもともとオリジナルにあったロゴのように見えたら理想的。 天衣無縫、秘すれば花、 「最高の特殊効果とは、特殊効果の存在が分からないようなエフェクトである」 ということです。
例えば、怪獣映画で怪獣が暴れているときに「うわー大変だ」とストーリーのほうに目が行くのが本当で、 「ほお、よく出来たセットだなあ」と注目されるようでは、 何か「段差」が存在してしまっている、ということではないでしょうか。
字幕も「何か読みにくい字幕だなあ」は問題外として、 「ほお、すごい凝ったデザインの字幕だなあ」とテキストの内容よりスタイルが目立つようでは、 たぶん理想ではないでしょう。 もっともそれはあくまで一つの考え方であり、 趣味で自作するからには何をやろうが100%自分の勝手である、というのも一面の真実です。
末尾のリンク集を見てください。 特に別記事「字幕作成 SSA中級編」をごらんください。
Huffyuvについて、一とおり補足しておきます。 この内容は字幕作成に直接関係ないので、飛ばしてかまいません。 本格的に字幕を趣味にしたいかたは、むしろ付録2: SRT・SSA・ASSの違いに目を通しておいてください。
以下、必ずしも常にそうとは言えないものもありますが、 一般的に Huffyuv のメリットと考えられることを挙げてみます。
DVDやキャプチャーのソースを、AviUtlでノイズ除去・加工して、 VirtualDubMod（以下VDM）を使ってハードサブを行うとします。
AviUtlでXviD 200MBで出力したものを、 VDMで再エンコして字幕を入れXviD 200MBで出力すると、 XviDで2回圧縮することになり、サイズが同じでも画質面で損をします。 AviUtlからはロスレス（劣化なし）のHuffyuv形式で出力しておき、 この中間ファイルにVDMで字幕を入れてXviDに圧縮すれば、劣化が起こる場所が1か所で済むので、 高画質を実現できます。
字幕のスタイリングを行うには、自分がSSA上で加えた変更がどのように実際の字幕に反映されるのか、 予定出力をモニターしながら行う必要があります。
TextSubプラグインを用いて、VDM上でモニターできるわけですが、 このときビデオソースがXviDなどで圧縮されていると、前後にちょっとコマ送りして字幕の流れなどを見たいときに、 場合によってコマ送りがスムーズにできずストレスを感じますし、作業の能率も悪くなります（逆方向のシークが引っかかりやすい）。 DivXやXviDなどの通常の動画圧縮では、 1フレームずつが独立した情報でなく前後の（場合によっては100フレーム以上離れた）フレームからの差分情報でできているためです。
Huffyuvなら、全フレームが独立したキーフレームになるので、どのフレームからどのフレームへでも瞬時に移動でき、ストレスなく作業ができます。 全部がキーフレームということは、どこからどこまででも再圧縮なしでカット＆ペーストできるので、 自作ビデオを編集するような場合にも大変便利です。
「DVD→AVI・OGM・MKV入門」で見たように、 動画のエンコでは、数時間、場合によって10時間以上の長時間が必要です。 実は時間がかかるのは、 ソースの映像からノイズを除去したりするフィルタリングの部分で、 XviDなどでのエンコードそれ自体は、そんなに時間はかかっていません。
例えば、1パス10時間かかる場合（フィルター9時間、XviD 1時間とする）、普通にやると2パスで約20時間かかります。 ところが、フィルタリングの結果をHuffyuvで中間出力するなら、まず約9時間でフィルタリングだけやって、 あとはフィルタ済みのソースをXviDでFast recompress できるため、9+1+1でだいたい11時間で済みます。 半分の時間で同じ結果が得られるわけです。
サイズの調整などで2パスめを再実行したいときも、 Huffyuv→XviDの高速圧縮だけをササッとやればいいならラクです。 一方、フィルタリング結果がHuffyuvにキャッシュされていないと、 ゼロからまた10時間かけてえっちらおっちらやらなければならなくなり、結果的に「ちょっとやり直す」というのも困難になり、ひいては「じゃあ、まあこれでいいか」となって、トータルのクオリティまで下がってきます。
ハードサブの場合、 数カ所誤字を訂正する・単語をちょっと変える程度のわずかの変更なら、同じ.statsファイルを使って、 2パスめだけやり直すのでかまいません。 ハードサブができあがったあとで再生して確認しているときに、 誤字や表現を変えたい部分を見つけるのはよくあることです。 Huffyuvを使っていれば、こうしたときの小回りの修正も簡単。 最近（2003年）のマシンでVHQを使わなければ1時間かからずに再エンコできるでしょう。 これに反して、 Huffyuvのキャッシュを作っておかないと、1文字直すだけで10時間……これではお話になりません （実際には、そういう場合には、部分エンコという別の方法を使った方が良い）。 Huffyuvは一般的にも便利なものですが、特に字幕作成を行う場合には大変便利なツールです。
30分で約8GB、1時間なら16GBのサイズになります。 この連載の最初で「ひとつのHDに20GB（できれば40GB）程度の空きがある」ことを前提条件にしているのは、 そのためです。
Huffyuvは、あくまで作業用の一時ファイルなので、動画が完成したあとは削除してかまいません （ゴミ箱に入りきらないときは、[Shift]+[Del]）。 それでも一時的にたくさんのスペースを必要とすることは確かです。
HDにそんなに空きがないという場合、初心者でも簡単に実行できる増設はUSB外付けです。 PCにUSB 2.0ポートの空きがあるなら、 USB 2.0の外付けHD（容量120GBとかの）を買ってくれば、 Windows 2000なら、たださすだけですぐ使えます。 USB 1.1では遅すぎて使えません。
古いPCなどで4GBを超えるファイルを作れない場合、Huffyuv出力を手動でいくつかに分割する必要があるかもしれません。 例えば、アニメのＡパートとＢパートを別々のHuffyuvにすれば個々のファイルは4GB未満になるでしょう。 この場合、VDMでは、分割の境目になるフレームは両方に含まれるようにしてください。 例えば、1-9999と10000-20000という分け方ではなくて、1-10000と10000-20000という分け方にします（フレーム番号10000は重複して両方に入れる）。VDMにロードするときは、2つ目以降の断片は File | append segment... で読みます。
4GBを超えられないのは何かと不便ですから、Windows 2000以降の新しいOSを使っているのであれば、 ファイルシステムをNTFSにしましょう。
Huffyuvは、見かけは普通の .aviファイルですが、 動画プレーヤーで直接再生することを目的としたファイルではありません（少なくとも2003年現在の常識としては）。 フィルタリング結果をHuffyuvに格納したあと、品質を確認するには、 プレーヤーで再生してみるのではなく、VirtualDubなどで開いてみてください。 そのほうが、1コマずつじっくり調べられます。
DirectVobSubを使ってプレーヤー経由で仕上がりを確認したい場合や、 作業を分担したい場合は、 XviD品質70などで暫定的に素早く圧縮した「参照用の低画質版」を作ると良いでしょう。
時間・手間・ストレスのある重い作業をいとわなければ、Huffyuvを使わなくても、 劣化を伴う圧縮を二重に行うことなく、AviUtlとVDの間でデータをやりとりできます。 AviUtlのフィルター結果をVDで読み込むには、 aup形式で保存したプロジェクト・ファイルをVFAPI Codecで疑似avi化します。 逆に、VDの処理結果をAviUtlから利用するにはフレームサーバーを使います。
これらは、どちらかと言えば20世紀の手法であり、HDが安い・速い・巨大になった21世紀においては、 VFAPI枠外の通信はHuffyuv経由が明快です。
ある程度の経験がないと「オーバーラップ」「コリジョン」の意味が実感できないと思いますが、 これはとても重要な概念です。
SSA/ASSは、単に「フォントの色などが指定できる」というだけではありません。 スタイリング能力の差は確かにSRTとSSAの大きな違いですが、 SRTにも、必ずしも標準ではないのですが、若干のスタイリング能力があります。
現在のSRTとSSAの質的違いは、 タイムスタンプのオーバーラップが可能かどうかです。 ある人がしゃべり終わらないうちに別の人がしゃべり始めたり、 字幕が下に出ている状態で、それとは独立のタイミングで上に訳注を出したり、 といった複数イベントの同時進行が、SSAでは可能です。 SRTの場合 — 特に従来のOgg系のコンテナではそうですが — タイムスタンプがオーバーラップできず、 単調増加しないと不具合が起きます。
オーバーラップは決して特殊な現象ではありません。 実際にタイミングすればすぐ分かることですが、 たいていの映画やアニメでは、 たとえ30分ものでも一度や二度は同時の声があります。 アニメの中にテレビのニュース番組などが出て、 テレビを見ながらニュースキャスターと同時にキャラがしゃべるようなことも、よくあります。
同じ表示位置（例えば下部センタリング）のデータでタイムスタンプがオーバーラップすると、 字幕のコリジョン（collision = 衝突）が起きます。 Gabest系レンダラーは、コリジョンがあると、字幕が重ならないように、 自動的に後から出た字幕を前からある字幕をよけるように描画します。 ときには、この自動処理がSSAタイプセットを分かりにくくします。 レイヤー的な処理が必要になったら、Zインデックスを明示できるASSに移行してください。
| SRT | オーバーラップは存在できない。 |
|---|---|
| SSA |
事実上無制限にオーバーラップ可能。 コリジョンは原則として自動処理され、文字が重ならない。 原則として、文字を重ねようとしても自動処理でよけられてしまう。 |
| ASS |
事実上無制限にオーバーラップ可能。 コリジョンの自動処理はレイヤーごとに行われ、 Zインデックスを離すことで、 文字や図形を意図的に重ね打ちできる。 |
