********************************************************************** * This file contains header_info about these file_formats : * * * * 669/IFF-voice/amiga exe/AMS/ARC/ARJ/AU/BGI/BMP/CEG/CEL/CHR/ * * CMF/COL/COM/CORE/CPI/Dbase II/Dbase III/DBase IV/DMF/DMS/DWC/ * * EFE/EXE/FAR/FLC/TWE/OPT/FLI/FON/FPT/FSM/GF1 PAT/GIF/GZIP/GKH/ * * GL/GRIB/HSI/HYP/IFF/INS/JPG/LBM/LBR/LZH/MID/MOD/MSK/MTM/ * * MZ-EXE/NE-EXE/NG/OBJ/OS2-hlp/PBM/PCX/PIC/PICpro/PLY/PS16/QFX/ * * RAW/RDIB/RIFF/RIFX/S3I/S3M/SND/SQZ/SDK/SDS/SMP/STM/TAR/TIFF/ * * TXW/UWF/ULT/WAVE/WKS/DOC/WP-file/WQ1/XM/ZIP/ZOO/Zyxel * * * ********************************************************************** File format list Release 1.00 Last change 05/28/95 This compilation is Copyright (c) 1994,1995 Max Maischein This is only the beta version. Please do not redistribute, as the format might still change. --------!-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 Max Maischein, 2:244/1106.17 Max_Maischein@spam.fido.de corion@hera.rbi.uni-frankfurt.de Corion on 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 a - Animations B - Binary files for compilers etc. H - Help file I - Images, bit maps D - Data support files E - Executable files 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) R - Resource data files S - Sound files (WAV,VOC) 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. 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 1 - unpacked (obsolete) 2 - unpacked 3 - packed 4 - squeezed (after packing) 5 - crunched (obsolete) 6 - crunched (after packing) (obsolete) 7 - crunched (after packing, using faster hash algorithm) 8 - crunched (after packing, using dynamic LZW variations) 9 - Squashed c/o Phil Katz (no packing) (var. on crunching) 10 - crushed (PAK only) 11 - distilled (PAK only) (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: 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 Byte 2 7 6 5 4 3 2 1 0 bit # op2 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 ********* 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. OFFSET Count TYPE Description 0000h 4 char ID='core' 0176h 1 word Executable type 0176h - 386 executable ************ >566 short 072401 386 executable >564 short 0535 B370 executable >564 short 056401 B370 executable >564 short 0530 B370 executable >564 short 054001 B370 executable >564 short 0537 XA370 executable >564 short 057401 XA370 executable >564 short 055001 XA370 executable >564 short 0532 XA370 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-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-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 : 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 high bit of the packet type is set, the remaining 7 bits are a 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. 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:??? --------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. 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 , 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 --------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 WORD offset to return thunks or start of gangload area 003Ah WORD offset to segment reference thunks or length of gangload area 003Ch WORD minimum code swap area size 003Eh 2 BYTEs 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 --------D-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 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 --------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 ****** 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 --------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 --------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 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. ** The following fields are not recommended except perhaps for local use ** They have either been superseded by other fields, have been found to have serious drawbacks, or are simply not as useful as once thought. CellLength Tag = 265 (109) Type = word N = 1 The length, in 1-bit samples, of the dithering/halftoning matrix. Assumes that Threshholding = 2. This field, plus CellWidth and Threshholding, are problematic because they cannot safely be used to reverse-engineer grayscale image data out of dithered/halftoned black-and-white data, which is their only plausible purpose. The only "right" way to do it is to not bother with anything like these fields, and instead write some sophisticated pattern-matching software that can handle screen angles that are not multiples of 45 degrees, and other such challenging dithered/halftoned data. FillOrder Tag = 266 (10A) Type = word N = 1 The order of data values within a byte. 1 = most significant bits of the byte are filled first. 2 = least significant bits are filled first. Since little interest has been expressed in least-significant fill order to date, and since it is easy and inexpensive for writers to reverse bit order (use a 256-byte lookup table), FillOrder=2 is for private (non-interchange) use only. FreeByteCounts Tag = 289 (121) Type = dword For each "free block" in the file, the number of bytes in the block. FreeOffsets Tag = 288 (120) Type = dword For each "free block" in the file, its byte offset. MaxSampleValue Tag = 281 (119) Type = word N = SamplesPerPixel Default is 2**(BitsPerSample) - 1. The maximum used sample value. Statistical use only. MinSampleValue Tag = 280 (118) Type = word N = SamplesPerPixel Default is 0. The minimum used sample value. Statistical use only. 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: --------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 ************ IALL I 49+NTL*32+NOS*SSIbyte[256] IPattern Sequence Table I IALL I305+NTL*32+NOS*SSIbyte INumber of tracks (NOT) Base 0 I I I306+NTL*32+NOS*SSIbyte INumber of patterns (NOP) Base 0 I I2.1-2.2I307+NTL*32+NOS*SSIbyte[NOT] IPAN-position table I I I I I[0 left]-[F right] I IALL I307+NTL*32+NOS*SSI IEvent structure (see event struct) I I I+NOT Ivaries I I Ã-------+-----------------+---------------+-----------------------------------´ IThe remainder of the file is the raw sample data. (signed) I À-----------------------------------------------------------------------------Ù Ú-----------------------------------------------------------------------------¿ ISample Structure (length: ULT 1.0 - ULT 2.1 = 64bytes I ULT 2.2 = 66bytes) I Ã-----------------------------------------------------------------------------´ ISamplename : 32 bytes Sample name I IDosName : 12 bytes when you load a sample into UT, I I it records the file name here I ILoopStart : dbl word loop start point I ILoopEnd : dbl word loop end point I ISizeStart : dbl word see below I ISizeEnd : dbl word see below I Ivolume : byte UT uses a logarithmic volume setting, ranging I I from 0-255 (ULT 1.0) I I from ULT 2.0: uses linear Volume ranging from 0-255 I IBidi Loop : byte see below I IFineTune : word Fine tune setting, uses full word value I I Linear Finetune I Ã---Additional-in-ULT-2.2-----------------------------------------------------´ IC2-Freqency: word This is the frequency, UT uses to play a middle C, I I all other notes are calculated relatively to this I I value. I À-----------------------------------------------------------------------------Ù 8 Bit Samples: -------------- SizeStart: The SizeStart is the starting offset of the sample. This seems to tell UT how to load the sample into the Gus's onboard memory. All the files I have worked with start with a value of 32 for the first sample, and the previous SizeEnd value for all sample after that. (See Example below) If the previous sample was 16bit, then SizeStart = (Last SizeEnd * 2) SizeEnd : Like the SizeStart, SizeEnd seems to tell UT where to load the sample into the Gus's onboard memory. SizeEnd equal SizeStart + the length of the sample. Example: -------- If a UT file had 3 samples, 1st 12000 bytes, 2nd 5600 bytes, 3rd 8000 byte. The SizeStart and SizeEnd would look like this: Sample SizeStart SizeEnd 1st 32 12032 2nd 12032 17632 3rd 17632 25632 ***Note*** Samples may NOT cross 256k boundaries. If a sample is too large to fit into the remaining space, its Sizestart will equal the start of the next 256k boundary. UT does keep track of the free space at the top of the 256k boundaries, and will load a sample in there if it will fit. Example : EndSize = 252144 If the next sample was 12000 bytes, its SizeStart would be 262144, not 252144. Note that this leaves 10000 bytes unused. If any of the following sample could fit between 252144 and 262144, its Sizestart would be 252144. Say that 2 samples after the 12000 byte sample we had a sample that was only 5000 bytes long. Its SizeStart would be 252144 and its SizeEnd would be 257144. This also applies to 16 Bit Samples. 16 Bit Samples: --------------- 16 bit samples are handled a little different then 8 bit samples. The SizeStart variable is calculated by dividing offset (last SizeEnd) by 2. The SizeEnd variable equals SizeStart + (SampleLength / 2). If the first sample is 16bit, then SizeStart = 16. Example : sample1 = 8bit, 1000 bytes sample2 = 16bit, 5000 bytes sample1 SizeStart = 32 SizeEnd = 1032 (32 + 1000) sample2 SizeStart = 516 (offset (1032) / 2) SizeEnd = 3016 (516 + (5000/2)) ***Note*** If a 16bit sample is loaded into banks 2,3, or 4 the SizeStart variable will be (offset / 2) + 262144 (bank 2) (offset / 2) + 524288 (bank 3) (offset / 2) + 786432 (bank 4) The SizeEnd variable will be SizeStart + (SampleLength / 2) + 262144 (bank 2) SizeStart + (SampleLength / 2) + 524288 (bank 3) SizeStart + (SampleLength / 2) + 786432 (bank 4) BiDi Loop : (Bidirectional Loop) -------------------------------- UT takes advantage of the Gus's ability to loop a sample in several different ways. By setting the Bidi Loop, the sample can be played forward or backwards, looped or not looped. The Bidi variable also tracks the sample resolution (8 or 16 bit). The following table shows the possible values of the Bidi Loop. Bidi = 0 : No looping, forward playback, 8bit sample Bidi = 4 : No Looping, forward playback, 16bit sample Bidi = 8 : Loop Sample, forward playback, 8bit sample Bidi = 12 : Loop Sample, forward playback, 16bit sample Bidi = 24 : Loop Sample, reverse playback 8bit sample Bidi = 28 : Loop Sample, reverse playback, 16bit sample Ú-----------------------------------------------------------------------------¿ IEvent Structure I Ã-----------------------------------------------------------------------------´ INote : byte (See note table below) I ISampleNumber : byte (Sample Number) I IEffect1 : nib (Effect1) I IEffect2 : nib (Effect2) I IEffectVar : word (Effect variables) I I I I The High order byte of EffectVar is the Effect variable for Effect1. I I The Low order byte of EffectVar is the Effect variable for Effect2. I I***(Note)*** I I UT uses a form of compression on repetitive events. Say we read in the firstI I byte, if it = $FC then this signifies a repeat block. The next byte is the I I repeat count. followed by the event structure to repeat. I I If the first byte read does NOT = $FC then this is the note of the event. I I So repeat blocks will be 7 bytes long : RepFlag : byte ($FC) I I RepCount : byte I I note : byte I I samplenumber : byte I I effect1 : nib I I effect2 : nib I I effectVar : word I I I I ! Repeat blocks do NOT bridge patterns. ! I Ã-----------------------------------------------------------------------------´ INote Table I Ã-----------------------------------------------------------------------------´ Inote value of 0 = pause I IC-0 to B-0 1 to 12 I IC-3 to B-3 37 to 48 I IC-4 to B-4 49 to 60 I IC-5 to B-5 61 to 72 I IC-6 to B-6 73 to 84 I IC-7 to B-7 85 to 96 I À-----------------------------------------------------------------------------Ù That should about cover it. If you have any questions , feel free to e-mail me at freejack@shell.portal.com I can also be contacted on The UltraSound Connection (813) 787-8644 The UltraSound Connection is a BBS dedicated to the Gravis Ultrasound Card. Also I'm the author of Ripper and Gvoc. If anyone has any questions or problems, please contact me. 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 --------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 didnt 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------------------------- Usefull 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 ... 14.03.95 MM Introduced tables Last table number=0010