..
.
AUDIO FILE FORMAT RESOURCE GUIDE (Version 1.1)
by Dave Huizing
1 TABLE OF CONTENTS
2 GENERAL INFORMATION
2.1 Foreword
2.2 Printed Version
2.3 Copyrights
2.4 Disclaimer
2.5 Contributrors
3 TX WAVE FORMAT
4 YAMAHA TYPHOON WAVE FILE FORMAT
4.1 DWVW v1.2 compression
4.2 DWVW sample delta bit frame
5 D009
5.1 The D00 header
5.2 The Instrument data
5.3 The SpFX data
5.4 The Arrangement data
5.5 The Sequence data
6 MIDI SAMPLE DUMP STANDARD
6.1 INTRODUCTION
6.2 SPEC: SAMPLE DUMP FORMATS
6.3 SPEC: SAMPLE DUMP MESSAGES
6.4 HANDSHAKING MESSAGES:
6.5 DUMP PROCEDURE: MASTER (DUMP SOURCE)
6.6 DUMP PROCEDURE: SLAVE (DUMP DESTINATION)
6.7 SDS OVERVIEW
7 ROL
7.1 Structure of .ROL files
7.2 Notes
8 8SVX
8.1 FORMblock [VHDR]
8.2 FORMblock [BODY]
9 AIFF
10 AU
11 FSM
12 GF1 PATCH
13 S3I
14 UWF
15 WAVE
15.1 RiffBLOCK [data]
15.2 RiffBLOCK [fmt ]
15.3 RiffBLOCK [loop]
16 ZYXEL
17 CREATIVE LABS FILE FORMATS
17.1 Sound Blaster Instrument File Format (SBI)
17.2 Creative Music File Format (CMF)
17.3 The CMF Instrument Block
17.4 The CMF Music Block
17.5 Sound Blaster Instrument Bank File Format (IBK)
18 CREATIVE VOICE (VOC) FILE FORMAT
19 REVISION HISTORY
2 General information
2.1 Foreword
I started to compile this document after I thought there was a need
for
it. By surfing all around the web I collected these descriptions
and
brought them to this document.I have planed to keep this document
updated
so if theres any file format description thats not in this document,
or
you have any comments on this document please send me an email
message at:
stallion@worldonline.nl.
Happy developping,
Dave Huizing
2.2 Printed Version
If you need a printed version send an email.
2.3 Copyrights
Only the title and the compilation is copyrighted by Dave Huizing.
As far
as I know all this information is free for use. See the disclaimer
part
for more details. All trademarks, technical information and file
extensions belong to their respectfull owners.
2.4 Disclaimer
This document is provided on a as is base. The information has been
verified as far as possible, but I cannot be held responsible for
any
problems caused by use or misuse of the information. All due I
think I
wont happen I am also not responseble for any damage to any knid
of
computer system after or while
using parts form this documentation. Use this document on your
own risk.
2.5 Contributrors
Dave Huizing, stallion@worldonline.nl
DJ, Producer, DTP designer, etc
muki pakesch, mpakesch@t0.or.at
Maintainer of the TX16W mailinglist
Markus - Jvnsson , f93-maj@nada.kth.se
Author of the Awave sample convertor
3 TX Wave Format
The file consists of a 32 byte header followed by the actual waveform
(the
first 16 bytes only identifies the file type). In C syntax
the header
would look like this:
char filetype[6] = "LM8953"
char nulls[10]
char dummy_aeg[6]
space for the AEG (never mind this
char format
0x49 = looped, 0xC9 = non-looped
char sample_rate
1 = 33 kHz, 2 = 50 kHz, 3 = 16 kHz
char atc_length[3]
I'll get to this...
char rpt_length[3]
char unused[2]
set these to null, to be on the safe side
The "atc_length" and "rpt_length" fields are quite complex.
First of all
you should know that there is no such thing as a looping point
in a TX
wave. Instead a wave is split into two parts, the attack part and
the
repeat part (of course the actual wave data isn't split, this is
just a
logical definition). As you might guess, the attack part
is played first
and the repeat part is looped until the key is released. Each of
these
parts are limited to a maximum of 128k words in length. That is
the reason
why waves can't be longer than 256k words (4096 blocks).
The length of a part is stored LSB first (Intel). And only
the least
significant _bit_ of the third byte (bit 0) is used (representing
the most
significant bit of the length). Are you confused yet? Then
hold your
breath. It seems that Yamaha has chosen to squeeze in the sample
rate(!)
of the wave in the unused _bits_ of these last bytes. Although
they
already have a separate byte for the sample rate, this isn't enough.
I
won't go into details on this now (or you would be even more confused).
You only need to know that the possible values are:
0x06, 0x52 = 33 kHz
0x10, 0x00 = 50 kHz
0xF6, 0x52 = 16 kHz
(The first value is located in byte three of "atc_length" and the
second
value is located in byte three of "rpt_length".) To wrap it up,
this is
the format of the two length fields on a bit level:
[0]
[1]
[2]
atc_length
AAAAAAAA
BBBBBBBB
DDDDDDDC
rpt_length
EEEEEEEE
FFFFFFFF
HHHHHHHG
A
LSB of the attack length
B
MSB of the attack length (except for one bit)
C
the utterly most significant _bit_ of the attack length
D
the first value of the magic sample rate constant (0x06,
0x10 or 0xF6)
E
LSB of the repeat length
F
MSB of the repeat length (except for one bit)
G
the utterly most significant _bit_ of the repeat length
H
the second value of the magic sample rate constant (0x52,
0x00)
Now for the most important (and probably most interesting) part.
The
waveform data. As you certainly know the TX uses 12-bit sampling
resolution, and this requires some kind of encoding if we are not
willing
to waste one fourth of our disk space. Yamaha has chosen
to group the
samples two by two, making three bytes of data in the file for
each pair.
I'll illustrate this on a bit level (as with the lengths above):
AA CD BB
A
MSB of the first sample
B
MSB of the second sample
C
least significant nybble (oh, is that the correct spelling?)
of the first
sample
D
least signiticant nybble of the second sample
4 Yamaha Typhoon wave file format
This specification describes the compression algorithm for Typhoon
format
waves. It does not cover the file format, which is AIFF-C. The
documentation for AIFF-C is available at the site ftp.sgi.com in
the
directory /sgi/aiff-c.9.26.91.ps.Z (compressed Postscript file).
4.1 DWVW v1.2 compression
DWVW was invented 1991 by Magnus Lidstrom and is copyright 1993
by NuEdge
Development. You have the right to use the algorithm freely as
long as you
make no false claims on its origin. DWVW is a lossless (or bit
faithful)
compression method for digital audio data. Lossless means that
the exact
original data will be preserved when compressing and decompressing.
The compression utilize the fact that the delta between the sample
points
is generally less than the full dynamic width. Each sample point
is
subtracted from the previous one and the difference is enthropy
encoded in
a special format. Therefore the compression works best on low frequency
sounds with low noise ratio, where the difference between each
sample is
small.
DWVW can be applied on samples of any bit resolution and with any
number
of channels. As opposed to AIFF standard, sample bits are not "left
justified". Instead the necessary translation should be done when
decompressing. Also, while AIFF interleaves multichannel sounds,
DWVW
doesn't as this complicates compression and decompression.
Each channel follows one another with only a slight break in the
bit run.
The first delta for each channel should be put at an even 16-bit
word
position. The encoding stores the delta points with only as many
bits as
is required (hence the name "variable word width").
Thus, the number of bits used by each delta has to be stored as
well.
Since this count varies very little we apply a (simpler) delta
encoding on
this information.
To wrap it up, each compressed sample point consists of two values:
the
delta from the last sample and the difference in word width of
this delta
from the last delta (hereby referred to as "the WWM" - the word
width
modifier).
Even though the word width modifier is stored first in each delta
frame we
will describe the delta information first. The delta is always
stored as
an absolute difference (i.e. unsigned) in a varible number of bits.
An
extra bit follows that tells the sign (if the delta isn't zero).
The
number of bits required for the delta (i.e. the word width) is
decided by
the position of the most significant high bit in the absolut value.
One
bit less than this is actually stored since the first bit is always
high.
For instance, the delta 11 (binary 1011) has a required word width
of four
bits ,but only the least significant three bits are stored. A zero
delta
will have a zero word width and consequently requires neither delta
bits
nor sign bit. A delta of one will require only a sign bit.
One special case requires attention. A normal two's complement number's
lowest negative number is one less than the highest positive number.
Treating zero as a positive value this gives exactly as many negative
as
positive numbers. The delta encoding on the other hand does not
consider
zero to be of any sign and does therefore not include the one extra
negative value. If this value is encountered in the delta stream
it is
encoded as one greater than it actually is (putting it within the
expressable range of values).
To distinguish it from the next lowest value one extra bit is inserted
after the sign bit. The bit is high for the lowest value and low
for the
next lowest value.
For example, a 16-bit two's complement number can be -32768. It
would be
encoded as negative 32767 with an extra high bit. The value - 32767
would
also be encoded as negative 32767 but with the extra bit low. Of
course,
only these two values require the extra bit.
The WWM preceeds the delta bits. It is encoded as a series of low
bits (0)
terminated by a high bit (1) (in most cases). The count of low
bits tells
the modifier amount. If the modifier isn't zero an extra bit follows
that
tells the modifier sign. A high bit means negative modifier. Word
width
"wraps" at the used bit resolution (new-width =3D (original-width
+
modifier) modula bit- resolution).
This enables us to go from a small width to a large width by using
a
negative modifier. Because of this fact a WWM will never need to
be larger
than the sound bit resolution divided by two (rounded downwards).
If the
modifier is the maximum the terminating high bit would be superfluous,
so
in this case it isn't inserted. (However; the sign bit is always
included,
even if the bit resolution is even.)
For encoding the current word width and sample value should be initially
reset to zero for each channel (the first delta will thus be the
sample
value). A compressed channel always starts on an even 16-bit word
boundary. Notice that the highest possible compression ratio is
eight
times, i.e. one bit per sample. This occurs when the source is
continous
series of zero samples.
4.2 DWVW sample delta bit frame:
0...
WWM is the count of low bits (can be none)
1
terminating high bit (if not max W=WM)
ms
WWM sign, high is negative (only on non-zero WWM)
delta
(word width - 1) sample delta bits (if delta 1)
sb
delta sign bit (only on non-zero delta)
xb
extra bit (only on lowest and next lowest possible delta value)
Some encoding examples (the examples all represent extreme situations
with
unusually poor
compression):
Bit resolution
16
Delta
923 (bin 00000011 10011011=)
Current width
1
New width
10
Modifier
-7 (mod 16 =3D 10)
Yields
0000000 1 1 110011011 0
Bit resolution
12
Delta
-2048 (bin 1000 00000000)
Current width
0
New width
11
Modifier
-1 (mod 12 =3D 11)
Yields
0 1 1 1111111111 1 1
(-2048 is encoded as 2047 with extra bit and negative high)
Bit resolution
8
Delta
-12 (bin 11110100, negated 00001100)
Current width
0
New width
4
Modifier
+4
Yields
0000 0 100 1 (no terminating bit for WWM)
5 D00
This part describes the D00 music format (used by the AdLib player
v4.01
coded by JCH/Vibrants) in more detail than the docs of EdLib (the
respective tracker, also coded by JCH) do. This document assumes
that you
already own EdLib and have some experience with it. Also, the availability
of the EdLib docs as well as of the docs for the player included
with
EdLib is assumed. You should know some basics about AdLib programming
and
data formats (byte, word etc.) as well as the EdLib structures
(Instruments, SpFX etc.) and with hexadecimal notation.
5.1 The D00 header
A description of the D00 header can be found in the player's docs.
So I
won't show it again here. But JCH gives very cryptic names to the
other
file structures, so I'll call them differently:
JCH's names
My names
TPoin tables
Arrangment data
SeqPointer tables
Sequence data
Instrument data
Instrument data
DataInfo text
Song description
Special tables
SpFX data
Also, I should mention that all the pointers to these tables are
meant
relative to the beginning of the D00 file.
5.2 The Instrument data
The instrument data simply consists of all instruments used in the
song.
Since the number of instruments is stored nowhere inside the file,
loaders
should the start offset of the next structure for determining if
they have
read enough data. The data for each instrument consists of 16 bytes,
which
occur in the same order as the corresponding bytes in the EdLib
Instrument
table:
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
+------------+ +------------+ & &
& & & &
Carrier data Modulator data &
& & & +---Unused
& & & +Hard restart SR value
& & +Hard restart timer
& +Fine-tune
+AM/FM + Feedback
For the exact meaning of these bytes, read the EdLib manual. Note
that in
the Carrier and Modulator data the ADSR parts are not stored
word-oriented, but byte-oriented. That means, they aren't stored
as a word
whose High byte is the AD part and whose Low byte is the SR part
(although
the display in EdLib creates that assumption).
Instead they're simply stored as two bytes of which the first one's
the AD
part and the second one's the SR part. 5.3 The SpFX data The SpFX
data ist
stored more or less like the Instrument data, but one single table
entry
consists of only 8 bytes arranged like this:
xxxx xx xx xx xx xxxx (note xx's are BYTES and xxxx's are
WORDS!)
& & &
& & &
& & &
& & +Pointer to next SpFX entry
& & &
& +Duration of SpFX entry in Frames
& & &
+Modulator Level add
& & +New Modulator
level
& +Note add value
+Instrument to use
Again, to really understand the meaning of these parts, you should
read
the EdLib docs.
5.4 The Arrangement data
The arrangement data determines which sequence is to be played on
which
channel at which moment and in which way, if you understand what
I mean :)
It consists of two parts: The Pointer part and the Data part (I
simply
call them that way now :). The Pointer part consists of 16 word
pointers
and one endmark (all endmarks are FFFFh, by the way). Only the
first nine
pointers are used at the moment: one for each one of the nine AdLib
channels. Each one of these nine pointers points to the part of
the Data
part which belongs to its channel. The Data part consists, as you'd
have
guessed before, of nine independent arrangement streams. Each one
of tese
streams has the following format:
First comes a word telling the speed of that stream. Since this
information is stored at the beginning of EVERY stream, I assume
that
every channel may have its own unique speed, and EdLib simply doesn't
support this.
After that, the real arrangement data is stored. This data is organized
like this: If a word below 8000h is read, it's the number of a
sequence to
be played. In that case, the saved transpose data is used.
But if a word 8XYYh is read, with X and YY being any value, the
transpose
data is updated to X and YY (see the EdLib docs for information
on the
meaning of X and YY).
I have found out that the first arrangement entry for an arrangement
stream that contains at least one sequence is always such a command
to set
the
internal transpose data. So no default value is required to be
loaded into
the transpose data before playing. And looping the arrangement
stream
becomes easier.
If the word FFFFh is read, the arrangement stream has arrived at
its
looping point. The word following the FFFFh is an offset into the
arrangement stream telling at which position the stream should
be
restarted. If the word FFFEh is read, the arrangement stream has
reached
its end. Unlike the Loop command (FFFFh), the stream mustn't get
restarted
but halted. Also, there is no word following the FFFEh command.
5.5 The Sequence data
The Sequence data again consists of a pointer part and a data part.
But
this time these two parts aren't stored in different parts of the
file,
the data part is stored directly after the pointer part. Therefore,
a
reference to a specific pattern should be seen as a reference to
a word
counted from the beginning of the Sequence data.
This word (e.g. the first word for Pattern 0000h) then points to
the
offset of the actual sequence data inside the file. I hope you
got my
point... Then, each sequence is stored as follows: Read a word.
If it's
high byte is below 20h, then it's a note. Note that RESTs and HOLDs
are
also counted as notes. In this case, the low byte can contain the
following values:
00h = REST
The high byte tells the number of rests to insert minus one! e.g.
a REST
with a high byte of 01h means "Two RESTs"
01h - 7Dh = Note
The value of this note byte tells the amount of halfnotes to add
to C-0
(e.g. 01h would mean C#0). In this case, the high byte tells the
number of
HOLDs to insert after the note.
7Fh = HOLD
The high byte tells the number of HOLDs minus one again!
If the high byte is 20h or above, but below 40h, it's a note again,
but
this time with Tienote switched on. The high word is used as repetition
count again, but don't forget to substract 20h before evaluating
it!!
If the high bzte is 40h or above, it's an effect. In this case,
the
complete word can simply be interpreted like any EdLib effect (set
instrument, set volume etc.). See the EdLib docs for a list of
them.
The note word this effect refers to follows directly after the ceffect
word.
If the read word is FFFFh, it indicates the end of that sequence.
In that
case, the next sequence to be played should be determined and loaded
and
the first effect/note of it should be played.
6 MIDI SAMPLE DUMP STANDARD
6.1 INTRODUCTION
The MIDI SDS was adopted in January
1986 by the MIDI
Manufacturers Association and the Japanese MIDI Standards
Committee. The
SDS defines the standard method for transfer of sound sample
data
between MIDI-equipped devices. Sample dumps may be
accomplished with
either an 'open loop' or 'closed loop' system.
The open loop method simply involves the straight dump of all sample
data
from its source to the destination, with no timeouts, packet
acknowledgements, or any other form of handshaking, much as in
the manner
of a sysex bulk dump, usually intiated at the source.
The closed loop method allows the use of handshaking messages between
the
dump source and destination, and usually places
the dump process
under the control of the slave, to allow it time to process
the incoming
data as necessary. As with any standard, it can not
be assumed that a
device adheres to it unless the accompanying documentation specifically
indicates it. Even then, it is best to check its conformity with
non-critical data.
6.2 SPEC: SAMPLE DUMP FORMATS
DUMP HEADER: F0 7E cc 01 ss ss ee ff ff ff gg gg gg hh hh hh ii
ii ii jj
F7
cc
channel number
ss ss
sample number (LSB first)
ee
sample format (number of significant bits; 8->28)
ff ff ff
sample period (1/sample rate) in nanoseconds (LSB first)
gg gg gg
sample length, in words
hh hh hh
sustain loop start point (word number) (LSB first)
ii ii ii
sustain loop end point (word number) (LSB first)
jj
loop type (00:forwards only; 01:alternating)
DATA PACKET: F0 7E cc 02 kk <120 bytes> mm F7
cc
channel number
kk
running packet count (00->7F)
mm
checksum (XOR of 7E, cc, 02, kk <120 bytes>)
The total size of a data packet is 127 bytes.
This is to avoid overflow
of the MIDI input buffer of a device that may want to receive an
entire
packet before processing it. A data packet consists of its own
header, a
packet number, 120 bytes of data, a checksum, and an EOX.
The packet
number begins at 00 and increments with each new packet.
It resets to 00
after it reaches 7F, and continues counting.
The packet number is used by the receiver to distinguish between
a new
data packet, or a resend of a previous packet.
The packet number is
followed by 120 bytes of data, which form 60, 40, or
30 words (MSB first
for multiword samples), depending on the length of a single
data sample.
Each data byte hold seven bits, with the msb in each byte
set to 0, in
order to conform to the requirements of MIDI data transmission.
Information is left justified within the 7-bit bytes, and
unused bits are
filled with 0. Example: Assume a data point in the
memory of a 16-bit
sampler, with the value 87E5. In binary, that would be:
1000 0111 1110 0101
and would be encoded as the following MIDI data stream:
01000011 01111001 00100000
The checksum is the running XOR of all the data after the
SYSEX byte, up
to but not including the checksum itself.
6.3 SPEC: SAMPLE DUMP MESSAGES
DUMP REQUEST: F0 7E cc 03 ss ss F7
cc
channel number
ss ss
sample number requested (LSB first)
Upon receiving the request, the sampler checks the sample
number to see
if it is within legal range. If it is not,
the request is ignored.
If it is, the sample dump is started. One packet at a time is sent,
under
control of the handshaking messages outlined below.
6.4 HANDSHAKING MESSAGES:
For all below:
cc
channel number
pp
packet number
Packet numbers are included in the
handshaking messages to
accomodate machines that have the intelligence to re-transmit specific
packets after an entire dump is finished, or if
synchronization is
lost.
ACK
F0 7E cc 7F pp F7
Means last packet was recieved correctly
(checksum OK, etc), please
send next one. Packet number is packet being acknowledged
as correct.
NAK
F0 7E cc 7E pp F7
Means last packet not received correctly,
please send again. Packet
number is packet being rejected.
CANCEL
F0 7E cc 7D pp F7
Means abort dump immediately. Packet number is packet
on which abort
occurs.
WAIT
F0 7E cc 7C pp F7
Means pause dump indefinitely, until next message is sent. Allows
the
unit recieving the dump to perform other functions (disk access,
etc),
before receiving the remainder of the dump. The next message
it sends (eg
ACK, ABORT) will determine if the dump continues or aborts.
6.5 DUMP PROCEDURE: MASTER (DUMP SOURCE)
Once a dump has been requested, either via MIDI or through
the front
panel, the DUMP HEADER is sent.
After sending the header, the master must time out for
at least two
seconds, to allow the receiver to decide if it will accept this
sample
(has enough memory, etc).If it receives a CANCEL, within
this time,
it should abort immediately.
If it receives an CAK, it will start sending packets
immediately. If it
receives a WAIT, it pauses until another message is received,
and then
processes that mesage normally. If nothing
is recieved within the
timeout, an open loop is assumed, and the dump starts with the
first
packet.
After sending each packet, the master should time
out for at least 20
milliseconds and watch its MIDI In.
If an ACK is received, it sends the next packet
immediately. If it
receives an NAK, and the packet number matches the number
of the last
packet sent, it resend that packet If
the packet numbers don't
match, and
the device is incapable of sending packets out of order, the NAK
will be
ignored.
If a WAIT is received, the master should watch its MIDI In
port
indefinitely for another ACK, NAK, or CANCEL message, which
it should
then process normally.
If no messages are received within
20 milliseconds of the
transmission of a packet, the master
may assume an open loop
configuration, and send the next packet.
This process continues until there are less than 121 data bytes
to send.
The final packet will still consist of 120n bytes, regardless of
how
many significant bytes actually remain, and the unused bytes will
be
filled with zeroes. The receiver should
handshake after receiving
the last packet.
6.6 DUMP PROCEDURE: SLAVE (DUMP DESTINATION)
When receiving a sample dump, a device should keep a running checksum
during reception. If its checksum matches the checksum in the data
packet, it will send an ACK and wait for the next packet.
If it does not match, it will send
an NAK containing the number of
the packet that caused the error, and wait for the next packet.
If, after
sending an NAK, the packet number of the next packet doesn't match
the
previous packet number (the one that was NAK'd), and
the unit is not
capable of accepting packets out of order, the error is
ignored and the
dump continues as if the checksums had matched.
If a receiver runs out of memory before the dumpo is completed,
it should
send a CANCEL to stop the dump.
6.7 SDS OVERVIEW
DUMP DATA FORMAT: DUMP HEADER
Sysex
ID: Universal Non-Real Time
Channel Number
Sub ID: Header
Sample Number (2 bytes, LSB first)
Sample Format
Sample Period (3 bytes, LSB first)
Sample Length (3 bytes, LSB first)
Sustain Loop Start Point (3 bytes, LSB first)
Sustain Loop End Point (3 bytes, LSB first)
Loop Type
Eox
SAMPLE DUMP DATA FORMAT: DATA PACKET
Sysex
ID: Universal Non-Real Time
Channel Number
Sub ID: Data Packet
Packet Number
Sample Data (120 bytes)
Checksum
Eox
SAMPLE DUMP MESSAGES: DUMP REQUEST
Sysex
ID: Universal Non-Real Time
Channel Number
Sub ID: Dump Request
Sample Number (2 bytes, LSB first)
Eox
SAMPLE DUMP MESSAGES: HANDSHAKING FLAGS:
Sysex
ID: Universal Non-Real Time
Channel Number
Sub ID: ACK or NAK or CANCEL or WAIT
Packet Number
Eox
7 ROL
This part contains details of .ROL files used by AdLib and compatible
cards on PC It is also used by Visual Composer (TM).
7.1 Structure of .ROL files:
fld #
size
(bytes)
type
description
1
2
int
file version, major
2
2
int
file version, minor
3
40
char
unused
4
2
int
ticks per beat
5
2
int
beats per measure
6
2
int
editing scale (Y axis)
7
2
int
editing scale (X axis)
8
1
char
unused
9
1
char
0 = percussive mode
1 = melodic mode
10
90
char
unused
11
38
char
filler
12
15
char
filler
13
4
float
basic tempo
Field 14 indicates the number of times to repeat fields 15 and 16:
fld #
size
type
description (bytes)
14
2
int
number of tempo events
15
2
int
time of events, in ticks
16
4
float
tempo multiplier (0.01 - 10.0)
The remaining fields (17 to 34) are to be repeated for each of 11
voices:
fld #
size
type
description (bytes)
17
15
char
filler
18
2
int
time (in ticks) of last note +1
Repeat the next two fields (19 and 20) while the summation of field
20 is
less than the value of field 18:
fld #
size
type
description (bytes)
19
2
int
note number: 0 => silence from 12 to 107 => normal note (you
must subtract 60 to obtain the correct value for the sound driver)
20
2
int
note duration, in ticks
21
15
char
filler
Field 22 indicates the number of times to repeat fields 23 to 26:
fld #
size
type
description (bytes)
22
2
int
number of instrument events
23
2
int
time of events, in ticks
24
9
char
instrument name
25
1
char
filler
26
2
int
unused
27
15
char
filler
Field 28 indicates the number of times to repeat fields 29 and 30:
fld #
size
type
description (bytes)
28
2
int
number of volume events
29
2
int
time of events, in ticks
30
4
float
volume multiplier (0.0 - 1.0)
31
15
char
filler
Field 32 indicates the number of times to repeat fields 33 and 34:
fld #
size
type
description (bytes)
32
2
int
number of pitch events
33
2
int
time of events, in ticks
34
4
float
pitch variation (0.0 - 2.0, nominal is 1.0)
7.2 Notes
Fields #1 and #2 should be set to 0 and 4 respectively. Field #10
should
be filled with zeros.
8 8SVX
The 8SVX files are IFF files used for digital audio data. The format
of
the VHDR block is complete guesswork. These files use Motorola
byte order.
The 8SVX file format is fixed to 8-bit mono sample data - at least
GoldWave does not support saving files in any other format than
8-bit
mono.
8.1 FORMblock [VHDR]
This is the sample information block. The normal size is 20 bytes.
OFFSET
Count
TYPE
Description
0000h
1
dword
Sampling rate of digital data in Hz. This count seems not to
be too accurate, at least GoldWave v2.0 creates different
rates for Wave and 8SVX files.
0004h
4
dword
Other data, unknown
8.2 FORMblock [BODY]
This block contains the raw sample data, maybe the usual IFF compression
was used. The details of both the compression and the information
about
the IFF format are unknow.
9 AIFF
The Audio Interchangeable File Format files are digital audio files
stored
in the IFF format; the samples are stored in signed PCM. The header
block
is [AIFF], different subblocks are :
[AUTH]
The authors information optional
[COMM]
This record stores information about the sampled data
OFFSET
Count
TYPE
Description
0000h
1
word
number of channels or number of instrument samples ???
0002h
1
dword
Sample length
0006h
1
dword
lower frequency
000Ah
1
dword
maximum frequency
000Dh
1
dword
???
[MARK]
[NAME]
The name of the instrument / sample
[SSND]
The stored sample data.
10 AU
The AU files are digital audio files used by the Sun and NeXT
workstations. Further information wanted.
OFFSET
Count
TYPE
Description
0000h
4
char
ID='.snd'
0004h
1
dword
Offset of start of sample
0008h
1
dword
Length of stored sample
000Ch
1
dword
Sound encoding :
1 - 8-bit ISDN u-law,
2 - 8-bit linear PCM (REF-PCM),
3 - 16-bit linear PCM,
4 - 24-bit linear PCM,
5 - 32-bit linear PCM,
6 - 32-bit IEEE floating point,
7 - 64-bit IEEE floating point,
23 - 8-bit ISDN u-law compressed(G.721 ADPCM)
0010h
1
dword
Sampling rate
0014h
1
dword
Number of sample channels
11 FSM
The .FSM files are samples to be used for module style music with
the
Fandarole Composer. Currently only samples of up to 64K length
are
supported, altough the header reserves a dword for the sample size.
OFFSET
Count
TYPE
Description
0000h
4
char
ID='FSM',254
0004h
32
char
ASCII name of sample
0024h
3
char
ID=10,13,26
0027h
1
dword
Length of sample (<=64K)
0028h
1
byte
Fine tune value for sample (currently unsupported)
0029h
1
byte
Sample volume (currently unsupported)
002Ah
1
dword
Start of sample loop
002Dh
1
dword
End of sample loop. If the sample is not set to loop (see below)
this should be set to the end of the sample.
0032h
1
byte
Sample type bitmapped
0 - 8-bit/16-bit sample
1-7 - reserved
0033h
1
byte
Loop mode ?bit mapped?
0-2 - reserved
3 - loop off/loop on
4-7 - reserved
0034h
?
byte
Sample data in signed format
12 GF1 PATCH
The GF1 Patch files are multipart sound files for the Gravis Ultrasound
sound card to emulate MIDI sounds in high quality. Each Patch can
consist
of many samples (for example, a string ensemble consists of Violin,
Viola,
Cello, Bass) which are played depending on the note to play. A
patch can
also
contain a part to be played before the loop and a part to be played
after
the tone has been released.
OFFSET
Count
TYPE
Description
0000h
12
char
ID='GF1PATCH110'
000Ch
10
char
Manufacturer ID
0018h
60
char
Description of the contained Instruments or copyright of
manufacturer.
0054h
1
byte
Number of instruments in this patch
0055h
1
byte
Number of voices for sample
0056h
1
byte
Number of output channels (1=mono,2=stereo)
0057h
1
word
Number of waveforms
0059h
1
word
Master volume for all samples
005Bh
1
dword
Size of the following data
0060h
36
byte
reserved
Following this header, the instruments with their headers follow.
An
instrument header contains the
name and other data about one instrument contained within the patch.
OFFSET
Count
TYPE
Description
0000h
1
word
Instrument number. ?Maybe the MIDI instrument number?. In the
Gravis patches, this is 0, in other patches, I found random values.
0002h
16
char
ASCII name of the instrument.
0012h
1
dword
Size of the whole instrument in bytes.
0016h
1
byte
Layers. Needed for whatever.
0017h
40
byte
reserved
About the patch, I don't know anything. Maybe somebody could enlighten
me.
Each patch record has the following format :
OFFSET
Count
TYPE
Description
0000h
7
char
Wave file name
0007h
1
byte
Fractions
0008h
1
dword
Wave size. Size of the wave digital data
000Ch
1
dword
Start of wave loop
0010h
1
dword
End of wave loop
0012h
1
word
Sample rate of the wave
0014h
1
word
Minimum frequency to play the wave
0016h
1
word
Maximum frequency to play the wave
0018h
1
dword
Original sample rate of the wave data
001Ch
1
int
Fine tune value for the wave
001Eh
1
byte
Stereo balance, values unknown**
001Fh
6
byte
Filter envelope rate
0025h
6
byte
Filter envelope offse
002Bh
1
byte
Tremolo sweep
002Ch
1
byte
Tremolo rate
002Dh
1
byte
Tremolo depth
002Fh
1
byte
Vibrato sweep
0030h
1
byte
Vibrato rate
0031h
1
byte
Vibrato depth
0032h
1
byte
Wave data, bitmapped
0 - 8/16 bit wave data
1 - signed/unsigned data
2 - de/enable looping
3 - no/has bidirectional looping
4 - loop forward/backward
5 - Turn envelope sustaining off/on
6 - Dis/Enable filter envelope
7 - reserved
0033h
1
int
Frequency scale, whatever that means
0035h
1
word
Frequency scale factor
0037h
36
byte
Reserved
13 S3I
This is the Digiplayer/ST3.0 digital sample file format. The sample
files
include information about the loop of the instrument. The AdLib
instruments have another format listed below.
OFFSET
Count
TYPE
Description
0000h
1
byte
ID=01h
0001h
12
char
DOS filename
000Dh
1
byte
reserved (0)
000Eh
1
word
Paragraph offset of the raw sample data from beginning of file.
0010h
1
dword
Sample length in bytes
0014h
1
dword
Start of sample loop
0018h
1
dword
End of sample loop
001Ch
1
byte
Playback volumne of sample
001Dh
1
byte
??? "DSK" what ever that means
001Eh
1
byte
Pack type
0 - unpacked
1 - DP30ADPCM 1
001Fh
1
byte
Flags (bitmapped)
0 - loop on/off
1 - stereo sample (length bytes for left channel,
then another length bytes for right channel!)
2 - 16-Bit samples (in Intel byte order)
0020h
1
dword
C2 frequency
0024h
1
dword
reserved
0028h
1
word
reserved
002Ah
1
word
ID=512
002Ch
1
dword
?? Date of last modification ?? (see table 0009)
0030h
28
char
ASCIIZ Sample name
003Ch
4
char
ID='SCRS'
0040h
?
byte
Raw sample data
Here follows the AdLib instrument format for which I don't know
the
extension:
OFFSET
Count
TYPE
Description
0000h
1
byte
Instrument type
2 - melodic instrument
3 - bass drum
4 - snare drum
5 - tom tom
6 - cymbal
7 - hihat
0001h
12
char
DOS file name
000Dh
3
byte
reserved
0010h
1
byte
Modulator description (bitmapped)
0-3 - frequency multiplier
4 - scale envelope
5 - sustain
6 - pitch vibrato
7 - volume vibrato
0011h
1
byte
Carrier description (same as modulator)
0012h
1
byte
Modulator miscellaneous (bitmapped)
0-5 - 63-volume
6 - MSB of levelscale
7 - LSB of levelscale
0013h
1
byte
Carrier description (same as modulator)
0014h
1
byte
Modulator attack / decay byte (bitmapped)
0-3 - Decay
4-7 - Attack
0015h
1
byte
Carrier description (same as modulator)
0016h
1
byte
Modulator sustain / release byte (bitmapped)
0-3 - Release count
4-7 - 15-Sustain
0017h
1
byte
Carrier description (same as modulator)
0018h
1
byte
Modulator wave select
0019h
1
byte
Carrier wave select
001Ah
1
byte
Modulator feedback byte (bitmapped)
0 - additive synthesis on/off
1-7 - modulation feedback
001Bh
1
byte
reserved
001Ch
1
byte
Instrument playback volume
001Dh
1
byte
??? "DSK"
001Eh
1
word
reserved
0020h
1
dword
C2 frequency
0024h
12
byte
reserved
0030h
28
char
ASCIIZ Instrument name
004Ch
4
char
ID='SCRI'
14 UWF
The UWF files are sample files used by the UltraTracker. Further
information wanted.
OFFSET
Count
TYPE
Description
0000h
32
char
ASCIIZ sample name
0020h
1
char
ID=1Ah
0021h
1
char
ID=10h
0022h
5
char
ID='MUWFB'
0027h
1
char
ID=0
0028h
6
char
Length of sample as ASCII long integer
002Eh
1
word
Length of sample
15 WAVE
The Windows .WAV files are RIFF format files. Some programs expect
the fmt
block right behind the RIFF header itself, so your programs should
write
out this block as the first block in the RIFF file. The subblocks
for the
wave files are:
15.1 RiffBLOCK [data]
This block contains the raw sample data. The necessary information
for
playback is contained in the
[fmt ] block.
15.2 RiffBLOCK [fmt ]
This block contains the data necessary for playback of the sound
files.
Note the blank after fmt.
OFFSET
Count
TYPE
Description
0000h
1
word
Format tag
1 = PCM (raw sample data)
2 etc. for APCDM, a-Law, u-Law ...
0002h
1
word
Channels (1=mono,2=stereo,...)
0004h
1
dword
Sampling rate
0008h
1
dword
Average bytes per second (=sampling rate*channels)
000Ch
1
word
Block alignment / reserved ??
000Eh
1
word
Bits per sample (8/12/16-bit samples)
15.3 RiffBLOCK [loop]
This block is for looped samples. Very few programs support this
block,
but if your program changes the wave file, it should preserve any
unknown
blocks.
OFFSET
Count
TYPE
Description
0000h
1
dword
Start of sample loop
0004h
1
dword
End of sample loop
16 ZyXEL
The ZyXEL Modems are capable of digitizing speech, the ZFAX software
and
answering machine software like VoiceConnect store the sampled
data in
those files. The Modems are capable of compressing the data down
to 19.2k
CPS (ADPCM) and 9.6k CPS (CELP), the algorithms for the compression
may be
found in the ZyxelVoc package by N. Igl, but as the firmware on
the modems
changes, so might the compression algorithm. Playback on the modem
is
always possible. Files are specified by the .ZVD and .ZYX extensions.
OFFSET
Count
TYPE
Description
0000h
5
char
ID='ZyXEL'
0005h
1
byte
02h, ??? format tag
0006h
4
byte
reserved
000Ah
1
word
Compression scheme
0 - CELP
1 - 2 bit ADPCM
2 - 3 bit ADPCM
000Ch
4
byte
reserved
0010h
?
????
Raw Data, The voice data is just the data received from U1496
Modem/Fax.
17 Creative Labs File Formats
17.1 Sound Blaster Instrument File Format (SBI)
The SBI format contains the register values for the FM chip to synthesize
an instrument.
Offset
Description
00h-03h
Contains id characters "SBI" followed by byte 1Ah
04h-23h
Instrument name, NULL terminated string
24h
Modulator Sound Characteristic (Mult, KSR, EG, VIB, AM)
25h
Carrier Sound Characteristic
26h
Modulator Scaling/Output Level
27h
Carrier Scaling/Output Level
28h
Modulator Attack/Delay
29h
Carrier Attack/Delay
2Ah
Modulator Sustain/Release
2Bh
Carrier Sustain/Release
2Ch
Modulator Wave Seelct
2Dh
Carrier Wave Select
2Eh
Feedback/Connection
2Fh-33h
Reserved
17.2 Creative Music File Format (CMF)
The CMF file format consists of 3 blocks: the header block, the
instrument
block and the music block.
The CMF Header Block
Offset
Description
00h-03h
Contains id characters "CTMF"
04h-05h
CMF Format Version MSB = major version, lsb = minor version
06h-07h
File offset of the instrument block
08h-09h
File offset of the music block
0Ah-0Bh
Clock ticks per quarter note (one beat) default = 120
0Ch-0Dh
Clock ticks per second
0Eh-0Fh
File offset of the music title (0 = none)
10h-11h
File offset of the composer name (0 = none)
12h-13h
File offset of the remarks (0 = none)
14h-23h
Channel-In-Use Table
24h-25h
Number of instruments used
26h-27h
Basic Tempo
28h-?
Title, composer and remarks stored here
17.3 The CMF Instrument Block
The instrument block contains one 16 byte data structure for each
instrument in the piece. Each record is of the same format as bytes
24h-33h in the SBI file format.
17.4 The CMF Music Block
The music block adheres to the standard MIDI file format, and can
have
from 1 to 16 instruments. The PC-GPE file MIDI.TXT contains more
information on this file format.
The music block consists of an alternating seqence of time and MIDI
event
records:
dTime
MIDI Event
dTime
MIDI Event
dTime
MIDI Event
........
dTime (delta Time) is the amount of time before the following MIDI
event.
MIDI Event is any MIDI channel message.
The CMF file format defines the following MIDI Control Change events:
Control No
Control Data
66h
1-127, used as markers in the music
67h
0 - melody mode, 1 = rhythm mode
68h
0-127, changes the pitch of all following notes upward by the given
number
of 1/128
semitones
69h
0-127, changes the pitch of all following notes downward by the
given
number of
1/128 semitones
In rhythm mode, the last five channels are allocated for the percussion
instruments:
Channel
Instrument
12h
Bass Drum
13h
Snare Drum
14h
Tom-Tom
15h
Top Cymbal
16h
High-hat Cymbal
17.5 Sound Blaster Instrument Bank File Format (IBK)
A bank file is a group of up to 128 instruments.
Offset
Description
00h-03h
Contains id characters "IBK" followed by byte 1Ah
04h-803h
Parameters for 128 instruments, 16 bytes for each instrument in
the same
format
as bytes 24h-33h in the SBI format
804h-C83h
Instrument names for 128 instruments, 9 bytes for each instrument,
each
name
must be null terminated
18 Creative Voice (VOC) file format
HEADER (bytes 00-19)
Series of DATA BLOCKS (bytes 1A+) [Must end w/ Terminator Block]
byte #
Description
00-12
"Creative Voice File"
13
1A (eof to abort printing of file)
14-15
Offset of first datablock in .voc file (std 1A 00 in Intel Notation)
16-17
Version number (minor,major) (VOC-HDR puts 0A 01)
18-19
2's Comp of Ver. # + 1234h (VOC-HDR puts 29 11)
Data Block: TYPE(1-byte), SIZE(3-bytes), INFO(0+ bytes)
NOTE: Terminator Block is an exception -- it has only the TYPE
byte.
TYPE
Description
Size (3-byte int)
Info
00
Terminator
(NONE)
(NONE)
01
Sound data
2+length of data
*
02
Sound continue
length of data
Voice Data
03
Silence
3
**
04
Marker
2
Marker# (2 bytes)
05
ASCII
length of string
null terminated string
06
Repeat
2
Count# (2 bytes)
07
End repeat
0
(NONE)
08
Extended
4
***
*Sound Info Format:
**Silence Info Format:
00 Sample Rate
00-01 Length of silence - 1
01 Compression Type
02 Sample Rate
02+ Voice Data
***Extended Info Format:
00-01
Time Constant:
Mono: 65536 - (256000000/sample_rate)
Stereo: 65536 - (25600000/(2*sample_rate))
02
Pack
03
Mode:
0 = mono
1 = stereo
Marker#
Driver keeps the most recent marker in a status byte
Count#
Number of repetitions + 1 Count# may be 1 to FFFE for 0 - FFFD
repetitions or FFFF for endless repetitions
Sample Rate
SR byte = 256-(1000000/sample_rate)
Length of silence
in units of sampling cycle
Compression Type
of voice data
8-bits= 0
4-bits = 1
2.6-bits = 2
2-bits = 3
Multi DAC = 3+(# of channels)
[interesting this isn't in the developer's
manual]
19 Revision History
Version 1.0 - First document containing 15 formats
Version 1.1 - 2 More formats added
.
.to.top