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.
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.