アカウント名:
パスワード:
> ちなみに、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くらいの音を聞くことができる人
スワップそのものじゃなくて、バッファのとり方の問題ね。
仮に片側1サンプルのビット数が16だったとして、16ビットごとにスワップするならバグも遅延もないかもしれないけれど、多分そういう作りにはなってない。だって、圧縮音源も同様に再生できなきゃいけないから。生データ(不揮発)をデコーダに流してメモリに展開してから、そのバッファを音響ハードに食べさせるっていう処理をしているはず。で、デコーダがスワップしてれば遅延とかは生じないだろうけど、
be+無圧縮:生→バッファ→ハードbe+圧縮 :生→デコーダ→バッファ→ハードle+無圧縮:生→バッファ→スワップ→ハードle+圧縮 :生→デコーダ→バッファ→スワップ→ハード
で、スワップのところが混みすぎたらってこと。一見、le+無圧縮の実装がおかしいようにも見えるけど、多分、本当に問題なのはデコーダが可変長leで吐くかもしれないってところにあるんだと思う。
ないない。
be+無圧縮:生→デコーダ→バッファ→ハードbe+圧縮 :生→デコーダ→バッファ→ハードle+無圧縮:生→デコーダ→バッファ→ハードle+圧縮 :生→デコーダ→バッファ→ハード
何のためのデコーダなのよ、と。ビット数・チャンネル数・サンプリングレートの違う音声をソフトでミキシングするんなら、もう一段バッファかませて処理を行うことはあるかもしれませんが。エンディアンは後にとっとく意味がないです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
エンディアン (スコア: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くらいの音を聞くことができる人
Re:エンディアン (スコア:0)
スワップそのものじゃなくて、バッファのとり方の問題ね。
仮に片側1サンプルのビット数が16だったとして、16ビットごとにスワップするならバグも遅延もないかもしれないけれど、多分そういう作りにはなってない。だって、圧縮音源も同様に再生できなきゃいけないから。生データ(不揮発)をデコーダに流してメモリに展開してから、そのバッファを音響ハードに食べさせるっていう処理をしているはず。で、デコーダがスワップしてれば遅延とかは生じないだろうけど、
で、スワップのところが混みすぎたらってこと。一見、le+無圧縮の実装がおかしいようにも見えるけど、多分、本当に問題なのはデコーダが可変長leで吐くかもしれないってところにあるんだと思う。
Re: (スコア:0)
ないない。
何のためのデコーダなのよ、と。
ビット数・チャンネル数・サンプリングレートの違う音声をソフトでミキシングするんなら、もう一段バッファかませて処理を行うことはあるかもしれませんが。
エンディアンは後にとっとく意味がないです。