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 件のコメント:
コメントを投稿