8 : 07 Sabbu

← 8‒06 p↑ もくじ i 8‒08 n →

Sabbu メモ

2005年 7月11日
記事ID d50711

Sub Station Alpha の後継となるフリーソフトウェア Sabbu 0.2.5 について。

Sabbu 0.2.5 スクリーンショット

0.2.5のインストーラで同時にGTKランタイム(2.6.8)をインストールした場合、 初期状態で日本語は文字化けしている。 pango.aliases と gtkrc を sabbu025ja-fix.zip内のものと置き換えれば、解決する。 上記 gtkrc のフォントサイズは10。大きすぎれば、font-size-9フォルダ内の gtkrc を、 小さすぎれば font-size-11 フォルダ内の gtkrc を使えば良い。

GTK+ and The GIMP installers for Windowsのページにある 2.6.8-1 を手動で入れた場合、 OSのシステムフォントが Tahoma なら初期状態で日本語が表示されるが、 フォントが不自然。中国語・韓国語フォントの優先順位が高く、それらが漢字・ひらがな・句読点を持っているため、 通常の日本語フォントと違う字形が混ざるため。上記と同様にカスタマイズできる。 Gimp ページのランタイムは、行儀悪く、古い日付をそのままにして、新しいものが追加されている。

0.2.5を日本語インターフェイスで使うと、1行前に移動する Alt+V というショートカットが利かない。 これは「映像」メニューのショートカットキーとかぶってしまっているため。 sabbu\locale\ja\LC_MESSAGES 内を、上記 sabbu025ja-fix.zip 内の sabbu.mo と置き換えれば解決する。

既知の問題として、日本語のフォント名(みかちゃんなど)がリストに表示されない。 またワークスペース(.sabbu)を日本語名にして、関連付けで開こうとするとクラッシュする。 このように細かい不具合はいろいろあるが、 SSAをテキストエディタで手動でいじれるユーザなら、Sub Station Alpha より便利だろう。

初期状態: 日本語UIは文字化け
PNG画像1
pango.aliases設定後: 文字化けは直るがフォントがやや小さめ
PNG画像2
gtkrc設定後: フォントサイズも制御できる
PNG画像3
「オプション」タブ初期状態
PNG画像4
「オプション」タブ推奨設定
PNG画像5
実際のタイミング作業の様子
PNG画像6
「プロパティ」タブでPlayResX/Yを指定する場合
PNG画像7
実際の映像に字幕を重ねながらWYSIWYGなタイプセットも可能だが、完成度はこれから
PNG画像8

Sabbu 0.2.5 リリース

2005年7月9日

http://sourceforge.net/projects/sabbu/

まもなく(24時間以内)正式公開される模様ですが、 初期状態では、英語以外の文字は文字化けすると思います。 また、メニューを何語で表示するかどこで選択するか分かりにくいかと思います。

文字化けについては、設定ファイルを二つ、ちょっと直すだけで解決します。 言語の選択は、スタートボタン→プログラム→GTK+何とか→Select languageで選べますが、 他のGTKアプリがあると、そちらにも影響します。他のGTKアプリに影響を与えず、Sabbuのみ英語にしたい場合、 Sabbuをインストールした先の、 locale というサブフォルダの JA (日本語)を削除してください。

Sabbu 0.2.5 のメリットとデメリット

2005年7月8日

入門者にとっては、Sub Station Alpha と、どっちもどっちなのだが、 どっちかというと、Sabbuの方が良いと思う。 Sub Station Alpha 経験者は説明不要なくらい簡単に移行でき、絶対Sabbuの方がいいが、いくつかわなもあるので、以下詳しく説明する。

まずメリットから。

任意のWAVが開ける
サブステでは8ビットモノラルにダウンコンバートする必要があって、うっとうしかった。 しかも末尾無音挿入というハックが必要とされた。オーディオエディタが必要になって、手順が複雑になってしまっていた。 個々の作業は面倒ではないし、数分しかかからないのだが、 入門段階でこれらをまとめて覚えるのは大変だった。 Sabbuでは普通のWAVならだいたい何でも開けるので、 手数が大幅に減って、 入門者にとって、大きなプラスとなる。
ロケールが日本でも動作する
サブステは少なくともWindows 2000ではロケールが日本だとTime from WAVができない。 ロケールを変えると、予期せぬ他のアプリに副作用が及ぶ。 Sabbuではこの問題がない。入門者のしきいがだいぶ下がる。
ユニコード対応!
サブステはそもそも日本語が完全に表示できないから、どう考えても日本語字幕を作るのに向いていない。 それでもASDFGのVi風一本指の速さは敵がなく、日本語のカラオケでさえ、いったんローマ字で書いてサブステで読み込むのが最速だった。 Sabbuは(上のようにGTKを調整すれば)日本語をきれいに表示でき、 サブステと同じVi風一本指も使えるので、日本語字幕作成には強い味方となる。

上記のように決定的なメリットが複数あるのだが、 以下のように問題点もある。バージョン0.2.5だからもちろんバグは枯れていないが、 主なポイントを列挙すると、

普通に保存するとUTF-8
「UTF-16で保存」というメニューがあるので、必ずそっちを使う。UTF-8ではTextsub etc.と相性が悪い。 新規作成したものをANSIで保存はできないらしい。Maestroなどと相互運用しようとすると初心者は、はまりそうだ。 UTF自体は今どきメモ帳でも開けるので問題ないだろう。
日本語でもEncoding 0
128にしないとWin98と互換がとれない。 正直、今さら感もあって無視してもいいが、直すならエディタで直すしかない。
PlayResX/Yは自動で書かれない
Sub Station Alphaでは黙っていても何かしら書いてくれたが、Sabbu 0.2.5はそれがない。 プロパティというタブでPlayResX/Yを明示的に一回ずつ指定するか、またはSSAをテキストエディタで編集。 このヘッダがないとレンダラーで何が起きるがまったく保証されないので、ソフトサブでは特に注意。
Sabbu上ではSSAでも輪郭色と影の色を独立して指定できる
Sabbuの上でそう見えるだけで、SSA形式では実際に字幕を表示すると、輪郭色に指定したものは無視される。 この問題はいろいろ対応があるが、輪郭色が指定できるASS形式で保存してしまうのがいちばん早い。 SSA形式にしたい場合、Sabbuの「輪郭色」は無視される。 SSA形式で字幕をプレビューしたいなら「輪郭色」は「影の色」を同じに設定する。
スタイル定義で太字、斜体などの指定が正の1のことがある
マイナス1でないと標準準拠にならない。マイナスがついてなかったら、エディタで手動で直す。
輪郭の太さ、影の大きさが浮動小数点
小数点以下の「.00」というのをエディタで削って整数値にしないと、標準準拠にならない。
デフォルトで[S]の挙動がサブステと違う
他がクローンであるだけに、サブステ経験者はあれっと思う部分。 サブステではWAV再生中にもう一度[S]を押すと再生が止まるが、 Sabbuのデフォでは[S]では止まらず[Q]で止まる。 再生中に[S]を叩くと「もう一度スタートタイムから再生」になる。 スタートタイムをずらしてやり直すときには、1ストローク節約できるというメリットがある半面、 いざ止めたいときには小指で上の[Q]というキーは遠い。 Sabbuには修飾キーを使った便利な機能拡張が山ほどあるが、 やはり、究極的には、ホームポジションに左手をくっつけたまま中央のASDFGだけでやりくりするのが、一番速いと思われる。
オプションメニューの「音声再生中は選択区間再生で停止」にチェックを入れると、 [S]の挙動がサブステーションと同じになる。 このオプションを使うかどうかの判断ポイントとして、 静かな会話シーンでも、何度もスタートタイムを決め直す必要があるタイマーはSabbuデフォの方がいい。 波形を見ただけで声の出だしが手に取るように分かるならサブステ方式がいい。 逆に言うと、複雑な効果音が多く波形から声が読めない場合は、Sabbuデフォが有利かもしれない。
Save as Textで保存先にタイムスタンプを入れられない
サブステではプレインテキストで保存するとき、たくさんオプションがあったが、 Sabbuでは未実装。今のところ、この問題だけは打つ手がない。

ビデオを0.01秒単位でシークするときのSSAのジレンマ

2005年6月12日

Sabbu 0.2.5 のビデオ・プレビューは現在±0.01秒の移動を許している。 SSAは0.01秒が時間単位なので一見自然な発想にも見えるが、 この仕様はデジサブの矛盾を浮き彫りにする。SSAのタイムスタンプは確かに10ms単位だが、 現実には字幕は1フレームごとしか変化できない。 23.976fpsのビデオでは42msごとにしか変化できない。 だから字幕を出せとか消せとか10ms単位で命令できても、実際にイベントの発生するタイミングは、 最長40msくらい遅れる。 フレーム単位でコマ送りする場合、このディレイは隠されてしまうが、 ±10msのプレビューを認めると、問題が表面化する。0から数えてフレーム20は0.834秒目、 フレーム20から出す字幕をSSAでは0.83と指定する。0.83とは書くけれど、これはデジサブではフレーム20を意味し、 絶対時間の0.83秒ではない。ところがSabbuは絶対時間軸の0.83に飛べてしまう。 0.83秒にはまだフレーム20は始まっていないからフレーム19を表示しなければならないが、 フレーム19にはまだ字幕は乗っていない。 0.83秒(というよりフレーム20)に開始される字幕をプレビューしたいのに、フレーム19に飛ぶことになる。 さりとて、0.83秒へのジャンプでフレーム20に飛ぶことにすれば、0.01秒単位で動かしていったとき、 フレームの変わり目がおかしな場所に来る。どっちかが破綻する。

固定FPSを前提とするなら、字幕のタイムスタンプは時間でなくフレーム番号で指定するのが正しかった。 VFRでさえ、フレームのタイミングが定義されているなら、フレーム番号で指定できる。 連続的な(フレーム単位の精度が保証されないので連続的に扱うしかない(注))アナログビデオにゲンロックしていた古代SSA(絶対時間で指定するしかない)を、 離散的なデジサブ(時間は量子化されていて42ms単位のとびとび)に用いたところに、 矛盾の芽がある。 1フレームが時間の基本単位なら、字幕のタイムスタンプもその基本単位によるべきなのだ。 SSAを「忠実」にプレビューすると、現実の姿にならない。 純粋なSSAは100fpsだが、現実には23.976fps(あるいはビデオのfps)に変換されるからだ。 ビデオの1フレーム単位でプレビューするのが現実的な解なのだ。

(注)アナログテープでは一般には1フレームの精度が保証されなかったが、 デジタルだと、処理するアプリケーションの側で厳密にフレーム単位の処理をするようになったので、 アナログでは誤差の範囲に吸収されてしまう問題をきちんと定義する必要が生じた。 それを行うとき、フレーム単位を前提としていないSSAの仕様は、必ずしも理想的ではなかった。

この記事のURL

パブリックドメイン


GTK+ メニュー 日本語 文字化け 直し方

2005年 7月 8日
記事ID d50708

GTK+上で動作する Windows アプリでは、 日本語(メニューやデータのテキスト)がしばしば文字化けする。 gtkrcを編集するだけの間違った直し方が紹介されていることが多い。 それでは文字化けが一応直っても、フォントがきれいに表示されない。

初めに

このメモは、 Sabbu 0.2.5 ユーザのためのものだが、 Gimp, Spondi など、他のGTKアプリにもほぼ共通するはずだ。

一般のGTKアプリとSabbu 0.2.5 の違いは、

GTKとは

GTK+(Gimp Toolkit)は、 簡単に言えば Java のような「クロスプラットフォームを実現するためのプラットフォーム」の一つ。 一般の Windows アプリが、基本的には「直接」 Windows 上で動作するのに対して、 GTKアプリは、GTKという中間的なレイヤーを介して動作する。 「直接」動くアプリに比べて多少効率が低下するし、開発もやや面倒だが、その代わり、同じアプリがクロスプラットフォームになる。 Linux 中心に開発されたアプリも、GTKアプリとして開発されていればWindows 上でも利用できる。 これは大きなメリットだろう。

GTK はもともとレタッチソフト Gimp のために作られたが(だから Gimp Toolkit という)、 今では、多くのアプリが GTK を利用して動作する。 2005年7月現在、Windows版のGTK環境は、日本語が文字化けするなど国際化対応が発展途上で、 ウィンドウの再描画処理が完全でないなど、完成度は必ずしも高くない。

GTKは、LGPL のフリーソフトウェアだ。 GTK同様の「クラスプラットフォームを実現するフリーの中間レイヤー」は他にもいくつかあるが、 Sabbu 0.2.5 は GTK アプリとして開発された。

文字化けの直し方

以下のファイルの編集では、 改行文字がUnixなので、対応しているエディタ(メモ帳より高機能ならたいがい対応しているはず)を使うのが良いが、 手元のテストでは、メモ帳で無理矢理開いて、適切な場所でWindowsの改行文字を入れても動作した。

Tahoma =
と指定してフォントがコントロールできるのは、 Windows側のシステムフォント(メニューなどのフォント)がTahomaに設定されている場合に限る。 Windows XP ではデフォルトでそうだと思うが、変えている人もいるかもしれない。 以下では、システムフォントがTahomaでなくてもうまくいく一般的な方法を説明する。

ステップ1: pango.aliasesを1行変更

位置の例。エディタで開く。 C:\Program Files\Common Files\GTK\2.0\etc\pango\pango.aliases

デフォルトでは、Tahoma= の行はこうなる予定。

Tahoma = "Tahoma,browallia new,mingliu,simhei,gulimche,msgothic,latha,mangal"

注: 2005年7月に Project: GTK+ and The GIMP installers for Windowsに置かれた gtk+-2.6.8-setup-1 では、実際、上記のようになっている。 そのリリースノートには gtk+-2.6.8-setup-1.zip adds a workaround for properly displaying Japanese text when wimp is used. (日本語を正しく表示するための応急処置)とあるが、 実際には、上記の方法では日本語は表示はできるが、正しく表示できない。

直し方はいろいろあるが、 とりあえずもとの行はコメントアウトし(Tahoma=の行がないパッケージでは何もしないでいい)、 改めて Tahoma= を定義して、 MS UI Gothicを2番目にするのが良い。 日本語化だからと言ってMS UI Gothicを先頭に持ってくると、英語までMS UI Gothicになる、 ロシア語・ギリシャ語も全角になる、 フランス語・ドイツ語・スペイン語等ではMS UI Gothicの中に特殊文字だけ他のフォントが混ざる、 といった汚い状態になる。一般のアプリでは実害ないかも知れないが、 必然的に複数の言語がからむ字幕アプリではまずい。 必ず2番目にすること。一般のアプリでもMS UI Gothicを2番目にした方が絶対見栄えがいいはず。 (2番目にすることの欠点があるとしたら、ロシア語を使った顔文字が正しく表示されないことくらい。)

具体的には、

#Tahoma = "Tahoma,browallia new,mingliu,simhei,gulimche,msgothic,latha,mangal"
Tahoma = "Tahoma,MS UI Gothic,browallia new,mingliu,simhei,gulimche,latha,mangal"

これはタイ文字フォントを3番目に検索したりして厳密には最適化とは言えないが、 msgothicを消して、2番目に使うフォントを入れただけ。Unicode 2の範囲を完全表示可能にするには、 末尾に Arial Unicode MS を加える。左から右へ検索するので、末尾でないと意味がない。真ん中に置いたら、 Arial Unicode MSでグリフが見つかって、それより右は永遠に評価されない。

OSのシステムフォントが全部Tahomaなら、この時点ですべての問題は解消されるが、 フォントが少し小さすぎるかもしれない。 またシステムフォントがTahomaでないと、この時点ではまだ文字化けは直らない。 いずれもステップ2で解決する。

ステップ2: gtkrcの編集

位置の例。C:\Program Files\Common Files\GTK\2.0\etc\gtk-2.0\gtkrc

次のブロックをファイルの末尾にペースト。数字の10がフォントサイズなので好みで加減。

style "my-font"
{
  # フォントサイズ(ツールチップ以外)
  font_name="Tahoma 10"
}
widget "*" style "my-font"

この指定で、wimpエンジンはメニュー等のインターフェイスで(OS自身のシステムフォントではなく)フォント名Tahomaを割り当てる。 Windows自身のフォントリンクは働かないが、働かない方がかえってカスタマイズの見通しが良く、 Tahomaの実体は、既にpango.aliasesで定義してある。OS自身のシステムフォントが最初からTahomaの場合、 上記ブロックはフォントサイズの制御のみ意味を持つ。

ボタンなどの上にマウスを置くと浮かぶことがあるツールチップは、 制御が別系統。 engine "wimp" という行の上あたりに、次の1行を足す。数字の10はツールチップのフォントサイズ。好みで加減。

  font_name="Tahoma 10"

この記事のURL

パブリックドメイン



<メールアドレス>