ラベル Ubuntu の投稿を表示しています。 すべての投稿を表示
ラベル Ubuntu の投稿を表示しています。 すべての投稿を表示

2009年10月31日土曜日

Ubuntu 9.10もいつの間にかリリース

入門Linux(?)として最近有名なUbuntuの最新版、Ubuntu 9.10(kermic)もいつの間にかリリースしていた。

…とりあえずVMにインストールしてみるよ(´・ω・`)


デフォルトのファイルシステムがext4になっていたり、謎の機能「Ubuntu One」が追加されていたり、デフォルトのメッセンジャーがpidginからEmpathyに、IMがSCIMからiBusに変更されていたり…
付属ソフトがコロコロ変わるってのは、初心者に優しくないような気がしなくもないのだが('A`)

あと、「結構重い」というのも…
まぁ、重いといっても、Vista初期に売られまくっていたVista必須スペック限界PC位なら普通に使えるので、まず気にならないとは思う。

EeePCをOpenSUSE 11.1からこっちに換えるべきか…悩み所だな…

2009年9月21日月曜日

# rm -rf /を実際にやってみた

Hyper-V 2.0の動作実験としてインストールしたUbuntuが必要無くなったので、よくネタとして扱われる
# rm -rf /
を実際に実行してみた。

その結果…
rm: cannot remove root directory '/'
(´・ω・`)ショボーン



では、# rm -rf /*ではどうなるのか。



( ゚∀゚)アハハ八八ノヽノヽノヽノ \ / \/ \


ここで固まってしまい、リブート。
だが、正しく起動できる訳もなく、
GRUB loading, please wait...
Error 15

となり…(ヽ´ω`)

2009年8月26日水曜日

Opera 10 RCが公開されていた件

何故かFirefox嫌い(?)な私が常用しているwebブラウザ、Operaのバージョン10のRelease Candidate版が、Opera Desktop Term Blogにて公開されていた。

http://my.opera.com/desktopteam/blog/2009/08/25/opera-10-0-release-candidate

正式版は9月1日にリリースされる予定らしい。
新しい物好き・Beta版好きな私は、正式版を待たず、早速RC版をインストールしてみた。

Opera 10 RC

Beta3から変わった点は、日本語化された(Beta時代は英語)ことと、デフォルトのUIが変わった位…か?
相変わらずフォントの設定が面倒くさいこと以外は、なかなか良い感じ。




※Firefoxが嫌いというより、私の家の回線が遅い上に不安定で、新しいページを開き損ねた時に、一瞬で前開いていたページを読めるOperaが便利過ぎてずっと使っている、ということだったりする。

Opera turboなど、回線が細くても快適なブラウジングができる機能が他にもあるので、回線が細い人にはとてもオススメ。

2009年8月22日土曜日

Multi thread Media Encoder Frontend v1.2 完成

コマンドプロンプトだと使いにくいって言われるから、そろそろGUI付けようか…(´・ω・`)
と考え続けて半年。
VisualuRubyが無茶苦茶使いやすいことに気付き、とりあえずVisualuRubyで作ることに決めて4日。

ようやくGUI付きのMulti thread Media Encoder Frontendが完成したよ…(´;ω;`)ウッ…
Malti thread Media Encoder Frontend GUI
これで本当に「フロントエンド」を名乗れる…気がしなくもない。
…地味だけど、これでいいよね…('A`)

使用方法、プログラムのダウンロードは、http://mtmef.g.hachune.net/からどうぞ。

2009年8月16日日曜日

マルチスレッド対応 マルチフロントエンド(もどき) 改め Multi thread Media Encoder Frontendのまとめサイトがようやく完成

マルチスレッド対応 マルチフロントエンド(もどき)では、どういうソフトなのか分かりづらいという反省点を踏まえ改名。ついでに、物凄く分かりづらかった使い方の説明や、最新版の配布を行うためのまとめサイトを作ってみた。

まとめサイトは以下のリンクから。
http://mtmef.g.hachune.net/


更についでに、ソフト本体の更新も行った。
今回(v1.1)の変更点は、以下の通り。
・lame(mp3)に加え、ogg Vorbis(ogg)、Free Lossless Audio Encoder(flac)、The True Audio(tta)、neroAacEnc(aac、m4a)、Windows Media Audio(wma)によるエンコードに対応。
・ディレクトリ選択時に、ディレクトリパス名の補完をTabキーで行えるようになった。
・-vオプションを付けて起動するか、スレッド数を1にすることで、エンコード/デコード処理の詳細を表示するようにした。
・その他細かな修正


プログラムを直接ダウンロードしたい場合は以下のリンクからどうぞ。
https://sites.google.com/a/g.hachune.net/mtmef/home/download

…(´ぅω・`)ネムタス

2009年7月25日土曜日

マルチスレッド対応 マルチフロントエンド(もどき) を作ってみた

だいぶ前、マルチスレッド対応 lameフロントエンド(もどき)を更新すると言って早一ヶ月…。
ようやくそれなりのモノが完成したので公開することにしてみることにした。

以前作っていたマルチスレッド対応 lameフロントエンド(もどき)を元に、

・機能と安定性、起動速度の向上
・lame(mp3)以外のエンコーダー以外にも対応(設定ファイルで追加可能、NeroAacEnc(m4a)、ogg Vorbisの動作を確認)
・コマンドラインで動作させられるものであれば、音楽だけでなく、動画等のエンコーダーにも対応させることが可能になった…かもしれない
・一応オブジェクト指向風味に

…などの改善を行った。
(元にしたと言っても、ソースは1から書き直していたりするのだが…)

その他にも、

・手軽にマルチスレッド化でき、どんなエンコーダーでもマルチコアCPUを有効に使える
・ファイルの名前、サイズ、最終アクセス日時、最終更新日時でフィルタリングをかけ、対象ファイルを絞り込んだりできる
・相変わらずディレクトリ単位での一括エンコードに特化
・結構詳しいエンコードログを記録できる(バイナリ統一すればベンチマークとしても使える…かも?)
・実行ファイルのアイコンにディレクトリ(フォルダ)アイコンをドラッグアンドドロップすると、規定の設定で一発エンコードすることが可能

などといった特徴がある…と思う(´・ω・`)


プログラム本体は以下からダウンロードできます。
http://mtmef.g.hachune.net/

※09.07.27 neroAacEncのコマンドラインオプションが、"-b 256000"ではなく"-b 256"となっている問題を修正しました。
ついでに、ogg Vorbisでのエンコードにも対応させました。
これで、neroAacEncとogg Vorbisをマルチスレッド化できる…ハズ。

※09.08.07 lame ABRのオプションの"--a"とすべきところが、"-a"となっている問題、pdcurses.dllが見つからないと言われる問題を修正しました。
設定ファイルの"-a"となっているところを"--a"にするだけでも回避できます。

※09.08.15 追記
ブログだといろいろ見づらい上に分かりづらいので、一つに纏めてみた
ついでに使い方の解説もしています。
最新版のダウンロードはこちらのページから行えます。
http://mtmef.g.hachune.net/



デフォルトの設定ファイルでは、lame(mp3)かneroAacEnc(m4a)、ogg Vorbisのいずれかのバイナリが必要です。
lameのWindows用バイナリは以下からダウンロードすることが出来ます。
http://www.rarewares.org/mp3-lame-bundle.php
neroAacEncのバイナリは以下からダウンロードすることが出来ます。
http://www.nero.com/jpn/technologies-aac-codec.html
ogg Vorbisのバイナリは以下からダウンロードすることが出来ます。
http://www.rarewares.org/ogg-oggenc.php


フォルダごとに適当にドラッグアンドドロップで登録して、実行するとこんな感じになる。

4つを別々に登録したので、コマンドプロンプトのウィンドウが4枚開いているが、
一つのウィンドウの処理が終わるまで待ち、それが終わった瞬間次の処理に移るようにしているので、
ファイルの整合性に問題が出ることは無い。
ドラッグアンドドロップで大量に登録しても、処理待ち状態になって、他の処理が終了すれば自動的に次の処理が開始することになるので、指定されたスレッド数以上の処理をすること無く処理を行う事が出来る。


5月位からすこーしずつ作り続けて、ようやくここまで…(ヽ´ω`)
後は、ディレクトリ選択や設定変更をGUI上で出来るようにすれば…
ドラッグアンドドロップでのエンコードに対応したんで、そろそろ(もどき)外してもいいかな…('A`)

それにしても、今マルチスレッド対応 lameフロントエンド(もどき)のソースを見ると、こりゃ汚いな…と。
非効率な上、やたらコケるという…
正直、あんなもんリリースしててごめんなさいと言わざるを得ない気が…(´・ω・`)

2009年7月4日土曜日

VMware Server 2をUbuntuにインストール

長い間、期限の切れたVMware Workstationで仮想マシンイメージを作成し、VMware Playerで起動という、激しく面倒くさいことをしていた。だが、ホストOSが起動したら、自動で仮想ゲストOSも起動する機能が必要になってきたので、VMware Serverを使ってみることにした。




まずは、VMware Server 2のLinux版をダウンロードしてくる。

http://www.vmware.com/jp/products/server/を開き、ダウンロードをクリック、"Register for your FREE Download"とあるので、名前とメールアドレスを入力、その他の情報を入力し、ユーザー登録するとダウンロードできる。
登録したメールアドレスにVMware Serverのアクティベーションに関する情報が送られてくるので、正しいメールアドレスを登録するように注意する。

今回はUbuntu x86_64に環境を構築する、ということなので、The core application needed to run VMware Server 2, 64-bit versionをダウンロードしてくる。



ダウンロードが終了したら、書庫を解凍、管理者権限でvmware-install.plを実行する。
インストール時、基本的には全部そのままEnter(デフォルト設定)で構わないが、
The current administrative user for VMware Server is ''. Would you like to
specify a different administrator?

と、VMware Serverの管理環境にログインするユーザーをどうするか聞かれる。
デフォルトでrootに設定されているが、Ubuntuでは通常rootアカウントにパスワードが設定されておらず、管理環境にはsudoを使ってログインということもできない為(Firefox等のブラウザ上で操作)、この設定だけ変更する必要があった。(デフォルト(root)のままでも、rootパスワードを変更(% sudo passwd root)すればVMware Serverの管理環境へログインできるが…)




何も問題が発生せずにインストールが終了したら、https://localhost:8333/にアクセス(httpsを使用したくないならhttp://localhost:8222/)する。

httpsでアクセスすると、

といった感じに怒られて、アクセスできない。
仕方が無いので、Firefox3の編集→設定→詳細タブ→証明書を表示→サーバー証明書→例外を追加…を開き…


https://localhost:8333/を入力、証明書を取得し、この証明書のセキュリティ例外を承認する。




こんな感じの画面が表示されれば、たぶん大丈夫…だと思う。
ここで、先ほど設定したユーザー名と、そのユーザーのログインパスワードを入力し、VMWareServerのログインを行う。

このとき使用するブラウザは、Firefoxが一番無難だと思われる。

それ以外のブラウザ(Operaなど)だと、コンソールが表示できない等の問題が発生して、まともに使用することができない。

Operaダメなのか…(´・ω・`)





Create Virtual Machineから、VMware Workstation等と同じ感じで、ゲストOSを設定できる。
Permisssionsタブから、管理環境でのアクセス権を設定することも可能。
間違ってrootで入るように設定してしまった場合も、ここで修正できる。




設定後、コンソールを開こうとすると、The VMware Remote Console Plug-in is not installed or could not be found.Please install the VMware Remote Console Plug-in to access this virtual machine's console.と、怒られてしまう。
install plug-inをクリックし、Firefox用のアドオンをインストールし、Firefoxを再起動する。


この時、「あなたのコンピューターを保護するため、Firefoxはこのサイト(localhost)はソフトウェアのインストールを要求出来ない設定になっています」と出るが、そのまま許可するしかないので、許可。



後は、VMware Playerと大体同じ感覚で、OSのセットアップ、管理を行える。





その他に分かった事は、
・ホストOS起動時のゲストOSの挙動は、Edit Virtual Machine Startup/Shutdown Settingsから行うことができる。
・仮想環境構築に必要なファイル(OSのisoイメージなど)は、指定したデータストア(デフォルトでは/var/lib/vmware/Virtual Machines)からのみ読み込める。ネットワークドライブなども指定可能。
ということ位か。

ネットワークを使用してサーバーのハードウェアを管理できるのは、予想以上に便利。
WindowsのVMware Playerも、VMware Serverに切り替えるか…('A`)

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年4月26日日曜日

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

※追記 09.07.26
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の正規表現を利用した絞り込み検索機能をメインに、修正してみた。


以下テンプレ。

どういう処理をするのか、などの解説はこちら。

特徴

  • 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月20日金曜日

Microsoftが学生向けにOSや開発ツールを無償で提供中

Microsoftは以前から、国際学生証を所有している学生向けにMicrosoft製品を提供する、ということをやっていたが、
最近、その対象に高校生なども含まれるようになったらしい。

提供される製品は以下の通り。
・Expression Studio 2
・SQL Server 2008 Developer Edition
・Visual Studio 2005 Professional Edition
・Visual Studio 2008 Professional Edition
・Windows Server 2003 Standard Edition
・Windows Server 2008 Standard Edition x86
・XNA Game Studio 3.0
・Microsoft CCR and DSS Toolkit 2008 Academic Edition
・Microsoft Robotics Developer Studio 2008 Academic Edition


普通にパッケージ版を買ったら、10万円近くするものも。

関連情報を某掲示板で見ていたら、メールでの申し込みフォームへのリンクがあった。
…国際学生証いらないじゃないか(;´д`)

実際に情報を入力し、メールを送信してみたところ、問題無く登録&ソフトウェアの入手ができた。
これは激しく(゚д゚)ウ-(゚Д゚)マー(゚A゚)イ-…ヽ(゚∀゚)ノ…ゾォォォォォ!!!!


・IT pro: マイクロソフト、20万円相当のソフト製品群を高校生に無償提供
http://itpro.nikkeibp.co.jp/article/NEWS/20090316/326707/?ST=win

・Microsoft DreamSpark Top
http://www.dreamspark.com/default.aspx

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のデュアルプロセッサ、とかは…(´・ω・`)知らんがな


どういう処理をするのか、などの解説はこちら。


特徴

  • 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スレッドに対応したので、試しにやってみた。
mtlamef 16thread
Phenomx4タン(´・ω・)カワイソス…
そしてタスクマネージャーが凄いことに…

ようやく普通のコンソールアプリ位に使えるレベルになってきた…かもしれない…'`,、('∀`) '`,、

2009年3月1日日曜日

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

※追記 09.07.26
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の上書き出力の廃止&連番リネーム出力化をメインに更新してみた。

以下テンプレ。
一応毎回少しづつ変わっているのだが…

特徴

  • 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月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月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月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で非効率なソースですまない…(´;ω;`)ブワッ
私、期末テスト期間中なんだけどなぁ… …まぁいいか。  

2009年1月26日月曜日

LAMEをマルチスレッドで実行するプログラムを作ってみた v1.3a

09.07.26 追記
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で解決する予定。
試しに暴走Pの2ndアルバム、「少女の空想庭園」を、Phenomx4搭載のはつねサーバで、全曲(-v -V 0)でエンコードした結果…
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月7日水曜日

Ubuntu8.10でtk8.4.19がインストールできない

RubyでのGUIプログラミングで、とりあえずTcl/Tkを試してみようと、tcl8.4.19-src.tar.gzとtk8.4.19-src.tar.gzをダウンロードしてきて、make installしてみようとしたところ、tk8.4.19のmakeでエラーに。
何が原因かと調べてみたら、xproto.hやらxresource.hが足りないとのこと。

…って ま た お ま い ら か

…以前rdesktopをmakeしようとしたときもこれが原因だったな…('A`)


ソースからmakeするのは激しく面倒なのでおとなしく
sudo apt-get install xorg-dev
しておいた。

これで普通にmakeできて(゚д゚)ウマー

2009年1月6日火曜日

LAMEをマルチスレッドで実行するプログラムを作ってみた v1.2a

09.07.26 追記
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の再エンコードのみを行うことができない。
  • エンコードに失敗しても「全ての処理が完了しました」と出る。
今回からは、Windowsでは全てOne-Click Ruby Installerを使用した。 One-Click Ruby Installer for Windowsは以下で入手できる。 http://rubyforge.org/frs/?group_id=167
インストール後の「ディスク上のサイズ」が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フロントエンドもどき」…だしなぁ…