web拍手 お返事

closeこの記事は 7 年 8 ヶ月 27 日前に投稿されたものです。最近の記事内容との齟齬がある場合,リンク切れが頻発している場合がありますが,ご了承下さい。

▼2009/02/05 14:28
 聴感上高域の情報量が多いのはある意味当然で,サンプリング定理を考えれば,ハイサンプリングレートになればなるほど,可聴帯域内の周波数の波形もより忠実に再現されるわけで,特に高い周波数になればなるほどその傾向は顕著になりますね。
 CD規格にあわせて「音作り」するのであれば,高解像度に聞こえるようにチューニングするのもありだとはおもいますが,ソースそのものの分解能が上がってくると,このあたりの「音作り」が逆効果になってしまうことは往々にしてあると思います。
 個人的には,理想を語るなら,音痩せしないものにするか,理詰めで音質調整なんてしてませんみたいなものにするのか(笑),どちらかにしたいですね。次期インターフェース期待してますよ?。

▼2009/03/05 06:56
 いつもご覧頂きありがとうございます^^ また,ご意見ありがとうございました。
 PC内部でデータを引き回す場合には,少なくともバイナリはクロックと切り離されているので,理論上はどのように取り扱おうが一切影響はないはずですが,そうだとすればわざわざ低負荷環境なんて作る必要すらないですね(汗)。
 少なくともPCへの負荷は電源への負荷と同義ですから,結果的に電源が繋がっているオーディオインターフェースのクロックも,間接的ながら影響を受けると言うことかな?と予想しています。今回の一連のエントリでその糸口は見えてきたような気もしますが,いかがでしたでしょうか。
 この点は,ご指摘いただいた通り,ソフトウェアがハードウェアに結果的にどのような影響を与えているのかを調べればよく,インターフェースのクロック出力のジッターをオシロで観察する方法がベターかもしれません。

▼2009/03/09 07:51
 大場商事のPuccini U-Clock解説ページがあまりに機械翻訳調で何が言いたいのかさっぱりなのですが(爆),それはともかく,AyreのQB-9の登場で非シンクロナス方式によるデータ転送が脚光を浴びそうなのは間違いありません。
 dCSもいずれは本格的にUSBを使ったオーディオ機器を出してくるかもしれませんね?。OCXOを登載しつつ外部クロック入力を省いたモデル(Puccini U-Clockはちょっと惜しい)を発表された日には,オーディオのトレンドが変わってしまうかもしれませんw

web拍手 お返事」への10件のフィードバック

  1. とおりすがり

    前段の文脈が分からないので、間違っていたらすみません。

    「サンプリング定理を考えれば,ハイサンプリングレートになればなるほど,可聴帯域内の周波数の波形もより忠実に再現されるわけで」

    可聴帯域が一定なら、その上限の2倍よい高い周波数でサンプリングしていれば、理論上は元の波形が完全に再現されるので、それ以上にサンプリングレートあげてに波形再現の忠実度は変わらないと思いますが(実装は別として)。

    って釈迦に説法ですよね。

    返信
  2. えるえむ

    とおりすがりさん,コメントありがとうございます^^
    理論的にはご指摘の通りですね。
    他方,実際には,録音時の原音は周波数成分的に無限大ですから,マイクの限界はあるにせよ,ハイサンプリングレートになればなるほど,A/D変換時の誤差やノイズ成分,LPFの問題等々が可聴帯域に影響を及ぼしにくくなるという意味合いでおおざっぱに書いてしまいました(汗)。
    web拍手に対する返事ではありますが,ほかの方もご覧になる以上,言い回しには気をつけたいと思います。ご指摘ありがとうございました^^

    返信
  3. とおりすがり

    すみません、揚げ足取りでは無いのですが、実装の問題では、LPFは良いのですが、ハイサンプリングレートになればなるほど、A/D変換時のジッターやノイズレベルの問題が出てくるので、ハイサンプリングレートであればと良くなる、と言い切るのは難しいと思います。

    返信
  4. えるえむ

    いいえ。お詳しい方にご指摘いただくのはとても嬉しいことですので,お気になさらないでください。
    確かに,ハイサンプリングレートになるほど不正確にサンプリングしてしまう虞はありますよね。D/A変換時もしかり。特にマルチビットのPCMではどんどんジッターに弱くなるのは否定できないことだと思います。

    私は多少ジッターの影響がでたとしてもサンプリング周波数を上げた方がよいかと思っておりましたが,ノイズの影響が大きいようであれば,一概にはいえないのかもしれません。
    とおりすがりさんがハイサンプリングレートのソースのメリット/デメリットをどのようにお考えか,ご意見をお聞かせ願えると幸いです。

    返信
  5. えるえむ

    追記です。

    視点を変えると,サンプリングレートを欲張りすぎるとジッターに弱くなりますから,論理的には毎回不正確なA/D・D/A変換となることもありえますね。
    となると,原信号に対する正確性という点では,高い周波数まで対応しようと,その分低い周波数を変換する際の正確性がむしろ脅かされるということになりますでしょうか。

    結局,ハイサンプリングレートのソースの利点って,20Hz?20kHzではほとんどない可能性もありますね。特に水晶発振器が貧弱な場合はむしろ不正確な変換となる虞も…。
    あとは,通説的に言われてきた可聴帯域がそもそも誤りなのだからと主張するしかないでしょうか。

    まあ,プロが作るソースならさすがに気を遣うでしょうから,ジッターのマージンは十分にとっていると信じたいところです^^;

    返信
  6. moonriver

    少々遅れてレスしますが
    シャノンの定理はフーリエ変換を理解できればあまり難しい定理ではないでうす。

    >録音時の原音は周波数成分的に無限大ですから,マイクの限界はあるにせよ,ハイサンプリングレートになればなるほど,A/D変換時の誤差やノイズ成分,LPFの問題等々が可聴帯域に影響を及ぼしにくくなるという意味合いでおおざっぱに書いてしまいました(汗)

    ちょっとロジックが分かりません。何か誤解がある気がします。

    >確かに,ハイサンプリングレートになるほど不正確にサンプリングしてしまう虞はありますよね。

    それはサンプリング間隔に対しての比率を両者で比較する時の話であって、絶対値を比較した時の話は違うのではないかと思います。
    まあいろいろ難しいけどねえ

    返信
  7. えるえむ

    moonriverさん,コメントありがとうございます^^

    >ちょっとロジックが分かりません。何か誤解がある気がします。

    可聴帯域がどこからどこまでか,という話をすっとばして書いたため,変な言い回しになってしまってるかもしれません。
    個人差があるので単純に20kHzまでですとは割り切れないかなと思い(だからといって100kHzまでとは思いませんがw),その意味で高域までより正確に変換できることは良いことだと考えたのですが,とおりすがりさんご指摘の通り,そうなるとジッターに弱くなって低い周波数が正確に変換できるのかという問題が生じてくるような…。
    可聴帯域が20kHzまでなら,A/D変換時においてLPFが可聴帯域内のアナログ信号に影響しない程度にサンプリング周波数のマージンを取っておけば良いのではないでしょうか(違っていたらご指摘ください)。

    >それはサンプリング間隔に対しての比率を両者で比較する時の話であって、絶対値を比較した時の話は違うのではないかと思います

    ご指摘の通りの予感ですが(汗),絶対値を比較するというのはどういう趣旨でしょう?
    ジッターの問題を考えると,闇雲にハイサンプリングにするくらいなら可聴帯域の正確な再現を志向するというのも一つの見識かなと思ったのですが,いかがでしょう。

    返信
  8. moonriver

    δω/ωを比べるんじゃなくてδωを比べるべきではないのかなあという話です。(ωは周波数でδωはその揺らぎ成分)

    返信
  9. えるえむ

    ご説明ありがとうございます。
    つまり,ジッター成分が正確なD/A変換を阻害したか否かについて,単純にサンプリング周波数の1単位分で割り算してしまうのはまずいということでしょうか。
    割り算して1単位に分割してしまうと,ある曲を再生している間に揺らぎ成分がふらふらしている挙動が捨象されてしまうみたいなとらえ方であっていますか?ふらつきのばらつきを考えると総量で考えるべきというのも納得のいく感じですが…。

    勘違いしていたらご指摘ください(汗)。

    返信

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title="" ktai=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <img localsrc="" alt="">