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の公式な規格書がないのはどういうことだろう。