- From: Michael Good <musicxml@gmail.com>
- Date: Sun, 12 Dec 2010 11:45:37 -0800
- To: public-xg-audio@w3.org
- Message-ID: <AANLkTi=c3fOfZtdtz33MzP5S=2H36_sYs46SLCT6juqx@mail.gmail.com>
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 cases. 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: http://www.recordare.com/musicxml/music 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: http://www.recordare.com/musicxml/xml-2006/lessons-adoption-musicxml-interchange-standard 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 CEO Recordare LLC www.recordare.com
Received on Sunday, 12 December 2010 19:46:11 UTC