Premier tour de piste dans le corpus Suno. C’est intéressant.
Je trouve des occurrences statistiquement significatives de motifs musicaux improbables : des progressions d’accords communes, des notes déplacées et des tendances mélodiques qui n’apparaissent NULLE PART dans la musique « réelle ».
Ça brise les règles.
Certains de ces motifs sont impossibles à reproduire avec de vrais instruments. C’est trop tôt pour tirer des conclusions (je n’ai traité qu’environ 25 % du matériel, soit grosso modo 160 000 clips, et la méthodologie n’est pas encore totalement finalisée), mais ça semble prometteur pour obtenir de nouvelles perspectives.
J’en suis à peu près à 9 heures de travail. Le GPU a planté avec la pile d’accélération surdimensionnée que j’ai pondue ce week-end. Pas totalement testée ! Mais on y arrive.
Je vais probablement laisser tomber pour ce soir. J’ai encore du développement à faire sur mes outils. Mais bordel, ça va être sympa. Je me prépare à lancer l’étude sur la mélodie que je voulais faire.
Qualité des données et incertitude
Cela dit, je bute sur des problèmes de cohérence des données et de qualité sonore. La méthode de réduction du bruit que j’utilise n’est pas assez robuste, et je vois des drapeaux d’incertitude apparaître dans 33 % des cas. C’est presque un tiers du jeu de données, ce qui rend les comparaisons avec l’ensemble d’entraînement peu fiables.
Le pipeline d’analyse
L’outil Grimes, que j’ai écrit ce week-end, gère la décomposition et la réduction du bruit sur les pistes et effectue un processus de décomposition simple pour extraire les bases de la composition. Il convertit tout ça en fichiers MIDI et crée un modèle de données Crunchy, implémentant partiellement la spec de modélisation de données Crunchy 0.3.4 que j’ai écrite la semaine dernière et que vous pouvez trouver sur GitHub.
Ensuite, il applique un fingerprinting algorithmique simple, découpant chaque chanson en une série de connexions ou de points de données. Ceux-ci servent à comparer chaque piste à toutes les autres du corpus, ainsi qu’aux données d’entraînement présumées (qui sont traitées avec la même méthodologie).
Conceptuellement, c’est très amusant. Imaginez un genre de toile 3D de données flottantes, comme dans un film Avengers.
Pour l’instant, le problème, c’est la qualité sonore. L’outil enregistre ce qu’il pense être la précision de l’extraction en analysant les marqueurs et les pics de la composition, et signale comme « bizarres » les distorsions non résolues et autres données floues que vos oreilles ne remarqueraient peut-être pas, mais que les machines auraient du mal à comprendre.
Les niveaux de certitude sont fixés à bas, moyen et haut une fois le processus d’extraction terminé. Et tout est logué. Le logging se fait par piste et par lot.
Et voilà comment j’évalue la faisabilité de mes outils face au jeu de données. On n’y est pas encore tout à fait.
Je dois faire baisser mes chiffres si je veux que ça marche.
J’espère vraiment pouvoir faire ça sans calculer le mur de bruit (parce que ça demanderait plus de puissance de calcul que ce que j’ai).
Laisser les données livrer leurs secrets
Honnêtement, je suis beaucoup moins inquiète de trouver quelque chose de compromettant qu’avant, mais il est important de garder l’esprit ouvert. Si c’était une question de sentiments personnels ou d’intentions cachées, les données ne seraient pas plus utiles que tout ce qui a été publié sur le corpus jusqu’à présent.
Il nous faut quelque chose d’un peu plus objectif. Laissons les données livrer leurs secrets d’une manière qui permette l’examen et une revue équitable. Pas de langage magique, pas de suppositions au départ, pas de grands discours.
Comme pour tout ce qui touche à l’art... tout est dans la méthode et le processus.