前回v2.3aをリリースをしてから1ヶ月半…
べっ、別に更新をサボっていた訳じゃないんだからね(´・ω・｀)
…
なんだかんだで、半年前に急いで作ったプログラムをひたすら拡張していただけなので、構造上の問題が山ほど見つかり、
1から作り直した方が早くね?
という事に。
今回は、
ちょっと弄れば他のオーディオ形式用のエンコーダーにも使えるように…
mp3のタグをファイル名やディレクトリ名を基準に付けたり…
なんて事が、いつかできるようにするために、拡張しやすく作っている…ハズ。
あとは、余計な処理を行っていた部分を削ぎ落としたり、設定を分かりやすいものに変えたり。
現在、エンコード処理の部分なので、デバッグがそれなりに終わりリリースできるまでは、あと1~2週間程掛かりそうな予感…
大学のレポートが…(´；ω；｀)ｳｯ…
最近Blogも週一位しか更新できてないな…
09.07.26 追記
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド(もどき))をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
http://mtmef.g.hachune.net/
2009年6月21日日曜日
2009年5月10日日曜日
マルチスレッド対応 lameフロントエンド (もどき) v2.3a
09.07.26 追記
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
GWが終わったら、バグ取りと機能改善したものをリリースするよ(´・ω・｀)、…と言って修正を開始し、とりあえず問題無く動くレベルになったので、リリースしてみた。
今回は、エンコードファイルのフィルタリング機能(ファイル名・ファイルサイズ・アクセス時間・更新時間で判別)と、スレッド数の上限の撤廃をメインに、いろいろ修正した。
以下テンプレ。
どういう処理をするのか、などの解説はこちら。
特徴
- lameのエンコード処理を並列して行うことができ(環境が許す限り無限に)、Corei7・PhenomⅡなどのマルチコア・マルチスレッドCPUや、デュアルプロセッサ環境も有効に使える。
- ディレクトリごとに一気にエンコードが可能。
- wav→mp3変換とmp3→mp3変換に対応。
- Ruby 1.8がインストールしてあれば、Windows、Unix、Linux、MacOSXなどの、どんなOSでも使用することができる(たぶん)
- Windowsの場合は、Rubyが無くても動く。
- Cygwinなどは必要ない。
- プロセスを多重起動しているだけなので、音質に影響するということがない。
- 大量のファイルを登録しても、登録エラーなどが発生しない(ﾊｽﾞ)
- エンコードのログを残せる。
- エンコードにかかった時間を計測できるようにしたので、ファイルやlameバイナリを統一すれば、mp3エンコードのベンチマークとして使える…かもしれない。
今回の変更・更新
- thread_mtlamef.rbを最適化。全行数が340行から40行に。
- スレッド数を無限に(エンコードするファイルの数だけ)増やせるようにした。
- 特定の文字列を含んだファイルやディレクトリを参照すると、強制終了する問題を一つ修正。
→未発見のものが他にも沢山ありそうな気が... - エンコードファイルフィルタリングを出来るようにした(ファイル名、ファイルサイズ、最終アクセス日時、最終更新日時)
- ディレクトリを変更する(cdする)時に、範囲外のディレクトリを選択すると必ず落ちる問題を解決。
- ディレクトリ選択時に、"/"でルートディレクトリに移動できない問題を修正。
解決していない問題
- mp3ファイルの再エンコードが終わってからでないとwavファイルのエンコードが開始できない。
- ディレクトリごとにしかエンコードできない(ファイルを個別にエンコードすることはできない)
- CUIである。
- aiffなどの形式に対応していない。
- サブディレクトリの数が多いと、マシンスペックによってはディレクトリ一覧表示処理が遅くなる(ディレクトリ数を確認するため)
- Windows用実行ファイルの起動に、5~10秒ほどかかってしまう。
- バグが取りきれていない可能性が…(´；ω；｀)ｳｯ…
必ず必要なもの
プログラム本体のダウンロードはこちらから。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
スレッド数の制限が無くなった、ということで、同時に64スレッド実行してみた。
見事にタスクマネージャーがlameだらけに。
エンコテストなので、同じ曲を複数回リネームしてエンコードしているが、気にしないで欲しいんだ…('A`)
2009年5月4日月曜日
マルチスレッド対応 lameフロントエンド (もどき)のバグの多さについて
しっかりバグ取りしろ(#ﾟДﾟ)ｺﾞﾙｧ!!
と自分に言い聞かせながらやっていますが、どうにも…(´・ω・`)
GWほぼ全部使うつもりでバグ取りやっていますが、次から次へと出るわ出るわ…
特に初期に作っていた部分の、取り忘れたバグが結構あったり。
ディレクトリ選択部分で、範囲外の番号を指定すると落ちるとか、未だに残っていたのがなんとも…(´;ω;`)ｳｯ…
GW終わるころには何とかある程度仕上げたいと思っています。
…誰かデバッグ手伝って(ぁ
と自分に言い聞かせながらやっていますが、どうにも…(´・ω・`)
GWほぼ全部使うつもりでバグ取りやっていますが、次から次へと出るわ出るわ…
特に初期に作っていた部分の、取り忘れたバグが結構あったり。
ディレクトリ選択部分で、範囲外の番号を指定すると落ちるとか、未だに残っていたのがなんとも…(´;ω;`)ｳｯ…
GW終わるころには何とかある程度仕上げたいと思っています。
…誰かデバッグ手伝って(ぁ
2009年4月26日日曜日
マルチスレッド対応 lameフロントエンド (もどき) v2.2a
※追記 09.07.26
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
シスアドの試験も終わり、久々のゆっくりできる土日を迎えたので、1か月近く更新の止まっていたマルチスレッド対応 lameフロントエンド (もどき)を更新してみた。
今回は、自分で役立つと思って付けたハズの、「再エンコードし、出力されたmp3ファイルの名前には"_re"を付ける」という機能が、場合によっては激しく邪魔だということに気付き、それを使いやすいようにしたのをメインに、いろいろ修正してみた。
以下テンプレ。
どういう処理をするのか、などの解説はこちら。
プログラム本体のダウンロードはこちらから。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
…使った感じは微妙にしか変わっていないように思えるが、中は結構変わって…('A`)
何度修正しても、更に修正したい場所が次々に見つかって、これはいつになったら終わるのか、全く分からない…(´；ω；｀)ｳｯ…
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
シスアドの試験も終わり、久々のゆっくりできる土日を迎えたので、1か月近く更新の止まっていたマルチスレッド対応 lameフロントエンド (もどき)を更新してみた。
今回は、自分で役立つと思って付けたハズの、「再エンコードし、出力されたmp3ファイルの名前には"_re"を付ける」という機能が、場合によっては激しく邪魔だということに気付き、それを使いやすいようにしたのをメインに、いろいろ修正してみた。
以下テンプレ。
どういう処理をするのか、などの解説はこちら。
特徴
- lameのエンコード処理を並列して行うことができ(最大16スレッド)、Corei7・PhenomⅡなどのマルチコア・マルチスレッドCPUや、デュアルプロセッサ環境も有効に使える。
- ディレクトリごとに一気にエンコードが可能。
- wav→mp3変換とmp3→mp3変換に対応。
- Ruby 1.8がインストールしてあれば、Windows、Unix、Linux、MacOSXなどの、どんなOSでも使用することができる(たぶん)
- Windowsの場合は、Rubyが無くても動く。
- Cygwinなどは必要ない。
- プロセスを多重起動しているだけなので、音質に影響するということがない。
- 大量のファイルを登録しても、登録エラーなどが発生しない(ﾊｽﾞ)
- エンコードのログを残せる。
- エンコードにかかった時間を計測できるようにしたので、ファイルやlameバイナリを統一すれば、mp3エンコードのベンチマークとして使える…かもしれない。
今回の変更・更新
- mp3再エンコード時に、出力mp3ファイル名に付加する文字列を設定できるようにした。
- 一時ファイル出力用ディレクトリを設定できるようにした。
解決していない問題
- mp3ファイルの再エンコードが終わってからでないとwavファイルのエンコードが開始できない。
- ディレクトリごとにしかエンコードできない(ファイルを個別にエンコードすることはできない)
- CUIである。
- aiff形式に対応していない。
- サブディレクトリの数が多いと、マシンスペックによってはディレクトリ一覧表示処理が遅くなる(ディレクトリ数を確認するため)
- バグが取りきれていない可能性が…(´；ω；｀)ｳｯ…
必ず必要なもの
プログラム本体のダウンロードはこちらから。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
…使った感じは微妙にしか変わっていないように思えるが、中は結構変わって…('A`)
何度修正しても、更に修正したい場所が次々に見つかって、これはいつになったら終わるのか、全く分からない…(´；ω；｀)ｳｯ…
2009年4月2日木曜日
マルチスレッド対応 lameフロントエンド (もどき) v2.1a
※追記 09.07.26
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
春休みも昨日で終わり、
ブログがはちゅねだらけなのはちょっとマズいか…?
…ということで、マルチスレッド対応 lameフロントエンド (もどき) v2.0aを更新した。
今回は、ディレクトリ操作の更なる効率化(また)とRubyの正規表現を利用した絞り込み検索機能をメインに、修正してみた。
以下テンプレ。
どういう処理をするのか、などの解説はこちら。
プログラムのダウンロードは以下から。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
自分でいろいろ作っていると、
限られた端末の画面の中で出来る限り分かりやすくすることが、
いかに難しいかが分かるな…('A`)
久々にHTML書いたら、CSSを大分忘れていて涙目。
ゆっくり書いてたら大学に間に合わなくなりそうになった…(´；ω；｀)ﾌﾞﾜｯ
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
春休みも昨日で終わり、
ブログがはちゅねだらけなのはちょっとマズいか…?
…ということで、マルチスレッド対応 lameフロントエンド (もどき) v2.0aを更新した。
今回は、ディレクトリ操作の更なる効率化(また)とRubyの正規表現を利用した絞り込み検索機能をメインに、修正してみた。
以下テンプレ。
どういう処理をするのか、などの解説はこちら。
特徴
- lameのエンコード処理を並列して行うことができ、Corei7・PhenomⅡなどのマルチコア・マルチスレッドCPUや、デュアルプロセッサ環境も有効に使える。
- ディレクトリごとに一気にエンコードが可能。
- 一度設定するだけで2回目以降の設定は不要。
- wav→mp3変換とmp3→mp3変換に対応。
- Rubyがインストールしてあれば、Windows、Unix、Linux、MacOSXなどの、どんなOSでも使用することができる(たぶん)
- Windowsの場合は、Rubyが無くても動く。
- Cygwinなどは必要ない。
- プロセスを多重起動しているだけなので、音質に影響するということがない。
- 大量のファイルを登録しても、登録エラーなどが発生しない(ﾊｽﾞ)
- エンコードのログを残せる。
- エンコードにかかった時間を計測できるようにしたので、ファイルやlameバイナリを統一すれば、mp3エンコードのベンチマークとして使える…かもしれない。
今回の変更・更新
- サブディレクトリの数を表示するようにした。
- Rubyの正規表現を利用した絞り込み検索機能を追加。
- 設定の値がおかしい場合、再設定をその場でできるようにした。
- 設定作成時のLameバージョン読み込みに失敗する問題を修正。
- HTMLのReadmeを作成。
解決していない問題
- mp3ファイルの再エンコードが終わってからでないとwavファイルのエンコードが開始できない。
- ディレクトリごとにしかエンコードできない(ファイルを個別にエンコードすることはできない)
- CUIである。
- 一時ファイルなどの出力先の問題。
(OSごとに環境変数が違うので厄介) - aiff形式に対応していない。
- サブディレクトリの数が多いと、マシンスペックによってはディレクトリ一覧表示処理が遅くなる(ディレクトリ数を確認するため)
- バグが取りきれていない可能性が…(´；ω；｀)ｳｯ…
必ず必要なもの
プログラムのダウンロードは以下から。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
自分でいろいろ作っていると、
限られた端末の画面の中で出来る限り分かりやすくすることが、
いかに難しいかが分かるな…('A`)
久々にHTML書いたら、CSSを大分忘れていて涙目。
ゆっくり書いてたら大学に間に合わなくなりそうになった…(´；ω；｀)ﾌﾞﾜｯ
2009年3月14日土曜日
マルチスレッド対応 lameフロントエンド (もどき) v2.0a
※追記 09.07.26
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
マルチスレッド対応 lameフロントエンド (もどき) v1.8aに大幅な改良を加え、v1.9aをすっ飛ばしv2.0aにしてみた。
今回は、ディレクトリ選択操作の効率化と、扱えるスレッド数の増量…といったことをメインの目標として、作りなおしてみた。
今回の改変で、同時実行可能スレッド数が一気に16スレッドに。
これで、6コア12スレッドのCPUでも100%使うことができる。
…これで当分は拡張しなくても大丈夫…だよな…
UltraSPARCのデュアルプロセッサ、とかは…(´・ω・`)知らんがな
どういう処理をするのか、などの解説はこちら。
プログラムのダウンロードは以下から。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
バグあったら報告してもらえると、非常に助かります…(´・ω・｀)必ずバグがあると思うので…
せっかく16スレッドに対応したので、試しにやってみた。
Phenomx4ﾀﾝ(´・ω・)ｶﾜｲｿｽ…
そしてタスクマネージャーが凄いことに…
ようやく普通のコンソールアプリ位に使えるレベルになってきた…かもしれない…'`,､('∀`) '`,､
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
マルチスレッド対応 lameフロントエンド (もどき) v1.8aに大幅な改良を加え、v1.9aをすっ飛ばしv2.0aにしてみた。
今回は、ディレクトリ選択操作の効率化と、扱えるスレッド数の増量…といったことをメインの目標として、作りなおしてみた。
今回の改変で、同時実行可能スレッド数が一気に16スレッドに。
これで、6コア12スレッドのCPUでも100%使うことができる。
…これで当分は拡張しなくても大丈夫…だよな…
UltraSPARCのデュアルプロセッサ、とかは…(´・ω・`)知らんがな
どういう処理をするのか、などの解説はこちら。
特徴
- lameのエンコード処理を並列して行うことができ、Corei7・Phenomなどのマルチコア・マルチスレッドCPUや、デュアルプロセッサ環境も有効に使える。
- ディレクトリごとに一気にエンコードが可能。
- 一度設定するだけで2回目以降の設定は不要。
- wav→mp3変換とmp3→mp3変換に対応。
- Rubyがインストールしてあれば、Windows、Unix、Linux、MacOSXなどの、どんなOSでも使用することができる。
- Windowsの場合は、Rubyが無くても動く。
- Cygwinなどは必要ない。
- プロセスを多重起動しているだけなので、音質に影響するということがない。
- 大量のファイルを登録しても、登録エラーなどが発生しない(ﾊｽﾞ)
- エンコードのログを残せる。
- エンコードにかかった時間を計測できるようにしたので、ファイルやlameバイナリを統一すれば、mp3エンコードのベンチマークとして使える…かもしれない。
今回の変更・更新
- 最大16スレッドまで対応。
- ディレクトリ選択操作を大幅改良。
- 端末の大きさを自動取得し、それに合わせて表示するようにした。
- 設定の個別変更を可能にした。
- ログファイルを$HOME/.mtlamef/に出力するようにした。
(Windowsの場合は%HOMEDRIVE%%HOMEPATH%/.mtlamef/) - だいぶ長くなってきたので、関数をライブラリとしてまとめた。
解決していない問題
- mp3ファイルの再エンコードが終わってからでないとwavファイルのエンコードが開始できない。
- ディレクトリごとにしかエンコードできない(ファイルを個別にエンコードすることはできない)
- CUIである。
- 一時ファイルなどの出力先の問題。
(OSごとに環境変数が違うので厄介) - aiff形式に対応していない。
- バグが取りきれていない可能性が…(´；ω；｀)ｳｯ…
必ず必要なもの
プログラムのダウンロードは以下から。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
バグあったら報告してもらえると、非常に助かります…(´・ω・｀)必ずバグがあると思うので…
せっかく16スレッドに対応したので、試しにやってみた。
Phenomx4ﾀﾝ(´・ω・)ｶﾜｲｿｽ…
そしてタスクマネージャーが凄いことに…
ようやく普通のコンソールアプリ位に使えるレベルになってきた…かもしれない…'`,､('∀`) '`,､
2009年3月4日水曜日
マルチスレッド対応 lameフロントエンド (もどき)の解説を書いてみた
マルチスレッド対応 lameフロントエンド (もどき)を作って公開したはいいものの、使うメリットなどが分かりずらいとのことだったので、解説を書いてみた。
微妙な部分もあるかもしれないが、そのときは指摘してくれ…(´・ω・｀)
Phenom x4(Quad-Core)を例に挙げてみる。
Phenom x4などのQuad-Core CPUの中には、4つコアがあり、それぞれが独立して処理を行う。
よって、OSはCPUが4つあるのと同じように処理を行う事ができる。
それぞれのコアが独立して処理を行うため、「同時に2つのCPUを使いますよ」という命令をしない限り、1つのコアしか使わないので、CPUには余力があるのに、処理速度が頭打ちになってしまう。
「同時に2つ以上のCPUを使いますよ」という命令(マルチスレッド処理)を使用しているプログラムを作成するのはなかなかめんどいので、「CPUパワーが必要なのに、1つのコアしか使ってくれないプログラム」というのは結構多い。
lameはそんな「CPUパワーを必要とするが、1つのコアしか使ってくれないプログラム」のうちのひとつ。
lameの場合、「lameバイナリ側でCPUを2つ以上同時に使用するようにしたら、音質が悪くなった」
という問題が発生していたため、マルチスレッド化が進まなかった。
そこで私は
「lameひとつで4つ分の仕事をするんじゃなくて、lameを4つ使って、4つ同時に仕事させればいいんじゃね?」
と考えた。
メモリの使用量が増えるのは困る?
プロセスがやたら増えるのが嫌?
フロントエンド4つ同時起動したら同じじゃねーかって?
(´・ω・`)知らんがな
…まぁlame自体ほとんどメモリ使用しないし、フロントエンド4つ同時起動すると、ファイルの競合起こしたりする可能性もあるし…(´・ω・｀)
通常のlameの処理の流れは、上の図の通り。
この方法だと、CPUコアが1つしか有効に活用できず、
エンコード速度が、Pentium4(HT無効)が一番早く、次にCore2Duo、一番遅いのがCore2Quad…なんて事になってしまったりもする。
現状存在するlameフロントエンドでは、知っている限りでは全てこの方法を取っている。
マルチスレッド対応のlameバイナリを使用した場合の処理の流れは上の図の通り。
ひとつのファイルを、ひとつのlameプロセスで、4つのコアを使って処理する、ということなので、ひとつのファイルを処理する時間が、1/4で済むことになる。
lameバイナリ側でマルチスレッドに対応しているので、フロントエンドなどには関係なくマルチスレッド処理してくれる。
現在lameを使用しmp3を作成する方法としては一番効率が良いが、先程述べた通り、
「lameバイナリの処理をマルチスレッド化すると出力ファイルの音質が悪くなる」
という問題があるため、推奨されていない。
私の作成したフロントエンド(もどき)、mtlamefでの処理の流れは上の図の通り。
4つのソースファイルを用意し、lameプロセスを一度に4つ実行、4つのファイルを並列処理している。
ファイルひとつ当たりのエンコードに掛かる時間は、通常のlameと変わらないが、4つのファイルを同時に処理することで、処理にかかる時間を1/4にすることができる。
フロントエンド側からlameプロセスを多重実行しているだけなので、音質などに影響することは無い。
これはSHA-1ハッシュを使用した実験で実証済み。
ファイルがひとつしか無い場合は、通常のlameと同じ時間が掛かってしまうが、気にしない。
…そもそも、このプログラムを作成する上での基本方針は、
・マルチスレッド処理による処理の高速化
・ディレクトリ単位での一括エンコード
なので、ファイルが1つだけという状況はまず無いかと…
4つのファイルを同時に出力することになるので、このプログラムでは、
・出力ファイル名の競合問題
・ファイルコピー・リネーム・削除の排他処理
などの問題がやたら発生し、かなり涙目になれた。
…解説としては、大体こんな感じだろうか。
図などがかなり適当だったが…(´д｀)
分かりにくいところなどは、順次修正していく予定。
プログラム本体はこちらからダウンロードできる。
※ 09.07.26
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
微妙な部分もあるかもしれないが、そのときは指摘してくれ…(´・ω・｀)
・lameとマルチコアCPU
Phenom x4(Quad-Core)を例に挙げてみる。
Phenom x4などのQuad-Core CPUの中には、4つコアがあり、それぞれが独立して処理を行う。
よって、OSはCPUが4つあるのと同じように処理を行う事ができる。
それぞれのコアが独立して処理を行うため、「同時に2つのCPUを使いますよ」という命令をしない限り、1つのコアしか使わないので、CPUには余力があるのに、処理速度が頭打ちになってしまう。
「同時に2つ以上のCPUを使いますよ」という命令(マルチスレッド処理)を使用しているプログラムを作成するのはなかなかめんどいので、「CPUパワーが必要なのに、1つのコアしか使ってくれないプログラム」というのは結構多い。
lameはそんな「CPUパワーを必要とするが、1つのコアしか使ってくれないプログラム」のうちのひとつ。
lameの場合、「lameバイナリ側でCPUを2つ以上同時に使用するようにしたら、音質が悪くなった」
という問題が発生していたため、マルチスレッド化が進まなかった。
そこで私は
「lameひとつで4つ分の仕事をするんじゃなくて、lameを4つ使って、4つ同時に仕事させればいいんじゃね?」
と考えた。
メモリの使用量が増えるのは困る?
プロセスがやたら増えるのが嫌?
フロントエンド4つ同時起動したら同じじゃねーかって?
(´・ω・`)知らんがな
…まぁlame自体ほとんどメモリ使用しないし、フロントエンド4つ同時起動すると、ファイルの競合起こしたりする可能性もあるし…(´・ω・｀)
・通常のlameの処理の流れ
通常のlameの処理の流れは、上の図の通り。
この方法だと、CPUコアが1つしか有効に活用できず、
エンコード速度が、Pentium4(HT無効)が一番早く、次にCore2Duo、一番遅いのがCore2Quad…なんて事になってしまったりもする。
現状存在するlameフロントエンドでは、知っている限りでは全てこの方法を取っている。
・マルチスレッドに対応させたlameの処理の流れ(音質劣化有り)
マルチスレッド対応のlameバイナリを使用した場合の処理の流れは上の図の通り。
ひとつのファイルを、ひとつのlameプロセスで、4つのコアを使って処理する、ということなので、ひとつのファイルを処理する時間が、1/4で済むことになる。
lameバイナリ側でマルチスレッドに対応しているので、フロントエンドなどには関係なくマルチスレッド処理してくれる。
現在lameを使用しmp3を作成する方法としては一番効率が良いが、先程述べた通り、
「lameバイナリの処理をマルチスレッド化すると出力ファイルの音質が悪くなる」
という問題があるため、推奨されていない。
・マルチスレッド対応 lameフロントエンド (もどき)での処理の流れ
私の作成したフロントエンド(もどき)、mtlamefでの処理の流れは上の図の通り。
4つのソースファイルを用意し、lameプロセスを一度に4つ実行、4つのファイルを並列処理している。
ファイルひとつ当たりのエンコードに掛かる時間は、通常のlameと変わらないが、4つのファイルを同時に処理することで、処理にかかる時間を1/4にすることができる。
フロントエンド側からlameプロセスを多重実行しているだけなので、音質などに影響することは無い。
これはSHA-1ハッシュを使用した実験で実証済み。
ファイルがひとつしか無い場合は、通常のlameと同じ時間が掛かってしまうが、気にしない。
…そもそも、このプログラムを作成する上での基本方針は、
・マルチスレッド処理による処理の高速化
・ディレクトリ単位での一括エンコード
なので、ファイルが1つだけという状況はまず無いかと…
4つのファイルを同時に出力することになるので、このプログラムでは、
・出力ファイル名の競合問題
・ファイルコピー・リネーム・削除の排他処理
などの問題がやたら発生し、かなり涙目になれた。
…解説としては、大体こんな感じだろうか。
図などがかなり適当だったが…(´д｀)
分かりにくいところなどは、順次修正していく予定。
プログラム本体はこちらからダウンロードできる。
※ 09.07.26
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
2009年3月1日日曜日
マルチスレッド対応 lameフロントエンド (もどき) v1.8a
※追記 09.07.26
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
いろいろ問題が見つかったので、修正してv1.8aにしてみた。
バグ修正や、設定ファイル作成部分の操作性の向上を目指し、改良した。
プログラムのダウンロードはこちらから。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
7割がテンプレだな…('A`)
多分またバグがあると思うので、あったら教えて欲しいんだ…(´・ω・｀)
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
いろいろ問題が見つかったので、修正してv1.8aにしてみた。
バグ修正や、設定ファイル作成部分の操作性の向上を目指し、改良した。
特徴
- lameのエンコード処理を並列して行うことができ、Corei7・Phenomなどのマルチコア・マルチスレッドCPUや、デュアルプロセッサ環境も有効に使える。
- ディレクトリごとに一気にエンコードが可能。
- 一度設定するだけで2回目以降の設定は不要。
- wav→mp3変換とmp3→mp3変換に対応。
- Rubyがインストールしてあれば、Windows、Unix、Linux、MacOSXなどの、どんなOSでも使用することができる。
- Windowsの場合は、Rubyが無くても動く。
- Cygwinなどは必要ない。
- プロセスを多重起動しているだけなので、音質に影響するということがない。
- 大量のファイルを登録しても、登録エラーなどが発生しない(ﾊｽﾞ)
- エンコードのログを残せる。
- エンコードにかかった時間を計測できるようにしたので、ファイルやlameバイナリを統一すれば、mp3エンコードのベンチマークとして使える…かもしれない。
今回の変更・更新
- 設定ファイルの作成部分を改良。
- 設定ファイルを$HOME/.mtlamef/(Windowsno場合は%HOMEDRIVE%%HOMEPATH%/.mtlamef/)に出力するようにした。
- 設定時のベースのディレクトリを/から$HOMEに変更。
- ディレクトリのシンボリックリンクに対応。
- リストの最後にあるディレクトリを選択しても反映されない問題を修正。
解決していない問題
- mp3ファイルの再エンコードが終わってからでないとwavファイルのエンコードが開始できない。
- ディレクトリごとにしかエンコードできない(ファイルを個別にエンコードすることはできない)
- CUIである。
- 一時ファイルなどの出力先の問題。
(OSごとに環境変数が違うので厄介) - aiff形式に対応していない。
必ず必要なもの
プログラムのダウンロードはこちらから。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
7割がテンプレだな…('A`)
多分またバグがあると思うので、あったら教えて欲しいんだ…(´・ω・｀)
2009年2月15日日曜日
またもや更新 マルチスレッド対応 lameフロントエンド (もどき) v1.7a
09.07.26 追記
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
春休み期間中なせいか、3~4日おきに更新している気がするが、気にしない。
今回は、出力先ディレクトリの選択と、mp3の上書き出力の廃止&連番リネーム出力化をメインに更新してみた。
以下テンプレ。
一応毎回少しづつ変わっているのだが…
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
初代v1.0aと比べると、安定性や操作性が格段に違うな…('A`) そろそろb(beta)にするか…ねぇ。 今回のバージョンから、mp3の上書きをしないようにして、重複した場合ファイル名に連番を付加するようにしたのだが、その過程で、
…な感じに、一見暴走したように見えるくらいに文字を吐き出しながら確認を求めるようになったのだが、この文字列は表示しない方が良いのだろうか…?
そして、スクリーンショットを撮って、初めて朝の７時になっているということに気付いた…(´・ω・｀)
もう完全に昼夜逆転してるな…ｧ '`,､'`,､('∀`) '`,､'`,､
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の上書きをしないようにして、重複した場合ファイル名に連番を付加するようにしたのだが、その過程で、
…な感じに、一見暴走したように見えるくらいに文字を吐き出しながら確認を求めるようになったのだが、この文字列は表示しない方が良いのだろうか…?そして、スクリーンショットを撮って、初めて朝の７時になっているということに気付いた…(´・ω・｀)
もう完全に昼夜逆転してるな…ｧ '`,､'`,､('∀`) '`,､'`,､
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を更に更新。
今回は、「安定性・操作性の向上」を目標に、改良してみた。
プログラムのダウンロードはこちらから。
旧バージョンの管理が大変なので、全て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なんてのにも、挑戦してみたいが…(´・ω・｀)
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月8日日曜日
lameマルチスレッド対応フロントエンド（もどき） v1.5a
09.07.26 追記
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド(もどき))をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
試験も終わって遂に春休みｷﾀ-*･゜ﾟ･*:.｡..｡.:*･゜(ﾟ∀ﾟ)ﾟ･*:.｡. .｡.:*･゜ﾟ･*!!!!
…ということで、LAMEをマルチスレッドで実行するフロントエンド(もどき) v1.4を更に更新してみた。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
試しに8スレッド立ててエンコードしてみた。
久々に、高負荷で他に何も操作できないという状態を体験した…(´・ω・｀)
試しに以前のバージョン(v1.3など)で、2秒のファイル50個を8スレッド並列処理させたところ、 かなりの頻度でアクセス権エラーが… 不具合多すぎだな…あれ…。 申し訳ない…(´；ω；｀)ｳｯ…
実行ファイルのアイコンを変更したら…
…私には削除できない…(´；ω；｀)ﾌﾞﾜｯ
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に変更したら問題無く動作した。
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%うｐ!(当社比)
したこと。
(あくまで感想であり、実際に効果があるかは(ry )
言ってしまえば、
「今までのバージョンDLして使っちゃっている人、もしいたら、ごめんね…」
なぐらいの変化が。
変更点や特徴などは以下の通り。
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の手順を繰り返せばおｋ。 多重登録などは発生しないようにしておいた。 エンコードしたいディレクトリの選択が終わったら、 カレントディレクトリ選択メニューのところで"/q"でエンコード処理に進める。 7. 後はエンコードが終わるのを待つだけ 
ファイルの上書きをしなければならないときは、一応問い合わせるようにしてある。
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で非効率なソースですまない…(´；ω；｀)ﾌﾞﾜｯ
私、期末テスト期間中なんだけどなぁ… …まぁいいか。
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
lameマルチスレッドエンコードフロントエンド(もどき)を、大幅に修正してみた。
特に大きいのは、
ディレクトリ選択操作の効率が80%うｐ!(当社比)
したこと。
(あくまで感想であり、実際に効果があるかは(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である。
- ディレクトリごとにしかエンコードできない(ファイルを個別にエンコードすることはできない)
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の手順を繰り返せばおｋ。 多重登録などは発生しないようにしておいた。 エンコードしたいディレクトリの選択が終わったら、 カレントディレクトリ選択メニューのところで"/q"でエンコード処理に進める。 7. 後はエンコードが終わるのを待つだけ 
ファイルの上書きをしなければならないときは、一応問い合わせるようにしてある。 必ず必要なもの
- lameバイナリ
- Rubyバイナリもしくは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で非効率なソースですまない…(´；ω；｀)ﾌﾞﾜｯ
私、期末テスト期間中なんだけどなぁ… …まぁいいか。
2009年1月26日月曜日
LAMEをマルチスレッドで実行するプログラムを作ってみた v1.3a
09.07.26 追記
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド(もどき))をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ようやくいろんなレポートが片付いてきたので、lameをマルチスレッドで実行するプログラム v1.2を修正・改良してみた。
今回は、ログの作成機能を主に追加してみた。
1スレッド: 158秒
2スレッド並列: 72秒
3スレッド並列: 45秒
4スレッド並列: 33秒
5スレッド並列: 31秒
6スレッド並列: 31秒
7スレッド並列: 35秒
8スレッド並列: 35秒
バックグラウンドで仮想マシンやら何やら、大量に動いている状態で実験したので、ベンチマークの結果としては微妙だが、 クアッドコアの性能が十分に生かされている………と思う。
しかし、その過程で、「鏡音レンの暴走.wav」がエンコードできないという問題が発生。 …lameのshift-jis ダメ文字問題のことをすっかり忘れていた…
今回も、Windowsでは全てOne-Click Ruby Installerを使用。 One-Click Ruby Installer for Windowsは以下で入手できる。
http://rubyforge.org/frs/?group_id=167
英語のインストーラーしか無いが、全部デフォルト設定でおkなので困ることはないと思う。
プログラムの本体はいつも通りｹﾞｲｼﾄﾞﾗｲﾌﾞからダウンロードできるようにしてみた。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド(もどき))をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ようやくいろんなレポートが片付いてきたので、lameをマルチスレッドで実行するプログラム v1.2を修正・改良してみた。
今回は、ログの作成機能を主に追加してみた。
特徴
- lameのエンコード処理を並列して行うことができ、Corei7などのマルチコア・マルチスレッドCPUも有効に使える。
- ディレクトリごとに一気にエンコードが可能。
- 一度設定するだけで2回目以降の設定は不要。
- wav→mp3変換とmp3→mp3変換に対応。
- Rubyがインストールしてあれば、Windows、Unix、Linux、MacOSXなどの、どんなOSでも使用することができる。
- プロセスを多重起動しているだけなので、音質に影響するということがない。
- 大量のファイルを登録しても、登録エラーなどが発生しない(ﾊｽﾞ)
- エンコードのログを残せる。
- エンコードにかかった時間を計測できるようにしたので、ファイルやlameバイナリを統一すればベンチマークとして使える…かもしれない。
1.2からの変更点
- ログを残せるようにした。
- エンコードにかかった時間を計測できるようにした。
- エンコードに失敗した場合、通知するようにした。
- 同じファイルを2回以上エンコードしてしまうかもしれない問題を修正。
- その他、様々な問題を修正。
解決していない問題
- Unix系OSでの拡張子の大文字・小文字問題(.WAV、.wAv等が処理できない)
- mp3ファイルの再エンコードが終了しないとwavファイルのエンコードを開始できない。
- mp3の再エンコードのみを行うことができない。
- ディレクトリ名を打ち込むのが果てしなく面倒くさい。 … v1.4で解決する予定。
1スレッド: 158秒
2スレッド並列: 72秒
3スレッド並列: 45秒
4スレッド並列: 33秒
5スレッド並列: 31秒
6スレッド並列: 31秒
7スレッド並列: 35秒
8スレッド並列: 35秒
バックグラウンドで仮想マシンやら何やら、大量に動いている状態で実験したので、ベンチマークの結果としては微妙だが、 クアッドコアの性能が十分に生かされている………と思う。
しかし、その過程で、「鏡音レンの暴走.wav」がエンコードできないという問題が発生。 …lameのshift-jis ダメ文字問題のことをすっかり忘れていた…
今回も、Windowsでは全てOne-Click Ruby Installerを使用。 One-Click Ruby Installer for Windowsは以下で入手できる。
http://rubyforge.org/frs/?group_id=167
英語のインストーラーしか無いが、全部デフォルト設定でおkなので困ることはないと思う。
プログラムの本体はいつも通りｹﾞｲｼﾄﾞﾗｲﾌﾞからダウンロードできるようにしてみた。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
2009年1月6日火曜日
LAMEをマルチスレッドで実行するプログラムを作ってみた v1.2a
09.07.26 追記
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
冬休みもそろそろ終了ということで、頭の運動になるかと思い「lameのエンコードをマルチスレッド処理するプログラム v1.1」を更に改良(?)してみた。
http://projectzero-swb.blogspot.com/2008/12/lame.html
「lameのエンコードをマルチスレッド処理するプログラム」本体は、いつも通りｹﾞｲﾂﾄﾞﾗｲﾌﾞからダウンロードできるようにした。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
解決できていない問題がたいして減っていない件。 …まぁいいか。
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
冬休みもそろそろ終了ということで、頭の運動になるかと思い「lameのエンコードをマルチスレッド処理するプログラム v1.1」を更に改良(?)してみた。
特徴
- lameのエンコード処理を並列して行うことができ、Corei7も有効に使える。
- ディレクトリごとに一気にエンコードが可能。
- 一度設定するだけで2回目以降の設定は不要。
- wav→mp3変換とmp3→mp3変換に対応。
- Rubyがインストールしてあれば、Windows、Unix、Linux、MacOSなどの、どんなOSでも使用することができる。
- プロセスを多重起動しているだけなので、音質に影響するということがない。
- 大量のファイルを登録しても、登録エラーなどが発生しない(ﾊｽﾞ)
1.1からの変更点
- カレントディレクトリの指定を可能にした。
- 同じディレクトリを複数回登録しないようにした。
- 一部のオプションをlameのデフォルト設定で動かせるようにした。
- Windows版とUnix版の違いを無くした。
- lameのパスにスペースが含まれているとうまく処理できない問題を修正。
解決していない問題
- Unix系OSでの拡張子の大文字・小文字問題(.WAV、.wAv等が処理できない)
- mp3ファイルの再エンコードが終了しないとwavファイルのエンコードを開始できない。
- mp3の再エンコードのみを行うことができない。
- エンコードに失敗しても「全ての処理が完了しました」と出る。
インストール後の「ディスク上のサイズ」が150MB近くになるんだよな…これ。サイズ自体は80MB無いのに… それでも、これ無いと動かないしな…
使用方法やRubyバイナリのインストール方法はv1.0と同じで…http://projectzero-swb.blogspot.com/2008/12/lame.html
「lameのエンコードをマルチスレッド処理するプログラム」本体は、いつも通りｹﾞｲﾂﾄﾞﾗｲﾌﾞからダウンロードできるようにした。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
解決できていない問題がたいして減っていない件。 …まぁいいか。
マルチスレッドCPUはPentium4があったが、マルチコアCPUはPhenom x4が初めてなんだよな…そういえば。
全然知識が無い時に、何故CPU使用率が50%で固定になるのか、悩んだんだよなぁ…'`,､('∀`) '`,､
BIOSでHyper-Threadingをoffにしたらやたら不安定になったりとか…
最近は「多コア化」がメインなんだよな… マルチスレッド対応してないと、エンコードとかはどんどん辛くなっていきそうだな… Cellみたいなヘテロコアを有効に使うアプリケーションの開発って、やはり難しいのだろうか…?
GUIで作りたいな、という希望が自分の中にあったりするが… CUIのままじゃ「lameフロントエンドもどき」…だしなぁ…
全然知識が無い時に、何故CPU使用率が50%で固定になるのか、悩んだんだよなぁ…'`,､('∀`) '`,､
BIOSでHyper-Threadingをoffにしたらやたら不安定になったりとか…
最近は「多コア化」がメインなんだよな… マルチスレッド対応してないと、エンコードとかはどんどん辛くなっていきそうだな… Cellみたいなヘテロコアを有効に使うアプリケーションの開発って、やはり難しいのだろうか…?
GUIで作りたいな、という希望が自分の中にあったりするが… CUIのままじゃ「lameフロントエンドもどき」…だしなぁ…
2008年12月29日月曜日
LAMEをマルチスレッドで実行するプログラムを作ってみた v1.1a
09.07.26 追記
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
冬休みが始まり、友人が殆ど帰省してしまい、ヒマになったので、「lameのエンコードをマルチスレッド処理するプログラム」をいろいろ改良(?)してみた。
拡張子が.wav以外だと、Unix系OSで処理できない問題は、Unix系OSとWindowsでのファイル名の扱いの違いがあることから、今回は修正出来ず…('A`)
Windowsって"miku.mp3"と"MIKU.MP3"が同じファイル名として認識されるんだったな…
RubyのバイナリはOne-Click Ruby Installer for Windowsをインストールするのが一番楽な感じがした。
One-Click Ruby Installer for Windowsは以下で入手できる。
http://rubyforge.org/frs/?group_id=167
使用方法やRubyバイナリのインストール方法はv1.0と同じで…
http://projectzero-swb.blogspot.com/2008/12/lame.html
「lameのエンコードをマルチスレッド処理するプログラム」本体は、ここからダウンロードできるようにしてみた。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
いつの間にかｹﾞｲﾂﾄﾞﾗｲﾌﾞの容量が25GBに増えてた…(ﾟдﾟ)ｳﾏｰ
これで、一気にミク曲が100曲位増えても、あっという間にエンコードが終わるよ…'`ｧ,､ｧ(*´Д｀*)'`ｧ,､ｧ
…私は曲を作ることはできないが、これなら…(´・ω・｀)
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
冬休みが始まり、友人が殆ど帰省してしまい、ヒマになったので、「lameのエンコードをマルチスレッド処理するプログラム」をいろいろ改良(?)してみた。
変更点
- Core i7やQuad-Core Opteronのデュアルプロセッサなんて贅沢な環境を使っている人の為に、同時に8スレッドまで立てられるようにした。
- mp3ファイルの再エンコードに対応。
- ファイルの上書きチェックをし、一応問い合わせるようにした。
解決していない問題
- Unix系OSでの拡張子の大文字・小文字問題(.WAV、.wAv等が処理できない)
- mp3ファイルの再エンコードが終了しないとwavファイルのエンコードを開始できない。
- mp3の再エンコードのみを行うことができない。
- 相対パスで指定することができない。
- エンコードに失敗しても「全ての処理が完了しました」と出る。
拡張子が.wav以外だと、Unix系OSで処理できない問題は、Unix系OSとWindowsでのファイル名の扱いの違いがあることから、今回は修正出来ず…('A`)
Windowsって"miku.mp3"と"MIKU.MP3"が同じファイル名として認識されるんだったな…
RubyのバイナリはOne-Click Ruby Installer for Windowsをインストールするのが一番楽な感じがした。
One-Click Ruby Installer for Windowsは以下で入手できる。
http://rubyforge.org/frs/?group_id=167
使用方法やRubyバイナリのインストール方法はv1.0と同じで…
http://projectzero-swb.blogspot.com/2008/12/lame.html
「lameのエンコードをマルチスレッド処理するプログラム」本体は、ここからダウンロードできるようにしてみた。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
いつの間にかｹﾞｲﾂﾄﾞﾗｲﾌﾞの容量が25GBに増えてた…(ﾟдﾟ)ｳﾏｰ
これで、一気にミク曲が100曲位増えても、あっという間にエンコードが終わるよ…'`ｧ,､ｧ(*´Д｀*)'`ｧ,､ｧ
…私は曲を作ることはできないが、これなら…(´・ω・｀)
2008年12月21日日曜日
LAMEをマルチスレッドで実行するプログラムを作ってみた
09.07.26 追記
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
mp3エンコーダーとして物凄く有名なlame。
音質などの面ではかなり良いのだが、マルチスレッド化で音質が低下するなどの問題が発生したらしく、最近主流のPhenomx4やCore2Quadなどのマルチコア・マルチスレッドCPUには対応できておらず、エンコード速度の面でちょっと問題がある。
ということで、
lameのエンコードをマルチスレッド処理するプログラム
を、Rubyで作ってみた。
(大学のレポートとして、4日間の突貫工事で作成したのだったりする)
エンコード処理内でマルチスレッドにするわけではない(コマンドプロンプトを4つ開いて、同時に実行しているのと同じ)ので、音質の問題も発生しない。…ハズ。
(以前、こんな実験をして確認したので、多分問題無い。)
一応、WindowsでもLinux・Unix・MacOSXのどれでも、Rubyが動けば使用できる…と思う。
(Windowsでは少し問題が発生したので、一応別に作り直したが)
ダウンロードはこちらから。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
※追記: One-Click Ruby Installer for Windowsの方がたぶん楽だが、書いてしまったので一応残す。
ソースに意味不明な#コメントが付いていたり、無駄が大量にするが、 見ないふりしてほしいんだ…(´；ω；｀)ｳｯ…
そのうちCorei7向けに8スレッドまで立てられるのも作ろうかと画策中(30分もかからずに出来そう…だが)
この要領で、他のAACやogg、flacとかのエンコーダやデコーダに対応したのも簡単に作れそうだな… …時間が足りないな('A`)
このプログラムを作成する上で、はつねさんの声を一体何回エンコードしたのだろうか…
そして1週間ほどニコニコ放置してたら新曲増えまくりで涙目w …(´；ω；｀)ﾌﾞﾜｯ
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/
ここより下の情報は古いです…(´・ω・｀)ｽﾏｿ
mp3エンコーダーとして物凄く有名なlame。
音質などの面ではかなり良いのだが、マルチスレッド化で音質が低下するなどの問題が発生したらしく、最近主流のPhenomx4やCore2Quadなどのマルチコア・マルチスレッドCPUには対応できておらず、エンコード速度の面でちょっと問題がある。
ということで、
lameのエンコードをマルチスレッド処理するプログラム
を、Rubyで作ってみた。
(大学のレポートとして、4日間の突貫工事で作成したのだったりする)
エンコード処理内でマルチスレッドにするわけではない(コマンドプロンプトを4つ開いて、同時に実行しているのと同じ)ので、音質の問題も発生しない。…ハズ。
(以前、こんな実験をして確認したので、多分問題無い。)
一応、WindowsでもLinux・Unix・MacOSXのどれでも、Rubyが動けば使用できる…と思う。
(Windowsでは少し問題が発生したので、一応別に作り直したが)
あまりに汚いのでコメントアウトしました…(´・ω・｀)
ダウンロードはこちらから。
旧バージョンの管理が大変なので、全てMulti thread Media Encoder Frontendに纏めました。
http://mtmef.g.hachune.net/
※WindowsでのRubyバイナリのインストール&スクリプトの実行
※追記: One-Click Ruby Installer for Windowsの方がたぶん楽だが、書いてしまったので一応残す。
- http://www.garbagecollect.jp/ruby/mswin32/ja/から安定版の最新版をダウンロード。
- Windows用lameバイナリはこちらからhttp://www.rarewares.org/mp3-lame-bundle.php
- 適当な解凍ツールを使用し解凍。
- "bin""doc""lib""man""share"といったディレクトリが生成されるので、ディレクトリ階層を壊さないようにそのまま全て"C:\Program Files\Ruby"などのディレクトリに入れる。
- 例:
- C:\Program Files\Ruby\bin
- C:\Program Files\Ruby\doc
- C:\Program Files\Ruby\lib
- C:\Program Files\Ruby\man
- C:\Program Files\Ruby\share
- C:\Program Files\Ruby\bin
- mtlamefconf.rbをコマンドプロンプトで実行すると、「このファイルを開けません」と出るので、「一覧からプログラムを選択する」を選択。
- 「参照」をクリックし、先ほどインストールしたRubyディレクトリの中の、bin/ruby.exeを選択。「この種類のファイルを開くときは、選択したプログラムをいつも使う」のチェックボックスをONにし、OKする。
- 再度mtlamefconf.rbをコマンドプロンプトで実行。環境を設定する。
- mtlamef_win.rbを実行。
※Linux・Unix・MacOSXでのRubyのインストール・スクリプトの実行
- ソースコードかパッケージ管理を利用してRubyとlameをインストール。
- mtlamef.rbのソースの1行目の
#!/usr/bin/ruby
を、自分でRubyをインストールしたディレクトリに設定しなおす。 - 端末でmtlame*.rbを実行。
※既知の問題
- 同じ名前のmp3ファイルが存在すると、問い合わせなしに上書きしてしまう
- ".wav"以外の拡張子が付いていた場合、wavファイルでも処理することができない
(".Wav"、".WAv"、".WAV"、".wAv"、".wAV"、".wav"、".wave"…など) - mp3ファイルの再エンコードが出来ない
- 相対パスで指定することができない("~/mp3"など)
- "lameが見つからない"、"ファイルのアクセス権が無い"などのエラーが発生した場合でも、
最後に「エンコードが完了しました」と出てしまう。
そのうちCorei7向けに8スレッドまで立てられるのも作ろうかと画策中(30分もかからずに出来そう…だが)
この要領で、他のAACやogg、flacとかのエンコーダやデコーダに対応したのも簡単に作れそうだな… …時間が足りないな('A`)
このプログラムを作成する上で、はつねさんの声を一体何回エンコードしたのだろうか…
そして1週間ほどニコニコ放置してたら新曲増えまくりで涙目w …(´；ω；｀)ﾌﾞﾜｯ
登録:
投稿 (Atom)
