2009年2月26日木曜日

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でも、結構ぬるぬる動作してくれて(゚Д゚)ウマー

2009年2月24日火曜日

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にスワップしまくりという、
とっても(´・ω・)カワイソスなことになっていた。

という訳で
早速分解してみようか(`・ω・´)シャキーン

分解前はこんな感じ。
元に戻らなかったらどうしようか…(;´∀`)…とか考えつつ…
分解前Mac Miniとはちゅねさん


分解。
分解後Mac Miniとはちゅねさん
テレカ等のカード2枚と、平らなフライ返しのようなもの(固い金属製で、テレカの幅より小さいものならおk)を使用した。

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


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

そして、以前の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`)

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

2009年2月17日火曜日

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

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

今朝起きたら…
ゆきとはちゅねさん
寒いから…ね…(´・ω・`)…


ねぎおとした
……( ;´д`)

2009年2月15日日曜日

またもや更新 マルチスレッド対応 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形式に対応していない。

必ず必要なもの

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

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


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

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

2009年2月14日土曜日

Windows 7と仮想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`)

2009年2月12日木曜日

マルチスレッド対応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ごとに環境変数が違うので厄介)

必ず必要なもの



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

旧バージョンの管理が大変なので、全て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なんてのにも、挑戦してみたいが…(´・ω・`)

2009年2月10日火曜日

Windows 7と仮想HDDイメージ(VHD) Part1

Windows 7をインストールする際、別HDDにインストールしたため、
ブートローダーを再設定することになった。

そのときに、bcdedit.exeのヘルプ(bcdedit /? set)を見ていたら、

次のコマンドは、指定されたオペレーティング システムのエントリについて、
OS デバイスを VHD ファイル (C:\vdisks\vdisk01.vhd) に設定します:

bcdedit /set {cbd971bf-b7b8-4885-951a-fa03044f5d71} osdevice
vhd=[C:]\vdisks\disk01.vhd

という説明が。

もしやこれは、ブートローダーに仮想マシン用HDDイメージを読み込ませて、
そのイメージからOSを起動(VHDブート)できる…という事…?

そもそも仮想HDDイメージを物理マシンにマウント出来るようになった…の?


というわけで、早速実験。
用意したものは、
  • Windows 7 Beta1がインストールされている物理マシン(はつねサーバ)
  • Windows 7 Beta1がインストールされている仮想マシン
  • Microsoftが配布していたWindows Vista EnterpriseがインストールされたVHDファイル

まず、一体どこから仮想HDDイメージをマウントするのか、という問題に直面。
何気なく探すこと1分。

コントロールパネル→管理ツール→コンピュータの管理→ディスクの管理
を開き、
操作タブの「VHDの接続」で接続できることが判明。


接続するとこんな感じになる。
デバイスの種類が「UNKNOWN」となっているが、ベータ版なので気にしない。


もしくは、コマンドプロンプトでdiskpart.exeを開き、
select vdisk file=C:\vhd\vista.vhd
attach vdisk
で、マウントできる。

初めてマウントする際、自動でMicrosoft VHD HBAドライバがインストールされる模様。


マウントすると、普通にexplorerから見れるようになる。

画像は、仮想ディスクの中身を開いた状態。
…どこが違うか全然分からない…('A`)

新規仮想ディスクを作成することも可能。


…仮想HDD関連のところはまだ一部翻訳されてないのね…
簡単な英語だから分かるけど…

今日は激しく眠いのでこの辺で…
bcdedit.exeでブートローダーにVHDファイル登録するのはまた今度…('A`)


Windows 7と仮想HDDイメージ(VHD) Part2
http://projectzero-swb.blogspot.com/2009/02/windows-hddvhd-part2.html

2009年2月8日日曜日

lameマルチスレッド対応フロントエンド(もどき) v1.5a

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


ここより下の情報は古いです…(´・ω・`)スマソ



試験も終わって遂に春休みキタ-*・゜゚・*:.。..。.:*・゜(゚∀゚)゚・*:.。. .。.:*・゜゚・*!!!!

…ということで、LAMEをマルチスレッドで実行するフロントエンド(もどき) v1.4を更に更新してみた。

特徴

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

今回の更新内容

  • ファイル名にShift-JISのダメ文字が含まれている場合発生する問題を解決。
  • ログの書式を修正。
  • 一応ダブルクリック起動に対応。
  • なんとなくmtlamef_sjis.exeにWindows用アイコンを付けてみた。
  • threadの実行がエラーで止まるかもしれない問題を(たぶん)修正。
  • *_re.mp3となっているファイルがある場合、mp3の再エンコードに失敗する可能性があることを通知するようにした。

解決していない問題

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

必ず必要なもの

プログラム本体はこちらから。

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


  試しに8スレッド立ててエンコードしてみた。 久々に、高負荷で他に何も操作できないという状態を体験した…(´・ω・`)
試しに以前のバージョン(v1.3など)で、2秒のファイル50個を8スレッド並列処理させたところ、 かなりの頻度でアクセス権エラーが… 不具合多すぎだな…あれ…。 申し訳ない…(´;ω;`)ウッ…


実行ファイルのアイコンを変更したら… …私には削除できない…(´;ω;`)ブワッ

2009年2月4日水曜日

RubyスクリプトをWindows用実行ファイル(exe)化する

Rubyでプログラム作成し、配布する上で、
Rubyインタプリタがインストールされていない場合は、
Rubyをインストールしてもらうしかないのか…と悩んでいたところ、
exerbなるものを発見。

exerb
http://sourceforge.jp/projects/exerb/

Rubyスクリプトをexe化でき、単体起動させることができるらしい。
これは(・∀・)イイ!!

管理者権限でsetup.rbを実行することでインストールできる模様。


と、いうことで。
早速、LAMEをマルチスレッドで実行するフロントエンド(もどき)v1.4を実行ファイル化してみた。

これで、いちいちOne-Click Ruby Installerをインストールする必要が無くなって(゚д゚)ウマー

※09.02.05追記
…と思ったら、requireでの読み込みがうまくいかず、スレッドを開始できないという問題が発生する模様…(´;ω;`)ブワッ

という訳で、RubyScript2Exeを使用し、作りなおした。
これは、exerbと同じようにRubyスクリプトを実行ファイル化できる上に、require関連のものも自動で追加してくれる…らしい。

…今度は大丈夫なハズ。


動作確認せずに寝たのが不味かった…('A`)

※09.07.30 追記
exerbとOne-Click Ruby Installer 1.8.6-27 RC2との相性が悪く、失敗していたという事が判明。
mswin32版 1.8.7-p72に変更したら問題無く動作した。

2009年2月1日日曜日

LAMEをマルチスレッドで実行するフロントエンド(もどき) 大幅に更新 v1.4a

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


ここより下の情報は古いです…(´・ω・`)スマソ



lameマルチスレッドエンコードフロントエンド(もどき)を、大幅に修正してみた。

特に大きいのは、
ディレクトリ選択操作の効率が80%うp!(当社比)
したこと。
(あくまで感想であり、実際に効果があるかは(ry )

言ってしまえば、
「今までのバージョンDLして使っちゃっている人、もしいたら、ごめんね…」
なぐらいの変化が。

変更点や特徴などは以下の通り。

特徴

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

1.3からの変更点

  • ディレクトリ選択まわりを大幅に修正。
  • ディレクトリ名を打ち込む必要を減らした。
  • .Wav、.WAVなどの拡張子のファイルも扱えるようにした。

解決していない問題

  • LameのShift-Jisダメ文字問題が回避できていない。
  • mp3ファイルの再エンコードが終了しないとwavファイルのエンコードを開始できない。
  • mp3の再エンコードのみを行うことができない。
  • CUIである。
  • ディレクトリごとにしかエンコードできない(ファイルを個別にエンコードすることはできない)
今回は、簡単な操作の説明をしてみようと思う。 1. 設定ファイルの作成 lameエンコード時に付けるオプションや、このフロントエンド(もどき)の処理に関する設定をファイルに書き出す。 詳細はreadme.txtあたりで。 2. 再実行し、一覧を表示するディレクトリ(カレントディレクトリ)を選択する 画像は、"/l"でディレクトリの中のファイルのリストを表示してみたところ。 3. 選択したカレントディレクトリの中にあるディレクトリのリストの表示 設定ファイル作成時に「一度に表示するディレクトリリスト一覧の数」で入力した数の分ずつ、リストが表示される。 ディレクトリ名に対応するNumの値を入力することで、flagが立ち、 flagが立っている状態で"q"で終了すると、そのディレクトリがエンコードリストに登録される。 nで次のページ、bで前のページを見ることができる。 "l 7"で、この画像の場合はディレクトリ「歌に形はないけれど - doriko」の中を表示することができる。 4. "l 7"を入力した結果 ディレクトリ「歌に形はないけれど - doriko」の中身が表示される。 5. 選択したいディレクトリに対応する番号を入力し、flagを立てる ここでは、Debutante3、歌に形はないけれど、少女の空中庭園のディレクトリを選択してみた。 6. 選択し、"q"を入力すると、選択されたディレクトリ一覧が表示される 2のカレントディレクトリの選択まで戻るので、別のところから追加する場合は"/c"やら/..でカレントディレクトリを移動し、3~6の手順を繰り返せばおk。 多重登録などは発生しないようにしておいた。 エンコードしたいディレクトリの選択が終わったら、 カレントディレクトリ選択メニューのところで"/q"でエンコード処理に進める。 7. 後はエンコードが終わるのを待つだけ ファイルの上書きをしなければならないときは、一応問い合わせるようにしてある。

必ず必要なもの

Windowsでは、One-Click Ruby Installerを使用するのが良いかと思う。
One-Click Ruby Installer for Windowsは以下で入手できる。
http://rubyforge.org/frs/?group_id=167

プログラム本体は、今回もSkyDriveからダウンロードできるようにしておいた。  

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

  ダウンロードしたら、右上の投票でもしてくれると、誰かがダウンロードしてくれたのかな~とすぐ分かって嬉しい。

ソースがかなり長くなってきて、処理も複雑になってきたので、デバッグし切れないところが… もしエラーや問題などが発生したら、報告してもらえると助かるんだ…(´・ω・`)
相変わらず、gdgdで非効率なソースですまない…(´;ω;`)ブワッ
私、期末テスト期間中なんだけどなぁ… …まぁいいか。