╔══════════════════════════════════════════════════╗
║ ║
║ T H E C F T F I L E F O R M A T ║
║ ════════════════════════════════════════════ ║
╚══════════════════════════════════════════════════╝
┌────────────────────────────────────────┐
│ <shft> F1 = Toggle to regular window │
└────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────┐
│ │
│ If you are reading this document for the first time and │
│ are unfamiliar with the commands for scrolling the text, you │
│ should be aware that <ctrl> ▲ (hold down the <ctrl> key and │
│ push the cursor UP key) will scroll the text UP and <ctrl> ▼ │
│ will scroll the text DOWN. You can also use the PageUp and │
│ PageDown keys to scroll quickly through the document. │
│ │
└──────────────────────────────────────────────────────────────────┘
1.1 A CFT file is a compression of a musical data set. A musical
data set may consist of
(1) a single MPG file representing a single page of musical
notation,
(2) a directory containing one or more MPG files, or
(3) a set of directories, each containing one or more MPG
files.
1.2 There are two advantages to having a compressed format for
musical data sets.
(1) Size. A typical MPG file representing a full page page of
musical notation averages about 30,000 bytes in size. The MPG
representation of a full score of a work such as J.S. Bach's
B-minor Mass, for example, requires about 9.3 megabytes. The
CFT compression of the same work takes about 1.77 megabytes,
making the compression ratio between the two formats in this
case about 5.2 to 1. Transmitting large data sets in the CFT
format takes about one fifth the time required to transmit the
same information in MPG file format.
(2) Simplicity. A musical data set in MPG format could have
as many as two hundred directories and more than one thousand
separate MPG files. Regardless of its size or complexity, the
CFT compression of a data set is always just one large file.
When storing or transmitting information, it is much easier to
deal with one large file than with many smaller files.
1.3 For purposes of displaying and printing music, it is just as
easy to work from a CFT file as from a set of MPG files. The
only reason to expand a CFT into its MPG component files is for
the purpose of editing the files (i.e., modifying the musical
notation). A CFT file cannot be edited, because the compression
algorithm itself is content dependent. Likewise, CFT files
cannot be subdivided or merged with other CFT files.
1.4 Dmuse provides utilities for both compressing (to CFT format)
and expanding (to MPG format) musical data sets. This means
that you can store your musical data efficiently (in CFT format)
and can also edit your musical data (in MPG format). You may also
use the editor to create new MPG files and later compress them
to CFT format. In this way, you can become an originator or
source of CFT files for publication on the internet.
──────────────────────────────────────────────────────────────────
2.1 Under normal circumstances, you would never have a reason
to examine the contents of a CFT file. Since a CFT file is not
an ASCII (character based) file, you can only view it in HEX
format. For those people interested, however, we include a
brief description of how a CFT file is organized.
┌───────────────────────┐
│ CFT file organization │
└═══════════════════════┘
I. Title and Offset information
Field 1: (8 bytes) Source of file e.g., CCARH
Field 2: (4 bytes) Version number (compression technique, etc)
Field 3: (4 bytes) Checksum number (for file varification)
Field 4: (4 bytes) Byte offset to File Organization section
Field 5: (4 bytes) Byte offset to Data Group offsets
II. Header information (byte offset = 24 bytes)
Field 1: byte 1: length of field in bytes (up to 100)
bytes 2..: composer
Field 2: byte 1: length of field in bytes (up to 100)
bytes 2..: work
Field 3: byte 1: length of field in bytes (up to 50)
bytes 2..: type of representation
e.g., Full Score
Complete Parts
Violin I
Field 4: byte 1: length of field in bytes (up to 50)
bytes 2..: resolution
e.g., 300 dots/inch
III. File Organization (offset contained in bytes 17..20 of file)
A CFT file may be one of three types.
1. It may be a compression of a single file
(generally not used)
2. It may be a compression of a set of MPG page
files from a single directory.
e.g., the full score of a work with only
one movement.
3. It may be a compression of <n> directories, each
containing a set of MPG files.
e.g., the full score of a work with <n> movements.
the set of parts for <n> instruments.
the part for one instrument, divided into
<n> movements.
Field 1: (one byte) 0 = case 1
1 = case 2
2 = case 3
Case 1:
Field 2: (one byte) 0x00
Field 3: (one byte) 0x00
Field 4: byte 1: length (up to 100)
bytes 2..: sub-divsion name (optional)
e.g. Movement 1
e.g. Violine I
Field 5: byte 1: length (up to 40)
bytes 2..: note size
e.g. 14 dots per staff line
21 dots per staff line
14 and 21 mixed
Field 6: (one byte) 0x00
Field 7: (one byte) <page number of this MPG file>
Field 8: (two bytes) 0x0002
Case 2:
Field 2: byte 1: length (up to 13)
bytes 2..: name of default path (directory)
for expansion
Field 3: (one byte) 0x00 = single sub-division name
0x01 = multiple sub-division names
0x02 = single sub-division name
plus a CONTENTS file
Field 4: (case 0x00)
byte 1: length (up to 100)
bytes 2..: sub-divsion name (optional)
e.g. Movement 1
e.g. Violine I
(case 0x01)
bytes 1-2: <n> = number of sub-division names
bytes 3-4: sequence number of CONTENTS file
(zero = no CONTENTS file)
bytes 5-6: length of data string
bytes 7..: data string
data string = <n> repetitions of:
byte: <k> = length of name
k-bytes: name
(case 0x02)
bytes 1-2: sequence number of CONTENTS file
byte 3: length (up to 100)
bytes 4..: sub-divsion name (optional)
e.g. Movement 1
e.g. Violine I
Field 5: byte 1: length (up to 40)
bytes 2..: note size
e.g. 14 dots per staff line
21 dots per staff line
14 and 21 mixed
Field 6: (one byte) <p> pages (high order byte)
Field 7: (one byte) <p> pages (low order byte)
Field 8: (two bytes) 0x0002
Case 3:
Field 2: byte 1: length (up to 13)
bytes 2..: name of default path (directory)
for expansion
Field 3: (one byte) <n> (1 to 255) number of
sub-directories
Fields 4..8: are repeated <n> times
Field 4: byte 1: length (up to 100)
bytes 2..: sub-divsion name
e.g. Movement 1
e.g. Violine I
Field 5: byte 1: length (up to 40)
bytes 2..: note size
e.g. 14 dots per staff line
21 dots per staff line
14 and 21 mixed
Field 6: byte 1: length (up to 13)
bytes 2..: name of default path
(sub-directory) for expansion
Field 7: (one byte) <p> pages
Field 8: (two bytes) data group number of first page
IV. Data group offsets and lengths (offset contained
in bytes 21..24 of file)
Each offset/length pair is stored in two 4-byte groups.
Offsets are measured from the beginning of the file.
Case 1: There are only only 2 data groups: i.e. the
compression key and the page data
Case 2: There are <p> + 1 data groups: i.e the
compression key, and data for <p> pages
Case 3: There are \ <n>
SUM | <p(i)> + 1 data groups:
/i = 1
i.e., the compression key, and the sum of all of
the pages from all of the sub-directories
V. Data groups
The first data group is always the cypher.
Each subsequent data group represents a page of music.
Each page data group begins with three header fields.
Field 1: byte 1: byte length of field
bytes 2..: name of file (for expansion purposes)
Field 2: 4 bytes: number of data records in file
Field 3: 4 bytes: length of data in bits.
This field is required, because
the compression is binary.
If this description of the CFT format seems confusing, don't
worry about it. We repeat what we said earlier; you probably will
never have recourse to look inside one of these files.
──────────────────────────────────────────────────────────────────