ThesisPDF Available

Détection et classification des notes d'une piste audio musicale

Authors:

Abstract and Figures

Nous présentons dans ce mémoire des contributions aux domaines du MIR, Musical Information Retrieval, et à l'AMT, Automatic Music Transcription. Une échelle de classification des travaux d'AMT est proposée, afin de définir quels sont les champs d'application de chaque recherche. Cette échelle classe en fonction des contextes monophonique et polyphonique, ainsi que mono-instrumental et multi-instrumental. Un outil est proposé, nommé Mélodium, permettant d'appliquer des traitements de signal à des données audio et musicales. Il gère également les données MIDI, Musical Instrument Digital Interface, ainsi que les fontes sonores. Cet outil est couplé à un langage de script permettant d'automatiser les traitements et de faciliter l'écriture d'expérimentations. Ce langage est axé sur l'application de traitements et la transmission des données entre-eux, en ôtant à l'utilisateur la responsabilité de manipulation de mémoire et d'ordonnancement. En plus de diverses expérimentations réalisées avec Mélodium, nous présentons des modèles à base d'auto-encodeurs éparses et de réseaux de neurones à propagation avant, capables de retranscrire de la musique dans des contextes monophoniques et polyphoniques. Ces modèles exploitent notamment les descripteurs HPCP, Harmonic Pitch Class Profiles, MFCC, Mel Frequency Cepstral Coefficients, et GFCC, Gammatone Frequency Cepstral Coefficients, pour effectuer la transcription. Sur la base de ces expérimentations, nous proposons une méthode permettant d'étendre à tout instrument la transcription monophonique automatique, en détaillant les étapes et l'architecture nécessaire pour y parvenir.
Content may be subject to copyright.
UNIVERSITÉ DU QUÉBEC À MONTRÉAL
DÉTECTION ET CLASSIFICATION DES NOTES
D’UNE PISTE AUDIO MUSICALE
MÉMOIRE
PRÉSENTÉ
COMME EXIGENCE PARTIELLE
DE LA MAÎTRISE EN INFORMATIQUE
PAR
QUENTIN VIGNAUD
JUIN 2020
REMERCIEMENTS
Comme pour toute chose accomplie en cette période, il y aurait bien trop de
personnes à remercier, de tous nos aïeuls au plus sombre inconnu de nos contem-
porains. Mais entre ces extrêmes se trouvent certains qui le méritent plus que
d’autres. Mes parents, grands-parents, et sœurs pour leur soutien depuis le Vieux
Continent. Mes professeurs, actuels comme passés, pour leur vocation. Et mes très
chers camarades et amis de tous bords.
Plus spécialement, je tiens à remercier pour cette maîtrise le professeur Bouguessa
pour m’avoir accepté dans son équipe, et pour toutes ses invitations à de bons
repas ; le professeur Privat pour ses cafés devenus rituels ; et mes collègues avec qui
j’ai pu partager moultes idées plus ou moins judicieuses. Merci également à Pierre
Pellegrin, qui a travaillé sur ces recherches lors de son stage à l’UQAM. Enfin,
merci à Florian, Mélanie, Lâm, Oswald, Jehan, Ellen, Julien, Morgane, Aimeric,
Éloïse, Victor, et Simon, et tous les autres, pour ces années passées au travers des
hivers et étés de Montréal.
TABLE DES MATIÈRES
LISTEDESTABLEAUX ........................... vii
LISTEDESFIGURES............................. viii
RÉSUMÉ .................................... x
INTRODUCTION ............................... 1
0.1 Origine .................................. 1
0.2 Objectif .................................. 2
0.3 Perspectives................................ 3
0.4 Contributions............................... 4
0.5 Structure ................................. 4
CHAPITRE I
DÉFINITION ET ÉCHELLE DE TRANSCRIPTION AUTOMATIQUE
DELAMUSIQUE............................... 5
1.1 Monophonique mono-instrumental . . . . . . . . . . . . . . . . . . . . 6
1.2 Polyphonique mono-instrumental . . . . . . . . . . . . . . . . . . . . 7
1.3 Monophonique multi-instrumental . . . . . . . . . . . . . . . . . . . . 7
1.4 Polyphonique multi-instrumental indistinct . . . . . . . . . . . . . . . 8
1.5 Polyphonique multi-instrumental distinct . . . . . . . . . . . . . . . . 8
CHAPITRE II
REVUE DU DOMAINE DE LA RESTITUTION DES INFORMATIONS
MUSICALES.................................. 10
2.1 Représentation des données . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Descripteurs et transformations . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Spectre .............................. 11
2.2.2 MFCC............................... 12
2.2.3 GFCC............................... 12
iv
2.2.4 HPCP............................... 12
2.3 Classification du genre musical . . . . . . . . . . . . . . . . . . . . . 13
2.4 Détection des instruments . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Transcription automatique de la musique . . . . . . . . . . . . . . . . 15
CHAPITRE III
PROPOSITION D’UN NOUVEL OUTIL : MÉLODIUM . . . . . . . . . . 17
3.1 Nécessitédunoutil............................ 17
3.2 Tâchesspéciques ............................ 18
3.3 Composants techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Architecture................................ 22
3.4.1 Pistes ............................... 22
3.4.2 Traitements............................ 22
3.4.3 Exécutants ............................ 23
3.4.4 Modèles .............................. 23
3.4.5 Initialisateurs et préparateurs . . . . . . . . . . . . . . . . . . 24
3.4.6 Ordonnanceurs .......................... 25
3.5 Usage et fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.1 Ligne de commande . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.2 Initialisateurs........................... 26
3.6 Performances ............................... 27
CHAPITRE IV
LANGAGE DE MANIPULATION DE DONNÉES AUDIO ET MUSICALES 28
4.1 Paramètresettypes ........................... 29
4.2 Traitements ................................ 30
4.3 Séquences ................................. 30
4.4 Connexions ................................ 31
4.5 Préparateurs ............................... 32
4.6 Modèles .................................. 34
v
4.7 Multipistes ................................ 35
CHAPITRE V
ÉTUDES EMPIRIQUES DE DÉTECTION ET CLASSIFICATION DES
NOTESDEMUSIQUE ............................ 36
5.1 Choix et constitution des jeux de données . . . . . . . . . . . . . . . 36
5.1.1 Fonte sonore en jeu monophonique . . . . . . . . . . . . . . . 36
5.1.2 Échantillons et œuvres en jeu polyphonique . . . . . . . . . . 38
5.2 Procédures de prétraitement . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.1 HPCP............................... 39
5.2.2 MFCC&GFCC ......................... 40
5.2.3 Spectre .............................. 40
5.3 Représentation et paramétrage des données . . . . . . . . . . . . . . 41
5.4 Constitution des architectures . . . . . . . . . . . . . . . . . . . . . . 43
5.5 Modèles expérimentaux . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6 Évaluation et exécution . . . . . . . . . . . . . . . . . . . . . . . . . 50
CHAPITRE VI
RÉSULTATS ET ANALYSES DU COMPORTEMENT DES ARCHITEC-
TURES ET MODÈLES D’APPRENTISSAGE MACHINE . . . . . . . . . 52
6.1 Échecs d’apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Architectures fructueuses . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3 Succès des auto-encodeurs . . . . . . . . . . . . . . . . . . . . . . . . 56
6.4 Apprentissage polyphonique . . . . . . . . . . . . . . . . . . . . . . . 58
CHAPITRE VII
PROTOCOLE DE CRÉATION DE MODÈLE DE TRANSCRIPTION MO-
NOPHONIQUE MONO-INSTRUMENTAL . . . . . . . . . . . . . . . . . 61
7.1 Donnéesrequises ............................. 61
7.2 Traitementaudio ............................. 62
7.3 Architecture................................ 63
7.4 Apprentissage............................... 64
vi
CONCLUSION................................. 66
APPENDICE A
LISTE DES TRAITEMENTS DISPONIBLES DANS MÉLODIUM . . . . 68
APPENDICE B
EXEMPLE DE DOCUMENTATION D’UN TRAITEMENT . . . . . . . . 71
APPENDICE C
SCRIPTSMÉLODIUM ............................ 73
C.1 ExtractionduHPCP........................... 73
C.2 Extraction du HPCP et spectre . . . . . . . . . . . . . . . . . . . . . 74
C.3 Extraction du HPCP, MFCC, et GFCC . . . . . . . . . . . . . . . . . 75
C.4 Obtention d’un modèle de classification monophonique mono-instrumental 80
APPENDICE D
RESSOURCES UTILISÉES PAR LES EXPÉRIMENTATIONS . . . . . . 83
APPENDICE E
RÉSULTATS DÉTAILLÉS D’EXPÉRIMENTATIONS . . . . . . . . . . . 86
E.1 Apprentissages monophoniques mono-instrumentaux . . . . . . . . . 86
E.2 Époques d’apprentissages monophoniques mono-instrumentaux . . . . 89
E.3 Séquences d’époques d’apprentissage monophoniques mono-instrumentaux 91
RÉFÉRENCES................................. 94
LISTE DES TABLEAUX
Tableau Page
1.1 Échelle de transcription automatique de la musique. . . . . . . . . 6
5.1 Instruments sélectionnées pour l’apprentissage monophonique. . . 37
5.2 Bandes de filtrage de fréquences. . . . . . . . . . . . . . . . . . . . 40
5.3 Synthèse des possibilités de configuration de lecture et découpage
designaux. .............................. 41
6.1 Scores d’apprentissage monophonique mono-instrumental du mo-
dèle HSaC onst10(1200 400; 10 ×400) à l’époque no. . . . . . 56
A.1 Liste des traitements disponibles dans Mélodium. . . . . . . . . . 69
D.1 Mémoire utilisée par les expérimentations . . . . . . . . . . . . . . 84
D.2 Durées des expérimentations . . . . . . . . . . . . . . . . . . . . . 85
LISTE DES FIGURES
Figure Page
0.1 Illustration de l’objectif recherché. . . . . . . . . . . . . . . . . . . 2
2.1 Échantillonnage d’un signal . . . . . . . . . . . . . . . . . . . . . 11
3.1 Graphe de dépendance de Mélodium. . . . . . . . . . . . . . . . . 21
3.2 Types de données présentes dans une piste. . . . . . . . . . . . . . 22
4.1 Exemple d’exécution multipistes. . . . . . . . . . . . . . . . . . . 35
5.1 Variations d’échantillonnage d’un signal de même durée. . . . . . 42
5.2 Variation de découpage et sauts de trames . . . . . . . . . . . . . 42
5.3 Variations de la représentation par le descripteur HPCP d’un même
signal selon le paramétrage de lecture et découpage. . . . . . . . . 43
5.4 Types d’architectures d’expérimentations. . . . . . . . . . . . . . 44
5.5 Schéma des architectures. . . . . . . . . . . . . . . . . . . . . . . 45
5.6 Hiérarchie des modèles expérimentaux H et partage de propriétés. 48
5.7 Hiérarchie des modèles expérimentaux HS et partage de propriétés. 49
5.8 Hiérarchie des modèles expérimentaux HMG et partage de propriétés. 50
6.1 Apprentissage monophonique sur l’instrument 013 Xylophone. . . 53
6.2 Détail d’époques d’apprentissage monophonique sur l’instrument
013 Xylophone. ............................ 55
6.3 Apprentissage monophonique sur l’instrument 048 Ensemble de cordes
acoustiques. .............................. 57
6.4 Apprentissage monophonique sur l’instrument 080 Signal carré. . 58
6.5 Apprentissage monophonique sur l’instrument 019 Orgue d’église. 59
ix
6.6 Apprentissage polyphonique sur le jeu Musiques........... 60
7.1 Prétraitements pour la transcription monophonique. . . . . . . . . 63
7.2 Architecture du modèle de transcription automatique monophonique. 64
E.1 Apprentissage monophonique du modèle HSaConst10 ....... 86
E.2 Époque d’apprentissage monophonique du modèle HSaConst10 no 89
E.3 Séquence d’apprentissage monophonique du modèle HSaConst10 92
RÉSUMÉ
Nous présentons dans ce mémoire des contributions aux domaines du MIR, Mu-
sical Information Retrieval, et à l’AMT, Automatic Music Transcription. Une
échelle de classification des travaux d’AMT est proposée, afin de définir quels
sont les champs d’application de chaque recherche. Cette échelle classe en fonc-
tion des contextes monophonique et polyphonique, ainsi que mono-instrumental
et multi-instrumental.
Un outil est proposé, nommé Mélodium, permettant d’appliquer des traitements
de signal à des données audio et musicales. Il gère également les données MIDI,
Musical Instrument Digital Interface, ainsi que les fontes sonores. Cet outil est cou-
plé à un langage de script permettant d’automatiser les traitements et de faciliter
l’écriture d’expérimentations. Ce langage est axé sur l’application de traitements
et la transmission des données entre-eux, en ôtant à l’utilisateur la responsabilité
de manipulation de mémoire et d’ordonnancement.
En plus de diverses expérimentations réalisées avec Mélodium, nous présentons
des modèles à base d’auto-encodeurs éparses et de réseaux de neurones à propa-
gation avant, capables de retranscrire de la musique dans des contextes mono-
phoniques et polyphoniques. Ces modèles exploitent notamment les descripteurs
HPCP,Harmonic Pitch Class Profiles,MFCC,Mel Frequency Cepstral Coeffi-
cients, et GFCC,Gammatone Frequency Cepstral Coefficients, pour effectuer la
transcription. Sur la base de ces expérimentations, nous proposons une méthode
permettant d’étendre à tout instrument la transcription monophonique automa-
tique, en détaillant les étapes et l’architecture nécessaire pour y parvenir.
Mots-clés : MIR, AMT, monophonique, polyphonique, MIDI, fonte sonore,
Mélodium, auto-encodeur, HPCP, MFCC, GFCC, signal
INTRODUCTION
0.1 Origine
Depuis que l’électronique et l’informatique ont rencontré le son et la musique
au cours du siècle dernier, énormément de progrès communs à ces deux mondes
ont été faits. Les systèmes techniques d’enregistrement et de restitution de l’onde
sonore se sont sans cesse améliorés et continuent encore de le faire actuellement.
Dans un passé plus récent, depuis les années 19801, a été développé un système,
à la fois technique, normatif, et d’encodage, permettant de disposer de la donnée
musicale et non plus uniquement de l’onde sonore. Il s’agit du système MIDI,
pour Musical Instrument Digital Interface (Moog, 1986). Ce système permet de
représenter numériquement les notes ainsi que d’autres caractéristiques musicales
sur une plage de temps définie. Initialement utilisé par les synthétiseurs électro-
niques, le MIDI est exploité de nos jours par tous les logiciels de composition et
de rendu musical qui se sont développés depuis sa création. Il est présentement le
standard de fait pour véhiculer l’information musicale.
Nous disposons donc d’un moyen d’encoder la musique, et en parallèle de multiples
techniques pour enregistrer le signal sonore, parmi lesquelles nous pouvons citer
les formats PCM, Flac, ou MP3 et Vorbis/Opus 2. Or, notre problématique com-
1. La première norme du système MIDI fut publiée en 1983.
2. PCM : Pulse Code Modulation, couramment utilisé dans le format Wave, Waveform Audio
File Format ; Flac : Free Lossless Audio Codec ; MP3 : MPEG-1/2 Audio Layer III ;Opus
Interactive Audio Codec ; la différence entre PCM & Flac ainsi que MP3 & Vorbis/Opus étant
que les premiers conservent le signal tel qu’il est enregistré « sans perte », les seconds
effectuent une compression excluant certaines composantes sonores.
2
mence ici : la génération d’un signal sonore à partir de données musicales est une
tâche courante. Qu’il s’agisse d’un musicien jouant sa partition, d’un synthétiseur
générant un signal, d’un logiciel faisant un rendu, nous disposons de multiples
techniques abouties. Bien que ne pouvant être qualifiées de simples, elles sont
éprouvées et ne représentent plus de difficultés. Mais il n’en va pas de même pour
la tâche inverse.
0.2 Objectif
Notre problématique est la suivante : nous voulons établir une méthode permet-
tant de retranscrire automatiquement la mélodie présente dans un signal audio
(un enregistrement sonore), en des données musicales (un fichier MIDI, et par
extension des partitions).
Figure 0.1: Illustration de l’objectif recherché.
Le processus de génération d’une combinaison de signaux n’est en l’état pas ré-
versible, c’est-à-dire qu’à partir d’une piste audio, on ne peut pas retrouver de
manière triviale la partition qui a permis de générer la musique. La retranscrip-
tion musicale implique entre autres les problèmes de déconstruction de signaux,
et de séparation des sources ; qui ne sont pas des tâches solvables de façon satis-
faisante de manière automatique. La meilleure solution consiste encore à effectuer
3
le travail manuellement.
Aucun outil, qu’il soit commercial ou expérimental, n’est capable à ce jour de res-
tituer depuis un fichier sonore plat des partitions convenables pour les instruments
originels, et encore moins en disposant d’un signal sonore en direct. Le moyen le
plus commun actuellement pour obtenir, en direct, une retranscription musicale
est d’utiliser des instrument disposant d’une interface MIDI. Ceci afin d’avoir
numériquement l’information musicale au même moment que le son est produit
naturellement. Cette technique est lourde car elle requiert des instruments spécifi-
quement équipés, et est dans les faits relativement peu usitée lorsqu’elle n’est pas
absolument nécessaire. Elle ne permet pas non plus de retranscription a posteriori.
0.3 Perspectives
Les implications de la possibilité de retranscrire automatiquement la musique sont
multiples. En premier lieu, l’industrie musicale disposerait d’un moyen plus large
pour analyser et relever des plagiats ou des utilisations non autorisées d’œuvres.
Les plateformes et les instituts disposant de larges banques d’enregistrement pour-
raient en effectuer des classifications sur la base du contenu musical.
Pour ce qui est du domaine de la musicologie, ceci permettrait des retranscriptions
et des analyses massives pouvant avoir un intérêt pour la recherche. Toujours dans
le domaine de la recherche, nous avons déjà des méthodes expérimentales pour
faire de la séparation de signal lorsque la partition de la musique est connue. Une
telle extension permettrait de l’appliquer à toute musique, et de disposer alors de
pistes audio distinctes pour chacun des instruments la composant.
D’un point de vue conservatoire, retranscrire une musique la pérennise, ainsi des
instituts d’archivage auraient intérêt à appliquer ce traitement à leurs enregistre-
ments. Également, avec des outils suffisamment souples, le monde de l’art pourrait
4
exploiter cette technologie afin de créer des scénographies, spectacles, ou œuvres
diverses ayant une intégration plus poussée avec la musique, incluant l’improvisa-
tion et autorisant plus de liberté de jeu.
Enfin, au delà de l’application musicale, une technique de séparation et de clas-
sification d’éléments de signaux audio peut être utilisée dans de multiples autres
contextes. Parmi ceux-ci nous pouvons citer en exemple la détection de défaillances
mécaniques dans un cadre industriel, d’évènements sonores dans un cadre de sû-
reté, ou outre le domaine sonore, d’éléments dans des signaux électromagnétiques.
0.4 Contributions
Dans nos travaux, nous apportons les contributions suivantes :
une échelle de classement de la transcription automatique de la musique ;
un outil et langage de script pour effectuer des analyses sonores ;
une méthode de création de modèles de transcription automatique.
0.5 Structure
Dans ce mémoire, au Chapitre 1, nous présentons tout d’abord une définition
plus spécifique de notre problématique, et proposons une échelle de progression.
Nous effectuons par la suite, au Chapitre 2, une revue des travaux connexes à
nos recherches. Nous expliquons alors au Chapitre 3 le besoin d’un outil et le
présentons, ainsi qu’au Chapitre 4 le langage associé. Viennent ensuite, dans le
Chapitre 5, nos études empiriques nous détaillons diverses situations possibles,
à la suite desquelles nous exposons et développons au Chapitre 6 nos analyses des
résultats obtenus. Enfin, nous proposons une méthode générique de création de
modèles de classification audio musicale au Chapitre 7.
CHAPITRE I
DÉFINITION ET ÉCHELLE DE TRANSCRIPTION AUTOMATIQUE DE LA
MUSIQUE
Le domaine de la restitution d’informations musicales s’appuie en grande partie
sur la musicologie, qui est la science d’étude de la musique. Cette science porte
aussi bien sur l’aspect culturel que physique, et même psychoacoustique3. La
restitution d’informations musicales est une tâche non triviale, mêlant diverses
problématiques. Tout d’abord, l’identification des fondamentales, harmoniques de
premier rang, ou notes, présentes à un instant d’un signal. Ensuite, l’identification
des timbres, ou instruments, liés à ces harmoniques. De plus, la distinction des
différentes sources, les différents instruments, combinées en un seul signal. Ces
trois problématiques d’ensemble constituent la tâche à accomplir pour pouvoir
restituer les informations de n’importe quelle œuvre musicale. Mais vouloir les
résoudre d’un seul tenant n’est ni raisonnable, ni encore envisageable.
Nous proposons donc une échelle, à laquelle peuvent se rapporter les différents
travaux existants tout comme ceux présentés ici. Chacun des niveaux de cette
échelle constitue une progression dans les capacités offertes par la transcription
automatique de la musique. Nous détaillons chacun d’eux dans une section dédiée.
3. La psychoacoustique est la science décrivant la perception auditive humaine du son.
6
1 Monophonique mono-instrumental
2 Polyphonique mono-instrumental
3 Monophonique multi-instrumental
4 Polyphonique multi-instrumental indistinct
5 Polyphonique multi-instrumental distinct
Tableau 1.1: Échelle de transcription automatique de la musique.
1.1 Monophonique mono-instrumental
Premier niveau de la transcription automatique, la détection monophonique mono-
instrumentale porte sur la restitution de l’harmonique de premier rang, ou note,
jouée par un instrument. Ceci dans un contexte l’on sait que seul cet instrument
joue, et qu’au plus une note est produite à un instant donné.
Bien que semblant basique cet exercice est déjà complexe, car il requiert une
connaissance du profil harmonique, ou timbre, de l’instrument examiné. Trois
approches principales sont possibles :
Générale, un modèle agnostique vis-à-vis de l’instrument tenterait de
classer au mieux des instants sonores dans la gamme des notes possibles ;
cela au risque de perdre en précision selon les spécificités de l’instrument
réellement à l’origine du son.
Par instrument, un modèle est conçu et entraîné spécifiquement pour
un type d’instrument; la difficulté étant alors d’effectuer une bonne géné-
ralisation à tous les instruments du même type.
Par famille, un modèle est conçu et entraîné pour répondre aux ca-
ractéristiques sonores d’une famille instrumentale partageant des timbres
similaires, tels les violons, altos, violoncelles et contrebasses; la détermina-
tion finale pouvant alors se faire par connaissance de la tessiture4.
4. La tessiture est l’étendue des notes pouvant être jouées par un instrument.
7
Chacune de ces approches comporte des bénéfices et sacrifices. À défaut d’offrir
un modèle universel, déterminer une architecture générique produisant des mo-
dèles spécialisés lors de l’apprentissage d’un type d’instrument, ou famille, est un
compromis raisonnable qui constitue une grande avancée en soi.
1.2 Polyphonique mono-instrumental
La détection polyphonique mono-instrumentale consiste à restituer les différentes
harmoniques fondamentales jouées par un unique instrument à un instant donné.
Une telle détection permet de transcrire des accords et les mélodies usuelles des
instruments polyphoniques, comme les cordes.
Les trois approches possibles sont les mêmes que pour le niveau monophonique
mono-instrumental. La difficulté supplémentaire que constitue ce niveau de détec-
tion est particulière : il faut parvenir à distinguer de multiples fréquences harmo-
niques entre elles, et ce même en cas de superposition. L’exemple type est un jeu
de la même note sur différentes octaves. L’émission d’une note laproduisant une
fréquence de 440 Hz, ainsi que ses harmoniques à 880 Hz, 1 760 Hz, etc., et d’une
note lasimultanée, de fréquence 880 Hz, devient très difficile à distinguer.
1.3 Monophonique multi-instrumental
Le niveau de détection monophonique multi-instrumental est l’augmentation na-
turelle de complexité survenant après les cas mono-instrumentaux. Il consiste en
la détection d’une unique note à un instant donné, et l’attribution de cette note
à un ou plusieurs instruments.
Bien que proposant un problème théoriquement intéressant, ce niveau de détec-
tion ne propose pas d’utilité pratique vis-à-vis de l’immense majorité des cultures
8
musicales. Il est en effet très rare qu’une œuvre multi-instrumentale ne fasse appel
qu’à un seul instrument à la fois, ou que l’ensemble de ses instruments ne jouent
toujours qu’une unique note à un instant donné. On peut constater que les pro-
blématiques concrètes se rapportent aux niveaux de cette échelle soit inférieurs,
soit supérieurs.
1.4 Polyphonique multi-instrumental indistinct
Le niveau de détection polyphonique multi-instrumental indistinct consiste à dé-
tecter l’ensemble des harmoniques fondamentales jouées possiblement simulta-
nément par de multiples instruments. Instruments qui ne sont à ce niveau pas
distingués.
La problématique consiste ici à découvrir l’ensemble des notes sans confusion,
celles-ci provenant de différents profils harmoniques, ou timbres, qui doivent donc
être discriminés sans pour autant être classifiés. Un modèle de ce niveau permet
de traiter la quasi totalité des œuvres musicales de toutes cultures et genres, en
ce sens que leur mélodie est restituée, peu importe les instruments employés.
1.5 Polyphonique multi-instrumental distinct
Pour finir, le niveau de détection polyphonique multi-instrumental distinct cor-
respond à la détection des harmoniques fondamentales jouées possiblement simul-
tanément par différents instruments, incluant l’identification et l’attribution à un
timbre.
Il s’agit ici de découvrir l’ensemble des notes et de savoir quels instruments les
jouent. Un tel modèle est l’objectif ultime de la transcription automatique de la
musique. Il constitue la possibilité de traiter toute œuvre musicale et d’en recons-
9
tituer les partitions la décrivant intégralement pour chaque instrument employé
en son sein. Un tel modèle est possiblement un ensemble de modèles de niveau po-
lyphonique mono-instrumental couplés à des méthodes de filtrage leur permettant
d’ignorer les timbres autres que celui analysé. Cependant cette approche pose le
problème de décomposition de signal dans laquelle une perte d’information sur-
vient, nécessitant de faire appel à des techniques de reconstruction de signal. Ces
méthodes de filtrage et techniques de reconstruction sont encore à établir.
CHAPITRE II
REVUE DU DOMAINE DE LA RESTITUTION DES INFORMATIONS
MUSICALES
Ce travail fait partie d’un ensemble portant sur la recherche d’informations mu-
sicales, MIR, pour Musical Information Retrieval. Ce domaine recoupe plusieurs
disciplines parmi lesquelles la musicologie, la psychoacoustique, l’analyse de signal,
l’apprentissage automatique, et plus généralement l’informatique. Le regard porté
sur ce domaine se fait ici essentiellement depuis le point de vue des recherches en
apprentissage machine.
2.1 Représentation des données
Une des premières caractéristique de ce domaine est la représentation des données
à adopter en tant que vecteur d’entrée. l’analyse de données visuelles peut se
faire par des matrices de pixels brutes, l’analyse de signal audio requiert un choix,
ou une composition de choix, entre les multiples représentations possibles. Les
plus courantes sont le spectrogramme (pouvant être linéaire ou logarithmique),
des résultats de filtrage du signal, ou des descripteurs sonores spécifiques. L’usage
direct de la forme d’onde (couramment appelé « signal brut ») est moins populaire,
et quasi systématiquement accompagné d’une autre représentation (Sigtia et al.,
2016).
11
S’agissant d’un signal continu, il est nécessaire d’effectuer un découpage en trames
de celui-ci. Ce découpage est toujours opéré sur la forme d’onde lorsque des ana-
lyses ayant pour résultat des valeurs uniques sont opérées, ces valeurs résultantes
qualifiant alors l’intégralité de la trame.
La fréquence d’échantillonnage de la forme d’onde, la largeur de trame, ainsi que le
saut de décalage entre trames sont des facteurs primordiaux dans l’apprentissage
et les résultats obtenus. Un enregistrement audio standard sur Compact Disc est
échantillonné à 44100 Hz, les enregistrements professionnels à 48 000 Hz, et la
téléphonie utilise 7 000 Hz. Lors de l’application d’algorithmes d’apprentissage
automatique, il est courant de réduire la fréquence d’échantillonnage à 16 000 Hz.
x(t)
t
Signal réel
Échantillonnage
Figure 2.1: Échantillonnage d’un signal5.
2.2 Descripteurs et transformations
2.2.1 Spectre
Le spectre sonore est la représentation de l’onde sonore une fois celle-ci traitée par
la transformée de Fourier. Extrêmement utilisé dans le domaine de l’analyse audio,
5. Image adaptée de https://commons.wikimedia.org/wiki/File:Sampled_signal.svg,
sous licence Creative Commons By-Sa 3.0.
12
le spectre sonore ou spectrogramme est couramment exploité comme descripteur
dans les travaux du MIR. La décomposition de fréquences qu’il effectue le rend
très utile pour extraire les fréquences harmoniques.
2.2.2 MFCC
Les coefficients cepstraux en fréquence de Mel, ou MFCC pour Mel Frequency
Cepstral Coefficients, sont des descripteurs psychoacoustiques ; ils permettent une
représentation du son sur la base de la perception auditive humaine (Davis et
Mermelstein, 1980; Moore et Glasberg, 1983). Originellement développé dans le
cadre de la reconnaissance et transcription vocale ; il existe de multiples implé-
mentations du MFCC (Ganchev et al., 2005).
2.2.3 GFCC
Les coefficients cepstraux en fréquences gammatones, ou GFCC pour Gammatone-
Frequency Cepstral Coefficients, sont substantiellement équivalents aux MFCC,
mais utilisent une banque de filtres gammatones calqués sur une échelle de largeurs
de bandes rectangulaires (Shao et al., 2009).
Un filtre gammatone est un filtre linéaire décrit comme une réponse impulsionnelle
étant le produit d’une distribution gamma et d’une tonalité sinusoïdale (Patterson
et al., 1987). Tout comme le MFCC,GFCC est utilisé dans les travaux de
reconnaissance et transcription vocale (Shao et al., 2009).
2.2.4 HPCP
Les profils de classes de hauteur harmonique, HPCP pour Harmonic Pitch Class
Profiles, sont des descripteurs conçus dans le cadre du MIR pour effectuer de la
13
détection d’accords musicaux (Fujishima, 1999). Ce descripteur se révèle parti-
culièrement intéressant pour nos travaux puisqu’il consiste en un prétraitement
extrayant les combinaisons harmoniques présentes dans un signal (Gómez, 2006).
2.3 Classification du genre musical
Les premières applications fonctionnelles de l’apprentissage machine ont été ob-
tenues pour la classification du genre musical d’une piste audio. Tout d’abord,
l’usage de modèles de Markov cachés ayant en vecteur d’entrée les coefficients
cepstraux d’une piste audio permet de distinguer les enregistrements de voix, de
musique, de rires, ainsi que nul de ces trois cas (Kimber et al., 1997). D’autres
méthodes plus avancées, faisant également usage de modèles de Markov cachés,
permettent de détecter en temps réel les variations dans des films ou diffusions
télévisées, les catégorisant en musique, chanson, dialogue avec fond musical, pa-
role simple et environnement sonore quelconque sans harmonie (Zhang et Kuo,
2001). La distinction au sein d’un signal musical des séquences comprenant du
chant et des séquences comprenant de la musique uniquement instrumentale est
aussi réalisable (Berenzweig et Ellis, 2001).
L’extraction de spectre d’un signal audio permet une classification efficace du
genre musical au moyen de modèles de mélange gaussien ou de kplus proches voi-
sins (Tzanetakis et Cook, 2002). Selon le genre à classer, l’exactitude du meilleur
modèle varie entre 61% et 88%. Il faut cependant garder à l’esprit que les genres
musicaux sont subjectifs, et que la classification par des humains dans les travaux
de Tzanetakis et Cook n’excédait guère les 70% d’exactitude.
14
2.4 Détection des instruments
Une autre application de l’apprentissage dans ce domaine, fortement corrélée avec
la classification du genre, est la détection des instruments présents au sein d’une
piste ou d’une section de signal. La présence ou l’absence d’un type d’instrument
étant une information importante dans la détermination du genre, les premiers tra-
vaux dans le domaine en sont issus. À la différence du genre qui est une sonorité
globale commune à différents signaux, la détection d’instruments est sensiblement
plus complexe. Un instrument particulier a de multiples caractéristiques qui lui
sont propres, et qui peuvent même dépendre d’un enregistrement précis, aux
matériaux, à la forme, aux procédés de fabrication, au vieillissement, ainsi qu’au
matériel utilisé pour l’enregistrement, microphone, pièce, environnement et tech-
nique de jeu. Tout ceci sans même parler d’effets sonores ajoutés ultérieurement.
Il est évident, connaissant cela, de devoir disposer d’une grande variété dans les
jeux de données, ce qui augmente d’autant le temps nécessaire pour effectuer
l’apprentissage.
Dans leurs travaux, Barbedo et Tzanetakis font usage du spectre des signaux pour
identifier les harmoniques présentes et relever les inharmonicités. Ils travaillent
alors avec un algorithme d’élection de leur conception se basant sur les fréquences
harmoniques, puis des analyses discriminantes linéaires pour extraire les instru-
ments présents dans la section de signal étudiée. Une fois le signal intégralement
analysé de cette manière, ils considèrent que si un instrument est détecté dans
plus de 5% du signal, celui-ci est effectivement présent (Barbedo et Tzanetakis,
2011).
La méthode qu’ils utilisent s’avère efficace si suffisamment de données d’appren-
tissage sont disponibles. Tout d’abord, le taux de reconnaissance sur la banque de
données d’apprentissage s’élève à 78%, ce qui est déjà bien meilleur que l’humain.
15
Des travaux sur des étudiants au conservatoire montrent que leur taux moyen de
reconnaissance est de 55% (Srinivasan et al., 2002). Ensuite, leur solution dispose
d’une bonne capacité de généralisation, l’apprentissage effectué ayant pu détecter
les instrument dans une autre banque d’enregistrements avec 76% de réussite.
2.5 Transcription automatique de la musique
À l’inverse de la classification du genre ainsi que la détection des instruments, la
transcription automatique de la musique, ou AMT, pour Automatic Music Trans-
cription, est une tâche non triviale qui ne bénéficie à ce jour d’aucune solution
satisfaisante (Kelz et Widmer, 2017).
L’objectif de la transcription polyphonique est de déterminer les notes jouées par
différents instruments au sein d’un signal audio sans avoir accès à la partition
d’origine. Il s’agit justement de reconstituer cette partition par l’écoute, comme
le feraient des humains. Les humains compétents dans ce domaine abordent le
problème en donnant une importance à ce qu’ils s’attendent à entendre, en plus
de ce qui est simplement présent lors de l’écoute. L’humain effectue donc une
tâche d’anticipation.
En usant de RTRBM, pour Recurrent Temporal Restricted Boltzmann Machine,
et de réseaux de neurones récurrents couplés à des RBM, Restricted Boltzmann
Machine, Boulanger-Lewandoski, Bengio et Vincent présentent un moyen de re-
connaître et anticiper des séquences musicales usuelles. Ils ne s’appuient pas sur le
signal sonore mais sur des partitions déjà connues (Boulanger-Lewandowski et al.,
2012). L’intérêt de ces travaux réside dans le tri ou l’orientation musicale qui sont
à rechercher lors de la transcription automatique d’une musique.
Des travaux de Benetos, Ewert et Weyde proposent un modèle d’extraction basé
sur l’analyse probabiliste de composants latents, ou PLCA, pour Probabilistic La-
16
tent Component Analysis, permettant d’effectuer une transcription polyphonique
automatique de la musique occidentale (Benetos et al., 2014). Ce modèle per-
met également d’extraire les percussions présentes. Cependant, les résultats sont
limités, la performance de détection des notes par instrument étant inférieure à
50% lorsqu’appliqué à des échantillons de la base de données MAPS (détaillée en
Section 5.1.2).
Dans leurs travaux, Khlif et Sethu présentent un algorithme basé sur les facto-
risations non-négatives de matrices (Khlif et Sethu, 2015). Ils utilisent en pré-
traitement une transformation à Qconstant sur le spectre audio d’une mélodie
polyphonique de piano. Leur algorithme IMRNMF, pour Iterative Multi Range
Non-Negative Matrix Factorization, permet ainsi d’obtenir des performances si-
gnificativement meilleures qu’un NMF simple, avec une exactitude de 52% contre
38% pour le NMF et un score F1 de 69% contre 55% pour le NMF. La limi-
tation d’application de ces travaux est qu’il faut déterminer empiriquement les
paramètres de leurs algorithmes, ce qui empêche une réutilisation automatique
sur d’autres instruments que le piano, qui est le seul sujet de leur étude.
Au moyen d’une architecture combinant un réseau de neurones récurrent et un
NADE, Neural Autoregressive Density Estimator, il est possible d’établir un mo-
dèle de langage musical basé sur de multiples partitions (Sigtia et al., 2015). Ce
modèle permet ensuite d’effectuer une transcription polyphonique du piano lors-
qu’il est appliqué par un réseau de neurones récurrent ou un réseau de neurones
profond, combinés ou non. Cette méthode donne à son meilleur une exactitude de
53% et un score F1 de 69% sur 200 pistes provenant de la base MAPS (détaillée
en Section 5.1.2).
CHAPITRE III
PROPOSITION D’UN NOUVEL OUTIL : MÉLODIUM
3.1 Nécessité d’un outil
Un problème se pose rapidement lorsque l’on souhaite effectuer de l’analyse sonore
de manière modulaire tel que requis pour ces travaux : il n’existe pas d’outil per-
mettant efficacement l’application de traitements, la gestion de données audio, et
l’intégration d’algorithmes d’apprentissage machine. Certains outils permettent
d’effectuer des tâches bien spécifiques, comme les utilitaires Sox et FFMPEG
pour le traitement de fichiers audio, Audacity6pour les analyses, notamment
spectrales, ou encore divers programmes dont l’utilisation pour ces recherches se-
rait un détournement inconfortable de leur conception. On peut noter l’existence
d’un projet nommé Marsyas 7, dont l’objectif de permettre l’analyse de signal est
similaire aux besoins de nos travaux. Cependant son développement semble inter-
rompu et ses dépendances sont aujourd’hui obsolètes et difficiles à reconstituer.
Quelque soit la qualité, l’avancement du développement, la continuité et l’actua-
lisation de différents outils mentionnés, tous souffrent dans une mesure plus ou
moins grande des inconvénients suivants :
6. Disponible à l’adresse https://www.audacityteam.org/.
7. Disponible à l’adresse https://github.com/marsyas/marsyas.
18
développement ad hoc ;
fragmentation technologique ;
exécution peu ou pas optimisée ;
automatisation restreinte ou impossible.
Pour satisfaire aux besoins de nos recherches, un outil de pré-traitement, analyse,
apprentissage et restitution des données a donc été développé, dans le cadre de ce
mémoire.
Notre outil est baptisé « Mélodium », néologisme formé à partir de
« mélodie », tiré du latin melodia, lui-même issu du grec ancien μελῳδία,
melôidía chant ») composé de
μέλος,mélos arrangement musical »);
et ᾠδή,ôidê chant ») ;
et « medium », intermédiaire.
Un mélodium est donc un intermédiaire entre les mélodies, entre les arrangements
musicaux.
Mélodium dispose de sources et d’une documentation disponibles à l’adresse
https://gitlab.com/qvignaud/Melodium. L’ensemble est prévu pour être com-
pilé de manière conventionnelle sur une machine classique, un fichier de référence
étant fourni à la racine du dépôt pour les informations techniques.
3.2 Tâches spécifiques
Afin d’effectuer tous les traitements nécessaires aux expérimentations, bon nombre
de tâches sont nécessaires. Ces tâches sont pour certaines orientées vers la re-
cherche en restitution d’informations musicales, et d’autres plus générales. Tou-
jours est-il que l’assemblage à effectuer entre elles est spécifique à ce domaine, ce
qui peut complexifier l’usage de certains outils existants non prévus à cet effet.
19
Parmi ces tâches nous pouvons citer :
la modélisation des fichiers MIDI ;
la conversion des multiples formats audio ;
la décomposition de fontes sonores ;
l’intégration de banques d’enregistrements sonores ;
l’analyse et le traitement algorithmique du signal sonore;
la persistance des données extraites et l’échange interopérable (CSV, images) ;
l’interfaçage avec des modèles d’apprentissage machine;
l’apprentissage et l’exploitation des modèles d’apprentissage machine ;
la restitution et compilation des résultats d’apprentissage en données mu-
sicales ;
l’interprétation et l’évaluation des résultats.
3.3 Composants techniques
Le programme est écrit en C++ et repose sur la bibliothèque Qt 8pour disposer
d’un environnement de développement et de la plupart des fonctionnalités conven-
tionnelles n’étant pas propre aux besoins spécifiques de ces recherches. Une des
premières nécessités techniques, manquant à la quasi-totalité des outils évoqués,
est la parallélisation des tâches. Mélodium repose massivement en interne sur les
patrons de conception fabriques et commandes, couplés à un groupe de fils. Cela
requiert une conception de classes conteneures susceptibles d’êtres accédées par
de multiples fils d’exécution en simultané, notamment dans le cadre de flux entre
algorithmes. Ceci est implémenté dans Mélodium essentiellement au moyen de
mutexes et sémaphores, en plus d’un système d’ordonnancement des commandes
voué à éviter des accès concurrents et mises en attente de fils pour accéder aux
8. Documentation à l’adresse https://doc.qt.io/.
20
données.
Pour l’analyse de signaux, Mélodium dispose d’un ensemble d’interfaces permet-
tant l’exploitation transparente de la majorité des algorithmes implémentés dans
la bibliothèque Essentia (Bogdanov et al., 2013), au nombre de 173 au moment
de cette rédaction. Seuls quelques algorithmes spécifiques d’Essentia ne disposent
pas présentement de possibilité d’exploitation au travers de Mélodium, mais il
s’agit d’algorithmes relatifs à l’import et export de données, rendus de facto in-
utiles au sein de ce programme. L’interfaçage avec Essentia est conçu pour prendre
en charge d’éventuels nouveaux algorithmes pouvant être ajoutés ultérieurement,
sans recompilation de Mélodium.
Pour l’exploitation des fichiers MIDI, il est fait usage de QMidi9. Il s’agit d’un
développement connexe visant à fournir un support du MIDI, fichiers comme flux,
intégré à l’environnement Qt. Si une conversion de format audio est nécessaire,
Mélodium s’appuie sur la bibliothèque FFMPEG 10, communément répandue au
sein des systèmes de famille Unix. Cela permet une prise en charge aisée d’un grand
nombre de codecs sans effort de développement majeur, et un coût d’exploitation
mineur au sein du projet, se concentrant exclusivement autour de PCM et Flac
comme formats de travail. encore, la prise en charge de nouveaux formats audio
par FFMPEG ne requiert aucune modification au sein de Mélodium, qui prendra
dès lors ces nouveaux formats en compte de façon transparente.
Concernant l’exploitation d’algorithmes d’apprentissage, la bibliothèque Mlpack (Cur-
tin et al., 2018) est utilisée. Différents types de traitements sont effectués par son
biais, à savoir :
l’instanciation de modèles ;
9. Dépôt Git à l’adresse https://gitlab.com/qvignaud/QMidi.
10. Site du projet à l’adresse https://ffmpeg.org/.
21
l’apprentissage ;
la classification ;
l’évaluation ;
la sauvegarde ;
et l’exploitation productive de ces modèles.
À des fins d’optimisation des données comme des calculs, les bibliothèques OpenMP 11,
Armadillo (Sanderson et Curtin, 2016), et Ensmallen (Bhardwaj et al., 2018; San-
derson et Curtin, 2019), sont exploitées.
Mélodium
Essentia
FFMPEG Qt
QMidi
OpenMP
Mlpack
Armadillo
LAPACK/Intel MKL/OpenBLAS...
FFTW
Ensmallen
Figure 3.1: Graphe de dépendance de Mélodium.
Enfin, pour l’interaction du programme et la visualisation des données, aussi bien
en terminal que graphiquement, les fonctionnalités d’interface utilisateur de Qt
sont utilisées. Raison d’être initiale de cette bibliothèque, elles permettent d’ef-
fectuer tous les rendus visuels, sous différentes formes possibles, dont il y aurait
besoin.
11. Page du projet https://www.openmp.org/.
22
3.4 Architecture
Mélodium s’architecture autour de différents types d’éléments : les pistes, les trai-
tements, les exécutants, les modèles, les préparateurs, et les initialisateurs.
3.4.1 Pistes
Les pistes sont des conteneurs descriptifs des données présentes dans un enregis-
trement. Les données peuvent soit êtres globales, qualifier l’ensemble du signal ;
soit simples, qualifier par une unique valeur, un instant ou trame du signal ; soit
détaillées, associant alors de multiples valeurs à un instant ou trame du signal. Les
qualificateurs simples peuvent être perçus comme des tableaux unidimensionnels,
et les détaillés comme des tableaux bidimentionnels.
Piste
Global
Simple
Détaillé
V aleur
V aleurs
V aleurs2
Figure 3.2: Types de données présentes dans une piste.
Les pistes sont conçues pour gérer des accès concurrents dans un contexte d’exé-
cution multifil, et pour maintenir la cohérence des données par rapport au signal
étudié (notamment en termes de longueur et nombre de trames).
3.4.2 Traitements
Les traitements sont les descripteurs et paramétreurs des opérations qui vont être
appliquées sur des données. Ils jouent différents rôles parmi lesquels :
23
convertisseur ;
rendu audio ;
analyste de signal ;
alimenteur de modèle ;
entraîneur de modèle ;
prédicteur de modèle ;
enregistreur de modèle ;
chargeur de modèle ;
exporteur de données.
Un traitement peut être indépendant de toute piste, être lié à une unique piste, ou
bien opérer sur de multiples pistes. La liste des traitements existants est disponible
en Annexe A. Un traitement configure et supervise l’exécutant qui lui est lié
unitairement.
3.4.3 Exécutants
Les exécutants sont des éléments qui effectuent les opérations. Ils le font chacun
dans un fil d’exécution qui leur est alloué, avec la possibilité d’en instancier de
nouveaux à leur propre charge (au travers d’OpenMP notamment). En cas d’erreur
lors de l’exécution, ils interceptent toute exception ou échec et le signalent à leur
traitement sans faire échouer le programme dans son ensemble, dans le respect
des principes résilience aux erreurs et de sortie grâcieuse.
3.4.4 Modèles
Les modèles sont des éléments qui fournissent divers traitements, dépendamment
de leurs capacités. Ils renferment usuellement un modèle d’apprentissage machine,
bien que ce ne soit pas nécessairement le cas. Les traitements et exécutants mis à
24
disposition peuvent être les alimenteurs, entraîneurs, prédicteurs, enregistreurs et
chargeurs.
Trois modèles sont actuellement disponibles :
ConfigurableRectFfn, pour des réseaux de neurones à propagation avant
à taille constante ;
ConfigurableVarFfn, pour des réseaux de neurones à propagation avant
dont les couches intermédiaires peuvent avoir des tailles variables;
SparseAutoencoder, pour des auto-encodeurs éparses.
3.4.5 Initialisateurs et préparateurs
Les initialisateurs sont les éléments d’entrée du programme. Ils mettent en place
et configurent les pistes, les modèles, et les traitements qui sont utiles à leur tâche.
Pour ce faire, ils s’appuient notamment sur les préparateurs, dont l’objectif est
d’effectuer un tri et une sélection des données et fichiers qui leur sont confiés.
Typiquement, un préparateur gère des fichiers, en extrait les données, et s’assure
de les rendre exploitables au moyen des traitements adéquats, sur lesquels peuvent
être connectés les traitements que l’initialisateur appelant établi. Leur usage est
exposé en section 3.5.2.
Les trois préparateurs actuellement disponibles sont :
AudioFilePreparator, pour le chargement de fichiers de données audio
(impliquant leur conversion vers un format de travail si nécessaire);
MidiFilePreparator, pour le chargement de fichiers de données musicales
MIDI ;
SoundFontPreparator, pour le chargement de données provenant de fontes
sonores.
Les initialisateurs peuvent les utiliser pour appliquer leurs traitements à des don-
25
nées convenablement préparées.
3.4.6 Ordonnanceurs
Une fois les pistes, modèles, et traitements instanciés et configurés, le programme
passe la main à un ordonnanceur. Ce dernier effectue la gestion de l’exécution ma-
croscopique des traitements, leur exécution détaillée étant à la charge de leur exé-
cutants. L’ordonnanceur place un traitement qu’il juge opportun d’effectuer dans
un fil d’exécution disponible. Pour faire cette sélection un ordonnanceur se base
sur les traitements déjà achevés afin de poursuivre la gestion intégrale d’une piste
pour la compléter au plus vite, libérant alors l’espace mémoire qu’elle occuppe.
Ceci dans l’objectif de n’en utiliser qu’une quantité raisonnable, sans sacrifier au
temps d’exécution global. Le nombre de fils d’exécution, et donc de traitements
simultanés, est fixé par l’utilisateur, avec un choix par défaut dépendant de la
machine.
Nous avons actuellement implémenté deux ordonnanceurs :
MonoThreadScheduler, utilisé si un seul fil d’exécution est imposé ou dis-
ponible ;
MultiThreadScheduler, utilisé dans les autres cas.
Notre programme est conçu pour permettre l’implémentation de nouveaux ordon-
nanceurs, notamment pour l’exploitation de MPI 12.
12. Message Passing Interface, norme de communication pour des systèmes de grappes
massivement parallèles à mémoire distribuée, informations et documentation disponibles à
https://www.mpi-forum.org/docs/.
26
3.5 Usage et fonctionnalités
3.5.1 Ligne de commande
Une interaction classique est disponible en ligne de commande, permettant d’exé-
cuter Mélodium ou d’obtenir des informations documentaires.
melodium [options] <initializer> [params]
Les paramètres et commandes les plus utiles sont ici décrits.
--graph, génère un graphe au format GraphViz représentant l’enchaîne-
ment des traitements; les graphes d’exécution de ce mémoire sont générés
par ce moyen.
--threads, assigne le nombre de processus avec lesquels Mélodium doit
composer son ordonnancement, par défaut cela équivaut au nombre de
cœurs existants sur la machine.
--noexec, n’exécute pas les traitements, les initialise seulement, et génère
éventuellement le graphe si demandé ; ceci est utile pour vérifier la cohé-
rence des tâches demandées, avant de lancer la charge de travail réelle sur
une machine tierce par exemple.
--list-{initializers,models,treatments}, liste les éléments disponibles
du type demandé.
--info-{initializers,models,treatments}, affiche la documentation
de l’élément demandé, un exemple est disponible en Annexe B.
3.5.2 Initialisateurs
Le comportement par défaut de Mélodium est de considérer le premier paramètre
textuel non relatif à une option comme l’initialisateur à utiliser. Les éléments
27
d’appel de la ligne de commande apparaissant après le nom de l’initialisateur sont
considérés comme ses options.
Parmi les initialisateurs se trouvent notamment :
midigenerator, permettant la génération de pistes MIDI correspondant
aux besoins requis, paramétré pour les générer avec un contenu déterminé
ou avec des composantes aléatoires;
script, qui va suivre les instructions définies dans un fichier script pour
établir les traitements à exécuter, c’est ce dernier que nous développons
dans le chapitre suivant.
3.6 Performances
L’outil Mélodium est utilisé pour l’intégralité des travaux expérimentaux présen-
tés ici. Il exécute avec succès des expériences manipulant de larges quantités de
données avec accès concurrents. Plus de 1 500 000 traitements sont nécessaires à
certaines expérimentations, qui ont été menées à bien en quelques dizaines d’heures
sur des machines haute performance, comme décrit en Section 5.6. L’Annexe D
donne davantage de renseignements sur les ressources utilisées.
CHAPITRE IV
LANGAGE DE MANIPULATION DE DONNÉES AUDIO ET MUSICALES
Un interpréteur de scripts est présent dans Mélodium. Il vise à simplifier la créa-
tion d’expérimentations sans passer systématiquement par l’implémentation d’un
initialisateur dédié et la recompilation, permettant alors à des utilisateurs sans
connaissance technique approfondie des technologies associées, ni même du fonc-
tionnement interne, d’utiliser le programme.
Le langage utilisé au sein de ces scripts se veut paramétrique plus que program-
matique. Il permet de paramétrer des éléments existants au sein du programme
mais pas d’en créer de nouveaux. Une conséquence de ceci est que l’ordre d’appa-
rition des instructions n’a aucune importance, tant que les blocs sont cohérents.
Ce langage est implicitement parallèle et multipistes (cette notion est abordée en
section 4.7). Les éléments spécifiés dans un script sont tous susceptibles d’être
exécutés parallèlement, sous réserve d’une indépendance entre eux.
La syntaxe est globalement inspirée des langages C et Dot. On retrouve ainsi
des mots-clés précédant les déclarations, des blocs délimités par des accolades, et
des assignations et paramétrages similaires à des appels de fonction. Les éléments
présents dans ce langage sont multiples, sont abordés ici les principaux, ainsi que
quelques règles. Par ordre d’apparition : les paramètres et leurs types, les traite-
ments, les séquences, les connexions, les préparateurs, les modèles, et finalement
29
la notion de multipistes. Divers exemples de scripts fonctionnels sont disponibles
en Annexe C.
4.1 Paramètres et types
Les paramètres existent dans différents contextes pour lesquels les détails seront
fournis au moment opportun. Les paramètres prennent des valeurs de type boo-
léennes, numériques, chaînes de caractères, ou tableaux, et sont généralement nom-
més. Il est à noter qu’il ne s’agit jamais d’une déclaration, mais d’une assignation,
tout paramètre existant implicitement avec une valeur par défaut. La syntaxe d’un
paramètre est :
nom = <valeur>
Selon le type de la valeur, la syntaxe est comme suit :
booléen : « true » ou « false », littéralement ;
startFromZero =true
nombre : nombre réel en notation décimale classique « -1.234 », la décimale
se faisant au point;
duration = 1.35
chaîne de caractères : chaîne de caractères quelconque encadrée de doubles
guillemets droits « "», avec échappement pour les caractères guillemets
«"» et contre-oblique « \» par contre-oblique-guillemets et double-contre-
oblique respectivement « "...\"...\\..." » ;
type ="blackmanharris92"
tableau : l’un des trois types précédents, selon leur syntaxe, séparés par des
virgules « ,», le tout encadrés de crochets « [» et « ]».
30
frequencies =[261.63,277.18,293.66,311.13,329.63]
4.2 Traitements
Les traitements sont déclarés par leur nom suivi de la liste de paramètres qui leur
sont associés, encadrée de parenthèses. L’ordre des paramètres est arbitraire, et
les paramètres non spécifiés sont assignés à leur valeur par défaut. Un traitement
peut soit être déclaré avec le nom de son type, soit porter un nom arbitraire et
avoir son type spécifié avant la liste de paramètres.
// Traitement de type 'Spectrum'avec ses paramètres laissés à défaut.
Spectrum()
// Traitement de type 'Spectrum'avec la taille fixée à 4096.
Spectrum(size=4096)
// Traitement de type 'SpectralPeaks'avec ses paramètres.
SpectralPeaks(sampleRate=44100, orderBy="magnitude")
// Traitement nommé 'Pics'de type 'SpectralPeaks'avec ses paramètres.
Pics(SpectralPeaks, sampleRate=44100, orderBy="magnitude")
4.3 Séquences
Les séquences sont les éléments qui abritent les traitements et les lient. Une sé-
quence définit la tâche qui va être effectuée lors de l’exécution, elle est l’élément
principal du script. Une séquence est déclarée par le mot-clé « sequence », suivi
du nom de la séquence, et de son contenu encadré d’accolades « {/*...*/ }».
31
sequence maSequence {
/* ... */
}
4.4 Connexions
Les connexions sont les éléments qui définissent les liens entre les traitements. Une
connexion indique deux choses : quels sont le traitement antérieur et le traitement
postérieur, et quelle est la donnée éventuellement émise et reçue. La syntaxe de
base est de lier deux traitements par un tiret-chevron-fermant « -> », en détaillant
le nom de la donnée en sortie et en entrée au moyen du point. Ici, la sortie audio
du traitement MonoLoader est connectée à l’entrée signal de FrameCutter :
MonoLoader.audio -> FrameCutter.signal
Il est également possible d’enchaîner les déclarations de connexions en les posi-
tionnant successivement, et spécifier le nom de donnée de sortie et d’entrée en
les séparant d’une virgule. Ici, à la suite de l’exécution de FrameCutter, la sortie
frame est connectée à l’entrée frame de Windowing :
MonoLoader.audio -> FrameCutter.signal,frame -> Windowing.frame
Si plusieurs données doivent être transmises entre deux mêmes traitements, leurs
déclarations sont distinctes. Le nombre de tirets précédant le chevron peut être
arbitraire, afin de faciliter la lecture par alignement et structurer le code.
SpectralPeaks.frequencies -> HPCP.frequencies
SpectralPeaks.magnitudes --> HPCP.magnitudes
32
Dans certains cas spécifiques, il se peut qu’aucune donnée ne soit transmise entre
traitements; on omet alors simplement le nommage de donnée.
Feeder -> Trainer
4.5 Préparateurs
Les préparateurs sont chargés de préparer les données d’entrée à partir des fichiers.
Un préparateur est un élément contenu dans une séquence, qui ne peut en avoir
au plus qu’un. Il est déclaré par le mot-clé « preparator », suivi du nom désiré,
puis du type de préparateur entre parenthèses « (...) », et enfin de son contenu
encadré d’accolades « {/*...*/ }».
preparator audioFiles(AudioFile) {
/* ... */
}
Dans le corps d’un préparateur sont assignés ses différents paramètres, comprenant
au moins sampleRate,frameSize, et hopSize. Ces trois valeurs correspondent
respectivement au taux d’échantillonnage, à la taille des trames, et au décalage
entre trames. Le chemin des répertoires ou fichiers à traiter pour le prépara-
teur sont donnés anonymement, d’après la syntaxe des chaînes de caractères. Le
comportement qu’adopte un préparateur vis-à-vis de ces chemins, ainsi que les
paramètres supplémentaires dont il dispose, sont détaillés dans la documentation
de son type.
33
preparator audioFiles(AudioFile) {
sampleRate = 44100
frameSize = 4096
hopSize = 2048
"/home/quentin/Musique"
"/home/quentin/Bureau/Enregistrements"
}
Les traitements établis par un préparateur sont accessibles dans la séquence. Ils
sont désignés par le nom donné au préparateur, suivi du type du traitement en-
cadré de crochets « [...] ». Leur usage est le même que celui d’un traitement
classique. Ici, la sortie audio du traitement MonoLoader établi par le préparateur
audioFiles est connectée à l’entrée signal de FrameCutter :
audioFiles[MonoLoader].audio -> FrameCutter.signal
Il est également possible de les baptiser spécifiquement comme cela se ferait avec
un traitement instancié explicitement. Ici, le traitement MonoLoader établi par le
préparateur audioFiles est appelé AudioLoader :
AudioLoader(audioFiles[MonoLoader])
AudioLoader.audio -> FrameCutter.signal
Chaque type de préparateur voit les traitements qu’il établi décrits dans sa docu-
mentation.
34
4.6 Modèles
Les modèles sont des entités existant indépendamment des séquences. Un mo-
dèle est déclaré par le mot-clé « model », suivi du nom désiré, puis du type de
modèle entre parenthèses « (...) », et enfin de son contenu encadré d’accolades
«{/*...*/ }». Dans le corps d’un modèle sont assignés ses différents para-
mètres, totalement dépendants du type de modèle.
model reseau(ConfigurableRectFfn) {
layers =["PReLU","PReLU","Sigmoid"]
inputSize = 1200
layersSize = 400
outputSize = 128
}
Tout modèle déclaré rend accessible dans les séquences les types de traitements
qui y sont associés. On instancie un traitement lié à un modèle en utilisant le nom
du modèle suivi du type de traitement encadré de crochets « [...] ».
FFNFeeder(reseau[MlpackModelFeeder])
HPCP.hpcp ----------------------> FFNFeeder.data
MidiAnalyst.midiTrackContent1 --> FFNFeeder.label
L’usage de ces traitements est le même que celui d’un traitement classique, avec
cependant une éventuelle contrainte logique dans l’ordre d’exécution, dépendam-
ment des fonctionnalités du traitement. On alimentera ainsi un modèle avant
d’effectuer son apprentissage, tout comme on le chargera avant de demander des
prédictions.
35
4.7 Multipistes
Les traitements d’un type monopiste (l’essentiel des traitements), bien que spé-
cifiés une seule fois au sein d’un script, sont répliqués pour chaque piste fournie
par le préparateur. Les traitements d’un type multipistes (tel que Evaluator,
qui effectue des évaluations comparatives entre pistes) ou indépendant (tel que
MlpackModelLoader, un chargeur de modèles) ne sont eux instanciés qu’une unique
fois, et leurs connexions sont dupliquées pour chaque traitement monopiste aux-
quels ils sont connectés.
Ainsi, l’exemple suivant, en considérant que le préparateur audioFiles relève
trois fichiers audio, donnera le schéma d’exécution en Figure 4.1 :
AudioLoader(audioFiles[MonoLoader])
FFNFeeder(reseau[MlpackModelFeeder])
FFNTrainer(reseau[MlpackModelTrainer])
AudioLoader.audio -> FrameCutter.signal,frame -> FFNFeeder.data
FFNFeeder -------------------------------------> FFNTrainer
AudioLoader FrameCutter FFNFeeder
FFNTrainerAudioLoader FrameCutter FFNFeeder
AudioLoader FrameCutter FFNFeeder
Figure 4.1: Exemple d’exécution multipistes.
CHAPITRE V
ÉTUDES EMPIRIQUES DE DÉTECTION ET CLASSIFICATION DES
NOTES DE MUSIQUE
5.1 Choix et constitution des jeux de données
Les jeux de données disponibles pour travailler sur l’apprentissage et la transcrip-
tion automatique de la musique sont limités. Ceci est à la difficulté particulière
de disposer à la fois d’enregistrements réels et de données MIDI synchronisées avec
ces premiers. Il existe quelques jeux de données populaires dans la littérature, et
des études font également usage de fontes sonores pour effectuer une génération
automatique de pistes audio synchronisées avec l’information MIDI.
5.1.1 Fonte sonore en jeu monophonique
Pour effectuer un apprentissage monophonique sur de multiples instruments, tel
que présenté en Section 1.1, nous nous basons sur la fonte sonore Fluid rgm &gs,
créée par Frank Wen et Toby Smithe, disponible sous licence MIT 13. Elle comporte
plus de 1 400 échantillons sonores correspondants à plus de 190 instruments. Une
fonte sonore, ou soundfont, est un ensemble d’échantillons audio décrivant un ou
13. Disponibles notamment sous https://packages.debian.org/sid/fluid-soundfont-gm
et https://packages.debian.org/sid/fluid-soundfont-gs.
37
plusieurs instruments. Ces échantillons sont associés à des spécifications de modu-
lation et transformations sonores pour permettre à des synthétiseurs de restituer
les sonorités des instruments contenus dans la fonte.
En raison du grand nombre d’instruments et des ressources nécessaires pour ef-
fectuer un entraînement, un représentant par famille instrumentale a été choisi.
Les caractéristiques sonores étant partagées au sein des familles, on peut émettre
l’hypothèse raisonnable qu’un modèle apprenant avec succès sur un membre d’une
famille avec des paramètres spécifiques est apte à reproduire cet apprentissage sur
les autres membres.
Le Tableau 5.1 expose les instruments sélectionnés ainsi que l’étendue associée.
L’étendue est calquée sur la tessiture propre à chaque instrument, telle qu’échan-
tillonnée dans la fonte sonore d’origine. Bien qu’un synthétiseur MIDI soit tout à
fait capable de générer le jeu de tout instrument à n’importe quelle note, il n’est
pas pertinent de s’intéresser à des sonorités impossibles à produire en réalité.
Rangs Famille Numéro Instrument Tessiture 14
000-007 Pianos 000 Piano à queue 26-108
008-015 Percussions chromatiques 013 Xylophone 54-108
016-023 Orgues 019 Orgue d’église 39-91
024-031 Guitares 024 Guitare classique 40-87
032-039 Basses 032 Basse acoustique 28-48
040-047 Cordes 040 Violon 28-72
048-055 Orchestre 048 Ensemble de cordes 36-43
056-063 Cuivres 057 Trombone 48-84
064-071 Instruments à anches 064 Saxophone soprano 41-84
072-079 Flûtes 075 Flûte de pan 61-90
080-095 Synthétiseurs solos 080 Signal carré 72-93
Tableau 5.1: Instruments sélectionnées pour l’apprentissage monophonique.
14. 26 étant le , 28 le mi, 36 le do, 39 le ], 40 le mi, 41 le fa, 43 le sol, 48 le do, 54
le fa], 61 le do], 72 le do, 84 le do, 87 le ], 90 le fa], 91 le sol, 93 le la, et 108 le do.
38
Les signaux sonores générés sont constitués d’une seconde de chaque note de
l’étendue, espacées d’une seconde de silence. Le temps de jeu d’une seconde permet
de rendre compte des variations sonores de l’instrument, le son comprenant alors
l’attaque comme le maintien de la note. La seconde d’espacement permet d’avoir
le déclin de la note précédente ainsi que du silence bruité et pur.
5.1.2 Échantillons et œuvres en jeu polyphonique
Pour effectuer des apprentissages sur des timbres de piano provenant de différents
instruments, ainsi que des apprentissages en polyphonie, nous faisons usage de la
base de donnée MAPS 15, qui est une base de données d’enregistrements audio
de piano réel et synthétisé synchronisés avec leur transcription en MIDI. Les
enregistrements contiennent des notes isolées et sons monophoniques, des accords
usuels ou alétoires, ainsi que des œuvres complètes. Très utilisée dans la recherche
en transcription automatique de la musique, elle fût établie par Valentin Emiya et
est disponible sous licence Creative Commons By-Nc-Sa par l’institut Télécom
ParisTech en France (Emiya, 2008; Emiya et al., 2010).
Quatre jeux sont constitués depuis cette base :
Isolé : Des notes sont jouées seules, indépendamment les unes des autres.
Ceci constitue un jeu de données similaire à celui généré en 5.1.1.
Aléatoires : Des notes sont jouées simultanément dans des combinaisons
aléatoires, sans considération musicale préalable, avec une polyphonie com-
prise entre deux et sept voix.
Usuels : Des accords usuels sont joués. Ce sont des données comportant
une connaissance intrinsèque des règles musicales.
15. Disponible à l’adresse http://www.tsi.telecom-paristech.fr/aao/2010/07/08/
maps-database-base-de-sons-de-piano-pour-la-transcription-automatique-de-musique/.
39
Musiques : Des œuvres musicales « classiques » sont présentées sous forme
d’enregistrement audio couplé à leur annotation MIDI. Il va de soi qu’une
considération des règles musicales est présente dans ces données, qui sont
aussi susceptibles d’introduire un biais culturel ou stylistique.
Tous ces jeux sont composés en sélectionnant aléatoirement un certain nombre de
fichiers les constituant pour obtenir une durée de signal d’environ une heure (un
fichier unitaire n’étant jamais sectionné). Cette sélection aléatoire est effectuée
indépendamment pour chaque expérimentation.
5.2 Procédures de prétraitement
Disposer des fichiers audio, sonores comme musicaux, est une chose, avoir des
vecteurs d’entrée pertinents pour les modèles d’apprentissage en est une autre.
Beaucoup de travaux reposent sur l’analyse du signal ou de son spectre sans
transformations majeures. Nous avons décidé d’utiliser des descripteurs plus spé-
cifiques.
5.2.1 HPCP
Le HPCP, Section 2.2.4, est ici exploité dans sa forme classique, de telle manière
que les fréquences analysées s’étendent de 40 Hz à 5000 Hz, que la déviation est
estimée par rapport au la440 Hz, et que les huit premières harmoniques soient
considérées. On utilise la fonction cosinus pour la pondération, et nous dimen-
sionnons la sortie à 120, qui est un bon niveau de détail, le HPCP ne produisant
que des vecteurs de taille multiple de 12. Le code fonctionnel est disponible en
Annexe C.1.
40
5.2.2 MFCC & GFCC
En supplément du HPCP, nous expérimentons également les descripteurs MFCC
et GFCC. Le HPCP seul ayant à priori comme faiblesse de ne pas rendre compte
des différentes octaves possibles. Pour MFCC et GFCC nous effectuons un filtrage
préalable du spectre selon les bandes décrites au Tableau 5.2. Chacune des bandes
est dimensionnée à 12, pour chaque note de l’octave, le total des dix bandes des
deux descripteurs faisant 240. Le code fonctionnel est disponible en Annexe C.3.
Fréquence basse Fréquence haute Octave correspondante
15,90 Hz 31,25 Hz -1
31,25 Hz 62,50 Hz 0
62,50 Hz 125,00 Hz 1
125,00 Hz 250,00 Hz 2
250,00 Hz 500,00 Hz 3
500,00 Hz 1 000,00 Hz 4
1 000,00 Hz 2 000,00 Hz 5
2 000,00 Hz 4 000,00 Hz 6
4 000,00 Hz 8 000,00 Hz 7
8 000,00 Hz 16 000,00 Hz 8
Tableau 5.2: Bandes de filtrage de fréquences.
Ce filtrage permet de distinguer chaque octave indépendamment des autres. MFCC
et GFCC étant des descripteurs psychoacoustiques, nous pouvons considérer qu’ils
représentent davantage le son tel que nous le percevons plutôt que tel qu’il est en
termes de physique pure.
5.2.3 Spectre
En plus de tout cela, des expérimentations portant sur la combinaison du HPCP
et du spectre simple sont faites. Un spectre est un grand vecteur d’entrée duquel il
peut être difficile d’extraire l’information. Ces expérimentations nous permettent
41
de nous assurer qu’il n’y a pas de perte majeure d’informations de par les trans-
formations évoquées précédemment, mais également de vérifier si elles sont utiles
ou nécessaires.
5.3 Représentation et paramétrage des données
Qu’il s’agisse du HPCP,MFCC,GFCC, ou du spectre, les procédures de prétrai-
tement requièrent un paramétrage supplémentaire préalable concernant l’échan-
tillonnage et le découpage de trames. Plusieurs valeurs courantes existent dans le
domaine du traitement audio, présentées au Tableau 5.3.
Taux
8 000 Hz
11 025 Hz
16 000 Hz
32 000 Hz
44 100 Hz
48 000 Hz
(a) Taux usuels.
Taille des trames Sauts de trames
128 128 64 32
256 256 128 64
512 512 256 128
1 024 1 024 512 256
2 048 2 048 1 024 512
4 096 4 096 2 048 1 024
(b) Découpages usuels.
Tableau 5.3: Synthèse des possibilités de configuration de lecture et découpage de
signaux.
Les tailles de trames définissent la largeur des sections qui sont extraites du signal.
Chaque taille exprime le nombre de valeurs qui y sont prélevées. La durée du
signal contenu dans une trame est donc proportionnelle au taux d’échantillonage
du signal d’origine.
42
x(t)
t
(a) Taux 3×x.
x(t)
t
Signal représenté
Échantillonnage
(b) Taux 1×x.
Figure 5.1: Variations d’échantillonnage d’un signal de même durée.
Les sauts de trame correspondent au décalage entre le début d’une trame et le
début de la trame suivante ; par nature il doit être strictement positif et inférieur
ou égal à la taille de trame.
x(t)
t
(a) Taille de trame et dimension de saut
égales.
x(t)
t
(b) Saut inférieur de moitié à la taille de
trame.
Figure 5.2: Variation de découpage et sauts de trames 16.
Ces paramètres sont importants car ils peuvent significativement changer la re-
présentation que les données auront lors de leur utilisation en vecteur d’entrée.
16. Découpage par taille de trame 4 et saut de 4 sur 5.2a ; et taille de trame 4 avec saut de 2
sur 5.2b.
43
(a) Échantillonage 16000 Hz, trames de 256, et sauts de 256.
(b) Échantillonage 44100 Hz, trames de 2 048, et sauts de 1 024.
Figure 5.3: Variations de la représentation par le descripteur HPCP d’un même
signal selon le paramétrage de lecture et découpage.
Concernant les vecteurs obtenus, il est nécessaire de les cumuler. Un instant mu-
sical est défini par sa trame instantanée ainsi que par celles la précédant. Le cas
contraire reviendrait à donner la dernière syllabe d’un mot et vouloir en obtenir
le sens.
Nous avons déterminé au moyen d’expérimentations préalables que l’accumulation
de 10 trames est viable. Davantage complexifie l’interprétation du vecteur d’entrée,
et moins ne permet pas aux algorithmes d’extraire les classes recherchées. De
même, il ressort que les paramètres de prétraitement les plus satisfaisants sont un
taux d’échantillonage de 44100 Hz, une taille de trame à 4 096, et un saut entre
trames de 2 048.
5.4 Constitution des architectures
Nous avons constitué quatre types principaux d’architectures de réseaux de neu-
rones, évoluant depuis une base commune (Figure 5.4) :
(a) des réseaux de neurones pleinement connectés à propagation avant à taille
44
constante ;
(b) des réseaux de neurones pleinement connectés à propagation avant à taille
décroissante ;
(c) des auto-encodeurs éparses suivis de réseaux de neurones pleinement connec-
tés à propagation avant à taille constante;
(d) des auto-encodeurs éparses suivis de réseaux de neurones pleinement connec-
tés à propagation avant à taille décroissante.
(a) Const
(b) D´ec
(c) SaC onst
(d) SaD ´ec
Figure 5.4: Types d’architectures d’expérimentations.
La taille de la couche d’entrée de toute expérimentation dépend des descripteurs
utilisés. Les dimensions et configurations des auto-encodeurs et couches intermé-
diaires dépendent du type d’architecture et de l’expérimentation effectuée. Tous
les réseaux de neurones à propagation avant décrits ici exploitent l’unité linéaire
rectifiée paramétrique comme fonction d’activation (Parametric Rectified Linear
Unit, PReLU). À l’extrémité finale s’ajoute une couche supplémentaire de même
taille que la pénultième, reposant sur la fonction sigmoïde. La couche de sortie
est systématiquement de taille 128, pour chacune des possibilités du MIDI. Cette
constance est appliquée dans le soucis d’établir une méthode générique pour tout
45
instrument, même si aucun instrument n’a de tessiture comportant ces 128 notes.
Tel que présenté par la Figure 5.5, les architectures à taille constante (a) sont
constituées de Ncouches de taille Tfixe pleinement connectées. Les architectures
à taille décroissante (b) sont constituées de Ncouches pleinement connectées
dont la taille TNdécroît en proportion propre à chaque expérimentation. Les
architectures comportant un auto-encodeur (c) et (d) utilisent un auto-encodeur
éparse (Sparse Autoencoder, SA) ayant TEcomme taille de la couche d’entrée, et
TIcomme taille de couche intermédiaire.
0
1
2
T3
T2
T1
0
1
2
T3
T2
T1
0
1
2
T3
T2
T1
0
1
126
127
N
T
PReLU Sigmoïde
(a) Taille constante.
Figure 5.5: Schéma des architectures.
46
0
1
126
127
Na
Ta
0
1
2
Ta3
Ta2
Ta1
TbTc
Nc
PReLU Sigmoïde
0
1
2
Ta3
Ta2
Ta1
0
Tb2
Tb1
1
0
Tb2
Tb1
1
Tc1
0
Nb
(b) Taille décroissante.
0
1
2
T3
T2
T1
0
1
2
T3
T2
T1
0
1
2
T3
T2
T1
0
1
126
127
N
T
PReLU Sigmoïde
0
1
2
TE3
TE2
TE1
0
TI2
TI1
1
SA
TETI
(c) Auto-encodeur et taille constante.
Figure 5.5: Schéma des architectures (cont.)
47
0
1
126
127
Na
0
1
2
Ta3
Ta2
Ta1
TbTc
Nc
PReLU Sigmoïde
0
1
2
Ta3
Ta2
Ta1
0
Tb2
Tb1
1
0
Tb2
Tb1
1
Tc1
0
Nb
0
1
2
TE3
TE2
TE1
0
TI2
TI1
1
SA
TETITa
(d) Auto-encodeur et taille décroissante.
Figure 5.5: Schéma des architectures (cont.)
5.5 Modèles expérimentaux
Comme décrit en section 5.2, nous utilisons comme descripteurs soit HPCP seul,
noté H ; soit HPCP,MFCC, et GFCC combinés, noté HMG ; soit HPCP et le
spectre combinés, noté HS. En nous basant sur les architectures montrées précé-
demment, nous avons établi cinquante modèles expérimentaux, incluant les varia-
tions, afin de résoudre notre problématique de détection des notes. À ces modèles
expérimentaux sont appliqués distinctement les quinze jeux de données décrits en
section 5.1, ce qui nous porte à un total de sept-cent-cinquante expérimentations.
L’objectif est non seulement de déterminer une architecture efficace selon le niveau
de détection souhaité, mais également d’effectuer un comparatif des performances
et compromis raisonnables. Nous voulons aussi mettre en évidence des affinités
entre certaines architectures et des instruments et cas applicatifs.
48
HConst10
10×1200
HConst30
30×1200
HConst10
10×400
HConst50
50×1200
HConst50
50×400
HConst30
30×400
HSaConst50
1200400
50×400
HSaConst30
1200400
30×400
HSaConst10
1200400
10×400
HD´ec10
1×1200
2×400
7×200
HD´ec10
3×2400
7×1200
HSaD ´ec10
1200400
3×2400
7×1200
HD´ec30
10×2400
20×1200
HSaD ´ec10
1200400
3×400
7×200
HSaD ´ec30
1200400
10×2400
20×1200
HSaD ´ec30
1200400
10×400
20×200
HD´ec30
3×1200
7×400
20×200
Figure 5.6: Hiérarchie des modèles expérimentaux H et partage de propriétés.
Les modèles expérimentaux sont détaillés dans la Figure 5.6 pour le descripteur
H, la Figure 5.7 pour les descripteurs HS, et la Figure 5.8 pour les descripteurs
HMG. La notation EIdécrit les auto-encodeurs, et N×Tles nombres de
couches et tailles associées, par ordre de progression descendant (la couche de
sortie systématique de taille 128 est omise).
Nous établissons des modèles expérimentaux les réseaux sont dimensionnés à
10, 30, et 50 couches; taillés sur une largeur égale à leur vecteur d’entrée, ou
contraints à des tailles inférieures. Les architectures en décroissance sont établies
avec plusieurs degrés de contraintes de taille. Les auto-encodeurs éparses sont en-
traînés pour reproduire leur vecteur d’entrée, avec comme valeur de régularisation
L2λ= 0,0001 ; de divergence KL β = 3 ; et densité ρ= 0,01. Les auto-encodeurs
49
HSConst10
10×9690
HSConst30
30×9690
HSConst10
10×400
HSConst50
50×9690
HSConst50
50×400
HSConst30
30×400
HSD´ec10
1×21690
1×9690
1×3230
1×1600
1×800
2×400
3×200
HSD´ec10
3×19380
7×9690
HSSaD ´ec10
216903230
3×19380
7×9690
HSD´ec30
10×19380
20×9690
HSSaD ´ec10
216903230
1×3230
2×1600
2×800
2×400
3×200
HSSaD ´ec30
216903230
10×19380
20×9690
HSSaD ´ec30
216903230
3×3230
6×1600
6×800
6×400
9×200
HSD´ec30
3×21690
3×9690
3×3230
3×1600
3×800
6×400
9×200
Figure 5.7: Hiérarchie des modèles expérimentaux HS et partage de propriétés.
éparses sont chaînés à des réseaux également évalués distinctement et solitaire-
ment par d’autres expérimentations, pour faire un comparatif. Enfin, pour HMG
(Figure 5.8), en plus d’un auto-encodeur prenant l’intégralité du vecteur d’entrée,
nous combinons trois auto-encodeurs en parallèle correspondant distinctement à
un des trois descripteurs (3Sa).
50
HMGConst10
10×3600
HMGConst30
30×3600
HMGConst10
10×400
HMGConst50
50×3600
HMGConst50
50×400
HMGConst30
30×400
HMG3SaConst50
3(1200400)
50×1200
HMG3SaConst30
3(1200400)
30×1200
HMG3SaConst10
3(1200400)
10×1200
HMGD´ec10
1×3600
1×1200
2×800
3×400
3×200
HMGD´ec10
3×7200
7×3600
HMGSaD ´ec10
36001200
3×7200
7×3600
HMGD´ec30
10×7200
20×3600
HMGSaD ´ec10
36001200
1×1200
2×800
3×400
4×200
HMGSaD ´ec30
10×7200
20×3600
HMG3SaD ´ec10
3(1200400)
1×1200
2×800
3×400
4×200
HMGSaD ´ec30
36001200
3×1200
6×800
9×400
12×200
HMG3SaD ´ec30
3(1200400)
3×1200
6×800
9×400
12×200
HMGD´ec30
3×3600
3×1200
6×800
9×400
9×200
Figure 5.8: Hiérarchie des modèles expérimentaux HMG et partage de propriétés.
5.6 Évaluation et exécution
Évoluant dans un problème de classification à labels multiples (un par note),
l’évaluation repose essentiellement sur le score F1 englobant tous les labels-notes.
Nous effectuons aussi une évaluation binaire relative à chaque note afin de s’assurer
qu’une expérimentation ne souffre pas d’une déficience localisée à certaines parties
de la tessiture, et qui pourrait être masquée dans le score global. Une évaluation
51
est réalisée à chaque fin d’époque d’apprentissage.
Les expérimentations sont exécutées grâce à Calcul Québec 17 et Calcul Canada 18,
sur le calculateur Béluga de l’École de Technologie Supérieure 19 (ÉTS). Chaque
roulement est effectué sur quatre cœurs de processeur Intel Gold 6148 Skylake
cadencés à 2,40 GHz. Les durées d’exécution varient de quelques heures à sept
jours, la mémoire de moins de 4 Go à 100 Go. Les ressources nécessaires aux
différentes expérimentations, fortement corrélées à la taille du jeu de donnée ex-
ploité, sont détaillées en Annexe D. En tout et pour tout, un peu plus de 17 To
d’enregistrement de données ont été requis, en comptant les jeux de données, les
configurations, et les résultats d’évaluation.
17. Site officiel à https://www.calculquebec.ca/
18. Site officiel à https://www.calculcanada.ca/
19. Site officiel à https://www.etsmtl.ca/
CHAPITRE VI
RÉSULTATS ET ANALYSES DU COMPORTEMENT DES
ARCHITECTURES ET MODÈLES D’APPRENTISSAGE MACHINE
Nos analyses montrent des résultats très hétérogènes parmi les expérimentations
effectuées. Certaines sont en échec plat lorsque d’autres exposent un fort potentiel.
6.1 Échecs d’apprentissage
De tous les résultats expérimentaux, nous extrayons d’abord deux constats d’échecs
d’apprentissage. Le premier porte sur les expérimentations reposant sur le spectre
(HS), le second sur les architectures à taille décroissante (D´ec), qu’elles impliquent
ou non un auto-encodeur.
Le premier cas étaye notre postulat initial concernant la difficulté d’extraction
de l’information du spectre, même lorsqu’il est combiné au HPCP. Les auto-
encodeurs ne réussissent pas non plus à modéliser le spectre. Les architectures et
dimensions appliquées dans nos expérimentations sont ainsi inadéquates à l’ex-
ploitation du descripteur spectral.
Le second cas tend à montrer l’inadéquation d’un réseau en décroissance à l’ex-
traction de notes depuis chacun des descripteurs utilisés. L’explication plausible
est que les descripteurs sont résolus tardivement dans les couches intermédiaires,
53
donc que la réduction de leur taille depuis l’amont n’est pas souhaitable.
6.2 Architectures fructueuses
Les expérimentations H et HMG montrent des résultats bien plus intéressants.
Tout d’abord, les réseaux de dimension 10 à taille constante (Const10) par-
viennent dans l’ensemble à effectuer un apprentissage sur ces descripteurs dans
un cadre monophonique mono-instrumental, à savoir sur les jeux issus de Fluid
rgm (sous-section 5.1.1) et le jeu Isolé de MAPS (sous-section 5.1.2).
0
0.2
0.4
0.6
0.8
1
0 30 60 90 120 150 180 210 240 270 300
Score F1
Époque
Score F1 par époque
(a) HMGConst10
10 ×3600
0
0.2
0.4
0.6
0.8
1
0 30 60 90 120 150 180 210 240 270 300
Score F1
Époque
Score F1 par époque
(b) HMGConst10
10 ×400
Figure 6.1: Apprentissage monophonique sur l’instrument 013 Xylophone.
Ensuite, on constate une atténuation significative du sur-apprentissage lorsque le
réseau est contraint à une taille inférieure au vecteur d’entrée, comme illustré en
Figure 6.1. On peut également constater en Figure 6.2 les variations d’appren-
tissage entre les différentes notes de la tessiture. Ces analyses rendent comptent
du déclin constaté en Figure 6.1a entre les époques no (Figure 6.2a) et no
54
(Figure 6.2b). Nous constatons également qu’un bon score global peut masquer
des lacunes localisées à certaines notes (Figure 6.2c), même si le jeu de données
contient chaque note de façon équivalente (sous-section 5.1.1). De même, il n’y a
pas de changement significatif dans le score individuel des labels attribués au fil
des époques (Figure 6.2d).
55
Score F1
Numéro de note
Score F1 par note
0
0.2
0.4
0.6
0.8
1
0 12 24 36 48 60 72 84 96 108 120
(a) HMGConst10
10 ×3600
Époque no
Score F1
Numéro de note
Score F1 par note
0
0.2
0.4
0.6
0.8
1
0 12 24 36 48 60 72 84 96 108 120
(b) HMGConst10
10 ×3600
Époque no
Score F1
Numéro de note
Score F1 par note
0
0.2
0.4
0.6
0.8
1
0 12 24 36 48 60 72 84 96 108 120
(c) HMGConst10
10 ×400
Époque no
0
30
60
90
120
150
180
210
240
270
300
0
12
24
36
48
60
72
84
96
108
120
0
0.2
0.4
0.6
0.8
1
Score F1 par note par époque
Époque
Numéro de note
Score F1
0
0.2
0.4
0.6
0.8
1
(d) HMGConst10
10 ×400
Séquence totale
Figure 6.2: Détail d’époques d’apprentissage monophonique sur l’instrument 013
Xylophone.
56
6.3 Succès des auto-encodeurs
L’usage d’auto-encodeur se révèle extrêmement efficace et améliore drastiquement
les performances d’apprentissage avec le descripteur HPCP. Ainsi, dans un cadre
monophonique mono-instrumental, HSaConst10(1200 400; 10 ×400) est en
capacité d’apprentissage générique sur la majorité des instruments. Le détail des
résultats est disponible en Annexe E.1.
Numéro Instrument Score F1
000 Piano à queue 0,99
013 Xylophone 0,95
019 Orgue d’église 0,00
024 Guitare classique 0,97
032 Basse acoustique 0,99
040 Violon 0,98
048 Ensemble de cordes acoustiques 1,00
057 Trombone 0,98
064 Saxophone soprano 0,99
075 Flûte de pan 0,99
080 Signal carré 1,00
Tableau 6.1: Scores d’apprentissage monophonique mono-instrumental du modèle
HSaC onst10(1200 400; 10 ×400) à l’époque no.
Les scores exposés au Tableau 6.1 montrent de très bons résultats d’apprentis-
sage. Ces scores ne signifient pas un sur-apprentissage du modèle, car dans un
cadre monophonique mono-instrumental, le descripteur HPCP est proche d’être
déterministe en fonction de la note jouée. Le modèle est alors capable d’effec-
tuer l’analyse des classes harmoniques de façon très performante. La Figure E.2
disponible en annexe expose le détail des scores de chaque note à l’époque no.
Nous remarquons que les instruments 048 Ensemble de cordes acoustiques et 080
Signal carré sont au score 1. Cela s’explique pour le premier par la faible étendue
57
de sa tessiture (36 à 43, soit doà sol), Figure 6.3 ; et pour le second par le
caractère « synthétique » de son timbre, qui est totalement déterministe, Figure
6.4. Les tessitures sont spécifiées au Tableau 5.1.
0
0.2
0.4
0.6
0.8
1
0 100 200 300 400 500 600 700 800 900 1000
Score F1
Époque
Score F1 par époque
(a) HSaC onst10
1200 400
10 ×400
Global
Score F1
Numéro de note
Score F1 par note
0
0.2
0.4
0.6
0.8
1
0 12 24 36 48 60 72 84 96 108 120
(b) HSaC onst10
1200 400
10 ×400
Époque no
Figure 6.3: Apprentissage monophonique sur l’instrument 048 Ensemble de cordes
acoustiques.
Aussi, un échec d’apprentissage pour HSaConst10(1200 400; 10 ×400) est
à relever concernant l’instrument 019 Orgue d’église, Figure 6.5a. L’explication
est qu’un orgue ne peut pas strictement correspondre au cadre monophonique
mono-instrumental, puisque chaque tuyau qui le compose a un timbre propre. Un
orgue s’assimile ainsi davantage à un cas monophonique multi-instrumental. De
façon plus globale, aucune architecture contenant un auto-encodeur n’est parvenue
à apprendre sur cet instrument. Les expérimentations HMGConst10(10 ×400)
et HConst10(10 ×400), qui n’ont pas d’auto-encodeurs, montrent une difficulté
particulière d’apprentissage de cet instrument, comme illustré en Figures 6.5b et
6.5c.
58
0
0.2
0.4
0.6
0.8
1
0 100 200 300 400 500 600 700 800 900 1000
Score F1
Époque
Score F1 par époque
(a) HSaC onst10
1200 400
10 ×400
Global
Score F1
Numéro de note
Score F1 par note
0
0.2
0.4
0.6
0.8
1
0 12 24 36 48 60 72 84 96 108 120
(b) HSaC onst10
1200 400
10 ×400
Époque no
Figure 6.4: Apprentissage monophonique sur l’instrument 080 Signal carré.
6.4 Apprentissage polyphonique
Nous constatons une capacité d’apprentissage de HSaConst10(1200 400; 10 ×
400) dans un cadre polyphonique mono-instrumental. Sur le jeu Musiques de
MAPS un score F1 allant jusqu’à 0,85 est relevé, illustré en Figure 6.6a. Si l’ap-
prentissage est davantage variable au fil des époques qu’en situation monopho-
nique mono-instrumental (Figure 6.6b), on remarque que le modèle ne varie pas
significativement en performance sur des notes précises lorsque l’on sélectionne
des époques ayant de bons scores, comme entre l’époque no (Figure 6.6c) de
score 0,84, et l’époque no (Figure 6.6d) de score 0,85. La forme en cloche que
prend le détail d’apprentissage des différentes notes est à la distribution du jeu
de données Musiques, contenant davantage de notes des octaves 2 et 3 (48 à 72),
autour desquels sont composées la plupart des œuvres au piano classiques.
59
0
0.2
0.4
0.6
0.8
1
0 100 200 300 400 500 600 700 800 900 1000
Score F1
Époque
Score F1 par époque
(a) HSaC onst10
1200 400
10 ×400
0
0.2
0.4
0.6
0.8
1
0 100 200 300 400 500 600 700 800 900 1000
Score F1
Époque
Score F1 par époque
(b) HConst10
10 ×400
0
0.2
0.4
0.6
0.8
1
0 50 100 150 200 250 300 350
Score F1
Époque
Score F1 par époque
(c) HMGConst10
10 ×400
Figure 6.5: Apprentissage monophonique sur l’instrument 019 Orgue d’église.
60
0
0.2
0.4
0.6
0.8
1
0 30 60 90 120 150 180 210 240
Score F1
Époque
Score F1 par époque
(a) HSaC onst10
1200 400
10 ×400
Global
0
30
60
90
120
150
180
210
240
0
12
24
36
48
60
72
84
96
108
120
0
0.2
0.4
0.6
0.8
1
Score F1 par note par époque
Époque
Numéro de note
Score F1
0
0.2
0.4
0.6
0.8
1
(b) HSaC onst10
1200 400
10 ×400
Séquence totale
Score F1
Numéro de note
Score F1 par note
0
0.2
0.4
0.6
0.8
1
0 12 24 36 48 60 72 84 96 108 120
(c) HSaC onst10
1200 400
10 ×400
Époque no
Score F1
Numéro de note
Score F1 par note
0
0.2
0.4
0.6
0.8
1
0 12 24 36 48 60 72 84 96 108 120
(d) HSaC onst10
1200 400
10 ×400
Époque no
Figure 6.6: Apprentissage polyphonique sur le jeu Musiques.
CHAPITRE VII
PROTOCOLE DE CRÉATION DE MODÈLE DE TRANSCRIPTION
MONOPHONIQUE MONO-INSTRUMENTAL
Nous proposons dans ce chapitre un protocole permettant pour un instrument
donné d’obtenir un modèle de transcription automatique de la musique dans un
cadre monophonique mono-instrumental. Ce protocole se découpe en quatre par-
ties : (1) la sélection ou l’établissement des données requises; (2) le traitement
audio préalable et l’application de descripteur de signal ; (3) l’architecture du
modèle de classification ; et enfin (4) son entraînement. Ce protocole est une gé-
néralisation de l’expérimentation HSaC onst examinée en Section 6.3.
7.1 Données requises
Un instrument est préalablement choisi, pour lequel il est nécessaire de disposer
d’au moins un enregistrement de chaque note de la tessiture. Il est possible d’accu-
muler des enregistrements provenant de différents instruments physiques du même
type, ou bien d’une même famille instrumentale, afin de construire un modèle en
capacité de reconnaître une plus grande diversité de timbres. Ces enregistrements
doivent comporter :
un silence préalable au jeu de chaque note, même minime, afin de capturer
l’attaque en intégralité ;
62
comporter la phase d’attaque, de maintien, et de déclin, s’il y a lieu ;
poursuivre sur un silence équivalent au temps la note est musicalement
considérée comme jouée, ou d’au moins une seconde après que le seuil
d’audition soit passé.
À chaque enregistrement doit être couplé l’information musicale de jeu synchro-
nisée. Soit on dispose d’une base de données comportant les échantillons sonores
couplés à l’information musicale, tel que MAPS pour le piano ; soit on en consti-
tue une par l’enregistrement physique sonore et musical du jeu de l’instrument
sélectionné. On peut également faire usage d’une fonte sonore et d’un synthéti-
seur, pour lequel on aura préparé une piste MIDI permettant de correspondre aux
critères évoqués ici.
7.2 Traitement audio
Afin de préparer les données audio et d’en extraire le descripteur HPCP, une
séquence de prétraitement doit être appliquée aux enregistrements. La Figure 7.1
synthétise les informations de paramétrage, les spécifications précises d’implémen-
tation avec Mélodium sont disponibles en annexe C.4.
Le traitement audio à effectuer sur les enregistrements est tel que :
1. le chargement des fichiers est effectué en monocanal 44 100 Hz ;
2. le découpage de trames audio est effectué avec :
une taille de trame de 4 096 ;
un saut de trame de 2 048 ;
3. le fenêtrage est effectué avec une fenêtre de Blackman-Harris 92 dB ;
4. le spectre est calculé ;
5. les pics spectraux sont extraits avec :
une fréquence minimale de 40 Hz ;
63
une fréquence maximale de 5 000 Hz ;
un ordonnancement par magnitude;
6. le HPCP est calculé avec :
une considération des 8 premières harmoniques ;
une fréquence de référence fixée au la440 Hz ;
une pondération par cosinus ;
une sortie normalisée, et dimensionnée à 120 ;
7. une accumulation de chaque trame avec les 9 précédentes, soit un cumul
total de 10.
MonoLoader
downmix :’mix’
filename :’sample.flac’
sampleRate :44100
FrameCutter
frameSize :4096
hopSize :2048
lastFrameToEndOfFile :true
startFromZero :true
validFrameThresholdRatio :0
Windowing
normalized :true
size :4096
type :’blackmanharris92’
zeroPadding :0
zeroPhase :true
Spectrum
size :4096
SpectralPeaks
magnitudeThreshold :1e-05
maxFrequency :5000
maxPeaks :10000
minFrequency :40
orderBy :’magnitude’
sampleRate :44100
HPCP
bandPreset :true
harmonics :8
maxFrequency :5000
maxShifted :false
minFrequency :40
nonLinear :false
normalized :true
referenceFrequency :440
sampleRate :44100
size :120
splitFrequency :500
weightType :’cosine’
windowSize :0.5
Accumulator
cumulation :9
Figure 7.1: Prétraitements pour la transcription monophonique.
7.3 Architecture
Le modèle d’apprentissage machine correspond strictement à celui utilisé pour
l’expérimentation HSaC onst10(1200 400; 10 ×400) décrite au Chapitre 5. Son
architecture, illustrée en Figure 7.2, se décrit ainsi :
64
1. un auto-encodeur éparse paramétré tel qu’ayant :
une taille de la couche visible à 1200 ;
une taille de la couche intermédiaire à 400.
2. un réseau de neurones à propagation avant pleinement connecté paramétré
tel que :
il dispose de 10 couches intermédiaires;
chaque couche intermédiaire est dimensionnée à 400 neurones ;
les neurones des couches intermédiaires reposent sur la fonction d’acti-
vation PReLU ;
la couche de sortie est dimensionnée à 128 neurones;
les neurones de la couche de sortie reposent sur la fonction sigmoïde.
0
1
2
397
398
399
0
1
2
397
398
399
0
1
2
397
398
399
0
1
126
127
10
400
PReLU Sigmoïde
0
1
2
1197
1198
1199
0
398
399
1
SA
1200 400
Figure 7.2: Architecture du modèle de transcription automatique monophonique.
7.4 Apprentissage
L’auto-encodeur est préalablement entraîné sur l’ensemble des enregistrements
traités tel que décrit en section 7.2, de manière à reproduire le plus fidèlement
65
les données en entrée; avec comme valeur de régularisation L2λ= 0,0001, de
divergence KL β = 3, et densité ρ= 0,01. Le réseau de neurones à propagation
avant est ensuite entraîné sur les données de sortie de l’auto-encodeur, avec comme
table de vérité les annotations musicales d’origine du signal donné présentement
à l’auto-encodeur. Une cinquantaine d’époques d’apprentissage sont nécessaires
pour l’obtention d’un modèle fonctionnel.
Un tel modèle est alors capable d’effectuer une transcription automatique de la
musique dans un cadre monophonique pour l’instrument sélectionné, avec un score
F1 supposé dépasser 0,9. Il est à noter que l’on peut utiliser cette même démarche
en utilisant non pas des données monophoniques mais polyphoniques pour parve-
nir à un modèle de transcription automatique polyphonique. Cependant, le score
F1 pourrait ne pas être aussi bon, ou bien le nombre d’époques nécessaires diffé-
rer pour obtenir un apprentissage satisfaisant. L’état actuel de nos recherches ne
permet pas de garantir le succès de ce modèle pour le cadre polyphonique dans
un cas autre que celui du piano.
CONCLUSION
Dans ces travaux, nous avons présen les tenants et des aboutissants du domaine
de la transcription automatique de la musique. Nous avons proposé une échelle de
progression dans la complexité du problème auquel nous avons affaire. Composée
de cinq niveaux, elle permet de classer les travaux existants, et de repérer à quel
niveau d’avancement un modèle se situe.
Ayant constaté le manque d’outillage dédié à ce champ de recherche, nous avons
créé un logiciel nommé Mélodium, couplé à un langage de script permettant de
l’exploiter. Ce logiciel a été conçu en ayant comme objet le traitement automatique
et efficace de longs vecteurs de données représentant des signaux audio et des
données musicales, avec une forte résilience aux erreurs. Le langage associé vise
à faciliter la manipulation des données et la réalisation d’expérimentations, en se
concentrant sur les traitements mis à disposition par notre logiciel, sans requérir
de l’utilisateur une connaissance technique poussée.
En nous appuyant sur les travaux existants, et en combinant des approches cog-
nitives et d’apprentissage machine, nous avons mené à bien diverses expérimenta-
tions au moyen de l’outil nouv