Music Encoding Initiative
Just come across this:-
http://www.music-encoding.org/home
Is it something we should be tking notice of?
Just come across this:-
http://www.music-encoding.org/home
Is it something we should be tking notice of?
Do you still have an unanswered question? Please log in first to post your question.
Comments
Odd. I just read through a dozen or so pages on that site and didn't once upon anything explaining how what they are doing differs from MusicXML. A bit of searching brought me to http://web.simmons.edu/~zavras/XML/Final_Presentation.ppt, which seems ancient by technical standards (mentions MusicXML 2.0 as being in beta).
My impression from what I have gleaned in this cursory examination is that this "Music Encoding Initiative" (MEI) was started to be in direct competition to MusicXML at a time when the latter was not a viable choice for a number of applications for whatever reason, but the MEI folks haven't realized that MusicXML has already won. Maybe I'm wrong, though.
In reply to Odd. I just read through a by Marc Sabatella
I met the MEI developers on several occasions during the past years. So the MEI developers are very well aware of MuseScore and the fact that they can fork it.
While MusicXML was conceived out of a need by the sheet music publishing industry to easily exchange digital sheet music, MEI was conceived by music researchers as a storage and exchange format for their work on sheet music manuscripts.
Andrew Hankinson (one of the MEI developers) explains it this way:
To be sure, MEI and MusicXML share some similarities. Both of them encode music notation (notes, staves, rests, clefs, etc. etc.), and both of them are expressed in XML.
However, they are guided by two different philosophies. MusicXML is an interchange format that seeks to represent music notation in a way that is independent of any one particular software. Its real strength is that you can export a file from Sibelius and import it into Finale with little to no loss of information or layout.
While MEI could also be used as an interchange format, it is a superset of the functionality available in MusicXML. It contains nearly all of the same functionality in terms of notation and page layout. However, beyond this it can also encode information about the notation in a structured and systematic way.
MEI supports notation systems outside of the standard Common Western Notation. Currently MEI supports mensural notation (Renaissance-era music notation) and earlier neume notation (notation from the middle ages).
In reply to MEI vs MusicXML by Thomas
So an MEI plugin for MuseScore would be beneficial then?
In reply to So an MEI plugin for by ChurchOrganist
I'm still confused. Sounds like MEI is basically MusicXML plus semantic info that wouldn't be available in a notation program anyhow - something one would add by hand using some tool other than a notation program. Wouldn't it make more sense to simply have such a tool - one that could take an existing MusicXML file and allow the user to add the necessary semantic info, then save in MEI format?
Haven't tried it yet, but this could be useful:
https://github.com/gburlet/musicxml-mei-conversion
Maybe there is a way to integrate this into MuseScore for MEI import/export via MusicXML ?
Hi everyone,
I'm a bit late on this thread, but I just came across it and thought I'd explain a bit more about what we're trying to do with MEI.
We're a community-developed open-source project (Code and Issue Tracker here: https://code.google.com/p/music-encoding/). Anyone is open to participate in the discussions and decision-making process.
We're not ignorant of MusicXML, but we're trying to address, perhaps, bigger issues within the field of music encoding. We see MusicXML as a fantastic and valuable interchange format, but it has some limitations when it comes to truly "digital" music editions:
1. MusicXML is designed primarily for software rendering, while MEI is designed primarily to capture semantics. So, while MusicXML might say "place two square brackets around this note," MEI would instead prefer to encode a particular note as "supplied" (i.e., provided by the editor) and leave the specific rendering of that note to the software that interprets it.
2. MEI makes no specific assumptions on the nature of the music that it is encoding. While MEI has complete functionality for encoding Common Practice Notation, it can also encode Mensural notation, neume (e.g., Gregorian chant) notation, and different types of tablatures.
3. The amount of metadata capable of being stored by a MEI file is pretty significant. The Danish Royal Library is using MEI to encode the bibliographic information for the Carl Nielsen Edition. See: http://www.kb.dk/dcm/cnw/navigation.xq. This means that all the bibliographic information encoded here is available as Linked Open Data.
4. The upcoming Beethoven Digital Edition will be produced with MEI for Genetic Editions, meaning Scholars and Performers will have access, not just to the final "text" of a piece, but also semantic access to the composition process and linking the music notation with facsimiles, recordings, and sketches. See: http://beethovens-werkstatt.de (German only! Sorry).
We're also well aware that our software rendering support is currently a significant weakness, but we're slowly making headway. We have a plugin for (*cough*)Sibelius(*cough*), which was actually started on a lark but has been able to grow. We're starving for devs at the moment, though, so that's why a MuseScore exporter hasn't shown up.
If there's any interest I'll keep an eye on this thread and try to answer any questions that come up.