藤本健のDigital Audio Laboratory
第732回
MP3再生のデコーダを変えると音質は変わる? 歴代iTunesやWMPなどを比較
2017年7月31日 13:11
先日「MP3ファイルを作るエンコーダは進化した? 昔と今のiTunesで比較検証」という記事を書いた。その時の結論は、微妙に進化していそうではあるが、極端な違いはなかった、というものだった。この記事を公開した後、読者から「『デコーダ側も進化している可能性』という記述があるが、MP3のデコードアルゴリズムは規格で定められているので、異なる結果を出すデコーダは、デコーダではないことになるのでは」という指摘をいただいた。これは筆者が認識できていなかった点だが、本当にすべてのデコーダで結果は一致するのだろうか? ちょっと気になるところだったので、実際に複数のデコーダで試して検証してみた結果をレポートする。
MP3の特許ライセンス終了で、MP3利用が加速する?
「MP3なんて音質の悪い圧縮システムなんて早くなくなって、全部AACになればいいのに……」、ミュージシャンや制作サイドから、そんな声をよく耳にするが、そうした中、5月に「MP3が終了する」というニュースが流れて話題になった。正確にはMP3が無くなるのではなく、MP3の特許を管理している「Fraunhofer Institute for Integrated Circuits」が特許期限切れを理由にライセンス供給プログラムを終了するというものだった。これを受けて、いくつかのメディアが「MP3が終わる」、「緩やかにMP3が消えていく」といった記事を書いていたが、筆者個人的には逆の動きになるのでは? と思っていた。各種ソフトウェアやハードウェアにMP3のエンコーダやデコーダを組み込むのにライセンス料金がいらなくなるわけだから、かえって利用が加速するのではないか、より一般的になるのではないか? という見方だ。
実際、それに呼応する形でMP3を無償化したメーカーもある。Windows用のDAW、SONARを開発する老舗メーカー、米Cakewalkだ。これまでSONARではMP3のエンコーダはオプション扱いで、$9.99でライセンスをダウンロード購入する形になっていた。しかし、Fraunhoferの発表を受けて、6月5日よりダウンロードプログラムを無償化するとともに、最新のSONARインストーラではあらかじめMP3エンコーダを搭載する形に変わったのだ(インストーラへの搭載は2017年4月より)。今後、これに続く動きが出てくるのかは、まだわからないが、少なくとも、すぐにMP3が衰退に向かうということはないのではないだろうか。
さて、そのMP3を今回また検証するのは、冒頭でも書いた通り、読者の方からの指摘がキッカケだ。これまで、この連載で何度もMP3のデータやエンコーダについて検証してきたが、デコーダがどれも同じであるという認識を持ったことがなかったし、違って当たり前だろうと思っていた。原文を確認しているわけではないが、リファレンスとなるデコーダのソースコードも公開されており(sourceforge、MP3' Tech)、これらをベースにしているソフトが大半なのかもしれない。
これらはあくまでもリファレンスであるし、そもそもアルゴリズムが規定されているだけで「このコードを使え」となっているだけならば、プログラムに工夫の余地はあるはず。そもそも「24bit処理なのか32bit Float処理なので、音が大きく違う」というデジタルオーディオの世界、計算上で下位ビットをどう扱うかだけでも、音質的な差が表れても不思議ではない。
とはいえ、ふたを開けてみたら、すべて同じソースコードを使っていた……なんて可能性も否定できないわけで、こうなったら、やはり試してみるしかないだろう。
3バージョンのiTunesや、WMPなどのデコーダを比較
今回は1つのMP3ファイルを元に、複数のデコーダでデコードした結果を比較してみることにした。まずは、以前の記事でも扱った2005年7月リリースのiTunes 4.9(Windows 32bit版)、2010年1月リリースのiTunes 9.0(Windows 64bit版)、そして、最新版であるiTunes 12.6(Windows 64bit版)のそれぞれ。
方法としては、iTunesでCDからのインポート設定をWAVに設定した上で、MP3からWAVへ変換するというものだ。
バージョンによって微妙に操作方法に違いがあるが、いずれも44.1kHz/16bitのWAVファイルを生成することができたので、さっそく比較してみた。使ったのはefu氏開発のWaveComapare。これを使えば、頭に空白が入っていたとしても、実データ部分を比較して違いを見出してくれるので便利だ。曲は、前回と同じくTINGARAのambient JUPITERから抜き出した約45秒のWAV。
結果は、3つとも一致せず、iTunes 4とiTunes 12またiTunes 9とiTunes 12はまったく違うものであったが、iTunes 9とiTunes 12は、かなり近くなった。2,342,578サンプルのうち相違点が2,843サンプルなので、相違点は約0.1%。つまり99.9%は一致しているので、ほぼ同じ結果といってもよさそうだ。
せっかくならほかのデコーダとも比較してみたかったので、iTunesではない3つのデコーダを用意した。1つは「Windows Media Player」(WMP)の最新版、2つ目は「LAME」、そして3つ目は「午後のこ～だ」。LAMEも午後のこ～だも、もう何年も開発が止まっているようだが、フリーウェアとして今でも配布されているので、これをダウンロードして使ってみた。LAMEのほうはコマンドラインで操作する形になっているが、WindowsのGUIで操作できるLame Ivy Frontend Encoderというソフトがあったので、これを使った。
Windows 10 Creator Updateにインストールして使ったため、午後のこ～だやLAMEなど古い32bitアプリケーションは互換モードでインストールする必要があるなど、多少面倒なところはあったけれど、古いソフトが、そのまま動いてしまうWindowsの互換性には改めて感心した次第だ。なお、Windows Media Playerは、ほかのソフトのようにWAVへ直接変換する機能を有していない。ただし、MP3から直接CDを焼く機能があったので、これを用いていったんCDに焼いた上で、そのデータをWAVでリッピングしてみたのだ。
WaveCompareで見ると、WMP、LAME、午後のこ～だで比較すると、すべて異なるという結果だった。ここに取り上げた6つのソフトの総当たり結果をすべて掲載すると、数が多くなってしまうので控えるが、1つの組み合わせを除いて、すべて異なるというものだった。では、その1つとは何か。実はiTunes 4と午後のこ～だで、相違点が4,472サンプルなので、99.8%が合致という結果だ。もともと午後のこ～だはLAMEをベースにMMX、3DNow!、SSEなどのSIMD命令を使って最適化したものとしてリリースされたが、iTunes 4ではGOGOエンジンを搭載していた、ということなのだろうか。
6つのデコーダを周波数解析して比較
ビットbyビットでの比較結果は、以上の通りだが、これを周波数分析すると、どうなるのだろうか、6つのデコーダの結果を、同じくefu氏のWaveSpectraで解析した結果を以下に載せておこう。
これを見る限り、WindowsMediaPlayer以外はほぼ同じといっていい内容だった。前述の24bitと32bit floatの違いのようなものは、周波数解析からは見れないが、少なくとも周波数特性はどのデコーダもほぼ一緒といえそうだ。ただし、Windows Media Playerだけは見た目がかなり異なる。16kHz以上の高域でも音が出ているのだ。ただし、Windows Media Playerが高域成分の補間をしている、というわけではない。赤が最大値、青が300サンプルの平均、黒がリアルタイムの音を表しているのだが、黒を見ると高域が出ていないのがわかるはず。瞬間的に高域の成分が出たために赤だけが盛り上がっているのだ。ある意味ノイズとして高域の音が発生しただけと考えてもいいだろう。
聴いてみた感じでは、Windows Media Playerを含め6つともほぼ同じで、筆者の耳では違いを認識することはできなかった。正確に音に違いを聴き分けられる方がいれば、多少の差はあるかもしれないが、それでもごくわずかな違いしかなさそうで、その意味では、冒頭の指摘は合っているのだろう。ただ、データ上はやはり異なるものなので、前回の筆者の実験もあながち間違っていなかったかな、と思っている。
藤本健
リクルートに15年勤務した後、2004年に有限会社フラクタル・デザインを設立。リクルート在籍時代からMIDI、オーディオ、レコーディング関連の記事を中心に執筆している。以前にはシーケンスソフトの開発やMIDIインターフェイス、パソコン用音源の開発に携わったこともあるため、現在でも、システム周りの知識は深い。 著書に「コンプリートDTMガイドブック」(リットーミュージック)、「できる初音ミク&鏡音リン・レン 」(インプレスジャパン)、「MASTER OF SONAR」(BNN新社)などがある。またブログ型ニュースサイトDTMステーションを運営するほか、All AboutではDTM・デジタルレコーディング担当ガイドも務めている。Twitterは@kenfujimoto。