楽曲データおよび端末装置
【課題】 小さなデータサイズで、高品質の音声を記憶、配信可能な楽曲データを再生する楽曲再生システムを提供する。
【解決手段】 本発明は、楽曲を再生する機能およびネットワークに接続する機能を有する端末装置に、楽曲の再生を指示する楽曲データであって、データ内の所定の位置に、楽曲の少なくとも一部分に対応する楽曲素片データの前記ネットワーク内の所在を示す所在情報が記載された構造を有し、前記所在情報を読み込んだ端末装置に、前記所在情報により示される所在より前記楽曲素片データを取得させることを特徴とする楽曲データを提供する。
【解決手段】 本発明は、楽曲を再生する機能およびネットワークに接続する機能を有する端末装置に、楽曲の再生を指示する楽曲データであって、データ内の所定の位置に、楽曲の少なくとも一部分に対応する楽曲素片データの前記ネットワーク内の所在を示す所在情報が記載された構造を有し、前記所在情報を読み込んだ端末装置に、前記所在情報により示される所在より前記楽曲素片データを取得させることを特徴とする楽曲データを提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末装置において楽曲データから楽曲を再生する技術に関する。
【背景技術】
【０００２】
携帯電話機等の携帯端末において、発音用シーケンスデータあるいはＡＤＰＣＭ（Adaptive Differential Pulse Code Modulation）データのような発音データ等、様々なデータ形式（フォーマット）の発音データを再生する技術が開発されている（例えば、特許文献１参照）。このようなデータ形式で記述された楽曲データを携帯電話機等の携帯端末にあらかじめ記憶、あるいは楽曲データ配信サーバ等に通信回線を介して楽曲データをダウンロードして記憶するようにして、これを用いて、携帯電話機等の携帯端末に、いわゆる着信メロディ等の楽曲を再生させることができる。
【特許文献１】特開２００２−０９９５４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで上述の形式の発音データを携帯端末で再生させようとする際には、携帯端末にあらかじめ再生させようとする発音データが記憶されている必要がある。ここで、この発音データのデータサイズが大きい場合には大きいサイズのままで記憶あるいはダウンロードされることになる。したがって、メモリの記憶容量やデータ通信の転送速度等のリソースが乏しい携帯端末においては、このような発音データは多くのリソースを消費し、場合によってはリソースが不足してしまうという問題があった。また、このようにリソースが制限された環境においては、転送できるデータサイズに制限があるため高品質の楽曲を再生させることは難しく、着信メロディ等のコンテンツ提供者が、再生される楽曲の高品質化を望むユーザの要求に応えられないという問題もあった。
本発明は上述の事情に鑑みてなされたものであり、小さなデータサイズで、高品質の楽曲を記憶、配信可能な楽曲データを再生する楽曲再生システムを提供することを目的とする。
【課題を解決するための手段】
【０００４】
上述の課題を解決するため、本発明は、楽曲を再生する機能およびネットワークに接続する機能を有する端末装置に、楽曲の再生を指示する楽曲データであって、データ内の所定の位置に、楽曲の少なくとも一部分に対応する楽曲素片データの前記ネットワーク内の所在を示す所在情報が記載された構造を有する楽曲データを提供する。
好ましい態様において、前記楽曲データは複数チャンネルからなる構造を有し、前記データ内の所定の位置は、前記楽曲素片を再生すべきチャンネルと再生すべき時間に対応した位置である。
別の好ましい態様において、前記所在情報は、再生すべき楽曲素片を記憶するサーバのサーバ名とその楽曲素片のファイル名とを含む。
【０００５】
また、本発明は、上記の楽曲データを記憶する第１の記憶手段と、前記所在情報により示される楽曲素片データの少なくとも１部分を、前記ネットワークを介して取得する通信手段と、前記通信手段により取得した楽曲素片データを記憶する第２の記憶手段と、前記第１の記憶手段に記憶されている楽曲データおよび前記第２の記憶手段に記憶されている楽曲素片データに従って楽曲を再生する楽曲再生手段とを有する端末装置を提供する。
好ましい態様において、この端末装置は、前記第２の記憶手段の空き容量を監視する監視手段と、前記監視手段により監視される空き容量があらかじめ決められた条件を満足したときに前記楽曲素片データの取得を指示するダウンロード要求を生成するダウンロード要求生成手段とをさらに有する。
別の好ましい態様において、前記通信手段は、前記楽曲データを送信または受信する機能を有する。
以上の態様において、前記端末装置は携帯可能な端末装置であってもよい。
【発明の効果】
【０００６】
本発明によれば、楽曲の一部分の楽曲素片データがネットワークを介して取得されるので、記憶容量の限られた端末においても高品質の楽曲（音声）を再生することが可能となる。
【発明を実施するための最良の形態】
【０００７】
以下、図面を参照して本発明の一実施形態について説明する。
＜１．構成＞
図１は、本実施形態に係る楽曲配信システム１の構成を示すブロック図である。配信サーバ１０は、ｍｐ３データ等のストリームオーディオデータを記録したデータベースＤＢ１を有する。配信サーバ１０はインターネット等のネットワーク７０を介して他の機器と通信可能である。配信サーバ２０はデータベースＤＢ２を有し、配信サーバ１０と同様の機能を有する。携帯電話機、ＰＤＡ（Personal Digital Assistance）等の携帯端末５０は、基地局３０、基地局４０およびネットワーク７０を介して他の機器と通信可能である。すなわち、携帯端末５０は、基地局３０（あるいは基地局４０）およびネットワーク７０を介して配信サーバ１０あるいは配信サーバ２０と通信することができる。携帯端末６０も携帯端末５０と同様の機能を有する。
【０００８】
図２は、携帯端末５０のハードウェア構成を示すブロック図である。ＣＰＵ（Central Processing Unit）５１は、ＲＡＭ（Random Access Memory）５５を作業エリアとして、ＲＯＭ（Read Only Memory）５２に記憶されているプログラムを読み出して実行する。ＣＰＵ５１はまた、携帯端末５０の各構成要素を制御する機能を有する。本実施形態に係る携帯端末５０は携帯電話機であって、マイクから集音された音声を音声処理部５４によってアナログ／デジタル変換し、デジタル変換された音声データを通信部５３を介して無線送信する機能を有する。また、携帯端末５０はネットワーク７０を介して送信された音声データを通信部５３により受信する。受信された音声データは音声処理部５４によりデジタル／アナログ変換され、スピーカから音声として出力される。さらに、携帯端末５０は、音声データだけでなく、ｍｐ３データ等のストリームオーディオデータや、ＳＭＦ（Standard MIDI File）あるいはＳＭＡＦ（Synthetic music Mobile Application Format）等の演奏制御データや、電子メールメッセージや、アプリケーションソフトウェア等のデータ（コンテンツ）を通信部５３を介して通信することができる。これらのデータはＲＡＭ５５に保存される。
【０００９】
表示部５６はＬＣＤ（Liquid Crystal Display）等の表示装置を有し、ＣＰＵ５１の制御下で文字や画像を表示する。携帯端末５０の使用者は、表示部５６に表示された文字や画像を見ながら、テンキーや十字キー等からなる入力部５７を操作することにより携帯端末５０に対し指示入力を行うことができる。バイブレータ５８は、ＣＰＵ５１の制御下で振動し、使用者に着信等を通知する機能を有する。音源部１００については以下で詳細に説明する。以上の各構成要素は、バス９９を介して相互に接続されている。
【００１０】
図３は、音源部１００の構成を示すブロック図である。音源部１００は、ＳＭＦあるいはＳＭＡＦ等の演奏制御データおよびｍｐ３データ等の波形圧縮データを再生する機能を有する。演奏制御データの再生が指示されると、ＣＰＵ５１はＲＡＭ５５に記憶されている演奏制御データ（の一部）を音源部１００に供給する。演奏制御データはＩ／Ｆ１０１を介してＦＩＦＯ（First-In First-Out）１０２にそのデータの先頭から順次所定量が取り込まれ一時記憶される。ＦＩＦＯ１０２は、演奏制御データを限られた量だけ格納できる記憶手段であり、先に書き込まれた演奏制御データから順次読み出されるようにされている。シーケンサ１０３は、ＦＩＦＯ１０２から順次演奏制御データを読み出し、演奏制御データ中の時間情報（デュレーション）に従って音源制御データを随時生成する。シーケンサ１０３は、生成した音源制御データを音源１０４に出力する。音源１０４は、音源制御データに従ってデジタル音声データを出力する。音声データはＤＡＣ（Digital Analog Converter）１２０でアナログ音声信号に変換され、スピーカ５９から音声として出力される。ＦＩＦＯ１０２内に記憶されている演奏制御データが読み出されてＦＩＦＯ１０２内に設定された所定量の空き領域が発生すると、ＦＩＦＯ１０２は割込要求信号（Interrupt ReQuest、ＩＲＱ）を図示せぬ専用信号線を介してＣＰＵ５１に送り、後続する演奏制御データの転送をＣＰＵ５１に要求する。ＣＰＵ５１は、後続する演奏制御データを所定量ＦＩＦＯ１０２に供給する。
【００１１】
一方、波形圧縮データの再生が指示されると、ＣＰＵ５１はＲＡＭ５５に記憶されている波形圧縮データ（の一部）を音源部１００に供給する。波形圧縮データはＩ／Ｆ１１１を介してＦＩＦＯ１１２にそのデータの先頭から順次所定量が取り込まれ一時記憶される。ＦＩＦＯ１１２は、波形圧縮データを限られた量だけ格納できる記憶手段であり、先に書き込まれた波形圧縮データから順次読み出されるようにされている。デコーダ１１３は、ｍｐ３データ、ＡＤＰＣＭデータ等の波形圧縮データを伸張し、波形データ（デジタル音声データ）に変換する。デコーダ１１３は、変換した波形データを出力する。波形データはＤＡＣ１２０によりアナログ音声信号に変換され、スピーカ５９から音声として出力される。ＦＩＦＯ１１２内に記憶されている波形圧縮データが読み出されてＦＩＦＯ１１２内に設定された所定量の空き領域が発生すると、ＦＩＦＯ１１２は割込要求信号（ＩＲＱ）を図示せぬ専用信号線を介してＣＰＵ５１に送り、後続する波形圧縮データの転送をＣＰＵ５１に要求する。ＣＰＵ５１は、後続する波形圧縮データを所定量ＦＩＦＯ１１２に供給する。なお、本実施形態において、デコーダ１１３はｍｐ３データおよびＡＤＰＣＭデータの２種類のフォーマットのデータをデコードできる機能を有している。別の態様において、音源部１００が、ｍｐ３データをデコードするｍｐ３デコーダとＡＤＰＣＭデータをデコードするＡＤＰＣＭデコーダとを別個に有する構成としてもよい。また、データフォーマットはｍｐ３形式およびＡＤＰＣＭ形式に限られず、ｗｍａ形式等他のフォーマットの波形圧縮データを用いてもよい。なお、この場合は音源部１００が、使用されるデータフォーマットに適したデコーダを有する必要がある。
【００１２】
このように、音源部１００は、演奏制御データを再生する処理系統（Ｉ／Ｆ１０１、ＦＩＦＯ１０２、シーケンサ１０３、音源１０４）と、ｍｐ３データ等の波形圧縮データを再生する処理系統（Ｉ／Ｆ１１１、ＦＩＦＯ１１２、デコーダ１１３）との２つの再生系統を有する。演奏制御データおよび波形圧縮データは、それぞれに対応する再生系統で処理され、デジタル音声データが生成される。２つの再生系統で生成された音声データは加算器１０５によって加算され、同期してスピーカ５９から音声として出力される。
【００１３】
図４は、本実施形態に係る楽曲データＤ１の構成を示す図である。楽曲データＤ１は、パート１〜５の５つのパート（チャンネル）から構成されるフォーマットとされている。各パートのデータは、デュレーションデータとイベントデータのペアを有するシーケンスデータである。あるイベントデータに対応するデュレーションデータは、１つ前のイベントの開始時刻から、そのイベントの開始時刻までのデュレーション（時間）を示すデータである。イベントデータは、音源部１００等の出力デバイスに対する制御内容を示すデータである。図４において、パート１、３、５はイベントデータとしてＭＩＤＩイベントを有するＭＩＤＩ（Musical Instruments Digital Interface）データである。パート２は、イベントデータとしてＡＤＰＣＭ形式の発音データを有する埋め込みオーディオデータである。また、パート４は、イベントデータとしてｍｐ３形式の音声データ等のストリームオーディオデータの記憶場所を示すＵＲＬ（Uniform Resource Locator）を示すデータ（ＵＲＬイベント）と、デュレーションデータとしてそのストリームオーディオデータの再生を開始すべき時間を示すデータとを有している。ＵＲＬイベントは、例えば、「http://aaa.bbb.co.jp/sing-1.mp3」等、配信サーバ名と配信対象のファイル名の情報を含んでいる。携帯端末５０は、このＵＲＬで指定される配信サーバから指定されるデータ（ストリームオーディオデータ）をダウンロードして再生する。
【００１４】
携帯端末５０は楽曲データＤ１をＲＡＭ５５に記憶している。楽曲データＤ１は携帯端末５０の出荷時にあらかじめ記憶されているものであってもよいし、出荷後にサーバから通信回線を介してダウンロードして記憶したものであってもよい。携帯端末５０はＲＡＭ５５から楽曲データＤ１を読み出し、音源部１００に出力する。音源部１００は、前述のように楽曲データＤ１に従って楽曲を再生する。楽曲データＤ１は、ＭＩＤＩデータ、埋め込みオーディオデータ、サーバからダウンロードしたストリームオーディオデータが混在する楽曲データである。本実施形態に係る携帯端末５０は、前述のようにＭＩＤＩデータ（演奏制御データ）と、埋め込みオーディオデータおよびストリームオーディオデータ（波形圧縮データ）とを同期して再生することができる。本実施形態においては、このようなデータ形式の楽曲データフォーマットを採用したことにより、異なる形式のデータを同期して再生することが可能である。
【００１５】
図５は、配信サーバ１０のハードウェア構成を示すブロック図である。配信サーバ１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、Ｉ／Ｆ１４、入力部１５、表示部１６、記憶部１７を有するコンピュータ装置である。記憶部１７はＨＤＤ等の記憶装置で構成され、上述のｍｐ３形式の音声データ等のストリームオーディオデータを記録したデータベースＤＢ１を記憶している。配信サーバ１０はＩ／Ｆ１４を介してインターネット等のネットワーク７０に接続されており、ネットワーク７０を介して受信したダウンロード要求に応じて、記憶部１７に記憶しているストリームオーディオデータを送信する機能を有する。配信サーバ２０も配信サーバ１０と同様のハードウェア構成を有している。なお、配信サーバ１０に記憶されるストリームオーディオデータはｍｐ３形式のデータに限られず、ＡＤＰＣＭ形式、ｗｍａ形式等他のフォーマットで記述されたデータであってもよい。
【００１６】
＜２．動作＞
続いて、楽曲配信システム１の動作について説明する。
図６は、楽曲配信システム１の動作を示すフローチャートである。携帯端末５０において楽曲データＤ１の再生が指示されると（ステップＳ１０１：ＹＥＳ）、ＣＰＵ５１は、楽曲データＤ１の再生に先立って、楽曲データＤ１がＵＲＬイベントデータを有するか否か検索する（ステップＳ１０２）。楽曲データＤ１がＵＲＬイベントデータを有する場合（ステップＳ１０３：ＹＥＳ）、ＣＰＵ５１は、ＵＲＬイベントデータにより示されるデータ（ＵＲＬイベントデータが複数ある場合は、楽曲データＤ１の再生において最も早く現れるデータ）をダウンロードする旨を指示するダウンロード要求を生成する。ＣＰＵ５１は、ＵＲＬイベントデータにより示される配信サーバを宛先として、生成したダウンロード要求を、通信部５３を介して送信する（ステップＳ１０４）。本実施形態において、ＵＲＬイベントデータは、配信サーバ１０に記憶されているｍｐ３形式のストリームオーディオデータＤ２（以下、ｍｐ３データＤ２）を示している。したがって、ＣＰＵ５１は、配信サーバ１０に対しｍｐ３データＤ２のダウンロード要求を送信する。ここで、ダウンロード要求は、携帯端末５０が受信可能なデータのサイズを示すデータサイズ情報ＤＳ１を含んでいる。
なお、楽曲データＤ１がＵＲＬイベントデータを有さない場合（ステップＳ１０３：ＮＯ）、ＣＰＵ５１はステップＳ１０４および後述するＳ１０５の処理を行わずに、後述するステップＳ１０６へ処理を移行する。
【００１７】
ダウンロード要求を受信すると、配信サーバ１０のＣＰＵ１１は、データベースＤＢ１からｍｐ３データＤ２を検索する。ｍｐ３データＤ２を発見すると、ＣＰＵ１１は、データベースＤＢ１からｍｐ３データＤ２を抽出する。ＣＰＵ１１は、抽出したｍｐ３データＤ２の先頭から、ダウンロード要求に含まれるデータサイズ情報ＤＳ１により指定されるサイズのデータとなるように、ｍｐ３データＤ２の一部のデータを抽出する。以下、このｍｐ３データＤ２のうち一部分のデータを楽曲素片データＤ３という。
ＣＰＵ１１は、抽出した楽曲素片データＤ３を、Ｉ／Ｆ１４およびネットワーク７０を介して、ダウンロード要求の送信元である携帯端末５０に送信する。
【００１８】
楽曲素片データＤ３を受信すると、携帯端末５０のＣＰＵ５１は、受信した楽曲素片データＤ３をＲＡＭ５５に記憶する。ＲＡＭ５５には、楽曲素片データ用の記憶領域Ｍ１が確保されている。ＣＰＵ５１は、記憶領域Ｍ１に楽曲素片データＤ３を記憶する。また、ＣＰＵ５１は、ｍｐ３データＤ２のうち、ダウンロード済みのデータの位置（すなわち、次にダウンロードを開始するデータの先頭位置）を示す情報であるアドレスＰ３をＲＡＭ５５に記憶させる。記憶領域Ｍ１に楽曲素片データＤ３が記憶されると（ステップＳ１０５：ＹＥＳ）、ＣＰＵ５１は、楽曲データＤ１を順次音源部１００に出力する。こうして楽曲データＤ１の再生が開始される（ステップＳ１０６）。なお、以下で説明するように処理はステップＳ１０７〜Ｓ１０９へと進行するが、楽曲の再生が終了するまで、これらのステップにおいても楽曲は再生され続けている。
【００１９】
音源部１００は、図４に示される各パートのデータを時間情報（デュレーション）に従って順次再生して音声として出力する。パート１、３、５に関しては、ＭＩＤＩデータ（演奏制御データ）が順次ＦＩＦＯ１０２に供給され、各パートのＭＩＤＩデータに対応する音声が再生される。パート２に関しては、ＡＤＰＣＭデータ（圧縮波形データ）が順次ＦＩＦＯ１１２に供給され、それに対応する音声が再生される。そしてパート４においてＵＲＬイベントに到達すると、音源部１００はＣＰＵ５１に対して楽曲素片データＤ３の転送を要求する。ＣＰＵ５１は、その要求に従って記憶領域Ｍ１から楽曲素片データＤ３を順次音源部１００へ出力する。楽曲素片データＤ３はｍｐ３形式の圧縮波形データであるから、音源部１００において圧縮波形データの再生系統（Ｉ／Ｆ１１１、ＦＩＦＯ１１２、デコーダ１１３）により再生される。こうして、楽曲素片データＤ３に応じたストリームオーディオが再生される。楽曲素片データＤ３は、音源部１００のＦＩＦＯ１１２の記憶容量に応じて順次供給される。ここで、ＣＰＵ５１は、記憶領域Ｍ１の残存容量を監視している。
図７は、記憶領域Ｍ１の残存容量の監視方法を説明する図である。ＣＰＵ５１は、記憶領域Ｍ１においてまだ音源部１００に出力されていないデータの先頭アドレス（以下、アドレスＰ１という）および、まだ音源部１００に出力されていないデータの最後尾アドレス（以下、アドレスＰ２という）を変数としてＲＡＭ５５に記憶している（図７（ａ））。ここで、アドレスＰ１はいわばデータの読み込み点であり、アドレスＰ２はいわばデータの書き込み点である。
【００２０】
楽曲素片データＤ３が音源部１００に出力されるにつれ、アドレスＰ１は順次後部に移動する。ここで、記憶領域Ｍ１の先頭からアドレスＰ１までの領域（図７（ｂ）の白い部分）は、既にデータが転送済みであるので空き領域となっている。ＣＰＵ５１は、一定の時間間隔で、アドレスＰ１およびアドレスＰ２からこの空き領域の容量すなわち記憶領域Ｍ１の残存容量を算出する。
再び図６を参照して説明すると、ＣＰＵ５１は、算出した記憶領域Ｍ１の残存容量があらかじめ決められた値（例えば、記憶領域Ｍ１の記憶容量の半分の値）を超えたか否か監視している（ステップＳ１０７）。残存容量があらかじめ決められた値を超えていない場合（ステップＳ１０７：ＮＯ）、ＣＰＵ５１は、次に説明するステップＳ１０８の処理を行わずに、後述するステップＳ１０９の処理を行う。
【００２１】
残存容量があらかじめ決められた値を超えた場合（ステップＳ１０７：ＹＥＳ）、楽曲素片データの転送が行われる（ステップＳ１０８）。具体的には次のとおりである。ＣＰＵ５１は、ｍｐ３データＤ２のうち楽曲素片データＤ３に後続するデータのダウンロード要求を生成する。このダウンロード要求は、記憶領域Ｍ１の残存容量（すなわち記憶領域Ｍ１の記憶容量の半分の値）を示すデータサイズ情報ＤＳ２を含んでいる。このダウンロード要求はまた、ｍｐ３データＤ２のうち、ダウンロードを開始する位置を示す情報であるアドレスＰ３も含んでいる。ＣＰＵ５１は、生成したダウンロード要求を、ＵＲＬイベントデータが示す配信サーバ１０に送信する。
【００２２】
ダウンロード要求を受信すると、配信サーバ１０のＣＰＵ１１は、ｍｐ３データＤ２のうち、アドレスＰ３で指定される位置から、データサイズ情報ＤＳ２で指定されるサイズのデータを抽出する（以下、楽曲素片データＤ４という）。ＣＰＵ１１は、抽出した楽曲素片データＤ４を、ダウンロード要求の送信元である携帯端末５０に送信する。
【００２３】
楽曲素片データＤ３に後続する楽曲素片データである楽曲素片データＤ４を受信すると、携帯端末５０のＣＰＵ５１は、楽曲素片データＤ４を記憶領域Ｍ１のうち、アドレスＰ２の次の位置から始まる空き領域に記憶する。図７（ｂ）に示されるように、アドレスＰ２が記憶領域Ｍ１の最後尾に位置していた場合は、記憶領域Ｍ１の先頭から楽曲素片データＤ４を記憶する（図７（ｃ））。この際、ＣＰＵ５１は、ＲＡＭ５５に記憶されているアドレスＰ３の値を更新する。なお、このダウンロード処理の間も楽曲素片データＤ３の再生処理は継続しているので、アドレスＰ１は後部に進んでいる。
【００２４】
楽曲素片データＤ３の再生処理がさらに進行し、記憶領域Ｍ１の空き容量が再びあらかじめ決められた値に達した場合（図７（ｄ））、ＣＰＵ５１は、楽曲素片データＤ４をダウンロードしたときと同じように、楽曲素片データＤ４に後続するデータのダウンロード要求を生成し、配信サーバ１０からデータ（楽曲素片データＤ５）をダウンロードする。ＣＰＵ５１は、ダウンロードした楽曲素片データＤ５を記憶領域Ｍ１の空き領域に記憶する（図７（ｅ））。楽曲素片データＤ５を記憶領域Ｍ１に記憶すると、ＣＰＵ５１は、楽曲の再生が終了したか否か判断する（ステップＳ１０９）。楽曲の再生が終了した場合（ステップＳ１０９：ＹＥＳ）、ＣＰＵ５１は、楽曲配信システム１の動作を終了する。楽曲の再生が終了していない場合（ステップＳ１０９：ＮＯ）、ＣＰＵ５１は、ステップＳ１０７、１０８の処理を繰り返し実行する。なお、前述のように、ステップＳ１０７〜Ｓ１０９においてはＵＲＬイベントを有するパート４だけでなく他のパートも、楽曲の再生が終了するまで再生され続けている。
【００２５】
ＣＰＵ５１は、以上の処理を、ｍｐ３データＤ２の先頭から最後尾までの再生が完了するまで繰り返し実行する。ｍｐ３データＤ２の再生が完了したら、ＣＰＵ５１は、楽曲データＤ１内のさらに別のＵＲＬイベントデータに到達するまで待つ。別のＵＲＬイベントデータに到達した場合は、ＣＰＵ５１は、ｍｐ３データＤ２の場合と同様にダウンロードおよび再生処理を行う。
【００２６】
以上のようにして、ｍｐ３データＤ２は、記憶領域Ｍ１の記憶容量に応じて楽曲素片データに分割され、一部ずつダウンロードされる。ダウンロード処理の間も再生処理は並列して行われているので、携帯端末５０は、楽曲を途切れさせることなくｍｐ３データＤ２を再生することができる。また、パート１〜３、５のＭＩＤＩデータ、ＡＤＰＣＭデータも並列して再生される。したがって、本実施形態に係る携帯端末５０は、ＭＩＤＩ等の演奏制御データ、ＡＤＰＣＭ等の埋め込みオーディオデータ、およびサーバからダウンロードしたストリームオーディオデータが混在した楽曲データを再生可能である。
すなわち、携帯電話機のように使用可能なリソースが限られた環境において、例えば伴奏部分はＭＩＤＩ等の演奏制御データによって再生し、ヴォーカル等の演奏制御データでは再生が困難なパートはサーバからダウンロードするストリームデータによって再生することができる。これにより、携帯端末５０において、限られたリソースで高品質な楽曲を再生することができる。
【００２７】
＜３．変形例＞
本発明は上述の実施形態に限定されるものでなく、種々の変形実施が可能である。
上述の実施形態においては、楽曲素片データのダウンロードの際に、記憶領域Ｍ１の残存記憶容量に関する情報を配信サーバ１０に送信し、配信サーバ１０が残存容量に応じたサイズのデータを携帯端末５０に送信する態様について説明したが、楽曲素片データのダウンロード方法はこれに限定されるものではない。例えば、以下のような方法によって楽曲素片データのダウンロードを行ってもよい。携帯端末５０は、ダウンロード開始位置を示す情報（アドレスＰ３）のみを配信サーバ１０に送信する。配信サーバ１０は、アドレスＰ３で示される位置からデータを送信する。携帯端末５０のＣＰＵ５１は、記憶領域Ｍ１の容量を監視し、記憶領域Ｍ１が楽曲素片データで満たされたらダウンロード停止要求を配信サーバ１０に送信する。
【００２８】
上述の実施形態においては、記憶領域Ｍ１の空き容量が、記憶領域Ｍ１の記憶容量の半分になったときに後続する楽曲素片データのダウンロード要求を生成する構成としたが、ダウンロード要求を生成するタイミング、空き容量のしきい値はこれに限定されるものではない。記憶領域Ｍ１の記憶容量の１／３、１／４等、記憶容量と通信回線の環境に応じて任意に設定することができる。また、ＣＰＵ５１が、通信回線の速度等の通信環境情報に基づき、空き容量のしきい値を決定する構成としてもよい。あるいは、ユーザに空き容量のしきい値を指定させる構成としてもよい。
【００２９】
楽曲データは上述の実施形態で示した形式のものに限られない。例えば、演奏制御データとしてＳＭＦ形式あるいはＳＭＡＦ形式のデータを用いてもよいし、埋め込みオーディオデータ、ストリームオーディオデータとして、ｗｍａ形式等他の形式のデータを用いてもよい。また、演奏制御データや埋め込みオーディオデータのパートを持たず、ＵＲＬイベントのパートだけで楽曲データを構成してもよいし、楽曲データがＵＲＬイベントのパートを複数有してもよい。さらに、ＵＲＬイベントのパートがデュレーションを持たずに（またはデュレーションの時間が０）、１つのＵＲＬイベントだけで構成されていてもよい。
【図面の簡単な説明】
【００３０】
【図１】本発明の一実施形態に係る楽曲配信システム１の構成を示すブロック図である。
【図２】携帯端末５０のハードウェア構成を示すブロック図である。
【図３】音源部１００の構成を示すブロック図である。
【図４】同実施形態に係る楽曲データＤ１の構成を示す図である。
【図５】配信サーバ１０のハードウェア構成を示すブロック図である。
【図６】楽曲配信システム１の動作を示すフローチャートである。
【図７】記憶領域Ｍ１の残存容量の監視方法を説明する図である。
【符号の説明】
【００３１】
１…楽曲配信システム、１０…配信サーバ、１１…ＣＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…Ｉ／Ｆ、１５…入力部、１６…表示部、１７…記憶部、２０…配信サーバ、３０…基地局、５０…携帯端末、５１…ＣＰＵ、５２…ＲＯＭ、５３…通信部、５４…音声処理部、５５…ＲＡＭ、５６…表示部、５７…入力部、５８…バイブレータ、５９…スピーカ、６０…携帯端末、７０…ネットワーク、９９…バス、１００…音源部、１０１…Ｉ／Ｆ、１０２…ＦＩＦＯ、１０３…シーケンサ、１０４…音源、１０５…加算器、１１１…Ｉ／Ｆ、１１２…ＦＩＦＯ、１１３…デコーダ、１２０…ＤＡＣ
【技術分野】
【０００１】
本発明は、端末装置において楽曲データから楽曲を再生する技術に関する。
【背景技術】
【０００２】
携帯電話機等の携帯端末において、発音用シーケンスデータあるいはＡＤＰＣＭ（Adaptive Differential Pulse Code Modulation）データのような発音データ等、様々なデータ形式（フォーマット）の発音データを再生する技術が開発されている（例えば、特許文献１参照）。このようなデータ形式で記述された楽曲データを携帯電話機等の携帯端末にあらかじめ記憶、あるいは楽曲データ配信サーバ等に通信回線を介して楽曲データをダウンロードして記憶するようにして、これを用いて、携帯電話機等の携帯端末に、いわゆる着信メロディ等の楽曲を再生させることができる。
【特許文献１】特開２００２−０９９５４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで上述の形式の発音データを携帯端末で再生させようとする際には、携帯端末にあらかじめ再生させようとする発音データが記憶されている必要がある。ここで、この発音データのデータサイズが大きい場合には大きいサイズのままで記憶あるいはダウンロードされることになる。したがって、メモリの記憶容量やデータ通信の転送速度等のリソースが乏しい携帯端末においては、このような発音データは多くのリソースを消費し、場合によってはリソースが不足してしまうという問題があった。また、このようにリソースが制限された環境においては、転送できるデータサイズに制限があるため高品質の楽曲を再生させることは難しく、着信メロディ等のコンテンツ提供者が、再生される楽曲の高品質化を望むユーザの要求に応えられないという問題もあった。
本発明は上述の事情に鑑みてなされたものであり、小さなデータサイズで、高品質の楽曲を記憶、配信可能な楽曲データを再生する楽曲再生システムを提供することを目的とする。
【課題を解決するための手段】
【０００４】
上述の課題を解決するため、本発明は、楽曲を再生する機能およびネットワークに接続する機能を有する端末装置に、楽曲の再生を指示する楽曲データであって、データ内の所定の位置に、楽曲の少なくとも一部分に対応する楽曲素片データの前記ネットワーク内の所在を示す所在情報が記載された構造を有する楽曲データを提供する。
好ましい態様において、前記楽曲データは複数チャンネルからなる構造を有し、前記データ内の所定の位置は、前記楽曲素片を再生すべきチャンネルと再生すべき時間に対応した位置である。
別の好ましい態様において、前記所在情報は、再生すべき楽曲素片を記憶するサーバのサーバ名とその楽曲素片のファイル名とを含む。
【０００５】
また、本発明は、上記の楽曲データを記憶する第１の記憶手段と、前記所在情報により示される楽曲素片データの少なくとも１部分を、前記ネットワークを介して取得する通信手段と、前記通信手段により取得した楽曲素片データを記憶する第２の記憶手段と、前記第１の記憶手段に記憶されている楽曲データおよび前記第２の記憶手段に記憶されている楽曲素片データに従って楽曲を再生する楽曲再生手段とを有する端末装置を提供する。
好ましい態様において、この端末装置は、前記第２の記憶手段の空き容量を監視する監視手段と、前記監視手段により監視される空き容量があらかじめ決められた条件を満足したときに前記楽曲素片データの取得を指示するダウンロード要求を生成するダウンロード要求生成手段とをさらに有する。
別の好ましい態様において、前記通信手段は、前記楽曲データを送信または受信する機能を有する。
以上の態様において、前記端末装置は携帯可能な端末装置であってもよい。
【発明の効果】
【０００６】
本発明によれば、楽曲の一部分の楽曲素片データがネットワークを介して取得されるので、記憶容量の限られた端末においても高品質の楽曲（音声）を再生することが可能となる。
【発明を実施するための最良の形態】
【０００７】
以下、図面を参照して本発明の一実施形態について説明する。
＜１．構成＞
図１は、本実施形態に係る楽曲配信システム１の構成を示すブロック図である。配信サーバ１０は、ｍｐ３データ等のストリームオーディオデータを記録したデータベースＤＢ１を有する。配信サーバ１０はインターネット等のネットワーク７０を介して他の機器と通信可能である。配信サーバ２０はデータベースＤＢ２を有し、配信サーバ１０と同様の機能を有する。携帯電話機、ＰＤＡ（Personal Digital Assistance）等の携帯端末５０は、基地局３０、基地局４０およびネットワーク７０を介して他の機器と通信可能である。すなわち、携帯端末５０は、基地局３０（あるいは基地局４０）およびネットワーク７０を介して配信サーバ１０あるいは配信サーバ２０と通信することができる。携帯端末６０も携帯端末５０と同様の機能を有する。
【０００８】
図２は、携帯端末５０のハードウェア構成を示すブロック図である。ＣＰＵ（Central Processing Unit）５１は、ＲＡＭ（Random Access Memory）５５を作業エリアとして、ＲＯＭ（Read Only Memory）５２に記憶されているプログラムを読み出して実行する。ＣＰＵ５１はまた、携帯端末５０の各構成要素を制御する機能を有する。本実施形態に係る携帯端末５０は携帯電話機であって、マイクから集音された音声を音声処理部５４によってアナログ／デジタル変換し、デジタル変換された音声データを通信部５３を介して無線送信する機能を有する。また、携帯端末５０はネットワーク７０を介して送信された音声データを通信部５３により受信する。受信された音声データは音声処理部５４によりデジタル／アナログ変換され、スピーカから音声として出力される。さらに、携帯端末５０は、音声データだけでなく、ｍｐ３データ等のストリームオーディオデータや、ＳＭＦ（Standard MIDI File）あるいはＳＭＡＦ（Synthetic music Mobile Application Format）等の演奏制御データや、電子メールメッセージや、アプリケーションソフトウェア等のデータ（コンテンツ）を通信部５３を介して通信することができる。これらのデータはＲＡＭ５５に保存される。
【０００９】
表示部５６はＬＣＤ（Liquid Crystal Display）等の表示装置を有し、ＣＰＵ５１の制御下で文字や画像を表示する。携帯端末５０の使用者は、表示部５６に表示された文字や画像を見ながら、テンキーや十字キー等からなる入力部５７を操作することにより携帯端末５０に対し指示入力を行うことができる。バイブレータ５８は、ＣＰＵ５１の制御下で振動し、使用者に着信等を通知する機能を有する。音源部１００については以下で詳細に説明する。以上の各構成要素は、バス９９を介して相互に接続されている。
【００１０】
図３は、音源部１００の構成を示すブロック図である。音源部１００は、ＳＭＦあるいはＳＭＡＦ等の演奏制御データおよびｍｐ３データ等の波形圧縮データを再生する機能を有する。演奏制御データの再生が指示されると、ＣＰＵ５１はＲＡＭ５５に記憶されている演奏制御データ（の一部）を音源部１００に供給する。演奏制御データはＩ／Ｆ１０１を介してＦＩＦＯ（First-In First-Out）１０２にそのデータの先頭から順次所定量が取り込まれ一時記憶される。ＦＩＦＯ１０２は、演奏制御データを限られた量だけ格納できる記憶手段であり、先に書き込まれた演奏制御データから順次読み出されるようにされている。シーケンサ１０３は、ＦＩＦＯ１０２から順次演奏制御データを読み出し、演奏制御データ中の時間情報（デュレーション）に従って音源制御データを随時生成する。シーケンサ１０３は、生成した音源制御データを音源１０４に出力する。音源１０４は、音源制御データに従ってデジタル音声データを出力する。音声データはＤＡＣ（Digital Analog Converter）１２０でアナログ音声信号に変換され、スピーカ５９から音声として出力される。ＦＩＦＯ１０２内に記憶されている演奏制御データが読み出されてＦＩＦＯ１０２内に設定された所定量の空き領域が発生すると、ＦＩＦＯ１０２は割込要求信号（Interrupt ReQuest、ＩＲＱ）を図示せぬ専用信号線を介してＣＰＵ５１に送り、後続する演奏制御データの転送をＣＰＵ５１に要求する。ＣＰＵ５１は、後続する演奏制御データを所定量ＦＩＦＯ１０２に供給する。
【００１１】
一方、波形圧縮データの再生が指示されると、ＣＰＵ５１はＲＡＭ５５に記憶されている波形圧縮データ（の一部）を音源部１００に供給する。波形圧縮データはＩ／Ｆ１１１を介してＦＩＦＯ１１２にそのデータの先頭から順次所定量が取り込まれ一時記憶される。ＦＩＦＯ１１２は、波形圧縮データを限られた量だけ格納できる記憶手段であり、先に書き込まれた波形圧縮データから順次読み出されるようにされている。デコーダ１１３は、ｍｐ３データ、ＡＤＰＣＭデータ等の波形圧縮データを伸張し、波形データ（デジタル音声データ）に変換する。デコーダ１１３は、変換した波形データを出力する。波形データはＤＡＣ１２０によりアナログ音声信号に変換され、スピーカ５９から音声として出力される。ＦＩＦＯ１１２内に記憶されている波形圧縮データが読み出されてＦＩＦＯ１１２内に設定された所定量の空き領域が発生すると、ＦＩＦＯ１１２は割込要求信号（ＩＲＱ）を図示せぬ専用信号線を介してＣＰＵ５１に送り、後続する波形圧縮データの転送をＣＰＵ５１に要求する。ＣＰＵ５１は、後続する波形圧縮データを所定量ＦＩＦＯ１１２に供給する。なお、本実施形態において、デコーダ１１３はｍｐ３データおよびＡＤＰＣＭデータの２種類のフォーマットのデータをデコードできる機能を有している。別の態様において、音源部１００が、ｍｐ３データをデコードするｍｐ３デコーダとＡＤＰＣＭデータをデコードするＡＤＰＣＭデコーダとを別個に有する構成としてもよい。また、データフォーマットはｍｐ３形式およびＡＤＰＣＭ形式に限られず、ｗｍａ形式等他のフォーマットの波形圧縮データを用いてもよい。なお、この場合は音源部１００が、使用されるデータフォーマットに適したデコーダを有する必要がある。
【００１２】
このように、音源部１００は、演奏制御データを再生する処理系統（Ｉ／Ｆ１０１、ＦＩＦＯ１０２、シーケンサ１０３、音源１０４）と、ｍｐ３データ等の波形圧縮データを再生する処理系統（Ｉ／Ｆ１１１、ＦＩＦＯ１１２、デコーダ１１３）との２つの再生系統を有する。演奏制御データおよび波形圧縮データは、それぞれに対応する再生系統で処理され、デジタル音声データが生成される。２つの再生系統で生成された音声データは加算器１０５によって加算され、同期してスピーカ５９から音声として出力される。
【００１３】
図４は、本実施形態に係る楽曲データＤ１の構成を示す図である。楽曲データＤ１は、パート１〜５の５つのパート（チャンネル）から構成されるフォーマットとされている。各パートのデータは、デュレーションデータとイベントデータのペアを有するシーケンスデータである。あるイベントデータに対応するデュレーションデータは、１つ前のイベントの開始時刻から、そのイベントの開始時刻までのデュレーション（時間）を示すデータである。イベントデータは、音源部１００等の出力デバイスに対する制御内容を示すデータである。図４において、パート１、３、５はイベントデータとしてＭＩＤＩイベントを有するＭＩＤＩ（Musical Instruments Digital Interface）データである。パート２は、イベントデータとしてＡＤＰＣＭ形式の発音データを有する埋め込みオーディオデータである。また、パート４は、イベントデータとしてｍｐ３形式の音声データ等のストリームオーディオデータの記憶場所を示すＵＲＬ（Uniform Resource Locator）を示すデータ（ＵＲＬイベント）と、デュレーションデータとしてそのストリームオーディオデータの再生を開始すべき時間を示すデータとを有している。ＵＲＬイベントは、例えば、「http://aaa.bbb.co.jp/sing-1.mp3」等、配信サーバ名と配信対象のファイル名の情報を含んでいる。携帯端末５０は、このＵＲＬで指定される配信サーバから指定されるデータ（ストリームオーディオデータ）をダウンロードして再生する。
【００１４】
携帯端末５０は楽曲データＤ１をＲＡＭ５５に記憶している。楽曲データＤ１は携帯端末５０の出荷時にあらかじめ記憶されているものであってもよいし、出荷後にサーバから通信回線を介してダウンロードして記憶したものであってもよい。携帯端末５０はＲＡＭ５５から楽曲データＤ１を読み出し、音源部１００に出力する。音源部１００は、前述のように楽曲データＤ１に従って楽曲を再生する。楽曲データＤ１は、ＭＩＤＩデータ、埋め込みオーディオデータ、サーバからダウンロードしたストリームオーディオデータが混在する楽曲データである。本実施形態に係る携帯端末５０は、前述のようにＭＩＤＩデータ（演奏制御データ）と、埋め込みオーディオデータおよびストリームオーディオデータ（波形圧縮データ）とを同期して再生することができる。本実施形態においては、このようなデータ形式の楽曲データフォーマットを採用したことにより、異なる形式のデータを同期して再生することが可能である。
【００１５】
図５は、配信サーバ１０のハードウェア構成を示すブロック図である。配信サーバ１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、Ｉ／Ｆ１４、入力部１５、表示部１６、記憶部１７を有するコンピュータ装置である。記憶部１７はＨＤＤ等の記憶装置で構成され、上述のｍｐ３形式の音声データ等のストリームオーディオデータを記録したデータベースＤＢ１を記憶している。配信サーバ１０はＩ／Ｆ１４を介してインターネット等のネットワーク７０に接続されており、ネットワーク７０を介して受信したダウンロード要求に応じて、記憶部１７に記憶しているストリームオーディオデータを送信する機能を有する。配信サーバ２０も配信サーバ１０と同様のハードウェア構成を有している。なお、配信サーバ１０に記憶されるストリームオーディオデータはｍｐ３形式のデータに限られず、ＡＤＰＣＭ形式、ｗｍａ形式等他のフォーマットで記述されたデータであってもよい。
【００１６】
＜２．動作＞
続いて、楽曲配信システム１の動作について説明する。
図６は、楽曲配信システム１の動作を示すフローチャートである。携帯端末５０において楽曲データＤ１の再生が指示されると（ステップＳ１０１：ＹＥＳ）、ＣＰＵ５１は、楽曲データＤ１の再生に先立って、楽曲データＤ１がＵＲＬイベントデータを有するか否か検索する（ステップＳ１０２）。楽曲データＤ１がＵＲＬイベントデータを有する場合（ステップＳ１０３：ＹＥＳ）、ＣＰＵ５１は、ＵＲＬイベントデータにより示されるデータ（ＵＲＬイベントデータが複数ある場合は、楽曲データＤ１の再生において最も早く現れるデータ）をダウンロードする旨を指示するダウンロード要求を生成する。ＣＰＵ５１は、ＵＲＬイベントデータにより示される配信サーバを宛先として、生成したダウンロード要求を、通信部５３を介して送信する（ステップＳ１０４）。本実施形態において、ＵＲＬイベントデータは、配信サーバ１０に記憶されているｍｐ３形式のストリームオーディオデータＤ２（以下、ｍｐ３データＤ２）を示している。したがって、ＣＰＵ５１は、配信サーバ１０に対しｍｐ３データＤ２のダウンロード要求を送信する。ここで、ダウンロード要求は、携帯端末５０が受信可能なデータのサイズを示すデータサイズ情報ＤＳ１を含んでいる。
なお、楽曲データＤ１がＵＲＬイベントデータを有さない場合（ステップＳ１０３：ＮＯ）、ＣＰＵ５１はステップＳ１０４および後述するＳ１０５の処理を行わずに、後述するステップＳ１０６へ処理を移行する。
【００１７】
ダウンロード要求を受信すると、配信サーバ１０のＣＰＵ１１は、データベースＤＢ１からｍｐ３データＤ２を検索する。ｍｐ３データＤ２を発見すると、ＣＰＵ１１は、データベースＤＢ１からｍｐ３データＤ２を抽出する。ＣＰＵ１１は、抽出したｍｐ３データＤ２の先頭から、ダウンロード要求に含まれるデータサイズ情報ＤＳ１により指定されるサイズのデータとなるように、ｍｐ３データＤ２の一部のデータを抽出する。以下、このｍｐ３データＤ２のうち一部分のデータを楽曲素片データＤ３という。
ＣＰＵ１１は、抽出した楽曲素片データＤ３を、Ｉ／Ｆ１４およびネットワーク７０を介して、ダウンロード要求の送信元である携帯端末５０に送信する。
【００１８】
楽曲素片データＤ３を受信すると、携帯端末５０のＣＰＵ５１は、受信した楽曲素片データＤ３をＲＡＭ５５に記憶する。ＲＡＭ５５には、楽曲素片データ用の記憶領域Ｍ１が確保されている。ＣＰＵ５１は、記憶領域Ｍ１に楽曲素片データＤ３を記憶する。また、ＣＰＵ５１は、ｍｐ３データＤ２のうち、ダウンロード済みのデータの位置（すなわち、次にダウンロードを開始するデータの先頭位置）を示す情報であるアドレスＰ３をＲＡＭ５５に記憶させる。記憶領域Ｍ１に楽曲素片データＤ３が記憶されると（ステップＳ１０５：ＹＥＳ）、ＣＰＵ５１は、楽曲データＤ１を順次音源部１００に出力する。こうして楽曲データＤ１の再生が開始される（ステップＳ１０６）。なお、以下で説明するように処理はステップＳ１０７〜Ｓ１０９へと進行するが、楽曲の再生が終了するまで、これらのステップにおいても楽曲は再生され続けている。
【００１９】
音源部１００は、図４に示される各パートのデータを時間情報（デュレーション）に従って順次再生して音声として出力する。パート１、３、５に関しては、ＭＩＤＩデータ（演奏制御データ）が順次ＦＩＦＯ１０２に供給され、各パートのＭＩＤＩデータに対応する音声が再生される。パート２に関しては、ＡＤＰＣＭデータ（圧縮波形データ）が順次ＦＩＦＯ１１２に供給され、それに対応する音声が再生される。そしてパート４においてＵＲＬイベントに到達すると、音源部１００はＣＰＵ５１に対して楽曲素片データＤ３の転送を要求する。ＣＰＵ５１は、その要求に従って記憶領域Ｍ１から楽曲素片データＤ３を順次音源部１００へ出力する。楽曲素片データＤ３はｍｐ３形式の圧縮波形データであるから、音源部１００において圧縮波形データの再生系統（Ｉ／Ｆ１１１、ＦＩＦＯ１１２、デコーダ１１３）により再生される。こうして、楽曲素片データＤ３に応じたストリームオーディオが再生される。楽曲素片データＤ３は、音源部１００のＦＩＦＯ１１２の記憶容量に応じて順次供給される。ここで、ＣＰＵ５１は、記憶領域Ｍ１の残存容量を監視している。
図７は、記憶領域Ｍ１の残存容量の監視方法を説明する図である。ＣＰＵ５１は、記憶領域Ｍ１においてまだ音源部１００に出力されていないデータの先頭アドレス（以下、アドレスＰ１という）および、まだ音源部１００に出力されていないデータの最後尾アドレス（以下、アドレスＰ２という）を変数としてＲＡＭ５５に記憶している（図７（ａ））。ここで、アドレスＰ１はいわばデータの読み込み点であり、アドレスＰ２はいわばデータの書き込み点である。
【００２０】
楽曲素片データＤ３が音源部１００に出力されるにつれ、アドレスＰ１は順次後部に移動する。ここで、記憶領域Ｍ１の先頭からアドレスＰ１までの領域（図７（ｂ）の白い部分）は、既にデータが転送済みであるので空き領域となっている。ＣＰＵ５１は、一定の時間間隔で、アドレスＰ１およびアドレスＰ２からこの空き領域の容量すなわち記憶領域Ｍ１の残存容量を算出する。
再び図６を参照して説明すると、ＣＰＵ５１は、算出した記憶領域Ｍ１の残存容量があらかじめ決められた値（例えば、記憶領域Ｍ１の記憶容量の半分の値）を超えたか否か監視している（ステップＳ１０７）。残存容量があらかじめ決められた値を超えていない場合（ステップＳ１０７：ＮＯ）、ＣＰＵ５１は、次に説明するステップＳ１０８の処理を行わずに、後述するステップＳ１０９の処理を行う。
【００２１】
残存容量があらかじめ決められた値を超えた場合（ステップＳ１０７：ＹＥＳ）、楽曲素片データの転送が行われる（ステップＳ１０８）。具体的には次のとおりである。ＣＰＵ５１は、ｍｐ３データＤ２のうち楽曲素片データＤ３に後続するデータのダウンロード要求を生成する。このダウンロード要求は、記憶領域Ｍ１の残存容量（すなわち記憶領域Ｍ１の記憶容量の半分の値）を示すデータサイズ情報ＤＳ２を含んでいる。このダウンロード要求はまた、ｍｐ３データＤ２のうち、ダウンロードを開始する位置を示す情報であるアドレスＰ３も含んでいる。ＣＰＵ５１は、生成したダウンロード要求を、ＵＲＬイベントデータが示す配信サーバ１０に送信する。
【００２２】
ダウンロード要求を受信すると、配信サーバ１０のＣＰＵ１１は、ｍｐ３データＤ２のうち、アドレスＰ３で指定される位置から、データサイズ情報ＤＳ２で指定されるサイズのデータを抽出する（以下、楽曲素片データＤ４という）。ＣＰＵ１１は、抽出した楽曲素片データＤ４を、ダウンロード要求の送信元である携帯端末５０に送信する。
【００２３】
楽曲素片データＤ３に後続する楽曲素片データである楽曲素片データＤ４を受信すると、携帯端末５０のＣＰＵ５１は、楽曲素片データＤ４を記憶領域Ｍ１のうち、アドレスＰ２の次の位置から始まる空き領域に記憶する。図７（ｂ）に示されるように、アドレスＰ２が記憶領域Ｍ１の最後尾に位置していた場合は、記憶領域Ｍ１の先頭から楽曲素片データＤ４を記憶する（図７（ｃ））。この際、ＣＰＵ５１は、ＲＡＭ５５に記憶されているアドレスＰ３の値を更新する。なお、このダウンロード処理の間も楽曲素片データＤ３の再生処理は継続しているので、アドレスＰ１は後部に進んでいる。
【００２４】
楽曲素片データＤ３の再生処理がさらに進行し、記憶領域Ｍ１の空き容量が再びあらかじめ決められた値に達した場合（図７（ｄ））、ＣＰＵ５１は、楽曲素片データＤ４をダウンロードしたときと同じように、楽曲素片データＤ４に後続するデータのダウンロード要求を生成し、配信サーバ１０からデータ（楽曲素片データＤ５）をダウンロードする。ＣＰＵ５１は、ダウンロードした楽曲素片データＤ５を記憶領域Ｍ１の空き領域に記憶する（図７（ｅ））。楽曲素片データＤ５を記憶領域Ｍ１に記憶すると、ＣＰＵ５１は、楽曲の再生が終了したか否か判断する（ステップＳ１０９）。楽曲の再生が終了した場合（ステップＳ１０９：ＹＥＳ）、ＣＰＵ５１は、楽曲配信システム１の動作を終了する。楽曲の再生が終了していない場合（ステップＳ１０９：ＮＯ）、ＣＰＵ５１は、ステップＳ１０７、１０８の処理を繰り返し実行する。なお、前述のように、ステップＳ１０７〜Ｓ１０９においてはＵＲＬイベントを有するパート４だけでなく他のパートも、楽曲の再生が終了するまで再生され続けている。
【００２５】
ＣＰＵ５１は、以上の処理を、ｍｐ３データＤ２の先頭から最後尾までの再生が完了するまで繰り返し実行する。ｍｐ３データＤ２の再生が完了したら、ＣＰＵ５１は、楽曲データＤ１内のさらに別のＵＲＬイベントデータに到達するまで待つ。別のＵＲＬイベントデータに到達した場合は、ＣＰＵ５１は、ｍｐ３データＤ２の場合と同様にダウンロードおよび再生処理を行う。
【００２６】
以上のようにして、ｍｐ３データＤ２は、記憶領域Ｍ１の記憶容量に応じて楽曲素片データに分割され、一部ずつダウンロードされる。ダウンロード処理の間も再生処理は並列して行われているので、携帯端末５０は、楽曲を途切れさせることなくｍｐ３データＤ２を再生することができる。また、パート１〜３、５のＭＩＤＩデータ、ＡＤＰＣＭデータも並列して再生される。したがって、本実施形態に係る携帯端末５０は、ＭＩＤＩ等の演奏制御データ、ＡＤＰＣＭ等の埋め込みオーディオデータ、およびサーバからダウンロードしたストリームオーディオデータが混在した楽曲データを再生可能である。
すなわち、携帯電話機のように使用可能なリソースが限られた環境において、例えば伴奏部分はＭＩＤＩ等の演奏制御データによって再生し、ヴォーカル等の演奏制御データでは再生が困難なパートはサーバからダウンロードするストリームデータによって再生することができる。これにより、携帯端末５０において、限られたリソースで高品質な楽曲を再生することができる。
【００２７】
＜３．変形例＞
本発明は上述の実施形態に限定されるものでなく、種々の変形実施が可能である。
上述の実施形態においては、楽曲素片データのダウンロードの際に、記憶領域Ｍ１の残存記憶容量に関する情報を配信サーバ１０に送信し、配信サーバ１０が残存容量に応じたサイズのデータを携帯端末５０に送信する態様について説明したが、楽曲素片データのダウンロード方法はこれに限定されるものではない。例えば、以下のような方法によって楽曲素片データのダウンロードを行ってもよい。携帯端末５０は、ダウンロード開始位置を示す情報（アドレスＰ３）のみを配信サーバ１０に送信する。配信サーバ１０は、アドレスＰ３で示される位置からデータを送信する。携帯端末５０のＣＰＵ５１は、記憶領域Ｍ１の容量を監視し、記憶領域Ｍ１が楽曲素片データで満たされたらダウンロード停止要求を配信サーバ１０に送信する。
【００２８】
上述の実施形態においては、記憶領域Ｍ１の空き容量が、記憶領域Ｍ１の記憶容量の半分になったときに後続する楽曲素片データのダウンロード要求を生成する構成としたが、ダウンロード要求を生成するタイミング、空き容量のしきい値はこれに限定されるものではない。記憶領域Ｍ１の記憶容量の１／３、１／４等、記憶容量と通信回線の環境に応じて任意に設定することができる。また、ＣＰＵ５１が、通信回線の速度等の通信環境情報に基づき、空き容量のしきい値を決定する構成としてもよい。あるいは、ユーザに空き容量のしきい値を指定させる構成としてもよい。
【００２９】
楽曲データは上述の実施形態で示した形式のものに限られない。例えば、演奏制御データとしてＳＭＦ形式あるいはＳＭＡＦ形式のデータを用いてもよいし、埋め込みオーディオデータ、ストリームオーディオデータとして、ｗｍａ形式等他の形式のデータを用いてもよい。また、演奏制御データや埋め込みオーディオデータのパートを持たず、ＵＲＬイベントのパートだけで楽曲データを構成してもよいし、楽曲データがＵＲＬイベントのパートを複数有してもよい。さらに、ＵＲＬイベントのパートがデュレーションを持たずに（またはデュレーションの時間が０）、１つのＵＲＬイベントだけで構成されていてもよい。
【図面の簡単な説明】
【００３０】
【図１】本発明の一実施形態に係る楽曲配信システム１の構成を示すブロック図である。
【図２】携帯端末５０のハードウェア構成を示すブロック図である。
【図３】音源部１００の構成を示すブロック図である。
【図４】同実施形態に係る楽曲データＤ１の構成を示す図である。
【図５】配信サーバ１０のハードウェア構成を示すブロック図である。
【図６】楽曲配信システム１の動作を示すフローチャートである。
【図７】記憶領域Ｍ１の残存容量の監視方法を説明する図である。
【符号の説明】
【００３１】
１…楽曲配信システム、１０…配信サーバ、１１…ＣＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…Ｉ／Ｆ、１５…入力部、１６…表示部、１７…記憶部、２０…配信サーバ、３０…基地局、５０…携帯端末、５１…ＣＰＵ、５２…ＲＯＭ、５３…通信部、５４…音声処理部、５５…ＲＡＭ、５６…表示部、５７…入力部、５８…バイブレータ、５９…スピーカ、６０…携帯端末、７０…ネットワーク、９９…バス、１００…音源部、１０１…Ｉ／Ｆ、１０２…ＦＩＦＯ、１０３…シーケンサ、１０４…音源、１０５…加算器、１１１…Ｉ／Ｆ、１１２…ＦＩＦＯ、１１３…デコーダ、１２０…ＤＡＣ
【特許請求の範囲】
【請求項１】
楽曲を再生する機能およびネットワークに接続する機能を有する端末装置に、楽曲の再生を指示する楽曲データであって、
データ内の所定の位置に、楽曲の少なくとも一部分に対応する楽曲素片データの前記ネットワーク内の所在を示す所在情報が記載された構造を有する楽曲データ。
【請求項２】
前記楽曲データが複数チャンネルからなる構造を有し、
前記データ内の所定の位置は、前記楽曲素片を再生すべきチャンネルと再生すべき時間に対応した位置であることを特徴とする請求項１に記載の楽曲データ。
【請求項３】
前記所在情報が、再生すべき楽曲素片を記憶するサーバのサーバ名とその楽曲素片のファイル名とを含むことを特徴とする請求項１に記載の楽曲データ。
【請求項４】
請求項１〜３のいずれかの項に記載の楽曲データを記憶する第１の記憶手段と、
前記所在情報により示される楽曲素片データの少なくとも１部分を、前記ネットワークを介して取得する通信手段と、
前記通信手段により取得した楽曲素片データを記憶する第２の記憶手段と、
前記第１の記憶手段に記憶されている楽曲データおよび前記第２の記憶手段に記憶されている楽曲素片データに従って楽曲を再生する楽曲再生手段と
を有する端末装置。
【請求項５】
前記第２の記憶手段の空き容量を監視する監視手段と、
前記監視手段により監視される空き容量があらかじめ決められた条件を満足したときに前記楽曲素片データの取得を指示するダウンロード要求を生成するダウンロード要求生成手段と
をさらに有する請求項４に記載の端末装置。
【請求項６】
前記通信手段が、前記楽曲データを送信または受信する機能を有することを特徴とする請求項４に記載の端末装置。
【請求項７】
前記端末装置が携帯可能であることを特徴とする請求項４〜６のいずれかの項に記載の端末装置。
【請求項１】
楽曲を再生する機能およびネットワークに接続する機能を有する端末装置に、楽曲の再生を指示する楽曲データであって、
データ内の所定の位置に、楽曲の少なくとも一部分に対応する楽曲素片データの前記ネットワーク内の所在を示す所在情報が記載された構造を有する楽曲データ。
【請求項２】
前記楽曲データが複数チャンネルからなる構造を有し、
前記データ内の所定の位置は、前記楽曲素片を再生すべきチャンネルと再生すべき時間に対応した位置であることを特徴とする請求項１に記載の楽曲データ。
【請求項３】
前記所在情報が、再生すべき楽曲素片を記憶するサーバのサーバ名とその楽曲素片のファイル名とを含むことを特徴とする請求項１に記載の楽曲データ。
【請求項４】
請求項１〜３のいずれかの項に記載の楽曲データを記憶する第１の記憶手段と、
前記所在情報により示される楽曲素片データの少なくとも１部分を、前記ネットワークを介して取得する通信手段と、
前記通信手段により取得した楽曲素片データを記憶する第２の記憶手段と、
前記第１の記憶手段に記憶されている楽曲データおよび前記第２の記憶手段に記憶されている楽曲素片データに従って楽曲を再生する楽曲再生手段と
を有する端末装置。
【請求項５】
前記第２の記憶手段の空き容量を監視する監視手段と、
前記監視手段により監視される空き容量があらかじめ決められた条件を満足したときに前記楽曲素片データの取得を指示するダウンロード要求を生成するダウンロード要求生成手段と
をさらに有する請求項４に記載の端末装置。
【請求項６】
前記通信手段が、前記楽曲データを送信または受信する機能を有することを特徴とする請求項４に記載の端末装置。
【請求項７】
前記端末装置が携帯可能であることを特徴とする請求項４〜６のいずれかの項に記載の端末装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００６−１６３２８０（Ｐ２００６−１６３２８０Ａ）
【公開日】平成１８年６月２２日（２００６．６．２２）
【国際特許分類】
【出願番号】特願２００４−３５８４４４（Ｐ２００４−３５８４４４）
【出願日】平成１６年１２月１０日（２００４．１２．１０）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
【公開日】平成１８年６月２２日（２００６．６．２２）
【国際特許分類】
【出願日】平成１６年１２月１０日（２００４．１２．１０）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
[ Back to top ]