dPLP: A Differentiable Version of Predominant Local Pulse Estimation
微分可能なPLP(Predominant Local Pulse)を用いて、音楽ビート解析モデルのend-to-endな学習を行う手法。
DNNベースのビート解析手法は、「フレームごとにビート確率を推定する」アプローチが主流です。ビート確率は、0（ビート無し位置）が1（ビート有り位置）よりも圧倒的に多いため、DNNでend-to-endな教師あり学習をやろうとするとラベル不均衡問題に苦しみがちです。
そのため、ビート確率を推定する際に、ビート位置の性質（等間隔性）をなるべく考慮して推定してあげたいところです。本研究はこの目的を実現する手法として、「微分可能なPLP(Predominant Local Pulse)アルゴリズム」を考案しました。
PLPとは、音響特徴量から抽出した何かしらのNovelty function（オンセット強度・ビート推定DNNが出力した推定ビート確率etc.）を解析し、周期的なピーク信号列に変換するアルゴリズムで、ビート推定に用いられる道具の一つです。PLPを計算するには、Novelty functionのTempogramを求め、各フレームにおけるTempogramの最大値（＝推定テンポ）を求めた上で、最適な周期パルス列を求めます。計算過程でargmax関数を使うため、PLPは微分不可な処理です。
であれば、argmaxをsoftmaxに置き換えれば、PLPを微分可能処理に変換できます。微分可能なPLPをビート推定DNNの出力に繋げれば、DNNに周期的なピークを出力するように促す、強い帰納バイアスを持つ学習を行うことができ、ビート推定モデルの学習効率を向上させることが期待できます。
実際の実験では、Novelty functionはDNNではなく、学習可能なパラメータを持つSpectral Fluxから計算しています。「異なるdPLPカーネルサイズ（３秒/５秒/10秒）で計算した周期ピーク列」を線型層で融合させたものをモデル出力としています。著者に聞いてみたところ、この設計には特に明確な意図や詳しい考察はなく、「なるべく情報量は豊富なほうがいいよね」程度の意図であるとのこと。どんな実装が実際有効なのか、まだ掘り下げる余地はありますね。
GTZAN上で行った簡単な実験で、dPLPがビート推定精度向上につながることが示されています。学習済みSpectral FluxとFuserの実際の出力からも、dPLPが出力の周期性を促す効果があることを確認できます。
From Discord to Harmony: Consonance-based Smoothing for Improved Audio Chord Estimation
アノテーター間の解釈不一致に頑健な、音楽コード推定タスクの新たな評価指標を考案し、それに基づくコード推定モデル用の損失関数を提案。
音楽コード推定手法の性能を評価するには、推定結果と正解の重複率（overlap rate）を測るのが一般的なやり方ですが、推定結果の正誤を２値的に評価（binary metric）するのは、コード進行のタスクとしては不適切な部分もあります。なので、共通の構成音の数に基づいてスコアを算出するなど、コード推定の正誤を評価するための非２値的な指標（non-binary metric）がいくつか提案されています。
本研究は、Mechanical Distance with Consonanceという指標を考案しました。これも正解と推定コードの構成音の違いを数値化する手法ですが、構成音の誤りを音程ではなく、不協和性で評価する指標になっています。1半音のような不協和的な音高に間違えた場合は大きなペナルティがかけられ、4半音や7半音のような協和的な音高に間違えた場合は比較的小さなペナルティがかけられます。
コード進行に関する解釈は人それぞれなので、音楽コード推定手法に関する研究ではアノテーター間の解釈不一致が問題になっています。一方、その不一致には一定の傾向があり、協和的な音高に解釈する（D5とDmaj、AminとAmin7）ケースが多い一方、不協和的な音高に解釈する（CmajとCmin）ことは稀であることは容易に推測できるでしょう。
本研究は、提案指標が「アノテーター間で不一致が起こりやすい」間違いをうまく吸収し、かつ「アノテーター間で不一致が起こりにくい」間違いに大きなペナルティをかけることができることを、実験的に示しました。アノテーター間の不一致に影響されにくい頑健な指標である、ということですね。
続いて、この結論に基づき、本研究は音楽コード推定モデルを鍛えるための新たな損失関数を提案しました。協和的なエラーに小さめの、不協和的なエラーに大きめのペナルティをかけるような損失関数です。この損失関数を用いることで、コード解析モデルの性能を「従来的な指標」でも「提案指標」でも向上させることができた、としています。