JP2002091437A

JP2002091437A - 演奏情報圧縮装置、演奏情報復号装置及び電話端末装置

Info

Publication number: JP2002091437A
Application number: JP2000283179A
Authority: JP
Inventors: Kazuo Hikawa; 和生飛河
Original assignee: Victor Company of Japan Ltd
Current assignee: Victor Company of Japan Ltd
Priority date: 2000-09-19
Filing date: 2000-09-19
Publication date: 2002-03-27

Abstract

(57)【要約】【課題】着信メロディのデータ量を効率的に圧縮
してメモリに記憶すると共に、通話着信後直ちに着信メ
ロディの再生を開始する。【解決手段】着信時に再生する楽曲の演奏情報を時間
軸上で２つ以上のブロックに分割し、最初のブロックに
ついては着信後すぐに解凍して演奏できる状態でメモリ
に記憶しておく。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、演奏情報のデータ
量を圧縮する演奏情報圧縮装置、復号を行う演奏情報復
号装置及びこれらの装置を内蔵した電話端末装置に関す
る。

【０００２】

【従来の技術】一般に、ＭＩＤＩ（Musical Instrumen
t Digital Interface）データを保存する方式とし
て、スタンダードＭＩＤＩファイル（以下、ＳＭＦとい
う）が広く用いられ、このＳＭＦでは図１９に示すよう
に個々の演奏情報がデルタ（Δ）タイムとイベントの２
つの要素により構成されている。Δタイムは、隣合った
イベント間の相対時間を表し、イベントはノートオン又
はノートオフのステータス、音程（ノートナンバ）や音
の強さ（ベロシティ）などの種々の演奏情報を含む。こ
こで、演奏情報とは音符により示される音程、音の長さ
の他に、音の強さ、楽曲の演奏上の拍子、テンポなどの
情報、さらに音源の種類、リセットコントロールの情報
などを含むものを指すものとする。また、このＳＭＦで
は各演奏情報が時間順に並んでトラックを構成してい
る。ここで、ＳＭＦ方式は記憶容量や伝送路の効率的利
用という点ではあまり優れたものではないので、携帯電
話の着信メロディや通信カラオケ、音楽データベースの
ように多数の楽曲データを記録、伝送するシステムで
は、演奏情報のデータ量を効率的に圧縮することが求め
られている。

【０００３】これと同時に、携帯電話の着信メロディで
は、電話が着信したときに着信したことを着信メロディ
の再生によって知らせるが、この着信メロディのファイ
ルをＳＭＦファイルとして携帯電話本体に保存する際
に、携帯電話本体の記憶容量の小さいメモリー部分に、
できる限り多くの曲ファイルを記録することが求められ
ている。

【０００４】一方、テキスト等のデジタルデータを可逆
的（ロスレス）に圧縮する方法としては、文字列（デー
タパターン）が繰り返すことを利用して繰り返し分を圧
縮するＬＺ（Lempel-Zif）法が現在広く使用され、ＬＺ
法は一般に使われている可逆式圧縮方法の中で、圧縮率
が最も高いと言われている。ＬＺ法は文字列が繰り返す
ことを利用して圧縮するので、入力データの中の限られ
た範囲内に出現する同一のデータパターンの数が多く、
且つ同一データパターン長が長い場合に圧縮率が高くな
るという性質を有する。

【０００５】そこで、本出願人は、特開平９？１６１６
８において、ＬＺ法により圧縮する前に予め、同一のデ
ータパターンの長さが長く、出現回数が多く且つ近い距
離で出現するように、演奏情報を音程と、強さと、長さ
とその他の情報に分離し、それぞれ独立した領域に配置
するように、演奏情報を少なくとも音程の情報と、音の
強さの情報と、音の長さの情報とその他の情報に分離
し、各情報をそれぞれ独立した領域に配置した１次符号
を生成する１次符号生成手段と、前記１次符号生成手段
により生成された１次符号の各領域の情報をＬＺ法によ
り圧縮する２次符号生成手段とを有する演奏情報圧縮装
置を提案した。

【０００６】この装置では、１次符号生成手段が、各イ
ベント間の相対時間の公約数及び各音符の長さの公約数
を算出し、各イベント間の相対時間及び各音符の長さの
値をこれらの公約数で除算した後符号化するよう構成さ
れていることは前記提案の好ましい態様である。また、
１次符号生成手段が、各音符の音程情報をそれ以前に出
現した音符の音程の数値を使って一定の関数式に従って
算出した数値と実際の音程の数値との残差で表すよう構
成されていることは本発明の好ましい態様である。ま
た、１次符号生成手段が、各音符の強さ情報をそれ以前
に出現した音符の強さの数値を使って一定の関数式に従
って算出した数値と実際の強さの数値との残差で表すよ
う構成されていることは前記提案の好ましい態様であ
る。

【０００７】また、１次符号生成手段が、特定の種類の
イベントのパラメータ値をそれ以前に出現した同種類の
イベントのパラメータ値を使って一定の関数式に従って
算出した数値と実際のパラメータ値との残差で表すよう
構成されていることは前記提案の好ましい態様である。
また、１次符号生成手段が、各情報を当該領域において
トラック順に配置することは本発明の好ましい態様であ
る。さらに、１次符号生成手段が、前記各領域をデータ
の性質が似ている領域同志が近くなるように配置するこ
とは前記提案の好ましい態様である。

【０００８】

【発明が解決しようとする課題】最近の着信メロディは
ｉモード等のサービスサイトよりダウンロードすること
によって着信メロディファイルを得ることが主流になり
つつあるが、ユーザは着信メロディ楽曲ファイル（以下
ファイルと称する）の入手のために会費を支払ってお
り、携帯電話本体の内蔵メモリが少ないと、既にダウン
ロードしたファイルのファイルサイズの合計がメモリー
の容量を超えた際に、以前に購入したファイルを消去し
なければならなくなる。また、この状況はユーザが自ら
演奏データを入力する場合、あるいは専用のパーソナル
コンピュータ等のソフトウエアを用いてファイルを携帯
電話本体に記録する場合に於いても、同様な問題が発生
する。また、今後は着信メロディのファイルフォーマッ
トとしてＳＭＦ（スタンダードＭＩＤＩファイル）が用
いられることが予想され、従来の専用ファイルよりも個
々のファイルサイズが大きくなってしまう点が問題点と
して指摘されている。

【０００９】そこで、前記提案に記したようなファイル
圧縮技術を用いることにより、ファイルサイズを小さく
することが容易に考えられるが、携帯電話に搭載される
ＣＰＵによって前記提案のような圧縮処理を行うと、再
生しようとするファイルの全てを解凍し終わらない限り
演奏の開始が行えないことと、実際の端末側の処理速度
が遅いことにより、電話を着信してから着信メロディの
再生音を出力することが可能となるまでに、かなりの時
間がかかってしまうことが問題となっている。

【００１０】本発明は上記従来の問題点に鑑み、そこ
で、予め携帯電話などの電話端末の内部・外部メモリー
などにあらかじめ指定された１つまたは複数のファイル
を解凍した状態で保存することにより、電話着信時に即
座に着信メロディを再生することを可能とする。

【００１１】

【課題を解決するための手段】本発明は上記目的を達成
するために、演奏情報を少なくとも音程の情報と、音の
強さの情報と、音の長さの情報と、その他の情報に分離
し、前記各情報をそれぞれ独立した領域に配置した１次
符号を生成する１次符号生成手段と、前記１次符号生成
手段により生成された１次符号の各領域の情報を圧縮す
る２次符号生成手段と、前記演奏情報を時間軸上で２つ
以上のブロックに分割し、少なくとも最初のブロックに
ついては前記１次符号生成手段による圧縮及び／又は前
記２次符号生成手段による圧縮を行わないことを特徴と
する演奏情報圧縮装置を提供する。

【００１２】また、前記１次符号生成手段は、各イベン
ト間の相対時間の公約数及び各音符の長さの公約数を算
出し、各イベント間の相対時間及び各音符の長さの値を
これらの公約数で除算した後符号化することを特徴とす
る請求項１に記載の演奏情報圧縮装置を提供する。

【００１３】更に、前記１次符号生成手段は、各音符の
音程情報をそれ以前に出現した音符の音程の数値を使っ
て一定の関数式に従って算出した数値と実際の音程の数
値との残差で表すことを特徴とする請求項１又は２に記
載の演奏情報圧縮装置を提供する。

【００１４】更にまた、前記１次符号生成手段は、各音
符の強さ情報をそれ以前に出現した音符の強さの数値を
使って一定の関数式に従って算出した数値と実際の強さ
の数値との残差で表すことを特徴とする請求項１乃至３
のいずれか一項に記載の演奏情報圧縮装置を提供する。

【００１５】また更に、前記１次符号生成手段は、特定
の種類のイベントのパラメータ値をそれ以前に出現した
同種類のイベントのパラメータ値を使って一定の関数式
に従って算出した数値と実際のパラメータ値との残差で
表すことを特徴とする請求項１乃至４のいずれか一項に
記載の演奏情報圧縮装置を提供する。

【００１６】また、前記１次符号生成手段は、前記各情
報を当該領域においてトラック順に配置したことを特徴
とする請求項１乃至５のいずれか一項に記載の演奏情報
圧縮装置を提供する。

【００１７】更に、前記１次符号生成手段は、前記各領
域をデータの性質が似ている領域同志が近くなるように
配置したことを特徴とする請求項６に記載の演奏情報圧
縮装置を提供する。

【００１８】更にまた、演奏情報を少なくとも音程の情
報と、音の強さの情報と、音の長さの情報と、その他の
情報に分離し、前記各情報をそれぞれ独立した領域に配
置した１次符号を復号する演奏情報復号装置であって、
供給される前記１次符号を演奏情報に復号する１次符号
復号手段を有することを特徴とする演奏情報復号装置を
提供する。

【００１９】また更に、演奏情報を記憶可能で、且つ前
記演奏情報を電話着信時に再生する機能を有する電話端
末装置において、前記演奏情報を時間軸上で二つ以上の
ブロックに分割し、少なくとも最初のブロックが電話着
信時に直ちに演奏できるように二番目以降のブロックの
みを圧縮して記録することを特徴とする電話端末装置を
提供する。

【００２０】また、演奏情報を記憶可能で、且つ前記演
奏情報を電話着信時に再生する機能を有する電話端末装
置において、前記演奏情報を時間軸上で二つ以上のブロ
ックに分割して、それぞれのブロックを圧縮するとき
に、少なくとも最初のブロックは、電話着信時に直ちに
演奏でき、且つ、圧縮された二番目のブロックの復号を
行うことができる時間の長さ及び／又は二番目以降のブ
ロックの圧縮方法よりも短時間で復号可能な圧縮方法で
圧縮されていることを特徴とする電話端末装置を提供す
る。

【００２１】

【発明の実施の形態】以下、図面を参照して本発明の実
施の形態について説明する。図１は本発明に係る演奏情
報圧縮装置の一例を示すブロック図、図２は図１の１次
符号生成手段の一例を詳細に示すブロック図、図３は図
２のチャネル分離手段により作成されるチャネルマップ
を示す説明図、図４は図２の解析手段の処理を説明する
ためのフローチャート、図５は図２の解析手段により作
成されるノートテーブルを示す説明図、図６は図２の解
析手段により作成されるコントローラテーブルを示す説
明図、図７は音符を表現するＳＭＦのΔタイムと本実施
例のデュレーションの関係を示す説明図、図８は図２の
ノートΔ符号生成手段の処理を説明するためのフローチ
ャート、図９は図２のノートΔ符号生成手段により生成
されるノートΔ符号を示す説明図、図１０は図２のデュ
レーション符号生成手段の処理を説明するためのフロー
チャート、図１１は図２のデュレーション符号生成手段
により生成されるデュレーション符号を示す説明図、図
１２は図２のノートナンバ符号生成手段により生成され
るノートナンバ符号を示す説明図、図１３は図２のベロ
シティ符号生成手段により生成されるベロシティ符号を
示す説明図、図１４は図２のコントローラ符号生成手段
により生成されるコントローラ符号を示す説明図、図１
５はＳＭＦの連続イベントブロックを示す説明図、図１
６は本実施例の連続イベントブロックを示す説明図、図
１７は図１６の連続イベントブロックの効果を示す説明
図、図１８は図２の符号配置手段により並べ替えられた
１次符号を示す説明図、図２０は、本発明による端末装
置のうち、１次符号化された状態で指定楽曲を保存する
態様による端末の構成を示す説明図、図２１は、本発明
による端末装置のうち、１次符号化も２次符号化もされ
ない状態で指定楽曲を保存する態様による端末の構成を
示す説明図、図２２は、本発明による端末装置のうち、
１次符号化された状態で指定楽曲を追加的に保存する態
様による端末の構成を示す説明図、図２３は、本発明に
よる端末装置のうち、１次符号化も２次符号化もされな
い状態で指定楽曲を追加的に保存する態様による端末の
構成を示す説明図である。

【００２２】先ず、入力データ１は一例として図７、図
１９に示すようなＳＭＦであり、ＳＭＦのフォーマット
はΔタイム、ステータス、ノートナンバ及びベロシティ
により構成されている。ここで、本明細書では「発音開
始イベント」を「ノートオンイベント」、「発音停止イ
ベント」を「ノートオフイベント」と呼ぶ。また「ノー
トオンイベント」と「ノートオフイベント」を合わせて
「ノートイベント」と呼び、それ以外の「イベント」を
「コントローライベント」と呼ぶ。

【００２３】図１において、ＳＭＦフォーマットの入力
データ１は１次符号生成手段２により解析され、少なく
とも演奏情報を音程と、強さと、長さとその他の情報に
分離され、各情報がそれぞれ独立した領域に配置した１
次符号３が生成される。この１次符号３の各領域の符号
は２次符号生成手段４によりＬＺ法で圧縮され、２次符
号５が生成される。なお、このように圧縮されたデータ
は図２０〜図２８に詳しく示す復号装置によりＬＺ法で
復号され、音程と、強さと、長さとその他の情報に基づ
いて音符が復元される。

【００２４】１次符号生成手段２は例えば図２に詳しく
示すように、チャネル分離手段１１と、解析手段１２
と、ノートΔ符号生成手段１３と、コントローラΔ符号
生成手段１４と、デュレーション符号生成手段１５と、
ノートナンバ符号生成手段１６と、ベロシティ符号生成
手段１７と、コントローラ符号生成手段１８と符号配置
手段１９で構成され、この例では１つの音符を示すノー
トΔ符号、コントローラΔ符号、デュレーション符号、
ノートナンバ符号、ベロシティ符号及びコントローラ符
号の６種類の１次圧縮符号が符号配置手段１９により並
べ換えられ、１次符号３として２次符号生成手段４に出
力され、２次符号生成手段４により２次圧縮される。

【００２５】チェネル分離手段１１ではＳＭＦ１の１ト
ラックに複数チャネルのイベントが含まれているか否か
のチェックを行ない、複数チャネルのイベントが含まれ
ている場合には、１トラックの中に１チャネルのイベン
トのみが含まれるように、トラックの分割を行う。そし
て、図３のようなトラックとチャネル番号の対応を表し
たチャネルマップを作成し、これ以降の処理はトラック
単位で行う。ここで、ＳＭＦのイベントの大半はチャネ
ル情報を含んだものであるが、このようにトラック分割
とチャネルマップの作成を行うことにより、個々のイベ
ントのチャネル情報を省略することができ、データ量を
削減することができる。

【００２６】解析手段１２では図４に示す処理を行い、
トラック毎に図５に示すようなノートテーブルと図６に
示すようなコントローラテーブルを作成する。先ず、Ｓ
ＭＦから順次Δタイムとイベントを読み出し（ステップ
Ｓ１）、Δタイムからトラックの先頭を基準としたイベ
ントの時間（以下では単に、イベントの時間と呼ぶ）を
計算する（ステップＳ２）。次にイベントを解析し、イ
ベントを「ノートオンイベント」、「ノートオフイベン
ト」、「コントローライベント」の３種類に分類する。

【００２７】そして、「ノートオンイベント」の場合に
は図５に示すようなノートテーブルにノートナンバ（音
符の音程）とベロシティ（音符の強さ）を登録し（ステ
ップＳ３→Ｓ４）、「ノートオフイベント」の場合には
デュレーション（音符の長さ）を計算してノートテーブ
ルに登録する（ステップＳ５→Ｓ６）。また、「コント
ローライベント」の場合には図６に示すようなコントロ
ーラテーブルに登録し（ステップＳ７）、このようにし
て演奏情報毎にノートテーブルとコントローラテーブル
を作成する（ステップＳ８→Ｓ１）。

【００２８】ここで、ノートテーブルは図５に示すよう
にトラックのノート（音符）イベント情報を時間順に並
べたものであり、コントローラテーブルは図６に示すよ
うに、トラックのコントローラ（音符以外）の情報を時
間順に並べたものである。また、「ノートオンイベン
ト」の場合にノートナンバとベロシティを書き込む際
に、イベントの時間をノートテーブルの所定の欄に書き
込み、また、ノートテーブルの「ノートオフ参照」欄を
初期値として「０」にセットする。

【００２９】また、イベントがノートオフであれば、ノ
ートテーブルを先頭から走査して、ノートオフイベント
の時間よりも早く、かつノートナンバが同じで、かつノ
ートオフ参照欄が「０」にセットされているノートを選
び出し、対応させる。そして対応するノートオンの時間
Ｔｏｎとノートオフの時間Ｔｏｆｆとの差（Ｔｏｆｆ−
Ｔｏｎ）を「デュレーション（音符の長さ）」とし、ノ
ートテーブルの「デュレーション」欄に記録するととも
に、「ノートオフ参照」欄を「１」にセットする。

【００３０】ここで、「デュレーション」という概念は
ＳＭＦにはないが、これを用いることによりノートオフ
イベントを省略できるので、データ容量が削減できる。
ＳＭＦにおいて、１つの音符は図７のように１つのノー
トオンイベントと１つのノートオフイベントの組で表さ
れ、また、ノートオフイベントの前のΔタイムがデュレ
ーションに相当する。ノートオフイベントのノートナン
バは、ノートオンイベントとの対応を取る為に必要であ
り、デュレーションという概念を使ってノートオンとノ
ートオフの対応を取っておけば不要である。

【００３１】また、ノートオフイベントのベロシティ
は、ＭＩＤＩデータを受け取るほとんどの音源が実際に
はこの値を使用しないので、削除しても問題ない。した
がって、ノートオフイベント（３バイト）を省略するこ
とにより、場合によってはΔタイムのデータ量が増える
こともあるが、いずれにしてもノートオフイベント省略
の効果の方が大きく、１つの音符につき最大３バイト分
を削減することができる。その結果、１つの楽曲の中に
１万個程度の音符が含まれている場合も珍しくないの
で、この場合には最大３０Ｋバイトの削減ができること
になり、圧縮効果が大きい。

【００３２】イベントがノートオン、ノートオフ以外の
イベントであれば、イベントの時間とイベントの内容を
コントローラテーブルに登録し、このようにしてノート
テーブルにはＮＡ個のイベントが登録され、コントロー
ラテーブルにはＮＢ個のイベントが登録される。

【００３３】次に、ノートΔ符号生成手段１３とコント
ローラΔ符号生成手段１４について説明する。この２つ
は、同じような処理内容であるので、以下ではノートΔ
符号生成手段１３を例に取って説明する。ノートΔ符号
生成手段１３は図８に示すように、先ず、前述したノー
トテーブルに登録された各イベントに対し、その時間Ｔ
［ｉ］と１つ前のイベントの時間Ｔ［ｉ−１］との差 ΔＴ［ｉ］＝（Ｔ［ｉ］−Ｔ［ｉ−１］）を計算し（ステップＳ１１）、ノートテーブルの所定の
欄に書き込む（但し、ｉ＝１〜ＮＡ，Ｔ［０］＝０）。
すなわち、各ノートイベント間の相対時間が求まる。

【００３４】ここで、ＳＭＦにおいて、Δタイムは１拍
の何分の１かを基本単位にした可変長符号で表され、値
が小さいほど必要なバイト数は少なくて済む。例えば、
値が１２７以下であれば１バイトでよいが、値が１２８
以上１６３８３以下であれば、２バイト必要となる。Δ
タイムの基本単位が細かいほど音楽的な表現力は高いと
言えるが、それに従って必要なバイト数も増える。一
方、実際に楽曲に使われているΔタイムを調べると、基
本単位の１刻み（１ｔｉｃｋ）まで使っていないことが
多く、したがって、ΔＴ［ｉ］の値が必要以上の容量を
使って記録されていることが多い。

【００３５】そこで、実際に使用されている時間精度を
求める為に、ノートテーブルに登録されている全ての相
対時間ΔＴ［ｉ］に対する最大公約数ΔＴｓを算出する
（ステップＳ１２）。この場合、最大公約数を求めるの
が困難な場合は、適当な公約数を最大公約数ΔＴｓとす
る。次いで、ΔＴ［ｉ］をＳＭＦと同様の可変長符号で
出力する（ステップＳ１３〜Ｓ１７）。ただし、ΔＴ
［ｉ］の値を可変長符号にする際に、ΔＴ［ｉ］をΔＴ
ｓで除算した値ΔＴａ［ｉ］を符号化する（ステップＳ
１５）。したがって、ノートΔ符号は図９のように最大
公約数ΔＴｓと、ＮＡ個の値ΔＴａ［ｉ］（ｉ＝1〜Ｎ
Ａ）により構成される。

【００３６】ここで、本演奏情報圧縮装置により圧縮さ
れた符号を伸長する際には、ΔＴａ［ｉ］の値を読み取
りΔＴｓをかけ合わせることで元のΔＴ［ｉ］が復元さ
れ、したがって、ＳＭＦの持つ音楽的な表現力を失うこ
となくデータ量を削減することができる。例えばΔタイ
ムの基本単位を一般的に良く使われる４８０分の１拍と
し、ΔＴｓ＝１０である場合を例にすると、ＳＭＦでは
１拍の長さΔＴ＝４８０や１／２拍の長さΔＴ＝２４０
を表現するのに各々２バイト必要である。一方、本発明
ではΔＴｓで除算して表現することによりΔＴ＝４８あ
るいはΔＴ＝２４を表現すればよいことになり、各々１
バイトの使用で済む。また、１拍あるいは１／２拍に相
当するΔタイムは使用頻度が高いので、これらが１つの
Δタイムにつき１バイトずつ削減されれば、楽曲全体で
相当の容量を削減することができる。

【００３７】コントローラΔ符号生成手段１４は、処理
対象がノートテーブルではなくコントローラテーブルで
あるという点以外はノートΔ符号生成手段１３と全く同
じ処理であり、生成されるコントローラ符号の構成も符
号の数がＮＡ個からＮＢ個に変わる以外は、図９に示す
ノートΔ符号と同じである。

【００３８】デュレーション符号生成手段１５はノート
Δ符号生成手段１３とほぼ同じであり、図１０に従って
処理を行う。まず、ノートテーブルに登録された各デュ
レーションの値の最大公約数Ｄｓを算出する（ステップ
Ｓ２１）。この場合、最大公約数を求めるのが困難な場
合は、適当な公約数を最大公約数Ｄｓとする。デュレー
ション符号は図１１に示すように最大公約数Ｄｓと、Ｎ
Ａ個の値Ｄａ［ｉ］（ｉ＝1〜ＮＡ）により構成され、
最大公約数Ｄｓに続き、各デュレーションの値Ｄ［ｉ］
をＤｓで割った値Ｄａ［ｉ］を可変長符号として出力す
る（ステップＳ２２〜Ｓ２６）。ここで、デュレーショ
ンは前述したように、ＳＭＦのノートオンイベントとノ
ートオフイベントの間のΔタイムに相当するので、ノー
トΔ符号生成手段１３において説明したのと同様な理由
により、ＳＭＦに比べデータ量が削減される。

【００３９】ノートナンバ符号生成手段１６では、ノー
トテーブルに登録されているノートナンバに対し、以下
の処理を施すことによりノートナンバ符号を生成する。
ここで、あるノートナンバｎｕｍ［ｉ］を（１）式のよ
うにそれ以前のＳ個のノートナンバｎｕｍ［ｉ−１］、ｎｕｍ［ｉ−２］、…、ｎｕｍ［ｉ
−Ｓ］を変数とする関数ｆ（）と残差α［ｉ］で表す（ただ
し、ｎｕｍ［ｉ−１］はｎｕｍ［ｉ］の１つ前のノート
ナンバ、ｎｕｍ［ｉ−２］はｎｕｍ［ｉ］の２つ前のノ
ートナンバを表す）。

【００４０】ノートナンバ符号は図１２に示すように、
ｉ≦Ｓのイベントに対するノートナンバと、ｉ＞Ｓのイ
ベントに対して残差α[ｉ]を時間順に並べたものにより
構成される。したがって、圧縮時と伸長時で同じ関数ｆ
（）を使えば、残差α[ｉ]からｎｕｍ［ｉ］を復元する
ことができる。ｎｕｍ［ｉ］＝ｆ（ｎｕｍ［ｉ−１］，ｎｕｍ［ｉ−２］， …，ｎｕｍ［ｉ−Ｓ］）＋α［ｉ］ …（１）但し、イベントの数をＮＡとして、ｉ＝(Ｓ＋１)，(Ｓ＋２)，…，ＮＡここで、関数ｆ（）には種々のものが考えられるが、な
るべく同じ値のα｛ｉ］が繰り返して出現するようなも
のを選ぶことにより、２次符号生成手段４で効率の良い
圧縮が可能となる。一例として（２）式のような関数を
使った場合の効果を説明する。これはＳ＝１であり、１
つ前のノートナンバとの差分をα［ｉ］とすることを意
味する。ただしｉ＝１の場合はノートナンバそのものを
ノートナンバ符号として出力する。ｎｕｍ［ｉ］＝ｎｕｍ［ｉ−１］＋α［ｉ］ …（２）但し、イベントの数をＮＡとして、ｉ＝２，３，…，ＮＡここで、通常の楽曲においては、コード（和音）のルー
ト音（根音）の平行移動量と同じ音程だけ移動したメロ
ディーラインが存在することが多い。例えば「Ｃ」コー
ドの小節で「ド、ド、ミ、ソ、ミ」というメロディーラ
インがある場合に、ルート音が２度高い「Ｄ」コードの
小節において「レ、レ、#ファ、ラ、レ」というよう
に、最初のメロディーラインを２度上げたメロディーラ
インが存在することが多い。

【００４１】この各々のメロディーラインをＳＭＦのノ
ートナンバそのもので表すと、「６０，６０，６４，６
７，６０」、「６２，６２，６６，６９，６２」とな
り、この２つに共通のデータパターンは全くない。しか
し前述のα［ｉ］で表現すると、どちらのメロディーラ
インもその２音目以降は「０，４，３，−７」となり同
一のパターンとなる。このようにＳＭＦでは全く異なる
２つのデータパターンを、本手法により同一のデータパ
ターンに変換することができる。

【００４２】ＬＺ法では、同一のデータパターンが多い
ほど圧縮率が高くなるので、このようなノートナンバの
表現方法により圧縮率が高くなることは明らかである。
なお（１）式でＳ＝０とすると、ｎｕｍ［ｉ］＝α［ｉ］となり、ノートナンバそのものを符号化することにな
る。また関数ｆ()を何種類か用意しておき、最も適切な
関数を選択して符号化するとともに、どの関数を使用し
たかという情報を合わせて符号化してもよい。

【００４３】ベロシティ符号生成手段１７もノートナン
バ符号生成手段１６と同様である。ノートテーブルに登
録されたある音符のベロシティｖｅｌ［ｉ］を（３）式
のように、それ以前に出現したＴ個の音符のベロシティｖｅｌ［ｉ−１］，ｖｅｌ［ｉ−２］，…，ｖｅｌ［ｉ
−Ｔ］を変数とする関数ｇ()と残差β［ｉ］で表す（ただし、
ｖｅｌ［ｉ−１］はｖｅｌ［ｉ］の１つ前のベロシテ
ィ、ｖｅｌ[ｉ−２]はｖｅｌ［ｉ］の２つ前のベロシテ
ィ）。

【００４４】ベロシティ符号は図１３に示すように、ｉ
≦Ｔのイベントに対するベロシティと、ｉ＞Ｔのイベン
トに対して残差β[ｉ]を時間順に並べたものにより構成
される。したがって、圧縮時と伸長時で同じ関数ｇ()を
使えば、残差β[ｉ]からｖｅｌ［ｉ］を復元でき、ま
た、関数ｇ()を適当に選ぶことにより、同じデータパタ
ーンのβ［ｉ］が繰り返して出現することになり、ＬＺ
法を用いた場合の圧縮率を改善することができる。ｖｅｌ［ｉ］＝ｇ（ｖｅｌ［ｉ−１］，ｖｅｌ［ｉ−２］，…，ｖｅｌ［ｉ−Ｔ］）＋β［ｉ］（３）但し、イベントの数をＮＡとして、ｉ＝（Ｔ＋１），（Ｔ＋２），…，ＮＡ次に、コントローラ符号生成手段１８について説明す
る。コントローラ符号は図１４に示すように、図６に示
すコントローラテーブルに登録されたイベントの情報を
時間順に並べたものである。各コントローラ符号は、イ
ベントの種類を表すフラグＦとパラメータ（データバイ
ト）で構成される。パラメータの個数はイベントの種類
により異なる。イベントの種類は大きく分けて「通常イ
ベント」と「連続イベント」の２つのタイプがある。フ
ラグＦの最上位ビットが「１」、パラメータの最上位ビ
ットが「０」に設定されているので、ＳＭＦと同様のラ
ンニングステータス表現（前のイベントと同じ種類のイ
ベントの場合にフラグＦを省略すること）が可能になっ
ている。

【００４５】ここで、ＳＭＦではイベントの種類をあら
わすのに１バイトのＭＩＤＩステータスが使われてい
る。一般的に使用される値は、８ｎ（ｈｅｘ）、９ｎ
（ｈｅｘ）、Ａｎ（ｈｅｘ）、Ｂｎ（ｈｅｘ）、Ｃｎ
（ｈｅｘ）、Ｄｎ（ｈｅｘ）、Ｅｎ（ｈｅｘ）、Ｆ０
（ｈｅｘ）、ＦＦ（ｈｅｘ）のいずれかである（ただ
し、ｎ＝０〜Ｆ（ｈｅｘ）、ｎはチャネル番号であ
る）。「通常イベント」は、上記ＭＩＤＩステータスか
らノートオン８ｎ（ｈｅｘ）とノートオフ９ｎ（ｈｅ
ｘ）を除いたものであるが、本発明では前述したように
チャネル番号を表現する必要が無いので、「通常イベン
ト」のフラグの種類は７種類となる。従ってＭＩＤＩス
テータスに比べフラグＦは同じ値になる確率が高く、Ｌ
Ｚ法を用いた場合の圧縮率が高まる。「通常イベント」
の符号は、フラグＦの後に、ＳＭＦのＭＩＤＩステータ
ス１バイトを除いたデータバイトを並べたものである。

【００４６】また、ＳＭＦでは、特定の種類のイベント
が一定数以上連続して出現し、各々のイベントのパラメ
ータ値（データバイト）がほぼ一定の規則で変化する部
分が存在することが多い。例えば「ピッチホイールチェ
ンジ」イベントが使われている部分である。このイベン
トは、音符の音程を微妙に変えて音楽的な表現力を高め
る為のものであり、その性質上パラメータ値の異なる複
数イベントが連続して使われることが多い。このような
イベントを「連続イベント」と呼び、このような部分を
「連続イベントブロック」と呼ぶ。

【００４７】以下の説明では、「連続イベント」の一例
として「ピッチホイールチェンジ」を取りあげるが、こ
れに限定されるものではない。ＳＭＦの「連続イベント
ブロック」の一例を図１５に示す。この場合、各イベン
トのパラメータ値が異なる為、ＳＭＦの同一データパタ
ーンの長さは、（Δタイム・１バイト＋ステータス・１
バイト）の計２バイトであり、この程度の長さではＬＺ
法による圧縮の効果はほとんど得られない。

【００４８】そこで、コントローラテーブルの中で「ピ
ッチホイールチェンジ」が一定数以上連続して出現し、
パラメータ値がほぼ一定の規則で変化する領域に対し、
以下の処理を施すことによりコントローラ符号を生成す
る。先ず、「ピッチホイールチェンジ」の数が一定数に
満たないような場合は、前述した「通常イベント」とし
て符号化する。そして、（４）式に示すように、連続イ
ベントブロック内のイベントのパラメータｐ［ｉ］をそ
れ以前に出現したＵ個のイベントのパラメータ値ｐ［ｉ−１］，ｐ［ｉ−２］，…，ｐ［ｉ−Ｕ］を変数とする関数ｈ()と残差γ［ｉ］で表す（ただし、
ｐ［ｉ−１］はｐ［ｉ］の１つ前のパラメータ値、ｐ
［ｉ−２］はｐ［ｉ］の２つ前のイベントのパラメータ
値）。

【００４９】連続イベントの符号の構成は図１６に示す
ように、ピッチホイールチェンジが連続していることを
意味するフラグＦに続き、１番目からＵ番目までのイベ
ントに対してはパラメータの値そのものである。そし
て、（Ｕ＋１）番目以降のイベントでは、γ［ｉ］を時
間順に並べたものである。ｐ［ｉ］=ｈ（ｐ［ｉ−１］，ｐ［ｉ−２］，…，ｐ［ｉ−Ｕ］）+γ［ｉ］（４）ただし、連続イベントブロックのイベント数をNCとしてｉ＝（Ｕ＋１），（Ｕ＋２),…，ＮＣ関数ｈ()には種々のものが考えられるが、なるべく同じ
値のγ［ｉ］が繰り返して出現するようなものを選ぶこ
とにより、２次符号生成手段４において効率の良い圧縮
が可能となる。一例として（５）式のような関数を使っ
た場合の効果を説明する。これはＵ＝１であり、１つ前
のパラメータとの差分をとることを意味する。ｐ［ｉ］＝ｐ［ｉ−１］＋γ［ｉ］（５）ただし、連続イベントブロックのイベント数をＮＣとし
てｉ＝ｉ＝２，３，…，ＮＣこの方法によれば、図１５に示す領域は図１７のような
コントローラ符号に変換される。この場合、２番目以降
のイベントのデータが全て同一の「１」になる為、ＬＺ
法による圧縮率が高まる。また、コントローラ符号には
Δタイムが含まれないので、Δタイムがイベント毎に異
なる場合でも、ＬＺ法における圧縮率低下の影響が少な
い。また場合によっては、（４）式の代わりに、イベン
トの時間情報も変数に使った（６）式のような関数
ｅ（）を使っても良い。ただし、ｔ［ｉ］はパラメータ
を求めるイベントの時間、ｔ［ｉ−１］はその１つ前の
イベントの時間である。ｐ［ｉ］＝ｅ（ｐ［ｉ−１］，ｐ［ｉ−２］，…，ｐ［ｉ−Ｕ］，ｔ［ｉ］，ｔ［ｉ−１］，…，ｔ［ｉ−Ｕ］）＋γ［ｉ］（６）ただし、連続イベントブロックのイベント数をＮＣとし
てｉ＝（Ｕ＋１），（Ｕ＋２），…，ＮＣ符号配置手段１９では、上記の各符号を図１８のような
領域に配置して１次符号３を生成する。ヘッダは各符号
の開始アドレスや長さといった管理情報と前述したチャ
ネルマップを含んでいる。すでに説明したように各符号
はＳＭＦに比べ、同一データの出現回数が多く、同一デ
ータパターンの長さも長いという性質を持っているが、
さらに同一データパターンが近い距離で出現するように
工夫をしている。まず、同じ種類の符号内で、同じデー
タ列が出現する確率が高いので、トラック順に同一種類
の符号を配置している。また、ノートΔ符号とコントロ
ーラΔ符号とデュレーション符号は、全て時間情報であ
り、性質の異なるノートナンバ符号やベロシティ符号よ
りも同じデータ列が出現する確率が高いので、これらの
距離が近くなるように配置している。

【００５０】次に、図１９で示した例に戻って、同一デ
ータパターンの長さがどの程度改善されるか具体的に検
討する。ここで、各々のメロディは、５０個のノートオ
ンイベントと５０個のノートオフイベントで構成されて
おり、全てのΔタイムは１バイトであるとし、全てのイ
ベントは３バイトであると仮定すると、各々のメロディ
のノートナンバは前述したように全て同じである。

【００５１】ＳＭＦにおいて、各々のメロディのデータ
量は、（１＋３）×５０×２＝４００バイトである。各々のメロディのΔタイムとベロシティが全て
同じならば、同一データパターンの長さは４００バイト
になる。しかし両メロディ間の全てのΔタイムとノート
オンのベロシティが異なっているとすると、ＳＭＦで同
一データパターンの最大長は、ノートオフステータス、
ノートナンバ、ベロシティの並びの３バイトである。こ
の程度ではＬＺ法の圧縮はほとんど効果がない。

【００５２】一方、本発明では、Δタイム、ノートナン
バ、ベロシティを分離して符号化しているので、少なく
ともノートナンバ符号の中で５０バイトの長さの同一デ
ータパターンが出現する。また前述したようにＳＭＦの
ベロシティが全く異なる場合でも、ベロシティ符号の中
では同一データパターンが出現することが多い。従って
ＬＺ法による圧縮率は明らかに改善される。以上の説明
から分かるように１次符号３は、ＳＭＦの持つ音楽的な
情報量を全く落とすことなくデータ量が削減されている
と同時に、ＳＭＦに比べ同一のデータパターンの長さが
長く、出現回数が多く、しかもそれらが近い距離で出現
するようの性質を持っているので、２次符号生成手段４
において効果的な圧縮を行うことができる。また、この
１次符号３そのものも、かなり圧縮されたデータ量とな
っているので、この１次符号３を直接出力するようにし
てもよい。

【００５３】２次符号生成手段４においては、１次符号
生成手段２の出力３に対して、ＬＺ法による圧縮を行
う。ＬＺ法は、ｇｚｉｐ、ＬＨＡといった圧縮プログラ
ムで広く使われている手法である。これは入力データの
中から、同一のデータパターンを捜し、もし存在すれ
ば、(過去に出現したパターンへの距離、パターンの長
さ)という情報に置き換えて表現することでデータ量を
削減する。例えば、 ”ＡＢＣＤＥＡＢＣＤＥＦ” というデータを、”ＡＢＣＤＥ”が繰り返しであるの
で、 ”ＡＢＣＤＥ（５，５）Ｆ” という情報に置き換える。なお、圧縮符号（５，５）は
５文字戻って５文字コピーすることを表す。

【００５４】処理の概要は次のようになる。２次符号５
の生成は、処理位置を１次符号３の先頭から順次移動さ
せて行う。処理位置のデータパターンが、それ以前の一
定の範囲内のデータパターンと一致する場合は、処理位
置からそのデータパターンまでの距離と、一致したデー
タパターンの長さを２次符号５として出力し、処理位置
を２つ目のデータパターンの終わりに移動させ、処理を
続ける。処理位置のデータパターンが、それ以前の一定
の範囲内のデータパターンと一致しなければ、１次符号
３をコピーして２次符号５として出力する。

【００５５】以上の説明から明らかなように、２つの同
一のデータ領域が大きいほど、圧縮率は高くなる。また
同一のデータ領域の距離は一定範囲内である必要があ
る。前述したように楽曲の中では、同じようなメロディ
ーが繰り返し使われるが、ＳＭＦのままでそれらのデー
タを比較すると、完全に同一のデータ列の繰り返しであ
ることは少なく、むしろノートナンバは同じであるがベ
ロシティは異なるといったように、どこか一部分異なっ
ていることが多い。

【００５６】一方，本発明では、性質の同じデータを独
立した領域にまとめると同時に、各領域で同ーのデータ
がなるべく多く出現するような処理を行ない、さらに性
質の近い領域どうしをなるべく近くに配置することによ
り、ＬＺ法の圧縮率が高まるので、最終的な２次符号５
は十分容量の小さなものになる。なお、以上詳述したフ
ォーマット並びに処理手順は一例であり、その主旨を逸
脱しない範囲において種々の変更を加えることができ
る。また、演奏情報としてＳＭＦを例に取ったが、ＳＭ
Ｆに限らずこれに類似の演奏情報に対して本発明を適用
してデータ容量を効率よく削減することができる。

【００５７】次に、図２０〜図２８を参照して上記の１
次符号３又は２次符号５を復号するための演奏情報復号
装置について説明する。図２０は演奏情報復号装置を示
すブロック図、図２１は図２０の２次符号復号手段の処
理を説明するためのフローチャート、図２２は図２０の
１次符号復号手段の処理を説明するためのフローチャー
ト、図２３は図２２のトラック復号処理を詳しく説明す
るためのフローチャート、図２４は図２３のノートイベ
ント復号処理を詳しく説明するためのフローチャート、
図２５は図２４のノートイベント復号処理により復元さ
れたノートオンイベントを示す説明図、図２６は図２４
のノートイベント復号処理により復元されたノートオフ
キューを示す説明図、図２７は図２３のコントローライ
ベント復号処理を詳しく説明するためのフローチャー
ト、図２８は図２７の処理により復元されたコントロー
ライベントを示す説明図である。

【００５８】図２０では圧縮処理とは逆に、ＬＺ法で圧
縮された入力データ２１が２次符号復号手段２３により
音程と、音の強さと、音の長さとその他の情報に分離さ
れた１次符号３に復号され、次いで１次符号復号手段２
４により元の音符（出力データ２５）に復元される。制
御手段２６はスイッチ２２により、入力データ２１が図
１に示す２次符号５である場合に２次符号復号処理に続
き１次符号復号処理を行うように制御し、入力データ２
１が図１に示す１次符号３である場合に１次符号復号処
理のみを行うように制御する。

【００５９】ここで、２次符号５であるか又は１次符号
３であるかの判定は、キーボード、マウス、ディスプレ
イ等の図示しない入出力装置を使用してオペレータが指
定してもよいし、圧縮された情報に対して符号化方法の
種類を示す情報を符号化時に付加し、復号時にこの情報
を自動的に判別するようにしてもよい。

【００６０】次に、図２１を参照して２次符号復号手段
２３の復号処理を説明する。入力データ１１（２次符号
５）を先頭から読み込み（ステップＳ１０１）、次いで
圧縮データの部分であるかすなわちＡＢＣＤＥ（５，
５）の「ＡＢＣＤＥ」の部分（＝非圧縮データ）である
か又は「（５，５）」の部分（＝圧縮データ）であるか
を判定する（ステップＳ１０２）。

【００６１】そして、圧縮データの部分である場合には
過去に出現した同一パターンを参照してそれをコピーし
て出力し（ステップＳ１０３）、他方、非圧縮データの
部分である場合にはそのまま出力する（ステップＳ１０
４）。以下、入力データ１１を全て復号するまでこの処
理を繰り返すと（ステップＳ１０５→Ｓ１０１）、図１
８に示すような配置の１次符号３が復元される。

【００６２】次に、図２２及び図１８に示す１次符号３
を参照して１次符号復号手段２４の復号処理を説明す
る。先ず、１次符号３のヘッダを読み込む（ステップＳ
１１１）。ヘッダには総トラック数Ｎ、ノートΔ符号か
らコントロール符号までの各符号領域の先頭アドレス、
チャネルマップ、時間分解能等の情報が符号化の際に記
録されているので、このヘッダ情報に基づいてＳＭＦの
ヘッダを作成して出力する（ステップＳ１１２）。

【００６３】次にトラック番号ｉを「１」にセットし
（ステップＳ１１３）、図２３に詳しく示すトラック復
号処理を行う（ステップＳ１１４）。次いでトラック番
号ｉが総トラック数Ｎより小さいか否かをチェックし
（ステップＳ１１５）、もし小さければトラック番号ｉ
を１つインクリメントし（ステップＳ１１６）、ステッ
プＳ１１４に戻ってトラック復号処理を繰り返す。そし
て、ステップＳ１１５においてトラック番号ｉが総トラ
ック数Ｎより小さくない場合にこの１次符号復号処理を
終了する。

【００６４】図２３に詳しく示すトラック復号処理で
は、先ず、処理で使用する変数を初期化する（ステップ
Ｓ１２１）。具体的は、処理中のノートイベントの番号
を示す変数ｊを「１」にセットし、処理中のコントロー
ライベントの番号を示す変数ｋを「１」にセットし、ノ
ート終了フラグとコントローラ終了フラグをクリアす
る。ここで、ノート終了フラグは処理トラックの全ての
ノートイベントの復号が終了したことを示し、コントロ
ーラ終了フラグは処理トラックの全てのコントローライ
ベントの復号が終了したことを示す。

【００６５】次に処理トラック番号ｉのノートΔ符号の
最大公約数ΔＴｓｎと、コントローラΔ符号の最大公約
数ΔＴｓｃとデュレーション符号の最大公約数Ｄｓを読
み出す（ステップＳ１２２）。そして、ｊ番目のノート
Δ符号ΔＴａｎ［ｊ］とｋ番目のコントローラΔ符号Δ
Ｔａｃ［ｋ］を読み出し、（７）式のように各々最大公
約数ΔＴｓｎ、ΔＴｓｃを乗じてΔＴｎ［ｊ］、ΔＴｃ
［ｋ］を算出する（ステップＳ１２３）。 ΔＴｎ［ｊ］＝ΔＴａｎ［ｊ］×ΔＴｓｎ ΔＴｃ［ｋ］＝ΔＴａｃ［ｊ］×ΔＴｓｃ（７）さらに、（８）式のようにトラックの先頭を基準とした
時刻Ｔｎ［ｊ］、Ｔｃ［ｋ］に変換する（ステップＳ１
２４）。Ｔｎ［ｊ］＝Ｔｎ［ｊ−１］＋ΔＴｎ［ｊ］Ｔｃ［ｋ］＝Ｔｃ［ｋ−１］＋ΔＴｃ［ｋ］ただし、Ｔｎ［０］＝Ｔｃ［０］＝０（８）なお、ステップＳ１２３、Ｓ１２４では、ノート終了フ
ラグがセットされている場合にはΔＴｎ［ｊ］、Ｔｎ
［ｊ］の算出は行わず、また、コントローラ終了フラグ
がセットされている場合にはΔＴｃ［ｋ］，Ｔｃ［ｋ］
の算出は行わない。

【００６６】次に、出力すべきノートオフイベントの有
無をチェックし（ステップＳ１２５）、出力すべきデー
タが有る場合にはＳＭＦとしてノートオフイベントを出
力する（ステップＳ１２６）。なお、ステップＳ１２
５、Ｓ１２６については後述（図２４のステップＳ１４
４）する。次に、復号処理の選択を行う。先ず、コント
ローラ終了フラグをチェックし（ステップＳ１２７）、
セットされている場合には図２４に詳しく示すノートイ
ベント復号処理を行う（ステップＳ１２８）。

【００６７】コントローラ終了フラグがセットされてい
ない場合にはノート終了フラグをチェックし（ステップ
Ｓ１２９）、セットされている場合には図２７に詳しく
示すコントローライベント復号処理を行う（ステップＳ
１３０）。２つのフラグが共にセットされていない場合
にはＴｎ［ｊ］とＴｃ［ｋ］を比較し（ステップＳ１３
１）、Ｔｎ［ｊ］が小さければノートイベント復号処理
（ステップＳ１２８）を、そうでなければコントローラ
イベント復号処理（ステップＳ１３０）を行う。

【００６８】ノートイベント復号処理の後には、処理ト
ラックＮの全てのノートイベントを処理したか否かをチ
ェックし（ステップＳ１３２）、処理が終了している場
合にはノート終了フラグをセットし（ステップＳ１３
３）、ステップＳ１３８に進み、そうでなければ変数ｊ
を１つインクリメントし（ステップＳ１３４）、ステッ
プＳ１２３に戻る。また、コントローライベント復号処
理の後には、処理トラックＮの全てのコントローライベ
ントを処理したか否かをチェックし（ステップＳ１３
５）、処理が終了している場合にはコントローラ終了フ
ラグをセットし（ステップＳ１３６）ステップＳ１３８
に進み、そうでなければ変数ｋを１つインクリメントし
（ステップＳ１３７）、ステップＳ１２３に戻る。

【００６９】ステップＳ１３８ではノート終了フラグと
コントローラ終了フラグの両方がセットされているか否
かをチェックし、両方がセットされている場合にはこの
トラック復号処理を終了し、そうでなければステップＳ
１２３に戻ってこのトラック復号処理を繰り返す。

【００７０】図２４に詳しく示すノートイベント復号処
理では、先ず、ｊ番目のノートナンバ符号α［ｊ］を読
み取り、圧縮処理において使用した関数ｆ（）を用いて
（９）式に従ってノートナンバｎｕｍ［ｊ］を算出する
（ステップＳ１４１）。ｎｕｍ［ｊ］＝f（ｎｕｍ［ｊ−１］，ｎｕｍ［ｊ−２］，…，ｎｕｍ［ｊ−Ｓ］）＋α［ｊ］ (ｊ＞Ｓ) ｎｕｍ［ｊ]＝α［ｊ］（ｊ≦Ｓ）ただし、Ｓは関数ｆ（）の変数の個数（９）同様に、ｊ番目のベロシティ符号β［ｊ］を読み取り、
圧縮処理において使用した関数ｇ（）を用いて（１０）
式に従ってベロシティｖｅｌ［ｊ］を算出する（ステッ
プＳ１４２）。ｖｅｌ［ｊ］＝ｇ（ｖｅｌ［ｊ−１］，ｖｅｌ［ｊ−２］，…，ｖｅｌ［ｊ−Ｔ］）＋β［ｊ］（ｊ＞Ｔ) ｖｅｌ［ｊ］＝β［ｊ］ (ｊ≦Ｔ) ただし、Ｔは関数ｇ()の変数の個数（１０）次いで、Ｔｎ[ｊ］、ｎｕｍ［ｊ］，ｖｅｌ［ｊ］を用
いて図２５に示すようなノートオンイベントを出力する
（ステップＳ１４３）。なお、ＳＭＴのΔタイムΔＴ
は、Ｔｎ［ｊ］の直前に出力したイベントの時刻Ｔｂを
使って式（１１）に従って求め、出力する。 ΔＴ＝Ｔｎ［ｊ］−Ｔｂ（１１）図２５に示すノートオンイベントにおけるステータスバ
イトの上位４ビットはノートオン「９（ｈｅｘ）」を表
し、下位４ビットはチャネルマップから得られる番号が
続く。このステータスバイトの後にはノートナンバとベ
ロシティの各バイトが続く。

【００７１】次にノートオフイベントの登録を行う（ス
テップＳ１４４）。具体的にはデュレーション符号Ｄａ
［ｊ］を読み取って、（１２）式に従いノートオフイベ
ントの時刻Ｔoff を算出し、この時刻Ｔｏｆｆとノート
ナンバｎｕｍ[ｊ]を図２６に示すようなノートオフキュ
ーに登録する。このノートオフキューでは、使用されて
いるエントリの数を保持するとともに、ノートオフ時刻
Ｔｏｆｆが先頭から小さい順に並ぶように管理される。Ｔｏｆｆ［ｊ］＝Ｄａ［ｊ］×Ｄｓ＋Ｔｎ[ｊ] （１２）前述した図２３のステップＳ１２５においては、Ｔｎ
[ｊ]とＴｃ[ｋ]の内の値が小さいほうＴｍをノートオフ
キューの先頭のＴｏｆｆ[ｎ]（ｎ＝１〜エントリ総数
Ｎ）から順に比較する。Ｔｏｆｆ[ｎ]＜Ｔｍであるエン
トリがあればステップＳ１２６に進み、ノートオフイベ
ントを出力する。ステップＳ１２６では、前述したノー
トオフイベントをＳＭＦとして出力する。

【００７２】次に図２７を参照してコントローライベン
ト復号処理を詳しく説明する。この処理では図２８に示
すようにΔタイム、ステータス及びパラメータより成る
コントローライベントが復元され、先ず、Ｔｃ[ｋ]と直
前に出力したイベントの時刻Ｔｂを使って（１３）式に
従ってＳＭＴのΔタイムΔＴを求め、出力する（ステッ
プＳ１５１）。 ΔＴ＝Ｔｃ［ｋ］−Ｔｂ（１３）次にコントローラ符号領域からイベントの種類を表すイ
ベントフラグＦ［ｋ］を読み取り、Ｆ[ｋ］が「通常イ
ベント」であるか、「連続イベント」であるか又は「ラ
ンニングステータス」であるかを判定する（ステップＳ
１５２）。ここで、連続イベントブロック内では、図示
省略１６に示すように、２番目以降のイベントはイベン
トフラグが省略された「ランニングステータス」状態で
記録されている。

【００７３】Ｆ［ｋ］が「通常イベント」である場合に
は、処理イベントの連続イベントブロック内における順
番を示す変数ｍを「０」にリセットし（ステップＳ１５
３）、次いでチャネルマップを参照してＳＭＦのステー
タスバイトを作成して出力する（ステップＳ１５４）。
さらにイベントの種類に応じて必要なバイト数をコント
ローラ符号領域から読み出し、この読み出した値がＳＭ
Ｆのパラメータ（データバイト）であるのでこれを出力
する（ステップＳ１５５）。

【００７４】Ｆ［ｋ］が「連続イベント」である場合に
は、連続イベントブロック内における順番を示す変数ｍ
を「１」にセットし（ステップＳ１５６）、次いでチャ
ネルマップを参照してＳＭＦのステータスバイトを作成
して出力する（ステップＳ１５７）。なお、ｍ≧２の場
合のステータスバイトはｍが「１」の場合のステータス
バイトを利用する。そして、この「連続イベント」の場
合には、パラメータ符号γ［ｍ］を読み出し、圧縮処理
と同じ関数ｈ（）を使い、（１４）式に従ってＳＭＦの
パラメータｐ［ｍ］を作成し、出力する（ステップＳ１
５８）。ｐ［ｍ］＝ｈ（ｐ［ｍ−１］，ｐ［ｍ−２]，…，ｐ［ｍ−Ｕ］＋γ［ｍ］(ｍ＞Ｕ）ｐ［ｍ］＝γ［ｍ］ (ｍ≦Ｕ）ただし、Ｕは関数ｈ（）の変数の個数（１４）Ｆ［ｋ］が「ランニングステータス」である場合には、
変数ｍの値をチェックし（ステップＳ１５９）、ｍが
「０」より大きければｍを１つインクリメントし（ステ
ップＳ１６０）、「連続イベント」側のステップＳ１５
７に進む。他方、ｍが「０」であれば「通常イベント」
側のステップＳ１５４に進む。

【００７５】次に本発明の、ＳＭＦを時間軸上で２つ以
上のブロックに分割し、少なくとも最初のブロックは前
記１次圧縮及び／又は前記２次圧縮を行わないことを特
徴とする演奏情報圧縮装置について説明する。

【００７６】図２９に本発明による圧縮を行ったときの
第１の実施例を示す。従来の方法では、元の演奏情報は
そのまま１曲ごとに圧縮を行っているが、演奏情報を着
信メロディなどで使用する場合には、電話受信後、直ち
に着信メロディが再生されなければならず、圧縮された
ファイルを解凍するために端末側の処理速度を高速化す
る必要がある。そこで、図２９のように、演奏情報のフ
ァイルを時系列上にブロック１とブロック２の２つのブ
ロックに分割し、それぞれのブロック単位で圧縮を行
う。このとき、ブロック１はできるだけ端末側で即座に
データを解凍できるように１次符号化のみの圧縮を施
し、２次符号化は行わない。ブロック２は全体のメモリ
ー容量や配信ファイルサイズを小さくするために、通常
の１次符号化ならびに２次符号化による圧縮を行う。こ
のようにして、１次符号化のみ施された圧縮ブロック１
と１次符号化及び２次符号化が施された圧縮ブロック２
とを一つのファイルとして配信伝送し、端末側のメモリ
に記録させる。

【００７７】ブロック１は、例えば最初の５秒分など、
ある程度短めにしておき、電話に対して着信があったと
き、まず、圧縮されたブロック１から解凍し、ブロック
１に該当する部分の着信メロディを再生しながら、同時
に圧縮されたブロック２を解凍する。そのため、ブロッ
ク１はブロック２の解凍を行うための十分な時間があれ
ば、可能な限り短い方が良い。これは圧縮されたブロッ
ク１を解凍する作業時間を短縮する点においても重要で
ある。

【００７８】図３５に第１実施例のエンコードのフロー
を示す。まず、ＳＭＦを取りこみ（ステップ４０１）、
ステップ４０２にてＳＭＦを時間軸上で２分割し、最初
の５秒分をブロック１、残りの部分をブロック２とす
る。そして、ステップ４０３でブロック１を１次符号
化、これによりステップ４０４にてブロック１を圧縮し
た圧縮ブロック１を生成する。そして、ステップ４０５
にてブロック２を１次符号化及び２次符号化し、ステッ
プ４０６にて圧縮ブロック２を生成する。更に、圧縮ブ
ロック１及び圧縮ブロック２を一つにまとめて（ステッ
プ４０７）、エンコードを終了する。

【００７９】次に再生時の動作を図３１及び図３２を参
照しながら説明する。電話の着信が発生したとき、楽曲
取り込み手段１３４により、発信相手に対応する楽曲フ
ァイルを情報記憶手段１３５に取り込む。既に情報記憶
手段１３５に楽曲ファイルが収録されている場合には、
直接ここから解凍を行ってもよい。まず圧縮ブロック１
の解凍を始める。この際、圧縮ブロック１は１次符号化
のみ施されているので、図３１の１次符号復号手段１３
１によって復号を行い、直ちに演奏情報の再生を行う。
そして演奏情報の再生を行いながら、圧縮ブロック２の
解凍を始める。圧縮ブロック２は図３１の２次符号復号
手段１３２によって、２次復号化が行われ、次に１次符
号復号手段１３１によって１次復号化が行われる。ブロ
ック１のファイルサイズは、この２次復号化が終了し、
ブロック２の演奏情報が再生可能となるタイミングまで
に時間的な猶予が持てる程度の大きさが好ましい。ま
た、演奏情報はテンポをベースに記述されている場合が
あるので、再生テンポが端末側で最大（最も早い）とな
るように設定されている場合にも間に合うようにしなけ
ればならない。展開した楽曲情報は情報記憶手段１３５
に記録される。そして楽曲再生手段１３６により、情報
記憶手段１３５に展開された演奏情報が再生される。な
お、上述した実施例では発信相手に対応する楽曲ファイ
ルを選んでいるが、発信相手の全てに同じ着信メロディ
を使用し、電話の使用者の好みに応じて楽曲を切り替え
るようにしても良い。

【００８０】次に、本発明による圧縮を行ったときの第
２の実施例について図３０を参照して説明する。これ
は、第１の実施例よりも端末の処理が遅い場合に、全体
の圧縮率はやや下がるが、ブロック１の部分については
元のデータをそのまま用いるものである。図３６に第２
実施例のエンコードのフローを示す。なお、ブロック１
の１次符号化を行わない点を除いて上述した第１の実施
例と同じであるため説明を省略する。また、再生時の動
作についても図３１に示す第１の実施例と同様の端末構
成で、図３３に示すように圧縮ブロック１の解凍を行わ
ない点が異なるものであり説明は省略する。

【００８１】次に、本発明による圧縮を行ったときの第
３の実施例について図３４を参照して説明する。これ
は、ある程度端末側の処理速度の高速化が見込まれる場
合に、ブロック１にも１次符号化ならびに２次符号化を
施すものである。図３７に第３実施例のエンコードのフ
ローを示すがこれについてもブロック１に対して１次符
号化及び２次符号化を施す以外には上述した実施例と同
様であるため、説明を省略する。次に再生時のフローに
ついてであるも上述した実施例と同様であり、ブロック
１の部分のみがそれぞれの圧縮内容による違いが生ずる
のみであるので、説明は省略する。

【００８２】なお、上記は着信メロディについて説明を
行ったが、カラオケやＢＧＭであっても、再生指定時に
直ちに演奏を開始することができる点で、実用に耐えう
るものとなるので、これらのような使用形態に適用する
ことも可能である。

【００８３】

【発明の効果】以上説明したように本発明によれば、Ｌ
Ｚ法により圧縮する前に予め、同一のデータパターンの
長さが長く、出現回数が多く且つ近い距離で出現するよ
うに、演奏情報を音程と、強さと、長さとその他の情報
に分離し、各情報をそれぞれ独立した領域に配置した１
次符号を生成し、この１次符号をＬＺ法により圧縮する
ので、演奏情報のデータ量を効率的に圧縮することがで
きるが、このような装置に於いて、ＳＭＦを２つ以上の
ブロックに分割し、少なくとも最初のブロックは前記１
次圧縮及び/または前記２次圧縮を行わないことを特徴
とする装置を提供することで、圧縮した状態からの再生
をすぐに行える端末を提供する事ができる。

【００８４】また、１次符号として演奏情報を音符の音
程領域と、音符の強さ領域と、音符の長さ領域とその他
の領域の少なくとも４つの領域に分離して符号化するの
で、元の演奏情報のもつ演奏品位を全く失うことなく、
従来に比べ大幅にデータ容量が削減でき、したがって、
データを保存するのに小容量の記録媒体を用いることが
できコストを削減することができ、また、通信回線を介
してデータを伝送する場合にもコストを削減することが
できるとともに、伝送時間を削減することができる。ま
た、大量の演奏情報を扱う通信カラオケや着信メロディ
などの音楽データベースや端末のメモリ容量節約特に効
果が大きい。

【図面の簡単な説明】

【図１】本発明に係る演奏情報圧縮装置の一例を示すブ
ロック図である。

【図２】図１の１次符号生成手段の一例を詳細に示すブ
ロック図である。

【図３】図２のチャネル分離手段により作成されるチャ
ネルマップを示す説明図である。

【図４】図２の解析手段の処理を説明するためのフロー
チャートである。

【図５】図２の解析手段により作成されるノートテーブ
ルを示す説明図である。

【図６】図２の解析手段により作成されるコントローラ
テーブルを示す説明図である。

【図７】音符を表現するＳＭＦのΔタイムと本実施例の
デュレーションの関係を示す説明図である。

【図８】図２のノートΔ符号生成手段の処理を説明する
ためのフローチャートである。

【図９】図２のノートΔ符号生成手段により生成される
ノートΔ符号を示す説明図である。

【図１０】図２のデュレーション符号生成手段の処理を
説明するためのフローチャートである。

【図１１】図２のデュレーション符号生成手段により生
成されるデュレーション符号を示す説明図である。

【図１２】図２のノートナンバ符号生成手段により生成
されるノートナンバ符号を示す説明図である。

【図１３】図２のベロシティ符号生成手段により生成さ
れるベロシティ符号を示す説明図である。

【図１４】図２のコントローラ符号生成手段により生成
されるコントローラ符号を示す説明図である。

【図１５】ＳＭＦの連続イベントブロックを示す説明図
である。

【図１６】本実施例の連続イベントブロックを示す説明
図である。

【図１７】図１６の連続イベントブロックの効果を示す
説明図である。

【図１８】図２の符号配置手段により並べ替えられた１
次符号を示す説明図である。

【図１９】ＳＭＦのフォーマットを示す説明図である。

【図２０】演奏情報復号装置を示すブロック図である。

【図２１】図２０の２次符号復号手段の処理を説明する
ためのフローチャートである。

【図２２】図２０の１次符号復号手段の処理を説明する
ためのフローチャートである。

【図２３】図２２のトラック復号処理を詳しく説明する
ためのフローチャートである。

【図２４】図２３のノートイベント復号処理を詳しく説
明するためのフローチャートである。

【図２５】図２４のノートイベント復号処理により復元
されたノートオンイベントを示す説明図である。

【図２６】図２４のノートイベント復号処理により復元
されたノートオフキューを示す説明図である。

【図２７】図２３のコントローライベント復号処理を詳
しく説明するためのフローチャートである。

【図２８】図２７の処理により復元されたコントローラ
イベントを示す説明図である。

【図２９】本発明に係る演奏情報圧縮装置による圧縮方
法の第１の実施例を示す図である。

【図３０】本発明に係る演奏情報圧縮装置による圧縮方
法の第２の実施例を示す図である。

【図３１】本発明に係る演奏情報圧縮装置の構成を示す
図である。

【図３２】第１の実施例により圧縮された演奏情報の解
凍方法を示す図である。

【図３３】第２の実施例により圧縮された演奏情報の解
凍方法を示す図である。

【図３４】本発明に係る演奏情報圧縮装置による圧縮方
法の第３の実施例を示す図である。

【図３５】本発明に係る演奏情報圧縮装置による圧縮方
法の第１の実施例の動作を示す図である。

【図３６】本発明に係る演奏情報圧縮装置による圧縮方
法の第２の実施例の動作を示す図である。

【図３７】本発明に係る演奏情報圧縮装置による圧縮方
法の第３の実施例の動作を示す図である。

【符号の説明】

１入力データ２１次符号生成手段３１次符号４２次符号生成手段５２次符号１１チャネル分離手段１２解析手段１３ノートΔ符号生成手段１４コントローラΔ符号生成手段１５デュレーション符号生成手段１６ノートナンバ符号生成手段１７ベロシティ符号生成手段１８コントローラ符号生成手段１９符号配置手段２１入力データ２２スイッチ２３２次符号復号手段２４１次符号復号手段２５出力データ２６制御手段

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｈ０４Ｍ 1/00 Ｈ０４Ｍ 1/00 Ｂ

Claims

【特許請求の範囲】

【請求項１】演奏情報を少なくとも音程の情報と、音の
強さの情報と、音の長さの情報と、その他の情報とに分
離し、前記各情報をそれぞれ独立した領域に配置した１
次符号を生成する１次符号生成手段と、前記１次符号生成手段により生成された１次符号の各領
域の情報を圧縮する２次符号生成手段と、前記演奏情報を時間軸上で２つ以上のブロックに分割
し、少なくとも最初のブロックについては前記１次符号
生成手段による圧縮及び／又は前記２次符号生成手段に
よる圧縮を行わないことを特徴とする演奏情報圧縮装
置。
【請求項２】前記１次符号生成手段は、各イベント間の
相対時間の公約数、及び、各音符の長さの公約数を算出
し、各イベント間の相対時間、及び、各音符の長さの値
をそれぞれの公約数で除算した後符号化することを特徴
とする請求項１に記載の演奏情報圧縮装置。
【請求項３】前記１次符号生成手段は、各音符の音程情
報をそれ以前に出現した音符の音程の数値を使って一定
の関数式に従って算出した数値と実際の音程の数値との
残差で表すことを特徴とする請求項１又は２に記載の演
奏情報圧縮装置。
【請求項４】前記１次符号生成手段は、各音符の強さ情
報をそれ以前に出現した音符の強さの数値を使って一定
の関数式に従って算出した数値と実際の強さの数値との
残差で表すことを特徴とする請求項１乃至３のいずれか
一項に記載の演奏情報圧縮装置。
【請求項５】前記１次符号生成手段は、特定の種類のイ
ベントのパラメータ値をそれ以前に出現した同種類のイ
ベントのパラメータ値を使って一定の関数式に従って算
出した数値と実際のパラメータ値との残差で表すことを
特徴とする請求項１乃至４のいずれか一項に記載の演奏
情報圧縮装置。
【請求項６】前記１次符号生成手段は、前記各情報を当
該領域においてトラック順に配置したことを特徴とする
請求項１乃至５のいずれか一項に記載の演奏情報圧縮装
置。
【請求項７】前記１次符号生成手段は、前記各領域をデ
ータの性質が似ている領域同志が近くなるように配置し
たことを特徴とする請求項６に記載の演奏情報圧縮装
置。
【請求項８】演奏情報を少なくとも音程の情報と、音の
強さの情報と、音の長さの情報と、その他の情報とに分
離し、前記各情報をそれぞれ独立した領域に配置した１
次符号を復号する演奏情報復号装置であって、供給され
る前記１次符号を演奏情報に復号する１次符号復号手段
を有することを特徴とする演奏情報復号装置。
【請求項９】演奏情報を記憶可能で、且つ前記演奏情報
を電話着信時に再生する機能を有する電話端末装置にお
いて、前記演奏情報を時間軸上で二つ以上のブロックに分割
し、少なくとも最初のブロックが電話着信時に直ちに演
奏できるように二番目以降のブロックのみを圧縮して記
録することを特徴とする電話端末装置。
【請求項１０】演奏情報を記憶可能で、且つ前記演奏情
報を電話着信時に再生する機能を有する電話端末装置に
おいて、前記演奏情報を時間軸上で二つ以上のブロックに分割し
て、それぞれのブロックを圧縮するときに、少なくとも最初のブロックは、電話着信時に直ちに演奏
でき、且つ、圧縮された二番目のブロックの復号を行う
ことができる時間の長さ及び／又は二番目以降のブロッ
クの圧縮方法よりも短時間で復号可能な圧縮方法で圧縮
されていることを特徴とする電話端末装置。