MIDIからの自動採譜 ー リズム木とトークンによるリズム解析 ー

酒井 正彦（情報システム学専攻）

数年前、音楽情報処理の研究を始めた。ヤマハ音楽振興会の研究助成に採択されたのがことの始まりとも言える。 音楽情報処理といえば、いわゆるAI花盛りだ。 それまで項書換え系という、プログラムの本質を議論するための数学的なちょっとお硬い理論と格闘していたことから考えると大転換に見えるかもしれないが、そうでもない。 いまからMIDIという電子的な演奏データからの自動採譜について説明していきたいと思う。

自動採譜

自動採譜は、コンサート等の録音データからMIDIデータへの変換と、さらにそれを電子楽譜に変換する２段階の変換（図１）からなっている。ここでは後者の処理を機械学習に頼らない方法で扱うのだが、そうした理由は、楽譜には決まりごとがたくさんあることによる。 実際、写真２の本には、676ページも使って楽譜の決まりごとが書かれている。 決まり事を理論化してプログラムに組み入れていくことは大変だけれど、段階的に決まり事を組み入れていくことで改良することが可能だ。 現状の機械学習の場合、たくさんの決まりごとを一気に学習するというのが困難なのだけれど、だからといってそれまでの精度を保ちつつ、少しづつ学ぶ事柄を追加して改良していくのも実はあまり得意ではないらしいのだ。

これに対して前者の変換の場合、MIDIデータは音の鳴りはじめのイベント（時刻、高さ、強さ）と鳴り終わりのイベント（時刻、高さ）という2種類のイベントの系列だ。前者の変換の出力であるMIDIデータには、このように単純な約束しかないため、機械学習向きとも言える。実際、フーリエ変換などによる音響信号解析で得たデータを、機械学習を利用した手法でMIDIに変換するやり方はかなりうまくいっているらしい。

MIDIからの自動採譜

MIDIからの自動採譜における課題は、テンポ推定、調推定、リズム量子化、声部分離、記譜など山ほどあるのだが、今我々が取り組んでいるのは主に「リズム量子化」。先程も出てきたけれど、入力のMIDIデータでは音の鳴り始め（ノートON）や鳴り終わり（ノートOFF）の時刻は楽譜とは微妙にズレていて楽譜で表せない。そこで、それらの時刻を楽譜が表現できる時刻に修正するのがリズム量子化だ。図3(a)の楽譜を大学院生の天春さんにMIDIキーボードで演奏してもらい、そのMIDIデータをピアノロールで示したのが図3(b)だ。ここでピアノロールとは、縦軸が音の高さで横軸が時間として、キーが押されていることをバーで表したものだ。このデータをMIDIプレーヤーで音を鳴らしてみると実に自然に聞こえるのだが、そのピアノロールを見てみると極端に短い音があってびっくりする。それが理由ではないだろうが、これまでの方法はどれもノートONイベントのみを使ってリズム量子化を行っているようだ。この方法が良い一つの点は、ノートONイベントと楽譜中の音符（おたまじゃくし）とが一対一対応することにある。その一方、ノートOFF情報を使わないため休符や装飾音符の扱いが難しいとか、いろいろな問題点もあるのだ。

トークンの導入

ノートOFF情報も用いる場合には、楽譜の音符の時刻に複数のMIDIのイベント（トークン）を対応させることになる。このことは「ひらがな」の分かち書きと似ている。例えば、つぎの文章の解析を考えてみよう。
　　ここではきものをぬいでください
この文章は次に示すような2通りの分かち書きが存在する。ここで、縦棒を区切りに使っている。また、助詞とか細かい話は考えないことにする。

1. ここで|はきものを|ぬいで|ください　（ここで履物を脱いで下さい）
2. ここでは|きものを|ぬいで|ください　（ここでは着物を脱いで下さい）

自然言語解析の場合には、これら2つの分かち書きのうち、前後の文脈に応じて適切な方を選択することになる。MIDIイベントと対応させて考えると、一つの「ひらがな」文字が一つのMIDIイベント（ノートONあるいはノートOFF）に対応し、分割された「ここで」などのひらがな文字の系列がトークンに対応する。

図4の具体例を見てみよう。(b)は(a)の楽譜を演奏して得られた10個のMIDIイベントを表している。この図の記法はピアノロールとほとんど同じだが、MIDIイベントを強調して、ノートONを黒丸でノートOFFを白抜きの丸で表している。(c)は(a)からノートONだけを残したもので、ここから楽譜を起こすと多くの場合は(d)のようになってしまうだろう。

図５の(a)から(h)は異なる分かち書きを表している。これらの図において青い四角が1つのトークンを表しており、1つのトークンに含まれるMIDIイベントは後の処理において同一の時刻に移動されることになる。例えば(a)では4つのトークンに分けられていてそれぞれのトークンを適切な時刻に移動させることによって意図した楽譜(a)’を得ることができる。ここで、3つ目のトークンにおいてはミの音がノートONと同時にノートOFFされている。実は面白いことに装飾音符というのは、理論的には鳴っている長さがない音であると定義されている。

リズム木とリズム解析

図5(a)から(h)で示したような分かち書きのうち、どれを採用するのか、また、先程「1つのトークンに含まれるMIDIイベントは後の処理において同一の時刻に移動される」と書いたのだが、それはどのように決めるのだろうか。ここからはこの話題に移ろう。

図４(b)のリズム木は図6のようになる。一番上のdiv2は該当の小節全体（つまり４拍）を表していて、下に２本枝分かれすることでその４拍を半分に分けている。このようにして、一番下に並んでいるc_0,2, pc, c_1,2, rの４つはそれぞれ１拍の長さに決まるわけだ。ここでc_0,2, pc, c_1,2, rは（あまり気にする必要はないが）、それぞれ順に、2音のコード(Note)、部分的な継続（Partial Continuation）、と装飾音符(Grace Note)付きのコード、休符(Rest)を表している。

この木を図5(a)の最初の３つのトークンに対応させることで、それぞれのトークンに含まれるMIDIイベントがしかるべき時刻に移動する。このときの移動距離の総和が演奏の誤差と考えることができる。もちろん３つのトークンに対応するリズム木は他にもあるわけだが、それらの内で誤差の少ないものが良さそうに思える。それはある意味正しいのだけれど、それを徹底すると非常に細かい音符、例えば32分音符などが出てくるような不自然なリズムが得られてしまい、このときのリズム木は複雑なものになる。結局、誤差とリズム木の複雑さの両方を考えたうえで、最も良さそうなリズム木を探すことになる。さらに、いくつもの分かち書きが可能なので、これらのすべての組み合わせの中から最適なリズム木を発見するという作業を行うことになるが、動的探索と呼ばれるアルゴリズムを利用することで割と効率的に行うことができる。

図7の楽譜は図３（b）の演奏MIDIから、現時点で開発途中のシステムを使って量子化して得られた情報を楽譜化したものだ。今ひとつという感はあるが、原因はわかっているので今後対処する。この演奏だけ直っても仕方ないけれど。

ちなみにMuseScore(ver.4)で同じことを行うと図８の楽譜のようになった。このソフトはすぐれものなのにもかかわらず、小節がずれてしまった。与えたMIDIファイルの情報におかしなところがあるのかと思って、時間をかけていろいろと頑張ってみたのだけれど、結局解決できなかった。まあ、演奏の楽譜化は難しいということにしておこう。（おい、それでいいのか。。。）

おわりに

MIDIからリズムを取り出す方法についてざっくりと説明してみたのだけれど、その背後には割ときれいな論理の世界が広がっているように見えないだろうか？　大げさな気もするけれど。