最終更新:2010-12-14 (火) 04:33:02 (3264d)  

いまさらながらMP3のギャップレス処理を復習 はてなブックマークを見る
Top / いまさらながらMP3のギャップレス処理を復習

http://nyaochi.sakura.ne.jp/archives/2006/09/25/いまさらながらmp3のギャップレス処理を復習

2006 9 25

いまさらながらMP3のギャップレス処理を復習

新iPodでギャップレス再生が盛り上がったついでに,MP3におけるギャップレス処理をまとめてみようと思います.まず,MP3がギャップレス再生を苦手とする理由を4つ挙げて説明します.

第一に,「MP3はフレーム単位(44.1kHzのサンプル周波数なら1152サンプル = 0.0261秒)でデコードを行う」点です.言い換えると,MP3ストリームは1152サンプル(0.0261秒)の整数倍の曲長しかとり得ないことを意味します.具体例として,サンプル周波数44.1kHzの1秒のMP3ストリームを作ることを考えましょう.必要なMP3フレーム数を計算すると,44100 / 1152 = 38.3 になり,小数点は切り上げるしかないので,39フレームということになります.このとき,39フレームでMP3ファイルを作ると,デコード後の曲長は 39 * 1152 / 44100 = 1.02 [秒] になってしまい,正確に1秒のMP3ファイルは作れません.つまり,ファイル末尾に約0.02秒の無音部分が付いてしまいますので,完全ギャップレス再生への障壁になります.

この末尾に付加された余計なサンプルのことを,パッディングと呼びます.ギャップレス再生を行うためには,何らかの方法でパディング・サンプル数をデコーダーに伝え,ストリームの末尾をその長さだけ捨ててもらう必要があります.

次に,実装にもよりますが,たいていのMP3エンコーダはストリームの先頭に無音部分を付加しており,これをエンコーダ・ディレイと呼びます.曲の先頭に無音部分が付いてしまうと,完全ギャップレス再生はできなくなります.この問題が厄介なのは,エンコーダーの実装によって遅延サンプル数が異なることです.例えば,LAMEは576サンプル遅れるのに対し,iTunes7は528サンプルの遅れであることが分かっています.少々古い情報ですが,こちらのページに,各MP3エンコーダのディレイ値が載っています.

ギャップレス再生を行うためには,エンコーダは自分が発生させるディレイ・サンプル数を,何らかの方法でデコーダーに伝え,ストリームの先頭をその長さだけ捨ててもらう必要があります.

さらに,MP3のデコーダーもストリームの先頭に無音部分を追加してしまいます.これをデコーダー・ディレイと呼びます.ギャップレス再生を行うためには,デコーダーは自分が発生させるディレイ・サンプル数を認識し,ストリームの先頭をその長さだけ捨てなければなりません.

最後に,難しい理屈なのですがMDCTのオーバーラップ処理も絡んできます.MP3にはMDCTという変換処理が組み込まれていますが,この処理はフレームの独立性を確保できないため,i番目のフレームをデコードするためには,(i-1)番目のデコード結果が必要になってしまいます.仮に,(i-1)番目のフレームがトラック1に属していて,i番目のフレームがトラック2に属しているとしましょう.トラック2の先頭フレームであるi番目のフレームを正確にデコードするためには,(i-1)番目のフレームのデコード結果を保持しておかなければなりません.しかしながら,通常MP3のデコーダはトラックが変わった時点で内部状態をクリアしてしまうので,トラック2の先頭フレームのPCMデータは,不完全なものとなってしまいます.

さて,ギャップレス再生を実現する2つの方式をまとめてみましょう.

まず第1の方式,「個々のトラックをエンコードするときに,ストリームの長さ・ディレイの情報を付加する」方法 (LAMEのMP3-Infoタグ,iTunes 7) です.上で挙げた問題点を克服するため,MP3ストリームにメタ・データを付加して,エンコーダー・パッディング,エンコーダー・ディレイの情報をデコーダー側に伝えます.使用されるメタデータ領域は,LAMEは先頭のMP3フレームの中にあるMP3-Infoと呼ばれる領域,iTunes 7はID3v2のCOMMENTフレームです.MP3のデコーダーに要求されることは,これらのメタ・データをきちんと認識し,自分のデコーダー・ディレイと合わせて先頭・末尾の不要サンプルを除去することです.

MP3のギャップレス再生といえば,この方法が現在主流です.唯一の弱点は,前のトラックの末尾で急激に音が切れ,次のトラックの先頭では急激に立ち上がる場合,トラックの境界部分でアーティファクトが発生することがあることです.

第2の方式は,「CD全体をひとつの大きなMP3ファイルにエンコードして分割する」方式 (LAMEの–nogap) です.LAMEの–nogapオプションは,厳密に言えばこの通りの動作をする訳ではありませんが,理屈は「全体をMP3にエンコードしてトラックごとにファイル分割する」と考えれば分かりやすいです.この方式は,もともと BladeEnc で実装されたものです.MP3がギャップレス再生を苦手とする理屈を理解できなくても,「全体をひとつのMP3ファイルにエンコードして再生しているのと等価」ということであれば,ギャップレス再生が可能なことは理解できると思います.

ただし,ファイル分割を行うときは,前述のように1152サンプル単位しか行えませんので,各トラックの長さを適当に調整し,近傍のフレーム境界に合わせます.MP3のデコーダーに要求されることは,前のトラックの末尾のフレームをデコードした後,内部状態をリセットせずに次のトラックの先頭フレームを処理することになります.つまり,あたかも1つの大きなMP3ストリームであるかのようにデコードすることが要求されます.弱点は,各トラックの長さを正確に保持することができない点であり,汎用性に欠けるため,この方式は少数派になりつつあります.一部のハードウェア・プレイヤーは,トラックの切り替わりでMP3のデコーダをクリアしないため,この方式でのギャップレス再生が可能になっていますが,もはや過去のものになりつつあるので,今後は使わない方がよいと思います.

関連