Michael D. Good
Originally published in Digital Edition zwischen Experiment und Standardisierung, Peter Stadler and Joachim Veit, eds., Max Niemeyer Verlag, Tübingen, 2009, pp. 157-173.
Copyright © 2009 Michael D. Good
1 Introduction to MusicXML 2.0
During the last part of the 20th century, the creation of sheet music publications became an increasingly computerized process. The historical production process of plate engraving gave way to computerized engraving. In the 21st century, nearly any publication of Western music that uses common Western music notation will be produced using music notation software. In 2009, the most common notation software products are Finale and Sibelius. In the past, other programs like Score and Amadeus were used more frequently, and they still remain in use today.
All of these programs have their own internal, proprietary data formats for representing music notation. In the past, it was not possible for people to share music notation effectively between different programs. The MIDI format1 was the only interchange format widely supported by commercial music software, but MIDI includes only a small fraction of the information represented in music notation.2 Earlier efforts to create a standard notation format such as NIFF3 and SMDL4 were never widely adopted, due to a combination of technology and social issues.5
Around the turn of the century, many people realized that the XML language provided an excellent opportunity to at last create a standard music notation interchange language.6 XML provided a technology for representing complex data from different applications in a standard, Unicode, text-based format that was readable both by computers and people. XML attracted widespread interest from the information technology industry, so musicians could now leverage the base technology investments made by much larger industries.
The Recordare® MusicXML™ format7 was placed on a strong technical foundation by building on the two leading academic formats for symbolic music: the MuseData format8 and the Humdrum format.9 The first versions of MusicXML were basically an XML version of MuseData, with key concepts from Humdrum added in. Soon MusicXML added features for popular music and other areas that went beyond the original MuseData and Humdrum designs. MusicXML also followed best practices for XML language design, using elements for musical data and attributes for musical metadata such as formatting and performance information.10
MusicXML was one of numerous proposals for representing common Western music notation in an XML format that emerged at this time. Others included MML,11 MEI,12 and WEDELMUSIC,13 the last of which became the basis for MPEG’s symbolic music representation feature.14 Like SMDL before them, none of these alternative XML proposals attracted support from any commercial music applications. None of them provide a practical, usable solution for music editorial applications.
In contrast, MusicXML has become the de facto standard for music notation interchange. As of January 2009, it is supported by over 100 music applications. It is available under a non-revocable royalty-free license that is appropriate for both commercial and academic applications, whether delivered as proprietary or open source software.
Figure 1 lists the applications supporting the MusicXML format as of January 2009. The applications in the top section both read and write MusicXML files. Applications in the middle section can write MusicXML files without reading them, and applications in the bottom section read MusicXML files without writing them. Applications on the left hand side are generally available. Applications on the right hand side are in either beta test or prototype stage.
Figure 1: MusicXML Adoption as of January 2009
Many different types of music applications support the MusicXML format:
- Notation programs such as Finale, Sibelius, capella, PriMus, NOTION, Encore, and LilyPond.
- Music scanning applications such as SharpEye, SmartScore, PhotoScore, capella-scan, and Audiveris.
- Sequencers such as Cubase, Nuendo, Sequoia, Samplitude, and Rosegarden.
- Web browser plug-ins such as the Myriad Music Plug-in.
- Digital sheet music retail applications such as musicRAIN.
- Electronic music stands such as MuseBook Score and OrganMuse.
- Tablature editors such as PROGRESSION, Guitar Pro, TablEdit, and TaBazar.
- Automatic composition programs such as JMSL.
- Music analysis programs such as MelodicMatch and Humdrum.
- Translation tools such as PDFtoMusic Pro and utilities for SCORE and Amadeus files.
This widespread support at last makes it practical for different people working on a musical project to use the music tool that works best for them. When they exchange their music with somebody using a different application, far less rework is necessary. MusicXML is now used pervasively in commercial music preparation whenever application boundaries need to be crossed. A typical examples is when composers use one program and publishers, arrangers, or copyists use another. Another example is when a musical is being transferred between New York, London, or other locations where the music preparation staff use different programs.15
The amount of rework needed when crossing application boundaries depends on the quality of the software. While MusicXML 2.0 is a near-lossless format for music notation, the quality of MusicXML reading and writing software varies greatly. Exporting from recent versions of Finale to MusicXML is highly accurate, allowing digital sheet music retailers like musicRAIN to create a Flash-based retail environment that faithfully maintains the appearance of sheet music originally created in Finale. Each year sees improvements in both quality as well as the quantity of MusicXML translation software. For instance, the MusicXML 2.0 import provided in Sibelius 5.2 far exceeds the accuracy of the initial implementation of MusicXML 1.1 import in Sibelius 4. The availability of a W3C XML Schema version of the MusicXML 2.0 format, released in September 2008, should help accelerate these quality improvements by making MusicXML writing errors easier to diagnose and fix.
The amount and complexity of software needed to perform music notation format translations that are accurate enough for practical use is usually underestimated, since it is invisible to the musicians using these programs. MusicXML’s eight-year lead in software development over other XML formats for common Western music notation makes it unlikely that any other XML-based formats in this area will rival it in the future.
This large installed base of MusicXML support provides a great opportunity for building new music editorial applications that can integrate directly into the critical edition production process. The high fidelity of the format means that music editorial software can concentrate on issues that are particularly unique to the editorial users, without having to duplicate the notational capabilities of advanced programs such as Finale, Sibelius, and Cubase. A music editorial application can use files created by nearly any notation application and produce files readable by nearly any notation application. This frees editors to use whatever tool they like for notation entry, knowing that the resulting files can be read by engraving and music display software later in the process.
This opportunity can only be realized if the MusicXML format can support the demanding needs of music editorial applications. At the Digitale Medien und Musikedition symposium held in Mainz in November 2006, speakers raised several issues that limited MusicXML 1.1’s potential use in editorial applications. When version 2.0 of the MusicXML format was released in June 2007, the feedback from that conference had been incorporated into the 95 new features added to the format. MusicXML 2.0 now meets the needs of editorial applications for common Western music notation.
In the remainder of this paper, I will go through the key issues raised by Johannes Kepper and Stefan Morent16 in their requirements for music representation formats. Using annotated versions of Kepper and Morent’s editorial examples from Bach, Beethoven, and Brahms, I will demonstrate the specific MusicXML features that address these different editorial requirements.
The MusicXML examples were created by encoding the musical examples using Finale 2008, using the Dolet® 4 for Finale plug-in to automatically export the MusicXML 2.0 file. The MusicXML 2.0 files were then hand-edited as needed to add music editorial data required by the editorial examples but not yet supported by the Finale or Dolet for Finale software.
2 Editorial Example I: Versions / Adaptations of BWV 655,
Herr Jesu Christ dich zu uns wend, bars 1–4
Figures 2 and 3 show annotated versions of the variants in the Bach editorial example used by Kepper and Morent. Note the differences between these versions of the same piece that start in bar 2: differences in slurs and ornamentation in the top staff, and differences in pitches and rhythms in the bottom staff. The numbers added to the music refer to MusicXML example numbers that will follow in this discussion.
Figure 2: Bach editorial example, first variant
Figure 3: Bach editorial example, second variant
Kepper and Morent describe the encoding of the soprano C clef in the bottom staff as the main musical challenge in this generally straightforward example. This is not a great challenge as most contemporary formats, including MusicXML, support these movable C clefs. MusicXML’s solution separates the clef sign and the clef placement into separate elements so that they can be processed independently if need be. Listing 1 illustrates the MusicXML representation of the two clefs in this example.
<clef number="1"> <sign>G</sign> <line>2</line> </clef> <clef number="2"> <sign>C</sign> <line>1</line> </clef>
Listing 1: Representing clefs in MusicXML
The major issue in this editorial example, however, is the issue of representing variants. There are two variants in this editorial example, but there can easily be many more variants in real-life examples. This was the most critical music editorial issue regarding MusicXML 1.1 raised at the Mainz symposium, and it has been addressed in MusicXML 2.0.
One of the strengths of the MusicXML format is that, no matter what the musical application, MusicXML documents primarily are modeling a physical musical score, rather than an abstraction of a musical score. It is complex to represent music notation in a near-lossless fashion that incorporates musical semantics and well as fine points of graphical representation. Given this complexity, the clarity provided by this straightforward modeling of a printed score has been essential to the successful adoption of the format.
Since version 1.0, MusicXML has always offered XLink-based elements that can represent connections between musical scores. The problem in MusicXML 1.1 is that each variant had to be in a separate file. This type of representation is insufficient because it is far too easy to break the connection between documents, making it very difficult to build robust applications that use this feature.
One of the primary additions to MusicXML 2.0 is the addition of a compressed, zip-based file format. This zip format has many uses:
- It greatly reduces the size of MusicXML files. The file size reduction is roughly a factor of 20 on average, making MusicXML files roughly the same size as the corresponding MIDI files. This file size reduction makes MusicXML 2.0 files much more effective for digital sheet music distribution.
- Compressed MusicXML 2.0 files have their own unique .mxl suffix, rather than the common .xml suffix that is shared by many other applications. They also have a unique registered IANA media type. This makes it much easier for applications and web browsers to do automatic processing of MusicXML files. One example is the Myriad QuickLook plug-in for Mac OS 10.5 that provides automatic MusicXML score previews in the Mac Finder.
- Multimedia music files are made much more reliable because graphics and audio files can now be stored in the same file as the music notation file.
- Music editorial applications are made much more reliable because multiple variants can now be stored in a single music notation file.
- Music editorial applications can also use the zip file structure to store detailed metadata in a specialized format in the same single .mxl file as the multiple variants. This addresses the detailed metadata issues raised in the Weber editorial example II.17
Let us see how this works using the Bach example. First, the individual MusicXML score files contain hyperlinks within the score indicating the connections between them. Listing 2 shows the connection stored in the first variant. The id names reflect that there are no slurs in the top staff of the first variant, while slurs are present in the top staff of the second variant.
<bookmark id="Bar2NoSlurs"/> <link xlink:href="bach_2.xml#Bar2Slurs"/>
Listing 2: Representing a link from the first variant to the second variant
Listing 3 shows the connection stored in the second variant.
<bookmark id="Bar2Slurs"/> <link xlink:href="bach_1.xml#Bar2NoSlurs"/>
Listing 3: Representing a link from the second variant to the first variant
Each variant is represented by a separate MusicXML score-partwise document. The first variant is called bach_1.xml and the second is called bach_2.xml. Each of these files is then placed in the bach_1.mxl compressed zip file. A compressed MusicXML zip file always has a file at META-INF/container.xml whose first rootfile element points to the primary music notation file. Listing 4 shows the content of the container.xml file in this example, where the first variant is considered the primary file.
<?xml version="1.0" encoding="UTF-8"?>
<container>
<rootfiles>
<rootfile full-path="bach_1.xml"/>
</rootfiles>
</container>
Listing 4: Contents of the container.xml file within the bach_1.mxl file
Since these compressed files are zip-based, similar to the techniques used for many other XML-based formats in other domains such as word processing, they can be directly edited by industry-standard XML editors. Figure 4 shows what the bach_1.mxl file looks like when opened by the XMLSpy editor.
Figure 4: Opening the bach_1.mxl file in the XMLSpy editor
This solution to providing for multiple variants is easier for music applications to implement than the alternative approach of directly encoding variant readings within a single XML document. This is especially true for high-fidelity music notation formats that provide fully accurate formatting information as well as musical notation information. This is an important design consideration, because music application support is critical for turning the development and use of advanced music editorial applications from a dream into a reality.
3 Editorial Example III: Ludwig van Beethoven, Waldstein Sonata, op. 53, 1st mov., bars 1–4
When we move to the Beethoven editorial example, the encoding of the musical manuscript becomes more complicated. As Kepper and Morent state, “This typical example of piano music shall demonstrate the difference between graphical sign and corresponding meaning. The encoding should aim to describe the signs found within the source as well as the intentions they stand for.”18 MusicXML is designed to support just this type of dual representation. From the beginning, MusicXML adopted MuseData’s features for distinguishing and interrelating the graphical and sounding aspects of music notation.
With this example, we illustrate MusicXML 2.0’s capabilities to represent musical formatting as well as the elements of music notation. Figure 5 shows my Finale 2008 encoding of this example overlaid on the original manuscript image. Figure 6 shows the original Beethoven editorial example image. Both figures are annotated with numbers referring to the MusicXML examples to follow. In some cases, multiple MusicXML examples are used to illustrate an encoding issue.
Figure 5: Beethoven editorial example overlaid with Finale encoding
Figure 6: Beethoven editorial example
MusicXML uses tenths of a staff space as its primary formatting dimension, just as MuseData does. The scaling element is used to establish the relationship between tenths and the physical unit of millimeters. Listing 5 shows this scaling element. Dolet 4 for Finale software exports the scaling relationship using 40 tenths, so that the millimeters value represents the standard staff height. In this example, the staff height is just under 10 millimeters.
<scaling> <millimeters>9.966</millimeters> <tenths>40</tenths> </scaling>
Listing 5: MusicXML scaling of tenths of staff space to millimeters
Most MusicXML elements can have default-x and default-y attributes to show exact positioning. The default-y attribute is measured from the top line of the staff. The default-x attribute is generally measured from the parent element. For note elements, the default-x element is the distance of the left-hand side of the note from the left barline. For elements that are part of the note element, like slurs and articulations, the default-x attribute is measured from the left-hand side of the current note.
Listing 6 shows an example of encoding the width of the second measure together with the horizontal position of the left-hand side of the first note in the right hand.
<measure number="2" width="212"> <note default-x="34">
Listing 6: Encoding measure width and horizontal note position
Kepper and Morent describe eight encoding issues of interest in the Beethoven editorial example.19 The first issue is the encoding of the pianissimo directions in measure 1, including full formatting and positioning. Listing 7 shows the MusicXML encoding of the upper pianissimo direction.
<direction>
<direction-type>
<dynamics default-y="-25" relative-x="-46">
<!– Underline currently missing for dynamics -->
<?editorial underline="2"?>
<pp/>
<other-dynamics>:</other-dynamics>
</dynamics>
</direction-type>
<staff>2</staff>
</direction>
Listing 7: Formatted pianissimo direction
While MusicXML 2.0 can directly represent the colon following the pp mark, as well as the position of the mark on the staff, the MusicXML underline attribute is currently available only for text, not for dynamics. This can be added using the MusicXML 2.0 DTD by representing the underline with an XML processing instruction (the text that begins with “<?” and ends with “?>”). The W3C XML Schema version of the MusicXML 2.0 format, released in 2008, makes it easier to extend the MusicXML2.0 format to allow underlines for dynamics as well as text.
The second issue is to clarify the right hand’s movement from the lower staff in the first three bars to the upper staff in the fourth bar. MusicXML supports this by using a voice element to keep track of the movement of musical voices within and between staves. Note that the right-hand notes stay in voice 1 in both Listing 8 (bottom staff) and Listing 15 (top staff).
The third issue is to be sure that the first three bars are marked as empty, not resting. The MusicXML encoding includes no notes – not even rests – in the upper staff of the first three bars.
The fourth issue is that the repetition marks starting in the second half of the first bar are not just graphical additions, but represent that four eighth notes are played instead of a single half note. Listing 8 shows the MusicXML encoding of the repetition mark in the right hand of the first bar, including the unheard half note and the first of the four sounding eighth notes. The cue element indicates that the half note is not played, while the print-object attribute indicates that the eighth note is not printed. Three identical eighth note elements follow the first to complete the encoding of the repetition and have been omitted for brevity.
<note default-x="265">
<cue/>
<pitch>
<step>C</step>
<octave>3</octave>
</pitch>
<duration>8</duration>
<voice>1</voice>
<type size="full">half</type>
<stem default-y="21">up</stem>
<staff>2</staff>
<notations>
<ornaments>
<tremolo>1</tremolo>
</ornaments>
</notations>
</note>
<backup>
<duration>8</duration>
</backup>
<note print-object="no">
<pitch>
<step>C</step>
<octave>3</octave>
</pitch>
<duration>2</duration>
<voice>3</voice>
<type>eighth</type>
<staff>2</staff>
</note>
Listing 8: Note repetition
The fifth issue is the encoding of the half-bar repetition marks starting at the first half of the third bar. MusicXML 2.0 encodes this type of beat repetition using the attributes element. In MusicXML 1.1, the meaning of the repetition slash was limited to the beat implied by the time signature. This was not adequate for this example, as the repetition is for a half-note beat while the time signature is in a quarter-note beat. One of MusicXML 2.0’s 95 new features is a slash-type element to indicate when the beat-repeat value is different than the time signature value. This element is automatically exported using the Dolet 4 for Finale plug-in software. Listing 9 shows the resulting encoding. As in Listing 8, only the first note of the repeated passage is included here.
<attributes>
<measure-style number="2">
<beat-repeat type="start">
<slash-type>half</slash-type>
</beat-repeat>
</measure-style>
</attributes>
<note>
<pitch>
<step>B</step>
<octave>1</octave>
</pitch>
<duration>2</duration>
<voice>2</voice>
<type>eighth</type>
<staff>2</staff>
</note>
Listing 9: Beat repetition
The sixth issue involves the encoding of the Allegro con Brio movement title, the Sonata grande work title, and the composer’s name. In MusicXML 2.0, the encoding of the text on the page is done in a different element that the encoding of the metadata information. Listing 10 shows the encoding of the Allegro con Brio tempo mark as displayed on the page.
<direction placement="above">
<direction-type>
<words default-y="24"
relative-x="-36">Allegro con Brio.</words>
</direction-type>
<staff>1</staff>
</direction>
Listing 10: Tempo mark
Listing 11 shows the encoding of the Sonata grande title text as displayed on the page. The formatting is based on the Finale version shown in Figure 5. Credit elements are associated with a page. The default-x and default-y attributes are measured from the left-hand and bottom edges of the page respectively. The center justification indicates that the default-x value refers to the center of the text. The valign (vertical alignment) of top indicates that the default-y value refers to the top of the text. An halign attribute is also available for situations where horizontal alignment and justification are done differently, but it is not needed here. Unlike other units, MusicXML font sizes are in points, rather than tenths of staff space.
<credit page="1"> <credit-words default-x="708" default-y="921" font-size="12" font-weight="bold" justify="center" valign="top">Sonata grande</credit-words> </credit>
Listing 11: Title
Listing 12 shows the encoding of the composer’s name as displayed on the page, also using the formatting generated automatically from the Dolet 4 for Finale plug-in from the Finale version of this example, including the crossed-out text.
<credit page="1"> <credit-words default-x="1188" default-y="920 font-size="12" font-weight="bold" justify="right" line-through="1" valign="top">L. v. Beethoven</credit-words> </credit>
Listing 12: Composer
Listing 13 shows the metadata encoding of the work title, the movement title, and the composer.
<work> <work-title>Sonata grande</work-title> </work> <movement-title>Allegro con Brio</movement-title> <identification> <creator type="composer">L. v. Beethoven</creator> </identification>
Listing 13: Title and composer metadata
The seventh issue involves the rotated text at the end of the first system. This is another example that could not be encoded entirely accurately in MusicXML 1.1. In MusicXML 2.0, the rotation attribute represents the rotated text. Listing 14 shows the encoding of the text, including the line break and the 90 degree clockwise rotation. XML preserves whitespace within elements, so the line break is encoded directly within the content of the words element.
<direction>
<direction-type>
<words default-y="-27" relative-x="27"
rotation="90" xml:lang="de">Dämpfung
aufgehoben</words>
</direction-type>
</direction>
Listing 14: Rotated multi-line text
The final issue in the Beethoven example is the encoding of different musical elements in the last bar of the right hand: the accidentals, slur, tie, stroke, and grace note. Listing 15 shows the encoding of the grace note and its accidental.
<note default-x="42">
<grace/>
<pitch>
<step>C</step>
<alter>1</alter>
<octave>6</octave>
</pitch>
<voice>1</voice>
<type>16th</type>
<accidental>sharp</accidental>
<stem default-y="42">up</stem>
<staff>1</staff>
</note>
Listing 15: Grace notes and accidentals
Listing 16 shows the encoding of the start of the slur and the start of the tie, including slur curvature formatting details.
<note default-x="64">
<pitch>
<step>D</step>
<octave>6</octave>
</pitch>
<duration>4</duration>
<tie type="start"/>
<voice>1</voice>
<type>quarter</type>
<stem default-y="-12">down</stem>
<staff>1</staff>
<notations>
<tied type="start"/>
<slur bezier-x="32" bezier-y="21" default-x="6" default-y="35"
number="1" placement="above" type="start"/>
</notations>
</note>
Listing 16: Start of tie and start of slur
Listing 17 shows the encoding of the end of the slur and the stroke articulation. Following MuseData, MusicXML uses the spiccato element to refer to the stroke notation.
<note default-x="218">
<pitch>
<step>G</step>
<octave>5</octave>
</pitch>
<duration>4</duration>
<voice>1</voice>
<type>quarter</type>
<stem default-y="-31">down</stem>
<staff>1</staff>
<notations>
<slur bezier-x="-29" bezier-y="25" default-x="6"
default-y="23" number="1" type="stop"/>
<articulations>
<spiccato default-y="20" placement="above" relative-x="10"/>
</articulations>
</notations>
</note>
Listing 17: End of slur and stroke articulation
4 Editorial Example IV: Johannes Brahms, Capriccio op. 116,
no. 3, bars 9–12
The Brahms editorial example raises several issues in representing music from manuscripts rather than published editions. Figure 7 shows the Brahms editorial example, annotated with MusicXML example numbers that show the encoding of particular problems:
Figure 7: Brahms editorial example
Listing 18 shows the encoding of the fingering on the fourth note in the right hand. The Dolet 4 for Finale exporter automatically exports this as a fingering element, not as plain text.
<notations>
<technical>
<fingering default-y="-53" placement="below">4</fingering>
</technical>
</notations>
Listing 18: Fingering
Listing 19 demonstrates the encoding of the different slurs in the first bar of the right hand. The shorter slur is primary while the longer slur has been crossed out. The level elements are used to indicate the editorial information that the second slur was done in pencil and is for reference use only. The different Bezier curvature points show that the longer slur has a flatter curvature. The bezier-x and bezier-y attributes for the slur, like the default-x and default-y attributes, are measured from the left-hand side of the note and the top line of the staff.
<notations> <level>1</level> <slur number="1" bezier-x="63" bezier-y="27" default-x="19" default-y="26" placement="above" type="start"/> </notations> <notations> <level reference="yes">2 (pencil)</level> <slur number="2" bezier-x="90" bezier-y="26" default-x="19" default-y="26" placement="above" type="start"/> </notations>
Listing 19: Using MusicXML level elements for editorial information
This editorial information in the level elements needed to be manually added to the MusicXML file since there is no way to encode this directly in Finale in a way that the Dolet 4 for Finale plug-in can automatically understand. This is the type of data that could be generated in MusicXML files by a specialized music editorial application, without the need to duplicate all the notation features of full-featured editing programs like Finale and Sibelius.
5 Issues from Editorial Examples II and V
I have not dealt with the editorial examples from Carl Maria von Weber (Example II) and Hildegard von Bingen (Example V) in this paper.20 This is because the remaining issues they raise are largely out of the scope of the MusicXML format.
The Weber editorial example has not been discussed because the primary issues that are unique to this example deal more with metadata that musical notation. MusicXML 2.0 includes very simple metadata capabilities such as those that were illustrated in MusicXML listing 13. These metadata features were not designed to meet the needs of editorial applications. However, as mentioned earlier, the packaging of MusicXML 2.0 .mxl files makes it possible to include specialized metadata within the MusicXML file. This metadata format can be custom-designed to meet music editorial metadata needs. If this format is XML-based, XLinks can be used to connect metadata and musical scores similar to the way that they are used to connect variants in the Bach example. Other issues in this editorial example are elaborations of the variant and editorial level issues discussed in the Bach and Brahms editorial examples respectively.
The Hildegard editorial example has not been discussed because MusicXML only represents common Western music notation from the 17th century onwards. The history of computerized music notation formats teaches us that music data formats need to be constrained to represent music notation that is understood by a common community of musicians.21 Specialized XML formats, such as CMME22 for mensural notation and NeumesXML23 for neumes, are the best approach for representing earlier periods of Western music in XML format. Translators can then be built to go from the original notation to a modernized version, embodying editorial decisions similar to those made in preparing modern performing editions of early music for non-specialist musicians.
Conclusions
MusicXML is the only standard format currently available for high-fidelity encoding of common Western music notation. MusicXML 2.0 has matured from its origins as a music notation interchange format to also become a music notation distribution and archival format. Due in large part to the contributions of the Mainz conference of 2006, MusicXML has also added the necessary capabilities to meet the most demanding needs of music editorial applications. MusicXML 2.0’s container format for .mxl files solves the problem of encoding multiple variants in a single file which was perhaps the single largest impediment to using MusicXML in music editorial applications. The combination of MusicXML, CMME, and NeumesXML extends XML format coverage for music editorial applications to nearly the entire history of Western music notation.
Not every MusicXML design decision will be optimal for every music editorial application. MusicXML’s strength is its combination of great depth of power and detail in representing printed musical scores, together with its adaptability for use by a wide variety of musical applications. MusicXML eliminates the need for music editorial applications to duplicate the features of other music programs. It is this ability to combine specialized music editorial applications with a wealth of other musical applications – including those used in the rest of the critical edition production process – that makes the MusicXML format uniquely well suited for music editorial applications involving common Western music notation.
Acknowledgments
Walter Hewlett, Eleanor Selfridge-Field, David Huron, and Barry Vercoe provided the most important prior art and ongoing encouragement for the early development of the MusicXML format. Geri Actor, Doill Jung, Graham Jones, Curtis Morley, Didier Guillion, Mark Maronde, Don Byrd, Christof Schardt, Donncha Ó Maidín, Bernd Jungmann, and the many members of the MusicXML mailing list have made great contributions to the MusicXML community over the past eight years.
Footnotes
- MIDI Manufacturers Association Inc.: The Complete MIDI 1.0 Detailed Specification. Document version 96.1. Los Angeles, 1996. Also see http://www.midi.org, consulted August 2008.
- See Eleanor Selfridge-Field (Ed.): Beyond MIDI: The Handbook of Musical Codes. Cambridge (MA) 1997.
- See Cindy Grande: The Notation Interchange File Format. A Windows-Compliant Approach. In Selfridge-Field 1997 (note 2), pp. 491-512.
- See Donald Sloan: HyTime and Standard Music Description Language. A Document-Description Approach. In Selfridge-Field 1997 (note 2), pp. 469-490.
- See Michael Good: Lessons From the Adoption of MusicXML as an Interchange Standard. In Proceedings of the XML 2006 Conference (Boston, December 5-7), http://2006.xmlconference.org/proceedings/46/presentation.pdf, consulted August 2008.
- See Gerd Castan, Michael Good, and Perry Roland: Extensible Markup Language (XML) for Music Applications. An Introduction. In: The Virtual Score. Representation, Retrieval, Restoration. Ed. by Walter B. Hewlett and Eleanor Selfridge-Field. Cambridge (MA) 2001, pp. 95-102.
- Michael Good: MusicXML for Notation and Analysis. In Hewlett and Selfridge-Field 2001 (note 6), pp. 113-124. Also see http://www.recordare.com/xml/, consulted August 2008.
- See Walter B. Hewlett: MuseData. Multipurpose Representation. In Selfridge-Field 1997 (note 2), pp. 402-447.
- See David Huron: Humdrum and Kern. Selective Feature Encoding. In Selfridge-Field 1997 (note 2), pp. 375-401.
- Elliotte Rusty Harold: Effective XML. Boston 2004; Good 2006 (note 5).
- See Jacques Steyn: Framework for a Music Markup Language. In Proceedings of the First International Conference MAX 2002. Musical Application Using XML (Milan, September 19-20, 2002), pp. 22-29. Also see http://www.musicmarkup.info/, consulted August 2008.
- See Perry Roland: The Music Encoding Initiative (MEI). In Proceedings of the First International Conference MAX 2002 (note 11), pp. 50-55. Also see http://www.lib.virginia.edu/digital/resndev/mei/, consulted August 2008.
- See Pierfrancesco Bellini and Paolo Nesi: WEDELMUSIC Format. An XML Music Notation Format for Emerging Applications. In: Proceedings of the First International Conference on Web Delivering of Music (Florence, November 23-24, 2001), pp. 79-86.
- Pierfranceso Bellini, Paolo Nesi, and Giorgio Zoia: Symbolic Music Representation in MPEG. In: IEEE Multimedia 12/4, pp. 42-49. Also see http://www.interactivemusicnetwork.org/mpeg-ahg/, consulted August 2008.
- See Michael Good: MusicXML in Commercial Applications. In: Music Analysis East and West. Ed. by Walter Hewlett and Eleanor Selfridge-Field. Cambridge (MA) 2006, pp. 9-20.
- Johannes Kepper and Stefan Morent: Requirements for a Music-editorial Data Format. http://www.edirom.de/fileadmin/downloads/Requirements_for_Music_Encoding.pdf, consulted August 2008. The German version including all examples is reproduced in this volume, pp. 266-280.
- Cf. section Issues from Editorial Examples II and V, p. 172.
- Kepper and Morent 2007 (note 16).
- Kepper and Morent 2007 (note 16).
- Cf. Kepper and Morent 2007 (note 16).
- See Good 2006 (note 5).
- Theodor Dumitrescu: Corpus Mensurablis Musice ‘Electronicum’. Toward a Flexible Electronic Representation of Music in Mensural Notation. In: Hewlett and Selfridge-Field 2001 (note 6), pp. 3-18. Also see http://www.cmme.org/, consulted August 2008.
- Louis Barton et al.: The NEUMES Project. Digital Transcription of Medieval Chant Manuscripts. In: Proceedings of the Second International Conference on Web Delivering of Music (Darmstadt, December 9-11, 2002), pp. 211-218. Also see http://scribeserver.com/NEUMES/, consulted August 2008.