Introduction
MusicXML est un format ouvert et standardisé pour la représentation numérique de partitions musicales. Créé en 2000 par Michael Good et sa société Recordare LLC, ce format a été conçu pour faciliter l’échange de partitions entre différents logiciels de notation musicale, d’édition et d’analyse.
Le format repose sur le langage XML (eXtensible Markup Language), un langage de balisage extensible similaire au HTML, mais plus flexible et adapté à la description de données structurées. Depuis 2015, MusicXML est maintenu et développé par le W3C (World Wide Web Consortium) comme partie de la Community Group on Music Notation.
L’objectif principal du format MusicXML est de servir de « lingua franca » dans l’écosystème des logiciels musicaux, permettant une interopérabilité sans précédent entre plus de 260 applications musicales. En tant que format ouvert, il représente une alternative importante aux formats propriétaires qui limitaient auparavant le partage de partitions entre différents environnements logiciels.
Que permet de représenter le MusicXML ?
MusicXML a comme vocation de pouvoir représenter la notation de la musique occidentale, telle qu’écrite à partir du XVIIe siècle, à la fois pour la musique classique et la musique populaire. Le langage a été défini afin d’être extensible et couvrir dans le futur les notations moins standard des XXe et XXIe siècles.
En particulier, on peut représenter aujourd’hui dans MusicXML 4.0, la notation classique, les accords en notation anglo-saxonne, les tablatures et les percussions.
Il n’a cependant pas vocation à représenter des notations musicales non occidentales, même si les dernières évolutions introduisent plus des fonctionnalités permettant plus de flexibilité pour les micro-intervalles et altérations micro-tonales et la simulation d’échelles non tempérées, entres autres.
Néanmoins, MusicXML repose sur une structure conçue à l’origine pour la notation occidentale tonale standard, ce qui limite sa capacité à encoder certaines notations alternatives, notamment rythmiques. Il permet de coder :
- La notation standard : notes, silences, altérations, armures, métriques, clés, etc.
- Les articulations et nuances : staccato, legato, crescendo, forte, piano, etc.
- La structure des mesures : barres de mesure, reprises, fins alternatives
- Les paroles : alignées avec les notes correspondantes
- Les annotations textuelles : indications de tempo, expressions, instructions d’interprétation
- Les symboles d’ornementation : trilles, mordants, gruppettos
- La notation pour instruments spécifiques : tablatures pour guitare, percussion, notation pour instruments transpositeurs
- La mise en page : positionnement des éléments, sauts de système, marges
- Les parties instrumentales : séparation des parties dans un ensemble ou orchestre
Ce format est particulièrement puissant car il cherche à représenter à la fois :
- L’aspect sémantique : ce que signifie musicalement chaque élément
- L’aspect visuel : comment la partition apparaît graphiquement
Cette double représentation permet de conserver l’information musicale dans son intégralité lors des transferts entre logiciels.
Comment se positionne MusicXML par rapport au format MIDI ?
MusicXML et MIDI (Musical Instrument Digital Interface) sont deux formats qui servent des objectifs différents et complémentaires dans l’écosystème musical numérique :
| Caractéristique | MusicXML | MIDI |
| Objectif principal | Représenter la notation musicale | Contrôler des instruments électroniques |
| Contenu | Information complète de la partition (notation, mise en page, etc.) | Événements de notes (hauteurs, durées, vélocités) |
| Représentation | Symbolique et visuelle | Événementielle |
| Taille de fichier | Plus volumineux | Compact |
| Lisibilité humaine | Lisible (format texte) | Binaire (non lisible directement) |
| Usage principal | Échange de partitions entre logiciels | Séquençage musical, contrôle d’instruments |
Les principales différences peuvent se résumer ainsi :
- Notation vs Performance : MusicXML se concentre sur la représentation de la partition comme un document (ce qui est écrit), tandis que MIDI représente une performance (ce qui est joué).
- Richesse d’information : MusicXML contient des informations détaillées sur la notation (positions précises, nuances, articulations, texte) que MIDI ne peut pas représenter.
- Conversion bidirectionnelle : convertir du MIDI en MusicXML nécessite une interprétation musicale (quantification rythmique, détermination des enharmoniques), tandis que convertir du MusicXML en MIDI est plus direct mais peut perdre des informations expressives.
Un exemple concret : une partition avec un crescendo noté sur plusieurs mesures sera représentée symboliquement en MusicXML, alors qu’en MIDI, cette nuance serait traduite par une augmentation progressive de la vélocité des notes individuelles.
Ces deux formats sont souvent utilisés ensemble dans un flux de travail musical : MusicXML pour la notation et l’édition, MIDI pour l’exécution et l’enregistrement.
À quoi ressemble le MusicXML ?
Un premier exemple permettra de voir rapidement comment représenter une simple note en MusicXML. Prenons l’exemple du Do « serrure » (pour mémoire ce Do s’appelle ainsi car sur le piano, c’est le Do le plus proche de la serrure du couvercle du clavier).
En MusicXML, le fichier le représentant est le suivant, sachant que :
- Les notes respectent la notation alphabétique anglo-saxonne (A à G)
- Les commentaires ci-dessous ne reflètent que les symboles visibles de la partition
<measure number= »1″>
<attributes>
<divisions>4</divisions>
<key>
<fifths>0</fifths>
<mode>major</mode>
</key>
<time>
<beats>4</beats>
<beat-type>4</beat-type>
</time>
<clef>
<sign>G</sign>
<line>2</line>
</clef>
</attributes>
<note>
<pitch>
<step>C</step>
<octave>4</octave>
</pitch>
<duration>4</duration>
<type>quarter</type>
</note>
<!– Autres notes… –>
</measure>
A noter que sur ce premier exemple simplissime, on peut déjà constater (en dehors de l’aspect assez verbeux du XML), que certaines informations peuvent sembler redondantes :
a) Clef de Sol, explicitement à la ligne 2 (alors que c’est normalement toujours le cas),
b) Durée de 4 temps sur la ronde
En effet, pour le a) on est trop habitués aux clefs de Sol et de Fa, mais MusicXML s’adresse à tous les instruments. Un petit rappel de solfège nous remémorera que les symboles de clef de Sol, Fa et Ut peuvent s’utiliser sur des lignes différentes selon les instruments.
Pour le b), si la mesure avait été en 2/2, (ou « C barré »), une blanche aurait valu un temps, donc une ronde deux temps.
On a pu voir sur un exemple simple la richesse potentielle qui se cache déjà sous MusicXML…
Structure générale des fichiers MusicXML
Le MusicXML propose deux façons principales d’organiser les données musicales : le format « Partwise » (organisé par parties) et le format « Timewise » (organisé par mesures).
Assez fréquemment, une partition (surtout d’orchestre) fournit sur une même page des parties dédiées à des instruments séparés. Et dans le cas des instruments polyphoniques comme le piano, il y a toujours 2 portées conjointes, une dédiée à chaque main (à l’exception notable des concertos pour piano écrits pour la main gauche, l’exemple le plus connu étant le concerto pour la main gauche de Ravel).
On peut donc représenter une partition en MusicXML comme une suite de parties séparées, comme si chaque instrumentiste lisait sa propre partie sur la partition commune. C’est ce qu’on pourrait appeler la lecture horizontale. Cette représentation s’appelle partwise (par parties).
Ou alors comme une suite de mesures « globales », chacune représentant la mesure correspondante de chaque partie. Une lecture verticale en quelque sorte, mais qui est exactement la façon dont le chef d’orchestre utilise son « conducteur ». On parle alors de représentation timewise.
MusicXML permet donc de représenter une même partition suivant ces deux axes de lecture.
Format Partwise
Le format Partwise est le plus couramment utilisé. Il organise les données en privilégiant d’abord les parties instrumentales, puis les mesures à l’intérieur de chaque partie :
<score-partwise>
<part-list>
<!– Définition des parties –>
<score-part id= »P1″>
<part-name>Piano</part-name>
</score-part>
</part-list>
<part id= »P1″>
<measure number= »1″>
<!– Contenu de la mesure 1 –>
</measure>
<measure number= »2″>
<!– Contenu de la mesure 2 –>
</measure>
<!– Autres mesures… –>
</part>
<!– Autres parties… –>
</score-partwise>
Cette structure est particulièrement adaptée pour les logiciels qui organisent leurs données par instrument, comme la plupart des éditeurs de partitions.
Format Timewise
Le format Timewise organise les données en privilégiant d’abord les mesures, puis les parties instrumentales à l’intérieur de chaque mesure :
<score-timewise>
<part-list>
<!– Définition des parties –>
<score-part id= »P1″>
<part-name>Piano</part-name>
</score-part>
</part-list>
<measure number= »1″>
<part id= »P1″>
<!– Contenu de la partie P1, mesure 1 –>
</part>
<!– Autres parties pour la mesure 1… –>
</measure>
<measure number= »2″>
<!– Parties pour la mesure 2… –>
</measure>
<!– Autres mesures… –>
</score-timewise>
Cette structure est plus rare mais peut être utile pour les logiciels d’analyse musicale qui travaillent mesure par mesure ou pour des applications de synchronisation audiovisuelle.
Il est à noter que le MusicXML fournit des outils de conversion entre ces deux formats, permettant ainsi aux applications de travailler avec la structure qui leur convient le mieux, indépendamment du format d’origine.
Les différents tags sur un extrait de partition significatif
Pour illustrer concrètement l’utilisation des balises MusicXML, analysons un extrait plus complet qui représente les premières mesures d’une mélodie simple avec diverses indications musicales. L’extrait choisi est les 4 premières mesures de « Après un rêve » de Gabriel Fauré :
On peut voir sur cette partition un peu plus étoffée que :
- Chaque instrument a sa ou ses portées dans un tag part
- Les différentes indications littérales de tempo ou de nuances, sont indiquées sur chaque mesure par le tag words (direction/direction-type/words)
- Stem up ou down: Indique la position de la hampe de note
- note/pitch/step C octave 5 indique la hauteur par la note dans l’octave
- direction/direction-type/wedge type=crescendo permet d’indiquer des nuances
- note/staff : permet de spécifier sur quelle portée de la partie instrumentale doit figurer la note
Cet extrait montre comment le format MusicXML capture non seulement les notes et leur durée, mais aussi les nuances, articulations, liaisons, paroles et autres éléments expressifs essentiels à l’interprétation musicale correcte.
Performances et limites
Les performances du format MusicXML doivent être évaluées selon plusieurs critères :
Taille des fichiers
Les fichiers MusicXML sont généralement plus volumineux que leurs équivalents dans des formats propriétaires ou binaires. Une simple mélodie d’une page peut facilement atteindre plusieurs dizaines de kilobytes, tandis qu’une partition d’orchestre complète peut peser plusieurs mégabytes. Cela s’explique par :
- La nature textuelle du XML (par opposition aux formats binaires)
- La redondance inhérente à la structure XML
- La richesse des métadonnées et des informations de formatage
Pour remédier à ce problème, MusicXML utilise souvent la compression ZIP, créant des fichiers avec l’extension .mxl qui sont beaucoup plus compacts que les fichiers .xml non compressés.
Vitesse de traitement
Le traitement des fichiers MusicXML peut être relativement lent par rapport à d’autres formats, notamment pour les grandes partitions. Cela est dû à :
- L’analyse syntaxique (parsing) du XML qui est plus complexe que celle des formats binaires
- La grande quantité de données à traiter
- La nécessité de résoudre les références croisées entre différentes parties du document
Cependant, les bibliothèques modernes de traitement XML et l’augmentation des performances matérielles atténuent largement ce problème. De plus, MusicXML est principalement conçu comme un format d’échange plutôt que comme un format de travail interne, ce qui rend ces considérations moins critiques.
Précision et fidélité
MusicXML excelle dans la préservation fidèle des informations musicales lors des échanges entre applications. Toutefois, quelques limitations existent :
- Certains éléments de mise en page très spécifiques peuvent ne pas être parfaitement préservés
- Les fonctionnalités propres à certains logiciels peuvent ne pas avoir d’équivalent standardisé en MusicXML
- La complexité de certaines notations contemporaines peut poser des défis de représentation
Ces limitations sont progressivement résolues au fil des évolutions du standard.
🟩 En résumé – MusicXML
| Atouts | Description courte |
| 🔄 Interopérabilité | Échange facile entre logiciels |
| 💼 Large adoption | Norme dans l’édition musicale |
| 👶 Simplicité d’usage | Aucune connaissance technique requise |
| 📐 Contrôle du rendu | Gestion de certains éléments graphiques |
| 🕒 Évolutivité | Maintenu activement par le W3C |
| Limites | Description |
| 📚 Centré sur la notation occidentale | Difficulté à représenter d’autres traditions musicales |
| 🧠 Peu de sémantique | Mauvaise aptitude à l’analyse musicologique ou structurelle |
| 🔁 Interopérabilité fragile | Résultats incohérents selon les logiciels |
| ✏️ Contrôle graphique limité | Peu adapté à la gravure typographique de haute qualité |
| ⏱ Rythmes rigides | Modèle temporel inadéquat pour des œuvres non métriques |
| 📑 Aucune gestion d’apparat critique | Pas conçu pour l’édition savante multi-source |
| 🔍 Syntaxe complexe | Manipulation directe difficile sans interface logicielle |
