Martin Hagwallのマリオの歌

　かつて、Martin Hagwallなる人が、スーパーマリオRPGのハナちゃんの森のBGMに歌詞を付けて公開したところ、ネット上で大反響を得た。今、彼はさらにもう一つ作ったようだ。 http://www.users.se/tvsm/smrpg/ 本人のmp3と歌詞が手に入る。

さて、肝心の歌詞を、訳してみようと思う。

まず、テラマリオとして知られている最初の歌はどんな感じか

スーパーマリオRPG
僕だけの宝物
ゲームをすると　すぐ迷う
そうだよ、ジーノの迷路だよ

スーパーマリオRPG
僕だけの宝物
ゲームをすると　すぐ迷う
そうだよ、ジーノの迷路だよ

カエルコイン欲しい。
こおりだま欲しい。
びびりだま欲しい。
キノコ欲しい。
さよならはとつぜんに欲しい。
スターのたまご欲しい。
ヨッシーのクッキー欲しい。
ひつじのゆうわく欲しい。

全部欲しい,
もっともっと遊びたい,
カエルコインを集めなきゃ
クレジットカードを支払うために

ゲームには多くの謎がある
謎解きに熱くなる
何でチートなんかするんだい
バカげて飽きるだけさ

森を抜けるのはスーパーシンプル
ただ道を曲がるだけでいい
永遠に永遠に

ジーノの道についていけ……
ジーノの道についていけ……
ジーノの道についていけ……
僕はゲームの天才

Rawest Forest はどうかというと

The SMRPG Song, Rawest Forest - 2006
歌 by Martin Hagwall

クリボー: おい、あのマリオの野郎を知ってるか？
ノコノコ: あいつのことか？
クリボー: ああ、あのキノコ野郎だ。
ノコノコ: あー、あれね。
クリボー: そうそう、あの森の中を飛び回ってるやつだ。
ノコノコ: あー、あー、知ってる知ってる。
クリボー: よし、いいか。見に行こうぜ。

スーパーマリオRPG
僕だけの宝物
ゲームをすると　すぐ迷う
そうだよ、ジーノの迷路だよ

マリオ: カエルコインよこせ
クッパ: 来いマリオ
マリオ: カエルコインよこせ
クッパ: 来いマロ
マリオ: 「さよならは突然に」よこせ
クッパ: 来いジーノ
マリオ: クッキーよこせ

カメック: おお、与えようじゃないか　マリオよ

クッパ: ワガハイはオマエのバカげた声を聞きたくない。
マリオ: 一文にもならないこぎたないコインが欲しいんだ

ゲームには多くの謎がある
謎解きに熱くなる
何でチートなんかするんだい
バカげて飽きるだけさ

森を抜けるのはスーパーシンプル
ただ道を曲がるだけでいい
永遠に永遠に

声: こんぺいとうよこせ, クッキーよこせ, 「さよならは突然に」よこせ,
クラウンのカジノよこせ 全部よこせ

マリオ: 待て, 待て, 待て, 誰なんだ？

カリバー: ハハハハハ

カリバーの歌:
俺の名はカリバー, ラップの天使
オノレンジャーと共にさすらう刃
バカなマリオとその愉快な仲間たちに
スターロードなど直せるもんか, 直せるわけがない
(ジーノ: ジーノカッター) 瞬き早い (ジーノ: これならどうだ)
なぜなら、いつもいつも、右目ばかり攻撃されるからだ

マリオの歌:
最近は暇で意欲も沸かない
子猫たちも俺をさしてこういうよ。
配管工のイタリア人、大根ごぼうも木っ端微塵
城のお姫様を助け出せ
クッパとクリボー達を笑い飛ばす
Aボタンを押してパワーを上げろ
お金はないけれど, でも見てよ 退屈な子たちが
俺のゲームで楽しんでるよ

ダイアローグ 1:
声: よこせ
クロコ: ミーの名前はクロコデ～ス
声: よこせ　よこせ
クロコ: サイフ
声: よこせ
クロコ: サイフ
声: かえせ　かえせ
クロコ: ゲームの最後に
声: かえせ
クロコ: アイテム
声: かえせ　かえせ
クロコ: レアもの

ダイアローグ 2:
クラウンあに: やあ
マリオ: やあ、なんか気味悪いところだね
クラウンあに: ああ、そうだね
マリオ: ヒットポイントが残り少ないんだ
クラウンあに: なるほど
マリオ: なにかない？
クラウンあに: このキノコをつかうといい
マリオ: 腐ってるじゃないか

ピーチ姫の歌:
私は姫, どうか助けて
ブッキーは怖いわ
私と結婚するつもりだって聞いたけど
私はマリオと結ばれたいの

マリオ: カエルコインよこせ
クッパ: 来いマリオ
マリオ: カエルコインよこせ
クッパ: 来いマロ
マリオ: 「さよならは突然に」よこせ
クッパ: 来いジーノ


ピーチ姫: フライパンとパラソルをちょうだい

ゲームには多くの謎がある
謎解きに熱くなる
何でチートなんかするんだい
バカげて飽きるだけさ

森を抜けるのはスーパーシンプル
ただ道を曲がるだけでいい
永遠に永遠に

　star eyeが、なんなのか分からない。誰か思い当たる人は教えて欲しい。 　

　

　Exorはケンゾールじゃなくてカリバーだった。　s/ケンゾール/カリバー 　

　

　よく読んだら、クッパとクリボーを笑っているのはマリオのようなので、修正。万里夫が笑われているのだと解釈してしまった。 　

　

　ところで、blaster plantsとは、マリオUSAの引っこ抜ける野菜を台無しにすることかと思っていたのだけど、ひょっとしたら、パックンフラワーを倒すことなのかもしれない。英語ではPiranha Plant　（ピラニアプラント）と言うのだが。というかこの部分の意味がよく分からない。

　

　

　star eye をこんぺいとう、と訳してみた。 　

空気に課金しろ

http://www.itmedia.co.jp/news/articles/0707/26/news114.html

iPodやPCからも補償金を」と権利者　私的録音録画小委員会 私的録音録画補償金制度の見直しを検討する小委員会の会合が開かれ、iPodや携帯電話、PCなども補償金の課金対象にすべきなどの意見がでた。 2007年07月26日 20時53分 更新 　「私的録音録画補償金」制度をめぐり、見直しを検討するために文化庁文化審議会著作権分科会に設けられた「私的録音録画小委員会」の会合が7月26日開かれ、課金対象となる機器の範囲などについて話し合われた。 　私的録音録画補償金制度とは、MDやCD-Rなどデジタルメディアを使って音楽CDやテレビ番組などを録音・録画する場合に、一定の補償金を著作権者に支払う制度のこと。補償金はデジタルメディアの販売価格に上乗せして徴収している。 　小委員会の会合は今年8回目。権利者団体や消費者の代表、識者らが集まり、補償金の徴収方法や対象機器の範囲などの見直しを検討しており、今年中に結論を出す。 会合の様子 　「iPodなどのポータブルオーディオレコーダーや録音機能のついた携帯電話、PCなども補償金の課金対象に加えるべき」――実演家著作隣接権センターの椎名和夫さんや日本レコード協会の生野秀年専務理事など権利者側はこう主張した。 　録音・録画が主な用途ではない汎用的な機器まで対象にすれば、その機器を録音や録画以外の用途に使っているユーザーからも補償金を徴収することになってしまう。権利者側はPCやHDDも課金対象とするよう主張を繰り返してきたが、ユーザーやメーカーは反対の声を上げている。 　メディアやハードを著作物の複製に使っていないことを証明できれば、ユーザーが補償金の返還を請求できる制度もあるが、返還額が小額なことや、申請経費を請求者が負担するなど、実効性がないとの問題点がある（関連記事参照）。 　ユーザーではなく機器メーカーから補償金を徴収すればいいのではないかという意見もあるが、IT・音楽ジャーナリストの津田大介さんは「メーカーから補償金を徴収した場合、コストとして機器の価格に反映される可能性が高く、消費者の負担は変わらない」と反論した。 　野原佐和子氏（ITビジネスのコンサルティング事業を手がけるイプシ・マーケティング研究所社長）は、補償金の話からは離れると前置きした上で、ヤフーが動画投稿サイト「Yahoo！ビデオキャスト」で、ユーザーが投稿した動画で使用された楽曲の使用料をJASRACに支払う仮契約を結んだことを、新しい著作権料の支払いのあり方だと評価した。 　「どういうものが私的録音録画に当たるかを法制度で決めるのは良いが、どの機器にどれくらい課金するかというようなことは当事者間の契約で決めればいいのではないか。法制度で決めることと、市場に任せるべきことを分けて議論すべき」（野原氏）

　PCや携帯電話やmp3プレイヤーに課金しろというならば、ひとつ思うことがある。私も著作者ではなかろうか。私はPCや携帯電話やmp3プレイヤーを使って、音楽を生成している。私のPCにはマイク端子がついているし、任意の周波数を生成できたり、波形を編集できるアプリケーションも持っている。携帯電話はもちろん、電話をするためにある。音声を生成しているではないか。私の持っているmp3プレイヤーには、マイクがついている。これらのデバイスを使って、自分が著作権を持つ音楽を生成すれば、私は著作者になるのではないか。それが音楽なのか単なる音なのかという絶対的な基準はあるのだろうか。私が作り出した音なのだから、私が著作権を持っているはずだ。JASRACが私の、ひらがなとアルファベットの発声から構成されている音楽を登録しないのは差別だ。私が著作者なんだから。そしてもし私の音楽の一部分でも再生されたなら（日本人なら50音を発声せずに会話することは不可能だ）、著作権料を徴収すべきではないか。その著作権料は、もちろん私のものになるはずだ。 　こういうわけで、全員が著作権者になれば、全員が著作権料の分配を受けられてすばらしい世界になるだろう。まてよ、自分で払って自分でもらっているわけだから、特に世話はない。中間で分配のために働いている連中をリストラできるんじゃないのか？

localeの謎

　もう何度目か分からないが、今分かっていることを書いてみる。 　C++のロケール設定だが、まあ、次のような感じだ

// C++のグローバルロケールの設定 std::locale::global( std::locale("") ) ; // Cのロケールの設定 setlocale(LC_ALL, "") ; // すでに作成されているオブジェクトのロケールを変更 std::cin.imbue ( std::locale("") ) ; std::wcin.imbue( std::locale("") ) ; std::cout.imbue( std::locale("") ) ; std::wcout.imbue( std::locale("") ) ; std::cerr.imbue( std::locale("") ) ; std::wcerr.imbue( std::locale("") ) ; // OEMコードページにはない文字の出力 std::wcout << L"ハローワールド" << std::endl ; // OEMコードページにはない文字の入力 std::wstring buf ; std::wcout << "ワイド文字を入力してください：" ; std::wcin >> buf ; std::wcout << buf << std::endl ;

　これでいいはずなのだ。実際、VC7.1では、これはうまくいく。しかし、VC8では、なぜかグローバルのロケールがCロケールでないと、日本語版Windowsにおいて、OEMコードページ以外の文字の、コンソールの入出力がうまくいかない。ファイルの入出力はうまくいく。グローバルのロケール設定をせずにimbueだけ設定しておくと、問題なく出力できる。何故だ。また、VC7.1では、単にグローバルロケールを変えておくだけで、ワイド文字の入出力ができる。不思議だ。 　また、Unicodeにしかない文字（たとえば❤など）を出力しようとしたが、コンソールでは表示されななかった。これはいいとして、ファイルにも出力されない。一体どうしたことか。wstringstreamでは、❤を出力することができた。というか、これは単にShift-jisに変換されているだけのようだ。ワイド文字のまま出力するにはどうすればいいのだろう。 　P.J. Plauger様、ワイド文字は無視ですか？ 　

ハリーポッターの物語が中二病臭くなってきた

HarryとVoldemortは、最強の剣ならぬ、最強の魔法棒を探しています。 ビードルなる詩人に語られし伝説 　昔々、あるところに、三人の兄弟がいて、夕暮れ時に、人さびしく風吹き付ける小道を旅していた。ある時、兄弟は、深くして、泳ぎ渡ることも怪しげな川岸にたどり着いた。しかし、彼等は魔法の術を心得ており、魔法棒の一振りで、怪しげな水面の上に、見事な橋をかけ上げた。さて、橋の中ほどに、外套で深く身を包みしものが、道をふさいでいた。 　死が彼等に語りかけた。死は三兄弟が、溺れ死ぬべき定めの川を渡った事に、憤慨していた。しかし狡猾な死は怒りを隠し、兄弟の魔法の術を褒め称えた。そして、各々に、己から逃れられた褒美を取らせよう、と云った。 　戦いの好きな長男は、この世で最も強い魔法棒を願った。決闘において常に所有者を勝たしめ、まさに死を克服した者にふさわしい魔法棒を。そこで死は、川岸の木の枝から魔法棒をこしらえ、長男に与えた。 　うぬぼれた次男は、死をあざけり、死人を呼び戻す力を持った石を願った。そこで死は、川岸の石を与え、人を死から呼び戻す力を持っていると言い含めた。 　死は、三男の望みを訊ねた。三男は分別を持っており、三兄弟のうち最も賢明であった。三男は死を信用していなかった。三男は死に付きまとわれずに、ここから安全に立ち去れるものを求めた。そこで死は、渋々、自分の着ていた透明なる外套を与えた。 　そして死は道を譲り、三兄弟は再び旅を続けた。彼らの為しえた冒険と、死からの贈り物を話の草に。 　その後、兄弟は互いに別れ、各々の道を歩んでいった。 　長男は一週間ばかり旅を続け、異郷の村にたどり着いた。古の魔法棒によって、彼は道中の厄介者に負けることはなかった。厄介者の死体をそのままに、彼は宿をとった。そして死より譲り受けし強い魔法棒と、無敵の己を吹聴した。 　その夜、別の魔法使が、長男が酔いつぶれて寝ている隙に、魔法棒を奪い取り、喉笛を切り裂いた。 　そして、長男は死の所有するところのものとなった。 　次男は自分の家に帰り、孤独に暮らした。そこで次男は、死を取り消さしむ力を持った石を手中に持った。興味と羨望により、かつて次男が愛した、今はなき女を、面前に呼び出した。 　悲しくも冷たくもあり、ベールにて分かたれてはいたけれど、女は死ぬべき定めの世に帰り来たが、真にこの世のものならず、あたりを漂っていた。次男はより所のなさに発狂し、自殺して、その身の置き所を女と同じくした。 　そして、次男は死の所有するところのものとなった。 　死は長の年月に渡って三男を探したが、見つけられずにいた。遂に三男は老年に達し、透明なる外套を脱いで、息子に譲った。三男は古き友たる死を迎え入れ、喜んでこの世を去った。 　なんというか、次男の部分だけ日本語で表現できない。

ハリーポッター7巻

今回はだいぶ急展開で面白い話になっている。まあ、5巻あたりが酷すぎたのだが。ところであるニュースでは、

両親と一緒に来た東京都文京区の小学５年、沖重ひかりさん（１１）は「幼稚園のころから読み始めたので、日本語はハリポタで学んだようなもの。今度は英語を勉強したい。ハリーが死なないように祈っています」と心配そうに話していた。

日本語はハリポタで学んだ……。なんと不遇な人間だろう。この子の日本語力が心配だ。治療のため、いますぐ中島敦の文章を読むべきだ。

バカのために最適化する必要はない

Rune Moberg 　こんにちは、64bit Windowsのデフォルトのデスクトップヒープサイズは20MBもあるので、かなり余裕があると思いました。 　だから僕はシステムの変数を書き換えて、１プロセスに10000ハンドルという制限を越えてみたんです。 　不可視のウインドウを20000個作るのは、すぐにできました。でも、そのハンドルを破棄するのが厄介でした。まず、自分でDestroyWindowを呼び出してみると、タスクマネージャからウインドウハンドルが、30000個から、徐々に減っていくのを数えられるほど遅いのです。秒間30個ぐらいしか解放できませんでした。単にリークさせて、OSに解放を任せてみても、やはり遅かったです。ただ、自分で解放するより早いんです。問題は、30秒ぐらい、UIが固まってしまうんです。そのコンピュータのネットワークサービスなどは、問題なく反応するのですが。問題ない数は、10000から18000ぐらいでした。僕の環境はXeonのデュアルです。教えてください。お願いします。 Raymond Chen 　いや、そりゃ単に、お前は20000個ものオブジェクトをリークすべきではないというだけさ。なんでバカのために最適化しなければならないんだ？　調子に乗るだけじゃないか。だいたい、デフォルトの制限値は10000個だ。そもそもシステムが想定しているよりも多いんだよ。だいたい、その制限を変えるには変数の値を変えないといけない。もちろん、ウインドウマネージャはちゃんとクリーンアップするよ。その挙動は、あまりいい気分ではないだろうけどね。 　悪意のあるプログラムが過負荷によるサービスアタックに利用するだって？　おいおい20000個もウインドウを作れるのならば、ウインドウをひとつ作り、そのウインドウで好きなだけユーザをたぶらかし給え。 　面白いことを云う。まあ、さすがは、USBドライバのバグをつくUSBデバイスを作成するより、フォークの方がセキュリティ上問題だと考えるだけある。

ウインドウハンドルの謎

このブログをブックマークしている奇特な人がいるらしい。最近は、ほとんどネタも書いてないというのに。まあこういうときは、例の如く、oldnewthingから話のネタを引っ張ってくるのがいいだろう。幸いにして、いま面白そうなネタを書いている。

How are window manager handles determined in 16-bit Windows and Windows 95?
How are window manager handles determined in Windows NT?
Why is the limit of window handles per process 10,000?

ただし、この話はいわゆるimplementation detailというものなので、絶対に悪用しないように。Raymond Chen様がブログを止めてしまうかもしれない。

今回は、ウインドウハンドルの値についてだ。oldnewthingを知っているようなプログラマなら誰しも、32bitなWindowsにおけるカーネルオブジェクトへのハンドルというのは、単にプロセスのハンドルテーブルのオフセットに過ぎないと言うことを知っているはずだ。しかしウインドウハンドルの値はどうか。16bit時代の頃、ウインドウハンドルの値というのは、ウインドウマネージャのセグメントへのnearポインタだったのだ。そのため、ウインドウハンドルと言うのは、16bitの値であった。

nearポインタとfarポインタ。私はこんな世界に生まれなくて幸いであった。当時は、メモリと言うのは64KBで境されるセグメントだったのだ。16bitなアドレッシングで扱えるメモリの量は64KBである。だから、64KBより大きいメモリを扱いたかったり、別のプロセスのメモリを指定したい場合は、FARポインタを使う必要があった。FARポインタは32bitで、上位16bitは、セグメントへのアドレスであった。当時はこのセグメントを複数使いこなすことが、プログラマに求められていた。必要ならば、DSを自分で書き換えることは普通であった。この頃のポインタは、本当に難しかったに違いない。

やがて時代は移り、32bitの世界がやってきた。Windows 95である。プロセスが複数のでかいヒープを持つことが当たり前になる時代。しかし、世の中はまだ16bitコードであふれかえっていた。そこで、Windowsは16bitコードをサポートする必要があった。そこで、WIN16のウインドウハンドルが問題になる。その頃、ウインドウハンドルの値は16bitである。したがって、Windoes 95でも、ウインドウハンドルの値は16bitでなくてはいけなかった。しかし、Windows 95 のポインタは32bitだ。一体どうすればいいのか。

そこで、ウインドウマネージャは、メモリを古きよきmovableとして確保する。得られるメモリは、実際のアドレスではなくHLOCALというハンドルだ。このとき、ウインドウマネージャは、32bitのヒープマネージャーに、16bitハンドルを返すように要求する。ヒープマネージャは64KBのメモリを確保し、実際のメモリポインタを格納しておき、そのメモリへのオフセットを返す。これで、16bitなウインドウハンドルが作られる。

ポインタひとつにつき4バイト必要なので、この64KBのハンドルでは、最大16384個のハンドルを扱える。CreateWindowExのドキュメントで

Windows 95/98/Me: The system can support a maximum of 16,384 window handles.

と書かれているのはこのためだ。実際には、ゼロはNULLと混同されるために使われなかったりするので、もう少し少ないそうだが。

しかし、ポインタは4バイトなのだから、あらかじめ4で割ることにしておけば、65535個のウインドウハンドルを扱えるはずである。何故しないのかと疑問を呈する人がいるかも知れぬ。しかし、Windows 3.1はたかだか700程度のウインドウしか扱えなかったことを考えると、すでに23倍も多いのである。その頃は、数百のウインドウと言うのは物凄く多いと考えられていた。メモリは現在のように十分ではなく、クールな奴等は8MB積んでいた。

しかし、この実装はある問題を引き起こした。同じウインドウハンドルの値が再利用されやすいと言うことである。すでに破棄されたウインドウハンドルを使おうとすれば、当然エラーになる。ところが、そのウインドウハンドルが、再利用されると、別のウインドウを指すようになる。つまりまったく別のウインドウに対して操作を行うようになる。これは、操作する側にとってもされる側にとっても、いい状況ではない。

そこで、Windows NTでは、対策を施した。ウインドウハンドルの上位16bitを活用するのである。Windows 95は上位16bitをゼロにしていたが、NTでは、ユニークな値を入れるようにしている。これは、ウインドウハンドルが再利用されるたびにインクリメントされる値である。こうすることによって、現実的な間、まったく同じ値のウインドウハンドルが使われないようにしている。16bitコードには、例の如く下位16bitだけを渡せば良い。

NTの時代には、だいぶメモリ容量も緩和されたが、ウインドウハンドルの数はどの程度緩和されたのだろうか。NULLなどの特殊な値を除外しても、65000個ほどはウインドウハンドルを扱えるはずである。しかし、NTのウインドウハンドルは32700程度に制限されている。なぜかというと、どうやら世の中には、ウインドウハンドルの値は偶数であると決め付けているプログラムがあるらしい。

また、１プロセスあたり10000個のウインドウハンドルしか開けないが、この制限は何のためにあるかと言うと。そんなに使うべきじゃないということらしい。すでに最大値の三分の一も使っているのだ。そんなプログラムは絶対におかしい。あまりにもウインドウが多すぎると、タスクマネージャが起動できなくなり、ユーザがそんなおかしなプロセスを強制終了できなくなってしまうかもしれない。まあ、この辺は納得できる。

さて、さっそくこの情報を試すことにしよう。ウインドウハンドルの、意味のある値は下位16bitである。しかも、偶数であるというassumptionにより（assumption、なんといういい響き！）　最下位ビットも使われていない。即ち我々は、ウインドウハンドルを0x0000fffeでANDしても問題ないはずである。早速試そう……動いた。どうやら、上位16bitがゼロのときは、ユニークな値にする対策を無視してくれるらしい。今の実装では。

ここに書いてあることを絶対に悪用しないように。

ffmpegのバグレポートなど

　ffmpegのメーリングリストにバグレポートとパッチを投げて、IRCで会話してたら、flvenc.cを書いた本人から回答が来た。

00:37 (hito) anyone test my patch? i find a bug in ffmpeg and make a patch. but i have no linux platform to test.
00:48 (mru) which patch?
00:48 (merbanan) hito: not tested, but it looks correct
00:49 (hito) http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2007-July/010103.html
00:49 (hito) it is
00:50 (hito) i just make handy program which read FLV file and find mencoder(ffmpeg) output completly broken file
00:51 (merbanan) sorry about that, it's my code :)
00:51 (hito) wow
00:51 (merbanan) well the VP6 code
00:51 (merbanan) not the complete flv muxer
00:52 (merbanan) hito: I'll push for inclusion of the fix, expect it to be committed in a few days
00:53 (hito) thanks
00:53 (merbanan) thanks for the bug report with a patch to fix it

　なるほど、やってみるものだ。

01:10 (hito) but even official Flash Player doesn't complain about Previous tag size... who use it? :)
01:12 (mru) probably nobody
01:12 (mru) what would you use it for? parse a file in reverse?
01:12 (hito) no
01:13 (hito) well yes i read it forward and hey there is Previous tag size maybe it is for reverse access
01:13 (hito) so i try it and find most of flv file broken.
01:13 (hito) allmost all flv file
01:14 (mru) then your best option is probably to simply ignore it

　そんなぁ……。

There's an awful lot of broken flv file out there

　最近、C++やWindowsに関する書籍を読み漁っていたが、全然実際のプログラミングをしていなかった。これではまずいと思い立ち、さっそく得た知識を使うべく、FLVファイルを扱うプログラムを書いた。 　しっかりと考えたC++のコードを書くのは、実に楽しい。さて、とりあえずFLVファイルのタグをひとつずつ読み込むコードを書き、テストしてみることにした。 　はたして正常に動作しなかった。 　調べてみたところ、私のコードに誤りはないという結論に達した。間違っているのは、FLVファイルのほうだ。 　まず、PHOTO蔵のFLVファイルであるが、ヘッダのビットマップには、VideoのフラグもAudioのフラグも立っていない。 　次に、YouTubeのFLVファイルであるが、二つ目のタグの、PreviousTagSize、即ちPreviousTagSize1がおかしい。恐らく、YouTubeはFLVファイルにメタデータを付加するツールを使って、自前のサービスに必要な情報を付加しているのだと思うが、このツールに問題があるらしい。メタデータを変更すると言うことは、そのタグのサイズを増減させると言うことになる。サイズに変更があった場合、その次のタグのPreviousTagSizeを適切に変更しなければならない。これが為されていない。 　また、最高にひどかったのは、ffmpegの吐くFLVファイルだ。mencoderで吐かせたFLVファイルがとんでもなく間違っていると思ったら、どうもffmpegのコードにバグがあるらしい。VP6の動画の場合、PreviousTagSizeが1バイトずれている。これは、実際にソースコードを読むと、バグが一目瞭然である。コーデックがVP6の場合、2バイトのデータを付加し、そうでない場合、1バイト付加するコードになっているのだが、PreviousTagSizeに加えられる値は、つねに1バイトである。これはひどい。 　どうやらこのことから、現行のプレイヤーはPreviousTagSizeなどまったく無視していると判断せざるを得ない。世の中には腐ったファイルが多すぎて、まったく信用ならないからだ。 http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2007-July/010098.html ffmpegのMLに投げてみたが、直してくれるだろうか。というか直してくれないと困るが。

catan quitter

　Sea3Dで遊んでいると、落ち逃げした者がいた。名前がKamemusiであった。日本人としては少々気になる名前だ。面白そうなので、さっそくこれなる名前のページを見てみることにした。 http://www.s3dconnector.net/connector/s3dPlayer.php?player=Kamemusi 　何と、同じIPのユーザに、haruhi loveとかsofmapなどがあるではないか。これは明らかに日本人だ。しかし、何と言うキモい名前。IPは動的割り当てだと思うが、同一人物である可能性は高いと思われる。 　IPを調べてみることにした。このユーザのIPは、必ず58.188.235.xxxで始まっている。このIPは、なんとeonetのものだ。やはりジャップだった。実は近所に住んでいるのではなかろうか。私もプロバイダはeonetなのだが、京都ではこのようなIPは割り当てられない。都道府県を調べてみると、どうやら大阪のようだ。 　とりあえず、大阪民国には、ハルヒラブでソフマップによく行くカメムシがいるらしい。このようなキモイ名前を付けることからして、相当のキモオタに違いない。しかもあの大阪民国に住んでいるとは救いようがない。

ffmpegのコードを読んだら、自信喪失した

　あｑｗせｄｒｆｔｇｙふじこｌｐ；　うわあああああああ　あんなに悩んでいたFLVのDataタグの完全なパースが、恐ろしく簡単に実装されている！＠＃＄％＾＆＊？　何週間も綺麗な実装方法について悩んでいたのに……。 　もう、この業界あきらめようかな。自分には向いていないし、一生かかっても極められない。何でも世の中には天才という奴がいて、我々凡夫はその後追いをしているだけだ。結局、ただ学んだ知識を使うだけで、何一つとして生み出すことが出来ない。 　

FLVのonMetaDataがカオスすぎる

　規格を読んだが、どうも細部がよく分からない。正しい例のひとつもつければいいのに。 　まず、Data tagであるが、トップレベルのSCRIPTDATAOBJECTはひとつだけなのか、あるいは複数あって、SCRIPTDATAOBJECTENDで終端されているものなのか。ほとんどのFLVはひとつだけのようだ。 　Lists of SCRIPTDATAOBJECT records are terminated by using the SCRIPTDATAOBJECTEND tag. 　とあるが、そもそもそんなFLVファイルは見当たらない。巷に転がっているFLVファイルは、みなSCRIPTDATAOBJECTがひとつだけだ。SCRIPTDATAOBJECTENDを使っているFLVファイルも見当たらない。どのFLVファイルも、最初の名前がonMetaDataで、ECMA array typeが格納されている。問題なのはここからだ。これはサイズを指定した配列なので、終端はいらないはずだ。事実、終端はObject typeかStrict array typeのときしか規定されていない。だからいらないはずなのだが、ffmpegは最後にSCRIPTDATAVARIABLEENDを吐く。不思議に思っていたが、どうもOn2のFlix EngineもSCRIPTDATAVARIABLEENDを出力している。一体何が正しいのか。規格を読む限り、必要なさそうに思えるのだが。 　しかもさらに問題をややこしくしているのがYouTubeだ。YouTubeのFLVファイルには、それらの終端があるのだろうか。本当にわからない。 　結論、こんな奇妙極まりない構造を考え付いたマクロメディアは糞に違いない。 　

シリアルポートを扱うのは簡単だ

　FPGAとVHDLの実習で、シリアルポートを使う練習で、ある値を送り続ける課題があった。果たしてさっぱりうまくいかなかった。ハイパーターミナルでは分かりづらいので、自前でCOMポートをモニタするツールを書くことにした。かねてより簡単にCOMポートに読み書きできるのは知っていたが、本当にあっさりと書くことができて拍子抜けした。それにしても、ボーレートやフロー制御の設定にまぎれて、１バイトが何ビットであるかを設定する項目があるのには、時代を感じた。 　 　とりあえず、概略を書いておく。まず、CreateFileで開く。ファイル名は。"COMx"だ。xの部分に、開きたいCOMポートの数字を入れればいい。そして必要に応じてREADやWRITEのアクセス権を指定する。また、MSDNによれば、排他的アクセスで無ければならないとされている。セキュリティは無し。OPEN_EXISTINGで開く。オーバーラップもサポートされている。テンプレートは設定できない。

HANDLE com = CreateFile( L"COM1", GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);

　現在の設定は、GetCommStateで設定できる。DCB構造体を適切に設定して、SetCommStateで変更できる。あとは、おなじみのReadFileやWriteFileで読み書きすればいい。 　時代と言えば、昔はシリアルだから遅い、パラレルにしたほうが早いと言われていたものだ。 　シリアルって早くね？　480Mボーぐらいでるんじゃね？

iPhoneのrootアカウントのパスワードがクラックされた

2009年11月5日追記：二年前のこの記事が、にわかにPV数を得ている。何故かというと、こういう事があったからだ。間違えてここに飛んできた人の為の便宜を図るために、リンクしておく。
ロック解除のiPhoneを人質に、「身代金」の要求騒ぎ - ITmedia News

http://www.hackint0sh.org/forum/showthread.php?t=1323

rootアカウントのパスワードは、"alpine"
mobileアカウントのパスワードは、"dottie"

パスワードのセンスを褒め称えるべきだろうか？　ちなみに、パスワードは古き良きDESでハッシュされているらしい。今となっては懐かしい暗号だ。クラックには、John the Ripperで15秒だったとか。

まあ、iPhoneは携帯である。マルチユーザなどといった使い方は想定していないし、そもそもiPhoneのシェル上から、rootにログインする方法がない。iPhoneにはターミナルなどないし、セキュリティ上の問題になることも無い。rootアカウントへのログインはまだ試みられていないようだが、そもそもUIが動くのかどうか疑問のようだ。

FLV ファイル

　FLVファイルを処理するツールを作ろうとしたが、なかなか難しい。Dataタグには、完全なパーサを書かなければならない。いい加減に対応すると、泣きを見るだろう。 　しかし、OnMetaDataの公式な規格書がないのはどういうことだろう。

久しぶりにアニメ

ニコニコでこの動画を見たついでに、うたわれるものを４話まで観たら、なかなか面白かった。

mencoder doesn't support vp7 well

mencoderでVP7のエンコードをしてみようと思ったのだが、どうもうまくいかない。

まず、vfw2mencでエンコードの設定を保存しようとしたのだが、保存したファイルを、mencoderで読み込ませようとすると失敗する。設定ダイアログを開くことはできるので、手動でエンコードしようとしたが、これもうまくいかない。エンコードはできるのだが、再生できない。不思議に思って出力されたAVIファイルを調べてみると、どうもFourCCの値がおかしい。VP70であるべきなのに、変な値になっている。そもそも、可読域ではない値だ。バイナリエディタでVP70に修正してみると、あっさりと再生できた。

問題は、ffourccオプションが働かないとはどういうことだろう。何のためのfourcc強制オプションだ。

肝心のVP7の画質だが、かなりのっぺりとした結果になる。ウェーブレットでもかけたような感じだ。恐らくアニメなどをエンコードするにはいいと思われる。FLVの動画コーデックの指定には4ビットが使われており、現在6種類のコーデックをサポートしている。つまり、まだ10個分空きがあるのだ。もし、FLVでサポートして欲しいとしたら、何を望むだろう。H264、VP7などだろうか。

　なお、今回思わぬ発見をした。mplayerでVP6を再生するとやけにブロックノイズが目立つが、これはffmpegのVP6の独自実装のデコーダのためである。vp6vfw.dllでデコードするためには、-vc vp6 と指定してやれば良い。

平生の主張

　タバコという合法ドラッグをやる人間は今すぐ死滅せよ。

危険なセキュリティソフトウェア

　http://blogs.technet.com/markrussinovich/archive/2007/06/19/1256677.aspx 　たとえば、あるコンピュータにインストールされているWindowsに、二つのアカウントが設定されているとする。お互いに、相手から読み書きができないようなパーミッションを付けたファイルを持っている。ところで、一方のアカウントは、かなり頻繁に、あるソフトウェアを実行していると分かっている。もし、もう一方のアカウントから、そのソフトウェア(.exeファイル）を差し替えられれば、自分にとって秘密のファイルの読み書きができてしまう。 　まあ、Windowsというのは、たいていの場合、ユーザが管理者であり、それほど問題にはならない。いくらVistaでマルチユーザーを歌おうとも、個人的には、これはそれほど問題にはならないかと思う。問題なのは、このようにセキュリティがずさんなことだ。 　というのも、何もこれはファイルに限った話ではないからだ。他のカーネルオブジェクトが危険なのだ。たとえばミューテックスオブジェクトだ。あるセキュリティソフトウェアが、名前付きミューテックスオブジェクトを使ってスレッド、あるいはプロセス間の同期を取っていたとする。このセキュリティソフトウェアを無効にしたい、悪意あるプログラムは、単にそのミューテックスを開いて、自分で所有してしまえばいい。セキュリティソフトウェアは、いつまでたっても解放されないミューテックスオブジェクトを永遠に待ち続けることになるだろう。たったそれだけのことで、セキュリティソフトウェアを無効にできてしまうかもしれない。 　また、セキュリティソフトウェアはその性質上、Local Systemで動作することもある。あるセキュリティソフトウェアは、Local Systemで動作させているプロセスと、他のプロセス（恐らくはユーザへのUIなどか）と共有メモリを使って通信している。何と皮肉なことに、この共有メモリのセキュリティが設定されていないのだ。つまりどのプロセスからでも、この共有メモリにアクセスすることができるのだ。マルウェアは、この共有メモリをいじってやれば、Local Systemで動作しているプロセスに何らかのメッセージを送ることができる。ひょっとしたら、自分の望み通りの動作をさせることができるかもしれない。これをセキュリティホールと言わずして何という。皮肉にも、セキュリティソフトウェアと名乗るプログラムに、これが非常に多いらしい。もちろん、他のプログラムも、それほど違いはなく、かなりいい加減なのだが。 　Mark氏は、これは9x時代には、シングルユーザであることが当たり前だったから、このようになっているのだと推測している。時代は変わったから、そろそろプログラマも頭を切り替えなければいけないようだ。

How do i encode ローゼンメイデン風アンパンマン

　恐らくは、いくらかの需要があるだろうと思い、ローゼンメイデン風アンパンマンを、高画質にエンコードする方法について書いてみる。 　まず、この元ソースは、Flashだ。とりあえずソースを入手する。http://www.omosiro-flash.com/flash/anpanman.html 　さて、これを何とかして、動画にしなければならない。Swf2Aviを使い、動画にする。FPSは12だ。さて、動画を得られたら、次は音声である。幸いにして、このFlashは単一のBGMを流しているだけなので、単にFlashを分解して、音声ファイルを取り出せばよろしい。ADPCMなので、mp3にエンコードする必要がある。 　さて、動画のエンコードだ。動画を吟味すると、これは一見簡単そうに見える。なにしろ、ベタ塗りであるし、輪郭もはっきりしている。ところが、普通にエンコードすると、なぜか物凄く画質が悪くなってしまう。ビットレートが、指定したよりも大幅に下がってしまうのだ。これは、動画が12FPSだからだ。動画圧縮というのは、物凄く大雑把に言ってしまえば、キーフレームとその差分であるインターフレームで構成されるので、FPSが低いと、逆に不利になる。とくにVP6の場合、顕著である。従って、フレームレートを上げなければならない。ここは単純に、フレームを重複させるだけでいい。 　つまり、mencoderでは、 -vf (いろんなフィルタ),harddup -fps 12 -ofps 24 　としてやればいい。このharddupというフィルタは、単純かつ非常に役に立つ。フレームを重複させなければならないとき、nullフレームを挿入するのではなく、単純に前のフレームをそのまま使う。こうすれば、十分なFPSを確保でき、きれいにエンコードできる。

Human's ear is stupid

　人間の耳というのは、本当にいい加減なものだ。この動画は、超高音質と銘打っているものの、実際のところ、それほど音質がいいわけではない。それどころか、恐ろしく劣化している。にもかかわらず、多くの人が、音質がいいと錯覚している。 　さて、このFLVファイルを落とし、調べてみると、まず音声部分は、128kbpsのmp3であった。注意深く聞いてみると、低音と高温がやけに強調された音であることが分かる。いわゆるドンシャリだ。 　まあ思うに、ドンシャリの方が、音質がよくなったと感じる人間が多いのだから、ドンシャリの方が好いのではないかと思う。あくまで、人間がよい音だと認識することが重要なのだから。 　CreativeのX-Fiシリーズは、Crystalizerという名称の、いわばプリセット済みイコライザーがある。これは低音と高音を強調し、注音を抑えるという、まさにドンシャリフィルタだ。使ってみると、確かにいくつかの音に関しては、良くなったと錯覚してしまう。こういう機能があるのも、ひとえに人間の耳がいい加減なものだからだろう。

how do i get rid of disgusting interlace

追記：自動改行に頼っていた古い記事を整形。内容は結構古いので、今はどうなっているか分からない。

ソー、ディスタイム、ウィーアーゴーイングトゥトークアバウトデインターレース。

さて、インターレス解除の方法であるが、その前にひとつ、どうしても言わなければならないことがある。

曰く、「完璧を求めるならば、アナログなディスプレイで見ればいい」

本当に、これに尽きる。完璧なデインターレス方法などない。最良の方法とは、最初からインターレスなソースを用いないことだ。とは言え、入手可能な最良のソースがインターレスを含んでいることは往々にしてあることだ。なんとかして、インターレスは除かねばならない。

さて、mencoderに詳しくない者は、ひょっとしたら、mencoder以外でインターレスを解除しているかも知れぬ。ところが、mencoderには、最強のインターレス解除方法も備わっているのだ。早速見ていこう。

インターレスを解除するには、vf 引数、つまりビデオフィルタを使う。最も単純なのは、ppから始まる一連のフィルタだ。たとえば、pp=lbはLinear Blendであるし、pp=liはLinear Interpolationだ。基本的にこれらを使う。個人的には、PP系の中では、Cublic Interpolationがお勧めだ。これらは組み合わせて使うことも出来る。たとえば、pp=ci,pp=l5は、キューブリックインターポレーションの後に、ローパスフィルタをかけている。

PP以外のデインターレスフィルタはどうかというと、こちらはより賢い方法を採用している。たとえば、動画が実際より3/2フレーム数の多い、テレシネであった場合、逆テレシネを利用して、実に効果的にインターレスの解除が行える、pullupやfilmdintなどだ。もちろん、このフィルタを利用するには、テレシネ動画で無ければならないのだが。

さて、テレシネ動画でない場合、どうすればいいのか。ここで、かなり汎用的に使えて、性能のいいフィルタがある。yadif(Yet Another DeInterlace Filterの略)というフィルタだ。この性能はすばらしい。たいていの場合で、困ることはない。使い方だが、１フレーム毎に処理したいならば、yadif=0を使う。１フィールド毎に処理したいならば、yadif=1を使う。2や3は、spatial interlacingを行わない、0や1のことだ。yadif=1を使う場合は、framestep等を使い、フレームを脱落させるか、あるいは出力するFPSを倍にしないと、泣きを見ることになる。フレームがフィールド単位に分離されているからだ。単純に2倍になる。

さて、更なる高みを目指したい人は続きを読んで欲しい。最強のフィルタがある。その名はmcdeintだ。これは、動き補正をしつつインターレスを解除を行うという、恐ろしいフィルタだ。何が恐ろしいといって、物凄く遅い。現状のどんなCPUを使っても、エンコードのFPSは一桁を切るだろう。0.1、0.01の世界にまで落ち込む。

使い方は次の通り、

yadif=3,mcdeint=2,framestep=2

mcdeintは、それ自体でフィールド分離機能を持っていないので、フィールドを分離する、tfields=1や、yadif=1, yadif=3などを一緒に使わなければならない。そして、FPSが倍になっているので、単純にフレームを脱落させ、元のFPSに戻すか、FPSを倍にしなければならない。なお、mcdeint=3ならば、さらに遅くなる。これは劇的に遅いが、最強だ。

ふと思った

　よく、「私らが子供の時分には、皆、外で遊んでいたのに、近頃ときたら、皆で集まってもゲームばかり。まったく、最近の若い者はダメだ」などと言われる。 　まあ、そうは言っても、その時分にはゲームなどないし、今は遊べるような所も少ない。もちろんこういうことは、四千年前のエジプトのパピルスにも書いてあるそうだ。因みに、このエジプトのパピルスについて調べたが、どうも一次ソースが見当たらない。わが国では、柳田国男が、「Archibald Henry Sayceがそんなことを言っていた」と、著書「木綿以前の事」に書いている。そして、このArchibald Henry Sayceは、いくつかの本を書いている。この中に、恐らくはあるだろうと思われる。しかし、こんなマイナーな本は、国内では国会図書館か、有名な大学の図書室にでも行かなければ見つからないだろう。 　さて、そこでふと思った。もし我々が親の世代になったとき、一体なんと言われているのだろう。既にゲームはある。外で遊べる場所は今より増えることはないだろう。さて何と言う。 　思うに、ネット対戦ではないかと思う。最近、ようやくインターネットも普通になってきた。帯域は、現在でもゲームには十分すぎるぐらいだし、遅延も、恐らく将来は、日本国内は最高でも10ms程度の遅延でpingが通るだろう。Google Mapで日本列島の全長を測ると、だいたい1500kmぐらいであった。沖縄を無視すればだが。1500kmを光の速さで進むと、5msかかる。適当に言ったが、結構ありえそうだ。 　そんなわけで、どの家にも電話回線を付けているように、どこでもネットに接続可能になると、ネットゲームが物凄く身近な存在になる。 　そういう近い将来、我々は次のように言うだろう。 「私らが子供の時分には、皆、集まって誰かの家でゲームをしていたのに、近頃ときたら、皆ネットゲームばかり。まったく、最近の若い者はダメだ」と。 　ところで、書名を失念したが、ある物書きの文章読本では、物書きの間では、「ペンで書くのと、キーボードで打つのでは、文章が違う。ペンで書こうとすると、じっくりと考えてから書くので、必然的に良い文章が出来上がる。従って、物書きを生業とする以上、まずペンで書くべきだ」と主張する人が居ると書いてあった。その著者はこれを皮肉って、「まったく馬鹿げた話だ。ひょっとしたら将来、『音声認識による入力と、キーボードからの入力では、出来上がる文章はどちらが優れているか』という論争でも繰り広げられるのだろうか。ペンとキーボードの争いよりは、多少ましな気はするが」と締めくくっていた。

高部真規子裁判長のおかげで、日本国内においてネットワークストレージが違法と相成りました

http://headlines.yahoo.co.jp/hl?a=20070525-00000119-mai-soci

これはどんなサービスかというと、ユーザが、自分の持っているCDを、MYUTAの提供するサーバにアップロードでき、そのユーザの携帯電話に落とすことができるというものだ。記事やプレスリリースを見る限り、ユーザ個人だけで完結するサービスのようで、他のユーザの音楽を落とせるサービスではないようだ。

東京地裁の「高部真規子」裁判長がだした判決のようだ。こんなもので訴えるJASRACもJASRACだが、判決を出す高部真規子も高部真規子だ。もはやこれはJASRACがどうとかいう問題を通り越してあきれてしまう。なんという裁判長。

これはすばらしい。日本国内では、ネットストレージサービスが違法になってしまった。この解釈で行くと、Webサーバ、POP3サーバなどのレンタルは違法になってしまうだろう。

なんという判決だろう。これはまずい。

　しかし、ぐぐってみたところ、この高部真規子という人間、恐ろしくトンデモ判決を多数出しているようだ。 　あの有名な、松下がヘルプの機能で一太郎を訴えた裁判も、この高部真規子が出したらしい。 　裁判官ってどうやって罷免させられるのだろう。

FLV file structure

　最近、ニコニコ動画にハマっているのだが、FLVファイルの構造について知りたくなったので、調べていた。いくつか参考になりそうな情報が見つかった。 まず、ファイルの構造については、大まかにhttp://www.osflash.org/flvで情報がある。 　直接のコードで読めて、参考になりそうなソースは、まずFLV Extractだ。これは、C#のコードだ。C#にはなじみがないのだが、かなりC++に似ている、というよりも、そのままだ。FLV Extractについては、単純なGUIとファイルアクセスなので、これをC++に移植することは、優しいことだろう。詳細な構造についてのソースコードが見たければ、ffmpegのコードを参考になりそうだ。 　で、何がしたいかというと、どこの馬の骨かもわからないあのツールでマージするのではなく、自前でFLVのマージツールを作ってみようかと。

how to change console's font?

　old new thingは実に役に立つ。たまたまコンソールについて悩んでいたら、ちょうどいいタイミングで、コンソールのフォントについて解説してくれた。 http://blogs.msdn.com/oldnewthing/archive/2007/05/16/2659903.aspx 　なるほど、フォントの仕組みについてはよく知らなかったのだが、はみ出す文字というのがあるのか。 　それにしても、ABCなんて名前の構造体を定義しているPSDKもどうかとおもう。もちろん、そんな名前が実際に使われることは、まずないだろうとしても。 　一応、スーパーギークのために、フォントを変える方法はある。http://support.microsoft.com/kb/247815 HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Console\TrueTypeFont 下に、00という名前の文字列を付け加えて、値をフォントフェイスにすればよい。複数のフォントを付け加えたい場合は、000, 0000,などというように、レジストリエントリの名前に、0を付け加えていく。

一度生を受け、滅せぬ物のあるべきか

思へば、此世は常の住処にあらず。草葉に置く白露、水に宿る月より猶あやし。金谷に花を詠じ、栄花は先立て、無常の風に誘はるゝ。南楼の月をもてあそぶ輩も、月に先立つて、有為の雲に隠れり。人間五十年、化天の内を比ぶれば、夢幻のごとくなり。一度生を受け、滅せぬ物のあるべきか。これを菩提の種と思ひ定めざらんは、口惜しかりき次第ぞ

有名なところを超口語訳

つーか、人間ってせいぜい50年しか生きられねーよ。最下層の天使でさえも、八百年ぐらいはいきるっつーのによぅ。生まれたらそりゃ当然死ぬんだよ。これが定めか。なんつーこった

幸若舞『敦盛』（全文）
http://www.ikedakai.com/atsumori.html

動画サイトの未来

ひろゆき氏、「ニコニコ」ヒットでも「動画は“来て”ない」

http://www.itmedia.co.jp/news/articles/0705/11/news117.html

まあ、PV数だけは無駄に稼いでいるが、大赤字だろう。トラフィックが膨大だからといって、広告料も上げてくれるわけではない。それもあるのだが、日本の動画の特徴が気になるところだ。ほとんどがアニメである。確かに、アニメといえば日本なのだが、それは所詮、作られたコンテンツである。自分で動画を作ってあげようという人が、あまりにも少ない。たとえば、YouTubeで最も人気の高い動画は何かというと。

つまり、個人が作った動画というのがほとんどない。たとえば有名なUnreal Gamer（キーボードクラッシャー）の動画は、狙って作られたものである。この少年が、別の動画でなにやら話しているものも、アップロードされている。こちらは普通に話しているだけなので、あまり人気はないが。

これは、誰でも作れるのだ。しかし、日本人はこういう動画を作ろうとしない。既存のアニメをいかに画質良くエンコードしてニコニコに上げるかにはこだわっても、自前でいかに面白い動画を作るかについては、まったく考慮しない。まあ、かく偉そうなことをいうからには、自分で作って見なければならない。そんなわけで一連の動画をここにリンクしておく。

http://www.nicovideo.jp/search/hito

how do i use mencoder for two pass encoding

　さて、2パスエンコードを説明する。これまでのmencoderにはバグがあり、VP62の2パスエンコードがうまくいかなかった。.sstファイルが正常に出力されないのが原因である。これが、2chの有志により、直されたので、2パスエンコードができるようになった。ちなみに、CBRだと、バグがあってもできてしまったりする。公式にパッチは上げてくれるのだろうか。 　それにしても、やはり、2パスはすばらしい。動き始めのブロックノイズが激減する。いままで2パスを敬遠してきたのは、mencoderだけで完結する方法がなかったからだ。

echo オーディオのビットレートを指定(kbps) 例:64 set Audiobitrate=64 REM ビデオフォーマット設定(出力拡張子で自動的に確定) set FORMAT=-of lavf set FOPT=-lavfopts i_certify_that_my_video_stream_does_not_use_b_frames REM 一応入力側の名前に合わせてみる set OUTPUT=-o "%~n1.flv" set INPUT="%~1" REM ビデオコーデック設定 set VCODEC=-ovc vfw REM 音声コーデック設定 set ACODEC=-oac mp3lame set ACOPT=-lameopts abr:br=%Audiobitrate% -af resample=44100 REM その他フィルタオプション(現状は上下反転＋LanczosResize512x384)-ffourcc VP6F set EXTOPT=-vf flip,scale=512:384 -sws 9 REM 2pass用 set VCOPT=-xvfwopts codec=codecs\vp6vfw.dll:compdata=firstpass.mcf mencoder %FORMAT% %FOPT% %VCODEC% %VCOPT% %ACODEC% %ACOPT% %EXTOPT% %OUTPUT% %INPUT% set VCOPT=-xvfwopts codec=codecs\vp6vfw.dll:compdata=secondpass.mcf mencoder %FORMAT% %FOPT% %VCODEC% %VCOPT% %ACODEC% %ACOPT% %EXTOPT% %OUTPUT% %INPUT% あとは各自試行錯誤でもしてくれってことで。

　これが、2パスに必要なバッチファイルである。例の如く、自分好みに変えてある。さて、とりあえず試したい場合は、コーデックの指定を、vp6vfw.dll:compdata=dialogにすれば良い。設定ダイアログが表示されるので、それぞれ、Two Pass - First Pass, Two Pass - Second Passを選べば良い。しかし、それでは人間が応答しなければならない。私の理想は、無人のまま自働エンコードである。そこで、コーデックの設定を、保存しておく必要がある。これには、.mcfというファイルを生成する必要がある。このバッチファイルに添う形では、firstpass.mcfと、secondpass.mcfである。.mcfファイルはどうやって生成するか。それには、vfw2menc.exeを使う。次のように呼び出せば良い。

vfw2menc -f VP62 -d codecs\vp6vfw.dll -s firstpass.mcf vfw2menc -f VP62 -d codecs\vp6vfw.dll -s secondpass.mcf

それぞれ、１パス目、2パス目を設定する。このようにしておけば、人間が応答することなく2パスエンコードができる。

what niconico wiki's mencoder batch file doing?

前回、mplayerとmencoderについての概要を説明した。今回は、ニコニコ動画のまとめWikiにある、mencoderのバッチファイルが何をしているかを説明してみる。なお、今回は、mencoderのドキュメントを参照しつつ、読んで欲しい。 http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html

echo オーディオのビットレートを指定(kbps) 例:64 set /p ABITRATE=AudioBitrate: set Audiobitrate=%ABITRATE% REM ビデオフォーマット設定(出力拡張子で自動的に確定) set FORMAT=-of lavf set FOPT=-lavfopts i_certify_that_my_video_stream_does_not_use_b_frames REM 一応入力側の名前に合わせてみる set OUTPUT=-o "%~n1.flv" set INPUT="%~1" REM ビデオコーデック設定 set VCODEC=-ovc vfw set VCOPT=-xvfwopts codec=codecs\vp6vfw.dll:compdata=dialog REM 音声コーデック設定 set ACODEC=-oac mp3lame set ACOPT=-lameopts abr:br=%Audiobitrate% -afresample=44100 REM その他フィルタオプション(現状は上下反転＋LanczosResize512x384)-ffourcc VP6F set EXTOPT=-vf flip,scale=512:384 -sws 9 mencoder %FORMAT% %FOPT% %VCODEC% %VCOPT% %ACODEC% %ACOPT%%EXTOPT% %OUTPUT% %INPUT% あとは各自試行錯誤でもしてくれってことで。

これが、FLV4enc_D&D.batの中身である。１パスの、重要な部分だけを抜き出してある。基本的に、最後のmencoderが重要なのだ。このバッチファイルは、FLVにエンコードして、ニコニコにうｐするための、最小限のことだけをしている。これを理解して、自分で変更できるようになれば、さらに画質や音質を上げられるだろう。

まず最初のFORMAT変数には、-ofオプションを使い、どのフォーマットで出力するかが指定されている。明示的にflvを指定してもいいのだが、このバッチファイルではそれはしていない。次に、-lavfoptsオプションを使い、出力する動画が、Bフレームを使用していないことを明示している。現在、mencoderではBフレームの出力がサポートされていないからである。 VCODEC変数で、コーデックを指定している、これは、vfw(Video For Windows)を使う。つまり、vp6vfw.dllのことだ。次に続く-xvfwoptsオプションで、読み込むDLLファイルを指定している。また、コーデックの設定ダイアログを開くようにしている。コーデックの設定を自動化する方法があるのだが、それは2パスエンコードのときに説明するつもりだ。

余談だが、mencoderで、とうとう2パスエンコードができるようになったのだ。パッチがいつ、公式のMLに投げられるのか、不明ではあるが、diffは確保したので、いざとなればなんとでもなるだろう。私もUNIX環境のプログラミングを勉強すべきだろうか。

次は音声である。このバッチファイルは、いかなる動画ソースからでも、ニコニコに受け付けられるFLVを作成することを目的としているので、音声はエンコードされる。もし、自前でエンコードした音声がある場合、それを単にコピーすれば、再エンコードされずに、音質がよくなるだろう。FLVコンテナでは、無圧縮PCM、ADPCM、mp3をサポートしている。また、マイクで録音する際に、Nellymoser codecを使用しているようだが、このコーデックの仕様はよく分からない。現在のところ、オープンソースのデコーダーも見当たらない。 mp3へのエンコードは、-oacオプションで、mencoderに組み込まれているmp3lameを利用している。また、FLVコンテナは、 44.1kHz 22.05kHz 11.025kHzのいずれかのサンプリングレートでなければならないようなので、トラブルを防ぐために、-afオプションで、44.1kHzにリサンプルしている。ただし、このリサンプルは、次のEXTOPTで設定されている。ここが個人的に好きではないので、私の自前のバッチファイルでは、変更しているが。

さて、いよいよEXTOPT変数だ。ここにはまず、-vfオプションが指定されている。これは、ビデオフィルタという意味で、文字通りフィルタだ。 まず、flip、これは、VP6のデコーダであるVP6Fが上下反転した出力をするので、workaroundとして入れてある。最初から上下反転したフレームにしておけば、さらに上下反転して、意図通りにデコードされるという寸法だ。しかし、なぜこんなあまのじゃくな仕様なのだろう その次に、動画を512x384にスケーリングする。この解像度でなければ、SIMLEは再エンコードをしてしまうからだ。次に、-swsオプションで、スケーリングのアルゴリズムを設定してる。現在のところ11種類のアルゴリズムが実装されている。9というのは、lanczosアルゴリズムである。非常に品質のいいアルゴリズムとして有名だ。ほとんどの場合はこれでいいのだが、たとえばドット絵、ファミコンやスーパーファミコンなどの動画をエンコードするときは、4のnearest neighborがお勧めかもしれない。もちろん、エンコードする過程でかなり劣化するし、元ソースの画質にも影響されるので、どちらがいいかは、好みの問題ではある。また、先に説明したように、ここで音声リサンプルのための-afオプションが指定されている。 そのあとは、出力と入力のファイルを指定しているだけだ。

PS. やはり、バッチファイルを修正した。-afオプションと、%INPUT%にダブルクオーテーションがついているのを修正した。ダブルクオーテーションは、INPUT変数自体に含めるべき。