前 9 - 11 p ｜ 
もくじ i ｜ 次 9 - 13 n 
高品質のデジタル字幕を作りたいとき、考えなければいけない問題。
SSAスクリプトの完成度を高めるためのチェック作業・微調整について説明する。 特に、映像のシーンチェンジと字幕のオンオフのタイミングがほんの少しだけずれると一種のフリッカー（ちらつき）が生じることに注意を向け、 字幕のタイミングを意図的にシーンチェンジと同期させる方法、 あるいは意図的にシーンチェンジと十分に離す方法に触れる。
これらの問題は個々のツールとは無関係であり、 Sabbuで作業する場合にも同じ考え方が必要となる。
Sub Station Alpha を前提としたタイミング編、 スタイリング編からの続編ということもあり、 Sub Station Alpha での実際の作業についてさらに詳しく説明するが、 これらも概念的に Sabbu で通用する知識だ。
ここで紹介する内容は、必ず行わなければいけない義務的なものではない。 やり方を知っておいて、特に品質にこだわりたいとき、必要に応じて行えば良い。 目立たないところに時間をかけて物を作りあげていく、 趣味ならではの創造の楽しさを、感じていただければと思う。
字幕についての細かい技術的な議論が続くが、 実際の作業では、単なる技術的優劣や腕自慢ではなく、 常に作品への素朴な敬愛の気持ちを基本としなければならない。
内容についての要望、フィードバックは、 掲示板までどうぞ。
このセクションでは Sub Station Alpha での作業効率を上げ作業時間を短くするコツを説明する。
Sub Station Alpha では実時間より速くタイミングができる。 熟練したタイマーは24分のアニメを15分程度でタイムしてしまうことがある。
入門編で強調したように、それには正しい手の使い方が重要だ。 正しい手の使い方を覚えないなら Sub Station Alpha を使う意味はないとさえ言える。 基本は S D G の3キーだが、 さらに S の連打や、再生しながら縦棒を動かすやり方を覚えれば、いっそう作業が効率的に、ラクになる。 （S D G の基本をマスターしてから、このセクションを読むこと。 一気にまとめて覚えようとすると、かえって何も覚えられない可能性がある。）
Sub Station Alpha では、マウスクリックだけでも作業を行えるが、 もしマウスクリックだけで作業したいなら、新しいもっといいソフトがある。 また、マウスクリックだけで作業するのは効率が悪く、手も目も疲れてしまう。 右手のマウスだけでなく、同時に左手で（片手で）キーボードを使う方法は、 最初はとっつきにくいかもしれないが、決して難しくはなく、ちょっと練習すればすぐ覚えられる。 一度覚えてしまうともう他の方法ではタイミングしたくないと感じるほど効率的で、ラクで、速い方法なので、 ぜひこのやり方をマスターしよう。
入門編ですでに基本は説明したが、要するに、右手のマウスで字幕の開始タイミングと終了タイミングを探り、 左手（キーボードのホームポジション）でWAVファイルの再生・停止・タイミングの確定をコントロールする。
S は再生/一時停止ボタンだ。 停止中に押すと、WAVファイルが再生される。 再生中ならば停止する。
D は終了タイミング確認ボタンだ。 D を押すと、現在の選択範囲の「終了点の直前から終了まで」のごく短い時間範囲のWAVが再生される。 「終了タイミングを確認したいだけなのに、いちいち選択範囲の頭から聴く必要はない」ということだ。
G はタイミング確定ボタンで、押下すると、現在の選択範囲がその行のタイミングとして確定する。
最初にスタートタイムを決めたい。 開始の縦棒を適切と思われるタイミングにセットする。 終了の縦棒は「だいたいその辺」という場所でいい。 （開始のタイミングは一回で決めることをねらう。終了のタイミングはこの段階ではこだわらない。）
この状態で S を押し、再生開始する。
スタートタイムが間違っていると分かったら、ただちに S を押し停止する（スタートタイムが間違っているときに、 いちいち選択範囲の最後まで聞くのは時間の浪費）。
スタートタイムが間違っている場合というのは、既にしゃべり始めている声の途中でインしてしまった場合か、 または、声が始まるよりだいぶ前でインしてしまった場合だ。 間違っていると気づいた時点で、どのくらい縦棒を補正すればちょうどいいか分かるはずだから、 S で止めて、縦棒を動かし、もう一度 S する。
スタートタイムを確認する効率的な方法は、0.5秒間隔くらいで S を2回連打することだ。 選択範囲の最初の 0.5秒だけを聞くことができる。
10秒のせりふの開始点を決めるのに、10秒程度を何度も再生せず、 最初の0.5秒だけを最高でも3回程度繰り返すだけで、開始タイミングを決めたい。 10秒あるせりふの開始タイミングを2秒以内に確定する、と考えてほしい。そうすると、10秒を3回繰り返して30秒無駄にするより、 ずっと速くなるのが分かる。
波形と声のパターンの関係にも注意し、 できるだけ最初から誤差を少なくする。 間違っていたら、0.5秒ですぐ修正動作に入る。これが第一のコツだ。
スタートタイムが正しいと分かったときには、ふたつの選択がある。 S で止めていきなりエンドタイムを目指す方法と、 もう一つは、エンドタイムまで、そのまま声を聞く方法だ。 一般には、そのまま聞いたほうが安全だ。が、暗唱できるくらいせりふを分かっていて、 そのせりふが割と長い場合には、直接エンドタイムを目指すほうが絶対的に速い。
(2-a) まず、そのまま聞く場合を考える。
開始のタイミングが正しいときには、S を連打してすぐ停止せずに、そのまま選択範囲の最後まで聞き続ける、というやり方だ。 再生してみて開始がおかしければ S を押してすぐ止めるが、 開始が良ければ、S は押さない、というやり方だ。
この場合、声の進み方と、停止の縦棒とを見比べていると 「このままでは選択範囲が狭すぎる（声は今の縦棒位置よりもっと先まで続いている）」と分かる場合がある。 それが分かった場合、間違った範囲をとりあえず聞き終わるのでなく、 聞きながら、縦棒位置を右へ右へと「逃がして」いく。再生している場所が終了の縦棒にぶつかるとWAVが止まってしまうので、 そうなる前に逃がす。 逆に「これは縦棒よりだいぶ前で声が終わるぞ」と分かる場合もある。 その場合「この辺だろう」という場所まで左へ縦棒を動かす。 本来の終了場所を過ぎて再生してしまうと、もう一度頭から聞かない限り戻しようがないので、早めに調整すること。
この「WAVを再生中にも終了側の縦棒は随時動かして調整する」というのが第二のコツだ。
(2-b) スタートタイムが正しくても正しくなくても、必ず S は2回連打する、というやり方もある。 スタートタイムが正しく決まっても、0.5秒程度ですぐ止めてしまい、今度は D を押して選択範囲の末尾だけを調整する、 というやり方だ。この方法は、10秒あるせりふの頭と末尾だけをタイムして真ん中の9秒をスキップするので、極めて速い。 ぜひこの方法も覚えたい。第三のコツだ。 が、罠もある。 例えば「いいと思うけど、それで…わたしはね」のような「声がいったん止まってから、少しだけ何かがくっつくようなせりふ」の場合、 せりふを正確に知らないと、「わたしはね」を落として「それで」の「で」で終了させてしまう危険がある。 声は「いい思うけど、それで…わたしはね」なのに、対応する字幕が「それで」の「で」で消えてしまう状態になる。
2-a と 2-b のどちらがいいか。 2-a の方が安全だが、2-b の方が速い。
現在の再生位置が波形の表示範囲の右端に接近したときは、表示範囲をスクロールさせる必要がある。 マウスのホイールボタンが使えるならそれが簡単だが、 ホイールボタンが使えなくても F で前進、A で後退する。 左手で使う通常のキーは、ホームポジションの中段（ASDFG）に並んでいる、ということに注意する。
Alt+R は選択されている現在の行を再生する。 Alt+V は一行上を、Alt+X は一行下を再生する。 これらのキーにも慣れておこう。
熟練すると「このキーはこうだからこれを押して」などと理屈で考えることなく、 ほとんど何も考えないで指が勝手に動くようになる。 初心者はタイミングを面倒な作業、タイプセットは簡単、と考えるが、 実際は逆。 タイミングは半分居眠りしながらでもできるようなラクな作業、 タイプセットこそ集中を必要とし、時間のかかる精密作業だ。
タイミング作業は頭で考えて「難しい・難しくない」というより、 スポーツのような意味での、経験が物を言う世界だ。 いくら本を読んでもピアノを弾けるようにならないのと同じこと。 実際に指を動かしながら覚えよう。
入門編では、とりあえずハードサブで結果を確認したが、 カラオケなどの細かいタイミングを確認するのにちょっと変更するたびにハードサブしていては効率が悪い。 DirectVobSub や VirtaulDubMod なら SSA を1文字変更するたびに、その場で（上書き保存した瞬間に）ビデオ上で修正が反映される。
セクション3と4で説明する確認作業は、 DirectVobSub を使ってすることも、 VirtualDubMod を使ってすることも可能だ。 どちらでも使いやすいほうを使えば良いが、 標準の手順としては VirtualDubMod の使用を推奨する（そのほうが統合的に作業ができる）。
このセクションでは、 まずは古典的で応用範囲も広い DirectVobSub について説明し、 次に VirtualDubMod を使う場合について説明する。 どちらを使う場合も、末尾の「共通の注意事項」を踏まえてほしい。
DirectVobSub は基本的には DirectShow 経由の再生でソフトサブを実現するツールだが、 以下では、そのなかでも外部ファイルからの字幕について説明する（確認作業で必要なのは、それ）。
字幕データを mux することなしに、外部ファイルのまま、映像の上にソフトサブ表示する。 やり方は簡単で、ファイル名を拡張子以外同じにすればいい。 例えば、foo.ssa という字幕データと同じフォルダに foo.avi という動画ファイルがあるとすると、 foo.avi を再生したときに foo.ssa は自動的にロードされる。 タスクトレイには、緑の矢印のアイコンが表示される。 この緑の矢印のアイコンは「動画に埋め込まれているソフトサブ」の再生でおなじみと思うが、 「埋め込まれていない外部ファイル」のときも、データが動画ファイル内にあるかないかの違いだけで、ほぼ同様になる。 foo.ja.ssa のように拡張子が2段になっていても認識されるし、.ssa だけでなく .srt や .ass でもロードされる。
一般には、普通の意味で映画などの字幕を表示するための機能だが、 表示できる以上（字幕を作成中に）それを確認するのにも利用できる。 実際 DirectVobSub には字幕の作成をサポートするためのオプションがある。
MPCの内蔵字幕レンダラにもこれとよく似た機能があるが、 字幕の表示確認用には、MPCの内蔵レンダラではなく、必ず DirectVobSub を使う必要がある。 MPCの内蔵レンダラでは、SSAファイルを更新してもその場で反映されないからだ（字幕データを読み込みなおすと反映されるが、 それではちょこちょこ調整するのに不便だ）。
DirectVobSub 自体は VSFilter に含まれているので、MKVを再生できる環境ではすぐに利用できるが、 次のように、デフォルトとは設定を変える必要がある。
DirectVobSub は、VSFilter に含まれる。 VSFilter はLazy Man's MKVを使えば、 簡単にインストールできる。
AVIファイルと同名の（拡張子だけ違う）SSAファイルが同じフォルダにあれば、 AVIファイルを再生したとき、DirectVobSub は自動的にロードされるので、 タスクトレイの緑の矢印のアイコンを右クリック、 DirectVobSub を選択すれば設定ダイアログを呼び出せる。 Windows 2000以降で Lazy Man's MKV を使ってインストールした場合、 いつでも、スタートボタン → Programs → Lazy Man's MKV → VSFilter (DirectVobSub) で設定ダイアログを呼び出せる。
General タブの Loading が Do not load 以外になっていること、 External にチェックが入っていることを確認する。
次に Misc タブで、 Pre-buffer subpictures のチェックを外す（このチェックを外さないと、カラオケのような動的なエフェクトが有効にならない）。 さらに、Auto-reload subtitle files... と Apply changes immediately にチェックを入れる（さもないと、SSAファイルの更新が、 表示にその場で反映されない）。
以上の設定を変えたら [Apply] [OK] でダイアログを閉じる。
Pre-buffer subpictures オフの設定は、字幕再生時のCPU負荷を高める。 1.5 GHｚクラス以上のCPUでは、このままにしておいて問題ないはずだ。 その半分程度だと、普段はこのチェックをオンにして、字幕チェックのときだけオフにする方が良いかもしれない。
MPC (Media Player Classic) の VMR-7/9 モードでも、 同様に字幕ファイルが自動的にロードされる。 MPC と DirectVobSub の両方から同じ字幕を出しても無駄なだけだし、 微妙な表示位置の違いのせいで、字幕がぼけて見える原因にもなる。 しかも MPC での字幕は DirectVobSub の場合と違って、字幕ファイルの更新を瞬時に反映できないから、 字幕ファイルを修正しながら表示確認するような作業には向かない。 DirectVobSub から字幕を出す場合、MPC の字幕はオフにする必要がある（Play | Subtitles | Enable のチェックを外す）。
以下の説明で用いている VirtualDubMod のバージョンは 1.5.10.1 build 2439 だ。 バージョンが違うと機能などが違う場合があるので注意。
VirtualDubMod (以下VDMと略）と Textsub.vdf プラグインを使って、 SSAのハードサブができることは、入門編で説明した。 このフィルターが有効な状態で出力をモニターすれば、結果として、VDM上で出力イメージを再生しながら確認できる。 この方法なら、再生しながらの全体的な確認と、フレーム単位での精密な確認が、同じソフト上で統合的に行え便利だが、 次の点に注意してほしい。
第一に、VDM にロードする音声トラックは、厳密に音ズレが補正されているべきだ。 通常なら、Audio skew correction 等の設定で mux時に音ズレを補正するのでも構わないはずだが、 確認作業時にうっかり補正の設定を忘れたり、補正値の正負を逆にしたり、といったうっかりミスのせいで、 すべての作業が台無しになる。また、音声の形式によっては、正しくプレビューできない（特にVBR）。 安全のため、確認用の音声トラックは、WAV形式かCBR MP3形式として、 音ズレ補正済みのものを使うことをおすすめする。 TextSub以外の（重い）フィルターを併用すると、フィルター結果をリアルタイムでプレビューできないことがあるので、これも避ける。
通常、左側に出力を出すように Options | Swap input/output panes としておく。 映像、音声、および字幕のすべてがロードできたら、 後は、再生を開始したいフレームで [Enter] を押せば、プレビューが開始される。 一時停止するには [Alt]+[F] → [A] とする。
タイミングが済んだらすぐ確認してもいいが、スタイリング（スタイルの定義と適用）は先に済ませたほうがいい。 そのほうが「その字幕に読みにくいところがないか」をあわせて確認できる。
スタイリング（一般にタイプセット）では、映像を可逆圧縮したAVIを使う。 この連載では huffyuv を使っている。 CPUパワーが十分なら、この huffyuv ソースを VDM にロードした状態で、そのまま確認作業を行える。 CPUパワーが十分でない場合 huffyuv の再生それ自体が重すぎて、 確認作業がうまくできない可能性がある。 その場合、XviD などで字幕なしの圧縮をしておき、それに対して DirectVobSub してもいい。 この場合の XviD は単なる画面確認用なので、1パス、デフォルトなどの速い方法で圧縮しておけばたくさんだ。 注意しておくが、特にカラオケのようなエフェクトを「動的」に確認するには、 一定の CPU パワーが必要だ。以下の作業で、CPU負荷が100%になるようだと、 何かずれているとき、 タイミング自体が間違っているのか、 それともタイミングは合っているが負荷が高すぎて再生がずれているのか判然としなくなる。 それでは確認にならないので、huffyuv がきつければ、もっと軽い圧縮を使う必要があるし、 究極的には（特に複雑なエフェクトの部分は）ハードサブしてみる必要があるかもしれない。
確認作業に使う動画は、 音声のタイミングが本番と完全に同じで、各フレームも圧縮による劣化は別にして全フレームが本質的には同じでなければならない。 さらにクリッピングや色の補正も本番と同じでなければならない。
音声のタイミングが本番と違えば、字幕と声がずれているのか合っているのか判断できない。 特にDVDをリッピングした場合のAC3に -133ms のようなずれがある場合、極めて慎重に作業しなければならない （本番と同じ＝音ズレを補正した後の状態で確認しなければならない）。
映像が本番と（たとえ部分的にでも）1フレームでもずれていれば、対映像のタイミングを正しく確認できない。 例えば、24fps のソースでタイプセットのときと本番で何かの原因（インターレース解除の設定の変更など）で1フレームずれると、 シーンチェンジなどと字幕の消失の関係が約40msずつずれ、常に少しずつオーバーランしたりする。 これは非常に不愉快なことで、最悪、全行のアウトタイムを再調整するはめになる（全フレームが定数だけずれていれば修正は比較的ラクで、 部分的にずれているほうがさらに困る）。
クリッピングが本番と違えば字幕の絶対位置と画面の関係がずれるし、 色の補正が異なれば字幕の色と画面の色合わせがずれる。 タイミングの確認をする「規準」がずれては、すべて無駄骨になるので注意したい。
確認作業をするときは、DirectVobSub を使う場合でも、必ず VDM に huffyuv をロードし、Textsub で SSA を読み込んでおく（修正作業で使う）。 またエディタで編集する SSA を開いておく。 その上で VDM のプレビュー機能（または DirectVobSub ）を使用する。
音声のせりふには、せりふの最初の音が鳴る瞬間の「立ち上がりエッジ」と、 せりふの最後の音が消失する瞬間の「立ち下がりエッジ」がある。
字幕の開始時刻はフライングしてもいいが、 字幕の終了時刻はタイトが原則。
基本的には、字幕のスタートタイムはせりふの「立ち上がり」であり、 字幕のエンドタイムはせりふの「立ち下がり」だ。 実際には、字幕のスタートタイムを音の立ち上がりより0.1～0.2秒早めにして、 字幕をプリロードすることがしばしば行われ、経験上、その方が見ていて快適なことが多い。 おそらく、字幕が表示開始されて視神経に刺激が行ってから脳がその文字を認識するまでに微妙に遅れがあるため、 音声の立ち上がりと完全に同時では、心理的に字幕が遅れているように感じられるのかもしれない。
字幕のタイミングをするとき、スタートタイムは（好みによっては）立ち上がりよりわずかに早めでもいい。 遅れて出るくらいなら、早めに出たほうがいい。
これと対照的に、音声の立ち下がりを超えて字幕がオーバーランすると、一定確率で悪い結果を招く。 音声に対するオーバーランは問題にならないこともあるが、そこにシーンチェンジがあるとまずい（後述）。 エンドタイムは立ち下がりと同時がいい。どちらかといえば、遅すぎるよりは、ごくわずかに早すぎるくらいでいい。
第一に音声と字幕の関係を注意深くチェックする。 音声との同期ずれには4パターンある。
確認していて明らかに対音声のタイミングに問題があることが分かった場合、 0.2秒を加減するのが良い。微妙に問題があると感じる場合は、0.1秒を加減する。 意味がある最小単位は約0.05秒であり、それ以下の修正では実際には何も変わらないことがある。
例えば次の行のタイミングに問題があったとする。
Dialogue: Marked=0,0:00:45.27,0:00:52.48,Style1,,0000,0000,0000,,そっちから来ないなら こっちから行くぞ
スタートタイムが遅すぎた場合、 45.27 を 45.07 に変えて、効果を確認する。 エンドタイムが遅すぎた場合、 52.48 を 52.28 に変えて、効果を確認する。 これが0.2秒ずらすということだ。
実際には、ある程度慣れてくると、対音声で字幕のタイミングに問題が出ることは、ほとんどない。 Sub Station Alpha の段階で片がついているからだ。しかし、不慣れなうちは、 こうした問題が起こりうる。 最も悪いのは、何らかの理由で VBR MP3 音声を使ったものを、ノーマル版 VD などで分離し、 SSAのタイミングに使ったWAV自体が音ズレしていることだろう。
字幕の表示タイミングが声のタイミングとずれていては良くないことはすぐ分かるが、 このような対音声の同期だけでなく、 対映像の同期も問題になる。 実用的には（字幕は読めればたくさんで、細かいことにはこだわらないという立場では）映像とのタイミング問題は無視できるが、 その場合でも、知識としては知っておいたほうがいい。 ASS系のエフェクトを使いこなす基本としても、映像と字幕のタイミングの取り方は不可欠の知識だ。
確認作業では、音声とのタイミングより、むしろ映像とのタイミングの調整がメインと考えてほしい。
以下では、関連する話題をいくつかのサブセクションに分けて説明する。 何度か加筆を繰り返したため、やや見通しが悪い。 そこで、最初にポイントをまとめておく（この要約中の特殊用語については、本文中で詳しく説明してある）。
http://www.bunkus.org/videotools/mkvtoolnix/samples/
にある vsshort のビデオを、
vsshort-en.srt の字幕で見てほしい。字幕のタイミングは実用上ほぼ問題ないが、
その気になれば改善できる場所がたくさんある。
特に、ここでは「シーンチェンジに対する字幕のオーバーラン」とは何かを理解しよう。
例えば、青年が Don't record any more messages on my alarm clock. というシーン（字幕）がある。次のシーンでは女性にカメラが切り替わって、 女性は why not? と答えている。これらは、まったく申し分がない。
シーン1: 青年のせりふ
シーン2: 女性が答える
しかし、シーンチェンジの瞬間 #210 を見ると、シーンは既に変わっているのに、 前のシーンの字幕が残留しているのが分かる。この残留字幕は #227 まで18フレームもオーバーランしている。 せりふの音声はとっくに消えているので、このオーバーランは意味がない。
シーン2に切り替わっているのにシーン1の字幕が残留している状態:
ずれてついたり消えたりする字幕がバタバタした感じを生むうえ、
青年のせりふの字幕が女性の前に出て、誰がしゃべっているのか混乱が生じる。
「タイミングは合っているはずなのに、 字幕がバタバタして、何となくスムースに流れない」という場合、 シーンチェンジに対する字幕のオーバーラン（言い換えればシーンチェンジをまたがる残留字幕）が発生していることがある。 この例で言えば、シーン1の字幕は、シーンチェンジと同時に、#210の直前で消えるほうがいい。
音声に対するタイミングが（ほぼ）正しいはずの SSA でも、実際に表示確認すると、頻繁にこの問題が発生する。
シーンチェンジに対する字幕のオーバーランは、シーンが切り替わっても、前のシーンの字幕が残留する現象だ。 典型例として、AさんとBさんが会話するシーンで、Aさんが話し終わるのとほぼ同時にカメラがBさんに切り替わっていることがある。 もしBさんが一呼吸置いてから返答するのであれば、 音声のタイミング的には、Aさんの立ち下がりエッジからわずかに遅れて字幕が消えるとしても、 何も問題はないのだが、映像との関係で、バタバタしてしまう。 言い換えれば、この問題は映像上で確認して初めて分かるもので、 Sub Station Alpha で作業しているときには（エンドタイムはなるべくタイトにするという全般的な心掛け以外に）積極的な回避法はない。
10対1くらいで起こりにくいが、時間軸で逆方向に字幕がはみ出ていることがある。 カメラがまだAさんのうちに、Bさんの字幕が出て、その直後にカメラがBさんに切り替わるパターンだ。 これも好ましくない。
これらのオーバーランは、通常の人が字幕を見ても明確に意識はされず、 二、三回ならほとんど問題ないが、あまり多いと、何となく字幕がバタバタして、キレの悪い、スッキリしない感じが残る。
通常の人から見ても明らかな（したがって最悪の）オーバーランの例としては、 タイトルの表示がある。 例えば冒頭、白い背景に黒い文字で「第3話 なんたらかんたらの冒険」などとタイトルが出ているとする。 それの翻訳が字幕で、やはり黒い文字で出ているとする。 その後に、例えば平和な朝のシーンなどでストーリーが始まるとしよう。 この場合、たとえ1フレームでも字幕がオーバーランすると、平和な朝のシーンの上に「第3話 なんたらかんたらの冒険」に当たる黒い文字がはみ出して、 ずれて消えるので、誰が見ても気持ちが悪い。
シーンチェンジで合わせて、特に対音声で問題がなければ、何も考えることはないが、 しばしば問題になるのは、シーンチェンジに合わせると音声に対してアンダーラン、 音声に合わせるとシーンチェンジに対してオーバーラン、というジレンマだ。
シーンチェンジを少しだけまたがる字幕は、シーンチェンジと同時に消失するようにエンドタイムを早めるべきだ。 その逆方向にはみ出る字幕は、シーンチェンジと同時に出現するように、スタートタイムを遅らせるべきだ。 （上記の「タイトル」のような特別な例では、シーンチェンジと完全に同期して字幕を消すのがいい。）
差が0.2秒以内なら、シーンチェンジは音声の立ち下がりより優先。
シーンチェンジとの同期は、音声との同期を最大0.2秒程度（好みによっては0.3～0.4秒程度）犠牲にしてまで、優先すべきだ。 声の立ち上がりや立ち下がりは、通常、もともとエッジがそれほど厳密でなく、人の声はゆるやかに始まって、ゆるやかに消える。 これは波形を見ればすぐ分かるし、前述のように、もともと立ち上がりは0.2秒前にずらしてちょうどいいくらいの、あいまいさがある。 ところが、人間の目はシーンチェンジや字幕のオンオフのような明るさの変化には敏感で、 タイミングが1フレームずれているだけでも、ずれているのが感じられる（明確には意識されないとしても）。
音声が消えるのがシーンチェンジをわずかにまたがっている場合、そのまたがり方が、
シーンチェンジの瞬間に字幕が出現する（または切り替わる）ことは、 ハードサブでは、多くの場合、その字幕の画像情報がキーフレームをベースにエンコードされることを意味し、 したがってその字幕全体の画像品質向上も期待できる。
耳が不自由な人のための字幕では、音声とのタイミングを完全に無視して、常にシーンチェンジを尊重しても良い。 音が聞こえない場合、字幕がシーンチェンジをオーバーランすると誰がどのせりふをしゃべっているのか混乱するという根本的問題の原因になる。
今まで説明してきたフリッカー（チラチラ感、バタバタ感）の問題は、 外形的な見た目の印象の分析だ。 ところで、「シーンチェンジより少し前に声が消える（そして字幕も消える）」のと、 「シーンチェンジと同時に声が消える（そして字幕も消える）」のには、しばしば、意味的なニュアンスの違いがある。
例えば、しゃべっているアリスの顔が映り、次のシーンでボブの顔が映る場合:
実際の作業においては、フリッカーの原因となっている時間差を機械的に調べるだけでなく、 どのタイミングで視聴者の視点を字幕からアンロックするのが正しいのか、 演出意図を意味的に理解する必要がある。 （この項、2004年12月1日追加）
シーンチェンジに対して字幕がオーバーランしたな、と思ったら、まずビデオの再生はひとまず止めて、 VDM で検査する。Alt+左右矢印キーと、単独の矢印キーとを使って、問題のシーンチェンジの場所に行き、 オーバーランが発生していないか確かめる。動画を目で見てすぐ分かる場合は、まず間違いなくフレーム単位で見たら3～5フレーム、 あるいはそれ以上、激しくオーバーランしている。 チェックするときは1フレームのオーバーランも見逃さないつもりで、よく見よう。 1～2フレームのオーバーランは、見逃すことがあり、逆にオーバーランしていないのに「あれ？」と思うこともある。
修正するかどうかは、主に「せりふがどのくらいシーンチェンジをまたいでいるか」しだいだ。
修正するには、VDM でシーンチェンジのタイミングを調べる必要がある。
VDM では、現在のフレームの頭の時間が、ミリ秒の単位まで表示されている。
例えば、次の7030で前のシーンが終わり、7031でシーンチェンジしていると仮定しよう。
Frame 7030 (0:04:53.209)
Frame 7031 (0:04:53.251)
この場合、SSAで、字幕のエンドタイムが、 4:53.25 までなら良いが、4:53.26 を超えていると、前のシーンからオーバーランする。 オーバーランしている場合、4:53.21 から 4:53.25 までのどれかをエンドタイムとすることで、 シーンチェンジと同時に字幕が消えるようにできる。
ここで注意しなければならないのは、 SSA のタイムスタンプはセンチ秒（0.01秒）単位であり、 しかも、SSA での 4:53.21, 4:53.22, 4:53.23, 4:53.24, 4:53.25 の5つのタイムスタンプは、字幕としては、 どれも上記 #7031からの変化を意味していて、 実際には同じ結果になる、ということだ。 コンマ251がシーンチェンジの瞬間なので、その直前の最大値、つまり 4:53.25 がいい。
すなわち、シーンチェンジの直後（シーンが変わった瞬間）のフレームに移動し、 そのフレームのタイムスタンプの 0.001秒の位を切り捨てたセンチ秒（0.001の位が0の場合は0.01を引いた時刻）を、採用する。
例: フレームの時刻57.589と同時に消える字幕: エンドタイム 57.58 例: フレームの時刻12.270と同時に消える字幕: エンドタイム 12.26 （注）「同時に消える」とは「そのフレームにはもう字幕は乗っていない」こと
2番目の例のように0.001の位がゼロであるタイムスタンプは注意を要する。 VDM が 12.270 と表示しているフレームは実際には、12.2704 かもしれないし（その場合、終了時刻 12.27 で良い）、 12.2695 かもしれない（その場合、終了時刻 12.27 ではシーンチェンジ直後のそのフレームまで字幕が残る）。 どちらの場合でも安全なのが、12.26 であり、フレームの間隔は 0.04 程度あるので、0.01 戻しても前のフレームには影響しない。
上記の調整を行ったとき、 VDM でシーンチェンジ直後のフレームを表示して、そこで [Enter] を押せば、せりふの末尾をどれだけ切り落としたか確認できる。 「せりふがまだ終わりきっていないで（シーンチェンジをまたいで）だいぶ残っている」場合、シーンチェンジを優先するのは考え物だが、 「せりふの末尾が微妙に（シーンチェンジをまたいで）残っている」だけなら、シーンチェンジを優先しても良い。 定量的に言うと、0.2秒程度が限界の目安になる。（好みによっては、0.2秒未満でも「せりふ優先」でいいし、 0.2秒以上でも「シーンチェンジ優先」でいい。あくまで目安だ。）
逆に、あるフレーム「から」表示開始したい字幕は、そのフレームの頭のタイムスタンプのミリ秒を切り捨てたセンチ秒から開始すれば良い。 ミリ秒の位がゼロのときは、0.01秒引く。
例: フレームの時刻57.589から始まる字幕: スタートタイム 57.58 例: フレームの時刻12.270から始まる字幕: スタートタイム 12.26
テキストエディタでオーバーランに対する修正を行ったら、 すぐ上書き保存して、VDM でシーンチェンジの直前フレームから → ← → ← とシーンチェンジをまたいでコマ送りし、 シーンチェンジと同時に字幕が消えるように変更されたことを必ずその場で確認する。 勘違いなどがあった場合でも、後でもう一度このフレームに来るのは手間がかかるから、 その場で確認しておくのがいい。
前の行のエンドタイムと、次の行のスタートタイムが同じとき、
字幕は一瞬も重ならない。例えば、
Frame 7030 (0:04:53.209)
Frame 7031 (0:04:53.251)
に対して、53.23 で終わる字幕と、53.23 から始まる字幕があった場合、
前者はフレーム7031まで持続できないが、後者はフレーム7031と同時に表示開始されるので、終了と開始が同時の場合、
結果的に、オーバーラップにならない。
例えば同一人物がしゃべり続けている一連の字幕は上記のように、前の行のエンドが次の行のスタートとしても良い。
二つのせりふの間に声の切れ目がある場合は、みだりに二つの字幕を連続させず、字幕がオフになる時間を作るべきだ。 休符のない音楽が成り立たないように、 字幕も、表示と非表示のリズムがせりふのリズムに合致するべきだ。
シーンチェンジのすぐ直前（例えば1～2フレーム手前）で字幕が消えるのも、バタバタ見える原因になることがある。 このような場合には、逆に字幕のエンドタイムをシーンチェンジまでずらすと良い。 （この項、2004年10月22日追加）
シーンチェンジに対して、字幕を少しだけオーバーランさせると決めた場合、オーバーランがごくわずかな時間だと、 上述のように一種のフリッカー（ちらつき）の原因になる。
字幕のエンドタイムはある程度任意に延長可能で、 音声に対するオーバーランはほとんど気にならない。 したがって、シーンチェンジに対して微妙にオーバーランさせる必要がある場合は、 ごくわずかにオーバーランさせるのではなく、どうせなら0.4秒程度オーバーランさせ、 「シーンチェンジ」と「字幕の消えるタイミング」を意図的に離すことで、チラチラした印象を解決できる場合がある。 （この項、2004年12月1日追加）
上記の作業は、ハッキリいって面倒だ。 孤独で地道な作業だ。見ても普通の人には明確には分からない「何となくバタバタ」感をなくし、 字幕がなめらかに切り替わるようにするのだが、時間をかけてなめらかにしたからといって、 その仕事はほとんど気づかれないだろう。しかし、高品質ということは、そういう目立たない作業に支えられている。
そうは言っても、この修正は少ないに越したことはない。 ということは、Sub Station Alpha で作業する段階で、エンドタイムはタイトに、声が終わるのと同時に切り上げ、 字幕の時間軸方向の末端をルーズにしない、ということが大切だ。まだ声があるかな？あるかな？などと微妙に長めにせず、 早めに切り上げること。思い切りが重要だ。
ところが、このことにこだわり過ぎると、字幕がアンダーランしてしまう（まだ明らかにしゃべっているのに消えてしまう）。 それも良くない。
タイミングの時点で、エンドタイムはタイトにするが、対音声のアンダーランはしない。 チェックの段階では、対音声でアンダーランさせないとシーンチェンジと同期できない場合のみ、 かつ、ずれ方がわずかの場合のみ、対音声でアンダーランさせる。 それ以外の場合には、決してアンダーランさせない。
これらのデリケートな作業を行う場合、たとえ 66ms（0.07秒）でも AC3 が音ズレしていたり、 たとえ 1フレームでも何かが最終形とずれていると（例えば、結合する場合の結合フレームの処理で）、 せっかく苦労した0.01秒単位の作業が台無しになる。作業用のファイルが、最終形と完全に一致するように、細心の注意が必要だ。 特に、DVD2AVI で抽出したAC3ファイルの DELAY -66ms のような表示は「タイムスタンプ -66ms からファイルが始まっている」という意味であり、 映像と正しく同期させるには頭の66ミリ秒をトリミングする必要がある（そのまま再生すると音が映像に対して遅れる）。 AC3ファイルのDELAYの正負の方向を勘違いすると逆方向に2倍音ズレする。 例えば、上の DEALY -66ms で正負を取り違えると、 音声が映像に対して132ms遅れる。そのずれた音声に対していくら字幕を厳密にタイミングし、 シーンチェンジにまで配慮しても、苦労は水の泡だ。
理屈で「0.2秒以内だからどう」と単純に割り切らず、 目と耳と感覚で、経験を積もう。 リップシンクや効果音と絵のタイミングに注意して、音ズレした状態で字幕を作り込んでいないか確認しよう。 一度わざと音ズレを補正していないファイルで字幕を作り、同期がとれていないとどういう現象が起こるか意識的に観察してみると良い。
音声と字幕のタイミングの問題は、0.2秒単位、微調整でも0.1秒単位を加減すればいいが、 映像と字幕のタイミングの修正は、0.01秒単位の精度で SSA を編集する必要がある。 字幕の「映像タイミング」は影響度において「音声タイミング」の10分の1程度と言えるかもしれないが、 これを考慮する場合、10倍ややこしい（神経を使う）。
人物によって色を変えている字幕では、シーンチェンジに対するオーバーランが比較的気にならない。 そのようなスタイリングをしている場合、オーバーランに対して許容度を高くしても良い。
この記事の付録BとCはひとまずここに置いてますが、 入門編に入れたほうがいいので、後から動かす予定です。
ここで空間的な分割とは1単位の字幕が表示上2行以上に渡る場合をいう。 また時間的な分割とは、一続きのせりふが時間的に前半後半のように分けて表示される場合だ。
長いせりふなどは、適当に時間的に分割し、字幕は原則として2行以内、最大でも3行以内で収まるようにする。 4行も理由があればいいが、たいていの場合、前半と後半に分けたほうが読みやすいだろう。 長いせりふを分割する場合、翻訳の都合などで、後半の訳が字幕では前半になってしまってもいい。
例: This program is... / presented by Foobar, / your music shop.
この番組は / みなさまの音楽の店 / フーバーの提供でお送りします。
また、原文の切れ目を尊重すると（タイミングや分量の関係で）字幕の収まり具合が悪くなる場合、 原文では本来切れていない場所で前半と後半を切り替えてしまってもいい。
例: This program is presented by / Foobar, your music shop.
この番組はみなさまの音楽の店 / フーバーの提供でお送りします。
翻訳者から見ると気持ち悪い面があるが、2単位の字幕が連続して表示される場合（前半が消えた瞬間に、後半が出る）、 原文の切れ目と関係なくどこで切り替わってもいい。 特に原文が聞き取れない人には切れ目がずれていることがそもそも分からないわけで、 商用字幕では「どうせ視聴者には分からないから」ということがたくさん許されるだろう。 趣味として自作する場合、妥協はなるべくしない方がいいが、原文と翻訳先の言語の性質の違いで、 ひっくり返したり、切れ目をずらさなければならないことはある。
もう一つ、一部の商用字幕と違い、SSAでは字幕が常にオーバーラップできる。 商用字幕では、技術上の制約などで、 誰かがしゃべっている途中の短い相づちは脱落させてしまうことがあるし、 言い争っているシーンなどで声が重なる場合、字幕では単純化されることがあるだろう。 SSA では、複数のイベントが平行して進行できるので、オーバーラップを気にせずに、個々のせりふをタイムして良い。 （オーバーラップは再生時にレンダラの側で自動処理される。）
タイプセットでは、しばしばオリジナルにある文字と同じ色の文字を作りたいことがある。 オリジナルの背景色を取得してオリジナルにある文字を塗りつぶしてから、書き換えたいこともある。 こうした場合に、オリジナルの画面にある文字色・背景色などの、正確なカラーコードを取得する必要がある。
ビデオの特定の色の情報を、字幕データ内にコピーする、ということだ。
例えば、オリジナルに「小っちゃいって事は便利だね」というピンク系のタイトルロゴがあるとして、 SSAからは同じ色で Being Small is Convenient と出力させたいとする。 技術的には入門編の内容で実現できる。
Style: Logo,#44 Font Expanded,70,&H3140ca,&H000000,&Hccffff,&H000000,0,0,1,0,0,5,40,0,260,0,0
Dialogue: Marked=0,0:00:00.76,0:00:05.06,Logo,Title,0000,0000,0000,,B{\fs21}eing...
問題は &H3140ca というカラーコードを取得する方法だ。 オリジナルと見比べながら試行錯誤でカラーコードを作っていては効率が悪い。 以下の手順は単純だが、Windows に標準であるツールだけで実現でき、便利だ。
この作業の内容から分かるように、タイプセット作業で使う（Huffyuvなどの）ビデオは、 必ず最終形と同じクリッピング、同じ色設定でなければならない。 SSA を完成させた後で、クリッピングの条件を変えたり、色補正フィルターを使うと、 最悪、すべてのタイプセットが無意味になるので、十分注意したい。
ところで、上の例で、同様に「ああっ女神さまっ」の緑色も取得し、 オリジナルと同様 Being...の文字のすぐ上に Ah! My Goddess と緑で入れたいと思うかもしれない。 それを SSA でやろうとするとコリジョンになって、後から入れた行が重ならないように逃げて（自動的に位置がずれて）しまう。 Zインデックスを離してレイヤ処理できる ASSフォーマットが必要になる場面だ（または ASS の pos タグでもできる）。 タイプセットの幅を広げていくと、だんだん SSA では処理できない状況が出てくるのが分かる。
2004年9月22日 ColorCaptor SSA (CCSSA)
画像内の色をSSAの色コードとして取得する。
起動すると現在クリップボードに画像があれば、それを表示します。 十字カーソルを動かすと、カーソルの下のピクセルの色が左下のエリアに表示されます。 望む色が指定されたのを確認してから、マウスをクリックすると、 その色の色コードが、SSAの色コードの形式で、クリップボードに送られます。 （[Shift]+クリックでは、10進数で送られます。）
使い方の例 (1) VirtualDubMod でタイトルロゴを表示させ、[Ctrl]+[1] を押す。 (2) CCSSAを起動すると、そのフレームが表示させるので、タイトルロゴの上にカーソルを持って行く。 (3) 左クリックすると色コードがクリップボードに書き戻され、エディタのSSAファイルに貼り付けできる。
色ムラを補正する機能などもあります。 詳しくは付属のreadme参照。
EmEditor で SSA/ASSファイルを構文強調表示するための定義ファイル。 v0.2 では Sabbu で生成したASSファイル（Layer番号の前に複数個の半角スペース）にも対応。
カラオケは K または kf を黄色、k を水色で着色表示。 フィルか瞬時か一目で分かる。 スタイル定義でエンコーディングが128（日本語）の行は色が変わる。 日本語はこの128を忘れると Windows 98で文字化けする。 逆に西欧語に 128 を指定しても文字化けする。 間違いやすいので色分けした。
Advanced系も含めて、全てのタグは強調表示。
他に、問題になりやすい部分は黄色や赤で着色して注意する。 スタイル名が Default （潜在的にトラブルの原因）、 PlayResX/Y が4桁ある、 feタグを使っている（Linuxでサポートされない）、 エフェクト名としての Karaoke（非推奨）など。
例えば、PlayResX/Y は現状 640x480 が多い。 横1000ピクセル以上の解像度もありうるが、 それより、Sub Station Alpha から書き出したSSAファイルを単にそのまま使っている間違いの可能性が高いので、 黄色で確認を促す。着色表示が出ても必ずしもエラーではなく、分かってやっているのなら問題ない。
定義ファイルの使い方。 Tools | Select configuration | Define Confuguration | New | Use Default Configuration で新規項目を作成、 分かりやすい名前（SSAなど）をつけて、閉じる。SSA ファイルを EmEditor で開いたら、 Tools | Select configuration | SSA で今作った仮の設定ファイルを呼び出す。 Alt + Enter を押す。SSA Properties が開く。Highlight (1) タブの Import から、.esy ファイルを読み込む。 さらに Association タブで、拡張子 SSA と ASS をこの設定にする。
EmEditor は一般的にはあまり使いやすくないので、 他のフリーのエディタ用の同様の定義ファイルも作ってみたいと思ってます。 構文定義も「キーワード指向」で「行頭」「行末」という発想に乏しいので、作りにくかったです。 しかも正規表現の行頭が ^ でなくて ^^ になってました。 バグだか仕様だか分かりませんが、とりあえず現在の EmEditor で動くように、合わせてあります。
2004年10月16日 ShiftSSA v0.1 - SSA/ASSのタイミングを「フレーム単位で」ずらす
http://park14.wakwak.com/~flower/ShiftSSA/shiftssa01.zip
タイミングをずらすのは字幕ツールの基本機能ですが、 たいていは時間でずらすようになってます。例えば、23.976 fps の映像に対して字幕を1フレームずらすには、 時間としては約42ミリ秒のシフトですが、時間で指定すると、丸め誤差のため、実際のシフト量は場所によっては2フレームになったりします。 字幕のタイミングをフレーム数を単位としてシフトさせる機能がほしかったので、 適当に作ってみました。
フレーム #30000 以降（0起点）の字幕をちょうど3フレームずつ遅らせたい/早めたい、といった、 （対音声でなく）対映像でタイミングの微調整が必要なとき、使います。
ファイル名にも、ファイルの中身にもユニコードが使えますが、その代わり古い Windows では動作しません。 ユニコード以外でも主な言語のファイルをすべて開けますが、 その代償として、UTF-16以外のファイルは開くたびにいちいちこの文字コードは何かと聞いてきます。
試しに作ってみた v0.1 なので、致命的な不具合があるかもしれません。
Tip (20041129): Unicode SSA の場合、 Windows XP では、Verdana などの \fe0 系スタイル内に日本語などのいわゆる Unicode 文字を混在させても、 フォントリンク機能により、正常に字幕が表示される。しかし、Windows 2000 では、これはうまく行かない。 したがって、互換性を保つために、次のようにする。
Nihon or Nippon, {\fnMS UI Gothic}日本{\fnVerdana}, means "Japan."
{\fe128} 指定は非推奨だが、Windows 98 との互換性のために使っても良い。 フォントを元に戻すとき、{\r} でラクをする癖をつけないように。 後から全体に色やフェイドなどのエフェクトをかけたいとき {\r} でエフェクトが中断してしまう。
Tip (20041129): 矢印キーを押しっぱなしにして、1フレームずつ確認したいとき、
コマ送りの速度は、コントロールパネルの keyboard にて調整できる。
(20050416)
Repeat delay は「どれだけ長く押したとき押しっぱなしと認識されるか」を調整する。
敏感（Short）にし過ぎると、1コマだけ送りたいときに連続押しとみなされて2コマ（以上）送られてしまうことがあるから、
着実に1フレームずつ送るには、ある程度 Long にした方が良い。
Repeat rate は「押しっぱなしと認識された場合に、どのくらい速くキー入力を反復するか」と調整する。
時間をかけてていねいにフレームごとの確認をしたいときは Slow に、
手早く軽く処理するとき（目立つゴミだけ処理するような場合）は中間的な値にすると良い。
Tip (20041207) \fadによるフェイドでは、\1aが非ゼロのとき、透過した\1cの「下」に\3cが「漏れて」いる。 例えば、ボーダーが黒系のフォントでは、フェイスが灰色っぽく濁り、ボーダーが青のフォントではフェイスが白でもアルファが非ゼロのとき青みを帯びる。 これはシャドウ（\4c）が透けて見える現象とは別。\tでフェイドさせればこの問題は回避できる。
Tip (20041207) フェイドと\be1を併用すると、アルファが非ゼロのとき、予期せぬ相乗効果で斑点状のノイズが発生する場合がある。
Tip (20041207) \p1による図形描画では、\posと違い、Zインデックスが等しければ、コリジョンの自動処理が行われる。 したがって、描画コマンドの座標は、Zインデックスが明示的に指定されていない場合、描画位置が絶対的でない。 複数個の\p1を併用して描画する場合、必要に応じてZインデックスを正しく指定する必要がある。
Tip (20041208) 文字列を回転させるような効果などで、自動改行を禁止して、文字列の端が表示範囲外に出ることを許可したい場合がある。 理論上、ハードスペース \h を使って実現できる可能性もあるが、ワードラッピング自体を直接抑制する \q2 タグを使うのが早くて便利だ。
Tip (20050423) 二重の輪郭（異なる輪郭色）を持つ文字を作るには、例えば次のようにする。 下のレイヤーに bord4, shad0 で文字を描く。 同じ位置のZ方向上方に、同じフォント、同じフォントサイズの bord3, shad0 で 1c と 3c が異なる文字を描く。 これがフェイスカラーと内側の輪郭色となる。下のレイヤーで、はみ出ているボーダーの1ピクセル分が、 外側の輪郭色となる。
Tip (20050423) 「1a非ゼロ時に3cが1cに干渉するバグ」の一般的で確実に効果がある回避法は、 フェイスとボーダーを別レイヤで別々に描画すること。
Tip (20050423) \fad(100,0) のような通常のフェイド に対して、1a非ゼロのとき1cに3cが干渉するバグを避けるために、
\t を使った高品位フェイドがある:
{\1a&Hff&\3a&Hff&\4a&Hff&}{\t(0,1000,\1a&H00&\3a&H00&\4a&H80&)}
すなわち全アルファを0xffで初期化してから、
1000ミリ秒（カラオケのタグと時間の単位が違うことに注意）かけて本来のアルファに変化させる。フェイドアウトも同様に指定できる。
しかし、これだけでは必ずしも最高品質が達成できない。その理由は、フェイスのアルファが0xffから0x00まで変化するのに対して、
シャドウのアルファが同じ時間をかけて0xffから0x80まで変化するため、シャドウの「濃くなる速度」が2倍であり、
変化開始直後にフェイスはまだ淡いのにシャドウがかなり濃いためである。
この問題を解決するには、いくつかのトリックが考えられるが、
手っ取り早くきれいな結果が得られる一つの方法はこうだ。
{\1a&Hff&\3a&Hff&\4a&Hff&}{\t(0,1000,\1a&H00&\3a&H00&)}{\t(500,1000,\4a&H80&)}
要するに、変化初期には陰を描写せず、フェイスのアルファが中間の値となった時点から陰のフェイドインを開始している。フェイドアウトも同様に考えることができる。
Tip (20050606) 上述の高精度フェイドでも、なお、輪郭色と表面色の干渉を完全に避けられない場合がある。 一般解としては、Tip (20050423) にあるように、 表面色だけのレイヤーと輪郭色だけのレイヤーに分けて、1aと3aを完全に独立して制御すること。 つまり、同一の字幕データがZインデックスを変えて2回現れることになる。
