W3C home > Mailing lists > Public > public-xg-audio@w3.org > December 2010

Re: Music Notation on the Web

From: Michael Good <musicxml@gmail.com>
Date: Sun, 12 Dec 2010 11:45:37 -0800
Message-ID: <AANLkTi=c3fOfZtdtz33MzP5S=2H36_sYs46SLCT6juqx@mail.gmail.com>
To: public-xg-audio@w3.org
Hi Roger,

I'm sorry that you did not have a good experience with MusicXML. Without
more information, though, it is difficult to know how to respond. What
versions of Finale and Sibelius were you using? Things are much better now
with Finale 2011b and Sibelius 6.2 than they were with Finale 2003 and
Sibelius 4, the first versions of those programs to include built-in
MusicXML support.

It would be great to know what your experience is now with contemporary
notation software. Like any other software, MusicXML converters have bugs.
If you report the bugs to the software maker that can help in fixing them
for the future. If you send us a source file that demonstrates the problems,
Recordare can serve as a resource to determine where the problem resides and
which company to report it to.

As Joe mentioned, one of the complexities of music notation is that
formatting conveys semantics. Take a crescendo wedge, for instance. Its
horizontal position communicates semantics in continuous units (where does
the crescendo start and stop), while its vertical position communicates
semantics in discrete units (which instrument has the crescendo). Even that
is oversimplified, in both dimensions, for instruments like a piano.
MusicXML separates formatting and performance details into XML attributes
and special-purpose <print> and <sound> elements, while reserving musical
semantics for elements. But since the two are intertwined, separating them
into separate representations is unsatisfactory for most professional use

Regarding point 1: What is the use case for having alphabetic input of
notation be the same representation as a general-purpose representation for
music notation and playback? The abc format does a great job for its
intended use case of typing up simple folk tunes, but is wholly inadequate
for polyphonic, multi-part music.

This is an example of a very common and serious problem with music notation
software. Solutions that look acceptable for simple or
constrained situations fail to generalize to the full complexity of common
Western music notation, with all its corner cases. People inexperienced in
the field of music notation software stumble into this problem repeatedly,
which leads to a lot of fruitless labor and abandoned projects.

Regarding point 2: As I mentioned in my earlier reply, the lack of
availability of MusicXML files for public domain music on the web relates
both to software and marketing. To elaborate, public domain sites need the
compressed MusicXML 2.0 format to make the hosting of MusicXML files
efficient both for disk space and bandwidth. Not all programs handle
compressed MusicXML files yet. We are working on a free tool to convert back
and forth between .xml and .mxl files. Once that is in place, we then need
to market more effectively to public domain music sites. We have a list of
sites that offer music in MusicXML and related formats at:


But of course PDF files will be more popular than MusicXML files for the
near future, simply because it is much easier to scan music from a library
than to reenter the music in a notation program. If the PDF was generated
from a notation program, PDFtoMusic Pro can do an awfully good job of
recovering the semantics. For scans, though, optical scanning programs like
PhotoScore / SmartScore / capella-scan / SharpEye are more limited in what
they can recognize.

Regarding point 3: As previously discussed, you cannot separate content from
formatting and have a usable professional solution, because formatting is
part of content in music notation. MusicXML 1.0 had far less formatting
information than MusicXML 2.0. The number 1 customer request for
improvements to MusicXML 1.0 - by far, nothing else was remotely close - was
to add enough formatting to make MusicXML a lossless format for the visual
appearance of common Western music notation. We're not 100% there yet,
but Finale's MusicXML export is awfully close to being lossless, and web
based programs like Legato rely on this to provide services to CCLI and
other customers that are doing web-based music notation.

There have been many other efforts to standardize a music notation format
for interchange. ISO has two between SMDL and MPEG SMR. along with IEEE 1599
and NIFF. All were failures, and only one of those four (NIFF) had any
adoption whatsoever. The recent efforts (MPEG SMR and IEEE 1599) were doomed
to failure from the start since they were competing with MusicXML without
offering significant advantages, and thus were ignored by the music software
industry. There is lots more information on these issues in my XML 2006
paper, available at:


MusicXML is used by nearly every music notation software vendor in the
market - both the established players like Finale and Sibelius, and the new
entrants like Noteflight and the new iOS music notation programs, as well as
academic research programs like music21, MelodicMatch, and Ptolemaic. There
are some new programs yet to be written to get music available in a standard
web browser rather than relying on Flash or custom plug-ins. Among the
things such programs are waiting for is the audio API! It's a matter of
software technology, not the underlying music notation representation.

Throwing away a decade of music notation industry work in building a common
Internet-friendly music notation format would be counterproductive. The
problems for distributing music notation on the web are due to building out
the necessary software - which is very difficult, no matter what
representation you use - and the business issues that have plagued all
aspects of Internet music over the past decade. It's not due to the lack of
an adequate representation format.

Best regards,

Michael Good
Recordare LLC
Received on Sunday, 12 December 2010 19:46:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:59 UTC