(57)【特許請求の範囲】
【請求項１】
イベント情報とイベントを実行するための時間情報とを含むデータを受信して再生するデータ再生装置であって、
属性の異なるイベント情報を持つ複数種類のデータを受信することが可能なデータ受信部と、
前記データ受信部が受信した各データの時間情報を順次参照して、所定の時間幅を有する単位区間内で処理すべきデータを決定し、当該データを単位区間ごとに種類別に振り分けるデータ振分部と、
前記データ振分部で振り分けられた単位区間ごとの複数種類のデータを種類別に一時的に格納する記憶部と、
データの種類に対応して設けられ、前記記憶部に格納された単位区間ごとの複数種類のデータを次の単位区間において順次読み出し、各データに記録されているイベントを実行してデータを再生するデータ再生部と、
前記データ再生部で再生されたそれぞれのデータを出力する出力部と、
を備え、
前記データ振分部は、単位区間内で処理すべき全てのデータを、当該単位区間の最後のタイミングで種類別に振り分けて前記記憶部に格納し、
前記データ再生部は、前記データ振分部が振り分けた単位区間内の複数種類のデータを、次の単位区間において前記記憶部から順次読み出して、当該データのイベントを実行する、
ことを特徴とするデータ再生装置。
【請求項２】
前記時間情報は、前回イベントの実行時点から今回イベントが実行されるまでの時間として規定されるデルタ・タイムであって、
前記データ振分部は、単位区間の最後の時刻である現在時刻と、１つ前の単位区間における最後のイベントの実行時刻との差から今回データを処理すべき処理区間の時間幅を算出し、当該処理区間における各イベントのデルタ・タイムの和が処理区間の時間幅の範囲内となるように単位区間のデータを振分けて前記記憶部に格納し、
前記データ再生部は、前記データ振分部が振り分けた単位区間のデータを当該単位区間と同じ時間幅をもつ次の単位区間において再生する、
請求項１に記載のデータ再生装置。
【請求項３】
ストリームデータをダウンロードしながら再生を行う請求項１に記載のデータ再生装置であって、
前記データ受信部はバッファを備え、
前記データ受信部が最初に受信したデータに基づいて単位時間あたりのデータ転送容量Ｊおよび単位時間あたりのデータ消費量Ｅを計算し、
Ｊ＜Ｅの場合はデータを必要量だけ前記バッファにキャッシュした後に再生を開始し、Ｊ＞Ｅの場合はデータのキャッシュは行なわずに間歇的にデータを受信しながら再生を行なう、データ再生装置。
【請求項４】
文字を含むコマーシャル情報を受信し、前記文字のデータは、インターネットのブラウザ起動時のジャンプ先であるＵＲＬと、このＵＲＬのホームページの視聴者に対してサービスを提供するための情報とを含んでいる、請求項１に記載のデータ再生装置。
【請求項５】
請求項１に記載のデータ再生装置を搭載し、前記複数種類のデータがダウンロード可能な情報端末機であって、ダウンロードしたデータに基づいてサウンドを出力する発音部と、ダウンロードしたデータに基づいて文字および画像を表示する表示器とを含む、情報端末機。
【請求項６】
小型の情報記憶媒体が着脱可能となっており、前記情報記憶媒体に、ダウンロードしたＭＩＤＩによる音楽データと、文字による歌詞データと、画像によるジャケット写真データとを格納する、請求項５に記載の情報端末機。
【請求項７】
請求項５に記載の情報端末機であって、
前記発音部から通話音声が出力され、前記表示器に電話番号が表示される携帯電話機の機能を備え、かつ、
ダウンロードしたデータに基づいて、前記発音部から伴奏曲を出力するとともに、前記表示器に歌詞および背景画像を表示することによって、カラオケ装置として利用できるようにした、情報端末機。
【発明の詳細な説明】
［技術分野］
本発明は、音や画像等の属性の異なるデータを再生するのに用いられるデータ再生装置およびそれを搭載した情報端末機に関する。
［背景技術］
マルチメディアの進展により、さまざまな情報がネットワークを通じて供給されるようになっている。これらの情報の代表的なものは、音や文字、あるいは画像などである。たとえば通信カラオケを例にとると、曲のタイトルや歌詞などは文字の情報であり、伴奏曲やバックコーラスなどは音の情報であり、背景の動画などは画像の情報である。
通信カラオケでは、このような各種の情報がネットワークを通じて同時に配信され、端末装置にて各情報の再生が行われる。そして、これらの各情報相互間で同期をとることにより、曲の進行に応じて歌詞の文字の色が変化したり、動画が変化したりする。
従来においては、上記のような同期をとるために、音、文字、画像等の各情報を処理するそれぞれのソフトウェアのプログラム中に時計を設け、この時計の時間情報に従って同期処理をしていた。このため、システムの負荷が増大したような場合に各時計が相互に一致しないことがあり、いわゆる同期ずれが発生して各情報の出力されるタイミングがずれ、音声と画像とが一致しないなどの不具合が生じていた。
また、音、文字、画像等のデータは、命令に従ってその都度ファイルにアクセスして読み出しているため、処理に時間を要すると共に、ファイルが各データ毎に別個に作成されているために、ファイル管理が煩雑になるという問題もあった。
［発明の開示］
それゆえに、本発明の目的は、属性の異なる各種の情報を再生するにあたって容易に同期をとることができるデータ再生装置を提供することにある。
本発明の他の目的は、データの種類別にファイルを作成する必要がなく、ファイル管理が容易なデータ再生装置を提供することにある。
本発明の他の目的は、データを高速で処理できるデータ再生装置を提供することにある。
本発明の他の目的は、伝送路の容量の変動にかかわらず、安定してデータを再生することができるデータ再生装置を提供することにある。
本発明の他の目的は、音、文字、画像などの属性の異なる各種の情報をダウンロードし、これらを再生してサウンドや可視情報として出力することができる情報端末機を提供することにある。
本発明において、ＭＩＤＩとは、Musical  Instrument  Digital  Interfaceの略語であって、電子楽器相互間や電子楽器とコンピュータとの間で音楽演奏の信号を相互にやり取りするための国際標準規格のことである。また、ＳＭＦとは、Standard MIDI Fileの略語であって、デルタ・タイムと呼ばれる時間情報と、演奏内容等を示すイベント情報とからなる標準ファイル形式のことである。本明細書における「ＭＩＤＩ」および「ＳＭＦ」という用語は、上記の意味で用いるものとする。
本発明においては、受信するデータはイベント情報とイベントが実行される時間情報とを含んでおり、ＳＭＦのような形式のデータからなる。受信データは、それぞれの時間情報に基づいて種類別に振り分けられ、振り分けたデータのイベントが実行されてデータの再生が行なわれる。
本発明では時間情報と音、文字、画像等の情報とが一体となっているため、各種データをそれらの持つ時間情報に従って再生することにより、時間情報を同期情報として利用することができる。その結果、サウンドや映像のような異なる種類のデータ間で簡単に同期をとることが可能となり、また、データの種類ごとにファイルを別々に作成して管理する必要がなくファイル管理も容易となる。さらに、各種のファイルに都度アクセスする必要がなくなり、処理が高速化される。
受信データは、ＭＩＤＩのイベント情報を持つ第１のデータと、ＭＩＤＩ以外のイベント情報を持つ第２のデータとから構成することができる。第２のデータとしては、たとえば文字や画像あるいは音声等に関するデータが考えられる。
ＭＩＤＩイベントは、電子楽器の発音を制御するためのコマンドの集合体である。たとえば、「ドの音の発音を開始せよ」「ドの音の発音を停止せよ」というような命令コマンドの形をとっている。そして、このＭＩＤＩイベントは、時間情報であるデルタ・タイムが付加されてＳＭＦ形式のデータとなり、デルタ・タイムが示す時間に従って所定時刻になると「ドの音の発音開始」「ドの音の発音停止」といったイベントが実行されるようになっている。
一方、ＭＩＤＩ以外のイベントには、ＭＥＴＡイベントやシステム・エクスクルーシブ・イベントがある。これらのイベントは、後述するようにフォーマットを拡張することが可能であり、この拡張されたフォーマットに各種データを埋め込むことができる。このようなＳＭＦの拡張フォーマットを用いると、フォーマットに大幅な改変を加えることなく、サウンドや映像等の各種データを容易に記録することができる。
本発明では、ＭＩＤＩ、文字および画像の各イベント情報を持つデータを受信し、再生したＭＩＤＩのデータをサウンドとして出力するとともに、再生した文字および画像のデータを可視情報として出力することによって、カラオケに適したデータ再生装置を実現できる。この場合、サウンドとしてＭＩＤＩのほかに音声を加えることにより、楽器の演奏パートをＭＩＤＩで、バックコーラスなどのボーカル部分を音声でそれぞれ再生することが可能となり、臨場感にあふれた演奏を実現することができる。
本発明に係るデータ再生装置では、属性の異なる各データはそれらの時間情報に基づいて単位区間ごとに振り分けられて記憶部に格納され、次の単位区間において記憶部から順次読み出されて再生される。これによると、受信データの処理がパイプライン化されるため、より高速な処理を行うことができる。また、データの時間情報と単位区間の時間幅とを管理し、当該単位区間で処理すべきデータのみを記憶部へ送ることによって、容易に時間同期をとることができる。
本発明に係るデータ再生装置は、データをダウンロードしながら再生を行うストリーム方式を採用することも可能である。この場合、再生によって消費されるデータ量が取り込まれるデータ量を上回ると、データが不足して音や画像等が途切れるため、データを必要量だけキャッシュした後に再生を開始することにより、データが途切れることなく連続して再生を行なうことができる。
本発明に係るデータ再生装置は、携帯電話機やゲーム機のような情報端末機に搭載することが可能であり、端末機の通信機能を利用して、各種データをサーバからダウンロードすることができる。そして、情報端末機にサウンドを出力するスピーカや、文字および画像を表示する表示器を設けることにより、音楽や映像を端末機で視聴することができる。電話機の場合は、着信信号を受信したときにスピーカからのサウンド出力を禁止して、着信音を出力するのが好ましい。ゲーム機の場合は、スピーカからサウンドとともにＭＩＤＩによる効果音を出力することもできる。
本発明に係るデータ再生装置には、小型の情報記憶媒体を着脱可能に設けることができ、ダウンロードした各種データをこの情報記憶媒体に保存して再利用することができる。たとえば、音楽データをＭＩＤＩや音声で、歌詞や曲目解説等のデータを文字で、ジャケット用の写真データを画像でそれぞれダウンロードすれば、情報記憶媒体それ自体をＣＤやＭＤとして利用することができる。
本発明では、受信するコマーシャル情報の文字データの中に、インターネットのＵＲＬと、このＵＲＬにおいて提供されるサービスに関する情報とを含ませておき、コマーシャルの再生に続いて前記ＵＲＬのホームページへジャンプさせることによって、コマーシャル視聴者に種々のサービスを提供することができる。
［発明を実施するための最良の形態］
本発明の前提となるデータ再生装置の例を第１図に示す。第１図において、１ａ，１ｂはデータが記録されたファイルであって、１ａはたとえばインターネット上のサーバにあるファイル、１ｂはたとえば装置内部のハードディスクにあるファイルである。
２はデータ再生装置の全体を制御するＣＰＵで、データ受信部３およびデータ振分部４を含んで構成されている。ＣＰＵ２はこれ以外にも種々の機能を有するブロックを含んでいるが、本発明では直接関係しないので、図示は省略してある。データ受信部３は、ファイル１ａ，１ｂへアクセスしてこれらに格納されたデータを受信する。ファイル１ａのデータは、有線を介してまたは無線により受信される。これらの受信データは、バッファ３ａに一時的に格納される。データ振分部４は、データ受信部３が受信したデータをデータ再生部６へ種類別に振り分ける。
データ再生部６は、ＭＩＤＩに関するデータを再生するＭＩＤＩ再生部１１と、音声に関するデータを再生する音声再生部１２と、文字に関するデータを再生する文字再生部１３と、画像に関するデータを再生する画像再生部１４とから構成されている。ＭＩＤＩ再生部１１は、再生する音楽に用いる種々の楽器の音源データを記憶した音源ＲＯＭ１１ａを有している。この音源ＲＯＭ１１ａは、ＲＡＭに置き換えて内蔵データを交換できるように実装することもできる。画像再生部１４は、静止画と動画を再生する機能を備えている。
１５はＭＩＤＩ再生部１１および音声再生部１２の出力を混合するミキサ、１６は文字再生部１３および画像再生部１４の出力を混合するミキサである。ミキサ１５にはエコー付加のような処理を行うためのサウンドエフェクト部１５ａが設けられており、ミキサ１６には映像に特殊効果を付与する処理を行うためのビジュアルエフェクト部１６ａが設けられている。１７はミキサ１５の出力が一時的に格納される出力バッファ、１８はミキサ１６の出力が一時的に格納される出力バッファである。１９は出力バッファ１７のデータに基づいてサウンドを出力する発音部としてのスピーカ、２０は出力バッファ１８のデータに基づいて文字や絵などの可視情報を表示する表示器である。
データ受信部３には、ファイル１ａ，１ｂに記録されているＳＭＦ形式のデータが入力される。ＳＭＦ形式のデータは、一般にデルタ・タイムと呼ばれる時間情報と、演奏内容等を示すイベント情報とからなり、イベント情報の種類に応じて第２図（ａ）〜（ｃ）に示す３つの形式がある。（ａ）はイベント情報がＭＩＤＩイベントからなるデータ、（ｂ）はイベント情報がＭＥＴＡイベントからなるデータ、（ｃ）はイベント情報がSys．Exイベントからなるデータである。
ＭＩＤＩイベントの詳細が第３図に示されている。第３図（ａ）は第２図（ａ）と同じものである。ＭＩＤＩイベントは、第３図（ｂ）（ｃ）のように、ステータス情報とデータとからなる。第３図（ｂ）は発音開始命令のイベントであって、ステータス情報には楽器の種類、データ１には音階、データ２には音の強弱がそれぞれ記録されている。また、第３図（ｃ）は発音停止命令のイベントであって、ステータス情報には楽器の種類、データ３には音階、データ４には音の強弱がそれぞれ記録されている。このように、ＭＩＤＩイベントは演奏情報が格納されたイベントであって、１つのイベントによって、たとえば「ドの音をピアノの音でこの強さで発音せよ」といった命令が構成される。
第４図は、第３図のフォーマットを簡略化してデータ量を削減した簡易型ＭＩＤＩのフォーマット例を示す。第３図では、発音開始命令と発音停止命令とが別々に構成されているが、第４図ではデータに発音時間を入れることで、発音と停止とを１つのイベントに統合している。また、音の強弱のデータは省き、また音階のデータはステータス情報に含ませている。なお、第４図のフォーマットはＳＭＦのような標準フォーマットではないが、本発明で取り扱うデータにはこのようなＳＭＦ以外のフォーマットも含む。
ＭＥＴＡイベントの詳細が第５図に示されている。第５図（ａ）は第２図（ｂ）と同じものである。ＭＥＴＡイベントは、データを転送したり、再生の開始・停止などの制御を行うイベントであるが、フォーマットの拡張が可能であって、拡張されたフォーマットに各種のデータを埋め込むことができる。第５図（ｂ）〜（ｅ）は、拡張されたＭＥＴＡイベントのフォーマット例を示しており、（ｂ）は音声データが埋め込まれたフォーマット、（ｃ）は文字データが埋め込まれたフォーマット、（ｄ）は画像データが埋め込まれたフォーマット、（ｅ）は文字データと画像データとが埋め込まれたフォーマットをそれぞれ示している。画像には絵や写真のような静止画のほか、動画も含まれる。
先頭のＦＦｈはこのイベントがＭＥＴＡイベントであることを示すヘッダである。次の３０ｈ，３１ｈ，…は、ＭＥＴＡイベントのフォーマットが拡張フォーマットであることを表す識別子である。また、ｌｅｎはＭＥＴＡイベントのデータ長、ｔｙｐｅは転送するデータのフォーマット、ｉｄはデータの番号をそれぞれ表している。ｅｖｅｎｔは実行すべきイベントの内容を示すもので、たとえば「音声データの転送を開始せよ」や「画像データの転送を終了せよ」といった命令で表される。これらのデータの終了位置は、データ長を表すｌｅｎの値から知ることができる。
ＭＥＴＡイベントには上記のようなデータを記録した拡張フォーマットのほかに、制御に関するフォーマットがある。第６図はその一例であって、（ａ）は再生開始、（ｂ）は再生停止のイベントフォーマットを示している。（ａ）の１０ｈと（ｂ）の１１ｈが、それぞれ再生開始および再生停止のコマンドである。それ以外のＦＦｈ、ｌｅｎ、ｔｙｐｅおよびｉｄについては、第５図と同一であるから説明は省略する。
Sys．Exイベントの詳細が第７図に示されている。第７図（ａ）は第２図（ｃ）と同じものである。Sys．Exイベントはシステム・エクスクルーシヴ・イベントと呼ばれ、たとえばオーケストラに適合したシステムに設定する場合の設定情報等に関するイベントである。このSys．Exイベントも拡張が可能であって、拡張されたフォーマットに各種のデータを埋め込むことができる。第７図（ｂ）〜（ｅ）は、拡張されたSys．Exイベントのフォーマット例を示しており、第５図と同様のフォーマットとなっている。
ＳＭＦ形式のデータは以上のように構成されており、これらのデータがいくつも組み合わされて一連のデータ列が構成される。第８図は、このようなデータ列の例を示している。ＭはＭＩＤＩに関するデータで、第３図に示したフォーマットを備えている。Ａは音声に関するデータで、第５図（ｂ）に示したフォーマットを備えている。Ｔは文字に関するデータで、第５図（ｃ）に示したフォーマットを備えている。Ｐは画像に関するデータで、第５図（ｄ）に示したフォーマットを備えている。なお、各データの配列順序は第８図に限定されるものではなく、種々のパターンが存在しうる。また、第８図では音声、文字および画像のデータがＭＥＴＡイベントに記録されているが、これらをSys．Exイベントに記録することもできる。各データＭ，Ａ，Ｔ，Ｐはそれぞれパケットとして構成されており、これらが連鎖されて一連のデータ列となっている。このデータ列は、第１図のデータ受信部３によって受信され、バッファ３ａに格納される。
受信されたデータは、それぞれのデルタ・タイムΔＴに基づいてデータ振分部で振分けられ、データ再生部６でイベントが実行されてデータが再生される。イベントが実行されるタイミングは、デルタ・タイムΔＴによって決まる。すなわち、直前に実行されたイベントからの経過時間Δｔと、今回実行されるイベントのデルタ・タイムΔＴとの関係がΔｔ≧ΔＴのときにイベントが実行される。つまり、あるイベントが実行されると、そのイベント開始からの経過時間がカウントされ、この経過時間が次のイベントのデルタ・タイムと等しいかあるいはそれを超えたときに（ＣＰＵによる時間分解能は有限なので、デルタ・タイムとぴったり一致しないで超える場合もある）、次のイベントが実行されるようになっている。このように、デルタ・タイムは直前のイベントからどれだけ時間が経過すれば今回のイベントを実行すべきかを表す情報であって、絶対的な時間を表すものではないが、デルタ・タイムを積算してゆくことで再生開始からの時間を算出することは可能である。
以下、データ再生部６の各部における再生の詳細について説明する。まず、ＭＩＤＩ再生部１１における再生動作を説明する。第１図において、ＣＰＵ２のデータ振分部４は、図示しないＲＯＭに格納されたプログラムに従って、受信したデータをバッファ３ａから順次読み出す。読み出されたデータがＭＩＤＩに関するデータＭ（第３図）であれば、そのイベント情報はＭＩＤＩ再生部１１に与えられる。イベントの内容が、たとえば「ミの音をピアノの音で発音せよ」という命令であったとすると、ＭＩＤＩ再生部１１はこの命令を解読して、音源ＲＯＭ１１ａからピアノの音を読込み、ソフトウエア・シンセサイザによってシンセサイザ音を生成してミの音程で発音を開始する。このときからＣＰＵ２は経過時間をカウントし、この経過時間が「ミの発音を停止せよ」という次のイベントに付属しているデルタ・タイムと等しくなるかもしくはそれを超えると、ＭＩＤＩ再生部１１にこの命令が与えられ、ＭＩＤＩ再生部１１はこの命令を解読して、ミの音の発音を停止する。こうして、発音開始から発音停止までの時間だけミの音がピアノ音で再生される。
次にＣＰＵ２は、ミの音の発音停止からの経過時間をカウントし、この経過時間がたとえば「ラの音をピアノの音で発音せよ」という次のイベントに付属しているデルタ・タイムと等しくなるかもしくはそれを超えると、ＭＩＤＩ再生部１１にこの命令が与えられ、ＭＩＤＩ再生部１１はこの命令を解読して、音源ＲＯＭ１１ａからピアノの音を読込み、シンセサイザ音を生成してラの音程で発音を開始する。そして、このときからＣＰＵ２は経過時間をカウントし、この経過時間が「ラの発音を停止せよ」という次のイベントに付属しているデルタ・タイムと等しくなるかもしくはそれを超えると、ＭＩＤＩ再生部１１にこの命令が与えられ、ＭＩＤＩ再生部１１はこの命令を解読して、ラの音の発音を停止する。こうして、発音開始から発音停止までの時間だけラの音がピアノ音で再生される。このような動作が繰り返されることにより、ＭＩＤＩ再生部１１はＭＩＤＩによる音の再生を行う。
次に、ＭＩＤＩ以外のイベント情報をもつデータの再生について説明する。前述のように、音声、文字および画像の各データはＭＥＴＡイベント（第５図）またはSys．Exイベント（第７図）に記録されている。第１図において、データ振分部４は、前記と同様にして受信データをバッファ３ａから順次読み出す。読み出されたデータが音声に関するデータＡの場合は、読み出したデータのイベント情報はデルタ・タイムに従って音声再生部１２へ振分けられ、音声再生部１２は当該イベントの内容を解読してイベントを実行し、音声を再生する。読み出されたデータが文字に関するデータＴの場合は、読み出したデータのイベント情報はデルタ・タイムに従って文字再生部１３へ振分けられ、文字再生部１３は当該イベントの内容を解読してイベントを実行し、文字を再生する。読み出されたデータが画像に関するデータＰの場合は、読み出したデータのイベント情報はデルタ・タイムに従って画像再生部１４へ振分けられ、画像再生部１４は当該イベントの内容を解読してイベントを実行し、画像を再生する。
より具体的には、音声再生部１２がデータ振分部４からたとえば「音声Ｂを発音せよ」いうイベントを受け取ると、音声再生部１２は当該イベントに付加されている音声Ｂのデータをデコードして再生する。このときからＣＰＵ２は経過時間をカウントし、この経過時間がたとえば「文字Ｃを表示せよ」という次のイベントに付属しているデルタ・タイムと等しくなるかもしくはそれを超えると、文字再生部１３は当該イベントに付加されている文字Ｃのデータをデコードして再生する。次にＣＰＵ２は、文字Ｃの再生からの経過時間をカウントし、この経過時間がたとえば「絵Ｄを表示せよ」という次のイベントに付属しているデルタ・タイムと等しくなるかもしくはそれを超えると、画像再生部１４は当該イベントに付加されている絵Ｄのデータをデコードして再生する。この点、前述したＭＩＤＩデータの再生の原理と基本的に同じである。
上記の説明においては便宜上、ＭＩＤＩ再生部１１による再生動作と、ＭＩＤＩ以外の再生部１２〜１４による再生動作とを分けて記述したが、実際には第８図でも示したように、データ受信部３にはＭＩＤＩイベントを持つデータＭとＭＩＤＩ以外のイベントを持つデータＡ，Ｔ、Ｐとが時系列的に混在して入力される。たとえば、ＭＩＤＩ（Ｍ）→絵（Ｐ）→文字（Ｔ）→ＭＩＤＩ（Ｍ）→音声（Ａ）→動画（Ｐ）→…のように、次々と異なる種類のデータが入力される。データ振分部４は、これらのデータをデルタ・タイムに従って種類別に各再生部１１〜１４へ振り分け、各再生部１１〜１４はそれぞれに対応したデータの再生処理を行なう。
ＭＩＤＩ再生部１１で再生されたデータと、音声再生部１２で再生されたデータとは、ミキサ１５で混合され、サウンドエフェクト部１５ａでエコー処理等が施された後、出力バッファ１７に一時的に格納され、スピーカ１９からサウンドとして出力される。一方、文字再生部１３で再生されたデータと、画像再生部１４で再生されたデータとは、ミキサ１６で混合され、ビジュアルエフェクト部１５ａで特殊映像処理等が施された後、出力バッファ１８に一時的に格納され、表示器２０に可視情報として表示される。そして、データ振分部４が第６図（ｂ）に示した再生停止のＭＥＴＡイベントを受取ると、データの再生は終了する。
このようにして、第１図のデータ再生装置においては、ＭＩＤＩ、音声、文字および画像が混在したデータ列から各データを種類別に振り分けて再生することができる。そして、文字や画像を再生するにあたっては、ＭＩＤＩの再生と同じようにデルタ・タイムを参照し、このデルタ・タイムに従うタイミングでデータを再生するようにしている。したがって、デルタ・タイムを記述するだけでサウンドや映像のような異なる種類のデータ間で簡単に同期をとることができ、また、従来のように各データを処理するプログラム中に時計を組み込む必要がないので、時計相互間の不一致による同期ずれの問題も生じない。
第９図は、第１図の再生装置におけるデータ再生方法を示したフローチャートであり、ＣＰＵ２によって実行される手順を示している。以下、再生装置が通信カラオケ用の再生装置である場合を例にとって動作を説明する。なお、以下ではフローチャートのステップを「Ｓ」と略記することとする。
データ受信部３がネットワーク上のサーバのファイル１ａから通信回線を介してデータを受信すると（Ｓ１０１）、この受信データはバッファ３ａへ格納される（Ｓ１０２）。次に、データ振分部４はバッファ３ａのデータを読み出して、直前のイベントが実行されてからの経過時間をカウントする（Ｓ１０３）。そして、この経過時間がデルタ・タイムの示す時間と一致したか（または超えたか）を判断し（Ｓ１０４）、デルタ・タイムを超えていなければ（Ｓ１０４ＮＯ）、Ｓ１０３に戻って経過時間のカウントを続行する。経過時間がデルタ・タイムと一致したかまたは超えると（Ｓ１０４ＹＥＳ）、データの処理に移る。
データの処理にあたっては、まず受信したデータの種類が判別される。すなわち、受信したデータがＭＩＤＩのデータＭか否かが判別され（Ｓ１０５）、ＭＩＤＩのデータであれば（Ｓ１０５ＹＥＳ）、これをＭＩＤＩ再生部１１へ振り分け、ＭＩＤＩ再生部１１ではシンセサイザ音が生成される（Ｓ１１１）。その詳細な原理についてはすでに述べたので、ここでは説明を省略する。シンセサイザによる音の再生によって、スピーカ１９からカラオケの伴奏曲が出力される。
受信データがＭＩＤＩのデータＭでなければ（Ｓ１０５ＮＯ）、次に音声のデータＡか否かが判別され（Ｓ１０６）、音声のデータＡであれば（Ｓ１０６ＹＥＳ）、これを音声再生部１２へ振り分け、音声再生部１２で音声の処理が行われて音声が再生される（Ｓ１１２）。その詳細な原理についてもすでに述べたので、ここでは説明を省略する。音声の再生によって、スピーカ１９からはバックコーラスなどのボーカルが出力される。
受信データが音声のデータＡでなければ（Ｓ１０６ＮＯ）、次に文字のデータＴか否かが判別され（Ｓ１０７）、文字のデータＴであれば（Ｓ１０７ＹＥＳ）、これを文字再生部１３へ振り分け、文字再生部１３で文字の処理が行われて文字が再生される（Ｓ１１３）。文字の再生によって、カラオケ曲のタイトルや歌詞が表示器２０に表示される。
受信データが文字のデータＴでなければ（Ｓ１０７ＮＯ）、次に画像のデータＰか否かが判別され（Ｓ１０８）、画像のデータＰであれば（Ｓ１０８ＹＥＳ）、これを画像再生部１４へ振り分け、画像再生部１４で静止画や動画の処理が行われて画像が再生される（Ｓ１１４）。画像の再生によって、アニメーションや動画などの背景画像が表示器２０に表示される。
受信データが画像データでもなければ（Ｓ１０８ＮＯ）、そのデータはたとえば設定や制御などに関するデータであり、その内容に従った所定の処理が行われる（Ｓ１０９）。ついで、再生を停止するか否か、すなわち第６図（ｂ）のＭＥＴＡイベントを受取ったか否かが判断される（Ｓ１１０）。再生を停止しない場合は（Ｓ１１０ＮＯ）、Ｓ１０１に戻って次のデータの受信を待ち、再生を停止する場合は（Ｓ１１０ＹＥＳ）、動作を終了する。
以上のように、第１図のデータ再生装置は、ＭＩＤＩ再生部１１および音声再生部１２からなるサウンドの再生部と、文字再生部１３および画像再生部１４からなる可視情報の再生部とを設けたことによって、通信カラオケに適した装置となっている。本発明においては、音声再生部１２は必ずしも必要なものではなく、省略することも可能であるが、音声再生部１２を設けて楽器のパートはＭＩＤＩ再生部１１で再生し、ボーカル部分を音声再生部１２で再生することにより、ボーカル部分を本来の音声で再生することが可能となり、きわめて臨場感の高い演奏が実現できる。
なお、データ受信部３が受信するＳＭＦ形式のデータは、前述のようにネットワーク上のサーバのファイル１ａに蓄積されており、このファイル１ａには新曲のデータが定期的にアップロードされて、ファイル１ａの内容が更新されるようになっている。
第１０図は、第１図のデータ再生装置をテレビのＣＭ（コマーシャル）の放映に用いた場合の再生方法を示すフローチャートで、ＣＰＵ２によって実行される手順を示している。図において、Ｓ１２１〜Ｓ１２４は第９図のＳ１０１〜１０４にそれぞれ対応しており、その動作は第９図の場合と同じであるので、説明は省略する。
所定の時刻が到来して処理に移ると（Ｓ１２４ＹＥＳ）、受信データがＣＭのバックに流れる音楽のデータか否かが判別される（Ｓ１２５）。ここでは、このバック音楽のデータはＭＩＤＩで構成されている。バック音楽のデータであれば（Ｓ１２５ＹＥＳ）、ＭＩＤＩ再生部１１へ振り分けてシンセサイザ処理を行い、音を再生する（Ｓ１３２）。これによって、スピーカ１９からＣＭのバック音楽が出力される。
受信データがバック音楽データでなければ（Ｓ１２５ＮＯ）、次にアナウンサーが話すアナウンスのデータか否かが判別される（Ｓ１２６）。このアナウンスデータは音声データで構成されている。アナウンスデータであれば（Ｓ１２６ＹＥＳ）、音声再生部１２へ振り分けて音声処理を行い、音声を再生する（Ｓ１３３）。音声の再生によって、スピーカ１９からはアナウンサーの解説などが出力される。
受信データがアナウンスデータでなければ（Ｓ１２６ＮＯ）、次に商品名などを表す文字のデータか否かが判別され（Ｓ１２７）、文字データであれば（Ｓ１２７ＹＥＳ）、これを文字再生部１３へ振り分け、文字再生部１３で文字が再生されて表示器２０に表示される（Ｓ１３４）。
受信データが文字データでなければ（Ｓ１２７ＮＯ）、次に絵のデータか否かが判別され（Ｓ１２８）、絵のデータであれば（Ｓ１２８ＹＥＳ）、これを画像再生部１４へ振り分け、画像再生部１４で静止画の処理が行われて絵が再生され、表示器２０に表示される（Ｓ１３５）。
受信データが絵のデータでなければ（Ｓ１２８ＮＯ）、次に動画のデータか否かが判別され（Ｓ１２９）、動画のデータであれば（Ｓ１２９ＹＥＳ）、これを画像再生部１４へ振り分け、画像再生部１４で動画の処理が行われて動画が再生され、表示器２０に表示される（Ｓ１３６）。
受信データが動画データでもなければ（Ｓ１２９ＮＯ）、Ｓ１３０へ進む。Ｓ１３０およびＳ１３１は、第９図のＳ１０９およびＳ１１０にそれぞれ対応しており、その動作も第９図と同様であるから、説明は省略する。
ところで、上述した再生方法において、ＳＭＦ形式のデータに埋め込まれた音声、文字および画像のデータを再生するにあたっては、同じデータを何回か反復して再生する場合がある。たとえば、カラオケのバックコーラスを３回繰り返したり、ＣＭの最初と終りの部分で同じ文字を２回表示したりすることがある。このような場合、繰り返し回数に対応した個数のデータを第５図もしくは第７図のフォーマットに埋め込むと、データ量が増大するという問題がある。
そこで、この解決策として第１１図に示す方法が考えられる。すなわち、（ａ）のように、同じデータＲをｔ１，ｔ２，ｔ３のタイミングで３回繰り返して再生する場合、送信側（サーバ）では、（ｂ）のようにデータＲを埋め込んだパケットを最初に１回だけ送る。受信側（データ再生装置）では、このデータＲをメモリ（図示省略）に記憶しておく。反復再生時には、送信側はデータＲは送らず、「デルタ・タイムの示す時間が経過したらデータＲを再生せよ」というメッセージだけを送る。受信側ではこのメッセージに従い、デルタ・タイムに従う所定の時刻になると、メモリからデータＲを読み出してきてこれを再生する。この動作をｔ１，ｔ２，ｔ３の３回にわたって行うことで、送信するデータ量は３分の１で済む。
なお、ここでは送信データを一旦メモリに蓄積した後に再生を行う場合を例に挙げたが、第１１図の方法は、データをダウンロードしながら再生を行う、いわゆるストリーム方式のデータ受信においても適用できる。この場合は、最初の再生時点であるｔ１において、送られてきたデータＲをメモリに記憶することになる。
第１２図は上述した反復再生処理を示したフローチャートであり、第９図のＳ１１２、Ｓ１１３もしくはＳ１１４における詳細な手順、または、第１０図のＳ１３３、Ｓ１３４、Ｓ１３５もしくはＳ１３６における詳細な手順である。まず、受信したデータが反復再生するデータＲか否かを判断して（Ｓ１４１）、反復データでなければ（Ｓ１４１ＮＯ）、通常のデータとして処理する。反復データであれば（Ｓ１４１ＹＥＳ）、再生回数をＣＰＵ内部のカウンタＮにセットして（Ｓ１４２）メモリからデータＲを読み出し（Ｓ１４３）、これを出力する（Ｓ１４４）。次にカウンタＮを１つ減じてＮ−１に更新する（Ｓ１４５）。そしてカウンタＮが０になったか否かを判断して（Ｓ１４６）、０になっていなければ（Ｓ１４６ＮＯ）第９図のＳ１１０もしくは第１０図のＳ１３１へ移行する。カウンタＮが０になれば（Ｓ１４６ＹＥＳ）、記録されているデータＲを消去してメモリを開放する（Ｓ１４７）。
第１３図は、ストリーム方式におけるデータ先送りの原理を示す図である。ＭＩＤＩのデータに続いて音声や画像などのデータを送る場合、（ａ）に示したように、ＭＩＤＩの部分ではデータ量は少ないが、音声や画像などのデータＸの部分になると急激にデータ量が増大する。（ＭＩＤＩのデータ量が少ないのは、ＭＩＤＩは音そのもののデータではなく、音の発音を制御するためのコマンドであって、バイナリデータで構成されているからである。）したがって、このデータＸをそのまま送ったのでは、通信回線として大容量のものが必要となる。
そこで、第１３図（ｂ）に示すようにデータＸを適当に分割して、この分割したデータにＸ１，Ｘ２，Ｘ３というＩＤを付し、これらの分割データを先行するＭＩＤＩのデータ間に挿入して先送りすることで、送信するデータ量が平準化され、回線の容量を減らすことが可能となる。ここではデータＸの一部だけを分割する例を示したが、データＸを全区間にわたって分割してもよい。
ＭＩＤＩに後続するデータとしては、第１４図（ａ）に示すように複数のデータＸ，Ｙが同時に存在するものであってもよい。この場合も、データＸおよびデータＹの各分割データには、Ｘ１，Ｘ２，…およびＹ１，Ｙ２，…といったＸ，ＹそれぞれのグループごとのＩＤが付与される。第１４図（ｂ）は、分割データを先行するＭＩＤＩのデータ間に挿入した例を示す。このように分割データが挿入されたデータ群がデータ受信部３で受信されると、このデータ群から挿入された分割データが抽出され、抽出された分割データを合成することにより、元の再生データが復元される。この詳細を第１５図および第１６図により説明する。
受信された分割データは、ＭＩＤＩのデータとは分離されて、第１４図（ｂ）における先頭のデータから時系列的に順次メモリに格納されてゆく。このメモリの内容が第１５図に示されている。格納された各分割データのエリアには、当該分割データに連結される後続の分割データの開始番地がＸ，Ｙそれぞれのグループごとに記録される。たとえば、データＸ１の最後にはデータＸ２の開始番地が記録され、データＸ２の最後にはデータＸ３の開始番地が記録される。また、データＹ１の最後にはデータＹ２の開始番地が記録され、データＹ２の最後にはデータＹ３の開始番地が記録される。
第１６図は、データ受信部３が第１４図（ｂ）のデータ群を受信した場合に、分割データを抽出してメモリに格納する動作を示すフローチャートである。まず先頭のデータＸ１を読み取り（Ｓ１５１）、読み取ったデータＸ１をメモリに書き込む（Ｓ１５２）。ついでデータＸ２を読み取り（Ｓ１５３）、このときデータＸ２が格納されるエリアの開始番地をデータＸ１の最後に書き込んでから（Ｓ１５４）、データＸ２をメモリに書き込む（Ｓ１５５）。次に、ＭＩＤＩのデータの処理を行った後（Ｓ１５６）、データＹ１を読み取り（Ｓ１５７）、読み取ったデータＹ１をメモリに書き込む（Ｓ１５８）。その後、データＸ３を読み取り（Ｓ１５９）、このときデータＸ３が格納されるエリアの開始番地をデータＸ２の最後に書き込んでから（Ｓ１６０）、データＸ３をメモリに書き込む（Ｓ１６１）。ついでデータＹ２を読み取り（Ｓ１６２）、このときデータＹ２が格納されるエリアの開始番地をデータＹ１の最後に書き込んでから（Ｓ１６３）、データＹ２をメモリに書き込む（Ｓ１６４）。以下、同様にしてデータＸ４からデータＸ６までをメモリに書き込む。
このようにして、メモリに格納された分割データの終わりに後続の分割データの開始番地を記録しておくことにより、分割データを容易に合成して復元することができる。すなわち、データＸに関しては、分割データＸ１，Ｘ２，…Ｘ６が開始番地を介して連鎖的に連結されているので、第１５図のようにデータＸの分割データとデータＹの分割データとが混在して格納されていても、開始番地を参照してＸ１，Ｘ２，…Ｘ６のデータを読み出して合成すれば、簡単に元のデータＸを復元することができる。データＹに関しても同様である。
第１７図は無音区間を有する音声データの処理を説明する図である。たとえば、アナウンサーの声を音声信号として記録し、第５図（ｂ）もしくは第７図（ｂ）のＳＭＦフォーマットに埋め込む場合を考える。アナウンサーの声は途中で途切れたりすることがあり、この途切れた区間（無音区間）のデータは本来不要なデータである。したがって、この無音区間のデータをカットして、必要な部分だけをＳＭＦフォーマットに埋め込むようにすれば、データ量を削減することができる。
第１７図の音声信号においては、Ｔの区間が無音区間である。無音区間Ｔは本来的には信号レベルが０の区間であるが、実際にはノイズ等の混入により必ずしもレベルが０とは限らない。そこで、一定範囲のレベル値Ｌを定め、信号レベルがＬを超えない区間が一定区間続いた場合に、この区間を無音区間Ｔとする。そして、この無音区間Ｔをカットした音声データを作成し、これを第５図（ｂ）もしくは第７図（ｂ）のＳＭＦフォーマットに埋め込んで、前述した再生方法に従って再生するようにすれば、送信するデータ量が少なくて済み、受信側のメモリの容量も節約できる。
しかしながら、無音区間Ｔを単にカットしただけでは、再生時に信号が急峻な立上りや立下がりをしてノイズが発生する。そこで、これを回避するために信号の立上りと立下り付近において窓処理を施し、滑らかな立上り・立下り特性が得られるようにすることが望ましい。この窓処理は、窓関数を用いた公知の方法により容易に実現できる。第１７図においては、Ｗ１〜Ｗ４が窓処理の施される部分である。
第１８図は、無音区間をカットしてデータを記録する場合のフローチャートである。先頭から順次データを読取り（Ｓ１７１）、読取ったデータのレベルが一定値を超えているか否かが判断される（Ｓ１７２）。一定値を超えていなければ（Ｓ１７２ＮＯ）、Ｓ１７１へ戻って引続きデータを読取り、一定値を超えていれば（Ｓ１７２ＹＥＳ）、データの立上り付近で上述した窓処理を行い、処理後のデータをメモリに書き込む（Ｓ１７３）。ここでの窓処理は、第１７図におけるＷ１での窓処理であり、緩やかに信号が立上るフェイド・インの処理となる。
次に、再びデータを読取り（Ｓ１７４）、読取ったデータのレベルが一定値を超えているか否かが判断される（Ｓ１７５）。一定値を超えていれば（Ｓ１７５ＹＥＳ）、そのデータをメモリに書き込み（Ｓ１７６）、Ｓ１７４へ戻って次のデータを読む。一定値を超えていなければ（Ｓ１７５ＮＯ）、その区間が一定区間連続したか否かが判断され（Ｓ１７７）、一定区間連続していなければ（Ｓ１７７ＮＯ）、データをメモリに書き込んで（Ｓ１７６）、Ｓ１７４へ戻って次のデータを読む。一定レベルを超えない区間が一定区間連続していれば（Ｓ１７７ＹＥＳ）、その区間は無音区間であるとみなして、第１７図におけるＷ２の部分に窓処理を施し、処理後のデータをメモリに書き込む（Ｓ１７８）。ここでの窓処理は、緩やかに信号が立下るフェイド・アウトの処理となる。なお、Ｓ１７８ではＳ１７６で書き込んだデータのうち、無音区間における不要なデータを消去する処理も行われる。
次に、データの読取りが終了したか否かが判断され（Ｓ１７９）、終了していなければ（Ｓ１７９ＮＯ）Ｓ１７１へ戻って次のデータを読み、以降は上記と同様のステップを経て、第１７図のＷ３，Ｗ４における窓処理が行われる。データの読取りが終了すれば（Ｓ１７９ＹＥＳ）、動作を終了する。
上記においては、ＳＭＦの拡張フォーマットに埋め込む情報として、音声、文字および画像をとりあげたが、埋め込む情報は何であってもよく、たとえばコンピュータ・プログラムであってもよい。この場合、たとえばＭＩＤＩのデータに続いてコンピュータ・プログラムが再生されるようにしておくと、最初にＭＩＤＩによる音楽が演奏され、これが終ると自動的にプログラムが立ち上がるといった使い方ができる。
また、上記ではネットワーク上のサーバのファイル１ａから通信回線を介してデータを受信する例を示したが、パーソナルコンピュータでＳＭＦ形式のデータを作成してハードディスク上のファイル１ｂに蓄積しておき、ここからデータをダウンロードするようにしてもよい。
第１９図は本発明に係るデータ再生装置の第１実施形態を示す。１ａ，１ｂはデータが記録されたファイルであって、１ａはたとえばインターネット上のサーバにあるファイル、１ｂはたとえば装置内部のハードディスクにあるファイルである。
２はデータ再生装置の全体を制御するＣＰＵで、データ受信部３およびデータ振分部４を含んで構成されている。ＣＰＵ２はこれ以外にも種々の機能を有するブロックを含んでいるが、本発明では直接関係しないので、図示は省略してある。データ受信部３は、ファイル１ａ，１ｂへアクセスしてこれらに格納されたデータを受信する。ファイル１ａのデータは、有線を介してまたは無線により受信される。受信するデータのフォーマットは、第２図ないし第８図と同じものである。これらの受信データは、バッファ３ａに一時的に格納される。データ振分部４は、データ受信部３が受信したデータを種類別に振り分けて、記憶部５を構成する各バッファ７〜１０に格納する。
６はデータ再生部であって、ＭＩＤＩに関するデータを処理するＭＩＤＩ再生部１１と、音声に関するデータを処理する音声再生部１２と、文字に関するデータを処理する文字再生部１３と、画像に関するデータを処理する画像再生部１４とから構成されている。なお、図示は省略してあるが、ＭＩＤＩ再生部１１は第１図の音源ＲＯＭ１１ａを備えている。画像再生部１４は、静止画と動画を再生する機能を備えている。
１５はＭＩＤＩ再生部１１および音声再生部１２の出力を混合するミキサ、１６は文字再生部１３および画像再生部１４の出力を混合するミキサである。ここでも図示を省略してあるが、ミキサ１５は第１図のサウンドエフェクト部１５ａを備えており、ミキサ１６は第１図のビジュアルエフェクト部１６ａを備えている。１７はミキサ１５の出力が一時的に格納される出力バッファ、１８はミキサ１６の出力が一時的に格納される出力バッファである。１９は出力バッファ１７のデータに基づいてサウンドを出力する発音部としてのスピーカ、２０は出力バッファ１８のデータに基づいて文字や絵などの可視情報を表示する表示器である。２１はシステムの基準時刻となるシステムクロックを発生して各部のタイミングを制御するタイミング制御部、２２はデータ再生装置に外付けされる外部記憶装置である。
記憶部５、データ再生部６、ミキサ１５，１６、出力バッファ１７，１８およびタイミング制御部２１は、ＤＳＰ（Digital Signal Processor）により構成されている。ＤＳＰに代えてＬＳＩによって上記各部を構成することも可能である。
第１９図と第１図とを比較すれば明らかなように、第１９図のデータ再生装置においては、データ振分部４とデータ再生部６との間にバッファ７〜１０からなる記憶部５が設けられており、またタイミング制御部２１が設けられている。さらに、外部記憶装置２２も付加されている。
第２０図は、第１９図のデータ再生装置の全体の動作を示すフローチャートである。まず、データ受信部３がファイル１ａまたはファイル１ｂからのデータを受信する（Ｓ１８１）。この受信データはバッファ３ａへ格納される。次に、ＣＰＵ２はタイミング制御部２１からのシステムクロックや、データ受信部３が受信した各データのデルタ・タイムに基づいて、データ振分部４がデータを振り分けるのに必要な時間演算を行なう（Ｓ１８２）。このＳ１８２の詳細については後述する。データ振分部４は、時間演算の結果に従って処理すべきデータを種類別に振り分け、対応するバッファ７〜１０に格納する（Ｓ１８３）。このＳ１８３の詳細についても後述する。
バッファ７〜１０に格納されたデータは、各バッファに対応するデータ再生部１１〜１４によりそれぞれ読み出され、各データ再生部１１〜１４においてデータに記録されたイベントが実行されてデータが再生される（Ｓ１８４）。Ｓ１８４の詳細についても後述する。再生されたデータのうち、ＭＩＤＩと音声のデータはミキサ１５で混合され、文字と画像のデータはミキサ１６で混合される（Ｓ１８５）。これらの混合されたデータはそれぞれ出力バッファ１７，１８に格納された後、スピーカ１９および表示器２０へ出力される（Ｓ１８６）。
第２１図は、Ｓ１８２における時間演算の原理を説明する図である。図のｔは時間軸であって、イベント０〜イベント４は受信したデータ列に含まれているイベントの再生タイミングを示している（ただし、この再生タイミングは、受信データをそれらのデルタ・タイムに従って再生したと仮定した場合のタイミングを表しており、時間軸ｔ上で実際に再生されたタイミングを表したものではないことに注意）。たとえば、イベント０は画像のイベント、イベント１はＭＩＤＩのイベント、イベント２は音声のイベント、イベント３は文字のイベント、イベント４は画像のイベントである。ΔＴ１〜ΔＴ４はデルタ・タイムであって、ΔＴ１はイベント１のデルタ・タイム、ΔＴ２はイベント２のデルタ・タイム、ΔＴ３はイベント３のデルタ・タイム、ΔＴ４はイベント４のデルタ・タイムである。前述のように、デルタ・タイムは直前のイベントが実行された時点から今回のイベントが実行されるまでの時間であり、たとえばイベント１が実行された時点からΔＴ２が経過するとイベント２が実行され、イベント２が実行された時点からΔＴ３が経過するとイベント３が実行されるようになっている。ｔ１は前回データを処理した時刻、ｔ２は現在時刻を表しており、その差ｔ２−ｔ１は単位区間である１フレームに相当している。この１フレーム区間はたとえば１５ｍｓの時間幅を有しており、１フレームの最初と最後のタイミングは、タイミング制御部２１（第１９図参照）からのシステムクロックによって決定される。Ｑはデータの処理区間であって、現在時刻ｔ２と、１つ前のフレームにおける最後のイベント（イベント０）の実行時刻ｔ０との差として定義される。
第２２図はデータ振分部４によるデータ振分けの手順を示すフローチャートである。以下、第２１図および第２２図を参照して、データを振り分ける手順について説明する。第２１図のｔ２のタイミング（１フレームの最後のタイミング）においてタイミング制御部２１からＣＰＵ２へクロックの割込みがあると、システムがＷＡＫＥ状態となり（Ｓ１９１）、ＣＰＵ２は処理区間Ｑの時間幅を演算する（Ｓ１９２）。このＱは前述のように、
Ｑ＝ｔ２−ｔ０
として算出され、今回データを処理する時間幅を表している。次にＣＰＵ２は、受信したデータのデルタ・タイムΔＴを順に読み取って（Ｓ１９３）、処理区間Ｑの時間幅がΔＴ以上あるか否かを判定する（Ｓ１９４）。Ｑ≧ΔＴであれば（Ｓ１９４ＹＥＳ）、次にデータの種類を順に判定してゆき（Ｓ１９５、Ｓ１９８、Ｓ２００、Ｓ２０２）、それぞれのデータに対応して設けられたバッファ７〜１０へデータを振り分けて格納する（Ｓ１９６、Ｓ１９９、Ｓ２０１、Ｓ２０３）。その後、Ｑ＝Ｑ−ΔＴの演算を行なってＱの値を更新する（Ｓ１９７）。
第２１図の例では、イベント０は前回すでに処理が終わっているので、イベント１から順に判定する。イベント１のデルタ・タイムΔＴ１に関しては、Ｑ＞ΔＴ１であるからＳ１９４の判定はＹＥＳとなり、次にデータがＭＩＤＩか否かを判定する（Ｓ１９５）。第２１図において、イベント１がＭＩＤＩのイベントであれば（Ｓ１９５ＹＥＳ）、バッファ７へデータを送ってデータを一時的に格納する（Ｓ１９６）。イベント１がＭＩＤＩのイベントでなければ（Ｓ１９５ＮＯ）、音声のイベントか否かを判定する（Ｓ１９８）。イベント１が音声のイベントであれば（Ｓ１９８ＹＥＳ）、バッファ８へデータを送ってデータを一時的に格納する（Ｓ１９９）。イベント１が音声のイベントでなければ（Ｓ１９８ＮＯ）、文字のイベントか否かを判定する（Ｓ２００）。イベント１が文字のイベントであれば（Ｓ２００ＹＥＳ）、バッファ９へデータを送ってデータを一時的に格納する（Ｓ２０１）。イベント１が文字のイベントでなければ（Ｓ２００ＮＯ）、画像のイベントか否かを判定する（Ｓ２０２）。イベント１が画像のイベントであれば（Ｓ２０２ＹＥＳ）、バッファ１０へデータを送ってデータを一時的に格納する（Ｓ２０３）。イベント１が画像のイベントでもなければ（Ｓ２０２ＮＯ）、他の処理を行なう。
このようにして、イベント１のデータをバッファ７〜１０のいずれかへ振り分けた後、Ｑ＝Ｑ−ΔＴ１の演算を行ない（Ｓ１９７）、Ｓ１９３へ戻って次のイベント２のデルタ・タイムΔＴ２を読み取り、Ｑ≧ΔＴ２を判定する（Ｓ１９４）。このときのＱの値はＱ＝Ｑ−ΔＴ１であるが、第２１図ではＱ−ΔＴ１＞ΔＴ２であるから、Ｓ１９４の判定はＹＥＳとなり、上記の場合と同様にしてイベント２のデータの種類を判別して、対応するバッファへ振り分ける。
その後、Ｑ＝Ｑ−ΔＴ２の演算を行ない（Ｓ１９７）、Ｓ１９３へ戻って次のイベント３のデルタ・タイムΔＴ３を読み取り、Ｑ≧ΔＴ３を判定する（Ｓ１９４）。このときのＱの値はＱ＝Ｑ−ΔＴ１−ΔＴ２であるが、第２１図ではＱ−ΔＴ１−ΔＴ２＞ΔＴ３であるから、Ｓ１９４の判定はＹＥＳとなり、上記の場合と同様にしてイベント３のデータの種類を判別して、対応するバッファへ振り分ける。
その後、Ｑ＝Ｑ−ΔＴ３の演算を行ない（Ｓ１９７）、Ｓ１９３へ戻って次のイベント４のデルタ・タイムΔＴ４を読み取り（第２１図ではイベント４はｔ２より後に図示されているが、ｔ２の時点ではイベント４のデータはすでにバッファ３ａに入っていて読取りが可能となっている）、Ｑ≧ΔＴ４を判定する（Ｓ１９４）。このときのＱの値はＱ＝Ｑ−ΔＴ１−ΔＴ２−ΔＴ３であるが、第２１図ではＱ−ΔＴ１−ΔＴ２−ΔＴ３＜ΔＴ４であるから、Ｓ１９４の判定はＮＯとなり、ＣＰＵ２はイベント４のデータ処理は行なわずに、ＳＬＥＥＰ状態に移行して次のフレームでの処理まで待機する（Ｓ２０４）。そして、次のフレームの最初のタイミングでタイミング制御部２１からのクロック割込みがあると、ＷＡＫＥ状態となって（Ｓ１９１）、イベント４以下のデータについて上述した処理と同様の処理を行なう。
第２２図のフローチャートにおいて、Ｓ１９２〜Ｓ１９４、およびＳ１９７が第２０図のＳ１８２の詳細であり、Ｓ１９５，Ｓ１９６、Ｓ１９８〜Ｓ２０３が第２０図のＳ１８３の詳細である。
次に、各データ再生部１１〜１４における処理の詳細、すなわち第２０図のＳ１８４の詳細について説明する。第２３図は各データ再生部での処理手順を示すフローチャートで、（ａ）はＭＩＤＩ再生部１１における処理手順を表している。ＭＩＤＩ再生部１１では、データ振分部４によって振り分けられた１フレーム区間のデータがバッファ７に格納されると、このデータを次の１フレーム区間において読み込む（Ｓ２１１）。そして、読み込んだデータに記録されているＭＩＤＩイベント（第３図、第４図参照）の内容を解読して、ソフトウエア・シンセサイザによりシンセサイザ音を生成する（Ｓ２１２）。このシンセサイザの出力は、ＭＩＤＩ再生部１１の内部にある図示しないバッファに一時的に格納され、このバッファからミキサ１５へ出力される（Ｓ２１３）。
第２３図（ｂ）は、音声再生部１２における処理手順を示している。音声再生部１２では、データ振分部４によって振り分けられた１フレーム区間のデータがバッファ８に格納されると、このデータを次の１フレーム区間において読み込む（Ｓ３１１）。そして、読み込んだデータのイベントに記録されている音声データ（第５図（ｂ）、第７図（ｂ）参照）をデコードして、音声を再生する（Ｓ３１２）。この再生データは、音声再生部１２の内部にある図示しないバッファに一時的に格納され、このバッファからミキサ１５へ出力される（Ｓ３１３）。
第２３図（ｃ）は、文字再生部１３における処理手順を示している。文字再生部１３では、データ振分部４によって振り分けられた１フレーム区間のデータがバッファ９に格納されると、このデータを次の１フレーム区間において読み込む（Ｓ４１１）。そして、読み込んだデータのイベントに記録されている文字データ（第５図（ｃ）、第７図（ｃ）参照）をデコードして、文字を再生する（Ｓ４１２）。この再生データは、文字再生部１３の内部にある図示しないバッファに一時的に格納され、このバッファからミキサ１６へ出力される（Ｓ４１３）。
第２３図（ｄ）は、画像再生部１４における処理手順を示している。画像再生部１４では、データ振分部４によって振り分けられた１フレーム区間のデータがバッファ１０に格納されると、このデータを次の１フレーム区間において読み込む（Ｓ５１１）。そして、読み込んだデータのイベントに記録されている画像データ（第５図（ｄ）、第７図（ｄ）参照）をデコードして、画像を再生する（Ｓ５１２）。この再生データは、画像再生部１４の内部にある図示しないバッファに一時的に格納され、このバッファからミキサ１６へ出力される（Ｓ５１３）。
以上述べた第２３図（ａ）〜（ｄ）の各処理は、プログラムで定められた順序に従って行なわれ、ここでは（ａ）〜（ｄ）の順序で行なわれるものとする。すなわち、（ａ）のＭＩＤＩの処理をまず行ない、これが完了すれば（ｂ）の音声処理に移り、音声処理が完了すれば（ｃ）の文字処理に移り、文字処理が完了すれば（ｄ）の画像処理を行なう。なお、このように処理を直列的に行なうのは、記憶部５やデータ再生部６等を構成するＤＳＰが１個であるためであり、ＤＳＰを各再生部ごとに設けた場合には、処理を並列的に行なうことができる。
Ｓ２１３でミキサ１５へ出力されたＭＩＤＩの再生データと、Ｓ３１３でミキサ１５へ出力された音声の再生データとは、ミキサ１５で混合されて出力バッファ１７へ格納され、サウンドとしてスピーカ１９から出力される。また、Ｓ４１３でミキサ１６へ出力された文字の再生データと、Ｓ５１３でミキサ１６へ出力された画像の再生データとは、ミキサ１６で混合されて出力バッファ１８へ格納され、可視情報として表示器２０に表示される。出力バッファ１７およびスピーカ１９によって第１の出力部が構成され、出力バッファ１８および表示器２０によって第２の出力部が構成される。なお、出力バッファ１７はスピーカ１９へ出力するデータの個数を計数する機能を備えており、この計数値に基づいてタイミング制御部２１へ制御信号を送り、タイミング制御部２１はこの制御信号に基づいてＣＰＵ２にタイミング信号（システムクロック）を与える。すなわち、出力バッファ１７からデータ１個が出力するのに要する時間はサンプリング周波数により決まり、この時間をτとすると、Ｎ個のデータが出力するのに要する時間はＮ×τとなるから、Ｎの値によってタイミングを決定することができる。また、タイミング制御部２１は上記制御信号に従って出力バッファ１８にもタイミング信号を与え、出力バッファ１８から出力されるデータのタイミングをコントロールする。
第２４図は、以上述べたデータの振り分けから再生までの動作を全体的に表した図で、（ａ）は各再生部が処理するデータ量とフレーム区間との関係を表しており、（ｂ）は各再生部における処理時間とフレーム区間との関係を表したものである。Ｆ１〜Ｆ３は１フレーム区間であり、各フレーム区間の時間幅は、たとえば１５ｍｓに設定されている。すなわち、データ振分部４には、１５ｍｓごとにタイミング制御部２１からクロックの割り込みがかかるようになっている。ｔは時間軸を示し、ＭはＭＩＤＩのイベント、Ａは音声のイベント、Ｔは文字のイベント、Ｐは画像のイベントの再生タイミングを表している。なお、これらの再生タイミングは、第２１図と同様に、受信データをデルタ・タイムに従って再生したと仮定した場合のタイミングを示すものであって、時間軸ｔ上で実際に再生されたタイミングを示すものではない。
第２１図で説明したように、区間Ｆ１で処理される全てのデータは、当該区間の最後のタイミングにおいてバッファ７〜１０へ振り分けられ、格納される。そして、各再生部１１〜１４は次の１フレーム区間Ｆ２でバッファからデータを読み出して再生処理を行なう。この場合、各バッファから各再生部へ転送されるデータの量は、各再生部が１フレーム区間で処理できる量のデータであり、第２４図（ａ）に示すように、各再生部は次の１フレーム区間Ｆ２内で、データをすべて処理できるようになっている。
この処理のタイムチャートが第２４図（ｂ）であって、白矢印の長さが処理時間を表している。この処理時間は、各フレームごとに異なる。前述のように、バッファに格納されたデータは次の１フレーム区間Ｆ２において、あらかじめ決められた順序で各再生部１１〜１４により順番に読み出され、各再生部においてデータに記録されたイベントが実行されてデータの再生が行なわれる。第２４図（ｂ）では、Ｍ（ＭＩＤＩ）、Ａ（音声）、Ｐ（画像）がこの順序で再生処理される。再生されたＭとＡはミキサ１（第１９図のミキサ１５）にて処理され、再生されたＰはミキサ２（第１９図のミキサ１６）で処理される。このようにして、Ｆ１区間で振り分けられたデータはＦ２区間においてすべて処理が完結され、余った時間は次のＦ３区間での処理が開始されるまでの待機時間となる。図のＳＬＥＥＰがこれを表している。そして、ミキサ１からの出力は、出力バッファ１（第１９図の出力バッファ１７）に格納された後、次のフレーム区間Ｆ３においてサウンドとして出力され、また、ミキサ２からの出力は、出力バッファ２（第１９図の出力バッファ１８）に格納された後、フレーム区間Ｆ３において可視情報として出力される。
同様にして、Ｆ２区間ではＡ，Ｍ，Ｔのデータがバッファに振り分けられ、これらのデータはＦ３区間においてＭ，Ａ，Ｔの順序で読み出されて、各再生部において上記と同じ要領で再生処理され、次のＦ４区間（第２４図では図示されない）において出力される。
以上のようにして、第１９図のデータ再生装置においては、受信したデータをフレームごとに振り分けてバッファに格納し、次のフレームでバッファから読み出してデータを再生し、さらにその次のフレームでサウンドや可視情報として出力している。したがって、フレーム単位でデータの時間同期をとりながら再生を行なうことができる。
また、データ振分部４は受信データをバッファ７〜１０に振り分ける作業に専念し、各再生部１１〜１４はバッファに格納されたデータを読み出して再生することに専念するため、データ受信部３が受信したデータをパイプライン化して、高速に処理することが可能となる。
なお、データの再生にあたっては、本来はデルタ・タイムに従って再生のタイミングが管理されるべきであるが、第１９図の装置では、データ振分部４によってデータがバッファ７〜１０に振り分けられた後はデータが離散するため、個々のデルタ・タイムは再生タイミングを決定する上で実質的に意味を持たなくなる。しかし、１フレーム区間は前述のように１５ｍｓというごく短い時間であるから、この間に再生されたデータは、各データの再生タイミングにかかわらず、同時に再生されたものとみなして差し支えない。実際、１５ｍｓ程度の区間内におけるデータの再生タイミングのずれは、通常の人間の感覚では識別できないことが経験的に確かめられている。したがって、データを振り分ける時点において、デルタ・タイムに基づいて１フレーム区間で処理すべきデータさえ決定しておけば、１フレーム区間内でそれらのデータの再生タイミングがデルタ・タイムに従う再生タイミングからずれていても問題はない。
さらに、同一フレーム区間内において、異種のデータの再生順序が入れ替わっても差し支えない。たとえば、第２４図（ｂ）のＦ１区間では受信したデータの順序Ｍ，Ａ，Ｐに従って各再生部がバッファからデータを読み出しているが、Ｆ２区間では、受信したデータの順序がＡ，Ｍ，Ｔであるにもかかわらず、再生部がバッファからデータを読み出す順序はＭ，Ａ，Ｔとなり、ＡとＭが入れ替わる。これは、前述のように、各再生部での処理順序がプログラムによってＭ，Ａ，Ｔ，Ｐと定められているからである。しかし、このように処理順序が入れ替わっても、１５ｍｓ以内に各再生部がデータ処理を行なっていれば、上述したようにデータの再生タイミングは人間の感覚ではわからないため問題はない。
また、第２４図では１フレーム区間で振り分けられたデータを、次の１フレーム区間ですべて処理するようにしているが、これは必ずしも必須のことではない。すなわち、出力バッファ１７，１８が１フレーム区間での処理量を超えるサイズを有しておれば、１フレーム内で処理できなかったデータがあったとしても、出力バッファ１７，１８には先に処理されたデータが残っているので、データを途切れることなく出力することができる。
第２５図は、第１９図のデータ再生装置において、データをダウンロードしながら再生を行うストリーム方式を採用した場合のデータ受信部３の動作を説明する図である。ここでは、バッファ３ａがバッファＡ、バッファＢ、バッファＣの３つのバッファから構成されている。３ｂは各バッファＡ，Ｂ，Ｃに対応して設けられたレジスタＡ，Ｂ，Ｃである。受信されるデータはストリームデータＳとして示されている。ストリームデータＳの先頭にはヘッダＨが記録されており、これに続いてＭＩＤＩ、音声、文字、画像の各データがパケットＰ１，Ｐ２，Ｐ３，…Ｐｍとして混在して記録されている。このストリームデータＳの全データ量をＫとする。
以下、音楽を再生する場合を例にとって受信動作を説明する。サーバへのアクセスによりデータ受信部３がファイル１ａからストリームデータＳの受信を開始すると、まず、ストリームデータＳの先頭からバッファＡのサイズ（容量）に相当する分のデータＡ１がバッファＡに格納される。これによってバッファＡはフル状態となり、レジスタＡにはバッファＡがフル状態であることを示すフラグがセットされる。続いて、バッファＢのサイズに相当する分のデータＢ１がバッファＢに格納される。これによってバッファＢもフル状態となり、レジスタＢにはバッファＢがフル状態であることを示すフラグがセットされる。
バッファＢがフルになった時点で、データ振分部４はデータの振分けを開始し、バッファＡに格納されたデータＡ１とバッファＢに格納されたデータＢ１をデータの種類別にバッファ７〜１０へ転送する。転送されたデータは各再生部１１〜１４で再生され、曲の演奏が開始される。一方、バッファＣにはそのサイズに相当する分のデータＣ１が格納される。これによってバッファＣはフル状態となり、レジスタＣにはバッファＣがフル状態であることを示すフラグがセットされる。
バッファＣにデータＣ１が格納されている間に、バッファＡのデータＡ１が消費されてバッファＡが空になると、レジスタＡのフラグがリセットされ、データ受信部３は次のデータＡ２を取得してバッファＡに格納する。これによって、バッファＡは再びフル状態となり、レジスタＡにフラグがセットされる。また、バッファＢのデータＢ１が消費されてバッファＢが空になると、レジスタＢのフラグがリセットされ、データ受信部３は次のデータＢ２（第２５図では図示されない）を取得してバッファＢに格納する。これによって、バッファＢは再びフル状態となり、レジスタＢにフラグがセットされる。以上のような動作を繰り返すことによって、ストリームデータＳの再生が進行する。第２６図はこの場合のデータの流れを示した図である。
上述したストリーム方式においては、データＡ１が受信された時点から再生をスタートすることも可能である。しかしながら、バッファに取り込まれるデータの転送容量が十分でない場合は、再生開始後にバッファへのデータ補給が消費に追いつかず、音が途切れるという現象が発生する。そこで、これを回避するには、バッファにデータをキャッシュして、ある程度データが貯まった時点から再生をスタートする必要がある。これを第２７図の例で説明する。
第２７図において、バッファＡ，Ｂ，Ｃのサイズをそれぞれ５０Ｋｂｉｔとし、バッファにデータを取り込むのに要した時間を５秒とすると、１秒あたりのデータの転送容量は５０／５＝１０Ｋｂｐｓとなる。また、曲の演奏時間を１０秒、全データ量を２００Ｋｂｉｔとすると、曲の演奏によって消費されるデータの量は、１秒間あたり２００／１０＝２０Ｋｂｐｓとなる。したがって、データが受信された時点ｔ０から再生を開始したのでは、消費されるデータ量がバッファに取り込まれるデータ量を上回るため、バッファのデータが不足して音が途切れることになる。
この問題は次のようにして解決される。すなわち、データの受信時点ｔ０から５秒間でバッファＡに５０ＫｂｉｔのデータＡ１を格納し、続く５秒間でバッファＢに５０ＫｂｉｔのデータＢ１を格納し、１０秒間で合計１００Ｋｂｉｔのデータをキャッシュしておく。そして、データの受信時点ｔ０から１０秒経過したｔ１の時点から再生を開始する。このようにすると、再生開始以降のデータ転送容量がデータ消費量より小さくても、バッファＡ，Ｂに既に１００Ｋｂｉｔのデータが貯まっており、また、演奏開始時点ｔ１から演奏終了時点ｔ２までの１０秒間に残りの１００Ｋｂｉｔのデータ（Ｃ１とＡ２の合計）をバッファＣ，Ａに取り込むことができるため、データが途絶えることがなくなり、曲を最後まで連続して再生することができる。
これに対して、バッファに取り込まれるデータ量が消費されるデータ量を上回る場合には、上記のようなデータのキャッシュは不要であるが、バッファがフル状態になった時点で、それ以上のデータを送信しないようにデータ受信部３からサーバに対して指示を与える必要がある。この場合は、バッファのデータが消費されてバッファに空きが生じた時点で、データ受信部３はサーバからデータを取得することになる。
以上のことを一般化して記述すると次のようになる。バッファのサイズをＵ、バッファにデータを取り込むのに要した時間をｔとすると、単位時間あたりのデータ転送容量Ｊは、Ｊ＝Ｕ／ｔで与えられる。また、全データ量をＫ、再生時間をＴとすると、単位時間あたりのデータ消費量Ｅは、Ｅ＝Ｋ／Ｔで与えられる。第２５図においては、全データ量Ｋおよび演奏時間ＴはヘッダＨに記録されており、データ受信部３はヘッダＨを読み取ってデータ消費量Ｅを計算する。また、バッファＡにデータＡ１が取り込まれた時点で、データ転送容量Ｊを計算する。その結果、Ｊ＜Ｅであればデータのキャッシュが必要と判断して、必要な量のデータをキャッシュする。この場合、データのキャッシュ量をＣとして
Ｋ＜Ｃ＋Ｊ・Ｔ
の条件を満たすようにデータをキャッシュすれば、データを途切れることなく再生することができる。データをキャッシュするために、データ受信部３はサーバからデータＢ１を取得してバッファＢに格納する。この時点で上記条件が満たされると、データ受信部３はデータ振分部４にｒｅａｄｙ信号を送り、これを受けてデータ振分部４はバッファＡ，Ｂのデータの振分けを開始する。以後の動作はすでに述べたとおりである。
一方、Ｊ＞Ｅであればデータのキャッシュは不要であるため、データＡ１を受信した時点からデータ振分部４はデータの振分けを開始する。しかし、再生開始後にバッファがすぐにフル状態となるため、バッファがフル状態になった時点で、データ受信部３はサーバに対してデータ送信の停止を要求する。そして、データが消費されてバッファに空きができると、データ受信部３は再びサーバに対してデータの送信を要求する。すなわち、データ受信部３はサーバから間歇的にデータを取得することになる。
以上のようにして、データ受信部３はデータ転送容量Ｊを監視し、Ｊ＜Ｅであればデータを必要量だけキャッシュした後に再生を開始し、Ｊ＞Ｅであればデータのキャッシュは行なわずに間歇的にデータを受信しながら再生を行なう。これによって、伝送路の容量の変動にかかわらず、安定してデータを再生することができる。なお、Ｊ＝Ｅの場合は、データのキャッシュは不要であり、サーバからデータを連続して受信する。
ここで、伝送路の容量が何らかの原因によって突然減少すると、バッファへのデータキャッシュが間に合わず、バッファＡ，Ｂ，Ｃがすべて空状態になることがある。この場合は、データ振分部４からＭＩＤＩ再生部１１と音声再生部１２へミュート信号を送って、雑音が出力されるのを禁止することにより、ユーザに与える不快感をなくすことができる。また、データ振分部４から文字再生部１３と画像再生部１４へは前置保持信号を送って、直前の画面の表示が維持されるようにするとよい。また、これらに代えて、各再生部１１〜１４がデータの終了を表す信号を受け取っていないにもかかわらずデータ振分部４からデータが来ない場合には、各再生部１１〜１４において自動的にミュートや前置保持の処理を行い、データが来れば再生を再開するという方法を採用することもできる。
上記説明においては、バッファ３ａとして独立した３つのバッファＡ，Ｂ，Ｃを設けたが、これは単なる一例に過ぎず、バッファの数は任意に選定することができる。また、独立したバッファに代えてリングバッファなどを用いてもよい。
次に、本発明の応用例について説明する。第１９図のデータ再生装置は、電話機の機能を備えた情報端末機に搭載することができる。これによると、音、文字、画像などの各種情報をダウンロードし、これらを再生してスピーカからサウンドを流したり画面に文字や画像を表示することのできる携帯電話機が実現できる。たとえば、インターネットによって提供されるＣＭ（コマーシャル）や、カラオケなどの音楽・映像等を携帯電話機で視聴することが可能となる。このような携帯電話機の例が第３７図に示されている。
第３７図において、５０は情報端末機としての携帯電話機、５１は電話機の本体であって、本体５１にはアンテナ５２、表示器５３、数値キー５４等の各種キー、スピーカ５５、マイクロフォン５６が設けられている。この携帯電話機５０は、第３９図に示したように、基地局７３との間で通信を行ない、サーバ７２に蓄積されたデータを基地局７３を介してダウンロードするようになっている。
アンテナ５２は基地局７３との間で信号の送受信を行うものである。表示器５３はカラー液晶ディスプレイ等から構成されており、電話番号や映像などが表示される。発音部であるスピーカ５５からは通話相手の音声やメロディが聞こえるようになっている。マイクロフォン５６は、通話時や留守番案内メッセージの作成時に音声を入力するためのものである。
５４は０〜９の数字からなる数字キーで、電話番号や短縮番号の入力などに用いられる。５７は電話機の電源をオンオフする電源キー、５８は通話を開始するときに操作する通話キー、５９は表示器５３に表示される内容をスクロールするスクロールキーである。６０は他のキーとの組合せ操作により各種の機能を達成するファンクションキー、６１は登録されている内容を呼び出して表示器５３に表示させるための呼出しキー、６２は短縮ダイヤル番号等の登録を行う際に操作する登録キーである。６３は表示内容などを消去するためのクリアキー、６４は所定の動作を実行させる際に操作する実行キーである。６５はサーバ７２から音楽データをダウンロードするにあたって、新曲のリストを表示させるための新曲表示キー、６６は留守番案内メッセージを作成する際に操作する留守録キー、６７はカラオケを演奏する際に操作するカラオケキー、６８は曲の演奏をスタートさせる演奏開始キー、６９は曲の演奏を終了させる演奏終了キーである。
また、７０はカードやスティック等の形状をした小型の情報記憶媒体であって、電話機本体５１に設けられたスロット（図示省略）に着脱可能となっている。この情報記憶媒体７０の内部には、記憶素子であるフラッシュメモリ７１が内蔵されており、このメモリ７１にダウンロードした各種データが記憶される。
以上の構成において、表示器５３は第１９図の表示器２０に相当し、ここには文字や画像が表示される。たとえば、ＣＭの場合には文字、イラスト、写真、動画などが表示され、カラオケの場合には、タイトル、歌詞、背景映像などが表示される。また、スピーカ５５は第１９図のスピーカ１９に相当し、ここからはＭＩＤＩや音声によるサウンドが出力される。たとえば、ＣＭの場合にはＣＭソングや商品案内メッセージなどが流れ、カラオケの場合には伴奏曲やバックコーラスなどが流れる。このようにして、第１９図のデータ再生装置を携帯電話機５０に搭載することにより、携帯電話機５０をたとえばカラオケ装置として利用することができる。
また、携帯電話機５０にサーバ７２からＭＩＤＩのデータだけをダウンロードすることもできる。この場合、ＭＩＤＩにより生成されたメロディを着信音としてスピーカ５５より出力するようにすれば、着信音はきわめてリアルで洗練された音楽となる。また、携帯電話機５０の内部メモリ（図示省略）に、着信信号に対応させて異なる音楽のＭＩＤＩデータを記憶しておき、着信信号に応じて異なるメロディで報知するようにすれば、誰からの電話かを容易に識別することができる。また、携帯電話機５０に内蔵された着信報知用のバイブレータ（図示省略）をＭＩＤＩデータに基づいて振動させ、たとえばドラムのリズムと同じリズムでバイブレータを振動させるようにしてもよい。さらに、留守番案内メッセージにＭＩＤＩによるＢＧＭ（バック・グランド・ミュージック）を付加するような使い方もできる。
情報記憶媒体７０は第１９図の外部記憶装置２２に相当するもので、フラッシュメモリ７１に、音楽データや映像のデータを記憶して保存することができる。たとえばＣＤ（Compact Disk）の音楽データをダウンロードする場合、第３８図に示したように、ＭＩＤＩまたは音声による音楽データや、文字による歌詞および曲目解説等のデータに加えて、画像によるＣＤジャケットの写真データもあわせて記録することにより、情報記憶媒体７０それ自体をＣＤ化することができる。ＭＤ（Mini Disk）の場合も同様のことがあてはまる。
上記のようなデータ再生装置を搭載した携帯電話機５０においては、たとえばＣＭを視聴している間に着信があった場合に、着信音を優先させて出力させるのが望ましい。第２８図はこれを実現するための第２実施形態に係るデータ再生装置の構成を示している。第２８図の装置も携帯電話機５０に搭載されるもので、第１９図と同一部分には同一符号を付してある。第２８図において第１９図と相違する点は、着信信号用のバッファ２３が設けられていることと、バッファ７とＭＩＤＩ再生部１１との間に切替部２４が設けられていることである。
第２９図は、第２８図のデータ再生装置の動作を示すタイムチャートである。最初、スピーカ１９から（ｃ）のようにＣＭ音楽が流れており、また表示器２０に（ｄ）のようにＣＭ画像が表示されているとする。いま、データ受信部３に（ａ）のような着信信号が割込信号として入力されると、データ受信部３は着信信号のデータをバッファ２３へ格納するとともに、切替部２４をバッファ７からバッファ２３側に切り替える。これによって、バッファ７のデータに代えてバッファ２３のデータがＭＩＤＩ再生部１１へ入力され、ＭＩＤＩ再生部１１ではバッファ２３のデータを読み込んでソフトウエア・シンセサイザにより着信音を生成し、これをミキサ１５および出力バッファ１７を介してスピーカ１９へ出力する。その結果、スピーカ１９からは（ｂ）のようにＣＭ音楽に代わってＭＩＤＩの着信音が出力される。そして、着信が終了して着信音が停止すると、スピーカ１９からは（ｃ）のように再びＣＭ音楽が流れる。なお、ＣＭ画像は（ｄ）のように、着信音の有無にかかわらず継続して表示器２０に表示される。このようにして、第２８図のデータ再生装置によれば、着信があったときに着信音が優先されて出力されることになり、視聴者に着信を確実に知らせることができる。また、着信音の生成にあたってＭＩＤＩ再生部１１のソフトウエア・シンセサイザを共用できるので、処理が簡略化される。
本発明のデータ再生装置は、電話機の機能を備えた情報端末機のほかにも、たとえばゲーム機の機能を備えた情報端末機に搭載することができる。ゲーム機としては、ゲーム専用機であってもよいし、ゲームと他の機能とを併有する装置であってもよい。たとえば、第３７図に示した携帯電話機５０にゲームのソフトウエアを組み込んだものであってもよい。
このようなゲーム機において、通常、ゲームの進行中にはバックに音楽が流れているが、画面の状況に合わせてＭＩＤＩによる効果音をバック音楽に重ねて鳴らすようにすれば、趣向に富んだゲーム展開となる。第３０図はこれを実現するための第３実施形態に係るデータ再生装置の構成であって、第１９図と同一部分には同一符号を付してある。第３０図において第１９図と相違する点は、効果音信号用のバッファ２５が設けられていることと、バッファ７とＭＩＤＩ再生部１１との間にミキサ２６が設けられていることである。
第３１図は、第３０図の装置の動作を示すタイムチャートである。最初、スピーカ１９から（ｃ）のようにバック音楽が流れており、また表示器２０に（ｄ）のようにゲーム画像が表示されているとする。いま、ゲーム機の特定のボタンを操作することによって、データ受信部３に（ａ）のような効果音信号が割込信号として入力されたとすると、データ受信部３は効果音信号のデータをバッファ２５へ格納する。このバッファ２５の効果音データは、ミキサ２６においてバッファ７のデータと混合される。ＭＩＤＩ再生部１１は、ミキサ２６のデータを読み込んで、ソフトウエア・シンセサイザによりバック音楽に加えて効果音を生成し、これらをミキサ１５および出力バッファ１７を介してスピーカ１９へ出力する。その結果、スピーカ１９からは（ｂ）のようにＭＩＤＩによる効果音（たとえば爆発音）が出力される。この効果音が鳴っている間も、バック音楽は（ｃ）のように継続して流れている。そして、効果音信号が終了するとスピーカ１９からの効果音は停止し、バック音楽のみが流れる。なお、ゲーム画像は（ｄ）のように、継続して表示器２０に表示される。このようにして、第３０図のデータ再生装置によれば、バック音楽の上にＭＩＤＩによる効果音を重ねて鳴らすことのできるゲーム機が実現できる。また、効果音の生成にあたってＭＩＤＩ再生部１１のソフトウエア・シンセサイザを共用できるので、処理が簡略化される。
本発明のデータ再生装置を用いると、以上のほかにも種々の機能をもつシステムが実現できる。第３２図ないし第３４図はその一例であって、インターネットにおいて特定のＣＭを視聴した者に対して一定の特典を付与する例を示している。ＣＭ情報には、第３３図のようにＭＩＤＩ、音声、文字、画像の各データが時系列的に混在している。そこで、文字データの最後の部分（破線Ｚ）に、第３４図に示したようなＵＲＬ（Uniform Resource Locator）を記述したタグを入れておく。このタグにおいて、最後の「ＸＸＸ」は、何のＣＭかを表す情報である。
第３２図のフローチャートに従って説明すると、視聴者はまずインターネット上のサーバにあるファイル１ａ（第１９図参照）から、ＣＭデータをダウンロードする（Ｓ６０１）。このＣＭデータはデータ受信部３で受信され、データ振分部４により各部へ振り分けられ、前述した手順で再生されてスピーカ１９および表示器２０から出力される。ここで、受信した文字データを文字再生部１３において最後まで再生すると、第３４図に示したタグが読み取られる（Ｓ６０２）。
続いて、ブラウザ（閲覧ソフトウエア）が起動され（Ｓ６０３）、読み取ったタグに記述されているＵＲＬのホームページへジャンプする（Ｓ６０４）。ジャンプ先のサーバ（図示省略）では、タグの「ＸＸＸ」の部分を解釈して、何のＣＭを視聴したのかを判別し（Ｓ６０５）、ネット上で当該ＣＭの商品の購入があった場合に、たとえば２０％割り引いた額で課金するといった処理を行なう（Ｓ６０６）。したがって、上記システムによると、ＣＭを視聴した者に対して割引サービスを付与することができる。
第３５図および第３６図は、本発明のデータ再生装置を用いた他の応用例であって、インターネットにおいて音楽データを購入した者に対して、チケットの割引サービスを提供する例を示している。この場合、音楽データには、歌詞や曲の解説あるいは演奏者の紹介などが文字データとして付加されており、文字データの最後の部分に第３６図に示したようなタグを入れておく。このタグにおいて、「ｆｒｏｍ＝２０００／０８／１５  ｔｏ＝２０００／０９／１５」は、チケットの有効期限が西暦２０００年８月１５日から西暦２０００年９月１５日までであることを表している。また、最後の「ＹＹＹ」は購入した音楽データが何かをあらわす情報である。
第３５図のフローチャートに従って説明すると、視聴者はまずインターネット上のサーバにあるファイル１ａから、音楽データをダウンロードする（Ｓ７０１）。この音楽データはデータ受信部３で受信され、データ振分部４により各部へ振り分けられ、前述した手順で再生されてスピーカ１９および表示器２０から出力される。また、各データは外部記憶装置２２（第３７図では情報記憶媒体７０）へ格納され保存される。ここで、受信した文字データを文字再生部１３において最後まで再生すると、第３６図に示したタグが読み取られる（Ｓ７０２）。
続いて、ブラウザが起動され（Ｓ７０３）、現在の日付が有効期限内か否かが判定される（Ｓ７０４）。この判定は、前述したタグに記述されている有効期限を参照することにより行なう。有効期限内であれば（Ｓ７０４ＹＥＳ）、読み取ったタグに記述されているＵＲＬのホームページへジャンプし（Ｓ７０５）、有効期限内でなければ（Ｓ７０４ＮＯ）、何もせずに終了する（Ｓ７０８）。
ジャンプ先のサーバ（図示省略）では、タグの「ＹＹＹ」の部分を解釈して、何の音楽データを購入したのかを判別し（Ｓ７０６）、その音楽アーティストのコンサートのチケットを割引価格で購入できる旨の案内メッセージを送信し、表示器２０にそのメッセージが表示される（Ｓ７０７）。したがって、上記システムによると、音楽データを購入した者に対して、チケットの購入を誘導することが可能となる。
[産業上の利用分野]
本発明のデータ再生装置は、前述した携帯電話機やゲーム機のほか、パーソナル・コンピュータやインターネットテレビ用のＳＴＢ（Set Top Box）など、各種の情報端末機に搭載することができる。
【図面の簡単な説明】
第１図は、本発明の前提となるデータ再生装置の例を示すブロック図である。
第２図は、ＳＭＦ形式の受信データのフォーマットを示す図である。
第３図は、ＭＩＤＩに関するデータのフォーマット例である。
第４図は、簡易型のＭＩＤＩに関するデータのフォーマット例である。
第５図は、音声、文字、画像に関するデータのフォーマット例である。
第６図は、制御に関するＭＥＴＡイベントのフォーマット例である。
第７図は、音声、文字、画像に関するデータの他のフォーマット例である。
第８図は、データ列のフォーマット例である。
第９図は、データ再生方法の例を示すフローチャートである。
第１０図は、データ再生方法の他の例を示すフローチャートである。
第１１図は、データの反復再生処理を説明する図である。
第１２図は、反復再生処理のフローチャートである。
第１３図は、データの先送りの原理を示す図である。
第１４図は、分割データの挿入例を示す図である。
第１５図は、分割データを格納したメモリの内容を示す図である。
第１６図は、分割データをメモリに格納する場合のフローチャートである。
第１７図は、無音区間を有する音声データの波形図である。
第１８図は、無音区間の処理を示すフローチャートである。
第１９図は、本発明のデータ再生装置の第１実施形態を示すブロック図である。
第２０図は、本発明のデータ再生方法の例を示すフローチャートである。
第２１図は、データ振分けにおける時間演算の原理を説明する図である。
第２２図は、データ振分けの手順を示すフローチャートである。
第２３図は、各データ再生部の動作を示すフローチャートである。
第２４図は、データ処理の全体のタイムチャートである。
第２５図は、ストリーム方式におけるデータ受信の動作を説明する図である。
第２６図は、データ受信のタイムチャートである。
第２７図は、データのキャッシュを説明するタイムチャートである。
第２８図は、本発明のデータ再生装置の第２実施形態を示すブロック図である。
第２９図は、第２８図の装置の動作を示すタイムチャートである。
第３０図は、本発明のデータ再生装置の第３実施形態を示すブロック図である。
第３１図は、第３０図の装置の動作を示すタイムチャートである。
第３２図は、本発明のデータ再生装置を用いて課金割引処理を行なう場合のフローチャートである。
第３３図は、ＣＭを構成する各データを時系列的に示した図である。
第３４図は、文字データに付加されるタグの例である。
第３５図は、本発明のデータ再生装置を用いて有効期限付きのサービスを行なう場合のフローチャートである。
第３６図は、文字データに付加されるタグの例である。
第３７図は、本発明のデータ再生装置を搭載した携帯電話機を示す図である。
第３８図は、情報記憶媒体に内蔵されたメモリのテーブル図である。
第３９図は、携帯電話機を用いたシステムを示す図である。
【図１】
0004236024.tif 000002
【図２】
0004236024.tif 000003
【図３】
0004236024.tif 000004
【図４】
0004236024.tif 000005
【図５】
0004236024.tif 000006
【図６】
0004236024.tif 000007
【図７】
0004236024.tif 000008
【図８】
0004236024.tif 000009
【図９】
0004236024.tif 000010
【図１０】
0004236024.tif 000011
【図１１】
0004236024.tif 000012
【図１２】
0004236024.tif 000013
【図１３】
0004236024.tif 000014
【図１４】
0004236024.tif 000015
【図１５】
0004236024.tif 000016
【図１６】
0004236024.tif 000017
【図１７】
0004236024.tif 000018
【図１８】
0004236024.tif 000019
【図１９】
0004236024.tif 000020
【図２０】
0004236024.tif 000021
【図２１】
0004236024.tif 000022
【図２２】
0004236024.tif 000023
【図２３】
0004236024.tif 000024
【図２４】
0004236024.tif 000025
【図２５】
0004236024.tif 000026
【図２６】
0004236024.tif 000027
【図２７】
0004236024.tif 000028
【図２８】
0004236024.tif 000029
【図２９】
0004236024.tif 000030
【図３０】
0004236024.tif 000031
【図３１】
0004236024.tif 000032
【図３２】
0004236024.tif 000033
【図３３】
0004236024.tif 000034
【図３４】
0004236024.tif 000035
【図３５】
0004236024.tif 000036
【図３６】
0004236024.tif 000037
【図３７】
0004236024.tif 000038
【図３８】
0004236024.tif 000039
【図３９】
0004236024.tif 000040