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時になっているということに気付いた…(´・ω・`)
もう完全に昼夜逆転してるな…ァ '`,、'`,、('∀`) '`,、'`,、

0 件のコメント: