(57)【要約】【課題】  トラックを動的に切り替えて送信し、切り替えられた箇所を滑らかに再生することを可能にするコンテンツ配信方法、コンテンツ配信方法を用いたコンテンツ配信サーバ及びコンテンツ受信装置を提供する。【解決手段】  伝送制御部３２は、コンテンツデータのファイル名、トラック番号、およびコンテンツの再生範囲と共にコンテンツの再生要求メッセージを送信し、伝送制御部２２が再生要求メッセージを受信すると、コンテンツ取得部２１はファイル名、トラック番号、およびコンテンツの再生範囲に従って、指定されたトラックのコンテンツ素片を取得する。伝送制御部３２がトラック番号と共にトラックの切替要求メッセージを送信し、伝送制御部２２が切替要求メッセージを受信すると、コンテンツ取得部２１は、トラック番号に従って、送出したコンテンツ素片が有する時刻情報に連続する時刻情報を有する指定されたトラックのコンテンツ素片を取得する。【選択図】  図１
2005284041.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンテンツ素片データを有する複数のトラックを備えたコンテンツデータを記憶しているコンテンツ配信サーバと、このコンテンツ配信サーバに対して、ネットワークを介してコンテンツの再生要求を行い、その再生要求に応じてコンテンツ配信サーバからネットワークを介して送信される当該コンテンツ素片データを受信し再生するコンテンツ受信装置とを備えたコンテンツ配信システムにおけるコンテンツ配信方法であって、
前記コンテンツ配信サーバに記憶されているコンテンツデータは、ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号、トラックタイムスタンプ周波数、総フレーム数、音程の移調の度合いを示すトラックキー情報、パートナー音声の有無を示すトラックデュエット情報およびフレーム番号、再生のタイミングを示す時刻情報、コンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するものであり、
前記コンテンツ受信装置が、前記コンテンツ受信装置と前記コンテンツ配信サーバとの間でセッションを確立して前記コンテンツ素片データを受信するための事前情報であるセッション記述を要求する工程と、
前記コンテンツ配信サーバが、前記トラック毎に少なくとも前記トラック番号、前記トラックキー情報、前記トラックデュエット情報を含む前記セッション記述を送信する工程と、
前記コンテンツ受信装置が、前記セッション記述を受信すると、前記トラック番号に前記トラックキー情報および前記トラックデュエット情報を関連付けて表示する工程と、
前記コンテンツ受信装置が、前記コンテンツデータのファイル名、前記トラック番号、およびコンテンツの再生範囲と共にコンテンツの再生要求メッセージを送信する工程と、
前記コンテンツ配信サーバが、前記再生要求メッセージを受信すると、前記ファイル名、前記トラック番号、および前記コンテンツの再生範囲に従って、指定された前記トラックの前記コンテンツ素片データを取得、送信する工程と、
を有し、
前記トラックを切り替える際には、
前記コンテンツ受信装置が、前記トラック番号と共にトラックの切替要求メッセージを送信する工程と、
前記コンテンツ配信サーバが、前記切替要求メッセージを受信すると、前記トラック番号に従って、既送の前記コンテンツ素片データのうち再生順序が最後となっている前記コンテンツ素片データに連続して再生されるべき時刻情報を有する指定された前記トラックの前記コンテンツ素片データを取得して送信する工程と、
を有することを特徴とするコンテンツ配信方法。
【請求項２】
コンテンツ受信装置からの再生要求に従って、複数のコンテンツ素片データを有する複数のトラックを備えたコンテンツデータから再生要求されたコンテンツ素片データを選択し、選択したコンテンツ素片データを、ネットワークを介して前記コンテンツ受信装置へ送信するコンテンツ配信サーバであって、
ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、トラック番号、トラックタイムスタンプ周波数、総フレーム数、音程の移調の度合いを示すトラックキー情報、パートナー音声の有無を示すトラックデュエット情報およびフレーム番号、再生のタイミングを示す時刻情報、およびコンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するコンテンツデータを記憶するコンテンツ記憶手段と、
前記コンテンツ受信装置と前記コンテンツ配信サーバとの間でセッションを確立して前記コンテンツ素片データを受信するための事前情報であるセッション記述が要求されると、前記トラック毎に少なくとも前記トラック番号、前記トラックキー情報、前記トラックデュエット情報を含む前記セッション記述を送信し、
前記コンテンツデータのファイル名、前記トラック番号、およびコンテンツの再生範囲と共にコンテンツの再生要求メッセージと、前記トラック番号と共にトラックの切替要求メッセージを受信する伝送制御手段と、
前記伝送制御手段が前記再生要求メッセージを受信すると、前記ファイル名、前記トラック番号、および前記コンテンツの再生範囲に従って、指定された前記トラックの前記コンテンツ素片データを前記コンテンツ記憶手段から取得し、前記伝送制御手段が前記切替要求メッセージを受信すると、前記トラック番号に従って、既送の前記コンテンツ素片データのうち再生順序が最後となっている前記コンテンツ素片データに連続して再生されるべき時刻情報を有する指定された前記トラックの前記コンテンツ素片データを前記コンテンツ記憶手段から取得するコンテンツ取得手段と、
を備えることを特徴とするコンテンツ配信サーバ。
【請求項３】
複数のコンテンツ素片データを有する複数トラックを備えたコンテンツデータを記憶しているコンテンツ配信サーバに対して、ネットワークを介してコンテンツの再生要求を行い、その再生要求に応じてコンテンツ配信サーバからネットワークを介して送信されるコンテンツ素片データを受信し再生するコンテンツ受信装置であって、
コンテンツ配信サーバに記憶されているコンテンツデータは、ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、トラック番号、トラックタイムスタンプ周波数、総フレーム数、音程の移調の度合いを示すトラックキー情報、パートナー音声の有無を示すトラックデュエット情報およびフレーム番号、再生のタイミングを示す時刻情報、およびコンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するものであり、
前記コンテンツ配信サーバに対して、
前記コンテンツ受信装置と前記コンテンツ配信サーバとの間でセッションを確立して前記コンテンツ素片データを受信するための事前情報であるセッション記述を要求し、
前記セッション記述を受信すると、前記トラック番号に前記トラックキー情報および前記トラックデュエット情報を関連付けて表示し、
コンテンツを再生する際には、前記コンテンツデータのファイル名、前記トラック番号、およびコンテンツの再生範囲と共にコンテンツの再生要求メッセージを送信し、トラックを切り替える際には、前記トラック番号と共にトラックの切替要求メッセージを送信する伝送制御手段を備えることを特徴とするコンテンツ受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して、複数トラックから構成されるコンテンツデータを送信するコンテンツ配信サーバと当該コンテンツデータを受信再生するコンテンツ受信装置からなるコンテンツ配信システムにおいて、トラックを動的に切り替えて送信し、切り替えられた箇所を滑らかに再生することを可能にするコンテンツ配信方法、およびコンテンツ配信方法を用いたコンテンツ配信サーバ、およびコンテンツ受信装置に関する。
【背景技術】
【０００２】
現在、通信カラオケシステムと呼ばれるカラオケシステムが一般的に用いられている。この通信カラオケシステムの大部分は、MIDI（Musical Instrument Digital Interface）に類する音色や譜面情報を含む曲データを再生前に受信しておくダウンロードシステムを採用している。MIDIは、PCM（Pulse Code Modulation）等のサンプリングを基調としたデジタル音声データと比較して、1/10〜1/100程度のデータ量であり、公衆電話回線等の狭帯域通信路を用いてデータ配信サービスを行うのに好適であるため、通信カラオケシステムに多く採用されている。コンテンツ受信装置では、受信した曲データ（MIDIデータ）を、予め多種の楽器に相当する音色を備えたMIDI音源装置によって演奏することで、利用者にサービスを提供している。
【０００３】
一方で、カラオケシステムには、キーコントロール機能が必要である。キーコントロール機能とは、利用者の声質にあわせて楽曲の音程を調整することで、快適に歌いやすくするための機能である。既存のMIDIを採用した通信カラオケシステムの場合、キーコントロールは、MIDIに含まれる譜面情報に対して移調処理を行うことで、極めて容易に実現できる。
【０００４】
一方で、MIDIを採用した通信カラオケシステムでは、近年の高品質化の要望に伴って、様々な問題が生じている。例えば、楽曲の音質を高品質化したい場合、MIDIで操作できる部分は譜面情報のみであるため、コンテンツ受信装置の音源を交換または改修しなければならない。これは利用者（または店舗）が数十万世帯に達する通信カラオケシステムでは莫大なコストとなる。
【０００５】
また、近年では、通信カラオケシステムにおいて、バックコーラス、あるいはデュエット曲におけるパートナー音声（例えば、利用者が男性であれば、女性が歌うパートナー音声）の需用が高まっている。しかし、上述のように、MIDIは譜面情報が主であるため、楽曲にあわせて別の手段でバックコーラスやパートナー音声のデータを伝送する必要があった。
【０００６】
次に、ストリーミングシステムを応用した通信カラオケシステムについて述べる。
【０００７】
近年、インターネットにおいては、受信側で再生コンテンツの曲データ全てを蓄積せずに、受信しながら再生するストリーミングシステムが盛んに利用されている。一般的なストリーミングシステムは、MPEG（Moving Picture Experts Group）等の高能率符号化方式によってデジタル化された再生コンテンツを扱うことが多い。
【０００８】
例えば、音声であればPCMデジタルデータをMPEG Audio Layer2,3,AAC（Advanced Audio Coding）等の高能率符号化処理を施すことで、データ容量を1/3〜1/15程度に圧縮でき、近年のADSL（Asymmetric Digital Subscriber Line：非対称デジタル加入者線）等のブロードバンド通信路を用いての実時間伝送が可能となってきた。
【０００９】
このストリーミングシステムでは、再生コンテンツを全てコンテンツ受信装置に蓄積する必要がないため、原音に非常に近いがMIDIよりも大容量の高能率符号化された曲データを迅速にコンテンツ受信装置へ提供できる。この特徴により、バックコーラスやパートナー音声入りの曲データを原音に近い品質で利用者に提供するので、サービスの高品質化に寄与できる。
【００１０】
しかしながら、ストリーミングシステムを採用した通信カラオケシステムでは、キーコントロール機能を付加しようとすると、その演算量が問題となる。MIDIの場合は、元が譜面情報であるがゆえに、あたかも楽譜を書き換えるかのように簡単に移調できる。しかし、PCMやMPEG Audio等の曲データの場合は、音声の特徴を利用して移調と同じ効果を得なければならない。
【００１１】
例えば、特開平９−１８５３９２号公報（特許文献１）では、周波数変換を基調とした音程変換装置が開示されているが、これは周波数領域におけるピッチシフトに相当し、MIDIでの移調と比較して莫大な演算を必要とする。それゆえに、ストリーミングシステムを採用した通信カラオケシステムでは、コンテンツ受信装置に莫大な演算を行うことができる音程変換手段を搭載しなければならなかった。
【００１２】
ここで、映像・音声等の実時間配信に用いられているストリーミングシステムの非同期モデルについて説明する。
【００１３】
Ethernet（登録商標）（IEEE802.3）を代表とする小さなデータサイズの伝送フレームの相互交換を基調としたデータリンクでは、エンド・ツー・エンド接続された２つの通信装置間に同期クロックは存在しない場合が大半であり、データリンクを下位層として、複数のネットワーク間のパケット交換を可能にするためのIP（Internet Protocol,RFC791等）、さらにIPを下位層としてIPパケットを用いてセッション（通信路）管理を行うためのTCP（Transmission Control Protocol,RFC793）やUDP（User Datagram Protocol,RFC768）などのネットワークプロトコルにも同期クロックは存在しない。
【００１４】
そのため、ある通信装置から送信された伝送フレームがいつ何時目的の通信装置へ届くかは保証されない。また、伝送フレームの送信から受信までに発生する時間遅延は一定ではなく、時間揺らぎ（ジッタ）が生じる。また、伝送フレームは伝送路上で消失することもあり、ある時間軸に沿って複数の伝送フレームを送信したとしても、その到着順序は保証されない。
【００１５】
ところで、ストリーミングシステムとは、ネットワークを介してコンテンツを受信し再生するシステムのうち、受信側でコンテンツの全てを蓄積せずに、受信しながら再生が可能となるようなシステムの総称である。映像・音声等は、実時間性を持ったコンテンツであるから、1秒間に所定のコマ数（例えば29.97フレーム／秒）で再生するといった再生同期制御が必須であり、同期クロックの存在は好適であると言える。例えば、ＴＶ放送においては、NTSC_TV信号におけるフレーム同期信号と呼ばれる同期クロックが存在し、受信側は、送信側の同期クロックを用いて非常に高い精度で再生することが可能である。
【００１６】
しかし、IPをベースとしたIPネットワークを介したストリーミングシステムでは、上述のような同期クロックがなく、送信側と受信側を同期させることはできない。必然的に非同期モデルによって再生機構を実現せざるを得ない。非同期モデルとは、各々の機器自身のシステムクロックを基準として動作する構成およびプログラミング手法である。
【００１７】
図９に、コンテンツ配信システム１０１ａ（非同期モデル）におけるコンテンツ配信サーバ１０２ａとコンテンツ受信装置１０３ａの機能ブロック図を示す。コンテンツ配信サーバ１０２ａとコンテンツ受信装置１０３ａは、IPネットワーク１０４によって相互に接続される。
【００１８】
コンテンツ配信サーバ１０２ａは、コンテンツ取得部１０２１、送信部１０２２、システムクロック発振部１０２３、およびコンテンツ記憶部１０２４を有する。
【００１９】
コンテンツ取得部１０２１は、再生するコンテンツのコンテンツデータをコンテンツ記憶部１０２４に記録し、任意のファイルポインタ（コンテンツ上の読み出し位置）を用いてコンテンツ素片を取得する機能を有する。この時、ファイルポインタとは、コンテンツファイル名、トラック番号、フレーム番号の３つのうちいずれか、もしくはそれらのうちいくつかの組み合わせである。また、“コンテンツ素片”とは、任意のデータ長を有するコンテンツの実データのことを指す。
【００２０】
コンテンツ取得部１０２１は、システムクロック信号に従ってコンテンツ素片を読み出す。コンテンツ取得部１０２１は、内部にコンテンツファイル名、トラック番号、フレーム番号等の初期値を持ち、起動時から自動的に読み出しを開始しても良いし、外部入力からコンテンツファイル名、トラック番号、コンテンツ再生開始時刻を得てから読み出しを開始しても良い。また、コマンド入力を受け付ける外部入力を設け、コマンド入力＝再生開始定数（例えば“PLAＹ”）である場合は再生するようにしても良いし、コマンド入力＝再生停止定数（例えば“STOP”）である場合は停止するようにしても良い。あるいは自動読み出し開始動作と外部読み出し開始動作を自動的に判別するようにしても良い。
【００２１】
また、システムクロック発振部１０２３は、水晶発振子等で実現されたリアルタイムクロック（高精度の時計）であり、システムクロック信号をコンテンツ取得部へ供給する機能を有する。
【００２２】
送信部１０２２は、セッションと呼ぶ仮想的な通信路を確保し、コンテンツ素片を適切なヘッダを付加してパケット化し、そのパケットを、IPネットワーク１０４を介してコンテンツ受信装置１０３ａへ送信する機能を有する。例えば、ヘッダにはネットワークタイムスタンプが含まれる。
【００２３】
パケットを送信する際には、送信部１０２２は、コンテンツ受信装置１０３ａへパケットを届けるために送信アドレスを用いる。送信アドレスは、送信アドレスと送信ポート番号の組で構成される。送信アドレスは送信部１０２２内部の定数として予め持っていてもよいし、他のブロックから入力を受け付けてもよい。なお、パケットを送信するためのセッション（通信路）は送信アドレスが確定した時点で動的に確立するものとする。また、コンテンツ素片とパケットが必ずしも一致する必要はない。
【００２４】
また、コンテンツ受信装置１０３ａは、受信部１０３１、バッファ部１０３２、システムクロック発振部１０３３、コンテンツ読取部１０３４、および再生部１０３５を有する。
【００２５】
受信部１０３１は、IPネットワーク１０４からパケットを受信して、ヘッダを解釈して、コンテンツ素片を抽出し、バッファ部１０３２に供給する機能を有する。受信部１０３１は、コンテンツ配信サーバ１０２ａからのパケットのうち自己に必要なパケットのみを受信するために受信アドレスを用いる。受信アドレスは、受信アドレスと受信ポート番号の組で構成される。受信アドレスは受信部１０３１内部の定数として予め持っていても良いし、他のブロックから入力を受け付けても良い。
【００２６】
バッファ部１０３２は、コンテンツ素片をヘッダから得られたネットワークタイムスタンプ（後述）と共に一次的に蓄積記憶する機能を有する。
【００２７】
コンテンツ読取部１０３４は、バッファ部１０３２を監視し、再生に十分なコンテンツ素片が蓄積されたと判断した時点から、システムクロック発振部１０３３からのシステムクロック信号に従ってコンテンツ素片の読み出しを開始し、コンテンツ素片の集合をコンテンツに復元して出力する機能を有する。
【００２８】
再生部１０３５は、入力されたコンテンツ素片に応じた復号化を行い、スピーカ等の所定の出力装置に対して音声信号、映像信号を出力する機能を有する。例えば、コンテンツ素片がMPEGに類する高能率符号化されたデジタル音声データである場合、再生部１０３５は、高能率符号復号器（デコーダ）、D/A変換器、アナログアンプ等を有して構成される。
【００２９】
図９に示すコンテンツ配信システムａ（非同期モデル）の第１の特徴は、コンテンツ配信サーバ１０２ａとコンテンツ受信装置１０３ａが個別にシステムクロック発振部１０２３、１０３３を有する点にある。両者のシステムクロック周波数の精度は相当に高い必要はあるが、伝送路であるIPネットワーク１０４が同期クロックの伝送機構を備えてはいない。
【００３０】
また、第２の特徴は、コンテンツ受信装置１０３ａがバッファ部１０３２を備え、バッファ部１０３２が空にならないようにコンテンツ読取部１０３４を構成することによって、再生部１０３５が映像・音声等の実時間性を持ったコンテンツを再生する場合であっても、IPネットワーク１０４によって生じるパケットの時間遅延や時間揺らぎ（ジッタ）を吸収しつつ、正常な再生を継続する点にある。
【００３１】
以上が、映像・音声等の実時間配信に用いられているストリーミングシステムの非同期モデルの概要である。
【００３２】
次に、ストリーミングシステムにおける再生時刻管理について説明する。
【００３３】
まず、コンテンツの再生時刻の付与方法について説明する。
【００３４】
上述の非同期モデルにおいては、コンテンツが連続メディアとして正しい再生時刻に再生されるためには、コンテンツ再生時刻をコンテンツ素片に関連付けて伝送する必要がある。例えば、図９において、コンテンツ読取部１０３４が、0秒0フレーム目の映像に相当するコンテンツ素片を選び出して、再生部１０３５に出力するためには、そのコンテンツ素片が0秒0フレーム目のデータであることを示すコンテンツ再生時刻が必要である。そうしなければ、ネットワーク上で時間遅延などが生じた場合は、そのまま再生時の時刻がずれてしまうことになる。
【００３５】
ストリーミングシステムにおいては、コンテンツ素片にコンテンツ再生時刻を付与するために、RTP（Real-time Transfer Protocol,RFC1889）を用いることが多い（Audio-Video Transport Working Group, "RTP: A Transport Protocol for Real-Time Applications",RFC1889, Internet Engineering Taskforce, Jan 1996）。RTPでは、コンテンツ素片をペイロード（貨物）とし、また、ペイロードに先立って付与される最低96bitのRTPヘッダを主体とし、そのうち32bitがRTPタイムスタンプと呼ばれるネットワークタイムスタンプ（コンテンツ再生時刻情報を変形したもの）に割り当てられている。
【００３６】
RTPタイムスタンプは、予めコンテンツの種類によって定められた、RTPタイムスタンプ周波数によって実時間に写像される。RTPタイムスタンプ周波数は、ネットワークタイムスタンプ周波数とも呼ばれる。一般に、MPEGの定めた高能率符号化方式によってデジタル化されたコンテンツの場合、RTPタイムスタンプ周波数には90000（90KHz）を用いることが多い。これは、1秒分のコンテンツを読み出した時、RTPタイムスタンプは+90000増加されることを意味する。つまり、RTPタイムスタンプに類するネットワークタイムスタンプとネットワークタイムスタンプ周波数とコンテンツ再生時刻には、以下の式が成り立つ。
【００３７】
[数１]
コンテンツ再生時刻＝ネットワークタイムスタンプ／ネットワークタイムスタンプ周波数
例えば、29.97fpsのMPEG-2映像の場合、最初の1フレーム目のRTPタイムスタンプが“0”であるとすると、2フレーム目は“3003”、30フレーム目は“90090”となる。
【００３８】
また、MPEG-4 Audio AACの場合、１フレームは1024サンプル固定であり、かつRTPタイムスタンプ周波数は音源のPCMサンプリング周波数を用いる。例えば、PCMサンプリング周波数44100Hz（44.1KHz PCM= CD Audio）の場合、RTPタイムスタンプ周波数は44100であり、1フレーム目のRTPタイムスタンプは“0”、2フレーム目は“1024”、約1秒分に当たる43フレーム目は“44032”となる。
【００３９】
なお、今回はRTPを例示して説明したが、再生時刻に供されるネットワークタイムスタンプと、それに対応したネットワークタイムスタンプ周波数から、受信側でのコンテンツ再生時刻を計算しうるパケットフォーマットは他にもあり、極めて有り触れたものである。例えば、MPEGが規格化した伝送規格MPEG-2 Transport StreamにはPresentation Time Stampと呼ばれる、全く同様の機能を持つタイムスタンプが規格化されている。以上が、コンテンツ再生時刻の付与方法の概要である。
【００４０】
次に、コンテンツ配信サーバ１０２ａが管理しコンテンツ受信装置へ送信するコンテンツを記録したファイル（以下、コンテンツファイルと称す）のデータ構造について説明する。
【００４１】
図１０に、コンテンツ取得部１０２１によって管理されるコンテンツデータのデータ構造の一例を示す。図１０に示すように、コンテンツデータは、コンテンツファイル名、総トラック数Ｔ、および各トラックのトラックデータから構成され、さらに各トラックのトラックデータは、トラック番号、トラックタイムスタンプ周波数、総フレーム数、およびフレーム番号、時刻情報、コンテンツ素片からなる複数のデータフレームから構成される。
【００４２】
コンテンツファイル名は、コンテンツ記憶部上でコンテンツデータを格納するファイルを一意に特定する名前である。また、総トラック数Ｔは１つのコンテンツデータ内に収められたトラック数を記録する。トラックとは、１つのファイル内に格納されている複数のコンテンツの１つひとつを指し、トラック番号ｔ（総トラック数Ｔ≧ｔ≧１）によって、任意のトラック（コンテンツ）を選択することができ、ポインタとしての時刻情報によって、任意の位置から取り出すことができる。また、各トラックに記録されるトラックタイムスタンプ周波数は、時刻情報の単位時間当たりの増分を示す。
【００４３】
また、各トラックには、データフレームの総数である総フレーム数が記録されているが、この総フレーム数は各トラックで一致していなくても良い。また、各データフレームには、時系列順にフレーム番号が付与され、トラックタイムスタンプ周波数を基準とした時刻情報が付与される。
【００４４】
以上のような複数のコンテンツが多重化されたコンテンツデータのデータ構造は、音声・動画等を格納するファイル形式として極めて有り触れたものである。ファイル形式によっては、トラックタイムスタンプ周波数がシステム定数でデータ内に含まれていない場合や、時刻情報の保存領域を節約するために同一の時刻情報を持つフレーム同士がインデックス化されている場合がある等の細かな違いはあるが、フレーム番号と時刻情報が相互変換可能な状態で保持されているという点は共通である。
【００４５】
このようなファイル形式としては、Microsoft AVIや、Apple Computer QuickTime FormatやISO/IEC 14496-1 MP4 Fileなどが挙げられる。また、Apple Computer QuickTime Format やISO/IEC 14496-1 MP4 Fileにおいては、参照Atom（Data Reference Atom）を使用することによって、複数トラックの全部または一部のコンテンツを、外部のコンテンツデータとして独立することができるが、主となるコンテンツデータにフレーム番号と時刻情報が相互変換可能な状態で記録されているので、コンテンツデータと同等のデータ構造を持つとみなして良い。以上がコンテンツ配信サーバ１０２ａにおけるコンテンツデータのデータ構造の概要である。
【００４６】
次に、コンテンツデータを読み出す際のコンテンツ取得部１０２１の再生時刻管理処理（送信側）について、図１１のフローチャートを用いて説明する。
【００４７】
まず、コンテンツ受信装置１０３ａからコンテンツの再生要求がされると、コンテンツ配信サーバ１０２ａのコンテンツ取得部１０２１は、以下に示す６つの変数の初期化を行う（ステップＳ１０１）。
【００４８】
１：コンテンツファイル名CF＝デフォルトのコンテンツファイル名（例えば“hoge.mp4”）
２：トラック番号TN＝デフォルトのトラック番号（例えば“1”）
３：開始フレーム番号FN＝デフォルトのフレーム番号（例えば“1”）
４：再生開始時刻STS＝システムクロック発振部１０２３から得た現在時刻NTS
５：コンテンツ再生時刻CTS＝“0”
６：再生状態フラグF＝真偽値“Ｎ”
次に、コンテンツ取得部１０２１は、自動的に再生を開始するか否かを示す予め定められた自動モード定数を参照し、自動再生を行うかどうか判定する（ステップＳ１０２）。自動モード定数が真偽値“Ｙ”である場合は、ステップＳ１１０の処理へ移行し、自動モード定数が真偽値“Ｎ”である場合には、ステップＳ１０３の処理へ移行する。
【００４９】
ステップＳ１０２の処理において、自動モード定数が真偽値“Ｎ”であった場合には、コンテンツ取得部１０２１は、外部入力（コマンド入力CMD、コンテンツファイル名CF1、トラック番号TN1、コンテンツ再生開始時刻CTS1の４つの変数の組）があるかどうか判定し（ステップＳ１０３）、外部入力がある場合に真偽値“Ｙ”となりステップＳ１０４の処理へ移行し、外部入力がない場合に真偽値“Ｎ”となりステップＳ１０６の処理へ移行する。
【００５０】
ステップＳ１０３の処理において、コンテンツ取得部１０２１は、外部入力のうちコマンド入力CMD＝再生停止定数であるかを判定し（ステップＳ１０４）、コマンド入力CMD＝再生停止定数である場合は真偽値“Ｙ”となり、全体の動作を停止終了し、それ以外の場合は真偽値“Ｎ”となり、ステップＳ１０５の処理へ移行する。
【００５１】
ステップＳ１０４の処理において、真偽値“Ｎ”であった場合には、コンテンツ取得部１０２１は、外部入力（コンテンツファイル名CF1、トラック番号TN1、コンテンツ再生開始時刻CTS1）の３変数を用いて５つの変数の初期化を行う（ステップＳ１０５）。
【００５２】
１：コンテンツファイル名CF＝コンテンツファイル名CF1
２：トラック番号TN＝トラック番号TN1
３：再生開始時刻STS＝システムクロック発振部１０２３から得た現在時刻NTS
４：コンテンツ再生時刻CTS＝コンテンツ再生開始時刻CTS1
５：再生状態フラグF＝真偽値“Ｙ”
さらにコンテンツ取得部１０２１は、コンテンツ再生時刻CTSを用いた開始フレーム番号FNの初期化を行い、前段階として送出開始時刻情報StartTSを算出する。送出開始時刻情報StartTSの算出式を以下に示す。
【００５３】
[数２]
StartTS＝CTS×TRS
ここでトラックタイムスタンプ周波数TRSは、コンテンツファイル名CFの中のトラック番号TNが指し示すトラックのトラックタイムスタンプ周波数である。
【００５４】
次に、コンテンツ取得部１０２１は、コンテンツファイル名CFの中のトラック番号TNが指し示すトラックのフレーム番号を１から順にサーチし、時刻情報≧StartTSが成り立つ地点のフレーム番号NFNを得て、フレーム番号NFNを開始フレーム番号FNに設定する。
【００５５】
また、ステップＳ１０３の処理において、自動モード定数が真偽値“Ｎ”であった場合には、コンテンツ取得部１０２１は、再生状態フラグの値が真偽値“Ｙ”であるかどうか判定し（ステップＳ１０６）、値が真偽値“Ｙ”である場合ステップＳ１０７の処理へ移行し、真偽値“Ｎ”である場合にはＳ１０３の処理へ移行する。
【００５６】
ステップＳ１０６の処理において再生状態フラグの値が真偽値“Ｙ”であった場合、またはステップＳ１０５から継続する処理の場合には、コンテンツ取得部１０２１は、システムクロック発振部１０２３から得た現在時刻NTSと再生開始時刻STSとシステムクロック周波数SSから経過時間を算出し、経過時間とコンテンツ再生時刻CTSとトラックタイムスタンプ周波数TRSから、送出可能時刻情報LastTSを算出することによって、送信可能範囲を検索する（ステップＳ１０７）。送出可能時刻情報LastTSの算出式を以下に示す。
【００５７】
[数３]
LastTS＝（NTS−STS）／SS×TRS
ここでシステムクロック周波数SSとは、（現在時刻NTS−再生開始時刻STS）を秒単位に変換するための定数である。例えばシステムクロックが1/1000000秒の精度を持っているとすると1000000である。
【００５８】
次に、コンテンツ取得部１０２１は、コンテンツファイル名CFの中のトラック番号TNが指し示すトラック内の、開始フレーム番号FNからフレーム番号を順にサーチし、時刻情報≧LastTSが成り立つ点のフレーム番号NFNを取得する。条件を満たすフレーム番号NFNが求まらない場合は、コンテンツ取得部１０２１は、フレーム番号NFNに終端定数“−1”を設定する。
【００５９】
次に、コンテンツ取得部１０２１は、開始フレーム番号FNとフレーム番号NFNを比較することによって送信の可否を判定し（ステップＳ１０８）、FN＜NFNが成立する場合には真偽値“Ｙ”となりステップＳ１０９の処理へ移行し、成立しない場合は真偽値“Ｎ”となりステップＳ１０３の処理へ移行する。
【００６０】
ステップＳ１０８の処理において真偽値“Ｙ”であった場合には、コンテンツ取得部１０２１は、  コンテンツファイル名CFの中のトラック番号TNが指し示すトラック内の、開始フレーム番号FNからフレーム番号NFN未満の各フレーム番号に対応するコンテンツ素片それぞれと、それぞれのコンテンツ素片について、対応する時刻情報から下記の式に従って生成されたネットワークタイムスタンプPTSを、送信部１０２２へ出力する（ステップＳ１０９）。送信部１０２２は、ネットワークタイムスタンプPTSを用いて適切なヘッダを生成し、コンテンツ素片に付加する。
【００６１】
[数４]
PTS＝時刻情報／TRS×ネットワークタイムスタンプ周波数
出力後、送信済みの位置まで開始フレーム番号FNをずらすため、コンテンツ取得部１０２１は、開始フレーム番号FN＝フレーム番号NFNと設定する。
【００６２】
また、ステップＳ１０２の処理において、自動モード定数が真偽値“Ｙ”であった場合には、コンテンツ取得部１０２１は、再生状態フラグF＝真偽値“Ｙ”と設定し、再生開始時刻STS＝システムクロック発振部１０２３から得た現在時刻NTSを設定し、自動再生開始のための設定を行う（ステップＳ１１０）。以上がコンテンツ取得部１０２１の再生時刻管理処理（送信側）についての概要である。
【００６３】
次に、ネットワークタイムスタンプを用いたコンテンツ読取部１０３４の再生時刻管理処理（受信側）について、図１２のフローチャートを用いて説明する。
【００６４】
コンテンツ読取部１０３４は、コンテンツの再生を開始すると、バッファ部１０３２に一定量コンテンツ素片と、これに関連付けられた受信ネットワークタイムスタンプPTSが蓄積されるまで蓄積量を監視し（ステップＳ１２１）、予め定められた蓄積量のしきい値を超えると、真偽値“Ｙ”となりステップＳ１２２の処理へ移行する。この蓄積量のしきい値は、単純に総バッファ量の半分（Half Full）でも良いし、予めコンテンツのビットレートが既知である場合は適切な計算して、バッファ部１０３２がバッファアンダーフローを起こさないように決定しても良い。
【００６５】
次に、コンテンツ読取部１０３４は、システムクロック発振部１０３３を参照し、再生開始時刻STS＝システムクロック発振部１０２３から得た現在時刻NTSを設定し、読み出し開始のための設定を行う（ステップＳ１２２）。また、コンテンツ読取部１０３４は、タイムアウト変数TOUT＝タイムアウト定数（例えば“10”）に設定する。
【００６６】
次に、コンテンツ読取部１０３４は、システムクロック発振部１０３３を参照して再度現在時刻NTSを更新した上で、下記の式に従って読み出すべきネットワークタイムスタンプPTSを算出する（ステップＳ１２３）。
【００６７】
[数５]
PTS＝（NTS−STS）／SS×ネットワークタイムスタンプ周波数
次に、コンテンツ読取部１０３４は、ネットワークタイムスタンプPTSに基づいてバッファ部１０３２を検索し、ネットワークタイムスタンプPTSと同じかより小さいネットワークタイムスタンプPTSと関連付けられたコンテンツ素片を取り出す（ステップＳ１２４）。コンテンツ素片が１つも見つからない場合は真偽値“Ｎ”となり、コンテンツ読取部１０３４は、ステップＳ１２６の処理へ移行し、コンテンツ素片が見つかった場合は真偽値“Ｙ”となり、タイムアウト変数TOUTにタイムアウト定数（例えば“10”）をセットして、ステップＳ１２５の処理へ移行する。
【００６８】
ステップＳ１２４で真偽値“Ｎ”であった場合には、コンテンツ読取部１０３４は、一定時間（例えば0.5秒程度）待機した後、タイムアウト変数TOUTを“1”だけ減算し、タイムアウトが発生したか判定する（ステップＳ１２５）。減算したTOUTが0未満になった場合は真偽値“Ｙ”となり、コンテンツ読取部１０３４は、処理を終了し、真偽値“Ｎ”となれば、ステップＳ１２３の処理に移行する。結果的に、5秒（0.5×10）の間パケットが到達しなかった場合には、終了動作を行うことになる。
【００６９】
また、ステップＳ１２４で真偽値“Ｙ”であった場合には、コンテンツ読取部１０３４は、ステップＳ１２４の処理で取り出されたコンテンツ素片を再生部１０３５へ出力する（ステップＳ１２６）。この際、コンテンツ素片を、再生部１０３５の希望に沿うように、適当な手段で並べ替えたり、コンテンツ素片同士を併合したりしても良い。例えば、RTPヘッダ内のシーケンス番号を用いて並べ替えた後に、同一のネットワークタイムスタンプ（RTPタイムスタンプ）を持つコンテンツ素片同士を結合しても良い。
【００７０】
なお、説明の便を考えて、受信パケットに付与されるネットワークタイムスタンプは常に0から始まることを仮定していたが、後述するRTSP等の、他の通信手順によって、予め送信開始時点のネットワークタイムスタンプ初期値OFSが既知である場合は、式１０５は、式１０６に変形できる。
【００７１】
[数６]
PTS＝（NTS−STS）／SS×ネットワークタイムスタンプ周波数＋OFS
以上がネットワークタイムスタンプを用いた、コンテンツ読取部１０３４の再生時刻管理処理（受信側）の概要である。
【００７２】
次に、ストリーミングシステムにおける伝送制御機構について説明する。
【００７３】
ストリーミングシステムにおいては、利用者の入力処理から任意のコンテンツを選択・再生・停止等の操作を受け付け、操作に応じてTCP／UDP等のセッションを動的に接続・切断する必要がある。これを伝送制御機構と呼ぶ。図１３に、伝送制御機構を備えるコンテンツ配信システム１０１ｂを構成するコンテンツ配信サーバ１０２ｂとコンテンツ受信装置１０３ｂの機能ブロック図を示す。コンテンツ配信サーバ１０２ｂとコンテンツ受信装置１０３ｂは、IPネットワーク１０４によって相互に接続される。
【００７４】
コンテンツ配信サーバ１０２ｂは、コンテンツ取得部１０２１、送信部１０２２、システムクロック発振部１０２３、コンテンツ記憶部１０２４、および伝送制御部１０２５を有し、また、コンテンツ受信装置１０３ｂは、受信部１０３１、バッファ部１０３２、システムクロック発振部１０３３、コンテンツ読取部１０３４、再生部１０３５、伝送制御部１０３６、および入力部１０３７を有する。なお、図９と同じものについては同じ番号を付し、その説明は省略する。
【００７５】
コンテンツ配信サーバ１０２ｂの伝送制御部１０２５は、コンテンツ受信装置１０３ｂからのコンテンツの選択、コンテンツの再生・停止等の指示を含む伝送制御情報を受信すると、この伝送制御情報を、コンテンツ取得部１０２１と、送信部１０２２に通知する機能を有する。また、伝送制御部１０２５は、コンテンツ記憶部１０２４を参照してコンテンツファイル名、トラック番号、コンテンツ再生開始時刻を取得し、それらをコンテンツ取得部１０２１に対して入力し、送信部１０２２に対して送信アドレスを入力する機能を有する。
【００７６】
適用するプロトコルとしては、RFC2326に規定されているRTSP（Real Time Streaming Protocol）に代表される実時間データ伝送制御用プロトコルを想定しており、Setup、Play、 Pause、Teardown、Describe等のメソッドを利用できる（H.Schulzrinne etal, "Real Time Streaming Protocol", RFC2326, Internet Engineering Taskforce, Apr 1998）。
【００７７】
また、コンテンツ受信装置１０３ｂの伝送制御部１０３６は、入力部１０３７からの伝送制御情報をコンテンツ配信サーバ１０２ｂの伝送制御部１０２５へ送信、その応答を受信し、応答を解析した後、受信アドレスを抽出し、受信部１０３１へ入力する機能を有する。
【００７８】
また、コンテンツ受信装置１０３ｂの入力部１０３７は、利用者から、コンテンツの選択・コンテンツの再生・停止等の伝送制御情報の入力処理を受け付ける機能を有する。例えば、ビットマップディスプレイとキーボードを用いて、再生ボタン、停止ボタン、コンテンツ選択ダイヤログなどのＧＵＩ部品を利用者に提供する。
【００７９】
次に、伝送制御情報の送受信時における伝送制御部１０２５および伝送制御部１０３６の動作について、図１４のシーケンス図を用いて説明する。図１４は、RTSPを用いて１つのコンテンツを選択し、伝送のためのセッションを確立し、再生を開始し、停止するまでに行われる処理である。なお、ここでは、コンテンツ配信サーバ１０２ｂのホスト名を“server.jvc-victor.jp”とし、コンテンツを蓄積しているコンテンツファイル名を“hoge.mp4”とし、“hoge.mp4”内部には１つのMPEG-4 AAC音声トラックが存在し、トラック番号は１であるとし、再生時間は235秒であるとする。
【００８０】
RTSPは、コンテンツをネットワーク上で一意に特定するための資源識別子として、コンテンツURI（Uniform Resource Identifier）を適用する（T. Berners-Lee, "Uniform Resource Identifiers （URI）: Generic Syntax", RFC2396, Internet Engineering Taskforce, Aug 1998）。コンテンツ“hoge.mp4”は以下のようなコンテンツURIによって表される。
【００８１】
“rtsp://server.jvc-victor.jp/hoge.mp4”
まず、伝送制御部１０３６は、コンテンツURIを用いて、セッション記述を要求する（ステップＳ１３１）。このセッション記述とは、コンテンツURIに関連付けられたコンテンツデータに対して、どのようなセッション（通信路）が確立できるかを示したテキストデータである。セッション記述形式としては、SDP（Session Description Protocol）が適用される（M. Handley, " SDP: Session Description Protocol ", RFC2327, Internet Engineering Taskforce, April 1998）。RTSPにおいてセッション記述の要求にはDESCRIBEメソッドを使用する。なお、各メソッドおよびその応答メッセージ（その他付随する情報も含めて）は、それぞれリクエストメッセージのヘッダおよびレスポンスメッセージのヘッダに挿入されて送受信される。
【００８２】
“DESCRIBE rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
伝送制御部１０２５は、セッション記述を含んだ応答を送信する（ステップＳ１３２）。セッション記述には、再生時間と、メディア記述が含まれる。この再生時間とは、指定したコンテンツURIに関連付けられた連続メディアの最大の再生時間である。再生時間のフォーマットは多種類あるが、最も簡単なフォーマットは、開始時間と終了時間を、浮動小数点を用いた秒数で表したNPT（Normal Play Time, ISO8601）である。例えば、235秒分のMPEG-4 AAC音声トラックを含んだコンテンツファイルを指し示すコンテンツURIの再生時間を、NPTを用いて表すと以下のようになる。
【００８３】
“a=range:npt=0.0-235.0”
また、メディア記述には、セッションを確立するための事前情報として、コンテンツ種別やネットワークタイムスタンプ周波数などの情報を含む。
【００８４】
“m=audio 0 RTP/AVP/UDP 96”
“a=rtpmap:96 mpeg4-generic/48000/2”
“a=control:rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1”
“a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1190; SizeLength=13; IndexLength=3; IndexDeltaLength=3; Profile=1;”
上記のメディア記述は、MPEG-4 AAC Hi-bitrate符号化方式で符号化された48000Hz（48KHz）PCMサンプル周波数のステレオ音声が含まれていることを表現している。また、セッションを確立する際には、UDPを下位ネットワークプロトコルとし、RTPを適用して伝送しなければならないことが示されている。
【００８５】
また、このセッションの準備要求には以下のコントロールURIを使うことが示されている。コントロールURIは、1つのコンテンツデータ内の複数トラックを識別するためにトラック番号（trackID=1）が付与されている。
【００８６】
“rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1”
セッション記述を解析した伝送制御部１０３６は、MPEG-4 AACステレオ音声を伝送するためのセッションを確立することを決定し、セッションの受信アドレスを決定し、セッション確立準備要求を伝送制御部１０２５へ送信する（ステップＳ１３３）。RTSPにおけるセッション確立準備要求にはSETUPメソッドを用いる。下記の例では、受信アドレスは、伝送制御部１０３６の持つ受信アドレス（136.198.190.100）と受信ポート番号（6668-6669）となっている。
【００８７】
“SETUP rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1 RTSP/1.0”
“Transport: RTP/AVP/UDP;unicast;destination=136.198.190.100;client_port=6668-
6669”
セッション確立準備要求を正しく受信した伝送制御部１０２５は、新たに送信アドレスを決定し、送信アドレスを送信部１０２２へ入力し、あわせて、セッション情報を伝送制御部１０３６へ送信する（ステップＳ１３４）。セッション情報には、配信に用いる配信サーバの送信アドレス（例では136.198.190.1）や送信ポート番号（下記の例では19000〜19001）が含まれる。
【００８８】
“Transport: RTP/AVP/UDP;unicast;source=136.198.190.1;server_port=19000-19001”
また、伝送制御部１０３６では、セッション情報を受け付けた時点で、先に決定しておいた受信アドレスを受信部１０３１へ入力する。送信部１０２２と受信部１０３１双方の処理が完了した時点で、新たなセッションが確立される。
【００８９】
次に、伝送制御部１０３６は、再生開始要求を送信する（ステップＳ１３５）。再生開始要求では、再生範囲を、NPTを用いて指定することができる。下記の例では、コンテンツの最初（0.0秒）から最後（235.0秒）までの指定している。RTSPにおいて再生開始要求にはPLAYメソッドを用いる。
【００９０】
“PLAY rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
“Range: npt=0.0-235.0”
伝送制御部１０２５は、再生開始要求の応答を送信する（ステップＳ１３６）。再生開始要求を受け付けた伝送制御部１０２５は、既に準備の済んでいる全てのセッション対して、各セッションのコントロールURIと再生開始要求に含まれる再生範囲から、コンテンツファイル名・トラック番号・コンテンツ再生開始時刻を算出し、コマンド入力＝再生開始定数（例えば“PLAＹ”）と合わせて、コンテンツ取得部１０２１に入力し、RTPパケットの送信を開始する。
【００９１】
また、この応答は、コンテンツ受信装置１０３ｂのコンテンツ読取部１０３４の動作に必要となるRTPパケット情報を含む。例えば、このセッションにおいて、最初に送られてくるRTPパケットのRTPタイムスタンプ（ネットワークタイムスタンプ）などが含まれる（下記の例では0000000）。
【００９２】
“RTP-Info: url= rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1;rtptime=0000000;”
伝送制御部１０３６は、利用者が停止入力を行った時点で停止要求を送信する（ステップＳ１３７）。RTSPにおいて停止要求はTEARDOWNメソッドである。
【００９３】
“TEARDOWN rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
停止要求を受け付けた伝送制御部１０２５は、送信部１０２２を制御し、RTPパケットの送信を停止、セッションを切断し、送信を停止したことを通知する（ステップＳ１３８）。また、伝送制御部１０２５は、コンテンツ取得部１０２１に対して、コマンド入力＝再生停止定数（例えば“STOP”）を入力し、読み出しを停止する。
【００９４】
なお、説明の簡単化のために、１つのコンテンツデータに1つのコンテンツのみが含まれると仮定していたが、前記の伝送制御機構は容易に複数のコンテンツの同期再生に拡張可能である。例えば、ステップＳ１３２において、複数のコンテンツに関するメディア記述を列挙し、ステップＳ１３３〜ステップＳ１３４の準備要求をメディア記述分繰り返すだけで、複数のコンテンツの同期再生が容易に行うことが可能である。以上がストリーミングシステムにおける伝送制御機構の概要である。
【００９５】
ここで、コンテンツ再生中に、動的に、滑らかに音声や映像の切替を行おうとした場合、非同期モデルを採用し、かつ動的なセッション生成を伴う伝送制御機構を備えたストリーミングシステムとでは、２つ以上のコンテンツを再生途中から滑らかにビットストリーム切り替えの動作を行うことはできない。
【００９６】
例えば、235秒分の再生時間を持つ２つのコンテンツ（トラック番号１および２とする）のうち、トラック番号１のコンテンツを再生しており、利用者がちょうど100秒目でトラック番号２のコンテンツへ切り替える指示を入力部１０３７へ入力したとする。
【００９７】
コンテンツ受信装置１０３ｂは、非同期モデルを採用しているから、利用者から見た100秒目とは、コンテンツ読取部１０３４内部で計算されている時刻差分（現在時刻NTS−再生開始時刻STS）であり、既にバッファ部１０３２には、コンテンツ配信サーバ１０２ｂから送信済みの100秒目以降のコンテンツ素片が、既に蓄積されているか、その一部がIPネットワーク１０４上のルーターやスイッチングハブに滞留していると考えられる。
【００９８】
この状況において、トラック番号１のセッションを切断し（ステップＳ１３７）、トラック番号２のコンテンツに対してステップＳ１３３〜ステップＳ１３５の一連の通信手順を行うことを考えた場合、ステップＳ１３５における再生範囲は以下のような指定せざるを得ない。
【００９９】
“PLAY rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
“Range: npt=100.0-235.0”
ステップＳ１３６の処理直後における、バッファ部１０３２に蓄積されているコンテンツ素片の順列を、図１５に示す。再生時刻100秒のコンテンツの時刻情報をT1とし、時系列順にT2,T3,T4とする。図１５では、トラック番号１のコンテンツはコンテンツ素片４まで蓄積され、続いてトラック番号２のコンテンツがコンテンツ素片１から蓄積されていることが示されている。このコンテンツ素片の順列で利用者が視聴した場合、コンテンツはT4からT1へ戻るため、一瞬巻き戻ったように感じ、滑らかには切り替わらず、激しい違和感が生じることになる。
【０１００】
また、トラック番号１のセッションをステップＳ１３７の処理で切断した時点からトラック番号２のセッション確立準備の要求を受信するまでにかかった時間が、既にバッファ部１０３２に蓄積されているパケットの総再生時間よりも長いとバッファアンダーフローを起こし、コンテンツ読取部１０３４のタイムアウト変数TOUTが満了すれば、再生が停止することになる。 
同様に、トラック番号１のセッションをステップＳ１３７の処理で切断し、トラック番号２のコンテンツに対してステップＳ１３３〜ステップＳ１３５までの一連の通信手順にかかる時間を計測し、ステップＳ１３５の処理におけるトラック番号２のNPTに補正をかけることで違和感を少なくする手法が考えられる。例えば、一連の通信手順に5.5秒かかったとしたら、npt=105.5-235.0に補正する。
【０１０１】
しかし、この手法を適用してもトラック番号２の再生開始要求がコンテンツ配信サーバ１０２ｂへ到達して実際にパケット送信が開始されるまでの時間遅延を考慮することができず、バッファ内部の全てのパケットについてコンテンツ再生時刻が完全に連続するように構成することは困難である。
【０１０２】
上記の問題に対処する第１の改善方法として、特開２００２−１１８５９２（特許文献２）が開示されている。
【０１０３】
これは配信サーバと、クライアント間に、二次配信サーバを設け、二次配信サーバが切り替え後のビットストリームをある程度バッファリングしてから切り替えることで、クライアントのバッファ部が空にならず、コンテンツを途切れなく切り替えることができるというものである。
【０１０４】
しかし、特許文献２では、複数の配信サーバから配信されるビットストリームの各々は互いに時間的に独立であって、フレーム境界が同期していない。つまり、バッファアンダーフローは防げるが、コンテンツの巻き戻り感に関しては無力であり、コンテンツ再生時刻を完全に連続するように構成することは困難である。
【０１０５】
上記の問題に対処する第２の改善方法として、多くのストリーミングシステムでは、複数トラック同時受信構成を採用している。一例として、２トラック同時受信可能なコンテンツ配信システム１０１ｃを構成するコンテンツ配信サーバ１０２ｃとコンテンツ受信装置１０３ｃの機能ブロック図を、図１６に示す。
【０１０６】
コンテンツ配信サーバ１０２ｃは、コンテンツ取得部１０２１Ａ、送信部１０２２Ａ、コンテンツ取得部１０２１Ｂ、送信部１０２２Ｂ、システムクロック発振部１０２３、およびコンテンツ記憶部１０２４を有する。また、コンテンツ受信装置１０３ｃは、受信部１０３１Ａ、バッファ部１０３２Ａ、コンテンツ読取部１０３４Ａ、受信部１０３１Ｂ、バッファ部１０３２Ｂ、コンテンツ読取部１０３４Ｂ、システムクロック発振部１０３３、再生部１０３５、伝送制御部１０３６、入力部１０３７、および切替部１０３８を有する。なお、図１３と同じものについては同じ番号を付し、その説明は省略する。
【０１０７】
切替部１０３８は、トラック切替入力に従って、２つのコンテンツ素片のうち、どちらか一方を採用して再生部１０３５へ入力する機能を有する。採用しなかった方のコンテンツ素片は、読み出しはするものの、そのまま破棄される。
【０１０８】
なお、入力部１０３７は、利用者が入力するトラック番号１または２を切り替えるためのトラック切替入力を受け付けるものとする。
【０１０９】
コンテンツ受信装置１０３ｃでは、複数の同期するトラックがあった場合、ステップＳ１３３〜ステップＳ１３４に相当する一連の準備要求・返答をトラック数分繰り返してから、ステップＳ１３５に相当する再生要求を開始し、全てのトラック分のストリームを受信し、受信側で複数のトラックのうち、１つを再生するような切替部１０３８をコンテンツ受信装置１０３ｃに備えることで対処している。
【０１１０】
図１７は、複数トラック同時受信構成を有するコンテンツ受信装置１０３ｃの動作を示したフローチャートである。ステップＳ１４１の処理以外、全ての処理（ステップＳ１４２〜ステップＳ１４６）は、図１２のステップＳ１２２〜ステップＳ１２６と同一なので、その説明を省略する。
【０１１１】
再生を選択されているトラックのコンテンツを受信する側のコンテンツ読取部１０３４（ＡまたはＢ）は、バッファ部１０３２（ＡまたはＢ）を監視し、一定量蓄積されるまで待機し、予め定められた蓄積量のしきい値を超えると、真偽値“Ｙ”を生成し、次の処理へ移行する（ステップＳ１４１）。これは、複数のトラック間における再生開始時刻STSが全く同一となることを意図している。
【０１１２】
以上が、従来の映像・音声等の実時間配信に用いられているビットストリーム切り替え動作を伴うストリーミングシステムである。
【０１１３】
このようなストリーミングシステムを採用した通信カラオケシステムには、以下のような問題点があった。
【０１１４】
まず、１つ目の問題点としては、ストリーミングシステムを採用した通信カラオケシステムにおいて、MIDIを採用した通信カラオケシステムと同様なキーコントロール機能を実現するためには、コンテンツ受信装置側に高い演算能力を有する音程変換手段を搭載しなければならず、コストアップの原因となっていた。
【０１１５】
また、２つ目の問題点としては、コンテンツ受信装置として、携帯電話やPDA（Personal Digital Assistant：携帯情報端末）等、比較的小さな、基板面積に制約のある機器を用いる場合、音程変換手段を搭載できない状況が発生することがあった。
【０１１６】
また、３つ目の問題点としては、音程変換手段をソフトウェアによって実現する場合、高品質にしようとするほど演算量が増大するため、コンテンツ受信装置として非力な中央処理装置を有する携帯電話やPDAでは、高品質な音程変換アルゴリズムを採用できなかった。
【特許文献１】特開平９−１８５３９２号公報
【特許文献２】特開２００２−１１８５９２号公報
【発明の開示】
【発明が解決しようとする課題】
【０１１７】
本発明は、上記事情に鑑みてなされたものであり、ネットワークを介して、複数トラックから構成されるコンテンツデータを送信するコンテンツ配信サーバと当該コンテンツデータを受信再生するコンテンツ受信装置からなるコンテンツ配信システムにおいて、トラックを動的に切り替えて送信し、切り替えられた箇所を滑らかに再生することを可能にするコンテンツ配信方法、およびコンテンツ配信方法を用いたコンテンツ配信サーバ、およびコンテンツ受信装置に関する。
【課題を解決するための手段】
【０１１８】
上記目的を達成するために、請求項１に記載のコンテンツ配信方法は、複数のコンテンツ素片データを有する複数のトラックを備えたコンテンツデータを記憶しているコンテンツ配信サーバと、このコンテンツ配信サーバに対して、ネットワークを介してコンテンツの再生要求を行い、その再生要求に応じてコンテンツ配信サーバからネットワークを介して送信される当該コンテンツ素片データを受信し再生するコンテンツ受信装置とを備えたコンテンツ配信システムにおけるコンテンツ配信方法であって、前記コンテンツ配信サーバに記憶されているコンテンツデータは、ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号、トラックタイムスタンプ周波数、総フレーム数、音程の移調の度合いを示すトラックキー情報、パートナー音声の有無を示すトラックデュエット情報およびフレーム番号、再生のタイミングを示す時刻情報、コンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するものであり、前記コンテンツ受信装置が、前記コンテンツ受信装置と前記コンテンツ配信サーバとの間でセッションを確立して前記コンテンツ素片データを受信するための事前情報であるセッション記述を要求する工程と、前記コンテンツ配信サーバが、前記トラック毎に少なくとも前記トラック番号、前記トラックキー情報、前記トラックデュエット情報を含む前記セッション記述を送信する工程と、前記コンテンツ受信装置が、前記セッション記述を受信すると、前記トラック番号に前記トラックキー情報および前記トラックデュエット情報を関連付けて表示する工程と、前記コンテンツ受信装置が、前記コンテンツデータのファイル名、前記トラック番号、およびコンテンツの再生範囲と共にコンテンツの再生要求メッセージを送信する工程と、前記コンテンツ配信サーバが、前記再生要求メッセージを受信すると、前記ファイル名、前記トラック番号、および前記コンテンツの再生範囲に従って、指定された前記トラックの前記コンテンツ素片データを取得、送信する工程とを有し、前記トラックを切り替える際には、前記コンテンツ受信装置が、前記トラック番号と共にトラックの切替要求メッセージを送信する工程と、前記コンテンツ配信サーバが、前記切替要求メッセージを受信すると、前記トラック番号に従って、既送の前記コンテンツ素片データのうち再生順序が最後となっている前記コンテンツ素片データに連続して再生されるべき時刻情報を有する指定された前記トラックの前記コンテンツ素片データを取得して送信する工程とを有することを特徴とする。
【０１１９】
また、請求項２に記載のコンテンツ配信サーバは、コンテンツ受信装置からの再生要求に従って、複数のコンテンツ素片データを有する複数のトラックを備えたコンテンツデータから再生要求されたコンテンツ素片データを選択し、選択したコンテンツ素片データをネットワークを介して前記コンテンツ受信装置へ送信するコンテンツ配信サーバであって、ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、トラック番号、トラックタイムスタンプ周波数、総フレーム数、音程の移調の度合いを示すトラックキー情報、パートナー音声の有無を示すトラックデュエット情報およびフレーム番号、再生のタイミングを示す時刻情報、およびコンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するコンテンツデータを記憶するコンテンツ記憶手段と、前記コンテンツ受信装置と前記コンテンツ配信サーバとの間でセッションを確立して前記コンテンツ素片データを受信するための事前情報であるセッション記述が要求されると、前記トラック毎に少なくとも前記トラック番号、前記トラックキー情報、前記トラックデュエット情報を含む前記セッション記述を送信し、前記コンテンツデータのファイル名、前記トラック番号、およびコンテンツの再生範囲と共にコンテンツの再生要求メッセージと、前記トラック番号と共にトラックの切替要求メッセージを受信する伝送制御手段と、前記伝送制御手段が前記再生要求メッセージを受信すると、前記ファイル名、前記トラック番号、および前記コンテンツの再生範囲に従って、指定された前記トラックの前記コンテンツ素片データを前記コンテンツ記憶手段から取得し、前記伝送制御手段が前記切替要求メッセージを受信すると、前記トラック番号に従って、既送の前記コンテンツ素片データのうち再生順序が最後となっている前記コンテンツ素片データに連続して再生されるべき時刻情報を有する指定された前記トラックの前記コンテンツ素片データを前記コンテンツ記憶手段から取得するコンテンツ取得手段とを備えることを特徴とする。
【０１２０】
また、請求項３に記載のコンテンツ受信装置は、複数のコンテンツ素片データを有する複数トラックを備えたコンテンツデータを記憶しているコンテンツ配信サーバに対して、ネットワークを介してコンテンツの再生要求を行い、その再生要求に応じてコンテンツ配信サーバからネットワークを介して送信されるコンテンツ素片データを受信し再生するコンテンツ受信装置であって、コンテンツ配信サーバに記憶されているコンテンツデータは、ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、トラック番号、トラックタイムスタンプ周波数、総フレーム数、音程の移調の度合いを示すトラックキー情報、パートナー音声の有無を示すトラックデュエット情報およびフレーム番号、再生のタイミングを示す時刻情報、およびコンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するものであり、前記コンテンツ配信サーバに対して、前記コンテンツ受信装置と前記コンテンツ配信サーバとの間でセッションを確立して前記コンテンツ素片データを受信するための事前情報であるセッション記述を要求し、前記セッション記述を受信すると、前記トラック番号に前記トラックキー情報および前記トラックデュエット情報を関連付けて表示し、コンテンツを再生する際には、前記コンテンツデータのファイル名、前記トラック番号、およびコンテンツの再生範囲と共にコンテンツの再生要求メッセージを送信し、トラックを切り替える際には、前記トラック番号と共にトラックの切替要求メッセージを送信する伝送制御手段を備えることを特徴とする。
【発明の効果】
【０１２１】
本発明における通信カラオケシステムでは、バックコーラスやパートナー音声入りのデータを、原音に近い品質で利用者に提供でき、しかも利用者の要求に応じて音程を動的に切り替えることができるので、サービスの高品質化に寄与できる。
【０１２２】
また、受信クライアント側に音程変換を行う手段を搭載する必要がなく、再生コンテンツのオーサリング時に音程変換を行うため、従来よりも低速かつ高品質な音程変換手段を用いることができ、サービス品質を向上させることができる。
【０１２３】
また、受信クライアント側に音程変換手段を搭載する必要がなく、再生コンテンツのオーサリング時に音程変換を行うため、受信クライアントの出荷後にいつでも新しい音程変換手段を適用することができ、その結果得られる受信クライアントにおける音程変換の効果は、受信クライアントのハードウェアの製作時期および出荷時期に依存せず、全ての受信クライアントで同等の効果が得られる。
【０１２４】
また、再生コンテンツのオーサリング時に、複数の音程範囲のうち、ある音程分は機械的な処理によって音程変換を行い、ある音程分は、移調された楽譜を用いて演奏者・歌唱者が実際に演奏・歌唱した音声データを用いることによって、従来の手法では不可能かつ高品質なサービスを実現することができる。
【０１２５】
また、再生コンテンツの著作者が音程変換等の楽曲加工に承諾しない再生コンテンツに関しては、オーサリング時に音程変換を行ったトラックを追加しないだけで、受信クライアント全てに特別な情報を送信することなく、容易に特定の再生コンテンツに対して音程変換再生を禁止できる。
【発明を実施するための最良の形態】
【０１２６】
本発明の実施形態を、図１〜図８を用いて説明する。
【０１２７】
≪第１の実施形態≫
図１に、コンテンツ配信システム１ａ（通信カラオケシステム）のシステム構成を示す。コンテンツ配信システム１ａは、コンテンツ配信サーバ２ａ、コンテンツ受信装置３ａ（カラオケ装置）、およびオーサリング装置５ａとから構成され、コンテンツ配信サーバ２ａとコンテンツ受信装置３ａは、IPネットワーク４によって相互に接続される。
【０１２８】
コンテンツ配信サーバ２ａは、コンテンツ取得部２１、伝送制御部２２ａ、送信部２３、システムクロック発振部２４、およびコンテンツ記憶部２５を有する。
【０１２９】
コンテンツ取得部２１は、再生するコンテンツのコンテンツデータをコンテンツ記憶部２５に記録し、システムクロック信号に従って、伝送制御情報に基づいて任意のポインタ（コンテンツ上の読み出し位置）を用いてコンテンツ素片を取得する機能を有する。このポインタとは、コンテンツファイル名、トラック番号、フレーム番号の３つのうちいずれか、もしくはそれらのうちいくつかの組み合わせである。また、“コンテンツ素片”とは、任意のデータ長を有するデータブロックのことを指す。
【０１３０】
コンテンツ取得部２１は、内部にコンテンツファイル名、トラック番号、フレーム番号等の初期値を持ち、起動時から自動的に読み出しを開始しても良いし、外部入力からコンテンツファイル名、トラック番号、コンテンツ再生開始時刻を得てから読み出しを開始しても良い。また、コマンド入力を受け付ける外部入力を設け、コマンド入力＝再生開始定数（例えば“PLAＹ”）である場合は再生するようにしても良いし、コマンド入力＝再生停止定数（例えば“STOP”）である場合は停止するようにしても良い。あるいは自動読み出し開始動作と外部読み出し開始動作を自動的に判別するようにしても良い。
【０１３１】
伝送制御部２２ａは、コンテンツ受信装置３ａからのコンテンツの選択、コンテンツの再生・停止、トラック切替要求等の指示を含む伝送制御情報を受信すると、その応答を返信し、この伝送制御情報を、コンテンツ取得部２１と、送信部２３に通知する機能を有する。また、伝送制御部２２ａは、コンテンツ記憶部２５を参照してコンテンツファイル名、トラック番号、コンテンツ再生開始時刻を取得し、それらをコンテンツ取得部２１に対して入力し、送信部２３に対して送信アドレスを入力する機能を有する。
【０１３２】
適用するプロトコルとしては、RFC2326に規定されているRTSPに代表される実時間データ伝送制御用プロトコルを想定しており、Setup、Play、 Pause、Teardown、Describe等のメソッドを利用できる。
【０１３３】
送信部２３は、セッションと呼ぶ仮想的な通信路を確保し、コンテンツ素片を適切なヘッダを付加してパケット化し、そのパケットを、IPネットワーク４を介してコンテンツ受信装置３ａへ送信する機能を有する。例えば、ヘッダにはネットワークタイムスタンプが含まれる。
【０１３４】
パケットを送信する際には、送信部２３は、コンテンツ受信装置３ａへパケットを届けるために送信アドレスを用いる。送信アドレスは、送信アドレスと送信ポート番号の組で構成される。送信アドレスは送信部２３内部の定数として予め持っていても良いし、他のブロックから入力を受け付けても良い。なお、パケットを送信するためのセッション（通信路）は送信アドレスが確定した時点で動的に確立するものとする。また、コンテンツ素片とパケットが必ずしも一致する必要はない。
【０１３５】
システムクロック発振部２４は、水晶発振子等で実現されたリアルタイムクロック（高精度の時計）であり、システムクロック信号をコンテンツ取得部２１へ供給する機能を有する。
【０１３６】
また、コンテンツ記憶部２５は、コンテンツデータを所定のファイル形式で記憶する機能を有する。
【０１３７】
また、コンテンツ受信装置３ａは、受信部３１、伝送制御部３２ａ、バッファ部３３、システムクロック発振部３４、コンテンツ読取部３５、再生部３６、入力部３７、およびマイク入力部３８を有する。
【０１３８】
受信部３１は、IPネットワーク４からパケットを受信して、ヘッダを解釈して、コンテンツ素片を抽出し、バッファ部３３に供給する機能を有する。受信部３１は、コンテンツ配信サーバ２ａからのパケットのうち自己に必要なパケットのみを受信するために受信アドレスを用いる。受信アドレスは、受信アドレスと受信ポート番号の組で構成される。受信アドレスは受信部３１内部の定数として予め持っていても良いし、他のブロックから入力を受け付けても良い。
【０１３９】
伝送制御部３２ａは、入力部３７からの伝送制御情報をコンテンツ配信サーバ２ａの伝送制御部２２ａへ送信、その応答を受信し、応答を解析した後、受信アドレスを抽出し、受信部３１へ入力する機能を有する。
【０１４０】
バッファ部３３は、コンテンツ素片をヘッダから得られたネットワークタイムスタンプ（後述）と共に一次的に蓄積記憶する機能を有する。
【０１４１】
コンテンツ読取部３５は、バッファ部３３を監視し、再生に十分なコンテンツ素片が蓄積されたと判断した時点から、システムクロック発振部３４からのシステムクロック信号に従ってコンテンツ素片の読み出しを開始し、コンテンツ素片の集合をコンテンツに復元して出力する機能を有する。
【０１４２】
再生部３６は、入力されたコンテンツ素片に応じた復号化を行い、マイク入力部からの音声信号と合成した後、スピーカ等の所定の出力装置に対して音声信号、映像信号を出力する機能を有する。例えば、コンテンツ素片がMPEGに類する高能率符号化されたデジタル音声データである場合、再生部３６は、高能率符号復号器（デコーダ）、D/A変換器、アナログアンプ等を有して構成される。
【０１４３】
ここでいう合成の最低要件は、コンテンツ読取部３５とマイク入力部３８とからの２つの入力をほぼ同時に再生することである。仮にコンテンツ素片の種別が音声である場合は、マイク入力部３８からの音声と不自然でないように適切なミキシング合成や音量調整を行っても良い。
【０１４４】
入力部３７は、利用者から、コンテンツの選択・コンテンツの再生・停止、トラック切替等の伝送制御情報の入力処理を受け付ける機能を有する。例えば、ビットマップディスプレイとキーボードを用いて、再生ボタン、停止ボタン、コンテンツ選択ダイヤログなどのＧＵＩ部品を利用者に提供し、また、テンキーや数段階のスライドスイッチなどを用いて、トラック番号の入力を受け付ける操作スイッチを提供する。
【０１４５】
マイク入力部３８は、マイク等の音声取込装置によって取り込まれた音声信号の入力を受け付け、その音声信号を再生部３６ｂが扱うデータ形式に変換する機能を有する。
【０１４６】
また、オーサリング装置５ａは、オーサリング部５１ａ、音程変換部５２、コンテンツ送信部５３、入力部５４、マイク入力部５５、およびコンテンツ一次記憶部５６を有する。このオーサリング装置５ａは、コンテンツ配信サーバ２ａと同一の筐体に収められても良いし、別の筐体に収められても良い。なお、便宜上、オーサリング装置５ａを利用する利用者のことを、編集者と呼ぶ。
【０１４７】
オーサリング部５１ａは、入力部５４からの指示入力とマイク入力部５５からの音声データを用いて、コンテンツデータの新規作成・トラック追加・コンテンツデータの削除等、コンテンツデータの作成編集を行う機能、作成編集したコンテンツデータをコンテンツ一次記憶部５６に記録する機能を有する。
【０１４８】
音程変換部５２は、コンテンツを構成する原音の音声データ（以降、ソース音声データと称す）に対して、少なくとも半音もしくは全音ごとに音程変換を行う機能（例えば、音声の周波数領域変換を利用した周波数シフトアルゴリズムを用いる）を有する。
【０１４９】
ここで、基準となるソース音声データの音階を“0”とし、上に半音シフトすると“＋1”、下に半音シフトすると“−1”となるような整数変数をキー変数kと呼ぶ。一般的なカラオケ装置における音程変換を実現する場合、キー変数kは、少なくとも“−6〜0〜＋6”までの範囲を採り得る。
【０１５０】
例えば、キー変数k=“＋1”の場合、短２度の移調に相当し、原曲がハ長調だった場合は移調後の調は変ニ長調となる。また、キー変数k=“−6”の場合は、減５度に相当し、原曲がハ長調だった場合は移調後の調は嬰ヘ長調となる。
【０１５１】
なお、キー変数kが“−6”未満（もしくは＋6より大）が用いられない理由は、例えば、半音シフトで−6だけさげるということは、半音シフトで＋6（増４度）してから１オクターブ下げる移調に相当するからである。カラオケの場合、利用者本人が意図している調に合致しさえすれば、演奏のオクターブが異なっても、快適に歌唱することができるため、半音±６以上の移調は必要無い。
【０１５２】
コンテンツ送信部５３は、入力部５４からコンテンツファイル移動指示と移動先配信サーバ名が入力されると、コンテンツ一次記憶部５６に保存されているコンテンツデータを、移動先配信サーバ名の指し示す配信サーバ内のコンテンツ記憶部２５へネットワークを介して送信する機能を有する。
【０１５３】
また、コンテンツ送信部５３は、CD-RやDVD-R等の記録媒体にコンテンツデータを記録する機能を有する。ネットワークを介してコンテンツデータの送信を行わない場合は、記録媒体にてコンテンツデータを提供する。
【０１５４】
入力部５４は、編集者が、コンテンツデータ新規作成指示・トラック追加指示・コンテンツデータ移動指示・コンテンツデータ削除指示の各指示入力を受け付ける機能を有する。例えば、ビットマップディスプレイとキーボードを用いて、再生ボタン、停止ボタン、コンテンツ選択ダイヤログなどのＧＵＩ部品を編集者に提供し、また、テンキーや数段階のスライドスイッチなどを用いて、トラック番号や、音程変換のためのキー変数ｋの入力を受け付ける操作スイッチを提供する。
【０１５５】
マイク入力部５５は、マイク等の音声取込装置によって取り込まれた音声信号の入力を受け付け、その音声信号を再生部３６ｂが扱うデータ形式に変換してソース音声データを生成する機能を有する。また、マイク入力部５５は、CD-ROMドライブやネットワーク等の外部からソース音声データを受け付けるためのインタフェースを備えても良い。さらに、マイク入力部５５はマイクとメモリを備え、一定時間分の音声信号を録音してソース音声データに変換するようにしても良い。編集者がトラック追加指示を入力すると、同時にソース音声データがオーサリング装置５ａにマイク入力部５５を通して取り込まれる。
【０１５６】
コンテンツ一次記憶部５６は、オーサリング部５１ａが作成編集したコンテンツデータを一次的に記憶する機能を有する。
【０１５７】
次に、オーサリング装置５ａの動作について、図２のフローチャートを用いて説明する。
【０１５８】
（１）コンテンツデータの新規作成
オーサリング部５１ａは、入力部５４からコンテンツデータ新規作成指示と、コンテンツファイル名CF1が入力されると、コンテンツ一次記憶部５６に、トラックの全く含まれないコンテンツデータを、コンテンツファイル名CF1で作成する。
【０１５９】
（２）コンテンツデータの削除
オーサリング部５１ａは、入力部５４からコンテンツデータ削除指示と、コンテンツファイル名CF1が入力されると、コンテンツ一次記憶部５６に記録されているコンテンツファイル名CF1のコンテンツデータを削除する。
【０１６０】
（３）トラック追加
オーサリング部５１ａは、入力部５４からトラック追加指示、コンテンツファイル名CF1、トラック番号TN1、キー変数kが入力され、マイク入力部５５から入力されるソース音声データを取得すると（ステップＳ０１）、まず、キー変数kが“0”か否かを判定する（ステップＳ０２）。キー変数ｋが“0”以外であれば、音程変換部５２が入力されたソース音声データに対して音程変換処理を施し（ステップＳ０３）、オーサリング部５１ａにその音程変換処理を施したソース音声データを供給する。キー変数ｋが“0”であれば、ステップＳ０４の処理に移行する。
【０１６１】
次に、オーサリング部５１ａは、コンテンツファイル名CF1の指し示すコンテンツデータをオープンし、総トラック数を+1し、トラック番号TN1の指し示すトラックデータを追加し、ソース音声データを適当なサンプル数毎にコンテンツ素片に分割する（ステップＳ０４）。次に、オーサリング部５１ａは、必要であれば高能率符号化を施し、フレーム番号と時刻情報を付与、多重化してトラックデータを生成する（ステップＳ０５）。トラックタイムスタンプ周波数は、音声データのサンプリング周波数を測定して書き込まれる。
【０１６２】
基本的には、図１０に示す従来のコンテンツデータと同様に、本実施形態におけるコンテンツデータは、コンテンツファイル名、総トラック数Ｔ、および各トラックのトラックデータから構成され、さらに各トラックのトラックデータは、トラック番号、トラックタイムスタンプ周波数、総フレーム数、および複数のデータフレームから構成され、さらに個々のデータフレームは、フレーム番号、時刻情報、コンテンツ素片から構成される。
【０１６３】
コンテンツ配信サーバ２ａから複数トラック分のコンテンツ素片がコンテンツ受信装置３ａへ到達した際、滑らかに再生を継続させるためには、少なくともコンテンツファイル中にトラック切替可能な複数のトラックの相互に、コンテンツ素片が割り当てられている各データフレームにおいて、コンテンツ再生時刻上での時間的な境界が一致している（同じフレーム番号のコンテンツ素片は同じ再生時刻で再生される）必要がある。
【０１６４】
言い換えれば、あるトラックＡとあるトラックＢに、同一のフレーム番号FNAおよびFNBが存在する時、FNAに付随する時刻情報／トラックＡのトラックタイムスタンプ周波数と、FNBに付随する時刻情報／トラックＡのトラックタイムスタンプ周波数とが、一致している必要がある。
【０１６５】
図３に、複数トラックを有するコンテンツデータのデータ構造（時間軸に沿って並べたもの）を示す。横軸をコンテンツ再生時刻（各々の時刻情報／トラックタイムスタンプ周波数）とする。
【０１６６】
図３中、コンテンツ素片、FN1，FN2…FNn，FNm等は、コンテンツ素片に割り当てられたフレーム番号である。１トラックのフレーム番号の総数は一致している必要はなく、図３では、トラック１は総フレーム数がｎ、トラック２は総フレーム数がｍとなっている。また、コンテンツのデータが、MPEG-4 AAC hi-bitrate符号化などの高能率符号化を施されている場合は、１つのコンテンツ素片に、複数の高能率符号化の圧縮パケットを含んでいてもかまわない。
【０１６７】
しかし、１つのコンテンツ素片に含まれる複数の圧縮パケットを再生した際の時間長の合計は、２つ以上のトラックから同一フレーム番号のコンテンツ素片を抽出した時、一致していなければならない。そのため、同一フレーム番号FNxにおける各トラックのコンテンツ素片xの時刻情報xは、各トラックのトラックタイムスタンプ周波数が同じ値であれば、必ず同じ値を有している。
【０１６８】
従って、図３中の矢印（Ａ）で示すように、フレーム番号FN2でトラック１からトラック２へと再生途中で切り替えても、滑らかに再生を継続することができる。先に述べたオーサリング部５１ａは、コンテンツデータを生成するのに好適である。同一のソース音声データを、順次異なるキー変数を指定して、各トラックに格納すれば、全ての音声データはステップＳ０４にて同一ルールでコンテンツ素片へ分割されるために前述のデータ構造を備える。
【０１６９】
このように、音程の異なるトラックを複数作成し、作成されたコンテンツデータを、オーサリング装置５ａはコンテンツ配信サーバ２ａへ供給することで、コンテンツのオーサリング時に高品質な音程変換が可能になるため、サービス品質を向上させることができる。
【０１７０】
次に、伝送制御情報の送受信時におけるコンテンツ配信サーバ２ａの伝送制御部２２ａおよびコンテンツ受信装置３ａの伝送制御部３２ａの動作について、図４のシーケンス図を用いて説明する。図４は、RTSPを用いて１つのコンテンツを選択し、伝送のためのセッションを確立し、再生を開始し、停止するまでに行われる処理であり、以下に示す送受信されるメッセージは、伝送制御情報に含まれる。
【０１７１】
なお、ここでは、コンテンツ配信サーバ２ａのホスト名を“server.jvc-victor.jp”とし、コンテンツを蓄積しているコンテンツファイル名を“hoge.mp4”とし、“hoge.mp4”内部には１つのMPEG-4 AAC音声トラックが存在し、トラック番号は１であるとし、再生時間は235秒であるとする。
【０１７２】
RTSPは、コンテンツをネットワーク上で一意に特定するための資源識別子として、コンテンツURIを適用する。コンテンツ“hoge.mp4”は以下のようなコンテンツURIによって表される。
【０１７３】
“rtsp://server.jvc-victor.jp/hoge.mp4”
まず、伝送制御部３２ａは、コンテンツURIを送信することによって、セッション記述を要求する（ステップＳ１１）。このセッション記述とは、コンテンツURIに関連付けられたコンテンツデータに対して、どのようなセッション（通信路）が確立できるかを示したテキスト情報である。セッション記述形式としては、SDPが適用される。RTSPにおいてセッション記述の要求にはDESCRIBEメソッドを使用する。なお、各メソッドおよびその応答メッセージ（その他付随する情報も含めて）は、それぞれリクエストメッセージのヘッダおよびレスポンスメッセージのヘッダに挿入されて送受信される。
【０１７４】
“DESCRIBE rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
伝送制御部２２ａは、セッション記述を含んだ応答を伝送制御部３２ａに送信する（ステップＳ１２）。セッション記述には、再生時間と、メディア記述が含まれる。この再生時間とは、指定したコンテンツURIに関連付けられた連続メディアの最大の再生時間である。再生時間のフォーマットは多種類あるが、最も簡単なフォーマットは、開始時間と終了時間を、浮動小数点を用いた秒数で表したNPTである。例えば、235秒分のMPEG-4 AAC音声トラックを含んだコンテンツデータを指し示すコンテンツURIの再生時間を、NPTを用いて表すと以下のようになる。
【０１７５】
“a=range:npt=0.0-235.0”
また、メディア記述には、セッションを確立するための事前情報として、コンテンツ種別やネットワークタイムスタンプ周波数などの情報を含む。
【０１７６】
“m=audio 0 RTP/AVP/UDP 96”
“a=rtpmap:96 mpeg4-generic/48000/2”
“a=control:rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1”
“a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1190; SizeLength=13; IndexLength=3; IndexDeltaLength=3; Profile=1;”
上記のメディア記述は、MPEG-4 AAC Hi-bitrate符号化方式で符号化された48000Hz（48KHz）PCMサンプル周波数のステレオ音声が含まれていることを表現している。また、セッションを確立する際には、UDPを下位ネットワークプロトコルとし、RTPを適用して伝送しなければならないことが示されている。
【０１７７】
また、このセッションの準備要求には以下のコントロールURIを使うことが示されている。コントロールURIは、1つのコンテンツデータ内の複数トラックを識別するためにトラック番号（trackID=1）が付与されている。
【０１７８】
“rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1”
セッション記述を解析した伝送制御部３２ａは、MPEG-4 AACステレオ音声を伝送するためのセッションを確立することを決定し、セッションの受信アドレスを決定し、セッション確立準備の要求を伝送制御部２２ａへ送信する（ステップＳ１３）。RTSPにおけるセッション確立準備要求にはSETUPメソッドを用いる。下記の例では、受信アドレスは、伝送制御部３２ａの持つ受信アドレス（136.198.190.100）と受信ポート番号（6668-6669）となっている。
【０１７９】
“SETUP rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1 RTSP/1.0”
“Transport: RTP/AVP/UDP;unicast;destination=136.198.190.100;client_port=6668-
6669”
セッション確立準備要求を正しく受信した伝送制御部２２ａは、新たに送信アドレスを決定し、送信アドレスを送信部２３へ入力し、あわせて、セッション情報を伝送制御部３２ａへ送信する（ステップＳ１４）。セッション情報には、配信に用いる配信サーバの送信アドレス（例では136.198.190.1）や送信ポート番号（下記の例では19000〜19001）が含まれる。
【０１８０】
“Transport: RTP/AVP/UDP;unicast;source=136.198.190.1;server_port=19000-19001”
また、伝送制御部３２ａでは、セッション情報を受け付けた時点で、先に決定しておいた受信アドレスを受信部３１へ入力する。送信部２３と受信部３１の双方の処理が完了した時点で、新たなセッションが確立される。
【０１８１】
次に、伝送制御部３２ａは、伝送制御部２２ａに対して、利用者の入力操作に応じた再生するコンテンツのトラックを指定するトラック切替要求（CHANGEメソッド）を送信する（ステップＳ１５）。トラック番号指定（TrackID=）には、次に切り替えたいトラック番号を設定する。
【０１８２】
“CHANGE rtsp://server.jvc-victor.jp/hoge.mp4/TrackID=2 RTSP/1.0”
伝送制御部２２ａは、トラック切替要求を受信すると、コンテンツ記憶部２５を参照して、次に切り替えたいトラック番号に対応するトラックがコンテンツhoge.mp4内に存在する場合は、下記の正常応答を送信する（ステップＳ１６）。
【０１８３】
“RTSP/1.0 200 OK”
また、次に切り替えたいトラック番号に対応するトラックがコンテンツhoge.mp4内に存在しない場合は、伝送制御部２２ａは、下記の異常応答を送信する。
【０１８４】
“RTSP/1.0 404 NOT FOUND”
なお、このトラック切替要求およびトラック切替応答は一例であって、文字列表現の多少の差異によって独自性が失われることはない。本実施形態ではRTSPを拡張したが、HTTP（Hyper Text Transfer Protocol）のGETメソッドを用いて、トラック切替要求を以下のように書き替えてもよい（Network Working Group, "Hypertext Transfer Protocol -- HTTP/1.1", RFC2616, The Internet Society, June 1999）。
【０１８５】
“GET /hoge.mp4?TrackID=2 HTTP/1.1”
GETメソッドにはコンテンツ配信サーバ２ａのホスト名が含まれないが、コンテンツファイル名と次に切り替えるトラック番号を、RTSPと同様の手法で内包させることができる。
【０１８６】
次に、伝送制御部３２ａは、再生開始要求を送信する（ステップＳ１７）。再生開始要求では、再生範囲を、NPTを用いて指定することができる。下記の例では、コンテンツの最初（0.0秒）から最後（235.0秒）までの指定している。RTSPにおいて再生開始要求にはPLAYメソッドを用いる。
【０１８７】
“PLAY rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
“Range: npt=0.0-235.0”
伝送制御部２２ａは、再生開始要求の応答を送信する（ステップＳ１８）。再生開始要求を受け付けた伝送制御部２２ａは、既に準備の済んでいる全てのセッション対して、各セッションのコントロールURIと再生開始要求に含まれる再生範囲から、コンテンツファイル名・トラック番号・コンテンツ再生開始時刻を算出し、コマンド入力＝再生開始定数（例えば“PLAＹ”）と合わせて、コンテンツ取得部２１に入力し、RTPパケットの送信を開始する。
【０１８８】
また、この応答は、コンテンツ受信装置３ａのコンテンツ読取部３５の動作に必要となるRTPパケット情報を含む。例えば、このセッションにおいて、最初に送られてくるRTPパケットのRTPタイムスタンプ（ネットワークタイムスタンプ）などが含まれる（下記の例では0000000）。
【０１８９】
“RTP-Info: url= rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1;rtptime=0000000;”
なおトラック切替要求は、ステップＳ１４の準備要求応答以降かつ停止前であれば、いつでも送信して良い。従って、あるトラックを再生途中でトラック切替が入力されると、伝送制御部３２ａは、ステップＳ１５で送信されたトラック切替要求を送信し（ステップＳ１９）、伝送制御部２２ａは、トラック切替要求を受信すると、次に切り替えたいトラック番号をコンテンツ取得部２１へ入力する。コンテンツ取得部２１は、次に切り替えたいトラック番号の存在を確認して、切替結果（＝正常または＝異常）を伝送制御部２２ａへ入力する。伝送制御部２２ａは、切替結果が入力されると、トラック切替応答（切替結果＝正常であれば正常応答へ、切替結果＝異常であれば異常応答）を伝達制御部３２ａへ送信する（ステップＳ２０）。
【０１９０】
また、コンテンツ取得部２１は、指定されたトラックのコンテンツ素片をコンテンツ記憶部２５から取得し、送信部２３を介してコンテンツ受信装置３ａへ送信する（詳細は後述）。
【０１９１】
また、伝送制御部３２ａは、利用者が停止入力を行った時点で停止要求を送信する（ステップＳ２１）。RTSPにおいて停止要求はTEARDOWNメソッドである。
【０１９２】
“TEARDOWN rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
停止要求を受け付けた伝送制御部２２ａは、送信部２３を制御し、RTPパケットの送信を停止、セッションを切断し、送信を停止したことを通知する（ステップＳ２２）。また、伝送制御部２２ａは、コンテンツ取得部２１に対して、コマンド入力＝再生停止定数（例えば“STOP”）を入力し、読み出しを停止する。
【０１９３】
なお、説明の簡単化のために、１つのコンテンツデータに1つのコンテンツのみが含まれると仮定していたが、前記の伝送制御機構は容易に複数のコンテンツの同期再生に拡張可能である。例えば、ステップＳ１２において、複数のコンテンツに関するメディア記述を列挙し、ステップＳ１３〜ステップＳ１４の準備要求をメディア記述分繰り返すだけで、複数のコンテンツの同期再生が容易に行うことが可能である。
【０１９４】
次に、コンテンツデータを読み出す際のコンテンツ取得部２１の再生時刻管理処理（送信側）について、図５のフローチャートを用いて説明する。
【０１９５】
まず、コンテンツ受信装置３ａからコンテンツの再生要求がされると、コンテンツ配信サーバ２ａのコンテンツ取得部２１は、以下に示す６つの変数の初期化を行う（ステップＳ３１）。
【０１９６】
１：コンテンツファイル名CF＝デフォルトのコンテンツファイル名（例えば“hoge.mp4”）
２：トラック番号TN＝デフォルトのトラック番号（例えば“1”）
３：開始フレーム番号FN＝デフォルトのフレーム番号（例えば“1”）
４：再生開始時刻STS＝システムクロック発振部２４から得た現在時刻NTS
５：コンテンツ再生時刻CTS＝“0”
６：再生状態フラグF＝真偽値“Ｎ”
次に、コンテンツ取得部２１は、自動的に再生を開始するか否かを示す予め定められた自動モード定数を参照し、自動再生を行うかどうか判定する（ステップＳ３２）。自動モード定数が真偽値“Ｙ”である場合は、ステップＳ４４の処理へ移行し、自動モード定数が真偽値“Ｎ”である場合には、ステップＳ３３の処理へ移行する。
【０１９７】
ステップＳ３２の処理において、自動モード定数が真偽値“Ｎ”であった場合には、コンテンツ取得部２１は、外部入力（コマンド入力CMD、コンテンツファイル名CF1、トラック番号TN1、コンテンツ再生開始時刻CTS1の４つの変数の組）があるかどうか判定し（ステップＳ３３）、外部入力がある場合に真偽値“Ｙ”となりステップＳ３４の処理へ移行し、外部入力がない場合に真偽値“Ｎ”となりステップＳ４０の処理へ移行する。
【０１９８】
ステップＳ３３の処理において、真偽値“Ｙ”であった場合には、コンテンツ取得部２１は、外部入力のうち、コマンド入力CMD＝トラック切替定数（例えば“CHANGE”）であるか判定し（ステップＳ３４）、トラック切替定数であった場合に真偽値“Ｙ”となりステップＳ３５の処理へ移行し、真偽値“Ｎ”の場合は、ステップＳ３８の処理へ移行する。
【０１９９】
また、ステップＳ３４の処理において、真偽値“Ｙ”であった場合には、コンテンツ取得部２１は、外部入力のうち（コンテンツファイル名CF1、トラック番号TN1）を用いて、CFとCF1が等しく、かつ、コンテンツファイル名CFにトラック番号TN1が指し示すトラックが存在するか、トラック切替可能か判定し（ステップＳ３５）、可能であれ真偽値“Ｙ”となりステップＳ３６の処理へ移行し、トラック番号TN＝トラック番号TN1となる代入しトラック切替処理を行った上で、伝送制御部２２ａへ切替結果＝正常を通知する（ステップＳ３６）。また、トラックが存在せずに切替不可能であれば真偽値“Ｎ”となり、コンテンツ取得部２１は、ステップＳ３７の処理へ移行し、伝送制御部２２ａへ切替結果＝異常を通知する（ステップＳ３７）。
【０２００】
また、ステップＳ３４の処理において、真偽値“Ｎ”となった場合には、コンテンツ取得部２１は、外部入力のうちコマンド入力CMD＝再生停止定数であるかを判定し（ステップＳ３８）、コマンド入力CMD＝再生停止定数である場合は真偽値“Ｙ”となり、全体の動作を停止終了し、それ以外の場合は真偽値“Ｎ”となり、ステップＳ３９の処理へ移行する。
【０２０１】
ステップＳ３８の処理において、真偽値“Ｎ”であった場合には、コンテンツ取得部２１は、外部入力（コンテンツファイル名CF1、トラック番号TN1、コンテンツ再生開始時刻CTS1）の３変数を用いて５つの変数の初期化を行う（ステップＳ３９）。
【０２０２】
１：コンテンツファイル名CF＝コンテンツファイル名CF1
２：トラック番号TN＝トラック番号TN1
３：再生開始時刻STS＝システムクロック発振部２４から得た現在時刻NTS
４：コンテンツ再生時刻CTS＝コンテンツ再生開始時刻CTS1
５：再生状態フラグF＝真偽値“Ｙ”
さらにコンテンツ取得部２１は、コンテンツ再生時刻CTSを用いた開始フレーム番号FNの初期化を行い、前段階として送出開始時刻情報StartTSを算出する。送出開始時刻情報StartTSの算出式を以下に示す。
【０２０３】
[数７]
StartTS＝CTS×TRS
ここでトラックタイムスタンプ周波数TRSは、コンテンツファイル名CFの中のトラック番号TNが指し示すトラックのトラックタイムスタンプ周波数である。
【０２０４】
次に、コンテンツ取得部２１は、コンテンツファイル名CFの中のトラック番号TNが指し示すトラックのフレーム番号を１から順に検索し、時刻情報≧StartTSが成り立つ点のフレーム番号NFNを得て、フレーム番号NFNを開始フレーム番号FNに設定する。
【０２０５】
また、ステップＳ３３の処理において、コンテンツ取得部２１は、再生状態フラグＦの値が真偽値“Ｙ”であるかどうか判定し（ステップＳ４０）、値が真偽値“Ｙ”である場合ステップＳ４１の処理へ移行し、真偽値“Ｎ”である場合にはステップＳ３３の処理へ移行する。
【０２０６】
ステップＳ４０の処理において再生状態フラグの値が真偽値“Ｙ”であった場合、またはステップＳ３６、Ｓ３７、Ｓ３９から継続する処理の場合には、コンテンツ取得部２１は、システムクロック発振部２４から得た現在時刻NTSと再生開始時刻STSとシステムクロック周波数SSから経過時間を算出し、経過時間とコンテンツ再生時刻CTSとトラックタイムスタンプ周波数TRSから、送出可能時刻情報LastTSを算出することによって、送信可能範囲を検索する（ステップＳ４１）。送出可能時刻情報LastTSの算出式を以下に示す。
【０２０７】
[数８]
LastTS＝（NTS−STS）／SS×TRS
ここでシステムクロック周波数SSとは、（現在時刻NTS−再生開始時刻STS）を秒単位に変換するための定数である。例えばシステムクロックが1/1000000秒の精度を持っているとすると1000000である。
【０２０８】
次に、コンテンツ取得部２１は、コンテンツファイル名CFの中のトラック番号TNが指し示すトラック内の、開始フレーム番号FNからフレーム番号を順にサーチし、時刻情報≧LastTSが成り立つ点のフレーム番号NFNを取得する。条件を満たすフレーム番号NFNが求まらない場合は、コンテンツ取得部２１は、フレーム番号NFNに終端定数“−1”を設定する。
【０２０９】
次に、コンテンツ取得部２１は、開始フレーム番号FNとフレーム番号NFNを比較することによって送信の可否を判定し（ステップＳ４２）、FN＜NFNが成立する場合には真偽値“Ｙ”となりステップＳ４３の処理へ移行し、成立しない場合は真偽値“Ｎ”となりステップＳ３３の処理へ移行する。
【０２１０】
ステップＳ４２の処理において真偽値“Ｙ”であった場合には、コンテンツ取得部２１は、コンテンツファイル名CFの中のトラック番号TNが指し示すトラック内の、開始フレーム番号FNからフレーム番号NFN未満の各フレーム番号に対応するコンテンツ素片それぞれと、それぞれのコンテンツ素片について、対応する時刻情報から下記の式に従って生成されたネットワークタイムスタンプPTSとを、送信部２３へ出力する（ステップＳ４３）。
【０２１１】
[数９]
PTS＝時刻情報／TRS×ネットワークタイムスタンプ周波数
出力後、送信済みの位置まで開始フレーム番号FNをずらすため、コンテンツ取得部２１は、開始フレーム番号FN＝フレーム番号NFNと設定する。
【０２１２】
また、ステップＳ３２の処理において、自動モード定数が真偽値“Ｙ”であった場合には、コンテンツ取得部２１は、再生状態フラグF＝真偽値“Ｙ”と設定し、再生開始時刻STS＝システムクロック発振部２４から得た現在時刻NTSを設定し、自動再生開始のための設定を行う（ステップＳ４４）。
【０２１３】
このように、伝送制御部２２ａおよび伝送制御部３２ａによって確立されるコントロールラインでトラック切替のメッセージが送受信され、そのメッセージに従って、時刻情報を基に切り替えた先のトラックのコンテンツ素片を取得、送信するので、コンテンツ受信装置３ａでは、トラックが切り替えられても滑らかな再生を行うことができる。
【０２１４】
なお、送信部２３−受信部３１間の通信は、RTP（Real-time Transfer Protocol, RFC1889）の規約に従って行っても良い。
【０２１５】
なお、図１のコンテンツ配信システム１ａでは、コンテンツ配信サーバ２ａ、コンテンツ受信装置３ａ、オーサリング装置５ａが、１つずつしかない構成であったが、図６に示すように、オーサリング装置５ａに複数台のコンテンツ配信サーバ２ａを接続し、それぞれのコンテンツ配信サーバ２ａにコンテンツ受信装置３ｂを接続するようにしても良い。
【０２１６】
これは、多数の利用者にサービスを提供可能な通信カラオケシステムの例として好適である。オーサリング装置５ａで音程変換処理を行って複数トラックに音程の異なるコンテンツデータが記録されたコンテンツデータを用意することによって、複数のコンテンツ配信サーバ２ａに同一のコンテンツデータをコピーするだけで、各コンテンツ受信装置３ａは音程変換を行う手段を搭載せずとも、トラックを変更することで再生中に動的な音程変換を行うことが可能となる。また、利用者が増加し、コンテンツ配信サーバ２ａとコンテンツ受信装置３ａの組が増加しても、音程変換処理に必要とされる時間・演算コストは常に一定であり、劇的なコスト削減が可能となる。
【０２１７】
≪第２の実施形態：デュエット曲におけるパートナー音声の切り替え≫
上記の実施形態では、予めどのトラックにどの音程のコンテンツデータが記録されているか分かっていることを前提としている。すなわち、トラック番号とキー変数が１対１で対応付けされている状態と言える。
【０２１８】
しかし、デュエット曲の場合は、伴奏の音程が変更されるとパートナー音声もあわせて音程を変更する必要がある。そこで第２の実施形態では、パートナー音声の切り替えとキーコントロールを同時に実現するコンテンツ配信システム１ｂについて説明する。
【０２１９】
図７に、コンテンツ配信システム１ｂ（通信カラオケシステム）のシステム構成を示す。コンテンツ配信システム１ｂは、コンテンツ配信サーバ２ｂ、コンテンツ受信装置３ｂ（カラオケ装置）、およびオーサリング装置５ｂとから構成され、コンテンツ配信サーバ２ｂとコンテンツ受信装置３ｂは、IPネットワーク４によって相互に接続される。なお、第１の実施形態と同じものについては、同じ番号を付し、その詳細な説明を省略する。
【０２２０】
コンテンツ配信サーバ２ｂは、コンテンツ取得部２１、伝送制御部２２ｂ、送信部２３、システムクロック発振部２４、およびコンテンツ記憶部２５を有する。
【０２２１】
伝送制御部２２ｂは、コンテンツ受信装置３ｂからのコンテンツの選択、コンテンツの再生・停止、トラック切替要求等の指示を含む伝送制御情報を受信すると、トラック番号、トラックキー情報およびトラックデュエット情報を含む応答を返信し、この伝送制御情報を、コンテンツ取得部２１と、送信部２３に通知する機能を有する。また、伝送制御部２２ｂは、コンテンツ記憶部２５を参照してコンテンツファイル名、トラック番号、コンテンツ再生開始時刻を取得し、それらをコンテンツ取得部２１に対して入力し、送信部２３に対して送信アドレスを入力する機能を有する。
【０２２２】
また、コンテンツ受信装置３ｂは、受信部３１、伝送制御部３２ｂ、バッファ部３３、システムクロック発振部３４、コンテンツ読取部３５、再生部３６、入力部３７、マイク入力部３８、および出力部３９を有する。
【０２２３】
伝送制御部３２ｂは、入力部３７からの伝送制御情報をコンテンツ配信サーバ２ｂの伝送制御部２２ｂへ送信、その応答を受信し、応答を解析した後、受信アドレスを抽出して受信部３１へ入力し、トラック番号、トラックキー情報およびトラックデュエット情報を抽出して出力部３９へ通知する機能を有する。
【０２２４】
出力部３９は、モニタ等の表示装置が接続され、セッション記述を含んだ応答から抽出されるトラックキー情報とトラックデュエット情報を表示装置に出力する機能を有する。
【０２２５】
また、オーサリング装置５ｂは、オーサリング部５１ｂ、音程変換部５２、コンテンツ送信部５３、入力部５４、マイク入力部５５、およびコンテンツ一次記憶部５６を有する。
【０２２６】
オーサリング部５１ｂは、入力部５４からの指示入力とマイク入力部５５からの音声データを用いて、コンテンツデータの新規作成・トラック追加・コンテンツデータの削除等、コンテンツデータの作成編集を行う機能、作成編集したコンテンツデータにトラックキー情報とトラックデュエット情報を付加してコンテンツ一次記憶部５６に記録する機能を有する。
【０２２７】
第２の実施形態においては、１トラックのコンテンツデータにパートナー音声が含まれているか否かを示すデュエット変数ｄを設ける。１トラックのコンテンツデータがパートナー音声無しの場合は、デュエット変数ｄ＝“0”とし、男性パートナー音声入りの場合は、デュエット変数ｄ＝“1”とし、女性パートナー音声入りの場合は、デュエット変数ｄ＝“2”とする。なお、伴奏なしのパートナー音声のみのトラックを用意しても良い。
【０２２８】
図８に第２の実施形態におけるコンテンツデータのデータ構造を示す。第１の実施形態と異なる点は、各トラックの情報として、コンテンツデータにトラックキー情報（１〜ｔ）とトラックデュエット情報（１〜ｔ）が追加されている点である。この時、添字ｔの最大値は総トラック数Ｔの値に等しい。
【０２２９】
このトラックキー情報は、そのトラックのコンテンツデータがどの程度移調されているかを示す情報であり、オーサリング装置５ｂのオーサリング部５１ｂが、コンテンツデータを生成する際に参照するキー変数ｋの値が記録される。また、トラックデュエット情報は、パートナー音声の有無を示す情報であり、デュエット変数ｄの値が記録される。
【０２３０】
例えば、図８のトラック番号が1のトラックは、トラックキー情報１の値が“0”、トラックデュエット情報１の値が“1”となっているので、移調されていない男性パートナーの音声入りのコンテンツデータであることが分かる。
【０２３１】
次に、伝送制御情報の送受信時におけるコンテンツ配信サーバ２ｂの伝送制御部２２ｂおよびコンテンツ受信装置３ｂの伝送制御部３２ｂの動作について説明する。
【０２３２】
伝送制御部３２ｂが、コンテンツURIを送信することによってセッション記述を要求すると、下記のメディア記述を含みセッション記述を含んだ応答を伝送制御部３２ａに送信する。
【０２３３】
例えば、コンテンツ記憶部２５に用意されているコンテンツデータに２つのトラックがあり、トラック番号が1のトラックのトラックキー情報が0、トラックデュエット情報が1であり、トラック番号が2のトラックのトラックキー情報が1、トラックデュエット情報が2であるとすると、メディア記述は下記の通りとなる。
【０２３４】
“m=audio 0 RTP/AVP/UDP 96”
“a=rtpmap:96 mpeg4-generic/48000/2”
“a=control:rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1”
“a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1190; SizeLength=13; IndexLength=3; IndexDeltaLength=3; Profile=1;”
“a=karaoke:96 keyinfo=0; duetinfo=1”
“m=audio 0 RTP/AVP/UDP 97”
“a=rtpmap:97 mpeg4-generic/48000/2”
“a=control:rtsp://server.jvc-victor.jp/hoge.mp4/trackID=2”
“a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1190; SizeLength=13; IndexLength=3; IndexDeltaLength=3; Profile=1;”
“a=karaoke:97 keyinfo=0; duetinfo=2”
このうち、keyinfoはトラックキー情報が設定される変数であり、duetinfoはトラックデュエット情報が設定される変数である。また、“96”“97”という数値は、SDPにおいてfmt_litsと呼ばれ、各メディア記述を識別するための値である。
【０２３５】
セッション記述を解析した伝送制御部３２ｂは、メディア記述からトラック番号、トラックキー情報、およびトラックデュエット情報を取得し出力部３９へ通知すると共に、MPEG-4 AACステレオ音声を伝送するためのセッションを確立することを決定し、セッションの受信アドレスを決定し、セッション確立準備の要求を伝送制御部２２ｂへ送信する。
【０２３６】
出力部３９は、トラック番号とトラックキー情報およびトラックデュエット情報を関連付けてモニタに出力する。この時の表示形態は、キー変数ｋやデュエット変数ｄの数字ではなく、音符のアイコンや、男性女性のアイコン等、デザインされた画像を表示するようにしても良い。このモニタに表示されたトラック番号、トラックキー情報、およびトラックデュエット情報を基に、利用者が変更したいトラックを選択すると、伝送制御部３２ｂは、利用者の入力操作によって入力されたトラック番号を入力部３７から取得し、第１の実施形態で示したトラックの切替処理が行われる。
【０２３７】
以上、本発明の実施形態について説明したが、本発明はこれらに限定されるものでない。コンテンツ配信サーバ２、コンテンツ受信装置３、およびオーサリング装置５の構成要件のうち、全てまたは一部をコンピュータで実行可能なプログラムとして実現し、予めコンピュータ読み取り可能な記録媒体などに記録して提供することも可能である。
【０２３８】
また、物理的に１台のコンピュータで、コンテンツ配信サーバ２に相当するプログラムを複数実行しても良い。さらに、物理的に１台のコンピュータで、コンテンツ受信装置３に相当するプログラムを複数実行しても良い。
【０２３９】
また、物理的に1台のコンピュータで、コンテンツ配信サーバ２に相当するプログラムとコンテンツ受信装置３に相当するプログラムを実行しても良い。さらに、物理的に１台のコンピュータで、コンテンツ配信サーバ２に相当するプログラムとオーサリング装置５に相当するプログラムを実行しても良い。
【図面の簡単な説明】
【０２４０】
【図１】コンテンツ配信システム１ａ（非同期モデル）におけるコンテンツ配信サーバ２ａ、コンテンツ受信装置３ａ、およびオーサリング装置５ａの機能ブロック図である。
【図２】オーサリング時の処理手順を示すフローチャートである。
【図３】複数トラックを有するコンテンツデータのデータ構造を示す図である。
【図４】伝送制御情報の送受信時におけるコンテンツ配信サーバ２ａの伝送制御部２２ａおよびコンテンツ受信装置３ａの伝送制御部３２ａの動作を示すシーケンス図である。
【図５】コンテンツデータを読み出す際のコンテンツ取得部２１の再生時刻管理処理（送信側）を示すフローチャートである。
【図６】オーサリング装置５ａに複数台のコンテンツ配信サーバ２ａを接続した構成例を示す図である。
【図７】コンテンツ配信システム１ｂ（非同期モデル）におけるコンテンツ配信サーバ２ｂ、コンテンツ受信装置３ｂ、およびオーサリング装置５ｂの機能ブロック図である。
【図８】コンテンツデータのデータ構造の一例を示す図である。
【図９】非同期モデルにおけるコンテンツ配信サーバ１０２ａとコンテンツ受信装置１０３ａの機能ブロック図である。
【図１０】コンテンツデータのデータ構造の一例を示す図である。
【図１１】コンテンツファイルを読み出す際のコンテンツ取得部１０２１の再生時刻管理処理（送信側）を示すフローチャートである。
【図１２】ネットワークタイムスタンプを用いたコンテンツ読取部１０３４の再生時刻管理処理（受信側）を示すフローチャートである。
【図１３】伝送制御機構を備えるコンテンツ配信システム１０１ｂを構成するコンテンツ配信サーバ１０２ｂとコンテンツ受信装置１０３ｂの機能ブロック図である。
【図１４】伝送制御情報の送受信時における伝送制御部１０２５および伝送制御部１０３６の動作を示すシーケンス図である。
【図１５】バッファ部１０３２に蓄積されているコンテンツ素片の順列を示す図である。
【図１６】２トラック同時受信可能なコンテンツ配信システム１０１ｃを構成するコンテンツ配信サーバ１０２ｃとコンテンツ受信装置１０３ｃの機能ブロック図である。
【図１７】複数トラック同時受信構成を有するコンテンツ受信装置１０３ｃの動作を示すフローチャートである。
【符号の説明】
【０２４１】
１ａ、ｂ…コンテンツ配信システム、２ａ、ｂ…コンテンツ配信サーバ、３ａ、ｂ…コンテンツ受信装置、４…IPネットワーク、５ａ、ｂ…オーサリング装置、２１…コンテンツ取得部、２２ａ、ｂ…伝送制御部、２３…送信部、２４…システムクロック発振部、２５…コンテンツ記憶部、３１…受信部、３２ａ、ｂ…伝送制御部、３３…バッファ部、３４…システムクロック発振部、３５…コンテンツ読取部、３６…再生部、３７…入力部、３８…マイク入力部、３９…出力部、５１ａ、ｂ…オーサリング部、５２…音程変換部、５３…コンテンツ送信部、５４…入力部、５５…マイク入力部、５６…コンテンツ一次記憶部、１０１ａ、ｂ、ｃ…コンテンツ配信システム、１０２ａ、ｂ、ｃ…コンテンツ配信サーバ、１０３ａ、ｂ、ｃ…コンテンツ受信装置、１０４…ネットワーク、１０２１…コンテンツ取得部（Ａ，Ｂ）、１０２２…送信部（Ａ，Ｂ）、１０２３…システムクロック発振部、１０２４…コンテンツ記憶部、１０２５…伝送制御部、１０３１…受信部（Ａ，Ｂ）、１０３２…バッファ部（Ａ，Ｂ）、１０３３…システムクロック発振部、１０３４…コンテンツ読取部（Ａ，Ｂ）、１０３５…再生部、１０３６…伝送制御部、１０３７…入力部、１０３８…切替部
【図１】
2005284041.tif 000003
【図２】
2005284041.tif 000004
【図３】
2005284041.tif 000005
【図４】
2005284041.tif 000006
【図５】
2005284041.tif 000007
【図６】
2005284041.tif 000008
【図７】
2005284041.tif 000009
【図８】
2005284041.tif 000010
【図９】
2005284041.tif 000011
【図１０】
2005284041.tif 000012
【図１１】
2005284041.tif 000013
【図１２】
2005284041.tif 000014
【図１３】
2005284041.tif 000015
【図１４】
2005284041.tif 000016
【図１５】
2005284041.tif 000017
【図１６】
2005284041.tif 000018
【図１７】
2005284041.tif 000019