前 9 - 11 P ｜ 
もくじ I ｜ 次 9 - 13 N 
高品質のSSA/ASS字幕では、ビデオの1フレーム単位の精度で、字幕のオン・オフが制御される。
プレインテキストとしての字幕の作成、つまり翻訳・編集作業の終了後、 字幕を実際にムービーと合体（ハードサブまたは多重化）できるように準備するまでには、いくつかのステップがある。 字幕をSSA/ASS形式で作成する場合、基本的なのは、字幕のスタート／エンド時刻を決めるタイミング作業と、 字幕用のフォントや色を選ぶスタイリング作業であり、それぞれ入門編で扱った。しかし、 それらはあくまで字幕作成に必要な最低限度の作業であり、テキスト作成とエンコードの間の広義タイプセッティングには、 次のような広範な作業が含まれうる。
上級とは文字通り特に高品質のトップクラスの仕事にのみ必要なもので、一般にはそこまでする必要はない。 準上級は、一般のタイプセッターでも知っているべき知識だ。 例えばサインのひとつも処理できなければ、まともなタイプセッターとは認められないだろう。 中級は（入門的ではないものの）さらに基本に近い技術である。 まともなタイマー、まともなタイプセッターは、フレームタイミングができなければいけない。 これは単に字幕のオンオフを特定のフレーム（シーンチェンジや口パクなど）と同期させて、 変にタイミングをずらさない、というだけの、基本的なことなのであるが、 その深層には「タイミングのノーマライズ」「フェイド等のサブフレーム精度」を軸とする微妙で深い理論的問題も横たわっている。 それらは別のメモで詳しく扱う。
以上で、テキストだけの字幕原稿が、実際に使えるASSスクリプトになるのである。 作業量は場合によって大きく異なるが、目安として、カラオケがない場合で、 レタッチ50、レタッチチェック20、タイミング10、スタイリング・サイン等10、対映像タイミング10と思ってほしい。 （これは原稿とエンコードの間の作業のことであり、もちろん「その前」の翻訳・チェック・推敲も大変な作業だし、 「そのあと」のエンコード・チェックなども大変な作業である。）
2009-04-02 追記: レタッチは「フィルター」に近いので、タイプセットよりエンコードに含めるべきだろう。 全体を100として、 基本のスタイリング50、シーンチェンジタイミング10、クチパク開口10、クチパク閉口10、サインなど10、全体の確認と仕上げ10という目安になる。
SSAスクリプトの完成度を高めるためのチェック作業・微調整について説明する。 中心となる考え方は「フレーム・タイミング」だ。 シーンチェンジと字幕のオンオフが少しだけずれると、 一種のフリッカー（ちらつき）が生じ、好ましくない。 そこで、ビデオの1フレーム単位の精度で、特定のフレーム（上記の場合、シーンチェンジの直前または直後のフレーム）に同期するように、 字幕のオンオフを行うべき場合がある。 また、一般的な音声と画像の「リップ・シンク」に加えて、 話者が口を開く瞬間、口を閉じる瞬間に同期するように字幕のオン・オフさせるのも、場合によっては好ましい。 このように、音声のタイミングと字幕を合わせるのとは別に、 映像の1フレーム単位の精度で、字幕をコントロールする技術が「フレーム・タイミング」である。
この文書では、 入門編（タイミング、スタイリング）を一通り理解した学習者を対象に、 シーンチェンジに対するフレーム・タイミングの諸問題を詳しく扱う。 リップ・シンクについても、ほぼ同様に考えることができる。
タイミングツールとして Sub Station Alpha の名前を出しているが、他ツールを使う場合でも同じことだ。 実際、これは特定のタイミングツールに関する作業ではなく、音声タイミングが終了した後で、 別途、手動で、微調整する部分である。
ここで紹介する内容は、必ず行わなければいけない義務的なものではない。 やり方を知っておいて、特に品質にこだわりたいとき、必要に応じて行えば良い。 目立たないところに時間をかけて物を作りあげていく、 趣味ならではの創造の楽しさを、感じていただければと思う。
字幕についての細かい技術的な議論が続くが、 実際の作業では、単なる技術的優劣や腕自慢ではなく、 常に作品への素朴な敬愛の気持ちを基本としなければならない。
Advanced SSA（ASS）を中心とする上級向けの記事が準備できていないので、 便宜上、本文書の末尾で「ヒント」として、高度なトピックをいくつか簡単に取り上げている。
この文書の最新版は
http://www.faireal.net/articles/9/12/
にある。
内容についての要望、フィードバックは、 掲示板までどうぞ。
このセクションでは 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秒早めにして、 字幕をプリロードすることがしばしば行われ、経験上、その方が見ていて快適なことが多い。 おそらく、字幕が表示開始されて視神経に刺激が行ってから脳がその文字を認識するまでに微妙に遅れがあるため、 音声の立ち上がりと完全に同時では、心理的に字幕が遅れているように感じられるのかもしれない。
字幕のタイミングをするとき、スタートタイムは（好みによっては）立ち上がりよりわずかに早めでもいい。 遅れて出るくらいなら、早めに出たほうがいい。
これと対照的に、音声の立ち下がりを超えて字幕がオーバーランすると、一定確率で悪い結果を招く。 音声に対するオーバーランは問題にならないこともあるが、そこにシーンチェンジがあるとまずい（後述）。 エンドタイムは立ち下がりと同時がいい。どちらかといえば、遅すぎるよりは、ごくわずかに早すぎるくらいでいい。
2009-04-09 追記: ここで「遅すぎる」とは500 msとか1000 msといった理不尽な残留を意味する。 ほんのわずか、40～200 ms程度なら、エンドが立ち下がりより遅いことはむしろ好ましいと示唆される。
第一に音声と字幕の関係を注意深くチェックする。 音声との同期ずれには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系のエフェクトを使いこなす基本としても、映像と字幕のタイミングの取り方は不可欠の知識だ。
確認作業では、音声とのタイミングより、むしろ映像とのタイミングの調整がメインと考えてほしい。
以下では、関連する話題をいくつかのサブセクションに分けて説明する。 何度か加筆を繰り返したため、やや見通しが悪い。 そこで、最初にポイントをまとめておく（この要約中の特殊用語については、本文中で詳しく説明してある）。
基本的には通常の字幕は、音声に同期させる。 字幕に対応するせりふの声の出だし・声の終わりのタイミングが同期ポイントとなる。
しかし、次の段階としては、映像との同期を考える必要がある。 映像の同期ポイントは、(1) シーンチェンジ、(2) リップシンク（人物が口を開く・閉じる＝話し始める・話し終わる）、 (3) 標識その他の視覚的サインなどがある。本稿では主に (1) を解説する。 なお (2) のリップシンクは、通常は音声と映像の同期について言う言葉だが、 字幕のスタート、エンドも、必要に応じて、映像に対してリップシンクさせることができる。 狭義のリップシンクの問題がある場合、 例えば映像では人物が口を開いているのに、音声が遅れていてまだ出ない場合において、 字幕は映像側に同期させるのが良い。もちろん、字幕加工の過程の内部でA/Vの非同期（音ズレ）を発生させてしまうのは問題外だが、 字幕をつけたい作品自体が最初からリップシンクしていないこともある（旧作アニメなど）。 (3) は Advanced SSA (ASS) の範囲であり、それについては別記事で詳しく説明する予定だが、 特定の映像のフレームをSSAでどうやって指し示すのかというのが出発点となる。 例えばフレーム100から200までに乗っていて201では消えている字幕、 というものをSSAではどう記述するのか（SSAはフレーム番号ではなく時刻でタイミングを指定するので）、 それさえ押さえておけば、さまざまな発展・応用ができる。 それは (1) や (2) を通して、身につけることができる。
「字幕が出るのが0.2秒遅すぎる」「これは0.4秒長すぎる」といったタイミング感覚は、 一般の人から見たら細か過ぎてついていけない話に思えるかもしれない。 けれど、これは少し経験を積めば自然に身につくもので、 決して難しいことではなく、単なる体感（慣れ・経験）に過ぎない。 字幕を利用する側はそんな細部に気を止める必要ないし、 実用になれば良いといった目的での字幕作成でも無視できるが、 より良い品質のもの、特にカラオケなどの特殊効果まで考えるなら、 フレームタイミングの諸問題は、どうしても避けて通れない。
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日 初版
2005年11月21日 ver. 0.3.0: "Grad4"を追加
2005年11月30日 ver. 0.3.1: エラー処理
画像内の色をSSAの色コードとして取得する。
起動すると現在クリップボードに画像があれば、それを表示します。 十字カーソルを動かすと、カーソルの下のピクセルの色が左下のエリアに表示されます。 望む色が指定されたのを確認してから、マウスをクリックすると、 その色の色コードが、SSAの色コードの形式で、クリップボードに送られます。 （[Shift]+クリックでは、10進数で送られます。）
使い方の例 (1) VirtualDubMod でタイトルロゴを表示させ、[Ctrl]+[1] を押す。 (2) CCSSAを起動すると、そのフレームが表示させるので、タイトルロゴの上にカーソルを持って行く。 (3) 左クリックすると色コードがクリップボードに書き戻され、エディタのSSAファイルに貼り付けできる。
色ムラを補正する機能などもあります。 詳しくは付属のreadme参照。
2009-04-09 追記: 現在ではより便利なa3rがある。
EmEditor で SSA/ASSファイルを構文強調表示するための定義ファイル。
2004年8月23日 EmEditor Syntax File for SSA v0.1
2005年3月26日 EmEditor Syntax File for SSA v0.2: Sabbu で生成したASSファイル（Layer番号の前に複数個の半角スペース）に暫定対応。
2005年6月20日 EmEditor Syntax File for SSA v0.3: カンマが三つ並んだとき（,,,）警告表示するようにした。
2005年12月5日 EmEditor Syntax File for SSA v0.4: \fadeと\fadの定義順序のため\fadeがハイライトされない不具合修正。
2006年5月20日 EmEditor Syntax File for SSA v0.5: \alphaと\aの定義順序のため\alphaがハイライトされない不具合修正。
カラオケは 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 Configuration | New | OK (Use Default Configuration) で新規項目を作成、 分かりやすい名前（SSAなど）をつけて、閉じる。SSA ファイルを EmEditor で開いたら、 Tools | Select configuration | SSA で今作った仮の設定ファイルを呼び出す。 Alt + Enter を押す。SSA Properties が開く。Highlight (1) タブの Import から、.esy ファイルを読み込む。 さらに Association タブで、Enable association: Add: 拡張子 SSA と ASS をこの設定にする。
EmEditor は一般的にはあまり使いやすくないので、 他のフリーのエディタ用の同様の定義ファイルも作ってみたいと思ってます。 構文定義も「キーワード指向」で「行頭」「行末」という発想に乏しいので、作りにくかったです。 しかも正規表現の行頭が ^ でなくて ^^ になってました。 バグだか仕様だか分かりませんが、とりあえず現在の EmEditor で動くように、合わせてあります。
2009-04-09 追記: 「EmEditorのSSA/ASS構文強調を素早くオンオフする方法」も参照のこと。
2004年10月16日 ShiftSSA v0.1 - SSA/ASSのタイミングを「フレーム単位で」ずらす
タイミングをずらすのは字幕ツールの基本機能ですが、 たいていは時間でずらすようになってます。例えば、23.976 fps の映像に対して字幕を1フレームずらすには、 時間としては約42ミリ秒のシフトですが、時間で指定すると、丸め誤差のため、実際のシフト量は場所によっては2フレームになったりします。 字幕のタイミングをフレーム数を単位としてシフトさせる機能がほしかったので、 適当に作ってみました。
フレーム #30000 以降（0起点）の字幕をちょうど3フレームずつ遅らせたい/早めたい、といった、 （対音声でなく）対映像でタイミングの微調整が必要なとき、使います。
ファイル名にも、ファイルの中身にもユニコードが使えますが、その代わり古い Windows では動作しません。 ユニコード以外でも主な言語のファイルをすべて開けますが、 その代償として、UTF-16以外のファイルは開くたびにいちいちこの文字コードは何かと聞いてきます。
試しに作ってみた v0.1 なので、致命的な不具合があるかもしれません。
2009-04-09 追記: 現在ではより便利なa3rがある。[Ctrl]+[S] でシフト保存できる。
聞こえる人のための字幕は、外国語の部分だけを補助すれば良いが、 失聴者のための字幕は、聴覚チャンネルを介するすべての情報を、必要に応じて、文字によって補助しなければならない。 また、聞こえる人は、外国語が分からなくても声（性別、大人子どもなど）は区別できるのに対して、 失聴者は、一般の字幕だけ出されても、誰がしゃべっているか、話者がオンスクリーン正面でない限り分からない。
（失聴者用字幕）-（一般字幕） = （音全体）+ (話者情報) -（外国語の音+外国語の標識） = (話者情報) +（雑音）+ （背景音楽）
言い換えると、一般字幕でも失聴者用でも共通するのは、外国語の音（言語音）と標識（文字）の翻訳であり、 障害者用に追加すべきなのが、話者情報、雑音、音楽の処理である。
さらに、同じ聴覚障害者でも、情報処理における中途失聴者と先天的なろう者の違いに留意しなければならない。 中途失聴の場合、日本語が第一言語なので日本語字幕を拡張すれば良いが、 先天的なろうあ者は、一般に日本手話を第一言語としており、文字の日本語字幕では真のローカライズになっていない。 多くのろうあ者が文字言語としての日本語（および日本語準拠の手話）も理解するとは言うものの、 今後の課題として、日本手話通訳のサブビデオ・ストリームということを考える必要がある。 この違いはアメリカ英語（またはそれに対応した手話）とASLの関係に相当する。
以下、これらの問題について、略述する。
聞こえない人は「外国語（に限らず音声）が聞こえない」だけでなく、一般に、誰がしゃべっているか、声の違いが分からないので、 単に文字を与えただけではストーリーを適切に理解できない。 アプローチとして、基本的には「アリス: こんにちは」「ボブ: 久しぶり」のように、話者情報を文字として字幕に入れる。 ただし、主要人物ごとに字幕の色を変えることで、声の違いを色の違いに「翻訳」しても良い。 また、オンスクリーン正面で口が見えるなど、誰がしゃべっているか自明のときは、話者情報を省いたほうがいい。 男性形・女性形など言葉の性質と状況から誰がしゃべっているのか明白なときも、話者情報は省略できる。 小説でも、「～と○○は言った」という地の文を省略して、会話文だけが続くことがあり、 それでも誰がどのせりふをしゃべっているか分かる。 情報は多ければいいものではなく、必要十分ちょうどが良い。冗長な（不必要な、多すぎる）情報は作品を楽しむ妨げになる。 逆に、オフスクリーンだったり、オンスクリーンでも複数人物が映っていて誰のせりふか自明でないときは、話者情報を入れる。
健常者にとって「ドアの開く音」「銃声」などの非言語音は翻訳不要である。 聴覚障害者は、それが聞こえない。そして、その部分が了解できないとストーリーが理解できないことも多い。 例えば、電話が鳴って人が顔を上げたとき「電話が鳴る」と文字化しないと何で顔を上げたか分からないし、 背後で銃声がして振り向いたり走り出したりしたときもそうだ。「ハッと息を飲む」「笑う」「うなる」などの非言語音声も、 文字化しなければならない。
基本的には、映画を小説化するとして、どうするかと考えてば良い。 ただし、実際には、小説のようにすべてを文字化する必要はない。 「銃声」は見ても分からないので文字化するが、 「驚いた様子で振り返る」は見れば分かるので文字化しない。
音楽も抽象的に、文字化できる。 特に、中途失聴者であれば、「柔らかなピアノ曲」「静かなオーケストラ曲が鳴り出す」「音楽が高まる」「激しい音楽」など、 文字から豊かなイメージを喚起できる。
音楽を必要に応じてうまく文字化する目的は（上記のようにムードを出せる以上）マルチメディアとしての作品全体をより良く味わうためという意味もあるが、 さらに重要なこととして、作品中には音楽が高まってせりふがしばらく止まる場所が往々あり、 聞こえない人は何で突然誰もしゃべらなくなったのか、何が起きているのか理解できないという問題が生じるからだ。 ストーリーの途中で（そういう意図ではないのに）何が起きているか理解できない状態になることは、 フラストレーションがたまるばかりか、作品世界に没入できなくなるので、正しい配慮が必要だ。
ところで、先天的に聞こえない人にとって「柔らかなピアノ曲」などの文字情報がどういうイメージを喚起するのか、 健常者には理解することが難しい。聞こえない人でも振動やダンスなどの「リズム」は感覚的に理解できるが、 音楽に限らず「大きな」爆発音だとか「小さな」ささやき声という文字情報を“逐語的”には理解できないと考えられる。 しかし他の感覚チャンネル（強烈な光と弱い柔らかな光、強いにおいとかすかなにおい、塩辛い味と薄塩味、激しい抱擁と優しい抱擁など）からの類推で、 ある程度のイメージはつかめる。 「柔らかなピアノ曲」も「柔らかな」は十分に意味を持つのである。 あなたが健常者だとして、このことを理解するには、次のような例を考えて見れば良い。
映像と音声で、ふたりの妖精がしばらく早口で会話しているとする。 あなたにとっては不明な理由で、急に会話がとぎれて、 文字として「フェアリーネス」と出たとしよう。 しばらくして今度は「フェアリーシュなウェリリギスが静まる」と出て、それから最初の妖精たちが、 互いに別れを告げて去ってゆくとしよう。
あなたとしては何が何やらよく分からないだろうが、たとえ意味が分からなくても、 「フェアリーネス」「フェアリーシュなウェリリギスが静まる」という文字があったほうが、間がもつだろう。 何も情報がなく、突然なぜか会話がとだえ、しばらくしたら急に「さようなら」になるより良いし、 「フェアリーシュ」とか「ウェリリギス」の感覚がなくても「静まる」という部分から、 極めて抽象的ながら背景効果がどのようなものか一定の理解はできる。
ただし、日本手話を母語とするろう者にとって、文字日本語は厳密に言えば母語ではない。 上の例で言えば、「フェアリーネス」という（あなたにとってよく意味の分からない）字幕は、カタカナの「フェアリーネス」でなく、 実はアルファベットの fairyness と表示されていることになる。それでもなお、まったく何も表示されないよりは良い。
知っておくと役立つことがあるちょっとしたヒントのたぐいを、順不同で、ごく簡単に取り上げる。 本来もっとずっと長い議論が必要なものもある。
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} でエフェクトが中断してしまう。 （注: なお Encoding 0 では機能しないフォントもある。）
Tip (20041129): 矢印キーを押しっぱなしにして、1フレームずつ確認したいとき、
コマ送りの速度は、コントロールパネルの keyboard にて調整できる。
2009-04-09 追記: 現在ではより便利なa3rがある。[Ctrl]+[Shift]+[G] で調整できる。
(20050416)
Repeat delay は「どれだけ長く押したとき押しっぱなしと認識されるか」を調整する。
敏感（Short）にし過ぎると、1コマだけ送りたいときに連続押しとみなされて2コマ（以上）送られてしまうことがあるから、
着実に1フレームずつ送るには、ある程度 Long にした方が良い。
Repeat rate は「押しっぱなしと認識された場合に、どのくらい速くキー入力を反復するか」と調整する。
時間をかけてていねいにフレームごとの確認をしたいときは Slow に、
手早く軽く処理するとき（目立つゴミだけ処理するような場合）は中間的な値にすると良い。
(20050724)
単にフレーム・タイミングを確認するだけなら、リアルタイム（つまり24fpsを24fpsで再生）で十分（それで見切ることができる限りにおいて）。
一方、フレーム・バイ・フレーム・レタッチングにおいては、
Repeat rate は、通常処理では Slow → Fast の中間 50% くらいが良い。
高速（簡易）処理では 75% 程度、ていねいな処理では 25% 程度。
キーを押下したままホールドしているときに、まばたきをしてはいけない。まばたきをする前に必ずキーを上げる。
目を開いた直後は動態視力が完全でないことがある。
まばたきをして、ハッキリ見えるように集中できるようになってから、キーをホールドする。
3000フレームあたり30分を目安に、休憩をはさみながら作業する。休憩をのぞいた正味では約24分の1話あたり6時間程度を見込む。
集中力と根気が必要で神経に負担がかかるので、まとめて大量にやろうとせず、何日かに分けてやるようにする。AviUtl ではウィンドウを最大化して、
スクリーンに集中のさまたげになる余計なものが入らないようにする。（これはフレーム・バイ・フレーム・レタッチングの話。フレーム・タイミングではない。）
また「1パス」でゴミが完全除去できると思わないこと。ゴミ探しをするとなると、640x480は意外と広いし、42msは短い。
1フレームずつレタッチしたあと、リアルタイムで再生して再チェックすると、意外と取り残しが見つかることが多い。
この問題は改めて、詳しく取り上げる予定。
(20060504) 再生して、もともとビデオ内にある文字と字幕の同期を見る場合、 OPなどでは「カラオケのタイミング」「クレジットの文字同期」「歌詞の文字同期」の3回に分けて、 3回再生して確認するくらいで良い。
(20060603) keyboard repeat-delay は最短0（約250ms）から、 最長3（約1000ms）まで4段階の設定ができる。 個人差の問題だが、 0では慎重な作業に対してキーの反応が過敏過ぎるから1（約500ms）が良いかもしれない。 keyboard repeat-speed は最低速0（約2.5回/秒）から最高速31（約30回/秒）まで32段階（絶対速度は、 ハードによって、最大20%の差がある）。これも個人差・ハードなどの環境差で変わるが、 あまりに速過ぎて「あれ、今ゴミがあったかな」と戻って調べる必要が出ると、かえって遅くなる。 ゴミが見えたらすぐ止まれる速度が良い。やはり中間あたりの13～15（約14回/秒～ 16回/秒）が目安となるかもしれない。 動態視力に自信があれば、もっと速くしても良い。 リピート速度が遅過ぎても、ゴミ検出率は上がらず、能率が下がる場合がある。 時間軸方向で鈍く瞬くようなゴミは、ゆっくりコマ送りするとかえって検出できない可能性もある。
フレーム修正は、ある程度試行錯誤・経験を重ねて自分なりのやり方をつかむしかないと思われる。 トリッキーな要素もある。 ヒントとして、アニメは一般に、同じフレームが繰り返される可能性が高いから、 汚いフレームがあってもレタッチせずコピペで修正できる可能性も高い。 コーデックの特性もあり、経験上、特に旧作では、 シーンチェンジ前後のフレームは汚いことが多い。 いわゆるリミテッド・アニメでは典型的には3コマ、場合によっては2～6コマ同じフレームが反復されるので、 その冗長性により汚いフレームを修復できることが多い。本来同じフレームなら、 いちばんきれいな場所からコピペで完全にアイデンティカルにしてしまうと、CFRの場合、 圧縮効率上は最適となる。 一般に、同じに見える2フレームは、後のフレームの方がきれいなことが多い。 ビットレートが不足気味でも差分表現が「収束」するためと思われる（シーンチェンジ直後は、 レート不足でかつIフレームでないと、所与のフレームサイズでは表現できなくなる）。 リミテッドではシーンチェンジ直後、同じフレームが連続するときは6コマ先までは見た方が良いようだ （作品によっても異なりうる）。 口パク・シーンでは他に閉・半開・開の3種類のフレームが適当にリピートしており、 概して汚いフレームを修復しやすい。 より複雑なケースで、 少し離れた場所から良いフレームを見つけるためには、AviUtlを二つ起動しておくと良い。 またレタッチが必要な場合、メインのAviUtlを最大化しておけば、どこで右クリックしても、クリップボードに送ったり、 クリップボードから貼り付けたりできる。フレームの上までマウスカーソルを動かす必要ない。 フレームの一部だけが汚い場合、前後のフレームから部分コピーして修復できることが多い。 また単純なゴミは手動でサッとレタッチしてしまうのが最速なこともある。 本当は同じフレームでなくても、重要でない・修復困難・そのままでは汚過ぎるなどの理由で、 前後のフレームをコピーして代用してしまうことも可能だが、それは本質的にコマ落ちだから乱用は禁物。 忠実度の犠牲と、主観的きれいさのトリッキーなトレードオフとなる。
目安として、3000フレームを15～30分で、3000フレームごとくらいに休憩した方が良い。 プロジェクトを保存して、何日かに分けて作業するのも良いだろう。 フレーム修正は神経の負担が大きい細かい作業なので、ストレスにならないように工夫すること。
(20060611) あくまで目安で、 ハードウェアや環境によっても異なるが、 一例として、筆者は、keyboard repeat-speed が 17 では早すぎる。15～16が良い。
フレーム修正は、まとめてやろうとしたり、ノルマがたまるとストレスになるので、 計画的に例えば 1回3000フレーム、1日3回、の3日くらいでやると良い。 1日30分時間がとれるなら3000フレームはやるべき。 つらい仕事だが、ため込むとますます大変なので、音楽でも聴きながら毎日こつこつやろう。
2009-04-10 追記: 3000フレーム×3、なら、ざっとなら2時間以内、わりと丁寧にやっても3時間ほどで処理できる（とことん丁寧にやるときりがないが…）。 つまり1日9000フレームなら、それほどストレスなく、仕事・学業と両立可能だろう。 1フレームずつのチェックとレタッチ（ゴミ取り）はクレイジーな作業だと思われるかもしれないが、 アニメの1話はざっと3万5千フレームだから、1日9000フレーム×4日なら十分に現実的だ。 実際には、それより多少きついスケジュールをこなすことになる場合が多いかもしれないが、 タイプセッターとして、フレームごとのレタッチは非常に役立つ技術でもある。 ほんの一例を挙げると、止め絵のサインサブなら、フレーム処理によりrawの揺らぎさえ吸収してしまえれば、単なる文字出力で処理できる。 旧作でrawのフレームに微妙な揺れがあったりすると、 単純な文字出力だと止まっているはずのサインが動いて見えてしまう（正確に言えばサインは止まっているが背景がきっちり止まっていない）。
AviUtlを最大化するのは、どこでも右クリックができるようにすることのほか、 他のアプリのウィンドウが目に入らないようにして集中を高める意味もある。
2009-04-09 追記: AviUtlの「ファイル」メニューからいろいろショートカットを設定しておくと便利だ。 手元では [Ctrl]+[D] で「現在のフレームをクリップボードにコピー」（好みによっては [Ctrl]+[Shift]+[C] でも良いが、 頻繁に使う操作に対して3キー同時押しはやや面倒）、[Ctrl]+[↓]で「現在のフレームにクリップボードから貼り付け」にしている （好みによっては [Ctrl]+[Shift]+[V] や [Ctrl]+[F] などでも良いだろう。）
品質重視の場合、2パス目は必ずやった方がいい。 1パス目で目立つゴミはほぼ取れているはずだから、 2パス目は速い。取り残しをどんどん処理でき、効率が良い。 既に1パス目で10～20時間かけているとき、 1～2時間かけるだけで、完璧度がグッと上がる。
(20060614) 例えば「3000フレーム→5～10分休憩→3000フレーム（→5～10分休憩→3000フレーム）→いったんやめる」とする。 3000フレームごとに長々と休まず、やるときは短い休憩をはさんで一気にやる。 休憩のときは真剣に目を休め、体をほぐす。 「息抜きにゲームをやろう」などと目が疲れることはやらない。
Tip (20041207) \fadによるフェイドでは、\1aが非ゼロのとき、透過した\1cの「下」に\3cが「漏れて」いる。 例えば、ボーダーが黒系のフォントでは、フェイスが灰色っぽく濁り、ボーダーが青のフォントではフェイスが白でもアルファが非ゼロのとき青みを帯びる。 これはシャドウ（\4c）が透けて見える現象とは別。\tでフェイドさせればこの問題は回避できる。
Tip (20050423) 「1a非ゼロ時に3cが1cに干渉するバグ」の一般的で確実に効果がある回避法は、 フェイスとボーダーを別レイヤで別々に描画すること。
Tip (20041207) フェイドと\be1を併用すると、アルファが非ゼロのとき、予期せぬ相乗効果で斑点状のノイズが発生する場合がある。 （追記: 特殊な効果のフェイドとして活用できる可能性もある。）
Tip (20041207) \p1による図形描画では、\posと違い、Zインデックスが等しければ、コリジョンの自動処理が行われる。 したがって、描画コマンドの座標は、Zインデックスが明示的に指定されていない場合、描画位置が絶対的でない。 複数個の\p1を併用して描画する場合、必要に応じてZインデックスを正しく指定する必要がある。
Tip (20041208) 文字列を回転させるような効果などで、自動改行を禁止して、文字列の端が表示範囲外に出ることを許可したい場合がある。 理論上、ハードスペース \h を使って実現できる可能性もあるが、ワードラッピング自体を直接抑制する \q2 タグを使うのが早くて便利だ。
Tip (20051120) 単語の途中にタグをはさむ場合:
{\3c&H000000&}sam{\3c&Hff0000&}ple
この例では、samとpleの間でワードラップ（改行）されてしまう可能性がある。それを阻止するには \q2 を用い、
改行位置を \N で明示する。
Tip (20050423) 二重の輪郭（異なる輪郭色）を持つ文字を作るには、例えば次のようにする。 下のレイヤーに bord4, shad0 で文字を描く。 同じ位置のZ方向上方に、同じフォント、同じフォントサイズの bord3, shad0 で 1c と 3c が異なる文字を描く。 これがフェイスカラーと内側の輪郭色となる。下のレイヤーで、はみ出ているボーダーの1ピクセル分が、 外側の輪郭色となる。
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回現れることになる。
さらに詳しい議論は「[SSA/ASS] 高品質のフェイドイン・フェイドアウト」参照。
Tip (20050722) 順序が問題になるタグがある。 \fn の後に \fad を書くと \fn が有効にならないことがある。\fad の後に \fn を書けば有効になる。 これは特定のレンダラーのバグと考えられる。
Tip (20050722) \r はすべての変更を元に戻すわけではない。 例えば、\fad の効果は必ずしも \r で中断されないし、 カラオケ（\K など）は \r を越えて通算される（カラオケにおける \t-\r エフェクト）。 ただし \r がどこまでのエフェクトをキャンセルするかは、レンダラーに依存すると考えるべきだ。 （追記: 多くのタグを使ったときなど、まとめて元に戻すのに安易に\rを使わないこと。後からその行全体にさらに別の何かを指定するときに、 安易に使った\rのせいで効果が中断してしまうことがある。）
これらの問題は改めて、詳しく取り上げる予定。
Tip (20051206) Z方向下のレイヤーで、 輪郭線のみの文字（一般にアルファ非ゼロ）をわずかに（1単位など）ずらして描画し、上のレイヤーで重ねて本来の文字を描画すると、 上のレイヤーのフェイスが透過・半透過であっても、その真下にシャドウが透けない。 「ずらしたボーダー」でシャドウをエミュレートするのである。
Tip (20051206) \moveなどでフレームあたりの移動量が非整数単位だと（10フレームで3ピクセル移動など）、 動きが完全に滑らかにならず、移動にむらができる。通常、目立つ悪影響はないが、 フェイス、ボーダー、シャドウなどの「内部的レイヤー」や、 明示的に多レイヤーになっている文字（特にわずかにずらして重ねているもの）では、丸め誤差の関係か「移動のむら」が全レイヤーでそろわないことがある。 「むら」が発生するのは整除できない以上仕方ないのだが、その「むら」の発生の仕方が等速度で動いているはずの上下レイヤーで微妙に違うことがある。 例えば、10フレームでx=1から4まで移動するレイヤーL1と、10フレームでx=2から5まで移動するレイヤーL2とでは、 それぞれ10フレーム内のどこかで3回「量子ジャンプ」するはずだが、L1とL2で量子ジャンプするフレームが違う可能性がある。 この「むらのむら」のため、例えばシャープははずの輪郭が、移動中、視覚心理的に、少しぼやけて見えることがある。
Windowsでもフォントがシステムに存在しているかは、 OSのバージョン、言語、アプリ（MSIEやOfficeなど）の有無やバージョン、インストール状況、サービスパックなどによって異なり、 予測が困難だ。以下、参考までに、主に簡体字中国語フォントについて、 Unicode名とASCII名の対照表を挙げる。これがすべてではないし、十分に確認していないので、 あくまで参考まで。
ASCII名、Unicode名、ファイル名
以下のフォントは中国語版Windowsにデフォルトで存在する:
SimHei 黑体 simhei.ttf
SimSun 宋体 simsun.ttf (or .ttc)
NSimSun 新宋体 (?)
? 仿宋体 simfs.ttf
? 楷体 simkai.ttf
LiSu 隶书 simli.ttf (?)
YouYuan 幼圆 simyou.ttf ?
simfang.ttf 仿宋
18030
SimSun-18030 宋体-18030
NSimSun-18030 新宋体-18030
Simsun (Founder Extended) 宋体-方正超大字符集
繁体字
MingLiU 細明體
PMingLiU 新細明體
以下のフォントは中国語版Windowsにデフォルトでは存在しない（？）:
黑眉 heimi.ttf
舒体 fzstk.ttf
STCaiyun 华文彩云
STFangsong 华文仿宋 stfangso.ttf
STHupo 华文琥珀 sthupo.ttf
STKaiti 华文楷体
STLiti 华文隶书
STSong 华文宋体
STXihei 华文细黑 stxihei.ttf
STXingkai 华文行楷 stxingka.ttf
STXinwei 华文新魏
STZhongsong 华文中宋 stzhongs.ttf
以下のフォントは英語版WindowsでCJKサポートをインストールするとインストールされる。
黑体 simhei.ttf
(20060412-A)
2009-04-09 追記: 現在ではより便利なa3rがある。[Ctrl]+[F]でCJKフォントのUnicode名とASCII名を簡単に確認できる。
カラオケで文字の色変化が始まるタイミングが良くなければならないことは当然であり、 どのカラオケアーもその点は気をつける。 しかし、急所は色変化が終わるタイミングである。
空でないトークン foo が色変化開始してから、次の空でないトークン bar が色変化するまでの時間を、 foo の占有時間と呼ぶことにすると、占有時間には、 色変化イベントに費やされる遷移時間と、遷移終了後 bar の占有時間が始まるまでのパディング時間が存在する。 一般に1個の空でないトークンは、1個の遷移トークン（音符部分）と0個または1個のパディングトークン（休符部分）で構成される。
(20060412-B)
どんな華々しいエフェクトを使っていても、肝心のカラオケの色変化タイミングが不正確では台無しだ。 急がば回れで、複雑なエフェクトをかける前に、まずはタイミングだけを念入りに確認するのが良い。 何度か再生してほぼ合っていることが確認できたあと、 特に慎重を期す場合、さらに、テスト用として、いったん、 スタイル定義でセカンダリー、ボーダー、シャドウを完全透明にし、プライマリーを黄色などの目立つ色にして、 「待機中は見えず、変化に合わせて徐々に文字が現れる」状態で、音声との同期を再確認しよう。
「タイミングがどこか微妙に違う」と感じるときは、 まずはその部分を繰り返し目視し、何が早過ぎる／遅過ぎるのか目星をつけてからスクリプトを修正し、 再生して、うまく修正できたか確認しよう。カラオケの持続単位とフレームの長さの関係にも注意する。 例えば、微調整したいからといっても、1単位や2単位では実質何も変わらないことがある。
カラオケ変化の対映像タイミングについて、 10単位の加減（{\K36}→{\K26}など）はおおむね2フレームのシフトだが、 20単位加減したときは4フレーム変わるときと5フレーム変わるときがある。 カラオケ単位の粒度は粗いが、1単位の違いでも累積すると（行の後ろに行くについれて）1フレーム以上の差に拡大されることがある。
@ 24000/1001 fps
Kara Unit Video frame dur.
(centisec) (frames) (millisec)
5 1 41.7
10 2 83.4
15 3 125.1
20 5 208.5
30 7 292.0
目安として 5～8単位で1フレーム 9～12単位で2フレーム 12～15単位で3フレーム 16～20単位で4フレーム 20～25単位で5フレーム 25～30単位で6フレーム
(20060412-C)
下記はHTMLについての記事だが、字幕でも注意。
On the use of some MS Windows characters in HTML
特にフランス語などの Œ œ とチェコ語などの Š š は Win Latin では拡張ASCIIにあるが、
ISO 8859-1 ではその場所にないので、非Unicode（ANSI）の字幕では、
クロスプラットフォームでは問題を起こしやすい。
(20060616)
