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なんてのにも、挑戦してみたいが…(´・ω・`)

0 件のコメント: