Re: DACでの処理について - ヒロ

2012/01/15 (Sun) 16:13:00

16bit幅データを24bit幅に設定したDACで受けると、16bit幅が24bit幅に拡張されて0bitから23bitの全てが使用されるが0から7bitはすべて0か１となる、あるいは不定になるはずです。
　では24,32Bitの優位性はといえば、内部でオーバサンプリングの補間処理（ディジタルフィルター）を行いますのでBit数が多い方がよりなめらかな補間ができるということになります。

Re: DACでの処理について - Phoenicia

2012/01/15 (Sun) 22:14:25

ヒロさん

解説ありがとうございます。

確かにそうですね。
16bitソースを入れても24bitソースを入れても音量が変わりませんでしたので、高bit側から詰めて足りない下位bitは補完しているというご説明に納得しました。

これで安心してES9018にチャレンジするかも。

Re: DACでの処理について - Bunpei

2012/01/16 (Mon) 01:43:02

厳密な話となると、PCMの話かどうかの確認、つぎにS/PDIFも含めた話なのか、I2S・Left-Justify・Right-Justifyに限る話なのかも絡んできます。とりあえずI2Sの話ということにして進めます。
I2Sに関して規格といえるものは、これしかありません。
http://www.nxp.com/acrobat_download/various/I2SBUS.pdf
このドキュメントには、MSBとLSBのことしか出てきません。
I2Sでは16bit,24bit,32bitのデータ長に合わせてSCK（BCLKとも書く）は32fs,48fs,64fsがありえそうですが、実際、送り出し側で48fsを採用した例を見たことがありません。となると32fs, 64fsの二つだけです。さらに実際は32fsを受けられるDACまたはCODECのチップは少なく、世の中一般は64fs対応のものが多いです。その64fsに16bit,24bitを載せると16bit,8bit分が余ってしまい、そこをどう扱うかについて、公式の規格での規定はないようです。
シリアルデータはいずれもMSBから始まるので、LSB側の16bit, 8bitをどう扱うかという話になります。ES9018の場合、データビット長を明示的に32,24,20,16で指定可能で、これに対応するビットクロックの数に対応するデータだけMSB側からラッチし、残りは捨てているものと思われます。
一方、余りの16bit,8bit分の値をどう送り出すかは、送り出し側に依存します。オールゼロが一般的かと思いますが、SDTransの場合、あるユーザからの強い要望でMSBのサインビットが立っているときは1, そうでないときには0としました（これも数学的にはおかしな話なのですが、そのほうが音が良いというので折れました）。このあたり、DACの変換には全然関係ないデータでも、1か0かの信号の違いがDAC側の電源ラインの揺れに影響を与える可能性がありますので、DACの音質への影響を否定はできません。
もし、16bitの有効データしかないのに32bitで受けているときはどうなるのかというと、DACは16bitと見破る方法がないので、それを32bitだと思って律儀に変換していることになります。

Re: DACでの処理について - Phoenicia

2012/01/16 (Mon) 17:07:59

Bunpeiさん

ありがとうございます。
規格があるようで無い状態ですね。

Re: DACでの処理について - へｎ

2012/01/16 (Mon) 17:22:37

デジタルフィルタを使う場合は、
デジタルフィルタからの出力が17bit以上なら
インターポレーションされたサンプル?で中間値がとれるからそのサンプルの量子化誤差は小さくできる…

80年代半ばからのビット拡張競争で、
16bitDACから18bitDAC…に進歩していったのは、
これも理由のひとつでしょうか。
(売り文句の都合という身も蓋もない理由を除けば)

それでも、98dBというダイナミックレンジが拡張されて今まで見えなかったものが見えてくる！
なーんてわけではないので、やっぱりハイビットのソースが欲しいですね。

間違ったことを書いていたら、ご指摘くださいm(__)m
（あまり自信が無いです）