はじめに
1年弱前に 、 私はHOLOと呼ばれる私が開発中のプログラムについてHabréに関する記事を書きました。
つまり、プログラムは音楽コレクションを「リッスン」し、収集されたデータの配列を視覚的に調べたり、特定のサンプル曲に似たプレイリストをコンパイルしたりすることができます。
肯定的なレビューにより、熱意を維持することができました。 .NET WinFormsからWPFにアプリケーションを書き直そうとした人もいましたが、中間の成功の後、突然姿を消しました。 プロジェクトの内容は非常に難しく、主な仕事のプログラマーであるため、HOLOに十分な時間を割くことは困難だったため、彼を責めません。
それにもかかわらず、私自身は新しいバージョンのリリースを遅らせましたが、これには平凡な怠inessよりも前向きな理由があります。
特徴
一般的に言えば、音知覚の心理学の観点から、タスクは非常に主観的です。 Zhanna AguzarovaとZemfira、Led ZeppelinとIron Maiden、System of a DownとMetallicaが似ているかどうかは、各人が独自の方法で評価します。 しかし、私と私の友人に対する徹底的なテストは、いくつかのことはまだ数字で表現できることを示しました。 音楽のジャンルによっては、より良いものもあれば、悪いものもあります。
そのため、現時点では、 HOLO（音楽融合システム）は次のことを実行できます。
ユーザーのコンピューターで音楽に関する情報を収集する
前のバージョンと比較して、ファイルの機械的処理と音声の統計処理の両方のアルゴリズムが大幅に改訂されました。 特に、複数のストリームのファイルを並行して処理することが可能になりました。
統計処理は、要するに次のようになります。
1）パラメーター化可能な長さのフラグメントがファイルから抽出され、全体の長さの20％から始まります。
2）フラグメントは、パラメーター化可能な割合のオーバーラップでパラメーター化可能な数の断片にカットされます。
3）ピースはFFT形式に変換され、平滑化およびクリーン化されます。
4）事前に準備された「重心」の特定のセットを使用して、これらの各重心までの各ピースの距離が推定されます。 重心は、特別に選択された4096/44100秒の長さの音の断片のスペクトログラムです。
5）重心までの距離の時間的ダイナミクスは、重心間の合成音の断片の遷移行列に最小化されます。 たとえば、音が長時間（最も近い重心までの距離内）変化しない場合、遷移行列の対角セルでは値が大きくなります。
6）遷移行列は、統計処理の結果です。
結果をデータベースに収集する
変更はありませんでした。 前と同じように、SQLiteは国の利益のために働いています。
提供された任意の数のサンプルレコードに基づいてプレイリストを作成する
ここでも、ほとんど変更は発生していません。 左上のリストは、データベースの内容です。 左下のリスト-検索パターン。 右側のリストは、結果のプレイリストです。 [保存して開く...]ボタンをクリックすると、.m3u8ファイルが作成され、M3Uプレイリストを認識するプログラムが開きます。
個々のトラックの統計の視覚化
これは、遷移行列を視覚化できるプログラムの新しい機能です（上記の統計処理のアルゴリズムを参照）。
視覚化されたマトリックス自体はユーザーにとってメリットがなく、主にプログラムの装飾的な要素です。
ただし、特定の構成が異なる重心の近くでどのようにグループ化されるかを観察することはしばしば可能です。
完全なデータベース視覚化
しかし、これはおそらく最も複雑で最近の機能です。
レンダリングする最初の方法は、 古典的な散布図です。 問題は、データベースに構築するデータが多すぎることです。7つの重心では、遷移行列にはそれぞれ49個の要素が含まれ、各処理済みファイルの49座標を処理しています。 さらに、多くの場合、これらの座標の半分までがゼロに等しく、これも明確さを増しません。 主要なコンポーネントの分析により、5-7次元の有用な情報の大部分を折りたたむことができます。これは、平面上の2つの座標と3つのRGB色座標を使用して視覚化できます。 その結果、データベースの散布図は多色の雲になりますが、非常に柔軟にパラメーター化でき、シフトおよびスケーリングも可能です。
視覚化の2番目の方法は、 平行座標上のグラフです。 この実施形態では、多数の座標が対応する数の平行軸として表され、各構成は各軸上の点を通るポリラインとして表される。 わかりやすくするために、破線はスプラインに置き換えられているため、グラフは編み組みのように見えます。 もちろん、主要なコンポーネントを分析することによるデータ圧縮も組みひもに役立ちます。
そして試してみる？
Windows XP以降を使用している場合は、.NET Framework 4.0がインストールされており、MP3ファイルを読み取るためのACMコーデックがインストールされています（その存在を確認する方法を尋ねないでください、私は知りません）。 ここにある配布キットを試すことができます 。
ソースコードを勉強したい人は、通常のリポジトリが設定されるまで待つ必要があります。
メリット
Apple、Google、Pandora Radio、Last.fmの同様のソリューションを分析しました。 すべての場合において、検索はメタデータに基づいています。メタデータは、少なくともスポーツマンらしくなく、少なくとも主観的であり、生きている評価者の意見に左右されます。
対照的に、HOLOはこれまでのところ、「教師なし」システムである、公平な査読者および推薦者です。 「さようなら」という言葉を使用したのは、教師のトレーニングの補助的なサブシステムであるユーザーの好みに調整の類似性を導入する予定だからです。
そしてもちろん、大きなプラスは、プレイリストのアイテムを自由に使えることです。リモートサーバーからのストリーミングはなく、すべてがあなたのコントロール下にあります。
制限事項
残念ながら、それらなしではありません。
1）これまでのところ、Winプラットフォームのみ。
2）これまでのところ、MP3ファイルのみ44.1 kHz 16ビット。
3）基本サイズが1万トラックx 10重心（データベースに最大100万レコード）を超える場合、プレイリストの形成速度は30分を超え始め、まだ並列化されていません。
4）データベースの収集を再開することはできません。再開するだけです。
5）いくつかのフォルダーを指定したり、コレクションのフォルダーを除外したり、シンボリックリンクを使用したりすることはまだできません。
6）データベースのダイヤル速度が許容範囲内であれば、トラックは完全に「リスニング」されず、1〜3分の長さの断片のみがリストされます。 したがって、このフレームワークに該当しないものすべてが、プレイリストの分析と形成に影響を与えることはありません。 これは、プレイリストを聞いているときに「WTF？！」と叫ぶ最も一般的な理由の1つです。
7）しかし、残念なことに、これが唯一の理由ではありません。 ファイルに関するすべてのメタデータを破棄しても、検索品質はまだ理想的ではありません。ご理解ください。 ただし、約80％の場合、プレイリストは、テンポ、サウンド密度、音量、およびジャンル全体のサンプルのように見えるもので構成されます。
あとがき
現時点では、プログラムは100キロバイトを超えるコードに成長しています。 C＃でのプログラミングは私の職業ではないという事実により、場所の質は驚異的です。 有益なフィードバックと、以下の面で役立つボランティアに喜んでいます。
0）自宅でアプリケーションをテストする人に最適なフィードバック方法を提供します。
1）コードの
2）作業速度を最適化し、可能であれば、SQLiteがクエリを実行しないようにします。
3）UIのドーピング。
4）MP3以外のサポートされている形式のセットをFLAC、AAC、OGGに拡張します。
5）MP3ファイルのデコードを行うプラットフォーム依存ライブラリNAudioの回避。 これはおそらく、MonoでHOLOをコンパイルできない唯一の方法であり、したがって、サポートするすべてのプラットフォームで実行できます。
PMに書き込みます。
UPD：プロジェクトリポジトリはこちらです。