MusicXML

MusicXML allows sharing of music notation between MusicXML-ready music notation applications. Most major brands of music notation software have adopted MusicMXL as their interchange standard.

MusicXML notation interchange, or any proposed notation interchange, works like sharing text documents through Rich Text Format (often called RTF), but the 'go-between' file format is an XML data structure; the targeted documents are music scores.

MusicMXL triumphs where NIFF (Notation Interchange File Format) failed. Widespread adoption is a significant part of MusicXML's success, making it today's de facto industry standard ...and the likely standard for some time to come.

Recordare designed and developed the MusicXML format. It states on its web page that MusicXML has other potential beyond musical score file exchange, proposing that MusicXML 2.0 "will soon serve the same role for interactive sheet music that MP3 files serve for recorded music." That's quite a claim, and this potential is yet to be seen.

Presently file interchange is the primary benefit for most notation applications. This alone is exciting news, but before we get too swept up, let's understand what MusicXML is not. MusicXML file interchange is not equivalent to file compatibility or file import. It's NOT a means of opening a Finale or Sibelius score directly in Encore ... nor is it a means of opening an Encore file in Finale or Sibelius. It is merely a means of exporting to a format that is readable by other MusicXML savvy notation applications.

Using MusicXML

Note: I'll speak here largely with reference to Encore 5, available for Macintosh and Windows, as it is my preferred music notation software.

Import and export are largely transparent to the user. In Encore you simply choose File>Export>MusicXML. similarly, in the application to which you intend to import, choose File>Import>MusicXML. It should be this simple in other applications as well.

Any application that reads MusicXML can open an Encore MusicXML file. Conversely, Encore can open MusicXML files generated by other notation applications. In other words, because Encore supports MusicXML you can export an Encore score to a MusicXML file. Other notation applications that read MusicXML (such as Finale and Sibelius) can open this XML representation of your score, with most or all aspects intact.

In the past people have become accustomed to using MIDI export because it was the only tool available. For notation exchange purposes MusicXML is far superior to MIDI export. MIDI exports only include notes, volumes, instrumentation (patches), basic effects like reverb, and details specific to the sound and timing. A MusicXML export contains lots more information. It has all the MIDI data, plus details essential to the score and its readability, such as: clefs, lines per page, measure per line, dynamic marks, articulations, lyrics, text, slurs, stem direction, tablature, repeat signs, endings ... the list goes on.

You can create scores in Encore and save to MusicXML knowing that a Finale or Sibelius will be able to open your score with all the aforementioned features intact. If your publisher wants your scores in Finale format, but your prefer working in Encore, try sending MusicXML files. Conversion on their end my suffice for their needs. Nevertheless, details and essentials may get lost along the way.

Well, that's the promise and indeed a legitimate and attainable end, but let's look again at the RTF analogy.

An RTF exported a word processing document may lose some aspects of formatting or layout during export or import phase. Usually all the words come through, as well as basic formatting such as font faces, styles and sizes, but highly specialized typographical issues may be ignored, such as kerning, tracking, ligatures, and true fractions. Column layout and image positioning are commonly lost or distorted.

Similarly there's a potential for loss of detail when sharing scores via MusicXML. Layout and notational features may be lost two main ways:

1) A notation application may fail to export all the features and aspects of a score to the MusicXML document it creates.

have internal features that it fails to translate to MusicXML. Thus the MusicXML export is a subset of the score itself.

2) An importing notation application may not support all the features in a MusicXML file which came from a more advanced program. In such cases the importing application simply ignores those features and they are permanently lost.

Reports and Silent Failures:

Ideally applications will report on issues that will affect the score during import or export. An application knows when it encounters a object, property or feature that it does not include in MusicXML exports, therefore it should provide a list of unexported elements, features and properties.

Just the same, an importing application knows when it encounters a object, properties or features that it ignores or discards; it should provide a list of unimported elements, features and properties.

Without such reports users will have to examine every measure to see if details have been successfully transferred. Few things are more frustrating than silent failures or silent ineptitude, being led down a path ... thinking that your export is complete, or that another application will have the capacity to import all of it's characteristics.

I'd always recommend testing to see if an application can import its own XML exports. Visually compare the original score to the exported/reimported XML data. If they're not identical then the software's export or import functions must be improved before it's MusicMXL export or import can be trusted.

The Promise of MusicXML and Application Independence

For many years notation software companies have enforced "customer loyalty" in part by proprietary file formats—a scenario often referred to as 'vendor lock.' Widespread, full adoption of MusicXML could solve this problem.

Vendor lock works like this.

You want to switch from NotSoGreatNotationSoftware to VeryPopularNotationSoftware. However, through no fault of its own, VeryPopularNotationSoftware can't read NotSoGreatNotationSoftware's file format, which is a proprietary format and a closely guarded secret. Even if VeryPopularNotationSoftware cracked the code to be able to read NotSoGreatNotationSoftware's scores, NotSoGreatNotationSoftware may up the ante with needless changes in file format ... so that scores created by (or saved by) NotSoGreat's latest software will again be unreadable to VeryPopularNotationSoftware ... until someone again cracks the code.

If you're a long-time user of NotSoGreatNotationSoftware, you're in a bind. Even if you switch to VeryPopularNotationSoftware you won't be able to open, edit or print your existing NotSoGreatNotationSoftware scores. You'll have to continue using your old software to do so.

If you have no need for opening your legacy scores in the new software (an unlikely condition for those who have created large libraries of scores) then you're free to jump ship. Just be clear, this means leaving your old scores readable and printable only from the old software which you no longer want to use. It also means your may incur an unpleasant financial burden as you may need to continue buying updates of NotSoGreatNotationSoftware' to cope with evolving OS issues, issues with printer drivers, etc.

Not an ideal situation or transition!

Some people go to desperate lengths in attempting to fully free themselves. MIDI export is not an ideal option, because you'd only get the notes, time signature and expression; you loose LOTS of score details, including layout, lyrics, slurs ... this list goes on. Thus I've heard of extreme efforts such as printing every score, scanning, and importing, and then examining and fussing over every detail to make sure each new score matches the old one.

How Music XML would help

Once the promise of MusicMXL is fulfilled, vendor lock becomes a thing of the past. It will level the playing field among notation applications, forcing them to compete on usability, workflow, and features. That day has not yet fully dawned. However if notation companies fully embrace MusicXML, the promise may occur soon enough.

An extreme example of the ideal interchange dream goes something like this. Via MusicXML interchange, you'll be able to edit a score in various applications, switching between them due to strengths, aptitudes and usability, choosing the tool that best fulfills a particular task. When you're done with the heavy lifting, you can open the MusicXML file in your favorite 'polishing' application and add the finishing touches. Presently this is not entirely possible because not all vendors support all MusicMXL properties. Most overlooked are issues of layout, such as measures per line and lines per page. And there are many small details that may be lost, and that can really trip you up.

As MusicXML adoption and development continue, the future benefits of MusicXML will unfold. Ultimately MusicXML may allow notational application independence. It's up to developers to keep up with the evolving MusicXML standard. Conversely MusicXML must keep stride with features and innovations created by notation developers.

The present MusicMXL specification is very thorough. Hopefully vendors will step up to the plate. Recordare claims that over 80 notation offerings are already on board at some level. Please encourage your software company to do so.

Before long most of those using music notation software will benefit directly from MusicXML.