日記みたいな何か

調べてみたら原因はやっぱcpufreqにあるっぽいっす．CPUのクロックを落とした状態でサスペンドすると帰ってこない現象が発生してしまいます．そんなわけで，apmd_porxyのサスペンド直前の部分に，CPUのクロックを最大値に戻すような記述を書き加えてひとまず対処完了．

yazさんのxmms-scrobblerパッチを見て再び思ったのですが，世の中(日本だけじゃなくて中国や台湾，韓国なんかも含めて)のMP3のID3タグの文字コードってどうなってんでしょ．インスタントメッセンジャーの文字コードとかと違って，個々のユーザがそれぞれ好き勝ってにできることなんで，みんなどうしているのか全くわからんですが，とりあえず思い付くこと(というか単なる思い込み)を列挙してみますと・・・

• 日本語に限れば，SJIS(というかCP932？)とUnicode系以外でタグつけてるのって，UNIX系OSのユーザだけかも(昔のキモSoundJam/iTunesのタグを除く)
• UNIX系のユーザで非SJIS・非Unicode派はEUC-JPでつけているに違いない(ID3v1なんてただでさえ使えるバイト数少ないのに，わざわざISO-2022-JPとかで付けてる人はいるんだろうか？)
• xmmsはデフォルトだとLANG依存(なのでSJIS出すには多分LANG=ja_JP.SJISとかして起動するしかないが，これだとEUC-JPなファイル名が化けたりすると思う)
• Sianさんのパッチ当てたxmmsは，変換決め打ち(しかも選べるコード限定)
• BMPは内部でUTF-8処理するので変換元を優先度付けて複数選べる
• AmaroKはどうしてるか知らないや
• 日本語を自動認識させた場合，たとえば「琥珀」みたいなタグがついてたらどうなるんだろう
• 中国語や韓国語はどうなっているんだろう(日本語のタグみたいにややこしい状況だったりするのか？)
• 同じファイルをWindowsでも再生したり，ポータブルオーディオプレイヤーに転送するような人は，EUC-JPとかでタグつけたりしないんでは？

てなことを考えたりした結果，結局よくわからなくなり，マイxmms-scrobblerパッチは自動認識付けずにBMPの真似して優先度つき決め打ちにしちゃったんすよね．正直，EUC-JPなタグつけちゃったファイルはさっさとスクリプト書いてまとめてSJISかUnicodeあたりに付け直すのが一番平和なんじゃないのかなーなんて思ったり．すべて思い込みベースなんで，本当はどうなのか知りませんけど・・・．

もっとも，自分の場合，音屋さん配布のMP3ファイルとかは全部一旦デコードして音量正規化してからOggにしちゃうんで，文字コードで悩むことないんですが，UTF-8でタグつけてると今度はBMPで文字幅計算がおかしいとかそういう問題が・・・．