音楽をつまらなくするコード進行をディープラーニングしてみたらやっぱりつまらなかった

音楽におけるコードはあんまり好きじゃない。

かっちりしたコード進行なんてものが音楽をつまらなくするのだ、あんなものを覚えてしまうと型にはまった音楽しか作れなくなってしまう。もっと自由な方がいいのだ。

と常々勝手に思っていたが、まあしかしなんだかんだ実作業の面では便利だったりするので、結局学ばざるをえなかったりもする。

自動音楽生成でもコードは使わないぞ、と頑張ってきたのだけど、やっぱりなんらかの進行のヒントになるかもしれないので、一応こちらも自動生成を試してみることにしました。

音楽のコード進行

コード進行にはある程度の法則がある。

一番教科書的なルールとしては、

C -> F -> Gのような

立ち上がり（トニック）、ちょっと盛り上がり（サブドミナント）、盛り上がり（ドミナント）、みたいな形が基本。

例外はあるにせよ、C F# Dm Abみたいな脈絡のない妙なコード進行がくることはあんまりない。

これはちょうど文章と同じような形で、主語があって文末がある、みたいなもの。

ということで、コード進行データは「文章と同じ時系列のデータ」と捉えてしまって問題ないでしょう。

となれば話は簡単、文章をディープラーニングさせる時と同じ手法が使えます。

コードのデジタル表現

では、コード進行のデータをプログラム上でどうあらわすか。
これはドレミファソラシドを12bitのまとまりに置き換えて、

Cメジャーならば

[1,0,0,0,1,0,0,1,0,0,0,0]

Cmならば

[1,0,0,1,0,0,0,1,0,0,0,0]

C7ならば

[1,0,0,0,1,0,0,1,0,0,1,0]

とすることにする。

この方式だとCー＞Fー＞Gのコード進行は以下の通りになる。

[1,0,0,0,1,0,0,1,0,0,0,0]　[1,0,0,0,0,1,0,0,0,1,0,0]　[0,0,1,0,0,0,0,1,0,0,0,1]

学習データ

学習データは邦楽洋楽とりまぜてコード譜10000曲ほどを用意した。

そのうちkeyがCと明記されているもの2000曲あまりを学習データとした。

ちょっと数が心許ないけど仕方ない。

というわけでモデルを組んで学習させてみる

Epoch 1/50
33/33 [==============================] - 1s 21ms/step - loss: 0.6694 - val_loss: 0.5621
Epoch 2/50
33/33 [==============================] - 0s 2ms/step - loss: 0.5366 - val_loss: 0.4543
Epoch 3/50
33/33 [==============================] - 0s 2ms/step - loss: 0.4366 - val_loss: 0.3682
Epoch 4/50
33/33 [==============================] - 0s 2ms/step - loss: 0.3468 - val_loss: 0.2882

.
.
Epoch 46/50
33/33 [==============================] - 0s 2ms/step - loss: 8.5190e-04 - val_loss: 8.1676e-04
Epoch 47/50
33/33 [==============================] - 0s 2ms/step - loss: 8.0641e-04 - val_loss: 7.7746e-04
Epoch 48/50
33/33 [==============================] - 0s 1ms/step - loss: 7.6571e-04 - val_loss: 7.4075e-04
Epoch 49/50
33/33 [==============================] - 0s 1ms/step - loss: 7.3260e-04 - val_loss: 7.0640e-04
Epoch 50/50
33/33 [==============================] - 0s 2ms/step - loss: 6.9866e-04 - val_loss: 6.7435e-04

コード進行生成

生成させるのは８小節。

最初の２小節をこちらから与えることにする。

まずは、C->F を与えたものと、C->Amを与えたもの

とすると出てきた進行（例）はこんな感じ。

C, F , G , C, F, G, C, F

C, Am,  F , G ,C ,F ,G ,C ,F

ありゃ、どちらも、C->F->Gに収束してしまった。 まあ基本だからしょうがないな。

というわけで、Cキーでありながら、Gから入るという進行G->Amを与えてみる。

 

G ,Am ,G ,C ,F ,G ,C

おお、こちらもGに戻ってまた、C->F->Gに収束してしまう。それだけ、C->F->Gの進行が強いんだな。

では次は２小節目から転調してやれ、ということで、C->Eを与えてみる。

C ,E ,G ,C ,F ,G ,C ,F

あららららら、こちらも、Gに戻りまたC->F->Gに収束してしまった。。。。。

結論

冒頭の方でコード進行の教科書的な進行ということでC->F->Gを例にあげたけど、これだけ、C->F->Gにばかり収束するということは、実際の曲中でも、C->F->Gは結局それだけ例があるということか。

本当は、RNNの予測に使う過去のデータ数を２（最初に与える小節）ではなくもっと増やせば少し変わってくるとは思うのだけど、文章と比較すると小節は生成する量が少ない（通常文章が数十単語の羅列を生成するのに対して、音楽は８小説とか、１６小節とかのみ）ため、そのアプローチにも限界がありそう。

それに、４・８小節でのまとまりがあるべきなのに、それを意識してないのも問題。

しかし、結論としてはやっぱりコード進行はC->F->Gの基本がめちゃ強くて、それ以外のバリエーションが大量にある（使用されている）というわけではないということですね。

こんな結論ですみませぬ。

AI作曲をコードと数式を使わず説明してみる、その3

再帰型ニューラルネットワーク(RNN)とその発展系(LSTM) 

前回出たのは、過去の時系列の並びから未来のことを予測するという再帰型ニューラルネットワーク。 

今回はその中でもLong Short-Term Memory(以後LSTM)を使うことにします。

LSTMは再帰型ニューラルネットワーク（以後RNN)の拡張、とでも言うべきもので、RNNもLSTMも過去の時系列の並びを手掛かりに未来の展開を予想すると言う意味では同じです。

RNNは直前のいくつかの音の並びしか手掛かりにできないのに対して、LSTMの方がずっと昔の音の並びを手掛かりにすることができます。

リフレインが音楽を作る

メロディは基本的に過去のフレーズを繰り返したり、展開したりすることで、構築されます。

まったく関連性のない音の並びがずっと続くということはありえません。

 たとえば、「世界に一つだけの花」であれば 「世界にひとつだけの花〜ひとりひとり同じ種を持つ、その花をさかせることだけに〜」と展開しますが、 冒頭の「世界に〜」と途中の「その花〜」は全く同じフレーズですよね。 

「世界に〜」を聞かせておいて「ひとりひとり〜」と違うフレーズを挟んでわすれたころにまた元に戻る。 

これが「メロディ」を強く人間に意識させるのです。

このような繰り返し、リフレインは至る所で使われます。

このように音楽製作者は意図的に繰り返しを多用します。

たとえば、音程を変えて、リズムだけリフレインしたり、コードをリフレインしたり、そもそもドラムパターンは基本リフレインですよね。

こういったリフレインこそが単なる音の並びを「音楽」にしているものと言えるでしょう。

リフレインを基本としたアプローチ

そこで「リフレイン」に強いアプローチとなると、前述LSTMのAIモデルを使用して、過去の音を学習して未来の音を予測させるという手法が意味をもってきます。

この時にどれくらい昔まで参考にするのか、1秒前なのか、5秒前なのか、どれくらいの重みでそれらを重要視するか、などを考えて設計していきます。

これらのパラメーターの設置次第で、様々な音を作ることができるわけです。

これが最もシンプルなAI音楽の姿と言えるでしょう。 

未来のAI音楽

ただ実際にはこれだけで、複雑な音楽を作れるわけではありません。  

音楽にはもっともっと様々なレイヤーが存在しています。  

調和した音程を作る「和音・コード」のレイヤー、AメロからBメロへ移り変わる「展開」のレイヤー、音色のレイヤー。 

今回は波形の話をしましたが、これをMIDIで行うアプローチもあります。  

今現在これらのレイヤーをすべて実用化のレベルで持っているというAIはほぼないでしょう。 

それはそれだけそれぞれの組み合わせが難しいと言うことでもあります。  

そうしてこういうアプローチを見ていくと、結局は人間の感覚、どうやって作品を生み出しているのか、聞く側はなぜこれを心地よいと感じるのか、を理解する必要があると言うところにぶつかります。 

 それだけ人間はいかに複雑なマシーンと言うことでもあるのですね。

AI音楽備忘録 どこまでが音楽か

 AI音楽備忘録

現状AIモデルにての11作品。
https://www.youtube.com/channel/UCX514JhcB-HsCYC4dBLMC1Q

実際には同じモデルでなく、ずっと改良を加えているので、まあ途中経過がそのまま備忘録的にアップロードされているという感じです。

当初は生成されたトラックサンプルをシーケンサ上で人力で選択し組み合わせていたのが、自動でミックス・フェードアウトまで作れるようになって、シーケンサを通さずに、コマンド一つで音楽が作成できるようにはなりました。

>


この例をみると、ドラムパターンはいい感じで繰り返されていますが、上物はどうも変化に乏しい。

現在のモデルは波形を直接学習しその続きを作っていくというもので、そしてその仮定でBPMや小節といったある程度の「音楽のルール」は正規化されています。

しかし、コードや、音楽の大枠での構造（４、８小節のまとまりなど）をいうものを理解しているわけじゃないので、はじめと終わりなどの展開、コードに沿った音の重ね合わせ、などができるようになるのが次の課題になるでしょう。

本当はリズムパターンだって１小節を繰り返してるだけじゃなく、４、８小節ごとにリフがあったり展開があるのが普通ですしね。

何をもって音楽と呼ぶのだろう？

しかし、作っていくうちに音楽の定義という物を考えないと何がゴールかさっぱりわからない、ということに気がついたのです。

「何を音楽とするか」のいわゆるAIでいうところのフレーム問題（使い方が違う気はするけど）的な物にぶつかってしまったわけである。

なにが音楽なんて曖昧な物で、とどのつまり、いってしまえばただ雑音を録音しただけでも、音楽と言えてしまうわけですしね。

たとえばこれはリズムパターンを延々と生成するタイプの曲。

個人的にこれは音楽だと思うが、そうじゃないという人もいるかもしれない。

シュレーディンガーの作曲家

このプログラムの目標は音楽が永遠とアップロードされていて、それが人の手によるかどうなのかわからなくなることです。

これは昔からずっと考えていたことで、クリエイターの究極の姿ってそういうことなんじゃないかと思っているのです。

自分が死んでもずっとアップロードされているので、周りからみたら生きてるか死んでるかわからない、みたいな形。

いわば、シュレーディンガーの作曲家？

おそらくそういうことはこれからたくさん出てくるでしょう。

ずっと新作ドラマに登場してくる俳優、永遠にニュースを読み続けるアナウンサー、ずっと新作を発表し続ける絵描き、、、ずっと作曲をし続ける作曲家。。。

しかし、まあそれは先の話なので、とりあえずここでは音楽を

「リズム」と「上物」とに分かれた繰り返しの拍子を持つ物

に定義して進めてみることにしましょう。

AI作曲をコードと数式を使わず説明してみる、その2

特徴量の抽出

代表的なものには以下のようなものがあり、それぞれ一長一短ありますが、

• 短時間フーリエ変換 (STFT)
• メル周波数ケプストラムMFCC
• ウェーブレット解析

とりあえずここでは一番基本の短時間フーリエ変換（以下STFT)を使用することにします。

といっても普段からおなじみの、音質を調整するイコライザのようなものだと思ってくれれば良いです。

この状態のデータのグラフは、横軸に時間、縦軸に音量をとっていますね。

このデータにSTFTをかけると。。。。

以下のようなグラフになります。

横軸時間、縦軸に周波数、さらに色の濃淡で、音の音量も表現することができます。

（イコライザ なんかはこのデータを元に各音域を調整するのですね）

このようにすると生のwaveデータの状態よりも音の構造がよりわかるようになります。

そして、この状態のデータをAIに「学習」させることにします。

時系列データを学習する

AIで学習するデータはざっくり大きく乱暴に分けると２種類あります。

• 時系列のデータ
• 時間によってデータ変わるもの、毎日の気温、文章（前から後ろへ書いていきますね）、映像、などなど。
• 時系列ではないデータ
• 文字認識、絵、などなど。

それぞれによって使用するアプローチが変わってきます。

音楽は当然時系列のデータです。

たとえば、ピアノに座って「ミ」の音を出しただけではただの音です

前に「ド」をつけて、「ド・ミ」と引くとその音はそれぞれ意味を持ってきます。

意味を持たないただの音だった「ミ」はドと並べることで「音程が上がったよ」「三度上がった調和する音程だよ」という意味をもつ音となり、それはメロディとなり、調性をも生み出します。ド・ミとつながったのだから多分ソがきてドミソの和音かな？、とその先の展開も想像できるわけです。

AIでも同じ考え方をします。

前のデータを学習すれば、その先の音はわかるのではないかな？という仮定に立ちます。

その考え方に立ったものがAI学習方法の一つ「再帰型ニューラルネットワーク」です。

これはそれより「過去に起きた情報」を保持し、次のステップに利用することができるというアルゴリズムです。

時間の共に変化する分野、特に、「言語解析」や「音声認識」の世界では主流となっています。

音楽も同じように「時間と共に変化する」性質をもつので、この考え方を利用することとします。

というわけで次は、実際の楽曲生成です。

AI作曲をコードと数式を使わず説明してみる、その1

Waveファイルで音楽をディープラーニングさせたい！！

今現在、AIによる作曲の手段としてはgoogleのmagentaというライブラリが有名です。

これを利用した作曲手順についてはこちらに記事を書いています。

作曲家兼プログラマー 早川大地がAIによる作曲について語る：「人工知能で作曲、ここまで来てた！！」

googleが作ってくれたんだからそりゃあ有能に違いない、とmagenta を使って色々遊んではみたのですが、なにぶん残念なことに作曲については基本Midiがベースとなっているのです。

（ボーカル合成とかあるにはあるんだけど）

Midiファイルの例：「どの位置で何の音が鳴るか」が記録されたファイル

こうなってくると、作曲家の補助的な用法としては使えるかもしれないけど、リスニングの分野の実現性としてはどうなんだろうかと思うところなのです。

ということで、やっぱりなんといっても普段聴き慣れているWavデータを使って、自動作曲したいと思うのですよね。

Wav ファイルの例：普段PC上で耳にする音楽はほぼこれですね。

そこで、magentaに頼らずに１からモデルを作ってみることにしました、その過程で考えたことを通して、AI作曲についてなるべくわかりやすくまとめてみたいと思います。

AI作曲についてはなにが正解ということもないので、こんな考え方があるのだなあと思って思えれば。

もちろんこのアプローチですぐにまともな「作曲」ができるとは思えないけれど、リズムを変異させたりあらたな環境音を作りだしたり、と新たな作曲のヒント程度は作ることができるかもしれない。

というわけで数回にわけて、Waveファイルを対象としてディープラーニング作曲・AI作曲にチャレンジしてみたいと思います。

できるだけ、技術畑の人だけでなく音楽畑の人にプロセスを理解してもらいやすいようにかければなと思っております。

音楽を分析する際のポイント

同じようにWaveファイルを分析するものとして、代表的なものに音声認識があります。

音声認識は母音や子音の特徴量を認識して、これが「Ah あ」だとかこれが「kah か」だとか、分類していく作業です。

ところが音楽の場合は単なる音声認識と違ってさらに考慮すべき構造がもっときっちりとあるのです。

• テンポの正規化
• 小節の構造
• 楽器の構造

構造があるということは手がかりがあるということです。

これらの構造を利用してコンピュータが学習することができれば！！

と期待できますよね。

まずは音の「特徴」について考えよう。

例えば誰かの歌声を覚えるとき、人は、無意識のうちにその特徴を覚えていると思います。

声色の雰囲気だったり、のどの使い方だったり、高さだったり、しゃくりあげや、語尾の発生の仕方だったり。

ちなみにものまねがうまいひとなんかはこれが上手なのですよね。

「特徴」となる部分を上手に掴み取ることができる、天性の学習能力がある、とも言えるでしょう。

それに類することをコンピュータ上でも行い、データを整理し学習しやすくする、というのがデープラーニングのプロセスの第一歩です。

これを「特徴量の検出」という言い方をします。

ただしそれを人間がやるのと違う点は、音楽を物凄い短い時間の単位に区切り（0.001 秒ごと、などなど）そしてそれを、物凄い数やるということでしょうか。

音とは何か

さて、いったん基本に立ち返って、音とは何か、という話。

まずは以下二つの波形を見てみましょう。

4cos10πの波形

3cos6πの波形

横軸に1（秒）をとり縦軸に大さ（振れ幅）をとったグラフです。

ずいぶん単純なグラフ（波形）ですね。

さて、この周波数と、振幅（振り幅）はいくつでしょうか。

そして、周波数=1秒ごとに揺れ動く（グラフと山と谷の数）とですので、最初のグラフは周波数が「5」です。(数えてみましょう、いち、にー、さん〜、し〜、ご〜・・）

そして、下のグラフの方も数えてみると周波数が「3」となりますね。

加えて振幅の大さがそれぞれ、4、３となっているのは見て取れますよね。（グラフの山のてっぺんをが縦軸のどこに来ているか、を見れば良いでしょう。）

そして、どちらの式もXcosYπという形で表されます。

上のグラフは、4cos10πで下のグラフは3cos6πですので、XとYに入る数字が変わっているだけですね。

ちなみにこの場合Xが振幅となり、Y の二分の一が周波数となりますので、グラフを見ずとも、式をみるだけで、振幅と周波数がわかります。

これは「コサイン波」と呼ばれる波形、これも立派な「音」になります。（シンセサイザにも入ってますので、ご存知の方も多いかと。）

この音は非常にシンプルな「プー」とか「ポー」とかいう素朴な音。

コサイン波同士を足し算して音を作る

そして、これら波形は足算・引き算、四則演算をすることができます。

たとえば、最初の二つの波形を足し合わせると、以下のような波形になります。

4cos10π＋3cos3π

足し方は簡単です。

上のグラフでは横軸（時間）が0.0の時に縦軸（振幅）は４となっていて、下のグラフでは横軸が0.0の時に縦軸は3となっています。

ですので、足算したグラフでは0.0のところに4+3=7が入ります。

この要領で順次足していけば良いのです。

とまあ二つの単純な波形を足算しただけですが、ずいぶんと複雑な形になりましたね。

実際にはこれ以上に無数の波形が足し合わせられることで、様々な複雑な音が生成されます。

鳥の声も人の声も、楽器の音も、もちろんシンセサイザも、すべて単純な波形の重ね合わせです。

となると、それぞれ重なり合った波形を分析していけば、必要な音の「特徴量」が掴めるのでは・・・・なんて気がしてくるのではないでしょうか。

この技術の延長に「イコライザ」のようなみなさんお馴染みのものがあり、まずは特徴量の学習はそこからのスタートということになります。

次回以降は特徴量の抽出方法について試行錯誤していく話となります。

絶対音感がある人は3%、音大生では30%、アプリによれば5%？

 

新潟大学の宮崎謙一教授らチームによる研究によれば、日本人で絶対音感がある人は全体の3%ほどなんだそうです。

それが音大生だとぐんと跳ね上がって30%ほどになるそう。

ちなみに宮崎教授らのチームのテスト方法はピアノの音を聞かせて90%以上当てられることを基準としているそうです。

というわけでその結果を踏まえて、「絶対音感トレーニング」

アプリの結果からそのデータを独自に計算してみました。                                               

このアプリはビギナーモードだと単音だけでのテストとなりますので、だいたい、850~900点以上、図の中の青い線より下のスコアが出た場合絶対音感がある、と考えて良いでしょう。

ビギナー意外のノーマル、ハード、スーパーハード、モードでは複数音当てなども含んでいるので、ちょっと比較しづらいので除外します。

こちらがその点数のグラフです。

縦軸が得点（1000点満点）、横軸がその人数です。

そして、実際に850点以上記録している人の割合を計算してみると、5.67% = 5%強となりました。

日本人全体の3%よりは多いですが、テストしてみようという時点で既に音楽への興味はある程度強いと考えられますから、5%というのは妥当な数字とも思えますね。

その他のデータはこちら

ハード

ノーマル

スーパーハード

かなり複雑な複数の音を当てるハード、スーパーハードとなると、逆に900点超えがたくさんいるのも面白いところです。

９００点を超えるには、４つの音が同時になっているのを即座に判別して、正確に答えられないといけませんが、スーパーハードに限っては半数近くが達成している模様。

できる人はとことんできるということなのでしょうか。

FlutterによるiOS/Androidアプリ開発が良い理由

最近使用頻度の高いAndroid/iOS 両対応フレームワーク Flutter

数本アプリ開発を通じて少し知見も貯まったと思うので、思うところを記載します。

結論から言うと

そのアプリに必要なライブラリがあることが予め確認（重要）できるのなら、導入ゴーで良いと思う。

フレームワーク自体の開発速度も早いし、バージョン管理ツールも出た。いまアツい。

個人的には今年ARライブラリのWikitudeが対応したことで、さらに幅が広がりそう。

箇条書きで理由を述べます

    

    Google開発・オープンソースなのでなんとなく安心感がある。

フレームワーク自体の開発ペースが早い。そのため複数バージョンを使用したりする機会も多い。以前は複数インストールして手動でパスを変えるという方法しかなかったが、バージョン管理ツールfvmが出てからだいぶ楽になった。

    ネイティブコードで動作する。

アプリの動作・UIの部分だけ両対応することに集中した設計。細かい設定はXcodeやAndroidManifestを直接いじることになるが、正直その方が楽。両OSのバージョンアップや仕様変更にも対応しやすい。したがってバグも少ない。（Titaniumなどはbuild時にXcodeのプロジェクト自体を作り直していたので、いろいろ大変だった。。。）

    ホットリロード機能がすごい。

動作中に少しコードを変更し、Rキーを押すだけで、リロードされる。再コンパイルが必要なしで、HTMLのような感覚でデザインを作れる。開発速度がとてもあがる。

    アプリをDartで開発できる。

Javascriptのゆるさとオブジェクト志向言語のかっちり感を程よく組み込んだ良い言語だと思う。個人的には　” ) ” が多くなりすぎるので視認性はどうかな、とは思う。一部わかりづらい書き方があるがそれは慣れ。

嫌なコードの例

            Container(
              padding: EdgeInsets.only(left:100,right:100),
              child:rows,
              alignment: Alignment(0,0), 
            )
          ]), //この辺の括弧が多い。。。
        ),
      ] 
    );

    ライブラリ充実度がかなり上がってきた

2019年初頭くらいには、videoのプレイヤーやXMLのパースなどライブラリによってはまだまだ足りないところがあった印象だけど、ここにきて通常の使用には困らなくなった印象。このあたりは今後dartがどれくらい伸びるかにかかっている。。。