MusicXML DTD Hits 1.0; Browser Support Next?

base_chakra writes "Two years since its initial release, the MusicXML music notation document type has finally reached v1.0. MusicXML is an (you guessed it) XML-based musical score format developed by Recordare LLC, and derived from the MuseData and Humdrum projects. Although MusicXML was quickly adopted by virtually every major music notation software products available, a standard non-binary format for rendering music notation on the web is something that's still sorely needed. Despite its unfortunate limitations, will MusicXML eventually become the de facto means of rendering music notation online, or will it fall into obscurity like so many document types?"

Comments

Easy answer

[ENOENT]

If the format is open and free, then it has a good chance of becoming widespread. Otherwise, no.

Thanks for asking.

Re:Easy answer

[mhesseltine]

Examples of widespread file formats:

• MS Word
• MS Excel
• MS Powerpoint
• Macromedia Flash
• Autocad DWG (if you're into engineering)
• Adobe Pagemaker
• Quicken data files

I'm sorry to say, but marketing seems to have a much more profound effect on the spread of a file format than its openness and freedom.

Re:Easy answer

[mhesseltine]

From the AC:

Hrm, did you mention HTML and PDF?

HTML I'll give you as a well-supported open standard file format. PDF, not as much, but better supported than the MS formats.

I suppose for balance, supported documented file formats would include:

• JPEG
• HTML
• CSS
• Mpeg video
• RTF
• Text (duh)

And, for further comparison, well documented open formats that somehow just don't seem to be as widespread as you might hope:

• TeX
• PNG
• Postscript
• The slashdot favorite Ogg Vorbis or just plain OGG

A blanket statement really can't cover all the possibilities. It just seems that despite the advantages to open formats, the market just doesn't seem to care right now.

SVG First

[bay43270]

We still can't get good SVG support in a browser (unless you have IE on window/mac and Adobe's plugin installed). I can't imagine supporting MusicXML in the browser before SVG... besides, once SVG is supported, XSLT should be able to transform MusicXML to SVG, SVG Print, or PDF.

Unfortunate Limitations

[lordvdr]

I think they are being very reasonable with their licensing structures.
1: The Format is fee-free provided you follow the license
2: The software is not free/OS. SO? Not everything should be free. I am ALL about OO.o and Linux, and whatnot, but trying to claim that all software should be free is just stupid, and giving list "unfortunate limitations" jab is unfair.

Would you prefer the XML format they designed to be GPLed? Wouldn't that make it useless? Everyone could modify the format and then you wouldn't have a standard format?

-lv

p.s. Here come the GPL flames. Bring it on!!!!

Re:Unfortunate Limitations

[adrianbaugh]

How is their standard not free? (I don't mean their particular application; I don't care one way or the other about that.) I didn't see any particular gotchas in the license; they say they want it to catch on as widely as possible, that they want as many applications to use it as possible and that they don't care if you want to make your application open source. The only possible thing I can think of is a hidden patent, but using XML to represent discrete events (notes) would seem kind of obvious, no? There must be tons of prior art.

Or is there some kind of zealots' vendetta going on, of which I was not previously aware?

The trouble with XML

[91degrees]

It makes files so absolutely huge. Even something like "A" is a least 14 bytes, whereas in a binary format, it would probably be 2 at most (identifier byte and note byte).

Binary formats, while harder to design for extendibility when using this sort of data, are a lot more compact.

Unfortunate limitations...?!

[Jester99]

I read both of those links.

As far as I can tell, the MusicXML license is just a BSD license. Give credit where it's due for the DTD and you can use it wherever you'd like. I really don't see the limitation there...

Just because it's not GPL doesn't mean it's useless.

Re:Oh really...

[SnatMandu]

Well, MIDI is nice, but it's just instructions for an instrument. MusicML is desireable because the other formats are either proprietary (and tied to particular composition/editing program like VST), or are weak like MIDI or scanning-handwritten-pages.

MIDI is bad because it doesn't really tell you anything about how the notation should appear. You could write a pretty smart interpreter that would produce some readable score, but the author loses a lot of control.

Scanned Scores suck, because they're generally pretty large, may not print cleanly, etc. Also, good luck writing an application that will do the musical equivalent of OCR and get you something you can play back on a digital instrument.

MusicML should be trivial to convert to MIDI for having a digital robot (PC+MIDI capable instrument) play, and also easy to convert to a score for an organic robot (Musician) to play.

You don't need to learn anything. Just use your composition GUI/environemnt of choice (Cubase, Digital PErformer, whater) to put together the score, and then save in MusicXML. Now everyone who has an application that can read the format can use it.

So it actually sounds pretty nice, based on my cursory look at it.

As a musician....

[ericdano]

I would not put anything out there as XML. If I'm giving away something I worked on, I make a PDF of it, so then I am SURE what it will look like. Musicians are picky. I'm picky. I like to have my scores/parts/music look good. I'd lose that ability to be sure it is going to look if I put it in XML or whatever format.

The other thing I would do would be to give the files that I used to create the music. In my case, it's Finale. But, I have YET to do that. I like to retain some sort of credits for doing the work. PDF allows me to do that. And if they want to hear it, creating an MP3 of a score is simple as well.

Re:Browsers? Why over PDF?

[MattRog]

"WEFSAFD" was random frustrated keyboard mashings.

You say "Computer readability" then you mention an example of someone opening the file and looking at it.

As an API developer I would care what the physical structure of a file is only because I'm writing functions to write to these files. As an application developer I couldn't care less; I would be working with high-level things like 'measures' and 'notes'.

The method of storage has absolutely nothing to do with it being proprietary or not. In this case, XML is both ASCII and open, in that it doesn't obfuscate the plaintext. I could easily create a non-ASCII but open (all you have to do is tell someone what it is) format, just as easily as I could create an ASCII but 'closed' format (encrypting your message to an ASCII format for example).

Further, the scenario you paint makes no sense. A computer program does not need a file to be in ASCII text to be able to understand the structure and therefore derive meaning.

The only thing remotely plausible is that someone would look at the file contents but what is not plausible is that, given a super-duper-recognizing browser, they would use a text editor and not the penultimate file browser.