8 : 13 SSA字幕作成リファレンス

← 8 - 12 P↑ もくじ I 8 - 14 N →

SSA入門 スタイリング編 Ver.2.4.1a

2003年10月 7日
記事ID d31007

注意:
この記事は、書かれてから数年たっているため、内容が現状と合わない部分があります。
重要な変化については、動画・字幕関係の記事について(2007年4月)を見てください。

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」と読み替えてください。

もくじ
  1. タイプセットのあらまし
  2. 作業の準備
  3. SSAのフォーマット
  4. 実際的なヒント
  5. 付録1: Huffyuvについての補足
  6. 付録2: SRT・SSA・ASSの違い

(1) タイプセットのあらまし

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のテキストベースの編集」には、いくつかの側面があります。

スタイリング: 字幕の空間的デザイン
字幕のスタイルを1つまたは2つ以上定義し、 字幕の各データにどれかのスタイルを指定する作業。 今回のテーマです。
タイミングの調整: 字幕の時間的デザイン
対音声または対映像で、 字幕が出る/消えるのが早すぎた/遅すぎたのが分かったとき、 テキストエディタでSSAを直接編集することで、タイミングをします。 特にシーンチェンジとの関係では、繊細な時間的デザインが要求されることがあります。 中級編で詳しく扱います。
特殊効果: 時間と空間にまたがるエフェクト
通常の字幕とは別に、オリジナル画面に文字が映る場合の処理があります。 家の表札、標識、主人公が持っている本の題名、ラブレター、携帯電話のメッセージ、 など、画面に映るテキスト(サイン)のなかには翻訳しないとストーリーの流れが分からないような、 クリティカルなものもあります。 商用映画ではこの種のテキストは白い長方形に囲って訳を出すことが多いようです。 ファンサブ(自作の字幕)でも同じようにしてもいいですし、 画面に映る文字を直接書き換えることもできます。 他にも特殊効果に属することがいくつかありますが(カラオケ、スクロールなど)、 これらの多くはASSタグを使って実現され、 時間と空間の両方をにらんだデザインが要求されます。 今回は扱いません。

(2) 作業の準備

この項では Huffyuv についてと、 基本的なスタイリング作業の進め方について、説明します。 字幕作成における Huffyuv の必要性は2点です。

注: 簡単なタイプセットだけなら(フォントの種類と色を選ぶだけ、など)、作業用の Huffyuv を用意しなくても、 DivX、XviDなどのビデオで作業しても、問題ありません。 シーンチェンジなどフレーム単位でタイミングを厳密に決めたり、細かいところまで入念にタイプセットを行う場合は、 自由自在に前後にコマ送りできる Huffyuv が便利です。

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 を使っています。

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にした方がかえって高速になる可能性もあります。

Huffyuv出力

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と矢印キーを併用するとファイルの頭・末尾にジャンプします。

(3) SSAのフォーマット

SSAファイルのフォーマットを、次の5つに分けて説明します。

  1. ヘッダ
  2. スタイル定義
  3. カラーコード
  4. 字幕データのフォーマット
  5. タグ (オーバーライド・コード)

これらの要素をテキストエディタで書き換えたり、書き加えたりすることで、 タイプセットの目的が達成されます。

ヘッダ

[Script Info] セクションのことで、ファイルの最初になければなりません。 注意すべき項目は、

ScriptType

SSAでは、v4.00 が指定されています。 ASSでは v4.00+ とプラスが付きますが、 ここを v4.00+ にしただけでASSになるわけではないので注意。

PlayResXとPlayResY

必ずその動画の表示解像度を指定します。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
となっています。これは必要なヘッダであり、 以下に続くカンマ区切りのデータの各フィールドの説明にもなっています。

Name
字幕データ部分からそのスタイルを呼び出すときの名前です。 安全のため半角英数字を使います。 例えば、通常の字幕データの部分を Jimaku というスタイル、訳注の部分を Chuu というスタイルにして、 Jimaku は下部中央、Chuu は上部中央にそれぞれ違ったフォント設定で出すようにすることができます。
Fontname
使用するフォントの内部名です。アルファベットのフォントの場合、 一般的な Verdana, Times New Roman などの名称がそのまま内部名にもなっています。 日本語のフォントでは、通称と内部名が違うことがあります。 SSAをユニコード(UTF-16)で作成する場合、日本語のフォント名をそのまま使うこともできますが、 SJISで作成する場合は、内部名を使う必要があります。 「みかちゃんPB」は mikachan-PB、 「あくあPフォント」はaqua_pfont(pとfontの間にアンダースコアが入らないことに注意)、 「ことり文字ふぉんと」はTheLittleBirdFont、 「MT たれっぴ」はMT TARE_P です。 「あくびん」にはVer.0.7現在、内部名がないので、 「あくびん」を使いたい場合、SSAをユニコードで作成します。

フォントの名称(内部名)は、フォントのファイル名とは別のものです。 一般には、後述の Font properties extension の Names タブで確認できます(掲示板での質問1921)。 SSAを Unicode (UTF-16) で作成すれば、 日本語を含む各国語のフォント名(みかちゃんPBなど)をそのまま用いることができ、 ASCII表記の内部名を知る必要はありません。

Fontsize
フォントのサイズです。ヘッダのPlayResX, PlayResYが動画の横と縦の解像度と一致している場合、 数字の1が1ピクセルに対応します。
PrimaryColour
プライマリー・カラー(第一の色)。文字表面の色です。カラーコードについては後述します。

SecondaryColour
セカンダリー・カラー(第二の色)。カラオケで色変化前の色を表す。
Tertiary Colour
ターシアリー・カラー(第三の色)。SSAでは使われません。ASSでは「第三の色」はボーダー(アウトライン、文字の輪郭)の色を表しますが、指定の仕方が異なります。
BackColour
シャドウの色(第四の色)。SSAではボーダーの色の指定も兼ねます。 SSAのスタイルでは、ボーダーとシャドウは強制的に同じ色になり、 まとめてバックカラーと呼ばれます。 ボーダーはアルファ0(不透明)、 シャドウはアルファ0x80(半透明)に固定されるため、シャドウは薄く見えます。 ASSでは、ボーダーとシャドウは独立で、アルファは自由に設定可能です。
Bold
太字にしたいときは-1(マイナス1)を指定、太字にしないときは0(ゼロ)を指定。 日本語の手作りフォントでは太字データが同一ファイルにないことが多く、 しばしば太字の指定が効きません。
Italic
イタリックにしたいときは-1(マイナス1)を指定、しないときは0(ゼロ)を指定。
BorderStyle
文字の表示方式。通常は1(文字の輪郭とシャドウを使う)を指定します。 3を指定するとレターボックスを描画します。
Outline
ボーダー(文字の輪郭)の太さを指定します。0を指定するとボーダーが描かれず、軽い感じになりますが、 明るい色のフォントではボーダーがないと見にくいです。
Shadow
シャドウ(文字から落ちる影)がどのくらい太く見えるかを指定します。 0を指定するとシャドウが描かれず、平面的に見えるスタイルになります。

シャドウは技術的にはフォント表面の「裏」(Z方向下側)に投影されるその文字の影で、 フォント自身とずれて描画されると、影の一部がはみ出してZ方向上から見えるようになります。 1以上のShadow値は、このずれを表します。 本体と影がずれればずれるほど見える影部分が大きくなるので、 「影の太さ」と理解してかまいません。ただし、見えないだけで、概念上、 フォント自身の真下にもシャドウが存在しています。 プライマリーを透過させると、シャドウが0でなければ、裏にあるシャドウが透けます。

Alignment
字幕の表示位置です。よく使うのは、2(下部センタリング)と6(上部センタリング)。
MarginL, MarginR
画面の左右の端から何ピクセルあけるかを指定します。0であれば、 長い字幕は画面の端に接触可能です。 例えば、30であれば端30ピクセルは字幕が入ってはいけない範囲になります。 禁止範囲に達すれば、自動でワードラップされます。
MarginV
画面下端から(表示位置が上部の場合、画面上端から)何ピクセルあけるかを指定します。
AlphaLevel
本家SSAのドキュメントでは、このフィールドは将来の拡張用の予約領域とされています。 Gabest系はこのフィールドを読み、簡易的にアルファ(透過度)を変更します。 範囲は0から255(0xFF)。 ここで指定した透過度は、プライマリー(文字色)とボーダー(文字の輪郭)に同時に同じ値が適用されるため、 「輪郭だけ残して中は透明な文字」などは、ここでは作れません。 アルファを使いたい場合はASSにしてください。
Encoding
文字セットのコードページを表す。日本語は128、西欧語は0、 一部の絵文字や手書き風フォントで1または2。 SSAをユニコードで作成する場合、本来、コードページの指定(日本語なら128)を省略できるのですが、 省略するとソフトサブのとき Windows 98で文字が表示されなくなるので、 ユニコードで作る場合も、指定するべきです。 スタイリッシュなフォントで0ではフォント変更がきかないときには、1または2にしてみてください。 西欧語・英語以外の場合の文字コード
カラーコード(色を指定する文字列)

HTML3.2のRRGGBB方式と同様、 赤、緑、青の3つの成分をそれぞれ0(16進数00)から255(16進数ff)までの256段階で指定します。 RRGGBB方式をご存じないかたは、とほほの色入門・色見本HTMLの色指定についてなどをごらんください。

HTMLでは #rrggbb と書きますが、SSAでは &Hbbggrr& と書きます。 3原色の並ぶ順番が逆になります。 頭にHをつけ、全体を2つの&で挟みます (Gabest系SSAでは末尾の&は省略可能だが、仕様書には明記されていない)。

上の「とほほのページ」の表によると金色(gold)は #FFD700 とあるので、 SSAでは、FF、D7、00の3要素を逆順にして、 &H00D7FF& と指定できます。 16進数の大文字・小文字は区別されません。

このカラーコードは、SSAのタグで使うほか、Gabest系ではスタイル定義の色指定として、 そのまま書くこともできます。

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系でもドキュメント化されていない裏技にあたる。)しかし、 この書き方のほうが色の3成分を簡単にコントロールでき、便利です。

互換性のある記法(正式)

本家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では半角の¥)がつき、原則として二つの半角中括弧 {} で囲みます。

SSAの基本的なタグ
{\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については後日説明します。

(4) 実際的なヒント

以上でSSAの基本的要素を見たわけですが、初めての人がこのリファレンスを見ても、 「実際問題何をどう指定すればいいのか」と迷われると思います。 実際的な注意点をいくつか書いておきます。

AVS+VSFilter.dllのハードサブについて(AVSユーザ向け)

基本的には同じことができるのですが、不具合があります。 詳細は「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に当てはめるとき、背景色とはシャドウ、図色とはプライマリーですが、 それとは別に字幕全体が図で映像が地でもあります。 背景の映像はフレームによって異なるので、字幕はどこに置いても視認性が高いものになるように注意します。 まぶしい白のフレームや真っ黒のフレームにいて、そこでは字幕がきれいに見えても、 その配色が他でも通用するとは限りません。

ユニコードについて: BOMのあるUTF-16がベスト

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中級編」をごらんください。

付録1: Huffyuvについての補足

Huffyuvについて、一とおり補足しておきます。 この内容は字幕作成に直接関係ないので、飛ばしてかまいません。 本格的に字幕を趣味にしたいかたは、むしろ付録2: SRT・SSA・ASSの違いに目を通しておいてください。

Huffyuvを使う意義

以下、必ずしも常にそうとは言えないものもありますが、 一般的に 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は一般的にも便利なものですが、特に字幕作成を行う場合には大変便利なツールです。

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出力を手動でいくつかに分割する必要があるかもしれません。 例えば、アニメのAパートとBパートを別々の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を使わずにハードサブで同じ品質を得る方法(参考)

時間・手間・ストレスのある重い作業をいとわなければ、Huffyuvを使わなくても、 劣化を伴う圧縮を二重に行うことなく、AviUtlとVDの間でデータをやりとりできます。 AviUtlのフィルター結果をVDで読み込むには、 aup形式で保存したプロジェクト・ファイルをVFAPI Codecで疑似avi化します。 逆に、VDの処理結果をAviUtlから利用するにはフレームサーバーを使います。

これらは、どちらかと言えば20世紀の手法であり、HDが安い・速い・巨大になった21世紀においては、 VFAPI枠外の通信はHuffyuv経由が明快です。

付録2: SRT・SSA・ASSの違い

ある程度の経験がないと「オーバーラップ」「コリジョン」の意味が実感できないと思いますが、 これはとても重要な概念です。

オーバーラップ/コリジョンが本質的
タイムスタンプのオーバーラップ
時間的に字幕の表示タイミングが重なること。
コリジョン
表示位置が同じ字幕が時間的にオーバーラップして、 あるフレーム内で空間的に字幕の衝突が起きること。

SSA/ASSは、単に「フォントの色などが指定できる」というだけではありません。 スタイリング能力の差は確かにSRTとSSAの大きな違いですが、 SRTにも、必ずしも標準ではないのですが、若干のスタイリング能力があります。

現在のSRTとSSAの質的違いは、 タイムスタンプのオーバーラップが可能かどうかです。 ある人がしゃべり終わらないうちに別の人がしゃべり始めたり、 字幕が下に出ている状態で、それとは独立のタイミングで上に訳注を出したり、 といった複数イベントの同時進行が、SSAでは可能です。 SRTの場合 — 特に従来のOgg系のコンテナではそうですが — タイムスタンプがオーバーラップできず、 単調増加しないと不具合が起きます。

オーバーラップは決して特殊な現象ではありません。 実際にタイミングすればすぐ分かることですが、 たいていの映画やアニメでは、 たとえ30分ものでも一度や二度は同時の声があります。 アニメの中にテレビのニュース番組などが出て、 テレビを見ながらニュースキャスターと同時にキャラがしゃべるようなことも、よくあります。

同じ表示位置(例えば下部センタリング)のデータでタイムスタンプがオーバーラップすると、 字幕のコリジョン(collision = 衝突)が起きます。 Gabest系レンダラーは、コリジョンがあると、字幕が重ならないように、 自動的に後から出た字幕を前からある字幕をよけるように描画します。 ときには、この自動処理がSSAタイプセットを分かりにくくします。 レイヤー的な処理が必要になったら、Zインデックスを明示できるASSに移行してください。

タイムスタンプのオーバーラップという観点からみた 各字幕フォーマットの比較
SRT オーバーラップは存在できない。
SSA 事実上無制限にオーバーラップ可能。
コリジョンは原則として自動処理され、文字が重ならない。
原則として、文字を重ねようとしても自動処理でよけられてしまう。
ASS 事実上無制限にオーバーラップ可能。
コリジョンの自動処理はレイヤーごとに行われ、
Zインデックスを離すことで、 文字や図形を意図的に重ね打ちできる。

リンク

シリーズ
応用・発展
関連記事

更新履歴

2003年10月7日 Ver.1
暫定公開。
2003年11月6日 Ver.1.1
フォントビュアーの例示を追加(X-Fonter 4.0)
2003年11月21日 Ver.1.2
Huffyuvの設定で、HD転送速度によってはbestの圧縮の方がかえって高速になる可能性があることを追記。
2003年12月24日 Ver.1.3
「IRO-UZU」のサイト構成が変わったためリンクを更新。
2004年1月17日 Ver.1.4
従来「Vobsub系SSA」と表記していたGabestのSSAを「Gabest系SSA」と改めました(「Vobsub」は字幕フォーマットの名前としても使われるので、意味が紛らわしいと思って)。
SSAをUnicodeで作成する場合、通常BOMをつけることを明記しました。
簡単なタイプセットなら作業用の Huffyuv を作る必要がないことを追記しました。
フォントリソースへのリンクをいくつか追加しました。
2004年1月27日 Ver.1.5
フォントリソースへのリンクを、さらに1つ追加。
2004年2月8日 Ver.1.6
ユニコードのSSAはUTF-8でなく16にすべきことを注記した。 「ぱうフォント」の不具合について追記した。 その他、少し加筆。
2004年4月12日 Ver.1.7
VSFilter.dll+AVSのバグについて注記。 MKVでソフトサブのフォント埋め込みが可能になっているので、 解説記事へのリンク追加。
2004年4月25日 Ver.1.8
細かい加筆。 ワードラップの問題の説明を少し詳しくした。 各国語言語コード表へのリンク追加、ほか。
2004年5月9日 Ver.1.9
Huffyuvの最新版について加筆。ほか。
2004年9月28日 Ver.2.0
中級編の公開に合わせて、一部修正。 Huffyuv で RGB色空間を使うべきことを加筆。
2004年11月18日 Ver.2.1
カラオケ字幕作成についての記事が遅れているため、 さしあたって、カラオケ字幕作成を扱っている他サイトへのリンクを追加しました。
2005年7月20日 Ver.2.2
X-Fonter 4.6へのリンク追加。
2006年4月13日 Ver.2.3
若干のソフトへのリンク追加。
2006年4月13日 Ver.2.4
さらに若干のユーティリティへのリンク追加。
「付録1: Huffyuvについての補足」一部コメントアウト。
2006年6月15日 Ver.2.4.1
ツール紹介にHashTab追加。
2008年6月17日 Ver.2.4.1a
HashTabの紹介内容を、現在のバージョンのHashTabと合うように更新。

この記事のURL



Email Address
中文,英文或日文都可以。
Email us in Chinese, English, or Japanese.