Rapports de progression du projet

Cette page contient les rapports de progression du projet. Elle sera mise à jour au fur et à mesure de leur rédaction et constitue l'espace principal de publication.

Semaine 0 : Préambule

Avant de s’intéresser à la création d’un moteur de recherche musical, il est important de se pencher sur le statut quo. En effet, il existe déjà des moteurs de suggestion musicale dans les principales applications modernes de streaming musical. Le lecteur aura sûrement déjà interagi avec certains d'ente eux. Je m’intéresserai dans ce rapport au moteur qui est considéré comme le standard d’industrie, celui de Spotify. Il alimente un des fonctionnalités clés du client Spotify : les recommandations automatiques. Celles-ci sont utilisées pour venir artificiellement étendre une playlist crée par l’utilisateur, de la sorte que au lieu de retourner au premier morceau, l’utilisateur se voit offrir l’opportunité de profiter d’une « playlist infinie ».
Dans son état actuel, ce moteur présente un grand avantage : il est très rapide. Il est capable de générer des séries de recommandations à la volée sans que l’utilisateur ne perçoive de ralentissement de service.
Néanmoins, et c’est là que nous touchons à la problématique du projet, ce moteur se contente de générer des suggestions avec comme entrée les autres morceaux de la playlist. Les résultats sont donc acceptables, mais présentent souvent une faible diversité de genre et une déviation émotionnelle pouvant grandement varier d’un titre à l’autre.
En 2024 et 2025, des fonctionnalités ont été rajoutées par Spotify pour proposer aux utilisateurs des playlist thématiques (les "Mix"). Ceux-ci se présentent sous la forme de playlist auto-générées quand l’utilisateur recherche un mot clé spécifique qui peut servir de graine émotionnelle pour la génération. Malheureusement, il est facile de constater la nature hasardeuse et peu originale de ces "Mix". En effet, ces playlists utilisent des morceaux extraits d’autres playlists de l’utilisateur avec une identité émotionnelle plus ou moins bien identifiée, et utilisent ensuite ces morceaux comme graine de génération via les principes mentionnés précédemment.
L’objectif de ce projet de recherche est d'aller au-delà de ce genre de structure, en trouvant une façon intuitive pour l’utilisateur de passer en entrée du moteur de recherche un état émotionnel désiré et de visualiser les résultats d’une façon qui fasse du sens.

Semaine 1 : Etat des lieux des métriques existantes

Comment décrit-on un morceau de musique de façon objective ? C’est une question plus complexe qu'il n'y parait, en effet, l’essentiel de nos outils descriptifs issus de notre logos (au sens grec du terme) sont confinés à des représentations subjectives de l’espace émotionnel, induisant donc un biais lors de la transmission de l’information émotionnelle.
Par exemple, je pourrai trouver que An die Freude de Beethoven est un morceau très gai et plein d’espoir, mais il serait également acceptable de privilégier la vision mélancolique qui ressort du morceau.
La tache se complexifie d’autant plus que les perceptions elles-mêmes sont biaisées par les diverses barrières à la compréhension qui pourraient séparer les auditeurs : en admettant que l'auditeur ne comprenne pas l’anglais Suicide is painless de Johny Mandel serait un simple morceau mélancolique tel qu’il en passe des dizaines à la radio, mais l’information contenue dans les paroles, suivie du contexte associé (son utilisation en tant que générique de "M.A.S.H") en fait un morceau dont l’impact émotionnel sur l’auditeur peut grandement varier.

Plusieurs métriques quantifiées sont aujourd’hui disponibles afin de proposer une solution partielle à ce problème. Parmi celles-ci, on peut citer

-Le tempo (souvent mesuré en BPM) -La tonalité -La valence -La liveness -Le arousal (Imparfaitement traduisible en Excitation) -Le speechiness -L’intensité (Loudness)

Ces métriques présentent le double avantage de ne pas nécessiter d’intervention humaine pour leur calcul, retirant ainsi le risque de biais, et aussi de proposer une sortie quantifiée, donc exploitable dans notre contexte.

Le tempo est sans doute la plus élémentaire mais aussi une des plus importantes de ces métriques. C’est le rythme fondamental sur lequel le morceau se construit et propose déjà une information générale sur celui-ci. De façon générale, des morceaux avec une énergie plus élevée auront un BPM plus élevé, à l’opposé de morceaux plus tristes ou à l’énergie plus faible qui tendent à avoir un BPM plus faible. Un exemple êxtreme que j’aime donner pour illsutrer ce cas est Binary data XXXIV de Alfonso Peduto avec un BPM de 198. Le solo de piano souligne à quel point la rapidité du tempo donne toute son intensité au morceau.

La tonalité est un élément plus technique du morceau, qui intervient notamment lors de sa création, ou de son exploitation quand on cherche à l’associer à d’autres morceaux. En effet, la tonalité correspond à la note qui décrit le mieux le morceau.La quantification de cette information est dépendante du système musical utilisé, en effet il existe plusieurs systèmes de notation pour les notes. Les pays parlant une langue avec des racines anglo-saxonnes utilisent les lettres de l’alphabet (C D E F G A B) alors que les pays parlant une langue latine utilisent le système bien connu du Do Ré Mi fa Sol La Si (lui-même tiré d’un chant en latin, le Ut queant laxis (hymne pour saint Jean-Baptiste) que Gui d'Arezzo utilisa pour créer ledit système). Il existe beaucoup de façons plus ou moins exactes de déterminer la tonalité d’un morceau, que ce soit à l’oreille ou par ordinateur, et même là, ce n’est pas une science exacte puisqu'il y a encore des questions ouvertes dans ce domaine. La chanson Sweet Home Alabama de Lynyrd Skynyrd fait l’objet d’un débat entre musicologue depuis sa sortie, ceux-ci ne pouvant tomber d’accord sur sa tonalité.

L’intensité d’un morceau (qui est une traduction de loudness) n’est pas une simple mesure de son volume sonore, en effet, il suffirait alors d’amplifier un morceau pour fausser cette mesure. De façon générale, elle est calculée après avoir ramené l’enveloppe du morceau a un niveau permettant de le comparer avec les autres (l’enveloppe de l’enregistrement correspond grossièrement à l’espace que l’on donne à la forme d’onde pour se développer en amplitude. Réduire l’enveloppe réduit l’amplitude moyenne de la forme d’onde contenue et mène à une diminution du volume perçu). Cette mesure peut être quantifiée soit par une unité arbitraire, par souci d’interopérabilité, soit, si l’on envisage de ne travailler que sur un seul système sonore, en dB.

Nous entrons maintenant dans le domaine des métriques agrégées, qui utilisent des combinaisons de mesures et des stratégies de calcul qui mènent à des résultats beaucoup plus abstraits. Ces métriques sont parfois calculées par des algorithmes propriétaires sur lesquels on ne sait que peu de choses.

Le Speechiness détermine si le morceau est instrumental ou chanté. Plus la valeur se rapproche de 1, plus le morceau est supposé contenir de la parole humaine ininterrompue. Inversement, une valeur de 0 ou proche de zéro tendrait à indiquer un morceau purement instrumental.

Le liveness indique par une échelle de zéro à 1 à quel point il est probable que le morceau ait été enregistré lors d’une performance live de l’artiste.

La valence est une unité calculée par machine learning. D’après la documentation de l’API de Spotify, elle décrit la "positivité" générale du morceau. Plus un morceau serait joyeux, positif, plus celui-ci aurait une valence proche de 1. A l’inverse, un morceau triste aurait une valence proche de 0.
Elle est intimement liée, via le modèle circumplex de Russel, à une autre mesure nommée dans le système original Arousal mais renommée pour des raisons se passant d’explications en energy par Spotify. Le peu d’information disponible sur la façon dont Spotify calibre cette mesure en interne tend à indiquer que les deux représentent fondamentalement la même chose, c’est-à-dire la deuxième coordonnée du modèle de Russell qui représente un état d’activité et d’énergie pouvant varier entre des valeurs bornes.

Semaines 3 et 4 : Bases de données, vecteurs, représentations à dimensionnalité élevée et datasets

Embeddings

Pour faire un moteur de recherche, il faut avoir des éléments à chercher. De façon générale, il est toujours préférable d'effectuer la recherche dans un ensemble de données du même format.
Il s'agirait ici de vecteurs émotionnels, c’est-à-dire une représentation vectorisée des différentes métriques et embeddings représentatifs du morceau. Un embedding est une représentation vectorisée d’une entité générée par un modèle de machine learning.
Les embeddings seront nécessaire pour représenter certains éléments qui sont impossibles à résumer en une valeur unique, par exemple les paroles. Étant donné qu'il n'est ni possible ni pertinent d'effectuer une recherche qui utiliserait l'intégralité des paroles (il est de toute façon impossible de calculer la proximité vectorielle de phrases sans passer par cette méthode) on utilise un générateur d'embeddings. La nécessité de générer des embeddings compacts afin de garder la taille de la base de données sous contrôle, ainsi que de traiter des segments de texte de taille conséquente (des paroles de chanson) nous force à nous tourner vers des modèles capables de générer des représentations vectorielles de faible dimensionalité. Qwen3-embedding-0.6b se détache dans ce contexte comme la meilleure option. Il est capable de générer des embeddings pouvant descendre jusqu'à 64 dimensions et est rapidement exploitable grâce à son enregistrement sur le CDN de la librairie sentence transformer de Hugging Face qui offre un excellent niveau d'abstraction par rapport aux modèles. Cette abstraction sera la bienvenue au moment de la lancer le traitement de la base de données, elle permettra notamment de ne pas avoir à se soucier du chargement et de l'amorçage du modèle, qui sont pris en charge par la librairie.

Paroles

Les paroles sont indissociables d'une musique. Elles contiennent le vrai sens du morceau et peuvent changer complètement son interprétation émotionnelle. Un morceau a la musique triste peut avoir des paroles joyeuses et inversement. Il est donc nécessaire de les inclure dans notre analyse émotionnelle. La récupération des paroles s’est révélé être un obstacle important mais qui a éventuellement été surmonté.

Construction du dataset autour des paroles

Le dataset FMA que j’utilise est naturellement non biaisé, à condition de ne pas introduire de déséquilibre entre les 156 catégories. C’est extrêmement avantageux pour nous puisque cela fait en sorte que la dataset est research ready (prêt à l’exploitation pour un usage scientifique). La subdivision du dataset en catégories joue aussi à notre avantage puisqu’il est impossible à notre échelle d’exploiter les plus de 106000 moreaux de ce dernier, le plan était donc de piocher dix morceaux au hasard dans chaque catégorie pour créer un petit sous-dataset de 1560 morceaux, baptisé pour l’occasion « micro-FMA ». Le problème est que, pour que les paroles représentent une part significative du dataset (idéalement 50%), il faudrait aider le hasard. A cet effet, la stratégie suivante à été mise au point :

Pour chaque morceau d’une catégorie :
    le morceau a-t-il des paroles ?
        si oui :
            As-t-on déjà 5 morceaux avec paroles pour cette catégorie ?
                si non : 
                    ajouter le morceau à micro-FMA
                si oui :
                    ignorer le morceau
        si non : 
            As-t-on déjà 5 morceaux sans paroles pour cette catégorie ?
                si non : 
                    ajouter le morceau à micro-FMA
                si oui :
                    ignorer le morceau
Passer à la catégorie suivante

Acquisition des paroles

Initialement, je pensais m procurer les paroles par l’intermédiaire de datasets libres qui me permettraient d’opérer une jointure entre les morceaux du dataset FMA dont on connaît les informations clé (titre, album, année, etc.) via son index. La question est donc maintenant de se mettre en recherche d’un dataset de paroles musicales. Je me suis premièrement intéressé à OpenLyrics, qui est généralement le premier point d’entrée dans la recherche de parole crowdsourcée libres. Mais une rapide inspection avec leur outil de recherche a mené à son élimination, sachant qu’un nombre important de chansons très populaires qui se trouvait dans FMA ne se trouvait pas dans OpenLyrics.

On touche ici au problème récurrent de la couverture. Une bonne façon de compter le nombre de morceau de musique en circulation aujourd’hui et de passer par l’ISRC (International Standard Recording Number). Ce numéro unique a chaque morceau permet aux maisons de distribution et aux labels de suivre de façon standardisée la da distribution des morceaux et de faciliter la gestion des copyrights. L’ISRC ne doit pas être confondu avec d’autres systèmes tiers tels que le Spotify ID, l’Apple Music ID, et le Musixmatch commontrack ID (dont il sera question dans les sections ultérieures), dans le sens qu’il s’agit du seul système d’identification des morceaux de musique dans le monde qui soit complètement agnostique concernant la plateforme de distribution.

Le nombre d’ISRC dans la base de données de l’IFPI (International Federation of the Phonographic Industry), qui est l’organisation chargée de maintenir le standard et les bases de données associées, dépasse les 150 millions, ce qui fait de la recherche d’une bonne couverture par un jeu de donnée un défi des plus intéressants. Une tentative a ensuite été réalisée avec un dataset issu de la jointure entre le 5 million song dataset et la base de données du site de paroles Genius. Ce dataset se présentait comme un csv de dimensions significative qui a mené au crash immédiat de Excel, Libre Office Calc, et même de Tablecruncher. J’ai donc dû faire usage des outils en ligne de commande Visidata et Xan afin de manipuler ce csv sans le charger en mémoire, sachant qu’il fallait encore opérer une jointure entre FMA et ledit dataset. Après plusieurs essais, cette tentative s’est soldée par un échec après la confirmation que la couverture était elle aussi insuffisante. A la suite de cet échec, deux décisions ont été prises afin de maximiser la probabilité d’un succès. Dans un premier temps, je me suis tourné vers le dataset LRCLIB et ai commencé à en télécharger les dumps (qui sont des fichiers aux formats SQLite) et j’ai effectué une demande de financement pour un abonnement à l’onéreuse API de Musixmatch, sur laquelle je reviendrais très bientôt.

Le dump de LRCLIB étant un fichier SQLite, il allait falloir le manipuler à travers du SQL. A cet effet, j’ai utilisé l’application DataGrip de JetBrains qui permet de faire tourner plusieurs SGDB en parallèle et de faire des requêtes inter-bases. L’index de FMA étant un csv, j’ai dû le convertir avec SQLite Tools en fichier SQLite. J’ai ensuite essayé de faire des jointures entre les différentes bases de données pour obtenir les paroles. La base de données de LRCLIB était organisée en un grand nombre de tables, ce qui a nécessité plusieurs jointures très couteuses. Il fallait d’abord faire une jointure par titre et album pour trouver les morceaux de FMA dans la table principale, puis effectuer une jointure sure, non pas l’id principal de cette table, mais le last_known_track_id avec la table des paroles, puis exporter cette table en CSV. Les datasets en question pesant jusqu’à 100 Go, il n’était pas possible pour moi de les manipuler sur ma machine, il a donc fallu passer par un SSD externe. Le problème est que ces requêtes effectuaient des jointures très inefficaces, notamment la première qui demandait un full read de la base. Les opérations pouvaient prendre jusqu’à 15 minutes pour s’exécuter. J’ai reçu au même moment la confirmation de M. Lafontant que je pouvais procéder à l’achat d’un abonnement à Musixmatch, ce qui a débloqué la situation en une soirée.

Musixmatch

La compagnie Bolonaise Musixmatch est actuellement la référence en matière de parole de musique. En effet, ils s’appuient sur une contribution participative (faiblement) rémunérée, de la sorte que n’importe qui peut contribuer au jeu de paroles et être récompensé pour son travail. De plus, Musixmatch est le backend utilisé par toutes les plateformes majeures de streaming musicales pour leurs paroles. Spotify et Apple music ont un contrat avec eux, ce qui représente environ 50% du streaming musical dans le mode. De la sorte, leur couverture est une quasi garantie. Si un morceau existe sur ces plateformes et qu’il a des paroles, il n’y a probablement pas de meilleur endroit pour les chercher que Musixmatch.
La raison pour laquelle il a fallu attendre que la demande de financement soit acceptée est que Musixmatch est premièrement exceptionnellement difficile à contacter et que leur site mentionne de façon explicite qu’ils ne sont pas intéressés par la recherche.

Néanmoins, une fois la clé API récupérée, les choses ont pu s’enchaîner très rapidement, avec le caveat que la clé venait avec un nombre très limité de requêtes pour les paroles. De la sorte, il a fallu procéder à une petite optimisation par-dessus l’algorithme susmentionné. J’ai en effet remarqué que la limite pour les appels de paroles était très limitée, un nombre significativement plus grand d’appels était autorisé dans la catégorie généraliste. L’optimisation a donc été d’effectuer en premier le morceau, puis dans la réponse de l’endpoint de recherche vérifier si le morceau est instrumental ou non. Si c’est le cas, on peut alors agir en fonction, notamment si la catégorie contient déjà suffisamment de morceaux du type en question. Cette recherche et association s’effectue à l’aide du commontrack id, qui est le numéro d’identification de morceau interne utilisé par Musixmatch.