(57)【要約】  Musical Instrument Digital Interface (MIDI) プロトコルなどに従ってマルチメディア信号を構成または分解する方法および装置。信号は、予め定義されたパッチのうちのどれを再生に使用すべきか、予め定義されたノートのうちのどれを再生すべきかついての、装置に対する命令を保持するように構成されている第１タイプのイベントと、第１タイプのイベントとは別に識別可能であり、追加コンテンツを保持するように構成されている第２タイプのイベントとを保持するように構成されている。マルチメディア信号を分解する方法は、信号を解析して第２タイプのイベントを識別し、追加コンテンツを読み出すステップと、追加コンテンツで指定されたアドレスのマルチメディア・コンテンツの符号化サンプルをロードするステップと、符号化サンプルを復号化してマルチメディア・コンテンツの再生のために復号化サンプルを提供するステップとを有する。それによって、広く使用されているMIDIプロトコルによって効率の良い方法でボーカル・ソングまたはボーカルおよび他のオーディオタイプの信号を伝達することが可能である。
2007514971.tif 000002
【特許請求の範囲】
【請求項１】
出力装置に対する命令の形式でコンテンツを保持するように構成されている第１タイプのイベント (407) と、
マルチメディア・コンテンツの符号化サンプルを識別するアドレスを含む追加コンテンツ (410) を保持するように構成されている第２タイプのイベント (406) と
を含むマルチメディア信号 (401; 409) 、を提供する方法であって、
前記第１タイプのイベントに応答してマルチメディア出力を生成するステップと、
前記マルチメディア信号 (401; 409) を解析 (602) して、前記第２タイプのイベント (406) を識別するとともに、追加コンテンツ (410) を読み出すステップと、
前記アドレスによって識別されるマルチメディア・コンテンツ (402) の前記符号化サンプルをロードするステップ (607) と、
前記符号化サンプルを復号化 (611) して、前記マルチメディア・コンテンツの再生のために復号化サンプルを提供するステップと、
前記第２タイプのイベントに関連付けられているタイミング情報に従って前記復号化サンプルを前記生成されたマルチメディア出力に重畳するステップ (609) と
を有することを特徴とする方法。
【請求項２】
前記タイミング情報は、基準時刻に対する時間を定義するデルタタイム値を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記第２タイプのイベントは、符号化サンプルを識別する１または２以上の予め定められたコマンドのテキスト情報を含むことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記重畳は、前記タイミング情報に基づいて前記復号化サンプルを前記マルチメディア出力と同期することを含むことを特徴とする請求項１から３までのいずれかに記載の方法。
【請求項５】
前記マルチメディア信号および前記符号化サンプルは、コンテナデータ項目に含まれることを特徴とする請求項１から４までのいずれかに記載の方法。
【請求項６】
前記第２タイプのイベント (406) は、Musical Instrument Digital Interface (MIDI) 仕様で定義されたシステム・エクスクルーシブ・イベントを含むことを特徴とする請求項１から５までのいずれかに記載の方法。
【請求項７】
前記第２タイプのイベント (406) は、Musical Instrument Digital Interface (MIDI) 仕様で定義されたメタ・イベントを含むことを特徴とする請求項１から６までのいずれかに記載の方法。
【請求項８】
前記第２タイプのイベント (406) は、16進数FF 07によって識別される、cue-pointタイプのメタ・イベントを含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記第２タイプのイベント (406) は、16進数FF 05によって識別される、lyricタイプのメタ・イベントを含むことを特徴とする請求項７に記載の方法。
【請求項１０】
前記第２タイプのイベント (406) は、16進数FF 01によって識別される、textタイプのメタ・イベントを含むことを特徴とする請求項７に記載の方法。
【請求項１１】
アドレスが、前記マルチメディア信号に関連付けられている第１のファイル (402; 303) の位置を示すことを特徴とする請求項１から１０までのいずれかに記載の方法。
【請求項１２】
前記マルチメディア信号は第２のファイル (302) に格納されることを特徴とする請求項１から１１までのいずれかに記載の方法。
【請求項１３】
前記追加コンテンツは、前記符号化サンプルの符号化に使用される符号化方式のタイプの指示を含むことを特徴とする請求項１から１２までのいずれかに記載の方法。
【請求項１４】
前記マルチメディア信号は、Musical Instrument Digital Interface (MIDI) 通則に準拠することを特徴とする請求項１から１３までのいずれかに記載の方法。
【請求項１５】
前記装置に対する命令の形式でコンテンツを保持するように構成されている第１タイプのイベント (407) と、
マルチメディア・コンテンツの符号化サンプルを識別するアドレスを含む追加コンテンツを保持するように構成されている第２タイプのイベント (406) と
を含むマルチメディア信号 (401; 409) 、を提供する装置であって、
前記第１タイプのイベントに応答してマルチメディア出力を生成する再生ユニット (202) と、
前記第２タイプのイベント (406) を識別するとともに、前記追加コンテンツ (410) を読み取すパーザ (201) と、
前記アドレスによって識別されるマルチメディア・コンテンツの前記符号化サンプルをロードし、デコーダに、前記マルチメディア・コンテンツのその後の再生のために、復号化サンプルを復号させるインターフェイス (204) と、
前記復号化サンプルの再生を前記マルチメディア出力の生成と同期させる同期ユニット (210) と
を有することを特徴とする装置。
【請求項１６】
前記マルチメディア信号は、Musical Instrument Digital Interface (MIDI) 通則に準拠することを特徴とする請求項１に記載の装置。
【請求項１７】
前記タイミング情報は、基準時刻に対する時間を定義するデルタタイム値を含むことを特徴とする請求項１５または１６に記載の装置。
【請求項１８】
前記第２タイプのイベントは、符号化サンプルを識別する１または２以上の予め定められたコマンドのテキスト情報を含むことを特徴とする請求項１５から１７までのいずれかに記載の装置。
【請求項１９】
前記マルチメディア信号および前記符号化サンプルは、コンテナデータ項目に含まれることを特徴とする請求項１５から１８までのいずれかに記載の装置。
【請求項２０】
前記第２タイプのイベント (406) は、Musical Instrument Digital Interface (MIDI) 仕様で定義されたシステム・エクスクルーシブ・イベントを含むことを特徴とする請求項１５から１９までのいずれかに記載の装置。
【請求項２１】
前記第２タイプのイベント (406) は、Musical Instrument Digital Interface (MIDI) の仕様で定義されたメタ・イベントを含むことを特徴とする請求項１５から１９までのいずれかに記載の装置。
【請求項２２】
前記第２タイプのイベント (406) は、16進数FF 07によって識別される、cue-pointタイプのメタ・イベントを含むことを特徴とする請求項２１に記載の装置。
【請求項２３】
前記第２タイプのイベント (406) は、16進数FF 05によって識別される、lyricタイプのメタ・イベントを含むことを特徴とする請求項２１に記載の装置。
【請求項２４】
前記第２タイプのイベント (406) は、16進数FF 01によって識別される、textタイプのメタ・イベントを含むことを特徴とする請求項２１に記載の装置。
【請求項２５】
アドレスが、前記マルチメディア信号に関連付けられている第１のファイル (402; 303) の位置を示すことを特徴とする請求項１５から２４までのいずれかに記載の装置。
【請求項２６】
前記マルチメディア信号は第２のファイル (302) に格納されることを特徴とする請求項１５から２５までのいずれかに記載の装置。
【請求項２７】
前記追加コンテンツは、前記符号化サンプルの符号化に使用される符号化方式のタイプの指示を含むことを特徴とする請求項１５から２６までのいずれかに記載の装置。
【請求項２８】
データ処理装置上で実行されたときに、請求項１から１４までのいずれかに記載の方法を実行するように構成されたプログラム・コード手段を有することを特徴とするコンピュータ・プログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア信号、特にMusical Instrument Digital interface (MIDI) 仕様に従ってマルチメディア信号を提供する方法に関する。MIDI仕様によれば、マルチメディア信号は、どのパッチを再生に使用すべきか、どのノート (notes) を再生すべきか、およびどのサウンド・レベルで各ノートを再生すべきかの命令をユニットに伝送するように構成されている第１タイプのイベントによって、楽曲の記述を保持する。MIDI仕様によれば、オプションとして、追加コンテンツを保持するように構成された第２タイプのイベントの使用が可能である。
【０００２】
また、本発明は、マルチメディア信号を提供するユニットに関する。
【背景技術】
【０００３】
Musical Instrument Digital Interface (MIDI) プロトコルは、演奏情報を電子データとして伝達する、標準化された効率の良い手段である。MIDI情報は「MIDIメッセージ」により送信される。「MIDIメッセージ」は、音楽の一部をどのように再生するかを音楽シンセサイザに伝える命令と考えることができる。MIDIデータを受信したシンセサイザは、実際のサウンドを生成する必要がある。サウンドは、例えば標本化されてウェーブ・テーブルに格納された、予め定義されたサウンドから生成される。ウェーブ・テーブルは、楽器を定義し、楽器のオーディオサンプルを含む。これと関連して、インストルメント・マップは、各楽器名がプログラム番号としても知られている0〜127の番号に関連付けられた、楽器名の集まりである。したがって、インスツルメント・マップ自体には、楽器の音がどのようであるかについての情報は含まれてはいない。また、インスツルメント・マップは、128未満の楽器しか指定できない。さらに、いわゆるパッチ (patch) は、プログラムの別の名前であり、特定の楽器 (0〜127の数値によって指定される) または特定のドラムキットを表す。一般のMIDI仕様は、ピアノ、フルート、トランペット、様々なドラムなど、128の楽器を含む標準的な楽器のセットを定義している。MIDIプロトコルの網羅的な説明は、カリフォルニア州ロサンゼルスのMIDI Manufacturers Associationによって発行されたMIDI Detailed Specificationに公開されている。
【０００４】
MIDIプロトコルは、もともと、音楽家がシンセサイザをつなげて調和させることができるように開発されたものであるが、現在では、ゲームやマルチメディア・アプリケーションにおけるデジタルオーディオにとって代わる、または補うための配信媒体として、利用範囲の広がりを見せている。オーディオMIDIシンセサイザでサウンドを生成することには、ディスクやCD-ROMからサンプリングされたオーディオを使用する場合に対して、いくつかの利点がある。第１の利点は、記憶スペースである。パルス符号化変調 (PCM) フォーマット (.WAVファイルなど) でデジタルサンプリングされたオーディオを記憶するために使用されるデータ・ファイルはかなり大きなサイズになることが多い。これは、特に、高いサンプリング・レートでステレオ記録された非常に長い音楽作品 (musical piece) の場合にそうである。
【０００５】
一方、MIDIデータ・ファイルは、サンプリングされたオーディオファイルと比べるとかなり小さい。例えば、高品質ステレオのサンプリングオーディオを含むファイルは、サウンド１分当たり約10Mバイトのデータを必要とする一方、一般のMIDIシーケンスは、サウンド１分当たり10Kバイト未満のデータしか消費しない可能性がある。これは、MIDIファイルは、サンプリングオーディオデータを含んでおらず、シンセサイザがサウンドを再生するのに必要な命令のみを含んでいるからである。これらの命令は、どのパッチを使用すべきか、どのノートを再生すべきか、および各ノードを再生するのにどれだけ大きくするかを、シンセサイザに指示するMIDIメッセージの形式を有する。実際のサウンドは、シンセサイザによって生成される。MIDIを使用してサウンドを生成する他の利点は、音楽を容易に編集することができ、また、再生速度や、サウンドのピッチまたはキーを別個に変更できる点にある。
【０００６】
このMIDIデータ・ストリームの受信は、一般にMIDIサウンド・ジェネレータまたはサウンド・モジュールで行われ、そのMIDI INコネクタでMIDIメッセージを受信し、サウンドを再生することによってこれらのメッセージに応答する。
【０００７】
MIDIファイルは、イベントごとの時間情報とともに、１または２以上のMIDIストリームを含む。イベントは、正規のMIDIコマンド、または歌詞または速さの情報を保持することができるオプションのメタ・イベントとすることができる。「Lyrics」および「Tempo」は、こうしたメタ・イベントの例である。歌詞、シーケンス、およびトラックの構造、速さおよび時間署名の情報は、すべてサポートされている。さらに、トラック名および他の記述的情報を、MIDIデータとともにメタ・イベントとして格納することができる。
【０００８】
MIDIファイルは、チャンクから成る。MIDIファイルは、常にヘッダー・チャンクで始まり、１または２以上のトラック・チャンクが続く。基本的に、チャンクは、チャンクのサイズを示す値および一連のメッセージを含む。
【０００９】
MIDIプロトコルのこの構造によって、予め定められたサウンドをその楽曲で使用されている楽器のノートに使用するために、楽曲のインストルメント部の非常に効率の良い表現が可能になる。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかし、ボーカル・ソングまたはボーカルが楽曲のかなりの部分を占めることが多い。MIDIプロトコルは、ボーカル・ソングまたはボーカル、または楽曲のボーカル・ソングまたはボーカル部分を処理するには不十分であることもある。これは、適切なMIDIマップからトーンを再生することによってボーカル・ソングまたはボーカルを表現することができないからである。
【００１１】
メモリ消費の観点から、楽曲は、一般にはパルス符号化変調によってサンプリングされ、効率の良い記憶のための符号化によって圧縮され、再現 (reproduction) または再生 (playback) の際に復号化される。符号化／復号化方式の典型例としては、MPEG layer 3 (MPEG=Moving Picture Experts Group) であるMP3、AMR (Adaptive Multi Rate) 、およびAAC (Advanced Audio Codec) がある。しかし、圧縮フォーマットであろうと非圧縮フォーマットであろうと、サンプリングされた楽曲は、そのサンプリング中に、楽曲の個々のノートの操作のために楽曲を記憶する際に従うプロトコルや、ノートをどのように再生するかという情報は失われてしまうため、サンプリングされた楽曲がこの情報を提供することはない。
【００１２】
したがって、楽曲のボーカル・ソングまたはボーカル部とインストルメント部との結合された格納のための効率的な方法がない。
【課題を解決するための手段】
【００１３】
上記および他の問題は、出力装置に対する命令の形式でコンテンツを保持するように構成されている第１タイプのイベントと、マルチメディア・コンテンツの符号化サンプルを識別するアドレスを含む追加コンテンツを保持するように構成されている第２タイプのイベントとを含むマルチメディア信号を提供する方法であって以下の構成を有する方法によって解決される。すなわち、この方法は、
・前記第１タイプのイベントに応答してマルチメディア出力を生成するステップと、
・前記マルチメディア信号を解析して、前記第２タイプのイベントを識別するとともに、追加コンテンツを読み出すステップと、
・前記アドレスによって識別されるマルチメディア・コンテンツの前記符号化サンプルをロードするステップと、
・前記符号化サンプルを復号化して、前記マルチメディア・コンテンツの再生のために復号化サンプルを提供するステップと、
・前記第２タイプのイベントに関連付けられているタイミング情報に従って前記復号化サンプルを前記生成されたマルチメディア出力に重畳するステップと
を有する。
【００１４】
その結果、楽曲のMIDI表現は、ボーカル・ソングまたはボーカル、あるいは他の演奏を伝える効率の良い手段を提供することもできる。ボーカル・ソングまたはボーカルの情報は、一般に、どの楽器パッチを使用すべきか、どの楽器のノートを再生すべきか、およびどのサウンド・レベルで楽器のノートを再生すべきかの判断以外の目的に用いられるイベントの手段によって伝えられるため、楽器の演奏の表現は損なわれない。ボーカル・ソングまたはボーカルの演奏を伝えるイベントの追加コンテンツは、ボーカル・ソングまたはボーカルの演奏を含み得るサンプリングされたマルチメディア・コンテンツの符号化サンプルへのアドレスを含む。そのために、符号化サンプルは、MIDI表現を保持する信号の内部または外部に配置され得る。この信号は、マルチメディア信号と表すことができる。例えば、マルチメディア信号は、MIDI信号および１または２以上の符号化サンプルを含むコンテナ・ファイルとすることができる。一部の実施形態において、符号化サンプルは、マルチメディア信号の外部にある。そのために、MIDI信号であるマルチメディア信号は、符号化サンプルのロードではいっぱいにはならない。圧縮されているにも関わらず、MIDI信号の外部のある位置の符号化サンプルを扱うのは便利であり得る。そのために、MIDI信号を読み取る、ボーカル・ソングまたはボーカルの演奏の再生をサポートしない装置は、符号化サンプルではいっぱいにはならない。その結果、追加コンテンツは、サンプリングされたマルチメディア・コンテンツの符号化サンプルのアドレスを含むため、出力装置は、符号化サンプルにアクセスし、それを復号化し、生成された出力信号に重畳することができる。さらに、特定のマルチメディア成分がMIDIファイル内の複数の場所にある場合、対応する符号化サンプルは、MIDIファイル内の異なるイベントからアドレス指定することができるため、一度提供されるだけでよい。その結果、特に小型のマルチメディア信号を実現することができる。
【００１５】
アドレスは、ファイル名、メモリ・アドレス、ファイルまたはメモリ・セクション内のオフセット、または符号化サンプルの位置への他の任意の適したポインタを含み得る。追加コンテンツは、コマンド・セットの１または２以上のコマンドなどのそれ以上の情報、および/または、符号化サンプルのいくつかの反復、符号化された例の符号化タイプ/方式、MIMEタイプなどのそれ以上の情報またはパラメータを含み得る。
【００１６】
本明細書に記載された方法の利点は、標準MIDIファイルのフレームワーク内で、すなわち既存のMIDI標準を変更する必要なしに、さまざまなマルチメディア・コンテンツを再生する手法を提供できることである。そのため、既存のMIDIシステムとの高度な互換性が確保される。
【００１７】
好ましい実施形態では、この方法は、第１タイプのサンプルを挿入するステップをさらに含む。これによって、同時のストリームでコンテンツを提供するMIDIおよびボーカル・ソングやボーカル/オーディオ/ビデオのソースからマルチメディア信号を構成することができる。あるいは、マルチメディア信号は、ランダム・アクセス・メモリ・タイプで格納されているMIDIおよびボーカル・ソングやボーカル/オーディオ/ビデオ・コンテンツから成っていてもよい。
【００１８】
第２タイプのイベントに関連付けられているタイミング情報に従って符号化サンプルを出力信号に重畳することによって、その異なる成分がMIDI形式によってすべて直接表現可能とは限らない場合でさえ、マルチメディア信号は、それらの正確な相対的なタイミングで表現され得る。
【００１９】
この方法は、第２タイプの各イベントの前にデルタタイム値を挿入するステップを含むことが好ましい。このデルタタイム値は、サンプリングされたマルチメディア・コンテンツの再生を開始する時点を表す。デルタタイム値の使用によって、符号化されたボーカルの演奏の所与の部分または一部が再生されるべきデルタタイムの瞬間を正確に指定することができる。そのために、楽曲の音楽部分とボーカル部分とを同期させるための同期手段が提供される。マルチメディア信号が構成されつつあるとき、デルタタイム・カウンタは、ボーカルの演奏への参照を保持する第２タイプのイベントの前にデルタタイム値を挿入するのに使用するタイムスタンプを取得するために使用することができる。そのために、マルチメディア信号の音楽部分とボーカル部分との構成は、共通のデルタタイム・カウンタを使用することができる。あるいは、ボーカル部分は、音楽部分を保持する第１タイプのイベントの既存のファイルまたはストリーム内のデルタタイム値に対して作られたデルタタイム値で構成することができる。
【００２０】
前述したように、本発明は、マルチメディア信号を提供する装置にも関する。マルチメディア信号は、装置に対する命令の形式でコンテンツを保持するように構成されている第１タイプのイベントと、マルチメディア・コンテンツの符号化サンプルを識別するアドレスを含む追加コンテンツを保持するように構成されている第２タイプのイベントとを含む。そしてこの装置は、
前記第１タイプのイベントに応答してマルチメディア出力を生成する再生ユニットと、
前記第２タイプのイベントを識別するとともに、前記追加コンテンツを読み取すパーザと、
前記アドレスによって識別されるマルチメディア・コンテンツの前記符号化サンプルをロードし、デコーダに、前記マルチメディア・コンテンツのその後の再生のために、復号化サンプルを復号させるインターフェイスと、
前記復号化サンプルの再生を前記マルチメディア出力の生成と同期させる同期ユニットと
を有する。
【００２１】
好適な実施形態において、第２タイプのイベントは、Musical Instrument Digital Interface (MIDI) の仕様で定義されるようなシステム・エクスクルーシブ・イベントを含む。システム・エクスクルーシブ・イベントは、いわゆるsysexイベントとも呼ばれ、中央機関で発行され登録された製造業者自体の識別番号に関連付けられるように定義される。通常、詳細なシステム・エクスクルーシブ・イベントは、4つの成分として格納される。第１は16進数「F0」を有する識別子、第２は「F0」の後送信されるバイト数の16進数値、第３は追加コンテンツ、第４は16進数「F7」を有する終了文字（terminator）である。本発明によれば、追加コンテンツは、符号化されたオーディオデータを取り出すべきアドレスを含む。
【００２２】
第２タイプのイベントがMusical Instrument Digital Interface (MIDI) 仕様で定義されているようなメタ・イベントを含む場合には、追加的な楽曲表現が可能になる。
【００２３】
好ましい実施形態において、第２タイプのイベントは16進数FF 07によって識別されるcue-pointタイプのメタ・イベントを含む。cue-pointイベントは、3つの成分を含み、第１は16進数「FF 07」を有する識別子であり、第２は「FF 07」の後に送信されるバイト数の16進数値であり、第３は追加コンテンツである。
【００２４】
第２タイプのイベントは、16進数FF 05によって識別されるLyricタイプのメタ・イベントを含むことが好ましい。
【００２５】
また、第２タイプのイベントは、16進数FF 01によって識別されるtextタイプのメタ・イベントを含むことが好ましい。
【００２６】
アドレスがマルチメディア信号に関連付けられている第１のファイル内のある部分を示す場合には、個別にアドレス指定することができる符号化サンプルの複数のチャンクをファイルが含むことができるという点で、マルチメディア信号を配信する柔軟性の向上が得られる。さらに、符号化サンプルの特定のチャンクを、信号内で複数回アドレス指定することができる。これは、符号化サンプルの再利用、したがって、マルチメディア・コンテンツのそれ以上の圧縮を行うことができる。アドレスは、ファイル内のバイト・カウントまたは位置、あるいはファイル内のフレーム番号またはチャンク番号を示すことができる。さらに、または代わりに、アドレスは、ローカルまたはリモートに格納されているファイルへのポインタを含むことができるUnified Resource Locator (URL) を含むことができる。
【００２７】
好適な実施形態によれば、マルチメディア信号は、第２のファイルに格納される。第２のファイルは、標準MIDIファイルとすることができる。第１のファイルおよび第２のファイルは、ファイルの効率の良い転送を可能にする共通のファイル・コンテナに組み込まれることが好ましい。
【００２８】
追加コンテンツは、符号化サンプルの符号化に使用される符号化方式のタイプの指示を含み得る。そのために、例えば、改良された新しい方式が開発された結果として、あるいは、他の方式の中から最も効率の良いと判断される方式を選択することができるようにするために、複数の符号化/復号化方式のうちの１つを選択することができる。
【発明を実施するための最良の形態】
【００２９】
以下、図面を参照して、本発明を詳しく説明する。
【００３０】
図１は、マルチメディア信号を作成する装置を示す図である。装置100は２つの主な信号経路を含む。第１の経路は、キーボードや別の楽器などのMIDI生成装置またはシーケンサのOUTポートからMIDIメッセージが供給される経路であり、第２の経路は、サンプリングされたオーディオが受信され、符号化され、記憶され、オーディオまたはオーディオのデコーダへの命令が挿入される経路である。ここで、シーケンサという用語は、MIDIの楽曲をオフラインで作成するように構成されているコンピュータ・プログラム、およびMIDIファイルを実行するように構成されているハードウェアまたはソフトウェアを含むものとする。
【００３１】
装置100の第１の信号経路は、MIDI仕様に従って、信号またはファイルを受信することができるMIDI INポート104を含む。これらの信号はマージャ (merger) 105に渡され、ここでポート104上で受信された信号が第２の信号経路を介して提供された信号とマージされる。第１の経路を介して提供される信号は、MIDIイベント、およびオプションでMIDIヘッダーおよび他のよく知られているMIDI情報を含むMIDIメッセージを含む。なお、マージャは、加算器 (adder) という場合もある。
【００３２】
装置100の第２の信号経路は、オーディオ信号および/またはビデオ信号をサンプリングして、サンプリングされたオーディオ信号またはビデオ信号を提供するサンプラ101を含む。したがって、これらのサンプルは、オーディオおよび/またはビデオを含み得るマルチメディア・コンテンツを表すことができる。一般に、オーディオ信号は、20Hz〜20KHzの周波数帯域を有するが、ボーカル・ソングまたはボーカルの演奏を伝えるオーディオ信号は、約100Hz〜5KHzの周波数帯域にのみ存在している。このため、ボーカルを含むメロディに必要なものよりかなり低いビット・レートで、ボーカルのみの符号化が可能になる。別の実施形態では、サンプラ101は、パルス符号変調サンプルなど、サンプリングされたオーディオおよび/またはサンプリングされたビデオを受信するように構成されている入力ポートによって置き換えられる。
【００３３】
サンプリングされたオーディオ/ビデオ信号はエンコーダ102に送信され、そのサンプリングされたオーディオ/ビデオ信号が圧縮フォーマットに符号化される。したがって、エンコーダからの第１の出力は、圧縮フォーマットのファイルまたは信号、またはより一般的にはデータである。このファイルまたは信号は、サンプル・バンク106に格納され、そこから圧縮フォーマットのファイルまたは信号をその後のデコードのために取り出すことができる。エンコーダからの第２の出力は、圧縮フォーマットのファイルまたは信号のアドレスを含む。第１の出力は、オーディオの場合、MPEG1 layer 3 (MPEG=Moving Picture Experts Group) であるMP3、AMR (Adaptive Multi Rate) 、およびAAC (Advanced Audio Codec) 、ビデオの場合、いわゆるブロックベースの予測差分ビデオ符号化方式 (predictive differential video coding scheme) であるMPEG-4ビデオ符号化など、周知の符号化方式によって生成することができる。第２の出力におけるアドレスは、圧縮フォーマットのファイルまたは信号が格納される場所を登録することによって生成される。
【００３４】
イベント・インサータ103は、格納された圧縮フォーマットのファイルおよびそのアドレスに基づいて、MIDI仕様に従ってイベントを生成するように構成されている。イベントは、MIDI仕様で定義されているようなシステム・エクスクルーシブ (Sysex) タイプまたはメタ・タイプのものとすることができる。アドレスは、イベントのタイプの指定の後ろ、および後に続くバイト数の指定の後ろに挿入される。
【００３５】
MIDI仕様によれば、システム・エクスクルーシブ・イベントの構文はF0＜length＞＜bytes to be transmitted after F0＞である。ここで、F0は、イベントのタイプがSysexイベントであると識別する識別子である。識別子の後に、イベントの次に続くバイトのバイト長を示す値を含むフィールド＜length＞が続く。また、本発明の観点によれば、フィールド＜bytes to be transmitted after F0＞は、追加コンテンツを表す。この後者のフィールドに、圧縮フォーマットのデータおよび他の任意の情報をアドレス指定する情報が含められる。
【００３６】
システム・エクスクルーシブの使用の非常に簡単な例は、MIDI仕様、および本発明の一態様によるイベントの次のフラグメントのように表すこともできる。
【００３７】
64
F0 09 7D 7F xx xx 00 00 00 B7
【００３８】
第１行目において、64HEXは、100ティックのデルタタイムに、指定されたティック期間で次のイベントが実行されるべきであることを示す。第２行目において、F0は、システム・エクスクルーシブ・イベントの開始を示す。09 HEXは、F0コードの後に続くバイト数を示す。次の位置で、コード7Dは、イベントは研究用のものであり、したがってMIDI機器の特定の製造業者によって使用されないことを示す。そのために、本発明に従ってコード7Dを使用することができる。次の位置で、7Fは、すべての装置は使用されているが、使用すべき装置のそれぞれの装置IDを書き込むことによって特定の装置を使用することができることを示す。xx xxで示されている次の２つの位置で、前の位置で示された装置のサブIDを示すことが可能である。続いて、00 00は開始フレームを示し、00 B7は停止フレームを示す。
【００３９】
cue-pointタイプのメタ・イベントでは、構文は、FF 07＜length＞＜text＞である。ここで、FF 07は、イベントのタイプを識別する識別子である。識別子の後に、イベントの次に続くバイトのバイト長を示す値を含むフィールド＜length＞が続く。また、本発明の観点では、フィールド＜text＞は、追加コンテンツを表す。この後者のフィールドに、圧縮フォーマットのデータおよび他の任意の情報をアドレス指定する情報が含められる。
【００４０】
したがって、cue-pointタイプのメタ・イベントに相当する例は、次のフラグメントのように表すこともできる。
【００４１】
64
FF 07 05 00 00 00 B7
【００４２】
この場合も、第１行目の64HEXは、100ティックのデルタタイムで次のイベントが実行されるべきであることを示している。第２行目で、FF 07は、cue-pointタイプのメタ・イベントの開始を示す。05は、追加コンテンツ00 00 00 B7とともにイベントの長さを示し、00 00は開始フレーム、00 B7は停止フレームを示す。10進表現では、HEX FFで開始する上記の行は、
255 7 5 0 0 0 183
である。HEX表現の代わりにこの表現が好ましい場合がある。
【００４３】
装置100に戻って、加算器105の機能は、第１および第２の信号経路から提供されたイベントを含む信号をマージすることである。これは、昇順または降順に行われる、デルタタイム・スタンプがそれぞれ前に置かれたイベントを加算器からの出力が含むように信号をマージすることによって実行される。
【００４４】
図２は、マルチメディア信号を分解するユニットを示す図である。装置200は、MIDI仕様による信号を２つの信号に分割するように構成されているパーザ201を含む。第１の実施形態において、パーザは、第１タイプのイベントとは別に識別可能である第２タイプのイベントを識別することに基づいている。第２タイプのイベントは、所与の値またはビットパターンによって識別されるイベントとすることができる。したがって、第１タイプのイベントは、第２タイプのもの以外のイベントとして識別することができる。イベントの前に置かれた任意のデルタタイム・スタンプは、次のイベントに続くように分割される。次いで第１タイプのイベントはポートA上に出力され、第２タイプのイベントはポートBに出力される。
【００４５】
第２の代替実施形態では、パーザは、第２タイプのものと決定されるイベントおよびその前に置かれたデルタタイムをコピーしながらすべてのイベントをポートAに渡すように構成されている。
【００４６】
第３の代替実施形態では、パーザは、所与の基準を満たす追加コンテンツの一部分を取り除いた後、そうでない場合は元のままの信号をポートAに送信するように構成されている。所与の基準を満たす追加コンテンツの部分は、識別された追加コンテンツおよび前に置かれた任意のデルタタイム値を含む第２タイプのイベントとともにポートBに転送される。
【００４７】
パーザ201のポートAでの出力は、シンセサイザ202に送信され、ここで受信されたMIDI信号が解釈されて、MIDI信号によって記述された楽曲のアナログまたはデジタルの再現を行う。
【００４８】
パーザ201のポートBでの出力は、インタプリタ203に送信され、ここで追加コンテンツが、追加コンテンツを伝えていたイベントの前に置かれるデルタタイム値とともに解釈される。この解釈は、デルタタイム値によって設定された瞬間に再生するよう意図された圧縮フォーマットのファイルを取り出すべきアドレスの決定を含む。オプションで、インタプリタは、存在している場合は、タイプを示す情報を読み取ることによって圧縮フォーマットのファイルの符号化に使用される符号化方式のタイプを識別することができる。決定されたアドレスに基づいて、圧縮フォーマットのファイルの参照部分がインターフェイス204を介してサンプル・バンク106から取り出される。取り出された部分は、デコーダ205に送信され、ここで符号化サンプルは復号化されて、シンセサイザ202から出力されたアナログまたはデジタルの再生信号とミキシングすることができる信号を提供する。ミキシングされた信号を出力する加算器208によって信号がミキシングされて、増幅器207およびスピーカ209によって再生される。加算器208に供給された2つの信号の間の同期をとるために、同期ブロック210が提供される。この同期ブロックは、デコーダ205に対するシンセサイザ202の動作、またはその逆を制御することによって実施することができる。ただし、同期は、他の方法で実施することもできる。
【００４９】
一実施形態において、インタプリタ203は、符号化サンプルを識別する各メタ・イベントのデルタタイムを、対応するサンプルのプレゼンテーション時間に変換する。プレゼンテーション時間とは、処理ユニットのシステム時間によって決定される時点である。インタプリタは、符号化サンプルの取り出し、およびデコーダ205によって取り出されたサンプルの復号化のためにインターフェイス204にコマンドを送出するとき、対応するサンプルを再生すべきシステム時間を示すプレゼンテーション・タイム・スタンプをコマンドに含む。次いで、符号化サンプルは、対応するシステム時間に処理するように、デコーダ205のキューに入れられる。
【００５０】
なお、「圧縮フォーマットのファイルの参照部分 (referenced portion of the compressed format file) 」という用語は、Compressed Audio Block、CAB、Compressed Video Block、CVB、またはCompressed Multimedia Block、CMBと表すこともできる。
【００５１】
図３は、ファイル・コンテナを示している。ファイル・コンテナ301は、MIDIファイル302および符号化されたオーディオファイル303を含む。オプションで、または代わりに、ファイル・コンテナは、符号化されたビデオ・ファイル304を含むことができる。符号化されたオーディオファイル303および/または符号化されたビデオ・ファイル304は、上記では、サンプル・バンク106と呼ばれる。ファイル・コンテナ301によって、インストルメント部分とボーカル・ソングまたはボーカル部分とを含む完全な楽曲を単一のファイルとして配信することができる。符号化されたオーディオファイル303は、複数のCompressed Audio Blockを含むことができる。コンテナ内の成分は、ストリーミングに適した形式を容易にするために、インターリーブすることができることは明らかであろう。
【００５２】
図４ａは、圧縮オーディオブロック、圧縮ビデオ・ブロックまたは圧縮マルチメディア・ブロック内のデータと、ブロックへのイベントに基づく参照とが結合された、イベントに基づくマルチメディア信号の構造を示している。イベントに基づくマルチメディア信号401は、上述した第１タイプ407 (イベント1) および第２タイプ407 (イベント2) のイベントを含む。構造401は、加算器105によって供給された信号、およびパーザ201によって受信された信号の構造を示している。パーザ201の第２の代替実施形態では、構造は、信号をパーザのポートAで提供されるものとしても表している。
【００５３】
符号化されたオーディオデータ402は、符号化されたオーディオのブロック403および404を含む。これらのブロックは、第２タイプのイベント406のコンテンツに埋め込まれたイベントに基づく参照410によってアドレス指定される。イベントの前に置かれるデルタタイム・スタンプDTは、符号化されたオーディオのそれぞれのブロックの再生を開始する時点を決定する。
【００５４】
図４ｂは、イベントに基づくマルチメディア信号の構造を示している。構造408は、第１タイプのイベント407のみが存在するMIDI信号を示している。従って、符号化されたオーディオまたはビデオへの参照はない。
【００５５】
図４ｃは、符号化オーディオデータと、その符号化オーディオデータへのイベントに基づく参照との構造を示している。構造409は、それぞれ符号化されたオーディオまたはビデオへの参照を備える第２タイプのイベント406を含む。
【００５６】
図５は、マルチメディア信号を構成する方法のフローチャートである。この処理手順は、ステップ501で開始し、ステップ502に進み、時間の単位をカウントするカウンタが開始する。このカウンタは、デルタタイム・カウンタという。その後、ステップ503で、受信されたイベントがMIDI信号であるか、オーディオ/ビデオ信号であるかが検査される。イベントが検出されない場合、処理は、イベントが受信されるまでイベントが受信されるかどうかを引き続き検査する。後者の場合、この処理は、ステップ504に進み、検出されたイベントが、MIDIイベントの到着を表すイベントであるか、符号化されたオーディオブロックの送信の開始または停止を表すイベント (CAB) であるかが検査される。
【００５７】
MIDIイベントが到着した場合、MIDIイベントのデルタタイムが挿入される。その後、MIDIイベントは、ステップ505で、構成されつつあるマルチメディア信号に挿入される。
【００５８】
オーディオ/ビデオのブロックの受信が開始した場合、または受信が終了した場合、ブロックが開始または停止するかどうかが決定される。ブロックの受信が開始した場合、ステップ507で、デルタタイム・カウンタのカウントに基づいてデルタタイム・スタンプが生成される。ステップ508で、メタ・イベントが生成される。オーディオ/ビデオのブロックの完全なアドレスがわからない場合があるため、ポインタは、生成されたメタ・イベントに設定される。その後、符号化されたオーディオブロックのファイル・ストレージへのストリームが開始する。ファイル・ストレージは、ファイル・コンテナ内のオーディオファイルとすることができる。
【００５９】
オーディオ/ビデオのブロックの受信が終了した場合、ステップ508で設定されたポインタによって参照されるメタ・イベントは、格納されているデータにアクセスするための完全な情報を提供するために、任意の残りのアドレス情報で更新される。その後、ステップ511で、符号化されたオーディオブロックのファイルへのストリーミングのプロセスが終了する。
【００６０】
ステップ508、509、または511が完了すると、処理は、ステップ503に戻って、任意のイベントが受信されているかどうかを検査する。しかし、オプションとして、処理を停止するかどうかをステップ512で検査するようにしてもよい。しかし、符号化されたオーディオデータへのデータのストリーミングのプロセス中に処理を停止することは避けるべきである。
【００６１】
図６は、マルチメディア信号を分解する方法のフローチャートである。ステップ601で処理手順が開始し、処理はそこからステップ602に進んで、受信されたMIDIファイルまたは信号を解析する。その後のステップ603で、MIDIファイルまたは信号のイベントが１つずつ選択され、そのタイプが判定される。イベントは、楽器による演奏を伝えるMIDIイベント、またはMIDI仕様で提示される情報および/または符号化されたオーディオデータを探す情報を伝えるメタ・イベントとすることができる。ステップ604で、MIDIイベントはステップ605に渡され、メタ・イベントはステップ606に渡される。
【００６２】
ステップ605で、MIDIイベントは、シンセサイザで楽曲のインストルメント部分を再生するように実行される、あるいはシンセサイザに送信される。
【００６３】
ステップ606で、任意の追加コンテンツを有するメタ・イベント・タイプのものと決定されたイベントは、符号化されたオーディオデータが配置されるアドレスおよび/またはファイル名などを推定するように解釈される。ステップ607で、符号化されたオーディオサンプルのロードが開始され、アドレスによって指定された範囲の間続く。ステップ607の後、経路「a）」は、第１の実施形態を示し、経路「b）」は第２の実施形態を示す。a) 経路に従って、ステップ608で符号化されたオーディオサンプルのデコードが開始される。シンセサイザ605によって生成されたサウンドと符号化されたオーディオとの間の同期を確実にするために、同期は、ステップ609で開始された後、ステップ610で復号化サンプルの再生中維持される。b) 経路に従って、アドレス指定された符号化されたオーディオサンプルは、その後の再生のために、ステップ611でデコーダに送信される。
【００６４】
上記の図２との関連で説明したように、MIDI成分の再生に対する符号化サンプルの再生の同期は、識別された符号化サンプルごとにデルタタイムをプレゼンテーション・タイム・スタンプに変換することによって実行することができる。プレゼンテーション・タイム・スタンプは、サンプルが再生されるべきシステム時間を決定する。次いでタイムスタンプが押されたサンプルは、デコーダに転送される。
【００６５】
図７ａは、マルチメディア信号のエンベロープの概略を示す。エンベロープは、時間tの関数として示される。エンベロープ701は、典型的な2.5分から10分間の楽曲を表している。楽曲は、例示の目的で、4つの部分A1、B、C、およびA2のボーカル・ソングまたはボーカルを含む。
【００６６】
第１の実施形態において、ボーカル・ソングまたはボーカルの部分を、矢線706によって示されるデータの単一のおよび連続するブロックに符号化することができる。
【００６７】
第２の実施形態において、ボーカル・ソングまたはボーカルの部分を、矢線707によって示されるデータのいくつかのブロックに符号化することができる。ブロックは、ボーカル・ソングまたはボーカルの部分のみをカバーするように一時的に構成することができる。各ブロックは、MIDIで、デルタタイム・スタンプ、および記憶メモリ内でブロックをアドレス指定するための追加コンテンツを有するメタ・イベントによって表される。
【００６８】
第３の実施形態において、ブロックは、歌われる歌詞の一部分に対応するボーカル・ソングまたはボーカルの部分をカバーするように一時的に構成することができる。そのために、ボーカル・ソングまたはボーカルの一部分の符号化サンプルがブロックに含まれる。ボーカル・ソングまたはボーカルの一部分が例えば３回繰り返される場合、これらの３つの部分は、同じ部分の再生によって再現可能である。さらに、話し言葉におけるポーズの期間は、話や歌におけるかなりの部分を占めることが考えられるため、たとえ単一の言葉でも複数回の繰り返しによる再生が効率的となり得る。これによりマルチメディア信号をさらに圧縮することができる。
【００６９】
図７ｂは、MIDIイベント、符号化されたオーディオイベント、および再生信号のサンプルの時間的側面を示す図である。例えば44.1や48KHzのサンプル・レートで等間隔に、サンプルが定期的に再生されることが示されている。MIDIイベント711、すなわち第１タイプのイベントは、それほど頻繁ではないレートで、どのパッチを再生に使用すべきか、どのノートを再生すべきか、およびどのサウンド・レベルで各ノートを再生するかについての情報を有するMIDIファイルにおいて生じている。個々のノートの再生はイベントにおいて定義され、異なるノートの同時再生や、オーバーラップ再生なども可能である。これは、イベント内の情報によって決まり、アタック (attack) 、ディケイ (decay) 、サステイン (sustain) 、およびフェード (fade) の期間を含み得る。
【００７０】
本発明による情報を含むイベントの場合、上述した符号化されたオーディオブロックのサイズによって決定されるレートで、メタ・イベント710、すなわち第２タイプのイベントが生じる。これらのイベントは、ボーカル・ソングまたはボーカルの演奏の再生を判定し、符号化されたオーディオブロックの同時再生やオーバーラップ再生、あるいは図７ａに示されている連続再生を行うことが可能である。
【００７１】
一般に、トラック・チャンクは、異なるタイプのイベントを含む。第１タイプのイベントは、いわゆるMIDIイベントであり、第２タイプのイベントは、追加コンテンツを伝送するいわゆるメタ・イベントおよびSysexイベントを含む。各チャンクは、単なるイベントのストリームであり、以下ではデルタタイム値が前に置かれる「Mイベント」とも呼ばれる。構文は次の通りである。
【００７２】
＜track chunk＞=＜length＞＜M event＞+
【００７３】
プラス記号「+」は、一般にフィールド＜M event＞のいくつかが行われることを示す。
【００７４】
Mイベントの構文は非常に簡単である。
【００７５】
＜M event＞=＜delta time＞＜event＞
【００７６】
ここで、＜delta-time＞は可変長の量として格納される。これは、次のイベントの前の時間量を表す。トラック内の第１のイベントがトラックの冒頭で生じる場合、または２つのイベントが同時に生じる場合は、デルタタイムは０とされる。デルタタイムは、常に標準MIDIファイルに存在する。デルタタイムは、ヘッダー・チャンクによってティックで指定される。
【００７７】
＜event＞=＜MIDI event＞|＜sysex event＞|＜meta-event＞
【００７８】
ここで、フィールド＜event＞は、タイプ＜MIDI event＞または＜sysex event＞または＜meta-event＞のうちのいずれか1つとすることができることが示されている。
【００７９】
フィールド＜MIDI event＞は、任意のMIDIチャネル・メッセージを含む。
【００８０】
フィールド＜sysex event＞は、MIDIシステム・エクスクルーシブ・メッセージ (MIDI system exclusive message) を1つの単位として、またはパケットに、または送信されるべき任意のバイトを指定する「エスケープ」として指定するために使用される。本発明によれば、Sysexイベントは、符号化されたオーディオまたはビデオの再生を制御するための直接的または間接的なアドレスまたは命令の形の情報を伝えることができる。sysexイベントのいわゆるマルチパケット態様は本発明の範囲内において適用可能であることに留意されたい。
【００８１】
フィールド＜meta-event＞は、構文FF 07＜length＞＜text＞を含むタイプ「Cue point」のメタ・イベントを含み、フィールド＜text＞は、本発明による追加の情報を伝えることができる。特定のタイプのキュー・ポイントは、個々のイベントの発生を指すことができ、各キュー番号を、特定の単発のサウンド・イベントなど特定の反応に割り当てることができる。特定の単発のイベントは、特定のCAB、CVB、CMBをデコードするためのものとすることができる。この場合、特定のブロックを、指定されたイベント番号に関連付けることができる。
【００８２】
さらに、フィールド＜meta-event＞は、構文FF 05＜length＞＜text＞を含むタイプ「Lyric」、およびFF 01＜length＞＜text＞を含む「テキスト・イベント」のメタ・イベントを含み、フィールド＜text＞は、本発明による追加の情報を伝えることができる。
【００８３】
本発明は、Musical Instrument Digital Interface (MIDI) に限定されないことに留意されたい。イベントが、楽曲内のコンテンツの少なくとも1つの部分的な表現を例えばマルチメディア信号、特にオーディオ信号の形で保持する、すべてのタイプのファイルまたはデータのストリームに対して、本発明の利点を得ることができる。ここで、イベントは、指定されたボーカルおよび/または音楽および/またはビデオおよび/または他のマルチメディア演奏を再生するための瞬時の情報に関連付けられている。しかし、好ましくは、本発明は特に、タイム・ラインのタイプ、およびメタ・イベントのタイプに対して動作するあらゆるプロトコルにも有益である。実際に、3GPPで使用される3GPコンテナは、タイム・ラインに沿ってテキスト・ファイルに添付することができ、テキスト・ファイルは、マルチメディア演奏および/またはこうした情報へのアドレス/ポインタを再現するための情報を含む。
【００８４】
さらに、本発明は、すなわちMIDIおよび音楽および/またはボーカルの演奏との関連で説明されていることに留意されたい。「マルチメディア (multimedia) 」および/または「マルチメディア信号 (multimedia signal) 」および/または「マルチメディア演奏 (multimedia performance) 」という用語は、「オーディオ (audio) 」および/または「オーディオ/信号 (audio/signal) 」および/または「オーディオ演奏 (audio performance) 」をそれぞれ含み、オーディオ (audio) は、音楽 (music) および/またはボーカル (vocals) を含む。本発明は「extensible music format」 (XMF) 、MODファイルなどによるファイルなど、マルチメディア・ファイル/データフォーマットにも適用可能であることは理解されよう。
【００８５】
さらに、本発明によるオーディオ、歌、またはボーカルのメタ制御は、任意のファイルの中の任意の位置を指すことができることに留意されたい。それによって、歌、発話音声、ボーカル、他のオーディオコンテンツとの組み合わせで、楽曲の効率の良い柔軟性のある表現が提供される。
【００８６】
本明細書に記載した方法、製品手段、および装置は、いくつかの個別の要素を含むハードウェアによって、および適切にプログラミングされたマイクロプロセッサによって実施することができる。特に、本明細書に記載された方法の特徴は、ソフトウェアで実施可能であり、データ処理装置や、コンピュータ実行可能命令などのプログラム・コード手段の実行によって実現される他の処理手段で実行することができる。
【００８７】
一部の場合、プログラムは、CD-ROMまたはフロッピ・ディスク (両方とも一般には記憶装置として表される) 上で符号化されてユーザに提供されるか、代わりにコンピュータ・ネットワークを介して読み取ることができる。さらに、コンピュータ・システムは、他のコンピュータ可読媒体からソフトウェアをロードすることができる。これは、磁気テープ、ROMまたは集積回路、光磁気ディスク、コンピュータと別の装置との間の無線または赤外線送信チャネル、PCMCIAカードなどのコンピュータ可読カード、および電子メール送信およびインターネット・サイトに記録された情報を含むインターネットおよびイントラネットなどを含み得る。上記は単に、関連のコンピュータ可読媒体の例にすぎない。他のコンピュータ可読媒体は、本発明の範囲および主旨を逸脱することなく実現することができる。
【００８８】
いくつかの手段を列挙する装置クレームでは、これらの手段のいくつかを、例えば適切にプログラミングされたマイクロプロセッサ、１または２以上のデジタル信号処理プロセッサなど、ハードウェアの1つまたは同じアイテムによって組み込むことができる。いくつかの手段が相互に異なる従属クレームに述べられている、または異なる実施形態で説明されているという単なる事実は、これらの手段の組み合わせを有利に使用することができないことを示すものではない。
【００８９】
「含む (comprises/comprising) 」という用語は、本明細書においては、説明した特徴、数値、ステップ、または構成要素の存在を示すために使われているのであり、1または2以上の他の特徴、数値、ステップ、構成要素、またはそれらのグループの存在または追加を除外するものではないことを強調しておく。
【図面の簡単な説明】
【００９０】
【図１】マルチメディア信号を構成する装置を示す図である。
【図２】マルチメディア信号を分解する装置を示す図である。
【図３】ファイル・コンテナを示す図である。
【図４ａ】符号化されたオーディオデータおよび符号化されたオーディオデータへのイベントに基づく参照と結合されたイベントに基づくマルチメディア信号の構造を示す図である。
【図４ｂ】イベントに基づくマルチメディア信号の構造を示す図である。
【図４ｃ】符号化されたオーディオデータおよび符号化されたオーディオデータへのイベントに基づく参照の構造を示す図である。
【図５】マルチメディア信号を構成する方法を示すフローチャートである。
【図６】マルチメディア信号を分解する方法を示すフローチャートである。
【図７ａ】マルチメディア信号のエンベロープを示す略図である。
【図７ｂ】ＭＩＤＩイベント、符号化されたオーディオイベント、および再生信号のサンプルの時間的側面を示す図である。
【図１】
2007514971.tif 000003
【図２】
2007514971.tif 000004
【図３】
2007514971.tif 000005
【図４ａ】
2007514971.tif 000006
【図４ｂ】
2007514971.tif 000007
【図４ｃ】
2007514971.tif 000008
【図５】
2007514971.tif 000009
【図６】
2007514971.tif 000010
【図７ａ】
2007514971.tif 000011
【図７ｂ】
2007514971.tif 000012
【手続補正書】
【提出日】平成18年8月1日(2006.8.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
出力装置に対する命令の形式でコンテンツを保持するように構成されている第１タイプのイベント (407) と、
マルチメディア・コンテンツの符号化サンプルを識別するアドレスを含む追加コンテンツ (410) を保持するように構成されている第２タイプのイベント (406) と
を含むマルチメディア信号 (401; 409) 、を提供する方法であって、
前記第１タイプのイベントに応答してマルチメディア出力を生成するステップと、
前記マルチメディア信号 (401; 409) を解析 (602) して、前記第２タイプのイベント (406) を識別するとともに、追加コンテンツ (410) を読み出すステップと、
前記アドレスによって識別されるマルチメディア・コンテンツ (402) の前記符号化サンプルをロードするステップ (607) と、
前記符号化サンプルを復号化 (611) して、前記マルチメディア・コンテンツの再生のために復号化サンプルを提供するステップと、
前記第２タイプのイベントに関連付けられているタイミング情報に従って前記復号化サンプルを前記生成されたマルチメディア出力に重畳するステップ (609) と
を有し、
前記第２タイプのイベント (406) は、Musical Instrument Digital Interface (MIDI) 仕様で定義された、cue-pointタイプ、lyricタイプ、textタイプから選択されるいずれかのタイプのメタ・イベントを含み、
前記アドレスは、前記マルチメディア信号に関連付けられている第１のファイル (402; 303) の位置を示す
ことを特徴とする方法。
【請求項２】
前記タイミング情報は、基準時刻に対する時間を定義するデルタタイム値を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記第２タイプのイベントは、符号化サンプルを識別する１または２以上の予め定められたコマンドのテキスト情報を含むことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記重畳は、前記タイミング情報に基づいて前記復号化サンプルを前記マルチメディア出力と同期することを含むことを特徴とする請求項１から３までのいずれかに記載の方法。
【請求項５】
前記マルチメディア信号および前記符号化サンプルは、コンテナデータ項目に含まれることを特徴とする請求項１から４までのいずれかに記載の方法。
【請求項６】
前記第２タイプのイベント (406) は、16進数FF 07によって識別される、cue-pointタイプのメタ・イベントを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記第２タイプのイベント (406) は、16進数FF 05によって識別される、lyricタイプのメタ・イベントを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記第２タイプのイベント (406) は、16進数FF 01によって識別される、textタイプのメタ・イベントを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記マルチメディア信号は第２のファイル (302) に格納されることを特徴とする請求項１から８までのいずれかに記載の方法。
【請求項１０】
前記追加コンテンツは、前記符号化サンプルの符号化に使用される符号化方式のタイプの指示を含むことを特徴とする請求項１から９までのいずれかに記載の方法。
【請求項１１】
前記マルチメディア信号は、Musical Instrument Digital Interface (MIDI) 通則に準拠することを特徴とする請求項１から１０までのいずれかに記載の方法。
【請求項１２】
前記装置に対する命令の形式でコンテンツを保持するように構成されている第１タイプのイベント (407) と、
マルチメディア・コンテンツの符号化サンプルを識別するアドレスを含む追加コンテンツを保持するように構成されている第２タイプのイベント (406) と
を含むマルチメディア信号 (401; 409) 、を提供する装置であって、
前記第１タイプのイベントに応答してマルチメディア出力を生成する再生ユニット (202) と、
前記第２タイプのイベント (406) を識別するとともに、前記追加コンテンツ (410) を読み取すパーザ (201) と、
前記アドレスによって識別されるマルチメディア・コンテンツの前記符号化サンプルをロードし、デコーダに、前記マルチメディア・コンテンツのその後の再生のために、復号化サンプルを復号させるインターフェイス (204) と、
前記復号化サンプルの再生を前記マルチメディア出力の生成と同期させる同期ユニット (210) と
を有し、
前記第２タイプのイベント (406) は、Musical Instrument Digital Interface (MIDI) 仕様で定義された、cue-pointタイプ、lyricタイプ、textタイプから選択されるいずれかのタイプのメタ・イベントを含み、
前記アドレスは、前記マルチメディア信号に関連付けられている第１のファイル (402; 303) の位置を示す
ことを特徴とする装置。
【請求項１３】
前記マルチメディア信号は、Musical Instrument Digital Interface (MIDI) 通則に準拠することを特徴とする請求項１２に記載の装置。
【請求項１４】
前記タイミング情報は、基準時刻に対する時間を定義するデルタタイム値を含むことを特徴とする請求項１２または１３に記載の装置。
【請求項１５】
前記第２タイプのイベントは、符号化サンプルを識別する１または２以上の予め定められたコマンドのテキスト情報を含むことを特徴とする請求項１２から１４までのいずれかに記載の装置。
【請求項１６】
前記マルチメディア信号および前記符号化サンプルは、コンテナデータ項目に含まれることを特徴とする請求項１２から１５までのいずれかに記載の装置。
【請求項１７】
前記第２タイプのイベント (406) は、16進数FF 07によって識別される、cue-pointタイプのメタ・イベントを含むことを特徴とする請求項１２に記載の装置。
【請求項１８】
前記第２タイプのイベント (406) は、16進数FF 05によって識別される、lyricタイプのメタ・イベントを含むことを特徴とする請求項１２に記載の装置。
【請求項１９】
前記第２タイプのイベント (406) は、16進数FF 01によって識別される、textタイプのメタ・イベントを含むことを特徴とする請求項１２に記載の装置。
【請求項２０】
前記マルチメディア信号は第２のファイル (302) に格納されることを特徴とする請求項１２から１９までのいずれかに記載の装置。
【請求項２１】
前記追加コンテンツは、前記符号化サンプルの符号化に使用される符号化方式のタイプの指示を含むことを特徴とする請求項１２から２０までのいずれかに記載の装置。
【請求項２２】
データ処理装置上で実行されたときに、請求項１から１１までのいずれかに記載の方法を実行するように構成されたプログラム・コード手段を有することを特徴とするコンピュータ・プログラム製品。
【国際調査報告】
2007514971.tif 000013
2007514971.tif 000014
2007514971.tif 000015