JP4595828B2 - オーディオ再生装置 - Google Patents

Description

本発明は、オーディオデータのストリーミング再生を行うオーディオ再生装置及びマルチメディアファイルのファイルフォーマットに関する。

従来、映像や音声などのマルチメディアデータを再生する方法として、ダウンロード再生とストリーミング再生の二種類が知られている。ダウンロード再生とは、端末が通信回線からマルチメディアデータを全て引き出し、端末内部のメモリに蓄積した後に再生する方式である。

圧縮オーディオデータとＭＩＤＩ（Musical Instruments Digital Interface）データと画像データ、テキストデータとから構成されるフォーマットファイルは、このダウンロード再生によりユーザの端末に提供されている。

一方、ストリーミング再生とは、端末が通信回線からマルチメディアデータを受信しながら同時に再生する方式である。ストリーミング再生の場合、最初にいくらかのデータをバッファメモリに蓄えておき、再生しつつ受信することでデータを確保していく。

図５はストリーミング再生を示す模式図であり、再生ポインタは端末で現在再生されているデータの位置を示すポインタであり、読み込みポインタは端末で通信回線から現在受信しているデータの位置を示すポインタである。

データを再生する速度よりもデータを読み込む速度の方が速ければ、読み込みポインタが常に再生ポインタよりも時間軸上で先に位置することになるため、ユーザはデータが蓄積されるのを待たずに、端末でマルチメディアデータを再生することができる。

逆に、データを再生する速度よりもデータを読み込む速度の方が遅ければ、再生中に読み込みポインタが再生ポインタの位置へと接近した時点で、端末は再生に必要なデータをバッファメモリに蓄積する必要があり、この間マルチメディアファイルの再生は中断される。

ＰＣ（Personal Computer）で行われている動画や音声のストリーミング再生では、端末側のデータ受信速度に合わせて配信データの量を調整し、途中で中断することなくストリーミング再生が行われるようにしている。近年、携帯電話機においても、音楽や映像の配信サービスが開始され始めており、ストリーミング再生の技術は重要な位置づけとなっている。
なお、本出願に関する従来技術の参考文献として、特許文献１が知られている。
特開２００１−３３１１７６号公報

しかし、ＰＣで行われている動画や音声のストリーミング再生は、フレーム単位のデータである動画や音声を全て送るものであるため、ストリーミング再生時のデータ容量が大きい。

また、圧縮オーディオデータとＭＩＤＩデータと画像データ、テキストデータとから構成されるフォーマットファイルは、データ容量は小さいものの、シーケンスデータであるＭＩＤＩデータをフレーム単位で処理することが困難であるため、ストリーミング再生による配信が実現されていない。

本発明は上記事情を考慮してなされたもので、その目的は、圧縮オーディオデータとＭＩＤＩデータと画像データ、テキストデータとから構成されるマルチメディアファイルでストリーミング再生を可能にするファイルフォーマット及びオーディオ再生装置を提供することにある。

本発明は上記の課題を解決するためになされたもので、本発明は、オーディオデータと、当該オーディオデータと同期して再生されるシーケンスデータと、当該オーディオデータが格納された位置を示す位置情報とを含むマルチメディアファイルであって、前記オーディオデータが前記シーケンスデータ及び前記位置情報より後に受信されるように配置されたファイルフォーマットのマルチメディアファイルを受信する受信手段と、前記受信手段で受信したマルチメディアファイルを逐次格納するバッファ手段と、前記オーディオデータを再生するオーディオデータ再生手段と、前記シーケンスデータを再生するシーケンスデータ再生手段と、前記バッファ手段に格納されたマルチメディアファイルを読み込み、前記オーディオデータ再生手段及び前記シーケンスデータ再生手段を制御する制御手段とを具備し、前記制御手段は、前記バッファ手段から読み込む前記マルチメディアファイルの読み込み位置が前記位置情報によって示される位置に到達したときに、前記バッファ手段が前記マルチメディアファイル中のオーディオデータを格納し始めたと判断し、前記オーディオデータのストリーミング再生と前記シーケンスデータの再生を開始することを特徴とするオーディオ再生装置である。

また、本発明は、上記の発明において、前記シーケンスデータは、演奏データ、画像データ、テキストデータのいずれかを含むことを特徴とする。

また、本発明は、上記の発明において、前記オーディオデータは圧縮されたデータであり、前記マルチメディアファイルは、前記オーディオデータの圧縮形式に関する圧縮情報をさらに含み、前記圧縮されたオーディオデータを伸張して前記オーディオデータ再生手段へと出力するオーディオデコード手段をさらに具備し、前記制御手段は、前記バッファ手段から前記圧縮情報を読み込むと、当該圧縮情報を前記オーディオデコード手段に登録することを特徴とする。

本発明によれば、ＭＩＤＩ等の演奏データや画像データ、テキストデータをオーディオデータより先に受信するようなファイルフォーマットであるため、オーディオ再生装置がオーディオデータを受信しストリーミング再生を行う際には、オーディオデータと同期して演奏データの再生や画像データ・テキストデータの表示を行うことが可能である。したがって、演奏データ等のシーケンスデータを含むマルチメディアファイルにおいても、ストリーミング再生を行うことができる。

また、マルチメディアファイルの圧縮オーディオデータを受信した時点でストリーミング再生を開始することが可能であるため、マルチメディアファイルの全体を受信後に再生を行うダウンロード再生と比較して、再生までの待ち時間を短縮することができる。

以下、図面を参照して本発明の実施形態について説明する。図１は、本発明の実施形態に係る携帯電話機（オーディオ再生装置）の構成を示す構成図である。図１において、携帯電話機１内のＣＰＵ１０１は携帯電話機内の各部を制御するＣＰＵ（Central Processing Unit）である。

ＲＯＭ１０２は、ＣＰＵ１０１が実行するプログラム等を保持するＲＯＭ（Read Only Memory）である。ＲＡＭ１０３は、ＣＰＵ１０１が使用するメモリ領域を提供するＲＡＭ（Random Access Memory）である。

通信インタフェース１０４は、外部のネットワークと接続するためのインタフェースである。描画モジュール１０５は、ＣＰＵ１０１から入力するグラフィックデータ（画像データ）およびテキストデータに基づいて、ディスプレイ１０６への表示を制御するものである。ディスプレイ１０６は、描画モジュール１０５の出力を表示する表示器である。

音源１０７は、図３のMIDI Track Chunk内に格納されたＭＩＤＩ形式のメロディデータ（演奏データ）を解釈し、ＦＭ（Frequency Modulation）方式やＷＴ（Wave Table）方式によってデジタル楽音データを生成する音源である。図３のファイルフォーマットについては後述する。

ＤＳＰ部１０８は、圧縮形式のオーディオデータに対してリアルタイムでのデコード処理等を行うＤＳＰ（Digital Signal Processor）である。Ｄ／Ａ部１０９は、ＤＳＰ部１０８でデコードされたオーディオデータまたは、音源１０７で生成されたデジタル楽音データをアナログ音声信号に変換するＤＡＣ（Digital-to-Analog Converter）である。

スピーカ１１０（オーディオデータ再生手段）は、Ｄ／Ａ部１０９で変換されたアナログ音声信号を発音するスピーカである。バスライン１１１は、携帯電話機内の各部を相互に接続するバスラインである。

なお、本実施形態の携帯電話機１は図１に示した機能以外に電話機能を備えているほか、電子メールによるファイルを送受信する機能およびインターネットによりファイルを取得する機能を備えている。

図２は、受信側の携帯電話機１と送信側の配信サーバ２とで構成されるシステムにおける機能構成図を示す図である。図２において、配信サーバ２内のデータディスク２１は、多くのマルチメディアファイルを格納するメモリである。

図３は、マルチメディアファイルのフォーマット構造の一例を示した図である。図３において、フォーマット構造内のデータはChunk単位で管理される。Contents Info Chunkには、コンテンツの種別やコンテンツ複製許可等の、ファイル管理用のデータが格納される。

Optional Data Chunkには、楽曲データの固有情報が含まれ、Master Audio Track Chunkの情報を示すデータが格納される。具体的には、ＭＰ３、ＡＡＣ ＨＥといった圧縮オーディオの種別情報と、Master Audio Track Chunk中の圧縮オーディオのデータを格納する位置のファイル先頭からのポインタ（以下では、オーディオポインタと呼ぶ。）と、当該圧縮オーディオデータがモノラルかステレオかを示す情報と、当該圧縮オーディオデータのビットレート情報である。

なお、特許請求の範囲に記載のヘッダとは、図３のContents Info Chunk及びOptional Data Chunkを指し、位置情報とはオーディオポインタを指す。また、圧縮情報とは、上述の圧縮オーディオの種別情報や、モノラルかステレオかの情報、ビットレート情報等を指す。

MIDI Track Chunkには、音源１０７によって再生されるシーケンスデータ等が格納される。Setup Data Chunkには、MIDI Track Chunk全体における設定パラメータや音色パラメータ、エフェクトデータ等が格納される。Sequence Data Chunkには、音源１０７によって再生されるシーケンスデータが格納される。

ここで、シーケンスデータとは、時間情報を持つＭＩＤＩイベントの集合体である。ＭＩＤＩイベントは、例えば、発音イベント（ノートオン／オフ）や音色イベント（プログラムチェンジ）、音量変更やパンポット変更のためのイベント（コントロールチェンジ）、ピッチ変更イベント（ピッチチェンジ）等である。

Graphics Track Chunkには、ディスプレイ１０６に表示を行うための描画シーケンスデータ、グラフィックデータ（画像データ）、テキストデータ等が格納される。Setup Data Chunkには、Graphics Track Chunk全体における設定パラメータが格納される。Sequence Data Chunkには、ディスプレイ１０６に描画するためのシーケンスデータが格納される。

ここで、シーケンスデータは、座標を指定するための数値表現（Coordinates）と表示タイミングや表示時間長等を指定するための数値表現（Duration）で表され、テキストや画像を時間に同期して表示、消去するためのシーケンスが記述される。

Graphics Track Chunkは複数の仮想プレーンを持つ表示デバイスを想定しており、Graphics Track Chunkには各仮想プレーンに対応したSequence Data Chunkを複数格納することができる。この場合、実際の表示デバイス（ディスプレイ１０６）には仮想プレーンを合成した結果が表示される。Master Audio Track Chunkには圧縮オーディオのバイナリデータが格納される。

図３に示したマルチメディアファイルフォーマットにおいては、ストリーミング再生を可能とするために、Master Audio Track Chunkをフォーマットの最後に配置し、最後に受信されるようにする。なお、ストリーミング再生中に必要としないデータはMaster Audio Track Chunkの後方に配置してもよい。

図２に戻って、配信サーバ２内のファイルコントローラ２２は、ユーザからの楽曲のリクエストを受けると、リクエストされた楽曲に対応するマルチメディアファイルをデータディスク２１から読み込み、送信コントローラ２３へと出力するものである。送信コントローラ２３は、ファイルコントローラ２２からの指示に基づき、入力したマルチメディアファイルのストリーム送信を行うものである。

携帯電話機１内の受信コントローラ１１はＣＰＵ１０１の一機能であり、送信コントローラ２３からストリーム送信されたデータを受信し、逐次メモリバッファ１２へと格納するものである。メモリバッファ１２は、ストリーミング再生を行うためのバッファメモリとして図１のＲＡＭ１０３内に設けられたメモリ領域である。

プレイヤー１３は、ＣＰＵ１０１の一機能であり、メモリバッファ１２からマルチメディアファイルの情報を逐次読取り、マルチメディアファイル中に含まれる各種データを必要なデコーダモジュールに送るものである。

また、プレイヤー１３は、マルチメディアファイル中のそれぞれのSequence Data Chunk内のシーケンスデータの時間を管理し、シーケンスに従い、それぞれのモジュールに指示するものである。音源１０７は、前述したとおり、ＭＩＤＩデータをリアルタイムに解釈しデジタル楽音データを出力するモジュールである。

オーディオデコーダ１４は、図１のＤＳＰ部１０８の一機能であり、ＭＰ３やＡＡＣといった特定の圧縮オーディオフォーマットから、リニアなオーディオフォーマットにリアルタイムでデコードするものである。音源１０７及びオーディオデコーダの出力はミックスされてＤ／Ａ部１０９へ入力され、スピーカ１１０から発音される。

グラフィックデコーダ１５は、図１のＤＳＰ部１０８の一機能であり、マルチメディアファイル中のＪＰＥＧやＰＮＧといった特定のグラフィックデータ（画像データ）を読み取り、ディスプレイ１０６に表示するための実データにデコードするモジュールである。

テキストデコーダ１６は、図１のＤＳＰ部１０８の一機能であり、マルチメディアファイル中の歌詞を記述したテキストデータを読み取り、テキストからフォントに置き換え、ディスプレイ１０６に表示するための実データにデコードするモジュールである。

描画モジュール１０５は、グラフィックデコーダ１５及びテキストデコーダ１６からの出力を元に、描画の時刻シーケンスに従って、歌詞のワイプや画像の移動、表示切替などの処理を行い、ディスプレイ１０６に表示するものである。

次に、上述した実施形態の動作を、図２の機能構成図及び図４のフローチャートを参照して説明する。図４は、図１の携帯電話機１でマルチメディアファイルのストリーミング再生を行う手順を示すフローチャートである。

携帯電話機１のユーザが配信サーバ２に対して楽曲のリクエストを行うと、配信サーバ２内のファイルコントローラ２２は、リクエストされた楽曲に対応するマルチメディアファイルをデータディスク２１から読み込み、送信コントローラ２３を経由してストリーム配信を開始する。

送信コントローラ２３からストリーム配信されたデータを携帯電話機１内の受信コントローラ１１が受信すると、逐次メモリバッファ１２に格納していく。プレイヤー１３は、メモリバッファ１２にデータが格納され始めると、メモリバッファ１２からマルチメディアファイルの読み込みを開始する（ステップＳ４０１）。

プレイヤー１３は、最初に受信するマルチメディアファイルのContents Info Chunk及びOptional Data Chunkから、ファイル内に含まれる圧縮オーディオデータの情報を取得する（ステップＳ４０２）。プレイヤー１３は、圧縮オーディオ種別情報などの各種情報を読み込んでオーディオデコーダ１４に登録し、オーディオデータのデコードを行えるように準備を行う。また、プレイヤー１３はファイル中の圧縮オーディオデータの位置を示すオーディオポインタをセットする（ステップＳ４０３）。

プレイヤー１３が、次に受信するMIDI Track Chunkを読み込むと（ステップＳ４０４）、ＭＩＤＩデータ中のシーケンスデータを読み込み、マルチメディアファイルの再生スタートと同時に音源１０７へ時刻シーケンスに従ってイベントを送信できるように準備する（ステップＳ４０５）。

プレイヤー１３が、次に受信するGraphic Track Chunkを読み込むと（ステップＳ４０６）、Graphic Track Chunk中のＪＰＥＧやＰＮＧといった特定のグラフィックデータ（画像データ）を読み取り、マルチメディアファイルの再生スタートと同時にディスプレイ１０６へ時刻シーケンスに従って表示できるように準備する（ステップＳ４０７）。

プレイヤー１３が、メモリバッファ１２における読み込み位置がステップＳ４０３でセットしたオーディオポインタの位置まで到達したかを判定する（ステップＳ４０８）。メモリバッファ１２からプレイヤー１３が読み込むファイルポインタの位置がオーディオポインタの位置まで到達すると、すなわち、メモリバッファ１２がマルチメディアファイル中の圧縮オーディオデータを格納し始めていることが確認されると（ステップＳ４０８：Ｙｅｓ）、マルチメディアファイル全体のストリーミング再生が開始される（ステップＳ４０９）。

ストリーミング再生が開始されると、プレイヤー１３はメモリバッファ１２からMaster Audio Track Chunkに格納されている圧縮オーディオデータを逐次読み込み、オーディオデコーダ１４へと出力する。オーディオデコーダ１４は、入力した圧縮オーディオデータをリニアなオーディオデータにデコードし、スピーカ１１０から再生する（ステップＳ４１０）。

プレイヤー１３は、ＭＩＤＩデータ部分に関しては、時刻シーケンスに従ってメモリバッファ１２から逐次音源１０７へとイベントを出力する。音源１０７は、入力したイベントにしたがって楽音を生成し、スピーカ１１０から再生する。

なお、オーディオデコーダ１４及び音源１０７からの出力は、Ｄ／Ａ部１０９によりアナログ信号に変換され、アンプ増幅された後にスピーカ１１０から再生される。

一方、グラフィックデータ（画像データ）やテキストデータは、メモリバッファ１２から逐次描画モジュール１０５に出力される。描画モジュール１０５では、描画時刻シーケンスに従って、歌詞のワイプや画像の移動、表示切替などの処理が行われ、ディスプレイ１０６に表示される。

すなわち、ストリーミング再生においては、マルチメディアファイルに圧縮されて含まれるオーディオデータの再生を行いながら、マルチメディアファイル内に示された時刻シーケンスに従って、ＭＩＤＩ音源を再生し、かつ画像やテキストをディスプレイ１０６に表示する。

以後、プレイヤー１３がメモリバッファ１２から読み込む位置がマルチメディアファイルの終了地点に到達するまで、ステップＳ４１０のストリーミング再生を行う。マルチメディアファイルの終了地点まで到達すると（ステップＳ４１１：Ｙｅｓ）、プレイヤー１３はストリーミング処理を終了する。

本実施形態では、ＭＩＤＩデータや画像データ、テキストデータを圧縮オーディオデータより先に受信するようなファイルフォーマットであるため、携帯電話機１が圧縮オーディオデータを受信しストリーミング再生を行う際には、当該オーディオデータと同期してＭＩＤＩデータの再生や画像データ・テキストデータの表示を行うことが可能である。したがって、ＭＩＤＩデータ等のシーケンスデータを含むマルチメディアファイルにおいても、ストリーミング再生を行うことができる。

また、図３に示すファイルフォーマットを用いることにより、オーディオデータにＭＩＤＩデータやテキストデータを加えることが可能であるため、圧縮オーディデータの入ったカラオケやアニメーションのコンテンツ等をストリーミング再生で配信することができる。

以上、本発明の実施形態を詳述してきたが、具体的な構成は本実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。例えば、オーディオデータは特定の形式で圧縮されている必要はなく、圧縮されていないオーディオデータに対しても本発明を適用できる。

本発明は、オーディオデータのストリーミング再生が可能な携帯電話機等のオーディオ再生装置に用いて好適である。

本発明の実施形態に係る携帯電話機の構成を示す構成図である。 受信側の携帯電話機１と送信側の配信サーバ２とで構成されるシステムにおける機能構成図を示す図である。 マルチメディアファイルのフォーマット構造の一例を示した図である。 図１の携帯電話機１でマルチメディアファイルのストリーミング再生を行う手順を示すフローチャートである。 ストリーミング再生を示す模式図である。

符号の説明

１１…受信コントローラ（受信手段）、１２…メモリバッファ（バッファ手段）、１３…プレイヤー（制御手段）、１４…オーディオデコーダ（オーディオデコード手段）、１５…グラフィックデコーダ、１６…テキストデコーダ、２１…データディスク、２２…ファイルコントローラ、２３…送信コントローラ、１０１…ＣＰＵ、１０２…ＲＯＭ、１０３…ＲＡＭ、１０４…通信インタフェース、１０５…描画モジュール、１０６…ディスプレイ（シーケンスデータ再生手段）、１０７…音源、１０８…ＤＳＰ部、１０９…Ｄ／Ａ部、１１０…スピーカ（オーディオデータ再生手段）、１１１…バスライン

Claims (3)

1. オーディオデータと、当該オーディオデータと同期して再生されるシーケンスデータと、当該オーディオデータが格納された位置を示す位置情報とを含むマルチメディアファイルであって、前記オーディオデータが前記シーケンスデータ及び前記位置情報より後に受信されるように配置されたファイルフォーマットのマルチメディアファイルを受信する受信手段と、
   前記受信手段で受信したマルチメディアファイルを逐次格納するバッファ手段と、
   前記オーディオデータを再生するオーディオデータ再生手段と、
   前記シーケンスデータを再生するシーケンスデータ再生手段と、
   前記バッファ手段に格納されたマルチメディアファイルを読み込み、前記オーディオデータ再生手段及び前記シーケンスデータ再生手段を制御する制御手段と
   を具備し、
   前記制御手段は、前記バッファ手段から読み込む前記マルチメディアファイルの読み込み位置が前記位置情報によって示される位置に到達したときに、前記バッファ手段が前記マルチメディアファイル中のオーディオデータを格納し始めたと判断し、前記オーディオデータのストリーミング再生と前記シーケンスデータの再生を開始することを特徴とするオーディオ再生装置。
2. 前記シーケンスデータは、演奏データ、画像データ、テキストデータのいずれかを含むことを特徴とする請求項１に記載のオーディオ再生装置。
3. 前記オーディオデータは圧縮されたデータであり、
   前記マルチメディアファイルは、前記オーディオデータの圧縮形式に関する圧縮情報をさらに含み、
   前記圧縮されたオーディオデータを伸張して前記オーディオデータ再生手段へと出力するオーディオデコード手段をさらに具備し、
   前記制御手段は、前記バッファ手段から前記圧縮情報を読み込むと、当該圧縮情報を前記オーディオデコード手段に登録することを特徴とする請求項１又は請求項２に記載のオーディオ再生装置。

Images