--- title: "Comment construire un corpus audio pour la recherche musicale" slug: construir-corpus-audio.fr kind: guide summary: "Un corpus audio n'est pas une playlist : c'est une collection structurée, étiquetée et reproductible. Ce qu'il faut pour qu'il soit réellement utile en recherche MIR, et comment commencer avec des outils accessibles." publishedAt: 2026-06-22 updatedAt: 2026-06-22 --- import { Image } from "astro:assets"; import infografiaCorpus from "../../assets/blog/posts/infografias/infografia-corpus-audio.jpg"; Un corpus audio n'est pas une playlist. Une playlist est une séquence d'écoute ; un corpus est une collection avec une structure, des étiquettes et des conditions d'enregistrement documentées qui permettent de reproduire une expérience. Cette différence compte, parce qu'un système de **MIR** (Music Information Retrieval) — qu'il s'agisse de transcription, de détection de tonalité ou de classification d'instruments — ne vaut que ce que valent les données sur lesquelles on l'entraîne ou on l'évalue. J'explique ici comment monter un corpus de zéro avec des outils accessibles, et quelles décisions séparent un dossier de fichiers d'une ressource qu'une autre personne peut réellement réutiliser.
Infographie du pipeline d'un corpus audio : de la partition à la numérisation, à l'audio (forme d'onde et spectrogramme), à l'annotation par métadonnées, jusqu'au corpus structuré. L'exemple utilise un enregistrement de Beethoven du domaine public. Les libellés de la figure sont en espagnol.
Le parcours complet d'un corpus audio, de la partition à la donnée structurée. L'exemple —la Sonate nº 14 de Beethoven dans un enregistrement historique du domaine public (Schnabel, 1932)— montre comment chaque enregistrement est accompagné de métadonnées qui le rendent filtrable, comparable et reproductible.
## Ce qui définit un corpus (et ce qui le distingue d'une collection) Trois propriétés distinguent un corpus d'un dossier rempli de fichiers WAV : - **Structure** : les fichiers sont organisés selon un critère explicite. Que ce critère soit l'instrument, l'interprète, le contexte d'enregistrement ou la tâche d'analyse importe peu — ce qui compte, c'est qu'il soit énoncé et appliqué de façon cohérente. - **Étiquettes** : chaque fichier est accompagné de métadonnées décrivant son contenu. Sans étiquettes, un corpus ne peut servir ni de données d'entraînement ni de référence pour l'évaluation. - **Reproductibilité** : quelqu'un d'autre doit pouvoir utiliser le corpus et obtenir les mêmes résultats. Cela implique de documenter comment chaque enregistrement a été réalisé, avec quel matériel et dans quelles conditions. Si l'une des trois manque, on a du matériel, pas un corpus. ## Matériel minimal viable Il ne faut pas un studio d'enregistrement. Il faut le contrôle du bruit. Le minimum qui fonctionne : - **Un microphone à condensateur d'entrée de gamme** (ou, à défaut, un smartphone récent enregistrant en WAV 44,1 kHz / 16 bits, sans compression). La qualité de la capsule compte plus que la marque de l'interface. - **Un enregistreur de terrain** — du type H4n — si l'on enregistre hors studio ou en contexte de concert. L'enregistrement sur carte SD évite la latence USB et le bruit du ventilateur d'ordinateur. - **Un espace calme et contrôlé** : une pièce sans réverbération artificielle notable, sans ventilation audible, sans bruit de fond de circulation. Le bruit qui entre dans l'enregistrement ne peut pas être entièrement retiré en post-traitement. La règle pratique : enregistrer en WAV non compressé dès le début. Le MP3 supprime des informations dont on peut avoir besoin pour l'analyse spectrale. ## Logiciel : de l'enregistrement à l'annotation **Audacity** est le point de départ naturel. Il est libre, multiplateforme, et permet d'enregistrer, découper, normaliser et exporter dans les formats qu'exige tout pipeline MIR. Pour un corpus initial, c'est suffisant. Quand l'analyse devient plus exigeante, **Sonic Visualiser** entre en jeu. Il n'enregistre pas, mais il permet d'afficher des spectrogrammes, d'ajouter des couches d'annotation temporelle (onset, hauteur, segmentation) et de les exporter dans des formats standards comme CSV ou `.svl`. C'est l'outil que j'utilise pour l'annotation temporelle fine. Pour des corpus plus importants, avec annotation collaborative ou versionnage du jeu de données, des outils comme **Label Studio** ou **Praat** (ce dernier orienté phonétique mais utile pour l'analyse de hauteur) couvrent des besoins qu'Audacity n'atteint pas. ## Métadonnées : quoi enregistrer pour que le corpus soit utile Les métadonnées représentent la moitié du travail. Sans elles, les enregistrements ne peuvent être filtrés, reproduits ni comparés. Au minimum : | Champ | Description | |---|---| | `instrument` | Nom canonique de l'instrument enregistré | | `performer` | Identifiant de l'interprète (peut être anonymisé) | | `context` | Studio / terrain / concert en direct | | `date` | Date d'enregistrement (ISO 8601) | | `recorder` | Appareil et microphone utilisés | | `sample_rate` | Fréquence d'échantillonnage en Hz | | `bit_depth` | Profondeur de bit (16 / 24) | | `duration_s` | Durée en secondes | | `annotation` | Chemin vers le fichier d'annotation s'il existe | D'autres champs s'ajoutent selon la tâche : un corpus pour la détection de mélodie a besoin d'une transcription de référence ; un corpus pour l'identification d'instrument utilise l'instrument lui-même comme étiquette. ## Organisation des fichiers Une structure plate ne passe pas à l'échelle. Une structure qui fonctionne : ``` corpus/ metadata.csv # table maîtresse (une ligne par enregistrement) recordings/ _.wav # fichiers audio avec un schéma d'ID cohérent annotations/ .csv # annotations temporelles par fichier README.md # protocole d'enregistrement et critères ``` Le `README.md` du corpus est aussi important que les données elles-mêmes : il doit expliquer qui a enregistré, quand, avec quel matériel et selon quel protocole. Sans ce document, le corpus n'est pas reproductible. ## Commencer petit L'erreur la plus courante en montant un corpus est de viser l'exhaustivité dès le départ. Ce n'est pas nécessaire. Un ensemble initial réduit mais bien annoté — avec des critères clairs sur ce qui est enregistré, comment et pourquoi — vaut mieux que des milliers de fichiers non étiquetés. La question qui doit guider la conception n'est pas « combien d'audio puis-je rassembler » mais « que veux-je pouvoir évaluer avec ces données ». C'est l'intersection entre le bricolage de laboratoire et la rigueur de la recherche : construire la donnée qui n'existe pas pour pouvoir poser la question à laquelle on ne peut pas répondre sans elle. ## Références Les références sur lesquelles s'appuie cet article, et par où poursuivre la lecture : - Müller, M. (2015). [*Fundamentals of Music Processing: Audio, Analysis, Algorithms, Applications*](https://doi.org/10.1007/978-3-319-21945-5). Springer. - Cannam, C., Landone, C. et Sandler, M. (2010). [« Sonic Visualiser: An Application for Viewing and Analysing Music Audio Files »](https://doi.org/10.1145/1873951.1874248). Dans *Proceedings of the ACM Multimedia International Conference*. - Wilkinson, M. D. et al. (2016). [« The FAIR Guiding Principles for scientific data management and stewardship »](https://doi.org/10.1038/sdata.2016.18). *Scientific Data*, 3, 160018. - Outils libres : [Audacity](https://www.audacityteam.org) · [Sonic Visualiser](https://www.sonicvisualiser.org).