Enigma Transport Format (ETF for short) is a format designed by MakeMusic! inc. (formerly known as Coda Music Technology), and it is used in the proprietary notation package Finale (Finale is a registered trademark of MakeMusic! inc.).
The ETF specification issued by CODA is available at http://www.xs4all.nl/~hanwen/lily-devel/etfspec.pdf.
Unfortunately many crucial details (which are partly listed here) have been omitted from the specs by Coda, we will attempt some doco here.
ETF is an memory dump where object pointers have been replaced by object numbers. The numbers are larger than 0 and the number 0 is used to denote the nil pointer. The dump is encoded in ASCII (where the mac version uses CR, and the PC CR/LF as line delimiters)
A file is divided into sections like this
^section-header
DATA
^section-header
DATA
(etc.)
DATA is stored in the form of tagged lines, where a tagged line looks like
^TG(N1,N2?) X1 X2 X3 (etc)
The caret is at the start of the line, ‘TG’ is a two letter tag, and N1 (and optionally N2) are numbers identifying the object to be described. X3, X4 etc contain data in the form of either a signed 16 bit number, or a 32 bit number (in hex, with a $ sign prepended). The number of Xs per line for a certain tag is constant.
The numbers in ‘N1’ need not be consecutive or ascending, mostly.
If an object is too large to fit on a single line (which typically has only five X's), it is put on multiple lines and padded with zero's, eg.
^GF(1,2) 3 0 1 2 3
^GF(1,2) 4 0 0 0 0
(the GF object requires 6 16 bit words, hence the 4 padding zeroes).
Note structure:
Each staff can contain up to four layers, where a layer correspond to a horizontal ‘line’ of notes. Each layer is broken up into frames, where each frame is one measure of a layer.
^GF(s,m) C FLAGS F1 F2 F3
^GF(s,m) F4 0 0 0 0
Here S is the staff number, M the measure number, FLAGS is a 16-bit bit-vector, and F1 to F4 are frame identifiers. C is a clef-identifier.
There is a second variant of the ‘GF’ tag, which has only one line; it looks like
^GF(s,m) FR C X Y Z
here, ‘fr’ is a frame number, ‘c’ the clef number. The function of x, y , z is unknown.
A frame is described by the FR tag
^FR(N) N1 N2 0 0
This means frame number N runs from note N1 to note N2 Where ‘running from’ is interpreted as "that part of a linked note list that starts with note N1 and ends with note N2". This is something different from the sequence of notes N1, N1 + 1 , ... , N2 - 1, N2.
Notes (or more accurately chord-notes/rests) are described as follows:
^eE(N) L1 L2 DUR POS $FLAGS EXTFLAGS PITCHCOUNT
pitchrecords
This is note number N (in list where L1 and L2 are previous and next).
Durations are stored as a number where 1024 is the quarter note, 512 the eighth, etc. Dotted notes are stored by multiplying the dur field appropriately.
pitchcount is the number of pitch records. Each pitchrecord looks like
pitch $flags
(note that the line starts with spaces, and not with a caret)
pitch is a 16 bit number, where the lower order 4-bits is a signed nybble which adds an alteration (0 = natural, 1 = sharp, etc.) The remaining 12 bits encodes the note-name (octave inclusive.)
Both the alteration and the note-name are relative to the scale as defined by the key-signature in this measure. The person who invented this should have his head checked out.
The key and time signature are defined in the MS field. The measure struct is documented in the SDK file edata.h
^MS(n) space key beats beatlen y z
N is the measure number. SPACE is the width of the measure (?), KEY the number of the keysignature (0 = C major, 1 G major, etc. 255 = F major, 254 = Bflat major). beats and beatlen determine time signature. Y and Z are two 16bit bit-fields. The bits are documented in the SDK.
Key and time are determined score wide. The mind boggles at how they plan to do polytonal and polymetric music. And how do they do mid-measure keychanges?
Slurs are (among others) stored with an Sx tag
^Sx(SLURNUMBER) STUFF
The slur has many parameters. The 6th number on the first line is the starting note, the 3rd number on the 4th line the ending note.
Articulation is stored in a two-step process: for every articulation there is an
IM(n,m) def h1 h2 v1 v2
H1, H2, V1 and V2 are offsets. DEF is the number of an articulation definition. M is the note number.
The articulation definition looks like
IX(n) ... [24 16-bit words] ..
the layout is described in edata.h. The first two words contain info on the glyph.
More tags:
RU - repeat
ES - end repeat
ET - end repeat text
BR - backw repeat
mt - measure text
pT - page text
TX - text blocks
SD - shape
DY - score expr
AC - tempo
GF - clef
IS - staff spec
DO (shape expression),
DT (text expression),
IK (chord playback),
IS (staff spec),
IV (chord suffix),
IX (articulation definition - documented in edata.h),
Iu (instrument used - documented in edata.h),
LA (layer preferences - documented in eprfdata.h),
MN (measure number region),
MS (measure spec),
PS (page spec),
RS (repeat style - documented in edata.h),
RT (text repeat style text - documented in edata.h),
SD (shape),
SS (staff system spec),
TX (text block),
pT (page text)
TP - tuplet
sl - slur shapetag