アカウント名:
パスワード:
> ちなみに、AIFFとWAVではエンディアンも異なる。
ビッグエンディアンのほうが演算素子の回路構成やメモリへのデータ格納イメージが堂々と力強いので、堂々と力強い音楽に向いています。一方、リトルエンディアンは、繊細でこまやかな表現に優れています。
とすると、エンディアンを選択できるフォーマットが最強のように思えますが、選択機構のところがノイズ源になるので避けるべきというのが常識です。
しかし、エンディアンが音質に与える影響はないとは言えないんじゃないかな。どっちも再生できる機器の場合、どこかでスワップ処理してるのは確かなんだから、バッファのサイズによっては不具合が生じてもおかしくない。つまり、ソフトウェア的に同一ではない場合、片方だけバグがあるってことは有り得るんじゃないの。
あるいは、どっちかがヘッダの処理を間違えているとか、コンバーターの実装が狂っていて数十バイトの情報すら正確に写し取れないとか。無圧縮でも丸めちゃうとか。
おっしゃるとおり、エンディアンの変換には時間がかかりますし、バグがつきものです。たとえば、Z80の場合で、HLレジスタに16ビットデータが入っている場合、LD A,HLD H,LLD L,Aで16ビットデータの上位・下位8ビットが交換できます。
まず時間について考えてみましょう。それぞれ4クロックの時間がかかりますので、全体で12クロックです。クロック4MHzのZ80Aの場合、3マイクロ秒かかることになってしまいます。100,000Hzくらいの音を聞くことができる人にとっては、これは致命的なことです。現代的なCPUはクロックがGHz程度ですので、100,000,000Hzくらいの音を聞くことができる人にとって、やはりこれは致命的な問題です。
次に、バグの問題について考えてみます。データの上位・下位の交換には上記のように3行にもわたるプログラミングが必要です。さらに、データが32ビットの場合には6行、64ビットの場合には12行ものプログラミングが必要です。このように長いプログラムをまったくバグなしで行うのは、長いデスマを乗り越えてきて睡眠不足が極限まで積み重なったプログラマにとっては、過酷な要求です。なお、現代的なCPUはデータ交換命令を持っていて、従来では3行必要なプログラムを1行で表現できる可能性もありますが、CPUそのものにハードウェア的なバグがある可能性がありますので、使用を避けた方がいい場合も考えられます。ですので、バグの可能性はあると考えた方がよいでしょう。
つまり、結論として、エンディアンの変換による音質への影響はあると考えるべきです。
スワップそのものじゃなくて、バッファのとり方の問題ね。
仮に片側1サンプルのビット数が16だったとして、16ビットごとにスワップするならバグも遅延もないかもしれないけれど、多分そういう作りにはなってない。だって、圧縮音源も同様に再生できなきゃいけないから。生データ(不揮発)をデコーダに流してメモリに展開してから、そのバッファを音響ハードに食べさせるっていう処理をしているはず。で、デコーダがスワップしてれば遅延とかは生じないだろうけど、
be+無圧縮：生→バッファ→ハードbe+圧縮 :生→デコーダ→バッファ→ハードle+無圧縮:生→バッファ→スワップ→ハードle+圧縮 :生→デコーダ→バッファ→スワップ→ハード
で、スワップのところが混みすぎたらってこと。一見、le+無圧縮の実装がおかしいようにも見えるけど、多分、本当に問題なのはデコーダが可変長leで吐くかもしれないってところにあるんだと思う。
ないない。
be+無圧縮：生→デコーダ→バッファ→ハードbe+圧縮 :生→デコーダ→バッファ→ハードle+無圧縮:生→デコーダ→バッファ→ハードle+圧縮 :生→デコーダ→バッファ→ハード
何のためのデコーダなのよ、と。ビット数・チャンネル数・サンプリングレートの違う音声をソフトでミキシングするんなら、もう一段バッファかませて処理を行うことはあるかもしれませんが。エンディアンは後にとっとく意味がないです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
エンディアン (スコア:5, おもしろおかしい)
> ちなみに、AIFFとWAVではエンディアンも異なる。
ビッグエンディアンのほうが演算素子の回路構成やメモリへのデータ格納イメージが堂々と力強いので、堂々と力強い音楽に向いています。
一方、リトルエンディアンは、繊細でこまやかな表現に優れています。
とすると、エンディアンを選択できるフォーマットが最強のように思えますが、選択機構のところがノイズ源になるので避けるべきというのが常識です。
Re: (スコア:0)
しかし、エンディアンが音質に与える影響はないとは言えないんじゃないかな。どっちも再生できる機器の場合、どこかでスワップ処理してるのは確かなんだから、バッファのサイズによっては不具合が生じてもおかしくない。つまり、ソフトウェア的に同一ではない場合、片方だけバグがあるってことは有り得るんじゃないの。
あるいは、どっちかがヘッダの処理を間違えているとか、コンバーターの実装が狂っていて数十バイトの情報すら正確に写し取れないとか。無圧縮でも丸めちゃうとか。
Re:エンディアン (スコア:5, おもしろおかしい)
おっしゃるとおり、エンディアンの変換には時間がかかりますし、バグがつきものです。
たとえば、Z80の場合で、HLレジスタに16ビットデータが入っている場合、
LD A,H
LD H,L
LD L,A
で16ビットデータの上位・下位8ビットが交換できます。
まず時間について考えてみましょう。それぞれ4クロックの時間がかかりますので、全体で12クロックです。
クロック4MHzのZ80Aの場合、3マイクロ秒かかることになってしまいます。
100,000Hzくらいの音を聞くことができる人にとっては、これは致命的なことです。
現代的なCPUはクロックがGHz程度ですので、100,000,000Hzくらいの音を聞くことができる人にとって、
やはりこれは致命的な問題です。
次に、バグの問題について考えてみます。データの上位・下位の交換には上記のように3行にもわたる
プログラミングが必要です。さらに、データが32ビットの場合には6行、64ビットの場合には12行もの
プログラミングが必要です。このように長いプログラムをまったくバグなしで行うのは、長いデスマを
乗り越えてきて睡眠不足が極限まで積み重なったプログラマにとっては、過酷な要求です。
なお、現代的なCPUはデータ交換命令を持っていて、従来では3行必要なプログラムを1行で表現
できる可能性もありますが、CPUそのものにハードウェア的なバグがある可能性がありますので、
使用を避けた方がいい場合も考えられます。
ですので、バグの可能性はあると考えた方がよいでしょう。
つまり、結論として、エンディアンの変換による音質への影響はあると考えるべきです。
Re: (スコア:0)
スワップそのものじゃなくて、バッファのとり方の問題ね。
仮に片側1サンプルのビット数が16だったとして、16ビットごとにスワップするならバグも遅延もないかもしれないけれど、多分そういう作りにはなってない。だって、圧縮音源も同様に再生できなきゃいけないから。生データ(不揮発)をデコーダに流してメモリに展開してから、そのバッファを音響ハードに食べさせるっていう処理をしているはず。で、デコーダがスワップしてれば遅延とかは生じないだろうけど、
で、スワップのところが混みすぎたらってこと。一見、le+無圧縮の実装がおかしいようにも見えるけど、多分、本当に問題なのはデコーダが可変長leで吐くかもしれないってところにあるんだと思う。
Re: (スコア:0)
ないない。
何のためのデコーダなのよ、と。
ビット数・チャンネル数・サンプリングレートの違う音声をソフトでミキシングするんなら、もう一段バッファかませて処理を行うことはあるかもしれませんが。
エンディアンは後にとっとく意味がないです。