Michael Good
Recordare LLC
PO Box 3459
Los Altos, CA 94024
Reprinted with permission from Music Analysis East and West, Walter B. Hewlett and Eleanor Selfridge-Field, eds., MIT Press, Cambridge, MA, 2006, pp. 9-20. Computing in Musicology 14. Copyright © 2006 Center for Computer Assisted Research in the Humanities.
Abstract
We describe recent features and implementations of MusicXML 1.1 (May 2005). Current uses include the import and export of music notation files, the acquisition of scanned images of music, the support of digital music stands, and various applications in music education and research. As of November 2005, fifty applications have shipped or announced support for the MusicXML format, making it the first widely adopted format for symbolic music representation since MIDI. We discuss future directions, including the evolution of MusicXML from an interchange format to a distribution format.
Introduction
MusicXML is a format for representing common Western music notation from the seventeenth century onwards (Good, 2001a). It is based on the Extensible Markup Language (XML). MusicXML can represent both classical and popular music. It is intended to be extensible to coverage of the requirements of early music and to less-standard notation needs of twentieth and twenty-first century scores. MusicXML was designed in response to the opportunities posed by Internet music publishing.
When Recordare, the developer of MusicXML, was started in 2000, digital sheet-music was available for sale, but supported uses were limited to transposition, printing, and using it with proprietary music players, such as Sunhawk’s Solero system. These uses did not compare well to the flexibility of digital audio available in CD or MP3 formats, nor to the availability of websites in HTML format. At this writing (November 2005) proprietary formats (e.g., from MusicNotes, Sibelius, and Sunhawk) still dominate the market. They are coupled with more restrictive digital rights management than is found for audio files at sites like Apple’s iTunes Music Store.
Unsurprisingly, digital sheet-music currently has a smaller share of the print music market than digital downloads have of the audio market. The need for a well-accepted symbolic music interchange format more competent than MIDI has long been recognized. Prior attempts to create an interchange protocol include the NIFF and SMDL formats described (along with many others) in Beyond MIDI (Selfridge-Field, 1997). None of these previous efforts was widely adopted.
To circumvent the problems of past interchange formats, the design of MusicXML followed two main strategies. First, the design of MusicXML was based on two of the most powerful academic music formats for music notation: MuseData (Hewlett, 1997) and the Humdrum **kern format (Huron, 1997). Both formats have large music repertoires available and have been used for diverse music applications. A format that incorporates and grows beyond these successes would have a solid technical grounding.
Additionally, the MusicXML definition was developed iteratively with MusicXML software. The initial prototype software did two-way conversions to MuseData, read from NIFF files, and wrote to Standard MIDI Files (Format 1). Handling these three very different formats demonstrated that MusicXML’s basic interchange capabilities were solid. We then moved on to support interchange with MakeMusic’s Finale program.
Figure 1.1 “Before” and “after” views of J. S. Bach’s Fugue in C# Major from Book II of the Well Tempered Clavier via MusicXML 1.0 (c. 2001). The left-hand image shows the start of the MuseData (Stage 2) file, which is translated in the right-hand image to the first bars of the fugue. Finale’s layering feature has been used here to highlight the entry of each voice.
Figure 1.1 shows “before” and “after” views of a Bach fugue translated from the MuseData Stage 2 format (http://www.ccarh.org/publications/books/beyondmidionline/musedata) to display in Finale. More than one thousand encoded works of the classical repertory (2005) are available at http://musedata.ccarh.org. Most can be imported into Finale and Sibelius versions through 2005 via MusicXML. More than 800 additional works in the Humdrum format are available at Craig Stuart Sapp’s KernScores website http://kern.ccarh.org/ (Sapp 2005).
Iterative design and evolutionary delivery techniques have been used since the 1980s to produce more usable and useful computer systems (Gilb, 1988; Good, 1988; Gould and Lewis, 1985). With MusicXML, we have found that these techniques can also be successful in XML language design. Limited support for MusicXML 1.0 for music formatting was deemed to be the single greatest barrier to its use in Internet music publishing applications. In MusicXML 1.1 (May 2005) we added 70 new features to the MusicXML 1.0 language, most of which were focused on music notation formatting. The 1.1 additions and changes were carefully designed for upward compatibility, so that all MusicXML 1.0 files were also valid MusicXML 1.1 files. MusicXML 1.1 was soon adopted by major notation editing, scanning, and digital sheet-music sales applications.
Uses in Finale® and Sibelius®
Works prepared in either Finale or Sibelius can be exported to MusicXML and imported into the alternative program with the appropriate Dolet(s). In one recent instance wherein a show was transferred from a London West End stage to a Broadway one, the music team in London passed on its Sibelius files to Recordare for custom conversion, via MusicXML, to Finale, which was required for the Broadway production. (This took a single day.)
The 2005 releases of MusicXML 1.1, Finale 2006, and Sibelius 4 have greatly improved the translation process for music preparation applications. MusicXML 1.1 allows much more formatting information to be transferred between applications. These versions of Finale and Sibelius read MusicXML 1.1 files on both Windows and Macintosh OS X without the need for any additional plug-ins.
Writing MusicXML 1.1 files from Finale and Sibelius currently requires Recordare’s Dolet 3 plug-ins. These plug-ins rely on the development kits provided by those programs. Currently, Finale’s kit gives complete (if incompletely documented) access to Finale’s static musical data, and some access to dynamic musical data such as stem direction. Sibelius’s kit provides limited access to static musical data and no access to dynamic musical data. Sibelius 4 added many features to its plug-in developer kit, allowing Dolet 3 for Sibelius to export articulations, codas, segnos, system breaks, and page breaks. Stem direction, transpositions, and beaming are among the features that still cannot be exported accurately from Sibelius. Even with these limitations, the more complete interchange provided by MusicXML, compared to Standard MIDI Files, provides a large time savings when music files need to be transferred from Sibelius to Finale.
Finale 2006 and Finale PrintMusic 2006 read MusicXML 1.1 files and write MusicXML 1.0 files directly from the file menu. Dolet 3 (for Finale plug-in) allows Finale to write MusicXML 1.1 files, and supports previous Finale versions back to 2000 on Windows and 2004 on Macintosh OS X. Finale 2003 to 2005 on Windows can also read and write earlier versions of MusicXML files without additional software. Sibelius 4 reads MusicXML 1.1 files directly from the file menu. Writing MusicXML files requires Recordare’s Dolet for Sibelius plug-in. Dolet 1 for Sibelius writes MusicXML 1.0 files starting with Sibelius 2.1. The Dolet 3 for Sibelius plug-in adds the ability to write MusicXML 1.1 files from Sibelius 4.
Uses in Other Notation Applications
MusicXML was designed so that a single symbolic music file created in a program chosen by the user could be used in another program also chosen by the user. At this writing, 29 applications were shipping with MusicXML support, and another 21 applications had announced support in beta or prototype versions. Not all implementations are as extensive as those of Finale and Sibelius. Some read the format but do not write it, while others have the reverse capability. A few, like Finale and Sibelius, support operations in both directions.
The read-only programs are mainly related to score preparation and viewing. They include NOTION (Figure 1.2), MuseBook Score (Figure 1.4), OrganMuse, Overture 4, capella playAlong, SipXML-2Score (Kloe, 2005), MusicEase, Turandot, Igor Engraver, and Personal Composer. The write-only programs are mainly related to music acquisition and include SharpEye Music Reader (Figure 1.3), PhotoScore Professional, SCOREMAKER, and Java Music Specification Language (JMSL; see Didkovsky, 2004). Bidirectional programs include Harmony Assistant (a shareware program for music arranging) and several programs used by guitarists.
File transfer from Finale to other kinds of programs also occurs. Guitar music editions have been transferred from Finale to SCORE using the Dolet for Finale plug-in and SipXML (the MusicXML 1.0 predecessor of the SipXML-2Score program). Other companies have used MusicXML to transfer music from Finale to an in-house music typesetting software system.
Figure 1.2. Import via MusicXML of a contemporary score, Robert Kyle Hamilton’s Triages (2005), in NOTION. (Used by permission.)
Uses in Music Acquisition
When the first MusicXML products were shipped in 2001, Finale and Sibelius each had their own captive music-scanning program (Good and Actor 2003). Finale users were limited to the SmartScore product family and Sibelius users to the PhotoScore product family. Conversely, SmartScore users could only transfer music to Finale, and PhotoScore users could only transfer music to Sibelius. One of the most promising newcomers in music scanning, SharpEye Music Reader, could only communicate with these programs using MIDI files. This lack of competition was not healthy for either music-scanning software consumers nor for the advancement of music-scanning software technology.
Recordare selected Finale as its first support target because it was the only major music notation application with a full-featured plug-in software development kit that allowed us to both read and write MusicXML files. SharpEye Music Reader was the first application targeted for MusicXML support (September 2001). When Dolet 2 for Finale was released for Macintosh OS X (August 2004), it allowed Macintosh users the ability to choose between different scanning programs. This encouraged MakeMusic (Finale‘s owner) to add MusicXML support to the Windows version of Finale 2003. With MakeMusic’s 2006 releases, built-in MusicXML support expanded to Macintosh OS X and to the less-expensive PrintMusic product.
Figure 1.3. Screen capture and editing tools provided by SharpEye. Edited files exported to MusicXML may be processed further in notation programs supporting MusicXML import.
It was thus music scanning which provided the first illustration of how a music notation interchange format can lead to faster product innovation. Given the small size of the market for music notation software, this example is significant. Most companies have fewer than ten developers; many have just one or two. Writing to an interface format supported by industry-standard development tools is much more cost-effective than trying to support multiple proprietary formats. Much of the demand for music scanning software comes from people who are not music preparation professionals. Many customers have reported that they can now produce music in minutes, via scanning and editing, scores that used to take them hours to key in manually.
Sibelius’s initial response to Finale’s expanded scanning options was to add NIFF import to the Windows version of Sibelius, as both SmartScore and SharpEye Music Reader can export NIFF files. Sibelius’s experiences with NIFF are illustrative of why MusicXML has been much more widely adopted. Pitch representation proved to be a particularly problematic area. NIFF does not represent pitch directly (unless optional MIDI data is used). Instead it uses a graphical representation that describes where a note is positioned vertically on a staff. To determine pitch, we need to check the clef and key signature, then handle any accidentals that precede the note in this measure, then look for any accidentals affecting a note that may be tied to this one. Fortunately, the other basic element of music notation, the timing of the note, is represented much more directly. Yet the indirect nature of pitch representation makes NIFF less than optimal for most performance and analysis applications. (Good, 2001b)
Sibelius’s NIFF importer exhibited exactly this type of bug – getting the pitch incorrect by not checking for the accidentals in a note tied to the current note. The bug was present when Sibelius introduced NIFF import in version 2.1 and remained in version 3. NIFF provides all the data needed to translate these files correctly, but its difficult-to-use format has discouraged most software developers from adopting it. Sibelius dropped support for the NIFF format in version 4 and added MusicXML support on both Windows and Macintosh. Sibelius’s MusicXML importer is also superseding its Finale importer that relied on Finale’s Enigma Transportable File (ETF) format. ETF import is no longer supported for Finale 2006 files, and Sibelius recommends MusicXML import over ETF import for the files created with recent releases of Finale.
Uses in Electronic Music Stands
FreeHand Systems, Inc. released the first commercially available electronic music stand product, the FreeHand MusicPad Pro (freehandsystems.com), in 2003. A competing product called the eStand (estandmusic.com), which offers repertory from CD Sheet Music and Hal Leonard Corp., was released in 2005. These products display music and allow hands-free page turns. The FreeHand and eStand systems also include annotation capabilities. Both rely (2005) on music images rather than a symbolic model with musical meaning.
Figure 1.4. Instructions for the use of MuseBook Score (from AMuseTec Co., Ltd.). The musical displays are based on the MusicXML format.
In contrast, MuseBook Score (www.musebook.com) from AMuseTec Co., Ltd., is the first commercial product to use a symbolic music representation, the MusicXML format, to present repertory on an electronic music stand (Figure 1.4). The initial version of MuseBook Score, released in 2004, displayed MusicXML files of piano music on a Windows PC, then “listened” to a performance of the piece. The performance could be on either an acoustic piano with a microphone attached to the soundboard or a MIDI keyboard connected to the computer. The system attempts to match the performed music to what is in the MusicXML score. The notes are animated as you play, and pages are turned automatically in “Dutch door” fashion once you reach the last system on a page (with the first system of the next page replacing the first system of the current page). The next page is displayed it its entirety once its first system is reached. In this way, the next system of music is always in the performer’s view.
The OrganMuse product works similarly for organ music and MIDI-equipped organs, adding the ability to memorize and automatically perform registration changes.
Uses in Internet Publishing
The musicRAIN 2.0 player (November 2005) uses the MusicXML 1.1 format to create digital sheet-music with formatting faithful to its Finale source. The musicRAIN player runs in a web browser, using Macromedia Flash Player 8. The player allows for transposition for printing and playback. The digital rights management (DRM) provided is similar to what is available in other digital sheet-music sales applications. The MusicXML files are not delivered directly to the end user, however. Thus the capabilities offered by the musicRAIN player give digital sheet-music retailers a solution for Finale files roughly comparable to that provided by the Scorch player for Sibelius files. Project Gutenberg’s sheet-music project has adopted MusicXML for use in its electronic archive of music in the public domain.
Uses in Music Education
Several uses of MusicXML are currently active and others are under development in software for music education. Accompaniment systems, which help performers practice their parts by hearing the rest of the music in the piece, offer an apt example of those in use. MusicXML files can be read into version 2 of the capella playAlong program, which then produces an accompaniment CD that contains the score minus your part. Similarly, MusicXML files can be read into Finale in order to produce SmartMusic files. SmartMusic can track you as you play into a microphone attached to the computer, following your tempo changes, cadenzas, and fermatas.
Initiatives involving MusicXML are under development with a cluster of European educational programs that are associated with the Vemus tools made available by GRAME (Lyons, France). Collaborators are located in Greece, Sweden, Lithuania, Roumania, and Estonia, as well as France and Belgium. Another MusicXML program, MusicAlign, is in preliminary development in Belgium by Joachim Ganseman.
Several projects are investigating the possible use of MusicXML to produce music in the different dialects of Braille used in the USA and Europe (Encelle, 2003; Kahlisch, Leopold, and Waldvogel, 2004; McCann and Milani, 2003). The KlavarScript program translates from MusicXML into Klavar notation or Klavarscribo, a format invented in the Netherlands in 1931 to provide an easier way to read music.
Future Directions
The initial goal for MusicXML was to facilitate Internet music publishing, and some steps have been taken in this direction. To date we have not seen MusicXML put to widespread use as a consumer format for this purpose. New features, including compression and digital rights management, may be needed to make MusicXML as attractive for commercial distribution as it is for interchange. Raw MusicXML files are very large, but simple zip compression can make them even smaller than MIDI files for the corresponding piece. A standard compressed MusicXML format could make people more willing to publish, download, and share public-domain music and their own compositions in MusicXML format.
To some extent, the desire for interchange and rights management are conflicting goals. An interchange format is intended to make files readable everywhere, while rights management is intended to control use. It seems likely that MusicXML will need to be distributed within a container format that can be protected with DRM technology. MPEG-4 and Adobe’s PDF formats are two leading contenders for this container role. For commercial success, we expect that the music industry’s move to less restrictive DRMs for audio files will need to be extended to music notation files.
Our future MusicXML efforts will attempt to address these issues. We have seen ever-increasing progress both in software technology and in the business environment for Internet music. MusicXML 1.1 has shown the power of having a standard interchange format for digital sheet-music. We anticipate even greater benefits when MusicXML can also be used as a distribution format.
Acknowledgements
Eleanor Selfridge-Field, Walter Hewlett, Barry Vercoe, and David Huron provided the most important prior art and ongoing encouragement for the early development of MusicXML. Curtis Morley and the musicRAIN team made major contributions to the MusicXML 1.1 project. Geri Actor, Graham Jones, Doill Jung, Don Byrd, Craig Stuart Sapp, Jane Singer, and the many members of the MusicXML mailing list have made great contributions to the MusicXML community over the past six years.
References
Baird, Kevin C. (2004). “Generating Music Notation in Real Time,” Linux Journal, 128, 72-76.
Clemmons, William (2002). “New Standards and Emerging Technologies: A Rhythm Tutor with MusicXML and Finale,” Association for Technology in Music Instruction (ATMI) Annual Conference (Kansas City).
Didkovsky, Nick (2004). “Java Music Specification Language, V103 Update” in Proceedings of ICMC 2004 (Miami, November 1-6, 2004).
Encelle, Benoit (2003). “Transcriptions Between MusicXML and PLAY Code,” Music and Braille International Exhibition (Madrid). See www.dodiesis.com/asp/CONFMusicXMLPLAY.asp?language=2
Gilb, Tom (1988). Principles of Software Engineering Management. Reading, MA: Addison-Wesley.
Good, Michael (1988). “Software Usability Engineering” in Digital Technical Journal, 6, 125-133. R/ at www.recordare.com/good/dtj.html
Good, Michael (2001a). “MusicXML for Notation and Analysis” in The Virtual Score: Representation, Retrieval, Restoration (Computing in Musicology 12), ed. Walter Hewlett and Eleanor Selfridge-Field (Cambridge, MA: The MIT Press), 113-124.
Good, Michael (2001b). “MusicXML: An Internet-Friendly Format for Sheet Music.” XML 2001 (Orlando, FL). See www.idealliance.org/papers/xml2001/papers/html/03-04-05.html
Good, Michael (2002). “MusicXML in Practice: Issues in Translation and Analysis” in Proceedings First International Conference MAX 2002: Musical Application Using XML (Milan), 47-54.
Good, Michael and Geri Actor (2003). “Using MusicXML for File Interchange” in Proceedings Third International Conference on WEB Delivering of Music (Leeds, UK), Los Alamitos, CA: IEEE Press, p. 153.
Gould, John D. and Clayton Lewis (1985). “Designing for Usability: Key Principles and What Designers Think” in Communications of the ACM, 28/3, 300-311.
Hewlett, Walter B. (1997). “MuseData: Multipurpose Representation” in E. Selfridge-Field, ed., Beyond MIDI (Cambridge, MA: The MIT Press), pp. 402-447.
Huron, David. (1997). “Humdrum and Kern: Selective Feature Encoding” in E. Selfridge-Field, ed., Beyond MIDI (Cambridge, MA: The MIT Press), pp. 375-401.
Kahlisch, Thomas, Matthias Leopold, and Christian Waldvogel (2004). “DaCapo – A Project on Transforming Ink Printed to Braille Notes Semi-Automatically: The Project’s Current State” in Proceedings of the 9th International Conference on Computers Helping People with Special Needs (Paris), Heidelberg: Springer-Verlag (Lecture Notes in Computer Science, Vol. 3118), 224-227.
Kloe, Jan de (2005). SIP Newsletter #24: www.dekloe.be/SipNews024.htm
McCann, William R. and Albert M. Milani, Jr. (2003). “Dancing Dots Braille Music Technology.” Music and Braille International Exhibition (Madrid). See www.dodiesis.com/asp/CONFDancingDots.asp?language=2
Santana, Hugo Pimentel de, Márcio Leal de Melo Dahia, Ernesto Trajano de Lima, and Geber Lisboa Ramalho (2003). “VExPat: An Analysis Tool for the Discovery of Musical Patterns” in Proceedings of the IX. Brazilian Symposium on Computer Music, I, 14-21.
Sapp, Craig Stuart (2005). “Online Database of Scores in the Humdrum File Format” in Proc. ISMIR 2005 6th International Conference on Music Information Retrieval (London), 664-665. See ismir2005.ismir.net/proceedings/3123.pdf
Selfridge-Field, Eleanor, ed. (1997). Beyond MIDI: The Handbook of Musical Codes. Cambridge, MA: The MIT Press, 1997.
Tremblay, Guy and France Champagne (2002). “Automatic Marking of Musical Dictations By Applying the Edit Distance Algorithm On a Symbolic Music Representation” in Proceedings First International Conference MAX 2002: Musical Application Using XML (Milan), 11-17.