航海日誌 Starlog

BitPerfectという名前のiTunes/ミュージック用のアプリケーションを使っている。こいつの動作はその名前とはちょっと違って（？）、iTunes/ミュージックの出力を指定したビットレート・サンプリング周波数で出力する。音源のサンプリング周波数の2のべき乗でアップサンプリングするために使っている。自分のiTunesには48 kHzや44.1 kHzだけではなくて、32 kHzの音源も入っていて、USB DACが対応しているならきちんと整数倍のサンプリング周波数で出力したい。

MBP13/2009はCore2Duoとかなり性能が低いせいか、あるいは2009年製造とかなり古くて老朽化しているせいか、BitPerfectの設定によってはUSB DACから出る音が割れたりノイズまみれになってしまう。FX-01J TYPE-Aだと音が割れる、U-44だと数分間聞いているとだんだんノイズまみれになる（音が細切れになる？）という感じになる。

FX-01J TYPE-Aではアップサンプリングと最大サンプルレートを96 kHz、最大ビット数16 bitで音が割れなくなった。FX-01J TYPE-Aそのものは96 kHz/24 bitまで対応していたはず。

U-44では同じ設定でもどうやらだめなようで、サンプルレートやビット数にかかわらずディザがTriangular High Pass Ditherだとノイズが出てくることがわかった。CoreAudio (Noise Shaped Dither)では96 kHz、最大ビット数24 bitで使えている。

FX-01J TYPE-AはMBP 15/2017へ持っていったら問題なく使えるようになったためMBP 13/2009でテストはしていないが、ひょっとしたらこっちもディザの設定を変えたら24 bitで動作したのだろうか。24 bitなんてビット長が活きるようないい環境でもいい音源でもないのでわざわざテストしようとは思わないけど。

2023/9/2追記

その後、上記の設定でも音が割れるようになってしまった。音源のファイルにも依存している気もする。さらに設定をいじって、次の設定で安定している。

General
　Integerモード：オフ
　バッファーサイズ：256 MB

Sound
　SRC：SoX 14.3.2 VHQ Intermediate
　アップサンプリング：96.0 kHz
　2のべき乗（2x / 4x）でアップサンプリング
　ディザ：CoreAudio (Noise Shaped Dither)
　最大サンプルレート：96.0 kHz
　最大ビット数：24
　デバイスバッファサイズを最大に：オン　←　以前はこれにチェックを入れていなかった。これが勝利の鍵？
　極性の反転をデフォルトに：オフ
　ギャップレス再生を無効に：オフ

iTunes
　iTunesとのやり取りを最小化：オン
　固定インデックスをデフォルトに：オフ
　iTunesのAirPlayデバイス使用を停止：オン
　音量を自動調整 を有効にする：オン

普段はこの手のエフェクトはオフで使っているのだが、NAGAOKAの安価なBluetoothイヤホンの音があまりにしょぼかったのでiTunesのサウンドエンハンサーを使ってみた。最小から一目盛り右のところでちょうどいい感じ。本来の使い方とは違う気もするが、そのままでは音のアラが目立つ感じだったのがいい感じで聞けるようになった。

NAGAOKA BT807という安価なBluetoothイヤホンを使っているときの問題。

iTunesで再生しているとき、曲の出だしでデータが1回だけ0.5秒程度の音飛びが発生することがある。別のBluetoothレシーバで接続するときはそんなことはなく、この機種でのみ発生する。AAC接続。Audio MIDI設定で設定を見ると32ビット浮動小数点48kHz。Audio MIDI設定で様子を見てからiTunesを使ったら、なぜか音飛びが減った。全くなくなったわけではない。

Audacityで再生すると、プツプツと音が途切れる。常時そうなると言ってもいいくらいで、こちらはAudio MIDI設定を触ってからも変化はない。

SBCで接続したら変わるかと思ったのだが、Bluetooth ExplorerでDisable AACにチェックしたらMacと接続できなくなった。Enable AACにチェックを入れたら元通り接続できた。

iTunes 12になってから、曲リストのスクロールが遅い。正確には、スクロール操作を始めてから、スクロールが始まるまでが遅い。その後の追従性はそこそこ良好。

環境はiTunes 12.0.1/OS X 10.10.1 Yosemite/MacBook Pro 13" 2009(Core2Duo 2.26GHz/8GB/SSHD500GB)

マシンが非力なのは承知の上なのだけど、iTunes 11はここまで遅くなかったよなあと思いつつ、iTunesの環境設定をいじってみた。

一般設定/表示の設定：開いているアルバムやムービーなどにカスタムカラーを使用
一般設定/通知：曲が変更されたとき

以上の2つのチェックを外したら割と軽くなった。それでもまだ重い感じはするけど。

5年も使ったMacBook Pro、そろそろ最新の環境には追いつけなくなりつつあるようだ・・・。

2/1追記

iTunes 12.1になったら以前よりスムーズに動くようになった。それから、曲の情報の編集画面が11以前のようになっていてよかった。12.0のものは使いにくかったな。

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.の方は相対パスでの操作なので変更の必要はない。

手持ちの約500枚のCDのほとんどはMP3でiTunesnに取り込んであるのだが、やはりMP3なので音質が良くないこと、CDの取り込みは音質の悪さに定評のある昔のiTunes（使ったのはiTunes 2.0）のMP3エンコーダなので尚一層音質が良くないこと、取り込んだ当時(10年以上前)はディスクの容量も小さくて全部取り込んでいないCDがあること、といった理由でバックアップとしては完全とは言い難い。

CDの寿命も気になるし、うちの光学ドライブのヘタリ具合や故障の具合を考えると、ハードディスクに完全コピーをとっておいたほうがいいんじゃないかと思うようになった。ちょうど320GBのHDDが余ったので、これをFirewire 400のポートのあるケースに入れ、ベージュG3に接続した。

手持ちのCDは500枚以上600枚以下（多分）。平均して60分の収録時間とすると、1枚あたりのデータとしては60[分]×60[秒]×44100[サンプリング周波数]×16[bit]×2[ch] = 5080320000[bits] = 607[MB]の容量になる。Apple Losslessフォーマットでエンコードすると、だいたい半分ぐらいのサイズになるらしいので、CD 1枚あたり300MBを見込んでおく。320GB(298GB)のHDDだと、約1000枚を保存できる計算になる。

実際にApple Losslessで読み込むと、500MHzのG4のベージュG3では5〜10倍の変換速度となる。LAMEだと1.5〜2倍ぐらいだが。LAMEで25倍前後の変換速度になるMacBook Proの方で読み込めたら70〜140倍の変換速度になるかもしれないけど、光学ドライブがCDで48倍速ぐらいなのでそこが限界だろうし、我が家のMBPは光学ドライブのイジェクト機構が故障してディスクが入らなくなっているので使えない・・・。

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フォルダに書き換えた。

iTunesのバージョンが11になった。バージョンアップのたびに気になるのがiTunes LAMEが使えるかということ。

今までどおりにスクリプトメニューにiTunes LAMEはある。

早速AIFFファイルをiTunes LAMEでMP3に変換し、無事に取り込まれていることを確認した。これで一安心。

MacBook Proに入っているiTunesのライブラリに、音楽データファイル本体が外部ディスクにあることになっている曲がいくつもあることに気づいた。

元々はベージュPowerMac G3の外付けディスクに入っていたライブラリをMacBook Proにつないで取り込んだもので、この外付けディスクがファイルコピー中に突然止まることが何度かあってちゃんとコピーできなかったものがいくつかあった模様。

MacBook ProにベージュG3の古いiTunesライブラリの入った外付けHDDをつなぎ、iTunesのファイルメニュー/ライブラリ/ライブラリを整理で「ファイルを統合」と「整理しなおす」の両方にチェックを付けて実行したらすべての曲がMacBook Proにコピーされてきたようだ。

ベージュG3の方は、古いiTunesライブラリの入ったディスクの動作が怪しいので、別の外付けHDDにライブラリをコピーし、今は新しい方を使っている。しかし、コピーした時にMacBook Proの時と同じようにディスクが何度も止まったので、こちらもコピーしきれていないものがいくつもあるはず・・・というか、気がついたものは手動でコピーしなおしていたのだが、17700曲もあると見落としが山のようにあったようだ (^_^;)　こちらもiTunesにライブラリの統合をさせたら、何曲もコピーしていた。

これで古いiTunesライブラリのデータは完全にMBPや新しいHDDにコピーできたはずなので、古い方は削除して大丈夫、かな。

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倍速となった。