2020年9月2日，初のオンライン開催となる「CEDEC 2020」が開幕した。
　ここでは，CRI・ミドルウェアの増野宏之氏による「フーリエ変換は2のべき乗が速いといったな、あれは嘘だ。 -Constant-Q変換を用いた楽譜情報の抽出とゲームへの応用法について-」についてのレポートを行いたい。

　講演タイトルは非常に挑戦的なものとなっている。フーリエ変換（正確にはフーリエ級数解析か）どういうものかというのはご存じの方も多いとは思うが，これが分かっていないと何も理解できないため念のために簡単に説明しておこう。それは，あらゆる周期波形はたくさんのSinとCosの波の和で表現することができるというジョセフ・フーリエさんの仮説に基づくものだ。のちに証明されさまざまな分野で応用されている。どんな音でも，どの周波数のSin波がどれくらい入っているかが詳細に解析されるので，とくに音声処理には必須のものとなっている。

　なおフーリエ変換は音声に使われることが多いが，似たような考え方は2次元（3次元？）的にも応用でき，2次元画像では離散コサイン変換（DCT）が同様な考え方に基づいて画像圧縮で多用されている。JPEGなどがそれだ。さらに極座標を使って立体的に展開したようなものが，球面調和関数としてグローバルイルミネーションなどで活用されている。周波数成分を使うことで，データ量を大幅に削減してもだいたいの傾向は示せるようになったのだ。

　とはいっても周期波形なんて現実にはそんなにないよとかいう人のために，どんな波でも周期波形の1周期分だと仮定して処理するとか，SinとCosとか面倒だよという人のためにSinだけで扱えるようにするとか，計算面倒だよという人のために，サンプル数が2のべき乗個の場合だけ高速で演算できるアルゴリズム（FFT）が開発されるとかで，音声信号（単なる音圧の時系列データ）を周波数成分で表し，それをFFTで処理するというのは定番となっている。

　そのFFTを使わない音声処理とはどのようなものかを説明する前に，増野氏がどのようなことをやっている人かというのを紹介しておこう。
　氏は，楽曲の音声データを入力すると，自動的にリズムゲームを作ってくれるようなシステムを構築している。
　こういうことを実現するには，音声の主要部分（ボーカル部分）の識別やリズム・音程の判定など多くの難問をクリアしなければならない。そのために必要なさまざまな処理についてこれまでもCEDECで講演してきており，今回もそういったシステムの改良のためのアプローチを示したものだ。
　昨年までの発表で，楽曲の音声データからボーカル部分を抜き出して楽譜化するような処理は実現されていたのだが，実は昨年の発表時点ですでにいくつかの欠陥が判明していたのだという。下のスライドがその例だ。


　コーラスやエコーの処理はあるあるである。和音などがうまく処理できず，デュエットなどに弱いという。一方で音の数が少ない弾き語りなどでも干渉が発生してうまく楽譜が取れないことがあるという。

　フィルター条件というのは，たとえば4分音符未満の長さで急に1オクターブも飛んだら「そいつはノイズだ」ということで，フィルタリングしていたのだが，そうはいかない楽曲もあるのだという。ヨーデルである。それを楽譜化したいという需要がどれくらいあるのかは知らないが，非常に速い周期で裏声と表声（？）を入れ替えつつ歌唱するヨーデルでは，前提条件がそもそも違っていたのだ。

　また，操作自体も簡単ではなく，20以上のパラメータが用意されているものの，それぞれの効きが分かりにくく，うまく設定しても60％程度の正解率でしか採譜できないのだが，その設定を詰めるのだけで半日かかるといった状態だそうだ。これなら耳コピのほうが早いと考える人が出るのも頷ける。耳コピできない人でも，ヘッドホンで聞きながらハミングしたものを処理するなどのほうが実用的かもしれない。
　とはいえ，全自動でリアルタイムに採譜できるソリューションというのはロマンであろう。

　そこで増野氏は音程認識部分について根本的に見直し，FFTは音程認識には使えないと結論付けていた。その理由は，低音部の解像度が4Hzと高く，必要な窓幅が16Kにも達するからだ。処理は重く，遅延も0.37秒とリアルタイム処理には使いにくいものだった。


　八方ふさがりになった氏は，一度離散フーリエ変換に立ち戻り再検討をしたという。

　44kHzのデータ1024サンプルをフーリエ変換すると，中央周波数帯で0Hz〜22kHzまでの512個の区域（周波数ビン）での利得と位相が取得できる。
　ただ，実際の歌というのはだいたい2オクターブくらいで収まるとの話だったので，かなり無駄がある。解析に必要な4kHzまでの音程を求めるために必要な周波数ビンは100個程度（MIDIのノート番号の上下を少し省いた）なので，実数部と虚数部で合計1024個のデータがまとめて出力されるFFTでは実は効率が悪くなっているのだという。


　そこで，必要な周波数ビンごとに必要な窓幅を計算して，それぞれで利得を計算すればよいのではないかと考えたそうだ。それがすなわちConstant-Q変換なのだという。高速アルゴリズムは使えなくても，FFTで512個の周波数帯を計算するより，個別の窓で必要な100個程度を計算するほうが効率は上がるかもしれない。実際には，A4（第4オクターブのA音）を442.0Hzと設定し，44.1kHzデータでC1からC8までの85個分をDFTで計算している。


　FFTを使わないと計算負荷がかなり高くなりそうに思われる。実際，初期の実装ではCPU使用率が90％以上にもなっていたという。これは毎回窓関数を計算していたことが原因で，初期化の際に窓関数を事前計算しておけば格段に軽くすることができる。ただしメモリは1.4MB程度余分に食うことになる。そのほかの調整を繰り返した結果，CPU負荷2％程度に抑えることができたそうだ。
　処理するデータ量がビンごとに異なるので，それぞれのビンで処理遅延が異なるという問題もあったのだが，どのビンにも同じデータ量を与えて調整しているという。余分のデータを与える意味があるのかと少し思ってしまうのだが，これは高周波部分の精度を上げることとも関連している。
　高周波部分ではサンプル数が少なく，隣接するビンと区別がつかないケースも出てくるのだが，増野氏はここで窓枠を浮動小数点数で設定することにより精度を上げていた。

　出力されたスペクトラムを見て奇妙だったのが，該当の音の1オクターブ下に偽信号が出ていることだ。音声的には，楽器などの特性で倍音が出ることはあっても，半分の周波数の音が出るというのはありえないのだが，これは1倍成分だけを解析すると利得が少なくて誤差に埋もれるので，全空間の利得を取得しているためだという。結果としてピーク部分はきっちり立っているのだが，オクターブ下の偽信号が残ってしまっている結果だ。


　和音判定では，音域をルート音を判定する低域，コードの中域，メロディ中心の高域に分けて処理を行うのだという。それぞれのビンは独立して処理されるので，音域ごとにフィルタリングしたデータを与えても問題はないという。1オクターブ内の12個の半音に対して，オクターブを無視して利得をまとめる。これはクロマベクトルと呼ばれていた。低域と中域でそれを生成し，これを基に和音処理を行っていた。そのピークの出方から，一定の法則でコード記号を割り出すのだが，その判定を増野氏は3つの表にまとめていた。


　このように，以前の方式では難しかった和音処理も可能になり，昨年発表したシステムの欠点を補うシステムが同程度の負荷で可能になっている。増野氏は今後も開発を続け，さまざまな音ゲーなどでの活用を目指すという。今後の発展に期待したい。