Ｐａｇｅ 151 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 通常モードに戻る ┃ ＩＮＤＥＸ ┃ ≪前へ │ 次へ≫ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ▼デジタル接続でのクロックについて ハリー 05/2/13(日) 16:21 ┗Re:デジタル接続でのクロックについて Kenzo 05/2/13(日) 17:00 ┗Re:デジタル接続でのクロックについて ハリー 05/2/13(日) 19:40 ┗Re:デジタル接続でのクロックについて Kenzo 05/2/14(月) 20:31 ┗Re:デジタル接続でのクロックについて 良蔵 05/2/14(月) 22:16 ┗Re:デジタル接続でのクロックについて Kenzo 05/2/15(火) 21:18 ─────────────────────────────────────── ■題名 ： デジタル接続でのクロックについて ■名前 ： ハリー ■日付 ： 05/2/13(日) 16:21 -------------------------------------------------------------------------
| はじめまして、ハリーと申します。 近年G-0sといったクロックジェネレーターがはやっているようで、それに関して疑問があります。 当方アンプにSONYのTA-DR1を使っております。TA-DR1はデジタル入力があるので、P-0sといったクロック入力のあるCDトランスポートからデジタル出力で繋げる場合に、G-0sを接続すると効果があるのかどうかということが知りたいのです。 DACを用いる場合は両者クロックで同期をとって有効であるとはいろいろ聴くのですが、DACがない場合でもG-0sの効果は明らかに分かるほどあるのかということです。 それともう一つ、TA-DR1とペアになるSCD-DR1をiLINK接続で継げた場合、SCD-DR1のクロック入力にG-0sを接続した場合、効果があるのかということです。 詳しいことはよく分かりませんが、iLINKだと、アンプとプレイヤー側で同期をとりながらデーターを受け渡すので、ジッターが発生しないということで、クロック入力は意味がないのではないかと思ってしまうのです。 ただし、TA-DR1は同じSONYのデジタルアンプTA-DA9000ESと違いH.A.T.S.というのができないそうで、だとしたらクロック入力は有効なのかなとも思ってしまいます。 どなたか分かる方いましたら、よろしくお願いします。 <Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR...> |
| ▼ハリーさん： はじめまして、 さて、クロックに含まれるジッターのなかで音質を阻害する成分は機器が出力するオーディオ成分（DATA）です。オーディオ成分がマスタークロック発振回路に干渉し、マスタークロックの位相成分に混入します。外部発振回路にすることによりオーディオ成分の干渉を低減できます。 G-Osはルビジューム発振を行っており水晶より高精度ですが、オーサリングをする場合を除いてそこまでの精度が必要かと言う部分があります。また、ルビジュームの原発振は数GHz帯で必要とするMHz帯の周波数はPLLで生成しており、単純な水晶発振に比べ位相雑音（純度）は不利になっています。G-OとG-Osを機器比べたことはありませんので音質については判りません。 デジタル入力の場合は、デジタル信号に含まれるfs成分をPLLやDSPで抽出し使用します。送りに含まれるジッターが低減できればそれなりの効果は得られると思いますが、デジタル伝送以降受信側のPLLや内部のDATAからの干渉によるジッターは吸収できません。受信側に送信側のマスタークロックを直接注入すれば効果が期待できますが外部クロックの端子が無いと実現は困難です。 iLINK接続では、送受信がコミュニケーションし、受信側のクロックで処理が行われますので、送信側に外部クロックを使った場合、送信するまでのジッターについては改善されますが、全体としての効果は少ないと考えます。 >ただし、TA-DR1は同じSONYのデジタルアンプTA-DA9000ESと違いH.A.T.S.というのができないそうで、だとしたらクロック入力は有効なのかなとも思ってしまいます。 H.A.T.S.という仕組みがわかりませんので有効かどうか判断できません。 いずれにせよ、外部クロックを使うことで何らかの改善は見込めますが、果たして投資に見合うものなのかは申し訳ありませんがなんとも言えません。 高純度水晶発振によるジッターの改善についてHPで述べておりますので宜しかったらご覧下さい。 <Mozilla/5.0 (Macintosh; U; PPC; ja-JP; rv:1.0.1) Gecko/20020823 Netscape/7.0> |
| ハリーです。 KENZOさん詳しく説明していただきましてありがとうございます。 G-0sは100万以上するものなので、価格に見合うかは難しいかもしれませんね。 ところで、H.A.T.S.というのは高品質デジタル・オーディオ送信システムのことで、詳しくは下記のHPの一番下に載っております。 http://www.sony.jp/products/Consumer/SACD/technology/#page06 このH.A.T.S.というのが働けば、クロックジェネレーターを使用する意味はなくなるのでしょうね。 でも、残念ながらTA-DR1はH.A.T.S.には対応していないのです。(以前にソニーに確認済みです。) 尚SCD-DR1は対応しています。 下位機種であるTA-DA9000ESやTA-DA7000ESではH.A.T.S.に対応しているというのに。 というわけで、TA-DR1であれば、iLINK接続の場合でもG-0sのようなクロックジェネレーターを導入する意義があるのかなと思った次第なのです。 <Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR...> |
| ▼ハリーさん： >ところで、H.A.T.S.というのは高品質デジタル・オーディオ送信システムのことで、詳しくは下記のHPの一番下に載っております。 > >http://www.sony.jp/products/Consumer/SACD/technology/#page06 読んでみましたが、元々iLINK(IEEE1394)は双方向コミュニケーションでこういった機能が無い訳はないので少し??です。検索してみたところ、どうやら相互接続のための標準化の仕組みのように思えます。 恐らく、H.A.T.S.に対応していなくても、送信側のクロックを利用してクロック生成をすることはありませんが、完全に受信側の要求で伝送が行われないことも起こりえて、音切れや動画のフレーム欠落が起きないとは保証できないということなのではないかと思います。 ということで、H.A.T.S.に対応していなくても送り側のクロックと受信側のクロックは無相関になると思います。 残念ながらこれ以上のことは判りません。 <Mozilla/5.0 (Macintosh; U; PPC; ja-JP; rv:1.0.1) Gecko/20020823 Netscape/7.0> |
| H.A.T.Sと言うのは、詳細はわからないのですが、たぶん、以下のような事 だと思います。 IEEE1394にはアイソクロナス転送とアンシンクロナス転送と呼ばれる2つの 転送モードを持っています。 アンシンクロナス転送と言うのは通常の転送で、ホストから、必要なデータの 要求をすると、それに応じて要求されただけデータを転送すると言う、まあ、 普通の転送形式です。PCのATAPIとかUSBの転送と同じです。 それに対して、アイソクロナス転送は、ある細切れのデータを定期的に半強制 的にホストに送りつける方法で転送します。また、アイソクロナス転送は アンシンクロナス転送より優先されます。このため、データの転送レートを 保証する事ができます。 通常のiLink Audioと言うのは、IEEE1394のアイソクロナス転送を使用します。 AVデータのようにデータの信頼性より時間的な制約が有るようなデータには、 こちらの方が都合が良いからです。 それでH.A.T.Sですが、これは、たぶん、アンシンクロナス転送モードと使って 転送するのだと思います。この場合、データは要求して分だけ送られるので バッファーに必要な量だけ転送できますが、転送レートを保証することは、 できなくなります。ただ、接続機器が1つしか無いのであれば、転送レート 保証は意味がないです。 アイソクロナス転送時に送り手と受け手のクロックが違っていると、時間が 長くなると微妙にデータが余ったり足りなくなったりと言うことが発生する 事になります。このことを嫌って、H.A.T.Sのような専用モードを設けたので はないかと思われます。 <Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.5) Gecko/20041108 Firef...> |
| ▼良蔵さん： 解説有り難う御座います。 アイソクロナス転送とアンシンクロナス転送のモードがあることを忘れていました。 H.A.T.S.では、メインのストリームのタイムコードも使って制御するようなことは無いのでしょうか？ 何となく、Quick Timeのような時間制御の考え方も使っているような気がしています。 <Mozilla/5.0 (Macintosh; U; PPC; ja-JP; rv:1.0.1) Gecko/20020823 Netscape/7.0> |