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.
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 ([email protected])
Daniel Dissett ([email protected])
Marcus Groeber ([email protected])
Darrel Hankerson ([email protected])
Carl Hauser ([email protected])
Jouni Miettunen ([email protected])
Jan Nicolai Langfeldt ([email protected])
Mark Ouellet (Telix .FON structures)
Greg Roelofs ([email protected])
Robert Rothenburg Walking-Owl ([email protected])
Jesus Villena (CONVERT.EXE, a digital sample conversion program)
Christos Zoulas ([email protected])
JAL / Nostalgia
David McDuffee, (75530,[email protected])
Information gleaned from other programs :
Formats for Word and WordPerfect (Selke's filetype)
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 [email protected] 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 REFERENCE:?Windows SDK? SEE ALSO:MS COMPRESS 5.0 VALIDATION: --------I-MSK------------------------------- The MSK files are mask files used by the Autodesk Animator and Animator Pro packages. Two types of MSK files exist. The Animator Pro version is simply a PIC file with the depth 1; A MSK file created by the original Animator is exactly 8000 bytes long. There is no file header or other control information in the file. It contains the image bit map, 1 bit per pixel, with the leftmost pixels packed into the high order bits of each byte. The size of the image is fixed at 320x200. The image is stored left-to-right, top-to-bottom. EXTENSION:MSK OCCURENCES:PC PROGRAMS:Autodesk Animator SEE ALSO:PIC,FLIc --------M-MTM------------------------------- The MTM format is generated by the Multi Track Module tracker by the demo group Renaissance. The tracker features up to 32 channel digital music. Instead of saving whole patterns, the tracker only saves the different tracks and the data which tracks should be played together at which time, thus saving some pattern space. OFFSET Count TYPE Description 0000h 3 char ID='MTM' 0003h 1 byte Version data upper nibble is major version number lower nibble is minor version number 0004h 20 char ASCIIZ song name 0018h 1 word Number of saved tracks. ="NOT" 001Ah 1 byte Highest pattern number saved ="NOP" 001Bh 1 byte Last order number to play(=Songlength-1) 001Ch 1 word Length of extra comment field in bytes ="XSZ" 001Eh 1 byte Number of samples ="NOS" 001Fh 1 byte Attribute byte (currently defined as 0) 0020h 1 byte Beats per track 0021h 1 byte Number of tracks 0022h 32 byte Pan positions of the voices (0=left, 15=right??) 0042h "NOS" rec Instrument data 22 char Sample name 1 dword Sample length in bytes 1 dword Start of sample loop in bytes 1 dword End of sample loop in bytes 1 byte Fine tune value for sample 1 byte Default volume for sample 1 byte Attribute byte, bit mapped 0 0=8 bit sample,1=16 bit sample 1-7 undefined (set to zero) 0042h+ 128 byte Pattern order data "NOS"*37 01C2h+ "NOS"*37 "NOT" rec Track data Each track is saved independently and has the size of exactly 192 bytes. Each track is arranged as 64 3-byte notes with the following format : 64*3 byte BYTE 0 BYTE 1 BYTE 2 ppppppii iiiieeee aaaaaaaa p = pitch value (0=no pitch stated) i = instrument number (0=no instrument number) e = effect number a = effect argument The effects are the standard Protracker effects. 01C2h+ ("NOP"+1)*32 word Track sequencing data "NOS"*37+ This is the list of which track is used "NOT"*192 as which voice in each pattern. One track can be part of many patterns, the drums for example. Track 0 is never saved but is always considered as an empty track. That means that counting really starts at one. The data is organized in sets of 32 voices. The first word contains the information which track is used in pattern 0, voice 0. The next word is for pattern 0, voice 1, etc., this is repeated for each pattern, 32 words for each saved pattern. 01C2h+ "XSZ" char Extra comment field. This contains some "NOS"*37+ message or something. "NOT"*192+ ("NOP"+1)*32*2 01C2h+ ? byte Raw sample data(unsigned). "NOS"*37+ "NOT"*192+ ("NOP"+1)*32*2+ "XSZ" EXTENSION:MTM SEE ALSO:MOD OCCURENCES:PC PROGRAMS:MMEDIT,DMP VALIDATION: --------M-MTS------------------------------- The Master Tracker program by the french demo group Arkham is a tracker for AdLib, SB and speaker - the further limits of this tracker are unknowm to me. OFFSET Count TYPE Description 0000h 6 char ID="MTRAC " 0006h 20 char Song name, zero padded EXTENSION:MST OCCURENCES:PC PROGRAMS:Master Tracler v1.0 SEE ALSO:MOD --------E-MZ EXE---------------------------- The old EXE files are the EXE files executed directly by MS-DOS. They were a major improvement over the old 64K COM files, since EXE files can span multiple segments. An EXE file consists of three different parts, the header, the relocation table and the binary code. The header is expanded by a lot of programs to store their copyright information in the executable, some extensions are documented below. The format of the header is as follows : OFFSET Count TYPE Description 0000h 2 char ID='MZ' ID='ZM' 0002h 1 word Number of bytes in last 512-byte page of executable 0004h 1 word Total number of 512-byte pages in executable (including the last page) 0006h 1 word Number of relocation entries 0008h 1 word Header size in paragraphs 000Ah 1 word Minimum paragraphs of memory allocated in addition to the code size 000Ch 1 word Maximum number of paragraphs allocated in addition to the code size 000Eh 1 word Initial SS relative to start of executable 0010h 1 word Initial SP 0012h 1 word Checksum (or 0) of executable 0014h 1 dword CS:IP relative to start of executable (entry point) 0018h 1 word Offset of relocation table; 40h for new-(NE,LE,LX,W3,PE etc.) executable 001Ah 1 word Overlay number (0h = main program) Following are the header expansions by some other prorams like TLink, LZExe and other linkers, encryptors and compressors; all offsets are relative to the start of the whole header : ---new executable OFFSET Count TYPE Description 001Ch 4 byte ???? 0020h 1 word Behaviour bits ?? 0022h 26 byte reserved (0) 003Ch 1 dword Offset of new executable header from start of file (or 0 if plain MZ executable) ---Borland TLINK OFFSET Count TYPE Description 001Ch 2 byte ?? (apparently always 01h 00h) 001Eh 1 byte ID=0FBh 001Fh 1 byte TLink version, major in high nybble 0020h 2 byte ?? ---old ARJ self-extracting archive OFFSET Count TYPE Description 001Ch 4 char ID='RJSX' (older versions) new signature is 'aRJsf'" in the first 1000 bytes of the file) ---LZEXE compressed executable OFFSET Count TYPE Description 001Ch 2 char ID='LZ' 001Eh 2 char Version number : '09' - LZExe 0.90 '91' - LZExe 0.91 ---PKLITE compressed executable OFFSET Count TYPE Description 001Ch 1 byte Minor version number 001Dh 1 byte Bit mapped : 0-3 - major version 4 - Extra compression 5 - Multi-segment file 001Eh 6 char ID='PKLITE' ---LHarc 1.x self-extracting archive OFFSET Count TYPE Description 001Ch 4 byte unused??? 0020h 3 byte Jump to start of extraction code 0023h 2 byte ??? 0025h 12 char ID='LHarc's SFX ' --LHA 2.x self-extracting archive OFFSET Count TYPE Description 001Ch 8 byte ??? 0024h 10 char ID='LHa's SFX ' For version 2.10 ID='LHA's SFX ' (v2.13) For version 2.13 ---LH self-extracting archive OFFSET Count TYPE Description 001Ch 8 byte ??? 0024h 8 byte ID='LH's SFX ' ---TopSpeed C 3.0 CRUNCH compressed file OFFSET Count TYPE Description 001Ch 1 dword ID=018A0001h 0020h 1 word ID=1565h ---PKARC 3.5 self-extracting archive OFFSET Count TYPE Description 001Ch 1 dword ID=00020001h 0020h 1 word ID=0700h ---BSA (Soviet archiver) self-extracting archive OFFSET Count TYPE Description 001Ch 1 word ID=000Fh 001Eh 1 byte ID=A7h ---LARC self-extracting archive OFFSET Count TYPE Description 001Ch 4 byte ??? 0020h 11 byte ID='SFX by LARC ' After the header, there follow the relocation items, which are used to span multpile segments. The relocation items have the following format : OFFSET Count TYPE Description 0000h 1 word Offset within segment 0002h 1 word Segment of relocation To get the position of the relocation within the file, you have to compute the physical adress from the segment:offset pair, which is done by multiplying the segment by 16 and adding the offset and then adding the offset of the binary start. Note that the raw binary code starts on a paragraph boundary within the executable file. All segments are relative to the start of the executable in memory, and this value must be added to every segment if relocation is done manually. EXTENSION:EXE,OVR,OVL OCCURENCES:PC PROGRAMS:MS-DOS REFERENCE:Ralf Brown's Interrupt List SEE ALSO:COM,EXE,NE EXE --------E-NE EXE---------------------------- The NE EXE files are the new exe files used by windows and OS/2 executables. They contain a small MZ EXE which prints "This program requires Microsoft Windows" or something similar but Some files contain both DOS and Windows versions of the executable. The position of the new EXE header can be found in the old exe header - see the MZ EXE topic for further information. All offsets within this header are from the start of the header if not noted otherwise. OFFSET Count TYPE Description 0000h 2 char ID='NE' 0002h 1 byte Linker major version 0003h 1 byte Linker minor version 0004h 1 word Offset of entry table (see below) 0006h 1 word Length of entry table in bytes 0008h 1 dword File load CRC (0 in Borland's TPW) 000Ch 1 byte Program flags, bitmapped : 0-1 - DGroup type : 0 - none 1 - single shared 2 - multiple 3 - (null) 2 - Global initialization 3 - Protected mode only 4 - 8086 instructions 5 - 80286 instructions 6 - 80386 instructions 7 - 80x87 instructions 000Dh 1 byte Application flags, bitmapped 0-2 - Application type 1 - Full screen (not aware of Windows/P.M. API) 2 - Compatible with Windows/P.M. API 3 - Uses Windows/P.M. API 3 - OS/2 family application 4 - reserved? 5 - Errors in image/executable 6 - "non-conforming program" whatever 7 - DLL or driver (SS:SP info invalid, CS:IP points at FAR init routine called with AX=module handle which returns AX=0000h on failure, AX nonzero on successful initialization) 000Eh 1 byte Auto data segment index 0010h 1 word Initial local heap size 0012h 1 word Initial stack size 0014h 1 dword Entry point (CS:IP), CS is index into segment table 0018h 1 dword Initial stack pointer (SS:SP) SS is index into segment table 001Ch 1 word Segment count 001Eh 1 word Module reference count 0020h 1 word Size of nonresident names table in bytes 0022h 1 word Offset of segment table (see below) 0024h 1 word Offset of resource table 0026h 1 word Offset of resident names table 0028h 1 word Offset of module reference table 002Ah 1 word Offset of imported names table (array of counted strings, terminated with a string of length 00h) 002Ch 1 dword Offset from start of file to nonresident names table 0030h 1 word Count of moveable entry point listed in entry table 0032h 1 word File alignment size shift count 0 is equivalent to 9 (default 512-byte pages) 0034h 1 word Number of resource table entries 0036h 1 byte Target operating system 0 - unknown 1 - OS/2 2 - Windows 3 - European MS-DOS 4.x 4 - Windows 386 5 - BOSS (Borland Operating System Services) 0037h 1 byte Other OS/2 EXE flags, bitmapped 0 - Long filename support 1 - 2.x protected mode 2 - 2.x proportional fonts 3 - Executable has gangload area 0038h 1 word Offset to return thunks or start of gangload area - whatever that means. 003Ah 1 word offset to segment reference thunks or length of gangload area. 003Ch 1 word Minimum code swap area size 003Eh 2 byte Expected Windows version (minor version first) EXTENSION:DLL,EXE,FOT OCCURENCES:PC PROGRAMS: REFERENCE:Windows 3.1 SDK Programmer's Reference, Vol 4. SEE ALSO:EXE,MZ EXE --------H-NG-G------------------------------ Information about this format comes only from a magic file, thus is only good for file identification. I did not test it, since I don't have any NG files. The Norton Guides are a popup help program for the IBM PCs which provide instant help anywhere... OFFSET Count TYPE Description 0000h 2 char ID='NG' 0002h 1 dword ID=0 EXTENSION:NG OCCURENCES:PC PROGRAMS:NG.EXE SEE ALSO:TPH,HLP --------B-OBJ------------------------------- Most of the description was taken from the Microsoft Product Support Services Application Note SS0288. The .OBJ files are binary files used by compilers to link in precompiled code. They contain symbol and relocation information necessary to link the data and code contained in the files. The .OBJ files have no common header which makes a validation or identification guesswork at best. The .OBJ files consist of at least one record, each of the following type : OFFSET Count TYPE Description 0000h 1 byte Record type (see below) 0001h 1 word Record length ="LEN" 0003h "LEN" byte Record data 0003h 1 byte Checksum or 0 +"LEN" (that much for validation) The maximum size of the entire record (unless otherwise noted for specific record types) is 1024 bytes. For LINK386, the format is determined by the least-significant bit of the Record Type field. An odd Record Type indicates that certain numeric fields within the record contain 32-bit values; an even Record Type indicates that those fields contain 16-bit values. The affected fields are described with each record. Note that this principle does not govern the Use32/Use16 segment attribute (which is set in the ACBP byte of SEGDEF records); it simply specifies the size of certain numeric fields within the record. It is possible to use 16-bit OMF records to generate 32-bit segments, or vice versa. LINK ignores the value of the checksum byte, but some other utilities may not. Microsoft's Quick languages write a 0 byte instead of computing a checksum. The contents of each record are determined by the record type, but certain subfields appear frequently enough to be explained separately. The format of such fields is below. Names : A name string is encoded as an 8-bit unsigned count followed by a string of count characters. The character set is usually some ASCII subset. A null name is specified by a single byte of 0 (indicating a string of length 0). Indexed References : Certain items are ordered by occurrence and are referenced by index. The first occurrence of the item has index number 1. Index fields may contain 0 (indicating that they are not present) or values from 1 through 7FFF. The index number field in an object record can be either 1 or 2 bytes long. If the number is in the range 0-7FH, the high-order bit (bit 7) is 0 and the low-order bits contain the index number, so the field is only 1 byte long. If the index number is in the range 80- 7FFFH, the field is 2 bytes long. The Type Indexes : Type Index fields occupy 1 or 2 bytes and occur in PUBDEF, LPUBDEF, COMDEF, LCOMDEF, EXTDEF, and LEXTDEF records. They are encoded as described above for indexed references, but the interpretation of the values stored is governed by whether the module has the "new" or "old" object module format. "Old" versions of the OMF (indicated by lack of a COMENT record with comment class A1), have Type Index fields that contain indexes into previously seen TYPDEF records. This format is no longer produced by Microsoft products and is ignored by LINK if it is present. See the section of this document on TYPDEF records for details on how this was used. "New" versions of the OMF (indicated by the presence of a COMENT record with comment class A1), have Type Index fields that contain proprietary CodeView information. For more information on CodeView, see Appendix 1. Ordered Collections : Certain records and record groups are ordered so that the records may be referred to with indexes (the format of indexes is described in the "Indexed References" section of this document). The same format is used whether an index refers to names, logical segments, or other items. The overall ordering is obtained from the order of the records within the file together with the ordering of repeated fields within these records. Such ordered collections are referenced by index, counting from 1 (index 0 indicates unknown or not specified). For example, there may be many LNAMES records within a module, and each of those records may contain many names. The names are indexed starting at 1 for the first name in the first LNAMES record encountered while reading the file, 2 for the second name in the first record, and so forth, with the highest index for the last name in the last LNAMES record encountered. The ordered collections are: Names Ordered by occurrence of LNAMES records and names within each. Referenced as a name index. Logical Ordered by occurrence of SEGDEF records in Segments file. Referenced as a segment index. Groups Ordered by occurrence of GRPDEF records in file. Referenced as a group index. External Ordered by occurrence of EXTDEF, COMDEF, Symbols LEXTDEF, and LCOMDEF records and symbols within each. Referenced as an external name index (in FIXUP subrecords). Numeric 2- and 4-Byte Fields : Certain records, notably SEGDEF, PUBDEF, LPUBDEF, LINNUM, LEDATA, LIDATA, FIXUPP, and MODEND, contain size, offset, and displacement values that may be 32-bit quantities for Use32 segments. The encoding is as follows: - When the least-significant bit of the record type byte is set (that is, the record type is an odd number), the numeric fields are 4 bytes. - When the least-significant bit of the record type byte is clear, the fields occupy 2 bytes. The values are zero-extended when applied to Use32 segments. NOTE: See the description of SEGDEF records in this document for an explanation of Use16/Use32 segments. The general record ordering is not mandatory, but should be (for link speed) like this : THEADR or LHEADR record : Records Processed by LINK Pass 1 : All records may occur in any order but must stand before the link pass separator, if it is present. COMENT records identifying object format and extensions COMENT records other than Link Pass Separator comment LNAMES or LLNAMES records providing ordered name list SEGDEF records providing ordered list of program segments GRPDEF records providing ordered list of logical segments TYPDEF records (obsolete) ALIAS records PUBDEF records locating and naming public symbols LPUBDEF records locating and naming private symbols COMDEF, LCOMDEF, EXTDEF, LEXTDEF, and CEXTDEF records Link Pass Separator (Optional) : COMENT class A2 record indicating that Pass 1 of the linker is complete. When this record is encountered, LINK stops reading the object file in Pass 1; no records after this comment are read in Pass 1. All the records listed above must come before this COMENT record. For greater linking speed, all LIDATA, LEDATA, FIXUPP, BAKPAT, INCDEF, and LINNUM records should come after the A2 COMENT record, but this is not required. In LINK, Pass 2 begins again at the start of the object module, so these records are processed in Pass 2 no matter where they are placed in the object module. Records Ignored by LINK Pass 1 and Processed by LINK Pass 2 : The following records may come before or after the Link Pass Separator: LIDATA, LEDATA, or COMDAT records followed by applicable FIXUPP records FIXUPP records containing only THREAD subrecords BAKPAT and NBKPAT FIXUPP records COMENT class A0, subrecord type 03 (INCDEF) records containing incremental compilation information for FIXUPP and LINNUM records LINNUM and LINSYM records providing line number and program code or data association Terminator : MODEND record indicating end of module with optional start address Details of each record (form and content) follow below. Conflicts between various OMFs that overlap in their use of record types or fields are marked. Below is a combined list of record types defined by the Intel 8086 OMF specification and record types added after that specification was finished. Titles in square brackets ([]) indicate record types that have been implemented and that are described in this document. Titles not in square brackets indicate record types that have not been implemented and are followed by a paragraph of description from the Intel specification. For unimplemented record types, a subtle distinction is made between records that LINK ignores and those for which LINK generates an "illegal object format" error condition. Records Currently Defined 6EH RHEADR R-Module Header Record This record serves to identify a module that has been processed (output) by LINK-86/LOCATE-86. It also specifies the module attributes and gives information on memory usage and need. This record type is ignored by Microsoft LINK. 70H REGINT Register Initialization Record This record provides information about the 8086 register/register-pairs: CS and IP, SS and SP, DS and ES. The purpose of this information is for a loader to set the necessary registers for initiation of execution. This record type is ignored by Microsoft LINK. 72H REDATA Relocatable Enumerated Data Record This record provides contiguous data from which a portion of an 8086 memory image may eventually be constructed. The data may be loaded directly by an 8086 loader, with perhaps some base fixups. The record may also be called a Load-Time Locatable (LTL) Enumerated Data Record. This record type is ignored by Microsoft LINK. 74H RIDATA Relocatable Iterated Data Record This record provides contiguous data from which a portion of an 8086 memory image may eventually be constructed. The data may be loaded directly by an 8086 loader, but data bytes within the record may require expansion. The record may also be called a Load-Time Locatable (LTL) Iterated Data Record. This record type is ignored by Microsoft LINK. 76H OVLDEF Overlay Definition Record This record provides the overlay's name, its location in the object file, and its attributes. A loader may use this record to locate the data records of the overlay in the object file. This record type is ignored by Microsoft LINK. 78H ENDREC End Record This record is used to denote the end of a set of records, such as a block or an overlay. This record type is ignored by Microsoft LINK. 7AH BLKDEF Block Definition Record This record provides information about blocks that were defined in the source program input to the translator that produced the module. A BLKDEF record will be generated for every procedure and for every block that contains variables. This information is used to aid debugging programs. This record type is ignored by Microsoft LINK. 7CH BLKEND Block End Record This record, together with the BLKDEF record, provides information about the scope of variables in the source program. Each BLKDEF record must be followed by a BLKEND record. The order of the BLKDEF, debug symbol records, and BLKEND records should reflect the order of declaration in the source module. This record type is ignored by Microsoft LINK. 7EH DEBSYM Debug Symbols Record This record provides information about all local symbols, including stack and based symbols. The purpose of this information is to aid debug- ging programs. This record type is ignored by Microsoft LINK. [80H] [THEADR] [Translator Header Record] [82H] [LHEADR] [Library Module Header Record] 84H PEDATA Physical Enumerated Data Record This record provides contiguous data, from which a portion of an 8086 memory image may be constructed. The data belongs to the "unnamed absolute segment" in that it has been assigned absolute 8086 memory addresses and has been divorced from all logical segment information. This record type is ignored by Microsoft LINK. 86H PIDATA Physical Iterated Data Record This record provides contiguous data, from which a portion of an 8086 memory image may be constructed. It allows initialization of data segments and provides a mechanism to reduce the size of object modules when there is repeated data to be used to initialize a memory image. The data belongs to the "unnamed absolute segment." This record type is ignored by Microsoft LINK. [88H] [COMENT] [Comment Record] [8AH/8BH] [MODEND] [Module End Record] [8CH] [EXTDEF] [External Names Definition Record] [8EH] [TYPDEF] [Type Definition Record] [90H/91H] [PUBDEF] [Public Names Definition Record] 92H LOCSYM Local Symbols Record This record provides information about symbols that were used in the source program input to the translator that produced the module. This information is used to aid debugging programs. This record has a format identical to the PUBDEF record. This record type is ignored by Microsoft LINK. [94H/95H] [LINNUM] [Line Numbers Record] [96H] [LNAMES] [List of Names Record] [98H/99H] [SEGDEF] [Segment Definition Record] [9AH] [GRPDEF] [Group Definition Record] [9CH/9DH] [FIXUPP] [Fixup Record] 9EH (none) Unnamed record This record number was the only even number not defined by the original Intel specification. Apparently it was never used. This record type is ignored by Microsoft LINK. [A0H/A1H] [LEDATA] [Logical Enumerated Data Record] [A2H/A3H] [LIDATA] [Logical Iterated Data Record] A4H LIBHED Library Header Record This record is the first record in a library file. It immediately precedes the modules (if any) in the library. Following the modules are three more records in the following order: LIBNAM, LIBLOC, and LIBDIC. This record type is ignored by Microsoft LINK. A6H LIBNAM Library Module Names Record This record lists the names of all the modules in the library. The names are listed in the same sequence as the modules appear in the library. This record type is ignored by Microsoft LINK. A8H LIBLOC Library Module Locations Record This record provides the relative location, within the library file, of the first byte of the first record (either a THEADR or LHEADR or RHEADR record) of each module in the library. The order of the locations corresponds to the order of the modules in the library. This record type is ignored by Microsoft LINK. AAH LIBDIC Library Dictionary Record This record gives all the names of public symbols within the library. The public names are separated into groups; all names in the nth group are defined in the nth module of the library. This record type is ignored by Microsoft LINK. [B0H] [COMDEF] [Communal Names Definition Record] [B2H/B3H] [BAKPAT] [Backpatch Record] [B4H] [LEXTDEF] [Local External Names Definition Record] [B6H/B7H] [LPUBDEF] [Local Public Names Definition Record] [B8H] [LCOMDEF] [Local Communal Names Definition Record] BAH/BBH COMFIX Communal Fixup Record Microsoft doesn't support this never- implemented IBM extension. This record type generates an error when it is encountered by Microsoft LINK. BCH CEXTDEF COMDAT External Names Definition Record C0H SELDEF Selector Definition Record Microsoft doesn't support this never- implemented IBM extension. This record type generates an error when it is encountered by Microsoft LINK. [C2H/C3] [COMDAT] [Initialized Communal Data Record] [C4H/C5H] [LINSYM] [Symbol Line Numbers Record] [C6H] [ALIAS] [Alias Definition Record] [C8H/C9H] [NBKPAT] [Named Backpatch Record] [CAH] [LLNAMES] [Local Logical Names Definition Record] [F0H] [Library Header Record] Although this is not actually an OMF record type, the presence of a record with F0H as the first byte indicates that the module is a Microsoft library. The format of a library file is given in Appendix 2. [F1H] [Library End Record] 80H THEADR--TRANSLATOR HEADER RECORD The THEADR record contains the name of the object module. This name identifies an object module within an object library or in messages produced by the linker. OFFSET Count TYPE Description 0000h 1 byte ID=80h 0001h 1 byte Record length ="LEN" 0002h "LEN" char Name 0002h 1 byte Checksum +"LEN" 82H LHEADR--LIBRARY MODULE HEADER RECORD This record is very similar to the THEADR record. It is used to indicate the name of a module within a library file (which has an internal organization different from that of an object module). This record type was defined in the original Intel specification with the same format but with a different purpose, so its use for libraries should be considered a Microsoft extension. OFFSET Count TYPE Description 0000h 1 byte ID=82h 0001h 1 byte Record length ="LEN" 0002h "LEN" char Name 0002h 1 byte Checksum +"LEN" EXTENSION:OBJ,OBP,OBW,LIB OCCURENCES:PC PROGRAMS:MS Link, TLink, OBJDUMP REFERENCE:**** --------H-OS/2 HELP------------------------- The OS/2 help files are different from the WinHelp help files,since the WinHelp format is proprietary to MicroSoft because of the patented LZ-packing they implemented. OFFSET Count TYPE Description 0000h 3 char ID='HSP' 0003h 1 byte Flags : 0 - INF style file 1-3 - unknown 4 - HLP style file Patching this file allows reading HLP files using the VIEW command, while HLP files seem to work with INF settings as well. 0005h 1 word Total size of header 0007h 1 word Unknown ????h other data 0047h ? char ASCIIZ name of the HLP/INF file EXTENSION:HLP,INF OCCURENCES:OS/2 REFERENCE:INF02A.DOC SEE ALSO:WinHelp HLP --------X-PARADOX DATAFILES-?--------------- The data files for the paradox database engine have the following format : OFFSET Count TYPE Description 0000h 1 byte Number of bytes per record 0001h 32 byte ???? 0021h 1 byte Number of fields per record 0022h 1 byte ?Password protected? / other flags ? - if password protected, 32 more bytes seem to be inserted. 0023h ?? byte ????? 0058h ? rec 1 byte Field type ? 1 - character field 5 - currency? 6 - integer 1 byte Field length After that, my information becomes really blurry :-I There seems to follow the name of the file, and some 0-filled areas, and after that the "first ASCII character after 0C0h" is said to be the start of the field names. Each field name is in ASCIZ. The actual records start after the field names, either at the 4th byte after 00h 02h (the sequence ending the field names section) or after 00h 02h 00h 00h 00h. EXTENSION:??? OCCURENCES:PC PROGRAMS:Paradox engine SEE ALSO: --------I-PBM-G----------------------------- The PBM files are image files, which were used at least by DMGraph, an utility to insert new graphics into a DOOM WAD file. The image dimensions seem to be stored in ASCII format delimited with CR/LF, after that follows the raw binary image data. OFFSET Count TYPE Description 0000h 1 char ID='P' 0001h 1 char Bitmap type : '1' - PBM bitmap '2' - PGM greymap '3' - PPM pixmap '4' - PBM raw bitmap '5' - PGM raw greymap '6' - PPM raw pixmap EXTENSION:PBM,PGM,PPM OCCURENCES:PC PROGRAMS:DMGraph.EXE --------I-PCX------------------------------- The PCX files are created by the programs of the ZSoft Paintbrush family and the FRIEZE package by the same manufacturer. A PCX file contains only one image, the data for this image and possibly palette information for this image. The encoding scheme used for PCX encoding is a simple RLE mechanism, see ALGRTHMS.txt for further information. A PCX image is stored from the upper scan line to the lower scan line. The size of a decoded scan line is always an even number, thus one additional byte should always be allocated for the decoding buffer. The header has a fixed size of 128 bytes and looks like this : OFFSET Count TYPE Description 0000h 1 byte Manufacturer. 10=ZSoft 0001h 1 byte Version information 0=PC Paintbrush v2.5 2=PC Paintbrush v2.8 w palette information 3=PC Paintbrush v2.8 w/o palette information 4=PC Paintbrush/Windows 5=PC Paintbrush v3.0+ 0002h 1 byte Encoding scheme, 1 = RLE, none other known 0003h 1 byte Bits per pixel 0004h 1 word left margin of image 0006h 1 word upper margin of image 0008h 1 word right margin of image 000Ah 1 word lower margin of image 000Ch 1 word Horizontal DPI resolution 000Eh 1 word Vertical DPI resolution 0010h 48 byte Color palette setting for 16-color images 16 RGB triplets 0040h 1 byte reserved 0041h 1 byte Number of color planes ="NCP" 0042h 1 word Number of bytes per scanline (always even, use instead of right margin-left margin). ="NBS" 0044h 1 word Palette information 1=color/bw palette 2=grayscale image 0046h 1 word Horizontal screen size 0048h 1 word Vertical screen size 004Ah 54 byte reserved, set to 0 The space needed to decode a single scan line is "NCP"*"NBS" bytes, the last byte may be a junk byte which is not displayed. After the image data, if the version number is 5 (or greater?) there possibly is a VGA color palette. The color ranges from 0 to 255, 0 is zero intensity, 255 is full intensity. The palette has the following format : OFFSET Count TYPE Description 0000h 1 byte VGA palette ID (=0Ch) 0001h 768 byte RGB triplets with palette information EXTENSION:PCX OCCURENCES:PC PROGRAMS:PC Paintbrush SEE ALSO: --------I-PIC------------------------------- PIC files contain images in an uncompressed format. Both the original Animator and Animator Pro from Autodesk produce PIC files. The file formats are different; Animator Pro produces a hierarchial block oriented file, while the original Animator file is a simpler fixed format. See PIC(Pro) for further information on the Animator Pro PIC format. The original Animator uses this format to store a single-frame picture image. This format description applies to both PIC and original Animator CEL files. The file begins with a 32 byte header, as follows: OFFSET Count TYPE Description 0000h 1 word ID=9119h 0002h 1 word Width of image; PIC files have always a width of 320, CEL images may have any value. 0004h 1 word Height of image, 200 for a PIC, any value for a CEL file. 0006h 1 word X offset of image, always 0 for a PIC image, may be nonzero in a CEL image. 0008h 1 word Y offset of image. Zero for a PIC file. 000Ah 1 byte Bits per pixel (8) 000Bh 1 byte Compresion flag, always zero 000Ch 1 dword Size of the image data in bytes 0010h 16 byte reserved(0) Immediately following the header is the color map. It contains all 256 palette entries in rgb order. Each of the r, g, and b components is a single byte in the range of 0-63. Following the color palette is the image data, one byte per pixel, from left to right, top to bottom. EXTENSION:PIC,CEL OCCURENCES:PC PROGRAMS:Autodesk Animator SEE ALSO:CEL,FLIc,PIC(PRO) --------I-PIC(PRO)-------------------------- This format description applies to both PIC and MSK files created with the Autodesk Animator Pro package. The file begins with a 64-byte header defined as follows: Offset Length Name Description 0000h 1 dword The size of the whole file including the size of this header. 0004h 1 word ID=9500h 0006h 1 word Width of the image 0008h 1 word Height of the image 000Ah 1 word X offset of image 000Ch 1 word Y offset of image 000Eh 1 dword User ID, set to zero 0012h 1 byte Bits per pixel (8 for PIC, 1 for MSK) 0013h 45 byte reserved (0) Following the file header are the data blocks for the image. Each data block within a PIC or MSK file is formatted as follows: OFFSET Count TYPE Description 0000h 1 dword The size of the block, including this header. 0004h 1 word Data type ID : 0 - Color palette info 1 - Byte-per-pixel image data 2 - Bit-per-pixel mask data 0006h ? byte Data The type values in the block headers indicate what type of graphics data the block contains. In a PIC_CMAP block, the first 2-byte word is a version code; currently this is set to zero. Following the version word are all 256 palette entries in rgb order. Each of the r, g, and b components is a single byte in the range of 0-255. This type of block appears in PIC files; there will generally be no color map block in a MSK file. In a PIC_BYTEPIXELS block, the image data appears immediately following the 6-byte block header. The data is stored as one byte per pixel, in left-to-right, topD to-bottom sequence. In a PIC_BITPIXELS block, the bitmap data appears immediately following the 6-byte block header. The data is stored as bits packed into bytes such that the leftmost bits appear in the high-order positions of each byte. The bits are stored in left-to-right, top-to bottom sequence. When the width of the bitmap is not a multiple of 8, there will be unused bits in the low order positions of the last byte on each line. The number of bytes per line is ((width+7)/8). This type of block appears in MSK files. EXTENSION:PIC,MSK OCCURENCES:PC PROGRAMS:Autodesk Animator Pro REFERENCE: SEE ALSO:PIC,FLT --------E-PIF------------------------------- The Program Information Files have stayed a long time with the PC. They origi- nated from IBMs Topview, were carried on by DoubleView and DesqView, and today they are used by Windows and Windows NT. The PIF files store additional information about executables that are foreign to the running multitasking system such as ressource usage, keyboard and mouse virtualization and hotkeys. The original (Topview) PIF had a size of 171h bytes, after that, there come the various extensions for the different operating environments. The different extensions are discussed in their own sections. OFFSET Count TYPE Description 0000h 1 byte reserved 0001h 1 byte Checksum 0002h 30 char Title for the window 0020h 1 word Maximum memory reserved for program 0022h 1 word Minimum memory reserved for program 0024h 63 char Path and filename of the program 0063h 1 byte 0 - Do not close window on exit other - Close window on exit 0064h 1 byte Default drive (0=A: ??) 0065h 64 char Default startup directory 00A5h 64 char Parameters for program 00E5h 1 byte Initial screen mode, 0 equals mode 3 ? 00E6h 1 byte Text pages to reserve for program 00E7h 1 byte First interrupt used by program 00E8h 1 byte Last interrupt used by program 00E9h 1 byte Rows on screen 00EAh 1 byte Columns on screen 00EBh 1 byte X position of window 00ECh 1 byte Y position of window 00EDh 1 word System memory ?? whatever 00EFh 64 char ?? Shared program path 012Fh 64 char ?? Shared program data file 016Fh 1 word Program flags EXTENSION:PIF,DVP OCCURENCES:PC PROGRAMS:Topview, DesqView, Windows REFERENCE:see DDJ #202, July 1993, QuarterDeck SDK SEE ALSO:Windows PIF, Windows NT PIF VALIDATION: --------I-PLY------------------------------- The PoLYgon files created by the Autodesk Animator packages contain a set of points that describe a polygon. OFFSET Count TYPE Description 0000h 1 word Number of points in the file 0002h 1 dword reserved (0) 0006h 1 byte Closed shape flag. If nonzero there is an implied connection between the last and the first point. If it is zero, the shape is open. 0007h 1 byte ID=99h After the header, there follows the point data, organized in records like this : OFFSET Count TYPE Description 0000h 1 word X coordinate 0002h 1 word Y coordinate 0006h 1 word Z coordinate, always zero EXTENSION:PLY OCCURENCES:PC PROGRAMS:Autodesk Animator --------I-PNG-M----------------------------- "excerpted from the PNG (Portable Network Graphics) specification, tenth draft." The PNG format (pronounced PiNG) was the replacement the Internet found, after the GIF format/CompuServe/LZW compression-patent stuff. PNG is a lossless image- compression format, which allows a large range of applications. The PNG format is in the public domain, the latest versions of the standard and related information can always be found at the PNG FTP archive site, ftp.uu.net:/graphics/png/. The maintainers of the PNG specification can be contacted by e-mail at [email protected]. The PNG format uses Motorola byte order, scanlines always begin on byte boundaries. When pixels are less than 8 bits deep, if the scanline width is not evenly divisible by the number of pixels per byte then the low-order bits in the last byte of each scanline are wasted. The contents of the padding bits added to fill out the last byte of a scanline are unspecified. An additional "filter" byte is added to the beginning of every scanline, as described in detail below. The filter byte is not considered part of the image data, but it is included in the data stream sent to the compression step. PNG allows the image data to be filtered before it is compressed. The purpose of filtering is to improve the compressibility of the data. The filter step itself does not reduce the size of the data. All PNG filters are strictly lossless. PNG defines several different filter algorithms, including "none" which indicates no filtering. The filter algorithm is specified for each scanline by a filter type byte which precedes the filtered scanline in the precompression data stream. An intelligent encoder may switch filters from one scanline to the next. The method for choosing which filter to employ is up to the encoder. A PNG image can be stored in interlaced order to allow progressive display. The purpose of this feature is to allow images to "fade in" when they are being displayed on-the-fly. Interlacing slightly expands the file size on average, but it gives the user a meaningful display much more rapidly. Note that decoders are required to be able to read interlaced images, whether or not they actually perform progressive display. With interlace type 0, pixels are stored sequentially from left to right, and scanlines sequentially from top to bottom (no interlacing). Interlace type 1, known as Adam7 after its author, Adam M. Costello, consists of seven distinct passes over the image. Each pass transmits a subset of the pixels in the image. The pass in which each pixel is transmitted is defined by replicating the following 8-by-8 pattern over the entire image, starting at the upper left corner: 1 6 4 6 2 6 4 6 7 7 7 7 7 7 7 7 5 6 5 6 5 6 5 6 7 7 7 7 7 7 7 7 3 6 4 6 3 6 4 6 7 7 7 7 7 7 7 7 5 6 5 6 5 6 5 6 7 7 7 7 7 7 7 7 Within each pass, the selected pixels are transmitted left to right within a scanline, and selected scanlines sequentially from top to bottom. For example, pass 2 contains pixels 4, 12, 20, etc. of scanlines 0, 8, 16, etc. (numbering from 0,0 at the upper left corner). The last pass contains the entirety of scanlines 1, 3, 5, etc. The data within each pass is laid out as though it were a complete image of the appropriate dimensions. For example, if the complete image is 8x8 pixels, then pass 3 will contain a single scanline containing two pixels. When pixels are less than 8 bits deep, each such scanline is padded to fill an integral number of bytes (see Image layout). Filtering is done on this reduced image in the usual way, and a filter type byte is transmitted before each of its scanlines (see Filter Algorithms). Notice that the transmission order is defined so that all the scanlines transmitted in a pass will have the same number of pixels; this is necessary for proper application of some of the filters. Caution: If the image contains fewer than five columns or fewer than five rows, some passes will be entirely empty. Encoder and decoder authors must be careful to handle this case correctly. In particular, filter bytes are only associated with nonempty scanlines; no filter bytes are present in an empty pass. A PNG file consists of a PNG signature followed by a series of chunks. This chapter defines the signature and the basic properties of chunks. Individual chunk types are discussed in the next chapter. PNG Header OFFSET Count TYPE Description 0000h 8 char ID=89h,'PNG',13,10,26,10 Chunk layout OFFSET Count TYPE Description 0000h 1 dword Number of data bytes after this header. 0004h 4 char Chunk type. A 4-byte chunk type code. For convenience in description and in examining PNG files, type codes are restricted to consist of uppercase and lowercase ASCII letters (A-Z, a-z). However, encoders and decoders should treat the codes as fixed binary values, not character strings. For example, it would not be correct to represent the type code IDAT by the EBCDIC equivalents of those letters. ????h ? byte Data ????h 1 dword CRC calculated on the preceding bytes in that chunk, including the chunk type code and chunk data fields, but not including the length field. The CRC is always present, even for empty chunks such as IEND. The CRC algorithm is specified below. Chunk naming conventions ======================== Chunk type codes are assigned in such a way that a decoder can determine some properties of a chunk even if it does not recognize the type code. These rules are intended to allow safe, flexible extension of the PNG format, by allowing a decoder to decide what to do when it encounters an unknown chunk. The naming rules are not normally of interest when a decoder does recognize the chunk's type. Four bits of the type code, namely bit 5 (value 32) of each byte, are used to convey chunk properties. This choice means that a human can read off the assigned properties according to whether each letter of the type code is uppercase (bit 5 is 0) or lowercase (bit 5 is 1). However, decoders should test the properties of an unknown chunk by numerically testing the specified bits; testing whether a character is uppercase or lowercase is inefficient, and even incorrect if a locale-specific case definition is used. It is also worth noting that the property bits are an inherent part of the chunk name, and hence are fixed for any chunk type. Thus, TEXT and Text are completely unrelated chunk type codes. Decoders should recognize codes by simple four-byte literal comparison; it is incorrect to perform case conversion on type codes. The semantics of the property bits are: First Byte: 0 (uppercase) = critical, 1 (lowercase) = ancillary Chunks which are not strictly necessary in order to meaningfully display the contents of the file are known as "ancillary" chunks. Decoders encountering an unknown chunk in which the ancillary bit is 1 may safely ignore the chunk and proceed to display the image. The time chunk (tIME) is an example of an ancillary chunk. Chunks which are critical to the successful display of the file's contents are called "critical" chunks. Decoders encountering an unknown chunk in which the ancillary bit is 0 must indicate to the user that the image contains information they cannot safely interpret. The image header chunk (IHDR) is an example of a critical chunk. Second Byte: 0 (uppercase) = public, 1 (lowercase) = private If the chunk is public (part of this specification or a later edition of this specification), its second letter is uppercase. If your application requires proprietary chunks, and you have no interest in seeing the software of other vendors recognize them, use a lowercase second letter in the chunk name. Such names will never be assigned in the official specification. Note that there is no need for software to test this property bit; it simply ensures that private and public chunk names will not conflict. Third Byte: reserved, must be 0 (uppercase) always The significance of the case of the third letter of the chunk name is reserved for possible future expansion. At the present time all chunk names must have uppercase third letters. Fourth Byte: 0 (uppercase) = unsafe to copy, 1 (lowercase) = safe to copy This property bit is not of interest to pure decoders, but it is needed by PNG editors (programs that modify a PNG file). If a chunk's safe-to-copy bit is 1, the chunk may be copied to a modified PNG file whether or not the software recognizes the chunk type, and regardless of the extent of the file modifications. If a chunk's safe-to-copy bit is 0, it indicates that the chunk depends on the image data. If the program has made any changes to critical chunks, including addition, modification, deletion, or reordering of critical chunks, then unrecognized unsafe chunks must not be copied to the output PNG file. (Of course, if the program does recognize the chunk, it may choose to output an appropriately modified version.) A PNG editor is always allowed to copy all unrecognized chunks if it has only added, deleted, or modified ancillary chunks. This implies that it is not permissible to make ancillary chunks that depend on other ancillary chunks. PNG editors that do not recognize a critical chunk must report an error and refuse to process that PNG file at all. The safe/unsafe mechanism is intended for use with ancillary chunks. The safe-to-copy bit will always be 0 for critical chunks. For example, the hypothetical chunk type name "bLOb" has the property bits: bLOb <-- 32 bit Chunk Name represented in ASCII form |||| |||'- Safe to copy bit is 1 (lower case letter; bit 5 of byte is 1) ||'-- Reserved bit is 0 (upper case letter; bit 5 of byte is 0) |'--- Private bit is 0 (upper case letter; bit 5 of byte is 0) '---- Ancillary bit is 1 (lower case letter; bit 5 of byte is 1) Therefore, this name represents an ancillary, public, safe-to-copy chunk. See Rationale: Chunk naming conventions. CRC algorithm ============= Chunk CRCs are calculated using standard CRC methods with pre and post conditioning. The CRC polynomial employed is as follows: x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1 The 32-bit CRC register is initialized to all 1's, and then the data from each byte is processed from the least significant bit (1) to the most significant bit (128). After all the data bytes are processed, the CRC register is inverted (its ones complement is taken). This value is transmitted (stored in the file) MSB first. For the purpose of separating into bytes and ordering, the least significant bit of the 32-bit CRC is defined to be the coefficient of the x^31 term. Practical calculation of the CRC always employs a precalculated table to greatly accelerate the computation. See Appendix: Sample CRC Code. 4. Chunk Specifications ======================= This chapter defines the standard types of PNG chunks. Critical Chunks =============== All implementations must understand and successfully render the standard critical chunks. A valid PNG image must contain an IHDR chunk, one or more IDAT chunks, and an IEND chunk. IHDR Image Header This chunk must appear FIRST. Its contents are: Width: 4 bytes Height: 4 bytes Bit depth: 1 byte Color type: 1 byte Compression type: 1 byte Filter type: 1 byte Interlace type: 1 byte Width and height give the image dimensions in pixels. They are 4-byte integers. Zero is an invalid value. The maximum for each is (2^31)-1 in order to accommodate languages which have difficulty with unsigned 4-byte values. Bit depth is a single-byte integer giving the number of bits per pixel (for palette images) or per sample (for grayscale and truecolor images). Valid values are 1, 2, 4, 8, and 16, although not all values are allowed for all color types. Color type is a single-byte integer that describes the interpretation of the image data. Color type values represent sums of the following values: 1 (palette used), 2 (color used), and 4 (full alpha used). Valid values are 0, 2, 3, 4, and 6. Bit depth restrictions for each color type are imposed both to simplify implementations and to prohibit certain combinations that do not compress well in practice. Decoders must support all legal combinations of bit depth and color type. (Note that bit depths of 16 are easily supported on 8-bit display hardware by dropping the least significant byte.) The allowed combinations are: Color Allowed Interpretation Type Bit Depths 0 1,2,4,8,16 Each pixel value is a grayscale level. 2 8,16 Each pixel value is an R,G,B series. 3 1,2,4,8 Each pixel value is a palette index; a PLTE chunk must appear. 4 8,16 Each pixel value is a grayscale level, followed by an alpha channel level. 6 8,16 Each pixel value is an R,G,B series, followed by an alpha channel level. Compression type is a single-byte integer that indicates the method used to compress the image data. At present, only compression type 0 (deflate/inflate compression with a 32K sliding window) is defined. All standard PNG images must be compressed with this scheme. The compression type code is provided for possible future expansion or proprietary variants. Decoders must check this byte and report an error if it holds an unrecognized code. See Deflate/Inflate Compression for details. Filter type is a single-byte integer that indicates the preprocessing method applied to the image data before compression. At present, only filter type 0 (adaptive filtering with five basic filter types) is defined. As with the compression type code, decoders must check this byte and report an error if it holds an unrecognized code. See Filter Algorithms for details. Interlace type is a single-byte integer that indicates the transmission order of the pixel data. Two values are currently defined: 0 (no interlace) or 1 (Adam7 interlace). See Interlaced data order for details. PLTE Palette This chunk's contents are from 1 to 256 palette entries, each a three-byte series of the form: red: 1 byte (0 = black, 255 = red) green: 1 byte (0 = black, 255 = green) blue: 1 byte (0 = black, 255 = blue) The number of entries is determined from the chunk length. A chunk length not divisible by 3 is an error. This chunk must appear for color type 3, and may appear for color types 2 and 6. If this chunk does appear, it must precede the first IDAT chunk. There cannot be more than one PLTE chunk. For color type 3 (palette data), the PLTE chunk is required. The first entry in PLTE is referenced by pixel value 0, the second by pixel value 1, etc. The number of palette entries must not exceed the range that can be represented by the bit depth (for example, 2^4 = 16 for a bit depth of 4). It is permissible to have fewer entries than the bit depth would allow. In that case, any out-of-range pixel value found in the image data is an error. For color types 2 and 6 (truecolor), the PLTE chunk is optional. If present, it provides a recommended set of from 1 to 256 colors to which the truecolor image may be quantized if the viewer cannot display truecolor directly. If PLTE is not present, such a viewer must select colors on its own, but it is often preferable for this to be done once by the encoder. Note that the palette uses 8 bits (1 byte) per value regardless of the image bit depth specification. In particular, the palette is 8 bits deep even when it is a suggested quantization of a 16-bit truecolor image. IDAT Image Data This chunk contains the actual image data. To create this data, begin with image scanlines represented as described under Image layout; the layout and total size of this raw data are determinable from the IHDR fields. Then filter the image data according to the filtering method specified by the IHDR chunk. (Note that with filter method 0, the only one currently defined, this implies prepending a filter type byte to each scanline.) Finally, compress the filtered data using the compression method specified by the IHDR chunk. The IDAT chunk contains the output datastream of the compression algorithm. To read the image data, reverse this process. There may be multiple IDAT chunks; if so, they must appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of all the IDAT chunks. The encoder may divide the compressed data stream into IDAT chunks as it wishes. (Multiple IDAT chunks are allowed so that encoders can work in a fixed amount of memory; typically the chunk size will correspond to the encoder's buffer size.) It is important to emphasize that IDAT chunk boundaries have no semantic significance and can appear at any point in the compressed datastream. A PNG file in which each IDAT chunk contains only one data byte is legal, though remarkably wasteful of space. (For that matter, zero-length IDAT chunks are legal, though even more wasteful.) See Filter Algorithms and Deflate/Inflate Compression for details. IEND Image Trailer This chunk must appear LAST. It marks the end of the PNG data stream. The chunk's data field is empty. Ancillary Chunks ================ All ancillary chunks are optional, in the sense that encoders need not write them and decoders may ignore them. However, encoders are encouraged to write the standard ancillary chunks when the information is available, and decoders are encouraged to interpret these chunks when appropriate and feasible. The standard ancillary chunks are listed in alphabetical order. This is not necessarily the order in which they would appear in a file. bKGD Background Color This chunk specifies a default background color against which the image may be presented. Note that viewers are not bound to honor this chunk; a viewer may choose to use a different background color. For color type 3 (palette), the bKGD chunk contains: palette index: 1 byte The value is the palette index of the color to be used as background. For color types 0 and 4 (grayscale, with or without alpha), bKGD contains: gray: 2 bytes, range 0 .. (2^bitdepth) - 1 (For consistency, 2 bytes are used regardless of the image bit depth.) The value is the gray level to be used as background. For color types 2 and 6 (RGB, with or without alpha), bKGD contains: red: 2 bytes, range 0 .. (2^bitdepth) - 1 green: 2 bytes, range 0 .. (2^bitdepth) - 1 blue: 2 bytes, range 0 .. (2^bitdepth) - 1 (For consistency, 2 bytes per sample are used regardless of the image bit depth.) This is the RGB color to be used as background. When present, the bKGD chunk must precede the first IDAT chunk, and must follow the PLTE chunk, if any. See Recommendations for Decoders: Background color. cHRM Primary Chromaticities and White Point Applications that need precise specification of colors in a PNG file may use this chunk to specify the chromaticities of the red, green, and blue primaries used in the image, and the referenced white point. These values are based on the 1931 CIE (International Color Committee) XYZ color space. Only the chromaticities (x and y) are specified. The chunk layout is: White Point x: 4 bytes White Point y: 4 bytes Red x: 4 bytes Red y: 4 bytes Green x: 4 bytes Green y: 4 bytes Blue x: 4 bytes Blue y: 4 bytes Each value is encoded as a 4-byte unsigned integer, representing the x or y value times 100000. If the cHRM chunk appears, it must precede the first IDAT chunk, and it must also precede the PLTE chunk if present. gAMA Gamma Correction The gamma correction chunk specifies the gamma of the camera (or simulated camera) that produced the image, and thus the gamma of the image with respect to the original scene. Note that this is not the same as the gamma of the display device that will reproduce the image correctly. The chunk's contents are: Image gamma value: 4 bytes A value of 100000 represents a gamma of 1.0, a value of 45000 a gamma of 0.45, and so on (divide by 100000.0). Values around 1.0 and around 0.45 are common in practice. If the encoder does not know the gamma value, it should not write a gamma chunk; the absence of a gamma chunk indicates the gamma is unknown. If the gAMA chunk appears, it must precede the first IDAT chunk, and it must also precede the PLTE chunk if present. See Gamma correction, Recommendations for Encoders: Encoder gamma handling, and Recommendations for Decoders: Decoder gamma handling. hIST Image Histogram The histogram chunk gives the approximate usage frequency of each color in the color palette. A histogram chunk may appear only when a palette chunk appears. If a viewer is unable to provide all the colors listed in the palette, the histogram may help it decide how to choose a subset of the colors for display. This chunk's contents are a series of 2-byte (16 bit) unsigned integers. There must be exactly one entry for each entry in the PLTE chunk. Each entry is proportional to the fraction of pixels in the image that have that palette index; the exact scale factor is chosen by the encoder. Histogram entries are approximate, with the exception that a zero entry specifies that the corresponding palette entry is not used at all in the image. It is required that a histogram entry be nonzero if there are any pixels of that color. When the palette is a suggested quantization of a truecolor image, the histogram is necessarily approximate, since a decoder may map pixels to palette entries differently than the encoder did. In this situation, zero entries should not appear. The hIST chunk, if it appears, must follow the PLTE chunk, and must precede the first IDAT chunk. See Rationale: Palette histograms, and Recommendations for Decoders: Palette histogram usage. pHYs Physical Pixel Dimensions This chunk specifies the intended resolution for display of the image. The chunk's contents are: 4 bytes: pixels per unit, X axis (unsigned integer) 4 bytes: pixels per unit, Y axis (unsigned integer) 1 byte: unit specifier The following values are legal for the unit specifier: 0: unit is unknown (pHYs defines pixel aspect ratio only) 1: unit is the meter Conversion note: one inch is equal to exactly 0.0254 meters. If this ancillary chunk is not present, pixels are assumed to be square, and the physical size of each pixel is unknown. If present, this chunk must precede the first IDAT chunk. See Recommendations for Decoders: Pixel dimensions. sBIT Significant Bits To simplify decoders, PNG specifies that only certain bit depth values be used, and further specifies that pixel values must be scaled to the full range of possible values at that bit depth. However, the sBIT chunk is provided in order to store the original number of significant bits, since this information may be of use to some decoders. We recommend that an encoder emit an sBIT chunk if it has converted the data from a different bit depth. For color type 0 (grayscale), the sBIT chunk contains a single byte, indicating the number of bits which were significant in the source data. For color type 2 (RGB truecolor), the sBIT chunk contains three bytes, indicating the number of bits which were significant in the source data for the red, green, and blue channels, respectively. For color type 3 (palette color), the sBIT chunk contains three bytes, indicating the number of bits which were significant in the source data for the red, green, and blue components of the palette entries, respectively. For color type 4 (grayscale with alpha channel), the sBIT chunk contains two bytes, indicating the number of bits which were significant in the source grayscale data and the source alpha channel data, respectively. For color type 6 (RGB truecolor with alpha channel), the sBIT chunk contains four bytes, indicating the number of bits which were significant in the source data for the red, green, blue and alpha channels, respectively. Note that sBIT does not have any implications for the interpretation of the stored image: the bit depth indicated by IHDR is the correct depth. sBIT is only an indication of the history of the image. However, an sBIT chunk showing a bit depth less than the IHDR bit depth does mean that not all possible color values occur in the image; this fact may be of use to some decoders. If the sBIT chunk appears, it must precede the first IDAT chunk, and it must also precede the PLTE chunk if present. tEXt Textual Data Any textual information that the encoder wishes to record with the image is stored in tEXt chunks. Each tEXt chunk contains a keyword and a text string, in the format: Keyword: n bytes (character string) Null separator: 1 byte Text: n bytes (character string) The keyword and text string are separated by a zero byte (null character). Neither the keyword nor the text string may contain a null character. Note that the text string is not null-terminated (the length of the chunk is sufficient information to locate the ending). The keyword must be at least one character and less than 80 characters long. The text string may be of any length from zero bytes up to the maximum permissible chunk size. Any number of tEXt chunks may appear, and more than one with the same keyword is permissible. The keyword indicates the type of information represented by the text string. The following keywords are predefined and should be used where appropriate: Title Short (one line) title or caption for image Author Name of image's creator Copyright Copyright notice Description Description of image (possibly long) Software Software used to create the image Disclaimer Legal disclaimer Warning Warning of nature of content Source Device used to create the image Comment Miscellaneous comment; conversion from GIF comment Other keywords, containing any sequence of printable characters in the character set, may be invented for other purposes. Keywords of general interest may be registered with the maintainers of the PNG specification. Keywords must be spelled exactly as registered, so that decoders may use simple literal comparisons when looking for particular keywords. In particular, keywords are considered case-sensitive. Both keyword and text are interpreted according to the ISO 8859-1 (Latin-1) character set. Newlines in the text string should be represented by a single linefeed character (decimal 10); use of other ASCII control characters is discouraged. See Recommendations for Encoders: Text chunk processing and Recommendations for Decoders: Text chunk processing. tIME Image Last-Modification Time This chunk gives the time of the last image modification (not the time of initial image creation). The chunk contents are: 2 bytes: Year (complete; for example, 1995, not 95) 1 byte: Month (1-12) 1 byte: Day (1-31) 1 byte: Hour (0-23) 1 byte: Minute (0-59) 1 byte: Second (0-60) (yes, 60, for leap seconds; not 61, a common error) Universal Time (UTC, also called GMT) should be specified rather than local time. tRNS Transparency Transparency is an alternative to the full alpha channel. Although transparency is not as elegant as the full alpha channel, it requires less storage space and is sufficient for many common cases. For color type 3 (palette), this chunk's contents are a series of alpha channel bytes, corresponding to entries in the PLTE chunk: Alpha for palette index 0: 1 byte Alpha for palette index 1: 1 byte etc. Each entry indicates that pixels of that palette index should be treated as having the specified alpha value. Alpha values have the same interpretation as in an 8-bit full alpha channel: 0 is fully transparent, 255 is fully opaque, regardless of image bit depth. The tRNS chunk may contain fewer alpha channel bytes than there are palette entries. In this case, the alpha channel value for all remaining palette entries is assumed to be 255. In the common case where only palette index 0 need be made transparent, only a one-byte tRNS chunk is needed. The tRNS chunk may not contain more bytes than there are palette entries. For color type 0 (grayscale), the tRNS chunk contains a single gray level value, stored in the format gray: 2 bytes, range 0 .. (2^bitdepth) - 1 (For consistency, 2 bytes are used regardless of the image bit depth.) Pixels of the specified gray level are to be treated as transparent (equivalent to alpha value 0); all other pixels are to be treated as fully opaque (alpha value (2^bitdepth)-1). For color type 2 (RGB), the tRNS chunk contains a single RGB color value, stored in the format red: 2 bytes, range 0 .. (2^bitdepth) - 1 green: 2 bytes, range 0 .. (2^bitdepth) - 1 blue: 2 bytes, range 0 .. (2^bitdepth) - 1 (For consistency, 2 bytes per sample are used regardless of the image bit depth.) Pixels of the specified color value are to be treated as transparent (equivalent to alpha value 0); all other pixels are to be treated as fully opaque (alpha value (2^bitdepth)-1). tRNS is prohibited for color types 4 and 6, since a full alpha channel is already present in those cases. Note: when dealing with 16-bit grayscale or RGB data, it is important to compare both bytes of the sample values to determine whether a pixel is transparent. Although decoders may drop the low-order byte of the samples for display, this must not occur until after the data has been tested for transparency. For example, if the grayscale level 0x0001 is specified to be transparent, it would be incorrect to compare only the high-order byte and decide that 0x0002 is also transparent. When present, the tRNS chunk must precede the first IDAT chunk, and must follow the PLTE chunk, if any. zTXt Compressed Textual Data A zTXt chunk contains textual data, just as tEXt does; however, zTXt takes advantage of compression. A zTXt chunk begins with an uncompressed Latin-1 keyword followed by a null (0) character, just as in the tEXt chunk. The next byte after the null contains a compression type byte, for which the only presently legitimate value is zero (deflate/inflate compression). The compression-type byte is followed by a compressed data stream which makes up the remainder of the chunk. Decompression of this data stream yields Latin-1 text which is equivalent to the text stored in a tEXt chunk. Any number of zTXt and tEXt chunks may appear in the same file. See the preceding definition of the tEXt chunk for the predefined keywords and the exact format of the text. See Deflate/Inflate Compression, Recommendations for Encoders: Text chunk processing, and Recommendations for Decoders: Text chunk processing. Summary of Standard Chunks ========================== This table summarizes some properties of the standard chunk types. Critical chunks (must appear in this order, except PLTE is optional): Name Multiple Ordering constraints OK? IHDR No Must be first PLTE No Before IDAT IDAT Yes Multiple IDATs must be consecutive IEND No Must be last Ancillary chunks (need not appear in this order): Name Multiple Ordering constraints OK? cHRM No Before PLTE and IDAT gAMA No Before PLTE and IDAT sBIT No Before PLTE and IDAT bKGD No After PLTE; before IDAT hIST No After PLTE; before IDAT tRNS No After PLTE; before IDAT pHYs No Before IDAT tIME No None tEXt Yes None zTXt Yes None Standard keywords for tEXt and zTXt chunks: Title Short (one line) title or caption for image Author Name of image's creator Copyright Copyright notice Description Description of image (possibly long) Software Software used to create the image Disclaimer Legal disclaimer Warning Warning of nature of content Source Device used to create the image Comment Miscellaneous comment; conversion from GIF comment Additional Chunk Types ====================== Additional public PNG chunk types are defined in the document "PNG Special-Purpose Public Chunks", available by FTP from ftp.uu.net:/graphics/png/ or via WWW from http://sunsite.unc.edu/boutell/pngextensions.html. 5. Deflate/Inflate Compression ============================== PNG compression type 0 (the only compression method presently defined for PNG) specifies deflate/inflate compression with a 32K window. Deflate compression is an LZ77 derivative used in zip, gzip, pkzip and related programs. Extensive research has been done supporting its patent-free status. Portable C implementations are freely available. Documentation and C code for deflate are available from the Info-Zip archives at ftp.uu.net:/pub/archiving/zip/. Deflate-compressed datastreams within PNG are stored in the "zlib" format, which has the structure: Compression method/flags code: 1 byte Additional flags/check bits: 1 byte Compressed data blocks: n bytes Checksum: 4 bytes Further details on this format may be found in the zlib specification. At this writing, the zlib specification is at draft 3.1, and is available from ftp.uu.net:/pub/archiving/zip/doc/zlib-3.1.doc. For PNG compression type 0, the zlib compression method/flags code must specify method code 8 ("deflate" compression) and an LZ77 window size of not more than 32K. The checksum stored at the end of the zlib datastream is calculated on the uncompressed data represented by the datastream. Note that the algorithm used is not the same as the CRC calculation used for PNG chunk checksums. Verifying the chunk CRCs provides adequate confidence that the PNG file has been transmitted undamaged. The zlib checksum is useful mainly as a crosscheck that the deflate and inflate algorithms are implemented correctly. In a PNG file, the concatenation of the contents of all the IDAT chunks makes up a zlib datastream as specified above. This datastream decompresses to filtered image data as described elsewhere in this document. It is important to emphasize that the boundaries between IDAT chunks are arbitrary and may fall anywhere in the zlib datastream. There is not necessarily any correlation between IDAT chunk boundaries and deflate block boundaries or any other feature of the zlib data. For example, it is entirely possible for the terminating zlib checksum to be split across IDAT chunks. PNG also uses zlib datastreams in zTXt chunks. In a zTXt chunk, the remainder of the chunk following the compression type code byte is a zlib datastream as specified above. This datastream decompresses to the user-readable text described by the chunk's keyword. Unlike the image data, such datastreams are not split across chunks; each zTXt chunk contains an independent zlib datastream. 6. Filter Algorithms ==================== This chapter describes the pixel filtering algorithms which may be applied in advance of compression. The purpose of these filters is to prepare the image data for optimum compression. PNG defines five basic filtering algorithms, which are given numeric codes as follows: Code Name 0 None 1 Sub 2 Up 3 Average 4 Paeth The encoder may choose which algorithm to apply on a scanline-by-scanline basis. In the image data sent to the compression step, each scanline is preceded by a filter type byte containing the numeric code of the filter algorithm used for that scanline. Filtering algorithms are applied to bytes, not to pixels, regardless of the bit depth or color type of the image. The filtering algorithms work on the byte sequence formed by a scanline that has been represented as described under Image layout. When the image is interlaced, each pass of the interlace pattern is treated as an independent image for filtering purposes. The filters work on the byte sequences formed by the pixels actually transmitted during a pass, and the "previous scanline" is the one previously transmitted in the same pass, not the one adjacent in the complete image. Note that the subimage transmitted in any one pass is always rectangular, but is of smaller width and/or height than the complete image. Filtering is not applied when this subimage is empty. For all filters, the bytes "to the left of" the first pixel in a scanline must be treated as being zero. For filters that refer to the prior scanline, the entire prior scanline must be treated as being zeroes for the first scanline of an image (or of a pass of an interlaced image). To reverse the effect of a filter, the decoder must use the decoded values of the prior pixel on the same line, the pixel immediately above the current pixel on the prior line, and the pixel just to the left of the pixel above. This implies that at least one scanline's worth of image data must be stored by the decoder at all times. Even though some filter types do not refer to the prior scanline, the decoder must always store each scanline as it is decoded, since the next scanline might use a filter that refers to it. PNG imposes no restriction on which filter types may be applied to an image. However, the filters are not equally effective on all types of data. See Recommendations for Encoders: Filter selection. Filter type 0: None =================== With the None filter, the scanline is transmitted unmodified; it is only necessary to insert a filter type byte before the data. Filter type 1: Sub ================== The Sub filter transmits the difference between each byte and the value of the corresponding byte of the prior pixel. To compute the Sub filter, apply the following formula to each byte of each scanline: Sub(x) = Raw(x) - Raw(x-bpp) where x ranges from zero to the number of bytes representing that scanline minus one, Raw(x) refers to the raw data byte at that byte position in the scanline, and bpp is defined as the number of bytes per complete pixel, rounding up to one. For example, for color type 2 with a bit depth of 16, bpp is equal to 6 (three channels, two bytes per channel); for color type 0 with a bit depth of 2, bpp is equal to 1 (rounding up); for color type 4 with a bit depth of 16, bpp is equal to 4 (two-byte grayscale value, plus two-byte alpha channel). Note this computation is done for each byte, regardless of bit depth. In a 16-bit image, MSBs are differenced from the preceding MSB and LSBs are differenced from the preceding LSB, because of the way that bpp is defined. Unsigned arithmetic modulo 256 is used, so that both the inputs and outputs fit into bytes. The sequence of Sub values is transmitted as the filtered scanline. For all x < 0, assume Raw(x) = 0. To reverse the effect of the Sub filter after decompression, output the following value: Sub(x) + Raw(x-bpp) (computed mod 256), where Raw refers to the bytes already decoded. Filter type 2: Up ================= The Up filter is just like the Sub filter except that the pixel immediately above the current pixel, rather than just to its left, is used as the predictor. To compute the Up filter, apply the following formula to each byte of each scanline: Up(x) = Raw(x) - Prior(x) where x ranges from zero to the number of bytes representing that scanline minus one, Raw(x) refers to the raw data byte at that byte position in the scanline, and Prior(x) refers to the unfiltered bytes of the prior scanline. Note this is done for each byte, regardless of bit depth. Unsigned arithmetic modulo 256 is used, so that both the inputs and outputs fit into bytes. The sequence of Up values is transmitted as the filtered scanline. On the first scanline of an image (or of a pass of an interlaced image), assume Prior(x) = 0 for all x. To reverse the effect of the Up filter after decompression, output the following value: Up(x) + Prior(x) (computed mod 256), where Prior refers to the decoded bytes of the prior scanline. Filter type 3: Average ====================== The Average filter uses the average of the two neighboring pixels (left and above) to predict the value of a pixel. To compute the Average filter, apply the following formula to each byte of each scanline: Average(x) = Raw(x) - floor((Raw(x-bpp)+Prior(x))/2) where x ranges from zero to the number of bytes representing that scanline minus one, Raw(x) refers to the raw data byte at that byte position in the scanline, Prior(x) refers to the unfiltered bytes of the prior scanline, and bpp is defined as for the Sub filter. Note this is done for each byte, regardless of bit depth. The sequence of Average values is transmitted as the filtered scanline. The subtraction of the predicted value from the raw byte must be done modulo 256, so that both the inputs and outputs fit into bytes. However, the sum Raw(x-bpp)+Prior(x) must be formed without overflow (using at least nine-bit arithmetic). floor() indicates that the result of the division is rounded to the next lower integer if fractional; in other words, it is an integer division or right shift operation. For all x < 0, assume Raw(x) = 0. On the first scanline of an image (or of a pass of an interlaced image), assume Prior(x) = 0 for all x. To reverse the effect of the Average filter after decompression, output the following value: Average(x) + floor((Raw(x-bpp)+Prior(x))/2) where the result is computed mod 256, but the prediction is calculated in the same way as for encoding. Raw refers to the bytes already decoded, and Prior refers to the decoded bytes of the prior scanline. Filter type 4: Paeth ==================== The Paeth filter computes a simple linear function of the three neighboring pixels (left, above, upper left), then chooses as predictor the neighboring pixel closest to the computed value. This technique is taken from Alan W. Paeth's article "Image File Compression Made Easy" in Graphics Gems II, James Arvo, editor, Academic Press, 1991. To compute the Paeth filter, apply the following formula to each byte of each scanline: Paeth(x) = Raw(x) - PaethPredictor(Raw(x-bpp),Prior(x),Prior(x-bpp)) where x ranges from zero to the number of bytes representing that scanline minus one, Raw(x) refers to the raw data byte at that byte position in the scanline, Prior(x) refers to the unfiltered bytes of the prior scanline, and bpp is defined as for the Sub filter. Note this is done for each byte, regardless of bit depth. Unsigned arithmetic modulo 256 is used, so that both the inputs and outputs fit into bytes. The sequence of Paeth values is transmitted as the filtered scanline. The PaethPredictor function is defined by the following pseudocode: function PaethPredictor (a, b, c) begin ; a = left, b = above, c = upper left p := a + b - c ; initial estimate pa := abs(p - a) ; distances to a, b, c pb := abs(p - b) pc := abs(p - c) ; return nearest of a,b,c, ; breaking ties in order a,b,c. if pa <= pb AND pa <= pc begin return a end if pb <= pc begin return b end return c end The calculations within the PaethPredictor function must be performed exactly, without overflow. Arithmetic modulo 256 is to be used only for the final step of subtracting the function result from the target pixel value. Note that the order in which ties are broken is fixed and must not be altered. The tie break order is: pixel to the left, pixel above, pixel to the upper left. (This order differs from that given in Paeth's article.) For all x < 0, assume Raw(x) = 0 and Prior(x) = 0. On the first scanline of an image (or of a pass of an interlaced image), assume Prior(x) = 0 for all x. To reverse the effect of the Paeth filter after decompression, output the following value: Paeth(x) + PaethPredictor(Raw(x-bpp),Prior(x),Prior(x-bpp)) (computed mod 256), where Raw and Prior refer to bytes already decoded. Exactly the same PaethPredictor function is used by both encoder and decoder. For more information, check out the above ftp sites. EXTENSION:PNG OCCURENCES:PC,UNIX,AMIGA PROGRAMS:???? REFERENCE:The PNG Specification --------M-PTM------------------------------- Poly Tracker is a Scream Tracker 3 like tracker written by Lone Ranger of AcmE. This is a description of version 2.03 of the PTM format. Early formats are no longer used or supported by the current version of Poly Tracker (it still says "version 1.0β", but there have been about a dozen different versions, including some customized test versions). The samples are stored using delta-compression. OFFSET Count TYPE Description 0000h 28 char Songname in ASCIZ format, 0 padded 001Ch 1 char ID=#26 001Dh 1 word File type version, currently 0203h 001Fh 1 byte reserved (0) 0020h 1 word Number of orders ="ORD" 0022h 1 word Number of instruments ="INS" 0024h 1 word Number of patterns ="PAT" 0026h 1 word Number of voices used ="CHN" 0028h 1 word File flags (always 0 ??) 002Ah 1 word reserved (0) 002Ch 4 char ID='PTMF' 0030h 16 byte reserved (0) 0040h 32 byte Pan settings for each channel : 0 = left, 7 = middle, 15 = right 0060h 256 byte Order list, valid entries are 0.."ORD" 0160h 128 word (Pattern offsets) div 16 The instruments data follows immediately after the header. --- PTM instrument format There are 0.."INS" instruments in the file, each of the following format : OFFSET Count TYPE Description 0000h 1 byte Sample type (bit mapped) 0,1 : 0 - no sample (instrument info only) 1 - normal sample (FileOfs / Length fields are valid) 2 - OPL2 / OPL3 instrument (not used) 3 - MIDI instrument (not used) 2 - sample loop (0 = no loop, 1 = loop) 3 - loop type (0 = unidirectional, 1 = bidirectional) 4 - sample resolution (0 = 8 bits, 1 = 16 bits) 0001h 12 char Name of external sample file 000Dh 1 byte Default volume for sample 000Eh 1 word C4 speed 0010h 1 word reserved (0) 0012h 1 dword absolute? offset of sample data 0016h 1 dword Size of sample in bytes 001Ah 1 dword Start of loop 001Eh 1 dword End of loop 0022h 13 byte reserved (0) 0030h 28 char ASCIZ name of sample 004Ch 4 char ID='PTMS' EXTENSION:PTM OCCURENCES:PC --------M-PS16------------------------------ The Protracker Studio 16 Modules are yet another digital music format. The Protracker modules can have up to 255 different patterns and a length of up to 255 patterns with 31 instruments. The samples can only have a size of up to 64K, there is a maximum of 16 tracks supported. The header of each MOD file looks like this : OFFSET Count TYPE Description 0000h 5 char Header string ID='PS16',254 0005h 75 char Song name, ending with ^Z so that if typing the file will result in PS16 <SongName> 0050h 1 byte File type : 0 - Module with patterns and samples 1 - Song with patterns but without samples 0051h 1 dword Offset of comment field from start of file. Zero if no commend is stored. 0055h 1 byte Format version byte (0) 0056h 1 byte Number of patterns in the file ="PAT" 0057h 1 dword Total size of all patterns in bytes, stored for quick disk reads. 005Bh 1 byte Songlength, number of sequences. 005Ch 128 byte Sequencing information for file 00CCh 31 rec Sample information 1 byte Sample flags, bitmapped : 0 - synthesized / digital 1 - Waveform / FM (only if bit 0 is set) 2 - 16 bit / 8 bit 1 byte Default volume for the sample (0-64) 1 byte Sample fine tuning (signed nibble) 1 dword Sample length - Protracker does only support samples with a size less than 64K. 1 dword Sample loop start 1 dword Sample loop length 1 word Default playback frequency for C2 Can be used to fine tune a sample. 00CCh+ "PAT" rec The pattern information 31*17 The tracks are stored sequentially after each other, first all rows of track 1, then all rows of track 2 and so on. 1 word Pattern size+3, rounded up to a paragraph boundary. 1 byte Number of rows in pattern ="ROW" "ROW" rec 2 byte Note information, bitmapped : 0-5 - Note (see table 0005) 6 - Bit 4 of instrument 7 - Compression bit If this bit not set, there is another byte following the note record specifying the row where the next event takes place - if it is set, the next note follows immediately. A track is terminated by a 0FFh byte. 8-11 - Effect bits 12-15 - Bits 0-3 of instrument 1 byte Effect data 00CCh+ ? byte Sample data in delta format 31*17+ See algorthm.txt for details. ???? The comment block contains information about the sample names as well as some comments to the module. It is formatted like this : OFFSET Count TYPE Description 0000h 4 char ID='INST' 1 byte Instrument name length ="LEN" 1 byte Sample name count ="CNT" "LEN"*"CNT" char Sample names 0000h+ 4 char ID='TEXT' "LEN"*"CNT"+4 1 word Length of following text EXTENSION:MOD OCCURENCES:PC PROGRAMS:Protracker REFERENCE: SEE ALSO:DMF,MOD,S3M,STM VALIDATION: --------I-QFX------------------------------- QFX files are yet another graphic file format used to store received fax images. The .QFX file format is proprietary to Smith Micro Software, Inc. and is used by the Quick Link II fax software. The QFX file header is exactly 1536 bytes long. The fax pages themselves are stored in byte aligned, bit reversed T4 format terminated with 6 EOL's. See CCITT Recommendation T.4 for full documentation on this coding scheme. OFFSET Count TYPE Description 0000h 8 char ID='QLIIFAX',0 0008h 1 word Number of pages in the QFX file 000Ah 1 word Number of scan lines on last page 000Ch 1 dword Number of scan lines for all pages 0010h 1 word Horizontal scaling 1 - High res (200x200), 2 - Normal res (200x100) 0012h 1 word Vertical scaling (always = 1). 0014h 12 byte reserved 0020h 375 dword Offsets of the single pages in the document. Page 1 always starts at offset 1536. The last non-zero dword points to the end of the last page, the first zero dword marks the end of the pages. 0600h ? byte Start of fax page images EXTENSION:QFX OCCURENCES:PC PROGRAMS:Quick Link II --------S-RAW------------------------------- The RAW files are raw signed PCM sound files. PCM means Pulse Code Modulation - which can be played through most sound devices without further manipulation. There is no header or whatsoever. The properties include 8/16-bit samples in INTEL order, stereo or mono format. No identification is possible. EXTENSION:RAW SEE ALSO:SND --------I-RDIB------------------------------ The RDIB files are Device Independent Bitmaps used by Windows. They are RIFF format files. The blocks are unknown to me. SEE ALSO:RIFF --------f-RIFF------------------------------ The RIFF (Resource interchange file format) format was created by Microsoft and is used by many applications like Windows, Corel Draw etc.. It is block structured, each block has a header ID and a size, so that even a program that works with an old version of the file format can skip the unknown parts of the file and work on the known parts of the file. All RIFF blocks begin on a word boundary so it might be necessary to skip an additional byte. In the present specification, only one RIFF block per file is allowed, and only the RIFF and LIST blocks may contain subblocks. The order of blocks in a RIFF file is not mandatory, so you should always scan the whole file for the block ID you seek. Throughout this file, the RIFF block IDs are given in square brackets []. Each ID is always 4 characters dword. OFFSET Count TYPE Description 0000h 4 char ID='RIFF' Each RIFF format file has a header with the signature and the size of the following blocks. 0004h 1 dword Block size. This size is the size of the block controlled by the RIFF header. Normally this equals the file size. ="BSZ" 0008h 4 char Format name. This is the format name of the RIFF file. After this RIFF header comes the first RIFF record. Each RIFF record has the following format : OFFSET Count TYPE Description 0000h 4 char Signature. This is the description of what is contained in this block. 0004h 1 dword Block size. This is the size of the following data block. To get the offset of the next RIFF block record, you have to add this value + 8 to the offset of the current record. ---RiffBLOCK [LIST] This block contains a string list, again in the RIFF subblock format. This list is used for messages and/or copyright messages. All strings in the LIST block share the same format, each block contains one ASCIIZ string - the most common LIST block is the [INFO] block, which can contain the following subblocks : [INAM] The name of the data stored in the file [ICRD] Creation date of the file SEE ALSO:BMP,rDIB,IFF,WAVe,RIFX OCCURENCES:PC PROGRAMS:Windows,Corel Draw REFERENCE:DDJ0994 VALIDATION:FileSize="BSZ"+8 --------f-RIFX-M---------------------------- The RIFX file format is identical to the RIFF file format except that all values are in Motorola byte order. OFFSET Count TYPE Description 0000h 4 char ID='RIFX' 0004h 1 dword Block size. This size is the size of the block controlled by the RIFX header. ="BSZ" 0008h 4 char Format name. REFERENCE:DDJ0994 SEE ALSO:RIFF --------S-S3I------------------------------- This is the Digiplayer/ST3.0 digital sample file format. The sample files include information about the loop of the instrument. The AdLib instruments have another format listed below. OFFSET Count TYPE Description 0000h 1 byte ID=01h 0001h 12 char DOS filename 000Dh 1 byte reserved (0) 000Eh 1 word Paragraph offset of the raw sample data from beginning of file. 0010h 1 dword Sample length in bytes 0014h 1 dword Start of sample loop 0018h 1 dword End of sample loop 001Ch 1 byte Playback volumne of sample 001Dh 1 byte ??? "DSK" what ever that means 001Eh 1 byte Pack type 0 - unpacked 1 - DP30ADPCM 1 001Fh 1 byte Flags (bitmapped) 0 - loop on/off 1 - stereo sample (length bytes for left channel, then another length bytes for right channel!) 2 - 16-Bit samples (in Intel byte order) 0020h 1 dword C2 frequency 0024h 1 dword reserved 0028h 1 word reserved 002Ah 1 word ID=512 002Ch 1 dword ?? Date of last modification ?? (see table 0009) 0030h 28 char ASCIIZ Sample name 003Ch 4 char ID='SCRS' 0040h ? byte Raw sample data Here follows the AdLib instrument format for which I don't know the extension (yet) : OFFSET Count TYPE Description 0000h 1 byte Instrument type 2 - melodic instrument 3 - bass drum 4 - snare drum 5 - tom tom 6 - cymbal 7 - hihat 0001h 12 char DOS file name 000Dh 3 byte reserved 0010h 1 byte Modulator description (bitmapped) 0-3 - frequency multiplier 4 - scale envelope 5 - sustain 6 - pitch vibrato 7 - volume vibrato 0011h 1 byte Carrier description (same as modulator) 0012h 1 byte Modulator miscellaneous (bitmapped) 0-5 - 63-volume 6 - MSB of levelscale 7 - LSB of levelscale 0013h 1 byte Carrier description (same as modulator) 0014h 1 byte Modulator attack / decay byte (bitmapped) 0-3 - Decay 4-7 - Attack 0015h 1 byte Carrier description (same as modulator) 0016h 1 byte Modulator sustain / release byte (bitmapped) 0-3 - Release count 4-7 - 15-Sustain 0017h 1 byte Carrier description (same as modulator) 0018h 1 byte Modulator wave select 0019h 1 byte Carrier wave select 001Ah 1 byte Modulator feedback byte (bitmapped) 0 - additive synthesis on/off 1-7 - modulation feedback 001Bh 1 byte reserved 001Ch 1 byte Instrument playback volume 001Dh 1 byte ??? "DSK" 001Eh 1 word reserved 0020h 1 dword C2 frequency 0024h 12 byte reserved 0030h 28 char ASCIIZ Instrument name 004Ch 4 char ID='SCRI' EXTENSION:S3I,SMP OCCURENCES:PC PROGRAMS:ScreamTracker 3.0 SEE ALSO:MTM,S3M,STM --------M-S3M------------------------------- The ScreamTracker composer and the ScreamTracker Music Interface Kit (STMIK) were written by the demo group Future Crew for their demonstrations and released. S3M files are the files of the version 3 of the ScreamTracker. OFFSET Count TYPE Description 0000h 20 char Song name, ASCII, 0 padded 001Ch 1 byte ID=1Ah 001Dh 1 byte Filetype : 16=Module 17=Song ? What is this supposed to mean ? 001Eh 1 word Reserved 0020h 1 word Number of orders in song ="ORD" 0022h 1 word Number of instruments in song ="INS" 0024h 1 word Number of patterns in song ="PAT" 0026h 1 word Song flags, bitmapped 0 - ScreamTracker 2.0 type vibrato 1 - ScreamTracker 2.0 type tempo 2 - Amiga type slides 3 - Zero volume optimizations 4 - Amiga limits 5 - enable filters / sfx 0028h 1 word Tracker version 002Ah 1 word File format version 1=Original format 2=Original format, unsigned samples 002Ch 4 char ID='SCRM' 0032h 1 byte Maximum volume 0033h 1 byte Initial speed 0034h 1 byte Initial tempo 0035h 1 byte Master multiplier Whats this ???? 0036h 12 byte reserved 0040h 32 byte Channel balance settings 0=left 127=right +128=disabled 255=unused 0060h "ORD" byte Ordering sequence of the patterns 0060h "INS" word Offset of the instruments in paragraphs from +"ORD" begin of header (for binary offset, multiply with 16) 0060h "PAT" word Offset of the pattern data from begin of header +"ORD" in paragraphs +"INS"*2 EXTENSION:S3M OCCURENCES:PC PROGRAMS:ScreamTracker 3.0 SEE ALSO:S3I,STM,S2M --------S-SND------------------------------- The SND files are raw unsigned PCM sound files. PCM means Pulse Code Modulation - which can be played through most sound devices without further manipulation. There is no header or whatsoever. The properties include 8/16-bit samples in INTEL order, stereo or mono format. No identification is possible. EXTENSION:SND SEE ALSO:RAW --------A-SQZ------------------------------- The SQZ files are yet another archive format. The SQZ archives consist of one archive header and several file headers. The archive header has the following format : OFFSET Count TYPE Description 0000h 5 char ID='HLSQZ' 0005h 1 char Version in ASCII ID='1' 0006h 1 byte OS byte, 0 - PC-DOS / MS-DOS 1 - OS/2 2 - MVS 3 - HPFS (OS/2) 4 - Amiga 5 - Macintosh 6 - Unix 0007h 1 byte Misc. flags, bitmapped : 0 - Intel byte order / Motorola byte order 1 - Filetime in ?? / File time in DOS format 2 - No security envelope / security envelope 3-7 - reserved After the header and each block, there is one byte denoting the type/size of the next block : OFFSET Count TYPE Description 0000h 1 byte Block/size specifier : 0 - End of archive 1 - Comment 2 - Password 3 - Security envelope 4-18 - reserved >18 - normal file header, byte value is size of header The normal file header then has the following format : OFFSET Count TYPE Description 0000h 1 byte Checksum of header 0001h 1 byte Flags, bitmapped : 0-3 : Compression method : 0 - 1 - 2 - 3 - 4 - 4 - Security envelope should follow 5-7 - reserved 0002h 1 dword Compressed size of file 0006h 1 dword Original file size 000Ah 1 dword Date and time of file (see table 0009) 000Eh 1 byte File attributes 000Fh 1 dword CRC-32 of file 0013h ? char Filename (see above for length) The comment block : OFFSET Count TYPE Description 0000h 1 word Size of uncompressed comment 0002h 1 word Size of compressed comment data ="LEN" 0004h 1 byte Flags, bitmapped, see above 0005h 1 dword CRC-32 0009h "LEN" byte Compressed comment data The password block : OFFSET Count TYPE Description 0000h 1 word Size of password block (=4) 0004h 1 dword CRC-32 of password Other blocks : OFFSET Count TYPE Description 0000h 1 word Size of this block ="LEN" 0002h "LEN" byte Block data EXTENSION:SQZ OCCURENCES:PC PROGRAMS:?? REFERENCE: SEE ALSO: --------S-SDK------------------------------- The SDK files are disk images from disks used by the Roland S-550/S-50/S-330 sampler devices. Further information wanted. EXTENSION:SDK --------S-SDS------------------------------- The SDS files are MIDI Sample Dump Standart files and are used to transfer samples between MIDI devices. Further information wanted. EXTENSION:SDS SEE ALSO:MID,SDX --------S-SDX------------------------------- The SDX file are like the SDS files sample dump files used for transfer of data between MIDI devices. EXTENSION:SDX SEE ALSO:MID,SDS --------S-SMP------------------------------- The SMP files are digital sample files used by Samplevision software. Further information wanted. EXTENSION:SMP --------M-STM------------------------------- The ScreamTracker 1.0 format was the module format used by the ScreamTracker before version 2.0. OFFSET Count TYPE Description 0000h 20 char ASCIIZ song name 0014h 8 char Tracker name 001Ch 1 byte ID=1Ah 001Dh 1 byte File type 1 - song (contains no samples) 2 - module (contains samples) 001Eh 1 byte Major version number 001Fh 1 byte Minor version number 0020h 1 byte Playback tempo 0021h 1 byte Number of patterns ="PAT" 0022h 1 byte Global playback volume 0023h 13 byte reserved 0030h 31 rec Instrument data 12 char ASCIIZ instrument name 1 byte ID=0 1 byte Instrument disk 1 word reserved 1 word Sample length in bytes 1 word Sample loop start 1 word Sample loop end 1 byte Sample playback volume 1 byte reserved 1 word C3 frequency in Hz 1 dword reserved 1 word length in paragraphs (only for modules,in songs:reserved) 03D0h 64 byte Pattern orders 0410h 4*64*"PAT" rec Pattern data. Each pattern consists of 64 rows, each 4 channels. The channels are stored from left ro right, row by row. 1 byte Note byte : 251 - last 3 bytes not stored, all bytes 0 252 - last 3 bytes not stored, note -0-, whatever that means. 253 - last 3 bytes not stored, note ... 254 - undefined (reserved for run-time) 255 - undefined (reserved for run-time) otherwise bit mapped : 0-3 : note (c=0,c#=1...) 4-7 : octave 1 byte Only valid if above byte < 251, bit mapped 0-2 ; lower bit of note volume 3-7 : instrument number 1 byte bit mapped 0-3 : Effect command in ProTracker format seems to be overlapped by volume bits... 4-6 : upper bits of volume 1 byte command data in ProTracker format 0410h+ ? byte Raw sample data padded to 16 byte boundaries. 4*64*4*"PAT" EXTENSION:STM OCCURENCES:PC PROGRAMS:ScreamTracker 1.0 REFERENCE: SEE ALSO:S3M,MOD --------A-TAR-G----------------------------- The Unix Tape ARchives mostly have the extension TAR. The info about this comes from a magic file, thus useful only for identification. --------A-TAR------------------------------- The Unix TAR program is an archiver program which stores files in a single archive without compression. OFFSET Count TYPE Description @section The Standard Format A @dfn{tar tape} or file contains a series of records. Each record contains @code{RECORDSIZE} bytes. Although this format may be thought of as being on magnetic tape, other media are often used. Each file archived is represented by a header record which describes the file, followed by zero or more records which give the contents of the file. At the end of the archive file there may be a record filled with binary zeros as an end-of-file marker. A reasonable system should write a record of zeros at the end, but must not assume that such a record exists when reading an archive. The records may be @dfn{blocked} for physical I/O operations. Each block of @var{N} records (where @var{N} is set by the @samp{-b} option to @code{tar}) is written with a single @code{write()} operation. On magnetic tapes, the result of such a write is a single tape record. When writing an archive, the last block of records should be written at the full size, with records after the zero record containing all zeroes. When reading an archive, a reasonable system should properly handle an archive whose last block is shorter than the rest, or which contains garbage records after a zero record. The header record is defined in C as follows: @example /* * Standard Archive Format - Standard TAR - USTAR */ #define RECORDSIZE 512 #define NAMSIZ 100 #define TUNMLEN 32 #define TGNMLEN 32 union record @{ char charptr[RECORDSIZE]; struct header @{ char name[NAMSIZ]; char mode[8]; char uid[8]; char gid[8]; char size[12]; char mtime[12]; char chksum[8]; char linkflag; char linkname[NAMSIZ]; char magic[8]; char uname[TUNMLEN]; char gname[TGNMLEN]; char devmajor[8]; char devminor[8]; @} header; @}; /* The checksum field is filled with this while the checksum is computed. */ #define CHKBLANKS " " /* 8 blanks, no null */ /* The magic field is filled with this if uname and gname are valid. */ #define TMAGIC "ustar " /* 7 chars and a null */ /* The magic field is filled with this if this is a GNU format dump entry */ #define GNUMAGIC "GNUtar " /* 7 chars and a null */ /* The linkflag defines the type of file */ #define LF_OLDNORMAL '\0' /* Normal disk file, Unix compatible */ #define LF_NORMAL '0' /* Normal disk file */ #define LF_LINK '1' /* Link to previously dumped file */ #define LF_SYMLINK '2' /* Symbolic link */ #define LF_CHR '3' /* Character special file */ #define LF_BLK '4' /* Block special file */ #define LF_DIR '5' /* Directory */ #define LF_FIFO '6' /* FIFO special file */ #define LF_CONTIG '7' /* Contiguous file */ /* Further link types may be defined later. */ /* Bits used in the mode field - values in octal */ #define TSUID 04000 /* Set UID on execution */ #define TSGID 02000 /* Set GID on execution */ #define TSVTX 01000 /* Save text (sticky bit) */ /* File permissions */ #define TUREAD 00400 /* read by owner */ #define TUWRITE 00200 /* write by owner */ #define TUEXEC 00100 /* execute/search by owner */ #define TGREAD 00040 /* read by group */ #define TGWRITE 00020 /* write by group */ #define TGEXEC 00010 /* execute/search by group */ #define TOREAD 00004 /* read by other */ #define TOWRITE 00002 /* write by other */ #define TOEXEC 00001 /* execute/search by other */ @end example All characters in header records are represented by using 8-bit characters in the local variant of ASCII. Each field within the structure is contiguous; that is, there is no padding used within the structure. Each character on the archive medium is stored contiguously. Bytes representing the contents of files (after the header record of each file) are not translated in any way and are not constrained to represent characters in any character set. The @code{tar} format does not distinguish text files from binary files, and no translation of file contents is performed. The @code{name}, @code{linkname}, @code{magic}, @code{uname}, and @code{gname} are null-terminated character strings. All other fileds are zero-filled octal numbers in ASCII. Each numeric field of width @var{w} contains @var{w}@minus{} 2 digits, a space, and a null, except @code{size}, and @code{mtime}, which do not contain the trailing null. The @code{name} field is the pathname of the file, with directory names (if any) preceding the file name, separated by slashes. The @code{mode} field provides nine bits specifying file permissions and three bits to specify the Set UID, Set GID, and Save Text (``stick'') modes. Values for these bits are defined above. When special permissions are required to create a file with a given mode, and the user restoring files from the archive does not hold such permissions, the mode bit(s) specifying those special permissions are ignored. Modes which are not supported by the operating system restoring files from the archive will be ignored. Unsupported modes should be faked up when creating or updating an archive; e.g. the group permission could be copied from the @code{other} permission. The @code{uid} and @code{gid} fields are the numeric user and group ID of the file owners, respectively. If the operating system does not support numeric user or group IDs, these fields should be ignored. The @code{size} field is the size of the file in bytes; linked files are archived with this field specified as zero. @xref{Extraction Options}; in particular the @samp{-G} option.@refill The @code{mtime} field is the modification time of the file at the time it was archived. It is the ASCII representation of the octal value of the last time the file was modified, represented as an integer number of seconds since January 1, 1970, 00:00 Coordinated Universal Time. The @code{chksum} field is the ASCII representation of the octal value of the simple sum of all bytes in the header record. Each 8-bit byte in the header is added to an unsigned integer, initialized to zero, the precision of which shall be no less than seventeen bits. When calculating the checksum, the @code{chksum} field is treated as if it were all blanks. The @code{typeflag} field specifies the type of file archived. If a particular implementation does not recognize or permit the specified type, the file will be extracted as if it were a regular file. As this action occurs, @code{tar} issues a warning to the standard error. @table @code @item LF_NORMAL @itemx LF_OLDNORMAL These represent a regular file. In order to be compatible with older versions of @code{tar}, a @code{typeflag} value of @code{LF_OLDNORMAL} should be silently recognized as a regular file. New archives should be created using @code{LF_NORMAL}. Also, for backward compatibility, @code{tar} treats a regular file whose name ends with a slash as a directory. @item LF_LINK This represents a file linked to another file, of any type, previously archived. Such files are identified in Unix by each file having the same device and inode number. The linked-to name is specified in the @code{linkname} field with a trailing null. @item LF_SYMLINK This represents a symbolic link to another file. The linked-to name is specified in the @code{linkname} field with a trailing null. @item LF_CHR @itemx LF_BLK These represent character special files and block special files respectively. In this case the @code{devmajor} and @code{devminor} fields will contain the major and minor device numbers respectively. Operating systems may map the device specifications to their own local specification, or may ignore the entry. @item LF_DIR This specifies a directory or sub-directory. The directory name in the @code{name} field should end with a slash. On systems where disk allocation is performed on a directory basis the @code{size} field will contain the maximum number of bytes (which may be rounded to the nearest disk block allocation unit) which the directory may hold. A @code{size} field of zero indicates no such limiting. Systems which do not support limiting in this manner should ignore the @code{size} field. @item LF_FIFO This specifies a FIFO special file. Note that the archiving of a FIFO file archives the existence of this file and not its contents. @item LF_CONTIG This specifies a contiguous file, which is the same as a normal file except that, in operating systems which support it, all its space is allocated contiguously on the disk. Operating systems which do not allow contiguous allocation should silently treat this type as a normal file. @item 'A' @dots{} @itemx 'Z' These are reserved for custom implementations. Some of these are used in the GNU modified format, as described below. @end table Other values are reserved for specification in future revisions of the P1003 standard, and should not be used by any @code{tar} program. The @code{magic} field indicates that this archive was output in the P1003 archive format. If this field contains @code{TMAGIC}, the @code{uname} and @code{gname} fields will contain the ASCII representation of the owner and group of the file respectively. If found, the user and group ID represented by these names will be used rather than the values within the @code{uid} and @code{gid} fields. @section GNU Extensions to the Archive Format The GNU format uses additional file types to describe new types of files in an archive. These are listed below. @table @code @item LF_DUMPDIR @itemx 'D' This represents a directory and a list of files created by the @samp{-G} option. The @code{size} field gives the total size of the associated list of files. Each filename is preceded by either a @code{'Y'} (the file should be in this archive) or an @code{'N'} (The file is a directory, or is not stored in the archive). Each filename is terminated by a null. There is an additional null after the last filename. @item LF_MULTIVOL @itemx 'M' This represents a file continued from another volume of a multi-volume archive created with the @samp{-M} option. The original type of the file is not given here. The @code{size} field gives the maximum size of this piece of the file (assuming the volume does not end before the file is written out). The @code{offset} field gives the offset from the beginning of the file where this part of the file begins. Thus @code{size} plus @code{offset} should equal the original size of the file. @item LF_VOLHDR @itemx 'V' This file type is used to mark the volume header that was given with the @samp{-V} option when the archive was created. The @code{name} field contains the @code{name} given after the @samp{-V} option. The @code{size} field is zero. Only the first file in each volume of an archive should have this type. @end table EXTENSION: OCCURENCES: PROGRAMS: REFERENCE: SEE ALSO: VALIDATION: OFFSET Count TYPE Description 0000h 256 byte Other header info ? 0100h 6 char ID='ustar',0 EXTENSION:TAR OCCURENCES:PC, Unix PROGRAMS:TAR --------G-TDDD------------------------------ This format is used by the Imagine rendering package. The names of the blocks are unknown to me. OFFSET Count TYPE Description EXTENSION:IFF OCCURENCES:Amiga,PC PROGRAMS:Imagine package REFERENCE:DDJ0794 SEE ALSO:IFF --------I-TIFF------------------------------ The TIFF file format was designed jointly by Aldus and Microsoft with leading scanner vendors to faciliate incorporating scanned images into publishing. The described TIFF specification is TIFF 5.0. A TIFF file consists of several different blocks which define the palette data or the LZW-compressed body among other things. TIFF files can be in Motorola _or_ Intel byte order, depending on the first word. If it is 'II', the byte order is in Intel order, if it is 'MM', then you have Motorola byte ordering. Each TIFF file begins with a image file header which points to one or more image file directories, which contain the image data and image information. The format of the image header : OFFSET Count TYPE Description 0000h 2 char ID='II', ID='MM' This is the identification, 'II' stands for Intel byte order, 'MM' for Motorola byte order. The following data must be interpreted accordingly ! 0002h 1 word TIFF "version number". This version number never changed and the value (42) was choosen for its deep philosophical value. In fact, if the version number ever changes, this means that radical changes to the TIFF format have been made, and a TIFF reader should give up immediately. You can consider this word to be a part of the header ID. 0004h 1 dword Offset of first image directory in file form start of file. The first image directory must begin on an even byte boundary. The image directory may follow the image data it describes. The image directory is described below. An organization may wish to store information that is meaningful to only that organization in a TIFF file. Tags numbered 32768 or higher are reserved for that purpose. Upon request, the administrator will allocate and register a block of private tags for an organization. Private enumerated values can be accommodated in a similar fashion. The format of the image file directory (IFD) : All entries are sorted in ascending order by the tag field. OFFSET Count TYPE Description 0000h 1 word Number of entries ="NUM" 0002h "NUM" rec Field descriptor 1 word Field tag, see below 1 word Field type 1 - byte 2 - ASCII string, counted in length. Most often an ASCIIZ string, the trailing zero is counted with the data length. 3 - word 4 - dword / uword 5 - rational (2 dwords, numerator and denominator) 1 dword Length of the field in units of the data type. A single 16-bit word has the length 1. 1 dword Data offset of the field. The data starts on a word boundary, thus the dword should be even. The data for the field may be anywhere in the file, even after the image data. If the data size is less or equal to 4 bytes (determined by the field type and length), then this offset is not a offset but instead the data itself, to save space. If the data size is less than 4 bytes, the data is stored left-justified within the 4 bytes of the offset field. 0002h+ "NUM"*12 1 dword Offset of next IFD in file, 0 if none follow If a certain field in the IFD does not exist, you have to presume the default values. The different fields are : --- BitsPerSample Tag = 258 (102) Type = word N = SamplesPerPixel Default = 1 Number of bits per sample. Note that this tag allows a different number of bits per sample for each sample corresponding to a pixel. For example, RGB color data could use a different number of bits per sample for each of the three color planes. --- ColorMap Tag = 320 (140) Type = word N = 3 * (2**BitsPerSample) No default.ColorMap must be included in all palette color images. This tag defines a Red-Green-Blue color map for palette color images. The palette color pixel value is used to index into all 3 subcurves. The subcurves are stored sequentially. The Red entries come first, followed by the Green entries, followed by the Blue entries. The width of each entry is 16 bits, as implied by the type of word. 0 represents the minimum intensity, and 65535 represents the maximum intensity. --- ColorResponseCurves Tag = 301 (12D) Type = word N = 3 * (2**BitsPerSample) Default: curves based on the NTSC recommended gamma of 2.2. This tag defines three color response curves, one each for Red, Green and Blue color information. The Red entries come first, followed by the Green entries, followed by the Blue entries. The length of each subcurve is 2**BitsPerSample, using the BitsPerSample value corresponding to the respective primary. The width of each entry is 16 bits, as implied by the type of word. The purpose of the color response curves is to refine the content of RGB color images. --- Compression Tag = 259 (103) Type = word N = 1 Default = 1. 1 = No compression, but pack data into bytes as tightly as possible, with no unused bits except at the end of a row. The bytes are stored as an array of bytes, for BitsPerSample <= 8, word if BitsPerSample > 8 and <= 16, and dword if BitsPerSample > 16 and <= 32. The byte ordering of data >8 bits must be consistent with that specified in the TIFF file header (bytes 0 and 1). Rows are required to begin on byte boundaries. 2 = CCITT Group 3 1-Dimensional Modified Huffman run length encoding. See ALGRTHMS.txt BitsPerSample must be 1, since this type of compression is defined only for bilevel images (like FAX images...) 3 = Facsimile-compatible CCITT Group 3, exactly as specified in "Standardization of Group 3 facsimile apparatus for document transmission," Recommendation T.4, Volume VII, Fascicle VII.3, Terminal Equipment and Protocols for Telematic Services, The International Telegraph and Telephone Consultative Committee (CCITT), Geneva, 1985, pages 16 through 31. Each strip must begin on a byte boundary. (But recall that an image can be a single strip.) Rows that are not the first row of a strip are not required to begin on a byte boundary. The data is stored as bytes, not words - byte-reversal is not allowed. See the Group3Options field for Group 3 options such as 1D vs 2D coding. 4 = Facsimile-compatible CCITT Group 4, exactly as specified in "Facsimile Coding Schemes and Coding Control Functions for Group 4 Facsimile Apparatus," Recommendation T.6, Volume VII, Fascicle VII.3, Terminal Equipment and Protocols for Telematic Services, The International Telegraph and Telephone Consultative Committee (CCITT), Geneva, 1985, pages 40 through 48. Each strip must begin on a byte boundary. Rows that are not the first row of a strip are not required to begin on a byte boundary. The data is stored as bytes, not words. See the Group4Options field for Group 4 options. 5 = LZW Compression, for grayscale, mapped color, and full color images. See ALGRTHMS.txt 32773 = PackBits compression, a simple byte oriented run length scheme for 1-bit images. See Appendix C. Data compression only applies to raster image data, as pointed to by StripOffsets. --- GrayResponseCurve Tag = 291 (123) Type = word N = 2**BitsPerSample The purpose of the gray response curve and the gray units is to provide more exact photometric interpretation information for gray scale image data, in terms of optical density. --- GrayResponseUnit Tag = 290 (122) Type = word N = 1 For historical reasons, the default is 2. However, for greater accuracy, 3 is recommended. 1 = Number represents tenths of a unit. 2 = Number represents hundredths of a unit. 3 = Number represents thousandths of a unit. 4 = Number represents ten-thousandths of a unit. 5 = Number represents hundred-thousandths of a unit. --- ImageLength Tag = 257 (101) Type = word or dword N = 1 No default. The image's length (height) in pixels (Y:vertical). The number of rows (sometimes described as "scan lines") in the image. --- ImageWidth Tag = 256 (100) Type = word or dword N = 1 No default. The image's width, in pixels (X:horizontal). The number of columns in the image. --- NewSubfileType Tag = 254 (FE) Type = dword N = 1 Default is 0. A general indication of the kind of data that is contained in this subfile. This field is made up of a set of 32 flag bits. Unused bits are expected to be 0. Bit 0 is the low-order bit. Currently defined values for the bitmap are: 0 - Image is reduced of another TIFF image in this file 1 - Image is a single page of a multi-page 2 - Image is a transparency mask for another image in this file --- PhotometricInterpretation Tag = 262 (106) Type = word N = 1 No default. 0 = For bilevel and grayscale images: 0 is imaged as white. 2**BitsPerSample-1 is imaged as black. If GrayResponseCurve exists, it overrides the PhotometricInterpretation value. 1 = For bilevel and grayscale images: 0 is imaged as black. 2**BitsPerSample-1 is imaged as white. If GrayResponseCurve exists, it overrides the PhotometricInterpretation value. 2 = RGB. In the RGB model, a color is described as a combination of the three primary colors of light (red, green, and blue) in particular concentrations. For each of the three samples, 0 represents minimum intensity, and 2**BitsPerSample - 1 represents maximum intensity. For PlanarConfiguration = 1, the samples are stored in the indicated order: first Red, then Green, then Blue. For PlanarConfiguration = 2, the StripOffsets for the sample planes are stored in the indicated order: first the Red sample plane StripOffsets, then the Green plane StripOffsets, then the Blue plane StripOffsets. 3 = "Palette color." In this mode, a color is described with a single sample. The sample is used as an index into ColorMap. The sample is used to index into each of the red, green and blue curve tables to retrieve an RGB triplet defining an actual color. When this PhotometricInterpretation value is used, the color response curves must also be supplied. SamplesPerPixel must be 1. 4 = Transparency Mask. This means that the image is used to define an irregularly shaped region of another image in the same TIFF file. SamplesPerPixel and BitsPerSample must be 1. PackBits compression is recommended. The 1-bits define the interior of the region; the 0-bits define the exterior of the region. The Transparency Mask must have the same ImageLength and ImageWidth as the main image. PlanarConfiguration Tag = 284 (11C) Type = word N = 1 Default is 1. 1 = The sample values for each pixel are stored contiguously, so that there is a single image plane. See PhotometricInterpretation to determine the order of the samples within the pixel data. So, for RGB data, the data is stored RGBRGBRGB...and so on. 2 = The samples are stored in separate "sample planes." The values in StripOffsets and StripByteCounts are then arranged as a 2-dimensional array, with SamplesPerPixel rows and StripsPerImage columns. (All of the columns for row 0 are stored first, followed by the columns of row 1, and so on.) PhotometricInterpretation describes the type of data that is stored in each sample plane. For example, RGB data is stored with the Red samples in one sample plane, the Green in another, and the Blue in another. If SamplesPerPixel is 1, PlanarConfiguration is irrelevant, and should not be included. Predictor Tag = 317 (13D) Type = word N = 1 Default is 1. To be used when Compression=5 (LZW). 1 = No prediction scheme used before coding. 2 = Horizontal differencing. See Appendix I. ResolutionUnit Tag = 296 (128) Type = word N = 1 Default is 2. To be used with XResolution and YResolution. 1 = No absolute unit of measurement. Used for images that may have a non-square aspect ratio, but no meaningful absolute dimensions. The drawback of ResolutionUnit=1 is that different applications will import the image at different sizes. Even if the decision is quite arbitrary, it might be better to use dots per inch or dots per centimeter, and pick XResolution and YResolution such that the aspect ratio is correct and the maximum dimension of the image is about four inches (the "four" is quite arbitrary.) 2 = Inch. 3 = Centimeter. RowsPerStrip Tag = 278 (116) Type = word or dword N = 1 Default is 2**32 - 1, which is effectively infinity. That is, the entire image is one strip. Recomended is a strip size of 8K. The number of rows per strip. The image data is organized into strips for fast access to individual rows when the data is compressed - though this field is valid even if the data is not compressed. --- SamplesPerPixel Tag = 277 (115) Type = word N = 1 Default = 1. The number of samples per pixel. SamplesPerPixel is 1 for bilevel, grayscale, and palette color images. SamplesPerPixel is 3 for RGB images. --- StripByteCounts Tag = 279 (117) Type = word or dword N = StripsPerImage for PlanarConfiguration equal to 1. = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2 No default. For each strip, the number of bytes in that strip. The existence of this field greatly simplifies the chore of buffering compressed data, if the strip size is reasonable. --- StripOffsets Tag = 273 (111) Type = word or dword N = StripsPerImage for PlanarConfiguration equal to 1. = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2 No default. For each strip, the byte offset of that strip. The offset is specified with respect to the beginning of the TIFF file. Note that this implies that each strip has a location independent of the locations of other strips. This feature may be useful for editing applications. This field is the only way for a reader to find the image data, and hence must exist. --- XResolution Tag = 282 (11A) Type = RATIONAL N = 1 No default. The number of pixels per ResolutionUnit in the X direction, i.e., in the ImageWidth direction. --- YResolution Tag = 283 (11B) Type = RATIONAL N = 1 No default. The number of pixels per ResolutionUnit in the Y direction, i.e., in the ImageLength direction. --- Artist Tag = 315 (13B) Type = ASCII Person who created the image. Copyright notice. --- DateTime Tag = 306 (132) Type = ASCII N = 20 Date and time of image creation. Uses the format "YYYY:MM:DD HH:MM:SS", with hours on a 24-hour clock, and one space character between the date and the time. The length of the string, including the null, is 20 bytes. --- HostComputer Tag = 316 (13C) Type = ASCII "ENIAC", or whatever. --- ImageDescription Tag = 270 (10E) Type = ASCII For example, a user may wish to attach a comment such as "1988 company picnic" to an image. --- Make Tag = 271 (10F) Type = ASCII Manufacturer of the scanner, video digitizer, or whatever. --- Model Tag = 272 (110) Type = ASCII The model name/number of the scanner, video digitizer, or whatever. This tag is intended for user information only so format is arbitrary. --- Software Tag = 305 (131) Type = ASCII Name and release number of the software package that created the image. User information only. --- Group3Options Tag = 292 (124) Type = dword N = 1 Those options are for fax-images stored in TIFF format. This field is made up of a set of 32 flag bits. Unused bits are expected to be 0. It is probably not safe to try to read the file if any bit of this field is set that you don't know the meaning of. Bit map : 0 - 2-dimensional coding used. 1 - Image is uncompressed 2 - Fill bits have been added before EOL codes, so that EOL always ends on a byte boundary. --- Group4Options Tag = 293 (125) Type = dword N = 1 This field is made up of a set of 32 flag bits and is used for the images with fax group 4 compression. Unused bits are expected to be 0. It is probably not safe to try to read the file if any bit of this field is set that you don't know the meaning of. Gray scale and color coding schemes are under study, and will be added when finalized. For 2-D coding, each strip is encoded as if it were a separate image. In particular, each strip begins on a byte boundary; and the coding for the first row of a strip is encoded independently of the previous row, using horizontal codes, as if the previous row is entirely white. Each strip ends with the 24-bit end-of-facsimile block (EOFB). Bit map : 0 - reserved (unused) 1 - uncompressed mode is used 2-31 - reserved --- DocumentName Tag = 269 (10D) Type = ASCII The name of the document from which this image was scanned. --- PageName Tag = 285 (11D) Type = ASCII The name of the page from which this image was scanned. --- PageNumber Tag = 297 (129) Type = word N = 2 This tag is used to specify page numbers of a multiple page (e.g. facsimile) document. Two word values are specified. The first value is the page number; the second value is the total number of pages in the document. Note that pages need not appear in numerical order. The first page is 0 (zero). --- XPosition Tag = 286 (11E) Type = RATIONAL The X offset of the left side of the image, with respect to the left side of the page, in ResolutionUnits. --- YPosition Tag = 287 (11F) Type = RATIONAL The Y offset of the top of the image, with respect to the top of the page, in ResolutionUnits. In the TIFF coordinate scheme, the positive Y direction is down, so that YPosition is always positive. --- White Point Tag = 318 (13E) Type = RATIONAL N = 2 Default is the SMPTE white point, D65: x = 0.313, y = 0.329. The white point of the image. Note that this value is described using the 1931 CIE xyY chromaticity diagram and only the chromaticity is specified. The luminance component is arbitrary and not specified. This can correspond to the white point of a monitor that the image was painted on, the filter set/light source combination of a scanner, or to the white point of the illumination model of a rendering package. The ordering is x, y. --- PrimaryChromaticities Tag = 319 (13F) Type = RATIONAL N = 6 Default is the SMPTE primary color chromaticities: Red: x = 0.635 y = 0.340 Green: x = 0.305 y = 0.595 Blue: x = 0.155 y = 0.070 The primary color chromaticities. Note that these values are described using the 1931 CIE xyY chromaticity diagram and only the chromaticities are specified.For paint images, these represent the chromaticities of the monitor and for scanned images they are derived from the filter set/light source combination of a scanner. The ordering is red x, red y, green x, green y, blue x, blue y. --- SubfileType Tag = 255 (FF) Type = word N = 1 A general indication of the kind of data that is contained in this subfile. Currently defined values are: 1 = full resolution image data - ImageWidth, ImageLength, and StripOffsets are required fields 2 = reduced resolution image data - ImageWidth, ImageLength, and StripOffsets are required fields. It is further assumed that a reduced resolution image is a reduced version of the entire extent of the corresponding full resolution data. 3 = single page of a multi-page image (see the PageNumber tag description). Continued use of this field is not recommended. Writers should instead use the new and more general NewSubfileType field. --- Orientation Tag = 274 (112) Type = word N = 1 Default is 1. 1 = The 0th row represents the visual top of the image, and the 0th column represents the visual left hand side. 2 = The 0th row represents the visual top of the image, and the 0th column represents the visual right hand side. 3 = The 0th row represents the visual bottom of the image, and the 0th column represents the visual right hand side. 4 = The 0th row represents the visual bottom of the image, and the 0th column represents the visual left hand side. 5 = The 0th row represents the visual left hand side of the image, and the 0th column represents the visual top. 6 = The 0th row represents the visual right hand side of the image, and the 0th column represents the visual top. 7 = The 0th row represents the visual right hand side of the image, and the 0th column represents the visual bottom. 8 = The 0th row represents the visual left hand side of the image, and the 0th column represents the visual bottom. It is extremely costly for most readers to perform image rotation "on the fly", i.e., when importing and printing; and users of most desktop publishing applications do not expect a file imported by the application to be altered permanently in any way. Threshholding Tag = 263 (107) Type = word N = 1 1 = a bilevel "line art" scan. BitsPerSample must be 1. 2 = a "dithered" scan, usually of continuous tone data such as photographs. BitsPerSample must be 1. 3 = Error Diffused. ColorImageType Tag = 318 (13E) Type = word N = 1 Default is 1. Gives TIFF color image readers a better idea of what kind of color image it is. There will be borderline cases. 1 = Continuous tone, natural image. 2 = Synthetic image, using a greatly restricted range of colors. Such images are produced by most color paint programs. See ColorList for a list of colors used in this image. ColorList Tag = 319 (13F) Type = BYTE or word N = the number of colors that are used in this image, times SamplesPerPixel A list of colors that are used in this image. Use of this field is only practical for images containing a greatly restricted (usually less than or equal to 256) range of colors. ColorImageType should be 2. See ColorImageType. The list is organized as an array of RGB triplets, with no pad. The RGB triplets are not guaranteed to be in any particular order. Note that the red, green, and blue components can either be a BYTE or a word in length. BYTE should be sufficient for most applications. EXTENSION:TIF,TIFF OCCURENCES:PC,MAC,UNIX PROGRAMS:Aldus Pagemaker, Paintbrush REFERENCE: SEE ALSO: VALIDATION: --------I-TARGA----------------------------- The Targa-File format is an image file format used by a wide variety of both scanners and imaging software, and exists in many incarnations. The information has been taken from Appendix C of the Truevision Technical Guide.Requests for further information could be directed to: AT&T Electronic Photography and Imaging Center 2002 Wellesley Ave. Indianapolis, IN 42619 The lack of completeness is due to the fact that the Targa recognizes over half a dozen image file formats, some of which are more widely used than others. OFFSET Count TYPE Description 0000h 1 byte Length of image identification field (below) 0001h 1 byte Color map type : 0 - no color map 1 - 256 entry palette 0002h 1 byte Image type : 0 - no image data included 1 - Uncompressed, color-mapped image 2 - Uncompressed, RGB image 3 - Uncompressed, black and white image 9 - RLE encoded color-mapped image 10 - RLE encoded RGB image 11 - Compressed, black and white image 32 - Compressed color-mapped data, using Huffman, Delta, and runlength encoding. 33 - Compressed color-mapped data, using Huffman, Delta, and RLE. 4-pass quadtree- type process. 0003h 1 word Index of first color map entry 0005h 1 word Count of color map entries 0007h 1 byte Number of bits per color map entry 0008h 1 word X coordinate of the lower left corner of the image. 000Ah 1 word Y coordinate of the lower left corner of the image. 000Ch 1 word Width of the image in pixels 000Eh 1 word Height of the image in pixels 0010h 1 byte Bytes per pixel 0011h 1 byte Flags (bitmapped): 0-3 : Number of attribute bits 4 : reserved 5 : Screen origin in upper left corner 6-7 : Data storage interleave 00 - no interleave 01 - even/odd interleave 10 - four way interleave 11 - reserved The byte should be set to 0. Don't know why. 0012h ? char Image identification string, usually not there, when the length (see up) is 0. ????h ? byte Color map data Depending on the number of bits per color map entry, the entries here have a different size. 4 bytes : 1 byte for blue 1 byte for green 1 byte for red 1 byte for attribute 3 bytes : 1 byte for blue 1 byte for green 1 byte for red 2 bytes : Bitmapped as a word in Intel byte order as follows : ARRRRRGG GGGBBBBB ????h ? byte Image data For images of type 9 (using RLE), the image data is divided into packets, the first byte being the indicator for repetition or copy. If bit 7 of the first byte is set, then repeat (first byte and 07Fh+1) times the next byte, otherwise copy first byte+1 pixels from data stream. RLE packets may cross scan lines ! EXTENSION:TGA OCCURENCES:PC SEE ALSO: --------S-TXW------------------------------- The TXW files are disk images used by the Yamaha TX-16W. Further information wanted. EXTENSION:TXW --------S-UWF-G----------------------------- The UWF files are sample files used by the UltraTracker. Further information wanted. OFFSET Count TYPE Description 0000h 32 char ASCIIZ sample name 0020h 1 char ID=1Ah 0021h 1 char ID=10h 0022h 5 char ID='MUWFB' 0027h 1 char ID=0 0028h 6 char Length of sample as ASCII long integer 002Eh 1 word Length of sample ????? EXTENSION:UWF SEE ALSO:ULT --------M-ULT------------------------------- The ULT files are modules used by the UltraTracker. UltraTracker is a module editor for the Gravis UltraSound soundcard. The version of the file format used now is 6. OFFSET Count TYPE Description 0000h 11 char ID="MAS_UTrack_V" 000Ch 4 char Version number in 4-digit ASCII : 1 - ULT version 1.0 2 - ULT version 2.0 3 - ULT version 2.1 4 - ULT version 2.2 000Fh 32 char Song title 002Fh 1 byte Number of song text lines ="NTL" 0030h "NTL"*32 char Song text 0030h+"NTL"*32 1 byte Number of samples ="NOS" 0031h+"NTL"*32 "NOS" rec Sample structure 32 byte Sample name 12 byte DOS file name of sample 1 dword Sample loop start 1 dword Sample loop end 1 dword Size start 1 dword Size end 1 byte Sample volume (linear) 1 byte Bidirectional loop 0 - No looping, forward playback, 8bit sample 4 - No Looping, forward playback, 16bit sample 8 - Loop Sample, forward playback, 8bit sample 12 - Loop Sample, forward playback, 16bit sample 24 - Loop Sample, reverse playback 8bit sample 28 - Loop Sample, reverse playback, 16bit sample 1 word Fine tune setting 1 word C2-Frequency 0031h+"NTL"*32 +"NOS"*64 256 byte Pattern orders 0131h+"NTL"*32 +"NOS"*64 1 byte ="NOT" Number of tracks -1 0132h+"NTL"*32 +"NOS"*64 1 byte ="NOT" Number of patterns -1 0133h+"NTL"*32 +"NOS"*64 "NOT" byte Pan-position table (0-left, F-right) After the header there comes the event data. EXTENSION:ULT SEE ALSO:UWF --------S-WAVE------------------------------ The Windows .WAV files are RIFF format files. Some programs expect the fmt block right behind the RIFF header itself, so your programs should write out this block as the first block in the RIFF file. The subblocks for the wave files are RiffBLOCK [data] This block contains the raw sample data. The necessary information for playback is contained in the [fmt ] block. RiffBLOCK [fmt ] This block contains the data necessary for playback of the sound files. Note the blank after fmt ! OFFSET Count TYPE Description 0000h 1 word Format tag 1 = PCM (raw sample data) 2 etc. for APCDM, a-Law, u-Law ... 0002h 1 word Channels (1=mono,2=stereo,...) 0004h 1 dword Sampling rate 0008h 1 dword Average bytes per second (=sampling rate*channels) 000Ch 1 word Block alignment / reserved ?? 000Eh 1 word Bits per sample (8/12/16-bit samples) RiffBLOCK [loop] This block is for looped samples. Very few programs support this block, but if your program changes the wave file, it should preserve any unknown blocks. OFFSET Count TYPE Description 0000h 1 dword Start of sample loop 0004h 1 dword End of sample loop EXTENSION:WAV SEE ALSO:RIFF,VOC OCCURENCES:PC PROGRAMS:Windows,GUSWAV,WAV2VOC VALIDATION:NONE --------E-Windows PIF----------------------- Windows also uses the PIF files for better performance under the DOS box. The Windows extension of the original PIF format starts at offset 0171h. OFFSET Count TYPE Description ********* not yet implemented ;-) EXTENSION: OCCURENCES: PROGRAMS: REFERENCE:DDJ #202 SEE ALSO:PIF, WINDOWS NT PIF VALIDATION: --------W-WKS------------------------------- The WKS files are worksheets/spreadsheets used by the Lotus 1-2-3 and Lotus Symphony packages. More information has yet to be found since this information origins from a magic file. OFFSET Count TYPE Description 0000h 5 byte ID=0,0,2,0,4 0005h 1 byte WKS type : 4 - Lotus 1-2-3 v1.A WKS 5 - Symphony 1.0 WKS other - ?WK1 file? (Lotus 2.01+, Symphony 1.1+) EXTENSION:WKS OCCURENCES:PC PROGRAMS:Lotus 1-2-3,Lotus Symphony SEE ALSO:WKS --------T-WORD-G---------------------------- The Microsoft Word programs store their documents in files. The info comes from a magic file and my own (not working) sources, so it is very unreliable except for identification. OFFSET Count TYPE Description 0000h 1 dword ID=31BE00 0002h 1 byte Document type : 0 - MS Word text 1 - MS Text building block 2 - Printer description file(maybe wrong topic) 0003h 1 byte ID=00 0004h 1 word ID=AB00h ToolID, different for the different versions ? 0006h 6 word reserved(0) 0008h 1 dword Textbytes??? Whatever 000Ch 1 word Paragraph information 000Eh 1 word Foot note table 0010h 1 word Section property 0012h 1 word Section table 0014h 1 word Page table 0016h 64 char Style sheet path 0056h 1 word Windows Write page count Can be used to identify Windows Write files, because it is 0 for MS Word and nonzero for Windows Write documents. 0058h 8 char Printer name Used under MS Word / WinWord only 0060h 1 word MS Word page count 0062h 8 byte Document properties 006Ah 1 byte Word version this file was made by 006Bh 1 bool Autosave flag 006Ch 1 word Word 5 page table 006Eh 1 word Mac bkmk (whatever) 0070h 1 word ?Offset of file name for autosave? 0072h 1 word Running head table 0074h 1 word Code page used making this document EXTENSION:DOC OCCURENCES:PC PROGRAMS:MS Word,Windows Write, WinWord SEE ALSO: VALIDATION: --------T-WORDPERFERCT FILES---------------- The WordPerfect files all have a common header - even tough I don't know anything else about them. OFFSET Count TYPE Description 0000h 4 char ID=255,"WPC" 0004h 4 byte unknown 0008h 1 byte ID=1 0009h 1 byte Filetype (see table 0003) (Table 0003) File types of WordPerfect files 01h - macro file 02h - WordPerfect help file 03h - keyboard definition file 0Ah - document file 0Bh - dictionary file 0Ch - thesaurus file 0Dh - block 0Eh - rectangular block 0Fh - column block 10h - printer resource file (PRS) 11h - setup file 12h - prefix information file 13h - printer resource file (ALL) 14h - display resource file (DRS) 15h - overlay file (WP.FIL) 16h - graphics file (WPG) 17h - hyphenation code module 18h - hyphenation data module 19h - macro resource file (MRS) 1Ah - graphics driver (WPD) 1Bh - hyphenation lex module EXTENSION:various OCCURENCES:PC --------W-WQ1------------------------------- Similar to the WKS spreadsheet files, the Quattro Pro spreadsheet files exist, and their header is somewhat similar. Info again from a magic file which makes only identification possible. OFFSET Count TYPE Description 0000h 1 dword ID=00000200h 0004h 1 char ID='Q' EXTENSION:WQ1 OCCURENCES:PC PROGRAMS:Borland Quattro Pro REFERENCE: SEE ALSO:WKS VALIDATION: --------M-XM-------------------------------- The .XM files (Extended Module) are multichannel MOD files created by Triton's FastTracker ][. They feature up to 32 channels and different effects. FT 2 is a shareware program. After the initial .XM header follows the pattern data, after the patterns follow the instruments. OFFSET Count TYPE Description 0000h 17 char ID="Extended module: " 0011h 20 char Module name, padded with zeroes 0025h 1 char ID=01Ah 0026h 20 char Tracker name 003Ah 1 word Tracker revision number, hi-byte is major version 003Ch 1 dword Header size 0040h 1 word Song length in patterns 0042h 1 word Restart position 0044h 1 word Number of channels 0046h 1 word Number of patterns (< 256) ="PAT" 0048h 1 word Number of instruments (<128) 004Ah 1 word Flags : 0 - Linear frequency table / Amiga freq. table 004Ch 1 word Default tempo 004Eh 1 word Default BPM 0050h 256 byte Pattern order table --- Pattern header The patterns are stored as ordinary MOD patterns, except that each note is stored as 5 bytes: ? 1 (byte) Note (0-71, 0 = C-0) +1 1 (byte) Instrument (0-128) +2 1 (byte) Volume column byte (see below) +3 1 (byte) Effect type +4 1 (byte) Effect parameter A simle packing scheme is also adopted, so that the patterns do not become TOO large: Since the MSB in the note value is never used, it is used for the compression.If the bit is set, then the other bits are interpreted as follows: bit 0 set: Note byte ollows 1 set: Instrument byte follows 2 set: Volume column byte follows 3 set: Effect byte follows 4 set: Effect data byte follows OFFSET Count TYPE Description 0000h 1 dword Length of pattern block/header ?? 0004h 1 byte Pattern pack type 0005h 1 word Number of rows in pattern (1..256) 0007h 1 word Size of pattern data ="PSZ" "PSZ" byte Pattern data --- Instrument header Each instrument has one or more sample headers following it. OFFSET Count TYPE Description 0000h 1 dword Instrument block/header size 0004h 22 char ASCII Instrument name, 0 padded ? 001Ah 1 byte Instrument type (always 0) 001Bh 1 word Number of samples in instrument 001Dh 1 dword Sample header size 0021h 96 byte Sample numbers for all notes 0081h 48 byte Points of volume envelope 00C1h 48 byte Points of panning envelope 0101h 1 byte Number of volume points 0102h 1 byte Number of panning points 0103h 1 byte Volume sustain point 0104h 1 byte Volume loop start point 0105h 1 byte Volume loop end point 0106h 1 byte Panning sustain point 0107h 1 byte Panning loop start point 0108h 1 byte Panning loop end point 0109h 1 byte Volume type, bitmapped 0 - Volume on 1 - Sustain on 2 - Loop on 010Ah 1 byte Panning type, bitmapped 0 - Panning on 1 - Sustain on 2 - Loop on 010Bh 1 byte Vibrato type 010Ch 1 byte Vibrato sweep 010Dh 1 byte Vibrato depth 010Eh 1 byte Vibrato rate 010Fh 1 word Volume fadeout 0111h 1 word Reserved --- Sample headers OFFSET Count TYPE Description 0000h 1 dword Sample length ="LEN" 0004h 1 dword Sample loop start 0008h 1 dword Sample loop length 000Ch 1 byte Volume 000Dh 1 byte Finetune for sample (-128..+127) +-127 is one half tone 000Eh 1 byte Sample type, bitmapped 0,1 : Loop type : 0 - no loop 1 - forward loop 2 - ping-pong loop 3 - reserved 4?: sample is 16-bit 000Fh 1 byte Sample pan 0010h 1 byte Relative note number (signed byte) (-96..+95), 0 -> C-4 sounds as C-4 0011h 1 byte Reserved 0012h 22 char ASCII name of sample, 0 padded 0013h "LEN" byte Sample data. The sample data is stored as delta compressed data like the ProTracker. EXTENSION:XM,MOD OCCURENCES: PROGRAMS: REFERENCE: SEE ALSO:MOD,S3M VALIDATION: --------A-ZIP------------------------------- The ZIP archives are created by the PkZIP/PkUnZIP combo produced by the PkWare company. The PkZIP programs have with LHArc and ARJ the best compression. The directory information is stored at the end of the archive, each local file in the archive begins with the following header; This header can be used to identify a ZIP file as such : OFFSET Count TYPE Description 0000h 4 char ID='PK',03,04 0004h 1 word Version needed to extract archive 0006h 1 word General purpose bit field (bit mapped) 0 - file is encrypted 1 - 8K/4K sliding dictionary used 2 - 3/2 Shannon-Fano trees were used 3-4 - unused 5-15 - used internally by ZIP Note: Bits 1 and 2 are undefined if the compression method is other than type 6 (Imploding). 0008h 1 word Compression method (see table 0010) 000Ah 1 dword Original DOS file date/time (see table 0009) 000Eh 1 dword 32-bit CRC of file (inverse??) 0012h 1 dword Compressed file size 0016h 1 dword Uncompressed file size 001Ah 1 word Length of filename ="LEN" 001Ch 1 word Length of extra field ="XLN" 001Eh "LEN" char path/filename 001Eh "XLN" char extra field +"LEN" After all the files, there comes the central directory structure. (Table 0010) PkZip compression types 0 - Stored / No compression 1 - Shrunk / LZW, 8K buffer, 9-13 bits with partial clearing 2 - Reduced-1 / Probalistic compression, lower 7 bits 3 - Reduced-2 / Probalistic compression, lower 6 bits 4 - Reduced-3 / Probalistic compression, lower 5 bits 5 - Reduced-4 / Probalistic compression, lower 4 bits 6 - Imploded / 2/3 Shanno-Fano trees, 4K/8K sliding dictionary --- Central directory structure The CDS is at the end of the archive and contains additional information about the files stored within the archive. OFFSET Count TYPE Description 0000h 4 char ID='PK',01,02 0004h 1 byte Version made by 0005h 1 byte Host OS (see table 0011) 0006h 1 byte Minimum version needed to extract 0007h 1 byte Target OS see above "Host OS" 0008h 1 word General purpose bit flag see above "General purpose bit flag" 000Ah 1 word Compression method see above "Compression method" 000Ch 1 dword DOS date / time of file 0010h 1 dword 32-bit CRC of file (see table 0009) 0014h 1 dword Compressed size of file 0018h 1 dword Uncompressed size of file 001Ch 1 word Length of filename ="LEN" 001Eh 1 word Length of extra field ="XLN" 0020h 1 word Length of file comment ="CMT" 0022h 1 word Disk number ?? 0024h 1 word Internal file attributes (bit mapped) 0 - file is apparently an ASCII/binary file 1-15 - unused 0026h 1 dword External file attributes (OS dependent) 002Ah 1 dword Relative offset of local header from the start of the first disk this file appears on 002Eh "LEN" char Filename / path; should not contain a drive or device letter, all slashes should be forward slashes '/'. 002Eh+ "XLN" char Extra field +"LEN" 002Eh "CMT" char File comment +"LEN" +"XLN" (Table 0011) PkZip Host OS table 0 - MS-DOS and OS/2 (FAT) 1 - Amiga 2 - VMS 3 - *nix 4 - VM/CMS 5 - Atari ST 6 - OS/2 1.2 extended file sys 7 - Macintosh 8-255 - unused --- End of central directory structure The End of Central Directory Structure header has following format : OFFSET Count TYPE Description 0000h 4 char ID='PK',05,06 0004h 1 word Number of this disk 0006h 1 word Number of disk with start of central directory 0008h 1 word Total number of file/path entries on this disk 000Ah 1 word Total number of entries in central dir 000Ch 1 dword Size of central directory 0010h 1 dword Offset of start of central directory relative to starting disk number 0014h 1 word Archive comment length ="CML" 0016h "CML" char Zip file comment EXTENSION:ZIP OCCURENCES:PC,Amiga,ST PROGRAMS:PkZIP,WinZIP REFERENCE:Technote.APP --------A-ZOO------------------------------- The ZOO archive program by Raoul Dhesi is a file compression program now superceeded in both compression and speed by most other compression programs. The archive header looks like this : OFFSET Count TYPE Description 0000h 20 char Archive header text, ^Z terminated, null padded 0014h 1 dword ID=0FDC4A7DCh 0018h 1 dword Offset of first file in archive 001Ch 1 dword Offset of ???? 0020h 1 byte Version archive was made by 0021h 1 byte Minimum version needed to extract Each stored file has its own header, which looks like this : OFFSET Count TYPE Description 0000h 1 dword ID=0FDC4A7DCh 0004h 1 byte Type of directory entry 0005h 1 byte Compression method : 0 - stored 1 - Crunched : LZW, 4K buffer, var len (9-13 bits) 0006h 1 dword Offset of next directory entry 000Ah 1 dword Offset of next header 000Dh 1 word Original date / time of file (see table 0009) 0012h 1 word CRC-16 of file 0014h 1 dword Uncompressed size of file 0018h 1 dword Compressed size of file 001Ch 1 byte Version this file was compressed by 001Dh 1 byte Minimum version needed to extract 001Eh 1 byte Deleted flag 0 - file in archive 1 - file is considered deleted 001Fh 1 dword Offset of comment field, 0 if none 0023h 1 word Length of comment field 0025h ? char ASCIIZ path / filename EXTENSION:ZOO OCCURENCES:PC PROGRAMS:ZOO.EXE REFERENCE: VALIDATION: --------S-ZyXEL----------------------------- The ZyXEL Modems are capable of digitizing speech, the ZFAX software and answering machine software like VoiceConnect store the sampled data in those files. The Modems are capable of compressing the data down to 19.2k CPS (ADPCM) and 9.6k CPS (CELP), the algorithms for the compression may be found in the ZyxelVoc package by N. Igl, but as the firmware on the modems changes, so might the compression algorithm. Playback on the modem is always possible. OFFSET Count TYPE Description 0000h 5 char ID='ZyXEL' 0005h 1 byte 02h, ??? format tag 0006h 4 byte reserved 000Ah 1 word Compression scheme 0 - CELP 1 - 2 bit ADPCM 2 - 3 bit ADPCM 000Ch 4 byte reserved 0010h ? ???? Raw Data The voice data is just the data received from U1496 Modem/Fax. EXTENSION:ZVD,ZYX OCCURENCES:PC PROGRAMS:Voice Connect,ZFAX REFERENCE:ZYXELVOC.* VALIDATION:NONE --------!-ALGORITHMS------------------------ Some algorithms used for encoding images etc... --- TIFF PackBits algorithm Abstract This document describes a simple compression scheme for bilevel scanned and paint type files. Motivation The TIFF specification defines a number of compression schemes. Compression type 1 is really no compression, other than basic pixel packing. Compression type 2, based on CCITT 1D compression, is powerful, but not trivial to implement. Compression type 5 is typically very effective for most bilevel images, as well as many deeper images such as palette color and grayscale images, but is also not trivial to implement. PackBits is a simple but often effective alternative. Description Several good schemes were already in use in various settings. We somewhat arbitrarily picked the Macintosh PackBits scheme. It is byte oriented, so there is no problem with word alignment. And it has a good worst case behavior (at most 1 extra byte for every 128 input bytes). For Macintosh users, there are toolbox utilities PackBits and UnPackBits that will do the work for you, but it is easy to implement your own routines. A pseudo code fragment to unpack might look like this: Loop until you get the number of unpacked bytes you are expecting: Read the next source byte into n. If n is between 0 and 127 inclusive, copy the next n+1 bytes literally. Else if n is between -127 and -1 inclusive, copy the next byte -n+1 times. Else if n is 128, noop. Endloop In the inverse routine, it's best to encode a 2-byte repeat run as a replicate run except when preceded and followed by a literal run, in which case it's best to merge the three into one literal run. Always encode 3-byte repeats as replicate runs. So that's the algorithm. Here are some other rules: o Each row must be packed separately. Do not compress across row boundaries. o The number of uncompressed bytes per row is defined to be (ImageWidth + 7) / 8. If the uncompressed bitmap is required to have an even number of bytes per row, decompress into word- aligned buffers. o If a run is larger than 128 bytes, simply encode the remainder of the run as one or more additional replicate runs. When PackBits data is uncompressed, the result should be interpreted as per compression type 1 (no compression). --- TIFF LZW Compression Abstract This document describes an adaptive compression scheme for raster images. Reference Terry A. Welch, "A Technique for High Performance Data Compression", IEEE Computer, vol. 17 no. 6 (June 1984). Describes the basic Lempel-Ziv & Welch (LZW) algorithm. The author's goal in the article is to describe a hardware-based compressor that could be built into a disk controller or database engine, and used on all types of data. There is no specific discussion of raster images. We intend to give sufficient information in this Appendix so that the article is not required reading. Requirements A compression scheme with the following characteristics should work well in a desktop publishing environment: o Must work well for images of any bit depth, including images deeper than 8 bits per sample. o Must be effective: an average compression ratio of at least 2:1 or better. And it must have a reasonable worst-case behavior, in case something really strange is thrown at it. o Should not depend on small variations between pixels. Palette color images tend to contain abrupt changes in index values, due to common patterning and dithering techniques. These abrupt changes do tend to be repetitive, however, and the scheme should make use of this fact. o For images generated by paint programs, the scheme should not depend on a particular pattern width. 8x8 pixel patterns are common now, but we should not assume that this situation will not change. o Must be fast. It should not take more than 5 seconds to decompress a 100K byte grayscale image on a 68020- or 386-based computer. Compression can be slower, but probably not by more than a factor of 2 or 3. o The level of implementation complexity must be reasonable. We would like something that can be implemented in no more than a couple of weeks by a competent software engineer with some experience in image processing. The compiled code for compression and decompression combined should be no more than about 10K. o Does not require floating point software or hardware. The following sections describe an algorithm based on the "LZW" (Lempel-Ziv & Welch) technique that meets the above requirements. In addition meeting our requirements, LZW has the following characteristics: o LZW is fully reversible. All information is preserved. But if noise or information is removed from an image, perhaps by smoothing or zeroing some low-order bitplanes, LZW compresses images to a smaller size. Thus, 5-bit, 6-bit, or 7-bit data masquerading as 8-bit data compresses better than true 8-bit data. Smooth images also compress better than noisy images, and simple images compress better than complex images. o On a 68082- or 386-based computer, LZW software can be written to compress at between 30K and 80K bytes per second, depending on image characteristics. LZW decompression speeds are typically about 50K bytes per second. o LZW works well on bilevel images, too. It always beats PackBits, and generally ties CCITT 1D (Modified Huffman) compression, on our test images. Tying CCITT 1D is impressive in that LZW seems to be considerably faster than CCITT 1D, at least in our implementation. o Our implementation is written in C, and compiles to about 2K bytes of object code each for the compressor and decompressor. o One of the nice things about LZW is that it is used quite widely in other applications such as archival programs, and is therefore more of a known quantity. The Algorithm Each strip is compressed independently. We strongly recommend that RowsPerStrip be chosen such that each strip contains about 8K bytes before compression. We want to keep the strips small enough so that the compressed and uncompressed versions of the strip can be kept entirely in memory even on small machines, but large enough to maintain nearly optimal compression ratios. The LZW algorithm is based on a translation table, or string table, that maps strings of input characters into codes. The TIFF implementation uses variable-length codes, with a maximum code length of 12 bits. This string table is different for every strip, and, remarkably, does not need to be kept around for the decompressor. The trick is to make the decompressor automatically build the same table as is built when compressing the data. We use a C-like pseudocode to describe the coding scheme: InitializeStringTable(); WriteCode(ClearCode); Omega = the empty string; for each character in the strip { K = GetNextCharacter(); if Omega+K is in the string table { Omega = Omega+K; /* string concatenation */ } else { WriteCode (CodeFromString(Omega)); AddTableEntry(Omega+K); Omega = K; } } /* end of for loop */ WriteCode (CodeFromString(Omega)); WriteCode (EndOfInformation); That's it. The scheme is simple, although it is fairly challenging to implement efficiently. But we need a few explanations before we go on to decompression. The "characters" that make up the LZW strings are bytes containing TIFF uncompressed (Compression=1) image data, in our implementation. For example, if BitsPerSample is 4, each 8-bit LZW character will contain two 4-bit pixels. If BitsPerSample is 16, each 16-bit pixel will span two 8-bit LZW characters. (It is also possible to implement a version of LZW where the LZW character depth equals BitsPerSample, as was described by Draft 2 of Revision 5.0. But there is a major problem with this approach. If BitsPerSample is greater than 11, we can not use 12-bit-maximum codes, so that the resulting LZW table is unacceptably large. Fortunately, due to the adaptive nature of LZW, we do not pay a significant compression ratio penalty for combining several pixels into one byte before compressing. For example, our 4-bit sample images compressed about 3 percent worse, and our 1-bit images compressed about 5 percent better. And it is easier to write an LZW compressor that always uses the same character depth than it is to write one which can handle varying depths.) We can now describe some of the routine and variable references in our pseudocode: InitializeStringTable() initializes the string table to contain all possible single-character strings. There are 256 of them, numbered 0 through 255, since our characters are bytes. WriteCode() writes a code to the output stream. The first code written is a Clear code, which is defined to be code #256. Omega is our "prefix string." GetNextCharacter() retrieves the next character value from the input stream. This will be number between 0 and 255, since our characters are bytes. The "+" signs indicate string concatenation. AddTableEntry() adds a table entry. (InitializeStringTable() has already put 256 entries in our table. Each entry consists of a single-character string, and its associated code value, which is, in our application, identical to the character itself. That is, the 0th entry in our table consists of the string <0>, with corresponding code value of <0>, the 1st entry in the table consists of the string <1>, with corresponding code value of <1>, ..., and the 255th entry in our table consists of the string <255>, with corresponding code value of <255>.) So the first entry that we add to our string table will be at position 256, right? Well, not quite, since we will reserve code #256 for a special "Clear" code, and code #257 for a special "EndOfInformation" code that we will write out at the end of the strip. So the first multiple-character entry added to the string table will be at position 258. Let's try an example. Suppose we have input data that looks like: Pixel 0: <7> Pixel 1: <7> Pixel 2: <7> Pixel 3: <8> Pixel 4: <8> Pixel 5: <7> Pixel 6: <7> Pixel 7: <6> Pixel 8: <6> First, we read Pixel 0 into K. OmegaK is then simply <7>, since Omega is the empty string at this point. Is the string <7> already in the string table? Of course, since all single character strings were put in the table by InitializeStringTable(). So set Omega equal to <7>, and go to the top of the loop. Read Pixel 1 into K. Does OmegaK (<7><7>) exist in the string table? No, so we get to do some real work. We write the code associated with Omega to output (write <7> to output), and add OmegaK (<7><7>) to the table as entry 258. Store K (<7>) into Omega. Note that although we have added the string consisting of Pixel 0 and Pixel 1 to the table, we "re-use" Pixel 1 as the beginning of the next string. Back at the top of the loop. We read Pixel 2 into K. Does OmegaK (<7><7>) exist in the string table? Yes, the entry we just added, entry 258, contains exactly <7><7>. So we just add K onto the end of Omega, so that Omega is now <7><7>. Back at the top of the loop. We read Pixel 3 into K. Does OmegaK (<7><7><8>) exist in the string table? No, so write the code associated with Omega (<258>) to output, and add OmegaK to the table as entry 259. Store K (<8>) into Omega. Back at the top of the loop. We read Pixel 4 into K. Does OmegaK (<8><8>) exist in the string table? No, so write the code associated with Omega (<8>) to output, and add OmegaK to the table as entry 260. Store K (<8>) into Omega. Continuing, we get the following results: After reading: We write to output: And add table entry: Pixel 0 Pixel 1 <7> 258: <7><7> Pixel 2 Pixel 3 <258> 259: <7><7><8> Pixel 4 <8> 260: <8><8> Pixel 5 <8> 261: <8><7> Pixel 6 Pixel 7 <258> 262: <7><7><6> Pixel 8 <6> 263: <6><6> WriteCode() also requires some explanation. The output code stream, <7><258><8><8><258><6>... in our example, should be written using as few bits as possible. When we are just starting out, we can use 9-bit codes, since our new string table entries are greater than 255 but less than 512. But when we add table entry 512, we must switch to 10-bit codes. Likewise, we switch to 11-bit codes at 1024, and 12-bit codes at 2048. We will somewhat arbitrarily limit ourselves to 12-bit codes, so that our table can have at most 4096 entries. If we push it any farther, tables tend to get too large. What happens if we run out of room in our string table? This is where the afore-mentioned Clear code comes in. As soon as we use entry 4094, we write out a (12-bit) Clear code. (If we wait any dworder to write the Clear code, the decompressor might try to interpret the Clear code as a 13-bit code.) At this point, the compressor re-initializes the string table and starts writing out 9-bit codes again. Note that whenever you write a code and add a table entry, Omega is not left empty. It contains exactly one character. Be careful not to lose it when you write an end-of-table Clear code. You can either write it out as a 12-bit code before writing the Clear code, in which case you will want to do it right after adding table entry 4093, or after the clear code as a 9-bit code. Decompression gives the same result in either case. To make things a little simpler for the decompressor, we will require that each strip begins with a Clear code, and ends with an EndOfInformation code. Every LZW-compressed strip must begin on a byte boundary. It need not begin on a word boundary. LZW compression codes are stored into bytes in high-to-low-order fashion, i.e., FillOrder is assumed to be 1. The compressed codes are written as bytes, not words, so that the compressed data will be identical regardless of whether it is an "II" or "MM" file. Note that the LZW string table is a continuously updated history of the strings that have been encountered in the data. It thus reflects the characteristics of the data, providing a high degree of adaptability. LZW Decoding The procedure for decompression is a little more complicated, but still not too bad: while ((Code = GetNextCode()) != EoiCode) { if (Code == ClearCode) { InitializeTable(); Code = GetNextCode(); if (Code == EoiCode) break; WriteString(StringFromCode(Code)); OldCode = Code; } /* end of ClearCode case */ else { if (IsInTable(Code)) { WriteString(StringFromCode(Code)); AddStringToTable(StringFromCode(OldCode)+ FirstChar(StringFromCode(Code))); OldCode = Code; } else { OutString = StringFromCode(OldCode) + FirstChar(StringFromCode(OldCode)); WriteString(OutString); AddStringToTable(OutString); OldCode = Code; } } /* end of not-ClearCode case */ } /* end of while loop */ The function GetNextCode() retrieves the next code from the LZW- coded data. It must keep track of bit boundaries. It knows that the first code that it gets will be a 9-bit code. We add a table entry each time we get a code, so GetNextCode() must switch over to 10-bit codes as soon as string #511 is stored into the table. The function StringFromCode() gets the string associated with a particular code from the string table. The function AddStringToTable() adds a string to the string table. The "+" sign joining the two parts of the argument to AddStringToTable indicate string concatenation. StringFromCode() looks up the string associated with a given code. WriteString() adds a string to the output stream. When SamplesPerPixel Is Greater Than 1 We have so far described the compression scheme as if SamplesPerPixel were always 1, as will be be the case with palette color and grayscale images. But what do we do with RGB image data? Tests on our sample images indicate that the LZW compression ratio is nearly identical regardless of whether PlanarConfiguration=1 or PlanarConfiguration=2, for RGB images. So use whichever configuration you prefer, and simply compress the bytes in the strip. It is worth cautioning that compression ratios on our test RGB images were disappointing low: somewhere between 1.1 to 1 and 1.5 to 1, depending on the image. Vendors are urged to do what they can to remove as much noise from their images as possible. Preliminary tests indicate that significantly better compression ratios are possible with less noisy images. Even something as simple as zeroing out one or two least-significant bitplanes may be quite effective, with little or no perceptible image degradation. Implementation The exact structure of the string table and the method used to determine if a string is already in the table are probably the most significant design decisions in the implementation of a LZW compressor and decompressor. Hashing has been suggested as a useful technique for the compressor. We have chosen a tree based approach, with good results. The decompressor is actually more straightforward, as well as faster, since no search is involved - strings can be accessed directly by code value. Performance Many people do not realize that the performance of any compression scheme depends greatly on the type of data to which it is applied. A scheme that works well on one data set may do poorly on the next. But since we do not want to burden the world with too many compression schemes, an adaptive scheme such as LZW that performs quite well on a wide range of images is very desirable. LZW may not always give optimal compression ratios, but its adaptive nature and relative simplicity seem to make it a good choice. Experiments thus far indicate that we can expect compression ratios of between 1.5 and 3.0 to 1 from LZW, with no loss of data, on continuous tone grayscale scanned images. If we zero the least significant one or two bitplanes of 8-bit data, higher ratios can be achieved. These bitplanes often consist chiefly of noise, in which case little or no loss in image quality will be perceived. Palette color images created in a paint program generally compress much better than continuous tone scanned images, since paint images tend to be more repetitive. It is not unusual to achieve compression ratios of 10 to 1 or better when using LZW on palette color paint images. By way of comparison, PackBits, used in TIFF for black and white bilevel images, does not do well on color paint images, much less continuous tone grayscale and color images. 1.2 to 1 seemed to be about average for 4-bit images, and 8-bit images are worse. It has been suggested that the CCITT 1D scheme could be used for continuous tone images, by compressing each bitplane separately. No doubt some compression could be achieved, but it seems unlikely that a scheme based on a fixed table that is optimized for word black runs separated by dworder white runs would be a very good choice on any of the bitplanes. It would do quite well on the high-order bitplanes (but so would a simpler scheme like PackBits), and would do quite poorly on the low-order bitplanes. We believe that the compression ratios would generally not be very impressive, and the process would in addition be quite slow. Splitting the pixels into bitplanes and putting them back together is somewhat expensive, and the coding is also fairly slow when implemented in software. Another approach that has been suggested uses uses a 2D differencing step following by coding the differences using a fixed table of variable-length codes. This type of scheme works quite well on many 8-bit grayscale images, and is probably simpler to implement than LZW. But it has a number of disadvantages when used on a wide variety of images. First, it is not adaptive. This makes a big difference when compressing data such as 8-bit images that have been "sharpened" using one of the standard techniques. Such images tend to get larger instead of smaller when compressed. Another disadvantage of these schemes is that they do not do well with a wide range of bit depths. The built-in code table has to be optimized for a particular bit depth in order to be effective. Finally, we should mention "lossy" compression schemes. Extensive research has been done in the area of lossy, or non- information-preserving image compression. These techniques generally yield much higher compression ratios than can be achieved by fully-reversible, information-preserving image compression techniques such as PackBits and LZW. Some disadvantages: many of the lossy techniques are so computationally expensive that hardware assists are required. Others are so complicated that most microcomputer software vendors could not afford either the expense of implementation or the increase in application object code size. Yet others sacrifice enough image quality to make them unsuitable for publishing use. In spite of these difficulties, we believe that there will one day be a standardized lossy compression scheme for full color images that will be usable for publishing applications on microcomputers. An International Standards Organization group, ISO/IEC/JTC1/SC2/WG8, in cooperation with CCITT Study Group VIII, is hard at work on a scheme that might be appropriate. We expect that a future revision of TIFF will incorporate this scheme once it is finalized, if it turns out to satisfy the needs of desktop publishers and others in the microcomputer community. This will augment, not replace, LZW as an approved TIFF compression scheme. LZW will very likely remain the scheme of choice for Palette color images, and perhaps 4-bit grayscale images, and may well overtake CCITT 1D and PackBits for bilevel images. Future LZW Extensions Some images compress better using LZW coding if they are first subjected to a process wherein each pixel value is replaced by the difference between the pixel and the preceding pixel. Performing this differencing in two dimensions helps some images even more. However, many images do not compress better with this extra preprocessing, and for a significant number of images, the compression ratio is actually worse. We are therefore not making differencing an integral part of the TIFF LZW compression scheme. However, it is possible that a "prediction" stage like differencing may exist which is effective over a broad range of images. If such a scheme is found, it may be incorporated in the next major TIFF revision. If so, a new value will be defined for the new "Predictor" TIFF tag. Therefore, all TIFF readers that read LZW files must pay attention to the Predictor tag. If it is 1, which is the default case, LZW decompression may proceed safely. If it is not 1, and the reader does not recognize the specified prediction scheme, the reader should give up. Acknowledgements The original LZW reference has already been given. The use of ClearCode as a technique to handle overflow was borrowed from the compression scheme used by the Graphics Interchange Format (GIF), a small-color-paint-image-file format used by CompuServe that also is an adaptation of the LZW technique. Joff Morgan and Eric Robinson of Aldus were each instrumental in their own way in getting LZW off the ground. The TIFF predictor algorithm The idea is to make use of the fact that many continuous tone images rarely vary much in pixel value from one pixel to the next. In such images, if we replace the pixel values by differences between consecutive pixels, many of the differences should be 0, plus or minus 1, and so on. This reduces the apparent information content, and thus allows LZW to encode the data more compactly. Assuming 8-bit grayscale pixels for the moment, a basic C implementation might look something like this: char image[ ][ ]; int row, col; /* take horizontal differences: */ for (row = 0; row < nrows; row++) for (col = ncols - 1; col >= 1; col--) image[row][col] -= image[row][col-1]; If we don't have 8-bit samples, we need to work a little harder, so that we can make better use of the architecture of most CPUs. Suppose we have 4-bit samples, packed two to a byte, in normal TIFF uncompressed (i.e., Compression=1) fashion. In order to find differences, we want to first expand each 4-bit sample into an 8-bit byte, so that we have one sample per byte, low-order justified. We then perform the above horizontal differencing. Once the differencing has been completed, we then repack the 4- bit differences two to a byte, in normal TIFF uncompressed fashion. If the samples are greater than 8 bits deep, expanding the samples into 16-bit words instead of 8-bit bytes seems like the best way to perform the subtraction on most computers. Note that we have not lost any data up to this point, nor will we lose any data later on. It might at first seem that our differencing might turn 8-bit samples into 9-bit differences, 4- bit samples into 5-bit differences, and so on. But it turns out that we can completely ignore the "overflow" bits caused by subtracting a larger number from a smaller number and still reverse the process without error. Normal twos complement arithmetic does just what we want. Try an example by hand if you need more convincing. Up to this point we have implicitly assumed that we are compressing bilevel or grayscale images. An additional consideration arises in the case of color images. If PlanarConfiguration is 2, there is no problem. Differencing proceeds the same way as it would for grayscale data. If PlanarConfiguration is 1, however, things get a little trickier. If we didn't do anything special, we would be subtracting red sample values from green sample values, green sample values from blue sample values, and blue sample values from red sample values, which would not give the LZW coding stage much redundancy to work with. So we will do our horizontal differences with an offset of SamplesPerPixel (3, in the RGB case). In other words, we will subtract red from red, green from green, and blue from blue. The LZW coding stage is identical to the SamplesPerPixel=1 case. We require that BitsPerSample be the same for all 3 samples. Results and guidelines LZW without differencing works well for 1-bit images, 4-bit grayscale images, and synthetic color images. But natural 24-bit color images and some 8-bit grayscale images do much better with differencing. For example, our 24-bit natural test images hardly compressed at all using "plain" LZW: the average compression ratio was 1.04 to 1. The average compression ratio with horizontal differencing was 1.40 to 1. (A compression ratio of 1.40 to 1 means that if the uncompressed image is 1.40MB in size, the compressed version is 1MB in size.) Although the combination of LZW coding with horizontal differencing does not result in any loss of data, it may be worthwhile in some situations to give up some information by removing as much noise as possible from the image data before doing the differencing, especially with 8-bit samples. The simplest way to get rid of noise is to mask off one or two low- order bits of each 8-bit sample. On our 24-bit test images, LZW with horizontal differencing yielded an average compression ratio of 1.4 to 1. When the low-order bit was masked from each sample, the compression ratio climbed to 1.8 to 1; the compression ratio was 2.4 to 1 when masking two bits, and 3.4 to 1 when masking three bits. Of course, the more you mask, the more you risk losing useful information adword with the noise. We encourage you to experiment to find the best compromise for your device. For some applications it may be useful to let the user make the final decision. Interestingly, most of our RGB images compressed slightly better using PlanarConfiguration=1. One might think that compressing the red, green, and blue difference planes separately (PlanarConfiguration=2) might give better compression results than mixing the differences together before compressing (PlanarConfiguration=1), but this does not appear to be the case. Incidentally, we tried taking both horizontal and vertical differences, but the extra complexity of two-dimensional differencing did not appear to pay off for most of our test images. About one third of the images compressed slightly better with two-dimensional differencing, about one third compressed slightly worse, and the rest were about the same. --- BMP RLE_8 compression The BMP can be compressed in two modes, absolute mode and RLE mode. Both modes can occur anywhere in a single bitmap. The RLE mode is a simple RLE mechanism, the first byte contains the count, the second byte the pixel to be replicatet. If the count byte is 0, the second byte is a special, like EOL or delta. In absolute mode, the second byte contains the number of bytes to be copied litteraly. Each absolute run must be word-aligned that means you will may have to add an aditional padding byte which is not included in the count. After an absolute run, RLE compression continues. Second byte Meaning 0 End of line 1 End of bitmap 2 Delta. The next two bytes are the horizontal and vertical offsets from the current position to the next pixel. 3-255 Switch to absolute mode --- BMP RLE_4 compression RLE_4 compression knows the two modes of the RLE_8 compression, absolute and RLE. In the RLE mode, the first byte contains the count of pixels to draw, the second byte contains in its two nibbles the indices off the pixel colors, the higher 4 bits are the left pixel, the lower 4 bits are the right pixel. Note that two-color runs are possible to encode with RLE_4 through this. --- Protracker sample compression / decompression Get the number of sample bytes to process. Call this SamplesLeft. Set Delta counter to 0. DO Get a byte from the buffer. Store the byte in Temp. Subtract the Delta counter from the byte. Store it in the buffer. Move the Temp byte into the Delta Counter Decrement SamplesLeft. WHILE(SamplesLeft <> 0) The technique for conversion back to the raw data is: Get the number of sample bytes to process. Call this SamplesLeft. Set Delta counter to 0. DO Get a byte from the buffer. Add onto the byte the Delta Counter. Store the byte in Delta Counter. Store the byte in Temp. Decrement SamplesLeft. WHILE(SamplesLeft <> 0) --------!-ADDRESSES------------------------- Useful adresses International Midi Association 5316 West 57th Street Los Angeles, CA 90056 xx1-213-649-6434 xx1-213-215-3380 fax --------!-HISTORY--------------------------- History is kept within this file for convenience whilst editing ... Date format is european/german, just for my convenience. Date Who What 14.03.95 MM Introduced tables Last table number=0012 05.06.95 MM + PTM format 25.07.95 MM + PIF format + Paradox format description 11.08.95 MM + MS Compress variants 18.11.95 MM + ARC enhancements, caveats + HA files 22.11.95 MM + Parts of the .CRD files 01.02.96 MM + PNG structure 02.02.96 MM + More on JPEG + TARGA entry created