最終更新:2010-12-14 (火) 04:33:02 (4880d)
いまさらながらMP3のギャップレス処理を復習
Top / いまさらながらMP3のギャップレス処理を復習
http://nyaochi.sakura.ne.jp/archives/2006/09/25/いまさらながらmp3のギャップレス処理を復習
2006 9 25 いまさらながらMP3のギャップレス処理を復習 新iPodでギャップレス再生が盛り上がったついでに，MP3におけるギャップレス処理をまとめてみようと思います．まず，MP3がギャップレス再生を苦手とする理由を４つ挙げて説明します． 第一に，「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 [秒] になってしまい，正確に１秒の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データは，不完全なものとなってしまいます． さて，ギャップレス再生を実現する２つの方式をまとめてみましょう． まず第１の方式，「個々のトラックをエンコードするときに，ストリームの長さ・ディレイの情報を付加する」方法 (LAMEのMP3-Infoタグ，iTunes 7) です．上で挙げた問題点を克服するため，MP3ストリームにメタ・データを付加して，エンコーダー・パッディング，エンコーダー・ディレイの情報をデコーダー側に伝えます．使用されるメタデータ領域は，LAMEは先頭のMP3フレームの中にあるMP3-Infoと呼ばれる領域，iTunes 7はID3v2のCOMMENTフレームです．MP3のデコーダーに要求されることは，これらのメタ・データをきちんと認識し，自分のデコーダー・ディレイと合わせて先頭・末尾の不要サンプルを除去することです． MP3のギャップレス再生といえば，この方法が現在主流です．唯一の弱点は，前のトラックの末尾で急激に音が切れ，次のトラックの先頭では急激に立ち上がる場合，トラックの境界部分でアーティファクトが発生することがあることです． 第２の方式は，「CD全体をひとつの大きなMP3ファイルにエンコードして分割する」方式 (LAMEの–nogap) です．LAMEの–nogapオプションは，厳密に言えばこの通りの動作をする訳ではありませんが，理屈は「全体をMP3にエンコードしてトラックごとにファイル分割する」と考えれば分かりやすいです．この方式は，もともと BladeEnc で実装されたものです．MP3がギャップレス再生を苦手とする理屈を理解できなくても，「全体をひとつのMP3ファイルにエンコードして再生しているのと等価」ということであれば，ギャップレス再生が可能なことは理解できると思います． ただし，ファイル分割を行うときは，前述のように1152サンプル単位しか行えませんので，各トラックの長さを適当に調整し，近傍のフレーム境界に合わせます．MP3のデコーダーに要求されることは，前のトラックの末尾のフレームをデコードした後，内部状態をリセットせずに次のトラックの先頭フレームを処理することになります．つまり，あたかも１つの大きなMP3ストリームであるかのようにデコードすることが要求されます．弱点は，各トラックの長さを正確に保持することができない点であり，汎用性に欠けるため，この方式は少数派になりつつあります．一部のハードウェア・プレイヤーは，トラックの切り替わりでMP3のデコーダをクリアしないため，この方式でのギャップレス再生が可能になっていますが，もはや過去のものになりつつあるので，今後は使わない方がよいと思います．
