The file formats and specification of these programs does not allow for this, so conversions between the various file formats is required. One is proposing that one possible solution to this problem is to define music as a formal grammar. Then implement this in a file format which contains both the positional information, required for displaying, and the information for the analysis of the work.
Format Features There are three formats: 0, 1, and 2. Format 0 is for monophonic music, i.e. one track. Format 1 is for polyphonic music and is the most widely used format. Format 2 deals with tracks that are temporally independent.
Layout Features All the formats have the same layout. Each file is split into chunks and there are two types of chunk: First, the header chunk which contains an ASCII identifier, Header Length, Format, the Number of Tracks and other defining features for aspects of the file. The second chunk is the track chunk, this contains an ASCII header, Track Length and Track Events. There are three types of Track Event: Midi Events, Meta Events and System Exclusive (SysEx) Events.
Midi events are control events which control; things like note on/off, instrument changes etc. Meta events contain information which is not represented in the midi or sysex events. Finally, the System Exclusive message contains information for midi instruments that control other features.
The following example shows a ASCII representation of two
tracks of a four track midi file.
2
ASCII Representation of MIDI file
Chunk Type: MThd
Header Length: 6
Midi Format type: 1
Number of Tracks: 4
Ticks Per Quarter Note: 96
Header Information
Key Signature: 0
Time Signature: 4 4
Ticks Per Quarter Note: 96
Number of 32nds per Quarter Note: 8
1 Note on F4 65 0 01:04:00 72
1 Note off F4 65 48 01:04:48 72
1 Note on G4 67 0 01:04:48 72
1 Note off G4 67 48 01:04:96 72
1 Note on A4 69 0 02:01:00 72
1 Note off A4 69 96 02:01:96 72
1 Note on Bb4 70 0 02:02:00 72
1 Note off Bb4 70 96 02:02:96 72
1 Note on C5 72 0 02:03:00 72
1 Note off C5 72 96 02:03:96 72
1 Note on C5 72 0 02:04:00 72
1 Note off C5 72 96 02:04:96 72
1 Note on D5 74 0 03:01:00 72
1 Note off D5 74 96 03:01:96 72
1 Note on E5 76 0 03:02:00 72
1 Note off E5 76 96 03:02:96 72
1 Note on F5 77 0 03:03:00 72
1 Note off F5 77 96 03:03:96 72
1 Note on F4 65 0 03:04:00 72
1 Note off F4 65 48 03:04:48 72
1 Note on G4 67 0 03:04:48 72
1 Note off G4 67 48 03:04:96 72
1 Note on A4 69 0 04:01:00 72
1 Note off A4 69 96 04:01:96 72
1 Note on Bb4 70 0 04:02:00 72
1 Note off Bb4 70 96 04:02:96 72
1 Note on C5 72 0 04:03:00 72
1 Note off C5 72 96 04:03:96 72
1 Note on C5 72 0 04:04:00 72
1 Note off C5 72 96 04:04:96 72
1 Note on Bb4 70 0 05:02:00 72
1 Note off Bb4 70 96 05:02:96 72
1 Note on A4 69 0 05:01:00 72
1 Note off A4 69 96 05:01:96 72
1 Note on G4 67 0 05:03:00 72
1 Note off G4 67 96 05:03:96 72
2 Note on C4 60 0 01:04:00 72
2 Note off C4 60 96 01:04:96 72
2 Note on F4 65 0 02:01:00 72
2 Note off F4 65 96 02:01:96 72
2 Note on E4 64 0 02:02:00 72
2 Note off E4 64 96 02:02:96 72
2 Note on F4 65 0 02:03:00 72
2 Note off F4 65 96 02:03:96 72
2 Note on A4 69 0 02:04:00 72
2 Note off A4 69 96 02:04:96 72
2 Note on Bb4 70 0 03:01:00 72
2 Note off Bb4 70 48 03:01:48 72
2 Note on A4 69 0 03:01:48 72
2 Note off A4 69 48 03:01:96 72
2 Note on G4 67 0 03:02:00 72
2 Note off G4 67 96 03:02:96 72
2 Note on A4 69 0 03:03:00 72
2 Note off A4 69 96 03:03:96 72
2 Note on C4 72 0 03:04:00 72
2 Note off C4 72 96 03:04:96 72
2 Note on F4 65 0 04:01:00 72
2 Note off F4 65 96 04:01:96 72
2 Note on G4 67 0 04:02:00 72
2 Note off G4 67 192 04:03:96 72
2 Note on F4 65 0 04:04:00 72
2 Note off F4 65 144 05:01:48 72
2 Note on E4 64 0 05:01:48 72
2 Note off E4 64 48 05:01:96 72
2 Note on F4 65 0 05:02:00 72
2 Note off F4 65 96 05:02:96 72
2 Note on E4 64 0 05:03:00 72
2 Note off E4 64 96 05:03:96 72
This demonstrates that there is a large amount of data required to
encode a small number of bars of music.
0xF0 start of sysex message 0x7D expEvent message (non-commercial value) <Data Bytes> Symbol data (at least 2 Bytes) 0xF7 end sysex messageEach symbol is encoded from a look-up table. There are three tables for the symbols which are split into two distinct groups. Isolated and Extensible, the difference being, extensible symbols appear across a number of events. The way in which the symbols are encoded is as follows:
Data Byte1 0XXYYYYY XX - table number YYYYY - Option Flags Data Byte2 0ZZZZZZZ ZZZZZZZ - Symbol NumberThe following example shows a sample ASCII representation of an expMidi file. Again it shows only the first two tracks. 2
ASCII Representation of Expressive MIDI file Chunk Type: MThd Header Length: 6 Midi Format type: 1 Number of Tracks: 4 Ticks Per Quarter Note: 96 Header Information Key Signature: 0 Time Signature: 4 4 Ticks Per Quarter Note: 96 Number of 32nds per Quarter Note: 8 1 Note on F4 65 0 01:04:00 72 1 <Begin expEvent> 01:04:00 CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=0 Beam_Code <End expEvent> 1 Note off F4 65 48 01:04:48 72 1 Note on G4 67 0 01:04:48 72 1 <Begin expEvent> 01:04:48 CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=1 Beam_Code <End expEvent> 1 Note off G4 67 48 01:04:96 72 1 Note on A4 69 0 02:01:00 72 1 Note off A4 69 96 02:01:96 72 1 Note on Bb4 70 0 02:02:00 72 1 Note off Bb4 70 96 02:02:96 72 1 Note on C5 72 0 02:03:00 72 1 Note off C5 72 96 02:03:96 72 1 Note on C5 72 0 02:04:00 72 1 Note off C5 72 96 02:04:96 72 1 Note on D5 74 0 03:01:00 72 1 Note off D5 74 96 03:01:96 72 1 Note on E5 76 0 03:02:00 72 1 Note off E5 76 96 03:02:96 72 1 Note on F5 77 0 03:03:00 72 1 <Begin expEvent> 03:03:00 CodeTbl=0 Y1=0 Y2=0 Y3=1 Y4=0 Y5=0 Fermata_Code <End expEvent> 1 Note off F5 77 96 03:03:96 72 1 Note on F4 65 0 03:04:00 72 1 <Begin expEvent> 03:04:00 CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=0 Beam_Code <End expEvent> 1 Note off F4 65 48 03:04:48 72 1 Note on G4 67 0 03:04:48 72 1 <Begin expEvent> 03:04:48 CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=1 Beam_Code <End expEvent> 1 Note off G4 67 48 03:04:96 72 1 Note on A4 69 0 04:01:00 72 1 Note off A4 69 96 04:01:96 72 1 Note on Bb4 70 0 04:02:00 72 1 Note off Bb4 70 96 04:02:96 72 1 Note on C5 72 0 04:03:00 72 1 Note off C5 72 96 04:03:96 72 1 Note on C5 72 0 04:04:00 72 1 Note off C5 72 96 04:04:96 72 1 Note on Bb4 70 0 05:02:00 72 1 Note off Bb4 70 96 05:02:96 72 1 Note on A4 69 0 05:01:00 72 1 Note off A4 69 96 05:01:96 72 1 Note on G4 67 0 05:03:00 72 1 <Begin expEvent> 05:03:00 CodeTbl=0 Y1=0 Y2=0 Y3=1 Y4=0 Y5=0 Fermata_Code <End expEvent> 1 Note off G4 67 96 05:03:96 72 2 Note on C4 60 0 01:04:00 72 2 Note off C4 60 96 01:04:96 72 2 Note on F4 65 0 02:01:00 72 2 Note off F4 65 96 02:01:96 72 2 Note on E4 64 0 02:02:00 72 2 Note off E4 64 96 02:02:96 72 2 Note on F4 65 0 02:03:00 72 2 Note off F4 65 96 02:03:96 72 2 Note on A4 69 0 02:04:00 72 2 Note off A4 69 96 02:04:96 72 2 Note on Bb4 70 0 03:01:00 72 2 <Begin expEvent> 03:01:00 CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=0 Beam_Code <End expEvent> 2 Note off Bb4 70 48 03:01:48 72 2 Note on A4 69 0 03:01:48 72 2 <Begin expEvent> 03:01:48 CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=1 Beam_Code <End expEvent> 2 Note off A4 69 48 03:01:96 72 2 Note on G4 67 0 03:02:00 72 2 Note off G4 67 96 03:02:96 72 2 Note on A4 69 0 03:03:00 72 2 <Begin expEvent> 03:03:00 CodeTbl=0 Y1=0 Y2=0 Y3=1 Y4=0 Y5=0 Fermata_Code <End expEvent> 2 Note off A4 69 96 03:03:96 72 2 Note on C4 72 0 03:04:00 72 2 Note off C4 72 96 03:04:96 72 2 Note on F4 65 0 04:01:00 72 2 Note off F4 65 96 04:01:96 72 2 Note on G4 67 0 04:02:00 72 2 <Begin expEvent> 04:02:00 CodeTbl=0 Y1=1 Y2=0 Y3=0 Y4=0 Y5=0 Tie_Code <End expEvent> 2 Note off G4 67 96 04:02:96 72 2 Note on G4 67 0 04:03:00 72 2 <Begin expEvent> 04:03:00 CodeTbl=0 Y1=1 Y2=0 Y3=0 Y4=0 Y5=1 Tie_Code <End expEvent> 2 Note off G4 67 96 04:03:96 72 2 Note on F4 65 0 04:04:00 72 2 <Begin expEvent> 04:04:00 CodeTbl=0 Y1=1 Y2=0 Y3=0 Y4=0 Y5=0 Tie_Code <End expEvent> 2 Note off F4 65 96 04:04:96 72 2 Note on F4 65 0 05:01:00 72 2 <Begin expEvent> 05:01:00 CodeTbl=0 Y1=1 Y2=0 Y3=0 Y4=0 Y5=0 Tie_Code <End expEvent> 2 Note off F4 65 48 05:01:48 72 2 Note on E4 64 0 05:01:48 72 2 Note off E4 64 48 05:01:96 72 2 Note on F4 65 0 05:02:00 72 2 Note off F4 65 96 05:02:96 72 2 Note on E4 64 0 05:03:00 72 2 <Begin expEvent> 05:03:00 CodeTbl=0 Y1=0 Y2=0 Y3=1 Y4=0 Y5=0 Fermata_Code <End expEvent> 2 Note off E4 64 96 05:03:96 72
The following example shows how the file is laid-out.
It is an Alphanumeric format. There have been variants developed,
these are discussed later. It is widely used by scholars in both
typesetting and analytical applications. The internals of the format
are such that every object is described completely and all positional
information in explicit. Pitches are defined using a `vertical space
code', which represents the line on the stave that the note
is1.
One draw back in the format, in the `vertical space code', is that
enharmonic notation is ambiguous even when there is a key signature.
The actual note is not explicitly known.
The first DARMS variant one will look at is Note-Processor Dialect
DARMS. This describes the actual musical symbols as they appear on
the page. This uses a combination of key-codes and alphanumeric
characters to represent the symbols. This is used for typesetting
purposes. These include Brinkman DARMS[4] and
Erickson[9] (Canonical) DARMS but the basics are the same
throughout all the variants.
The following example shows one possible encoding technique. The file
layout is free-format, easing data-entry but creating many
possibilities for problems to occur in the interpretation of the code.
2
2
Basic Guido as mentioned above deals with the basic notation issues,
like duration, slurs etc. Whereas Advanced Guido takes this a
step further and adds the extra information that is required when
typesetting music.
The following example demonstrates the Basic Guido in use.
2
Figure 2, above, demostrates the typesetting done by the
Guido Note Server[26]. This demonstrates the need for the
additional information used in Advanced Guido.
Each file is hierarchically structured having two sections
: the first is a setup section which contains part definitions, default
parameters and header information.
The second section, the data section, contains the musical symbols in a
page-ordered format. This means that the data, musical symbols, are stored as
they would appear. There is a special case where all the symbols are placed
in one system on an indefinitely wide page. Each part has it's own staff.
This case is known as `simulated part ordering'. No example is given because
the data is stored as hexadecimal numbers.
The following example represents a simple encoding in the format, the
columns are not strictly observed, but it does demonstrate the
encoding technique.
2
There are four main domains which can be represented in the file. The
first is the Logical domain or cantus, this is where all the
basic musical data is stored. This domain can be split into
threads/voices, each having their own instrument assigned. The
second domain is the Visual domain, this is where the display
information is stored. The type of notehead, for example, might
appear here. The third domain is the Gestural domain, this stores
performance information such as the real-time duration of the musical
data. The final domain is the Analytic domain which stores any
analysis or bibliographic information about the work.
There are five details, about the logical domain, that are important.
The first is that pitch can be specified in three different ways, as a
specific frequency, as a function of a reference frequency or be
defined in a look-up table, gamut. Second is the duration,
this can be specified as either a real-time value or as a
virtual-time4. Thirdly, articulation and ornamentation are not
represented fully, mainly because of the number of possibilities.
These are clarified in the Visual and Gestural domains. Dynamics are
represented in the same fashion as articulation and ornamentation
markings. Finally, the timbre can be set by splitting the
cantus into threads/voices, each having its own
instrument label.
From the example it is clear that there are two distinct sections to
the file. The first is the Document Type Definitions (DTD's). Then
all the data entries. SMDL has the advantage over other formats
because it can be used with music that is encoded using the majority
of formats available today. However, being a document style format it
is very verbose, both in the amount of data needed and it's layout.
Grace Notes still have to be finalised as there are
many different contexts where they can be applied and have different meanings.
We have shown in the previous section that there are a great number of
different file formats available for use in music programs. The
majority have their origins from the file formats used by the early
music programs, in-particular MUSIC V [32]. The programs, that
use formats derived from these programs, are the typesetting or audio
generation. The main reason behind this is the parametric syntax used
within the files. This means that the files have a formalised
structure, making them easy to decipher when being read by the user
outside of the program's environment. An example of this is SCORE 's
ASCII format.
The analysis programs also use a parametric file format in a sense.
However, there is a different style of layout in the file. The layout
is dependent on the program. Some programs layout the file so that
each part appears sequentially, others layout the file so that
concurrent events, over all parts, appear on the same line. Two
examples of this are Lilypond , although a typesetting package, and,
of the latter, Humdrum.
;;; -*- syntax: common-lisp; package:cmn; base: 10; mode: lisp -*-
(cmn (size 20)
(system brace
(setf s1 (staff treble (key f-major) (meter 4 4)
(f4 e stem-up) (g4 e stem-up) bar
(a4 q stem-up) (b4 q stem-up) (c5 q stem-up) (c5 q stem-up) bar
(d5 q stem-up) (e5 q stem-up) (f5 q fermata stem-up)
(f4 e stem-up) (g4 e stem-up) bar
(a4 q stem-up) (b4 q stem-up) (c5 q stem-up) (c5 q stem-up) bar
(b4 q stem-up) (a4 q stem-up) (g4 q fermata stem-up)))
(staff (tied-to s1) (c4 q stem-down) bar
(f4 q stem-down) (e4 q stem-down) (f4 q stem-down)
(a4 q stem-down) bar
(b4 e stem-down) (a4 e stem-down) (g4 q stem-down)
(a4 q stem-down) (c4 q stem-down) bar
(f4 q stem-down) (g4 q stem-down begin-tie) (g4 q stem-down end-tie)
(f4 q stem-down begin-tie) bar
(f4 e stem-down end-tie) (e4 e stem-down) (f4 q stem-down)
(e4 q stem-down))
(setf s2 (staff bass (key f-major) (meter 4 4)
(a3 e stem-up) (b3 e stem-up) bar
(c4 q stem-up) (b3 q stem-up) (a3 e stem-up) (c4 e stem-up)
(f4 q stem-up) bar
(f4 q stem-up) (c4 q stem-up) (c4 q stem-up) (a3 q stem-up) bar
(d4 q stem-up) (d4 q stem-up) (c4 e stem-up) (b3 e stem-up)
(a3 q stem-up) bar
(b3 q stem-up) (c4 q stem-up) (c4 q stem-up))
(staff (tied-to s2) (f3 q stem-down) bar
(f3 q stem-down) (g3 q stem-down) (a3 q stem-down)
(f3 q stem-down) bar
(b3 q stem-down) (c4 q stem-down) (f3 q stem-down
upside-down-fermata) (f3 e stem-down) ( e3 e stem-down) bar
(d3 q stem-down) (c3 e stem-down) (b2 e stem-down)
(a2 q stem-down) (d3 q stem-down) bar
(g2 q stem-down) (a2 e stem-down) (b2 e stem-down)
(c3 q stem-down upside-down-fermata))))
There are features that
rigorously specify positional information. Also, storage becomes a
problem because of the file size. This is possibly the easiest format
to read because of the amount of description used.
1.2.2 DARMS
This file format is the oldest for describing music, it was initially
designed in 1963 by Bauer-Mengelberg[3]. It has
two main features[30] other than the one mentioned above.
The first is that it
...illustrates the orientation of
the print-oriented code extremely well.
and second is
that it
...offers a paradigm that is rarely presented in
the other codes...All files stored in DARMS can be converted to an
unambiguous `canonical' version.
!I1 !G, !G, !F, !F
K Begin Soprano Part $
!K1- !M4:4 2EU( 3U) /
4QU 5U 6U 6U /
7QU 8U 9U?109 2EU( 3U) /
4QU 5U 6U 6U /
5QU 4U 3U?109 !-50
K Begin Alto Part $
!K1- !M4:4 -1QD /
2QD 1D 2D 4D /
5ED( 4D) 3QD 4D?110 -1D /
2QD 3DJ1 3DJ2 2DJ1 /
2E(J2 1D) 2QD 1D?110 !-50
K Begin Tenor Part $
!K1- !M4:4 9EU( 10U) /
11QU 10U 9EU( 11U) 14QU /
14QU 11U 11U?109 9U /
12QU 12U 11EU( 10U) 9QU /
10QU 11U 11U?110 !-50
K Begin Bass Part $
!K1- !M4:4 7QD /
10QD 8D 9D 7D /
10QD QQD 7D?110 7ED( 6D) /
5QD 4ED( 3D) 2QD 5D /
1QD 2ED( 3D) 4QD?110
1.2.3 SCORE
SCORE is a commercial typesetting/engraving package, which aims to
produce equal quality printed output to that of engraving[19].
There are two output file formats available to the user. The first is
plain binary and the second is ASCII text. The file format
has been derived from the MUSIC V 's file format. One will focus on the
ASCII format for this discussion. Contained in the file is
all the information to do with the positioning, type of musical object
that is to be placed on the page. This also includes an optional
offset for particular features, this is so that no collisions occur
when the objects appear on the page. However, the main problem with
this format is that the data is represented numerically. Thus meaning
that one has to have extensive knowledge of the object key to be able
to decipher the file. It also means that it is difficult to edit
outside the program's environment. There is no example no example
given for this due to the nature of the contents of the file. To give
an accurate example the SCORE program is required.
1.2.4 Lilypond
Lilypond as mentioned previously is a typesetting program[23].
With this program one is concerned only with the input file format, as
the output produced is in LATEX. The file is laid out differently
compared to the other formats discussed in that it is a bottom-up
design. The first item that appears in the file is the Header.
All the files to be included are added. Then each Part is, in
turn described. The penultimate section is the grouping of the like
parts. The final section is the grouping of all the parts in a system
and paper definitions.
The syntax of the file is as follows each note is represented as it's
note name, then it has an octave specification followed by a duration.
A rest is denoted by a r. Then all the other symbols are
entered by using their names but having a \ at the front of
the name.
%Lilypond Sample file
\header{
filename = "bach.ly";
title = "O Ewigeit, du Donnerwort";
tagline = "";
}
\version "1.2.0";
\include "paper11.ly";
global =\notes {
\key f;
\time 4/4;
\skip4*3;
}
sop = \notes \relative c' {
\clef "violin";
\global
\context Staff <
\context Voice = uVoice {
\stemup
f8 g |
a4 bes c c |
d e f-\fermata f,8 g |
a4 bes c c |
bes a g-\fermata \bar "||";
}
\context Voice = dVoice {
\stemdown
c,4 |
f e f a |
bes8 a g4 a c, |
f g~ g f~ |
f8 e f4 e
}
>
}
bass = \notes {
\clef "bass";
\global
\context Staff <
\context Voice = tenor {
\stemup
a8 bes |
c'4 bes a8 c' f'4 |
f' c' c' a |
d' d' c'8 bes a4 |
bes c c' \bar "||";
}
\context Voice = Bass {
\stemdown
f4 |
f g a f |
bes, c f-\fermata f8 e |
d4 c8 bes, a,4 d |
g a,8 bes, c4-\fermata
}
>
}
\score {
\notes \context PianoStaff <
\sop
\bass
>
\paper{indent=0.0\cm; }
}
1.2.5 Guido
Guido[17,15] is an ASCII based notation
format. It is focused on musical information.The format has three
different hierarchies. The first is Basic Guido, this deals with the
low-level representation notation. The second, Advanced Guido[16], deals
with the formatting issues and thirdly, Extended Guido, which
introduces features not found in Western Notation. Being a
human-readable format guido has some similar properties with CMN in
that it is descriptive in it's encoding technique.
{
[ \staff<1>
\clef<"g2"> \key<"F"> \meter<"4/4">
\stemsUp
_*3/4 f1/8 g |
a1/4 b& c2 c |
d e \fermata(f) f1/8 g |
a1/4 b& c2 c |
b&1 a \fermata(g) |
],
[ \staff<1> \key<"F"> \meter<"4/4">
\stemsDown
_*3/4 c1/4 |
f e f a |
b&/8 a g1/4 a c |
f \tie(g g) \tie(f | f1/8) e f1/4 e
],
[ \staff<2>
\clef<"bass"> \stemsUp \key<"F"> \meter<"4/4">
_*3/4 a0*1/8 b&0*1/8 |
c0*1/4 b&0*1/4 a0*1/8 c1*1/8 f1*1/4 |
f c c a0*1/4 |
d1*1/4 d c1*1/8 b&0*1/8 a0*1/4 |
b& c0 c1*1/4],
[ \staff<2> \stemsDown \key<"F"> \meter<"4/4">
_*3/4 f0*1/4 |
f d a f |
b&-1*1/4 c0*1/4 \fermata(f) f0*1/8 e |
d/4 c/8 b&-1*1/8 a-1/4 d0*1/4 |
g a-1*1/8 b& \fermata(c0*1/4)]
}
Figure
1.3 Analysis Based Formats
1.3.1 Humdrum and Kern
Humdrum is an analysis toolkit which uses ASCII text to
encode musical works [32,18]. The files are laid out in
a concurrent style. This, one assumes is to make the parsing of the
file easier as concurrent events appear on the same line. The way in
which the musical objects are encoded, is completely different from
SCORE . Notes are represented by letters as opposed to numbers.
Again, the user needs to be familiar with the syntax to use this
because the octave specification is not numerical, instead a
combination of symbols are used.
2
!!Humdrum Sample file
!!Title
**kern **kern **kern **kern
*staff4 *staff3 *staff2 *staff1
*clefF4 *clefF4 *clefG2 *clefG2
*k[b-] *k[b-] *key[b-] *k[b-]
*M4/4 *M4/4 *M4/4 *M4/4
4F 8A 4c 8f
. 8B . 8g
=1 =1 =1 =1
4F 4c 4f 4a
4G 4B 4e 4b
4A 8A 4f 4cc
. 8c . .
4F 4f 4a 4cc
=2 =2 =2 =2
4B 4f 8b 4dd
. . 8a .
4c 4c 4g 4ee
4F 4c 4a 4ff
8F 4A 4c 8f
8E . . 8g
=3 =3 =3 =3
4D 4d 4f 4a
8CC 4d [4g 4b
8BB . . .
4AA 8c 4g] 4cc
. 8B . .
4D 4A [4F 4cc
=4 =4 =4 =4
4GG 4B 8F] 4b
. . 8e .
8AA 4c 4f 4a
8BB . . .
4C 4c 4e 4g
== == == ==
1.4 Independent Formats
1.4.1 Notation Interchange File Format (NIFF)
The NIFF file format[13,12] is modelled upon the features
of the SCORE file format. It was designed using the rule of
Microsoft's Resource Interchange File Format (RIFF)[25]
structure. It is also platform independent to a certain extent, the
only difference between platforms being the way that an integer byte (8bit
value) is ordered2. If RIFF is found then it is in Intel byte
order, if RIFX is found it is in Motorola byte order. It is a binary
format, with some of the data being stored as a combination of
ASCII and Hexadecimal codes.
1.4.2 MuseData
This format is designed for data entry and storage
purposes[14]. It has a parametric layout and has the
advantage of being software-neutral3. It is another
ASCII based format. There are other points which make this
is a bad format to use. The first is that conversion to other formats
is required to process the data in the file. Secondly, it is not
intended to represent a score fully. Finally, there is only one part
of the score encoded per file. Thus large orchestral scores require a
large number of files. The format uses Mnemonics to represent the
musical symbols. Due to it's parametric format it gives columns for
each attribute/option. There are 80 columns which contain the data
for the note or rest being represented. The columns are split as
follows: For note records columns 1-4 contain pitch information,
columns 6-9 contain duration information, then columns 13-80 contain
graphic and interpretive information.
29/10/1999 A Tee
WK#: ? MV#: ?
?
Chorale
?
Soprano
1 0
Group memberships: sound, score
sound: part 1 of 4
score: part 1 of 4
$ k:-1 Q:8 T:4/4 C:4
F4 4 e u [
G4 4 e u ]
measure 1
A4 8 q u
Bf4 8 q u
C5 8 q u
C5 8 q u
measure 2
D5 8 q u
E5 8 q u
F5 8 q u F
F4 4 e u [
G4 4 e u ]
measure 3
A4 8 q u
Bf4 8 q u
C5 8 q u
C5 8 q u
measure 4
Bf4 8 q u
A4 8 q u
G4 8 q u F
29/10/1999 A Tee
WK#: ? MV#: ?
?
Chorale
?
Alto
1 0
Group memberships: sound, score
sound: part 2 of 4
score: part 2 of 4
$ k:-1 Q:8 T:4/4 C:4
C4 8 q d
measure 1
F4 8 q d
E4 8 q d
F4 8 q d
A4 8 q d
measure 2
Bf4 4 e d
A4 4 e d
G4 8 q d
A4 8 q d
C4 8 q d
measure 3
F4 8 q d
G4 8- q d -
G4 8 q d
F4 8- q d -
measure 4
F4 4 e d [
E4 4 e d ]
F4 8 q d
E4 8 q d F
29/10/1999 A Tee
WK#: ? MV#: ?
?
Chorale
?
Tenor
1 0
Group memberships: sound, score
sound: part 3 of 4
score: part 3 of 4
$ k:-1 Q:8 T:4/4 C:22
A3 4 e u [
Bf3 4 e u ]
measure 1
C4 8 q u
Bf3 8 q u
A3 4 e u [
C4 4 e u ]
F4 8 q u
measure 2
F4 8 q u
C4 8 q u
C4 8 q u E
A3 8 q u
measure 3
D4 8 q u
D4 8 q u
C4 4 e u [
Bf3 4 e u ]
A3 8 q u
measure 4
Bf3 8 q u
C4 8 q u
C4 8 q u E
29/10/1999 A Tee
WK#: ? MV#: ?
?
Chorale
?
Bass
1 0
Group memberships: sound, score
sound: part 4 of 4
score: part 4 of 4
$ k:-1 Q:8 T:4/4 C:22
F3 8 q d
measure 1
F3 8 q d
G3 8 q d
A3 8 q d
F3 8 q d
measure 2
Bf3 8 q d
C4 8 q d
F3 8 q d E
F3 4 e d [
E3 4 e d ]
measure 3
D3 8 q d
C3 4 e d [
Bf2 4 e d ]
A2 8 q d
D3 8 q d
measure 4
G2 8 q d
A2 4 e d [
Bf2 4 e d ]
C3 8 q d E
1.4.3 Standard Music Description Language (SMDL)
This is a derivative of HyTime (HyperMedia/Time-based Structuring
Language)[1] which is a derivative of SGML (Standard
Generalized Markup Language)[10]. Before one introduces this
format, a note should be made that some knowledge of the formats
mentioned above (SGML, HyTime) is an advantage in understanding
SMDL[31,22] fully.
<!DOCTYPE work SYSTEM "smdl.dtd" [
<?HyTime VERSION "ISO/IEC 10744:1992" HYQCNT=32>
<?HyTime MODULE base
desctxt dvlist lextype refctl>
<?HyTime MODULE measure
axismdu dimref fcsmdu HyFunk HyOp markfun>
<?HyTime MODULE sched
grpdex>
<?HyTime MODULE rend
modify patch profun project>
<!NOTATION virtime PUBLIC -- virtual time--
"+//ISO/IEC 10744//NOTATION Virtual Time Unit//EN">
<!ENTITY tactvtu "80640">
<!ENTITY % e.canti "Chorale">
<!ENTITY % av.wxdm "4294967295">
<!ENTITY % av.wxfm "`SIsecond 1 1000'">
<!ENTITY % av.wxbg "msec">
<!ENTITY % av.wxgh "`1 1'">
<!ENTITY % av.wxpg "`1 1'">
<!ENTITY % av.cxdm "4294967295">
<!ENTITY % av.cxfm "`virtime 1 1'">
<!ENTITY % av.cxbg "vtu">
<!ENTITY % av.cxgh "`1 1'">
<!ENTITY % av.cxpg "`1 &tactvtu;">
<!ENTITY % e.rsrc "strestem|chordgam|pitchgam|mudef">
<!ENTITY % e.music "note|chord|rest">
<!ENTITY % m.ceg "(%e.music; | ceg)+">
<!ENTITY % m.np "(gampitch|freqspec)">
<!ENTITY % e.intji "arbintvl">
<!ENTITY % e.bib "title|author|date|issuer|descript|copr|status|role|numclass">
<!ENTITY % d.bib "<!ELEMENT (%e.bib;) - o (#PCDATA)>"> %d.bib;
<!ENTITY % m.bib "(%e.bib; | theme)*">
<!ENTITY % a.theme "">
]>
<work>
<bibdata>
<title>O Ewigkeit, du Donnerwort
<author>J.S.Bach
<descript>Choral music
</bibdata>
<workfcs>
<workschd>
<workseg>
<bibdata>
<title>O Ewigkeit, du Donnerwort
</bibdata>
<pitchgam id=pitchgm0
gamutdes="conventional 12-tone equal temperament"
highstep=11
octratio=2 1
>
<genfreq>
<gamstep>9</gamstep>
<freqspec><hertz>440</hertz></freqspec>
</genfreq>
<namestep><pitchdef><pitchnm>c</pitchnm><gamstep>0</gamstep></pitchdef></namestep>
<namestep><pitchdef><pitchnm>d</pitchnm><gamstep>2</gamstep></pitchdef></namestep>
<namestep><pitchdef><pitchnm>e</pitchnm><gamstep>4</gamstep></pitchdef></namestep>
<namestep><pitchdef><pitchnm>f</pitchnm><gamstep>5</gamstep></pitchdef></namestep>
<namestep><pitchdef><pitchnm>g</pitchnm><gamstep>7</gamstep></pitchdef></namestep>
<namestep><pitchdef><pitchnm>a</pitchnm><gamstep>9</gamstep></pitchdef></namestep>
<namestep><pitchdef><pitchnm>b</pitchnm><gamstep>11</gamstep></pitchdef></namestep>
</pitchgam>
<fictagam id=1flat idref=pitchgm0>
<pitchnm>b</pitchnm><fictadj>-1</fictadj>
</fictagam>
<notedurs HyTime=desctab id mydurs>
<durname HyTime=desctxt>t</durname>
<durval HyTime=descdef><marklist>&tactvtu;</marklist></durval>
<durname HyTime=desctxt>t4</durname>
<durval HyTime=descdef><marklist>
<HyOp opname=div>
<marklist desctab=mydurs desctxt=t>
<marklist>4
</HyOp>
</durval>
</notedurs>
<ce HyTime=event exspec=myextlist2>
<extlist HyTime=extlist id=myextlist2>
<marklist HyTime=marklist desctxt="t4" desctab=mydurs>
</ce>
<ce HyTime=event exspec=myextlist>
<extlist HyTime=extlist id=myextlist>
<dimref HyTime=dimref elemref=dur1231 selcomp=last>
<marklist HyTime=marklist desctxt="t4" desctab=mydurs>
</extlist>
</ce>
<strestem id=simptrip pointcnt=4>
<pointnum>1</pointnum>
<stresval><strestxt>downbeat</strestxt></stresval>
<strestem id=simplesub pointcnt=2>
<pointnum>1</pointnum>
</strestem>
</strestem>
<stresuse id=tsig1 idr=simptrip strespt=4>
<O Ewigkeit, du Donnerwort>
<thread id=thd1 nominst="soprano">
</thread>
<thread id=thd2 nominst="alto">
</thread>
<thread id=thd3 nominst="tenor">
</thread>
<thread id=thd4 nominst="bass">
</thread>
2
<baton id=bat1>
</baton>
<start thd1>
<ceg id=sopline>
<note>t2 0 f
<note>t2 0 g
<note>t 0 a
<note>t 0 b
<note>t 1 c
<note>t 1 c
<note>t 1 d
<note>t 1 e
<note>t 1 f
<note>t2 0 f
<note>t2 0 g
<note>t 0 a
<note>t 0 b
<note>t 1 c
<note>t 1 c
<note>t 0 b
<note>t 0 a
<note>t 0 g
</ceg>
<end thd1>
<start thd2>
<ceg id=altoline>
<note>t 0 c
<note>t 0 f
<note>t 0 e
<note>t 0 f
<note>t 0 a
<note>t2 0 b
<note>t2 0 a
<note>t 0 g
<note>t 0 a
<note>t 0 c
<note>t 0 f
<note>2t 0 g
<note>1.5t 0 f
<note>t2 0 f
<note>t2 0 e
<note>t 0 f
<note>t 0 e
</ceg>
<end thd2>
<start thd3>
<ceg id=tenorline>
<note>t2 -1 a
<note>t2 -1 b
<note>t 0 c
<note>t -1 b
<note>t2 -1 a
<note>t2 0 c
<note>t 0 f
<note>t 0 f
<note>t 0 c
<note>t 0 c
<note>t -1 a
<note>t 0 d
<note>t 0 d
<note>t2 0 c
<note>t2 -1 b
<note>t -1 a
<note>t -1 b
<note>t 0 c
<note>t 0 c
</ceg>
<end thd3>
<start thd4>
<ceg id=bassline>
<note>t -1 f
<note>t -1 f
<note>t -1 g
<note>t -1 a
<note>t -1 f
<note>t -1 b
<note>t 0 c
<note>t -1 f
<note>t2 -1 f
<note>t2 -1 e
<note>t -1 d
<note>t2 -1 c
<note>t2 -2 b
<note>t -2 a
<note>t -1 d
<note>t -2 g
<note>t2 -2 a
<note>t2 -2 b
<note>t -1 c
</ceg>
<end thd4>
1.4.4 Music Markup Language MML
MML[33] is only in its discussion stage at present and has no parser to
test the syntax. This is another subset of SGML but focussing upon the XML
approach to document definition. It aims to be deliverable in the following
formats text, block bars/piano roll (as seen in sequencers), Western music
notation and by midi device. The format will not go into the amount of
detail to represent a score fully. It has a modular design so that only the
modules of relevance are used when marking a score up.
<mml>
<head>
<title>O Ewigeit, du DonnerWort</title>
</head>
<song>
<div clef="G" octave="4" note="4" key="Fmaj">
<upbeat>[C:4 F:8]G:8 </upbeat>
<bar 1>[F A] [E Bf] [F 5C] [A 5C] </bar>
<bar 2>[Bf:8 5D]A:8 [G 5E] [A 5F] [C F:8]G:8 </bar>
<bar 3>[F A] [G Bf] [G 5C] [F 5C] </bar>
<bar 4>[F:8 Bf]E:8 [F A] [E G]</bar>
</div>
<div clef="F" octave="3" note="4" key="Fmaj">
<upbeat>[F A:8]Bf:8 </upbeat>
<bar 1>[F 4C] [G Bf] [A A:8]4C:8 [F 4F]</bar>
<bar 2>[2Bf 4F] [C 4C] [F 4C] [F:8 A]E:8</bar>
<bar 3>[D 4D] [C:8 4D]2Bf:8 [2A 4C:8]Bf:8 [D A]</bar>
<bar 4>[G Bf] [2A:8 C]2Bf:8 [C 4C]</bar>
</div>
</song>
</mml>
2 The Grammar
The fact that music can be treated like a language meant that a
grammatical approach could be made in the designing of a
representation. There are various different types of grammar which
can be used[6]. The type of grammar that was chosen was a
Phrase-Structure Grammar[6,27]. The formal grammar,
shown below, represents the musical score by laying out each
individual musical object in a hierarchical format. The top-level
aspect of a musical score is the system this can then have a number of
staff groups attached to it forming the basics of a score.
3 Representation of the Grammar as File Format
3.1 Introduction
3.2 Revised Design
The revised design has removed all the identifiers (i.e. MusicalObject
etc..) and replaced some of them with single characters, with the
exception of the System, StaffGroup and StaffSpec. These last three
items have beginnings and ends so they will be represented by a pair
of characters e.g. curly braces ( { } ), in the case of a System,
Square brackets ( [ ] ) in the case of the StaffGroup and brackets ( ()
)for a StaffSpec. Rests will be represented by the letter r as
opposed to Rest(....).
This has an effect on the file in two ways.
The first is that it makes the file easier to read and secondly it
reduces the files size dramatically.
2
{ brace [
( 5 0 0
1 1 0,0 G
1 1 5,0 Fmaj
1 1 10,0 4/4
1 4 0,0 f 4 up 0 right 1/2
1 4 0,0 c 4 down 0 null 1
1 4.5 0,0 g 4 up 0 left 1/2
2 1 -10,0 simple_line
2 1 0,0 a 4 up 0 null 1
2 1 0,0 f 4 down 0 null 1
2 2 0,0 bb 4 up 0 null 1
2 2 0,0 e 4 down 0 null 1
2 3 0,0 c 5 up 0 null 1
2 3 0,0 f 4 down 0 null 1
2 4 0,0 c 5 up 0 null 1
2 4 0,0 a 4 down 0 null 1
3 1 -10,0 simple_line
3 1 0,0 d 5 up 0 null 1
3 1 0,0 bb 4 down 0 right 1/2
3 1.5 0,0 a 4 down 0 left 1/2
3 2 0,0 e 5 up 0 null 1
3 2 0,0 g 4 down 0 null 1
3 3 0,0 f 5 up fermata 0,15 null 1
3 3 0,0 a 4 down 0 null 1
3 4 0,0 f 4 up 0 right 1/2
3 4 0,0 c 4 down 0 null 1
3 4.5 0,0 g 4 up 0 left 1/2
4 1 -10,0 simple_line
4 1 0,0 a 4 up 0 null 1
4 1 0,0 f 4 down 0 null 1
4 2 0,0 bb 4 up 0 null 1
4 2 0,0 g 4 down tie 0,-5 null 1
4 3 0,0 c 5 up 0 null 1
4 3 0,0 g 4 down null 1
4 4 0,0 c 5 up 0 null 1
4 4 0,0 f 4 down tie 0,-5 0 null 1
5 1 -10,0 simple_line
5 1 0,0 bb 4 up 0 null 1
5 1 0,0 f 4 down 0 right 1/2
5 1.5 0,0 e 4 down 0 left 1/2
5 2 0,0 a 4 up 0 null 1
5 2 0,0 f 4 down 0 null 1
5 3 0,0 g 4 up fermata 0,15 null 1
5 3 0,0 e 4 down 0 null 1
)
( 5 0 0
1 1 0,0 F
1 1 5,0 Fmaj
1 1 10,0 4/4
1 4 0,0 a 3 up 0 right 1/2
1 4 0,0 f 3 down 0 null 1
1 4.5 0,0 bb 3 up 0 left 1/2
2 1 -10,0 simple_line
2 1 0,0 c 4 up 0 null 1
2 1 0,0 f 3 down 0 null 1
2 2 0,0 bb 3 up 0 null 1
2 2 0,0 g 3 down 0 null 1
2 3 0,0 a 3 up 0 right 1/2
2 3 0,0 a 3 down 0 null 1
2 3.5 0,0 c 4 up 0 left 1/2
2 4 0,0 f 4 up 0 null 1
2 4 0,0 f 3 down 0 null 1
3 1 -10,0 simple_line
3 1 0,0 f 4 up 0 null 1
3 1 0,0 bb 3 down 0 null 1
3 2 0,0 c 4 up 0 null 1
3 2 0,0 c 4 down 0 null 1
3 3 0,0 c 4 up 0 null 1
3 3 0,0 f 3 down fermata 0,-15 null 1
3 4 0,0 a 3 up 0 null 1
3 4 0,0 f 3 down 0 right 1/2
3 4.5 0,0 e 3 down 0 left 1/2
4 1 0,0 simple_line
4 1 0,0 d 4 up 0 null 1
4 1 0,0 d 3 down 0 null 1
4 2 0,0 d 4 up 0 null 1
4 2 0,0 c 3 down 0 right 1/2
4 2.5 0,0 bb 2 down 0 left 1/2
4 3 0,0 c 4 up 0 right 1/2
4 3 0,0 a 2 down 0 null 1
4 3.5 0,0 bb 3 up 0 left 1/2
4 4 0,0 a 3 up 0 null 1
4 4 0,0 d 3 down 0 null 1
5 1 -10,0 simple_line
5 1 0,0 bb 3 up 0 null 1
5 1 0,0 g 2 down 0 null 1
5 2 0,0 c 4 up 0 null 1
5 2 0,0 a 2 down 0 right 1/2
5 2.5 0,0 bb 2 down 0 left 1/2
5 3 0,0 c 4 up 0 null 1
5 3 0,0 c 3 down fermata 0,-15 null 1
)]}
3.3 Reference Implementation
To test the syntax of the file format a reference parser has been
implemented. This has been implemented using the Lex(Flex) and
Yacc(Bison) tools[21,24,8]. The grammar was translated
into a Yacc compatible grammar, see Appendix A. The grammar
required some syntactic alterations due to the way Yacc interprets a
grammar specification. The lexical analyser has been implemented as a
stateful lexer. The descion to do this was made because some of the
lexical elements have a different meaning when they appear in
different parts of the file. There are six states in the lexical
analyser. These are the initial state, system state, staffgroup
state,staff state, musicalobject state and note state.
References
1 1is the lowest line on the stave and 9 is the highest line on the stave
2Intel uses Little Endian Encoding, lowest byte first and other Architectures use Big Endian encoding Most significant byte first
3The format is not associated with any current music program
4All virtual-time units are related to one
another and only become real values when converted in the Gestural
domain