JP2002328683A - データ送信装置、データ受信装置、データ送信方法、データ受信方法、伝送システム - Google Patents

Abstract

(57)【要約】 【課題】 データフォーマット変化への受信側の適切な
対応を実現する。 【解決手段】 送信側では、送信データストリーム内
に、当該送信データストリーム上でのデジタルデータの
データフォーマットの変化を事前に予告する変化予告情
報（ストリームチェンジノーティファイデータ）が含む
ようにし、受信側では、受信されたデータストリームに
含まれる変化予告情報に基づいて、デジタルデータのデ
ータフォーマットの変化を認識し、デコード処理をデー
タフォーマットの変化に応じて切換制御する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はデジタルデータをブ
ロック化して所定の伝送フォーマットで伝送する伝送シ
ステム、及びデータの伝送にかかるデータ送信装置、デ
ータ受信装置、データ送信方法、データ受信方法に関す
るものである。

【０００２】

【従来の技術】例えばオーディオデータについていえ
ば、Ｌ、Ｒの２チャンネルデータとすることが主流であ
るが、近年、３チャンネル、４チャンネル、或いはそれ
以上のチャンネルのオーディオデータについても広く実
施されている。即ちデジタルオーディオデータとしての
チャンネルフォーマットは非常に多様化している。ま
た、デジタルオーディオデータとしてのデータ形式も、
サンプリング周波数、量子化ビット数なども多様なフォ
ーマットが存在する。

【０００３】

【発明が解決しようとする課題】これら多様なデータフ
ォーマットのオーディオデータが存在することに応じ
て、オーディオデータの伝送フォーマットとしても、各
種チャンネル数や各種データ形式に対応できるようにす
ることが行われている。

【０００４】例えば、詳しい伝送データ構成については
後述するが、ＩＥＥＥ１３９４におけるオーディオデー
タの伝送においては、オーディオデータを含むブロック
と呼ばれる単位を連続させて伝送データストリームを形
成しており、当該ブロックにおいて各チャンネルのオー
ディオデータを配置するようにしている。そして複数の
ブロックを含むパケットのヘッダ、或いはブロック内の
付加的なデータとして、チャンネルフォーマットやデー
タ形式等の情報も含むようにし、受信装置側ではこれら
の情報やブロックのサイズなどからデータフォーマット
を確認することで、デジタルオーディオデータに対して
正しくデコード処理ができるようにしている。

【０００５】ところが、例えば音楽等のコンテンツデー
タを複数、連続して伝送する場合において、しかも、各
コンテンツデータのデータフォーマット、例えばチャン
ネルフォーマットが異なっていたような場合に不都合が
生じる。

【０００６】上記のように受信側ではオーディオデータ
等と同時に受信される付加的な情報やブロックサイズか
らデータフォーマットを認識し、オーディオデータのデ
コードを行うものである。このため、場合によっては楽
曲の曲頭部分のデコード処理が間に合わず、この受信側
での曲の再生（或いは記録媒体への記録）が頭切れを起
こすことがあり得る。

【０００７】例えば連続して伝送し、受信側で再生させ
ようとする第１の音楽コンテンツデータと第２の音楽コ
ンテンツデータが、共に５チャンネルのオーディオデー
タであるが、一方はＬ（左）、Ｒ（右）、ＬＦＥ（スー
パーウーハー用低域エンハンス：Low Freqency Enhance
ment）、Ｌｓ（後方左）、Ｒｓ（後方右）であり、他方
がＬ、Ｒ、Ｃ（センタ）、Ｌｓ、Ｒｓとされて、チャン
ネルフォーマットが異なるものであったとする。この場
合受信側では、上記ＩＥＥＥ１３９４伝送路に送出され
る伝送フォーマットのブロックについては、共に５チャ
ンネルであるため同一サイズとなり、第２の音楽コンテ
ンツデータを受信してみないと、変化したチャンネルフ
ォーマットを特定できない。これによりデコード処理の
遅れが生ずる場合がある。

【０００８】また、このような事態を回避するために
は、複数の楽曲コンテンツデータの伝送時には、伝送す
るデータストリーム上で、曲と曲の間に相当する部分に
ブランク（無音）データを挿入することが推奨されてい
る。しかしながら、特に音楽コンテンツデータの場合、
曲と曲の間に無音期間が挿入されることは必ずしも適切
ではない。例えば受信側で複数の曲をシームレスに再生
させたい場合でも、無音データの挿入により実現できな
くなる。もちろん単に無音データを挿入するのみでは変
化するデータフォーマットを特定することもできない。

【０００９】また、データストリームとは別系統のコマ
ンド伝送により、送信側の機器から受信側の機器にデー
タフォーマットの変化を伝えるという方式も考えられる
が、コマンドは伝送データストリームとは同期したもの
ではないため、リアルタイム性に欠け、受信側で最適タ
イミングでデコード処理を切り換えることは難しい。特
に受信装置側での制御部において受信処理負担が大きい
場合は、コマンド対応処理を迅速に行うことができない
場合もある。

【００１０】

【課題を解決するための手段】本発明はこのような状況
に鑑みて、デジタルデータをブロック化して所定の伝送
フォーマットにより伝送路で伝送する場合に、チャンネ
ルフォーマット等のデータフォーマットの変化をデータ
ストリーム上で事前に予告できるようにし、受信側で最
適なタイミングでデコード処理を切り換えることができ
るようにすることを目的とする。

【００１１】このため本発明では、各種のデータフォー
マットによるデジタルデータについて、所定の伝送フォ
ーマットで送出するデータ送信装置において、デジタル
データをブロック化処理をしたうえで上記伝送フォーマ
ットに合致した送信データストリームを生成するととも
に、当該送信データストリーム内には、当該送信データ
ストリーム上での上記デジタルデータのデータフォーマ
ットの変化を事前に予告する変化予告情報が含まれてい
るようにする伝送データ生成手段と、上記伝送データ生
成手段で生成された送信データストリームを送出する送
出手段とを備えるようにする。また上記変化予告情報
は、変化するデータフォーマットの内容を示す情報を含
むようにする。また上記変化予告情報は、データフォー
マット変化タイミングを示す情報を含むようにする。

【００１２】本発明のデータ受信装置は、デジタルデー
タが所定の伝送フォーマットとされて伝送されてきたデ
ータストリームを受信する受信手段と、上記受信手段に
より受信されたデータストリームから上記デジタルデー
タを抽出し、デコード処理するデコード手段と、上記受
信手段により受信されたデータストリームに含まれる変
化予告情報に基づいて、上記デジタルデータのデータフ
ォーマットの変化を認識し、上記デコード手段のデコー
ド処理をデータフォーマットの変化に応じて切換制御す
る制御手段とを備えるようにする。また上記制御手段
は、上記変化予告情報に含まれる、データフォーマット
の内容を示す情報に基づいて、上記デコード手段のデコ
ード処理内容を切換制御する。また上記制御手段は、上
記変化予告情報に含まれる、データフォーマット変化タ
イミングを示す情報に基づいて、受信されるデータスト
リーム上でのデータフォーマット変化タイミングを認識
し、当該データフォーマット変化タイミングで上記デコ
ード手段のデコード処理内容を切換制御する。

【００１３】また本発明は、上記構成のデータ送信装
置、データ受信装置により伝送システムを構成する。

【００１４】本発明のデータ送信方法は、各種のデータ
フォーマットによるデジタルデータについて、ブロック
化処理をしたうえで所定の伝送フォーマットに合致した
送信データストリームを生成するとともに、当該送信デ
ータストリーム内には、当該送信データストリーム上で
の上記デジタルデータのデータフォーマットの変化を事
前に予告する変化予告情報が含まれている伝送データを
生成し、送出する。

【００１５】本発明のデータ受信方法は、受信された所
定の伝送フォーマットのデータストリームからデジタル
データを抽出し、デコード処理するとともに、受信され
たデータストリームに含まれる、デジタルデータのデー
タフォーマットの変化を予告する変化予告情報に基づい
て、上記デコード処理の切換制御を行う。

【００１６】即ち本発明では、伝送するデータストリー
ム上で、チャンネルフォーマット等のデータフォーマッ
トの変化を予告する変化予告情報を含むようにすること
で、受信側にデータフォーマットの変化を認識させ、適
正なタイミングでデータフォーマット変化に対応したデ
コード処理内容の切換を実行させるようにする。

【００１７】

【発明の実施の形態】以下、本発明の実施の形態を次の
順に説明する。なお実施の形態ではＩＥＥＥ１３９４の
伝送フォーマットでオーディオデータを伝送するデータ
送信装置とデータ受信装置の例を説明する。 １．ＩＥＥＥ１３９４の伝送フォーマット ２．第１の実施の形態の伝送方式 ３．第２の実施の形態の伝送方式 ４．第３の実施の形態の伝送方式 ５．第４の実施の形態の伝送方式 ６．送信装置及び受信装置

【００１８】１．ＩＥＥＥ１３９４の伝送フォーマット まずＩＥＥＥ１３９４による伝送フォーマットについて
説明する。ＩＥＥＥ１３９４方式でのデータ伝送では、
例えば図１（ａ）に示すように、所定の通信サイクル
（例えば１２５μｓｅｃ）毎に時分割多重によって行わ
れる。そして、この信号の伝送は、サイクルマスタと呼
ばれる機器（ＩＥＥＥ１３９４バス上の任意の１台の機
器）が通信サイクルの開始時であることを示すサイクル
スタートパケットＣＳＰをバス上へ送出することにより
開始される。なお、サイクルマスタは、バスを構成する
ケーブルに各機器を接続したとき等に、ＩＥＥＥ１３９
４で規定する手順により自動的に決定される。

【００１９】１通信サイクル中における通信の形態は、
ビデオデータやオーディオデータなどのリアルタイム性
を必要とするデータを伝送するアイソクロナス伝送（Ｉ
ｓｏ）と、制御コマンドや補助的なデータなどを確実に
伝送するアシンクロナス伝送（Ａｓｙ）の２種類の伝送
が行われる。各通信サイクル中では、アイソクロナス伝
送用のアイソクロナスパケットＩｓｏが、アシンクロナ
ス伝送用のアシンクロナスパケットＡｓｙより先に伝送
される。アイソクロナスパケットＩｓｏの通信が終了し
た後、次のサイクルスタートパケットＣＳＰまでの期間
が、アシンクロナスパケットＡｓｙの伝送に使用され
る。従って、アシンクロナスパケットＡｓｙが伝送でき
る期間は、そのときのアイソクロナスパケットＩｓｏの
伝送チャンネル数により変化する。また、アイソクロナ
スパケットＩｓｏは、１通信サイクル毎に予約した帯域
（チャンネル数）が確保される伝送方式であるが、受信
側からの確認は行わない。アシンクロナスパケットＡｓ
ｙで伝送する場合には、受信側からアクノリッジメント
（Ａｃｋ）のデータを返送させて、伝送状態を確認しな
がら確実に伝送させる。

【００２０】図１（ｂ）に、ＣＩＰ(Common Isochronos
Packet)の構造を示す。つまり、図１（ａ）に示したア
イソクロナスパケットＩｓｏのデータ構造である。例え
ば、後述する１ビットデジタルオーディオデータ等の伝
送の際には、ＩＥＥＥ１３９４通信においては、アイソ
クロナス通信によりデータの送受信が行われる。つま
り、リアルタイム性が維持されるだけのデータ量をこの
アイソクロナスパケットに格納して、１アイソクロナス
サイクル毎に順次送信するものである。

【００２１】アイソクロナスパケットは、図１（ｂ）の
ように、１３９４パケットヘッダ、ヘッダＣＲＣ、ＣＩ
Ｐヘッダ、データ部、データＣＲＣから成る。

【００２２】上記ＣＩＰ構造として、例えばＳＡＣＤ
（Super Audio CD）方式の２チャンネルの１ビットデジ
タルオーディオデータの伝送に用いる場合の具体例を図
２に示している。

【００２３】なお１ビットデジタルオーディオデータと
は、通常のＣＤ（Compact Disc）におけるオーディオデ
ータよりも高品位なデータとして開発されたものであ
る。これは、サンプリング周波数を例えばＣＤ方式にお
ける４４．１ＫＨｚの１６倍という非常に高いサンプリ
ング周波数である２．８２２４ＭＨｚとしてΔΣ変調さ
れた１ビットデータのことであり、周波数帯域はＤＣ成
分〜１００ＫＨｚの広範囲とされ、ダイナミックレンジ
はオーディオ帯域全体で１２０（ｄＢ）を実現できるデ
ータ形式である。なお、本例ではこのような１ビットデ
ジタルオーディオデータをパケット化して伝送する場合
を例に挙げるが、もちろん伝送されるデータ自体の形
式、種別はどのようなものでもよい。

【００２４】図２では、横方向に３２ビット（４バイ
ト）を示しているが、その１行分のデータ、つまり３２
ビットが１カドレット（ｑｕａｄｌｅｔ）と呼ばれる。
ＣＩＰの先頭３２ビット（１カドレット）は、１３９４
パケットヘッダとされている。１３９４パケットヘッダ
においては、１６ビットのデータレングス（ｄａｔａ＿
Ｌｅｎｇｔｈ）、２ビットのタグ（ｔａｇ）、６ビット
のチャンネル（ｃｈａｎｎｅｌ）、４ビットのタイムコ
ード（ｔ ｃｏｄｅ）、４ビットのシンク（ｓｙ）が配
される。データレングス（ｄａｔａ＿Ｌｅｎｇｔｈ）
は、当該アイソクロナスパケット全体のデータ長を示し
ている。また６ビットのチャンネル（ｃｈａｎｎｅｌ）
は伝送チャンネルを示すものであり、Ｌ、Ｒ等のオーデ
ィオデータのチャンネルに相当するものではない。

【００２５】そして、１３９４パケットヘッダに続く１
カドレットの領域はヘッダＣＲＣが格納される。

【００２６】ヘッダＣＲＣに続く２カドレットの領域が
ＣＩＰヘッダとなる。ＣＩＰヘッダの上位カドレットの
先頭２バイトには、それぞれ‘０’‘０’が格納され、
続く６ビットの領域はＳＩＤ（送信ノード番号）を示
す。ＳＩＤに続く８ビットの領域はＤＢＳ（データブロ
ックサイズ）であり、データブロックのサイズ（パケッ
ト化の単位データ量）が示される。つまり、後述するデ
ータ部はｎ＋１個のデータブロックにより構成される
が、その一つのデータブロックのサイズが例えばカドレ
ット数で示される。続いては、ＦＮ（２ビット）、ＱＰ
Ｃ（３ビット）の領域が設定されており、ＦＮにはパケ
ット化する際に分割した数が示され、ＱＰＣには分割す
るために追加したカドレット数が示される。ＳＰ（１ビ
ット）にはソースパケットのヘッダのフラグが示され、
ＤＢＣにはパケットの欠落を検出するカウンタの値が格
納される。なお、図中「ｒｓｖ」はリザーブ、つまり未
定義の領域を示している。

【００２７】ＣＩＰヘッダの下位カドレットの先頭２バ
イトにはそれぞれ‘１’‘０’が格納される。そして、
これに続いてＦＭＴ（６ビット）、ＦＤＦ（８ビッ
ト）、ＳＹＴ（１６ビット）の領域が設けられる。ＦＭ
Ｔには信号フォーマット（伝送フォーマット）が示さ
れ、ここに示される値によって、当該ＣＩＰに格納され
るデータ種類（データフォーマット）が識別可能とな
る。具体的には、ＭＰＥＧストリームデータ、Ａｕｄｉ
ｏストリームデータ、デジタルビデオカメラ（ＤＶ）ス
トリームデータ等の識別が可能になる。ＦＤＦは、フォ
ーマット依存フィールドであり、上記ＦＭＴにより分類
されたデータフォーマットについて更に細分化した分類
を示す領域とされる。オーディオに関するデータであれ
ば、例えばリニアオーディオデータであるのか、ＭＩＤ
Ｉデータであるのかといった識別が可能になる。例えば
１ビットデジタルオーディオデータであれば、先ずＦＭ
ＴによりＡｕｄｉｏストリームデータの範疇にあるデー
タであることが示され、ＦＤＦに規定に従った特定の値
が格納されることで、そのＡｕｄｉｏストリームデータ
は１ビットデジタルオーディオデータであることが示さ
れる。ＳＹＴは、フレーム同期用のタイムスタンプが示
される。

【００２８】このようなＣＩＰヘッダに続いては、ＦＭ
Ｔ，ＦＤＦによって示されるデータが、データ部として
のｎ＋１個のデータブロック（ブロック＃０〜＃ｎ）の
シーケンスによって格納される。ＦＭＴ，ＦＤＦにより
１ビットデジタルオーディオデータであることが示され
る場合には、このデータブロックとしての領域に１ビッ
トデジタルオーディオデータが格納される。そして、デ
ータブロックに続いて最後にデータＣＲＣが配置され
る。

【００２９】この図２では、データ部にＳＡＣＤ方式の
２チャンネルの１ビットデジタルオーディオデータが配
されている例を示している。これは、ＩＥＥＥ１３９４
バスによるデータ伝送について適用できるＡＭ８２４と
呼ばれる伝送プロトコルに基づいた例であり、その場合
において１ビットデジタルオーディオデータとしてＬ、
Ｒの２チャンネルのオーディオデータを伝送する場合の
パケット構造例である。

【００３０】上述のように３２ビット（４バイト）を１
カドレット（Quadlet）と呼ぶと、この１ビットデジタ
ルオーディオデータとしての２チャンネルデータの場
合、４カドレット（ｑ１〜ｑ４）で１つのブロック（デ
ータブロック）が形成され、このブロックが連続するも
のとなる。なお、このため上記ＤＢＳ（データブロック
サイズ）には、４カドレットと記述されることになる。

【００３１】各カドレットにおける先頭のバイト（バイ
ト０）は、ラベルとされている。ラベルとは、そのカド
レットに配されるデータの識別情報となる。ラベルとし
ての値及び意味を図３に示す。図示するようにラベル値
に対して各種の意味が定義されており、例えばラベル値
４０ｈ〜４Ｆｈは、ＤＶＤ（Digital Versatile Disc）
システムで採用されているマルチビットリニアオーディ
オデータに対応するものとされる。なお、「ｈ」を付し
た数値は１６進表記のものである。またラベル値５０ｈ
〜５７ｈは、１ビットデジタルオーディオデータに対応
する値、ラベル値５８ｈ〜５Ｆｈは、エンコードされた
１ビットデジタルオーディオデータに対応する値、ラベ
ル値８０ｈ〜８３ｈはＭＩＤＩデータに対応する値とさ
れる。さらにＣ０ｈ〜ＥＦｈはアンシラリデータ（Anci
llary Data；補助データ）を意味するなど、ラベル値は
識別情報として機能するために各種定義されている。

【００３２】各ラベル値についての詳細な定義の説明は
本発明と直接関係がないため説明を省略するが、図２に
示した値についてのみ述べると次のようになる。

【００３３】図２においてブロック＃０の第１カドレッ
トｑ１をみると、ラベル値は「Ｄ１ｈ」とされている。
従って第１カドレットｑ１はアンシラリデータが記述さ
れるものと提示されていることになり、さらにこの場合
バイト１はサブラベルとされて「００ｈ」とされてい
る。このときバイト２，バイト３が実際の補助データ内
容となるが、ここではバリディティフラグ（Validity F
lag）Ｖ、コピーコントロール情報（Track Attribut
e）、チャンネル数（Ch Bit Num）、スピーカ配置情報
（Loudspeaker Config）が記述される。

【００３４】第２カドレットｑ２ではラベル値は「５０
ｈ」とされる。ラベル値５０ｈ〜５７ｈは、１ビットデ
ジタルオーディオデータに対応する値であるが、「５０
ｈ」は、マルチチャンネルのデータを配したブロックの
最初のデータであることを示す。また第３カドレットｑ
３ではラベル値は「５１ｈ」とされる。「５１ｈ」は、
マルチチャンネルのデータを配したブロックの２番目以
降のデータであることを示す。従って、第２、第３カド
レット（ｑ２、ｑ３）では、チャンネル１、チャンネル
２の２チャンネルの１ビットデジタルオーディオデータ
が配されていることが示されるものとなる。各チャンネ
ルのデータはバイト１〜バイト３の３バイトで記述され
る。

【００３５】第４カドレットｑ４では、ラベル値は「Ｃ
Ｆｈ」とされている。これはアンシラリデータの範疇で
あるが、「ＣＦｈ」は特に無効データ（NO DATA）を示
す値として定義されている。またバイト１はサブラベル
として無効データの内容を示す値とされており、この例
では「ＣＦｈ」とされている。そしてこのときバイト
２，バイト３が無効データにより充填される。

【００３６】なお、このように無効データを配するカド
レットが設けられるのは、一つのデータブロックが偶数
個のカドレットで構成されるという規定を満たすためで
ある。この例の場合は有効なデータを配したカドレット
が３つであるため、無効データのカドレットを追加して
いる。従って有効なデータを配するべく用意されたカド
レットが偶数個である場合は、無効データのカドレット
を追加する必要はない。

【００３７】ブロック＃１の第１カドレットｑ１では、
ラベル値は「Ｄ１ｈ」とされている。従って第１カドレ
ットｑ１はアンシラリデータが記述されるものと提示さ
れていることになり、さらにこの場合バイト１はサブラ
ベルとされて「０１ｈ」とされている。このときはバイ
ト２，バイト３の補助データ内容は、サプリメンタリデ
ータとされる。第２〜第４カドレットはブロック＃０と
同様である。

【００３８】このように各ブロックが構成されて、アイ
ソクロナスパケットＩｓｏにおけるデータ部が形成され
る。

【００３９】２．第１の実施の形態の伝送方式 以上のようなＩＥＥＥ１３９４による伝送フォーマット
を用いてデータを伝送する場合において、本発明の実施
の形態となる伝送方式を以下、説明していく。なお伝送
方式としては第１〜第４の実施の形態を順次説明してい
く。また、各実施の形態では、上記ＣＩＰ構造として、
例えばＳＡＣＤ（Super Audio CD）方式の５チャンネル
の１ビットデジタルオーディオデータの伝送に用いるブ
ロックフォーマットを用いる場合を例に挙げる。

【００４０】まず図４でブロックシーケンスの概要を述
べる。例えば上記図２で示したようにデータ部を構成す
るブロック＃０、＃１・・・に配されるオーディオデー
タは、元々の１ビットデジタルオーディオデータとして
のトラック（楽曲単位）から見ると図４に示す関係とな
る。

【００４１】図４（ａ）は１つの楽曲としてのデータ群
となるトラック（例えばＳＡＣＤとしてのディスクに記
録されている楽曲等のプログラム）をトラック＃Ｎとし
て示しているが、このトラック＃Ｎは図５（ｂ）のよう
に複数のフレームから構成される。公知のようにＣＤ方
式の場合、１つのフレームは７５Ｈｚ周期、即ち１３．
３ｍｓｅｃ分のオーディオデータに相当する単位であ
る。そして図４（ｃ）のように１フレームは１５６８ブ
ロック（ブロック＃０〜＃１５６７）で構成される。な
お、図４にフレームとして示すブロック＃０〜＃１５６
７の部分は、図１，図２で説明したアイソクロナスパケ
ットＩｓｏ内のデータ部に相当する部分である。

【００４２】図５に本例の、５チャンネルの１ビットデ
ジタルオーディオデータの伝送に用いるブロックフォー
マットを示す。図１のように構成されるアイソクロナス
パケットにおいて、１３９４ヘッダ、ヘッダＣＲＣ、Ｃ
ＩＰヘッダ、及びデータＣＲＣの構造については、この
図５の場合も、図２で説明したものと同様になるため、
重複説明を避ける。

【００４３】この場合は、データ部を構成するブロック
＃０〜＃１５６７が、５チャンネルのオーディオデータ
伝送用のフォーマットとされている。即ち、６カドレッ
ト（ｑ１〜ｑ６）で１つのブロック（データブロック）
が形成され、このブロックが連続するものとなる。な
お、このためＣＩＰヘッダにおけるＤＢＳ（データブロ
ックサイズ）には、６カドレットと記述されることにな
る。

【００４４】図４においてブロック＃０の第１カドレッ
トｑ１は、図２の場合と同様にラベル値は「Ｄ１ｈ」で
あり、サブラベルは「００ｈ」とされ、バイト２，バイ
ト３に補助データ（アンシラリデータ）が記述される。
この２バイトの補助データは、上記図２で説明したよう
に、バリディティフラグ（Validity Flag）Ｖ、コピー
コントロール情報（Track Attribute）、チャンネル数
（Ch Bit Num）、スピーカ配置情報（Loudspeaker Conf
ig）が記述されるが、さらに本実施の形態の場合は、図
２においてリザーブとされていたビット１７〜１９の３
ビットのうちの１ビットはストリームチェンジノーティ
ファイデータ（ＳＣＮ）とされる。このストリームチェ
ンジノーティファイデータとしてのビットが「１」とな
っている場合は、それが１ビットデジタルオーディオデ
ータについてのチャンネルフォーマット等のデータフォ
ーマットの変化を予告する情報となる。

【００４５】ブロック＃０の第２カドレットｑ２ではラ
ベル値は「５０ｈ」とされる。また、第３カドレットｑ
３〜第６カドレットｑ６ではラベル値は「５１ｈ」とさ
れる。そしてこの第２カドレットｑ２〜第６カドレット
ｑ６において、１ビットデジタルオーディオデータとし
ての第１チャンネル（ｃｈ１）〜第５チャンネル（ｃｈ
５）のデータが配される。この場合、例えばチャンネル
ｃｈ１はＬチャンネル、チャンネルｃｈ２はＲチャンネ
ル、チャンネルｃｈ３はＣ（センタ）チャンネル、チャ
ンネルｃｈ４はＬｓ（後方Ｌ）チャンネル、チャンネル
ｃｈ５はＲｓ（後方右）チャンネルとされる。

【００４６】後続するブロック＃１〜＃１５６７につい
ても、同様に第２カドレットｑ２〜第６カドレットｑ６
において、１ビットデジタルオーディオデータとしての
第１チャンネル（ｃｈ１）〜第５チャンネル（ｃｈ５）
のデータが配される。但し、各ブロック＃１〜＃１５６
７において、第１カドレットは、補助データ（アンシラ
リデータ）、サプリメンタリデータ、ＩＳＲＣ、無効デ
ータ（NO DATA）が、それぞれ配されることになる。

【００４７】図６（ａ）（ｂ）に、ブロック＃０〜＃１
５６７について第１カドレットｑ１のみを示したブロッ
クシーケンスを示す。図６（ａ）は、図４（ｂ）のよう
に連続するフレームについて一般的なブロックシーケン
スを示しており（フレーム＃Ｘとする）、図６（ｂ）
は、例えば図４（ａ）のトラック＃Ｎを形成するうちの
最後のフレームなどの、特定のフレーム（フレーム＃
Ｙ）のブロックシーケンスを示している。

【００４８】図６（ａ）に示すように、フレーム＃Ｘで
は、各ブロック＃０〜＃１５６７の第１カドレットｑ１
において、ブロック＃０にはアンシラリデータ、ブロッ
ク＃１〜＃（ｘ−１）にはサプリメンタリデータ、ブロ
ック＃（ｘ）〜＃（ｘ＋２）にＩＳＲＣが、それぞれ配
されている。なおブロック＃（ｘ＋３）〜＃１５６７の
第１カドレットｑ１は、無効データ（NO DATA）となっ
ている。そして、ブロック＃０のアンシラリデータにお
いては、図５に示したストリームチェンジノーティファ
イデータＳＣＮ＝０とされている。つまり、特にデータ
フォーマットの変化を予告する状態とはされていない。

【００４９】一方、フレーム＃Ｙにおいても、図６
（ｂ）のように、各ブロック＃０〜＃１５６７の第１カ
ドレットｑ１については、ブロック＃０にはアンシラリ
データ、ブロック＃１〜＃（ｘ−１）にはサプリメンタ
リデータ、ブロック＃（ｘ）〜＃（ｘ＋２）にＩＳＲ
Ｃ、ブロック＃（ｘ＋３）〜＃１５６７は、無効データ
（NODATA）とされている。但しブロック＃０のアンシラ
リデータにおいては、図５に示したストリームチェンジ
ノーティファイデータＳＣＮ＝１とされている。つま
り、データフォーマットの変化を予告する情報とされて
いる。

【００５０】即ち、例えば図４（ａ）のトラック＃Ｎと
トラック＃（Ｎ＋１）としてのオーディオデータを連続
して伝送する場合であって、トラック＃Ｎとトラック＃
（Ｎ＋１）のチャンネルフォーマット等が異なるもので
あった場合、トラック＃Ｎを構成する図４（ｂ）のフレ
ームのうち、少なくとも１つのフレームは、図６（ｂ）
のようにストリームチェンジノーティファイデータＳＣ
Ｎ＝１とされて、次のトラックでチャンネルフォーマッ
トが変化することを受信側に認識させるようにしてい
る。例えばＳＣＮ＝１となるフレーム＃Ｙとしては、ト
ラック＃Ｎを構成する最後のフレームとすればよい。そ
の場合、受信側は、ＳＣＮ＝１となるフレームが終了し
たら、次のフレーム（つまりトラック＃（Ｎ＋１）の先
頭フレーム）から、チャンネルフォーマットが変化する
ことを認識できる。

【００５１】もちろん、フレーム＃Ｙはトラックの最後
のフレームでなくてもよく、最後から３番目のフレーム
とするなどと設定してもよい。その場合、受信側ではＳ
ＣＮ＝１として予告されたフレームを含めて３フレーム
を経過後に、チャンネルフォーマットが変化すると認識
するように設定されていればよい。もちろん最後の数フ
レームをフレーム＃Ｙとして設定するなど、複数のフレ
ームにおいてＳＣＮ＝１としてもよい。

【００５２】ただしこの実施の形態の場合は、変化予告
情報としてのストリームチェンジノーティファイデータ
ＳＣＮによっては、フォーマット変化の予告のみしかで
きず、どのようなフォーマットに変化するかは受信側は
認識できない。従って受信側は、フォーマット変化タイ
ミングで、最初のフレームのブロック＃０において補助
データのうちのチャンネル数（Ch Bit Num）、スピーカ
配置情報（Loudspeaker Config）を確認して、デコード
処理の切換等の対応を行うことになる。

【００５３】３．第２の実施の形態の伝送方式 第２の実施の形態の伝送方式を図７，図８で説明する。
図７にアイソクロナスパケットの構造を示しているが、
基本的には上記図５と同様である。但し、上記第１の実
施の形態の場合のように、ラベル「Ｄ１ｈ」、サブラベ
ル「００」の補助データ（アンシラリデータ）において
ストリームチェンジノーティファイデータＳＣＮとして
のビットは設けられない。この場合は、補助データ内容
の同一のアンシラリデータがサブラベルによって区別さ
れて、そのアンシラリデータ自体がストリームチェンジ
ノーティファイデータＳＣＮとされる。

【００５４】即ち図７に示すように、ブロック＃０の第
１カドレットｑ１では、ラベル「Ｄ１ｈ」としてアンシ
ラリデータが配されるが、サブラベルが「００ｈ」とさ
れる場合と「４０ｈ」とがある。つまり本例では、或る
フレームにおいて、第１カドレットｑ１のサブラベルが
「４０ｈ」とされることで、当該カドレットがストリー
ムチェンジノーティファイデータＳＣＮとしての意味を
持つものとされる。

【００５５】図８（ａ）（ｂ）には上記図６の場合と同
様にフレーム＃Ｘ、＃Ｙとしてのブロックシーケンスの
例を示している。図８（ａ）に示すように、通常はブロ
ック＃０の第１カドレットｑ１は、ラベル「Ｄ１ｈ」、
サブラベル「００ｈ」とされてアンシラリデータが配さ
れるが、図８（ｂ）のように特定のフレーム＃Ｙでは、
ブロック＃０の第１カドレットｑ１は、ラベル「Ｄ１
ｈ」、サブラベル「４０ｈ」とされてアンシラリデータ
が配される。アンシラリデータ自体の内容は同一（但し
異なる情報内容を定義してもかまわない）であるが、こ
のラベル「Ｄ１ｈ」、サブラベル「４０ｈ」のアンシラ
リデータによって、受信側はチャンネルフォーマットの
変化を予告されたものと認識するようにする。

【００５６】例えばフレーム＃Ｙを、トラック＃Ｎを構
成する最後のフレームとするように規定した場合は、受
信側は、サブラベルが「４０ｈ」となるフレームが終了
したら、次のフレーム（つまりトラック＃（Ｎ＋１）の
先頭フレーム）から、チャンネルフォーマットが変化す
ることを認識できる。もちろん第１の実施の形態の場合
と同様に、フレーム＃Ｙはトラックの最後のフレームで
なくてもよく、また複数のフレームをフレーム＃Ｙに相
当するものとしてもよい。また、この実施の形態の場合
も、変化予告情報は、フォーマット変化の予告のみしか
できず、どのようなフォーマットに変化するかは受信側
は認識できないため、受信側は、フォーマット変化タイ
ミングで、最初のフレームのブロック＃０において補助
データのうちのチャンネル数（Ch Bit Num）、スピーカ
配置情報（Loudspeaker Config）を確認して、対応する
ことになる。

【００５７】４．第３の実施の形態の伝送方式 第３の実施の形態の伝送方式を図９，図１０，図１１で
説明する。図９にアイソクロナスパケットの構造を示し
ているが、基本的には上記図５と同様である。但し、上
記図５の第１の実施の形態の場合のように、ラベル「Ｄ
１ｈ」、サブラベル「００」の補助データ（アンシラリ
データ）においてストリームチェンジノーティファイデ
ータＳＣＮとしてのビットは設けられない。そしてこの
場合は、例えばブロック＃１の第１カドレットｑ１にお
いて示すように、ラベル「Ｄ１ｈ」、サブラベル「２０
ｈ」として、補助データの一種となるストリームチェン
ジノーティファイデータＳＣＮが定義され、当該第１カ
ドレットｑ１のバイト２，バイト３において２バイトの
ストリームチェンジノーティファイデータＳＣＮが記述
されるものとしている。

【００５８】図１０（ａ）（ｂ）には上記図６、図８の
場合と同様にフレーム＃Ｘ、＃Ｙとしてのブロックシー
ケンスの例を示している。図１０（ａ）に示すように、
フレーム＃Ｘでは、各ブロック＃０〜＃１５６７の第１
カドレットｑ１において、ブロック＃０にはアンシラリ
データ、ブロック＃１〜＃（ｘ−１）にはサプリメンタ
リデータ、ブロック＃（ｘ）〜＃（ｘ＋２）にＩＳＲ
Ｃ、ブロック＃（ｘ＋３）〜＃１５６７は無効データ
（NO DATA）が、それぞれ配されている。

【００５９】一方、フレーム＃Ｙにおいては図１０
（ｂ）のように、或るブロック、例えばブロック＃１に
おいては、その第１カドレットｑ１に、ラベル「Ｄ１
ｈ」、サブラベル「２０ｈ」に続いて２バイトのストリ
ームチェンジノーティファイデータＳＣＮが挿入され
る。例えばフレーム＃Ｙを、トラック＃Ｎを構成する最
後のフレームとするように規定した場合は、受信側は、
ラベル「Ｄ１ｈ」、サブラベル「２０ｈ」のストリーム
チェンジノーティファイデータＳＣＮが挿入されている
ことで、当該フレームが終了したら、次のフレーム（つ
まりトラック＃（Ｎ＋１）の先頭フレーム）から、チャ
ンネルフォーマットが変化することを認識できる。

【００６０】もちろん第１、第２の実施の形態の場合と
同様に、フレーム＃Ｙはトラックの最後のフレームでな
くてもよく、また複数のフレームをフレーム＃Ｙに相当
するものとしてもよい。

【００６１】さらにこの第３の実施の形態の場合は、変
化予告情報としてのストリームチェンジノーティファイ
データＳＣＮは、フォーマット変化の予告のみではな
く、どのようなフォーマットに変化するかも予告できる
ようにしている。図１１に２バイトのストリームチェン
ジノーティファイデータＳＣＮの定義を示す。即ちこの
場合は、２バイト（１６ビット）の数値により、変化さ
れる新たなチャンネルフォーマットを識別できるように
している。例えば図示するように変化する新たなチャン
ネルフォーマットとして、２バイト値が「００ｈ」（＝
００００００００００００００００）の場合はＬ、Ｒの
２チャンネル、２バイト値が「０１ｈ」（＝０００００
００００００００００１）の場合はＬ、Ｒ、Ｃ（セン
タ）の３チャンネル、２バイト値が「０２ｈ」（＝００
００００００００００００１０）の場合はＬ、Ｒ、Ｓ
（後方）の３チャンネル、２バイト値が「０３ｈ」（＝
００００００００００００００１１）の場合はＬ、Ｒ、
Ｌｓ、Ｒｓの４チャンネル・・・・・というように定義
される。

【００６２】従って受信側では、２バイトのストリーム
チェンジノーティファイデータＳＣＮの値を判別するこ
とで、どのようなチャンネルフォーマットに変化するか
についても前もって認識できるものとなる。

【００６３】５．第４の実施の形態の伝送方式 図１２で第４の実施の形態の伝送方式を説明する。これ
は、例えばラベル「Ｄ１ｈ」、サブラベル「２０ｈ」と
して２バイトのストリームチェンジノーティファイデー
タＳＣＮが配されるカドレットが、或るフレームの或る
ブロックにおいて形成されることは上記第３の実施の形
態と同様である。

【００６４】但しこの場合は、２バイトのストリームチ
ェンジノーティファイデータＳＣＮについては、図１２
ように定義される。即ち１バイトがカウントダウンナン
バとされ、１バイトが変化される新たなチャンネルフォ
ーマットを示す情報とされる。

【００６５】新たなチャンネルフォーマットを示す情報
は、上記図１１で示したものとほぼ同様にして、８ビッ
ト値に対して特定のチャンネルフォーマットが定義され
る。例えば図示するように１バイト値が「０ｈ」（＝０
０００００００）の場合はＬ、Ｒの２チャンネル、１バ
イト値が「１ｈ」（＝０００００００１）の場合はＬ、
Ｒ、Ｃ（センタ）の３チャンネル、１バイト値が「２
ｈ」（＝００００００１０）の場合はＬ、Ｒ、Ｓ（後
方）の３チャンネル・・・・・というように定義され
る。

【００６６】また１バイトのカウントダウンナンバとし
ては、チャンネルフォーマットが変化するタイミングま
でのカウントダウン値が配される。カウントダウン値と
しては例えば、あと何フレームでチャンネルフォーマッ
トが変化するか、或いはあと何ブロックで変化するか、
或いはあと何サンプルで変化するか、或いはあと何フレ
ーム何ブロック何サンプルで変化するか、等を示す値と
してのフレーム数、ブロック数、サンプル数等が記述さ
れる。

【００６７】なお、このようにカウントダウン値が受信
側に伝えられるようにすることで、当該ストリームチェ
ンジノーティファイデータＳＣＮの挿入位置について
は、特別に規定する必要はない。つまり、上記第１〜第
３の実施の形態の場合のように、例えば最後のフレーム
にストリームチェンジノーティファイデータＳＣＮを挿
入するなどと規定しておかなくても、受信側はストリー
ムチェンジノーティファイデータＳＣＮに含まれるカウ
ントダウン値からチャンネルフォーマットが変化するタ
イミングを認識できるものとなる。従って、送信側では
任意のブロックにストリームチェンジノーティファイデ
ータＳＣＮを挿入できる。また、多数のブロックにスト
リームチェンジノーティファイデータＳＣＮを挿入して
いき、カウントダウン値によって実際にカウントダウン
されていくようにすることもできる。

【００６８】つまり、次に伝送しようとするトラック＃
（Ｎ＋１）においてチャンネルフォーマットが変化する
場合において、現在伝送しているトラック＃Ｎの或るフ
レームの或るブロックにおいて少なくとも１回、ストリ
ームチェンジノーティファイデータＳＣＮを挿入して、
受信側ではそのストリームチェンジノーティファイデー
タＳＣＮに示されるカウントダウン値に基づいて受信デ
ータについてカウントダウンしていくことで、チャンネ
ルフォーマットの変化タイミングを認識するようにして
もよい。或いはまた、現在伝送しているトラック＃Ｎの
終端のフレームにおいて終端付近の複数のブロックにス
トリームチェンジノーティファイデータＳＣＮを挿入
し、各ストリームチェンジノーティファイデータＳＣＮ
におけるカウントダウン値でカウントダウンを行うこと
で、受信側にチャンネルフォーマットの変化タイミング
を認識させるようにしてもよい。

【００６９】なお、ここまでで伝送方式として各種実施
の形態を説明してきたが、これらはいずでも変化予告情
報たるストリームチェンジノーティファイデータＳＣＮ
をブロック内の補助的なデータとして挿入している。こ
れはＩＥＥＥ１３９４伝送フォーマットに対応して本発
明を実現でき、ＩＥＥＥ１３９４伝送フォーマットを採
用する機器間の伝送システムとして広く利用できるもの
となることを意味する。

【００７０】６．送信装置及び受信装置 続いて、上記各実施の形態の伝送方式を実現するための
データ送信装置及びデータ受信装置について説明する。
図１３は、或る２つの機器が例えばＩＥＥＥ１３９４に
よる伝送路３により接続されている場合に、送信装置１
を有する機器（又は回路部）から受信装置２を有する機
器（又は回路部）にオーディオデータを伝送するモデル
において本発明の実施の形態を示したものである。なお
受信装置２としては、伝送されてきたオーディオデータ
を再生出力する再生装置や、所定の記録媒体（ディス
ク、固体メモリ、テープなど）に記録する記録装置など
が想定される。オーディオデータは、上述したアイソク
ロナスパケットにより伝送されるものとし、そのオーデ
ィオデータは、例えば１ビットデジタルオーディオデー
タであるとする。

【００７１】図示するように送信装置１は、マルチチャ
ンネルデータソース１１，伝送データ生成部１２、送信
部１３、制御部１４が設けられる。

【００７２】マルチチャンネルデータソース１１は、１
又は複数チャンネルのオーディオデータを出力する。マ
ルチチャンネルデータソース１１の具体的な構成は多様
な例が考えられ、例えばディスクメディアや固体メモリ
メディア等の記録媒体に対する再生装置部、ネットワー
ク通信その他の受信装置部、ハードディスクドライブ等
によるサーバ装置部、などが考えられる。どのような装
置部であれ、ここでは１又は複数チャンネルのオーディ
オデータを出力できるものとされる。例えば音楽データ
として、ｎチャンネルのオーディオデータを出力する。

【００７３】伝送データ生成部１２は、マルチチャンネ
ルデータソース１１から供給されるｎチャンネルのオー
ディオデータを、上述した構成のブロック化処理を行
い、アイソクロナスパケットを形成していく処理を行
う。送信部１３は伝送データ生成部１２の出力をＩＥＥ
Ｅ１３９４バスによる伝送路３に送出する動作を行う。

【００７４】制御部１４は、伝送データ生成部１２のブ
ロック化処理を制御する。特に、マルチチャンネルデー
タソース１１から出力されるコンテンツデータ、つまり
受信装置２側に伝送しようとするコンテンツデータにつ
いての管理情報（例えばＣＤ方式のディスクにおけるＴ
ＯＣなどの管理情報）を参照し、各コンテンツデータの
データフォーマット（チャンネルフォーマット）を確認
して、連続して送信するコンテンツデータについてフォ
ーマット変化がある場合は、それに応じてストリームチ
ェンジノーティファイデータＳＣＮが挿入されるように
伝送データ生成部１２を制御するものとなる。

【００７５】受信装置２は、受信部３１，伝送パケット
デコード部３２、データデコード部３３、制御部３４を
備える。

【００７６】受信装置２において、受信部３１は、伝送
路３から供給されるデータを受信して取り込む動作を行
う。伝送パケットデコード部３２は、受信されたアイソ
クロナスパケットのデータについてパケットデコード処
理を行い、各ブロック内に配されている各チャンネルの
オーディオデータや、補助的な情報を抽出する処理を行
う。デコード部３３は、伝送パケットデコード部３２で
抽出されたｎチャンネルのオーディオデータについて復
号処理を行い、ｎチャンネルデータとして出力する。制
御部３４は、伝送パケットデコード部３２で抽出される
補助的なデータを取り込み、データのフォーマット、属
性等を判別する。そしてそれに応じてデータデコード部
３３を制御し、データのフォーマット等に応じたデコー
ド処理やチャンネル分配を制御する。また制御部３４
は、抽出されたストリームチェンジノーティファイデー
タＳＣＮに基づいて、データフォーマットの変化タイミ
ングを認識し、そのタイミングでデータデコード部３３
の処理を切換制御することになる。

【００７７】なお、デコード部３２は、伝送されてきた
データを所定チャンネル数の１ビットオーディオデータ
にまで復号して出力するものとしてもよいし、あるいは
更にリニアＰＣＭデータ等の形態にまで復号して出力す
るようにすることも考えられる。

【００７８】送信装置１から受信装置２への、データ伝
送は次のように行われる。マルチチャンネルデータソー
ス１１が伝送すべきデータとしてｎチャンネルの１ビッ
トデジタルオーディオデータを伝送データ生成部１２に
対して出力すると、伝送データ生成部１２では、各チャ
ンネルデータを取り込んで、図５等で説明した構造でア
イソクロナスパケットを形成していく。そしてそのよう
なパケットが送信部１３から受信装置３１に伝送され
る。

【００７９】また制御部１４は、伝送しようとする複数
のコンテンツデータについて、予めマルチチャンネルデ
ータソース１１から管理情報を確認し、例えば図１４の
ようなテーブルデータを作成しておく。例えば連続して
伝送するコンテンツデータをＣＴ１，ＣＴ２・・・とす
ると、各コンテンツについて、チャンネル数、サンプリ
ング周波数、量子化ビット数、スピーカ配置情報、演奏
時間（データサイズ）等のデータフォーマットに係る情
報を記憶しておく。

【００８０】そして、コンテンツデータの伝送時には、
上記のようにマルチチャンネルデータソース１１から出
力された１ビットデジタルオーディオデータがブロック
化されてパケットが構成されていくが、制御部１４は、
上記図１４のテーブルデータからデータフォーマット変
化点を認識し、その変化点より事前のタイミングとなる
位置において、伝送データ生成部１２のブロック化処理
の際にストリームチェンジノーティファイデータＳＣＮ
を挿入させる。例えば図１４の例の場合、コンテンツデ
ータＣＴ１，ＣＴ２は、チャンネルフォーマットが異な
るため、コンテンツデータＣＴ１の終端のフレームの或
るブロック、或いは複数のブロックにおいて、上述した
実施の形態の例のように、ストリームチェンジノーティ
ファイデータＳＣＮを挿入させる。

【００８１】受信装置２では、受信部３１で受信したパ
ケットについて、伝送パケットデコード部３２で処理を
行い、データブロックサイズＤＢＳ及びブロック内の各
カドレットのラベルの値に基づいて、ｎチャンネルの各
オーディオデータを抽出する。また、ラベル値、サブラ
ベル値に基づいて各種補助的なデータやストリームチェ
ンジノーティファイデータＳＣＮを抽出し、制御部３４
に供給する。制御部３４はストリームチェンジノーティ
ファイデータＳＣＮに基づいて、フォーマット変化タイ
ミングを認識する。また上記第４の実施の形態の例の場
合は、新たなチャンネルフォーマットについても認識す
ることになる。

【００８２】データデコード部３３には抽出されたｎチ
ャンネルの各オーディオデータに対してデコード処理を
行う。また、データデコード部３３に供給されるオーデ
ィオデータのフォーマットが変化する場合は、そのフォ
ーマットに合致したデコード処理方式が制御部３４によ
って指示されることで処理内容が切り換えられることに
なる。データデコード部３３でデコードされたオーディ
オデータは、図示しない後段の回路部においてアナログ
信号に変換され、増幅されてスピーカシステムから出力
されたり、或いはデジタルオーディオデータとして記録
系回路に供給され、ディスク、メモリカード（固体メモ
リ）、テープ等の記録媒体に記録される。

【００８３】このように、複数の音楽データ等のコンテ
ンツデータを連続して伝送する場合などにおいて、各デ
ータのチャンネル数が異なるなどにより伝送過程でデー
タフォーマットの変化が発生する場合であっても、受信
側ではその変化タイミングを伝送ストリームから認識で
きるため、最適なタイミングでフォーマットに応じた適
切なデコード処理に切り換えることができる。また、上
記第３，第４の実施の形態のストリームチェンジノーテ
ィファイデータＳＣＮが挿入される場合は、変化するフ
ォーマット内容も受信側で予め確認できるため、デコー
ド処理の切換処理のためには、より都合のよいものとな
る。

【００８４】以上、実施の形態を説明してきたが、本発
明はさらに多様な構成例が考えられ、多様な機器に導入
できるものである。また、上記例では送信側と受信側は
有線としてのＩＥＥＥ１３９４方式の伝送路３による伝
送システムとしたが、他の伝送規格によるものでもよ
く、また衛星通信、無線電話通信、赤外線伝送などの無
線伝送システムに本発明を適用できることはもちろんで
ある。また、伝送するデータはＩＥＥＥ１３９４伝送フ
ォーマットのアイソクロナスパケットに限定されるもの
ではなく、他の種のデータ伝送フォーマットにも本発明
を適用できる。更にオーディオデータとしては、１ビッ
トデジタルオーディオデータに限らず、マルチビットデ
ジタルオーディオデータの伝送にも当然に適用でき、ま
たビデオデータの伝送などにも応用できる。

【００８５】また、データフォーマットの変化として、
チャンネルフォーマットの変化の場合を例に挙げて説明
したが、データのサンプリング周波数、量子化ビット数
などのフォーマット変化の場合にも、当然デコード処理
を切り換えなければならないため、上記ストリームチェ
ンジノーティファイデータＳＣＮによって事前に受信側
に通知できるようにすることが好適である。さらには、
例えばオーディオデータ、ビデオデータを連続して送信
する場合に、オーディオデータからビデオデータに切り
替わることを通知することなども考えられる。

【００８６】

【発明の効果】以上の説明からわかるように本発明で
は、送信側では、送信データストリーム内に、当該送信
データストリーム上でのデジタルデータのデータフォー
マットの変化を事前に予告する変化予告情報（ストリー
ムチェンジノーティファイデータ）を含むようにし、受
信側では、受信されたデータストリームに含まれる変化
予告情報に基づいて、デジタルデータのデータフォーマ
ットの変化を認識し、デコード処理をデータフォーマッ
トの変化に応じて切換制御するようにしている。これに
より、受信側では伝送されてくるデジタルデータのデー
タフォーマットの変化に対応して適切なタイミングでデ
コード処理を切り換えることができ、受信データを正し
くデコードできる。例えばオーディオデータであれば頭
切れ等を起こさずにデコードデータを得ることができ
る。もちろんこれによって無音データの挿入等は必要な
くなるため、シームレスな音楽再生なども実現できる。
また、別系統のコマンド等ではなく、データストリーム
上で変化予告情報が得られるため、受信側でもデータフ
ォーマットの変化タイミングを正確に認識できる。

【００８７】また変化予告情報に変化するデータフォー
マットの内容を示す情報を含むことで、受信側で次のデ
ータフォーマットを正確に認識でき、デコード処理の切
換を適切に実行できる。また変化予告情報に、データフ
ォーマット変化タイミングを示す情報、例えばデータ変
化タイミングまでのカウントダウン情報を含むことで、
受信側でのデータ変化タイミングの認識に好適である。

【図面の簡単な説明】

【図１】ＩＥＥＥ１３９４による伝送フォーマットの説
明図である。

【図２】ＩＥＥＥ１３９４のアイソクロナスパケットの
説明図である。

【図３】データブロックのラベルの説明図である。

【図４】実施の形態のブロックシーケンスの説明図であ
る。

【図５】第１の実施の形態のアイソクロナスパケットの
説明図である。

【図６】第１の実施の形態のストリームチェンジノーテ
ィファイデータ挿入例の説明図である。

【図７】第２の実施の形態のアイソクロナスパケットの
説明図である。

【図８】第２の実施の形態のストリームチェンジノーテ
ィファイデータ挿入例の説明図である。

【図９】第３の実施の形態のアイソクロナスパケットの
説明図である。

【図１０】第３の実施の形態のストリームチェンジノー
ティファイデータ挿入例の説明図である。

【図１１】第３の実施の形態のストリームチェンジノー
ティファイデータの説明図である。

【図１２】第４の実施の形態のストリームチェンジノー
ティファイデータの説明図である。

【図１３】実施の形態の送信装置及び受信装置のブロッ
ク図である。

【図１４】実施の形態のストリームチェンジノーティフ
ァイデータの生成情報の説明図である。

【符号の説明】

１ 送信装置、２ 受信装置、３ 伝送路、１１ マル
チチャンネルデータソース、１２ 伝送データ生成部、
１３ 送信部、１４ 制御部、３１ 受信部、３２ 伝
送パケットデコード部、３３ データデコード部、３４
制御部

Claims (17)

【特許請求の範囲】
1. 【請求項１】 各種のデータフォーマットによるデジタ
   ルデータについて、所定の伝送フォーマットで送出する
   データ送信装置において、 デジタルデータをブロック化処理をしたうえで上記伝送
   フォーマットに合致した送信データストリームを生成す
   るとともに、当該送信データストリーム内には、当該送
   信データストリーム上での上記デジタルデータのデータ
   フォーマットの変化を事前に予告する変化予告情報が含
   まれているようにする伝送データ生成手段と、 上記伝送データ生成手段で生成された送信データストリ
   ームを送出する送出手段と、 を備えたことを特徴とするデータ送信装置。
2. 【請求項２】 上記変化予告情報は、変化するデータフ
   ォーマットの内容を示す情報を含むことを特徴とする請
   求項１に記載のデータ送信装置。
3. 【請求項３】 上記変化予告情報は、データフォーマッ
   ト変化タイミングを示す情報を含むことを特徴とする請
   求項１に記載のデータ送信装置。
4. 【請求項４】 デジタルデータが所定の伝送フォーマッ
   トとされて伝送されてきたデータストリームを受信する
   受信手段と、 上記受信手段により受信されたデータストリームから上
   記デジタルデータを抽出し、デコード処理するデコード
   手段と、 上記受信手段により受信されたデータストリームに含ま
   れる変化予告情報に基づいて、上記デジタルデータのデ
   ータフォーマットの変化を認識し、上記デコード手段の
   デコード処理をデータフォーマットの変化に応じて切換
   制御する制御手段と、 を備えたことを特徴とするデータ受信装置。
5. 【請求項５】 上記制御手段は、上記変化予告情報に含
   まれる、データフォーマットの内容を示す情報に基づい
   て、上記デコード手段のデコード処理内容を切換制御す
   ることを特徴とする請求項４に記載のデータ受信装置。
6. 【請求項６】 上記制御手段は、上記変化予告情報に含
   まれる、データフォーマット変化タイミングを示す情報
   に基づいて、受信されるデータストリーム上でのデータ
   フォーマット変化タイミングを認識し、当該データフォ
   ーマット変化タイミングで上記デコード手段のデコード
   処理内容を切換制御することを特徴とする請求項４に記
   載のデータ受信装置。
7. 【請求項７】 各種のデータフォーマットによるデジタ
   ルデータについて、ブロック化処理をしたうえで所定の
   伝送フォーマットに合致した送信データストリームを生
   成するとともに、当該送信データストリーム内には、当
   該送信データストリーム上での上記デジタルデータのデ
   ータフォーマットの変化を事前に予告する変化予告情報
   が含まれている伝送データを生成し、送出することを特
   徴とするデータ送信方法。
8. 【請求項８】 上記変化予告情報として、変化するデー
   タフォーマットの内容を示す情報を含むようにすること
   を特徴とする請求項７に記載のデータ送信方法。
9. 【請求項９】 上記変化予告情報として、データフォー
   マット変化タイミングを示す情報を含むようにすること
   を特徴とする請求項７に記載のデータ送信方法。
10. 【請求項１０】 受信された所定の伝送フォーマットの
    データストリームからデジタルデータを抽出し、デコー
    ド処理するとともに、 受信されたデータストリームに含まれる、デジタルデー
    タのデータフォーマットの変化を予告する変化予告情報
    に基づいて、上記デコード処理の切換制御を行うことを
    特徴とするデータ受信方法。
11. 【請求項１１】 上記変化予告情報に含まれる、データ
    フォーマットの内容を示す情報に基づいて、上記デコー
    ド処理内容を切換制御を行うことを特徴とする請求項１
    ０に記載のデータ受信方法。
12. 【請求項１２】 上記変化予告情報に含まれる、データ
    フォーマット変化タイミングを示す情報に基づいて、受
    信されるデータストリーム上でのデータフォーマット変
    化タイミングを認識し、当該データフォーマット変化タ
    イミングで上記デコード処理内容を切換制御することを
    特徴とする請求項１０に記載のデータ受信方法。
13. 【請求項１３】 各種のデータフォーマットによるデジ
    タルデータを所定の伝送フォーマットで送出するデータ
    送信装置と、伝送されてきたデジタルデータを受信する
    データ受信装置から成る伝送システムにおいて、上記デ
    ータ送信装置は、デジタルデータをブロック化処理をし
    たうえで上記伝送フォーマットに合致した送信データス
    トリームを生成するとともに、当該送信データストリー
    ム内には、当該送信データストリーム上での上記デジタ
    ルデータのデータフォーマットの変化を事前に予告する
    変化予告情報が含まれているようにする伝送データ生成
    手段と、上記伝送データ生成手段で生成された送信デー
    タストリームを送出する送出手段と、を備え、上記デー
    タ受信装置は、上記送信データストリームを受信する受
    信手段と、上記受信手段により受信されたデータストリ
    ームから上記デジタルデータを抽出し、デコード処理す
    るデコード手段と、上記受信手段により受信されたデー
    タストリームに含まれる上記変化予告情報に基づいて、
    上記デジタルデータのデータフォーマットの変化を認識
    し、上記デコード手段のデコード処理をデータフォーマ
    ットの変化に応じて切換制御する制御手段と、を備えた
    ことを特徴とする伝送システム。
14. 【請求項１４】 上記変化予告情報は、変化するデータ
    フォーマットの内容を示す情報を含むことを特徴とする
    請求項１３に記載の伝送システム。
15. 【請求項１５】 上記変化予告情報は、データフォーマ
    ット変化タイミングを示す情報を含むことを特徴とする
    請求項１３に記載の伝送システム。
16. 【請求項１６】 上記制御手段は、上記変化予告情報に
    含まれる、データフォーマットの内容を示す情報に基づ
    いて、上記デコード手段のデコード処理内容を切換制御
    することを特徴とする請求項１４に記載の伝送システ
    ム。
17. 【請求項１７】 上記制御手段は、上記変化予告情報に
    含まれる、データフォーマット変化タイミングを示す情
    報に基づいて、受信されるデータストリーム上でのデー
    タフォーマット変化タイミングを認識し、当該データフ
    ォーマット変化タイミングで上記デコード手段のデコー
    ド処理内容を切換制御することを特徴とする請求項１５
    に記載の伝送システム。