【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/
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を高音質で再生したいと思っています。
512 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/19(月) 23:38:31 ID:gzckih010]: >>507
>デコーダーとプレーヤーの違いを理解してから、話題に参加して欲しいと思います。
それは常識というものですよ。わざわざ問い質される必要はないのでは？

>「検出」の意味がよくわかりません。
質問の趣旨が分かりづらくて申し訳ない。デコード結果をどの時点で取り出しているのかを知りたかっただけです。
例えば、WaveSpectraのようなツールを使いデコード結果を取り出したのであれば、
当然、デバイスドライバを経由するため、デバイスドライバの精度や出力ビット深度等が関係してくるわけです。
しかし、ファイル変換機能を利用されたのであれば、デバイスドライバや出力ビット深度等の影響はないでしょう。

各デコーダにおける精度等の分析は、今度、時間がある時にでもやってみようかと思います。
ちなみに、私はSPLを支持しているわけではありません。論理的に示された真実が知りたいだけです。
513 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/20(火) 00:16:34 ID:4Aj+JuFV0]: >>512

常識がわかっていればデコーダーのテストに
デバイスドライバが無関係であることは当然わかっているはずです。
デバイスドライバが関係あると思っている時点で
話題についてきていないことがばればれです。

あとこちらはわざわざ手間ひまかけてかなりのテストしている上に
追試に必要なMP3ファイルなどのバイナリまで公開しています。
それによって私の主張を反証しようと思えば誰にでも可能なんですね。
デコード結果のロスレス圧縮ファイルまで公開しているので
私のデコーダーの使い方に問題があるならば誰にでもそのことを証明可能です。
ttp://anonymousriver.hp.infoseek.co.jp/tmp/KMFDM-Dogma.zip

議論で熱くなって激しい発言をするのは雰囲気が出て良い場合がありますが、
再検証や反証に開かれた発言を詭弁呼ばわりするのは絶対にまずいです。
そういう態度では「論理的に示された真実」など永久に知ることは不可能です。
口先だけの真実追求と本気の真実追求の違いを早く悟るべきですね。
514 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/20(火) 01:26:08 ID:2os/YaeT0]: >>513
>デバイスドライバが関係あると思っている時点で、話題についてきていないことがばればれです。

あなたは、デコード結果の取り出し方法について一切触れていなかった。
>>512に示したように、WaveSpectra等を用いてデコード結果を取得した場合には、デバイスドライバを介すため、
デバイスドライバの精度やデータの受け渡し方法などが関係してくる。

あらぬ誤解を生まぬためにも、測定環境及び測定条件・方法を示すべきではないでしょうか？
匿名掲示板という特性ゆえ、全てをオープンにしない限り、閲覧者の納得は得られないと考えます。
少なくとも、自分の主張を他人に検証させるのであれば、持てる情報の全てを提示するのがマナーではないでしょうか？
515 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/20(火) 12:47:22 ID:NHhphvaO0]: >>514

常識があれば Sound Player Lilith のデコーダーを
「ファイルの変換」経由で使ったことは言わなくてもわかるはずです。
しかも、私が示した過去ログの数字も見てなければ、
せっかく公開したデコード前およびデコード後のファイルも調べていない。

もしもデバドラ経由で「録音」したファイルであれば
SPL と他のデコーダーの差があんなに小さな数字なるはずがない。
さらに私が公開したファイルをダウンロードしてチェックしても
SPL の「ファイルの変換｣経由でデコードしたことがわかるはずです。

foobar2000 (mad) と foobar2000 (mpglib) のあいだの違いは
16bit整数で±1におさまっているのでデバドラ経由で録音したもので
あるはずがない。こちらについてもバイナリ比較が同様に可能です。

>>514さんはこの話題に全然ついてこれていません。
せっかく私なんかよりも(私は大した知識を持っていない)明らかによくわかっている方が
検証に参加して下さっているのに水を差さないで下さい。

現実には持てる情報のすべてを公開することは手間がかかりすぎるので不可能。
可能であっても面倒なので問題がない程度に手抜きをしたい。
デコード前のMP3ファイルとデコード結果のロスレス圧縮ファイルを公開して
細かい説明に関しては手抜きをさせてくれても良いじゃないですか？
それによって十分に再検証可能性や反証可能性が確保できます。
>>514さん以外のよくわかっている人であれば
そのデータをもとに再検証なり反証なりを自由にできる。
私の分析に重大な落ち度があればすぐに明らかになるはずです。

この程度の些細な手抜きを責めたいならばまずおまえ自身が分析結果を発表してくれ。
「詭弁」という言葉を使ったことを早く謝罪して自分の無知と誤りを認めて下さい。
516 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/20(火) 13:05:54 ID:NHhphvaO0]: もう少し詳しく説明しておきましょう。

この議論の主題は「Sound Player Lilith (SPL) のMP3デコーダーと
他の定評あるデコーダーとの差がどれくらい大きいか」です。

経験的に定評あるデコーダー (foobar2000 (mpglib)、foobar2000 (mad)、Otachan's mpg123、
Audioactive など) のあいだにはほとんどの場合にデコード結果の差の最大値は
16bit整数で1におさまります。厳密には各デコーダーのバージョンや設定を細かく説明する
必要があるのですが、この議論のためにはそこまで厳密な情報は必要ない。
なぜならばこれらのデコーダーは十分に枯れており(安定しており)、
ちょっとぐらいバージョンナンバーなどが違っていても
結果に大きな違いは出ないと考えられるからです。

デコーダーのテストで特に問題になるのではデコード前のMP3ファイルが何であるかです。
同一のWaveファイルを同じソースファイルから作った同じバージョンのエンコーダーの
同じ設定でエンコードしても、コンパイラーなどが違うとエンコード結果は等しくなりません。
だから、このような微妙な試験ではエンコード前の音源だけではなく、
エンコード後のMP3ファイルも公開される必要があります。
私がMP3ファイルも公開したのはこのような理由があるからです。

完全に同一のMP3ファイルを共有していればデコーダーのテストに関する疑いの
一部を晴らすことができます。共通のMP3ファイルさえあれば各自が自分で
私の主張を検証もしくは反証することができます。

私が最初から公開されていた音源でテストを始めたのも
誰でも自分なりの検証および反証をできる可能性を確保しておきたかったからです。

私が以上のような気の使い方をしていたことを理解せずに
「詭弁」などと非難されるのはちょっと困ります。
517 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/20(火) 18:22:43 ID:AVFfYMZy0]: LAME 3.96.1 --preset insane (= -b 329) だけではなく、複数のエンコーダーを試してみました。

以下 foobar2000 0.8.3 mpglib (= foobar2000 のデフォルトのMP3デコーダー) と
Sound Player Lilith 0.992 によるデコード結果の差のピーク値が1以下か
ずっと大きいかだけを問題にします。圧縮前の音源は KMFDM-Dogma.wav です。

(1) LAME 3.96.1 --preset standard
Peak(lilith0.991b - mpglib) = 40
Peak(lilith0.992 - mpglib) = 39

(2) FIIS MP3 Codec (pro) MP3 Codec Version 3.3.44, acmenc -p fiis-pro -b 320
Peak(lilith0.992 - mpglib) = 1

(3) 午後のこ～だ 3.13, gogo.exe -b 320
Peak(lilith0.992 - mpglib) = 37

(4) Helix MP3 Encoder R12 ICL9, hmp3enc -B160 -U2
Peak(lilith0.992 0 mpglib) = 1
518 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/20(火) 18:25:07 ID:AVFfYMZy0]: 以上の(2)のMP3ファイルのサウンドスペクトログラムを見ると
16kHz以上がほとんどカットされており、(4)では完全にカットされている。

(5-1) LAME 3.96.1 -b 320 --lowpass 15000
Peak(lilith0.992 - mpglib) = 1

これで LAME を使っても 15kHz のLPFを入れれば
lilith0.992 と mpglib の差のピーク値が1におさまることがわかった。

(5-2) LAME 3.96.1 -b 320 --lowpass 16000
Peak(lilith0.992 - mpglib) = 38

以上の結果から示唆されることは Sound Player Lilith 0.992 のMP3デコーダーでは
16kHz以上の成分に関わる計算で精度が落ちているのではないかと推測できる。

追試に必要なMP3ファイルなどは次の場所からダウンロードできます。
ttp://anonymousriver.hp.infoseek.co.jp/tmp/KMFDM-Dogma.zip
519 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/20(火) 21:01:25 ID:jYyrsL3A0]: >>518の続き

と思ったのですが、よく見直してみると LAME 3.96.1 -b 320 --lowpass 15000 で
作った MP3 ファイルは32kHzにリサンプリングされていた。これはまずいと思って
さらに --resample 44100 を追加して調べてみた。

(5-3) LAME 3.96.1 -b 320 --lowpass 15000 --resample 44100
Peak(lilith0.992 - mpglib) = 38

だから >>518 に書いた推測は誤りです。
LAME との相性が問題なのか？
しかし他のデコーダーは互いに最下位ビットの違いを除いて同じデコード結果が得られる。
これで原因がまったくわからなくなった。

ttp://anonymousriver.hp.infoseek.co.jp/tmp/KMFDM-Dogma.zip
もアップデートしておきました。
520 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/20(火) 22:43:13 ID:2os/YaeT0]: >>515
>常識があれば Sound Player Lilith のデコーダーを「ファイルの変換」経由で使ったことは言わなくてもわかるはずです。

それは怠慢というやつです。
不特定多数の方が閲覧している掲示板だからこそ、前提条件は誰にでも分かるように明記しておく必要があるのです。
それが理解できないあなたは非常識ではないでしょうか？
ここはあなたの日記帳ではありません。

>もしもデバドラ経由で「録音」したファイルであれば、SPL と他のデコーダーの差があんなに小さな数字なるはずがない。

なぜ、そう言えます？何か確たる証拠でもお持ちなんですか？もし、そうならその証拠を示しなさい。
安易な予測に基づく発言は、あなたが仰っている「本気の真実追求」の妨げになりますよ。

今までのあなたの発言を見ると、どうも基本的なことを理解されてないように思えます。
いいですか、デバイスドライバへのデータの受け渡しが適正に行われていれば、
ファイル変換機能を利用したデコード結果と完璧に一致します。
ですから、当然、SPLと他のデコーダ間で差が大きくなるということはないのです。
話題に「全然ついてこれていない」のは、あなたの方ですよ。

>この程度の些細な手抜きを責めたいならばまずおまえ自身が分析結果を発表してくれ。

あなたにお前呼ばわりされる覚えはありません。
あなたは初対面の人にお前と呼ぶのですか？
匿名性の高い掲示板だからと言って、何を言っても構わないというものではありません。
節度を弁えた発言を望みます。
521 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/20(火) 23:11:50 ID:jYyrsL3A0]: >>520

あとは読者の判断にまかせましょうかね。

こういう人には何を言ってもどうせわかってもらえない。
真実が知りたいというのは口先だけ。
私のように知識が無いところを努力して
テスト結果を発表するというようなことを決してしない。
疑問があっても絶対に自分でテストをしてみない。
デコーダーのディレイの正確な数字を見付ける面倒さの類も
一切知らずに文句をつけるだけ。

ちなみに波形の差を取ってどれだけキャンセルするかを調べる場合には
完璧な精度が必要です。数万分の1秒のずれも許されない。
実際に実験してもすぐにわかることです。
デコード結果の違いの検証のためにはそれくらいの精度が必要になります。
もちろん時間軸方向の精度だけではなく、振幅方向の精度も重要。
デバドラ経由させて録音なんてしたら（以下略）

まあ実際にやってみればわかりますよ。
誰でもテストしてチェックできることについて
詳しく説明していないから駄目だと言われて困るんだよねえ。

もしも自分でテストしたいがテストの方法が
わからない場合には頭を下げて質問すればよい。
>>520さんのような人は他人を「詭弁」だと非難する前に
自分の無知を認識して質問するようにしないと駄目。

私は自分が無知でミスで犯しやすいと思っているので、
テストに使ったファイルをできるだけ公開するようにしている。
522 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/20(火) 23:37:27 ID:PdOk4JcK0]: >>521
> あとは読者の判断にまかせましょうかね。

読者はおまえをキチガイだと思ってる。
いい加減にしろ！
523 名前：名無しさん＠お腹いっぱい。 [2005/09/20(火) 23:50:18 ID:jYGpgT6YO]: >>521は絶対に友達にしたくないタイプだな。
524 名前：久々に見たら変なことになってんな… mailto:sage [2005/09/21(水) 01:03:24 ID:CH1zQKpo0]: スレの流れからすると
Lilithが一番音質適評価が高いという通説を信じられないから否定したいだけのように思えるのですが…

以下が>>520の主張したこと
Lilith以外のデコーダーがピーク値において「互いの差が最下位1bit程度の範囲」に収まっており、
Lilith以外のデコーダーは「精度が低いにもかかわらず、どれも同じ方向にずれて」いることは「信じられないこと」
であるから「Sound Player Lilith (SPL) のMP3デコーダー」のデコード精度が低いのではないか？

そもそも、何回も使われている「精度」というものは何に対しての精度なのか？
そして、ピーク値とはどのくらいの数学的精度をもってして「精度」が「高い」または「低い」と言えるのか？
理想的に「精度」の「高い」基準値とはどのくらいなのか？具体的にKMFDM-Dogmaにおいて理想とすべきピーク値とは？

ピーク値が音質にどのように影響を与えるかもわからないし、それがどうあるべきかもわからない状態で
ピーク値がLilithだけ40弱違うと声高らかに叫んだところで、意味がないと思う（すくなくとも私は両方ともわからない）

数値で語りたいのならば、その数値が明確に音質に影響を与えることをまず述べるべきです
このことが自明の理でないのならば、我々は値を比べる前に、
音質に関係あるその値を計算する「優秀な」アルゴリズムに関して勉強しなくてはいけない

ここは音質について語る場所なのに、ピーク値が違うことが音質に関係あるのかわからない状態でスレを消費していくのは見るに堪えない
デコーダーの出力結果を比較し、ABXテストをしてわからなければどれを使っても満足できるという結論では不満なのでしょうか？
もし、>>520さんがLilithのピーク値が他のデコーダーと違う理由、または他のデコーダーとのアルゴリズム的な違いなどを
知りたいのならばLilithの作者に尋ねた方が、我々で議論するよりも何百倍も早く結論が得られるでしょう

以下チラシの裏
私が大学時代、実験レポートを書く前に教授からこういわれました
「たとえどんな簡単な実験だろうと『全く同じ実験を小学生が読んでもできるように』書きなさい」
会社に入ってからもこの言葉を時々思い出します
525 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/21(水) 01:06:15 ID:HhOLklM50]: 何が玉子を、このような気違いじみた行動に駆り立ててるのかな？
正に狂人だなｗ
526 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/21(水) 01:22:05 ID:HhOLklM50]: >>524
>>520がどうのこうのと書いてるけど間違ってないか？
Lilithのデコード精度云々といってるのは>>520ではなくて
玉子だよ。
527 名前：460 mailto:sage [2005/09/23(金) 21:11:21 ID:+iqMFTQE0]: 460です。
Lilithのデコーダが再度アップデートされたようです。
なんかスレの方向性が変な方向へ行ってしまっているようなので、
とりあえず、KMFDM-Dogmaのピーク比較結果だけ。

lame/otaとの間で比較してみましたが、±１の範囲に収まりました。
RMSは測定していません。
やはりLilithのバグだったようです。
BBSのコメントを見ると、稀に起こるバグだったそうで。

なお、デコード元MP3データは、
>>519のURLからDLしたアーカイブの中に入っていたものを使いました。
そちらでも追試してみてください。
528 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/23(金) 23:29:05 ID:0Y8N9Wjl0]: >>527

情報どうもありがとうございます。これからこちらでも追試してみます。
529 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/09/24(土) 00:03:30 ID:ErmGwBCZ0]: 追試終了。あまりの完璧な仕事に背筋に電流が走りました。素晴らしいのひとこと！

せっかくここまでしてもらっているので再度
lame.sourceforge.net/gpsycho/quality.html
からダウンロードしたすべてのサンプル音源で試してみました。

1. それらのサンプル音源を LAME 3.96.1 --preset insane でエンコード。
2. 比較したのは foobar2000 の mpglib と MAD および Sound Player Lilith でデコード。
3. これで書くサンプル音源ごとに3つのWAVファイルができたのでそれらの差のWAVファイルを作成。
4. WaveGain.exe -c で差のWAVファイルのピーク値を計測。

その結果 Peak の欄には見事に 1 が並びました。（それを見た瞬間に背筋に電流が走った！）
................
1 = Peak(diff_KMFDM-Dogma_lilith20050920_and_mad.wav)
1 = Peak(diff_KMFDM-Dogma_lilith20050920_and_mpglib.wav)
1 = Peak(diff_KMFDM-Dogma_mpglib_and_mad.wav)
...............
ただし一つだけ以下の例外がありました。
1 = Peak(diff_applaud_lilith20050920_and_mad.wav)
2 = Peak(diff_applaud_lilith20050920_and_mpglib.wav)
2 = Peak(diff_applaud_mpglib_and_mad.wav)
もともと Sound Player Lilith のMP3デコーダーはMADに
近かったのでこれは納得できる結果です。

素晴らしい！
530 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/02(日) 01:12:45 ID:6YlsOC/G0]: iTunes 5 のMP3デコーダも上と同様の方法でテストしてみました。

foobar2000 MAD と Sound Player Lilith の最新MP3デコーダの2つと
iTunes 5 によるデコード結果のあいだに16ビット整数で最大 2 の違いが生じる
場合が過半数もありました。

しかし、foobar2000 mpglib と iTunes 5 のデコード結果の違いは最大 1 におさまっていた。

foobar2000 mpglib、foobar2000 MAD、Sound Player Lilith の中の任意の2つの組み合わせの
違いは例外の applaud を除いて最大 1 におさまっていました。

これらの結果は
foobar2000 MAD、Sound Player Lilith の最新MP3デコーダ、foobar2000 mpglib の方が
iTunes 5 のMP3デコーダよりもほんの少し正確である可能性が高いということを示唆しています。
なぜならば十分に正確なデコーダーによるデコード結果の違いは最大で 1 におさまるはずだからです。

しかしこの程度の差であればおそらく通常の試聴環境では区別できないと思う。
ABXに成功した人がいるならば反論大歓迎。
531 名前：名無しさん＠お腹いっぱい。 [2005/10/03(月) 17:27:59 ID:bg/4AaQ20]: なんか使えば100%劣化する皮下逆圧縮MP3の話ばっかりだけど、
WAVやAIFFなんかの非圧縮はどれが一番音がいいのさ？
LilithもFooBarもiTunesもWMPもWinampも一緒かよ？
532 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/03(月) 17:45:04 ID:4Q1X9obN0]: >>531
ASIOのサウンドカードなら同じじゃね？
533 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/06(木) 01:47:09 ID:J8EVyBS8O]: PTLEだな
534 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/06(木) 20:02:08 ID:25sVCGPY0]: 初心者ですんません。
PCにCDをとりこむようになって、ミニコンポ処分してしまったんだけど、
WAVで取り込んでも、逆に音が喧嘩してるみたいで騒音にしか
聞こえないことがあります。
ミニコンポでもそれなりに柔らかげに聞こえてたと思うんですが、
やはりそれなりの一般的なPCだと、そこいらのCDラジカセの方が
まし、見たいな感じなんですかね？
535 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/06(木) 21:43:47 ID:Moebzm3o0]: >>531

クリッピングが起こっていないかどうかを udial サンプルでチェックしてみな。
ttp://www.hydrogenaudio.org/forums/index.php?showtopic=9772
プレーヤーとその設定とサウンドカードの組み合わせが問題になる。

私は foobar2000 で 48kHz にリサンプル (SSRCを使う) して
再生するようにしてクリッピングが起こるのを止めた。
udial サンプルについてはそれではっきり良くなったが、
普通に音楽を聴いている分にはどう音質が変わったかまったくわからん。
udial 以外に効果がわかるサンプル音源があれば紹介希望。
536 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/17(月) 00:10:30 ID:rwkS7U7i0]: コントロールパネルのサウンドとオーディオデバイスの、
スピーカーの設定って、ちゃんと環境に合わせたほうがいいの？
っていうかあれ、どんな影響があるものなの？
537 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/22(土) 22:09:04 ID:q1CzWOIg0]: ONKYOのMA-700Uについてきた
CarryOn Musicの音が好きです
クリアに聴こえるよ
538 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/23(日) 21:44:15 ID:3lPiiIHH0]: iAODIOとipodminiだと音質はどっちが良いですか？
教えてください。
539 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/23(日) 22:22:11 ID:b53wXBrG0]: 板違い
ポータブルAV板かデジタルモノ板でどうぞ
540 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/23(日) 23:47:32 ID:3lPiiIHH0]: >>539
すみません。そっち逝ってきます
541 名前：名無しさん＠お腹いっぱい。 [2005/10/24(月) 00:46:00 ID:6cbCQLLw0]: iAudioだろうな
それにしてもスレタイ紛らわしいか？
542 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/24(月) 01:21:09 ID:r/35uU+E0]: ソフトウェア板なんだから分かりそうなもんだけどな
543 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/31(月) 21:27:20 ID:gffzO1jv0]: 最近ネットラジオ聴き始めたんだけど
オススメのプレイヤーはある？httpのmp3 steaming再生で。
出来ればタイトルを表示できて評価のあるデコーダを使ってるのが良い。
ホントはfoobarで出来るからこれでもいいんだけど最近自分のPC（PII400）では
mp3をfoobarで再生するには比較的負荷が高い事に気付いたんで他のも試してみたい。

自分で試したプレイヤーを報告しておくと
lilithとmadplayは対応して無かった。mpg123は再生出来たけどタイトル表示が出来ない。mpg321も同様。
audioactiveはポート指定無しにすれば出来たと思うけどタイトルに対応してなかった。winplay3とunreal player2は
streaming再生には対応してるんだけどやり方が不味いのか無理だった。
foobarとwinamp、ituneは対応してる。

こんな感じです。
544 名前：名無しさん＠お腹いっぱい。 [2005/11/03(木) 01:42:34 ID:Bqz928FW0]: ここ最近人こないから他で聞いたほうがよさげ
ちなみに音質スレです
545 名前：553 mailto:sage [2005/11/04(金) 16:00:06 ID:k/czDawX0]: >>554
わかった。そうする。

>>ちなみに音質スレです
スマソ。後で気付いたけどプレイヤー総合スレでもあるから大丈夫かと思って･･･

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

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