Universal Music Translator/Store

• Feb 11, 2010 - 13:44

I'm looking into developing a 'universal' score translator/score store that can translate between any formats.
I'm also trying to develop a score store format that will allow rapid searching for pattern matching so new authors can check their work against others for potential copyright violations.
I was wondering if anyone knows of any work being don't on this - I'm aware of abc4j and several other programs have different import and export formats but fundamentally its about the music not the sheet it may be printed on.


Comments

In reply to by [DELETED] 5

but no-one in their right mind ( except for teaching purposes) would use it as an internal format in an application that require any computing or storage.
A simple example is a small 16 bar tune. ABC:200 byes. MusicXML ~ 6Kbytes.
Also to do any correlation the above tune would require 128bytes /mathematically/ but need 1 copy of XML for every key (or to be generated every time a correlation was done) so that's 72Kbytes to be processed every time.
MusicXML is a useful interchange language but, like all XML languages is hopelessly inefficient in terms of signal to noise, however it is easy to read and generate so it will be one of the first interfaces to the app.

In reply to by [DELETED] 5

MusicXML isnt bad as XML's go but, as an internal format its pretty useless.
I agree ABC doesnt carry info re layout - but from my point of view that is secondary to the music: as you would translate it into finger movements/breaths etc the layout is irrelevant to the instrument - its the real data contained within it that I'm more concerned with.
I must confess a dislike for XML in itself as a waste of time - its followed the paths of many data formats before, and repeated their mistakes etc. I'm often told that its human readable - well you print out a tune in XML or ABC or MIDI and try and play from them? But fed into the right program they will all make a decent job of it, or provide the sheet music for you to do it.
As I hope you can see there will be a central more abstract format - that may indeed share a lot of its structure with MusicXML and ABC and MID and... layout where provided will be in separate but conjoined area.
I've been looking into correlation algorithms and methods and at that level you have to get well away from xml type representations of data, and it happens to represent the music as well as the xml and is considerably more compact - to the point where the comparison algorithms would be sped up by factors of hundreds, or even millions. I doubt if they'll ever get to the speed of an autistic boy who lived near me once, and when I tried to learn the bass guitar asked me why I was playing certain tunes from classical music so slowly and so low. Quite freaky to discover some of the highest earning songwriters of the 80's were using 400 year old tunes.

In reply to by madtom1999

XML, text or binary is for me just a storing form. They all have their cons and pros regarding compactness, easiness to read by human or computer.
My point was more about the semantics in the format and I do understand that for pattern matching you will not need all the semantics you can found in MusicXML since it represents a score and you are interested in the performance, the sound.

Regarding the highest earnings songwriters and their predecessors, I strongly believe fundaments of Arts are in copying/inspiration, for paintings, writings, music. That's why I love CC licencing ;)

Do you still have an unanswered question? Please log in first to post your question.