JP3613254B2 - 楽曲データの圧縮方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、楽音の音高、発音タイミング、発音持続時間あるいはパートに対応するチャンネル番号等の音符情報からなる演奏イベント情報を圧縮する楽曲データの圧縮方法に関し、特に携帯電話機の着信メロディなど、楽曲データの配信等を行うのに適した楽曲データの圧縮方法に関する。
【０００２】
【従来の技術】
近年、携帯電話機やパソコンなどの電子機器（端末機）によるネットワークの利用が進み、これらの電子機器によりサーバから多種多用なコンテンツのサービスを受けることができるようになった。このコンテンツとしては、例えば携帯電話機の着信メロディで鳴らすための楽曲データや、パソコンで楽曲演奏やカラオケ演奏を行うための楽曲データなど、各種のものがある。
【０００３】
しかし、このような楽曲の再生時間やパート数などが多くなれば、データサイズが大きくなり、例えば着信メロディの楽曲データをダウンロードするための通信時間や通信コストがかかるという問題がある。また、端末内に楽曲データを格納する際、大きなメモリ容量が必要になるという問題がある。そこで、楽曲データを圧縮することが要求される。
【０００４】
特開平８−２２２８１号公報には、楽曲データであるＭＩＤＩ信号を分析し、連続する同一音や連続する同一パターンを検出し、連続した同一部分を削除するとともに、そのかわりに繰り返しのある旨を示す信号を挿入することにより、ＭＩＤＩ信号を圧縮するという内容が開示されている。また、特開平９−１５３８１９号公報には、１音のＭＩＤＩデータ（音高、デュレーション、音長、ベロシティ、チャンネルナンバ）をその要素毎に分解、その要素毎に再結合することで、後段の可逆圧縮器の圧縮率を上げるという内容が開示されている。
【０００５】
【発明が解決しようとする課題】
前記特開平８−２２２８１号公報のものでは、例えばキーオンイベントに着目した場合、それは、キーオンイベントである旨を表す情報とチャンネルを表す情報とで構成されるステータス情報と、キーナンバ情報（７ビット）と、ベロシティ情報（７ビット）と、ゲートタイム情報（、さらに場合によってはデュレーション）で構成されるが、その全てが同一である音が連続することは稀であり圧縮効率が悪いという問題がある。また、所定のパターンが繰り返されるような曲目では大きな圧縮率が期待できるが、長い繰り返しの区間を検出するためのアルゴリズムが複雑になるという問題がある。
【０００６】
また、特開平９−１５３８１９号公報のものでは、通信カラオケシステムのカラオケコンテンツに利用されるもので、組替え処理を施されたカラオケコンテンツはカラオケボックスあるいは一般家庭に設置された端末に一旦ダウンロードされた後、元の１音毎のＭＩＤＩデータに再組替えを行って利用される。このため、受信しながら再生するようなストリーム再生には向かないという問題がある。また、この特開平９−１５３８１９号公報はデータの並べ替えを行うことが開示されているだけであり、新たな圧縮手法を提案するものではない。
【０００７】
本発明は、データサイズを大幅に削減できる新規な楽曲データの圧縮方法を提供することを課題とする。
【０００８】
【課題を解決するための手段】
本発明の請求項１の楽曲データの圧縮方法は、音符情報からなる演奏イベント情報の列を含む楽曲データを圧縮する楽曲データの圧縮方法であって、前記楽曲データの演奏イベント情報を、該演奏イベント情報の音符情報と直前の演奏イベント情報の音符情報との一致不一致のパターンに対応するステータス情報と、不一致である音符情報と、を含む演奏イベント情報に変換するようにしたことを特徴とする。
【０００９】
上記のように構成された請求項１の楽曲データの圧縮方法によれば、直前の演奏イベント情報の音符情報との一致不一致のパターンがステータス情報に含まれており、一致する音符情報以外の不一致の音符情報のみをデータとして持っていればよいので、データサイズを削減することができる。この圧縮された楽曲データを伸長するときは、ステータス情報が示す一致不一致のパターンに基づいて、必要であれば前の演奏イベント情報の音符情報を参照することで圧縮前の演奏イベント情報に伸長することができる。
【００１０】
本発明の請求項２の楽曲データの圧縮方法は、請求項１の構成を備え、前記音符情報中の音高情報を、初期音高からの差分で表現することを特徴とする。
【００１１】
上記のように構成された請求項２の楽曲データの圧縮方法によれば、請求項１と同様な作用効果が得られるとともに、音高情報（差分）は初期音高の音に対する相対値となるので、全音域に対応する絶対値で音高を表現するよりもデータサイズを削減することができる。
【００１２】
本発明の請求項３の楽曲データの圧縮方法は、請求項２の構成を備え、前記初期音高は楽曲データに含まれるいずれかの音の音高であることを特徴とする。
【００１３】
上記のように構成された請求項３の楽曲データの圧縮方法によれば、請求項２と同様な作用効果が得られるとともに、初期音高として楽曲データの最初の音の音高でもよいし、任意の音の音高でもよい。さらに、最高音と最低音の中間の音高とすることもできる。
【００１４】
本発明の請求項４の楽曲データの圧縮方法は、請求項２または３の構成を備え、前記楽曲データは複数チャンネルの演奏イベント情報で構成されるとともに、各演奏イベント情報をチャンネルを混在して時系列に配列し、該チャンネルを混在した時系列の順に前記音符情報の一致不一致を検出することを特徴とする。
【００１５】
上記のように構成された請求項４の楽曲データの圧縮方法によれば、請求項２または３と同様な作用効果が得られるとともに、複数のチャンネルを混在して、この混在した時系列の順に音符情報の一致不一致を検出して圧縮するので、圧縮された楽曲データも複数チャンネルが混在した時系列の順になるので、例えば圧縮した楽曲データを配信し、受信しながら楽曲データを再生（ストリーム再生）することができる。
【００１６】
本発明の請求項５の楽曲データの圧縮方法は、請求項２または３の構成を備え、前記楽曲データは複数チャンネルの演奏イベント情報で構成されるとともに、各演奏イベント情報をチャンネル毎に時系列に配列し、該チャンネル毎の時系列の順に前記音符情報の一致不一致を検出することを特徴とする。
【００１７】
上記のように構成された請求項５の楽曲データの圧縮方法によれば、請求項２または３と同様な作用効果が得られるとともに、各チャンネル毎に含まれている演奏イベント情報にはチャンネル情報を必要としないので、データサイズを削減することができる。
【００１８】
本発明の請求項６の楽曲データの圧縮方法は、請求項４または５の構成を備え、前記初期音高はチャンネル毎に設定され、前記音高情報を該チャンネル毎に前記差分で表現することを特徴とする。
【００１９】
上記のように構成された請求項６の楽曲データの圧縮方法によれば、請求項４または５と同様な作用効果が得られるとともに、例えばチャンネルによっては差分を表すデータ長によっては差分で表現できないチャンネルがあっても、チャンネル毎に他のチャンネルを差分で表現できるので、できるだけデータサイズの削減をすることができる。
【００２０】
本発明の請求項７の楽曲データの圧縮方法は、請求項４の構成を備え、前記初期音高が１つ設定され、前記音符情報をチャンネルを混在して前記差分で表現することを特徴とする。
【００２１】
上記のように構成された請求項７の楽曲データの圧縮方法によれば、請求項４と同様な作用効果が得られるとともに、初期音高が１つなので処置が簡単になる。
【００２２】
本発明の請求項８の楽曲データの圧縮方法は、請求項１、２、３、４、５、６または７の構成を備え、前記音符情報中に前記演奏イベント情報間の間隔情報及び発音持続時間の情報を含み、該間隔情報及び発音持続時間の情報を、予め決められた音符の符長で表現するようにしたことを特徴とする。
【００２３】
上記のように構成された請求項８の楽曲データの圧縮方法によれば、請求項１、２、３、４、５、６または７と同様な作用効果が得られるとともに、演奏イベント情報間の間隔情報及び発音持続時間の情報が、音符の符長で表現される、すなわち近似されるので、データサイズを削減することができる。
【００２４】
【発明の実施の形態】
本発明の一実施形態を図面を参照して説明する。図４は本発明の楽曲データの圧縮方法を適用した実施形態の基本システム構成を示す図である。データ制作・配信側は、例えば配信サーバ（そのコンピュータ）等であり、スタンダード・ＭＩＤＩ・ファイル（ＳＭＦ）形式の楽曲データや、実施形態の形式の楽曲データ（「ＳＭＡＦ」という。）に対して、データ圧縮処理を行い、本実施形態の仕様のフォーマットに圧縮された楽曲データとする。
【００２５】
データ受信・再生側は例えば携帯電話機等であり、データ制作・配信側で圧縮された楽曲データのダウンロード等が行われ、該データ受信・再生側のメモリに記憶する。そして、楽曲の再生時には該楽曲データに対して伸長処理を行い、シーケンサ処理により音源の所定のチャンネルにキーオン、ノートナンバ、キーオフ等の音符データを出力して発音する。なお、以下の説明では、データ制作・配信側を「配信サーバ」、データ受信・再生側を「携帯電話機」、楽曲データを「着信メロディのデータ」として説明する。
【００２６】
図５は携帯電話機の着信メロディの配信サービを行うネットワークの具体例を示す図である。ネットワーク１０は電話交換機網やインターネット等であり、このネットワーク１０には、着信メロディの楽曲データを配信する配信サーバ１、ユーザ側の携帯電話機２に接続する基地局３、ネットワーク対応のパーソナルコンピュータ４等が接続される。
【００２７】
図６は配信サーバ１のコンピュータのハードウエア構成を示すブロック図であり、ＣＰＵ１ａは、外部記憶装置１ｂにインストールされたＯＳによりＲＯＭ１ｃやＲＡＭ１ｄを使用して各種の処理を行う。また、外部記憶装置１ｂは、例えば大容量のＨＤＤ（ハードディスクドライブ）等であり、ＳＭＦ形式及びＳＭＡＦ形式の各種の楽曲データ、楽曲データの配信サービス等でユーザの携帯電話機２に表示する各種の情報（ＨＴＭＬで作成された複数のＷＷＷページのソース）など、各種のデータが記憶されている。そして、通信インターフェース１ｅを介して前記ネットワーク１０に接続され、ユーザの携帯電話機２等に対して着信メロディの楽曲データの配信サービスを行う。このとき、ＣＰＵ１ａは、後述する楽曲データの圧縮処理、通信処理等を行う。なお、オペレータの入出力装置としてディスプレイ１ｆ、キーボード１ｇ、マウス１ｈ等を備えている。
【００２８】
図７は携帯電話機２のハードウエア構成を示すブロック図であり、ＣＰＵ２ａは、ＲＯＭ２ｂに格納されたプログラムを実行することにより、携帯電話機２の各部の動作を制御する。ＲＡＭ２ｃは、ＣＰＵ２ａのワークエリア、配信サービスでダウンロードした楽曲データの格納エリア、あるいは、ユーザの設定データの格納エリア等に使用される。通信部２ｄはアンテナ２ｅで受信された信号の復調を行うとともに、送信する信号を変調してアンテナ２ｅに供給する。通信部２ｄで復調された受話信号は音声処理部２ｆにおいて復号され、楽曲再生部２ｇは復号された受話信号により受話用スピーカ２ｉから放音する。また、楽曲再生部２ｇは、楽曲データを再生して着信メロディを着信用スピーカ２ｊから放音する。さらに、マイク２ｈから入力された通話信号は音声処理部２ｆにおいて圧縮符号化され、符号化された通話信号は通信部２ｄにより送信される。
【００２９】
インターフェース（Ｉ／Ｆ）２ｋは、パーソナルコンピュータ等の外部機器から楽曲データや音色データ等をダウンロードするためのインターフェースである。また、ダイヤルボタンや各種操作子等からなる入力部２ｍ、電話機能や通信機能のメニュー、配信サービスの選択操作やダイヤルボタン等の操作に応じた表示を行う表示部２ｎ、着信時に着信音に代えて本体を振動させるバイブレータ２ｐ等を備えている。
【００３０】
ここで、楽曲再生部２ｇは、内部に設けられた楽曲データ用バッファから演奏イベントを読み出して楽曲データを再生するが、この楽曲データを再生している際にデータ用バッファに所定量の空きエリアが生じた場合は、割込み要求信号をＣＰＵ２ａに与える。これにより、ＣＰＵ２ａはＲＡＭ２ｃに記憶されている圧縮された楽曲データの続きを読み出し、楽曲再生部２ｇに転送する。この楽曲再生部２ｇに供給する楽曲データはＣＰＵ２ａにより伸長処理が施されたものであるが、この伸長処理をどの時点で行うかは後述のフォーマットに応じて異なる。なお、楽曲再生部２ｇは時分割多重処理により複数の発音チャンネルで楽音信号を発生する音源を備えており、楽曲データの演奏イベントに応じて、自動演奏と同様に着信メロディを再生する。このような楽曲データによる自動演奏の技術は周知の技術であり、詳細な説明は省略する。
【００３１】
図３は実施形態における圧縮対象楽曲データの２種類のフォーマットを示す図であり、いずれも１つのファイルで１曲分の楽曲データを構成している。楽曲データは、パートに対応して通常複数チャンネル（ＳＭＦの場合は１６チャンネル）で構成されるが、この実施形態ではチャンネル数は４チャンネルであり、最大４音色の発音が可能である。また、チャンネルの扱い方に応じて、シングル・チャンネル・チャンク・フォーマットとマルチ・チャンネル・チャンク・フォーマットの２種類ある。
【００３２】
図３（Ａ） のシングル・チャンネル・チャンク・フォーマットは、「データ長」、「テンポ」及び「音色」のデータがヘッダとして記録され、これに続いて曲の各音に対応する「演奏イベント」のデータ（演奏イベント情報）が記録されている。「データ長」のデータは８ビットで全データの長さを表し、「テンポ」のデータは４ビットで曲の再生テンポを表し、さらに「音色」のデータはそれぞれ６ビットでｃｈ１〜４の各チャンネルにアサインされた音色を表している。
【００３３】
また、「演奏イベント」のデータは、「チャンネル」、「ノートナンバ」、「デュレーション」及び「ゲートタイム」のデータ（各音符情報）から構成されており、「チャンネル」は２ビットでその演奏イベントが属するチャンネルのチャンネル番号を表し、「ノートナンバ」は６ビットで音高を表し、「デュレーション」は１〜２バイトで直前のイベントからの時間間隔（すなわち符長）を表し、「ゲートタイム」は１〜２バイトで発音持続時間を表している。
【００３４】
図３（Ｂ） のマルチ・チャンネル・チャンク・フォーマットは、「データ長」及び「テンポ」のデータがヘッダとして記録され、これに続いて、各チャンネル毎のかたまり（チャンク）のデータが４チャンネル分記録されている。なお、４チャンネル以下の場合もある。各チャンクのデータには、そのチャンクのチャンネル番号を表す「チャンネル」のデータ、そのチャンクの全データの長さを表す「データ長」のデータ及びそのチャンク（チャンネル）にアサインされた音色を表す「音色」のデータがヘッダとしてそれぞれ記録されている。そして、その後に曲の各音に対応する「演奏イベント」のデータが記録されている。
【００３５】
「演奏イベント」のデータは、シングル・チャンネル・チャンク・フォーマット同様な「ノートナンバ」、「デュレーション」及び「ゲートタイム」のデータから構成されているが、このマルチ・チャンネル・チャンク・フォーマットの場合は各チャンク毎にチャンネル番号が設定されているので、各「演奏イベント」には「チャンネル」のデータは含まれていない。デュレーションは直前のイベントからの時間間隔を表すので、曲全体で最初の音のデュレーションは０となり、曲全体で最初とならない他チャンネルの最初の音のデュレーションは０以外の値となる。
【００３６】
なお、シングル・チャンネル・チャンク・フォーマット、マルチ・チャンネル・チャンク・フォーマットの何れにおいても、「ノートナンバ」のデータは、次表１に示すように、オクターブを表す２ビットの「ブロック」のデータと音名を表す４ビットの「ノート」のデータで構成されている。
【００３７】
【表１】

【００３８】
以上のような楽曲データに対して配信サーバ１で次のように処理を行う。配信サーバ１には、各種楽曲について、シングル・チャンネル・チャンク・フォーマットとマルチ・チャンネル・チャンク・フォーマットの両方のフォーマットで楽曲データをソースとして記憶している。そして、以下の各実施形態のようにこのソースを各々圧縮し、圧縮されたシングル・チャンネル・チャンク・フォーマット及びマルチ・チャンネル・チャンク・フォーマットに変換する。次に、以下の各実施形態のように、演奏イベントのノートナンバを初期ノートナンバに基づいて差分のデータとし、楽曲データを圧縮する。
【００３９】
（圧縮の仕方の第１実施形態）
次に、同一チャンネルの演奏イベントに着目し、最初の演奏イベントのノートナンバを検出し、それを初期ノートナンバ（初期音高）とする。そして、同一チャンネルの演奏イベントについてそのノートナンバを、初期ノートナンバとの差分（音高差）で表す差分形態に変換する。ただし、この差分形態への変換は、全ての演奏イベントが、そのノートナンバの上記差分を５ビットで表しきれるようなチャンネル（以後、「許容音域のチャンネル」ともいう。）を対象とし、ノートナンバが上記差分を５ビットで表しきれない演奏イベントが一つでも存在するチャンネルについては差分形態への変換を行わない。この場合、差分形態への変換を行わないチャンネルを識別するために、そのチャンネルの初期ノートナンバに代えて、予め決められた特定のデータ（ノートナンバ以外のデータ）をセットするようにすればよい。次に、演奏イベントの「デュレーション」及び「ゲートタイム」を、次表２の所定の符長の最も近いものに丸める処理を行い、「デュレーション」及び「ゲートタイム」を対応する３ビットのデータに変換する。
【００４０】
【表２】

【００４１】
以上の処理により、図３の楽曲データを例えば図２のようなフォーマットに変換する。すなわち、図２（Ａ） のように、シングル・チャンネル・チャンク・フォーマットでは、ヘッダのデータとして各チャンネル（ｃｈ１〜４）に対応してそのチャンネルの最初の音のノートナンバを「初期ノートナンバ」として付加する。「演奏イベント」は、２ビットの「チャンネル」、該演奏イベントのノートナンバの初期ノートナンバからの差分を表す５ビットの「ノートメッセージ」、３ビットの「デュレーション」及び「ゲートタイム」とする。
【００４２】
また、図２（Ｂ） のように、マルチ・チャンネル・チャンク・フォーマットでは、各チャンネルのチャンクにおいて、ヘッダのデータとしてそのチャンネルの最初の音のノートナンバを「初期ノートナンバ」として付加する。また、「演奏イベント」は、ノートナンバの初期ノートナンバからの差分を表す５ビットの「ノートメッセージ」、３ビットの「デュレーション」及び「ゲートタイム」とする。なお、最初の音の「演奏イベント」においては、「ノートメッセージ」が“０００００ｂ”（差分が０）として記録されることはいうまでもない。
【００４３】
以上の処理では、各チャンネルの最初の演奏イベントのノートナンバを初期ノートナンバ（初期音高）としているが、各チャンネル内の任意のノートナンバを初期ノートナンバとしてもよい。また、別途入力設定したノートナンバを初期ノートナンバとしてもよい。
【００４４】
（圧縮の仕方の第２実施形態）
第１実施形態ではチャンネル毎に圧縮したが、第２実施形態では、チャンネルを混在して圧縮する。まず、各チャンネルの演奏イベントに着目し、全チャンネルの中で最初の演奏イベントのノートナンバを検出し、それを初期ノートナンバ（初期音高）とする。そして、各チャンネルの演奏イベントについてそのノートナンバを、初期ノートナンバとの差分（音高差）で表す差分形態に変換する。ただし、この差分形態への変換は、全チャンネルの全ての演奏イベントが、そのノートナンバの上記差分を５ビットで表しきれるような場合を対称とする。そして、演奏イベントの「デュレーション」及び「ゲートタイム」を前記同様に所定の符長の最も近いものに丸める処理を行い、「デュレーション」及び「ゲートタイム」を対応する３ビットのデータに変換する。
【００４５】
この第２実施形態においても、初期ノートナンバ（初期音高）として、全チャンネル内の任意のノートナンバを初期ノートナンバとしてもよいし、また、別途入力設定したノートナンバを初期ノートナンバとしてもよい。
【００４６】
以上の処理により、シングル・チャンネル・チャンク・フォーマットでは、ヘッダのデータとして全チャンネルに対応して「初期ノートナンバ」を付加し、「演奏イベント」は、図２（Ａ） と同様に、２ビットの「チャンネル」、該演奏イベントについての差分を表す５ビットの「ノートメッセージ」、３ビットの「デュレーション」及び「ゲートタイム」とする。
【００４７】
以上のように、ノートナンバを初期ノートナンバとの差分（ノートメッセージ）に変換するので、全音域に対応する絶対値（ノートナンバ）で音高を表現するよりも圧縮されたものとなる。また、さらに、「デュレーション」及び「ゲートタイム」を所定の符長に丸めて表現するので、さらに圧縮される。また、シングル・チャンネル・チャンク・フォーマットをマルチ・チャンネル・チャンク・フォーマットに変換すると、演奏イベント自体に「チャンネル」のデータを必要としないので、圧縮されたデータとなる。
【００４８】
この実施形態では上記のように各種の圧縮の処理を行うが、次のように演奏イベントのシーケンスについての圧縮処理を行うことで、楽曲データを大幅に圧縮することができる。すなわち、隣接する２つの演奏イベントを比較し、後ろの演奏イベントについて、前の演奏イベントとの各データの一致不一致を検出する。そして、その一致不一致のパターンに対応する３ビットの「ステータス」のデータを付加し、その一致不一致のパターンに応じて必要なデータ（一致しないデータ）だけを残すことで、演奏イベントのデータの圧縮を行う。
【００４９】
なお、シングル・チャンネル・チャンク・フォーマットではファイル全体の演奏イベントのシーケンス（各チャンネル混在のシーケンス）について処理をし、マルチ・チャンネル・チャンク・フォーマットでは各チャンネル（チャンク）毎に演奏イベントのシーケンスについて処理を行う。ただし、前述のように差分を５ビットで表現できないチャンネルについては差分形態としないが、このようなチャンネルについては、特にシングル・チャンネル・チャンク・フォーマットの場合、上記の圧縮処理を他のチャンネルと区別して処理する。この場合、演奏イベントの比較ではノートナンバ（ブロック及びノート）の一致不一致を検出する。
【００５０】
次表３はシングル・チャンネル・チャンク・フォーマットの場合のステータス、一致不一致の条件、ステータスに続くデータ及び演奏イベントのトータルビット数を表している。なお、この例はノートナンバを差分形態に変換した場合を示している。
【００５１】
【表３】

【００５２】
例えば、最上段のように、前の演奏イベントと「ノートメッセージ」、「デュレーション」及び「ゲートタイム」が全て一致していれば、「ステータス」の後に「チャンネル」のデータだけを残して演奏イベントとする。この場合、トータルビット数は、「ステータス」の３ビットと「チャンネル」の２ビットで計５ビットとなる。次段、その他の段についても同様に、「ステータス」の後に必要なデータ（一致しないデータ）だけを残して演奏イベントを圧縮する。これにより、演奏イベントは最大で１６ビット、最小で５ビットに圧縮される。なお、表に示した条件の中で「Ｂ，Ｃ，Ｄが一致」のように“，”で連結した条件はアンド条件を表している。
【００５３】
次表４はマルチ・チャンネル・チャンク・フォーマットの場合のステータス、一致不一致の条件、ステータスに続くデータの種類及び演奏イベントのトータルビット数を表している。この例もノートナンバを差分形態に変換した場合を示している。
【００５４】
【表４】

【００５５】
この表４の意味も表３と同様であり具体的な説明は省略するが、マルチ・チャンネル・チャンク・フォーマットの場合は演奏イベント中に「チャンネル」のデータが不要な分だけシングル・チャンネル・チャンク・フォーマットよりも短くなる。
【００５６】
図１は演奏イベントのシーケンスについての圧縮前後の楽曲データの一例を示す図であり、図中Ａは「チャンネル」、Ｂは「ノートメッセージ」、Ｃは「デュレーション」、Ｄは「ゲートタイム」、Ｓｔは「ステータス」を表している。図１（Ａ） のシングル・チャンネル・チャンク・フォーマットの場合、圧縮前は、「チャンネル」、「ノートメッセージ」、「デュレーション」及び「ゲートタイム」が１つの演奏イベントであり、全体で１３ビットとなっている。そして、図示の一つ目の演奏イベントにおいて前の演奏イベントとの一致不一致の条件（パターン）から、「ステータス」が“０００”（表３の最上段）であったとすると、その演奏イベントは「チャンネル」のみとなり、５ビットの演奏イベントとなる。同様に「ステータス」が“００１”なら１０ビット、“０１０なら９ビットに圧縮される。
【００５７】
また、図１（Ｂ） のマルチ・チャンネル・チャンク・フォーマットの場合、圧縮前は、「ノートメッセージ」、「デュレーション」及び「ゲートタイム」が１つの演奏イベントであり、全体で１１ビットとなっている。そして、図示の一つ目の演奏イベントにおいて前の演奏イベントとの一致不一致の条件（パターン）から、「ステータス」が“０００”（表４の最上段）であったとすると、その演奏イベントは「ステータス」のみとなり、３ビットの演奏イベントとなる。同様に「ステータス」が“００１”なら６ビット、“０１０なら８ビットに圧縮される。
【００５８】
図８は配信サーバー１における楽曲データ圧縮処理の要部フローチャート、図９はシングルチャンネルチャンク圧縮処理のサブルーチンのフローチャート、図１０はマルチチャンネルチャンク圧縮処理のサブルーチンのフローチャート、図１１は配信処理の要部フローチャートである。なお、これらのフローチャートの処理は、前記第１実施形態に対応している。図８の楽曲データ圧縮処理を開始すると、ステップＳ１で所定のＳＭＦデータまたはＳＭＡＦデータを指定し、ステップＳ２で図９のシングルチャンネルチャンク圧縮処理を行って圧縮データを記憶する。次に、ステップＳ３で図１０のマルチチャンネルチャンク圧縮処理を行って圧縮データを記憶する。そして、ステップＳ４で終了か否かを判定し、上記の処理を必要に応じて繰り返し、圧縮された楽曲データを外部記憶装置１ｂに蓄積する。
【００５９】
図９のシングルチャンネルチャンク圧縮処理では、ステップＳ２１で圧縮元の楽曲データのフォーマットを判定し、マルチ・チャンネル・チャンク・フォーマットの場合はステップＳ２２に進み、シングル・チャンネル・チャンク・フォーマットの場合はステップＳ２３に進む。ステップＳ２２では、各チャンネルの演奏イベントのデュレーションに基づいて、全チャンネルを混合して演奏イベントを時系列に配列する。そして、各演奏イベントに元のチャンネルのチャンネル番号を付加するとともに、チャンネルを混合した結果の演奏イベントの間隔に対応するようにデュレーションを変更する。すなわち、ステップＳ２２ではマルチ・チャンネル・チャンク・フォーマットをシングル・チャンネル・チャンク・フォーマットに変換する処理を行う。そして、ステップＳ２３に進む。
【００６０】
ステップＳ２３では、各チャンネルの初期ノートナンバを検出して記憶し、ステップＳ２４で、各チャンネルにおいて、演奏イベントのノートナンバが、初期ノートナンバからの差分を５ビットで表現できるか否かを検出する。すなわち許容音域のチャンネルを検出する。次に、ステップＳ２５で、許容音域のチャンネルについて、ノートナンバを初期ノートナンバとの差分のデータ（ノートメッセージ）に変換して記憶する。次に、ステップＳ２６で、前掲の表３の条件により、直前の演奏イベントを参照しつつ、演奏イベントのデータを変換する。具体的には、演奏イベントのデータのうち直前の演奏イベントのデータと一致するデータを削除し、満足する条件（一致不一致のパターン）に対応するステータスを付与して一つの演奏イベントとする。そして、楽曲データの全演奏イベントについての処理が終了すると元のルーチンに復帰する。
【００６１】
図１０のマルチチャンネルチャンク圧縮処理では、ステップＳ３１で、圧縮元の楽曲データのフォーマットを判定し、シングル・チャンネル・チャンク・フォーマットの場合はステップＳ３２に進み、マルチ・チャンネル・チャンク・フォーマットの場合はステップＳ３３に進む。ステップＳ３２では、演奏イベントに含まれるチャンネルのデータに基づいて、同一チャンネルの演奏イベントをチャンネルチャンクとして、チャンネルを分離する。そして、各演奏イベントのデュレーションを同一チャンネルの前の演奏イベントとの時間間隔となるように変更する。すなわち、ステップＳ３２ではシングル・チャンネル・チャンク・フォーマットをマルチ・チャンネル・チャンク・フォーマットに変換する処理を行う。そして、ステップＳ３３に進む。
【００６２】
ステップＳ３３では各チャンネルの初期ノートナンバを検出して記憶し、ステップＳ３４で前記許容音域のチャンネルを検出する。次に、ステップＳ３５で、許容音域のチャンネルについて、演奏イベントのノートナンバを初期ノートナンバとの差分のデータ（ノートメッセージ）に変換して記憶する。次に、ステップＳ３６で、前掲の表４の条件により、各チャンネル毎に、直前の演奏イベントを参照しつつ、演奏イベントのデータを変換する。具体的には、演奏イベントのデータのうち直前の演奏イベントのデータと一致するデータを削除し、満足する条件に対応するステータスを付与して一つの演奏イベントとする。そして、楽曲データの全演奏イベントについての処理が終了すると元のルーチンに復帰する。
【００６３】
図１１の楽曲データ配信処理は、当該配信サーバ１に携帯電話機２が接続され、例えば各種コンテンツの配信サービス等を行う時に逐次実行される。まず、ステップＳ４１で、ユーザ（携帯電話機２）から着信メロディの配信リクエストが有るかを監視し、配信リクエストがあれば、ステップＳ４２で、外部記憶装置１ｂに蓄積されている圧縮された楽曲データの曲名リストと選択入力画面を表示するためのＷｅｂページのファイルを携帯電話機２に配信する。これにより、携帯電話機２の表示部に曲名リストと選択入力画面が表示され、携帯電話機２でユーザが所望の曲名と、必要な圧縮タイプすなわちシングルチャンネルチャンク圧縮かマルチチャンネルチャンク圧縮かを選択入力可能となる。
【００６４】
そこで、ステップＳ４３で、曲名と圧縮タイプの選択入力を監視し、選択入力があれば、ステップＳ４４で選択された圧縮タイプを判定する。そして、選択された圧縮タイプがマルチチャンネルチャンク圧縮の場合は、ステップＳ４５で選択された曲のマルチチャンネルチャンク圧縮された楽曲データを配信してステップＳ４７に進み、選択された圧縮タイプがシングルチャンネルチャンク圧縮の場合は、ステップＳ４６で選択された曲のシングルチャンネルチャンク圧縮された楽曲データを配信してステップＳ４７に進む。そして、ステップＳ４７では課金処理などのその他の処理を行い、配信処理を終了する。
【００６５】
以上、図９のシングルチャンネルチャンク圧縮の処理では、前記第１実施形態に対応して、各チャンネル毎に初期ノートナンバを用いるようにしているが、全チャンネル内の任意のノートナンバ、あるいは所定のノートナンバ、あるいは外部から設定したノートナンバ、最高音と最低音の平均のノートナンバなど、一つのノートナンバを全チャンネルについての初期ノートナンバ（初期音高）とするようにしてもよい。また、図１０のマルチチャンネルチャンク圧縮の処理でも、各チャンネル毎に初期ノートナンバを用いるようにしているが、この場合も任意の一つの初期ノートナンバを用いるようにしてもよい。
【００６６】
以上のようにして携帯電話機２に圧縮された楽曲データが配信されると、携帯電話機２のＲＡＭ２ｃに格納される。携帯電話機２では、着信メロディの確認操作を行ったり通常のモードで着信が発生したときに、該楽曲データが再生される。このとき、ＣＰＵ２ａはＲＡＭ２ｃから楽曲データの演奏イベントを読み出しながら、次のような処理を行う。
【００６７】
シングルチャンネルチャンク圧縮された楽曲データの場合は、ｃｈ１〜４の「音色」のデータを読み出して楽曲再生部２ｇの音源に設定し、各チャンネルの「初期ノートナンバ」を読み出す。次に最初の演奏イベントを読み出すが、この最初の演奏イベントは「チャンネル」「ノートメッセージ／ノートナンバ」「デュレーション」及び「ゲートタイム」のデータから構成されている。該演奏イベントに含まれる「チャンネル」のデータに対応するチャンネルの「初期ノートナンバ」に「ノートメッセージ」を加算し、この加算データを「ノートナンバ」とし、この「ノートナンバ」を「チャンネル」、「デュレーション」及び「ゲートタイム」と共に楽曲再生部２ｇに送出する。なお、演奏イベントのチャンネルが許容音域のチャンネルでない場合は、その演奏イベントデータをそのまま楽曲再生部２ｇに送出する。
【００６８】
２番目以降の演奏イベントはビット長が異なるので、ステータスを読み出してその演奏イベントを構成するデータを判別する。そして、圧縮処理により削除されているデータは直前の演奏イベントと同一のデータとして復元（伸長）し、「初期ノートナンバ」と「ノートメッセージ」の加算等を行い、「チャンネル」、「ノートナンバ」、「デュレーション」及び「ゲートタイム」を楽曲再生部２ｇに送出する。この処理を演奏イベントを順次読み出しながら行い、楽曲再生部２ｇのデータ用バッファに所定量のデータを書き込む。
【００６９】
マルチチャンネルチャンク圧縮された楽曲データの場合は、ｃｈ１〜４の各チャンネルに対応する４つのポインタを設定しておき、各チャンネル毎に「音色」のデータを読み出して楽曲再生部２ｇの音源に設定し、各チャンネルの「初期ノートナンバ」を読み出す。次に、各チャンネルのポインタを更新して、各チャンネル毎に演奏イベントを順次読み出し、前記同様に、ステータスによるデータの復元（伸長）や「初期ノートナンバ」と「ノートメッセージ」の加算等を行い、「チャンネル」、「ノートナンバ」、「デュレーション」及び「ゲートタイム」を楽曲再生部２ｇに送出する。
【００７０】
以上のように、配信される楽曲データは圧縮されているので、楽曲データをダウンロードするための通信時間や通信コストを低減できるとともに、上記のように再生時に伸長処理を行うと、携帯電話機２のＲＡＭ２ｃにおいて楽曲データ用の容量が小さくて済む。また、圧縮された楽曲データを予め伸長して、この伸長された楽曲データ（圧縮前の楽曲データ相当）をＲＡＭ２ｃに記憶しておくようにしてもよい。この場合、ＲＡＭ２ｃにはある程度の記憶容量が必要となるが、この場合もダウンロード時の通信時間や通信コストを低減できることは同様である。上記の伸長処理や再生処理はＲＯＭ２ｂに格納されたプログラムにより実行されるので、楽曲データを予め伸長しておくか、再生時に逐次伸長するかの処理をユーザが選択できるようにしてもよい。
【００７１】
また、楽曲データをダウンロードしながら再生するようにしてもよい。この場合は、シングルチャンネルチャンク圧縮された楽曲データであれば、最初の演奏イベントの受信とほぼ同時に伸長・再生を開始することができ、ストリーム再生に適している。なお、マルチチャンネルチャンク圧縮された楽曲データの場合は、少なくとも最後のチャンネルの演奏イベントの受信が開始された時点からなら、再生を行うことができる。
【００７２】
実施形態では、音高を初期ノートナンバとの差分形態で表現するようにしているのでデータサイズを削減できるが、差分が５ビットで表現できないチャンネルの場合のように、ノートナンバのままで演奏イベントのシーケンスについて圧縮するようにしてもよい。また、ノートナンバの構成やチャンネル数は実施形態のものに限らず、任意に設定することができる。
【００７３】
また、上記の実施形態では、伸長処理のためのプログラムが携帯電話機２のＲＯＭ２ｂに記憶されているものとして説明したが、このようなプログラムを配信サーバ１から携帯電話機２に配信するようにしてもよい。
【００７４】
上記の実施形態では、携帯電話機に着信メロディの楽曲データを配信する場合について説明したが、図５に示したように、ネットワーク対応のパーソナルコンピュータ４に対して楽曲データを配信するような場合にも適用できる。この場合の楽曲データは、パーソナルコンピュータ４による自動演奏、あるいは電子楽器５における自動演奏等に用いるものとすることができる。さらに、カラオケ装置にカラオケ用の楽曲データを配信するような場合、あるいはゲーム機にゲームソフト用の楽曲データを配信するような場合にも適用できる。
【００７５】
上記の実施形態ではＳＭＡＦという形式のフォーマットについて説明したが、本発明が対象とする楽曲データは、音符情報からなる演奏イベント情報の列を含む楽曲データであればよく、通常のＳＭＦ形式のフォーマットにも適用できることはいうまでもない。
【００７６】
【発明の効果】
本発明の請求項１の楽曲データの圧縮方法によれば、前後の演奏イベント情報のうち全ての音符情報が一致する場合のみならず、一部が一致している場合でも、直前の演奏イベント情報と一致する音符情報以外の不一致の音符情報のみをデータとして持っていればよいので、データサイズを大幅に削減することができる。
【００７７】
本発明の請求項２の楽曲データの圧縮方法によれば、請求項１と同様な効果が得られるとともに、音高情報が初期音高に対する相対値となるので、全音域に対応する絶対値で音高を表現するよりもデータサイズを削減することができる。
【００７８】
本発明の請求項３の楽曲データの圧縮方法によれば、請求項２と同様な効果が得られるとともに、初期音高として楽曲データの最初の音の音高でもよいし、任意の音の音高でもよい。さらに、最高音と最低音の中間の音高とすることもできる。
【００７９】
本発明の請求項４の楽曲データの圧縮方法によれば、請求項２または３と同様な効果が得られるとともに、複数のチャンネルを混在して圧縮するので、配信サービス等で受信しながら楽曲データを再生することができる。
【００８０】
本発明の請求項５の楽曲データの圧縮方法によれば、請求項２または３と同様な効果が得られるとともに、各チャンネル毎に含まれている演奏イベント情報にはチャンネル情報を必要としないので、データサイズを削減することができる。
【００８１】
本発明の請求項６の楽曲データの圧縮方法によれば、請求項４または５と同様な効果が得られるとともに、例えばチャンネルによっては差分を表すデータ長によっては差分で表現できないチャンネルがあっても、チャンネル毎に他のチャンネルを差分で表現できるので、できるだけデータサイズの削減をすることができる。
【００８２】
本発明の請求項７の楽曲データの圧縮方法によれば、請求項４と同様な効果が得られるとともに、初期音高が１つなので処置が簡単になる。
【００８３】
本発明の請求項８の楽曲データの圧縮方法によれば、請求項１、２、３、４、５、６または７と同様な効果が得られるとともに、演奏イベント情報間の間隔情報及び発音持続時間の情報が、音符の符長で表現されるすなわち近似されるので、データサイズを削減することができる。
【図面の簡単な説明】
【図１】本発明の実施形態における演奏イベントのシーケンスについての圧縮前後の楽曲データの一例を示す図である。
【図２】本発明の実施形態における楽曲データの圧縮途中のフォーマットを示す図である。
【図３】本発明の実施形態における楽曲データの圧縮前のフォーマットを示す図である。
【図４】本発明の実施形態の基本システム構成を示す図である。
【図５】本発明の実施形態における着信メロディの配信サービを行うネットワークの具体例を示す図である。
【図６】本発明の実施形態における配信サーバのコンピュータのハードウエア構成を示すブロック図である。
【図７】本発明の実施形態における携帯電話機のハードウエア構成を示すブロック図である。
【図８】本発明の実施形態における楽曲データ圧縮処理の要部フローチャートである。
【図９】本発明の実施形態におけるシングルチャンネルチャンク圧縮処理のサブルーチンのフローチャートである。
【図１０】本発明の実施形態におけるマルチチャンネルチャンク圧縮処理のサブルーチンのフローチャートである。
【図１１】本発明の実施形態における配信処理の要部フローチャートである。
【符号の説明】
１…配信サーバ、２…携帯電話機、１０…ネットワーク

Claims (8)

1. 音符情報からなる演奏イベント情報の列を含む楽曲データを圧縮する楽曲データの圧縮方法であって、
   前記楽曲データの演奏イベント情報を、該演奏イベント情報の音符情報と直前の演奏イベント情報の音符情報との一致不一致のパターンに対応するステータス情報と、不一致である音符情報と、を含む演奏イベント情報に変換するようにしたことを特徴とする楽曲データの圧縮方法。
2. 前記音符情報中の音高情報を、初期音高からの差分で表現することを特徴とする請求項１記載の楽曲データの圧縮方法。
3. 前記初期音高は楽曲データに含まれるいずれかの音の音高であることを特徴とする請求項２記載の楽曲データの圧縮方法。
4. 前記楽曲データは複数チャンネルの演奏イベント情報で構成されるとともに、各演奏イベント情報をチャンネルを混在して時系列に配列し、該チャンネルを混在した時系列の順に前記音符情報の一致不一致を検出することを特徴とする請求項２または３記載の楽曲データの圧縮方法。
5. 前記楽曲データは複数チャンネルの演奏イベント情報で構成されるとともに、各演奏イベント情報をチャンネル毎に時系列に配列し、該チャンネル毎の時系列の順に前記音符情報の一致不一致を検出することを特徴とする請求項２または３記載の楽曲データの圧縮方法。
6. 前記初期音高はチャンネル毎に設定され、前記音高情報を該チャンネル毎に前記差分で表現することを特徴とする請求項４または５記載の楽曲データの圧縮方法。
7. 前記初期音高が１つ設定され、前記音符情報をチャンネルを混在して前記差分で表現することを特徴とする請求項４記載の楽曲データの圧縮方法。
8. 前記音符情報中に前記演奏イベント情報間の間隔情報及び発音持続時間の情報を含み、該間隔情報及び発音持続時間の情報を、予め決められた音符の符長で表現するようにしたことを特徴とする請求項１、２、３、４、５、６または７記載の楽曲データの圧縮方法。

Images