JPH08152881A

JPH08152881A - 演奏情報圧縮装置

Info

Publication number: JPH08152881A
Application number: JP6319337A
Authority: JP
Inventors: Ichiro Shishido; 一郎宍戸
Original assignee: Victor Company of Japan Ltd
Current assignee: Victor Company of Japan Ltd
Priority date: 1994-11-29
Filing date: 1994-11-29
Publication date: 1996-06-11
Anticipated expiration: 2015-12-25
Also published as: JP3120675B2

Abstract

(57)【要約】【目的】時間情報とイベント情報を有する演奏情報デ
ータの性質を利用して、データ量を大きく削減すること
のできる演奏情報圧縮装置を提供する。【構成】楽音を構成する音の発音時間情報と共に音の
音程その他を指定するイベントを含む演奏情報に応答
し、演奏情報のイベント間の相対時間を分析する時間分
析手段１２と、演奏情報に応答し、イベントの種類を分
析するイベント分析手段１４と、演奏情報に応答し、所
定時間間隔でデータを分割してセグメント化し、各々の
セグメントから同一内容のデータを検出する楽曲構造分
析手段１６と、時間分析手段とイベント分析手段と楽曲
構造分析手段のそれぞれの分析結果に基づいて演奏情報
を符号化する符号生成手段１８とを、有する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、演奏情報のデータ量を
削減する演奏情報圧縮装置に関する。

【０００２】

【従来の技術】一般に通信カラオケと言われるシステム
が登場している。これは従来の光ディスク等の記憶媒体
に記録された楽音、歌詩、画像等のデータをリクエスト
に応じて選択して再生するものに代えて、ステーション
（ホスト）と各端末を通信回線で結び、新譜を短時間で
端末に送る等の配信を可能としたものである。かかる通
信カラオケでは、ＭＩＤＩ信号のデータが用いられ、楽
音信号は楽音を構成する音の音程と発音時間等を指定す
る演奏情報として送信されている。従来、ＭＩＤＩデー
タの保存形式として、スタンダードＭＩＤＩファイ
ル（以下ＳＭＦとする）と呼ばれる形式が一般に用いら
れている。ＳＭＦの詳細は省略するが、個々の演奏情報
は、図２に示すように、デルタタイムとイベントという
２つの部分で構成される。デルタタイム（△ｔ）は、隣
り合ったイベント間の時間間隔を表している。イベント
は、音程や音の強さといった種々の演奏情報を含んでい
る。この形式は、記憶容量の効率的利用という点では、
必ずしも適当なものではない。この理由は大きく分けて
２つある。

【０００３】１つは、イベントデータとして、ＭＩＤＩ
メッセージをそのまま使っている点である。例えば、Ｍ
ＩＤＩメッセージの中に、ある特定の音を止める「ノー
トオフ」メッセージというものがある。これは、ノート
オフであることを示すステータスに１バイト、ノートナ
ンバ（音程）を表すのに１バイト、ベロシティ（鍵盤を
離す速さ）に１バイトの合計３バイトで構成される。し
かしノートオフのベロシティは実際には一定値であるこ
とがほとんどで、この場合１つのノートオフメッセージ
につき１バイト無駄な情報が保存されていることにな
る。

【０００４】もう１つは、１つの楽曲の中で同じパター
ンが繰り返しある場合でも、繰り返し情報を記述しない
で、同じデータを重複して記録している点である。通常
の楽曲であれば、同じパターンが繰り返される確率は非
常に高いので、重複するデータを省くことができれば、
記憶容量の有効利用を図ることができる。なお、音符、
記号よりなるメロディの楽譜データについて繰り返し部
分を効率よく処理する技術が特公昭６１−９１６９７号
公報に示されているが、これはＭＩＤＩ信号を前提とす
るものではなく、通信カラオケに応用することはできな
い。さらに特開平４−１４７１９２号公報には楽譜の繰
り返し部分をパターン化する技術が示されているが、十
分なデータの圧縮は期待できない。

【０００５】

【発明が解決しようとする課題】ＳＭＦには以上のよう
な問題点があるので、特にＭＩＤＩデータを大量に保存
する音楽データベースにおいて、記憶容量を削減できる
保存形式への要求が高かった。また、通信カラオケ等で
はデータ量の削減による通信時間及び通信コストの削減
が望まれていた。したがって、本発明は時間情報とイベ
ント情報を有する演奏情報データの性質を利用して、デ
ータ量を大きく削減することのできる演奏情報圧縮装置
を提供することを目的とする。

【０００６】

【課題を解決するための手段】上記目的を達成するため
に、本発明では演奏情報に含まれる時間情報及びイベン
ト情報の中から同一の情報の出現頻度を検出して符号化
するようにしている。すなわち、本発明によれば、楽音
を構成する音の発音時間情報と共に音の音程その他を指
定するイベントを含む演奏情報に応答し、前記演奏情報
のイベント間の相対時間を分析する時間分析手段と、前
記演奏情報に応答し、イベントの種類を分析するイベン
ト分析手段と、前記演奏情報に応答し、所定時間間隔で
データを分割してセグメント化し、各々のセグメントか
ら同一内容のデータを検出する楽曲構造分析手段と、前
記時間分析手段と前記イベント分析手段と前記楽曲構造
分析手段のそれぞれの分析結果に基づいて前記演奏情報
を符号化する符号生成手段とを、有する演奏情報圧縮装
置が提供される。

【０００７】

【実施例】以下、図面と共に本発明の演奏情報圧縮装置
の好ましい実施例について説明する。図１はかかる実施
例のブロック図であり、この演奏情報圧縮装置はトラッ
ク分離手段１０と時間分析手段１２とイベント分析手段
１４と楽曲構造分析手段１６と符号生成手段１８で構成
される。これらの手段は全体を１つ又は複数のＣＰＵ
（中央演算処理装置）で構成することができる。入力デ
ータはＳＭＦであり、前述したように個々の演奏情報
は、デルタタイムとイベントの２つの部分で構成されて
いる。一般に入力データには複数のＭＩＤＩチャンネル
の演奏情報が含まれている。まずトラック分離手段１０
において、１トラックに１つのＭＩＤＩチャンネルの演
奏情報のみ含まれるように、入力データを分離する。入
力データがＳＭＦのフォーマット１のようにあらかじめ
この条件を満たしている場合は、この処理を省略するこ
とができる。

【０００８】時間分析手段１２はデルタタイムを分析す
るもので、ここでは入力データに含まれるデルタタイム
の種類とその使用頻度を分析する。デルタタイムは、隣
り合ったＭＩＤＩイベントの間隔をある時間単位で表し
たものである。現在市販されているＭＩＤＩデータ作成
ソフトにおいては、４部音符の４８０分の１を基本単位
（１ｔｉｃｋ）とするものが多いので、以下では４部音
符の４８０分の１を単位とした場合を例にして説明す
る。

【０００９】図３は、音符の例を示すもので、このよう
な音符の並びをＳＭＦで表した場合、デルタタイム及び
デルタタイムの記述に必要なバイト数は表１のようにな
る。時間分析手段１２においては、トラック内のデルタ
タイムの使用頻度（あるいは、全トラックを通してのデ
ルタタイムの使用頻度）を調べ、表２に示すように、使
用頻度の高い順に表２のようなインデックスをつけたデ
ルタタイム頻度表を作り、これを符号生成手段１８に出
力する。これは非常に単純な例であるが、通常の楽曲に
おいても使用頻度の高いデルタタイムの数は限られたも
のになる。使用頻度の高いデルタタイムを短い符号に変
換すれば、データ量が削減できる。

【００１０】

【表１】

【００１１】

【表２】

【００１２】ＳＭＦにおいてデルタタイムは可変長符号
で表され、値が小さいほど必要なバイト数は少なくて済
む。デルタタイムの基本単位が細かいほど音楽的な表現
力は高いと言えるが、それに従って必要なバイト数も増
える。一方実際に楽曲に使われているデルタタイムを調
べると、基本単位の１刻み（１ｔｉｃｋ）まで使ってい
ない場合がある。この例では、１２０ｔｉｃｋが実際に
使用されている最小単位である。そこでデルタタイムの
最大公約数を求め、符号生成手段１８において、個々の
デルタタイムをこの最大公約数で除算して符号化する。

【００１３】次にイベント分析手段１４について説明す
る。イベント分析の処理としては、全てのイベントにつ
いて使用頻度を算出する場合と、特に使用頻度の高い
「ノートオン」（ある音を出す）、「ノートオフ」（あ
る音を止める）イベントに絞って使用頻度を算出する場
合の２つがあるが、以下ではノートオンとノートオフに
絞った場合を中心に説明する。

【００１４】ＳＭＦにおいては図４に示すように、ノー
トオンイベントを３バイト、ノートオフイベントを３バ
イトで表している。各々のパラメータは、ノートナンバ
（音程）とベロシティ（強さ）の２バイトである。

【００１５】１曲の中で使われるノートナンバとベロシ
ティの組み合わせは、ある程度限られており、しかも同
じ組み合わせが繰り返して使われることが多い。したが
って、ノートナンバとベロシティの組み合わせの使用頻
度を調べ、多く使われるものを短い符号に変換すれば、
データ量が削減できる。

【００１６】イベント分析手段１４においては、図５に
示す手順でノートオン、ノートオフ各々について、ノー
トナンバとベロシティの組み合わせの使用頻度をトラッ
ク単位あるいは全トラックを通して算出し、使用頻度の
高い順にインデックスをつけたノートオン頻度表とノー
トオフ頻度表をトラック毎にあるいは、全トラックにつ
いて１つ作成し、符号生成手段１８に出力する。表３に
図３の音符を例とした場合のノートオン頻度表を示す。
ノートオフ頻度表も同様である。以上の実施例では、ノ
ートオンとノートオフのみを対象として、各々の使用頻
度を算出したが、全ての種類のイベントを対象にした使
用頻度を算出する場合は、ノートオン頻度表、ノートオ
フ頻度表の代わりに表４のようなイベント頻度表を作れ
ばよい。

【００１７】

【表３】

【００１８】

【表４】

【００１９】ところで、音程を連続的に変えるイベント
であるピッチベンドなどは、ＳＭＦにおいてパラメータ
が少しずつ変わりながら連続して使われていることが多
い。このような部分を以下では、連続イベント部分と呼
ぶが、連続イベント部分を検出し、その最初と最後の位
置を記録して、符号生成手段１８に出力する。この情報
の利用については後述する。

【００２０】次に楽曲構造分析手段１６について説明す
る。まず演奏情報を一定の時間間隔（例えば、１小節相
当）で分割する。分割された要素をここではセグメント
と呼ぶ。前述したように、通常の楽曲では、同じ内容の
セグメントが繰り返して使われている場合が多いので、
このようなセグメントの検出を行う。

【００２１】セグメントには、楽曲の先頭から順に０，
１，２…Ｎといった番号を付け、セグメントの先頭位置
及び長さの情報と共にセグメント表として記述する。先
頭位置は入力データの先頭からのオフセットバイトで表
し、長さはセグメントのバイト数で表す。ｉ番目のセグ
メントに対し、０〜ｉ−１番目のセグメントとの比較を
行い、同じ内容のセグメントがあれば、最も若い番号を
セグメント表に記録する。このような処理をｉ＝１〜Ｎ
として行った後、セグメント表を符号生成手段１８に出
力する。セグメント表の一例を表５に示す。

【００２２】

【表５】

【００２３】次に符号生成手段１８について説明する。
本装置で生成する符号は図６の（ａ）に示すように、ヘ
ッダ、デルタタイム、ノートオンマップ、ノートオフマ
ップ、データブロックの各部分で構成されている。デー
タブロックの要素は、図７に示すように、ｍビットのデ
ルタタイムフラグとｎビットのイベントフラグと可変長
のデータ部で構成される。

【００２４】符号生成手段１８では、トラック分離手段
１０の出力を順次走査し、デルタタイムとイベントを順
次読み込む。その際、楽曲構造分析手段１６で作成され
たセグメント表を参照して、現在読み込んでいるデータ
がどのセグメントに属しているか、またそのセグメント
と同じセグメントの有無についてチェックする。セグメ
ント表に同じ内容のセグメントがある場合は、イベント
フラグにセグメント参照を意味するコードをセットし、
データ部に参照するセグメント番号を出力する。そして
次のセグメントが始まるまでトラック分離手段１０から
出力を読み飛ばす。セグメント表に同じ内容のセグメン
トが無い場合は、イベントフラグにセグメント定義を意
味するコードをセットする。そのセグメントについて以
下の処理を行った後、セグメント定義終了を意味するコ
ードをイベントフラグにセットする。以上セグメント記
述をまとめると図１０のようになる。

【００２５】セグメントを定義する場合の処理は次のよ
うになる。デルタタイムの値が、前記デルタタイム頻度
表の先頭から２^m−１個の範囲にあれば、デルタタイム
フラグに、そのインデクッスを記述する。この場合、デ
ータ部にはデルタタイムのデータは出力しない。またこ
の範囲になければ、ｍビットを全て１にして、データ部
には時間分析手段１２で求めた最大公約数で除したデル
タタイムをＳＭＦと同様な可変長符号で記述する。

【００２６】イベントフラグはｎビットあるので、２ⁿ
種類のイベントが記述できるが、マップにないことを示
すのに１個、セグメントの記述用に３個必要なので、ノ
ートオン用にｐ個、ノートオフ用にｑ個、連続イベント
記述用にｒ個のコードを割り当てる（ただし、ｐ＋ｑ＋
ｒ＜２ⁿ−４）。イベントがノートオンである場合は、
ノートオン表を参照し、インデックスが０からｐ−１の
範囲で、ノートナンバとベロシティが一致すれば、その
インデックスをイベントフラグにセットする。この場合
は、データ部に出力しない。もしノートオン表のその範
囲になければ、ｎビットを全て１にして、データ部にＳ
ＭＦと同様のイベント情報を記述する。ノートオフにつ
いても同様である。

【００２７】イベント分析手段１４で検出した連続イベ
ント部分を読み込んだ場合、以下の処理を行う。イベン
トフラグには、連続イベント用に割り当てられたｒ個の
コードの中から、イベントの種類に対応したものを選
び、それを設定する。データ部は、図８の（ａ）で示し
たフォーマットとする。

【００２８】図９に示した連続イベントを例に取って、
具体的に説明する。連続イベント部分は、この例のよう
にほぼ同じ時間間隔でパラメータ値が少しずつ変化して
いることが多い。この例では、ピッチベンドイベントが
６個あり、イベントの時間間隔は全て５０、パラメータ
値は各々１０、１１、１２、１５、１８、２１となって
いるものとする。ＳＭＦで記述する場合は、各々のデル
タタイムに１バイト、イベントに３バイト必要として、
６×（１＋３）＝２４バイト必要である。この例を図８
の（ａ）に従って、実際に記述したものが図８の（ｂ）
である。８バイトで記述ができ、ＳＭＦに比べて大幅に
記憶容量が削減できる。

【００２９】ヘッダには、図６の（ｂ）に示すように、
トラックの長さ、デルタタイムの最大公約数が記述され
る。デルタタイムマップは図６の（ｃ）に示すように、
マップに含まれるデルタタイムの数と、時間分析手段１
２で作成したデルタタイム頻度表の中のインデックスが
０から（２^m−２）を超えない範囲のデルタタイムを順
番に並べたものである。

【００３０】ノートオンマップは図６の（ｄ）に示すよ
うに、マップに含まれるデータ数と、イベント分析手段
１４で作成したノートオン頻度表のインデックスが０か
らｐ−１までのノートナンバとベロシティを順番に並べ
たものである。ノートオフマップも同様であるが、ノー
トオンとは違いノートオフのベロシティは全て同じ値に
なっていることが多いので、ベロシティ情報を記述する
１バイトを追加する。ノートオフベロシティが全て同じ
値であれば図６の（ｅ）に示すように、その値（０〜１
２７）をこの場所に記述し、続いてノートオフ頻度表の
ノートナンバのみｑ個並べる。もし一定値でなければ、
図６の（ｆ）に示すように先頭の１バイトに１２８以上
の適当な値を書き込み、続いてノートナンバとベロシテ
ィの組をｑ個並べる。なお、この例では、デルタタイム
マップ、ノートオンマップ、ノートオフマップをトラッ
ク毎に作成したが、これらを全トラックに対して１つず
つ用意してもよい。

【００３１】以上本発明の演奏情報圧縮装置について説
明したが、図３の音符の並びが具体的にどのような符号
に変換され、どの程度圧縮されるかを示す。ノートオフ
ベロシティは全て６４で一定とする。ＳＭＦで記述する
場合、トラックの長さを表すのに４バイト、表１に示し
たようにデルタタイムに１６バイト、ノートオン６回、
ノートオフ６回各々３バイトずつとして３６バイト、合
計５６バイト必要である。

【００３２】一方ｍ＝３、ｎ＝５、ｐ＝３、ｑ＝２とし
た場合の本装置の出力はヘッダ５バイト、デルタタイム
マップ５バイト、ノートオンマップ７バイト、ノートオ
フマップ４バイト、データブロック１２バイトで合計３
３バイトとなり、データ圧縮される。この例はデータ数
が少なく、セグメントの重複が無い例であるが、一般の
楽曲ではセグメントの重複があるので更に効率的に圧縮
できる。

【００３３】ノートオン頻度表、ノートオフ頻度表の代
わりにイベント頻度表を使う場合は、出力は、図６の
（ｇ）に示すような構成となる。イベントマップは図６
の（ｈ）に示すように、イベントマップに含まれるデー
タの個数に続き、イベント頻度表のデータ長とデータの
組を２ⁿ−１個超えない範囲で並べる。また、データブ
ロックのイベント記述は、２ⁿ−１個のコードを使って
上記と同様に行なえば良い。

【００３４】なお、以上詳述したフォーマット並びに処
理手順は一例であり、その主旨を逸脱しない範囲におい
て種々の変更を加えることができる。

【００３５】

【発明の効果】以上説明したように本発明の演奏情報圧
縮装置は上記構成なので、原データの持つ情報を全く失
うことなく、大幅なデータ削減が可能であり、特にＭＩ
ＤＩデータを大量に保存する音楽データベースにおいて
は、記憶容量が少なくてすみコストが削減できる。また
ＭＩＤＩデータを通信回線で送る場合には、送信時間が
短縮でき、コストも削減することができる。

【図面の簡単な説明】

【図１】本発明の演奏情報圧縮装置の好ましい実施例の
ブロック図である。

【図２】ＳＦＭデータの説明図である。

【図３】演奏データの一例を示す図である。

【図４】ＳＭＦのノートオン、ノートオフの構成図であ
る。

【図５】イベント分析手段の動作を示すフローチャート
である。

【図６】本装置の出力する符号の構成を示す図である。

【図７】データブロックの要素の説明図である。

【図８】連続イベントを記述するフォーマットを示す図
である。

【図９】連続イベントの一例を示す図である。

【図１０】セグメントを記述するフォーマットを示す図
である。

【符号の説明】

１０トラック分離手段１２時間分析手段１４イベント分析手段１６楽曲構造分析手段１８符号生成手段

Claims

【特許請求の範囲】

【請求項１】楽音を構成する音の発音時間情報と共に
音の音程その他を指定するイベントを含む演奏情報に応
答し、前記演奏情報のイベント間の相対時間を分析する
時間分析手段と、前記演奏情報に応答し、イベントの種類を分析するイベ
ント分析手段と、前記演奏情報に応答し、所定時間間隔でデータを分割し
てセグメント化し、各々のセグメントから同一内容のデ
ータを検出する楽曲構造分析手段と、前記時間分析手段と前記イベント分析手段と前記楽曲構
造分析手段のそれぞれの分析結果に基づいて前記演奏情
報を符号化する符号生成手段とを、有する演奏情報圧縮装置。
【請求項２】前記時間分析手段がイベント間の相対時
間の出現頻度を算出する手段と、出現するイベント間の
相対時間の最大公約数を算出する手段とを有する請求項
１記載の演奏情報圧縮装置。
【請求項３】前記イベント分析手段が特定の種類のイ
ベントの出現の頻度を算出する手段を有する請求項１記
載の演奏情報圧縮装置。
【請求項４】前記イベント分析手段が全ての種類のイ
ベントの出現の頻度を算出する手段を有する請求項１記
載の演奏情報圧縮装置。
【請求項５】前記イベント分析手段が特定の種類のイ
ベントが所定数以上連続している部分を検出する手段を
有する請求項１記載の演奏情報圧縮装置。