repository·gh-pages·Indexed 20 days ago
https://github.com/w3c-cg/musicxmlOfficial host for the MusicXML specification maintained by the W3C Music Notation Community Group. This documentation provides the latest release of the specification for developers working with music notation data, including XML Schema (XSD) definitions, element hierarchies, data types, and implementation examples.
MusicXML is a digital sheet music interchange and distribution format designed to be a universal standard for Western music notation. It is intended to be used by:
Tuplets are handled using two distinct elements to separate musical timing from visual notation:
<time-modification>: Handles the mathematical timing. It uses <actual-notes> (the number of notes played) and <normal-notes> (the number of notes in the standard time allotted). An optional <normal-type> can be used if the symbolic type of the notes in the tuplet differs from the standard type (e.g., an eighth-note triplet containing a quarter note).<tuplet>: A child of the <notations> element used to represent the visual part of the tuplet (brackets, etc.) and define where the tuplet begins and ends.Example of an eighth-note triplet where the first note is a quarter note:
<type>quarter</type>
<time-modification>
<actual-notes>3</actual-notes>
<normal-notes>2</normal-notes>
<normal-type>eighth</normal-type>
</time-modification>To represent multiple notes played simultaneously as a chord in MusicXML, you must include the <chord> element within the <note> elements of the subsequent notes in the chord. The first note of the chord is defined by its standard <note> structure, and all following notes that belong to that same chord must contain the <chord> tag to indicate they are played together with the first note.
<!-- Example logic: If representing a chord where the first note is a quarter note and subsequent notes are also quarter notes, the subsequent notes must have the <chord> element -->
<note>
<pitch>...</pitch>
<duration>2</duration>
</note>
<note>
<pitch>...</pitch>
<duration>2</duration>
<chord/>
</note>.mxl file. This replaces previous methods that might have required separate files or non-standard packaging for parts.In MusicXML, you can define global score settings and specific part-level overrides to manage how parts relate to a central concert score.
Global Score Settings: Use the <concert-score/> element within the <defaults> section to indicate that the score is a concert score.
Part-Specific Overrides: Use the <for-part> element within a part's <attributes> to specify how that part should be interpreted relative to the concert score. This is useful for instruments that require different clefs or transpositions than the written concert pitch.
Inside <for-part>, you can define:
<part-clef>: Specifies the clef used for the part.<part-transpose>: Specifies the transposition for the part, including <diatonic>, <chromatic>, and <octave-change> values.<defaults>
<concert-score/>
</defaults>
<!-- ... -->
<part id="P3">
<measure number="1">
<attributes>
<clef>
<sign>F</sign>
<line>4</line>
</clef>
<for-part>
<part-clef>
<sign>G</sign>
<line>2</line>
</part-clef>
<part-transpose>
<diatonic>-1</diatonic>
<chromatic>-2</chromatic>
<octave-change>-1</octave-change>
</part-transpose>
</for-part>
</attributes>
</measure>
</part>The <notations> element acts as a container for elements that represent the visual appearance of musical markings rather than their sound or timing.
Common children of <notations>:
<tied> and <tuplet> represent the visual part of ties and tuplets (the <tie> and <time-modification> elements handle sound and timing respectively).<slur>.<notations>. For example, a staccato mark is placed within an <articulations> element.Note that <slur>, <tied>, and <tuplet> all support a number attribute to distinguish between overlapping graphical elements.
<note default-x="92">
<pitch>
<step>E</step>
<alter>-1</alter>
<octave>5</octave>
</pitch>
<duration>8</duration>
<tie type="stop"/>
<voice>1</voice>
<type>eighth</type>
<time-modification>
<actual-notes>3</actual-notes>
<normal-notes>2</normal-notes>
</time-modification>
<stem default-y="-40">down</stem>
<beam number="1">begin</beam>
<notations>
<tied type="stop"/>
<tuplet bracket="no" number="1" placement="above" type="start"/>
</notations>
</note>MusicXML compressed files use a zip container based on the Info-ZIP format and are compatible with java.util.zip and Java JAR files. Files within the container are compressed using the DEFLATE algorithm (RFC 1951).
Key requirements for container creation:
mimetype.application/vnd.recordare.musicxml encoded in US-ASCII.mimetype file must not be compressed or encrypted.mimetype file header must not have an extra field.mimetype file; applications should handle containers without it.Musical directions (<direction>) are used for expression marks not tied to a specific note.
placement: Indicates if the direction goes above or below the staff.default-x and default-y: Provide precise positioning in units of tenths of interline space. default-x is measured from the start of the current measure (or the left-hand side of a note), and default-y is measured from the top barline of the staff.<offset>: Measures horizontal distance in terms of divisions (the same unit used by <duration>).Multiple <direction-type> elements can be nested within a single <direction> to link related marks (e.g., a text marking and a dynamic marking appearing together).
To include musical parts in a score, you must first declare them in a <part-list> header and then define their content in a <part> element.
<part-list>: Contains one or more <score-part> elements. Each <score-part> must have a unique id attribute and a <part-name> element.<part>: Contains the actual musical measures. The id attribute of the <part> must match an id defined in the <part-list> header. IDs should be unique and cannot start with a number (e.g., P1, P2).<part-list>
<score-part id="P1">
<part-name>Part 1</part-name>
</score-part>
</part-list>
<part id="P1">
<measure number="1">
<!-- ... -->
</measure>
</part>To represent parallel musical lines (like different voices or layers) in MusicXML, you must be able to move the musical counter independently of notes.
<backup> element to move the musical counter backwards to a previous position.<forward> element to move the musical counter forwards (often used to represent 'invisible' rests to fill a measure).In a layer-based approach, each independent part typically covers a complete measure. To add a second layer after completing the first, use <backup> to return to the start of the measure, <forward> to insert necessary rests, and then the new notes.
For temporary splits (like a voice splitting on a specific beat), use <backup> to move the counter back over the duration of the notes in the primary voice so that the secondary voice's notes are positioned correctly relative to the beat.
<!-- Example: Layer approach for a second layer starting at beat 3 in a 4-division measure -->
<backup>
<duration>16</duration>
</backup>
<forward>
<duration>8</duration>
</forward>
<note>
<pitch>
<step>G</step>
<octave>3</octave>
</pitch>
<duration>4</duration>
</note>
<note>
<chord/>
<pitch>
<step>B</step>
<octave>3</octave>
</pitch>
<duration>4</duration>
</note>
<forward>
<duration>4</duration>
</forward>The <work> element is used to represent a musical work within a MusicXML document. It typically contains metadata about the work, such as its number and title, and provides a link to the actual musical content via the <opus> element.
Key child elements include:
<work-number>: The designation or number assigned to the work (e.g., catalog numbers like 'D. 911').<work-title>: The name of the musical work.<opus>: An element that links to the specific MusicXML file containing the musical data, often using xlink attributes to define the relationship.<work>
<work-number>D. 911</work-number>
<work-title>Winterreise</work-title>
<opus xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="opus/winterreise.musicxml" xlink:show="new"/>
</work>A .mxl file is a zip-based archive using the DEFLATE algorithm (RFC 1951). To be compliant, the archive must follow these structural rules:
mimetype. It must be encoded in US-ASCII, must not be compressed or encrypted, and must contain only the string application/vnd.recordare.musicxml (no leading whitespace or byte order marks).<container> element to describe the root MusicXML file and any alternate renditions (like PDF or audio).<image> or <credit-image> can be included in the archive, typically in subfolders.