4. Comments

Our system of representation is optimized for data entry and storage, not for user applications. The various elements of our system of representation have been tested with software we have developed for practicality and completeness. As part of this testing process, we have used MuseData code in its raw form as a source for producing performance materials and analytical searches; in translation we have used it for sound files and printing on other systems.

Our working solution to the need for data interchange is to write our own translation programs and to offer data in formats intended for diverse applications MIDI for sound output, SCORE for printing, and Kern for analysis. [Humdrum page] Other formats may be supported in the future. A draft MuseData-to-MIDI was written by Brent Field in 1991 and the program we currently use for this purpose was written by Walter B. Hewlett in 1992. A MuseData-to-Kern program was written by David Huron in 1994 and a new program is currently under development (1998) by Craig Sapp.

From our experiences with translation programs we can report a 99% or better data interchange rate with SCORE parameter files, i.e., almost everything that we represent is represented in SCORE, so data loss occurs only at an insignificant and relatively inconsequential level. Our interchange rate to Kern is almost as good, but because Kern does not currently support printed notational output, there is no way to visually verify the result against the original.

Interchange to MIDI filters out an enormous amount of detailed print data and can distort quite simple things, such as rests, grace notes, and unisons between parts. Plans to offer data in the DARMS format have been postponed because early experiments in translating to DARMS [again using a draft program by Brent Field written in 1991] revealed that despite DARMS' professed orientation towards printing applications, there were significant lapses.

Our current view is that a standard for interchange of musical information is not likely to thrive if it is developed in isolation from major applications and data sets. Pending schemes leave several problems unresolved, and this owes partly to limited manpower and the lack of robust testing. This could be remedied by a standards effort supported by a large group of users.

References