ラトックシステム PC Audioブログ

#25 Digital Audioの伝送について（S/PDIF編 その5）

　前回はフレームの基本単位（Sub Frame）について説明しましたが、C bitについては文章が長大になるので説明できませんでした。ということで今回はC bitについて説明することにします。

　C bitの正式名称はChannel Status bitですので、文字どおりChannelのStatusを表しています。したがって、各Channelごとに独立している必要がありますので、ひとつのFrame内の各Sub Frameは独立したC bitを持っているということになります。1bitではややこしいことは表現できませんので各ChannelのStatus情報はFrame#0からFrame#191までの各Frame内の各Sub Frameに含まれているC bitを取り出して順番に並べ、全長が192bit（24Bytes）のデータを作成します。送信側はあらかじめ、バッファレジスタやメモリ上にこのデータを用意しておき、1サンプリングあたりの音楽データと一緒にしてBMCでエンコードします。受信側は受信したSub Frameの中からC bitをせっせと取り出し順番にバッファレジスタやメモリ上に格納します。
前回のBlogで「同一Frame内のSub Frameは同じU bit（C bitも）を持っている」と書きましたが、これは正確には「AES（Pro用）のmonoral、One Byte Mode時」の話で、私たちが使用しているS/PDIF（民生用）モードやAESでもWord ModeではU bitもC bitもそれぞれ独立してSub Frame内に存在しますので、Sub Frameごとに192bitのデータ列が存在し、Frameごとにそれらが2個ずつ存在します。前回の記述は正確さを欠き、お読みいただいた方々が誤解されるような表現であったことをおわびいたします。

　S/PDIFの最新規格（IEC60958-3 Ed.3 2006 May）ではC bitの192bitのbit列のうち、先頭部の41bitが使用されます。その41bitの意味について表にまとめましたので参照してください。

■bit0～bit7■	■bit16～bit31■ LPCM, Mode='00'の場合	■bit32～bit41■ LPCM, Mode='00'の場合

残りの151bitは未使用です。以前は先頭の32bitが使用されていましたが、現在の最新規格では41bitに拡張されています。実際に出回っている機器には古い規格に基づいたものの方が多く、Net上の情報もかなり古いものもありますので、実際に使用される際には原典を参照するようにしてください。C bitのbit数以外にもかなり拡張されており、最新版ではデジタルTV用に、画像表示のタイミングに合わせて音声を遅らせるリップシンク機能などのパラメータをU bitに埋め込む仕様などが追加されています。LPCM以外のAC-3やAAC、DTSなどの圧縮音声データに関する仕様はIEC61937（S/PDIF Coded Audio）を参照してください。日本国内ではJEITA（旧EIAJ）CP-1201「デジタルオーディオインターフェイス」という国内規格がありましたが2002年2月に廃止され、IECの規格に一本化されています。

　表中の各bitの番号（b0～b41）はブロック内のFrame番号に合わせてあります。ただし、b8からb15の1Byteに関しては今回は説明していません。この1ByteはCategory codeと呼ばれ、音楽データの出自を記述するためのcodeです。元々、CDから読み出したのか、どこの国で放送波を受信したのか、DAT（デジタルオーディオテープ）なのか、MDなのかということがこと細かく規定されています。それを説明していると、それだけで3ヶ月くらいかかりそうなので今回は省略します。

　私たちの製品であるREX-Link1,REX-Link2,REX-Link2EXの受信機にもS/PDIF（光）の送信機能が含まれていますが、PCからは音楽データ（I2S）しか送られて来ませんので、受信機のソフトウェアでU bitやC bitを設定しています。U bitは未使用'00'ですが、REX-Link2以降の製品では、光ケーブルで受信機とMDを接続してNet上のデジタル音楽Streamを録音できないよう、またPC内の音楽データをデジタルのまま複製できないようにCopyright Protect bit（bit2）を「著作件保護有り」にSetしています。でも、接続相手機器のMDやPCで無視されれば意味がありません。

　アナログオーディオはこんな面倒なことはなかったのですが、デジタル化でどんどん面倒なBlackBoxになり、アマチュアで趣味でアンプなどを作る人達を締め出してしまっている理由のひとつにもなっています。手の出しやすい真空管アンプの部品を求めて秋葉原や日本橋のパーツ屋さんをうろついているのは孫のいそうなじいさんばかりで小中学生はとんと見かけません。このままでは日本のエレクトロニクス産業の将来は......どうなるのでしょうか？

　次回からは、Category Codeに簡単に触れて、S/PDIFの実際の機器への実装とそれを採用しているHDMIのAudio信号についてblogを続けて行きたいと思います。

-----------------------------------
■番外編■
　先月（6月9日から13日）、AppleのWWDC（開発者会議）がサンフランシスコで開催され、月曜から金曜まで毎日、私たちのUSA事務所があるサンタクララ（わが事務所はintel本社の向いにあります）からサンフランシスコまでCaltrainという鉄道で片道1時間半かけて通っていました。
　ちなみに「鉄ちゃん」の読者の方もいらっしゃると思いますのでCaltrainのことを少々。Caltrainはオールステンレス製の2階建て客車（名古屋にある日本車両という会社が1985年に製造したというプレートがドアの上に貼り付けられています）を電気式ディーゼル機関車で牽引（サンフランシスコ発、ターンテーブルがないのでサンフランシスコ行きは機関車が後押し）しています。客車の1階部分の半分が自転車置き場というなかなかエコな乗り物です。
　そのCaltrainの終点のサンフランシスコ駅から4th.Streetを10分くらい歩くとWWDCの会場に到着しますが、その途中の古い2階建てのレンガ造りのアパートの入口をふと見ると six apartやtypepadというロゴが目に入りました。なんと、そこが本blogで使用しているtypepadの開発元six apartの本社でした。IT企業の本社は私たちの事務所のあるシリコンバレイには星の数ほどありますが、まさか、サンフランシスコの元倉庫街の古ぼけたアパートにあるとは思いませんでした。写真を掲載しておきますのでご参照ください。IT企業よりは真空管アンプの会社の方が似合いそうな建物です。

#24 Digital Audioの伝送について（S/PDIF編 その4）

　今回は音楽データがリニアPCMの場合のS/PDIFのFrameのフォーマットについて説明します。

　リニアPCMを伝送する場合の基本単位（Sub Frame）は前回（＃23）の図-2のように、32bitの長さで構成されています。先頭の4bitは同期検出用のSyncコードで、'B','M','W'の三種類があります。これらは4bit長ですが、リニアPCMのデータ部に合わせて2倍のビットレートに展開されるため（BMCでエンコードされるという訳ではありません）、表-1のようなビットパターンになります。

表-1　Syncコード（プリアンブル）部のビットパターン

ちょっと見るとBMCエンコードされているように見えますが、'0'あるいは'1'が3個連続している部分が含まれています。BMCエンコードを行ったデータは'0'もしくは'1'は2個しか連続しない（データが'0'の場合）という約束になっていました。S/PDIFのレシーバは、この3個の'1'もしくは'0'が連続しているのを目ざとく検出してSub Frameの始まりと種類を検出しているということになります。　当然、先行するSub Frameの最後が'1'の場合や'0'の場合は'1'が3個以上続いたり、'0'が3個以上続いたりしてしまわないよう、論理をひっくり返します。つまり、直前のSub Frameの最後が'1'ならSyncコード（プリアンブル）を'000'で始め、'0'なら'111'で始めるよう決められています。このあたりは表-1を参照してください。

　Syncコード（プリアンブル）の次はAudio Sampleデータフィールドです。bit4からbit27までの24bitの長さがあります。I2Sから入力されBMCエンコードされたbit列がここにはめ込まれます。本blogの#20（2008年4月4日掲載）の図-1をもう一度参照してください。I2Sでは最長24bitまでのAudio SampleデータがMSB（最上位bit、b23）を先頭にして、順番に送り出され、LSB（b0）が最後に送り出されます。ところが前回（#23）の図-2を参照してください。この順番はLSB（b0）が先で、MSB（B23）が最後というように逆順に並べ替えられています。また、16bit長のデータは図-1のように右詰めで送り出されますので、Sub Frameのb4からb11までの8bitはダミーとなり'0'でパディングされます。b4からb7までの4bitはAUX bitとして使用される場合もあります。

図-1　Sub FrameのAudio Sample データフィールドのフォーマット
注） 16bit data, 20bit data, 24bit dataのbit番号はI2S入力のSDATAに合わせています。

　Audio Sampleデータフィールドに続くb28,29,30,31の4bitはフラグやステイタスを表すbitとして表-2のように使用されています。

表-2　Sub Frameのb28からb31まで、V,U,C,P bitの意味。
注) UおよびCbitはFrame#0から#191までのbitをつなげて192bit長のbit列データとして使用されます。

V-bitはS/PDIFで送り出す前にセット/リセットされていますので、受信した方は、「このSub Frameは無効」と通知されても処置に困ってしまいます。Computer間の通信のようにエラー訂正のプロトコルが決められていれば、再送要求を出せますがAudio伝送では決められていませんので、V bitは受信側で無視するのが妥当なところだと思います。本来はCDプレイヤなどで、何度も読み出しエラーが発生した場合などに送信側でSetするようなものだと思います。iTunesなどでCDをリッピングする際に、「エラー訂正のために再読み込みを可能にする」という機能をONにするようなことができればよいのですが。
　bit31のP bitは送信側でbit4からb30までのbit列のParity bitです。受信側では受信したbit4からbit30までのbit列のParityを計算し、このP bitの値と一致するかどうか比較します。一致しなければ、通信の途中でどこかのbitが化けたということになります。再送を要求するか、無視してそのまま続行するかは上位のプロトコルで決められますが、現状のAudio伝送では無視して続行するしかありません。ただし、これはSync Codeが正しく検出できた場合の話で、同軸ケーブルを使用した場合は、送受信のレベルが低いのでノイズの影響を受けやすく、Sync Codeに同期できず、Sub Frame自体を検出できない場合があります。アナログ信号の場合、ノイズがのっても場合によっては「味付け」になりますが、Digital伝送の場合はノイズによってデータそのものが検出できないことがあるので、エラー訂正や再送プロトコルのない伝送には注意が必要です。
　bit29のU bitはUserが自由に使用できるbitです。ほとんどの場合、未使用（'0'）ですがCDプレイヤからのS/PDIF出力ではCDのSub-Qデータを送り出すために使用されている場合があります。この場合は、192個のFrameを構成するSub FrameのU bitを順番に並べて全体で192bit長のbit列をつくります。ひとつのFrame内に2個のSub FrameがあるからU bitの数は192x2で384ではないのか、と思いますが、同一Frame内のSub Frameは同じU bit（C bitも）を持っているので192個で間違いではありません。Sub-QデータというのはCDプレイヤで表示されるTrack番号や時間、現在演奏中の位置を示す時間データなどです。このデータは当然I2Sには全く含まれていませんので、CDメカの制御回路から直接取り出す必要があります。

　bit30のC bitも同じようにFrame#0から1bitずつ取り出して並べるとチャンネルステイタスと呼ばれるデータを再現することができます。実際は先頭のFrame#0から#31までに含まれている32bitに意味があり、EIAJで各bitの意味が規格化されています。C bitに関しては次回説明いたします。

#23 Digital Audioの伝送について（S/PDIF編 その3）

　S/PDIF編と謳いながら、序章のような内容が2回続いてしまい申し訳ありませんでした。今回からは直接S/PDIFに関するお話をしたいと思います。これまでに説明したようにマイクロホンなどで拾った楽器や歌声などのアナログ信号をDigital信号に変換した基本波形はI2S（最近はDSDも多いようですが）です。I2S信号の伝送には最低でも3本の信号線が必要になり、DataとClockが別々の信号線上を流れることにより外来ノイズやJitterなどの影響を受けやすくなります。極端な場合、Dataラインが断線あるいはショートしていてもWCLKとBCLKが伝送されていれば、無音なのか何なのか分かりません。同じような問題を抱えていたComputer間の通信（Ethernet/802.3）では、前回紹介したMancheter Codeという方法でエンコードを行い、Clockとデータを重畳させ1本の信号線で伝送できるように工夫されています。

　Audio信号の場合も同様に、Data（I2SのSDATA）とClock（SCLKまたはBCLK）をBMC（Biphase Mark Code）と呼ばれる方式でエンコードを行い、1本の信号線で伝送できるようにClockとDataを重畳させています。BMCエンコード方式もLogic Levelの'0'や'1'が連続して続いた場合であっても、断線と間違えることがないよう、必ずDataの1bit単位で信号が変化するように考えられています（図-1参照）。

図-1　Biphase Mark Code（BMC）エンコード。
#22の図-4と比較してください。

そのため、BMC化された信号のシンボルレートは元々のI2S信号のBCLKの2倍の値が必要になります。I2SのSDATAの'1'はBMCにより10もしくは01にエンコードされ、I2SのSDATA'0'は00もしくは11という同じデータ2個のbit列で表現されるようになります。そして、個々のCell（1bitのDataをエンコードしたもの）の先頭は、直前のCellの最後のLogicレベルが反転されたものになります。こうしておかないと、直前のCellの最後が、仮に'1'だった場合、後続するCellの先頭も'1’であれば'11'となってしまい、元のデータが'0'であると誤認してしまう可能性があるからです。そのように、常に極性がCell間で重ならないように反転させている結果、BMCは信号の極性が反転していても全く影響されずに通信できるという面白い性質を持っています。したがって、S/DIFのOPT（光）接続で、Logic'1'の場合に点灯し、'0'の場合に消灯していても、その逆であっても正しくデータを伝えることができるという優れた特徴を持っています。ただし、エンコードを行うために元のClockの2倍のClockが必要になるのでComputer間通信のような高速通信（10Mbps, 100Mbps, 1Gbps）などには向いていないので、比較的低速でも問題がないDigital Audioで使用されているのではないかと思います。でも、前途のような優れた点が多いのでDigital Audio信号伝送用として標準的に使用されているものと思います。

　上記のようにBMCエンコードという方法によってI2Sのデータとクロック（SDATA,SCLK）を1本の信号線にまとめることができるということ、およびどのようにまとめられているかということがおわかりだと思います。しかし、DataとClockのBMCエンコードだけでは、WCLK（Word Clock）が含まれていませんので、どこがLch.データか、どこがRch.データか判別できないので、Audioデータとしては使えません。そこで、#21でお話した同期方式という方法が使用されることになります。

図-2　S/PDIFのSub Frameのフォーマット

　S/PDIFではBMCエンコードされたひとつのAudioデータを図-2のようなSub Frame（サブフレーム）と呼ばれる情報単位としています。ひとつのSub Frameは32bitで構成され、先頭の4bitは同期検出のためのSync Code（プリアンブル）と呼ばれる同期検出用のビットパターンです。この部分は同期検出用でI2Sの元データからは独立していますので、BMCでエンコードはされていません。S/PDIFではこのSub Frame2個でひとつのFrameを構成し、FrameひとつでChennel#1（Left）, Channel#2（Right）を伝送できるように考えられています。さらにこのFrameを#0から#191までの192個をひとまとめにして1ブロックを構成させています。したがって、I2SによるリニアPCM信号を伝送する場合には、ひとつのブロックで192個のデータを送り出すことができます。

　S/PDIFによるAudioデータの伝送はリニアPCMデータだけでなく、Dolby 5.1ch.などの圧縮データ（Non-PCMデータ）の伝送にも使用されています。LPCMとそれらのNon-PCMでは個々のSub-FrameやFrameの内容、Block内部のFormatは異なりますが、Sync＋BMCエンコードされたデータ やbit streamという構成、Sub-Frame、Frame、Blockという構成は同じです。

図-3　S/PDIFのFrameフォーマット

　次回はLPCMの伝送についてSub FrameやFrame、Blockのフォーマットについて説明して行きたいと思います。

#22 Digital Audioの伝送について（S/PDIF編 その2）

　A/D変換によりデジタル化されたデジタルオーディオ信号の伝送に関しては、民生用ではS/PDIF（SONYとPhilipsにより規格が提案されたのでS/P Digital InterFace）、業務用ではAESが標準化されています。したがって、現実的には私たちはS/PDIFを使用せざるを得ません。実はHDMIのオーディオパケットもS/PDIFと同じですので、この機会に勉強しておくのもよいと思います。今回はS/PDIFことについて勉強する前に、デジタル信号の伝送の基礎知識について紹介しておきます。

　デジタル信号の伝送そのものに関しては、デジタル化された信号がオーディオであるのか、文字データであるのか数値データであるのか、内容とは無関係にとにかく高速で間違いがなく伝送することが要求されます。これの要求に応え、高速かつ正確な伝送を実現するために、これまで何十年にも渡って、無数のエンジニア達が知恵を絞ってきました。そのような努力と知恵の成果がコンピュータの世界だけではなく、S/PDIFを含めたデジタルオーディオの伝送についても活かされています。

　一番最初のデジタル信号の伝送は「モールス符号」です。昔、短波放送などのBCLやアマチュア無線に興味を持たれていた方はご存知と思いますが、アルファベットやカナ文字を「トン」と「ツー」の組合せで、送受信していました。最初は2本の電線の間に電流を流し、電流ループのOn-OFFあるいは強弱（0の場合は電線が切れていると判断できるように）により、受信側のリレー（継電器）や回路を操作していました。「ツー」は「トン」の3倍の長さ、「トン」や「ツー」の間隔は「トン」1ヶ分、文字と文字の間隔は「トン」3ヶ分、文と文の間隔は「トン」7ヶ分というように決められています。電気信号以外では光（ライトの点滅）でも、モールス信号を伝送することができます。

　これを図-1のように「トン」を短い長円、「ツー」をその3倍の長さの長円として並べてみると、なにやら見たことのあるものに見えます。

図-1 CDのpitはモールス信号に似ている。

CDの記録パターンです。CDでは"0"を意味する短円のPit（「トン」）、"1"を意味する長円のPit（「ツー」）が渦巻線上に配置されています。実際のCDでは、読み出しヘッドの位置が少しくらいずれても正確に読み出せるように、Pit（凹部）の幅や長さ、深さ、配置などが工夫されているだけではなく、CD作成時には元のデジタル化された音楽データ（LPCM 16bit/44.1kHz）を、読み出しエラーが発生しにくくかつ修復しやすいように特別なアルゴリズムを使用して、ビット列に変換した後、誤り訂正のための符号化と並べ替え、さらに、情報の単位ごとにフレーム化が行われ、実際のPitが配置されています。

　音楽をマイクロホンで拾った後、A/Dコンバータでデジタル信号したオーディオ信号は基本的にはI2S（最近ではSACDと同じ1bitのDSDが使用されることもあるようですが）ですから、本Blogの#20（I2S編）でも述べたように3bit（3本の信号線）が必要です。音楽CDの制作の際には、まずこれを「トン・ツー」の組合せが1列にならんだ1bitのビット列にする必要があります。1回のサンプリング分のLch.,Rch.それぞれ16bitのbit列を8bitx4のbit列にします。その各4byteのbit列を6組（サンプリング6回分）をまとめ、誤り検出・訂正のためにリードソロモンという方式でCIRC符号化します。CIRC符号化によって元の24byteのbit列は32byte（256bit）に拡張されます。その後、サブコード（CDの先頭やトラック先頭からの位置情報（経過時間情報）などのアドレス情報）の8bitが先頭に追加され、全体がEFM（8/14。8bitのbit列が14bitに拡張される）方式で変調されます。EFM変調により拡張された各14bitのbit列の間には3bitの結合bitが挿入されるので、全体が（3+14）+（（3+14）x32）の561bitに拡張されます。さらに、サブコードの先頭部には同期用として24bitのプリアンブルと3bitの結合bitが追加され、全体で588bitの長さのフレームが形成され、実際のpitの配置が決まります。

　CD上のこのフレームを読み出した後、エラーがあればこのリードソロモン符号が数学的に処理され、元の正しいbit列が復元されます。そういうことならば、CDから読み出した生データのbit列の訂正処理を行った後、TOSLINKのカプラ（送信モジュール）や他の送信回路を駆動させて、デジタルオーディオ信号を伝送すればよいではないかという疑問は湧いてきますが、CD上のbit列やフレームはCDに特化されていますので、デジタルオーディオ信号を幅広く伝送するには力不足です。そこで、S/PDIFが登場し、LPCMだけでなくDolby AC-3やDTSなどの圧縮データも取り扱えるように規格化されたわけです。

　S/DPIFはご存知のように信号線としては1本（GND-Returnを含めれば2本ですが）で、電気的には片側がGNDレベル（固定電位）のシングルエンド（アンバランス）信号です。Software的（論理的）には1bitのDigital信号ということになります。1本の信号線上にbit列をシリアル（直列）に乗せて伝送するシリアル通信はコンピュータやデータ通信の世界では常識で、私たちも創業以来25年間、すいぶん「痛い目」に会わされてきました。特にHigh-Speedシリアル（LAN 10Mbps, 100Mbps,1Gbps,IEE1394/i-link（400MBps）, USB2.0（480Mbps）,SATA （3Gbps）にはプリント基板の設計を含めて、ずいぶん苦労しました。おかげで測定器類も揃えざるをえず、測定技術も習得せざるをえませんでしたので、HDMIの信号品質テストなどは軽くPassすることができる実力が備わりました。先にも述べましたが、HDMIのオーディオ信号の伝送はS/PDIFの規格に準じて行われています。したがって、HDMIをマスターするためにも、S/PDIFおよびシリアルデータ伝送に関して"通"になっておくことは必要と思います。


　モールス信号に続くシリアルデータ伝送の原始的なものはASYNC（非同期）通信方式です。これはモールス信号のように、トン・ツーの可変長の組合せだけでは、途中で切断されたりしても分からず、エラーチェックもないため、データ伝送をより高速化・効率化されるために考え出された方式で、図-2のようにスタートbitとストップbitでデータの基本単位（文字）を区切り、パリティチェックを設けるという方式です。

送信側、受信側それぞれがStart bitを基準に一定のClock（間隔）で信号の論理を判定する。 図-2 ASYNC（非同期調歩）通信方式

TELEXやテレタイプなどで標準的に使用され、コンピュータの世界でも端末機とのインターフェイスになくてはならないものでした。今でも、マイコン組込み機器の開発時やコンピュータの故障診断時などで重宝されています。最近では19.2kbpsなどの速度が当たり前ですが、当初は110bpsが主流で、その後300bps,1200bpsなどが主流でした。おわかりのように、この速度ではとてもオーディオデータは送れませんので音声信号は同じ電話回線を使用してアナログで伝送されていました。これをさらに高速化し、エラーチェックをフレーム（情報の単位）ごとでも行えるようにしたのが、同期（SYNC）通信と呼ばれる方式です。

データ列の前後を同期確定用のSYNCコード（01001100）で囲む。また一定時間ごとにSYNCを挿入して同期がずれないようにする。FCS（Frame Check Sequence）はCRCチェックなどのError検出情報。

図-3 同期(キャラクタ同期)通信のフォーマット

個々の文字情報に相当する部分からスタートbitとストップbit、パリティbitを取り去り、高速化に対応するとともに、フレームごとにCRCチェックを行うようになりました。このままではどこがフレームの先頭で、どこが終端かわからないので、先頭にSYNCパターンと呼ばれる特別なbit列をくっつけて、受信側でそれを検出して同期を取り、終端にも同じようなパターンを追加しています。S/PDIFでも、後ほど説明しますがこのSYNCパターンと同様に、プリアンブルと呼ばれる同期のためのbit列が各フレームを構成する2個のサブフレームの先頭に付加されています。このあたりの話は、S/PDIFがいかにデジタルオーディオ伝送用として考え出されたかというバックグラウンドの知識としてお読みください。
　注）実際の電話回線上はこれらの直流信号がそのまま伝送されているわけではなく、モデムや音響カプラで音声帯域の信号に変換されて伝送されています。誤解のないように続きをお読みください。

　同期通信は銀行のオンラインなどで標準的に使用されましたが、速度が2400bps、4800bpsなどで増大するデータ量を高速に誤りなく伝送するという要求にはついてゆけなくなっていました。また、伝送されるのがデータのみで、それをサンプリングさせるクロックは伝送されていないため、送信側、受信側の両端でクロックを同期させるのが難しく、高速で大量のデータを伝送することができませんでした。そのため、モデムのような交流信号としてではなく、直流信号のままでクロックとデータを重ね合わせる（データの中にクロックを埋め込む）ということを中心にしたいろんな通信方式が提案されては消え、また新しい物が提案されて...という状況でしたが、25年くらい前にXroxなどからEtherNetという通信方式、通信プロトコル、Networkが提案されました。それがIEEE802.3として標準化され、今日ではパソコンのLANとして当たり前になっています。現在のLANの物理層は100Base-Tと呼ばれる電話線のようなツイストケーブル（撚り線）の2ペアが使用されていますが、25年くらい前はイエローケーブルと呼ばれる直径が15mmくらいの太くて固いシールドケーブルでした。そのケーブルにMAUと呼ばれるboxを噛み付かせ（ケーブルの途中に金属製の歯で噛み付かせて外部のビニール被覆を突き破りシールドに接触させ、さらにその中心部に針のようなもの突き刺して中心にある芯線に接触させるという強烈な方式でした）、MAUとパソコン（増設インターフェイスボード）との間は、これまた太い15芯のケーブルで接続するという代物でした。
電気信号の面では、10Mbpsでデジタル信号を伝送するために、bit列そのままでは"0"が連続した場合や、"1"が連続した場合にデータの判別が難しくなるので先に述べたCDのpit配置と同様にbit列に変調をかけていました。CDの場合はEFM変調とCIRCでしたが、EtherNetの場合はManchester Code（Phase Encoding）と呼ばれる方式でした。この方式は図-4のように、一本の信号線にクロックとデータを重畳させて伝送することができます。

図-4　ClockとDataをエンコードしてひとつの信号にする（LAN IEEE802.3の例）

　I2SのSCLKとデータ（SD）も、同じようなエンコード処理を行えば同軸ケーブルや光ケーブル（単方向）で伝送できそうな気がしますね。このManchester Codeは更に改良されて8B/10B EncodingやPhase-Sift Keying（FSK）などに発展しましたが、S/PDIFでは採用されていません。S/PDIFは別のBiphase Mark Codeと呼ばれる方式（詳細は次回に説明します）が採用され、I2SのSCLKとSDataが別の方法で重畳（SCLKが埋め込まれて）されて1bitの信号になるように変調されています。

　EherNetはその後、10Base2（10Mbpsでケーブル長が2mまで）という規格が制定され、ケーブルが3C2Vと同じ太さの同軸ケーブル＋BNCコネクタとなり、ずいぶん使いやすくなりました。ただし、インピーダンスはTVのアンテナ用やS/PDIF用の同軸ケーブルと違って50Ωでした。当然、ボード上の送受信回路とのインターフェイスはトランス結合でアイソレーションされていました。しかし、ターミネータの位置やボード上でのFrame-GND、Signal-GNDの処理などで通信エラーが頻発し、抑え込むのにずい分苦労をしました。そのため、現在もあまり同軸ケーブルは使いたくありません。S/PDIFの場合、Ethernetに比べて周波数が低い（4Mbps以下）ので扱いやすいという利点はありますが、やはり両端でのインピーダンスマッチングやGND（同軸ケーブルのシールド側）の処理などをきちんとしないと、データ化けやGNDからの高周波ノイズの回り込みなどで苦労させられます。市販の製品のS/PDIF同軸入出力部を見ると、抵抗1丁でターミネイションしているだけで、基板上の信号線パターンのインピーダンスコントロールも行われておらず、とても簡略化されています。本来は同軸ケーブルよりも、GNDの分離という面では光（TOSLINK）の方が有利ですが、S/PDIFで使用されているTOSLINKカプラやプラスチックファイバの帯域幅が狭いという問題があります。これを解決するために、一部のAudio機器では「ST-Link」という名称でLANの10base-F対応の送受信モジュールや、コネクタ（カプラ）、光ファイバを採用していたようです。これなら10Mbpsが保証されていますので、サンプリング周波数を96kHzに上げても伝送可能でしたが、工場内LAN用として耐ノイズ性を売りにした10Base-Fがさっぱり普及せず（低価格の10Base-Tの性能が上がったので）、送受信モジュールやコネクタ、光ファイバが生産中止になってしまい、「ST-Link」も消滅（?）した感があります。

　IEEE1394（i-Link）やUSBのIsochrounous転送を含め、オーディオの世界はエラーがあっても再送や訂正のためのプロトコルが定められておらず、「聴き流す」だけが一般的なようです。　データ通信技術をずっと追いかけてきて、「録音時にA/D変換されたデジタルデータを正しくDACに伝える」ということをモットーとしている私たちから見るとちょっと困ったことです。

　次回はS/PDIFのエンコード（Biphase Mark Code）から、話を進めてゆきたいと思います。

#21 Digital Audioの伝送について（S/PDIF編 その1）

　前回のI2Sは機器内部でのLSI-LSI間のBusのようなものでしたが、S/PDIFは機器と機器の間でAudio信号を伝送するための信号です。Audio雑誌やAudio関連のHPやBlogなどでも、よく取り上げられていますが、単にコネクタやケーブルの紹介で終わっている記事が多く、私たちのように20年以上も、Digital信号の伝送で苦労してきた（失敗し続けて来た）側からの見解は少ないようです。私たちと同じような経験を持つ人達が、海外でもDigital Audioの伝送についていろいろ研究しているようで、その成果がCDのRipping（Error訂正のRetry付） → Memory → HD → Memory → DMA → Digital Transportation → DAC → Analog　という経路を持つ機器として発売されるようになったと思います。
　そのような機器の中で、今年になって発売されたものにLINN KLIMAX DSがあります。この機器にはS/PDIFの入力や出力が排除されていますが、これは「せっかく、Errorなしでマスタレコーディング時のLPCMデータを引っ張ってきたのに、DACに入れる前にS/PDIFでErrorが出てしまったら意味がない」という意思表示だと思います。もちろん、S/PDIFはErrorの発生や「データ化け」が生じにくいよう工夫されており、Error検出機構もあります。しかし、Source Device → Sink Deviceへの一方通行で再送要求やフロー制御のプロトコル（通信手順）はありません。CDの読み出し時にはCIRCという方式で読み出したデータの一部のbitが化けても、「たぶん、この位置のbitが化けたのだろう」と周囲の状況から判断して訂正する機能が働いています。「データが化けて音を悪くしている」とバッシングされているCDの読み出しにもError訂正があり、RippingならRetry（Errorがなくなるまで何度か読み出す）こともできます。しかし、残念ながらS/PDIFにはError検出はあっても、訂正や再送はありません。その場合は、別の通信手段でSink DeviceからSource Deviceに、再送を要求するしかありませんが、トランスポートやDACには実装されていません。したがって、S/PDIFは現状では一方通行、フロー制御、再送なしと理解しておいてください。

　S/PDIFに関する詳しい話に入る前にHDMI Audio SplitterやDigital伝送に関して、以前Tさんからいただいたコメントについて、またechiさんからもコメントをいただいていますので、先に簡単に回答させていただきます。
　実は、HDMIのAudio信号も、S/PDIFのようにFrame（Packet）化された信号が映像信号の合間を縫うような形で、垂直帰線区間（垂直同期信号の前のブランク期間）に伝送されています。垂直帰線区間というのは、まだTVがブラウン管（CRT）を使用していたころの名残で、画面の左上端から走査線が描かれ、右下端に達すると、左上端に戻ります。その戻るX線（走査線）の軌跡が光らないように、その期間は映像信号をOFFにしていました。同様に水平走査線を左端から右端へ1本描いたあと、次の水平同期信号が来るまでに左端に戻らなければなりません。当然、その期間は走査線（帰線）が光らないように映像信号をOFFにする必要があります。こちらの方は水平帰線区間ということになります。

（1）Tさんからのコメントについて。
　Tさんからいただいたコメントの全文は（2008年2月14日 CESで見つけたもの　その5）のコメント欄を参照してください。

　ご質問は
　　「HDMI-Audioスプリッターのお話に戻りますが、現状は入力信号をPLLにて
　　　クロックを抽出する形式かと想像していますが（違っていたらすみません）、
　　　v1.4からオーディオ信号のフロー制御が搭載されるという噂もあるので、
　　　是非外部クロック入力も搭載していただけたら幸いです。」
　ということでした。
　
　ご指摘のように現状はAudio Info Packetに含まれる情報や、HDMI Source Deviceにより設定されるN値、CTS値をもとにPLLでClock Recovery（クロック抽出）を行い、Audio用のMaster Clockを作成しています。サンプリングクロックFsは本Splitterで使用しているHDMI Receiver（SiI9135A）の場合、Localで28.322MHzの水晶発振子を持っており、それを分周して作成しています。抽出したMCLKにそのサンプリングクロックの位相を合わせて（coherent）、Audio FIFOから受信したAudio Packetを取り出し、S/PDIF出力信号や、8ch.分のI2S出力を作成しています。1920x1080p@60Hz Deep Colorの映像信号の垂直帰線区間では、I2Sは最高でch.あたり192kHzのFsまで対応可能ですが、入力されたオリジナルのLPCM信号をアップサンプリングすることはできません。DSDやDTS-HD、Dolby-TrueHDなどのbit streamに関しては、また別の機会に触れることにします。
　フロー制御はHDMI 1.3aでは規定されていませんので実装していませんが、1.3aではHDMIコネクタのところで映像信号と音声信号のズレ（Lip Sync）が20mS以内というように規定されています。しかし、本機のようなSplitterでは分離した後のAudio信号と映像信号が全く別々に処理されますので、大画面の場合はAudio信号にDigital Delay（Lip Sync）を追加して音声を遅らせないと、音声の方が先に聞こえてしまうという現象が生じます。この機能をSplitterに内蔵させるかどうかは検討中です。

（2）echiさんから頂いたコメントについて。
　echiさんから頂いたコメントの全文は（2007年12月13日 その16）のコメント欄を参照してください。

　ご質問は
　「PCでEEPROM?の内容を変えられるとのことですが
　　HDMIの24bit192kHz、7.1chのLPCMを
　　フロント2chSPDIF、
　　サラウンド２chSPDIF、
　　サラウンドバック２chSPDIF、
　　センター+サブウーハ2chSPDIF出力
　　ということができることを期待しています。
　　#もし著作権上SPDIFデジタルoutがマズイということでしたら、DACの前に改造用に
　　3線シリアルのパターンをつくっておいていただければ自分でやります」
　ということですが、

　HDMIではAudio Info Packetのデータ部にAudioソースのch.数やSpeakerの配置に関する情報が含まれています。本SplitterではSourecがLPCM5.1ch、7.1chの場合、3または4組のI2S出力にマッピングして出力します。I2Sのままでは前記のように機器外部へ引っ張り出すことは問題がありますので、各2chずつをS/PDIFにまとめて出力するか、Wirelessで飛ばすか、あるいはDACでアナログ変換したものを出力する予定です。悩んでいるのはSub Woofer出力で、市販されているSub Wooferはほとんどがアンプ内蔵でアナログ入力のみに対応しています。したがって、Sub Woofer出力だけはDACを内蔵させて、アナログ固定にしようかとも考えています。また、全体のマスターVRをどうしようかと考えています。S/PDIFやWirelessなどのdigitalで直接出力する場合、Digital Volumeを通過させる必要があります。

　Tさんからのコメントの回答でも述べましたが、アップサンプリングは出来ませんので入力ソースがLPCM24bit192kHzであれば、そのまま出力されます。コンサートなどのライブ録画・録音のBDのように高bit、高fsのLPCMで記録されているものを再生すればOKと思います。
　PS3ではSACDのMulti Ch.のDSDがどのようにLPCMに変換されてHDMIから出力されるかは、まだ調べていませんが、PS3の変換結果に従うことになります。

　Audio出力formatの変換はPCを接続して、コマンドを送れば可能ですが、HDMI Source機器からのオリジナルのAudio formatのbit数拡張やアップサンプリング、圧縮信号のデコードなどはできません。Ch.の再マッピングは可能ですが、アンプやSpeakerの接続をその時その時で変更するわけではありませんので、あまり使用することはないと思います。

　今回も、かなり長文になってしまい申し訳ありません。S/PDIFの詳細な話は次回にさせていただきます。

#20 Digital Audioの伝送について(I2S編)

　前回から1ヶ月ちかくも空いてしまい、申し訳ありません。前回に続きトランスポートとAudio信号のデジタル伝送について考えてゆくことにします。

　CDからの読出し以降、DACに伝えるまでがAudioトランスポートの役割であり、トランスポートと呼ばれる製品では、伝送されるのはアナログ信号ではなくデジタル信号です。Audio信号を伝送するための標準的なデジタル伝送フォーマットはI2Sと呼ばれる方式で、アナログ信号をデジタル信号に変換するA/Dコンバータの出力フォーマット、D/Aコンバータへの入力信号、Audio処理のDSPの入出力などで、このI2Sフォーマットが標準化されています。SACD（Super Audio CD）や1bit AudioではI2Sの代わりにDSDと呼ばれるフォーマットが使用されていますが、今のところ少数派なのでまずI2Sについて理解しておくべきだと思います。I2Sは下図のようにLRCK（Word Clockと標記される場合もあります）、SCLKまたはBCLK（Bit Clock）、SD（Serial Data）の3本の信号線で構成されています。この他に、DACやDSPによってはMCLK（Master Clock）を必要とする場合があります。

  LRCLKは期間中のデータがLeft（Ch.1）かRight（Ch.2）かを示すための信号で、'L'レベルでLeft、'H'レベルでRightを示します。周期はfs（サンプリング周波数）の逆数ですので、CDの場合は約22,6757μSec.となります。SCLK/BCLK（サンプリングクロックまたはbitクロック）はSD信号線のデータをサンプリングしてレベルを判断する基準となるクロックで、アクティブエッジ（Clockの立ち上がり）でSD上の信号レベルをラッチします。SDはAudioのアナログ信号をデジタイズしたデータそのもので、SCLK/BCLKを基準に各ビットの状態（'L'か'H'か）を反映するようにI2Sマスタから送り出されます。CDから読み出したデータはL,Rそれぞれ16bit、サンプリングが44.1kHzですので、前記のように図からLRCLKの周波数が44.1kHzであることがわかります。I2Sは図のようにL,Rそれぞれ32bitに拡張されていますので、CDからの16bitデータは図のb0（LSB）からb15の位置にはめ込まれ、のこりのb16からb23まで'0'がパディングされます。データ部の最初には1bitのガードbit、後部には7bitのパディングbitがあり、最近のAudio用LSIでは、この後部の余っているところにS/PDIFのような情報bitをはめ込むことができるものもあります。
　図から、SCLK/BCLKの周波数はfs（サンプリング周波数。CDの場合は44.1kHz）の64倍（Lが32bit、Rが32bit）になります。したがって2.8224MHzとなり、1bitの周期は354.3nSec.となります。SLCK/BCLKがぶれていなければ、だいたいこの真中あたりでSD上の信号がラッチされますので、SCLK/BCLKの立下りから100nS以内くらいにデータが確定していればデータが化けるということはなさそうです。実際にD/Aコンバータを動作させるためにはI2Sの信号以外にMCLK（Master Clock）という、すべての動作の基準となるClockが必要な場合があり、DACによって異なりますが128fsや256fs、512fsなど、fsの128倍や256倍あるいは512倍の周波数が必要です。CD専用ならばfsは44.1kHz 固定でもよいのですが、DVDを再生したり、96kHzや192kHzでサンプリングされた信号を伝送するためにはMCLKもそれらに対応できるような設計にしておく必要があります。データ長（bit数）はI2Sでは元々各Ch.あたり24bit用意されていますので、DACさえ自動判別で対応できれば、CDの16bitであろうが、24bit長のデータであろうが伝送することができます。

　I2Sは簡単で、LSIなどに組み込むロジック回路の設計も難しくないことからDAC（Chipレベル）の入力や、ADC（同様にChipレベル）の出力として標準的に採用されています。しかし、図からおわかりのように、伝送エラーに対するチェックが全く存在せず、しかもプロトコル（通信手順）もMasterからSlaveへの一方通行（コンピュータ通信の世界では、"たれ流し方式”と呼んでいます）で、エラー検出時の再送手順やフロー制御など何もありません。しかし、前記のようにLRCLK、SCLK/BCLK、MCLK相互間の同期さえきちんと取っておけば、SCLK/BCLKの立ち上がりでデータをラッチしていますのでClcok信号の波形の揺らぎや崩れなどに強いという特徴があります。元々、LSI－LSI間の信号ですので、これで当たり前ということです。REX-Linkシリーズでは、2.4GHzWireless受信回路の±5ppmという高い精度の水晶発振子を使用した発振回路から分周してMCLKやLRCLK,BCLKを作成し、きちんと同期を取ってDACに送りこんでいます。Audio製品やTVなどの民生用の水晶発振子とはグレードが違いますのでご安心ください。2.4GHzの通信回路では周波数偏差やふらつきが大きいと通信できませんし、TELECにも合格させることができません。また、基板設計時にもノイズが飛び込んで誤動作しないよう、配慮していますのでRF受信部とDACの間、USBインターフェイス部とRF送信部の間でI2S信号が化けるということはありませんので、ご安心ください。

　基板上でのDAC-Chipへの信号伝送はI2Sでもよいのですが、機器（トランスポート）と機器（市販の筐体入りのDAC、フルデジタルアンプなど）の間を接続するためには、さすがにI2Sではノイズの影響を受けやすく、しかも信号線も4本と多いのでI2Sとは別の伝送方式が標準化されています。民生用として一般的なのがSONYとPhilippsから提案され、特許料無料で公開されたS/PDIFです。業務用はAES3というバランス方式でCanonコネクタが使用されます。本Blogでは民生用を中心に考えていますのでS/PDIFについて考えてゆくことにします。また、S/PDIFはHDMIのAudio伝送でも使用されていますので、次回はS/PDIFのフォーマットや問題点について検討してゆきたいと思います。あわせてTさんから頂いたコメントに関しても回答してゆきたいと思います。回答がどんどん遅れて申し訳ありません。

#19 PC-Audioについて、もう1度整理してみます。

　約1ヶ月、本Blogの更新ができずに申し訳ありませんでした。その間にいくつかコメントをいただいていますので、簡単ですが回答も掲載したいと思います。PC-Audio、「PCでもっといい音を」ということで始まった本Blogですが、1年以上続けて、やっと同じようなことを考えておられる方々に少しずつ広まってきたのではないかという手ごたえを感じています。また、当社の直販モールでREX-Link2EXやREX-WHP2をご購入いただいた方に、澤野工房のJazzCDを1枚プレゼントさせていただいておりますが、こちらもご好評をいただいております。

　本Blogの基本方針として、いわゆる「オーディオ評論」のような意見は書かないというということを徹底しているつもりです。「音」というのは私たちの体感、記憶による部分が大きく、映像ならば並べて同時に見比べることができますが、音の場合はそうは行きません。あくまでも、その直前に聴いた音や場合によっては30年ほど前に初めて聴いたJBLとMachintosh275の音との比較だったりします。そのため、記事内容はできるだけ実験を重ねて、科学的根拠を見つけてからから掲載するように努めていますので、場合によっては時間がかかりすぎるようなこともありますがご容赦ください。

　PC-Audioという分野は幅が広いのですが、私たちがテーマとしているのは「PCをCDトランスポート」として使用するということです。同時に「使いやすさ」ということをテーマとして、特別なドライバソフトウェアをインストールしなくとも使える、iTunesなどの一般のアプリケーションソフトウェアでそのまま使える、Wirelessで置き場所に関係なく、かつPCからのGNDノイズに関係なく使えるということをテーマにしています。また、基本的には非圧縮のリニアPCM（DSDも使いたいのですが）を使用しています。30年近くソフトウェアの世界にもいますので、ソフトウェア工学から考えた場合、圧縮技術には興味があります。でも、今のところ非圧縮にこだわっている理由は下記のようなものです。
　わかりやすい例として、液晶TVとブラウン管TV、デジカメ写真と銀塩写真を見比べて見てください。私たちの目と脳は、景色を見た場合、遠くにあるものと近くにあるものをどのようにして認識していますか？　遠くにあるものは輪郭や境界がはっきりせず、色も無彩色に近くなっています。ブラウン管TVや銀塩写真などのアナログ画像はこれに近いので、私たちの目でみると遠近感や奥行が感じられます。これに対し、液晶TVやデジカメ写真の場合、遠くのものでも輪郭や境界がはっきりしていて色も鮮やかなため、何となく平板な画像に見えます。特に地デジTVなどのMPEG2方式は動かない背景から動いたものだけを抜き出して処理するという方式ですので、昔の映画の特撮のように絵の前で演技をしているようなものです。当然、自然な奥行感や色合いを出すために多くの人達が連日連夜、ソフトウェアの改良に取組んでいますが、まだまだ改良の余地はあると思います。音についても、映像ほどデータ量も多くなく、処理が複雑ではありませんが似たようなものだと思っていますので、現時点ではリニアPCMが入口で余計なことをしないということで「よい」と考えて採用しています。皆さん方はどうお考えでしょうか？　ロスレスというのは、PCでのファイル圧縮・解凍ソフトウェアと同様、圧縮後、復元しても元のデジタルデータ(!)と同じということで、MP3などのように圧縮時にファイルサイズを小さくするために高音域を切り捨てていないということですが、ソフトウェアで操作を行っていることは事実です。最近はメモリやHDDが安くなったにもかかわらず、必要のない圧縮や復元のために高額のライセンス料を徴収されるというのはどうかと思います。また、アンプなどを自作することを趣味としている方々にとって、手が出せないというのもマニアとしては面白くありません。
　
　PCをトランスポートとして使用するということと同様なアプローチとして、前々回（CESレポートの3回目/2008年1月31日）に紹介した、PS-AudioのMemory PlayerやLinn（機器そのものにCDドライブは内蔵していませんが、どこかでCDからリッピングしてネットワークサーバに入れなければなりませんので、個人ユースで使用するにはPS-Audioの方式の方がよいと思います。それにネットワーク経由で同時にいくつかの端末からアクセスできたりすると著作権の問題も浮上します）のネットワークプレーヤーなどがあります。私たちが使用しているPC-Audioの方式ではCD音源以外にNAXOSやNapstarなどのストリーミングにも対応していますので、改良を重ねて、これらの専用機に負けない音が出せればよいと思っています。
　PS-AudioのPlayerと私たちの方式の大きな違いは、リニアPCMに戻したデータをDACに転送する経路が違うということになります。PS-Audioの場合は専用のハードウェア・ソフトウェアで行っていますが、PC-Audioの場合はUSBを経由しています。
USBのソフトウェアはUSBポートのハードウェアに近い部分（ドライバと呼ばれるソフトウェア）の上に何段かのクラスドライバと呼ばれるソフトウェアが重なっています。そしてこの部分は音が途切れたりしないよう、アイソクロナス転送と呼ばれる時間優先の転送方式が使用されています。しかし、この部分はWindows VistaやMacOS X 10.5になって（10.4の後半から）、動作モードがKernelモード（特権モード）からUserモードに移されてしまい、以前よりも実行の優先度が低くなってしまいました。そのあおりでMacOS X 10.4.10 updater V 1.0がインストールされているとバチバチ音が混じってしまうということになりましたが、すぐに修正用パッチ（Audio update 2007-001）が配布され事なきを得ました。
　iTunesやMediaPlayerなどのアプリケーション ソフトウェアとUSB Audioドライバの間にはさらにAudio Mixerなどのソフトウェアが介在します。この部分が一番PC-Audioの音質に影響を与えていると思われている部分で、トーンコントロールやサラウンド処理、更にはサンプリングレートなどの変換も行います。当然、MacOSとWindowsでは全く違う（USBドライバは処理としてはほとんど同じですが）ソフトウェアが使用されています。
REX-Linkを使用されている方々はほとんど、これらの機能をOFFか「使用しない」に設定されていると思いますが、特別なドライバ ソフトウェアをインストールしなくとも使える、iTunesなどのアプリケーションがそのまま使用できるという方針を守り続けようとすると、このあたりが障害になるかも知れません。

　中途半端ですが、続きは次回に記載します。Tさんからいただいたコメントについても次回にコメントさせていただきます。

#3 2008 CESで見つけたもの その５

今回は、CESで見つけたオーディオ関係機器の写真を紹介します。

◆HITACHI　HDTV Distribution Network◆
　　 　　 　　

◆SAMSUNG◆
　　 　　 　　 　　 　　 　　 　　 　　

◆TRIBE◆
　　

◆その他◆
　　

　　

 





　次回からはCESの話題から離れて、REX-Link本来の話題に戻りたいと思います。

#3 2008 CESで見つけたもの その４

  CESレポート4回目は、DACで有名なMSB Technology社です。同社はDAC以外にもCDトランスポート、プリアンプ、パワーアンプを販売しています。さらにiPodを改造してデジタルAudio出力を取り出し、S/PDIFやAES信号に変換するiPod Docking Station（Transport）を発売しています。DACも他社のように半導体メーカー製の既製品を使用せずに、自分たち独自で作ったladder（梯子）DACを使用するという徹底ぶりです。iPodを改造してAudioトランスポートとして使用するという製品は昨年のCESでも同社の部屋で見せてもらいました。私見では、何もここまでという感があり、iPodに移す前にパソコンやMacで一度CDをリッピングしている訳ですから、それを取り出せばよいのにと思います。通常、iPod用の機器を開発販売する場合には、事前にAppleに申請して「made for iPod」というライセンスを取得する必要がありますが、多分そんなものは無視して自分たちで改造してしまっているものと思います。また、i.LINKというのはご存知のようにIEEE1394のAV用としてSONYが登録している商標です。こちらも使用するためにはSONYの使用許諾を得なければなりません。この件に関してMSBの社員に質問したのですが、「SONYのi.LINKとは別物」という回答でした。ゲリラ的にどんどんやるというのはいいと思いますが、製品そのものと関係がないところでユーザーや販売店、実装工場の人達に迷惑をかけることがありますので独自の名前をつけた方がいいと思います。

　改造できるiPodも限定されると思いますが、iPodから取り出したデコーダの出力を、ドッキングステーション内部のDSP（Analog DevicesのSHARC）でS/PDIFやAES信号に変換しているようです。選曲はiPodそのものを操作しなければならないので、iPodそのものをリモコン感覚で使用できるようにRFトランスミッタも用意されています。このあたりはREX-Link1Pと同じような発想ですが、REX-Link1PはiPodを改造せずそのまま利用するためにアナログ出力（イヤホン出力）を取り出し、A/D変換してから2.4GHzデジタルで送信しています。MSB i.LINKがどんな周波数、方式を使用しているかは独自方式だとしか教えてもらえませんでした。
　　

　肝心の音質ですが、DACやアンプが優秀なこともあっていい音が出ていました。本当はパソコン（Mac）とのUSB接続やPS Audioのような方式との比較などがあるともっとよかったのですが、各メーカー別に部屋を用意するという形式では無理と思います。　

　MSB iLinkの詳細は同社のHP<http://www.msbtech.com>を参照してください。日本語のいろんなサイトにも本機の紹介や試聴記事などがアップされています。iPod関連商品というとケースやジャケット、充電器の類がいっぱい販売されていますが、Audio機器としてまじめに取り上げているMSB社の製品はREX-Link1Pなどと共通するところがあり、同志に出会ったようで嬉しく思います。

　毎年CESを見にラスベガスへ行っており、ここ何年かはHi-End Audio関連の展示も見ていますが、Hi-endの世界にも新しい傾向が見られます。PC Audioもそのひとつで、パソコン（Mac）やiPodをデモの主役にしている展示ブースが少しずつ増えています。でも、PC Audioは音楽の入口だけですのでパワーアンプやスピーカー、ケーブルなどは今後も展示会の主役でありつづけると思います。とにかく、私達としては、まず音楽をきちんとアンプに伝えるところまでをきちんとしたいと考えています。また、Audio信号のWireless伝送もめずらしくなくなり、JBLまでもが'On Air Control 2.4G Wireless Speaker System'というシリーズで'CONTROL 2.4G'というWirelessスピーカーを発売しています。送信機はREX-Link2EXと同じくらいの大きさで、入力はアナログL,Rのみです。左側のスピーカーユニットに受信機とアンプ（15Wx2）が内蔵され、DC20V出力のACアダプターで電源を供給しています。送信機と受信機のペアリングはそれぞれのリアパネルに用意されている4段階（ID1,ID2,ID3,ID4）のスライドSWで合わせるようになっています。その他のメーカー（QUADまで）も同じようなWirelessスピーカーを展示していましたが、JBLの'CONTROL 2.4G'とinfinity<http://ww.infinitysystems.com>のWireless Subwoofer PS212W、AcousticReserch<http://www.audiovox.com> WPA24 Digital Wireless Transmitter/Receiver SystemがInnovations 2008賞を受賞していました。
　受賞製品の展示ブースでガラス越しに写した写真を添付しておきます。
◆JBL ONTROL 2.4G◆
　　

◆infinity Wireless Subwoofer PS212W◆
　

◆AcousticReserch  WPA24 Digital Wireless Transmitter/Receiver System◆
　　

#3 2008 CESで見つけたもの その３

PS Audioという会社の部屋に行くと、入口の真正面に春に発売予定のMemory Playerが静態展示されていました。まだ、正式名も決まっていないのでカタログもなく、HP<http://www.psaudio.com>の製品ページにも掲載されていません。最初はUMP（Ultra Memory Playerの頭文字）という名称にしようとしていたらしいのですが、あまりにも冴えないので一般募集することになったようです。賞品はこのTransportを1台くれるそうです。

　フロントパネルには2インチのカラーLCDが装備されており、いろんなメッセージだけでなく再生中の動画を表示することができます。ひょっとしたらLAN経由でGrace Noteにアクセスし、CDジャケットの画像をダウンロードして表示させることができるのかも知れません。肝心の機能ですが、Mac Bookのようなスロットローディング式のCDメカニズム（TEAC製で、静電気対策を施してあるとのこと）を内蔵しています。CDを挿入すると、エラー訂正を行いながら正確にAudio Digital dataを内蔵のメモリ上にコピーし、メモリ上のデータを独自に作成した正確な固定クロック（Jitterが少ない）に同期させて出力するという仕組みのようです。出力はS/PDIF（TOSlink・光、同軸）、AES、I2S（HDMIポートから出力される）の3種類です。DVDの映像などは、DVDから読み出してそのままHDMIから送り出されたり、フロントパネルのLCD上に表示されるようです。
　入力としてはCDメカ以外に、LANポート経由でNASやPC上にあるCDをリッピングしたデータを内蔵メモリ上にコピーすることができるとのことです。したがって、NAXOSやNapstar、Internet RADIOなどのストリーミングには対応していません。また、USBのAポート（ホスト側）も持っていますので、USBフラッシュメモリやマス ストレージクラスとして認識される携帯Audioプレーヤーなどを接続し、それらから音楽データを取り出して再生できるようですが、対応フォーマットなどの詳細は不明でした。価格はUS$1,495とのことです。

　この仕組みは私達が日頃、REX-Linkシリーズなどでパソコン（Mac）を使用して行っていることと基本的には同じです。CDの音楽データをエラー訂正を行いながら（PS AudioのMTではフロントパネルのLCDにエラー訂正情報がリアルタイムで表示されるようです）、メモリあるいはHDDにコピーし、それを独立した正確なクロックで読み出してDACに送り込むという処理は同じです。違いは一旦HDDにコピーするかどうか、それを読み出した後に、オーディオ処理用のドライバーソフトウェア、USBドライバーを経由させるかの違いです。また、通常のCDトランスポートとの違いは、一旦メモリ上にコピーして、独立した正確なクロックでLPCM信号を作り直すことによってCDの読出し時の問題を解決しようとしていることです。Word Sync機能や高価なルビジウム発振器による解決策と比べて、こちらの方が簡単なように思います。CD1枚は600MBですのでメモリは1GBもあれば充分です。最近は2GBのフラッシュメモリカードが信じられないような低価格で販売されていますので、このような機能（バッファメモリ内蔵のメモリトランスポート機能）が一般的になるのではないかと思います。PC AudioもAudio ドライバーソフトウェアを改良して負けないようにしなければなりません。

　例によって、写りの悪い写真ですが参考にしてください。
　

#3 2008 CESで見つけたもの その2

　教えられた部屋にゆくと、こちらも同じJoseph Audioのスピーカーを同じe.Oneのアンプで駆動しています。こちらは、Mac Book ProにBoot CampでWindows XPをインストールして、iTunesではなくMedia PlayerでWMV（非圧縮LPCM）ファイルを再生しています。また、DAC3との接続はUSBではなく、Mac Book ProのS/PDIF（光オーディオ）出力を使用していました。S/PDIFの場合は一方的に出力するだけで、フロー制御やエラーチェックができませんので問題かなとも思いますが、パソコン（Mac）側に余裕があれば、それでもよいのかも知れません。気になるe.OneのDAC3の中身ですが、もらった資料（StereoPhileという雑誌のReview記事・別刷）によると、意外と簡単でCS8416で入力された16bit/32kHzから24bit/96kHzまでのS/PDIFやAES,同軸などのいろんな信号を24bit/192kHzにアップサンプリングし、PCM1792一丁でアナログ変換しています。
USBからの入力は別のUSB専用DAC PCM2903を使用していますが、単にUSB→S/PDIFコンバーターとして使用しているだけで、S/PDIF変換した16bit/44.1kHzの信号はCS8416で他の信号と同様、24bit/192kHzにアップサンプリングされ、PCM1792に送り込まれます。この際にS/PDIFを光信号に変換し、フォトカプラを使用してUSBインターフェイス部（パソコン）と電気的に絶縁しているのではないかと思います。電源は昨年末、REX-Link2EXの実験用電源でも使用したNuvotemのトロイダルトランスが2個（Digital電源用とDAC出力部のOPアンプ用の電源用）使用されており、特別ややこしいこともせず基本に忠実な回路のようです。価格は1台US$2,450（約￥300,000）とのことです。

　もらったReview記事では、USB経由の音質についてPowerBook Titaniumに接続すると無音時のノイズが多くFM放送のようだとクレームをつけられています。Mac miniに変更するとノイズもなくなり、従来の入力（S/PDIFなど）と同程度にはなるが、それらに比べて、音にリズム感や、奥行き感が少ない、音楽に包み込まれる感じが少なく、高域のなめらかさも少ない。同じファイルをWi-Fi（Wireless LAN）経由でSqueezbox（Logitec製（日本のBrand名はLogicool）のLAN経由の圧縮ファイルデコーダ付きのDAC、US$300くらい）で再生したほうがいいとまで酷評されています。さらに、US$2,450ではなくUS$1,250くらいの価格帯を望むとまで言われてしまっています。

　しかし、Joseph Audioが自社のスピーカーのデモを行うために、堂々とMac Book + USB + DAC3を使用し、平気で酷評されているReveiwの別刷を配布していることや、実際に聴いた音から考えて、そんなに酷いとは思えませんし、bel canta社の自信やJoseph Audio社の信頼のようなものを感じます。Squeezeboxの音は昨年も騒がしいメイン会場でAVアンプ経由で聴いたことがあります。条件が違うので単純に比較はできませんが、DAC3の方が劣るということはないと思います。私としては「こんなReviewに負けるな、圧縮ファイルの再生とCDトランスポートの出力との比較ではなく、まずPCをHDDトランスポートとしてCDトランスポートに負けないような音にすべし」とDAC3とbel canto社を応援したくなります。
　PowerBook TitaniumのUSB AudioのFM放送のようなブツブツ音ですが、これはUSB Audio Driverの問題です。最近ではMacOS X-10.4の特定のVersion（Pre-install用）で、同じような問題があり、Appleから修正用Patchが提供されていました。パッケージ版についてはすぐに修正されましたので、もし同じような問題に遭遇されている方はMacOS Xのサイトを参照してください。日本でも「LAN経由ではなく、iTunesで出力するとシステムの警告音が音楽と一緒に出てしまう（AirTunesも同じなのですが）」というような評論記事をみかけますが、MacOS Xではきちんと音楽とシステム音の出力先を分離することができます。こういう基本的なことを知らないで執筆されたパソコン（Mac）＋ AudioのReviewをまだよく見かけます。

デモ中の写真を撮影したのですが、綺麗に撮れておらず申し訳ありません。詳しくはbel canto社のURL<http://www.belcantodesign.com>を参照してください。

　

　次回はPS AudioのMemory Transportについて紹介します。

#3 2008 CESで見つけたもの その1

　新年おめでとうございます。本Blogも2年目を迎えることになりました。これからも、ものをつくり続けるかぎりは続けてゆきたいと考えておりますので、よろしくお願い申し上げます。

　お正月明けからすぐにラスベガスで開催された2008 International CES（Consumer Electronics Show）に行ってきました。といっても、日本に帰国したわけではなく、まだSilicon ValleyのSanta Claraというところにいます。CESはご存知の方も多いと思いますが、本来は家電関係の展示会ですが、同じくラスベガスで毎年11月に開催されていたパソコン関係の展示会COMDEXがなくなった2002年以降はPC関係やデジタルAV家電、情報家電が中心になりつつあります。ホームシアターなど家電に近いオーディオ製品以外に、高級オーディオ関係をまとめた展示やデモもあります。2006年までは高級オーディオ関係はラスベガスのはずれのアレクシスパークというモーテル（街道沿いのモーテルとはちがって、駐車場は建物とは別にありますが）を借り切って行われていました。各部屋に出展社が陣取り、デモを行う形式ですが、一人で部屋の中に入ってゆくのは勇気が必要ですので、気の弱い人には不向きなスタイルでした。また、アレクシスパークは木造2階建のツーバイフォーの安普請の建物ですので、音響的にもよくなく、左右上下の部屋の音が聞こえてしまうという欠点がありました。
　昨年からはSansコンベンションセンターに隣接するベネシアンという高級ホテルのフロアを借り切って、1部屋ずつ出展社が陣取るようになりましたので遮音性はすこしはよくなりました。一部屋と言ってもベネシアンの場合は日本の3LDKのマンションくらいあります。しかし、大手メーカーの場合は、製品も多いので別の場所の会議室のようなところでデモを行っています。

　ベネシアンでは中小規模のスピーカーメーカー、アンプメーカー、アナログカートリッジのメーカーなどがデモを行っていましたが、その中でパソコン（Mac）やiPodだけを使用してデモを行っていた会社や機器について紹介しておきます。

　最初に見つけたのは、ミネソタ州のミネアポリスにあるbel cantoという会社の"e.One DAC3"というDACです。Joseph Audioという日本にも輸入されているスピーカーのメーカーの部屋に入るとMac BookをDAC3に接続し、e.One製のアンプでスピーカーをドライブしていました。音楽の再生に使用していたソフトウェアはiTunesでApple Lossless形式の音楽を再生していました。Mac BookはMacOS Xで動作させ、USB経由でDAC3に音楽を送り込んでいました。Joseph Audioのスピーカーは日本に輸入されていて、東京インターナショナルオーディオショーなどでも試聴することができます。東京で聴いたときは、あまり好きにはなれなかったのですが、CESで聴いてみると感じのいい音がしていました。それで、再生機器の方を見ると、CDプレーヤーではなく、なんとMac Book + iTunes + USB + DAC3だったわけです。例によって、あつかましくしつこく聞くと、「ここ�