航海日誌 Starlog

ICレコーダで録音したラジオ番組を、ターミナルでlameコマンドを使ってmp3に変換することをよく行う。lameはiTunes-LAME内にあるものをAltivec/SSE最適化版に入れ替えてあり、こいつのシンボリックリンクを/usr/local/bin/に置いてある。ターミナルのパスは/usr/local/bin/に通っているので(自分で設定したかもしれない)、他のコマンドと同じように普通に使える。

このSSE最適化版はかなり速くて、Core 2 Duo 2.26 GHzのMBP 13" 2009で35〜40倍の変換速度になる。公式サイトで配布されているlameだと25倍ぐらいなので、1.5倍程度速い。

それが、いつの頃からかターミナルからの実行が公式並の速度になってしまった。

原因はMacportsのffmpegがlameをインストールし、コマンド検索パスに/opt/local/bin/が先頭にあるためSSE最適化版が使われなくなったため。

~/.bash_profileを編集して/usr/local/bin/を検索パスの先頭にした。

だが、Macportsのインストーラが毎回/opt/local/bin/をパスの先頭に加えるので、Macportsのインストーラを使うたびにパスを直さないといけない。Macportsの公式では、OSをアップデートしたら一旦全てアンインストールし、新OS対応のMacportsのインストールからやり直すのを推奨していたようなきがするのだが、面倒だからやめようかな。

MacBook Pro 13" (2009)でiTunes-LAMEを使っている。購入直後にインストールし、Leapardの時からOSもiTunesも上書きインストールをして使ってきていた。今回、新規作成したユーザーアカウントでiTunes-LAMEを設定しようとして躓いたので記録する。

以前手持ちのCDをすべてApple LosslessでPowerMac G3につないだHDDに取り込んだ。今iTunesにMP3化してあるCDは、手持ちのCDの大部分ではあるが全てではない。また、CDの取り込みはLAMEを使うようになる前のことで、ほとんどがMac OS 9上のiTunes 2でエンコードされている。

iTunesのMP3エンコーダは、聴感よりは周波数特性優先のエンコードをするので、LAMEに比べて音が悪い。エンコード速度だけは速いのだが、Altivec(SSE)最適化LAMEの方がもっと速い。そこで、Apple Losslessで取り込んだデータからLAMEを使ってMP3へ変換することにした。

CDをApple Losslessで取り込んだHDDは念のためマスターとして保存。1TBのポータブルHDDを買ってきて、これはMBPのTimeMachine用HDDを復元して新しいTimeMachine用HDDとする。旧TimeMachine用ディスクにApple Lossless取り込み済みHDDを復元して、圧縮作業用とする。

作業用に新規にユーザアカウントを作成した。これでログインしてiTunesの初期設定でiTunes Mediaフォルダの場所を作業用のポータブルHDDに変更。まだライブラリには何も登録されていないので、ファイルメニューのライブラリに追加でポータブルHDDのiTunes Mediaフォルダを指定し、ライブラリへの登録作業が終わるの待つ。

iTunes-LAMEをインストールする。オリジナルのアーカイブからインストールしてもいいのだけど、不精していつもの自分のユーザーアカウントで使っているiTunes-LAMEを作業用ユーザーのパブリックフォルダにコピーしておき、これを作業用ユーザーのライブラリ:iTunes:Scriptsフォルダへ移動する。Scriptsフォルダは自分で作成。Lion以降では自分のアカウントのライブラリフォルダは不可視なので、Finderでoptionキーを押しながら移動メニューをプルダウンして「ライブラリ」を選択する。

以前の記事にも書いたとおり、iTunes-LAMEをcontrolキーを押しながらクリックして、コンテキストメニューから「パッケージの内容を表示」とする。Contents:Resources:Import with LAME....scptのエイリアスを作り、iTunes-LAMEがあるScriptフォルダへ置く。

これでiTunesにアップルスクリプトメニューが現れるはずなのだが、出てこなかった。理由はよくわからないが、Yosemiteでエイリアスを作ると、エイリアスのファイルサイズが数十〜数百KBとすごく大きくなっている。以前は数KB程度だったので、エイリアスの内部形式がいつの頃からかわからないが変わってきているようだ。そのせいでiTunesがスクリプトファイルのエイリアスをちゃんと認識しないのではないかと思う。

いつも使っている自分の環境でスクリプトファイルのエイリアスを作りなおしたらiTunesにアップルスクリプトメニューが出なくなってしまったので、やっぱりYosemiteのエイリアスは昔のものとは違うらしい（ひょっとしたらLionとかMavericksあたりから変わっていたのかもしれないが、分からない）。

次のいずれかの方法でアップルスクリプトメニューが表示されることが分かった。

• Import with LAME....scptのショートカットではなく、ファイルそのものをScriptsへコピーする
• Import with LAME....scptのショートカットではなくて、シンボリックリンクをScriptsへ作成する

今回は複数ユーザーでiTunes-LAMEを使うために、各ユーザーのライブラリ:iTunes:Scriptsにインストールするのではなくて、起動ディスクのルートにあるライブラリの下にインストールすることにした。ライブラリの中にはiTunesというフォルダがあるが、Scriptsフォルダが多分存在しないので、まずこれを作成する。次にiTune-LAMEをScriptsフォルダへコピー。うちのマシンのiTunes-LAMEにはSSE最適化版LAMEを入れてあるので、ダウンロードしてあるアーカイブからではなくてもともと使っていたiTunes-LAMEをコピーする。

次に、シンボリックリンクを作るのはターミナルで行う。ターミナルを起動し、次の操作を行う。
1. カレントディレクトリをライブラリ:iTunes:Scriptsフォルダへ移動

cd /Library/iTunes/Scripts

2. シンボリックリンクの作成

sudo ln -s iTunes-LAME.app/Contents/Resources/Import\ with\ LAME....scpt Import\ with\ LAME....scpt

パスの中に空白文字がある時は「\ 」に置き換えるのが注意するところ。

iTunes-LAMEのインストール先が各ユーザーのライブラリ:iTunes:Scriptsの場合は、Finderではoptionキーを押しながら移動メニューから「ライブラリ」を選んでiTunesフォルダを開いてScriptsフォルダを作成、iTunes-LAMEをコピーする。ターミナルの操作では、1.のディレクトリの移動を

cd ~Library/iTunes/Scripts

とすればいい。2.の方は相対パスでの操作なので変更の必要はない。

iTunes-LAMEで曲を取り込むと、変な場所にファイルができるようになった。

具体的な場所は、/Volumesという隠しフォルダの下に、以前の起動ディスクの名前のフォルダが作成され、/Volumes/ディスク名/Users/アカウント名/Music/iTunes/iTunes Musicという階層の中に、変換した曲がアーティスト名のフォルダごとに保存されている。

/Volumesはマウントポイントと言って、MacOS Xではマウントされるディスクは全てこのフォルダの中にサブディレクトリとして現れる。
上に書いたファイルが置かれるフォルダは、少し古いiTunesの保存フォルダ。

こういう症状が起きた原因は、起動ディスクを変えた後もiTunes-LAMEが古いディスクのiTunes Mediaフォルダへのパスをずっと覚えていたせい。不思議なのは、変な場所にファイルを作るくせに、正しい場所にもファイルがコピーされていて、ちゃんとiTunesから認識できていたこと。

自分のアカウントのライブラリフォルダ内のPreferences/com.blacktree.itunes-lame.plistを削除してiTunes-LAMEを初期化すれば次からは多分正常に動くと思う。
今回はcom.blacktree.itunes-lame.plistをXcodeに入っているProperty List Editorで開き、destinationの中の文字列を今のiTunes Mediaフォルダに書き換えた。

lame 3.99.1 Altivec/SSE最適化版(とrarewaresからダウンロードしたもの)でいろいろな環境での速度を比較した。

全て同一の音源(サンプルレート44.1kHzのaiffファイル)、lameのオプションは-V5で、速度はplay/CPUの値とした。Ubuntuのみ3.98.4(もちろん通常版)。
CPUの処理効率の目安として、Play/CPUの値をクロック周波数で割った値も記した。MacBook AirとMacBook Proはすべて64bit版のバイナリでの比較。

                                                                      Play/CPU         [Play/CPU]/クロック
コンピュータ                CPU        クロック GHz  OS               最適化版 通常版  最適化版   通常版
Apple MacBook Air 11"(2011) Core i7    1.8(2.9)      OS X 10.7.2      64.4             35.9(22.3)
                                                     Win 7 SP1        61.8     51.5    34.3(21.3) 28.6(17.8)
Apple MacBook Pro 13"(2009) Core2Duo   2.26          OS X 10.7.2      39.1     29.2    17.3       12.9
Toshiba Satellite K31       Celeron    2.16          Win XP SP3       32.7     27.3    15.2       12.7
Dell Vostro 200             Core2Duo   1.8           Win XP SP3       27.2     21.7    15.1       12.1
HP dc5100 SFF PM215AV       Pentium 4  3.2           Win XP SP3       24.9     20.0     7.8        6.3
Dell Optiplex GX620         Pentium D  2.8           Win XP SP3       21.6     18.0     7.7        6.4
HP nx6120                   Celeron    1.4           Win XP SP3       17.4     15.7    12.4       11.2
NEC LaVie LL700/6           Celeron    1.8           Ubuntu 11.10               9.6                5.3
Toshiba Dynabook SS2010     Pentium 3M 0.863         Win XP SP3                 8.0                4.4
Apple PowerMac G3 266DT     PowecPC G4 0.5           Mac OS X 10.4.11  6.4             12.9

Core i7はTurboBoostが効いていると考え(実クロックは未確認)、最高クロックで割った数字を括弧内に記した。それでもCore2Duo以上の効率なのはさすが。

東芝Sattelite K31のCeleronはCore系のコアなので、lameの変換速度がクロック数の割に速い。これが実際の操作感に反映されているかというと微妙なところで、変換速度で2/3のDell Optiplex GX620の方が通常のWindowsの反応としては速い。デュアルコアであることやFSBやプロセッサのキャッシュ構成なんかが効いているのだろうけど。

東芝Dynabook S2010はMobile Pentium IIIなのだが、SSE最適化版は起動しなかった(エラーで終了)。Pentium III MもSSEは持っているのだが、SSE最適化版はSSE2を要求するので動作しない。

クロック周波数あたりの速度を見ると、Pentium系の数値がダントツで低いのがわかる。PowerPCはやっぱり効率のいいCPUだったんだな〜とも思う。

という記事を用意していたら、11/18に3.99.2がリリースされていた。Altivec/SSE最適化版もRarewaresのも即日更新されている。

Altivec/SSE最適化lameのページに表題のものが掲載されていたので早速ダウンロードしてみた。

例によって速度を比べてみる。今回の音源は前回のものとは違う。オプションは-V5のみ指定。

MacBook Pro 13"(2009), Core2Duo 2.26GHz, OS X 10.7.2
lame      play/CPU  kbps
3.98.4(32) 28.143   129.9
3.99(32)   32.772   124.2
3.99(64)   38.142   124.2
3.99.1(64) 38.735   124.2
3.99(64)   29.176   124.0  rarewaresからダウンロードしたもの

MacBook Proではrarewaresから落とした普通の3.99（64bit版）を走らせてみた。SSE最適化版はrarewaresにアップされているものの1.3倍の速度となった。

PowerPC版はおよそ6.5倍前後。全てAltivec最適化版。

LaVieのUbuntuで試した3.98.4は9.6倍の速度。

今回はAltivec/SSE最適化版のMac OS Xバイナリに加えて、Windows用のlame-3.99.1-win-20111106.zipというファイルもあった。解凍すると32bit版と64bit版の2種類が入っている。後でPentium Dのマシンで走らせてみよう。

LionとiTunes-LAMEの組み合わせでCDを取り込めないというコメントを頂いたので、少し試してみた。環境はOS X 10.7.2 Lion, iTunes 10.5.1, iTunes-LAME 2.0.9.34, Altivec/SSE最適化LAME 3.99 20111030版。iTunes-LAMEの中にあるlameを最適化版LAMEに置き換えてある。ハードウエアはMacBok Pro 13"(2009), Core2Duo 2.26GHz, RAM 4GB, HDD 320GB。

すぐ取り出せるところにあった2枚のCDを使用
CDDBによるタイトル 結果
マクロスF O.S.T.1 娘フロ。 取り込み可能
炎神戦隊ゴーオンジャー サウンドグランプリ 2nd ソングコレクション 取り込み不可能

マクロスフロンティアの方はiTunes-LAMEの設定でCDをハードディスクにキャッシュするというチェックをつけると普通のスピードで読み込むことができたが、チェックを外すと取り込みスピードがかなり遅くなった。どちらも変換した結果は同一で、問題はなかった。

ゴーオンジャーの方はかなりだめで、CDをハードディスクにキャッシュするというチェックをつけた状態ではiTunes-LAMEがクラッシュしてしまった。

ただし、iTunes-LAMEで直接読み込めないCDでも、次の手順で取り込むことができた。

1. iTunesでAIFF形式で取り込む
2. 取り込んだCDの曲でプレイリストを作成
3. 作成したプレイリストからiTunes-LAMEでmp3に変換
4. AIFF形式のファイルと変換用プレイリスト（不要ならば）を削除

この方法ならiTunesのCDのエラー訂正機能が有効だと思うので、直接iTunes-LAMEで取り込むよりいいかも知れない。

実は1年前に、Mac OS X 10.6.5(64bit起動) + iTunes 10.1 + iTune-LAME 2.0.9.34 + Altivec最適化LAME 3.98.4の組み合わせでも試してみていて、ほぼ同様の結果になっていた。エラーメッセージは少し違うようだが。なお、Mac OS X 10.4.11 + iTunes 9.2.1だとこのゴーオンジャーのCDも取り込める。

おそらくCDのタイトルが長すぎるのが原因ではないかと思う。今回取り込めなかったCDのタイトル名は全角で32文字+半角1文字となっている。そこで、色々な長さのタイトルのAudio CDを作って、iTunes-LAMEで読み込めるか試してみた。

タイトル文字数：読み込み結果
　　全角27文字：読み込み可能
　　全角28文字：読み込み不可能
　　半角80文字：読み込み可能
　　半角81文字：読み込み不可能

以上からできる推測は、iTunes 10.xはCDのタイトルをUnicodeで扱っているらしいということ。全角で27文字だと、一文字3バイトとして81バイト。これなら半角で81文字まで行けそうなんだけど、私がどこか数え間違っているか考えが間違っている可能性もあるけど、だいたい合っているのでよしとしよう（いいのか? ^^;）　テスト用のCDのタイトルの文字数を数え間違った可能性が一番高いけど。

式で書けば、CDのタイトルの文字が以下の条件ならiTunes 10.x + iTunes-LAMEの組み合わせで直接取り込むことができる。
　　[全角文字数]×3 + [半角文字数] <= 80

iTunes 9.xでちょっとだけ試したら半角161文字でも取り込むことができたので、iTunes-LAMEがAppleScriptでやり取りするのに使っているCDタイトル用の記憶サイズが10.xでかなり小さくなってしまったようだ。

話は変わって、Altivec/SSE最適化LAME 3.99 20111030版はついに64bitのバイナリも同梱された。今までは64bit版のパフォーマンスが出ていなかった、ということなのかな？　ともあれ、今回は64bt版が最速とのこと。
同じaiffファイルを20111021版の32bitバイナリと変換速度を比べてみたら、-V5オプションの時に34倍速→39倍速、-V4オプションの時に31倍速→37倍速となった。

lame 3.99がリリースされた。
Mac用のバイナリはLAME binary for Mac OS X(AltiVec最適化LAMEのページ)からダウンロードできる。

音質は聞き比べていないのでコメントできないが、処理速度とビットレートを3.98.4と3.99で比べてみた。

マシンはMacBook Pro 13" 2009年モデル、Core2Duo 2.26GHz RAM 4GB。OS X 10.7.2。3分半ほどのaiffファイル(サンプルレート44.1kHz)を-V5オプションで処理した時のplay/CPUの値を速度の目安とする。AltiVec最適化LAMEの各バージョン(3.99は細かく更新されている)とRarewareから落とした64bit版3.98.4の比較。LRはステレオ音声の扱い。高音質設定だとMSよりもLRの方が多くなる。

lameのバージョン  play/CPU  kbps   LR
3.99 20111021版   33.397x   129.0  18.3
3.99 20111020版   32.953x   129.0  18.3
3.99 20111016版   29.896x   129.1  18.3
3.98.4            27.632x   140.8  14.9
3.98.4 64bit      26.223x   140.8  14.9  Rarewaresから落としたもの

Windows XPで別のaiffデータを処理した結果が次。バイナリはRarewaresからダウンロード。マシンはPentium D 2.8GHz, RAM 4GB。音源ファイルはMacとは別。
lameのバージョン  play/CPU  kbps   LR
3.99              19.239x   127.3  62.0
3.98.4            23.618x   123.5  39.9

こちらは3.99の方が遅く、ビットレートが3.98.4よりも高い。

Macでの結果では3.99は3.98.4よりもビットレートが下がっているが、3.98.4が3.97よりはレートが高めなので、元に戻ったような印象。ただ、Windowsの結果では3.99の方がレートが高くなったので、データ次第なのかも知れない。

iTunes10のエントリーへのコメントで、iTunes 10.1にしたらCDから取り込めなくなったという方がいたので、自分でも試してみた。

我が家の環境はMacBook Pro 13" 2009 Mid, Mac OS X 10.6.5, iTunes 10.1, iTunes-LAME 2.0.9(34), lame 3.98.4。

結果として、正常に取り込めるものと取り込めないものがあった。3枚しか試していないのだけど (^^;)

取り込みができたCD
マクロスＦ O.S.T.1 娘フロ。
かなり昔に車用に焼いたCD-DA形式のCD-R、MacBook Proではタイトルデータがなく曲名/アルバム名が表示されない物

取り込みできなかったCD
炎神戦隊ゴーオンジャー オリジナルアルバム サウンドグランプリ2nd ソングコレクション

取り込みできないものは

Import Error
NSInvalidArgumentException
working directory doesn't exist.

というエラーが表示されてハングアップする。
iTunes-LAMEの初期設定で、CDをハードディスクにキャッシュしてからエンコードする設定にすると、エラーも表示されずにハングアップする。

コンソールでiTunes-LAMEのエラー出力を見ると、

10/11/14 5:19:27    iTunes-LAME[537]    No tracks found. These volumes are available:(
    "Macintosh HD",
    "\U708e\U795e\U6226\U968a\U30b3\U3099\U30fc\U30aa\U30f3\U30b7\U3099\U30e3\U30fc \U30aa\U30ea\U30b7\U3099\U30ca\U30eb\U30a2\U30eb\U30cf\U3099\U30e0 \U30b5\U30a6\U30f3\U30c8\U3099\U30af\U3099\U30e9\U30f3\U30d5\U309a\U30ea2nd \U30bd\U30f3\U30af\U3099\U30b3\U30ec\U30af\U30b7\U30e7\U30f3"
) tried theseFiles: (null)
10/11/14 5:19:27    iTunes-LAME[537]    Track "(null)" supposedly does not exist, using shell completion to match.

と表示されている。

CDのトラックの取得に失敗しているらしい。気になるのは、「ゴ」を「コ゛」と取得しているのだけど、これはUnicodeの仕様なのかなあ?

とりあえずの対策としては、iTunes-LAMEの使用を諦めるか (^^;)、CDの内容をFinderでハードディスクにコピーしてからiTunesのライブラリに取り込めばiTunes-LAMEでもmp3に変換できる。トラック名以外の情報が落ちてしまうけど。

原因が10.6.5アップデートにあるのか、iTunes 10.1にあるのかわからないのだけど・・・。

実は最近はCDの取り込みは行っていなくて(つまりCDは買っていない ^^;)、NHK-FMのセッション2010取り込みみばかり行っているので、いつからCDを読めなくなっているのかわからない。

lameでは--lowpass 15などと書くことで、ローパスフィルターの周波数を明示的に指定できる。いつもは-Vnオプションで指定した条件でのデフォルト設定値にお任せだったのだけど、FM放送を16bit 44.1kHzのリニアPCMで録音したデータを圧縮するときに、15 kHz以上を切りたいと思ったのでローパスフィルターをいくつか指定して試してみた。

その結果わかったのが、-V4 -lowpass 15とすると、32kHzのサンプリング周波数にリサンプルされるということ。そりゃたしかに15kHz以上がいらないからローパスフィルターを低く指定したのだけど、リサンプルまでするとは思わなかった (^^;)

-V5オプションで-slowpassを指定しないとローパスフィルターは16.5kHzとなる。他に15.5, 15, 14.5を指定した時のスペクトルを示す。音源はNHK-FMを録音したもの。

元のPCMだと19kHzのパイロット信号も見える。FM放送なので15 kHz以上がないのは当然なのだけど、15.3kHzあたりのピークはなんだろう?　実は1984年頃にカセットテープに録音した音を取り込んだデータを見ても同じピークが見えたので(もちろん今使っているチューナーとは全く別のもの)、FM放送特有のものなのだろうか?　これについては別ブログの記事にした。このスペクトルはNHK-FMを録音したもの。

この15.3kHzのピークも切ろうとすると、ローパスフィルターの指定は14.5あたりが最適値のように思える。15.3kHzまで入れようとすると、今回のデータにはないけど16 kHzの設定がよさそう。

lame 3.98.4で動作確認した。スペクトル作成はAudacity 1.3.12。

今週はFirefoxとLameのアップデートがあった。

Firefoxは3.6.2になった。3.6で導入された新しいフォント関係の機能に関する重大な修正があったらしい。

Lameは3.98.4がリリースされた。3.98.3が出たばかりだったけど、3.98.3で何か大きな問題があったのかな?