【PCAU】オーディオプレイヤー総合8【音質スレ】

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/14 19:34 / Filesize : 308 KB / Number-of Response : 935
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/12/21 23:29:22 ID:4+YnvZ0C]: 　　　　　　　　　　∫　　　＿＿＿＿＿＿＿＿＿＿＿＿
　　　∧,,∧ 　　　∬　　／
　　ミ,,ﾟДﾟ彡っ━~　　＜　オーディオプレイヤーについて語ろうや
＿と~,,　　~,,,ﾉ_. 　∀　　　＼
　　　ﾐ,,,,/~), │　┷┳━ 　￣￣￣￣￣￣￣￣￣￣￣￣
￣￣￣ .じ'Ｊ￣￣|　┃
￣￣￣￣

【過去スレ】
2 pc.2ch.net/test/read.cgi/software/1009735922/
3 pc2.2ch.net/test/read.cgi/software/1045810161/
4 pc2.2ch.net/test/read.cgi/software/1062259519/
5 pc5.2ch.net/test/read.cgi/software/1073815227/
6 pc5.2ch.net/test/read.cgi/software/1082555690/
7 pc5.2ch.net/test/read.cgi/software/1097066504/
411 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/27(土) 23:22:41 ID:atvxWAjm0]: いいから画質のいいビューア教えてみろよ。
「画質のいいJPEGビューアを語ろう」なんてスレ立てたら
馬鹿にされるだけで終わるだろうがな。
412 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/27(土) 23:49:24 ID:WZqNTf3U0]: 話を逸らすID:atvxWAjm0がｶﾜｲｲ
413 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/27(土) 23:57:18 ID:2IMWTS2b0]: >>411
>>410について反論すらできませんか？そうですか・・
まあ、誰でも現実を突きつけられればそうなりますから・・仕方ないことです。
414 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/28(日) 00:37:33 ID:KGo5+EDR0]: デコード結果の違いがあまりにも小さいと人間は音の違いを認識できない。
だから、十分に精度の高いMP3デコーダーであれば音質はどれも同じ。
十分に精度の高いMP3デコーダーであってもデコーダーごとに音質に違いがある
などと言っている人をみかけたら馬鹿扱いして構わない。
このスレでもそういう結論がすでに出ている。

しかし注意しなければいけないことはMP3デコーダー≠MP3プレーヤーであることだ。
MP3プレーヤーがやるべき仕事はMP3ファイルをデコードすることだけではない。

ありがちなのは、サウンドカードが勝手に48kHzにリサンプリングしてしまい、
しかもサウンドカードのリサンプラーの品質がよろしくない場合。
そういう場合にはプレーヤーソフトの側で48kHzにリサンプリング(SSRCなどを使う)
するように設定しておくとクリッピングの問題などが少し緩和される。
www.hydrogenaudio.org/forums/index.php?showtopic=9772

問題を切り分けて、必要なサンプル音源を用意し、
人間の耳を使ってプレーヤーソフトの選択や設定をチューニングするようにするべきである。
口先だけの連中はそのために必要な情報について何も言えない。
415 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/28(日) 01:19:11 ID:krPKEE660]: ↑乾電池で音が変わるかっていうCMを思い出した
データ以上に人間の耳には聞き分ける力ってあると思うけれど
＞デコード結果の違いがあまりにも小さいと人間は音の違いを認識できない。
そうかねぇ
416 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/28(日) 06:11:48 ID:w6BX7HAS0]: そうだよ
417 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/28(日) 08:31:55 ID:LHh75+130]: >>415
乾電池で音が変わるのは、乾電池の内部抵抗の関係。

アナログ系（アンプ）では、電源系の内部抵抗が音質に影響を
与えるのは理論的にも周知の事実。

デジタル系には関係のない話。
音が変わるとしたらデコードによるものじゃなくて、リサンプリングなど
演算によるデータの切り捨てや補完が行われる処理をした場合
だけだろうな。
418 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/28(日) 17:30:37 ID:b7Jr62kC0]: すでに結論は出ているだろう。
これ以上の議論は無駄。

１．音質は自分が最高と思ったものが一番(わからないやつは自分で比べろ)
２．他人のレスには語尾に【と、俺は思う】とつけて読む
３．プラシーボも実は重要。
４．もうこのスレいらないよ
419 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/28(日) 19:03:50 ID:4tr0f0350]: コテ使う奴にまともな奴はいないね
420 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/28(日) 23:08:05 ID:O6QdkM6x0]: >>417

乾電池で音質が変わることをダブルブラインドテストで検証した結果を知っていますか？

一般に「波形の変化」＝「音質の変化」ではないんだよな。
音質が変化していれば波形も変化しているはずなのですが、
波形が変化していても人間には認識不可能な場合があります。
（この事実がオーディオ圧縮技術の基礎になっている。）
特に携帯プレーヤーの通常の使用環境では認識はさらに困難になるはずです。

だから「理論的に波形が変化するはずだから音質も変化するはずだ」
という推測の仕方はものすごく危険。
やはり音質は、理論や物理的特性の測定ではなく、
人間の耳で評価するのが最も確実です。
421 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/28(日) 23:48:56 ID:WGZJ6LSc0]: しかし波形が変化しないなら音質も変化しないわけで、
つまりデコーダによる音質差がないのには変わりない。
422 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/28(日) 23:58:20 ID:zF1Y4EjX0]: >>421
1bitでもデコード結果が異なれば音質は変化しているんだよ。
それを人の耳が聴き取れるかは別問題だが・・
まあ、いずれにせよデコーダによって出力バイナリに違いが生じるというのは明らかなわけだ。
423 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/29(月) 00:11:26 ID:58OnbAsj0]: >>420での定義では、認識不可能な差は音質の差ではない。
1bitの違いを聞き取れるというなら別だけど。
424 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/29(月) 02:37:17 ID:reMlt1aA0]: 本当は単に「音質」と言わずに「人間に認識可能な音質」と言った方が良いかもね。
でも人間認識不可能な音質の違いについて語って何か嬉しいか？
やはり「音質」という言葉は「人間に認識可能な音質」という意味で使うべきだと思います。

バイナリレベルでの違いは単に聴く以外の処理を施す場合には重要になります。
例の超耳が良い guruboolez 氏はMP3デコーダーの違いによって
MP3による再圧縮による音質劣化の度合が違うことを確認している。
ttp://www.hydrogenaudio.org/forums/index.php?s=fa23ad57b3a8991b195c805a66cdc349&showtopic=32440&view=findpost&p=283566
しかし guruboolez 氏に認識可能なアーティファクトのすべてを
一般人も認識できるかどうかはかなり疑問。

余談。レコーディング、ミキシング、マスタリングの場合にもバイナリレベルでの精度が重要になります。
情報量は何か処理を施すごとに失われるので、できるだけ精度を高めて計算しておかないとまずい。
24bit/96kHz で処理することのメリットは、20kHz を超える高周波が扱えることよりも、
計算の精度を高めることによって人間に聴こえる0～20kHzでの歪みを減らせることです。
そして最終的なアウトプットは16bit/44.1kHzで十分です。
最終的なアウトプットまで24bit/96kHzでなければいけないと思っている人は騙されています。

あと通常では絶対にありえない試聴環境で聴いてもデコーダーによる音質の違いを確認できる。
そのことを確認したのもまたしても guruboolez 氏です。
ttp://www.hydrogenaudio.org/forums/index.php?showtopic=17728
極めて静かなサンプル音源のエンコード結果を
通常では絶対にありえないほどボリュームを上げて再生すると違いがわかる場合があるらしい。

しかし、guruboolez氏自身も通常の試聴環境では
MP3デコーダーの違いを認識できないと述べていることには注意しなければいけない。
425 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/29(月) 21:38:54 ID:WaJSHdER0]: たとえ１bitでもバイナリが変化するのは、精神衛生上よくない。
それに、自分を誤魔化しているようで何かいやだ。
426 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/29(月) 22:30:59 ID:6qbyuAf40]: >>420
コピペまがいののカキコにレスするのもなんだが・・・

>>417はアナログ回路、いわゆるアンプのことを書いてるのに何で
圧縮音楽の話が出てくるんだ？

アンプの等価回路を書いてみればわかるように、電源ラインの
インピーダンスはもろ出力信号に影響を与えるぞ。
電池の内部インピーダンス特性が、直線的ならまだ問題は少ないが
そうではないしね。

あとアンプの初段など出力インピーダンスが高い部分はまだいいが、
終段のイヤーホン駆動部分などはインピーダンスが低いから、より
影響を受けやすい。

マンガン電池なんか使うと（普通使わんが）電池がへたってくるにつれて
大音量部分で音が歪んだりするだろ。　でも電池を取り出して無負荷で
電圧測るとちゃんと1.5Vある。　これは電池の内部抵抗が増えたための
現象。　ま、これは極端な例だけどねw
427 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/30(火) 00:39:48 ID:aUNfoglg0]: > >>417はアナログ回路、いわゆるアンプのことを書いてるのに何で
> 圧縮音楽の話が出てくるんだ？

スレタイ100回読み直せ
お前らの方がスレ違いな事いってる
428 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/30(火) 01:28:10 ID:guVUcgW40]: 追加の指摘。>>426のようなスレタイさえ読めない奴は
「ダブルブラインドテストで検証した結果を知っていますか？」
という質問をまたしても無視している。

音質に関する噂ほど信用できない噂は存在しない。
人間は余計な知識があるせいで音質も変わって感じることがある。プラシーボ効果。

たとえば様々な知識があって電池によって音質が変わるはずだと信じている人は
実際には音質が変化していなかったり、実際の音質変化はものすごく微妙であったとしても、
乾電池が違っていることを知ｔった途端に「驚くほど」の音質の変化を感じることになるだろう。

さらに、波形が変化していても、人間が音質の変化を認識できるとも限らない。
つまり物理的測定は音質の変化の強い傍証にはなるが、
人間が結果的にどれだけの音質の変化を感じることになるか
について知りたい人にとっては不満足な検証結果に過ぎない。
(物理的測定が不必要だと言っているわけではない。)

以上のような理由で、主観的な音質の変化の大きさを正確に評価するためには、
人間の耳を使ったダブルブラインドリスニングテストを行なう必要がある。
音質の違いが微妙な場合にはテストリスナーは非常に苦労することになるだろう。
しかし実際に「驚くほど」の音質の変化が生じているならばすぐに違いが判別できるので、
そのダブルブラインドリスニングテストは速やかにかつ楽ちんに終わることになるだろう。
そういう楽なはずの試験の結果がどうして見付からないかが不思議である。

繰り返す。ダブルブラインドリスニングテストで検証した結果を知っているか？
429 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/30(火) 01:40:55 ID:guVUcgW40]: >>425

「MP3デコーダーごとに 16bit リニアPCMへのデコード結果で最下位1bitの違いが生じることがある」
という話をしているときに

＞たとえ１bitでもバイナリが変化するのは、精神衛生上よくない。

なんて話をするのは的を外しているぞ。MP3で圧縮した途端に情報は大幅に失われている。

ちなみに、>>414で紹介されているURLからダウンロードできる udial 音源は
自分のパソコンの再生環境がクリッピングを起こしていないかどうかのチェックに極めて有効。
プッシュホンの音だけではなく、「シューン、シューン」とか「キューン、キューン」のような音が
聴こえてしまった人の再生環境はどこかでクリッピングを起こしてしまっている。
(クリッピング＝音圧のピークが再生環境の限界を超えること)

1bitでもバイナリが変化することさえ許さない奴の再生環境は
果たしてクリッピングを起こしていないクリーンな再生環境なのかな？ｗ
apeファイルの再生の仕方がわからない人は foobar2000 をインストールするのが簡単だと思う。

実は私の再生環境はクリップしていた。
しかしfoobar2000の側で48kHzにリサンプリングするように設定したら、クリッピングが解消された。
430 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/30(火) 14:08:47 ID:IYaM7iKp0]: >>428
あのさ、乾電池で音が変わるっていうのは >>415の

>↑乾電池で音が変わるかっていうCMを思い出した

に対するレスだぞ。
デジタル的な音質変化じゃなくて、アナログ的な音質変化
だという主張で書いたのだが。

内部抵抗の大きい電池の例は、ダブルブラインドテストする
までもなく明らかに差がわかると思うぞ。

もちろん、ソニーと東芝の新品の乾電池で、どれくらい音質の
差があるかを調べるならダブルブラインドテストでもしないと
判別できないかもしれないが、使用するにつれて劣化していく
乾電池を同一条件で、とっかえひっかえするのに何本乾電池が
いるやらw

王子のこれまでの言動からするに、王子はアナログ系に関しての
知識は、あまりないように感じるな。まぁどうでもいいけどさ
431 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/30(火) 16:05:15 ID:xExnnVRp0]: 要するにダブルブラインドリスニングテストは誰もやっていないということだな。

問題は電池によって音質が変わるかどうかだけではない。
音質の変化がどの程度であるかも問題にされている。
電池の状態によって音質に違いがあると思っている人が
電池がへたってきていることを確認すると
プラシーボ効果のせいで音質の変化を
実際より極端に大きく感じてしまう可能性がある。

音質の変化がどの程度であるかの確認は
ダブルブラインドリスニングテストで音質の区別をどれだけ簡単にできたか
を調べるのが確実である。

たいていの人は音質について語るときに大げさな言葉を使いたがるものだ。
ダブルブラインドリスニングテストを常に強制される可能性を考慮している人であれば
大げさな言葉を使うのをできるだけ避けるようになるだろう。

真に驚くほどの音質変化であれば百発百中に近い成績で
しかも短時間でどちらであるかを正解し続けることができるだろう。
音質の変化が自明だと思われる場合であっても
念のために自分自身が実際にそうできるかを試してみた方が良い。

不思議なのはブラインドテストが必要ないほどの大きな変化であれば
楽々ブラインドテストをクリアできるはずなのに、
そのことからなんだかんだ言って逃げ続け、
自分自身の発言の信用を失うことを好む人が多いことである。

私は単なる知識よりも事実をより正確に把握する方法の方が大事だと思う。
私は事実を正確に把握するスキルと精神を持っている人以外は信用しない。
技術的なことに詳しい人であっても音質のことになると
途端にスキルと精神が劣化してしまう人が多いのは残念なことである。
432 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/30(火) 16:27:33 ID:xExnnVRp0]: ＞↑乾電池で音が変わるかっていうCMを思い出した

これはオキシライド乾電池のことですよね。
携帯プレーヤーでオキシライド乾電池を使うと
音質が変化するか、変化するとすれば音質の変化はどの程度であるか、
などに関するダブルブラインドリスニングテストの結果はあるのでしょうか？
このスレで続ける話題ではないと思うので
情報が得られそうなより適切な場所があれば教えて欲しいです。

もしもメーカーサイドがダブルブラインドリスニングテストをやらずに
宣伝しているとすればちょっと問題ありだよな。

知識が豊富な>>430氏は当然
オキシライド乾電池のCMの真偽についても知っているつもりだろうが、
ダブルブラインドリスニングテストの結果があるかどうかについてはきっと知らないだろうね。
そもそも科学的なテストの必要性を理解しているかどうかも疑問。
433 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/30(火) 16:34:43 ID:6sz4dOLm0]: CMを見ていて思ったのですが、是非ともやってもらいたいテストは、

1. 「通常のアルカリ電池を入れた」と教えて試聴してもらう。
しかし実際にはオキシライド乾電池もランダムに混ぜてある。

2. 次に「今度はオキシライド乾電池を入れた。音質が良くなっているはずだ」と教えて試聴してもらう。
しかし実際にはアルカリ乾電池も混ぜてある。

3. そしてどちらの音質が優れていたかの感想を述べてもらう。

もしもダブルブラインドリスニングテストなど必要がないくらい
オキシライド乾電池で音質が向上していれば
嘘を教えられた人は他の人と逆の回答をすることになるだろう。

しかし、プラシーボ公開にかきけされてしまうような微妙な音質の変化に過ぎなければ、
後者の電池の方が音質が良かったと大部分の人が答えることになるだろう。

こういう話を面白がる人は結構いるはずなのにどうして誰もやらないのか？
家族や友人で試してみることができますよね。
434 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/30(火) 16:35:42 ID:6sz4dOLm0]: 訂正：プラシーボ公開→プラシーボ効果
435 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/30(火) 19:28:36 ID:mvSu5gTl0]: >>432
あんたはiRiverのホームページの掲示板でも同様の議論してるな。w

べつに俺はオキシライド乾電池のこと言ってるわけじゃないぞ。
純粋にアナログアンプに対する電源のインピーダンスの影響について
言ってるだけ。

俺が主張しているのは、電池を替えて音質が良くなったというのであれば、
それはデコードのデジタル部分に関わることではなくて、DA変換後の
アンプの部分の影響だということ。

圧縮音楽の世界では、エンコード前とデコード後の波形を表示して
比較したりしているが、これはデコード後のPCMコードを演算して
アナログ波形として表示しているだけだよね。　実際のD/A変換した
アナログデータをオシロスコープで表示しているのとはわけが違う。

アナログの場合は、後段とのインピーダンスマッチングの状態に
よっても容易に波形は変化してしまう。　繋げるスピーカーやイヤホン
を替えるだけでも波形は変化してしまう。

そういった意味で、波形で音質は語れないという点は同意するがな。

あとクリップピングの事も書いてるようだけど、それはデジタルデータの
オーバーフローという形のクリッピングだと思うが、アナログ回路の
クリッピングもあることを忘れないで欲しいな。

>情報が得られそうなより適切な場所があれば教えて欲しいです。

iRiverの掲示板に詳しそうな人が居るみたいだから、その人に相手
してもらったら？w 　俺は行かんけど
436 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/08/31(水) 17:50:38 ID:mh5S8hQo0]: １．音質は自分が最高と思ったものが一番(わからないやつは自分で比べろ)
２．他人のレスには語尾に【と、俺は思う】とつけて読む
３．プラシーボも実は重要。
４．もうこのスレいらないよ
437 名前：名無しさん＠お腹いっぱい。 [2005/09/01(木) 07:58:42 ID:Z4Q2q4eH0]: >>436
ああだこうだとスレが楽しくなってくると
そのコピペをする無粋な粘着がまだいるんだな
438 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/01(木) 11:17:35 ID:2tc+lDah0]: >>436
こういうコピペをする人って，「自分はモノのわかったオトナだ」とか勝手に思っているんでしょうね

議論に入れるほどの知識はありませんが，
意見のぶつかり合いも含めて，色々勉強になります。
439 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/01(木) 15:38:10 ID:o/eAy/Yr0]: >>437-438
おまいらもスルーを覚えろ」
440 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/01(木) 21:28:40 ID:vWrUqgGt0]: >>437はまずsageからだな。
441 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/03(土) 16:29:58 ID:OSmoTgxh0]: .
442 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/08(木) 04:04:07 ID:/vcvGwD30]: Lilith のMP3デコーダーと他のデコーダーの「距離」がどの程度か
に興味がある人がいると思ったので今調べてみた。

試験に使ったサンプル音源は BlackBird.wv をデコードしたWAVファイル。
ダウンロードは lame.sourceforge.net/gpsycho/quality.html からできる。
LAME 3.96.1 の --preset insane でエンコードして各種デコーダーでデコード。

比較したのは

[audioactive] Audioactive MP3 Decoder
[mpglib] foobar2000 mpglib
[mad] foobar2000 MAD
[mpg123] Winamp Otachan's in_mpg123.dll
[lilith] Lilith 0.991b

つづく。
443 名前：名無しさん＠お腹いっぱい。 [2005/09/08(木) 04:05:00 ID:/vcvGwD30]: つづき。

デコード結果の差を取ってピークを調べると
audioactive, mpglib, mad, mpg123
のあいだには最下位1bitの差しかないことがわかる。
しかしそれらと lilith のあいだの差のピーク値は 2 であった。
だから差のピーク値だけを見る限りにおいて
lilith は他のデコーダーから遠いところにあると考えられる。
(これは正確さという観点からは lilith にとって不安要因かもしれない。)

デコード結果の差の波形を拡大して見てみると、
mpglib と mpg123 は非常に近く、mad と audioactive も近いことがわかる。
lilith は mpglib と mpg123 よりも mad と audioactive に近い感じ。

以上。
444 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/08(木) 23:33:54 ID:JJ2kTt2AO]: でも、lilithの音は他のデコーダに比べて自然に聞こえるんだよな。
元のＣＤに近い音って感じかな。
445 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/08(木) 23:57:34 ID:BgZc/+lE0]: >>443
デコーダ同士の比較にどんな意味があるのだろうか・・・
比較するならエンコ前のwavと比較すべきじゃない？
つまり、どれだけ忠実にオリジナルを再現できるかで評価すべきだと思うよ。
446 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 05:41:15 ID:+EOghvjO0]: >>445

エンコ前のWAVファイルとの差も取ってピーク値を計測すると、
audioactive, mpglib, mad, mpg123 は 1072 で
lilith は 1073 でひとつ大きくなります。
つまり lilith の方がオリジナルのWAVに近いとは言えない。
lilith のデコーダーは他のデコーダーより精度が低い可能性があると思います。

しかし 1 しか差がありません！果たしてこの差に意味があるのか？
おそらくこの程度の差であれば通常の試聴環境ではまったく区別できないと思います。

>>444の感想はプラシーボ効果である可能性が高いと思う。
MP3で圧縮した音は十分な聴き取り能力があればCDから程遠い音に聴こえるはず。

精度の高いMP3デコーダーであればどれを使っても音質は同じです。
MP3プレーヤーおよびその設定の仕方の違いでは音質の差が出る場合がある。
MP3デコーダーとMP3プレーヤーの問題を混同しないように！

あとMP3デコーダーの精度を計測するためにはオリジナルのWAVと比較しても無意味です。
MP3デコーダーの規格に沿って「数学的に理想的なデコーダー」を仮想的に考えることができます。
あらゆる計算が誤差ゼロで実行されるようなデコーダーです。
そのような仮想的に考えた理想的なデコーダーによるデコード結果と
どれだけ差が出てしまっているかを計算すればMP3デコーダーの精度がわかります。
447 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 05:44:02 ID:+EOghvjO0]: デコーダーの違いを聴き取るためには通常とは
異なる極端な試聴環境を使う必要があります。
たとえば極めて静かなサンプル音源をMP3で圧縮して、
通常ではありえないほどボリュームを上げて聴いてみる。
私も暇があればやってみたいのですが、
どなたか自分でもやってみた方がいれば感想を教えて下さい。

ttp://www.hydrogenaudio.org/forums/index.php?showtopic=17728
448 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 07:11:39 ID:YTYWwt+90]: MP3デコーダーの違いによる(16bitへの)デコード結果の差のピーク値で1でしかない。
(lilith とそれ以外は例外的に 2 になってしまった。)
MP3エンコーダーの違いによって生じる差のピーク値は数百のオーダーになる。
さらにMP3による圧縮結果と圧縮前の音源の差のピーク値は千～数千に程度に達する。つまり、

MP3デコーダーどうしの差＜＜＜ MP3エンコーダーどうしの差＜ CDとMP3の差

という感じになっている。CDとMP3の音質の違いやMP3エンコーダーごとの音質の違いを
楽々と聴き分けることができない人にはMP3デコーダーの違いを聴き取れるはずがない。
オーダーが2桁～3桁と大きく違う。

MP3エンコーダーには大したこだわりがないくせに
MP3デコーダーには妙なこだわりを見せるやつは
それだけで先入観や偏見で音質を評価しているだけであることがばれてしまう。
そういう人は自分自身が音質について何もわかっていなかったことを素直に認め、
プラシーボ効果を排除して音質を評価する方法を学ばなければいけない。
449 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 07:12:57 ID:YTYWwt+90]: 訂正：「lilith とそれ以外は」→「lilithとそれ以外の差のピーク値は」
450 名前：名無しさん＠お腹いっぱい。 [2005/09/09(金) 08:29:34 ID:qdGQ1r5F0]: サンプル音源が一つだけだと信頼性が低すぎるので、
lame.sourceforge.net/gpsycho/quality.html
からダウンロードできるすべてのサンプル音源でテストしてみた。
比較したのは mpglib, mad, lilith の3つだけ。
LAME 3.96.1 --preset insane でエンコードしたものを
それらのデコーダーでデコードした結果を比較した。

結果は以下の通り。

(1) mpglib と mad のデコード結果の差のピークは
例外的に applaud で 2 になっている以外はすべて 1 になった。

(2) lilith と残りの二つの差は想像以上に大きかった。
最も差が大きかったのは KMFDM-Dogma の 40 である。

以上の結果は「lilith だけが精度が高い」と解釈することも可能だが、
他の優秀だと言われているデコーダーとの比較も考慮すると、
実際には「lilithだけが精度が低い」という可能性の方が高いと思う。
この推測に誤りがあれば Lilith の開発者およびユーザーにお詫びしたいが、
さらなる分析が必要なことだけは事実だと思われる。

以下にデコード結果の差のピーク値のログを分割して投稿する。
451 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 08:30:53 ID:qdGQ1r5F0]: Peak Filename
--------------------------------------------------
2 diff_60_lilith_and_mad.wav
2 diff_60_lilith_and_mpglib.wav
1 diff_60_mpglib_and_mad.wav

2 diff_BlackBird_lilith_and_mad.wav
2 diff_BlackBird_lilith_and_mpglib.wav
1 diff_BlackBird_mpglib_and_mad.wav

4 diff_Fools_lilith_and_mad.wav
3 diff_Fools_lilith_and_mpglib.wav
1 diff_Fools_mpglib_and_mad.wav

40 diff_KMFDM-Dogma_lilith_and_mad.wav
40 diff_KMFDM-Dogma_lilith_and_mpglib.wav
1 diff_KMFDM-Dogma_mpglib_and_mad.wav

6 diff_applaud_lilith_and_mad.wav
5 diff_applaud_lilith_and_mpglib.wav
2 diff_applaud_mpglib_and_mad.wav

4 diff_castanets_lilith_and_mad.wav
3 diff_castanets_lilith_and_mpglib.wav
1 diff_castanets_mpglib_and_mad.wav
452 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 08:31:41 ID:qdGQ1r5F0]: Peak Filename
--------------------------------------------------
4 diff_else3_lilith_and_mad.wav
3 diff_else3_lilith_and_mpglib.wav
1 diff_else3_mpglib_and_mad.wav

3 diff_fatboy_lilith_and_mad.wav
2 diff_fatboy_lilith_and_mpglib.wav
1 diff_fatboy_mpglib_and_mad.wav

3 diff_ftb_samp_lilith_and_mad.wav
2 diff_ftb_samp_lilith_and_mpglib.wav
1 diff_ftb_samp_mpglib_and_mad.wav

2 diff_goldc_lilith_and_mad.wav
2 diff_goldc_lilith_and_mpglib.wav
1 diff_goldc_mpglib_and_mad.wav

4 diff_hihat_lilith_and_mad.wav
3 diff_hihat_lilith_and_mpglib.wav
1 diff_hihat_mpglib_and_mad.wav

4 diff_iron_lilith_and_mad.wav
3 diff_iron_lilith_and_mpglib.wav
1 diff_iron_mpglib_and_mad.wav
453 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 08:34:34 ID:qdGQ1r5F0]: Peak Filename
--------------------------------------------------
3 diff_main_theme_lilith_and_mad.wav
3 diff_main_theme_lilith_and_mpglib.wav
1 diff_main_theme_mpglib_and_mad.wav

1 diff_mstest_lilith_and_mad.wav
1 diff_mstest_lilith_and_mpglib.wav
1 diff_mstest_mpglib_and_mad.wav

1 diff_pipes_lilith_and_mad.wav
1 diff_pipes_lilith_and_mpglib.wav
1 diff_pipes_mpglib_and_mad.wav

3 diff_spahm_lilith_and_mad.wav
3 diff_spahm_lilith_and_mpglib.wav
1 diff_spahm_mpglib_and_mad.wav

3 diff_testsignal2_lilith_and_mad.wav
3 diff_testsignal2_lilith_and_mpglib.wav
1 diff_testsignal2_mpglib_and_mad.wav

1 diff_testsignal4_lilith_and_mad.wav
1 diff_testsignal4_lilith_and_mpglib.wav
1 diff_testsignal4_mpglib_and_mad.wav
454 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 08:36:58 ID:qdGQ1r5F0]: Peak Filename
--------------------------------------------------
3 diff_track7_lilith_and_mad.wav
3 diff_track7_lilith_and_mpglib.wav
1 diff_track7_mpglib_and_mad.wav

2 diff_vbrtest_lilith_and_mad.wav
1 diff_vbrtest_lilith_and_mpglib.wav
1 diff_vbrtest_mpglib_and_mad.wav

3 diff_velvet_lilith_and_mad.wav
3 diff_velvet_lilith_and_mpglib.wav
1 diff_velvet_mpglib_and_mad.wav

2 diff_youcantdothat_lilith_and_mad.wav
2 diff_youcantdothat_lilith_and_mpglib.wav
1 diff_youcantdothat_mpglib_and_mad.wav
455 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 13:05:14 ID:CXYUs/QvO]: >>446
言ってることが矛盾してるなぁ。

lilithのデコード結果とオリジナルのWAVを比較して、精度が低いと言っときながら、オリジナルのWAVと比較しても無意味だと言っている。

そもそも、一度でも非可逆圧縮にしたものをオリジナルと比較するのは全くの無意味。
これは、非可逆圧縮の原理がどういうものかを理解していれば分かると思う。

それから、出力バイナリの下位ビットを比較してデコーダの精度云々を論じるというのも全くのナンセンス。
非可逆圧縮のデコードである以上、デコード結果に差異が生じるのは仕方がないこと。
デコード結果に正解などないのだから、どのデコーダが優れているかなんて結論は出ない。

あえて言うなら、実際に聴いてみて良い音と感じたものが、その人にとって最良のデコーダだろう。
456 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 15:36:30 ID:AyfWPd9i0]: ＞非可逆圧縮のデコードである以上、デコード結果に差異が生じるのは仕方がないこと。

基本的なところで誤解している。

MP3ファイルのデコードは本質的に逆MDCTをやるだけなので
仮想的に誤差がまったく存在しないデコーダーを考えることができる。
実際には16bit整数などに量子化しなければいけないので
そこで最下位1bit程度の違いが生じてしまう可能性が出て来てしまう。

逆に言えば精度の高いデコーダーによるデコード結果のあいだにはその程度の差しかない。
Lilithだけが他のデコーダーとデコード結果に大きな違いがあるということは
「Lilithだけの精度が高い」か「Lilithだけの精度が低い」かのどちらかであるということだ。
この結論だけはどうしても否定できない。

「Lilithだけの精度が高い」というのは信じられないので
「Lilithだけの精度が低い」の方がおそらく正しいだろう。

もしも mpglib や MAD やそれらとやはり最下位1bit程度の差しかない
Audioactive や Otachan's mpg123 の精度がどれも低いという主張が正しいならば、
それらは精度が低いのにそれらのあいだには最下位1bitの差しか生じていない
というありそうもないことを信じなければいけなくなる。
457 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 15:48:15 ID:AyfWPd9i0]: わかりにくい説明になってしまっているかもしれないので再度説明しよう。

foobar2000 などで使われている mpglib、MAD や
Winamp などで使われている Otachan's in_mpg123.dll や
Audioactive MP3 Decoder による
16bitリニアPCMへのデコード結果のあいだの違いは
ときどき例外が生じるがせいせい最下位1bit程度でしかない。

しかし、Lilith のMP3デコーダーによるデコード結果と
mpglib、MAD によるデコード結果のあいだには最下位1bitよりも
大きな違いが生じていた。

ここまでは確認された事実であり、誰にでも再検証可能なことである。

MP3デコーダーの規格はある意味単純で数学的には逆MDCTを行なうだけである。
理想的に計算された場合のデコード結果と16bitに量子化された場合では当然
微少な違いが生じる。これが精度の高いデコーダーによるデコード結果のあいだに
最下位1bit程度の差が生じてしまう原因である。 (これは一般論)

さて以上の情報から何が結論されるだろうか。
もしも上に挙げた Lilith 以外のデコーダーの精度が低ければ、
それらは精度が低いにもかかわらず、どれも同じ方向にずれており、
互いの差が最下位1bit程度の範囲におさまってしまっているということになる。
それは信じられないことなので上に挙げた Lilith 以外のデコーダーの精度は高いはずである。
したがって精度の高いデコーダーとデコード結果が大きく違う Lilith の精度は低いと結論できる。
458 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 16:20:30 ID:AyfWPd9i0]: KMFDM-Dogma だけ lilith と mpglib、mad と
デコード結果の差のピーク値が40と非常に大きくなってしまっている。
差の波形を拡大してみてみて、どこの部分で差が大きくなっているかを確認してみた。
差が非常に大きくなっているのはファイルの終わりの方の右チャンネルである。
その部分を除けば差のピーク値は2におさまっている。
その程度の違いであれば通常の試聴環境で他のデコーダーとの違いはわからないだろう。

問題はどうして KMFDM-Dogma の終わりから 0.002 秒ほどの区間で
これほど大きな差が生じてしまったかである。
459 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 17:45:56 ID:CXYUs/QvO]: >>456-457
いや、誤解はしていない。
その量子化誤差のことを言っている。

そもそも精度とは何か？
mp3のデコードに関して、規定が設けられているのはご存じですか？
この規定にどれだけ近付けることができるか、それが精度だと思います。

あなたの推論は、多数派が常に正しいと言っているだけです。
根拠のない推論は詭弁にしか聞こえません。

それと、もう一つ。非可逆圧縮音源に関しては、必ずしも高精度＝高音質ではないということを覚えておいて下さい。
非可逆圧縮された音源の周波数や波形等を分析してみると、かなり破綻していることが分かります。
真に理想的なデコーダというのは、これら破綻した箇所を補完し、圧縮前に近い波形で出力できるものだと考えます。

つまり、デコード結果が規定された精度に近かったとしても、それは音質が良いという根拠にはならないのです。
最終的に音質の善し悪しを決めるのは人の耳しかないんですよ。
音質評論とは本来、そういったものではないでしょうか？
460 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/09(金) 18:53:16 ID:2hxUpYZW0]: なんで差のピーク値しか見ていないんだ(*´д｀）

何千何万とあるサンプルのうち、たった１つが大きく異なっている場合よりも、
すべてのサンプルが満遍なく小さく異なっている場合の方が音質は悪いだろ。

たとえて言うなら、オリジナルのWAVEと比べて最初の１サンプルだけ±40違うが、後はすべて一緒のデータと、
オリジナルのWAVEと比べてすべてのサンプルが±1違うデータで、
聴覚上どちらがよりオリジナルに近いか？　当然前者だろう。

オリジナルとの差分のRMSレベルを算出して、それも比べないと。
ピーク値だけ見たって音質は比較できん。

スペアナのピーク波形だけ見てオリジナルに近い・近くないと言っている
某ライターじゃないんだからさ。
461 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/10(土) 00:15:26 ID:3OwRUOpc0]: >>459

「多数派が常に正しい」という単純な議論はしていない。
「そのような偶然はとてもありそうもない」という議論をしている。

より精度が低いデコーダーが複数あるときに、
それらの精度が低いのに互いの差が最下位1bit程度しかない
というようなことが偶然起こるのはとありそうもないことだ。
そのようなことが起こるのはそれらのエンコーダーの精度が
どれも十分に高い場合以外にはほとんど考えられない。

Lilith によるデコード結果とそれ以外のデコーダーによるデコード結果
の差が最下位1bit程度におさまっている場合が存在するのも偶然ではない。
Lilithもまた精度の高いデコーダーを目指していたのは周知の事実である。
462 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/10(土) 00:19:18 ID:3OwRUOpc0]: >>460

差のピーク値だけを見るだけではいけないというのはまったくその通りだ。
音質云々についてもまったくその通りだと思う。

しかし、実際には波形も見ている (>>458を見よ)。
差の波形を見ると lilith によるデコード結果は mpglib よりも mad に近いこともわかる。
そして lilith とそれ以外の差はほとんどの部分で1以下であり、2以上の部分の密度はかなり薄い。

しかし、差のピーク値が Lilith と他を比較した場合に限って平均して2～3程度になってしまう
というのは事実である。しかも >>458 で紹介したサンプルでは差のピーク値が40に達して
しまっている。ピーク値を見るだけでは駄目だという意見は正しいのだが、
さすがにこれでは印象が悪いだろう。

私はできる範囲内でテスト結果を公開した。
使ったサンプル音源は公開されているものなので誰でも追試可能である。
私にはできなかったようなより詳細な分析を是非ともやってもらいたいものである。

以上のテスト結果を無視するのも自由である。
しかし他のデコーダーとの差のピーク値が
Lilith の場合だけ例外的に大きくなるという事実は
すでに十分に素晴らしいソフトである Lilith にも
まだ改良の余地が残っている可能性が高いことを意味していると思う。
繰り返すがこのような考え方を無視するのも自由である。
463 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/10(土) 00:31:47 ID:3OwRUOpc0]: 補足。差のピーク値だけを見て言えることが非常に少ないのは事実ですが、
差のピーク値が3～4程度になることが頻繁にあったり、
40にも達する場合があることは量子化に伴う誤差では説明できません。
LilithのMP3デコーダーでは量子化以外の原因で
誤差が生じている可能性が高いと思う。

やはりより詳しい分析が必要なことだけは事実じゃないですかね？
私にはこれ以上のことは無理ですが。
464 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/10(土) 02:23:06 ID:LfnABJgP0]: Lilithのデコーダについては、このスレでも過去に幾度となく議論され、多くの方が他のデコーダとの比較を行っている。
そして、今までに幾つかの共通した特徴が示されている。

　　１．mp3特有の高音域における歪が低減されている。
　　２．出音が自然で聴き疲れしない。
　　３．弦楽器の音色が瑞々しく再現されている。
　　４．ソース（wav）の再現性が高い。
　　５．艶かしい空気感がある。

中には眉唾ものもあるが、だいたい似たような意見が多い。

今回、新たに分かった事実は以下の通りである。

　　１．デコード結果の差のピーク値が、他のデコーダ間の差のピーク値よりも大きい。
　　２．差のピーク値が40にも達する場合があることは、量子化に伴う誤差だけでは説明できない。
　　３．LilithのMP3デコーダーは、量子化以外の原因で誤差が生じている可能性が高い。

今回証明された事実は、今まで囁かれてきたLilithの特徴を裏付けるものになるかも知れない。

つまり、過去の評論と今回の事実に鑑みて、次に示す推論が導き出せると考える。

　　１．Lilithはデコード以外に、データを改変するような処理を行っているのではないか？
　　２．そして、それは目的を持って意図的に行われているのではないか？（高音域の歪低減、再現性向上のため？）
　　３．試聴環境や試聴者の能力によっては、他のデコーダとの違いを十分聴きとれるのではないか？（プラシーボでないことの証明？）

以上の推論は、あくまでも想像の域を出ないが、一つの可能性として示してみた。
465 名前：460 mailto:sage [2005/09/15(木) 00:46:47 ID:/sQlVl9y0]: RMSレベル測ってみた。
サンプルは>>450に準じて、
BlackBird.wvをLAME 3.96.1 --preset insane でエンコードしたものを
それらのデコーダーでデコードした結果を比較した。
オフセットズレのあるデコーダも存在するので、
その他の音源はまだ測定できていない。

なお、今回の測定では、MADのサイトにあるリファレンスデコーダおよび、
オリジナル音源との間でのRMSレベルおよび差のピーク値を測定。
リファレンスデコーダは、MAD公式サイト
ttp://www.underbit.com/products/mad/
のDecoder Complianceコーナーから、
compliance bitstreams(Layer-3.tar)をDLし、
展開すると入っている。

なお、厳密な意味でのリファレンスデコーダというものは、存在しない
(dist.10にも色々バージョンがあり、どれをとってきてもバグが存在する)
ので、dist.10を元にバグ修正だけを行ったという
MADのサイトのものをリファレンスデコーダとした。

結果は次の書き込みで。
466 名前：460 mailto:sage [2005/09/15(木) 00:56:25 ID:/sQlVl9y0]: ref - lilith(x86) RMS=2.7851e-6 PEAK=6.1035e-5
ref - lilith(sse) RMS=2.8109e-6 PEAK=6.1035e-5
ref - lame3.96.1 (mpglib/rarewares) RMS=7.9452e-6 PEAK=3.0518e-5
ref - foobar0.83 (mpglib/case special) RMS=7.9567e-6 PEAK=3.05187e-5
ref - madplay0.15.2b RMS=1.5792e-5 PEAK=3.0518e-5

org - lilith(x86) RMS=1.3680e-3 PEAK=3.2745e-2
org - lilith(sse) RMS=1.3680e-3 PEAK=3.2745e-2
org - lame3.96.1 (mpglib/rarewares) RMS=1.3680e-3 PEAK=3.2715e-2
org - foobar0.83 (mpglib/case special) RMS=1.3680e-3 PEAK=3.2715e-2
org - madplay0.15.2b RMS=1.3867e-3 PEAK=3.2715e-2

順に、リファレンスデコーダでのデコード結果との比較、
およびオリジナルPCMファイルとの比較。
467 名前：460 mailto:sage [2005/09/15(木) 01:02:42 ID:/sQlVl9y0]: PEAK値を見ると、Lilithは確かにどちらの比較でも
今回のサンプルでは確かに差が大きく出ている。
リファレンスデコーダとの比較では、ちょうど16bitの下位1bit分余計。
この結果は450氏の測定と一致する。

しかしながら、RMSでは、ほかと同等かそれ以上の成績を残している。
PEAKが大きいということは、そのサンプルのためにその分RMSも高くなりやすいのに
それでも低い値を出しているということは、
少数のサンプルでは大きく違うが大多数のサンプルではほとんど違わないことを意味する。
＃RMSは二乗平均のことなので、大きく違うサンプルがあるほど、単純平均に比べて不利になる。

音質を差分のRMSレベル(=オリジナルに加えられたノイズ)と判断すると、
Lilithは若干音質がいいという結果となった。

なお、あくまでも１サンプル音源での結果でしかないので絶対的なものではない。
全部はきちんと測定していないが、ほかに少しだけ試したいくつかのサンプルでも
同様の傾向が得られたので、あながち間違いでもないとは思うが、
この程度の差を聴き分けられる可能性は低いと思う。

蛇足として、今回使用したデコーダ間での比較は、
リファレンスデコーダとの比較結果と同程度の差が、
それぞれのデコーダ間であった。
＃同じmpglibのlameとfoobarはほぼ同等だったが、コンパイラに起因する誤差は認められた。
ピーク値に関しては、450氏の結果と一致する。

最後に、今回の結果より、>>464で述べられているような明らかな色づけは行っていないのではないかと推測される。
色付けを行った場合、オリジナルPCMとの差は小さくなるかもしれないが、
リファレンスデコーダとの差は大きくなるはずだからだ。
468 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/15(木) 07:54:24 ID:fnohYO1O0]: >>467さん、どうもありがとうございます。非常に興味深い結果です。
>>450の最初の1行目にある通り、サンプル音源が一つだけだと信頼性が低いのですが
(たとえば KMFDM-Dogma のようなサンプル音源ではどうなるか？)、
それでも非常に面白いです！！！

ただし、>>464にある音質に関する1～5の主張はまったく信用できないと思います。
証拠にあたるABXテストの結果とサンプル音源のペアが一切提出されていない。
プラシーボ効果でないことがはっきりするまでは
>>464の1～5のような感想はすべて疑わしいとみなされるべきです。

あと、>>467さんが計測した結果程度の差であれば
通常の試聴環境では音質の差を認識できない可能性が高く、
違いを認識できる場合であってもあまりにも微妙な違いなので
>>464の1～5のようなまるで音質に大きな違いがあるかのような主張は
どれも否定されることになると思います。

guruboolez氏が
ttp://www.hydrogenaudio.org/forums/index.php?showtopic=17728
で使った方法でLilithのMP3デコーダーも含めた試聴試験を
誰か耳の良い方が行なってみるのは興味深いと思います。
(そこではMADの成績は悪い！ >>486の数字とその結果を比較してみよ！)
Lilith の MP3 デコーダーのキャラクターは他と違っているので
その違いがどう聴こえるかは面白そうです。
469 名前：460 mailto:sage [2005/09/15(木) 13:37:50 ID:/sQlVl9y0]: >>468

今回の結果は、あくまでもサンプル音源BlackBird.wvの結果なので、
これで音質が語れるとは思えない。
デコーダ間の比較はしたことないが、
以前MP3の再現性を確かめるために、
(確かLilithを用いて)オリジナル音源との(差分の)比較を行ったことがある。

手元にあるJ-POPなどの曲を丸ごとエンコード->デコードし、
オリジナルとのRMSレベルを計測した結果、
466とは一桁も二桁も違うオーダーでの差が検出された記憶がある。

BlackBird.wvは比較的静か曲で、使用されている音源の数も少なく、
音源の種類もシンプルなので、MP3で比較的再現しやすい音源である。
＃とはいっても、なんらかの不具合をもたらすキラーサンプルだから、
＃登録されて公開されているのだろうが。

最近のJ-POPなどのように、MP3での再現性が劣る音源で
デコーダ間の比較を行った場合、もっと差が出る可能性は
大いにありうると思う。

>>464の音質の関する１～５の主張は、確かに根拠が薄いと思うが、
J-POPなどで１曲丸ごと計測した場合に、
数値的に有意な差が可能性はあるので、
頭ごなしに否定することはできない。
＃それでも個人的には、聴いてわかるとは思えないが……
蛇足として、４の主張は>>466の結果だけを見れば、数値上は真だが、聴覚上は？
470 名前：名無しさん＠お腹いっぱい。 [2005/09/16(金) 15:27:02 ID:On9y7Xnw0]: ふと思い立った疑問なんですが、携帯オーディオプレイヤー（iPodとか）
ってやっぱり高いですよね。
ほし～な～って思ってはいるんですけどなかなか手が出なくて。
んで、こういうのないかなって思ったんですけど、
USB HDDにコントローラーみたいのをつけて音楽が再生できるっていう･･･。
こんなコントローラーがあればいいなぁ～って。
世界は広いからすでに開発中とかないんですかね♪
471 名前：名無しさん＠お腹いっぱい。 [2005/09/16(金) 15:28:44 ID:On9y7Xnw0]: あ･･･。音質スレでしたね･･･。
書くとこ間違えたっぽいですね。すみません。
472 名前：ハム左衛門 [2005/09/16(金) 21:15:30 ID:A53XF/vo0]: 取り込んだ音楽の速度変えれて（はやくしたり、おそくしたり）
音質はあまりかわらなくて、なおかつ変速後の音楽をMP3などに
ファイル化できるソフトあったらいいな～と思っている俺。
473 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/16(金) 21:50:52 ID:8JaNBsKY0]: あるよ
474 名前：460 mailto:sage [2005/09/17(土) 18:48:47 ID:zDYhxyFY0]: >>465のテストの追試をやってみた。
BlackBird.wvだけではなんともいえないため。

同URLよりすべての音源をDLして試してみようと思ったが、
MADとリファレンスデコーダはデコーダディレイ&曲長の補正が面倒なので、
全部やるのはあきらめますた……orz

そして、いくつか結果を出した後に、
Lilithがアップデートされたことに気づき、
Lilithのデータは再度取り直し。
MP3デコーダの修正が入ったみたいだが、
数値上はかなりの変化が見られた。

なお、今回対象デコーダを一部変更した。
foobar2k(mpglib)とlame(mpglib)の間に有意な差はなかったので、
foobar2kを廃止。
代わりに、同じmpg123だが、
デコードルーチンを64bitFloat化するなど音質面での強化を図った
otachan's mpg123(Winamp版)を採用した。

また、面倒なのときちんと効果が出ているのか良くわからないため、
Lilithの非SSEルーチンは測定しないことにした。
475 名前：460 mailto:sage [2005/09/17(土) 18:55:51 ID:zDYhxyFY0]: 今回試した音源は、>>450のサイトから落とせる以下のサンプル音源

BlackBird.wv
KMFDM-Dogma.wv
applaud.wv
else3.wv
Fools.wv

すべてを試すのは大変なので、450氏の測定で大きく差が出ているものをチョイスした。
なお、Lilithのアップデートに伴い、BlackBirdは再測定。
MADの結果も変わっているが、前回はディレイ&曲長補正を適当に済ませていたため、
正確な結果が出ていなかったようだ。
今回は正確な値を出せていると思う。

また、サンプル音源のほかに、手元のCDから最近のJ-POPとクラシックを１曲ずつ試してみた。
J-POPは趣味が判明してしまうので曲名は伏せるが、
クラシックはアルルの女第１組曲より第１楽章『前奏曲』を使用した。
ピアノソロとかも試してみたいが時間が取れなかった。

各プレイヤーは、結果では以下の略称で記載している。

リファレンスデコーダでの結果：ref
オリジナル音源：org
Winamp+otachan's in_mpg123(ot88)：ota
lame(mpglib)：lame
Sound Player Lilith：spl

なお、今回から参考データとして、
オリジナル音源とリファレンスデコーダの差の結果も記載することにした。
476 名前：460 mailto:sage [2005/09/17(土) 18:56:21 ID:zDYhxyFY0]: BlackBird.wv

org - ref RMS=1.3680e-3 PEAK=3.2715e-2

ref - mad RMS=1.5580e-6 PEAK=3.0518e-5
ref - lame RMS=7.9452e-6 PEAK=3.0518e-5
ref - ota RMS=7.9659e-6 PEAK=3.0518e-5
ref - spl RMS=8.2074e-7 PEAK=3.0518e-5

org - mad RMS=1.3680e-3 PEAK=3.2715e-2
org - lame RMS=1.3680e-3 PEAK=3.2715e-2
org - ota RMS=1.3680e-3 PEAK=3.2715e-2
org - spl RMS=1.3680e-3 PEAK=3.2715e-2

KMFDM-Dogma.wv

org - ref RMS=3.3448-e3 PEAK=3.8940e-2

ref - mad RMS=1.6126e-6 PEAK=3.0518e-5
ref - lame RMS=1.2521e-5 PEAK=3.0518e-5
ref - ota RMS=1.2544e-5 PEAK=3.0518e-5
ref - spl RMS=1.2135e-6 PEAK=3.0518e-5

org - mad RMS=3.3441e-3 PEAK=3.8940e-2
org - lame RMS=3.3440e-3 PEAK=3.8940e-2
org - ota RMS=3.3440e-3 PEAK=3.8940e-2
org - spl RMS=3.3441e-3 PEAK=3.8940e-2
477 名前：460 mailto:sage [2005/09/17(土) 18:57:16 ID:zDYhxyFY0]: applaud.wv

org - ref RMS=6.4451e-3 PEAK=1.0004e-1

ref - mad RMS=1.8837e-6 PEAK=3.0518e-5
ref - lame RMS=1.3766e-5 PEAK=3.0518e-5
ref - ota RMS=1.3766e-5 PEAK=3.0518e-5
ref - spl RMS=1.7125e-6 PEAK=3.0518e-5

org - mad RMS=6.4451e-3 PEAK=1.0004e-1
org - lame RMS=6.4450e-3 PEAK=1.0007e-1
org - ota RMS=6.4450e-3 PEAK=1.0007e-1
org - spl RMS=6.4451e-3 PEAK=1.0004e-1

else3.wv

org - ref RMS=3.7506e-3 PEAK=7.4219e-2

ref - mad RMS=1.6468e-6 PEAK=3.0518e-5
ref - lame RMS=1.0567e-5 PEAK=3.0518e-5
ref - ota RMS=1.0567e-5 PEAK=3.0518e-5
ref - spl RMS=1.1037e-6 PEAK=3.0518e-5

org - mad RMS=3.7506e-3 PEAK=7.4219e-2
org - lame RMS=3.7505e-3 PEAK=7.4188e-2
org - ota RMS=3.7505e-3 PEAK=7.4188e-2
org - spl RMS=3.7506e-3 PEAK=7.4219e-2
478 名前：460 mailto:sage [2005/09/17(土) 18:57:55 ID:zDYhxyFY0]: Fools.wv

org - ref RMS=2.4795e-3 PEAK=9.7443e-2

ref - mad RMS=1.6300e-6 PEAK=3.0518e-5
ref - lame RMS=1.0851e-5 PEAK=3.0518e-5
ref - ota RMS=1.0851e-5 PEAK=3.0518e-5
ref - spl RMS=1.1687e-6 PEAK=3.0518e-5

org - mad RMS=2.4795e-3 PEAK=9.7443e-2
org - lame RMS=2.4794e-3 PEAK=9.7443e-2
org - ota RMS=2.4794e-3 PEAK=9.7443e-2
org - spl RMS=2.4795e-3 PEAK=9.7443e-2
479 名前：460 mailto:sage [2005/09/17(土) 18:58:26 ID:zDYhxyFY0]: J-Pops

org - ref RMS=1.1390e-2 PEAK=2.1194e-1

ref - mad RMS=1.8311e-6 PEAK=3.0518e-5
ref - lame RMS=1.3221e-5 PEAK=6.1035e-5
ref - ota RMS=1.3222e-5 PEAK=6.1035e-5
ref - spl RMS=1.6320e-6 PEAK=3.0518e-5

org - mad RMS=1.1390e-2 PEAK=2.1194e-1
org - lame RMS=1.1390e-2 PEAK=2.1191e-1
org - ota RMS=1.1390e-2 PEAK=2.1191e-1
org - spl RMS=1.1390e-2 PEAK=2.1194e-1

Classic - L'Arlesienne

org - ref RMS=5.1195e-4 PEAK=1.4801e-2

ref - mad RMS=1.5773e-6 PEAK=3.0518e-5
ref - lame RMS=5.5242e-6 PEAK=3.0518e-5
ref - ota RMS=5.5242e-6 PEAK=3.0518e-5
ref - spl RMS=6.0866e-7 PEAK=3.0518e-5

org - mad RMS=5.1195e-4 PEAK=1.4801e-2
org - lame RMS=5.1194e-4 PEAK=1.4771e-2
org - ota RMS=5.1194e-4 PEAK=1.4771e-2
org - spl RMS=5.1195e-4 PEAK=1.4801e-2
480 名前：460 mailto:sage [2005/09/17(土) 19:24:24 ID:zDYhxyFY0]: Lilithの結果を見ると、±２以上の差が発生していたのは、
Lilithのバグだったようだ。
本日修正されたLilithでは、すべて±１に収まっている。
また、それが修正された影響か、RMSレベルが大きく下がっている。

リファレンスデコーダとの比較では、
一桁も結果が変わっている。
lame/mpg123と比べると１０倍以上、
MADと比べると２倍程度もRMSレベルが低くなり、
リファレンスへの準拠度が大幅にアップしたようだ。
481 名前：460 mailto:sage [2005/09/17(土) 19:24:58 ID:zDYhxyFY0]: リファレンスへの準拠度で採点すると、
Lilith >> MAD > lame=otampg123となったようだ。

しかしながら、リファレンスへの準拠度が高ければ
オリジナルへの準拠度も高いわけではないようだ。

たとえば、今回新たに調査した、手元にあった適当なJ-POPの結果を見ると、
lame&otaは、リファレンスとの差のピークが±２になってしまっているし、
RMSレベルもMAD/Lilithと比べて一桁違うのだが、
オリジナルとの比較を見ると、RMSレベルは誤差の範囲内で一致しているし、
ピークに関しては、オリジナルとの差がむしろ±１小さくなっている。
ピークだけを見れば、リファレンスよりもオリジナルに近い結果となった。

クラシックのサンプルでも同様の傾向が見られる。
こちらでは、RMSレベルも小さくなっており、
リファレンスデコーダよりよりオリジナルに近い結果を出している。

もっとも、この結果は小数点第５位以下で四捨五入しているので、
見た目の数字ほど大きな違いがあるわけではない。
確認のため再度計算してみたが、
四捨五入前の値の差はほとんどなかった。
（4989 と5010とか、そんな程度の差。)
もっと桁数を増やして記載すればよかったと思ったが、取り直しは勘弁。
482 名前：460 mailto:sage [2005/09/17(土) 19:30:50 ID:zDYhxyFY0]: まとめると、MADとLilithはリファレンスデコーダに非常に近いデータを吐く。
MADとLilithでは、Lilithの方がほとんどの場合精度が高い(リファレンスに近い)。
lame(mpglib)や、otachan's mpg123は、リファレンスへの準拠度はそれら２つと
かなり差がある(数倍以上違う)が、オリジナル音源との比較では誤差程度の違いしか見られない。

lame(mpglib)とotachan's mpg123は、測定不可能なレベルの違いしかない。
64bitFloatでデコードしても、最終的に16bitIntにするなら効果はまったくないということになる。
(もしかしたら、lameのmpglibも64bitFloatに変更してあるかもしれないが……
オリジナルのmpg123(mpglib)は、標準では32bitFloat)
24bitIntでDACへ生出力したり、64bitFloatでDSPを通した場合などを考えると、
64bitFloatの効果がでてくるかもしれないが。

結論としては、リファレンスデコーダの音(デコード結果)がもっとも音質の高いMP3の音とするなら、
LilithやMADの方が音質が良いということになるが、
エンコード前のオリジナル波形との差を見ると、
エンコードによって発生する誤差(劣化)に比べればほぼ皆無に等しいレベルの差なので、
実質的には音質の差はないといってよいだろう。
483 名前：460 mailto:sage [2005/09/17(土) 19:38:16 ID:zDYhxyFY0]: 最後に、これら高音質と呼ばれるデコーダの試聴インプレを書く人がたまにいるが、
次回試してみる機会があったら、今回使用したリファレンスデコーダでデコードし、
それの再生結果も比較対象に含めて欲しい。
もし、リファレンスの音が一番とまではいかなくてもかなり良いと感じたとしたら、
今回のようなリファレンスデコーダの結果との比較で、
数字でもある程度は音質を語ることができるようになる。

漏れはGolden Earの持ち主ではないので、
実際に聴いてみて、これらデコーダの音質を評価することはできない。
耳にある程度自信がある人で、この書き込みを見た人がいれば、
新しいLilithのデコーダと、リファレンスデコーダの音質を評価して欲しい。
ABXの結果を出せ、とは言わないので、是非感想を聴いてみたいものだ。
(特にリファレンスデコーダの感想)

なお、今回使用したリファレンスデコーダは、
出力ファイルがWAVE形式ではなく、RAW-PCMとなってしまう。
RAW-PCMを再生できるプレイヤーを利用するか、
何らかのツールを用いてWAVE形式に変換して利用して欲しい。

ついでに、他のサンプルや、手持ちのデータについて
誰かが計測してくれるかもしれないので、Tipsを書いておく。

・.MADとリファレンスデコーダは、LameTagに対応していないので、
　手作業でディレイと末尾の余計なデータを削除する必要がある。
・MADのディレイは1105サンプル。
・リファレンスデコーダのディレイは2257サンプル
・波形編集ソフトなどで、先頭から上記分のサンプルを削除した後、
　全体のサンプル数がオリジナルと一緒になるように、末尾を削除。
・ota/lame/lilithはLameTagに対応しているので、通常は修正必要なし。
484 名前：460 mailto:sage [2005/09/17(土) 19:55:53 ID:zDYhxyFY0]: >>481の以下の部分は書き間違え。

>リファレンスへの準拠度で採点すると、
>Lilith >> MAD > lame=otampg123となったようだ。

リファレンスへの準拠度で採点すると、
Lilith > MAD >> lame=otampg123となったようだ。

が正しいです。
連書きスマソ
485 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/17(土) 23:30:05 ID:35UrdaPh0]: >>474

お疲れ様です。
Lilithがアップデートしたことを知りませんでした。
私も暇ができたら試してみます。

デコーダディレイ＆曲長の補整には何を使っていますか？
私は sox-win を使って次のようなコマンドラインで補整しています。

original.wav のサンプル数が 123456 のとき
tmp.wav から先頭の 576 サンプルを削って、長さを 123456 サンプルに揃えるためには

sox tmp.wav trimed.wav trim 576s 123456s

私よりもパソコンの扱いに秀でている人であれば
sox と他のツールを組み合わせてこの辺の作業をかなり自動化できると思います。
486 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/17(土) 23:42:03 ID:35UrdaPh0]: >>485のつづき。

私もさらに協力者が増えると嬉しいので知っていることを箇条書きしておきます。

・ MAD を foobar2000 から使えば LAME タグを見てくれるので楽。
・ Audioactive MP3 decoder でデコードした結果は sox ～ trim 2257s が必要になる。
・ lame.exe と Otachan's mpg123 によるデコード結果は完全に一致。
・ foobar2000 (mpglib) と Otachan's mpg123 のデコード結果は極めて近い。
・ sox を使えば raw PCM を容易に WAV ファイルに変換できる。
487 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/17(土) 23:51:20 ID:35UrdaPh0]: どこで拾ったか忘れましたが wavmix.exe を次の場所にしばらく置いておきます。
ttp://anonymousriver.hp.infoseek.co.jp/tmp/wavmix.exe
誰が作ったバイナリなのか御存じの方がいれば教えて下さい。
wavmix.exe -i a.wav b.wav diff.wav で a.wav と b.wav の差を作れます。

soxmix -v 1 a.wav -v -1 b.wav diff.wav でも差を作れるのですが、
16bit linear PCM WAV では最下位1bitの誤差が出る場合がありました。
soxmix だと同じWAVファイルの差を取っても完全に0にならない場合がある！

しかし wavmix であればそういうことはありません。

sox-win も非常に便利です。次の場所からダウンロードできます。
sourceforge.net/projects/sox
488 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 00:17:09 ID:XKIBC9Ik0]: KMFDM-Dogma サンプルを LAME 3.96.1 --preset insane で圧縮した結果と
それを foobar2000 (mpglib)、foobar2000 (mad)、Sound Player Lilith 0.991b
でデコードした結果 (WavPacked) の4つのファイルを
ttp://anonymousriver.hp.infoseek.co.jp/tmp/KMFDM-Dogma.zip
にZIPにかためて置いておきました。
489 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 00:34:28 ID:XKIBC9Ik0]: >>488 で公開したデコード結果の差の Cool Edit 2000 Trial Version による計測結果
数字は左チャンネル、右チャンネルの順

(1) lilith - mad
Min Sample Value:-3-15
Max Sample Value:440
Peak Amplitude:-78.27 dB-58.27 dB
Minimum RMS Power:-157.14 dB-120.75 dB
Maximum RMS Power:-92.79 dB-82.26 dB
Average RMS Power:-103.19 dB-102.89 dB
Total RMS Power:-100.65 dB-98.38 dB

(2) lilith - mpglib
Min Sample Value:-3-15
Max Sample Value:440
Peak Amplitude:-78.27 dB-58.27 dB
Minimum RMS Power:-102.35 dB-103.03 dB
Maximum RMS Power:-93.92 dB-82.16 dB
Average RMS Power:-97.44 dB-97.23 dB
Total RMS Power:-97.3 dB-96.04 dB

(3) mpglib - mad
Min Sample Value:-1-1
Max Sample Value:11
Peak Amplitude:-90.31 dB-90.32 dB
Minimum RMS Power:-102.42 dB-103.11 dB
Maximum RMS Power:-95.87 dB-95.76 dB
Average RMS Power:-98.21 dB-98.01 dB
Total RMS Power:-98.14 dB-97.95 dB
490 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 00:37:15 ID:XKIBC9Ik0]: 数字が繋がってしまった部分をコンマを入れて再投稿します。
二重投稿になってしまうことをお詫びいたします。

>>488 で公開したデコード結果の差の Cool Edit 2000 Trial Version による計測結果
数字は左チャンネル、右チャンネルの順

(1) lilith - mad
Min Sample Value:-3,-15
Max Sample Value:4,40

(2) lilith - mpglib
Min Sample Value:-3,-15
Max Sample Value:4,40

(3) mpglib - mad
Min Sample Value:-1,-1
Max Sample Value:1,1
491 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 00:49:33 ID:XKIBC9Ik0]: 先週私が使った Sound Player Lilith は最新版だったので
インストールのし直しは必要ありませんでした。

>>476
＞KMFDM-Dogma.wv
＞...
＞ref - mad RMS=1.6126e-6 PEAK=3.0518e-5
＞ref - lame RMS=1.2521e-5 PEAK=3.0518e-5
＞ref - ota RMS=1.2544e-5 PEAK=3.0518e-5
＞ref - spl RMS=1.2135e-6 PEAK=3.0518e-5

>>489-490の結果を見ればわかるように
Sound Player Lilith (spl もしくは lilith) は
mad および mpglib (これは ota に極めて近い) の2つから
16bit整数でのピーク値で最大40も離れています。
ディザを入れてもこの40という値はやはり大きすぎます。
Average および Maximum RMS で見れば lilith と mad は非常に近い。
しかし Using RMS Window of 50 ms の Max RMS を見ると
やはり lilith だけが他と大幅に離れています。
10ms単位で大きな差が出ることを見逃してしまうような分析は
デコーダーの精度の測定としては不十分だと思います。

やはり lilith だけがデコーダーとしての精度が
他より低いという先週の私の分析は正しいのではないでしょうか？
mad と mpglib は16bit整数で最大1の違いしかないのに
それらと lilith は最大で40もの違いが生じてしまっています。
mad と mpglib が同時に偶然同じ方向に不正確になるとは思えない。
したがって lilith だけが不正確なデコードを行なっているのでしょう。
492 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 00:51:45 ID:XKIBC9Ik0]: しかし私の耳では KMFDM-Dogma サンプルで lilith と他のデコーダーのABXは不可能でした。
(これを正直に言っておかないとフェアじゃなくなる。)
493 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 01:05:55 ID:BlRzNOBg0]: soxmixで同一wavファイルで差分取っても0にならない事がある、
ってのはどの程度の頻度であるんですか?
手元で5曲ほど試してみたけどならなかったもので。
コンパイルオプションとかで変わるもんかもしれんけど。
494 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 01:23:14 ID:XKIBC9Ik0]: ftp://ftp.tnt.uni-hannover.de/pub/MPEG/audio/mpeg1/compliance/layer3.tar.gz
の中に含まれている l3dec.exe も試してみましたが、
このデコーダーによるデコード結果の終わりの方が切れてしまいます。
l3dec を使うとMP3に圧縮する前と同じサンプル数のWAVファイルを作れない。
その切れた部分にちょうど lilith と他のデコーダーの大きな差が出る部分が含まれています。
495 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 01:25:07 ID:XKIBC9Ik0]: >>493

非常にまれです。soxmixを使ってもほとんどの場合に0になるべき値が0になります。
496 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 01:28:05 ID:XKIBC9Ik0]: KMFDM-Dogma で lilith と他のデコーダーの差が大きくなるのは
圧縮前のWAVファイルと同じサンプル数にそろえたとき終わりから20ms程度の部分です。
その部分の右チャンネルで大きな差が生じている。

他の部分での差はかなり小さいのでこの部分だけ非常に変なことが起こっているんだと思う。
497 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 01:32:03 ID:XKIBC9Ik0]: l3dec.exe test.mp3 test.raw
sox -r 44100 -w -s -c 2 test.raw test.wav
とすれば test.raw を WAV に変換できます。
498 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 01:51:07 ID:EFtHSIzC0]: >>491
プレイヤー側の出力設定でも結果は大きく変わります。
それぞれの設定を示すべきではないでしょうか？
デコーダの精度云々を論議をするのであれば、他の条件を全て同じにしなければ意味がありません。
499 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 12:42:41 ID:Y1DVlM4T0]: >>491

先週？LilithのMP3デコーダのアップデートがあったのは昨日だが……
オンラインアップデートでデバッグ用云々をチェックして、アップデートして見れ。
500 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 20:55:23 ID:B3AyRvOa0]: >>449

申し訳ない。ウェブサイトの方を見て 0.991b が最新版かと誤解していました。
さっそく 0.992 にオンラインアップデート（初めて使いました！）して再テストしてみました。
結果はほとんど変化無しでした。

ピークで見ても Using RMS Window of 50 ms の Max RMS を見ても、
lilith0.992 はまだ mad と mpglib から大きく離れている。

>>498

デコードする前のMP3ファイルとデコード結果のロスレス圧縮ファイルがあれば
2人の人が異なるデコード結果に関する分析結果を述べていたことはすぐに
わかるはずです。だからこちらのファイルをすべて公開しました。

ttp://anonymousriver.hp.infoseek.co.jp/tmp/KMFDM-Dogma.zip

の内容をアップデートしておきました。このバイナリをダウンロードしても
解消しない疑問があればもっと具体的に指摘してください。
できる限り答えるようにします。
501 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 21:02:22 ID:B3AyRvOa0]: デコード結果の差の分析結果 (by Cool Edit 2000 Trial Version)

(1) diff_KMFDM-Dogma_lilith0.992_and_mad.wav

Min Sample Value:-3,-15
Max Sample Value: 4, 39
Peak Amplitude: -78.27 dB, -58.49 dB
Minimum RMS Power: -152.82 dB, -146.33 dB
Maximum RMS Power: -101.63 dB, -82.42 dB
Average RMS Power: -115.69 dB, -115.49 dB
Total RMS Power: -114.62 dB, -102.61 dB

(2) diff_KMFDM-Dogma_lilith0.992_and_mpglib.wav

Min Sample Value: -2, -15
Max Sample Value: 4, 39
Peak Amplitude: -78.27 dB, -58.49 dB
Minimum RMS Power: -102.36 dB, -103.04 dB
Maximum RMS Power: -95.86 dB, -82.31 dB
Average RMS Power: -98.2 dB, -98.01 dB
Total RMS Power: -98.12 dB, -96.73 dB

コメント： Min and Max Sample Values と Max RMS Power (Using RMS Window of 50 ms)
を見れば lilith0.992 と他のデコード結果は局所的に大きな違いが出ていることがわかる。
大きな差は終わりから20msの特に右チャンネルで発生していることが波形を見るとわかる。
502 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 21:04:57 ID:B3AyRvOa0]: (3) diff_KMFDM-Dogma_mpglib_and_mad.wav

Min Sample Value: -1, -1
Max Sample Value: 1, 1
Peak Amplitude:-90.31 dB, -90.32 dB
Minimum RMS Power: -102.42 dB, -103.11 dB
Maximum RMS Power: -95.87 dB, -95.76 dB
Average RMS Power: -98.21 dB, -98.01 dB
Total RMS Power: -98.14 dB, -97.95 dB

(4) diff_KMFDM_lilith0.992_and_lilith0.991b.wav

Min Sample Value: -3, -3
Max Sample Value: 3, 3
Peak Amplitude:-80.77 dB, -80.77 dB
Minimum RMS Power: -148.69 dB, -158.04 dB
Maximum RMS Power: -92.8 dB, -92.72 dB
Average RMS Power: -104.47 dB, -104.18 dB
Total RMS Power: -100.8 dB, -100.49 dB

コメント： mad と mpglib の差を Average, Total RMS で比較すると結構大きいが、
Min and Max Sample Value を見ると mad と mpglib の差は±1におさまっている。
liith0.992 と 0.991b では最大で±3の違いが生じている。
503 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 21:21:49 ID:MmkGvyG60]: (5) diff_KMFDM-Dogma_lilith0.992_and_audioactive1.1.4.wav

Min Sample Value: -3, -15
Max Sample Value: 4, 39
Peak Amplitude:-78.27 dB, -58.49 dB
Minimum RMS Power: -172.77 dB, -153.59 dB
Maximum RMS Power: -101.63 dB, -82.43 dB
Average RMS Power: -119.03 dB, -119.41 dB
Total RMS Power: -116.92 dB, -102.74 dB

(6) diff_KMFDM-Dogma_mad_and_audioactive1.1.4.wav

Min Sample Value: -1, -1
Max Sample Value: 1, 1
Peak Amplitude: -90.3 dB, -90.3 dB
Minimum RMS Power: -153.74 dB, -151.26 dB
Maximum RMS Power: -112.29 dB, -111.45 dB
Average RMS Power: -116.28 dB, -116.08 dB
Total RMS Power: -116.02 dB, -115.84 dB

(7) diff_KMFDM-Dogma_mpglib_and_audioactive1.1.4.wav

Min Sample Value: -1, -1
Max Sample Value: 1, 1
Peak Amplitude:-90.31 dB, -90.31 dB
Minimum RMS Power: -102.39 dB, -103.03 dB
Maximum RMS Power: -95.83 dB, -95.73 dB
Average RMS Power: -98.19 dB, -98 dB
Total RMS Power: -98.13 dB, -97.94 dB

コメント： Audioactive MP3 Decoder 1.1.4 を追加しても傾向は同じ。
504 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/18(日) 21:37:58 ID:2ddO5TjD0]: 繰り返しになりますが、もしも小数点以下の丸め誤差だけが原因ならば
デコード結果のあいだの差は16bit整数で±1におさまるはずです。
mad、mpglib、audioactive1.1.4 のあいだの関係は確かにそうなっている。
しかし lilith0.992 だけは特に右チャンネルで他と最大39もの違いが生じています。
この39という数字は大きすぎるので Sound Player Lilith 0.992 の
MP3 デコーダーの数学的精度にはかなり疑わしい部分があると思います。

Average、Total RMS で見ると mad、audioactive1.1.4、lilith0.992 の差が小さいのは
ディザをかけているからでしょう。
505 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/19(月) 00:14:14 ID:wbiReRBlO]: 測定条件を示さない者の言葉に力はない。

・デコード結果はどのように検出したのか？
・使用デバイスドライバは何か？
・リサンプリング、ディザ等の処理は掛けているのか？
・出力ビット深度は幾つに設定したのか？
・内部演算精度は？

これらの条件を各々について示すことができなければ、あなたの主張はただの詭弁でしかない。
506 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/19(月) 11:46:02 ID:s60S21V80]: >>505

質問する前に各デコーダーに関して調べてみましたか？
あと過去ログを十分に読みましたか？
バイナリをダウンロードして
自分でデコードした結果とバイナリ比較してみましたか？
そもそもデコードの手続きを自分でしたことがありますか？
これらの質問にすべて「Yes」と答えることができない人は
質問するのを控えてくれた方がありがたいです。
507 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/19(月) 11:46:42 ID:s60S21V80]: >>505

まず Sound Player Lilith (以下SPLもしくはlilith) 0.992 のMP3デコーダー
の使い方について

＞・デコード結果はどのように検出したのか？

「検出」の意味がよくわかりません。
MP3デコーダーとはMP3ファイルを linear PCM ファイル
(通常はWAVファイルにする)に変換するプログラムのことです。
プレーヤーとデコーダーを厳密に区別できる人以外に
現在このスレで進行中の話題を理解することは不可能でしょう。
そういう人は実際にプレーヤーとは別にデコーダーを実際に使ってみて
デコーダーとプレーヤーの違いを理解してから、
話題に参加して欲しいと思います。

念のために SPL 0.992 のMP3デコーダーの使い方を解説しておきます。

SPL 0.992 を起動→マウス右ボタンで「ファイルの変換」を選択
→「ファイルの変換 -> RIFF PCM WaveFile」の窓にMP3ファイルをドラッグ＆ドロップ
→「開始」ボタンを押す
508 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/19(月) 11:48:35 ID:pAuT3O7s0]: >>505

＞・使用デバイスドライバは何か？

この質問はナンセンス。デコーダーとデバイスドライバは無関係です。
その後の質問にも同じ誤解が混じっているようですが、答えておきます。

＞・リサンプリング、ディザ等の処理は掛けているのか？

バイナリをダウンロードしていれば
リサンプリングしていないことがわかるはずです。
リサンプリングせずに比較する程度のことは
当たり前のことなので説明はサボらせて欲しいです。

しかし一つだけ訂正しておきます。SPLの設定はデフォルトのままなので、
「サウンド出力」の設定の項目の「ディザリングを使用」の項目はオフでした。
それなのにMADやAudioactiveに近いのは不思議な感じがします。

＞・出力ビット深度は幾つに設定したのか？

「サウンド出力」の設定の項目では「16bit」に設定されています。
この設定はデコーダーと関係あるのですか？

デコード結果はどれも 16bit/44.1kHz linear PCM Wave ファイルになっています。

＞・内部演算精度は？

「サウンド出力」の「出力周波数」の設定項目は関係ありません。
SPLにはデコーダーの内部計算精度を設定する項目はないと思います。
509 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/19(月) 11:58:26 ID:pAuT3O7s0]: 私は Sound Player Lilith のMP3デコーダーの精度が
かなり疑わしい証拠を提出しているつもりです。
しかし私は SPL のことを十分に理解しているわけではありません。
だから色々疑問が出るのは当然だと思います。

こういう場合には
SPL のMP3デコーダの精度が高いと信じている人の側が
SPL を使ってデコードした結果を公開して、
そのデコード結果をみんなで分析すれば、
SPL を支持する側にとってフェアな議論になると思います。

ttp://anonymousriver.hp.infoseek.co.jp/tmp/KMFDM-Dogma.zip
に入っている KMFDM-Dogma.mp3 を SPL でデコードして作った
16bit/44.1kHz Stereo の Wave ファイルもしくはそのロスレス圧縮ファイル
(WavPack、FLAC、APE のどれかを希望) をどこかにアップロードしてくれれば
実際にそうできるので良いと思います。
510 名前：460 mailto:sage [2005/09/19(月) 17:51:02 ID:8y71DK2f0]: 460です。
リファレンスデコーダは、KMFDM-Dogmaで、末尾がデコードされないのは気づいていました。
が、異常が見られたのがその部分とは知らなかったので、
出てきた分だけ測定していました。

なお、KMFDM-Dogma以外のサンプルでは、末尾が切れることはありませんでしたので、
結果は正確だと思います。

で、あらためてKMFDM-Dogmaを測定したところ、
(リファレンスが使えないので、デコーダ間の比較)
450氏の結果どおり、Lilithは末尾に異常が認められました。
おそらくLilithのバグではないかと思います。

Lilithの作者さんは、先日のMP3デコーダの修正のタイミングなどから推測して、
おそらくこのスレをチェックしているものと思われますので、
この件についての修正が近々入るのではないかと期待しています。

複数のサンプルでの測定結果からすると、
おそらく特定のフレームにおける不具合ではないかと思われますので、
KMFDM-Dogma以外のサンプルにおける測定は、信頼できるデータであると思われます。

なお、測定条件などを示せとのことですが、
利用した各デコーダの設定は以下のとおりです。

Lilith：デフォルトのまま(16bitInt出力/ディザなし)
MAD：16bitInt出力/ディザなし(--no-ditherオプション使用)
ota：16bitInt出力(ディザはないはず)
lame：デフォルト(16bitInt出力/こちらもディザはないはず)
511 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/19(月) 20:29:55 ID:0GGamdJE0]: wavesの体験版使ってみたいんですが、>270さんの言うとおりL2というのを使うんでしょうか。
それともこれはCD同等とあるってことは圧縮音源再生時の話？

音楽CDを高音質で再生したいと思っています。

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef