Original Files from Corion.Net
These are the original files from corion.net by Max Maischein. Used with permission.
This is really just for reference in case I screwed up when I reformatted and indexed them.
filefmts.doc
In the file format list, several short mnemonics are used to describe
the structure of the data stored. Here I describe the structure (and
possible conversion) between some of these types. As some types have
different sizes across the platforms, for most types the byte order and
bit size is given to describe it.
ASCIIZ A sequence of characters(->char), terminated
with the special character with the value 0.
Note that ASCIIZ strings as most structures on
Intel machines should not be larger than
64Kb due to the ancient segmentation used.
BCD Binary coded decimal
A decimal number is converted into a hexadecimal number
which has the same digits as the decimal number.
(10d becomes 10h, 21d becomes 21h)
Bitmap If a value is declared as bitmapped, that means that
every bit in this value might have a different meaning.
The bytes are numbered from right to left, the least
significant bit has the number 0. After the bit number,
there are either two statements, separated by a
slash("/"), which are the two meanings if the bit is
set / not set, or one single statement, which is the
meaning of this bit, if it is set.
Byte 8 bit unsigned number. Smallest unit a record
consists of. All offsets are in the unit bytes.
(0-255)
Char Synonym for byte, most values are between 32 and
255. (#0-#255)
DWord 32 bit signed number. Well, maybe some of the
formats use a DWord which is a 32 bit unsigned
number, but as files tend not to be greater than
2GB, this won't be my concern. To convert
between Intel and Motorola format, you have to
swap bytes #2 & #3 and bytes #1 & #4.(-2Gb-+2Gb)
Int Integer. Signed 16-bit number.
(-32767-+32767)
LString A string which is preceeded by the length. Also
named "counted" string. Used by most Pascal
implementations Maximum length is 255 bytes, but it can
contain any char.
Nybble The upper or lower four bits of a byte. A nybble
is a single hex digit and can have values from
0 to 15. A signed nybble can have values from
-8 to 7 with bit 3 being the sign bit.
Paragraph A multiple of 16. A paragraph was the resolution of the
Intel chip 64K segments.
Word 16 bit unsigned number. Note that byte order is
important, wether you have a Motorola machine or
an Intel one. Conversion between the two formats
is simply by swapping byte #1 with byte #2.
(0-65535)
How to identify different files
While searching for different file formats, I found the following programs
helpful to gather information about different files. They all are DOS programs
since I'm not familiar with other platforms (except Windows). Most of them
should be available on SimTel CDs or via FTP at ftp.cdrom.com, except for my
program TF, which is still in beta.
LIST.COM v9.0a by Vernon Buerg
List is a file lister which supports both text and hex-view.
HIEW.EXE v4.18 by Sen
Another file lister with build-in disassembler.
FILE.EXE v2.0 by Felix von Leitner
File is a file identification program.
Q.COM v3.01 by SemWare
QEdit is the editor I'm editing the list with.
TF.EXE v0.38 by me
The program that started it all. A "simple" file identification
program - no more, since it has grown too big by now.
Still unreleased, since it is not really extensible yet.
The file formats list meta list ;)
The file format list uses a certain format to make it readable by programs which
convert it into the WinHelp format or create program structures out of the
lists. This format is very similar to the format used by Ralf Brown in his PC
interrupt list but was extended by me to accomodate for the specific needs of
this list :
Each topic in the list is delimited by a line of 45 chars, in which the
first 8 contain the char '-'. After these, there follows one character which
contains the type of topic. The different topics are described in the list
itself, the char '!' denotes an information topic - like the list of chars and
their meaning. After the topic identifier, there follows another '-' char and
then the topic name, not containing any '-' chars. After the topic name, there
may be some other descriptors like for Motorola byte ordering, guesswork marking
or other purposes, see the main list for further information. The line is ended
with at least one '-' char. Take the following prototype :
--------?-TEST------------------------------
OFFSET Count TYPE Description
EXTENSION:
OCCURENCES:
PROGRAMS:
REFERENCE:
SEE ALSO:
VALIDATION:
Sub-topics like different records are mostly delimited by three dashes ('-').
I suggest folding them up and making them available as a popup window.
Tables have the following format :
(see table 0000)
for a table reference and
(Table 0000)
for the beginning of a table. The end of a table is undefined (yet).
A primer on file formats
Abbrevations
Throughout the list, many abbrevations are used, some in the reference
section. Here some are explained :
c't
The c't is a german computer magazine, which developed the Borland
Pascal for OS/2 patch. They release source code in files called
CTmmyy.*. Note that comments in the source code and the language in
the issues tend to be german :-)
DDJxxyy
(Doctor Dobb's Journal)
The DDJ is a monthly publication by M&T/US which is intended for the
professional programmer. The four digits after the name indicate the
month/year of the issue referred to. Most of the sourcecode published
in the issue is available electronically on Compu$erve and other BBSes.
The files have the name DDJyymm.
PDN
Programmer's Distribution Net
A network dedicated to the distribution of source code useful to
programmers. Often linked with Fido-nodes.
Contributions to this list were made by :
Ralf Brown (The .EXE file formats from the INTERRUPT List, general layout)
David Dilworth (david.dilworth@sierraclub.org)
Daniel Dissett (ddissett@netcom.com)
Marcus Groeber (marcusg@ph-cip.uni-koeln.de)
Darrel Hankerson (hankedr@mail.auburn.edu)
Carl Hauser (chauser.parc@xerox.com)
Jouni Miettunen (jon@stekt.oulu.fi)
Jan Nicolai Langfeldt (janl@ifi.uio.no)
Mark Ouellet (Telix .FON structures)
Greg Roelofs (roe2@midway.uchicago.edu)
Robert Rothenburg Walking-Owl (wlkngowl@unix.asb.com)
Jesus Villena (CONVERT.EXE, a digital sample conversion program)
Christos Zoulas (christos@deshaw.com)
JAL / Nostalgia
David McDuffee, (75530,2626@compuserve.com)
Information gleaned from other programs :
Formats for Word and WordPerfect (Selke's filetype)
filefmts.lst
File format list Release 3.00 Last change 02/04/96
This compilation is Copyright (c) 1994,2002 Max Maischein
--------!-CONTACT_INFO----------------------
If you notice any mistakes or omissions, please let me know! It is only
with YOUR help that the list can continue to grow. Please send
all changes to me rather than distributing a modified version of the list.
This file has been authored in the style of the INTERxxy.* file list
by Ralf Brown, and uses almost the same format.
Please read the file FILEFMTS.1ST before asking me any questions. You may find
that they have already been addressed.
Max Maischein
corion@corion.net
Corion on #coders@IRC
--------!-DISCLAIMER------------------------
DISCLAIMER: THIS MATERIAL IS PROVIDED "AS IS". I verify the information
contained in this list to the best of my ability, but I cannot be held
responsible for any problems caused by use or misuse of the information,
especially for those file formats foreign to the PC, like AMIGA or SUN file
formats. If an information it is marked "guesswork" or undocumented, you
should check it carefully to make sure your program will not break with
an unexpected value (and please let me know whether or not it works
the same way).
Information marked with "???" is known to be incomplete or guesswork.
Some file formats were not released by their creators, others are regarded
as proprietary, which means that if your programs deal with them, you might
be looking for trouble. I don't care about this.
--------!-FLAGS-----------------------------
One or more letters may follow the file format ID; they have the following
meanings:
Cx - Charset used :
7 - Unix 7-bit characters
A - Amiga charset (if there is one)
E - EBDIC character format
U - Unicode character set
W - Windows char set
Default is the 8-Bit IBM PC-II Charset. Note that Microsoft
introduced codepages which might be relevant with other
programs.
G - guesswork, incomplete, unreliable etc.
M - Motorola byte order
Default is Intel byte order
O - obsolete, valid only for version noted below
X - Synonym topic. See topic named under see also.
--------!-CATEGORIES------------------------
The ninth column of the divider line preceding an entry usually contains a
classification code for the application that uses those files.
The codes currently in use are:
! - User information ( not really a file format )
A - Archives (ARC,LZH,ZIP,...)
a - Animations (CEL, FLI, FLT,...)
B - Binary files for compilers etc. (OBJ,TPU)
H - Help file (HLP,NG)
I - Images, bit maps (GIF,BMP,TIFF,...)
D - Data support files (CPI,FON,...)
E - Executable files (EXE,PIF)
f - Generic file format. RIFF and IFF are generic file formats.
F - Font files (TTF)
G - General graphics file
M - Module music file (MIDI,MOD,S3M,...)
R - Resource data files (RES)
S - Sound files (WAV,VOC,ZYX)
T - Text files (DOC,TXT)
W - Spreadsheet and related (WKS)
X - Database files (DBF)
--------!-FIELDS----------------------------
After a format description, you will sometimes find other keywords. The
meanings of these are :
EXTENSION:
This is the default extension of files of the given type.
On DOS systems, most files have a 3 letter extension.
On Amiga systems, the files are prefixed with something.
The DOS extensions are all uppercase, extensions for other systems
are in lower case chars. On other systems, which do not have the con-
cept of extensions, as the MAC, this is the file type.
OCCURENCES:
Where you are likely to encounter those files. This specifies
machines (like PC,AMIGA) or operating systems (like UNIX).
PROGRAMS:
Programs which either create, use or convert files of this format.
Some might be used for validation or conversion.
REFERENCE:
A reference to a file or an article in a magazine which is mandatory
or recommended for further understanding of the matter.
SEE ALSO:
A cross reference to a topic which might be interesting as well.
VALIDATION:
Methods to validate that the file you have is not corrupt. Normally
this is a method to check the theoretical file size against the
real filesize. Some file formats allow no reliable validation.
--------!-FORMAT----------------------------
The block oriented files are organized in some other fashion, since the
order of blocks is at best marginally obligatory.
Each block type starts with the block ID (eg. RIFFblock for a RIFF file) and
in square brackets the character value of the ID field (eg. [WAVE] for RIFF
WAVe sound files). The block itself is descripted in the format description,
that means you will have to look after RIFF or FORM. In the record
description, the header information is omitted !
If a record is descripted, the record ends when the next offset is given.
Bitmapped values have a description for each bit. The value left of the
slash ("/") is for the bit not set (=0), the right sided value applies
if the bit is set.
A note on the tables section. The tables were added as they were introduced
into Ralf Browns interrupt list - so not everything was pressed into a table.
The tables (should) have unique numbers, but they sure are out of order !
--------!-MACHINES--------------------------
Machines that use Intel byte ordering
PC
Machines that use Motorola byte ordering
AMIGA, ATARI ST, MAC, SUN
--------M-669-------------------------------
The .669 format is a module format for digital music.
OFFSET Count TYPE Description
0000h 1 word ID=6669h
0002h 108 byte ASCII song message
006Eh 1 byte Number of saved samples (0-40h)
="NOS"
006Fh 1 byte Number of saved patterns (0-80h)
="NOP"
0070h 1 byte Loop order number
0071h 128 byte Order list
00F1h 128 byte Tempo list for patterns
0171h 128 byte Break location list for patterns
01F1h "NOS" rec Sample data
The sample data is in the file
for "NOS"
13 byte ASCIIZ filename of instrument
1 dword Length of instrument sample
1 dword Offset of beginning of loop
1 dword Offset of end of loop
01F1h+ "NOP"*600 rec The note patterns
"NOS"*19h Those patterns are repeated for each row,
and the array of these is repeated 64 times
for each pattern.
3 byte Note(see table 0000)
01F1h+ ? byte Sample data (unsigned)
"NOS"*0x19+
"NOP"*0x600
(Table 0000)
669 Note format
Each note looks like this :
BYTE[0]: BYTE[1]: BYTE[2]:
nnnnnnii iiiivvvv ccccdddd
n : note value
i : 6-bit instrument number
v : 4-bit volume
c : command data (Protracker format mapped) :
0 = a
1 = b
2 = c
3 = d
4 = e
5 = f
d : command value (Protracker format)
Special values for byte 0 :
0FEh : no note, only volume
0FFh : no note or no command, if byte 2 = 0FFh
EXTENSION:669
OCCURENCES:PC
SEE ALSO:MOD
PROGRAMS:669 Mod Composer, DMP
VALIDATION:
--------S-8SVX-MG---------------------------
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.
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
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 unknown to me.
EXTENSION:IFF
OCCURENCES:PC,Amiga
PROGRAMS:GoldWave
SEE ALSO:IFF,WAVE
VALIDATION:
--------S-AIFC-MG---------------------------
The AIFC files seem to be a variation of the AIFF files - but I don't know
anything about them.
EXTENSION:IFF
SEE ALSO:AIFF
--------S-AIFF-MG---------------------------
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 ???
??? 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.
Further information wanted.
EXTENSION:AIF,IFF
--------E-AMIGA EXECUTABLE-MG---------------
All Amiga executables I've seen start with this signature. Of course the
bytes are in Motorola byte order, as you would exspect from a Motorola
based machine. This info here is based completely on my guesswork, maybe
somebody from the Amiga could help flesh out this part.
OFFSET Count TYPE Description
0000h 1 dword ID=03F3h
EXTENSION:EXE
OCCURENCES:AMIGA
SEE ALSO:
VALIDATION:
--------M-AMS-------------------------------
The AMS format is a multichannel module format created by the X-Tracker (not
to be mistaken for he tracker of the same name by D-Lusion).
The X-Tracker by Extreme PC is a multichannel tracker that features 32 digital
channels, 64 MIDI channels, 255 samples, 64K patterns and positions. The tracker
is currently in beta status and not enough information is yet available yet.
OFFSET Count TYPE Description
EXTENSION:
OCCURENCES:
PROGRAMS:
REFERENCE:
SEE ALSO:MOD
VALIDATION:
--------A-ARC-------------------------------
The ARC files are archive files created by the SEA ARC program. The compression
has been superceded by more recent compression programs. Similar archives can
be created by the PAK and PkPAK programs. There have been many variations
and enhancements to the ARC format though not as many as to the TIFF format.
You may have to use some (paranoid) checks to ensure that you actually are
processing an ARC file, since other archivers also adopted the idea of putting
a 01Ah byte at offset 0, namely the Hyper archiver. To check if you have a
Hyper-archive, check the next two bytes for "HP" or "ST" (or look below for
"HYP"). Also the ZOO archiver also does put a 01Ah at the start of the file,
see the ZOO entry below.
OFFSET Count TYPE Description
0000h 1 byte ID=1Ah
0001h 1 byte Compression method (see table 0001)
0002h 12 char File name
000Fh 1 dword Compressed file size
0013h 1 dword File date in MS-DOS format (see table 0009)
0017h 1 word 16-bit CRC
0019h 1 dword Original file size
="SIZ"
(Table 0001)
ARC compression types
0 - End of archive marker
1 - unpacked (obsolete) - ARC 1.0 ?
2 - unpacked - ARC 3.1
3 - packed (RLE encoding)
4 - squeezed (after packing)
5 - crunched (obsolete) - ARC 4.0
6 - crunched (after packing) (obsolete) - ARC 4.1
7 - crunched (after packing, using faster hash algorithm) - ARC 4.6
8 - crunched (after packing, using dynamic LZW variations) - ARC 5.0
9 - Squashed c/o Phil Katz (no packing) (var. on crunching)
10 - crushed (PAK only)
11 - distilled (PAK only)
12-19 - to 19 unknown (ARC 6.0 or later) - ARC 7.0 (?)
20-29 - ?informational items? - ARC 6.0
30-39 - ?control items? - ARC 6.0
40+ - reserved
According to SEA's technical memo, the information and control items
were added to ARC 6.0. Information items use the same headers as archived
files, although the original file size (and name?) can be ignored.
OFFSET Count TYPE Description
0000h 2 byte Length of header (includes "length"
and "type"?)
0002h 1 byte (sub)type
0003h ? byte data
Informational item types as used by ARC 6.0 :
Block type Subtype Description
20 archive info
0 archive description (ASCIIZ)
1 name of creator program (ASCIIZ)
2 name of modifier program (ASCIIZ)
21 file info
0 file description (ASCIIZ)
1 long name (if not MS-DOS "8.3" filename)
2 extended date-time info (reserved)
3 icon (reserved)
4 file attributes (ASCIIZ)
Attributes use an uppercase letter to signify the
following:
R read access
W write access
H hidden file
S system file
N network shareable
22 operating system info (reserved)
(Table 0009)
Format of the MS-DOS time stamp (32-bit)
The MS-DOS time stamp is limited to an even count of seconds, since the
count for seconds is only 5 bits wide.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
|<---- year-1980 --->|<- month ->|<--- day ---->|
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|<--- hour --->|<---- minute --->|<- second/2 ->|
EXTENSION:ARC,PAK
OCCURENCES:PC
PROGRAMS:SEA ARC,PAK,PkPAK
SEE ALSO:HYP,ZOO
VALIDATION:FileSize="SIZ"
--------A-ARJ-------------------------------
The ARJ program by Robert K. Jung is a "newcomer" which compares well to PKZip
and LhArc in both compression and speed. An ARJ archive contains two types of
header blocks, one archive main header at the head of the archive and local
file headers before each archived file.
OFFSET Count TYPE Description
0000h 1 word ID=0EA60h
0002h 1 word Basic header size (0 if end of archive)
0004h 1 byte Size of header including extra data
0005h 1 byte Archiver version number
0006h 1 byte Minimum version needed to extract
0007h 1 byte Host OS (see table 0002)
0008h 1 byte Internal flags, bitmapped :
0 - no password / password
1 - reserved
2 - file continues on next disk
3 - file start position field is available
4 - path translation ( "\" to "/" )
0009h 1 byte Compression method :
0 - stored
1 - compressed most
2 - compressed
3 - compressed faster
4 - compressed fastest
Methods 1 to 3 use Lempel-Ziv 77 sliding window
with static Huffman encoding, method 4 uses
Lempel-Ziv 77 sliding window with pointer/
length unary encoding.
000Ah 1 byte File type :
0 - binary
1 - 7-bit text
2 - comment header
3 - directory
4 - volume label
000Bh 1 byte reserved
000Ch 1 dword Date/Time of original file in MS-DOS format
0010h 1 dword Compressed size of file
0014h 1 dword Original size of file
0018h 1 dword Original file's CRC-32
001Ah 1 word Filespec position in filename
001Ch 1 word File attributes
001Eh 1 word Host data (currently not used)
? 1 dword Extended file starting position when used
(see above)
? char ASCIIZ file name
? char Comment
????h 1 dword Basic header CRC-32
????h 1 word Size of first extended header (0 if none)
="SIZ"
????h+"SIZ"+2 1 dword Extended header CRC-32
????h+"SIZ"+6 ? byte Compressed file
(Table 0002)
ARJ HOST-OS types
0 - MS-DOS
1 - PRIMOS
2 - UNIX
3 - AMIGA
4 - MAC-OS (System xx)
5 - OS/2
6 - APPLE GS
7 - ATARI ST
8 - NeXT
9 - VAX VMS
EXTENSION:ARJ
OCCURENCES:PC
PROGRAMS:ARJ.EXE
REFERENCE:
SEE ALSO:
VALIDATION:
--------S-AU-MG-----------------------------
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
EXTENSION:AU
OCCURENCES:SunOS
--------B-BGI-G-----------------------------
The BGI files are graphic drivers used by the Borland compilers to
provide graphics output for different graphics cards. They are loaded
dynamically. The exact format is not known to me ...
OFFSET Count TYPE Description
0000h 4 char ID='FBGD'
0004h 1 dword ID=08080808h
used to backspace over ID if typing the file
0008h ? char Driver ID string, terminated with #26
EXTENSION:BGI
OCCURENCES:PC
PROGRAMS:Borland Pascal, Borland C, Turbo Pascal
--------I-BMP-------------------------------
The BMP files are the way, Windows stores bit mapped images. The BMP image
data is bit packed but every line must end on a dword boundary - if thats not
the case, it must be padded with zeroes. BMP files are stored bottom-up,
that means that the first scan line is the bottom line. The BMP format has four
incarnations, two under Windows (new and old) and two under OS/2, all are
described here.
OFFSET Count TYPE Description
0000h 2 char ID='BM' - BitMap
OS/2 also supports the following IDs :
ID='BA' - Bitmap Array
ID='CI' - Color Icon
ID='CP' - Color Pointer (mouse cursor)
ID='IC' - Icon
ID='PT' - Pointer (mouse cursor)
0002h 1 dword Filesize of whole file
0006h 4 byte reserved
000Ah 1 dword Offset of bitmap in file
="BOF"
000Eh 1 dword Length of BitMapInfoHeader
The BitMapInfoHeader starts directly after
this header.
12 - OS/2 1.x format
40 - Windows 3.x format
64 - OS/2 2.x format
0012h 1 dword Horizontal width of bitmap in pixels
0016h 1 dword Vertical width of bitmap in pixels
001Ah 1 word Number of planes
001Ch 1 word Bits per pixel ( thus the number of colors )
="BPP"
001Eh 1 dword Compression type, see ALGRTHMS.txt for descrip-
tion of the different types
0 - none
1 - RLE 8-bit/Pixel
2 - RLE 4-bit/Pixel
0022h 1 dword Size of picture in bytes
0026h 1 dword Horizontal resolution
002Ah 1 dword Vertical resolution
002Ah 1 dword Number of used colors
002Ah 1 dword Number of important colors
0036h ? rec Definition of N colors
N=1 shl "BPP"
1 byte Blue component
1 byte Green component
1 byte Red component
1 byte Filler
"BOF" ? byte Image data
EXTENSION:BMP,RLE,LGO
OCCURENCES:PC
PROGRAMS:Windows,Paintbrush
REFERENCE:DDJ0994
VALIDATION:
SEE ALSO:rDIB
--------I-CEG-------------------------------
The CEG (Continous Edge Graphic)-format is a raw picture format used by the
Edsun cards with CEG-chips which provide some better look through anti-aliasing
or something like that. The header before the data looks like this :
OFFSET Count TYPE Description
0000h 1 word Version number of the CEG-format
0002h 9 char ID='Edsun CEG'
000Bh 1 byte Number of pixels per byte
000Ch 9 byte Reserved
0015h 80 char ASCIIZ copyright notice for the image
0065h 1 byte CEG-revision number (1)
0066h 1 byte Used CEG-mode (0..15)
0067h 1 Word Number of pixels per line
0069h 1 word Number of lines
006Ah 1 byte Old VGA-mode
006Bh 1 byte VGA Data flag :
0 - VGA registers are invalid
1 - VGA registers are valid
006Ch 92 byte VGA register data
00C2h 256 rec VGA palette entries
1 byte Value for red
1 byte Value for green
1 byte Value for blue
03C2h 1 word Year of file creation
03C4h 1 byte Day of file creation
03C5h 1 byte Month of file creation
03C6h 1 byte Hour of file creation
03C7h 1 byte Minute of file creation
03C8h 1 byte Second of file creation
03C9h 24 byte Reserved for future use
EXTENSION:???
OCCURENCES:PC
PROGRAMS:???
--------a-CEL-------------------------------
CEL files contain one or more frames of image data used by the Autodesk
Animator and Animator Pro animation pakages. Both Animator Pro and the original
Animator produce CEL files, but each uses a different file format.
--- Animator Pro CEL Files
An Animator Pro CEL file is identical to a FLC file in all respects. A CEL file
should have a Celdata block in the file prefix block which describes the x,y
placement of the CEL. If the Celdata placement block is not present, assume a
placement of 0,0.
--- Original Animator CEL Files
The original Animator also produced CEL files. These were still-picture files,
not the multi-frame files Animator Pro now uses. A CEL file from the original
Animator is identical to a PIC file from the original Animator in all respects.
EXTENSION:CEL
OCCURENCES:PC
PROGRAMS:Autodesk Animator
SEE ALSO:FLIc,FLC,PIC
VALIDATION:
--------F-CHR-------------------------------
The CHR files are scalable fonts used by the Borland graphics interface
(BGI) to display fonts in graphics mode.
OFFSET Count TYPE Description
0000h 4 char ID='PK',08,08
0004h 4 char ID='BGI '
0008h ? char Font description, terminated with #26
0008h 1 word Headersize
+???? ="SIZ"
4 char Internal font name
1 word Font file size in bytes
1 byte Font driver major version
1 byte Font driver minor version
1 word 0100h
"SIZ" word Zeroes to pad out the header
0080h 1 char Signature byte, '+' means stroke font
0081h 1 word Number of chars in font file
="NUM"
0083h 1 byte undefined
0084h 1 byte ASCII value of first char in file
0085h 1 word Offset to stroke definitions
0087h 1 byte Scan flag ??
0088h 1 byte Distance from origin to top of capital
0089h 1 byte Distance from origin to baseline
008Ah 1 byte Distance from origin to bottom descender
008Bh 4 char Four character name of font
0090h "NUM" word Offsets to character definitions
0090h+ "NUM" byte Width table for the characters
"NUM"*2
0090h+ Start of character definitions
"NUM"*3
The individual character definitions consist of a variable number of words
describing the operations required to render a character. Each word
consists of an (x,y) coordinate pair and a two-bit opcode, encoded as shown
here:
Byte 1 7 6 5 4 3 2 1 0 bit #
op1 <seven bit signed X coord>
Byte 2 7 6 5 4 3 2 1 0 bit #
op2 <seven bit signed Y coord>
Opcodes
op1=0 op2=0 End of character definition.
op1=0 op2=1 Do scan
op1=1 op2=0 Move the pointer to (x,y)
op1=1 op2=1 Draw from current pointer to (x,y)
EXTENSION:CHR
OCCURENCES:PC
PROGRAMS:Borland Pascal, Borland C
REFERENCE:BGIKIT.ZIP
SEE ALSO:
VALIDATION:
--------M-CMF-G-----------------------------
The CMF files are music files used by the SoundBlaster sound card family. The
Creative Labs Music Format might be proprietary, the info is guesswork.
OFFSET Count TYPE Description
0000h 4 char ID="CTMF"
*********
EXTENSION:CMF
OCCURENCES:PC
PROGRAMS:PLAYCMF.EXE
--------I-COL-------------------------------
A COL file stores the rgb values for entries in the color palette. Both
Animator Pro and the original Animator produce COL files, but the formats
are different. To process a COL file for input, check the file size. If it is
exactly 768 bytes, the file is an original Animator COL file. If the file is
any other size, it is an Animator Pro COL file - which makes identification
almost impossible.
Animator Pro COL Files do have a 8-byte header :
OFFSET Count TYPE Description
0000h 1 dword File size, including this header
0004h 1 word ID=0B123h
0006h 1 word Version, currently 0
Following the file header are palette entries in rgbrgb... order. Each of
the r, g, and b components is a single byte in the range of 0-255. Generally,
there will be data for 256 palette entries, but this cannot be assumed.
The actual number of palette entries is ((size-8)/3); if this value is not
an even multiple of three, the file is corrupted.
Original Animator COL Files
A COL file created by the original Animator is exactly 768 bytes
long. There is no file header or other control information in
the file.
EXTENSION:COL
OCCURENCES:PC
PROGRAMS:Autodesk Animator, Autodesk Animator Pro
SEE ALSO:FLIc,FLT
--------E-COM-------------------------------
The COM files are raw binary executables and are a leftover from the old CP/M
machines with 64K RAM. A COM program can only have a size of less than one
segment (64K), including code and static data since no fixups for segment
relocation or anything else is included. One method to check for a COM file is
to check if the first byte in the file could be a valid jump or call opcode, but
this is a very weak test since a COM file is not required to start with a jump
or a call. In principle, a COM file is just loaded at offset 100h in the segment
and then executed.
OFFSET Count TYPE Description
0000h 1 byte ID=0E9h
ID=0EBh
Those are not safe ways to determine wether a
file is a COM file or not, but most COM files
start with a jump.
Further information not available.
EXTENSION:COM
OCCURENCES:PC
SEE ALSO:EXE,MZ EXE,NE EXE
--------E-CORE-G----------------------------
The core images are dumps of the system core from different unix machines (as
far as I gather). Info comes from a magic file - so this is only good for
identification. What you would do with a core image on a foreign machine, eludes
me anyway. Maybe the information below is wrong and the 386 core dump also
belongs to the word at 0174h...
OFFSET Count TYPE Description
0000h 4 char ID='core'
0174h 1 word Executable type 1
015Dh - B370 executable
5D01h - B370 executable
0158h - B370 executable
5801h - B370 executable
015Fh - XA370 executable
05F01h - XA370 executable
015Ah - XA370 executable
0176h 1 word Executable type 2
0176h - 386 executable
EXTENSION:???
OCCURENCES:Unix flavours
PROGRAMS:N/A
SEE ALSO:
--------D-CPI-G-----------------------------
The DOS CPI files are data files which are loaded by the country drivers of
MS-DOS. The information comes from a magic file, which makes it good for
identification only.
OFFSET Count TYPE Description
0000h 9 char ID=255,'FONT ',0
EXTENSION:CPI
OCCURENCES:PC
PROGRAMS:MS-DOS
--------X-CRD-G-----------------------------
The Windows 3.1 Cardfile.EXE is a (simple) addressbook application included
with the Windows 3.1+ operating system by Microsoft.
OFFSET Count TYPE Description
EXTENSION:CRD
OCCURENCES:PC, ALPHA?
PROGRAMS:CARDFILE.EXE
--------X-DBase II-O------------------------
The DBase II file format.
The dBASE II file header has a fixed size of 521 bytes.
OFFSET Count TYPE Description
0000h 1 byte dBASE version, 02h = dBASE II
0001h 1 word Number of data records in file
="NDR"
0003h 1 byte Month of last update
0004h 1 byte Day of last update
0005h 1 byte Year of last update
0006h 1 word Size of each data record
="DRS"
0008h 64 rec Field descriptors
11 char ASCIIZ field name, 0Dh as first
char indicates end of list.
1 char Data type
'C' - Char
'N' - Numerical
'L' - Logical
1 byte Field length
1 word Field data address ( set in RAM )
1 byte Number of decimal places
0208h 1 byte If 0Dh, then all 32 field descriptors were used;
otherwise 00h
EXTENSION:DBF
OCCURENCES:PC
PROGRAMS:DBase
SEE ALSO:DBASE III,XBase
VALIDATION:FileSize="NDR"*"DRS"+0208h
--------X-DBase III-------------------------
DBASE - File header structure (DBASE III)
OFFSET Count TYPE Description
0000h 1 byte dBASE version,
03h = dBASE III w/o *.DBT
83h = dBASE III w *.DBT
0001h 1 byte Month of last update
0002h 1 byte Day of last update
0003h 1 byte Year of last update
0004h 1 dword Number of data records in file
="NDR"
0008h 1 word Header size
="HSZ"
000Ah 1 word Data record size
="DRS"
000Ch 12 byte reserved
0020h ? rec Field descriptors
The list of field descriptors is
terminated with a terminator
byte 0Dh.
11 char ASCIIZ field name
1 char Data type
'C' - Char
'D' - Date
'L' - Logical
'M' - Memo
'N' - Numerical
1 dword Field data address ( set in RAM )
1 byte Field length
1 byte Number of decimal places
14 byte reserved
EXTENSION:DBF
SEE ALSO:DBASE II,XBase
OCCURENCES:PC
PROGRAMS:DBase
VALIDATION:FileSize="NDR"*"DRS"+"HSZ"
--------X-DBASE IV--------------------------
**** Description missing ****
EXTENSION:DBF,DBT
OCCURENCES:PC
PROGRAMS:DBase 4.0, Clipper
REFERENCE:
SEE ALSO:DBASE II,DBASE III,XBase
VALIDATION:
--------M-DCM-------------------------------
The DCM module format was designed by Winfried Welti, and is based on a
RIFF / IFF style format called WUFF - Welti's Universal File header Format.
The header for WUFF files is built much like the RIFF header :
OFFSET Count TYPE Description
0000h 4 char ID="WUFF"
0004h 4 char Subformat ID, see below
0008h 1 dword File length including the WUFF header
000Ch 1 word File format version as BCD.
Bits 15-12 are flags :
12 - Archive file. If set, the data after the
header contains only WUFF style files.
13-15 - reserved.
000Eh 1 word Length of subheader following this header.
The DCM format has a header ID of "DCMw" and a version word of 0100h. It extends
the header with the following values:
0010h 1 word Song flags, bitmapped
0 - Samples present
1 - Songdata present
2 - Infotext present
3-15 - reserved
0012h 1 word Number of instruments
After the header, there follow the included (WUFF) files; Allowed fileformats
for include are : MDCw (Patterns), EDIw (Instrument), TXTw (Text); see below.
The MDC format is a module format which uses compiled pattern data. It has the
subformat ID "MDCw", the current version is 1.01, it extends the header with
the following fields :
OFFSET Count TYPE Description
0010h 1 word Flags for the song (see table 0011)
0012h 1 word Internal frequency for replay
0014h 1 dword Length of packed data channels
0028h 1 byte Number of used channels
24 : Chnls : Byte Used Channels (0..chnls-1)
(Table 0011)
MDC song flags
0 - Stereo enable
1 - Free Frequency (can replay freq change in song ?)
2-3 - Offset size :
00 - Byte (mod offsets, multiply by 256)
01 - Word (16 bit offsets)
10 - DWord (32 bit offsets)
11 - reserved
4-5 - Panning range
00 - GUS panning (4 bit, byte value)
01 - 8 Bit panning
10 - reserved
11 - reserved
6-7 - Instrument number range
00 - Byte
01 - Word
10 - reserved
11 - reserved
8 - S3M compatibility bit (all ranges are like s3m : mod offsets,
GUS panning, Ins Num Range : Byte)
9 - Tuning control
0 - Use Period values (word) (s3m)
1 - Use Frequency values (Dword)
10-15- reserved
After the header, there comes the packed data for the module. This format
consists of one control byte and depending on the value some other data
bytes.
Values of control byte :
0 - Next Frame
1 - End of File
2 - Order Num. follows [byte]
3 - Loop to Ord Num (1 byte follows)
4 - Frames to wait follows [byte]
5 - New Replay freq follows [byte]
6..31 - reserved
If the byte is greater than 31 then it has the following bitmapped format :
0-4 - Channel Nr.
5 - Key Byte follows
6 - Period Value follows [word]
7 - Volume Value follows [byte]
Key byte format, bitmapped :
0 - Start Sample
1 - Stop Sample
2 - Instr Nr follows [byte/word/??]
3 - Offset follows [byte/word/??]
4 - Pan pos follows [byte/??]
5-7 - reserved
The EDI format has an ID value of "EDIw" and a version of 0100h, and it extends
the header with the following information :
OFFSET Count TYPE Description
0010h 1 word Sample flags, bitmapped
0-1 - Loop type
00 - none
01 - forward loop
10 - bidirectional loop
11 - reserved
2 - 32 bit values for sample length etc., see below
3 - Sample is 16 bit
4 - Frequency is 32 bit.
5-15 - reserved
0012h 1 word C2 frequency of sample
0014h 1 dword Loop start, this may be a word, depending on
the sample flags.
0018h 1 dword Loop end, see loop start
001Ch 1 dword Sample length
The song text is plain ASCII.
EXTENSION:DCM
OCCURENCES:PC
SEE ALSO:S3M
--------M-DMF-------------------------------
The Digital Music Files are high quality MOD style files with up to
32 channels/1024 beats per track. The X-Tracker by the demo group
D-Lusion produces this format. In general, the format is well organised
due to the ID/Blocklength structure wich makes downward compatibility to
older version files easy, but the Version 4 (current version) of the file
format, produced by X-Tracker 0.30β still requires some manual scanning for
the next ID which I regard as not so nice. Version 5 of the format has the
[SEQU] block length fixed, but the [SMPD] block has the length 0.
The file consists of several blocks, each with a 4 char (dwordint) ID tag
and a length of the record data. The main file header looks as follows :
OFFSET Count TYPE Description
0000h 4 char ID='DDMF'
0004h 1 byte Version id.
4 -> XTracker 0.30β
0005h 8 char Tracker name, e.g. 'XTRACKER', 'HACKTRAK' :-)
000Dh 30 char Song name (ASCIIZ?)
002Bh 20 char Name of composer (ASCIIZ?)
0049h 1 byte Day of creation
004Ah 1 byte Month of creation
004Bh 1 byte Year of creation
The other headers have the standard skip record format, in this section
named DMFblock. The offsets start _after_ this header record :
OFFSET Count TYPE Description
0000h 4 char Record tag (see below)
0004h 1 dword Size of data bedwording to this tag
DMFblock [INFO]
Contains some message in ASCII. Length of the message is the size of
the record.
DMFblock [CMSG]
Contains the message the composer wants to bring to us. After the ID
record, another fill byte preceeds the real message !
OFFSET Count TYPE Description
0000h 1 byte Junk byte
0001h ? char Composer message
DMFblock [SEQU]
Contains the information necessary for sequencing the different tracks.
OFFSET Count TYPE Description
0000h 1 word Song loop start
0002h 1 word Song loop end
0004h ? word Sequencer data
DMFblock [PATT]
This block contains the information about the different patterns and tracks.
0000h 1 word Maximum pattern (=Songlength)
="MPT"
0004h 1 byte Number of channels of this song (<= 16)
0005h "MPT" rec Pattern data.
1 byte Track entries. (<=32)
="TET"
How many tracks this pattern has.
XTracker allows a different number of
tracks for each pattern.
1 byte Beat information
High nibble : Ticks per beat
Low nibble : Beats per measure
1 word Maximum number of ticks (<=512)
1 dword Number of bytes to skip for the
next pattern information.
? rec Track data stream
1 byte Global track effect
1 byte Global track data (only if global
effect >0 !!!)
"TET" rec
1 byte Information byte, bitmapped
For each bit set in the info byte, one
or two data byte(s) follow. This info byte
must not always be there, see below. For
effects, 2 bytes follow.
0 - reserved
1 - Volume effect
2 - Note effect
3 - Instrument effect
4 - Volume set
5 - Note set
6 - Instrument set
7 - Counter to next information byte.
Not set means, that next info byte
follows in 1 tick, unit is in
ticks.
The maximum number of effects is 3 at a time,
the maxximum size of a track information is
11 bytes (with info=0FEh).
? rec Effect bytes
1 byte Effect number
1 byte Effect data
? byte Set data
** Here follows the pattern data, but it's too late today **
DMFblock [INST]
This block contains the information about the instrument data.
If this block does not exists, then the instrument numbers in the patterns
point directly to the samples in the [SMPI] block.
OFFSET Count TYPE Description
0000h 1 byte Number of instruments
0001h ? rec Instrument information block
30 char The name of the instrument
1 byte Instrument type, bitmapped
0 - Instrument type
1 - Instrument type
00 - Sample in [SMPI] block
01 - MIDI device
10 - FM instrument
11 - reserved
2 - valid attack envelope
3 - sustain on
4 - reserved
5 - reserved
6 - reserved
7 - reserved
1 byte Range entries
="REN"
Like the GF1 patterns, an instrument can
consist of several samples.
"REN" rec Range definition
1 byte Sample to be played in this range
1 byte Length of this range in half tone steps up
6 byte Not yet defined 6-point envelope
DMFblock [SMPI]
This block contains the information about the samples stored in the file.
OFFSET Count TYPE Description
0000h 1 byte Number of samples (<= 250)
="NUM"
"NUM" rec Sample record
1 byte Length of sample name
? char Name of the sample
1 dword Length of sample in bytes
1 dword Start of sample loop
1 dword End of sample loop
1 word Frequency used for C-3
1 byte Volume for sample
0 - Don't change current volume
otherwise volume (linear scale)
1 byte Sample type, bitmapped
0 - not looped/looped
1 - 8/16-bit sample
(16-bit not supported with X-Tracker v0.30)
2,3 - Pack type :
00 - unpacked, signed sample
01 - pack type 0
10 - pack type 1
11 - pack type 2
4-6 - reserved, set to zero
7 - Sample stored in dmf/bib
1 word reserved, set to zero
1 dword crc32 of sample to identify samples
in BIB.
DMFblock [SMPD]
This block contains the sample data (raw or packed, see [SMPI] block) in the
following format :
<SampleLength> <SampleData> <SampleLength> <SampleData> etc.
OFFSET Count TYPE Description
0000h 1 dword Length of the following sample
? byte Sample data (might be packed)
DMFBlock [ENDE]
This block serves as a end of file marker and can be used for validation.
Note that the four ID characters are _not_ followed by a length dword ! Each DMF
file simply ends with the four characters 'ENDE'.
EXTENSION:DMF
OCCURENCES:PC
PROGRAMS:X-TRACKER,PLAY_DMF
SEE ALSO:
VALIDATION:
--------?-DMS-------------------------------
The DMS (Digital Music System??) are some other files I found on a
mixed system CD, so I include them in my listing. They are Amiga files,
so here's the call to the Amiga folks again.
OFFSET Count TYPE Description
0000h 4 char ID="DMS!"
EXTENSION:DMS
OCCURENCES:Amiga
--------A-DWC-?-----------------------------
The DWC archives seem to be a relict from ancient computing times - I've never
seen any program that dealt with them or could create them. They are yet
included in this compilation for reasons I don't know. But maybe one of you
stumbles over such a file, he might find this documentation helpful.
The DWC archives consist of single file entries with one archive trailer. The
archive entries seem to be at the start of the archive, but maybe they are
stored at the end of the archive, before the trailer. Each file header has the
following format :
OFFSET Count TYPE Description
0000h 13 char Name of the original file in ASCIIZ.
000Dh 1 dword Size of the original file
0011h 1 dword MS-DOS date and time of the original file
0015h 1 dword Size of the compressed file
0019h 1 dword Offset of compressed data in archive file
001Dh 3 byte reserved
0020h 1 byte Method :
1 - crunched
2 - stored
The trailer at the end of each archive has the following format :
OFFSET Count TYPE Description
0000h 1 word Length of trailer (=27)
0002h 1 word Size of the directory entries (=34)??
0004h 16 byte reserved
0014h 1 dword Count of the directory entries
0018h 3 char ID="DWC"
EXTENSION:DWC??
OCCURENCES:PC??
PROGRAMS:DWC.EXE??
--------S-EFE-------------------------------
The EFE files are instrument files for the Ensoniq sampler system.
Further information wanted.
EXTENSION:EFE
SEE ALSO:GKH,INS
--------E-EXE-X-----------------------------
Different types of executables have emerged on the Intel DOS related platforms -
but all contain at least a stub MZ Exe before their actual EXE body...
SEE ALSO:MZ EXE,NE EXE
--------M-FAR-------------------------------
The Fandarole composer is a 16 channel composer created by the group
Digital Infinity / Daniel Potter for digital music in module style.
The Fandarole modules have the following format :
OFFSET Count TYPE Description
0000h 4 char ID='FAR',254
0004h 40 char Song name
002Ch 3 char ID=13,10,26
This ID makes it possible to see the song name
by simply typing the .far file.
002Fh 1 word Remaining header size
0031h 1 byte Version number as BCD,
high nibble = major version
low nibble = minor version
0032h 16 byte Channel on/off map
<> 0 means that channel is used
0042h 1 rec Editing data.
This data is not necessary for playback,
but is stored by the composer for resume of
edit.
1 byte Current octave
1 byte Current voice
1 byte Current row
1 byte Current pattern
1 byte Current order
1 byte Current sample
1 byte Current volume
1 byte Current top of screen display
1 byte Current editing area
0=samples,
1=patterns,
2=orders
1 byte Current tempo (default tempo)
004Ch 16 byte Panning map for each channel, 0=left,15=right
005Ch 1 byte Marked block start
005Dh 1 byte Marked block end
005Eh 1 byte Grid granularity
005Fh 1 byte Edit mode
0060h 1 word Song text length
="STL"
0062h "STL" char Song text
0062h+ 256 byte Order bytes for pattern ordering
"STL"
0162h+ 1 byte Number of stored patterns
"STL"
0163h+ 1 byte Song length in patterns
"STL"
0164h+ 1 byte Loop position. This is the restart position
"STL" if the end of the song is reached.
0165h+ 256 word Length of each pattern. The number of rows in
"STL" each pattern is ( this word-2 )/(16*4)
After this block, there might be additional data in the future (see remaining
header size, above), after that, the pattern data follows.
The pattern data :
OFFSET Count TYPE Description
0000h 1 byte Length of pattern in rows
="LIR"
0001h 1 byte Tempo for this pattern - Unsupported,
use not recommended
0002h 4*"LIR" rec Note data for each pattern in 4 channels
1 byte Note value (Octave*12+Note)+1
0 means no note
1 byte Sample number
1 byte Volume byte. The volume is stored reversed,
the lower nibble is the major volume, the lower
nibble is the minor volume adjust.
1 byte Effect byte. Upper nibble is effect, lower
nibble is data. (see table 0004)
(Table 0004)
Note Effects in FAR-modules
01 - Pitch adjust
02 - Pitch adjust
03 - Portamento to note
04 - Retrigger note data times for one bar
05 - Set vibrato depth
06 - Vibrato
07-0C - ?Possibly undefined?
0D - Fine tune tempo down 128/Tempo
0E - Fine tune tempo up 128/Tempo
0F - Tempo, notes per second = 32/Tempo
After the pattern data, the sample map follows. This is an array of 64 bits
(eight bytes), each set bit corresponds to a sample record stored in the file,
each zero bit means that the corresponding record is not stored in the file.
OFFSET Count TYPE Description
0000h 8 byte Sample flags, see above
After the sample flags, the samples themselves are stored in the FSM format,
except for the ("FSM",254) header. They follow header-data-header-data-etc.,
see the FSM entry for further information.
EXTENSION:FAR
OCCURENCES:PC
PROGRAMS:Fandarole Composer
REFERENCE:
SEE ALSO:FSM
VALIDATION:
--------a-FLT-------------------------------
The FLC files are files created by the Autodesk Animator Pro and contain
animations. The FLC files are a superset of those created by the Autodesk
Animator (FLIc files). In some cases, new data fields or compression methods
were added. The FLC files use a hierarchical block oriented structure and blocks
are a combination of control information and data. The file consists of one
header followed by data blocks. It is possible that new types of blocks not
described in this document will be added to animation files in the future. It is
recommended that you quietly ignore unknown block types you encounter during
animation playback. The size fields in the block headers make it easy to skip
an entire unrecognized block.
The FLC files consist of one 128-byte header block and one or more of the
following blocks :
The prefix block, if present, contains Animator Pro settings information,
CEL placement information, and other auxiliary data.
A frame block exists for each frame in the animation. In addition, a ring frame
follows all the animation frames. Each frame block contains color palette
information and/or pixel data.
The ring frame contains delta-compressed information to loop from the last frame
of the flic back to the first. It can be helpful to think of the ring frame as a
copy of the first frame, compressed in a different way. All flic files will
contain a ring frame, including a single-frame flic.
The FLC file header
OFFSET Count TYPE Description
0000h 1 dword The size of the whole animation file, including
the size of this header.
0004h 1 word ID=0AF12h
0006h 1 word Number of frames in this animation, not
including the ring frame. FLC files have a
maximum length of 4000 frames.
0008h 1 word Screen width in pixels
000Ah 1 word Screen height in pixels
000Ch 1 word Bits per pixel (always 8)
000Eh 1 word Flags - bitmapped
0 - Ring frame not written / ring frame written
1 - Flic header not updated / updated
2-15 - reserved
0010h 1 dword Delay between frames in miliseconds.
0014h 1 word reserved
0016h 1 dword MS-DOS date and time of file creation (see table 0009)
001Ah 1 dword Serial number of the Animator Pro program used
to create the file. If the file was created
with the FlicLib development kit, this value
equals 0464c4942h ("FLIB").
001Eh 1 dword MS-DOS date and time of last modification (see table 0009)
0022h 1 dword Serial number of program that made the last
modification. See Serial Number.
0026h 1 word X-axis aspect ratio of the file
0028h 1 word Y-axis aspect ratio of the file
(320x200 = 6:5)
002Ah 38 byte reserved (0)
0050h 1 dword Offset from begin of file to the first
animation frame block.
0054h 1 dword Offset from begin of file to the second
animation frame block. This value is used
when looping the animation.
0058h 40 byte reserved (0)
Each subblock in the animation file has an identical header structure,
which is formatted like this :
0000h 1 dword The size of the whole block and all subordinate
blocks including the size of this header
0004h 1 word Block ID, varies depending on the block type.
0006h 1 word Number of subordinate blocks in this block.
including the ring frame. FLC files have a
maximum length of 4000 frames.
0008h 8 byte reserved(0)
Immediately after the header there may be an optional prefix block, which is
used to store additional data which is not directly involved in animation
playback.
The prefix block has the usual header with an ID of 0F100h.
The prefix block should only be created by the Animator Pro programs and never
by any other software, it is to be ignored by other software.
The FLC frame blocks contain the information to convert the current frame into
the next frame; they have an ID of 0F1FAh. Directly after the frame header,
there are the subordinate data blocks - if the subblock count is 0 this means,
that the current frame is identical to the previous frame, only the appropriate
delay has to be made.
The data blocks have a different header format :
OFFSET Count TYPE Description
0000h 1 dword Size of this block, including header size
0004h 1 word Data type identifier :
4 - 256-level color palette info
7 - Word-oriented delta compression
11 - 64-level color palette info
12 - Byte-oriented delta compression
13 - Entire frame is color index 0
15 - Byte run length compression
16 - No compression
18 - Postage stamp sized image
0006h ? byte Color or pixel data
The following sections describe each of these data encoding methods in detail.
--- Block Type 4 (FLI_COLOR256) - 256-Level Color
The data in this block is organized in packets. The first word following the
block header is a count of the number of packets in the blocks. Each packet
consists of a one-byte color index skip count, a one-byte color count and three
bytes of color information for each color defined.
At the start of the block, the color index is assumed to be zero. Before
processing any colors in a packet, the color index skip count is added to the
current color index. The number of colors defined in the packet is retrieved.
A zero in this byte indicates 256 colors follow. The three bytes for each color
define the red, green, and blue components of the color in that order. Each
component can range from 0 (off) to 255 (full on). The data to change colors
2,7,8, and 9 would appear as follows:
2 ; two packets
2,1,r,g,b ; skip 2, change 1
4,3,r,g,b,r,g,b,r,g,b ; skip 4, change 3
--- Block Type 11 (FLI_COLOR) - 64-Level Color
This block is identical to FLI_COLOR256 except that the values for the red,
green and blue components are in the range of 0-63 instead of 0-255, i.e. in
native VGA values which can be written to the VGA without modification.
--- Block Type 13 (FLI_BLACK) - No Data
This block has no data following the header. All pixels in the frame are set to
color index 0.
--- Block Type 16 (FLI_COPY) - No Compression
This block contains an uncompressed raw image of the frame, from upper left
to the lower right, storing each line sequentially. This type of block is
created when the preferred compression method (SS2 or BRUN) generates more
data than the uncompressed frame image; a relatively rare situation.
--- Block Type 15 (FLI_BRUN) - Byte Run Length Compression
This block contains the entire image in a compressed format. Usually this block
is used in the first frame of an animation, or within a postage stamp image
block.
The data is organized in lines. Each line contains packets of compressed pixels.
The first line is at the top of the animation, followed by subsequent lines
moving downward. The number of lines in this block is given by the height of the
animation.
The first byte of each line is a count of packets in the line. This value is
ignored, it is a holdover from the original Animator. It is possible to generate
more than 255 packets on a line. The width of the animation is now used to drive
the decoding of packets on a line; continue reading and processing packets until
width pixels have been processed, then proceed to the next line.
Each packet consist of a type/size byte, followed by one or more pixels. If the
number is negative (the high bit of the packet type is set), the absolute value
is the count of pixels to be copied from the packet to the animation image,
otherwise the next byte contains a single pixel which is to be replicated;
The lower 7 bits are the number of times the pixel is to be replicated.
--- Block Type 12 (FLI_LC) - Byte Aligned Delta Compression
This block contains the differences between the previous frame and this frame.
This compression method was used by the original Animator, but is not created by
Animator Pro. This type of block can appear in an Animator Pro file, however, if
the file was originally created by Animator, then some (but not all) frames were
modified using Animator Pro.
The first word following the block header contains the position of the first
line in the block. This is a count of lines (down from the top of the image)
which are unchanged from the prior frame. The second word contains the number of
lines in the block. The data for the lines follows these two words.
Each line begins with two bytes. The first byte contains the starting x position
of the data on the line, and the second byte the number of packets for the line.
Unlike BRUN compression, the packet count is significant (because this
compression method is only used on 320x200 flics).
Each packet consists of a single byte column skip, followed by a packet type/
size byte, which has the reverse meaning of in the block type 15.
--- Block Type 7 (FLI_SS2) - Word Aligned Delta Compression
This format contains the differences between consecutive frames. This is the
format most often used by Animator Pro for frames other than the first frame of
an animation. It is similar to the line coded delta (LC) compression, but is
word oriented instead of byte oriented. The data is organized into lines and
each line is organized into packets.
The first word in the data following the block header contains the number of
lines in the block. Each line can begin with some optional words that are used
to skip lines and set the last byte in the line for animations with odd widths.
These optional words are followed by a count of the packets in the line. The
line count does not include skipped lines.
The high order two bits of the word is used to determine the contents of
the word :
Bit 15 Bit 14 Meaning
0 0 The word contains the packet count. The packets follow
this word. The packet count can be zero; this occurs
when only the last pixel on a line changes.
1 0 The low order byte is to be stored in the last byte of
the current line. The packet count always follows this
word.
1 1 The word contains a line skip count. The number of
lines skipped is given by the absolute value of the
word. This word can be followed by more skip counts,
by a last byte word, or by the packet count.
The packets in each line are similar to the packets for the line coded block.
The first byte of each packet is a column skip count. The second byte is a
packet type. If the packet type is positive, the packet type is a count of words
to be copied from the packet to the animation image. If the packet type is
negative, the packet contains one more word which is to be replicated. The
absolute value of the packet type gives the number of times the word is to be
replicated. The high and low order byte in the replicated word do not
necessarily have the same value.
--- Block Type 18 (FLI_PSTAMP) - Postage Stamp Image
This block type holds a postage stamp - a reduced-size image - of the frame. It
generally appears only in the first frame block within a flic file. When
creating a postage stamp, Animator Pro considers the ideal size to be 100x63
pixels. The actual size will vary as needed to maintain the same aspect ratio as
the original.
The pixels in a postage stamp image are mapped into a six-cube color space,
regardless of the color palette settings for the full frame image. A six-cube
color space is formed as follows:
start at palette entry 0
for red = 0 thru 5
for green = 0 thru 5
for blue = 0 thru 5
palette_red = (red * 256)/6
palette_green = (green * 256)/6
palette_blue = (blue * 256)/6
move to next palette entry
end for blue
end for green
end for red
Any arbitrary rgb value (where each component is in the range of 0-255) can be
mapped into the six-cube space using the formula:
((6*red)/256)*36 + ((6*green)/256)*6 + ((6*blue)/256)
The full postage stamp block header is defined as follows:
Offset Length Name Description
OFFSET Count TYPE Description
0000h 1 dword Size of this block, including header size
0004h 1 word ID=18
0006h 1 word Height of the postage stamp image
0008h 1 word Width of the image
000Ah 1 word Color translation type :
1 - six-cube color space
Immediately following this header is the postage stamp data. The data is
formatted as a block with standard size/type header. The type will be one of:
15 FPS_BRUN Byte run length compression
16 FPS_COPY No compression
18 FPS_XLAT256 Six-cube color xlate table
The FPS_BRUN and FPS_COPY types are identical to the FLI_BRUN and FLI_COPY
encoding methods described above.
The FPS_XLAT256 type indicates that the block contains a 256-byte color
translation table instead of pixel data. To process this type of postage stamp,
read the pixel data for the full-sized frame image, and translate its pixels
into six-cube space using a lookup in the 256-byte color translation table. This
type of postage stamp appears when the size of the animation frames is smaller
than the standard 100x63 postage stamp size.
*************
TWE - Tween Data Files
A TWE file holds information about a tweening operation set up
via the Tween menus. The information includes the starting and
ending shapes, and the optional userD specified links between the
shapes. Animator Pro creates tween files.
A TWE file begins with an 8-byte header defined as follows:
Offset Length Name Description
0 2 magic File format identifier. Always hex 1995.
2 2 version The file format version; always zero.
4 4 tcount The number of tween shapes in the file;
always 2.
8 8 reserved Unused space; set to zeroes.
16 4 linkcount The number of link entries in the file.
Immediately following the file header are the link entries. If
the linkcount value is zero there are no links. Each link entry
is a pair of 32-bit integers. The first value in each pair is the
index of the point in the first shape, and the second value is
the index of the point in the ending shape. (IE, a link value of
2,7 says to link the second starting-shape point to the seventh
ending-shape point.)
Following the link entries is the data block that describes the
starting shape, then the data block that describes the ending
shape. The format of these blocks is identical to that of the
polygon (PLY) file, including file header data. In other words,
they appear as if a pair of polygon files are embedded in the
tween file at this point.
**********
OPT - Optics Menu Settings Files
An OPT file holds information about an optics operation set up
via the Optics menus. Both Animator Pro and the original
Animator create OPT files. The file format is the same for both.
An OPT file starts with a 4-byte header, as follows:
Offset Length Name Description
0 2 magic File type identifier. Always hex 1A3F.
2 2 count Number of records in the file.
Following the file header are optics records of 50 bytes each. A
record is generated for each click on CONTINUE MOVE in the OPTICS
menu. The move records are formatted as follows:
Offset Length Name Description
0 4 link In the file, this field is always zero.
In memory, it's a pointer to the next
move record.
4 6 spincenter The x,y,z coordinates of the spin
center point; three 16-bit values.
10 6 spinaxis The x,y,z coordinates of the spin axis;
three 16-bit values.
16 6 spinturns The x,y,z coordinates of the spin turns;
three 16-bit values.
22 4 spininter Intermediate turns. Two 16-bit values.
These are values for a conjugation matrix
that corresponds to spin axis.
26 6 sizecenter The x,y,z coordinates of the size
center point; three 16-bit values.
32 2 xmultiplier Determines (along with xdivisor)
how to scale along x dimension.
34 2 xdivisor Determines (along with xmultiplier) how
to scale along x dimension.
36 2 ymultiplier Determines (along with ydivisor)
how to scale along y dimension.
38 2 ydivisor Determines (along with ymultiplier) how
to scale along y dimension.
40 2 bothmult Like xmultiplier, but applied to both
dimensions.
42 2 bothdiv Like xdivisor, but applied to both
dimensions.
44 6 linearmove The x,y,z offset for a linear move;
three 16-bit values.
EXTENSION:FLT
OCCURENCES:PC
PROGRAMS:Autodesk Animator Pro
REFERENCE:
SEE ALSO:FLIc
VALIDATION:
--------a-FLIc------------------------------
The Flic file format was one of the first graphic animation formats on the PC.
It was developed by <> and used by the Autodesk Animator. It provides relatively
fast animation in 320x200 resolution modes. The FLI use delta updating for
faster animation. The single block information and prefix blocks are missing for
the FLI files, see the FLT format for a discussion.
OFFSET Count TYPE Description
0000h 1 dword Size of the FLIc file
0004h 1 word ID=0AF11h
AF11h means the file is a FLI file.
0006h 1 word Number of frames
0008h 1 word Width of displayed animation
000Ah 1 word Height of displayed animation
000Ch 1 word Number of used colors ("Depth")
000Eh 1 word Flags (=0003h)
0010h 1 dword Frame speed in sec/1024 **
0014h 1 word reserved
0016h 1 dword Date/Time of creation in DOS format (see table 0009)
001Ah 1 dword Creator
001Eh 1 dword Date/Time of last change in DOS format (see table 0009)
0022h 1 dword Serial number? of changer
0026h 1 word X-Aspect ratio of animation
0028h 1 word Y-Aspect ratio of animation
002Ah 38 byte reserved
0052h 1 dword Offset of frame 1 in file
0056h 1 dword Offset of frame 2 in file
005Ah 40 byte reserved
EXTENSION:FLI,FLT
OCCURENCES:PC
REFERENCE:DDJ0693
PROGRAMS:Autodesk Animator
SEE ALSO:QuickTime,AVI,FLT
--------D-FON-?-----------------------------
The Telix .FON files are the telephone books Telix uses to store numbers in.
The format is for Telix 3.22
OFFSET Count TYPE Description
0000h 1 dword ID=2E2B291Ah
0004h 1 word Version info (=1)
0006h 1 word Number of entries in directory (count from 1)
0007h 1 char ?will be used for encryption?
Currently 0
0008h 55 byte reserved
0040h ? rec Actual phonebook entry
25 char Name (0 terminated)
17 char Phone number (0 terminated)
1 byte Baud rate (see table 0006)
1 byte Parity type (see table 0007)
1 byte Data bits (7 or 8)
1 byte Stop bits (1 or 2)
12 char Script file name
6 char Date of last call in ASCII
1 word Number of total calls
1 byte Terminal type (see table 0008)
1 byte Protocol
1 byte Flags, bitmapped
0 - Local echo on / off
1 - add linefeeds on / off
2 - backspace is destructive on / off
3 - backspace sends DEL / sends BS
4 - strip high bits on / off
5-7 - reserved
1 word unknown
1 byte Dial prefix index
14 char Password
(Table 0006)
Baud rate tables for Telix
0 = 300 baud
1 = 1200 baud
2 = 2400 baud
3 = 4800 baud
4 = 9600 baud
5 = 19200 baud
6 = 38400 baud
7 = 57600 baud
8 = 115200 baud
(Table 0007)
Parity types for Telix
0 = None
1 = Even
2 = Odd
3 = Mark
4 = Space
(Table 0008)
Terminal types for Telix
0 = TTY
1 = ANSI-BBS
2 = VT102
3 = VT52
4 = AVATAR
5 = ANSI
EXTENSION:FON
OCCURENCES:PC
PROGRAMS:Telix v3.22
REFERENCE:
SEE ALSO:
VALIDATION:
--------M-FPT-------------------------------
The Fandarole Pattern files are used by the Fandarole Composer to store
single patterns in a file.
OFFSET Count TYPE Description
0000h 4 char ID='FPT',254
0004h 32 char ASCII pattern name
0024h 3 char ID=10,13,26
0027h 1 word Remaining size of file (size of pattern)
0029h 1 byte Break location (length of pattern)
002Ah 1 byte reserved
002Bh ? byte Pattern in raw format like in the .FAR file
EXTENSION:FAR,FPT
OCCURENCES:PC
PROGRAMS:Fandarole Composer
SEE ALSO:FAR,FSM
VALIDATION:
--------S-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
EXTENSION:FSM
OCCURENCES:PC
PROGRAMS:Fandarole Composer
REFERENCE:
SEE ALSO:FAR,USM
VALIDATION:
--------S-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
EXTENSION:PAT
OCCURENCES:PC
PROGRAMS:Patch Maker
SEE ALSO:VOC,WAVe
--------I-GIF-------------------------------
The Graphics Interchange Format (tm) was created by Compuserve Inc. as a
standard for the storage and transmission of raster-based graphics information,
i.e. images. A GIF file may contain several images, which are to be displayed
overlapping and without any delay betwenn the images. The image data itself is
compressed using a LZW scheme. Please note that the LZW algorithm is patented by
UniSys and that since Jan. 1995 royalties to Compuserve are due for every software
that implements GIF images.
The GIF file consists of a global GIF header, one or more image blocks and
optionally some GIF extensions.
OFFSET Count TYPE Description
0000h 6 char ID='GIF87a', ID='GIF89a'
This ID may be viewed as a version number
0006h 1 word Image width
0008h 1 word Image height
000Ah 1 byte bit mapped
0-2 - bits per pixel -1
3 - reserved
4-6 - bits of color resolution
7 - Global color map follows image descriptor
000Bh 1 byte Color index of screen background
000Ch 1 byte reserved
The global color map immediately follows the screen descriptor and has the size
(2**BitsPerPixel), and has the RGB colors for each color index. 0 is none, 255
is full intensity. The bytes are stored in the following format :
OFFSET Count TYPE Description
0000h 1 byte Red component
0001h 1 byte Green component
0002h 1 byte Blue component
After the first picture, there may be more pictures attached in the file
whic overlay the first picture or parts of the first picture. The Image
Descriptor defines the actual placement and extents of the following image
within the space defined in the Screen Descriptor. Each Image Descriptor is
introduced by an image separator character. The role of the Image Separator
is simply to provide a synchronization character to introduce an Image
Descriptor, the image separator is defined as ",", 02Ch, Any characters
encountered between the end of a previous image and the image separator
character are to be ignored.
The format of the Image descriptor looks like this :
OFFSET Count TYPE Description
0000h 1 char Image separator
ID=','
0001h 1 word Left offset of image
0003h 1 word Upper offset of image
0005h 1 word Width of image
0007h 1 word Height of image
0009h 1 byte Palette description - bitmapped
0-2 - Number of bits per pixel-1
3-5 - reserved (0)
6 - Interlaced / sequential image
7 - local / global color map, ignore bits 0-2
To provide for some possibility of an extension of the GIF files, a special
extension block introducer can be added after the GIF data block. The block has
the following structure :
OFFSET Count TYPE Description
0000h 1 char ID='!'
0001h 1 byte Extension ID
0002h ? rec
1 word Byte count
? byte Extra data
????h 1 byte Zero byte count - terminates extension block.
EXTENSION:GIF
OCCURENCES:PC
PROGRAMS:CSHOW.EXE
SEE ALSO:
VALIDATION:
--------A-GZIP------------------------------
The GNU ZIP program is an archive program mostly for the UNIX machines developed
by the GNU project.
OFFSET Count TYPE Description
0000h 2 char ID='!',139
0002h 1 byte Method :
0-7 - reserved
8 - deflated
0003h 1 byte File flags :
0 - ASCII-text
1 - Multi-part file
2 - Name present
3 - Comment present
4 - Encrypted
5-8 - reserved
0004h 1 dword File date and time (see table 0009)
0008h 1 byte Extra flags
0009h 1 byte Target OS :
0 - DOS
1 - Amiga
2 - VMS
3 - Unix
4 - ????
5 - Atari
6 - OS/2
7 - MacOS
10 - TOPS-20
11 - Win/32
EXTENSION:ZIP
PROGRAMS:GNU gzip
--------S-GKH-------------------------------
The GKH files are disk images of the Ensoniq EPS sampler system.
Further information is missing.
EXTENSION:GKH
SEE ALSO:EFE,INS
--------a-GRASPRT GL-G----------------------
The .GL animation files are graphic animations, some just .GIF files, others
mini-movies, used mostly for x-rated adult animations. The format of the files
is plain guesswork by me. The analyzed file did not include any animations but
only .GIF files and two text files which seemed to be the animation script.
There is no safe way of identifying a file as a GL animation, maybe except for
adding the subfile sizes and the header size and then check if this matches the
file size.
OFFSET Count TYPE Description
0000h 1 word Length of header, excluding this word
="HLN"
0002h ? rec The directory entries for each file
1 dword Offset of the stored file
12 char DOS file name of the stored file
0002h+ 1 dword Length of the first stored file
"HLN"
? byte The first file
The other files follow in similar
manner, length->file->length->file
EXTENSION:GL
OCCURENCES:PC
PROGRAMS:GRASPRT
--------?-GRIB------------------------------
The GRIB weather product information files just might be some satellite images
or something else. I have only seen this signature in a magic file and further
informations about the format is not known to me.
OFFSET Count TYPE Description
0000h 4 char ID='GRIB'
EXTENSION:???
OCCURENCES:???
PROGRAMS:???
--------A-HA--------------------------------
HA files (not to be confused with HamarSoft's HAP files [3]) contain a
small archive header with a word count of the number of files in the
archive. The constituent files stored sequentially with a header followed
by the compressed data, as is with most archives.
The main file header is formatted as follows:
OFFSET Count TYPE Description
0000h 2 char ID='HA'
0002h 1 word Number of files in archive
Every compressed file has a header before it, like this :
OFFSET Count TYPE Description
0000h 1 byte Version & compression type
0001h 1 dword Compressed file size
0005h 1 dword Original file size
0009h 1 dword CCITT CRC-32 (same as ZModem/PkZIP)
000Dh 1 dword File time-stamp (Unix format)
? ? char ASCIIZ pathname
? ? char ASCIIZ filename
????h 1 byte Length of machine specific information
? byte Machine specific information
Note that the path separator for pathnames is the 0FFh (255) character.
The high nybble of the version & compression type field contains the
version information (0=HA 0.98), the low nybble is the compression type :
(Table 0012)
HA compression types
0 "CPY" File is stored (no compression)
1 "ASC" Default compression method, using a sliding
window dictionary with an arithmetic coder.
2 "HSC" Compression using a "finite context [sic]
model and arithmetic coder"
14 "DIR" Directory entry
15 "SPECIAL" Used with HA 0.99B (?)
Machine specific information known:
1 byte Machine type (Host-OS)
1 = MS DOS
2 = Linux (Unix)
? bytes Information (currently only file-attribute info)
EXTENSION:HA
OCCURENCES:PC, Linux
PROGRAMS:HA
REFERENCE:
--------I-HSI1------------------------------
The HSI1 images are a JPEG derivative made by Handmade Software for their
Image Alchemy package.
OFFSET Count TYPE Description
0000h 4 char ID='HSI1'
EXTENSION:JPG
OCCURENCES:PC,SUN
PROGRAMS:Image Alchemy
REFERENCE:
SEE ALSO:JPEG
VALIDATION:
--------A-HYP-------------------------------
The Hyper archiver is a very fast compression program by P. Sawatzki and K.P.
Nischke, which uses LZW compression techniques for compression. It is not very
widespread - in fact, I've yet to see a package distributed in this format.
OFFSET Count TYPE Description
0000h 1 byte ID=1Ah
0001h 2 char Compression method
"HP" - compressed
"ST" - stored
0003h 1 byte Version file was compressed by in BCD
0004h 1 dword Compressed file size
0008h 1 dword Original file size
000Ch 1 dword MS-DOS date and time of file (see table 0009)
0010h 1 dword CRC-32 of file
0014h 1 byte MS-DOS file attribute
0015h 1 byte Length of filename
="LEN"
0016h "LEN" char Filename
EXTENSION:HYP
OCCURENCES:PC
PROGRAMS:HYPER.EXE
--------f-IFF-M-----------------------------
The IFF format is comparable to the RIFF file format, but it
uses Motorola byte ordering. After the FORM header, the different
records follow. Each record has a header ID of 4 bytes and then following
the size of the data (in Motorola byte ordering). Each IFF record starts on
an even byte boundary, that means if the record length is odd, you will have
to skip one more byte to get the next record.
OFFSET Count TYPE Description
0000h 4 char ID='FORM'
0004h 1 dword Size of the whole IFF block
0008h 4 char Type of the IFF file
Each IFF record has the following format :
OFFSET Count TYPE Description
0000h 4 char ID
0004h 1 dword Blocksize
0008h ? byte Block data, depends on block type.
OCCURENCES:Amiga,PC
SEE ALSO:8SVX,LBM,RIFF
--------S-INS-------------------------------
The INS files are instrument files for the Ensoniq sampler system.
Further information wanted.
EXTENSION:INS
SEE ALSO:EFE,GKH
--------I-JPEG-G----------------------------
The JPEG image standard is a standard for lossy (but efficient) image
compression made by the ???? Group. The endianness of the JPEG files is unknown
to me, there seem to exist both types of JPEG files.
The JPEG files are block oriented, there is a header for each JPG block,
but I was not able to find a list of all blocks - so you'll have to stick
with what I gathered here ;)
Format of a JPEG block (all data is in Motorola byte order) :
OFFSET Count TYPE Description
0000h 1 word Block ID
0FFD8h - JPEG signature block(4 chars="JFIF")
0FFC0h - JPEG color information
0FFC1h - JPEG color information
0002h 1 word Block size in bytes, without ID word.
Format of JPEG color information (motorola byte order) :
OFFSET Count TYPE Description
0000h 1 byte 1=Grayscale image
0001h 1 word Height
0003h 1 word Width
Another try for JPEG identification could be this one :
OFFSET Count TYPE Description
0000h 1 dword ID=FFD9FFE0h
ID=FFD8FFE0h
Big endian JPEG file (Intel)
ID=E0FFD8FFh
Little endian JPEG file (Motorola)
EXTENSION:JPG
OCCURENCES:PC,Amiga,SUN
PROGRAMS:
REFERENCE:
SEE ALSO:HSI1
VALIDATION:
--------I-LBM-M-----------------------------
The LBM/ILBM format is used by Deluxe Paint to store bitmap images. It
uses the IFF file format and Motorola byte order.
FORMblock [BMHD]
This block contains the information about the image.
OFFSET Count TYPE Description
0000h 1 word The image width (x-axis)
0002h 1 word The image height (y-axis)
0004h 1 dword reserved
0008h 1 byte Bits per pixel
0009h 1 byte ??reserved??
FORMblock [BODY]
This block contains the (compressed) image data... ****
FORMblock [CRGN]
This block contains palette information for a range of palette entries.
OFFSET Count TYPE Description
FORMblock [TINY]
This block contains a small image used for previewing.
OFFSET Count TYPE Description
EXTENSION:IFF,LBM
OCCURENCES:AMIGA,PC
PROGRAMS:Deluxe Paint
REFERENCE:???
SEE ALSO:IFF
--------A-LBR-------------------------------
The LBR files consist of a direcotry and one or more "members". The directory
contains from 4 to 256 entries and each entry describes one member.
The first directory entry describes the directory itself. All space allocations
are in terms of sectors, where a sector is 128 bytes long. Four directory
entries fit in one sector thus the number of directory entries is always evenly
divisible by 4. Different types of LBR files exist, all versions are discussed
here, the directory entry looks like this :
OFFSET Count TYPE Description
0000h 1 byte File status :
0 - active
254 - deleted
255 - free
0001h 11 char File name in FCB format (8/3, blank padded),
directory name is blanks for old LU,
ID='********DIR'
for LUPC
000Ch 1 word Offset to file data in sectors
000Eh 1 word Length of stored data in sectors
For the LUPC program, the remaining 16 bytes are used like this :
OFFSET Count TYPE Description
0000h 8 char ASCII date of creation (MM/DD/YY)
0008h 8 char ASCII time of creation (HH:MM:SS)
For the LU86 program, the remaining 16 bytes are used like this :
OFFSET Count TYPE Description
0000h 1 word CRC-16 or 0
0002h 1 word Creation date in CP/M format
0004h 1 word Creation time in DOS format
0006h 1 word Date of last modification, CP/M format
0008h 1 word Time of last modification, DOS format
000Ah 1 byte Number of bytes in last sector
000Bh 5 byte reserved (0)
EXTENSION:LBR
OCCURENCES:PC,CP/M
PROGRAMS:LU.COM, LUU.COM, LU86.COM
SEE ALSO:
--------A-LZH-------------------------------
The LHArc/LHA archiver is a multi platform archiver made by Haruyasu Yoshizaki,
which has a relatively good compression. It uses more or less the same
technology like the ZIP programs by Phil Katz. There was a hack named "ICE",
which had only the graphic characters displayed on decompression changed.
OFFSET Count TYPE Description
0000h 1 byte Size of archived file header
0001h 1 byte Checksum of remaining bytes
0002h 3 char ID='-lh'
ID='-lz'
0005h 1 char Compression methods used (see table 0005)
0006h 1 char ID='-'
0007h 1 dword Compressed size
000Bh 1 dword Uncompressed size
000Fh 1 dword Original file date/time (see table 0009)
0013h 1 word File attribute
0015h 1 byte Filename / path length in bytes
="LEN"
0016h "LEN" char Filename / path
0018h 1 word CRC-16 of original file
+"LEN"
(Table 0005)
LHArc compression types
"0" - No compression
"1" - LZW, 4K buffer, Huffman for upper 6 bits of position
"2" - unknown
"3" - unknown
"4" - LZW, Arithmetic Encoding
"5" - LZW, Arithmetic Encoding
"s" - LHa 2.x archive?
"\" - LHa 2.x archive?
"d" - LHa 2.x archive?
EXTENSION:LZH,ICE
OCCURENCES:PC
PROGRAMS:LHArc.EXE, LHA.EXE
--------M-MIDI-M----------------------------
The MIDI file format is used to store MIDI song data on disk. The discussed
version of the MIDI file spec is the approved MIDI Manufacturers' Associations
format version 0.06 of (3/88). The contact address is listed in the adresses
file. Version 1.0 is technically identical but the description has been
rewritten. The description was made by Dave Oppenheim, most of the text was
taken right out of his document.
MIDI files contain one or more MIDI streams, with time information for
each event. Song, sequence, and track structures, tempo and time signature
information, are all supported. Track names and other descriptive information
may be stored with the MIDI data. This format supports multiple tracks and
multiple sequences so that if the user of a program which supports multiple
tracks intends to move a file to another one, this format can allow that to
happen.
The MIDI files are block oriented files, currently only 2 block types are
defined, header and track data. Opposed to the IFF and RIFF formats, no
global header is given, so that the validation must be done by adding the
different block sizes.
A MIDI file always starts with a header block, and is followed by one or
more track block.
The format of the header block :
OFFSET Count TYPE Description
0000h 4 char ID='MThd'
0004h 1 dword Length of header data (=6)
0008h 1 word Format specification
0 - one, single multi-channel track
1 - one or more simultaneous tracks
2 - one or more sequentially independent
single-track patterns
000Ah 1 word Number of track blocks in the file
000Ch 1 int Unit of delta-time values.
If negative :
Absolute of high byte :
Number of frames per second.
Low byte :
Resolution within one frame
If positive, division of a quarter-note.
The track data format :
The MTrk block type is where actual song data is stored. It is simply a
stream of MIDI events (and non-MIDI events), preceded by delta-time
values.
Some numbers in MTrk blocks are represented in a form called a variable-
length quantity. These numbers are represented 7 bits per byte, most
significant bits first. All bytes except the last have bit 7 set, and
the last byte has bit 7 clear. If the number is between 0 and 127, it
is thus represented exactly as one byte. Since this explanation might not be
too clear, some exapmles :
Number (hex) Representation (hex)
00000000 00
00000040 40
0000007F 7F
00000080 81 00
00002000 C0 00
00003FFF FF 7F
001FFFFF FF FF 7F
08000000 C0 80 80 00
0FFFFFFF FF FF FF 7F
The largest number which is allowed is 0FFFFFFF so that the variable-
length representation must fit in 32 bits in a routine to write
variable-length numbers.
Each track block contains one or more MIDI events, each event consists of
a delta-time and the number of the event. The delta-time is stored as a
variable-length quantity and represents the time to delay before the following
event. A delta-time of 0 means, that the event occurs simultaneous with the
previous event or occurs right at the start of a track. The delta-time unit is
specified in the header block.
Format of track information block :
OFFSET Count TYPE Description
0000h 4 char ID='MTrk'
0004h 1 dword Length of header data
0008h ? rec <delta-time>, <event>
Three types of events are defined, MIDI event, system exclusive event and
meta event. The first event in a file must specify status; delta-time itself
is not an event. Meta events are non-MIDI informations.
The format of the meta event :
OFFSET Count TYPE Description
0000h 1 byte ID=FFh
0001h 1 byte Type (<=128)
0002h ? ? Length of the data, 0 if no data
stored as variable length quantity
? byte Data
A few meta-events are defined. It is not required for every program to support
every meta-event. Meta-events initially defined include:
FF 00 02 ssss Sequence Number
This optional event, which must occur at the beginning of a track,
before any nonzero delta-times, and before any transmittable MIDI
events, specifies the number of a sequence.
FF 01 len text Text Event
Any amount of text describing anything. It is a good idea to put a text
event right at the beginning of a track, with the name of the track, a
description of its intended orchestration, and any other information
which the user wants to put there. Programs on a computer which does not
support non-ASCII characters should ignore those characters with the hi-bit
set. Meta event types 01 through 0F are reserved for various types of text
events, each of which meets the specification of text events(above) but is
used for a different purpose:
FF 02 len text Copyright Notice
Contains a copyright notice as printable ASCII text. The notice should
contain the characters (C), the year of the copyright, and the owner of
the copyright. If several pieces of music are in the same MIDI file,
all of the copyright notices should be placed together in this event so
that it will be at the beginning of the file. This event should be the
first event in the first track block, at time 0.
FF 03 len text Sequence/Track Name
If in a format 0 track, or the first track in a format 1 file, the name
of the sequence. Otherwise, the name of the track.
FF 04 len text Instrument Name
A description of the type of instrumentation to be used in that track.
FF 05 len text Lyric
A lyric to be sung. Generally, each syllable will be a separate lyric
event which begins at the event's time.
FF 06 len text Marker
Normally in a format 0 track, or the first track in a format 1 file.
The name of that point in the sequence, such as a rehearsal letter or
section name ("First Verse", etc.).
FF 07 len text Cue Point
A description of something happening on a film or video screen or stage
at that point in the musical score ("Car crashes into house", "curtain
opens", "she slaps his face", etc.)
FF 2F 00 End of Track
This event is not optional. It is included so that an exact ending
point may be specified for the track, so that it has an exact length,
which is necessary for tracks which are looped or concatenated.
FF 51 03 tttttt Set Tempo, in microseconds per MIDI quarter-note
This event indicates a tempo change. Another way of putting
"microseconds per quarter-note" is "24ths of a microsecond per MIDI
clock". Representing tempos as time per beat instead of beat per time
allows absolutely exact dword-term synchronization with a time-based sync
protocol such as SMPTE time code or MIDI time code. This amount of
accuracy provided by this tempo resolution allows a four-minute piece at
120 beats per minute to be accurate within 500 usec at the end of the
piece. Ideally, these events should only occur where MIDI clocks would
be located Q this convention is intended to guarantee, or at least
increase the likelihood, of compatibility with other synchronization
devices so that a time signature/tempo map stored in this format may
easily be transferred to another device.
FF 54 05 hr mn se fr ff SMPTE Offset
This event, if present, designates the SMPTE time at which the track
block is supposed to start. It should be present at the beginning of
the track, that is, before any nonzero delta-times, and before any
transmittable MIDI events. The hour must be encoded with the SMPTE
format, just as it is in MIDI Time Code. In a format 1 file, the SMPTE
Offset must be stored with the tempo map, and has no meaning in any of
the other tracks. The ff field contains fractional frames, in 100ths of
a frame, even in SMPTE-based tracks which specify a different frame
subdivision for delta-times.
FF 58 04 nn dd cc bb Time Signature
The time signature is expressed as four numbers. nn and dd represent
the numerator and denominator of the time signature as it would be
notated. The denominator is a negative power of two: 2 represents a
quarter-note, 3 represents an eighth-note, etc. The cc parameter
expresses the number of MIDI clocks in a metronome click. The bb
parameter expresses the number of notated 32nd-notes in a MIDI quarter-
note (24 MIDI Clocks).
FF 59 02 sf mi Key Signature
sf = -7: 7 flats
sf = -1: 1 flat
sf = 0: key of C
sf = 1: 1 sharp
sf = 7: 7 sharps
mi = 0: major key
mi = 1: minor key
FF 7F len data Sequencer-Specific Meta-Event
Special requirements for particular sequencers may use this
event type: the first byte or bytes of data is a manufacturer ID.
However, as this is an interchange format, growth of the spec proper is
preferred to use of this event type. This type of event may be used by
a sequencer which elects to use this as its only file format;
sequencers with their established feature-specific formats should
probably stick to the standard features when using this format.
The system exclusive event is used as an escape to specify arbitrary bytes
to be transmitted. The system exclusive event has two forms, to compensate
for some manufacturer-specific modes, the F7h event is used if a F0h is to
be transmitted. Each system exclusive event must end with an F7h event.
The format of a system exclusive event :
OFFSET Count TYPE Description
0000h 1 byte ID=F0h,ID=F7h
0001h ? ? Length as variable length qty.
? byte bytes to be transmitted
EXTENSION:MID,MIDI
OCCURENCES:PC,MAC
PROGRAMS:Cubase
VALIDATION:
--------M-MOD-M-----------------------------
The Protracker composer is a composer for digital music. The MOD files are a
quasi standard for digital music, all words are in Motorola byte order. The
original MOD format allowed only 4 digital channels and 15 instruments, the
specification became enlarged (maybe by Mahoney and Kaktus??) to 4 channels and
31 instruments. Check the file at offset 1080d for the signatures 'M.K', '4CHN',
'6CHN','8CHN','FLT4','FLT8. If you find any of them, the module uses 31
instruments. With rising sound quality on the PC and other platforms, the old
MODule format has been replaced by numerous other formats. The 4/15 format has
almost become extinct. Below, only the 4/31 format is descripted.
The digital sample data is signed (two's complement) as necessary for the Amiga,
the sample data immediately follows the pattern data.
Maybe this is not valid for some 8CHN files; One of the two I have, uses Intel
byte ordering and unsigned samples.
OFFSET Count TYPE Description
0000h 20 char Song title, padded with spaces
0014h 31 rec Sample description record
For original MOD files, the number of
instruments would be 15.
22 char Sample name, padded with zeroes to
full length.
2 word Sample length / 2. Needs to be multiplied
by 2 to get the actual length. If the sample
length is greater than 8000h, the sample
is bigger than 64k.
1 byte Sample finetune. Only the lower nibble is
valid. Fine tune table :
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 +1 +2 +3 +4 +5 +6 +7 -8 -7 -6 -5 -4 -3 -2 -1
1 byte Sample volume (0-40h)
1 word Sample loop start / 2
1 word Sample loop length / 2
950d 1 byte Song length in patterns (0-80h)
951d 1 byte Restart byte for song looping (Noisetracker?)
952d 128 byte Pattern play sequences
1080d 4 char ID='M.K.', ID='4CHN',ID='6CHN',ID='8CHN'
ID='4FLT',ID='8FLT'
If this position contains 'M.K.','8CHN',
'4CHN','6CHN','FLT4' or 'FLT8' the module
has 31 instruments.
1084d ? rec Patterns
Each pattern has 64 rows.
Depending on the number of channels, each row
has from 4 to 8 notes. The channel count is
determined by the ID. (see table 0005)
The number of patterns is the highest pattern
number stored in the pattern list.
Each note has four bytes. Four notes make
up a track in a four channel MOD file. Each
track is saved sequentially :
byte 0-3 4-7 8-11 12-15
Chn #1 Chn #2 Chn #3 Chn #4
byte 16-19 20-23 24-27 28-31
Chn #1 Chn #2 Chn #3 Chn #4
1 word Instrument / period
The instrument number is in bits 12-15, the
12-bit period in bits 0-11.
1 byte Upper nibble : Lower 4 bits of the instrument,
Lower nibble : Special effect command.
1 byte Special effects data
(Table 0005)
Protracker 16 note conversion table / MOD Period table
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
PT16 : I 1I 2I 3I 4I 5I 6I 7I 8I 9I 10I 11I 12I
MOD : I 1712I 1616I 1524I 1440I 1356I 1280I 1208I 1140I 1076I 1016I 960I 906I
Note : I C-0I C#0I D-0I D#0I E-0I F-0I F#0I G-0I G#0I A-0I A#0I B-0I
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
I 13I 14I 15I 16I 17I 18I 19I 20I 21I 22I 23I 24I
I 856I 808I 762I 720I 678I 640I 604I 570I 538I 508I 480I 453I
I C-1I C#1I D-1I D#1I E-1I F-1I F#1I G-1I G#1I A-1I A#1I B-1I
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
I 25I 26I 27I 28I 29I 30I 31I 32I 33I 34I 35I 36I
I 428I 404I 381I 360I 339I 320I 302I 285I 269I 254I 240I 226I
I C-2I C#2I D-2I D#2I E-2I F-2I F#2I G-2I G#2I A-2I A#2I B-2I
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
I 37I 38I 39I 40I 41I 42I 43I 44I 45I 46I 47I 48I
I 214I 202I 190I 180I 170I 160I 151I 143I 135I 127I 120I 113I
I C-3I C#3I D-3I D#3I E-3I F-3I F#3I G-3I G#3I A-3I A#3I B-3I
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
I 49I 50I 51I 52I 53I 54I 55I 56I 57I 58I 59I 60I
I 107I 101I 95I 90I 85I 80I 75I 71I 67I 63I 60I 56I
I C-4I C#4I D-4I D#4I E-4I F-4I F#4I G-4I G#4I A-4I A#4I B-4I
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
EXTENSION:MOD,module
OCCURENCES:AMIGA,PC
PROGRAMS:DMP,ModEdit
VALIDATION:NONE
--------A-MS COMPRESS 5.0-G-----------------
Microsoft ships its files compressed with COMPRESS.EXE, for expansion the
program EXPAND.EXE (how original ;) ) is used. The program EXPAND.EXE is
available with every copy of MS-DOS 5.0+, the program COMPRESS.EXE is available
with several development kits, I found it with Borland Pascal 7.0. The
compression seems to be some kind of LZ-Compression, as the fully compatible?
LZCopy command under Windows can decompress the same files. This compression
feature seems to be available on all DOS-PCs.
OFFSET Count TYPE Description
0000h 4 char ID='SZDD'
0004h 1 long reserved, always 3327F088h ?
0008h 1 byte reserved
0009h 1 char Last char of filename if file was compressed
into "FILENAME.EX_".
000Ah 1 long Original file size
000Eh 1 byte reserved, varies...
EXTENSION:*.??_
OCCURENCES:PC
PROGRAMS:COMPRESS.EXE, EXPAND.EXE, LZEXPAND.DLL
REFERENCE:?Windows SDK?
SEE ALSO:MS COMPRESS 6.22+
VALIDATION:
--------A-MS COMPRESS 6.22+-G---------------
At least with the version 6.22 of MS-DOS, Microsoft changed their compression
program to a new signature; The program seems no more to be able to restore
files to their original name, if it is not given on the command line.
OFFSET Count TYPE Description
0000h 4 char ID="KWAJ"
0004h 1 long reserved, always 0D127F088h ?
0008h 1 long reserved, always 00120003h ?
000Ch 1 word reserved, always 01 ?
EXTENSION:*.??_
OCCURENCES:PC
PROGRAMS:COMPRESS.EXE, EXPAND.EXE, LZEXPAND.DLL