現在メイン執筆環境のMac miniですが、適当な置き場所がなく、やむなくMacBook Pro用のアルミスタンドに載せて使っています。同じアルミですからさほど違和感はありませんが、イケてませんねえ……というわけで、Mac miniの収納スタンドを物色中です。
さて、今回は「Apple Lossless(ALAC)」について。ALACはApple製品向けロスレスコーデックとしてのポジションを脱し、Apache Licenseのもとオープンソースプロダクトとしての歩みを始めたばかりだが、iPod/iPhoneという高い競争力を持つ製品との親和性の高さもあり、活用場面の増加が見込まれている。そのALACを、いくつかの角度から観察してみよう。
ALACの必要性
まず、どのような意図でAppleがALAC(プロジェクトサイト)をオープンソース化したかを推理してみたい。いまやオーディオ&ビジュアルの分野にも存在感を示すAppleだけに、従来プロプライエタリな技術だった(リバースエンジニアリングされてはいたが)ものを思いつきで公開するとは考えにくいからだ。
ひとつは、今後のデジタルオーディオでハイレゾ音源の比重が増す可能性が高いことだ。初代iPodのデビュー当時、MP3/128kbps程度が一般的だった圧縮オーディオは、その後より圧縮効率に優れるAACが主流となった。iTunes Storeで販売される楽曲のビットレートも、かつてはAAC/128kbpsが大半だったが、米国ではAAC/256kbps(iTunes Plus)に切り替えられている。突如シフトすることはないにせよ、長期トレンドとしてよりリッチなALACが指向されることは想像に難くない。
|
iTunes 10のデフォルトでは、CDの読み込み設定に「iTunes Plus」(AAC/256kbps)が割り当てられている |
他のロスレスコーデックとの関係もあるだろう。オーディオファン向けに高音質楽曲を販売するサイトは、非圧縮音源（*.WAVや*.AIFFなど）と同じクオリティでありながらよりコンパクトなロスレスコーデックを扱っており、採用事例という点ではFLACやWMA Losslessにリードを許している。AVアンプなど高級オーディオ機器も似た状況で、ALACは明らかに後発組だ。ありがちな手法だが、オープンソース化はこの問題の有効な解決策となる。
Appleの音楽に対する姿勢も影響していそうだ。米国のiTunes StoreではDRMを撤廃していることからもわかるように、彼らは音楽の「入れもの」に対する囲い込みを排除する方針で一貫している。リバースエンジニアリングによる外部のALACサポートを事実上黙認していたことからも、ALACオープン化は時間の問題だったのかもしれない。
一方、iTunes Matchではロスレスコーデックをサポートしないのでは? という声が聞こえてきそうだが、少なくとも現状(AAC/256kbps)より低品質になるとは考えにくい。むしろ通信環境の改善等により、将来的には音質向上が図られる可能性もある。となると、行き着く先はロスレスコーデックしかないように思えるのだが……。
|
ALACでエンコードした楽曲は、Apple製品を利用するかぎり、AACやMP3と取り扱いに違いはない |
念のため「afconvert」と比較する
ALACのオープンソース化は、オーディオ機器に関心のないOS Xユーザにとって、特別なメリットをもたらさない。iTunesにはALACのエンコーダ/デコーダが装備されているし、afconvertというフォーマット変換用コマンドも用意されている。新たにオーディオ機器でも購入しないかぎり、なにも変わることはないだろう。
むしろ気になるのは、配布されたソースコードがOS X内蔵のALAC実装と完全に同一かどうか。ロスレスコーデックなのだから、完全にOSから独立しているのであれば、どちらの環境で再生(デコード)してもデータサイズが完全に一致するはず。エンコードにしても然りで、WAVEなどのソースからまったく同じサイズのALACファイルが得られるはずだ。
まずは配布されたソースコードの入手から。以下のとおりTerminalでコマンドラインを実行すると、ソースコードのダウンロードとビルドが行われ、「alacconvert」を得ることができる。このコマンドはその名のとおり、WAVE→ALAC(*.CAF)コンバータとして機能する。
$ svn checkout http://svn.macosforge.org/repository/alac/trunk ALAC
$ cd ALAC
$ cd convert-utility
$ make
ALACの生成は、alacconvertとafconvertそれぞれで行う。ここでは前者の生成物を「opensource.caf」、後者の生成物を「afconvert.caf」というファイルに出力している。
$ alacconvert sample.wav opensource.caf
$ afconvert -f caff -d alac sample.wav afconvert.caf
結論から言うと、両者が生成するデータは同一のものだ。出力されたファイルサイズが若干異なったため、バイナリエディタ「HexEdit」で調べたところ、ヘッダー部分には多少の違いが確認できた。afconvertの場合、再生時間等の情報を加えるため、alacconvertのそれよりヘッダーが肥大するのだ。
今回のテストの場合、afconvertの生成物の&H000001FF0以降と、alacconvertの生成物の&H000014C5以降のデータがほぼ一致していると目視できたため、それより前の部分を取り除いたうえでバイナリを比較してみると、データは完全に一致した。今回はどちらもOS Xで生成したが、データの一致は両者のアルゴリズムが完全に同じということなのだから、Linuxなど他の環境で生成してもまったく同じ結果が得られると推測できる。
|
バイナリエディタ「HexEdit」で2つのALACを比較したところ。ヘッダー部を取り除いたデータは完全に一致した |
いささか疑い深いようだが、オーディオファンにとってこの辺りの検証作業は重要な意味がある。ともあれ、素性の確かさが証明できたALACは、Apple製品以外でも長く付き合えるサウンドフォーマットと信頼してよさそうだ。
