Debian5.0でkeymapを英語から日本語へ

Mac OSXが微妙だったので、結局5日でDebianに変更。
2月15日に5になったばかりのようなので、それの確認も兼ねて…

ということで、PPC版をインストールしたのだが、インストール時に何故か日本語106キーボードが選択できなかったので、設定しなおすことに。
…が、kbd-configコマンドを管理者で実行し、日本語106キーボードを選択しても、全然反映されず。

ここで30分ほど悩んだが、/etc/X11/xorg.confに何か設定があったことを思い出した。

以下の項目を、

Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc104"
        Option          "XkbLayout"     "us"
EndSection

このように書き換え、再ログインすれば良い模様。

Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "jp106"
        Option          "XkbLayout"     "jp"
EndSection

ウインドウマネージャーにxfceを選択したら、非力なMac Miniでも、結構ぬるぬる動作してくれて(ﾟДﾟ)ｳﾏｰ

Mac Mini (PPC)を分解してみた

昨日大学に行ったら、何故か教授からMac Mini（(PPC版)を借りれることになった。
大学卒業まで使用可&分解可(サポートは既に切れているので)ということで、これは(*´ω｀*)ﾀﾉｼｿｽ

初期Mac Miniということで、構成は、
・ CPU - PowerPC G4 1.42GHz
・ Memory - DDR 256MB × 1
・ Graphic - Radeon 9200 32MB
・ HDD Ultra-ATA 80GB
・ OS - Mac OSX 10.3
…と、大体こんな感じ。

…絶対メモリ足りないよな…これ。
Vista販売当初の「DDR2 512MB・メーカー製PC」を思い出す構成だな…

試しに起動してtopを見たところ、空きメモリが2~10MB位しか無く、HDDにスワップしまくりという、
とっても(´・ω・)ｶﾜｲｿｽなことになっていた。

という訳で
早速分解してみようか(｀・ω・´)ｼｬｷｰﾝ

分解前はこんな感じ。
元に戻らなかったらどうしようか…(；´∀｀)…とか考えつつ…



分解。

テレカ等のカード２枚と、平らなフライ返しのようなもの(固い金属製で、テレカの幅より小さいものならおｋ)を使用した。

本体をひっくり返し、端の部分の隙間にテレカと図書カード(どちらも使用済み)を差し込み、
そのカードの間に金属製の薄いなにかを突っ込み、ツメを外すらしい。
テレカなどを挟まないと、なにか嫌な音がして、どこかが削れているような感じがしたので、テレカなどは必須のようだった。


メモリを外してみた。
最近いろんな意味で話題のHynix製・DDR 256MBメモリだった。
…韓国製は嫌いなのだよ(´・ω・｀)


そして、以前のNECマシンで使用していたDDR 1GBのメモリと交換し、動作テスト。
問題無く認識した。


最後にケースを元に戻す。
元に戻すとき、背面のところが上手くはまらず、2回ほど、こじ開けなおす羽目に…



端末とシステム情報だけを実行した状態。

この状態で、topコマンドで表示される、使用メモリ量は250MBを超えている。
…これじゃあ、DDR 256MBでは使い物にならないわなぁ…(;´д｀)


Mac OSXを使ってみた感想として、
・アプリケーションの互換性の問題が多すぎ
・Safari3.2等のサポートが無くて涙目
・GIMP等の最新版バイナリ配布が「10.4.9以降」なんて条件ばかりで涙目
・デフォルトでGCC等が無く、インストールがめんどい
・ところどころ、WindowsやLinuxと違うところが多くて…(´Д⊂ ﾓｳﾀﾞﾒﾎﾟ
・白い
…これくらいだろうか(´・ω・｀)


消費電力が結構少なく、かなり静音なので、
そのうちDebianでもインストールして、常時稼働用サーバにするかねぇ…

はちゅねは たみふるを みつけた!!

どうする?

>たべる
・のむ
・しらべる
・わたす
・なげる
・すてる


はちゅねは たみふるを たべた!
…が いつもと かわらなかった!!



…と、いうことで(?)、インフルエンザで5日間程死にかけていました…(;´д｀)…
39度オーバーが3日続くと、頭がかなりヤバいことに…

今回キツかったのは熱・頭痛・腹痛で、逆に咳とかの風邪っぽい症状は全然出なかった。
3日目あたり、胃炎発症しかけて布団でのたうち回っていたときは、死ぬかと思った…('A`)

とりあえず無事治ったようなのでよしと…まだ頭がふらふらするが。

寒いと思ったらこれだよ!!

２日前まで、もうこのまま春になるのかな～ ( ´ー｀)．．．
という感じだったのだが、昨日から異常に寒くなり、久々に地吹雪に。
夜にはだいぶ静かになったので、もう降らないのかと思っていたのだが…

今朝起きたら…

寒いから…ね…(´・ω・`)…



……( ；´д｀)

またもや更新 マルチスレッド対応 lameフロントエンド (もどき) v1.7a

09.07.26 追記
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/


ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ

---

春休み期間中なせいか、3~4日おきに更新している気がするが、気にしない。

今回は、出力先ディレクトリの選択と、mp3の上書き出力の廃止&連番リネーム出力化をメインに更新してみた。

以下テンプレ。
一応毎回少しづつ変わっているのだが…

特徴

• lameのエンコード処理を並列して行うことができ、Corei7・Phenomなどのマルチコア・マルチスレッドCPUや、デュアルプロセッサ環境も有効に使える。
  
• ディレクトリごとに一気にエンコードが可能。
  
• 一度設定するだけで2回目以降の設定は不要。
  
• wav→mp3変換とmp3→mp3変換に対応。
  
• Rubyがインストールしてあれば、Windows、Unix、Linux、MacOSXなどの、どんなOSでも使用することができる。
  
• Windowsの場合は、Rubyが無くても動く。
  
• Cygwinなどは必要ない。
  
• プロセスを多重起動しているだけなので、音質に影響するということがない。
  
• 大量のファイルを登録しても、登録エラーなどが発生しない(ﾊｽﾞ)
  
• エンコードのログを残せる。
  
• エンコードにかかった時間を計測できるようにしたので、ファイルやlameバイナリを統一すれば、mp3エンコードのベンチマークとして使える…かもしれない。
  

今回の変更・更新

• ファイルを上書きせずに、リネームするようにして、安全性が向上。
  
• マルチスレッド処理の更なる安定化。
  
• 内部処理の効率化。
  
• ファイルのコピーや削除に失敗し続けた場合、ループし続ける問題を修正。
  
• 1.7preでエクスポート先を指定した場合に、Shift-JISのダメ文字を含むファイルをエンコードすると、エクスポート先にエンコードされず元のディレクトリに出力される問題を修正。
  

解決していない問題

• mp3ファイルの再エンコードが終わってからでないとwavファイルのエンコードが開始できない。
  
• ディレクトリごとにしかエンコードできない(ファイルを個別にエンコードすることはできない)
  
• CUIである。
  
• 設定ファイルや一時ファイルなどの出力先の問題。
  (OSごとに環境変数が違うので厄介)
  
• aiff形式に対応していない。
  

必ず必要なもの

• lameバイナリ
  
• Rubyバイナリ（Windows以外の場合）
  
• このプログラム本体
  

プログラムのダウンロードはこちらから。  

旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/


初代v1.0aと比べると、安定性や操作性が格段に違うな…('A`) そろそろb(beta)にするか…ねぇ。 今回のバージョンから、mp3の上書きをしないようにして、重複した場合ファイル名に連番を付加するようにしたのだが、その過程で、 …な感じに、一見暴走したように見えるくらいに文字を吐き出しながら確認を求めるようになったのだが、この文字列は表示しない方が良いのだろうか…?

そして、スクリーンショットを撮って、初めて朝の７時になっているということに気付いた…(´・ω・｀)
もう完全に昼夜逆転してるな…ｧ '`,､'`,､('∀`) '`,､'`,､

Windows ７と仮想HDDイメージ（VHD） Part2

前回、Windows 7やWindows Server 2008 R2で、仮想HDDからOSを立ち上げることができるのか、という実験をする前に　寝てしまったので、今日は続きを。

とりあえず、Windows 7をVirtualPCを使用し仮想HDDにインストール。

この起動ロゴも大分見慣れてきたな…('A`)


管理者でコマンドプロンプトを実行。
(無論自己責任で。最悪、OSが起動できなくなります。)

まず、
bcdedit /create /d "Windows 7 VHD" /application osloader
とコマンドを打ち、新しいエントリを作成する。
すると、
エントリ {--数列--} は正常に作成されました。
と返ってくるので、"--数列--"の部分を覚えておく。

次に、
bcdedit /displayorder {--数列--} /addlast
と打つ。
「ブートローダーで表示されるOS一覧の、一番下に先ほど登録したエントリを表示する」 …ということらしい。

そして、最後に{--数列--}のvalueを設定する。
bcdedit /set {--数列--} path \Windows\system32\winload.exe #ブートローダーのパス
bcdedit /set {--数列--} locale ja-JP #システムのロケーション
bcdedit /set {--数列--} systemroot \Windows #システムディレクトリの場所
bcdedit /set {--数列--} nx OptIn #データ実行防止(DEP)のオプション
ここまでは、普段ブートローダーの設定をするときとだいたい同じでよい模様。

今回VHDから起動するために修正が必要な項目は、
bcdedit /set {--数列--} device vhd=[c:]\vhd\vista.vhd
bcdedit /set {--数列--} osdevice vhd=[c:]\vhd\vista.vhd
たぶんこの二つ。
ドライブレターとディレクトリパスを指定するだけで良いらしい。

bcdeditについて、詳しくは、http://www.microsoft.com/japan/whdc/system/platform/firmware/bcd.mspx
を読めば、だいたい分か………る訳ないだろ(#ﾟДﾟ)ｺﾞﾙｧ!!
…細かすぎてさっぱり分からない…(´；ω；｀)ﾌﾞﾜｯ

…まぁ今回はbcdeditがメインではないので…。


そしてwktkしながら再起動。





(ノ∀`)ノ∀`)ノ∀`)ｼﾞｪﾄｽﾄﾘｰﾑｱﾁｬｰ
ブートロゴは出たものの、途中でブルースクリーン。
VirtualPCでインストールしたのをVMwareで起動したので、ドライバ周りの問題は、まぁ予想はできた。


では、VirtualPCにインストールしたWindows7からではどうなるのか。


実験した結果。



もうだめぽ。


今回出来上がったのは、

・動かなくなった仮想Windows 7
・ブートローダがぶっ壊れた仮想Windows Server 2008 R2

以上。


(´；ω；｀)ﾌﾞﾜｯ



原因としてありそうなのは、
・ブートローダーの設定ミス
・ドライバの問題
・可変サイズのVHDファイル
・VHDファイルのバージョン
…だろうか。

今回使用したVHDファイルは、全てVirtualPC2007 SP1で作成したもの。
…Windows 7で作成したVHDファイルを使用するべきだった…か?

一応以下のように/createでntldrを設定すれば、
bcdedit /create　｛ntldr} /d "Windows XP VHD"
XPなども起動できるはず…だと思うが、うまくいかなかった。


※09.03.09 追記
仮想ドライブ2つでスパン・ストライプ・ミラーボリュームを作成できないのか、と思い、実験してみたが、
ウィザードを開始、設定終了後に
「この操作は、オブジェクトによってサポートされていません。」
と出て、実行することができなかった。

ちなみに、BitLockerは普通に使用できた。

プロパティで表示されるデバイス名が、「Msft Virtual Disk SCSI Disk Device」って…
「Msftって何?」って30秒程悩んで閉まった…('A`)

マルチスレッド対応lameフロントエンド （もどき） また更新 v1.6a

09.07.26 追記
m4a(aac)とoggにも対応させてみた。

Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/


ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ

---

前のバージョンの出来に納得いかなかったので、lameマルチスレッド対応フロントエンド（もどき) v1.5aを更に更新。

今回は、「安定性・操作性の向上」を目標に、改良してみた。

特徴

• lameのエンコード処理を並列して行うことができ、Corei7などのマルチコア・マルチスレッドCPUや、デュアルプロセッサ環境も有効に使える。
  
• ディレクトリごとに一気にエンコードが可能。
  
• 一度設定するだけで2回目以降の設定は不要。
  
• wav→mp3変換とmp3→mp3変換に対応。
  
• Rubyがインストールしてあれば、Windows、Unix、Linux、MacOSXなどの、どんなOSでも使用することができる。
  
• Windowsの場合は、Rubyが無くても動く。
  
• Cygwinなどは必要ない。
  
• プロセスを多重起動しているだけなので、音質に影響するということがない。
  
• 大量のファイルを登録しても、登録エラーなどが発生しない(ﾊｽﾞ)
  
• エンコードのログを残せる。
  
• エンコードにかかった時間を計測できるようにしたので、ファイルやlameバイナリを統一すれば、mp3エンコードのベンチマークとして使える…かもしれない。
  

今回の変更・更新

• ディレクトリ選択まわりを更に修正。ディレクトリ名をいちいち入力する必要が無くなった。
  
• 失敗したエンコードのログだけをとったファイルfaillog.logを出力するようにした。
  
• マルチスレッド処理の安定化。
  
• アクセス権の無いディレクトリを参照した場合に、プログラム全体が終了する問題を修正。
  
• コピーや削除などの処理に失敗した場合に、プログラム全体が終了する可能性をできるだけ回避。
  

解決していない問題

• mp3ファイルの再エンコードが終わってからでないとwavファイルのエンコードが開始できない。
  (同時進行すると、同じ名前のファイルが作られてエラーになる可能性があるため)
  
• ディレクトリごとにしかエンコードできない(ファイルを個別にエンコードすることはできない)
  
• CUIである。
  
• *_re.mp3となっているmp3ファイルの再エンコード問題。
  
• 設定ファイルや一時ファイルなどの出力先の問題。
  (OSごとに環境変数が違うので厄介)
  

必ず必要なもの

• lameバイナリ
  
• Rubyバイナリ（Windows以外の場合）
  
• このプログラム本体
  

プログラムのダウンロードはこちらから。

旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/


コマンドプロンプトが狭くて使いづらい、という場合は、コマンドプロンプトのタイトル部分を右クリック→画面バッファーのサイズで変更できる。


以前のバージョンに比べると、格段に安定してきた。
今回のバージョンからは、例外が発生したら出来る限りRescueするようにしたので、安定度がぐーんとうp。

…というか、以前のバージョンが不安定すぎなんだよな…(´・ω・｀)ｼｮﾎﾞｰﾝ
どこで問題が発生するのか、テストするのも大変で…
果たしてバージョンからa(alpha)が取れる日は来るのか…('A`)

クアッドコアCPUを超える、6コア12スレッドCPUをIntelが出す、というのは、
一体いつなんだろうか?
このプログラム、増やす気があれば12どころか256ぐらいまで増やすことも可能なんだよな…
その場合、wavファイルが256個無いと意味ないけど'`,､('∀`) '`,､

そして、別にlameとmp3だけにこだわる必要も…。
wmaやaac、oggなんてのにも、挑戦してみたいが…(´・ω・｀)