Recordare Main Navigation Menu Recordare

MusicXML FAQ

Frequently Asked Questions

Why do we need a new music format?

There are many fine computer music programs in the world. Unfortunately, sharing music between them has been difficult. This is a real problem since no one program can do everything equally well. Having to reenter musical data for each program you want to use is a big inconvenience to everyone who uses more than one music software program.

Before MusicXML, the only music interchange format commonly supported was MIDI. MIDI is a wonderful format for performance applications like sequencers, but it is not so wonderful for other applications like music notation. MIDI does not know the difference between an F-sharp and a G-flat; it does not represent stem direction, beams, repeats, slurs, measures, and many other aspects of notation.

People had recognized for years that a new interchange format was needed, but no prior attempt at creating a new standard format had succeeded. NIFF had probably been the most successful attempt to date, but its use is very limited and the format is not being maintained. SMDL was the most ambitious attempt, but we know of no software actually using it.

At Recordare, we are excited by the possibilities of Internet music publishing just as many other people and companies are. But if you go to existing sites like Sunhawk and MusicNotes, you find that all you can do with their music is 1) print it or 2) play it back in their proprietary player. Sites that only use PDF files offer even less to consumers. If that is all you can do with online music, why get it online instead of on paper? That seems to be the reaction of most people, based on all published industry reports of online sheet music sales up through 2005.

We believe that an Internet-friendly standard format is necessary for the growth of the Internet music publishing market. Today it is like using the Internet before HTML was invented, or using synthesizers before MIDI was invented.

Why not use an existing format like NIFF or SMDL?

NIFF and SMDL were noble efforts to solve the same type of interchange problem that MusicXML addresses. So why don't we use them rather than inventing something new?

NIFF represents music using a graphical format. There is no concept of a "C" in NIFF: instead, you determine pitch by its placement on a staff. This type of graphical music representation has a long and distinguished history. It works well for the scanning programs that were the focus of NIFF's work. But it works poorly for many other types of applications, such as sequencing and musical databases. For both of these applications, MIDI works much better than NIFF; for notation, though, NIFF is more complete than MIDI. MusicXML is designed to meet the interchange needs for all these types of applications.

A graphical format like NIFF really does not work well for general interchange, which is one of the main reasons NIFF has not been adopted by more programs. Another major impediment is that NIFF is a binary format, rather than a text format like XML. It is much easier to write and debug programs that read and write to a text format vs. a binary format.

SMDL suffered from the problem of trying to be a general-purpose solution to the problem of representing all possible musics of the past, present, and future. In addition, the project was not grounded in practical implementation experience. The result was something so complicated that practically nobody can understand it. The overwhelming complexity has greatly inhibited SMDL's adoption - it certainly inhibited us! - and we know of no commercial software that supports it.

Where did the design of MusicXML come from?

MusicXML was based primarily on two academic music formats:

  • The MuseData format, developed by Walter Hewlett at the Center for Computer Assisted Research in the Humanities (CCARH), located at Stanford University
     
  • The Humdrum format, developed by David Huron, based at Ohio State University.

Eleanor Selfridge-Field from CCARH edited a magnificent book called Beyond MIDI: The Handbook of Musical Codes. Studying this volume made it clear that, as we had been advised, MuseData and Humdrum were the most comprehensive starting points for the type of language we wanted to build.

MusicXML is basically an XML updating of MuseData, with the addition of some key concepts from Humdrum. Since both formats have been used primarily for work in classical and folk music, MusicXML was extended beyond those boundaries to better support contemporary popular music.

Why do you use XML?

XML was designed to solve exactly the type of problem we face today in music software. Say you have 100 music applications, each with its own format. For each application to communicate with the other, 10,000 separate programs would need to be written without a common interface language! With a common interface language, each application writes only one program, so only 100 separate programs would be required. Consumers gain enormous value at relatively small cost to the software developer.

XML builds on decades of experience with its predecessor SGML, as well as the experience with the explosive growth of HTML and the Web. XML hits the magic "sweet spot" between simplicity and power, just as HTML and MIDI have done in the past. It is designed to represent complex, structured data, and musical scores fit that description.

Using XML frees us from worrying about the basic syntax of the language, instead letting us worry about the semantics - what to represent, versus the syntax of how to represent it. Similarly, there is no need to write a low-level parser to read the language: XML parsers exist everywhere. Basing a music interchange language on XML lets music software, a relatively small community, leverage the investment in tools made by much larger markets such as electronic commerce.

Is MusicXML free?

The MusicXML DTD is available under a royalty-free license from Recordare. This license is modeled on those from the World Wide Web Consortium (W3C). If you follow the terms of the license, you do not need to pay anyone to use MusicXML in your products or research. Recordare has no patents issued or pending for the MusicXML DTD.

Is your software open source?

No. We believe that making the MusicXML definition freely available is essential for its spread into the music industry. We do not see a similar advantage to making our own software free or open source. We do not charge people to beta test our software, but we do charge for production versions of our software.

We encourage people to build more applications using MusicXML. There are many potential applications, and no one company or group can do everything. If you want to make your software open source, that is fine with us.

Who is using MusicXML?

Many companies and music software developers are using MusicXML in their products, including:

  • Finale
  • PrintMusic
  • Sibelius
  • SharpEye Music Reader
  • capella professional
  • capella-scan
  • capella playAlong
  • Dolet 4 for Finale
  • Dolet 3 for Sibelius
  • musicRAIN
  • Notion
  • MuseBook Score
  • OrganMuse
  • AudioScore Professional
  • SipXML2Score
  • Rosegarden
  • LilyPond
  • JMSL
  • MusicEase
  • TaBazar
  • TablEdit
  • Humdrum Extras
  • pae2xml (Plaine and Easie)

See our MusicXML software page at http://www.musicxml.org/xml/software.html for a more complete description and links.

What software tools are available?

One of the great things about basing our work on XML is that there are tools available for practically every computer platform.

At Recordare, we used Microsoft tools for our first generation of Dolet software. The original Dolet for Finale plug-in was written in a mix of Visual Basic 6.0 and Visual C++ 6.0, using Microsoft's MSXML parser. The Microsoft parser is designed to be easy to use within Visual Basic and succeeds admirably. We had great success with it.

We then rewrote the Dolet for Finale plug-in in Java and C++ so that our software could run on Macintosh OS X as well as Windows. Many other projects are using Java for multiple platforms, including Linux. We are using the Xerces parser from the Apache group, as are most of the other Java-based MusicXML projects that we know. It also works very well for us. We have also heard good reports about the Xerces C++ parser. Other projects use the built-in XML support provided by Flash and Python.

If all you want to do is write MusicXML files, not read them, you really don't need a parser, though you may find it useful. A scanner like SharpEye Music Reader, for instance, does not have any great need to read MusicXML files. Its MusicXML support is written in C, like the rest of the program, without using any special XML tools. The pae2xml translator is written in Perl. The Dolet 3 for Sibelius plug-in is written in ManuScript. You can also use XSLT to read and transform MusicXML files.

There are many XML sites that can guide you to XML tools beyond what we list here. If you are using an XML parser, in most cases you will probably be using the XML DOM (Document Object Model) to handle MusicXML files. Good DOM support is likely to be more important than SAX support for MusicXML programs.

Why do you use a DTD instead of a schema?

When we started developing MusicXML, a DTD (Document Type Definition) was the only official W3C recommendation for defining an XML document. Since that time, XML Schemas have become an official W3C recommendation, and alternative schema languages like RELAX NG have also become available.

W3C XML Schemas offer many benefits when using XML in electronic commerce and business database applications. For musical documents, though, the advantages are less compelling. The added complexity seems to cost much more than what can be gained from a more precise document definition.

Relax NG is a promising alternative, but suffers from a lack of development tools. You cannot validate against Relax NG using the most common XML parsers like you can with DTDs. Validation is an important technology when you need to support customers who are passing files between 50 different applications. DTDs give developers freedom of choice, and MusicXML developers have taken full advantage of this with implementations in Java, C++, Visual Basic 6.0, Perl, Python, C, ManuScript, ActionScript 2.0, C#, Ada, and probably more. Not all of these projects use validating parsers, but DTDs retain a large lead in tool support compared to Relax NG.

DTDs are not going away. They are a stable part of XML technology. MusicXML 1.1 has stayed with this well-understood, well-supported part of XML.

Why do you use all these elements instead of attributes?

This is mainly a stylistic decision. Several XML books advise representing semantics in elements rather than attributes where possible. One advantage of doing this is that elements have structure, but attributes do not. If you find that what you are representing really has more than one part, you can create a hierarchical structure with an element. With attributes, you are limited to an unordered list. For information retrieval applications, it can also be easier to search directly for elements rather than for attribute/element combinations.

In MusicXML, attributes are generally limited to a few uses:

  • To indicate if this is where an element starts or stops, such as for slurs and tuplets.
  • To identify elements, as in measure numbers or beam levels.
  • To suggest how an element would best be printed.
  • To suggest how an element would best be converted into MIDI or other sound formats.

In MusicXML 1.1, the third category - suggesting how an element would best be printed - has grown enormously. So you will find that MusicXML 1.1 files make much more use of attributes than do MusicXML 1.0 files. The principles determining when to use elements and when to use attributes have remained the same.

In summary, we follow common recommended practice by using elements for data and attributes for metadata. We find this works well. Certainly there are DTDs in other domains that use attributes much more extensively, and they work well too. Either way can do the job as long as it is applied consistently.

While there are a lot of MusicXML elements, we have tried to limit them to elements that directly represent musical concepts. We have tried to avoid using elements that would introduce concepts not found in musical scores. For example, there is no "timeslice" element as found in formats like NIFF. We have generally found that we can represent what applications need without having to introduce artificial elements.

Why is MusicXML so verbose? Isn't that inefficient?

MusicXML is an interchange format. Ease of comprehension is much more important than terseness. Musical representation is complex enough without trying to figure out an abbreviated code. The XML specification advises that "terseness in XML markup is of minimal importance", and we believe this is really true. Somebody who understands the domain should be able to figure out the basics of an XML file simply by reading it. We believe that MusicXML meets this goal, where several other musical XML proposals do not.

There is of course a place for terse text formats like abc or Plaine and Easie, which allow easy and fast text entry of musical data. There are converters for both abc and the Plaine and Easie codes to MusicXML.

Uncompressed XML indeed takes up a lot of space, but XML files compress very well using standard tools like WinZip. The four-page Joplin rag on our web site takes up 514K in its uncompressed form, but compresses to only 19K using WinZip. This is even smaller than the MIDI representation, which is 21K, and the XML contains much more data about the music.

Why do I see text instead of music when I look at a MusicXML file in my browser?

Building high-quality music display programs is hard work. Programs like Finale and Sibelius are the results of a great many person-years of difficult programming work.

It would be possible to build an XSLT stylesheet to convert MusicXML into a web-readable format, and a proof of concept for this was done by one MusicXML user. But making something of professional quality is much harder.

A better approach is to build an application that can read MusicXML files and then display and play the results in a web browser. The musicRAIN 2.0 player takes this approach. It is built with the Macromedia Flash Player, so no additional downloads are needed to display, transpose, and play music in your web browser. It is part of a digital sheet music sales solution offered to retailers. See http://www.mediarain.com/musicrain/ for more details.

How do you pronounce Recordare?

Recordare is Latin for "remember", so the pronunciation is as in Latin or Italian (reh-cor-DAH-ray). Internet publishing will allow musical works to be remembered and performed more widely. We believe a standard Internet-friendly format like MusicXML is essential for the success of Internet music publishing.

FAQ - Hello World - File Structure - MIDI-Compatible - Notation Basics - Tablature - Percussion - Advanced

Home - Music - Software - MusicXML - Tutorial - Events - Search - Store - About Us

Copyright © 2008 Recordare LLC.

Last updated January 2, 2008.