home *** CD-ROM | disk | FTP | other *** search
/ io Programmo 17 / IOPROG_17.ISO / soft / formats / filefmts.lst < prev    next >
Encoding:
File List  |  1998-07-02  |  283.2 KB  |  6,008 lines
  1. **********************************************************************
  2. *  This file contains header_info about these file_formats :         *
  3. *                                                                    *
  4. *  669/IFF-voice/amiga exe/AMS/ARC/ARJ/AU/BGI/BMP/CEG/CEL/CHR/       *
  5. *  CMF/COL/COM/CORE/CPI/Dbase II/Dbase III/DBase IV/DMF/DMS/DWC/     *
  6. *  EFE/EXE/FAR/FLC/TWE/OPT/FLI/FON/FPT/FSM/GF1 PAT/GIF/GZIP/GKH/     *
  7. *  GL/GRIB/HSI/HYP/IFF/INS/JPG/LBM/LBR/LZH/MID/MOD/MSK/MTM/          *
  8. *  MZ-EXE/NE-EXE/NG/OBJ/OS2-hlp/PBM/PCX/PIC/PICpro/PLY/PS16/QFX/     *
  9. *  RAW/RDIB/RIFF/RIFX/S3I/S3M/SND/SQZ/SDK/SDS/SMP/STM/TAR/TIFF/      *
  10. *  TXW/UWF/ULT/WAVE/WKS/DOC/WP-file/WQ1/XM/ZIP/ZOO/Zyxel             *
  11. *                                                                    *
  12. **********************************************************************
  13.  
  14. File format list        Release 1.00             Last change 05/28/95
  15. This compilation is Copyright (c) 1994,1995 Max Maischein
  16.  
  17. This is only the beta version. Please do not redistribute, as the
  18. format might still change.
  19. --------!-CONTACT_INFO----------------------
  20. If you notice any mistakes or omissions, please let me know!  It is only
  21. with YOUR help that the list can continue to grow.  Please send
  22. all changes to me rather than distributing a modified version of the list.
  23.  
  24. This file has been authored in the style of the INTERxxy.* file list
  25. by Ralf Brown, and uses almost the same format.
  26.  
  27. Please read the file FILEFMTS.1ST before asking me any questions. You may find
  28. that they have already been addressed.
  29.  
  30.          Max Maischein
  31.  
  32. Max Maischein, 2:244/1106.17
  33. Max_Maischein@spam.fido.de
  34. corion@hera.rbi.uni-frankfurt.de
  35. Corion on IRC
  36. --------!-DISCLAIMER------------------------
  37. DISCLAIMER:  THIS MATERIAL IS PROVIDED "AS IS".  I verify the information
  38. contained in this list to the best of my ability, but I cannot be held
  39. responsible for any problems caused by use or misuse of the information,
  40. especially for those file formats foreign to the PC, like AMIGA or SUN file
  41. formats. If an information it is marked "guesswork" or undocumented, you
  42. should check it carefully to make sure your program will not break with
  43. an unexpected value (and please let me know whether or not it works
  44. the same way).
  45.  
  46. Information marked with "???" is known to be incomplete or guesswork.
  47.  
  48. Some file formats were not released by their creators, others are regarded
  49. as proprietary, which means that if your programs deal with them, you might
  50. be looking for trouble. I don't care about this.
  51. --------!-FLAGS-----------------------------
  52. One or more letters may follow the file format ID; they have the following
  53. meanings:
  54.          Cx - Charset used :
  55.                 7 - Unix 7-bit characters
  56.                 A - Amiga charset (if there is one)
  57.                 E - EBDIC character format
  58.                 U - Unicode character set
  59.                 W - Windows char set
  60.                 Default is the 8-Bit IBM PC-II Charset. Note that Microsoft
  61.                 introduced codepages which might be relevant with other
  62.                 programs.
  63.          G  - guesswork, incomplete, unreliable etc.
  64.          M  - Motorola byte order
  65.               Default is Intel byte order
  66.          O  - obsolete, valid only for version noted below
  67.          X  - Synonym topic. See topic named under see also.
  68. --------!-CATEGORIES------------------------
  69. The ninth column of the divider line preceding an entry usually contains a
  70. classification code for the application that uses those files.
  71.  
  72. The codes currently in use are:
  73.           ! - User information ( not really a file format )
  74.           A - Archives
  75.           a - Animations
  76.           B - Binary files for compilers etc.
  77.           H - Help file
  78.           I - Images, bit maps
  79.           D - Data support files
  80.           E - Executable files
  81.           f - Generic file format. RIFF and IFF are generic file formats.
  82.           F - Font files (TTF)
  83.           G - General graphics file
  84.           M - Module music file (MIDI,MOD)
  85.           R - Resource data files
  86.           S - Sound files (WAV,VOC)
  87.           T - Text files (DOC,TXT)
  88.           W - Spreadsheet and related (WKS)
  89.           X - Database files (DBF)
  90. --------!-FIELDS----------------------------
  91. After a format description, you will sometimes find other keywords. The
  92. meanings of these are :
  93.   EXTENSION:
  94.     This is the default extension of files of the given type.
  95.     On DOS systems, most files have a 3 letter extension.
  96.     On Amiga systems, the files are prefixed with something.
  97.     The DOS extensions are all uppercase, extensions for other systems
  98.     are in lower case chars. On other systems, which do not have the con-
  99.     cept of extensions, as the MAC, this is the file type.
  100.   OCCURENCES:
  101.     Where you are likely to encounter those files. This specifies
  102.     machines (like PC,AMIGA) or operating systems (like UNIX).
  103.   PROGRAMS:
  104.     Programs which either create, use or convert files of this format.
  105.     Some might be used for validation or conversion.
  106.   REFERENCE:
  107.     A reference to a file or an article in a magazine which is mandatory
  108.     or recommended for further understanding of the matter.
  109.   SEE ALSO:
  110.     A cross reference to a topic which might be interesting as well.
  111.   VALIDATION:
  112.     Methods to validate that the file you have is not corrupt. Normally
  113.     this is a method to check the theoretical file size against the
  114.     real filesize. Some file formats allow no reliable validation.
  115. --------!-FORMAT----------------------------
  116.   The block oriented files are organized in some other fashion, since the
  117.   order of blocks is at best marginally obligatory.
  118.  
  119.   Each block type starts with the block ID (eg. RIFFblock for a RIFF file) and
  120.   in square brackets the character value of the ID field (eg. [WAVE] for RIFF
  121.   WAVe sound files). The block itself is descripted in the format description,
  122.   that means you will have to look after RIFF or FORM. In the record
  123.   description, the header information is omitted !
  124.  
  125.   If a record is descripted, the record ends when the next offset is given.
  126.  
  127.   Bitmapped values have a description for each bit. The value left of the
  128.   slash ("/") is for the bit not set (=0), the right sided value applies
  129.   if the bit is set.
  130.  
  131.   A note on the tables section. The tables were added as they were introduced
  132.   into Ralf Browns interrupt list - so not everything was pressed into a table.
  133.   The tables (should) have unique numbers, but they sure are out of order !
  134. --------!-MACHINES--------------------------
  135.   Machines that use Intel byte ordering
  136.     PC
  137.   Machines that use Motorola byte ordering
  138.     AMIGA, ATARI ST, MAC, SUN
  139.  
  140. --------M-669-------------------------------
  141. The .669 format is a module format for digital music.
  142.  
  143. OFFSET              Count TYPE   Description
  144. 0000h                   1 word   ID=6669h
  145. 0002h                 108 byte   ASCII song message
  146. 006Eh                   1 byte   Number of saved samples (0-40h)
  147.                                  ="NOS"
  148. 006Fh                   1 byte   Number of saved patterns (0-80h)
  149.                                  ="NOP"
  150. 0070h                   1 byte   Loop order number
  151. 0071h                 128 byte   Order list
  152. 00F1h                 128 byte   Tempo list for patterns
  153. 0171h                 128 byte   Break location list for patterns
  154. 01F1h               "NOS" rec    Sample data
  155.                                  The sample data is in the file
  156.                                  for "NOS"
  157.                        13 byte   ASCIIZ filename of instrument
  158.                         1 dword  Length of instrument sample
  159.                         1 dword  Offset of beginning of loop
  160.                         1 dword  Offset of end of loop
  161. 01F1h+          "NOP"*600 rec    The note patterns
  162.  "NOS"*19h                       Those patterns are repeated for each row,
  163.                                  and the array of these is repeated 64 times
  164.                                  for each pattern.
  165.                         3 byte   Note(see table 0000)
  166. 01F1h+                  ? byte   Sample data (unsigned)
  167.  "NOS"*0x19+
  168.  "NOP"*0x600
  169.  
  170. (Table 0000)
  171. 669 Note format
  172. Each note looks like this :
  173. BYTE[0]: BYTE[1]: BYTE[2]:
  174. nnnnnnii iiiivvvv ccccdddd
  175.  
  176.   n : note value
  177.   i : 6-bit instrument number
  178.   v : 4-bit volume
  179.   c : command data (Protracker format mapped) :
  180.      0 = a
  181.      1 = b
  182.      2 = c
  183.      3 = d
  184.      4 = e
  185.      5 = f
  186.      d : command value (Protracker format)
  187.  
  188. Special values for byte 0 :
  189.   0FEh : no note, only volume
  190.   0FFh : no note or no command, if byte 2 = 0FFh
  191.  
  192. EXTENSION:669
  193. OCCURENCES:PC
  194. SEE ALSO:MOD
  195. PROGRAMS:669 Mod Composer, DMP
  196. VALIDATION:
  197. --------S-8SVX-MG---------------------------
  198. The 8SVX files are IFF files used for digital audio data. The format of
  199. the VHDR block is complete guesswork. These files use Motorola byte order.
  200. The 8SVX file format is fixed to 8-bit mono sample data - at least GoldWave
  201. does not support saving files in any other format than 8-bit mono.
  202.  
  203. FORMblock [VHDR]
  204. This is the sample information block. The normal size is 20 bytes.
  205. OFFSET              Count TYPE   Description
  206. 0000h                   1 dword  Sampling rate of digital data in Hz.
  207.                                  This count seems not to be too accurate,
  208.                                  at least GoldWave v2.0 creates different
  209.                                  rates for Wave and 8SVX files.
  210. 0004h                   4 dword  Other data, unknown
  211.  
  212. FORMblock [BODY]
  213. This block contains the raw sample data, maybe the usual IFF compression was
  214. used. The details of both the compression and the information about the IFF
  215. format are unknown to me.
  216. EXTENSION:IFF
  217. OCCURENCES:PC,Amiga
  218. PROGRAMS:GoldWave
  219. SEE ALSO:IFF,WAVE
  220. VALIDATION:
  221. --------S-AIFC-MG---------------------------
  222. The AIFC files seem to be a variation of the AIFF files - but I don't know
  223. anything about them.
  224. EXTENSION:IFF
  225. SEE ALSO:AIFF
  226. --------S-AIFF-MG---------------------------
  227. The Audio Interchangeable File Format files are digital audio files
  228. stored in the IFF format; the samples are stored in signed PCM. The header
  229. block is [AIFF], different subblocks are :
  230.  
  231. [AUTH]
  232. The authors information; optional
  233. [COMM]
  234. This record stores information about the sampled data :
  235. OFFSET              Count TYPE   Description
  236. 0000h                   1 word   ??? number of channels ???
  237.                                  ??? number of instrument samples ???
  238. 0002h                   1 dword  Sample length
  239. 0006h                   1 dword  lower frequency
  240. 000Ah                   1 dword  maximum frequency
  241. 000Dh                   1 dword  ???
  242. [MARK]
  243. [NAME]
  244. The name of the instrument / sample
  245. [SSND]
  246. The stored sample data.
  247.  
  248. Further information wanted.
  249. EXTENSION:AIF,IFF
  250. --------E-AMIGA EXECUTABLE-MG---------------
  251. All Amiga executables I've seen start with this signature. Of course the
  252. bytes are in Motorola byte order, as you would exspect from a Motorola
  253. based machine. This info here is based completely on my guesswork, maybe
  254. somebody from the Amiga could help flesh out this part.
  255.  
  256. OFFSET              Count TYPE   Description
  257. 0000h                   1 dword  ID=03F3h
  258. EXTENSION:EXE
  259. OCCURENCES:AMIGA
  260. SEE ALSO:
  261. VALIDATION:
  262. --------M-AMS-------------------------------
  263. The AMS format is a multichannel module format created by the X-Tracker (not
  264. to be mistaken for he tracker of the same name by D-Lusion).
  265. The X-Tracker by Extreme PC is a multichannel tracker that features 32 digital
  266. channels, 64 MIDI channels, 255 samples, 64K patterns and positions. The tracker
  267. is currently in beta status and not enough information is yet available yet.
  268.  
  269. OFFSET              Count TYPE   Description
  270.  
  271. EXTENSION:
  272. OCCURENCES:
  273. PROGRAMS:
  274. REFERENCE:
  275. SEE ALSO:MOD
  276. VALIDATION:
  277. --------A-ARC-------------------------------
  278. The ARC files are archive files created by the SEA ARC program. The compression
  279. has been superceded by more recent compression programs. Similar archives can
  280. be created by the PAK and PkPAK programs.
  281.  
  282. OFFSET              Count TYPE   Description
  283. 0000h                   1 byte   ID=1Ah
  284. 0001h                   1 byte   Compression method (see table 0001)
  285. 0002h                  12 char   File name
  286. 000Fh                   1 dword  Compressed file size
  287. 0013h                   1 dword  File date in MS-DOS format (see table 0009)
  288. 0017h                   1 word   16-bit CRC
  289. 0019h                   1 dword  Original file size
  290.                                  ="SIZ"
  291. (Table 0001)
  292. ARC compression types
  293.   1 - unpacked (obsolete)
  294.   2 - unpacked
  295.   3 - packed
  296.   4 - squeezed (after packing)
  297.   5 - crunched (obsolete)
  298.   6 - crunched (after packing) (obsolete)
  299.   7 - crunched (after packing, using faster hash algorithm)
  300.   8 - crunched (after packing, using dynamic LZW variations)
  301.   9 - Squashed c/o Phil Katz (no packing) (var. on crunching)
  302.   10 - crushed (PAK only)
  303.   11 - distilled (PAK only)
  304.  
  305. (Table 0009)
  306. Format of the MS-DOS time stamp (32-bit)
  307. The MS-DOS time stamp is limited to an even count of seconds, since the
  308. count for seconds is only 5 bits wide.
  309.  
  310.   31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
  311.  |<---- year-1980 --->|<- month ->|<--- day ---->|
  312.  
  313.   15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
  314.  |<--- hour --->|<---- minute --->|<- second/2 ->|
  315.  
  316. EXTENSION:ARC,PAK
  317. OCCURENCES:PC
  318. PROGRAMS:SEA ARC,PAK,PkPAK
  319. SEE ALSO:
  320. VALIDATION:FileSize="SIZ"
  321. --------A-ARJ-------------------------------
  322. The ARJ program by Robert K. Jung is a "newcomer" which compares well to PKZip
  323. and LhArc in both compression and speed. An ARJ archive contains two types of
  324. header blocks, one archive main header at the head of the archive and local
  325. file headers before each archived file.
  326.  
  327. OFFSET              Count TYPE   Description
  328. 0000h                   1 word   ID=0EA60h
  329. 0002h                   1 word   Basic header size (0 if end of archive)
  330. 0004h                   1 byte   Size of header including extra data
  331. 0005h                   1 byte   Archiver version number
  332. 0006h                   1 byte   Minimum version needed to extract
  333. 0007h                   1 byte   Host OS (see table 0002)
  334. 0008h                   1 byte   Internal flags, bitmapped :
  335.                                   0 - no password / password
  336.                                   1 - reserved
  337.                                   2 - file continues on next disk
  338.                                   3 - file start position field is available
  339.                                   4 - path translation ( "\" to "/" )
  340. 0009h                   1 byte   Compression method :
  341.                                   0 - stored
  342.                                   1 - compressed most
  343.                                   2 - compressed
  344.                                   3 - compressed faster
  345.                                   4 - compressed fastest
  346.                                  Methods 1 to 3 use Lempel-Ziv 77 sliding window
  347.                                  with static Huffman encoding, method 4 uses
  348.                                  Lempel-Ziv 77 sliding window with pointer/
  349.                                  length unary encoding.
  350. 000Ah                   1 byte   File type :
  351.                                   0 - binary
  352.                                   1 - 7-bit text
  353.                                   2 - comment header
  354.                                   3 - directory
  355.                                   4 - volume label
  356. 000Bh                   1 byte   reserved
  357. 000Ch                   1 dword  Date/Time of original file in MS-DOS format
  358. 0010h                   1 dword  Compressed size of file
  359. 0014h                   1 dword  Original size of file
  360. 0018h                   1 dword  Original file's CRC-32
  361. 001Ah                   1 word   Filespec position in filename
  362. 001Ch                   1 word   File attributes
  363. 001Eh                   1 word   Host data (currently not used)
  364. ?                       1 dword  Extended file starting position when used
  365.                                  (see above)
  366.                         ? char   ASCIIZ file name
  367.                         ? char   Comment
  368. ????h                   1 dword  Basic header CRC-32
  369. ????h                   1 word   Size of first extended header (0 if none)
  370.                                  ="SIZ"
  371. ????h+"SIZ"+2           1 dword  Extended header CRC-32
  372. ????h+"SIZ"+6           ? byte   Compressed file
  373.  
  374. (Table 0002)
  375. ARJ HOST-OS types
  376.   0 - MS-DOS
  377.   1 - PRIMOS
  378.   2 - UNIX
  379.   3 - AMIGA
  380.   4 - MAC-OS (System xx)
  381.   5 - OS/2
  382.   6 - APPLE GS
  383.   7 - ATARI ST
  384.   8 - NeXT
  385.   9 - VAX VMS
  386. EXTENSION:ARJ
  387. OCCURENCES:PC
  388. PROGRAMS:ARJ.EXE
  389. REFERENCE:
  390. SEE ALSO:
  391. VALIDATION:
  392. --------S-AU-MG-----------------------------
  393. The AU files are digital audio files used by the Sun and NeXT
  394. workstations.
  395. Further information wanted.
  396. OFFSET              Count TYPE   Description
  397. 0000h                   4 char   ID='.snd'
  398. 0004h                   1 dword  Offset of start of sample
  399. 0008h                   1 dword  Length of stored sample
  400. 000Ch                   1 dword  Sound encoding :
  401.                                    1 -  8-bit ISDN u-law
  402.                                    2 -  8-bit linear PCM (REF-PCM)
  403.                                    3 - 16-bit linear PCM
  404.                                    4 - 24-bit linear PCM
  405.                                    5 - 32-bit linear PCM
  406.                                    6 - 32-bit IEEE floating point
  407.                                    7 - 64-bit IEEE floating point
  408.                                   23 -  8-bit ISDN u-law compressed(G.721 ADPCM)
  409. 0010h                   1 dword  Sampling rate
  410. 0014h                   1 dword  Number of sample channels
  411. EXTENSION:AU
  412. OCCURENCES:SunOS
  413. --------B-BGI-G-----------------------------
  414. The BGI files are graphic drivers used by the Borland compilers to
  415. provide graphics output for different graphics cards. They are loaded
  416. dynamically. The exact format is not known to me ...
  417. OFFSET              Count TYPE   Description
  418. 0000h                   4 char   ID='FBGD'
  419. 0004h                   1 dword  ID=08080808h
  420.                                  used to backspace over ID if typing the file
  421. 0008h                   ? char   Driver ID string, terminated with #26
  422. EXTENSION:BGI
  423. OCCURENCES:PC
  424. PROGRAMS:Borland Pascal, Borland C, Turbo Pascal
  425. --------I-BMP-------------------------------
  426. The BMP files are the way, Windows stores bit mapped images. The BMP image
  427. data is bit packed but every line must end on a dword boundary - if thats not
  428. the case, it must be padded with zeroes. BMP files are stored bottom-up,
  429. that means that the first scan line is the bottom line. The BMP format has four
  430. incarnations, two under Windows (new and old) and two under OS/2, all are
  431. described here.
  432. OFFSET              Count TYPE   Description
  433. 0000h                   2 char   ID='BM' - BitMap
  434.                                  OS/2 also supports the following IDs :
  435.                                  ID='BA' - Bitmap Array
  436.                                  ID='CI' - Color Icon
  437.                                  ID='CP' - Color Pointer (mouse cursor)
  438.                                  ID='IC' - Icon
  439.                                  ID='PT' - Pointer (mouse cursor)
  440. 0002h                   1 dword  Filesize of whole file
  441. 0006h                   4 byte   reserved
  442. 000Ah                   1 dword  Offset of bitmap in file
  443.                                  ="BOF"
  444. 000Eh                   1 dword  Length of BitMapInfoHeader
  445.                                  The BitMapInfoHeader starts directly after
  446.                                  this header.
  447.                                  12 - OS/2 1.x format
  448.                                  40 - Windows 3.x format
  449.                                  64 - OS/2 2.x format
  450. 0012h                   1 dword  Horizontal width of bitmap in pixels
  451. 0016h                   1 dword  Vertical width of bitmap in pixels
  452. 001Ah                   1 word   Number of planes
  453. 001Ch                   1 word   Bits per pixel ( thus the number of colors )
  454.                                  ="BPP"
  455. 001Eh                   1 dword  Compression type, see ALGRTHMS.txt for descrip-
  456.                                  tion of the different types
  457.                                  0 - none
  458.                                  1 - RLE 8-bit/Pixel
  459.                                  2 - RLE 4-bit/Pixel
  460. 0022h                   1 dword  Size of picture in bytes
  461. 0026h                   1 dword  Horizontal resolution
  462. 002Ah                   1 dword  Vertical resolution
  463. 002Ah                   1 dword  Number of used colors
  464. 002Ah                   1 dword  Number of important colors
  465. 0036h                   ? rec    Definition of N colors
  466.                                  N=1 shl "BPP"
  467.                         1 byte   Blue component
  468.                         1 byte   Green component
  469.                         1 byte   Red component
  470.                         1 byte   Filler
  471. "BOF"                   ? byte   Image data
  472. EXTENSION:BMP,RLE,LGO
  473. OCCURENCES:PC
  474. PROGRAMS:Windows,Paintbrush
  475. REFERENCE:DDJ0994
  476. VALIDATION:
  477. SEE ALSO:rDIB
  478. --------I-CEG-------------------------------
  479. The CEG (Continous Edge Graphic)-format is a raw picture format used by the
  480. Edsun cards with CEG-chips which provide some better look through anti-aliasing
  481. or something like that. The header before the data looks like this :
  482.  
  483. OFFSET              Count TYPE   Description
  484. 0000h                   1 word   Version number of the CEG-format
  485. 0002h                   9 char   ID='Edsun CEG'
  486. 000Bh                   1 byte   Number of pixels per byte
  487. 000Ch                   9 byte   Reserved
  488. 0015h                  80 char   ASCIIZ copyright notice for the image
  489. 0065h                   1 byte   CEG-revision number (1)
  490. 0066h                   1 byte   Used CEG-mode (0..15)
  491. 0067h                   1 Word   Number of pixels per line
  492. 0069h                   1 word   Number of lines
  493. 006Ah                   1 byte   Old VGA-mode
  494. 006Bh                   1 byte   VGA Data flag :
  495.                                   0 - VGA registers are invalid
  496.                                   1 - VGA registers are valid
  497. 006Ch                  92 byte   VGA register data
  498. 00C2h                 256 rec    VGA palette entries
  499.                         1 byte   Value for red
  500.                         1 byte   Value for green
  501.                         1 byte   Value for blue
  502. 03C2h                   1 word   Year of file creation
  503. 03C4h                   1 byte   Day of file creation
  504. 03C5h                   1 byte   Month of file creation
  505. 03C6h                   1 byte   Hour of file creation
  506. 03C7h                   1 byte   Minute of file creation
  507. 03C8h                   1 byte   Second of file creation
  508. 03C9h                  24 byte   Reserved for future use
  509. EXTENSION:???
  510. OCCURENCES:PC
  511. PROGRAMS:???
  512. --------a-CEL-------------------------------
  513. CEL files contain one or more frames of image data used by the Autodesk
  514. Animator and Animator Pro animation pakages. Both Animator Pro and the original
  515. Animator produce CEL files, but each uses a different file format.
  516.  
  517. --- Animator Pro CEL Files
  518.  
  519. An Animator Pro CEL file is identical to a FLC file in all respects. A CEL file
  520. should have a Celdata block in the file prefix block which describes the x,y
  521. placement of the CEL. If the Celdata placement block is not present, assume a
  522. placement of 0,0.
  523.  
  524. --- Original Animator CEL Files
  525.  
  526. The original Animator also produced CEL files. These were still-picture files,
  527. not the multi-frame files Animator Pro now uses. A CEL file from the original
  528. Animator is identical to a PIC file from the original Animator in all respects.
  529.  
  530. EXTENSION:CEL
  531. OCCURENCES:PC
  532. PROGRAMS:Autodesk Animator
  533. SEE ALSO:FLIc,FLC,PIC
  534. VALIDATION:
  535. --------F-CHR-------------------------------
  536. The CHR files are scalable fonts used by the Borland graphics interface
  537. (BGI) to display fonts in graphics mode.
  538. OFFSET              Count TYPE   Description
  539. 0000h                   4 char   ID='PK',08,08
  540. 0004h                   4 char   ID='BGI '
  541. 0008h                   ? char   Font description, terminated with #26
  542. 0008h                   1 word   Headersize
  543. +????                            ="SIZ"
  544.                         4 char   Internal font name
  545.                         1 word   Font file size in bytes
  546.                         1 byte   Font driver major version
  547.                         1 byte   Font driver minor version
  548.                         1 word   0100h
  549.                     "SIZ" word   Zeroes to pad out the header
  550. 0080h                   1 char   Signature byte, '+' means stroke font
  551. 0081h                   1 word   Number of chars in font file
  552.                                  ="NUM"
  553. 0083h                   1 byte   undefined
  554. 0084h                   1 byte   ASCII value of first char in file
  555. 0085h                   1 word   Offset to stroke definitions
  556. 0087h                   1 byte   Scan flag ??
  557. 0088h                   1 byte   Distance from origin to top of capital
  558. 0089h                   1 byte   Distance from origin to baseline
  559. 008Ah                   1 byte   Distance from origin to bottom descender
  560. 008Bh                   4 char   Four character name of font
  561. 0090h               "NUM" word   Offsets to character definitions
  562. 0090h+              "NUM" byte   Width table for the characters
  563. "NUM"*2
  564. 0090h+                           Start of character definitions
  565. "NUM"*3
  566.  
  567. The individual character definitions consist of a variable number of words
  568. describing the operations required to render a character. Each word
  569. consists of an (x,y) coordinate pair and a two-bit opcode, encoded as shown
  570. here:
  571.  
  572. Byte 1          7   6   5   4   3   2   1   0     bit #
  573.                op1  <seven bit signed X coord>
  574.  
  575. Byte 2          7   6   5   4   3   2   1   0     bit #
  576.                op2  <seven bit signed Y coord>
  577.  
  578.           Opcodes
  579.  
  580.         op1=0  op2=0  End of character definition.
  581.         op1=0  op2=1  Do scan
  582.         op1=1  op2=0  Move the pointer to (x,y)
  583.         op1=1  op2=1  Draw from current pointer to (x,y)
  584.  
  585. EXTENSION:CHR
  586. OCCURENCES:PC
  587. PROGRAMS:Borland Pascal, Borland C
  588. REFERENCE:BGIKIT.ZIP
  589. SEE ALSO:
  590. VALIDATION:
  591. --------M-CMF-G-----------------------------
  592. The CMF files are music files used by the SoundBlaster sound card family. The
  593. Creative Labs Music Format might be proprietary, the info is guesswork.
  594. OFFSET              Count TYPE   Description
  595. *********
  596. EXTENSION:CMF
  597. OCCURENCES:PC
  598. PROGRAMS:PLAYCMF.EXE
  599. --------I-COL-------------------------------
  600. A COL file stores the rgb values for entries in the color palette. Both
  601. Animator Pro and the original Animator produce COL files, but the formats
  602. are different. To process a COL file for input, check the file size. If it is
  603. exactly 768 bytes, the file is an original Animator COL file. If the file is
  604. any other size, it is an Animator Pro COL file - which makes identification
  605. almost impossible.
  606.  
  607.  
  608. Animator Pro COL Files do have a 8-byte header :
  609.  
  610. OFFSET              Count TYPE   Description
  611. 0000h                   1 dword  File size, including this header
  612. 0004h                   1 word   ID=0B123h
  613. 0006h                   1 word   Version, currently 0
  614.  
  615. Following the file header are palette entries in rgbrgb... order. Each of
  616. the r, g, and b components is a single byte in the range of 0-255. Generally,
  617. there will be data for 256 palette entries, but this cannot be assumed.
  618. The actual number of palette entries is ((size-8)/3); if this value is not
  619. an even multiple of three, the file is corrupted.
  620.  
  621. Original Animator COL Files
  622.  
  623. A COL file created by the original Animator is exactly 768 bytes
  624. long. There is no file header or other control information in
  625. the file.
  626.  
  627. EXTENSION:COL
  628. OCCURENCES:PC
  629. PROGRAMS:Autodesk Animator, Autodesk Animator Pro
  630. SEE ALSO:FLIc,FLT
  631. --------E-COM-------------------------------
  632. The COM files are raw binary executables and are a leftover from the old CP/M
  633. machines with 64K RAM.  A COM program can only have a size of less than one
  634. segment (64K), including code and static data since no fixups for segment
  635. relocation or anything else is included. One method to check for a COM file is
  636. to check if the first byte in the file could be a valid jump or call opcode, but
  637. this is a very weak test since a COM file is not required to start with a jump
  638. or a call. In principle, a COM file is just loaded at offset 100h in the segment
  639. and then executed.
  640.  
  641. OFFSET              Count TYPE   Description
  642. 0000h                   1 byte   ID=0E9h
  643.                                  ID=0EBh
  644.                                  Those are not safe ways to determine wether a
  645.                                  file is a COM file or not, but most COM files
  646.                                  start with a jump.
  647. Further information not available.
  648. EXTENSION:COM
  649. OCCURENCES:PC
  650. SEE ALSO:EXE,MZ EXE,NE EXE
  651. --------E-CORE-G----------------------------
  652. The core images are dumps of the system core from different unix machines (as
  653. far as I gather). Info comes from a magic file - so this is only good for
  654. identification. What you would do with a core image on a foreign machine, eludes
  655. me anyway.
  656. OFFSET              Count TYPE   Description
  657. 0000h                   4 char   ID='core'
  658. 0176h                   1 word   Executable type
  659.                                  0176h - 386 executable
  660. ************
  661. >566    short           072401          386 executable
  662. >564    short           0535            B370 executable
  663. >564    short           056401          B370 executable
  664. >564    short           0530            B370 executable
  665. >564    short           054001          B370 executable
  666. >564    short           0537            XA370 executable
  667. >564    short           057401          XA370 executable
  668. >564    short           055001          XA370 executable
  669. >564    short           0532            XA370 executable
  670.  
  671. EXTENSION:???
  672. OCCURENCES:Unix flavours
  673. PROGRAMS:N/A
  674. SEE ALSO:
  675. --------D-CPI-G-----------------------------
  676. The DOS CPI files are data files which are loaded by the country drivers of
  677. MS-DOS. The information comes from a magic file, which makes it good for
  678. identification only.
  679. OFFSET              Count TYPE   Description
  680. 0000h                   9 char   ID=255,'FONT   ',0
  681. EXTENSION:CPI
  682. OCCURENCES:PC
  683. PROGRAMS:MS-DOS
  684. --------X-DBase II-O------------------------
  685. The DBase II file format.
  686. The dBASE II file header has a fixed size of 521 bytes.
  687. OFFSET              Count TYPE   Description
  688. 0000h                   1 byte   dBASE version, 02h = dBASE II
  689. 0001h                   1 word   Number of data records in file
  690.                                  ="NDR"
  691. 0003h                   1 byte   Month of last update
  692. 0004h                   1 byte   Day of last update
  693. 0005h                   1 byte   Year of last update
  694. 0006h                   1 word   Size of each data record
  695.                                  ="DRS"
  696. 0008h                  64 rec    Field descriptors
  697.                        11 char   ASCIIZ field name, 0Dh as first
  698.                                  char indicates end of list.
  699.                         1 char   Data type
  700.                                  'C' - Char
  701.                                  'N' - Numerical
  702.                                  'L' - Logical
  703.                         1 byte   Field length
  704.                         1 word   Field data address ( set in RAM )
  705.                         1 byte   Number of decimal places
  706. 0208h                   1 byte  If 0Dh, then all 32 field descriptors were used;
  707.                                 otherwise 00h
  708. EXTENSION:DBF
  709. OCCURENCES:PC
  710. PROGRAMS:DBase
  711. SEE ALSO:DBASE III,XBase
  712. VALIDATION:FileSize="NDR"*"DRS"+0208h
  713. --------X-DBase III-------------------------
  714.               DBASE - File header structure (DBASE III)
  715. OFFSET              Count TYPE   Description
  716. 0000h                   1 byte   dBASE version,
  717.                                    03h = dBASE III w/o *.DBT
  718.                                    83h = dBASE III w *.DBT
  719. 0001h                   1 byte   Month of last update
  720. 0002h                   1 byte   Day of last update
  721. 0003h                   1 byte   Year of last update
  722. 0004h                   1 dword  Number of data records in file
  723.                                  ="NDR"
  724. 0008h                   1 word   Header size
  725.                                  ="HSZ"
  726. 000Ah                   1 word   Data record size
  727.                                  ="DRS"
  728. 000Ch                  12 byte   reserved
  729. 0020h                   ? rec    Field descriptors
  730.                                  The list of field descriptors is
  731.                                  terminated with a terminator
  732.                                  byte 0Dh.
  733.                        11 char   ASCIIZ field name
  734.                         1 char   Data type
  735.                                  'C' - Char
  736.                                  'D' - Date
  737.                                  'L' - Logical
  738.                                  'M' - Memo
  739.                                  'N' - Numerical
  740.                         1 dword  Field data address ( set in RAM )
  741.                         1 byte   Field length
  742.                         1 byte   Number of decimal places
  743.                        14 byte   reserved
  744. EXTENSION:DBF
  745. SEE ALSO:DBASE II,XBase
  746. OCCURENCES:PC
  747. PROGRAMS:DBase
  748. VALIDATION:FileSize="NDR"*"DRS"+"HSZ"
  749. --------X-DBASE IV--------------------------
  750. **** Description missing ****
  751. EXTENSION:DBF,DBT
  752. OCCURENCES:PC
  753. PROGRAMS:DBase 4.0, Clipper
  754. REFERENCE:
  755. SEE ALSO:DBASE II,DBASE III,XBase
  756. VALIDATION:
  757. --------M-DMF-------------------------------
  758. The Digital Music Files are high quality MOD style files with up to
  759. 32 channels/1024 beats per track. The X-Tracker by the demo group
  760. D-Lusion produces this format. In general, the format is well organised
  761. due to the ID/Blocklength structure wich makes downward compatibility to
  762. older version files easy, but the Version 4 (current version) of the file
  763. format, produced by X-Tracker 0.30ß still requires some manual scanning for
  764. the next ID which I regard as not so nice. Version 5 of the format has the
  765. [SEQU] block length fixed, but the [SMPD] block has the length 0.
  766.  
  767. The file consists of several blocks, each with a 4 char (dwordint) ID tag
  768. and a length of the record data. The main file header looks as follows :
  769. OFFSET              Count TYPE   Description
  770. 0000h                   4 char   ID='DDMF'
  771. 0004h                   1 byte   Version id.
  772.                                  4 -> XTracker 0.30ß
  773. 0005h                   8 char   Tracker name, e.g. 'XTRACKER', 'HACKTRAK' :-)
  774. 000Dh                  30 char   Song name (ASCIIZ?)
  775. 002Bh                  20 char   Name of composer (ASCIIZ?)
  776. 0049h                   1 byte   Day of creation
  777. 004Ah                   1 byte   Month of creation
  778. 004Bh                   1 byte   Year of creation
  779.  
  780. The other headers have the standard skip record format, in this section
  781. named DMFblock. The offsets start _after_ this header record :
  782. OFFSET              Count TYPE   Description
  783. 0000h                   4 char   Record tag (see below)
  784. 0004h                   1 dword  Size of data bedwording to this tag
  785.  
  786. DMFblock [INFO]
  787.   Contains some message in ASCII. Length of the message is the size of
  788.   the record.
  789.  
  790. DMFblock [CMSG]
  791.   Contains the message the composer wants to bring to us. After the ID
  792.   record, another fill byte preceeds the real message !
  793. OFFSET              Count TYPE   Description
  794. 0000h                   1 byte   Junk byte
  795. 0001h                   ? char   Composer message
  796.  
  797. DMFblock [SEQU]
  798.   Contains the information necessary for sequencing the different tracks.
  799. OFFSET              Count TYPE   Description
  800. 0000h                   1 word   Song loop start
  801. 0002h                   1 word   Song loop end
  802. 0004h                   ? word   Sequencer data
  803.  
  804. DMFblock [PATT]
  805.   This block contains the information about the different patterns and tracks.
  806. 0000h                   1 word   Maximum pattern (=Songlength)
  807.                                  ="MPT"
  808. 0004h                   1 byte   Number of channels of this song (<= 16)
  809. 0005h               "MPT" rec    Pattern data.
  810.                         1 byte   Track entries. (<=32)
  811.                                  ="TET"
  812.                                  How many tracks this pattern has.
  813.                                  XTracker allows a different number of
  814.                                  tracks for each pattern.
  815.                         1 byte   Beat information
  816.                                  High nibble : Ticks per beat
  817.                                  Low nibble  : Beats per measure
  818.                         1 word   Maximum number of ticks (<=512)
  819.                         1 dword  Number of bytes to skip for the
  820.                                  next pattern information.
  821.                         ? rec    Track data stream
  822.                         1 byte   Global track effect
  823.                         1 byte   Global track data (only if global
  824.                                  effect >0 !!!)
  825.                     "TET" rec
  826.                         1 byte   Information byte, bitmapped
  827.                                  For each bit set in the info byte, one
  828.                                  or two data byte(s) follow. This info byte
  829.                                  must not always be there, see below. For
  830.                                  effects, 2 bytes follow.
  831.                                  0 - reserved
  832.                                  1 - Volume effect
  833.                                  2 - Note effect
  834.                                  3 - Instrument effect
  835.                                  4 - Volume set
  836.                                  5 - Note set
  837.                                  6 - Instrument set
  838.                                  7 - Counter to next information byte.
  839.                                      Not set means, that next info byte
  840.                                      follows in 1 tick, unit is in
  841.                                      ticks.
  842.                                  The maximum number of effects is 3 at a time,
  843.                                  the maxximum size of a track information is
  844.                                  11 bytes (with info=0FEh).
  845.                         ? rec   Effect bytes
  846.                         1 byte  Effect number
  847.                         1 byte  Effect data
  848.                         ? byte  Set data
  849. ** Here follows the pattern data, but it's too late today **
  850.  
  851. DMFblock [INST]
  852.   This block contains the information about the instrument data.
  853.   If this block does not exists, then the instrument numbers in the patterns
  854.   point directly to the samples in the [SMPI] block.
  855. OFFSET              Count TYPE   Description
  856. 0000h                   1 byte   Number of instruments
  857. 0001h                   ? rec    Instrument information block
  858.                        30 char   The name of the instrument
  859.                         1 byte   Instrument type, bitmapped
  860.                                  0 - Instrument type
  861.                                  1 - Instrument type
  862.                                    00 - Sample in [SMPI] block
  863.                                    01 - MIDI device
  864.                                    10 - FM instrument
  865.                                    11 - reserved
  866.                                  2 - valid attack envelope
  867.                                  3 - sustain on
  868.                                  4 - reserved
  869.                                  5 - reserved
  870.                                  6 - reserved
  871.                                  7 - reserved
  872.                         1 byte   Range entries
  873.                                  ="REN"
  874.                                  Like the GF1 patterns, an instrument can
  875.                                  consist of several samples.
  876.                     "REN" rec    Range definition
  877.                         1 byte   Sample to be played in this range
  878.                         1 byte   Length of this range in half tone steps up
  879.                         6 byte   Not yet defined 6-point envelope
  880.  
  881. DMFblock [SMPI]
  882. This block contains the information about the samples stored in the file.
  883. OFFSET              Count TYPE   Description
  884. 0000h                   1 byte   Number of samples (<= 250)
  885.                                  ="NUM"
  886.                     "NUM" rec    Sample record
  887.                         1 byte   Length of sample name
  888.                         ? char   Name of the sample
  889.                         1 dword  Length of sample in bytes
  890.                         1 dword  Start of sample loop
  891.                         1 dword  End of sample loop
  892.                         1 word   Frequency used for C-3
  893.                         1 byte   Volume for sample
  894.                                  0 - Don't change current volume
  895.                                  otherwise volume (linear scale)
  896.                         1 byte   Sample type, bitmapped
  897.                                    0 - not looped/looped
  898.                                    1 - 8/16-bit sample
  899.                                      (16-bit not supported with X-Tracker v0.30)
  900.                                  2,3 - Pack type :
  901.                                    00 - unpacked, signed sample
  902.                                    01 - pack type 0
  903.                                    10 - pack type 1
  904.                                    11 - pack type 2
  905.                                  4-6 - reserved, set to zero
  906.                                    7 - Sample stored in dmf/bib
  907.                         1 word   reserved, set to zero
  908.                         1 dword  crc32 of sample to identify samples
  909.                                  in BIB.
  910.  
  911. DMFblock [SMPD]
  912. This block contains the sample data (raw or packed, see [SMPI] block) in the
  913. following format :
  914. <SampleLength> <SampleData> <SampleLength> <SampleData> etc.
  915. OFFSET              Count TYPE   Description
  916. 0000h                   1 dword  Length of the following sample
  917.                         ? byte   Sample data (might be packed)
  918.  
  919. DMFBlock [ENDE]
  920. This block serves as a end of file marker and can be used for validation.
  921. Note that the four ID characters are _not_ followed by a length dword ! Each DMF
  922. file simply ends with the four characters 'ENDE'.
  923. EXTENSION:DMF
  924. OCCURENCES:PC
  925. PROGRAMS:X-TRACKER,PLAY_DMF
  926. SEE ALSO:
  927. VALIDATION:
  928. --------?-DMS-------------------------------
  929. The DMS (Digital Music System??) are some other files I found on a
  930. mixed system CD, so I include them in my listing. They are Amiga files,
  931. so here's the call to the Amiga folks again.
  932.  
  933. OFFSET              Count TYPE   Description
  934. 0000h                   4 char   ID="DMS!"
  935. EXTENSION:DMS
  936. OCCURENCES:Amiga
  937. --------A-DWC-?-----------------------------
  938. The DWC archives seem to be a relict from ancient computing times - I've never
  939. seen any program that dealt with them or could create them. They are yet
  940. included in this compilation for reasons I don't know. But maybe one of you
  941. stumbles over such a file, he might find this documentation helpful.
  942. The DWC archives consist of single file entries with one archive trailer. The
  943. archive entries seem to be at the start of the archive, but maybe they are
  944. stored at the end of the archive, before the trailer. Each file header has the
  945. following format :
  946.  
  947. OFFSET              Count TYPE   Description
  948. 0000h                  13 char   Name of the original file in ASCIIZ.
  949. 000Dh                   1 dword  Size of the original file
  950. 0011h                   1 dword  MS-DOS date and time of the original file
  951. 0015h                   1 dword  Size of the compressed file
  952. 0019h                   1 dword  Offset of compressed data in archive file
  953. 001Dh                   3 byte   reserved
  954. 0020h                   1 byte   Method :
  955.                                   1 - crunched
  956.                                   2 - stored
  957.  
  958. The trailer at the end of each archive has the following format :
  959. OFFSET              Count TYPE   Description
  960. 0000h                   1 word   Length of trailer (=27)
  961. 0002h                   1 word   Size of the directory entries (=34)??
  962. 0004h                  16 byte   reserved
  963. 0014h                   1 dword  Count of the directory entries
  964. 0018h                   3 char   ID="DWC"
  965.  
  966. EXTENSION:DWC??
  967. OCCURENCES:PC??
  968. PROGRAMS:DWC.EXE??
  969. --------S-EFE-------------------------------
  970. The EFE files are instrument files for the Ensoniq sampler system.
  971. Further information wanted.
  972. EXTENSION:EFE
  973. SEE ALSO:GKH,INS
  974. --------E-EXE-X-----------------------------
  975. Different types of executables have emerged on the Intel DOS related platforms -
  976. but all contain at least a stub MZ Exe before their actual EXE body...
  977. SEE ALSO:MZ EXE,NE EXE
  978. --------M-FAR-------------------------------
  979. The Fandarole composer is a 16 channel composer created by the group
  980. Digital Infinity / Daniel Potter for digital music in module style.
  981.  
  982. The Fandarole modules have the following format :
  983. OFFSET              Count TYPE   Description
  984. 0000h                   4 char   ID='FAR',254
  985. 0004h                  40 char   Song name
  986. 002Ch                   3 char   ID=13,10,26
  987.                                  This ID makes it possible to see the song name
  988.                                  by simply typing the .far file.
  989. 002Fh                   1 word   Remaining header size
  990. 0031h                   1 byte   Version number as BCD,
  991.                                    high nibble = major version
  992.                                    low nibble = minor version
  993. 0032h                  16 byte   Channel on/off map
  994.                                   <> 0 means that channel is used
  995. 0042h                   1 rec    Editing data.
  996.                                  This data is not necessary for playback,
  997.                                  but is stored by the composer for resume of
  998.                                  edit.
  999.                         1 byte   Current octave
  1000.                         1 byte   Current voice
  1001.                         1 byte   Current row
  1002.                         1 byte   Current pattern
  1003.                         1 byte   Current order
  1004.                         1 byte   Current sample
  1005.                         1 byte   Current volume
  1006.                         1 byte   Current top of screen display
  1007.                         1 byte   Current editing area
  1008.                                   0=samples,
  1009.                                   1=patterns,
  1010.                                   2=orders
  1011.                         1 byte   Current tempo (default tempo)
  1012. 004Ch                  16 byte   Panning map for each channel, 0=left,15=right
  1013. 005Ch                   1 byte   Marked block start
  1014. 005Dh                   1 byte   Marked block end
  1015. 005Eh                   1 byte   Grid granularity
  1016. 005Fh                   1 byte   Edit mode
  1017. 0060h                   1 word   Song text length
  1018.                                  ="STL"
  1019. 0062h               "STL" char   Song text
  1020. 0062h+                256 byte   Order bytes for pattern ordering
  1021.  "STL"
  1022. 0162h+                  1 byte   Number of stored patterns
  1023.  "STL"
  1024. 0163h+                  1 byte   Song length in patterns
  1025.  "STL"
  1026. 0164h+                  1 byte   Loop position. This is the restart position
  1027.  "STL"                           if the end of the song is reached.
  1028. 0165h+                256 word   Length of each pattern. The number of rows in 
  1029.  "STL"                           each pattern is ( this word-2 )/(16*4)
  1030.  
  1031. After this block, there might be additional data in the future (see remaining
  1032. header size, above), after that, the pattern data follows.
  1033.  
  1034. The pattern data :
  1035. OFFSET              Count TYPE   Description
  1036. 0000h                   1 byte   Length of pattern in rows
  1037.                                  ="LIR"
  1038. 0001h                   1 byte   Tempo for this pattern - Unsupported,
  1039.                                  use not recommended
  1040. 0002h             4*"LIR" rec    Note data for each pattern in 4 channels
  1041.                         1 byte   Note value (Octave*12+Note)+1
  1042.                                  0 means no note
  1043.                         1 byte   Sample number
  1044.                         1 byte   Volume byte. The volume is stored reversed,
  1045.                                  the lower nibble is the major volume, the lower
  1046.                                  nibble is the minor volume adjust.
  1047.                         1 byte   Effect byte. Upper nibble is effect, lower
  1048.                                  nibble is data. (see table 0004)
  1049.  
  1050. (Table 0004)
  1051. Note Effects in FAR-modules
  1052.     01 - Pitch adjust
  1053.     02 - Pitch adjust
  1054.     03 - Portamento to note
  1055.     04 - Retrigger note data times for one bar
  1056.     05 - Set vibrato depth
  1057.     06 - Vibrato
  1058.  07-0C - ?Possibly undefined?
  1059.     0D - Fine tune tempo down 128/Tempo
  1060.     0E - Fine tune tempo up 128/Tempo
  1061.     0F - Tempo, notes per second = 32/Tempo
  1062.  
  1063. After the pattern data, the sample map follows. This is an array of 64 bits
  1064. (eight bytes), each set bit corresponds to a sample record stored in the file,
  1065. each zero bit means that the corresponding record is not stored in the file.
  1066.  
  1067. OFFSET              Count TYPE   Description
  1068. 0000h                   8 byte   Sample flags, see above
  1069.  
  1070. After the sample flags, the samples themselves are stored in the FSM format,
  1071. except for the ("FSM",254) header. They follow header-data-header-data-etc.,
  1072. see the FSM entry for further information.
  1073.  
  1074. EXTENSION:FAR
  1075. OCCURENCES:PC
  1076. PROGRAMS:Fandarole Composer
  1077. REFERENCE:
  1078. SEE ALSO:FSM
  1079. VALIDATION:
  1080. --------a-FLT-------------------------------
  1081. The FLC files are files created by the Autodesk Animator Pro and contain
  1082. animations. The FLC files are a superset of those created by the Autodesk
  1083. Animator (FLIc files). In some cases, new data fields or compression methods
  1084. were added. The FLC files use a hierarchical block oriented structure and blocks
  1085. are a combination of control information and data. The file consists of one
  1086. header followed by data blocks. It is possible that new types of blocks not
  1087. described in this document will be added to animation files in the future. It is
  1088. recommended that you quietly ignore unknown block types you encounter during
  1089. animation playback.  The size fields in the block headers make it easy to skip
  1090. an entire unrecognized block.
  1091.  
  1092. The FLC files consist of one 128-byte header block and one or more of the
  1093. following blocks :
  1094.  
  1095. The prefix block, if present, contains Animator Pro settings information,
  1096. CEL placement information, and other auxiliary data.
  1097.  
  1098. A frame block exists for each frame in the animation. In addition, a ring frame
  1099. follows all the animation frames. Each frame block contains color palette
  1100. information and/or pixel data.
  1101.  
  1102. The ring frame contains delta-compressed information to loop from the last frame
  1103. of the flic back to the first. It can be helpful to think of the ring frame as a
  1104. copy of the first frame, compressed in a different way. All flic files will
  1105. contain a ring frame, including a single-frame flic.
  1106.  
  1107. The FLC file header
  1108.  
  1109. OFFSET              Count TYPE   Description
  1110. 0000h                   1 dword  The size of the whole animation file, including
  1111.                                  the size of this header.
  1112. 0004h                   1 word   ID=0AF12h
  1113. 0006h                   1 word   Number of frames in this animation, not
  1114.                                  including the ring frame. FLC files have a
  1115.                                  maximum length of 4000 frames.
  1116. 0008h                   1 word   Screen width in pixels
  1117. 000Ah                   1 word   Screen height in pixels
  1118. 000Ch                   1 word   Bits per pixel (always 8)
  1119. 000Eh                   1 word   Flags - bitmapped
  1120.                                  0 - Ring frame not written / ring frame written
  1121.                                  1 - Flic header not updated / updated
  1122.                               2-15 - reserved
  1123. 0010h                   1 dword  Delay between frames in miliseconds.
  1124. 0014h                   1 word   reserved
  1125. 0016h                   1 dword  MS-DOS date and time of file creation (see table 0009)
  1126. 001Ah                   1 dword  Serial number of the Animator Pro program used
  1127.                                  to create the file. If the file was created
  1128.                                  with the FlicLib development kit, this value
  1129.                                  equals 0464c4942h ("FLIB").
  1130. 001Eh                   1 dword  MS-DOS date and time of last modification (see table 0009)
  1131. 0022h                   1 dword  Serial number of program that made the last
  1132.                                  modification. See Serial Number.
  1133. 0026h                   1 word   X-axis aspect ratio of the file
  1134. 0028h                   1 word   Y-axis aspect ratio of the file
  1135.                                  (320x200 = 6:5)
  1136. 002Ah                  38 byte   reserved (0)
  1137. 0050h                   1 dword  Offset from begin of file to the first
  1138.                                  animation frame block.
  1139. 0054h                   1 dword  Offset from begin of file to the second
  1140.                                  animation frame block. This value is used
  1141.                                  when looping the animation.
  1142. 0058h                  40 byte   reserved (0)
  1143.  
  1144. Each subblock in the animation file has an identical header structure,
  1145. which is formatted like this :
  1146. 0000h                   1 dword  The size of the whole block and all subordinate
  1147.                                  blocks including the size of this header
  1148. 0004h                   1 word   Block ID, varies depending on the block type.
  1149. 0006h                   1 word   Number of subordinate blocks in this block.
  1150.                                  including the ring frame. FLC files have a
  1151.                                  maximum length of 4000 frames.
  1152. 0008h                   8 byte   reserved(0)
  1153.  
  1154. Immediately after the header there may be an optional prefix block, which is
  1155. used to store additional data which is not directly involved in animation
  1156. playback.
  1157.  
  1158. The prefix block has the usual header with an ID of 0F100h.
  1159. The prefix block should only be created by the Animator Pro programs and never
  1160. by any other software, it is to be ignored by other software.
  1161.  
  1162. The FLC frame blocks contain the information to convert the current frame into
  1163. the next frame; they have an ID of 0F1FAh. Directly after the frame header,
  1164. there are the subordinate data blocks - if the subblock count is 0 this means,
  1165. that the current frame is identical to the previous frame, only the appropriate
  1166. delay has to be made.
  1167. The data blocks have a different header format :
  1168. OFFSET              Count TYPE   Description
  1169. 0000h                   1 dword  Size of this block, including header size
  1170. 0004h                   1 word   Data type identifier :
  1171.                                   4 - 256-level color palette info
  1172.                                   7 - Word-oriented delta compression
  1173.                                  11 - 64-level color palette info
  1174.                                  12 - Byte-oriented delta compression
  1175.                                  13 - Entire frame is color index 0
  1176.                                  15 - Byte run length compression
  1177.                                  16 - No compression
  1178.                                  18 - Postage stamp sized image
  1179. 0006h                   ? byte   Color or pixel data
  1180.  
  1181. The following sections describe each of these data encoding methods in detail.
  1182.  
  1183. --- Block Type  4 (FLI_COLOR256) - 256-Level Color
  1184.  
  1185. The data in this block is organized in packets.  The first word following the
  1186. block header is a count of the number of packets in the blocks. Each packet
  1187. consists of a one-byte color index skip count, a one-byte color count and three
  1188. bytes of color information for each color defined.
  1189.  
  1190. At the start of the block, the color index is assumed to be zero. Before
  1191. processing any colors in a packet, the color index skip count is added to the
  1192. current color index.  The number of colors defined in the packet is retrieved.
  1193. A zero in this byte indicates 256 colors follow. The three bytes for each color
  1194. define the red, green, and blue components of the color in that order. Each
  1195. component can range from 0 (off) to 255 (full on).  The data to change colors
  1196. 2,7,8, and 9 would appear as follows:
  1197.  
  1198.      2                      ; two packets
  1199.      2,1,r,g,b              ; skip 2, change 1
  1200.      4,3,r,g,b,r,g,b,r,g,b  ; skip 4, change 3
  1201.  
  1202. --- Block Type 11 (FLI_COLOR) - 64-Level Color
  1203.  
  1204. This block is identical to FLI_COLOR256 except that the values for the red,
  1205. green and blue components are in the range of 0-63 instead of 0-255, i.e. in
  1206. native VGA values which can be written to the VGA without modification.
  1207.  
  1208. --- Block Type 13 (FLI_BLACK) - No Data
  1209. This block has no data following the header. All pixels in the frame are set to
  1210. color index 0.
  1211.  
  1212. --- Block Type 16 (FLI_COPY) - No Compression
  1213.  
  1214. This block contains an uncompressed raw image of the frame, from upper left
  1215. to the lower right, storing each line sequentially. This type of block is
  1216. created when the preferred compression method (SS2 or BRUN) generates more
  1217. data than the uncompressed frame image; a relatively rare situation.
  1218.  
  1219. --- Block Type 15 (FLI_BRUN) - Byte Run Length Compression
  1220.  
  1221. This block contains the entire image in a compressed format. Usually this block
  1222. is used in the first frame of an animation, or within a postage stamp image
  1223. block.
  1224.  
  1225. The data is organized in lines. Each line contains packets of compressed pixels.
  1226. The first line is at the top of the animation, followed by subsequent lines
  1227. moving downward. The number of lines in this block is given by the height of the
  1228. animation.
  1229.  
  1230. The first byte of each line is a count of packets in the line. This value is
  1231. ignored, it is a holdover from the original Animator. It is possible to generate
  1232. more than 255 packets on a line. The width of the animation is now used to drive
  1233. the decoding of packets on a line; continue reading and processing packets until width
  1234. pixels have been processed, then proceed to the next line.
  1235.  
  1236. Each packet consist of a type/size byte, followed by one or more pixels. If the
  1237. high bit of the packet type is set, the remaining 7 bits are a count of pixels
  1238. to be copied from the packet to the animation image, otherwise the next byte
  1239. contains a single pixel which is to be replicated; The lower 7 bits are the
  1240. number of times the pixel is to be replicated.
  1241.  
  1242. --- Block Type 12 (FLI_LC) - Byte Aligned Delta Compression
  1243.  
  1244. This block contains the differences between the previous frame and this frame.  This compression method was used by the original
  1245. Animator, but is not created by Animator Pro. This type of block can appear in
  1246. an Animator Pro file, however, if the file was originally created by Animator,
  1247. then some (but not all) frames were modified using Animator Pro.
  1248.  
  1249. The first word following the block header contains the position of the first
  1250. line in the block. This is a count of lines (down from the top of the image)
  1251. which are unchanged from the prior frame. The second word contains the number of
  1252. lines in the block. The data for the lines follows these two words.
  1253.  
  1254. Each line begins with two bytes. The first byte contains the starting x position
  1255. of the data on the line, and the second byte the number of packets for the line.
  1256. Unlike BRUN compression, the packet count is significant (because this
  1257. compression method is only used on 320x200 flics).
  1258.  
  1259. Each packet consists of a single byte column skip, followed by a packet type/
  1260. size byte, which has the reverse meaning of in the block type 15.
  1261.  
  1262. --- Block Type  7 (FLI_SS2) - Word Aligned Delta Compression
  1263.  
  1264. This format contains the differences between consecutive frames. This is the
  1265. format most often used by Animator Pro for frames other than the first frame of
  1266. an animation. It is similar to the line coded delta (LC) compression, but is
  1267. word oriented instead of byte oriented. The data is organized into lines and
  1268. each line is organized into packets.
  1269.  
  1270. The first word in the data following the block header contains the number of
  1271. lines in the block. Each line can begin with some optional words that are used
  1272. to skip lines and set the last byte in the line for animations with odd widths.
  1273. These optional words are followed by a count of the packets in the line. The
  1274. line count does not include skipped lines.
  1275.  
  1276. The high order two bits of the word is used to determine the contents of
  1277. the word :
  1278.  
  1279.      Bit 15  Bit 14       Meaning
  1280.  
  1281.        0      0           The word contains the packet count. The packets follow
  1282.                           this word. The packet count can be zero; this occurs
  1283.                           when only the last pixel on a line changes.
  1284.  
  1285.        1      0           The low order byte is to be stored in the last byte of
  1286.                           the current line. The packet count always follows this
  1287.                           word.
  1288.  
  1289.        1      1           The word contains a line skip count. The number of
  1290.                           lines skipped is given by the absolute value of the
  1291.                           word.  This word can be followed by more skip counts,
  1292.                           by a last byte word, or by the packet count.
  1293.  
  1294. The packets in each line are similar to the packets for the line coded block.
  1295. The first byte of each packet is a column skip count. The second byte is a
  1296. packet type. If the packet type is positive, the packet type is a count of words
  1297. to be copied from the packet to the animation image. If the packet type is
  1298. negative, the packet contains one more word which is to be replicated. The
  1299. absolute value of the packet type gives the number of times the word is to be
  1300. replicated. The high and low order byte in the replicated word do not
  1301. necessarily have the same value.
  1302.  
  1303. --- Block Type 18 (FLI_PSTAMP) - Postage Stamp Image
  1304.  
  1305. This block type holds a postage stamp - a reduced-size image - of the frame. It
  1306. generally appears only in the first frame block within a flic file. When
  1307. creating a postage stamp, Animator Pro considers the ideal size to be 100x63
  1308. pixels. The actual size will vary as needed to maintain the same aspect ratio as
  1309. the original.
  1310. The pixels in a postage stamp image are mapped into a six-cube color space,
  1311. regardless of the color palette settings for the full frame image. A six-cube
  1312. color space is formed as follows:
  1313.  
  1314.      start at palette entry 0
  1315.      for red = 0 thru 5
  1316.           for green = 0 thru 5
  1317.                for blue = 0 thru 5
  1318.                     palette_red   = (red   * 256)/6
  1319.                     palette_green = (green * 256)/6
  1320.                     palette_blue  = (blue  * 256)/6
  1321.                     move to next palette entry
  1322.                end for blue
  1323.           end for green
  1324.      end for red
  1325.  
  1326. Any arbitrary rgb value (where each component is in the range of 0-255) can be
  1327. mapped into the six-cube space using the formula:
  1328.  
  1329.   ((6*red)/256)*36 + ((6*green)/256)*6 + ((6*blue)/256)
  1330.  
  1331. The full postage stamp block header is defined as follows:
  1332.  
  1333. Offset  Length  Name         Description
  1334. OFFSET              Count TYPE   Description
  1335. 0000h                   1 dword  Size of this block, including header size
  1336. 0004h                   1 word   ID=18
  1337. 0006h                   1 word   Height of the postage stamp image
  1338. 0008h                   1 word   Width of the image
  1339. 000Ah                   1 word   Color translation type :
  1340.                                  1 - six-cube color space
  1341.  
  1342. Immediately following this header is the postage stamp data. The data is
  1343. formatted as a block with standard size/type header. The type will be one of:
  1344.  
  1345.      15     FPS_BRUN         Byte run length compression
  1346.      16     FPS_COPY         No compression
  1347.      18     FPS_XLAT256      Six-cube color xlate table
  1348.  
  1349. The FPS_BRUN and FPS_COPY types are identical to the FLI_BRUN and FLI_COPY
  1350. encoding methods described above.
  1351.  
  1352. The FPS_XLAT256 type indicates that the block contains a 256-byte color
  1353. translation table instead of pixel data. To process this type of postage stamp,
  1354. read the pixel data for the full-sized frame image, and translate its pixels
  1355. into six-cube space using a lookup in the 256-byte color translation table. This
  1356. type of postage stamp appears when the size of the animation frames is smaller
  1357. than the standard 100x63 postage stamp size. 
  1358. *************
  1359. TWE - Tween Data Files
  1360.  
  1361. A TWE file holds information about a tweening operation set up
  1362. via the Tween menus.  The information includes the starting and
  1363. ending shapes, and the optional userD specified links between the
  1364. shapes.  Animator Pro creates tween files.
  1365.  
  1366. A TWE file begins with an 8-byte header defined as follows:
  1367.  
  1368. Offset  Length  Name         Description
  1369.  
  1370.   0       2     magic        File format identifier. Always hex 1995.
  1371.  
  1372.   2       2     version      The file format version; always zero.
  1373.  
  1374.   4       4     tcount       The number of tween shapes in the file;
  1375.                              always 2.
  1376.  
  1377.   8       8     reserved     Unused space; set to zeroes.
  1378.  
  1379.   16      4     linkcount    The number of link entries in the file.
  1380.  
  1381. Immediately following the file header are the link entries.  If
  1382. the linkcount value is zero there are no links.  Each link entry
  1383. is a pair of 32-bit integers. The first value in each pair is the
  1384. index of the point in the first shape, and the second value is
  1385. the index of the point in the ending shape.  (IE, a link value of
  1386. 2,7 says to link the second starting-shape point to the seventh
  1387. ending-shape point.)
  1388.  
  1389. Following the link entries is the data block that describes the
  1390. starting shape, then the data block that describes the ending
  1391. shape.  The format of these blocks is identical to that of the
  1392. polygon (PLY) file, including file header data.  In other words,
  1393. they appear as if a pair of polygon files are embedded in the
  1394. tween file at this point.
  1395.  
  1396. **********
  1397. OPT - Optics Menu Settings Files
  1398.  
  1399.  
  1400. An OPT file holds information about an optics operation set up
  1401. via the Optics menus.  Both Animator Pro and the original
  1402. Animator create OPT files.  The file format is the same for both.
  1403.  
  1404. An OPT file starts with a 4-byte header, as follows:
  1405.  
  1406. Offset  Length  Name         Description
  1407.  
  1408.   0       2     magic        File type identifier.  Always hex 1A3F.
  1409.  
  1410.   2       2     count        Number of records in the file.
  1411.  
  1412. Following the file header are optics records of 50 bytes each.  A
  1413. record is generated for each click on CONTINUE MOVE in the OPTICS
  1414. menu.  The move records are formatted as follows:
  1415.  
  1416. Offset  Length  Name         Description
  1417.  
  1418.   0       4     link         In the file, this field is always zero.
  1419.                              In memory, it's a pointer to the next 
  1420.                              move record.
  1421.  
  1422.   4       6     spincenter   The x,y,z coordinates of the spin
  1423.                              center point; three 16-bit values.
  1424.  
  1425.   10      6     spinaxis     The x,y,z coordinates of the spin axis;
  1426.                              three 16-bit values.
  1427.  
  1428.   16      6     spinturns    The x,y,z coordinates of the spin turns;
  1429.                              three 16-bit values.
  1430.  
  1431.   22      4     spininter    Intermediate turns.  Two 16-bit values.
  1432.                              These are values for a conjugation matrix 
  1433.                              that corresponds to spin axis.
  1434.  
  1435.   26      6     sizecenter   The x,y,z coordinates of the size
  1436.                              center point; three 16-bit values.
  1437.  
  1438.   32      2     xmultiplier  Determines (along with xdivisor)
  1439.                              how to scale along x dimension.
  1440.  
  1441.   34      2     xdivisor     Determines (along with xmultiplier) how
  1442.                              to scale along x dimension.
  1443.  
  1444.   36      2     ymultiplier  Determines (along with ydivisor)
  1445.                              how to scale along y dimension.
  1446.  
  1447.   38      2     ydivisor     Determines (along with ymultiplier) how
  1448.                              to scale along y dimension.
  1449.  
  1450.   40      2     bothmult     Like xmultiplier, but applied to both
  1451.                              dimensions.
  1452.  
  1453.   42      2     bothdiv      Like xdivisor, but applied to both
  1454.                              dimensions.
  1455.  
  1456.   44      6     linearmove   The x,y,z offset for a linear move;
  1457.                              three 16-bit values.
  1458.  
  1459. EXTENSION:FLT
  1460. OCCURENCES:PC
  1461. PROGRAMS:Autodesk Animator Pro
  1462. REFERENCE:
  1463. SEE ALSO:FLIc
  1464. VALIDATION:
  1465. --------a-FLIc------------------------------
  1466. The Flic file format was one of the first graphic animation formats on the PC.
  1467. It was developed by <> and used by the Autodesk Animator. It provides relatively
  1468. fast animation in 320x200 resolution modes. The FLI use delta updating for
  1469. faster animation. The single block information and prefix blocks are missing for
  1470. the FLI files, see the FLT format for a discussion.
  1471.  
  1472. OFFSET              Count TYPE   Description
  1473. 0000h                   1 dword  Size of the FLIc file
  1474. 0004h                   1 word   ID=0AF11h
  1475.                                  AF11h means the file is a FLI file.
  1476. 0006h                   1 word   Number of frames
  1477. 0008h                   1 word   Width of displayed animation
  1478. 000Ah                   1 word   Height of displayed animation
  1479. 000Ch                   1 word   Number of used colors ("Depth")
  1480. 000Eh                   1 word   Flags (=0003h)
  1481. 0010h                   1 dword  Frame speed in sec/1024 **
  1482. 0014h                   1 word   reserved
  1483. 0016h                   1 dword  Date/Time of creation in DOS format (see table 0009)
  1484. 001Ah                   1 dword  Creator
  1485. 001Eh                   1 dword  Date/Time of last change in DOS format (see table 0009)
  1486. 0022h                   1 dword  Serial number? of changer
  1487. 0026h                   1 word   X-Aspect ratio of animation
  1488. 0028h                   1 word   Y-Aspect ratio of animation
  1489. 002Ah                  38 byte   reserved
  1490. 0052h                   1 dword  Offset of frame 1 in file
  1491. 0056h                   1 dword  Offset of frame 2 in file
  1492. 005Ah                  40 byte   reserved
  1493. EXTENSION:FLI,FLT
  1494. OCCURENCES:PC
  1495. REFERENCE:DDJ0693
  1496. PROGRAMS:Autodesk Animator
  1497. SEE ALSO:QuickTime,AVI,FLT
  1498. --------D-FON-?-----------------------------
  1499. The Telix .FON files are the telephone books Telix uses to store numbers in.
  1500. The format is for Telix 3.22
  1501.  
  1502. OFFSET              Count TYPE   Description
  1503. 0000h                   1 dword  ID=2E2B291Ah
  1504. 0004h                   1 word   Version info (=1)
  1505. 0006h                   1 word   Number of entries in directory (count from 1)
  1506. 0007h                   1 char   ?will be used for encryption?
  1507.                                  Currently 0
  1508. 0008h                  55 byte   reserved
  1509. 0040h                   ? rec    Actual phonebook entry
  1510.                        25 char   Name (0 terminated)
  1511.                        17 char   Phone number (0 terminated)
  1512.                         1 byte   Baud rate (see table 0006)
  1513.                         1 byte   Parity type (see table 0007)
  1514.                         1 byte   Data bits (7 or 8)
  1515.                         1 byte   Stop bits (1 or 2)
  1516.                        12 char   Script file name
  1517.                         6 char   Date of last call in ASCII
  1518.                         1 word   Number of total calls
  1519.                         1 byte   Terminal type (see table 0008)
  1520.                         1 byte   Protocol
  1521.                         1 byte   Flags, bitmapped
  1522.                                    0 - Local echo on / off
  1523.                                    1 - add linefeeds on / off
  1524.                                    2 - backspace is destructive on / off
  1525.                                    3 - backspace sends DEL / sends BS
  1526.                                    4 - strip high bits on / off
  1527.                                  5-7 - reserved
  1528.                         1 word   unknown
  1529.                         1 byte   Dial prefix index
  1530.                        14 char   Password
  1531.  
  1532. (Table 0006)
  1533. Baud rate tables for Telix
  1534.  
  1535.   0 =    300 baud
  1536.   1 =   1200 baud
  1537.   2 =   2400 baud
  1538.   3 =   4800 baud
  1539.   4 =   9600 baud
  1540.   5 =  19200 baud
  1541.   6 =  38400 baud
  1542.   7 =  57600 baud
  1543.   8 = 115200 baud
  1544.  
  1545. (Table 0007)
  1546. Parity types for Telix
  1547.  
  1548.    0 = None
  1549.    1 = Even
  1550.    2 = Odd
  1551.    3 = Mark
  1552.    4 = Space
  1553.  
  1554. (Table 0008)
  1555. Terminal types for Telix
  1556.  
  1557.    0 = TTY
  1558.    1 = ANSI-BBS
  1559.    2 = VT102
  1560.    3 = VT52
  1561.    4 = AVATAR
  1562.    5 = ANSI
  1563.  
  1564. EXTENSION:FON
  1565. OCCURENCES:PC
  1566. PROGRAMS:Telix v3.22
  1567. REFERENCE:
  1568. SEE ALSO:
  1569. VALIDATION:
  1570. --------M-FPT-------------------------------
  1571. The Fandarole Pattern files are used by the Fandarole Composer to store
  1572. single patterns in a file.
  1573.  
  1574. OFFSET              Count TYPE   Description
  1575. 0000h                   4 char   ID='FPT',254
  1576. 0004h                  32 char   ASCII pattern name
  1577. 0024h                   3 char   ID=10,13,26
  1578. 0027h                   1 word   Remaining size of file (size of pattern)
  1579. 0029h                   1 byte   Break location (length of pattern)
  1580. 002Ah                   1 byte   reserved
  1581. 002Bh                   ? byte   Pattern in raw format like in the .FAR file
  1582. EXTENSION:FAR,FPT
  1583. OCCURENCES:PC
  1584. PROGRAMS:Fandarole Composer
  1585. SEE ALSO:FAR,FSM
  1586. VALIDATION:
  1587. --------S-FSM-------------------------------
  1588. The .FSM files are samples to be used for module style music with the
  1589. Fandarole Composer. Currently only samples of up to 64K length are supported,
  1590. altough the header reserves a dword for the sample size.
  1591. OFFSET              Count TYPE   Description
  1592. 0000h                   4 char   ID='FSM',254
  1593. 0004h                  32 char   ASCII name of sample
  1594. 0024h                   3 char   ID=10,13,26
  1595. 0027h                   1 dword  Length of sample (<=64K)
  1596. 0028h                   1 byte   Fine tune value for sample
  1597.                                  (currently unsupported)
  1598. 0029h                   1 byte   Sample volume
  1599.                                  (currently unsupported)
  1600. 002Ah                   1 dword  Start of sample loop
  1601. 002Dh                   1 dword  End of sample loop. If the sample is not set
  1602.                                  to loop (see below) this should be set to the
  1603.                                  end of the sample.
  1604. 0032h                   1 byte   Sample type, bitmapped
  1605.                                    0 - 8-bit/16-bit sample
  1606.                                  1-7 - reserved
  1607. 0033h                   1 byte   Loop mode, ?bit mapped?
  1608.                                  0-2 - reserved
  1609.                                    3 - loop off/loop on
  1610.                                  4-7 - reserved
  1611. 0034h                   ? byte   Sample data in signed format
  1612.  
  1613. EXTENSION:FSM
  1614. OCCURENCES:PC
  1615. PROGRAMS:Fandarole Composer
  1616. REFERENCE:
  1617. SEE ALSO:FAR,USM
  1618. VALIDATION:
  1619. --------S-GF1 PATCH-------------------------
  1620. The GF1 Patch files are multipart sound files for the Gravis Ultrasound
  1621. sound card to emulate MIDI sounds in high quality. Each Patch can consist
  1622. of many samples (for example, a string ensemble consists of Violin, Viola,
  1623. Cello, Bass) which are played depending on the note to play. A patch can also
  1624. contain a part to be played before the loop and a part to be played after
  1625. the tone has been released.
  1626. OFFSET              Count TYPE   Description
  1627. 0000h                  12 char   ID='GF1PATCH110'
  1628. 000Ch                  10 char   Manufacturer ID
  1629. 0018h                  60 char   Description of the contained Instruments
  1630.                                  or copyright of manufacturer.
  1631. 0054h                   1 byte   Number of instruments in this patch
  1632. 0055h                   1 byte   Number of voices for sample
  1633. 0056h                   1 byte   Number of output channels
  1634.                                  (1=mono,2=stereo)
  1635. 0057h                   1 word   Number of waveforms
  1636. 0059h                   1 word   Master volume for all samples
  1637. 005Bh                   1 dword  Size of the following data
  1638. 0060h                  36 byte   reserved
  1639.  
  1640. Following this header, the instruments with their headers follow.
  1641. An instrument header contains the name and other data about one
  1642. instrument contained within the patch.
  1643. OFFSET              Count TYPE   Description
  1644. 0000h                   1 word   Instrument number. ?Maybe the MIDI instrument
  1645.                                  number?. In the Gravis patches, this is 0, in
  1646.                                  other patches, I found random values.
  1647. 0002h                  16 char   ASCII name of the instrument.
  1648. 0012h                   1 dword  Size of the whole instrument in bytes.
  1649. 0016h                   1 byte   Layers. Needed for whatever.
  1650. 0017h                  40 byte   reserved
  1651.  
  1652. About the patch, I don't know anything. Maybe somebody could enlighten me.
  1653. Each patch record has the following format :
  1654. OFFSET              Count TYPE   Description
  1655. 0000h                   7 char   Wave file name
  1656. 0007h                   1 byte   Fractions
  1657. 0008h                   1 dword  Wave size.
  1658.                                  Size of the wave digital data
  1659. 000Ch                   1 dword  Start of wave loop
  1660. 0010h                   1 dword  End of wave loop
  1661. 0012h                   1 word   Sample rate of the wave
  1662. 0014h                   1 word   Minimum frequency to play the wave
  1663. 0016h                   1 word   Maximum frequency to play the wave
  1664. 0018h                   1 dword  Original sample rate of the wave data
  1665. 001Ch                   1 int    Fine tune value for the wave
  1666. 001Eh                   1 byte   Stereo balance, values unknown**
  1667. 001Fh                   6 byte   Filter envelope rate
  1668. 0025h                   6 byte   Filter envelope offse
  1669. 002Bh                   1 byte   Tremolo sweep
  1670. 002Ch                   1 byte   Tremolo rate
  1671. 002Dh                   1 byte   Tremolo depth
  1672. 002Fh                   1 byte   Vibrato sweep
  1673. 0030h                   1 byte   Vibrato rate
  1674. 0031h                   1 byte   Vibrato depth
  1675. 0032h                   1 byte   Wave data, bitmapped
  1676.                                    0 - 8/16 bit wave data
  1677.                                    1 - signed/unsigned data
  1678.                                    2 - de/enable looping
  1679.                                    3 - no/has bidirectional looping
  1680.                                    4 - loop forward/backward
  1681.                                    5 - Turn envelope sustaining off/on
  1682.                                    6 - Dis/Enable filter envelope
  1683.                                    7 - reserved
  1684. 0033h                   1 int    Frequency scale, whatever that means
  1685. 0035h                   1 word   Frequency scale factor
  1686. 0037h                  36 byte   Reserved
  1687.  
  1688. EXTENSION:PAT
  1689. OCCURENCES:PC
  1690. PROGRAMS:Patch Maker
  1691. SEE ALSO:VOC,WAVe
  1692. --------I-GIF-------------------------------
  1693. The Graphics Interchange Format (tm) was created by Compuserve Inc. as a
  1694. standard for the storage and transmission of raster-based graphics information,
  1695. i.e. images. A GIF file may contain several images, which are to be displayed
  1696. overlapping and without any delay betwenn the images. The image data itself is
  1697. compressed using a LZW scheme.
  1698. The GIF file consists of a global GIF header, one or more image blocks and
  1699. optionally some GIF extensions.
  1700.  
  1701. OFFSET              Count TYPE   Description
  1702. 0000h                   6 char   ID='GIF87a', ID='GIF89a'
  1703.                                  This ID may be viewed as a version number
  1704. 0006h                   1 word   Image width
  1705. 0008h                   1 word   Image height
  1706. 000Ah                   1 byte   bit mapped
  1707.                                  0-2 - bits per pixel -1
  1708.                                    3 - reserved
  1709.                                  4-6 - bits of color resolution
  1710.                                    7 - Global color map follows image descriptor
  1711. 000Bh                   1 byte   Color index of screen background
  1712. 000Ch                   1 byte   reserved
  1713.  
  1714. The global color map immediately follows the screen descriptor and has the size
  1715. (2**BitsPerPixel), and has the RGB colors for each color index. 0 is none, 255
  1716. is full intensity. The bytes are stored in the following format :
  1717. OFFSET              Count TYPE   Description
  1718. 0000h                   1 byte   Red component
  1719. 0001h                   1 byte   Green component
  1720. 0002h                   1 byte   Blue component
  1721.  
  1722. After the first picture, there may be more pictures attached in the file
  1723. whic overlay the first picture or parts of the first picture. The Image
  1724. Descriptor defines the actual placement and extents of the following image
  1725. within the space defined in the Screen Descriptor. Each Image Descriptor is
  1726. introduced by an image separator character. The role of the Image Separator
  1727. is simply to provide a synchronization character to introduce an Image
  1728. Descriptor, the image separator is defined as ",", 02Ch, Any characters
  1729. encountered between the end of a previous image and the image separator
  1730. character are to be ignored.
  1731.  
  1732. The format of the Image descriptor looks like this :
  1733. OFFSET              Count TYPE   Description
  1734. 0000h                   1 char   Image separator
  1735.                                  ID=','
  1736. 0001h                   1 word   Left offset of image
  1737. 0003h                   1 word   Upper offset of image
  1738. 0005h                   1 word   Width of image
  1739. 0007h                   1 word   Height of image
  1740. 0009h                   1 byte   Palette description - bitmapped
  1741.                                  0-2 - Number of bits per pixel-1
  1742.                                  3-5 - reserved (0)
  1743.                                    6 - Interlaced / sequential image
  1744.                                    7 - local / global color map, ignore bits 0-2
  1745.  
  1746. To provide for some possibility of an extension of the GIF files, a special
  1747. extension block introducer can be added after the GIF data block. The block has
  1748. the following structure :
  1749.  
  1750. OFFSET              Count TYPE   Description
  1751. 0000h                   1 char   ID='!'
  1752. 0001h                   1 byte   Extension ID
  1753. 0002h                   ? rec
  1754.                         1 word   Byte count
  1755.                         ? byte   Extra data
  1756. ????h                   1 byte   Zero byte count - terminates extension block.
  1757.  
  1758. EXTENSION:GIF
  1759. OCCURENCES:PC
  1760. PROGRAMS:CSHOW.EXE
  1761. SEE ALSO:
  1762. VALIDATION:
  1763. --------A-GZIP------------------------------
  1764. The GNU ZIP program is an archive program mostly for the UNIX machines developed
  1765. by the GNU project.
  1766. OFFSET              Count TYPE   Description
  1767. 0000h                   2 char   ID='!',139
  1768. 0002h                   1 byte   Method :
  1769.                                  0-7 - reserved
  1770.                                    8 - deflated
  1771. 0003h                   1 byte   File flags :
  1772.                                    0 - ASCII-text
  1773.                                    1 - Multi-part file
  1774.                                    2 - Name present
  1775.                                    3 - Comment present
  1776.                                    4 - Encrypted
  1777.                                  5-8 - reserved
  1778. 0004h                   1 dword  File date and time (see table 0009)
  1779. 0008h                   1 byte   Extra flags
  1780. 0009h                   1 byte   Target OS :
  1781.                                    0 - DOS
  1782.                                    1 - Amiga
  1783.                                    2 - VMS
  1784.                                    3 - Unix
  1785.                                    4 - ????
  1786.                                    5 - Atari
  1787.                                    6 - OS/2
  1788.                                    7 - MacOS
  1789.                                   10 - TOPS-20
  1790.                                   11 - Win/32
  1791. EXTENSION:ZIP
  1792. PROGRAMS:GNU gzip
  1793. --------S-GKH-------------------------------
  1794. The GKH files are disk images of the Ensoniq EPS sampler system.
  1795. Further information is missing.
  1796. EXTENSION:GKH
  1797. SEE ALSO:EFE,INS
  1798. --------a-GRASPRT GL-G----------------------
  1799. The .GL animation files are graphic animations, some just .GIF files, others
  1800. mini-movies, used mostly for x-rated adult animations. The format of the files
  1801. is plain guesswork by me. The analyzed file did not include any animations but
  1802. only .GIF files and two text files which seemed to be the animation script.
  1803. There is no safe way of identifying a file as a GL animation, maybe except for
  1804. adding the subfile sizes and the header size and then check if this matches the
  1805. file size.
  1806. OFFSET              Count TYPE   Description
  1807. 0000h                   1 word   Length of header, excluding this word
  1808.                                  ="HLN"
  1809. 0002h                   ? rec    The directory entries for each file
  1810.                         1 dword  Offset of the stored file
  1811.                        12 char   DOS file name of the stored file
  1812. 0002h+                  1 dword  Length of the first stored file
  1813.  "HLN"
  1814.                         ? byte   The first file
  1815.                                  The other files follow in similar
  1816.                                  manner, length->file->length->file
  1817. EXTENSION:GL
  1818. OCCURENCES:PC
  1819. PROGRAMS:GRASPRT
  1820. --------?-GRIB------------------------------
  1821. The GRIB weather product information files just might be some satellite images
  1822. or something else. I have only seen this signature in a magic file and further
  1823. informations about the format is not known to me.
  1824. OFFSET              Count TYPE   Description
  1825. 0000h                   4 char   ID='GRIB'
  1826. EXTENSION:???
  1827. OCCURENCES:???
  1828. PROGRAMS:???
  1829. --------I-HSI1------------------------------
  1830. The HSI1 images are a JPEG derivative made by Handmade Software for their
  1831. Image Alchemy package.
  1832. OFFSET              Count TYPE   Description
  1833. 0000h                   4 char   ID='HSI1'
  1834. EXTENSION:JPG
  1835. OCCURENCES:PC,SUN
  1836. PROGRAMS:Image Alchemy
  1837. REFERENCE:
  1838. SEE ALSO:JPEG
  1839. VALIDATION:
  1840. --------A-HYP-------------------------------
  1841. The Hyper archiver is a very fast compression program by P. Sawatzki and K.P.
  1842. Nischke, which uses LZW compression techniques for compression. It is not very
  1843. widespread - in fact, I've yet to see a package distributed in this format.
  1844.  
  1845. OFFSET              Count TYPE   Description
  1846. 0000h                   1 byte   ID=1Ah
  1847. 0001h                   2 char   Compression method
  1848.                                  "HP" - compressed
  1849.                                  "ST" - stored
  1850. 0003h                   1 byte   Version file was compressed by in BCD
  1851. 0004h                   1 dword  Compressed file size
  1852. 0008h                   1 dword  Original file size
  1853. 000Ch                   1 dword  MS-DOS date and time of file (see table 0009)
  1854. 0010h                   1 dword  CRC-32 of file
  1855. 0014h                   1 byte   MS-DOS file attribute
  1856. 0015h                   1 byte   Length of filename
  1857.                                  ="LEN"
  1858. 0016h               "LEN" char   Filename
  1859.  
  1860. EXTENSION:HYP
  1861. OCCURENCES:PC
  1862. PROGRAMS:HYPER.EXE
  1863. --------f-IFF-M-----------------------------
  1864. The IFF format is comparable to the RIFF file format, but it
  1865. uses Motorola byte ordering. After the FORM header, the different
  1866. records follow. Each record has a header ID of 4 bytes and then following
  1867. the size of the data (in Motorola byte ordering). Each IFF record starts on
  1868. an even byte boundary, that means if the record length is odd, you will have
  1869. to skip one more byte to get the next record.
  1870. OFFSET              Count TYPE   Description
  1871. 0000h                   4 char   ID='FORM'
  1872. 0004h                   1 dword  Size of the whole IFF block
  1873. 0008h                   4 char   Type of the IFF file
  1874.  
  1875. Each IFF record has the following format :
  1876. OFFSET              Count TYPE   Description
  1877. 0000h                   4 char   ID
  1878. 0004h                   1 dword  Blocksize
  1879. 0008h                   ? byte   Block data, depends on block type.
  1880.  
  1881. OCCURENCES:Amiga,PC
  1882. SEE ALSO:8SVX,LBM,RIFF
  1883. --------S-INS-------------------------------
  1884. The INS files are instrument files for the Ensoniq sampler system.
  1885. Further information wanted.
  1886. EXTENSION:INS
  1887. SEE ALSO:EFE,GKH
  1888. --------I-JPEG-G----------------------------
  1889. The JPEG image standard is a standard for lossy (but efficient) image
  1890. compression made by the ???? Group. The endianness of the JPEG files is unknown
  1891. to me, there seem to exist both types of JPEG files.
  1892. OFFSET              Count TYPE   Description
  1893. 0000h                   1 dword  ID=FFD9FFE0h
  1894.                                  ID=FFD8FFE0h
  1895.                                  Big endian JPEG file (Intel)
  1896.                                  ID=E0FFD8FFh
  1897.                                  Little endian JPEG file (Motorola)
  1898. EXTENSION:JPG
  1899. OCCURENCES:PC,Amiga,SUN
  1900. PROGRAMS:
  1901. REFERENCE:
  1902. SEE ALSO:HSI1
  1903. VALIDATION:
  1904. --------I-LBM-M-----------------------------
  1905. The LBM/ILBM format is used by Deluxe Paint to store bitmap images. It
  1906. uses the IFF file format and Motorola byte order.
  1907. FORMblock [BMHD]
  1908. This block contains the information about the image.
  1909. OFFSET              Count TYPE   Description
  1910. 0000h                   1 word   The image width (x-axis)
  1911. 0002h                   1 word   The image height (y-axis)
  1912. 0004h                   1 dword  reserved
  1913. 0008h                   1 byte   Bits per pixel
  1914. 0009h                   1 byte   ??reserved??
  1915. FORMblock [BODY]
  1916. This block contains the (compressed) image data... ****
  1917. FORMblock [CRGN]
  1918. This block contains palette information for a range of palette entries.
  1919. OFFSET              Count TYPE   Description
  1920. FORMblock [TINY]
  1921. This block contains a small image used for previewing.
  1922. OFFSET              Count TYPE   Description
  1923. EXTENSION:IFF,LBM
  1924. OCCURENCES:AMIGA,PC
  1925. PROGRAMS:Deluxe Paint
  1926. REFERENCE:???
  1927. SEE ALSO:IFF
  1928. --------A-LBR-------------------------------
  1929. The LBR files consist of a direcotry and one or more "members". The directory
  1930. contains from 4 to 256 entries and each entry describes one member.
  1931. The first directory entry describes the directory itself. All space allocations
  1932. are in terms of sectors, where a sector is 128 bytes long. Four directory
  1933. entries fit in one sector thus the number of directory entries is always evenly
  1934. divisible by 4. Different types of LBR files exist, all versions are discussed
  1935. here, the directory entry looks like this :
  1936.  
  1937. OFFSET              Count TYPE   Description
  1938. 0000h                   1 byte   File status :
  1939.                                   0 - active
  1940.                                 254 - deleted
  1941.                                 255 - free
  1942. 0001h                  11 char   File name in FCB format (8/3, blank padded),
  1943.                                  directory name is blanks for old LU,
  1944.                                  ID='********DIR'
  1945.                                  for LUPC
  1946. 000Ch                   1 word   Offset to file data in sectors
  1947. 000Eh                   1 word   Length of stored data in sectors
  1948.  
  1949. For the LUPC program, the remaining 16 bytes are used like this :
  1950. OFFSET              Count TYPE   Description
  1951. 0000h                   8 char   ASCII date of creation (MM/DD/YY)
  1952. 0008h                   8 char   ASCII time of creation (HH:MM:SS)
  1953.  
  1954. For the LU86 program, the remaining 16 bytes are used like this :
  1955. OFFSET              Count TYPE   Description
  1956. 0000h                   1 word   CRC-16 or 0
  1957. 0002h                   1 word   Creation date in CP/M format
  1958. 0004h                   1 word   Creation time in DOS format
  1959. 0006h                   1 word   Date of last modification, CP/M format
  1960. 0008h                   1 word   Time of last modification, DOS format
  1961. 000Ah                   1 byte   Number of bytes in last sector
  1962. 000Bh                   5 byte   reserved (0)
  1963.  
  1964. EXTENSION:LBR
  1965. OCCURENCES:PC,CP/M
  1966. PROGRAMS:LU.COM, LUU.COM, LU86.COM
  1967. SEE ALSO:
  1968. --------A-LZH-------------------------------
  1969. The LHArc/LHA archiver is a multi platform archiver made by Haruyasu Yoshizaki,
  1970. which has a relatively good compression. It uses more or less the same
  1971. technology like the ZIP programs by Phil Katz. There was a hack named "ICE",
  1972. which had only the graphic characters displayed on decompression changed.
  1973.  
  1974. OFFSET              Count TYPE   Description
  1975. 0000h                   1 byte   Size of archived file header
  1976. 0001h                   1 byte   Checksum of remaining bytes
  1977. 0002h                   3 char   ID='-lh'
  1978.                                  ID='-lz'
  1979. 0005h                   1 char   Compression methods used (see table 0005)
  1980. 0006h                   1 char   ID='-'
  1981. 0007h                   1 dword  Compressed size
  1982. 000Bh                   1 dword  Uncompressed size
  1983. 000Fh                   1 dword  Original file date/time (see table 0009)
  1984. 0013h                   1 word   File attribute
  1985. 0015h                   1 byte   Filename / path length in bytes
  1986.                                  ="LEN"
  1987. 0016h               "LEN" char   Filename / path
  1988. 0018h                   1 word   CRC-16 of original file
  1989. +"LEN"
  1990.  
  1991. (Table 0005)
  1992. LHArc compression types
  1993.   "0" - No compression
  1994.   "1" - LZW, 4K buffer, Huffman for upper 6 bits of position
  1995.   "2" - unknown
  1996.   "3" - unknown
  1997.   "4" - LZW, Arithmetic Encoding
  1998.   "5" - LZW, Arithmetic Encoding
  1999.   "s" - LHa 2.x archive?
  2000.   "\" - LHa 2.x archive?
  2001.   "d" - LHa 2.x archive?
  2002.  
  2003. EXTENSION:LZH,ICE
  2004. OCCURENCES:PC
  2005. PROGRAMS:LHArc.EXE, LHA.EXE
  2006. --------M-MIDI-M----------------------------
  2007. The MIDI file format is used to store MIDI song data on disk. The discussed
  2008. version of the MIDI file spec is the approved MIDI Manufacturers' Associations
  2009. format version 0.06 of (3/88). The contact address is listed in the adresses
  2010. file. Version 1.0 is technically identical but the description has been
  2011. rewritten. The description was made by Dave Oppenheim, most of the text was
  2012. taken right out of his document.
  2013.   
  2014. MIDI files contain one or more MIDI streams, with time information for
  2015. each event.  Song, sequence, and track structures, tempo and time signature
  2016. information, are all supported.  Track names and other descriptive information
  2017. may be stored with the MIDI data.  This format supports multiple tracks and
  2018. multiple sequences so that if the user of a program which supports multiple
  2019. tracks intends to move a file to another one, this format can allow that to
  2020. happen.
  2021.  
  2022. The MIDI files are block oriented files, currently only 2 block types are
  2023. defined, header and track data. Opposed to the IFF and RIFF formats, no
  2024. global header is given, so that the validation must be done by adding the
  2025. different block sizes.
  2026.  
  2027. A MIDI file always starts with a header block, and is followed by one or
  2028. more track block.
  2029.  
  2030. The format of the header block :
  2031. OFFSET              Count TYPE   Description
  2032. 0000h                   4 char   ID='MThd'
  2033. 0004h                   1 dword  Length of header data (=6)
  2034. 0008h                   1 word   Format specification
  2035.                                    0 - one, single multi-channel track
  2036.                                    1 - one or more simultaneous tracks
  2037.                                    2 - one or more sequentially independent
  2038.                                        single-track patterns
  2039. 000Ah                   1 word   Number of track blocks in the file
  2040. 000Ch                   1 int    Unit of delta-time values.
  2041.                                  If negative :
  2042.                                    Absolute of high byte :
  2043.                                      Number of frames per second.
  2044.                                    Low byte :
  2045.                                      Resolution within one frame
  2046.                                  If positive, division of a quarter-note.
  2047.  
  2048. The track data format :
  2049. The MTrk block type is where actual song data is stored.  It is simply a
  2050. stream of MIDI events (and non-MIDI events), preceded by delta-time 
  2051. values.
  2052.  
  2053. Some numbers in MTrk blocks are represented in a form called a variable-
  2054. length quantity. These numbers are represented 7 bits per byte, most 
  2055. significant bits first.  All bytes except the last have bit 7 set, and 
  2056. the last byte has bit 7 clear.  If the number is between 0 and 127,  it 
  2057. is thus represented exactly as one byte. Since this explanation might not be
  2058. too clear, some exapmles :
  2059.  
  2060.         Number (hex)    Representation (hex)
  2061.         00000000        00
  2062.         00000040        40
  2063.         0000007F        7F
  2064.         00000080        81 00
  2065.         00002000        C0 00
  2066.         00003FFF        FF 7F
  2067.         001FFFFF        FF FF 7F
  2068.         08000000        C0 80 80 00
  2069.         0FFFFFFF        FF FF FF 7F
  2070.  
  2071. The largest number which is allowed is 0FFFFFFF so that the variable-
  2072. length representation must fit in 32 bits in a routine to write 
  2073. variable-length numbers.
  2074.  
  2075. Each track block contains one or more MIDI events, each event consists of
  2076. a delta-time and the number of the event. The delta-time is stored as a
  2077. variable-length quantity and represents the time to delay before the following
  2078. event. A delta-time of 0 means, that the event occurs simultaneous with the
  2079. previous event or occurs right at the start of a track. The delta-time unit is
  2080. specified in the header block.
  2081.  
  2082. Format of track information block :
  2083. OFFSET              Count TYPE   Description
  2084. 0000h                   4 char   ID='MTrk'
  2085. 0004h                   1 dword  Length of header data
  2086. 0008h                   ? rec    <delta-time>, <event>
  2087.  
  2088. Three types of events are defined, MIDI event, system exclusive event and
  2089. meta event. The first event in a file must specify status; delta-time itself
  2090. is not an event. Meta events are non-MIDI informations.
  2091.  
  2092. The format of the meta event :
  2093. OFFSET              Count TYPE   Description
  2094. 0000h                   1 byte   ID=FFh
  2095. 0001h                   1 byte   Type (<=128)
  2096. 0002h                   ? ?      Length of the data, 0 if no data
  2097.                                  stored as variable length quantity
  2098.                         ? byte   Data
  2099.  
  2100. A few meta-events are defined. It is not required for every program to support
  2101. every meta-event. Meta-events initially defined include:
  2102.  
  2103. FF 00 02 ssss   Sequence Number
  2104. This optional event, which must occur at the beginning of a track, 
  2105. before any nonzero delta-times, and before any transmittable MIDI 
  2106. events, specifies the number of a sequence.
  2107.   
  2108. FF 01 len text  Text Event
  2109. Any amount of text describing anything.  It is a good idea to put a text 
  2110. event right at the beginning of a track, with the name of the track, a 
  2111. description of its intended orchestration, and any other information 
  2112. which the user wants to put there. Programs on a computer which does not
  2113. support non-ASCII characters should ignore those characters with the hi-bit
  2114. set. Meta event types 01 through 0F are reserved for various types of text
  2115. events, each of which meets the specification of text events(above) but is
  2116. used for a different purpose:
  2117.  
  2118. FF 02 len text  Copyright Notice
  2119. Contains a copyright notice as printable ASCII text.  The notice should 
  2120. contain the characters (C), the year of the copyright, and the owner of 
  2121. the copyright.  If several pieces of music are in the same MIDI file, 
  2122. all of the copyright notices should be placed together in this event so 
  2123. that it will be at the beginning of the file.  This event should be the 
  2124. first event in the first track block, at time 0.
  2125.   
  2126. FF 03 len text  Sequence/Track Name
  2127. If in a format 0 track, or the first track in a format 1 file, the name 
  2128. of the sequence.  Otherwise, the name of the track.
  2129.  
  2130. FF 04 len text  Instrument Name
  2131. A description of the type of instrumentation to be used in that track.  
  2132.  
  2133. FF 05 len text  Lyric
  2134. A lyric to be sung.  Generally, each syllable will be a separate lyric 
  2135. event which begins at the event's time.
  2136.  
  2137. FF 06 len text  Marker
  2138. Normally in a format 0 track, or the first track in a format 1 file.  
  2139. The name of that point in the sequence, such as a rehearsal letter or 
  2140. section name ("First Verse", etc.). 
  2141.  
  2142. FF 07 len text  Cue Point
  2143. A description of something happening on a film or video screen or stage 
  2144. at that point in the musical score ("Car crashes into house", "curtain 
  2145. opens", "she slaps his face", etc.)
  2146.  
  2147. FF 2F 00 End of Track
  2148. This event is not optional.  It is included so that an exact ending 
  2149. point may be specified for the track, so that it has an exact length, 
  2150. which is necessary for tracks which are looped or concatenated.  
  2151.  
  2152. FF 51 03 tttttt Set Tempo, in microseconds per MIDI quarter-note
  2153. This event indicates a tempo change.  Another way of putting 
  2154. "microseconds per quarter-note" is "24ths of a microsecond per MIDI 
  2155. clock".  Representing tempos as time per beat instead of beat per time 
  2156. allows absolutely exact dword-term synchronization with a time-based sync
  2157. protocol such as SMPTE time code or MIDI time code.  This amount of 
  2158. accuracy provided by this tempo resolution allows a four-minute piece at 
  2159. 120 beats per minute to be accurate within 500 usec at the end of the 
  2160. piece.  Ideally, these events should only occur where MIDI clocks would 
  2161. be located Q this convention is intended to guarantee, or at least 
  2162. increase the likelihood, of compatibility with other synchronization 
  2163. devices so that a time signature/tempo map stored in this format may 
  2164. easily be transferred to another device. 
  2165.  
  2166. FF 54 05 hr mn se fr ff SMPTE Offset
  2167. This event, if present, designates the SMPTE time at which the track 
  2168. block is supposed to start.  It should be present at the beginning of
  2169. the track, that is, before any nonzero delta-times, and before any 
  2170. transmittable MIDI events.  The hour must be encoded with the SMPTE 
  2171. format, just as it is in MIDI Time Code.  In a format 1 file, the SMPTE 
  2172. Offset must be stored with the tempo map, and has no meaning in any of 
  2173. the other tracks.  The ff field contains fractional frames, in 100ths of 
  2174. a frame, even in SMPTE-based tracks which specify a different frame 
  2175. subdivision for delta-times.
  2176.  
  2177. FF 58 04 nn dd cc bb    Time Signature 
  2178. The time signature is expressed as four numbers.  nn and dd represent 
  2179. the numerator and denominator of the time signature as it would be 
  2180. notated.  The denominator is a negative power of two:  2 represents a 
  2181. quarter-note, 3 represents an eighth-note, etc.  The cc parameter 
  2182. expresses the number of MIDI clocks in a metronome click.  The bb 
  2183. parameter expresses the number of notated 32nd-notes in a MIDI quarter-
  2184. note (24 MIDI Clocks).
  2185.  
  2186. FF 59 02 sf mi  Key Signature
  2187.         sf = -7:  7 flats
  2188.         sf = -1:  1 flat
  2189.         sf = 0:  key of C
  2190.         sf = 1:  1 sharp
  2191.         sf = 7: 7 sharps
  2192.         
  2193.         mi = 0:  major key
  2194.         mi = 1:  minor key
  2195.         
  2196. FF 7F len data  Sequencer-Specific Meta-Event
  2197.         Special requirements for particular sequencers may use this
  2198. event type:  the first byte or bytes of data is a manufacturer ID.  
  2199. However, as this is an interchange format, growth of the spec proper is 
  2200. preferred to use of this event type.  This type of event may be used by
  2201. a sequencer which elects to use this as its only file format;
  2202. sequencers with their established feature-specific formats should 
  2203. probably stick to the standard features when using this format.
  2204.  
  2205. The system exclusive event is used as an escape to specify arbitrary bytes
  2206. to be transmitted. The system exclusive event has two forms, to compensate
  2207. for some manufacturer-specific modes, the F7h event is used if a F0h is to
  2208. be transmitted. Each system exclusive event must end with an F7h event.
  2209. The format of a system exclusive event :
  2210. OFFSET              Count TYPE   Description
  2211. 0000h                   1 byte   ID=F0h,ID=F7h
  2212. 0001h                   ? ?      Length as variable length qty.
  2213.                         ? byte   bytes to be transmitted
  2214.  
  2215. EXTENSION:MID,MIDI
  2216. OCCURENCES:PC,MAC
  2217. PROGRAMS:Cubase
  2218. VALIDATION:
  2219. --------M-MOD-M-----------------------------
  2220. The Protracker composer is a composer for digital music. The MOD files are a
  2221. quasi standard for digital music, all words are in Motorola byte order. The
  2222. original MOD format allowed only 4 digital channels and 15 instruments, the
  2223. specification became enlarged (maybe by Mahoney and Kaktus??) to 4 channels and
  2224. 31 instruments. Check the file at offset 1080d for the signatures 'M.K', '4CHN',
  2225. '6CHN','8CHN','FLT4','FLT8. If you find any of them, the module uses 31
  2226. instruments. With rising sound quality on the PC and other platforms, the old
  2227. MODule format has been replaced by numerous other formats. The 4/15 format has
  2228. almost become extinct. Below, only the 4/31 format is descripted.
  2229.  
  2230. The digital sample data is signed (two's complement) as necessary for the Amiga,
  2231. the sample data immediately follows the pattern data.
  2232. Maybe this is not valid for some 8CHN files; One of the two I have, uses Intel
  2233. byte ordering and unsigned samples.
  2234.  
  2235. OFFSET              Count TYPE   Description
  2236. 0000h                  20 char   Song title, padded with spaces
  2237. 0014h                  31 rec    Sample description record
  2238.                                  For original MOD files, the number of
  2239.                                  instruments would be 15.
  2240.                        22 char   Sample name, padded with zeroes to
  2241.                                  full length.
  2242.                         2 word   Sample length / 2. Needs to be multiplied
  2243.                                  by 2 to get the actual length. If the sample
  2244.                                  length is greater than 8000h, the sample
  2245.                                  is bigger than 64k.
  2246.                         1 byte   Sample finetune. Only the lower nibble is
  2247.                                  valid. Fine tune table :
  2248.                                   0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
  2249.                                   0 +1 +2 +3 +4 +5 +6 +7 -8 -7 -6 -5 -4 -3 -2 -1
  2250.                         1 byte   Sample volume (0-40h)
  2251.                         1 word   Sample loop start / 2
  2252.                         1 word   Sample loop length / 2
  2253.  
  2254. 950d                    1 byte   Song length in patterns (0-80h)
  2255. 951d                    1 byte   Restart byte for song looping (Noisetracker?)
  2256. 952d                  128 byte   Pattern play sequences
  2257. 1080d                   4 char   ID='M.K.', ID='4CHN',ID='6CHN',ID='8CHN'
  2258.                                  ID='4FLT',ID='8FLT'
  2259.                                  If this position contains 'M.K.','8CHN',
  2260.                                  '4CHN','6CHN','FLT4' or 'FLT8' the module
  2261.                                  has 31 instruments.
  2262. 1084d                   ? rec    Patterns
  2263.                                  Each pattern has 64 rows.
  2264.                                  Depending on the number of channels, each row
  2265.                                  has from 4 to 8 notes. The channel count is
  2266.                                  determined by the ID. (see table 0005)
  2267.                                  The number of patterns is the highest pattern
  2268.                                  number stored in the pattern list.
  2269.  
  2270.                                  Each note has four bytes. Four notes make
  2271.                                  up a track in a four channel MOD file. Each
  2272.                                  track is saved sequentially :
  2273.                                    byte  0-3     4-7    8-11    12-15
  2274.                                        Chn #1  Chn #2  Chn #3  Chn #4
  2275.                                    byte 16-19   20-23  24-27    28-31
  2276.                                        Chn #1  Chn #2  Chn #3  Chn #4
  2277.                         1 word   Instrument / period
  2278.                                  The instrument number is in bits 12-15, the
  2279.                                  12-bit period in bits 0-11.
  2280.                         1 byte   Upper nibble : Lower 4 bits of the instrument,
  2281.                                  Lower nibble : Special effect command.
  2282.                         1 byte   Special effects data
  2283. (Table 0005)
  2284. Protracker 16 note conversion table / MOD Period table
  2285.        +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
  2286. PT16 : I    1I    2I    3I    4I    5I    6I    7I    8I    9I   10I   11I   12I
  2287. MOD  : I 1712I 1616I 1524I 1440I 1356I 1280I 1208I 1140I 1076I 1016I  960I  906I
  2288. 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
  2289.        +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
  2290.        I   13I   14I   15I   16I   17I   18I   19I   20I   21I   22I   23I   24I
  2291.        I  856I  808I  762I  720I  678I  640I  604I  570I  538I  508I  480I  453I
  2292.        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
  2293.        +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
  2294.        I   25I   26I   27I   28I   29I   30I   31I   32I   33I   34I   35I   36I
  2295.        I  428I  404I  381I  360I  339I  320I  302I  285I  269I  254I  240I  226I
  2296.        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
  2297.        +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
  2298.        I   37I   38I   39I   40I   41I   42I   43I   44I   45I   46I   47I   48I
  2299.        I  214I  202I  190I  180I  170I  160I  151I  143I  135I  127I  120I  113I
  2300.        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
  2301.        +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
  2302.        I   49I   50I   51I   52I   53I   54I   55I   56I   57I   58I   59I   60I
  2303.        I  107I  101I   95I   90I   85I   80I   75I   71I   67I   63I   60I   56I
  2304.        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
  2305.        +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
  2306.  
  2307. EXTENSION:MOD,module
  2308. OCCURENCES:AMIGA,PC
  2309. PROGRAMS:DMP,ModEdit
  2310. VALIDATION:NONE
  2311. --------I-MSK-------------------------------
  2312. The MSK files are mask files used by the Autodesk Animator and Animator Pro
  2313. packages. Two types of MSK files exist. The Animator Pro version is simply a PIC
  2314. file with the depth 1; A MSK file created by the original Animator is exactly
  2315. 8000 bytes long. There is no file header or other control information in the
  2316. file. It contains the image bit map, 1 bit per pixel, with the leftmost pixels
  2317. packed into the high order bits of each byte. The size of the image is fixed at
  2318. 320x200. The image is stored left-to-right, top-to-bottom.
  2319.  
  2320. EXTENSION:MSK
  2321. OCCURENCES:PC
  2322. PROGRAMS:Autodesk Animator
  2323. SEE ALSO:PIC,FLIc
  2324. --------M-MTM-------------------------------
  2325. The MTM format is generated by the Multi Track Module tracker by the demo group
  2326. Renaissance. The tracker features up to 32 channel digital music. Instead of
  2327. saving whole patterns, the tracker only saves the different tracks and the data
  2328. which tracks should be played together at which time, thus saving some pattern
  2329. space.
  2330.  
  2331. OFFSET              Count TYPE   Description
  2332. 0000h                   3 char   ID='MTM'
  2333. 0003h                   1 byte   Version data
  2334.                                    upper nibble is major version number
  2335.                                    lower nibble is minor version number
  2336. 0004h                  20 char   ASCIIZ song name
  2337. 0018h                   1 word   Number of saved tracks.
  2338.                                  ="NOT"
  2339. 001Ah                   1 byte   Highest pattern number saved
  2340.                                  ="NOP"
  2341. 001Bh                   1 byte   Last order number to play(=Songlength-1)
  2342. 001Ch                   1 word   Length of extra comment field in bytes
  2343.                                  ="XSZ"
  2344. 001Eh                   1 byte   Number of samples
  2345.                                  ="NOS"
  2346. 001Fh                   1 byte   Attribute byte (currently defined as 0)
  2347. 0020h                   1 byte   Beats per track
  2348. 0021h                   1 byte   Number of tracks
  2349. 0022h                  32 byte   Pan positions of the voices
  2350.                                  (0=left, 15=right??)
  2351. 0042h               "NOS" rec    Instrument data
  2352.                        22 char   Sample name
  2353.                         1 dword  Sample length in bytes
  2354.                         1 dword  Start of sample loop in bytes
  2355.                         1 dword  End of sample loop in bytes
  2356.                         1 byte   Fine tune value for sample
  2357.                         1 byte   Default volume for sample
  2358.                         1 byte   Attribute byte, bit mapped
  2359.                                    0 0=8 bit sample,1=16 bit sample
  2360.                                  1-7 undefined (set to zero)
  2361. 0042h+                128 byte   Pattern order data
  2362.  "NOS"*37             
  2363. 01C2h+
  2364.  "NOS"*37           "NOT" rec    Track data
  2365.                                  Each track is saved independently and has
  2366.                                  the size of exactly 192 bytes. Each track
  2367.                                  is arranged as 64 3-byte notes with the
  2368.                                  following format :
  2369.                      64*3 byte            BYTE 0   BYTE 1   BYTE 2
  2370.                                          ppppppii iiiieeee aaaaaaaa
  2371.                                  p = pitch value (0=no pitch stated)
  2372.                                  i = instrument number (0=no instrument number)
  2373.                                  e = effect number
  2374.                                  a = effect argument
  2375.                                  The effects are the standard Protracker
  2376.                                  effects.
  2377. 01C2h+       ("NOP"+1)*32 word   Track sequencing data
  2378.  "NOS"*37+                       This is the list of which track is used
  2379.  "NOT"*192                       as which voice in each pattern. One track
  2380.                                  can be part of many patterns, the drums
  2381.                                  for example.
  2382.                                  Track 0 is never saved but is always
  2383.                                  considered as an empty track. That means
  2384.                                  that counting really starts at one.
  2385.                                  The data is organized in sets of 32 voices.
  2386.                                  The first word contains the information which
  2387.                                  track is used in pattern 0, voice 0. The next
  2388.                                  word is for pattern 0, voice 1, etc., this
  2389.                                  is repeated for each pattern, 32 words for each
  2390.                                  saved pattern.
  2391. 01C2h+              "XSZ" char   Extra comment field. This contains some
  2392.  "NOS"*37+                       message or something.
  2393.  "NOT"*192+
  2394.  ("NOP"+1)*32*2
  2395. 01C2h+                  ? byte   Raw sample data(unsigned).
  2396.  "NOS"*37+
  2397.  "NOT"*192+
  2398.  ("NOP"+1)*32*2+
  2399.  "XSZ"
  2400. EXTENSION:MTM
  2401. SEE ALSO:MOD
  2402. OCCURENCES:PC
  2403. PROGRAMS:MMEDIT,DMP
  2404. VALIDATION:
  2405. --------M-MTS-------------------------------
  2406. The Master Tracker program by the french demo group Arkham is a tracker
  2407. for AdLib, SB and speaker - the further limits of this tracker are unknowm
  2408. to me.
  2409. OFFSET              Count TYPE   Description
  2410. 0000h                   6 char   ID="MTRAC "
  2411. 0006h                  20 char   Song name, zero padded
  2412. EXTENSION:MST
  2413. OCCURENCES:PC
  2414. PROGRAMS:Master Tracler v1.0
  2415. SEE ALSO:MOD
  2416. --------E-MZ EXE----------------------------
  2417. The old EXE files are the EXE files executed directly by MS-DOS. They were a
  2418. major improvement over the old 64K COM files, since EXE files can span multiple
  2419. segments. An EXE file consists of three different parts, the header, the
  2420. relocation table and the binary code.
  2421. The header is expanded by a lot of programs to store their copyright information
  2422. in the executable, some extensions are documented below.
  2423. The format of the header is as follows :
  2424. OFFSET              Count TYPE   Description
  2425. 0000h                   2 char   ID='MZ'
  2426.                                  ID='ZM'
  2427. 0002h                   1 word   Number of bytes in last 512-byte page
  2428.                                  of executable
  2429. 0004h                   1 word   Total number of 512-byte pages in executable
  2430.                                  (including the last page)
  2431. 0006h                   1 word   Number of relocation entries
  2432. 0008h                   1 word   Header size in paragraphs
  2433. 000Ah                   1 word   Minimum paragraphs of memory allocated in
  2434.                                  addition to the code size
  2435. 000Ch                   1 word   Maximum number of paragraphs allocated in
  2436.                                  addition to the code size
  2437. 000Eh                   1 word   Initial SS relative to start of executable
  2438. 0010h                   1 word   Initial SP
  2439. 0012h                   1 word   Checksum (or 0) of executable
  2440. 0014h                   1 dword  CS:IP relative to start of executable
  2441.                                  (entry point)
  2442. 0018h                   1 word   Offset of relocation table;
  2443.                                  40h for new-(NE,LE,LX,W3,PE etc.) executable
  2444. 001Ah                   1 word   Overlay number (0h = main program)
  2445.  
  2446. Following are the header expansions by some other prorams like TLink, LZExe and
  2447. other linkers, encryptors and compressors; all offsets are relative to the start
  2448. of the whole header :
  2449.  
  2450. ---new executable
  2451. OFFSET              Count TYPE   Description
  2452. 001Ch                   4 byte   ????
  2453. 0020h                   1 word   Behaviour bits ??
  2454. 0022h                  26 byte   reserved (0)
  2455. 003Ch                   1 dword  Offset of new executable header from start of
  2456.                                  file (or 0 if plain MZ executable)
  2457.  
  2458. ---Borland TLINK
  2459. OFFSET              Count TYPE   Description
  2460. 001Ch                   2 byte   ?? (apparently always 01h 00h)
  2461. 001Eh                   1 byte   ID=0FBh
  2462. 001Fh                   1 byte   TLink version, major in high nybble
  2463. 0020h                   2 byte   ??
  2464.  
  2465. ---old ARJ self-extracting archive
  2466. OFFSET              Count TYPE   Description
  2467. 001Ch                   4 char   ID='RJSX' (older versions)
  2468.                                  new signature is 'aRJsf'" in the first 1000
  2469.                                  bytes of the file)
  2470. ---LZEXE compressed executable
  2471. OFFSET              Count TYPE   Description
  2472. 001Ch                   2 char   ID='LZ'
  2473. 001Eh                   2 char   Version number :
  2474.                                   '09' - LZExe 0.90
  2475.                                   '91' - LZExe 0.91
  2476. ---PKLITE compressed executable
  2477. OFFSET              Count TYPE   Description
  2478. 001Ch                   1 byte   Minor version number
  2479. 001Dh                   1 byte   Bit mapped :
  2480.                                  0-3 - major version
  2481.                                    4 - Extra compression
  2482.                                    5 - Multi-segment file
  2483. 001Eh                   6 char   ID='PKLITE'
  2484. ---LHarc 1.x self-extracting archive
  2485. OFFSET              Count TYPE   Description
  2486. 001Ch                   4 byte   unused???
  2487. 0020h                   3 byte   Jump to start of extraction code
  2488. 0023h                   2 byte   ???
  2489. 0025h                  12 char   ID='LHarc's SFX '
  2490. --LHA 2.x self-extracting archive
  2491. OFFSET              Count TYPE   Description
  2492. 001Ch                   8 byte   ???
  2493. 0024h                  10 char   ID='LHa's SFX '
  2494.                                  For version 2.10
  2495.                                  ID='LHA's SFX ' (v2.13)
  2496.                                  For version 2.13
  2497. ---LH self-extracting archive
  2498. OFFSET              Count TYPE   Description
  2499. 001Ch                   8 byte   ???
  2500. 0024h                   8 byte   ID='LH's SFX '
  2501. ---TopSpeed C 3.0 CRUNCH compressed file
  2502. OFFSET              Count TYPE   Description
  2503. 001Ch                   1 dword  ID=018A0001h
  2504. 0020h                   1 word   ID=1565h
  2505. ---PKARC 3.5 self-extracting archive
  2506. OFFSET              Count TYPE   Description
  2507. 001Ch                   1 dword  ID=00020001h
  2508. 0020h                   1 word   ID=0700h
  2509. ---BSA (Soviet archiver) self-extracting archive
  2510. OFFSET              Count TYPE   Description
  2511. 001Ch                   1 word   ID=000Fh
  2512. 001Eh                   1 byte   ID=A7h
  2513. ---LARC self-extracting archive
  2514. OFFSET              Count TYPE   Description
  2515. 001Ch                   4 byte   ???
  2516. 0020h                  11 byte   ID='SFX by LARC '
  2517.  
  2518. After the header, there follow the relocation items, which are used to span
  2519. multpile segments. The relocation items have the following format :
  2520. OFFSET              Count TYPE   Description
  2521. 0000h                   1 word   Offset within segment
  2522. 0002h                   1 word   Segment of relocation
  2523. To get the position of the relocation within the file, you have to compute the
  2524. physical adress from the segment:offset pair, which is done by multiplying the
  2525. segment by 16 and adding the offset and then adding the offset of the binary
  2526. start. Note that the raw binary code starts on a paragraph boundary within the
  2527. executable file. All segments are relative to the start of the executable in
  2528. memory, and this value must be added to every segment if relocation is done
  2529. manually.
  2530.  
  2531. EXTENSION:EXE,OVR,OVL
  2532. OCCURENCES:PC
  2533. PROGRAMS:MS-DOS
  2534. REFERENCE:Ralf Brown's Interrupt List
  2535. SEE ALSO:COM,EXE,NE EXE
  2536. --------E-NE EXE----------------------------
  2537. The NE EXE files are the new exe files used by windows and OS/2 executables.
  2538. They contain a small MZ EXE which prints "This program requires Microsoft
  2539. Windows" or something similar but Some files contain both DOS and Windows
  2540. versions of the executable. The position of the new EXE header can be found
  2541. in the old exe header - see the MZ EXE topic for further information. All
  2542. offsets within this header are from the start of the header if not noted
  2543. otherwise.
  2544.  
  2545. OFFSET              Count TYPE   Description
  2546. 0000h                   2 char   ID='NE'
  2547. 0002h                   1 byte   Linker major version
  2548. 0003h                   1 byte   Linker minor version
  2549. 0004h                   1 word   Offset of entry table (see below)
  2550. 0006h                   1 word   Length of entry table in bytes
  2551. 0008h                   1 dword  File load CRC (0 in Borland's TPW)
  2552. 000Ch                   1 byte   Program flags, bitmapped :
  2553.                                  0-1 - DGroup type :
  2554.                                        0 - none
  2555.                                        1 - single shared
  2556.                                        2 - multiple
  2557.                                        3 - (null)
  2558.                                    2 - Global initialization
  2559.                                    3 - Protected mode only
  2560.                                    4 - 8086 instructions
  2561.                                    5 - 80286 instructions
  2562.                                    6 - 80386 instructions
  2563.                                    7 - 80x87 instructions
  2564. 000Dh                   1 byte   Application flags, bitmapped
  2565.                                  0-2 - Application type
  2566.                                        1 - Full screen (not aware of
  2567.                                            Windows/P.M. API)
  2568.                                        2 - Compatible with Windows/P.M. API
  2569.                                        3 - Uses Windows/P.M. API
  2570.                                    3 - OS/2 family application
  2571.                                    4 - reserved?
  2572.                                    5 - Errors in image/executable
  2573.                                    6 - "non-conforming program" whatever
  2574.                                    7 - DLL or driver (SS:SP info invalid, CS:IP
  2575.                                        points at FAR init routine called with
  2576.                                        AX=module handle which returns AX=0000h
  2577.                                        on failure, AX nonzero on successful
  2578.                                        initialization)
  2579. 000Eh                   1 byte   Auto data segment index
  2580. 0010h                   1 word   Initial local heap size
  2581. 0012h                   1 word   Initial stack size
  2582. 0014h                   1 dword  Entry point (CS:IP),
  2583.                                  CS is index into segment table
  2584. 0018h                   1 dword  Initial stack pointer (SS:SP)
  2585.                                  SS is index into segment table
  2586. 001Ch                   1 word   Segment count
  2587. 001Eh                   1 word   Module reference count
  2588. 0020h                   1 word   Size of nonresident names table in bytes
  2589. 0022h                   1 word   Offset of segment table (see below)
  2590. 0024h                   1 word   Offset of resource table
  2591. 0026h                   1 word   Offset of resident names table
  2592. 0028h                   1 word   Offset of module reference table
  2593. 002Ah                   1 word   Offset of imported names table
  2594.                                  (array of counted strings, terminated with a
  2595.                                   string of length 00h)
  2596. 002Ch                   1 dword  Offset from start of file to nonresident
  2597.                                  names table
  2598. 0030h                   1 word   Count of moveable entry point listed in
  2599.                                  entry table
  2600. 0032h                   1 word   File alignment size shift count
  2601.                                   0 is equivalent to 9 (default 512-byte pages)
  2602. 0034h                   1 word   Number of resource table entries
  2603. 0036h                   1 byte   Target operating system
  2604.                                   0 - unknown
  2605.                                   1 - OS/2
  2606.                                   2 - Windows
  2607.                                   3 - European MS-DOS 4.x
  2608.                                   4 - Windows 386
  2609.                                   5 - BOSS (Borland Operating System Services)
  2610. 0037h                   1 byte   Other OS/2 EXE flags, bitmapped
  2611.                                  0 - Long filename support
  2612.                                  1 - 2.x protected mode
  2613.                                  2 - 2.x proportional fonts
  2614.                                  3 - Executable has gangload area
  2615. *****
  2616. 0038h    WORD    offset to return thunks or start of gangload area
  2617. 003Ah    WORD    offset to segment reference thunks or length of gangload area
  2618. 003Ch    WORD    minimum code swap area size
  2619. 003Eh  2 BYTEs   expected Windows version (minor version first)
  2620.  
  2621. EXTENSION:DLL,EXE,FOT
  2622. OCCURENCES:PC
  2623. PROGRAMS:
  2624. REFERENCE:Windows 3.1 SDK Programmer's Reference, Vol 4.
  2625. SEE ALSO:EXE,MZ EXE
  2626. --------D-NG-G------------------------------
  2627. Information about this format comes only from a magic file, thus is only good
  2628. for file identification. I did not test it, since I don't have any NG files.
  2629. The Norton Guides are a popup help program for the IBM PCs which provide instant
  2630. help anywhere...
  2631.  
  2632. OFFSET              Count TYPE   Description
  2633. 0000h                   2 char   ID='NG'
  2634. 0002h                   1 dword  ID=0
  2635. EXTENSION:NG
  2636. OCCURENCES:PC
  2637. PROGRAMS:NG.EXE
  2638. SEE ALSO:TPH,HLP
  2639. --------B-OBJ-------------------------------
  2640. Most of the description was taken from the Microsoft Product Support
  2641. Services Application Note SS0288. The .OBJ files are binary files used
  2642. by compilers to link in precompiled code. They contain symbol and relocation
  2643. information necessary to link the data and code contained in the files. The
  2644. .OBJ files have no common header which makes a validation or identification
  2645. guesswork at best. The .OBJ files consist of at least one record, each of the
  2646. following type :
  2647.  
  2648. OFFSET              Count TYPE   Description
  2649. 0000h                   1 byte   Record type (see below)
  2650. 0001h                   1 word   Record length
  2651.                                  ="LEN"
  2652. 0003h               "LEN" byte   Record data
  2653. 0003h                   1 byte   Checksum or 0
  2654.  +"LEN"                          (that much for validation)
  2655.  
  2656. The maximum size of the entire record (unless otherwise noted for specific
  2657. record types) is 1024 bytes.
  2658.  
  2659. For LINK386, the format is determined by the least-significant bit
  2660. of the Record Type field. An odd Record Type indicates that certain
  2661. numeric fields within the record contain 32-bit values; an even
  2662. Record Type indicates that those fields contain 16-bit values. The
  2663. affected fields are described with each record. Note that this
  2664. principle does not govern the Use32/Use16 segment attribute (which
  2665. is set in the ACBP byte of SEGDEF records); it simply specifies the
  2666. size of certain numeric fields within the record. It is possible to
  2667. use 16-bit OMF records to generate 32-bit segments, or vice versa.
  2668.  
  2669. LINK ignores the value of the checksum byte, but some other utilities may
  2670. not. Microsoft's Quick languages write a 0 byte instead of computing a checksum.
  2671.  
  2672. The contents of each record are determined by the record type, but
  2673. certain subfields appear frequently enough to be explained separately.
  2674. The format of such fields is below.
  2675.  
  2676. Names :
  2677.  
  2678. A name string is encoded as an 8-bit unsigned count followed by a
  2679. string of count characters. The character set is usually some ASCII
  2680. subset. A null name is specified by a single byte of 0 (indicating a
  2681. string of length 0).
  2682.  
  2683. Indexed References :
  2684.  
  2685. Certain items are ordered by occurrence and are referenced by index.
  2686. The first occurrence of the item has index number 1. Index fields may
  2687. contain 0 (indicating that they are not present) or values from 1
  2688. through 7FFF. The index number field in an object record can be either
  2689. 1 or 2 bytes long. If the number is in the range 0-7FH, the high-order
  2690. bit (bit 7) is 0 and the low-order bits contain the index number, so
  2691. the field is only 1 byte long. If the index number is in the range 80-
  2692. 7FFFH, the field is 2 bytes long. The
  2693.  
  2694. Type Indexes :
  2695.  
  2696. Type Index fields occupy 1 or 2 bytes and occur in PUBDEF, LPUBDEF,
  2697. COMDEF, LCOMDEF, EXTDEF, and LEXTDEF records. They are encoded as
  2698. described above for indexed references, but the interpretation of the
  2699. values stored is governed by whether the module has the "new" or "old"
  2700. object module format.
  2701.  
  2702. "Old" versions of the OMF (indicated by lack of a COMENT record with
  2703. comment class A1), have Type Index fields that contain indexes into
  2704. previously seen TYPDEF records. This format is no longer produced by
  2705. Microsoft products and is ignored by LINK if it is present. See the
  2706. section of this document on TYPDEF records for details on how this was
  2707. used.
  2708.  
  2709. "New" versions of the OMF (indicated by the presence of a COMENT
  2710. record with comment class A1), have Type Index fields that contain
  2711. proprietary CodeView information. For more information on CodeView,
  2712. see Appendix 1.
  2713.   
  2714. Ordered Collections :
  2715.  
  2716. Certain records and record groups are ordered so that the records may
  2717. be referred to with indexes (the format of indexes is described in the
  2718. "Indexed References" section of this document). The same format is
  2719. used whether an index refers to names, logical segments, or other
  2720. items.
  2721.  
  2722. The overall ordering is obtained from the order of the records within
  2723. the file together with the ordering of repeated fields within these
  2724. records. Such ordered collections are referenced by index, counting
  2725. from 1 (index 0 indicates unknown or not specified).
  2726.  
  2727. For example, there may be many LNAMES records within a module, and
  2728. each of those records may contain many names. The names are indexed
  2729. starting at 1 for the first name in the first LNAMES record
  2730. encountered while reading the file, 2 for the second name in the first
  2731. record, and so forth, with the highest index for the last name in the
  2732. last LNAMES record encountered.
  2733.  
  2734. The ordered collections are:
  2735.  
  2736.    Names       Ordered by occurrence of LNAMES records and
  2737.                names within each. Referenced as a name
  2738.                index.
  2739.                
  2740.    Logical     Ordered by occurrence of SEGDEF records in
  2741.    Segments    file. Referenced as a segment index.
  2742.                
  2743.    Groups      Ordered by occurrence of GRPDEF records in
  2744.                file. Referenced as a group index.
  2745.                
  2746.    External    Ordered by occurrence of EXTDEF, COMDEF,
  2747.    Symbols     LEXTDEF, and LCOMDEF records and symbols
  2748.                within each. Referenced as an external name
  2749.                index (in FIXUP subrecords).
  2750.                
  2751.  
  2752. Numeric 2- and 4-Byte Fields :
  2753.  
  2754. Certain records, notably SEGDEF, PUBDEF, LPUBDEF, LINNUM, LEDATA,
  2755. LIDATA, FIXUPP, and MODEND, contain size, offset, and displacement
  2756. values that may be 32-bit quantities for Use32 segments. The encoding
  2757. is as follows:
  2758.  
  2759.  - When the least-significant bit of the record type byte is set (that
  2760.    is, the record type is an odd number), the numeric fields are 4
  2761.    bytes.
  2762.  
  2763.  - When the least-significant bit of the record type byte is clear,
  2764.    the fields occupy 2 bytes. The values are zero-extended when
  2765.    applied to Use32 segments.
  2766.  
  2767.   NOTE: See the description of SEGDEF records in this document for an
  2768.   explanation of Use16/Use32 segments.
  2769.  
  2770.  
  2771. The general record ordering is not mandatory, but should be (for link speed)
  2772. like this :
  2773.  
  2774. THEADR or LHEADR record :
  2775.  
  2776.   Records Processed by LINK Pass 1 :
  2777.   All records may occur in any order but must stand before the link pass
  2778.   separator, if it is present.
  2779.    
  2780.    COMENT records identifying object format and extensions
  2781.    COMENT records other than Link Pass Separator comment
  2782.    LNAMES or LLNAMES records providing ordered name list
  2783.    SEGDEF records providing ordered list of program segments
  2784.    GRPDEF records providing ordered list of logical segments
  2785.    TYPDEF records (obsolete)
  2786.    ALIAS records
  2787.    PUBDEF records locating and naming public symbols
  2788.    LPUBDEF records locating and naming private symbols
  2789.    COMDEF, LCOMDEF, EXTDEF, LEXTDEF, and CEXTDEF records
  2790.     
  2791. Link Pass Separator (Optional) :
  2792.  
  2793. COMENT class A2 record indicating that Pass 1 of the linker is
  2794. complete. When this record is encountered, LINK stops reading the
  2795. object file in Pass 1; no records after this comment are read in Pass
  2796. 1. All the records listed above must come before this COMENT record.
  2797.  
  2798. For greater linking speed, all LIDATA, LEDATA, FIXUPP, BAKPAT, INCDEF,
  2799. and LINNUM records should come after the A2 COMENT record, but this is
  2800. not required. In LINK, Pass 2 begins again at the start of the object
  2801. module, so these records are processed in Pass 2 no matter where they
  2802. are placed in the object module.
  2803.  
  2804. Records Ignored by LINK Pass 1 and Processed by LINK Pass 2 :
  2805.    
  2806. The following records may come before or after the Link Pass
  2807. Separator:
  2808.    
  2809.    LIDATA, LEDATA, or COMDAT records followed by applicable FIXUPP
  2810.    records
  2811.    FIXUPP records containing only THREAD subrecords
  2812.    BAKPAT and NBKPAT FIXUPP records
  2813.    COMENT class A0, subrecord type 03 (INCDEF) records containing
  2814.    incremental compilation information for FIXUPP and LINNUM records
  2815.    LINNUM and LINSYM records providing line number and program code or
  2816.    data association
  2817.  
  2818. Terminator :
  2819.    
  2820.    MODEND record indicating end of module with optional start address
  2821.    
  2822. Details of each record (form and content) follow below.
  2823. Conflicts between various OMFs that overlap in their use of record
  2824. types or fields are marked.
  2825.  
  2826. Below is a combined list of record types defined by the Intel 8086 OMF
  2827. specification and record types added after that specification was
  2828. finished. Titles in square brackets ([]) indicate record types that
  2829. have been implemented and that are described in this document. Titles
  2830. not in square brackets indicate record types that have not been
  2831. implemented and are followed by a paragraph of description from the
  2832. Intel specification.
  2833.  
  2834. For unimplemented record types, a subtle distinction is made between
  2835. records that LINK ignores and those for which LINK generates an
  2836. "illegal object format" error condition.
  2837.  
  2838. Records Currently Defined
  2839.    
  2840.    6EH     RHEADR   R-Module Header Record
  2841.                     This record serves to identify a module that has
  2842.                     been processed (output) by LINK-86/LOCATE-86. It
  2843.                     also specifies the module attributes and gives
  2844.                     information on memory usage and need. This record
  2845.                     type is ignored by Microsoft LINK.
  2846.                     
  2847.    70H     REGINT   Register Initialization Record
  2848.                     This record provides information about the 8086
  2849.                     register/register-pairs: CS and IP, SS and SP, DS
  2850.                     and ES. The purpose of this information is for a
  2851.                     loader to set the necessary registers for
  2852.                     initiation of execution. This record type is
  2853.                     ignored by Microsoft LINK.
  2854.                     
  2855.    72H     REDATA   Relocatable Enumerated Data Record
  2856.                     This record provides contiguous data from which a
  2857.                     portion of an 8086 memory image may eventually be
  2858.                     constructed. The data may be loaded directly by
  2859.                     an 8086 loader, with perhaps some base fixups.
  2860.                     The record may also be called a Load-Time
  2861.                     Locatable (LTL) Enumerated Data Record. This
  2862.                     record type is ignored by Microsoft LINK.
  2863.                     
  2864.    74H     RIDATA   Relocatable Iterated Data Record
  2865.                     This record provides contiguous data from which a
  2866.                     portion of an 8086 memory image may eventually be
  2867.                     constructed. The data may be loaded directly by
  2868.                     an 8086 loader, but data bytes within the record
  2869.                     may require expansion. The record may also be
  2870.                     called a Load-Time Locatable (LTL) Iterated Data
  2871.                     Record. This record type is ignored by Microsoft
  2872.                     LINK.
  2873.                     
  2874.    76H     OVLDEF   Overlay Definition Record
  2875.                     This record provides the overlay's name, its
  2876.                     location in the object file, and its attributes.
  2877.                     A loader may use this record to locate the data
  2878.                     records of the overlay in the object file. This
  2879.                     record type is ignored by Microsoft LINK.
  2880.                     
  2881.    78H     ENDREC   End Record
  2882.                     This record is used to denote the end of a set of
  2883.                     records, such as a block or an overlay. This
  2884.                     record type is ignored by Microsoft LINK.
  2885.                     
  2886.    7AH     BLKDEF   Block Definition Record
  2887.                     This record provides information about blocks
  2888.                     that were defined in the source program input to
  2889.                     the translator that produced the module. A BLKDEF
  2890.                     record will be generated for every procedure and
  2891.                     for every block that contains variables. This
  2892.                     information is used to aid debugging programs.
  2893.                     This record type is ignored by Microsoft LINK.
  2894.  
  2895.    7CH     BLKEND   Block End Record
  2896.                     This record, together with the BLKDEF record,
  2897.                     provides information about the scope of variables
  2898.                     in the source program. Each BLKDEF record must be
  2899.                     followed by a BLKEND record. The order of the
  2900.                     BLKDEF, debug symbol records, and BLKEND records
  2901.                     should reflect the order of declaration in the
  2902.                     source module. This record type is ignored by
  2903.                     Microsoft LINK.
  2904.                   
  2905.    7EH     DEBSYM   Debug Symbols Record
  2906.                     This record provides information about all
  2907.                     local symbols, including stack and based symbols.
  2908.                     The purpose of this information is to aid debug-
  2909.                     ging programs. This record type is ignored by 
  2910.                     Microsoft LINK.
  2911.                           
  2912.    [80H]   [THEADR] [Translator Header Record]
  2913.                           
  2914.    [82H]   [LHEADR] [Library Module Header Record]
  2915.                           
  2916.    84H     PEDATA   Physical Enumerated Data Record
  2917.                     This record provides contiguous data,
  2918.                     from which a portion of an 8086 memory
  2919.                     image may be constructed. The data
  2920.                     belongs to the "unnamed absolute segment"
  2921.                     in that it has been assigned absolute
  2922.                     8086 memory addresses and has been
  2923.                     divorced from all logical segment
  2924.                     information. This record type is ignored
  2925.                     by Microsoft LINK.
  2926.                           
  2927.    86H     PIDATA   Physical Iterated Data Record
  2928.                     This record provides contiguous data,
  2929.                     from which a portion of an 8086 memory
  2930.                     image may be constructed. It allows
  2931.                     initialization of data segments and
  2932.                     provides a mechanism to reduce the size
  2933.                     of object modules when there is repeated
  2934.                     data to be used to initialize a memory
  2935.                     image. The data belongs to the "unnamed
  2936.                     absolute segment." This record type is
  2937.                     ignored by Microsoft LINK.
  2938.                           
  2939.    [88H]   [COMENT] [Comment Record]
  2940.                           
  2941.    [8AH/8BH] [MODEND] [Module End Record]
  2942.                           
  2943.    [8CH]   [EXTDEF] [External Names Definition Record]
  2944.                           
  2945.    [8EH]   [TYPDEF] [Type Definition Record]
  2946.                           
  2947.    [90H/91H] [PUBDEF] [Public Names Definition Record]
  2948.                           
  2949.    92H     LOCSYM   Local Symbols Record
  2950.                     This record provides information about
  2951.                     symbols that were used in the source
  2952.                     program input to the translator that
  2953.                     produced the module. This information is
  2954.                     used to aid debugging programs. This
  2955.                     record has a format identical to the
  2956.                     PUBDEF record. This record type is
  2957.                     ignored by Microsoft LINK.
  2958.                           
  2959.    [94H/95H] [LINNUM] [Line Numbers Record]
  2960.                           
  2961.    [96H]   [LNAMES] [List of Names Record]
  2962.                           
  2963.    [98H/99H] [SEGDEF] [Segment Definition Record]
  2964.                           
  2965.    [9AH]   [GRPDEF] [Group Definition Record]
  2966.                           
  2967.    [9CH/9DH] [FIXUPP] [Fixup Record]
  2968.                           
  2969.    9EH     (none)   Unnamed record
  2970.                     This record number was the only even
  2971.                     number not defined by the original Intel
  2972.                     specification. Apparently it was never
  2973.                     used.  This record type is ignored by
  2974.                     Microsoft LINK.
  2975.                           
  2976.    [A0H/A1H] [LEDATA] [Logical Enumerated Data Record]
  2977.                           
  2978.    [A2H/A3H] [LIDATA] [Logical Iterated Data Record]
  2979.  
  2980.    A4H     LIBHED   Library Header Record
  2981.                     This record is the first record in a library
  2982.                     file. It immediately precedes the modules
  2983.                     (if any) in the library. Following the
  2984.                     modules are three more records in the
  2985.                     following order: LIBNAM, LIBLOC, and LIBDIC.
  2986.                     This record type is ignored by Microsoft
  2987.                     LINK.
  2988.                         
  2989.    A6H     LIBNAM   Library Module Names Record
  2990.                     This record lists the names of all the
  2991.                     modules in the library. The names are listed
  2992.                     in the same sequence as the modules appear
  2993.                     in the library. This record type is ignored
  2994.                     by Microsoft LINK.
  2995.                         
  2996.    A8H     LIBLOC   Library Module Locations Record
  2997.                     This record provides the relative location,
  2998.                     within the library file, of the first byte
  2999.                     of the first record (either a THEADR or
  3000.                     LHEADR or RHEADR record) of each module in
  3001.                     the library. The order of the locations
  3002.                     corresponds to the order of the modules in
  3003.                     the library. This record type is ignored by
  3004.                     Microsoft LINK.
  3005.                         
  3006.    AAH     LIBDIC   Library Dictionary Record
  3007.                     This record gives all the names of public
  3008.                     symbols within the library. The public names
  3009.                     are separated into groups; all names in the
  3010.                     nth group are defined in the nth module of
  3011.                     the library. This record type is ignored by
  3012.                     Microsoft LINK.
  3013.                         
  3014.    [B0H]   [COMDEF] [Communal Names Definition Record]
  3015.                         
  3016.    [B2H/B3H] [BAKPAT] [Backpatch Record]
  3017.                         
  3018.    [B4H]   [LEXTDEF] [Local External Names Definition Record]
  3019.                         
  3020.    [B6H/B7H] [LPUBDEF] [Local Public Names Definition Record]
  3021.                         
  3022.    [B8H]   [LCOMDEF] [Local Communal Names Definition Record]
  3023.                         
  3024.    BAH/BBH COMFIX   Communal Fixup Record
  3025.                     Microsoft doesn't support this never-
  3026.                     implemented IBM extension. This record type
  3027.                     generates an error when it is encountered by
  3028.                     Microsoft LINK.
  3029.                         
  3030.    BCH     CEXTDEF  COMDAT External Names Definition Record
  3031.                         
  3032.    C0H     SELDEF   Selector Definition Record
  3033.                     Microsoft doesn't support this never-
  3034.                     implemented IBM extension. This record type
  3035.                     generates an error when it is encountered by
  3036.                     Microsoft LINK.
  3037.                         
  3038.    [C2H/C3] [COMDAT] [Initialized Communal Data Record]
  3039.                         
  3040.    [C4H/C5H] [LINSYM] [Symbol Line Numbers Record]
  3041.                         
  3042.    [C6H]   [ALIAS]  [Alias Definition Record]
  3043.                         
  3044.    [C8H/C9H] [NBKPAT] [Named Backpatch Record]
  3045.                         
  3046.    [CAH]   [LLNAMES] [Local Logical Names Definition Record]
  3047.                         
  3048.    [F0H]            [Library Header Record]
  3049.                     Although this is not actually an OMF record
  3050.                     type, the presence of a record with F0H as
  3051.                     the first byte indicates that the module is
  3052.                     a Microsoft library. The format of a library
  3053.                     file is given in Appendix 2.
  3054.  
  3055.    [F1H]            [Library End Record]
  3056.                         
  3057.  
  3058. 80H THEADR--TRANSLATOR HEADER RECORD
  3059.  
  3060. The THEADR record contains the name of the object module. This name
  3061. identifies an object module within an object library or in messages
  3062. produced by the linker.
  3063.  
  3064. OFFSET              Count TYPE   Description
  3065. 0000h                   1 byte   ID=80h
  3066. 0001h                   1 byte   Record length
  3067.                                  ="LEN"
  3068. 0002h               "LEN" char   Name
  3069. 0002h                   1 byte   Checksum
  3070. +"LEN"
  3071.  
  3072.   
  3073. 82H LHEADR--LIBRARY MODULE HEADER RECORD
  3074.  
  3075. This record is very similar to the THEADR record. It is used to
  3076. indicate the name of a module within a library file (which has an
  3077. internal organization different from that of an object module).
  3078. This record type was defined in the original Intel specification with
  3079. the same format but with a different purpose, so its use for libraries
  3080. should be considered a Microsoft extension.
  3081.  
  3082. OFFSET              Count TYPE   Description
  3083. 0000h                   1 byte   ID=82h
  3084. 0001h                   1 byte   Record length
  3085.                                  ="LEN"
  3086. 0002h               "LEN" char   Name
  3087. 0002h                   1 byte   Checksum
  3088. +"LEN"
  3089.  
  3090. EXTENSION:OBJ,OBP,OBW,LIB
  3091. OCCURENCES:PC
  3092. PROGRAMS:MS Link, TLink
  3093. REFERENCE:****
  3094. --------H-OS/2 HELP-------------------------
  3095. The OS/2 help files are different from the WinHelp help files,since the WinHelp
  3096. format is proprietary to MicroSoft because of the patented LZ-packing they
  3097. implemented.
  3098. OFFSET              Count TYPE   Description
  3099. 0000h                   3 char   ID='HSP'
  3100. 0003h                   1 byte   Flags :
  3101.                                    0 - INF style file
  3102.                                  1-3 - unknown
  3103.                                    4 - HLP style file
  3104.                                  Patching this file allows reading HLP files
  3105.                                  using the VIEW command, while HLP files seem to
  3106.                                  work with INF settings as well.
  3107. 0005h                   1 word   Total size of header
  3108. 0007h                   1 word   Unknown
  3109. ????h                   other data
  3110. 0047h                   ? char   ASCIIZ name of the HLP/INF file
  3111. EXTENSION:HLP,INF
  3112. OCCURENCES:OS/2
  3113. REFERENCE:INF02A.DOC
  3114. SEE ALSO:WinHelp HLP
  3115. --------I-PBM-G-----------------------------
  3116. The PBM files are image files, which were used at least by DMGraph, an utility
  3117. to insert new graphics into a DOOM WAD file. The image dimensions seem to be
  3118. stored in ASCII format delimited with CR/LF, after that follows the raw binary
  3119. image data.
  3120. OFFSET              Count TYPE   Description
  3121. 0000h                   1 char   ID='P'
  3122. 0001h                   1 char   Bitmap type :
  3123.                                  '1' - PBM bitmap
  3124.                                  '2' - PGM greymap
  3125.                                  '3' - PPM pixmap
  3126.                                  '4' - PBM raw bitmap
  3127.                                  '5' - PGM raw greymap
  3128.                                  '6' - PPM raw pixmap
  3129. EXTENSION:PBM,PGM,PPM
  3130. OCCURENCES:PC
  3131. PROGRAMS:DMGraph.EXE
  3132. --------I-PCX-------------------------------
  3133. The PCX files are created by the programs of the ZSoft Paintbrush family
  3134. and the FRIEZE package by the same manufacturer. A PCX file contains only
  3135. one image, the data for this image and possibly palette information for
  3136. this image. The encoding scheme used for PCX encoding is a simple RLE
  3137. mechanism, see ALGRTHMS.txt for further information. A PCX image is stored
  3138. from the upper scan line to the lower scan line.
  3139.  
  3140. The size of a decoded scan line is ******
  3141.  
  3142. The header has a fixed size of 128 bytes and looks like this :
  3143. OFFSET              Count TYPE   Description
  3144. 0000h                   1 byte   Manufacturer.
  3145.                                  10=ZSoft
  3146. 0001h                   1 byte   Version information
  3147.                                   0=PC Paintbrush v2.5
  3148.                                   2=PC Paintbrush v2.8 w palette information
  3149.                                   3=PC Paintbrush v2.8 w/o palette information
  3150.                                   4=PC Paintbrush/Windows
  3151.                                   5=PC Paintbrush v3.0+
  3152. 0002h                   1 byte   Encoding scheme, 1 = RLE, none other known
  3153. 0003h                   1 byte   Bits per pixel
  3154. 0004h                   1 word   left margin of image
  3155. 0006h                   1 word   upper margin of image
  3156. 0008h                   1 word   right margin of image
  3157. 000Ah                   1 word   lower margin of image
  3158. 000Ch                   1 word   Horizontal DPI resolution
  3159. 000Eh                   1 word   Vertical DPI resolution
  3160. 0010h                  48 byte   Color palette setting for 16-color images
  3161.                                  16 RGB triplets
  3162. 0040h                   1 byte   reserved
  3163. 0041h                   1 byte   Number of color planes
  3164.                                  ="NCP"
  3165. 0042h                   1 word   Number of bytes per scanline (always even,
  3166.                                  use instead of right margin-left margin).
  3167.                                  ="NBS"
  3168. 0044h                   1 word   Palette information
  3169.                                   1=color/bw palette
  3170.                                   2=grayscale image
  3171. 0046h                   1 word   Horizontal screen size
  3172. 0048h                   1 word   Vertical screen size
  3173. 004Ah                  54 byte   reserved, set to 0
  3174.  
  3175. The space needed to decode a single scan line is "NCP"*"NBS" bytes, the last
  3176. byte may be a junk byte which is not displayed.
  3177.  
  3178. After the image data, if the version number is 5 (or greater?) there possibly
  3179. is a VGA color palette. The color ranges from 0 to 255, 0 is zero intensity,
  3180. 255 is full intensity. The palette has the following format :
  3181.  
  3182. OFFSET              Count TYPE   Description
  3183. 0000h                   1 byte   VGA palette ID (=0Ch)
  3184. 0001h                 768 byte   RGB triplets with palette information
  3185.  
  3186. EXTENSION:PCX
  3187. OCCURENCES:PC
  3188. PROGRAMS:PC Paintbrush
  3189. SEE ALSO:
  3190. --------I-PIC-------------------------------
  3191. PIC files contain images in an uncompressed format. Both the original Animator
  3192. and Animator Pro from Autodesk produce PIC files. The file formats are
  3193. different; Animator Pro produces a hierarchial block oriented file, while the
  3194. original Animator file is a simpler fixed format. See PIC(Pro) for further
  3195. information on the Animator Pro PIC format.
  3196.  
  3197. The original Animator uses this format to store a single-frame picture image.
  3198. This format description applies to both PIC and original Animator CEL files. The
  3199. file begins with a 32 byte header, as follows:
  3200.  
  3201. OFFSET              Count TYPE   Description
  3202. 0000h                   1 word   ID=9119h
  3203. 0002h                   1 word   Width of image; PIC files have always a width
  3204.                                  of 320, CEL images may have any value.
  3205. 0004h                   1 word   Height of image, 200 for a PIC, any value for
  3206.                                  a CEL file.
  3207. 0006h                   1 word   X offset of image, always 0 for a PIC image,
  3208.                                  may be nonzero in a CEL image.
  3209. 0008h                   1 word   Y offset of image. Zero for a PIC file.
  3210. 000Ah                   1 byte   Bits per pixel (8)
  3211. 000Bh                   1 byte   Compresion flag, always zero
  3212. 000Ch                   1 dword  Size of the image data in bytes
  3213. 0010h                  16 byte   reserved(0)
  3214.  
  3215. Immediately following the header is the color map.  It contains all 256 palette
  3216. entries in rgb order. Each of the r, g, and b components is a single byte in the
  3217. range of 0-63.  Following the color palette is the image data, one byte per
  3218. pixel, from left to right, top to bottom.
  3219. EXTENSION:PIC,CEL
  3220. OCCURENCES:PC
  3221. PROGRAMS:Autodesk Animator
  3222. SEE ALSO:CEL,FLIc,PIC(PRO)
  3223. --------I-PIC(PRO)--------------------------
  3224. This format description applies to both PIC and MSK files created with the
  3225. Autodesk Animator Pro package. The file begins with a 64-byte header defined
  3226. as follows:
  3227.  
  3228. Offset  Length  Name         Description
  3229. 0000h                   1 dword  The size of the whole file including the size
  3230.                                  of this header.
  3231. 0004h                   1 word   ID=9500h
  3232. 0006h                   1 word   Width of the image
  3233. 0008h                   1 word   Height of the image
  3234. 000Ah                   1 word   X offset of image
  3235. 000Ch                   1 word   Y offset of image
  3236. 000Eh                   1 dword  User ID, set to zero
  3237. 0012h                   1 byte   Bits per pixel (8 for PIC, 1 for MSK)
  3238. 0013h                  45 byte   reserved (0)
  3239.  
  3240. Following the file header are the data blocks for the image. Each data block
  3241. within a PIC or MSK file is formatted as follows:
  3242.  
  3243. OFFSET              Count TYPE   Description
  3244. 0000h                   1 dword  The size of the block, including this header.
  3245. 0004h                   1 word   Data type ID :
  3246.                                   0 - Color palette info
  3247.                                   1 - Byte-per-pixel image data
  3248.                                   2 - Bit-per-pixel mask data
  3249. 0006h                   ? byte   Data
  3250.  
  3251. The type values in the block headers indicate what type of graphics data the
  3252. block contains.
  3253.  
  3254. In a PIC_CMAP block, the first 2-byte word is a version code;
  3255. currently this is set to zero. Following the version word are all 256 palette
  3256. entries in rgb order. Each of the r, g, and b components is a single byte in the
  3257. range of 0-255. This type of block appears in PIC files; there will generally be
  3258. no color map block in a MSK file.
  3259.  
  3260. In a PIC_BYTEPIXELS block, the image data appears immediately following the
  3261. 6-byte block header. The data is stored as one byte per pixel, in left-to-right,
  3262. topD to-bottom sequence.
  3263.  
  3264. In a PIC_BITPIXELS block, the bitmap data appears immediately following the
  3265. 6-byte block header. The data is stored as bits packed into bytes such that the
  3266. leftmost bits appear in the high-order positions of each byte. The bits are
  3267. stored in left-to-right, top-to bottom sequence. When the width of the bitmap is
  3268. not a multiple of 8, there will be unused bits in the low order positions of the
  3269. last byte on each line. The number of bytes per line is ((width+7)/8). This type
  3270. of block appears in MSK files.
  3271.  
  3272. EXTENSION:PIC,MSK
  3273. OCCURENCES:PC
  3274. PROGRAMS:Autodesk Animator Pro
  3275. REFERENCE:
  3276. SEE ALSO:PIC,FLT
  3277. --------I-PLY-------------------------------
  3278. The PoLYgon files created by the Autodesk Animator packages contain a set of
  3279. points that describe a polygon.
  3280. OFFSET              Count TYPE   Description
  3281. 0000h                   1 word   Number of points in the file
  3282. 0002h                   1 dword  reserved (0)
  3283. 0006h                   1 byte   Closed shape flag. If nonzero there is an
  3284.                                  implied connection between the last and the
  3285.                                  first point. If it is zero, the shape is open.
  3286. 0007h                   1 byte   ID=99h
  3287.  
  3288. After the header, there follows the point data, organized in records like this :
  3289. OFFSET              Count TYPE   Description
  3290. 0000h                   1 word   X coordinate
  3291. 0002h                   1 word   Y coordinate
  3292. 0006h                   1 word   Z coordinate, always zero
  3293.  
  3294. EXTENSION:PLY
  3295. OCCURENCES:PC
  3296. PROGRAMS:Autodesk Animator
  3297. --------M-PS16------------------------------
  3298. The Protracker Studio 16 Modules are yet another digital music format.
  3299. The Protracker modules can have up to 255 different patterns and a length of
  3300. up to 255 patterns with 31 instruments. The samples can only have a size of
  3301. up to 64K, there is a maximum of 16 tracks supported.
  3302. The header of each MOD file looks like this :
  3303. OFFSET              Count TYPE   Description
  3304. 0000h                   5 char   Header string
  3305.                                  ID='PS16',254
  3306. 0005h                  75 char   Song name, ending with ^Z so that if typing
  3307.                                  the file will result in PS16 <SongName>
  3308. 0050h                   1 byte   File type :
  3309.                                   0 - Module with patterns and samples
  3310.                                   1 - Song with patterns but without samples
  3311. 0051h                   1 dword  Offset of comment field from start of file.
  3312.                                  Zero if no commend is stored.
  3313. 0055h                   1 byte   Format version byte (0)
  3314. 0056h                   1 byte   Number of patterns in the file
  3315.                                  ="PAT"
  3316. 0057h                   1 dword  Total size of all patterns in bytes, stored
  3317.                                  for quick disk reads.
  3318. 005Bh                   1 byte   Songlength, number of sequences.
  3319. 005Ch                 128 byte   Sequencing information for file
  3320. 00CCh                  31 rec    Sample information
  3321.                         1 byte   Sample flags, bitmapped :
  3322.                                    0 - synthesized / digital
  3323.                                    1 - Waveform / FM
  3324.                                        (only if bit 0 is set)
  3325.                                    2 - 16 bit / 8 bit
  3326.                          1 byte  Default volume for the sample (0-64)
  3327.                          1 byte  Sample fine tuning (signed nibble)
  3328.                          1 dword Sample length - Protracker does only support
  3329.                                  samples with a size less than 64K.
  3330.                          1 dword Sample loop start
  3331.                          1 dword Sample loop length
  3332.                          1 word  Default playback frequency for C2
  3333.                                  Can be used to fine tune a sample.
  3334. 00CCh+               "PAT" rec   The pattern information
  3335.  31*17                           The tracks are stored sequentially after each
  3336.                                  other, first all rows of track 1, then all rows
  3337.                                  of track 2 and so on.
  3338.                         1 word   Pattern size+3, rounded up to a paragraph
  3339.                                  boundary.
  3340.                         1 byte   Number of rows in pattern
  3341.                                  ="ROW"
  3342.                     "ROW" rec
  3343.                         2 byte   Note information, bitmapped :
  3344.                                    0-5 - Note (see table 0005)
  3345.                                      6 - Bit 4 of instrument
  3346.                                      7 - Compression bit
  3347.                                          If this bit not set, there is another
  3348.                                          byte following the note record
  3349.                                          specifying the row where the next
  3350.                                          event takes place - if it is set,
  3351.                                          the next note follows immediately.
  3352.                                          A track is terminated by a 0FFh byte.
  3353.                                   8-11 - Effect bits
  3354.                                  12-15 - Bits 0-3 of instrument
  3355.                          1 byte  Effect data
  3356. 00CCh+                   ? byte  Sample data in delta format
  3357.  31*17+                          See algorthm.txt for details.
  3358.  ????
  3359.  
  3360. The comment block contains information about the sample names as well
  3361. as some comments to the module. It is formatted like this :
  3362. OFFSET              Count TYPE   Description
  3363. 0000h                   4 char   ID='INST'
  3364.                         1 byte   Instrument name length
  3365.                                  ="LEN"
  3366.                         1 byte   Sample name count
  3367.                                  ="CNT"
  3368.               "LEN"*"CNT" char   Sample names
  3369. 0000h+                  4 char   ID='TEXT'
  3370.  "LEN"*"CNT"+4
  3371.                         1 word   Length of following text
  3372. EXTENSION:MOD
  3373. OCCURENCES:PC
  3374. PROGRAMS:Protracker
  3375. REFERENCE:
  3376. SEE ALSO:DMF,MOD,S3M,STM
  3377. VALIDATION:
  3378. --------I-QFX-------------------------------
  3379. QFX files are yet another graphic file format used to store received
  3380. fax images. The .QFX file format is proprietary to Smith Micro Software, Inc.
  3381. and is used by the Quick Link II fax software.
  3382. The QFX file header is exactly 1536 bytes long. The fax pages themselves
  3383. are stored in byte aligned, bit reversed T4 format terminated with 6 EOL's.
  3384. See CCITT Recommendation T.4 for full documentation on this coding scheme.
  3385.  
  3386. OFFSET              Count TYPE   Description
  3387. 0000h                   8 char   ID='QLIIFAX',0
  3388. 0008h                   1 word   Number of pages in the QFX file
  3389. 000Ah                   1 word   Number of scan lines on last page
  3390. 000Ch                   1 dword  Number of scan lines for all pages
  3391. 0010h                   1 word   Horizontal scaling
  3392.                                  1 - High res (200x200),
  3393.                                  2 - Normal res (200x100)
  3394. 0012h                   1 word   Vertical scaling (always = 1).
  3395. 0014h                  12 byte   reserved
  3396. 0020h                 375 dword  Offsets of the single pages in the document.
  3397.                                  Page 1 always starts at offset 1536. The last
  3398.                                  non-zero dword points to the end of the last
  3399.                                  page, the first zero dword marks the end of
  3400.                                  the pages.
  3401. 0600h                   ? byte   Start of fax page images
  3402.  
  3403. EXTENSION:QFX
  3404. OCCURENCES:PC
  3405. PROGRAMS:Quick Link II
  3406. --------S-RAW-------------------------------
  3407. The RAW files are raw signed PCM sound files.  PCM means Pulse Code
  3408. Modulation - which can be played through most sound devices without
  3409. further manipulation. There is no header or whatsoever.
  3410. The properties include 8/16-bit samples in INTEL order,
  3411. stereo or mono format. No identification is possible.
  3412. EXTENSION:RAW
  3413. SEE ALSO:SND
  3414. --------I-RDIB------------------------------
  3415. The RDIB files are Device Independent Bitmaps used by Windows. They are RIFF
  3416. format files. The blocks are unknown to me.
  3417. SEE ALSO:RIFF
  3418. --------f-RIFF------------------------------
  3419. The RIFF (Resource interchange file format) format was created by Microsoft and
  3420. is used by many applications like Windows, Corel Draw etc.. It is block
  3421. structured, each block has a header ID and a size, so that even a program that
  3422. works with an old version of the file format can skip the unknown parts of the
  3423. file and work on the known parts of the file. All RIFF blocks begin on a word
  3424. boundary so it might be necessary to skip an additional byte. In the present
  3425. specification, only one RIFF block per file is allowed, and only the RIFF and
  3426. LIST blocks may contain subblocks.
  3427.  
  3428. The order of blocks in a RIFF file is not mandatory, so you should always scan
  3429. the whole file for the block ID you seek. Throughout this file, the RIFF block
  3430. IDs are given in square brackets []. Each ID is always 4 characters dword.
  3431.  
  3432. OFFSET              Count TYPE   Description
  3433. 0000h                   4 char   ID='RIFF'
  3434.                                  Each RIFF format file has a header with the
  3435.                                  signature and the size of the following
  3436.                                  blocks.
  3437. 0004h                   1 dword  Block size. This size is the size of the block
  3438.                                  controlled by the RIFF header. Normally this
  3439.                                  equals the file size.
  3440.                                  ="BSZ"
  3441. 0008h                   4 char   Format name. This is the format name of the RIFF
  3442.                                  file.
  3443. After this RIFF header comes the first RIFF record. Each RIFF record has the
  3444. following format :
  3445. OFFSET              Count TYPE   Description
  3446. 0000h                   4 char   Signature. This is the description of what is
  3447.                                  contained in this block.
  3448. 0004h                   1 dword  Block size. This is the size of the following
  3449.                                  data block. To get the offset of the next RIFF
  3450.                                  block record, you have to add this value + 8 to
  3451.                                  the offset of the current record.
  3452.  
  3453. ---RiffBLOCK [LIST]
  3454. This block contains a string list, again in the RIFF subblock format. This list
  3455. is used for messages and/or copyright messages. All strings in the LIST block
  3456. share the same format, each block contains one ASCIIZ string - the most common
  3457. LIST block is the [INFO] block, which can contain the following subblocks :
  3458.  
  3459. [INAM]
  3460. The name of the data stored in the file
  3461. [ICRD]
  3462. Creation date of the file
  3463.  
  3464. SEE ALSO:BMP,rDIB,IFF,WAVe,RIFX
  3465. OCCURENCES:PC
  3466. PROGRAMS:Windows,Corel Draw
  3467. REFERENCE:DDJ0994
  3468. VALIDATION:FileSize="BSZ"+8
  3469. --------f-RIFX-M----------------------------
  3470. The RIFX file format is identical to the RIFF file format except that all values
  3471. are in Motorola byte order.
  3472. OFFSET              Count TYPE   Description
  3473. 0000h                   4 char   ID='RIFX'
  3474. 0004h                   1 dword  Block size. This size is the size of the block
  3475.                                  controlled by the RIFX header.
  3476.                                  ="BSZ"
  3477. 0008h                   4 char   Format name.
  3478. REFERENCE:DDJ0994
  3479. SEE ALSO:RIFF
  3480. --------S-S3I-------------------------------
  3481. This is the Digiplayer/ST3.0 digital sample file format. The sample
  3482. files include information about the loop of the instrument. The AdLib
  3483. instruments have another format listed below.
  3484.  
  3485. OFFSET              Count TYPE   Description
  3486. 0000h                   1 byte   ID=01h
  3487. 0001h                  12 char   DOS filename
  3488. 000Dh                   1 byte   reserved (0)
  3489. 000Eh                   1 word   Paragraph offset of the raw sample data
  3490.                                  from beginning of file.
  3491. 0010h                   1 dword  Sample length in bytes
  3492. 0014h                   1 dword  Start of sample loop
  3493. 0018h                   1 dword  End of sample loop
  3494. 001Ch                   1 byte   Playback volumne of sample
  3495. 001Dh                   1 byte   ??? "DSK" what ever that means
  3496. 001Eh                   1 byte   Pack type
  3497.                                  0 - unpacked
  3498.                                  1 - DP30ADPCM 1
  3499. 001Fh                   1 byte   Flags (bitmapped)
  3500.                                  0 - loop on/off
  3501.                                  1 - stereo sample (length bytes for left channel,
  3502.                                      then another length bytes for right channel!)
  3503.                                  2 - 16-Bit samples (in Intel byte order)
  3504. 0020h                   1 dword  C2 frequency
  3505. 0024h                   1 dword  reserved
  3506. 0028h                   1 word   reserved
  3507. 002Ah                   1 word   ID=512
  3508. 002Ch                   1 dword  ?? Date of last modification ?? (see table 0009)
  3509. 0030h                  28 char   ASCIIZ Sample name
  3510. 003Ch                   4 char   ID='SCRS'
  3511. 0040h                   ? byte   Raw sample data
  3512.  
  3513. Here follows the AdLib instrument format for which I don't know the
  3514. extension (yet) :
  3515.  
  3516. OFFSET              Count TYPE   Description
  3517. 0000h                   1 byte   Instrument type
  3518.                                  2 - melodic instrument
  3519.                                  3 - bass drum
  3520.                                  4 - snare drum
  3521.                                  5 - tom tom
  3522.                                  6 - cymbal
  3523.                                  7 - hihat
  3524. 0001h                  12 char   DOS file name
  3525. 000Dh                   3 byte   reserved
  3526. 0010h                   1 byte   Modulator description (bitmapped)
  3527.                                  0-3 - frequency multiplier
  3528.                                    4 - scale envelope
  3529.                                    5 - sustain
  3530.                                    6 - pitch vibrato
  3531.                                    7 - volume vibrato
  3532. 0011h                   1 byte   Carrier description (same as modulator)
  3533. 0012h                   1 byte   Modulator miscellaneous (bitmapped)
  3534.                                  0-5 - 63-volume
  3535.                                    6 - MSB of levelscale
  3536.                                    7 - LSB of levelscale
  3537. 0013h                   1 byte   Carrier description (same as modulator)
  3538. 0014h                   1 byte   Modulator attack / decay byte (bitmapped)
  3539.                                  0-3 - Decay
  3540.                                  4-7 - Attack
  3541. 0015h                   1 byte   Carrier description (same as modulator)
  3542. 0016h                   1 byte   Modulator sustain / release byte (bitmapped)
  3543.                                  0-3 - Release count
  3544.                                  4-7 - 15-Sustain
  3545. 0017h                   1 byte   Carrier description (same as modulator)
  3546. 0018h                   1 byte   Modulator wave select
  3547. 0019h                   1 byte   Carrier wave select
  3548. 001Ah                   1 byte   Modulator feedback byte (bitmapped)
  3549.                                    0 - additive synthesis on/off
  3550.                                  1-7 - modulation feedback
  3551. 001Bh                   1 byte   reserved
  3552. 001Ch                   1 byte   Instrument playback volume
  3553. 001Dh                   1 byte   ??? "DSK"
  3554. 001Eh                   1 word   reserved
  3555. 0020h                   1 dword  C2 frequency
  3556. 0024h                  12 byte   reserved
  3557. 0030h                  28 char   ASCIIZ Instrument name
  3558. 004Ch                   4 char   ID='SCRI'
  3559.  
  3560. EXTENSION:S3I,SMP
  3561. OCCURENCES:PC
  3562. PROGRAMS:ScreamTracker 3.0
  3563. SEE ALSO:MTM,S3M,STM
  3564. --------M-S3M-------------------------------
  3565. The ScreamTracker composer and the ScreamTracker Music Interface Kit (STMIK)
  3566. were written by the demo group Future Crew for their demonstrations and
  3567. released. S3M files are the files of the version 3 of the ScreamTracker.
  3568.  
  3569. OFFSET              Count TYPE   Description
  3570. 0000h                  20 char   Song name, ASCII, 0 padded
  3571. 001Ch                   1 byte   ID=1Ah
  3572. 001Dh                   1 byte   Filetype :
  3573.                                    16=Module
  3574.                                    17=Song
  3575.                                  ? What is this supposed to mean ?
  3576. 001Eh                   1 word   Reserved
  3577. 0020h                   1 word   Number of orders in song
  3578.                                  ="ORD"
  3579. 0022h                   1 word   Number of instruments in song
  3580.                                  ="INS"
  3581. 0024h                   1 word   Number of patterns in song
  3582.                                  ="PAT"
  3583. 0026h                   1 word   Song flags, bitmapped
  3584.                                  0 - ScreamTracker 2.0 type vibrato
  3585.                                  1 - ScreamTracker 2.0 type tempo
  3586.                                  2 - Amiga type slides
  3587.                                  3 - Zero volume optimizations
  3588.                                  4 - Amiga limits
  3589.                                  5 - enable filters / sfx
  3590. 0028h                   1 word  Tracker version
  3591. 002Ah                   1 word  File format version
  3592.                                  1=Original format
  3593.                                  2=Original format, unsigned samples
  3594. 002Ch                   4 char  ID='SCRM'
  3595. 0032h                   1 byte  Maximum volume
  3596. 0033h                   1 byte  Initial speed
  3597. 0034h                   1 byte  Initial tempo
  3598. 0035h                   1 byte  Master multiplier
  3599.                                 Whats this ????
  3600. 0036h                  12 byte  reserved
  3601. 0040h                  32 byte  Channel balance settings
  3602.                                    0=left
  3603.                                  127=right
  3604.                                 +128=disabled
  3605.                                  255=unused
  3606. 0060h               "ORD" byte  Ordering sequence of the patterns
  3607. 0060h               "INS" word  Offset of the instruments in paragraphs from 
  3608. +"ORD"                          begin of header (for binary offset, multiply with 16)
  3609. 0060h               "PAT" word  Offset of the pattern data from begin of header
  3610. +"ORD"                          in paragraphs
  3611. +"INS"*2
  3612.  
  3613. EXTENSION:S3M
  3614. OCCURENCES:PC
  3615. PROGRAMS:ScreamTracker 3.0
  3616. SEE ALSO:S3I,STM,S2M
  3617. --------S-SND-------------------------------
  3618. The SND files are raw unsigned PCM sound files. PCM means Pulse Code
  3619. Modulation - which can be played through most sound devices without
  3620. further manipulation. There is no header or whatsoever.
  3621. The properties include 8/16-bit samples in INTEL order,
  3622. stereo or mono format. No identification is possible.
  3623. EXTENSION:SND
  3624. SEE ALSO:RAW
  3625. --------A-SQZ-------------------------------
  3626. The SQZ files are yet another archive format. The SQZ archives consist of one
  3627. archive header and several file headers. The archive header has the
  3628. following format :
  3629. OFFSET              Count TYPE   Description
  3630. 0000h                   5 char   ID='HLSQZ'
  3631. 0005h                   1 char   Version in ASCII
  3632.                                  ID='1'
  3633. 0006h                   1 byte   OS byte,
  3634.                                   0 - PC-DOS / MS-DOS
  3635.                                   1 - OS/2
  3636.                                   2 - MVS
  3637.                                   3 - HPFS (OS/2)
  3638.                                   4 - Amiga
  3639.                                   5 - Macintosh
  3640.                                   6 - Unix
  3641. 0007h                   1 byte   Misc. flags, bitmapped :
  3642.                                   0 - Intel byte order / Motorola byte order
  3643.                                   1 - Filetime in ?? / File time in DOS format
  3644.                                   2 - No security envelope / security envelope
  3645.                                 3-7 - reserved
  3646.  
  3647. After the header and each block, there is one byte denoting the type/size of the
  3648. next block :
  3649. OFFSET              Count TYPE   Description
  3650. 0000h                   1 byte   Block/size specifier :
  3651.                                  0 - End of archive
  3652.                                  1 - Comment
  3653.                                  2 - Password
  3654.                                  3 - Security envelope
  3655.                               4-18 - reserved
  3656.                                >18 - normal file header,
  3657.                                      byte value is size of header
  3658.  
  3659. The normal file header then has the following format :
  3660. OFFSET              Count TYPE   Description
  3661. 0000h                   1 byte   Checksum of header
  3662. 0001h                   1 byte   Flags, bitmapped :
  3663.                                  0-3 : Compression method :
  3664.                                          0 -
  3665.                                          1 -
  3666.                                          2 -
  3667.                                          3 -
  3668.                                          4 -
  3669.                                    4 - Security envelope should follow
  3670.                                  5-7 - reserved
  3671. 0002h                   1 dword  Compressed size of file
  3672. 0006h                   1 dword  Original file size
  3673. 000Ah                   1 dword  Date and time of file (see table 0009)
  3674. 000Eh                   1 byte   File attributes
  3675. 000Fh                   1 dword  CRC-32 of file
  3676. 0013h                   ? char   Filename (see above for length)
  3677.  
  3678. The comment block :
  3679. OFFSET              Count TYPE   Description
  3680. 0000h                   1 word   Size of uncompressed comment
  3681. 0002h                   1 word   Size of compressed comment data
  3682.                                  ="LEN"
  3683. 0004h                   1 byte   Flags, bitmapped, see above
  3684. 0005h                   1 dword  CRC-32
  3685. 0009h               "LEN" byte   Compressed comment data
  3686.  
  3687. The password block :
  3688. OFFSET              Count TYPE   Description
  3689. 0000h                   1 word   Size of password block (=4)
  3690. 0004h                   1 dword  CRC-32 of password
  3691.  
  3692. Other blocks :
  3693. OFFSET              Count TYPE   Description
  3694. 0000h                   1 word   Size of this block
  3695.                                  ="LEN"
  3696. 0002h               "LEN" byte   Block data
  3697.  
  3698. EXTENSION:SQZ
  3699. OCCURENCES:PC
  3700. PROGRAMS:??
  3701. REFERENCE:
  3702. SEE ALSO:
  3703. --------S-SDK-------------------------------
  3704. The SDK files are disk images from disks used by the Roland
  3705. S-550/S-50/S-330 sampler devices.
  3706. Further information wanted.
  3707. EXTENSION:SDK
  3708. --------S-SDS-------------------------------
  3709. The SDS files are MIDI Sample Dump Standart files and are used
  3710. to transfer samples between MIDI devices.
  3711. Further information wanted.
  3712. EXTENSION:SDS
  3713. SEE ALSO:MID,SDX
  3714. --------S-SDX-------------------------------
  3715. The SDX file are like the SDS files sample dump files used
  3716. for transfer of data between MIDI devices.
  3717. EXTENSION:SDX
  3718. SEE ALSO:MID,SDS
  3719. --------S-SMP-------------------------------
  3720. The SMP files are digital sample files used by Samplevision software.
  3721. Further information wanted.
  3722. EXTENSION:SMP
  3723. --------M-STM-------------------------------
  3724. The ScreamTracker 1.0 format was the module format used by the
  3725. ScreamTracker before version 2.0.
  3726.  
  3727. OFFSET              Count TYPE   Description
  3728. 0000h                  20 char   ASCIIZ song name
  3729. 0014h                   8 char   Tracker name
  3730. 001Ch                   1 byte   ID=1Ah
  3731. 001Dh                   1 byte   File type
  3732.                                  1 - song (contains no samples)
  3733.                                  2 - module (contains samples)
  3734. 001Eh                   1 byte   Major version number
  3735. 001Fh                   1 byte   Minor version number
  3736. 0020h                   1 byte   Playback tempo
  3737. 0021h                   1 byte   Number of patterns
  3738.                                  ="PAT"
  3739. 0022h                   1 byte   Global playback volume
  3740. 0023h                  13 byte   reserved
  3741. 0030h                  31 rec    Instrument data
  3742.                        12 char   ASCIIZ instrument name
  3743.                         1 byte   ID=0
  3744.                         1 byte   Instrument disk
  3745.                         1 word   reserved
  3746.                         1 word   Sample length in bytes
  3747.                         1 word   Sample loop start
  3748.                         1 word   Sample loop end
  3749.                         1 byte   Sample playback volume
  3750.                         1 byte   reserved
  3751.                         1 word   C3 frequency in Hz
  3752.                         1 dword  reserved
  3753.                         1 word   length in paragraphs
  3754.                                  (only for modules,in songs:reserved)
  3755. 03D0h                  64 byte   Pattern orders
  3756. 0410h          4*64*"PAT" rec    Pattern data. Each pattern consists of
  3757.                                  64 rows, each 4 channels. The channels
  3758.                                  are stored from left ro right, row by row.
  3759.                         1 byte   Note byte :
  3760.                                    251 - last 3 bytes not stored, all bytes 0
  3761.                                    252 - last 3 bytes not stored, note -0-,
  3762.                                          whatever that means.
  3763.                                    253 - last 3 bytes not stored, note ...
  3764.                                    254 - undefined (reserved for run-time)
  3765.                                    255 - undefined (reserved for run-time)
  3766.                                    otherwise bit mapped :
  3767.                                    0-3 : note (c=0,c#=1...)
  3768.                                    4-7 : octave
  3769.                         1 byte   Only valid if above byte < 251, bit mapped
  3770.                                    0-2 ; lower bit of note volume
  3771.                                    3-7 : instrument number
  3772.                         1 byte   bit mapped
  3773.                                    0-3 : Effect command in ProTracker format
  3774.                                          seems to be overlapped by volume
  3775.                                          bits...
  3776.                                    4-6 : upper bits of volume
  3777.                         1 byte   command data in ProTracker format
  3778. 0410h+                  ? byte   Raw sample data padded to 16 byte boundaries.
  3779.  4*64*4*"PAT"
  3780.  
  3781. EXTENSION:STM
  3782. OCCURENCES:PC
  3783. PROGRAMS:ScreamTracker 1.0
  3784. REFERENCE:
  3785. SEE ALSO:S3M,MOD
  3786. --------A-TAR-G-----------------------------
  3787. The Unix Tape ARchives mostly have the extension TAR. The info about this
  3788. comes from a magic file, thus useful only for identification.
  3789. --------A-TAR-------------------------------
  3790. The Unix TAR program is an archiver program which stores files in a single
  3791. archive without compression.
  3792. OFFSET              Count TYPE   Description
  3793. @section The Standard Format
  3794. A @dfn{tar tape} or file contains a series of records.  Each record
  3795. contains @code{RECORDSIZE} bytes.  Although this format may be
  3796. thought of as being on magnetic tape, other media are often used.
  3797.  
  3798. Each file archived is represented by a header record which describes
  3799. the file, followed by zero or more records which give the contents
  3800. of the file.  At the end of the archive file there may be a record
  3801. filled with binary zeros as an end-of-file marker.  A reasonable
  3802. system should write a record of zeros at the end, but must not
  3803. assume that such a record exists when reading an archive.
  3804.  
  3805. The records may be @dfn{blocked} for physical I/O operations.  Each
  3806. block of @var{N} records (where @var{N} is set by the @samp{-b}
  3807. option to @code{tar}) is written with a single @code{write()}
  3808. operation.  On magnetic tapes, the result of such a write is a
  3809. single tape record.  When writing an archive, the last block of
  3810. records should be written at the full size, with records after the
  3811. zero record containing all zeroes.  When reading an archive, a
  3812. reasonable system should properly handle an archive whose last block
  3813. is shorter than the rest, or which contains garbage records after a
  3814. zero record.
  3815.  
  3816. The header record is defined in C as follows:
  3817.  
  3818. @example
  3819. /*
  3820.  * Standard Archive Format - Standard TAR - USTAR
  3821.  */
  3822. #define  RECORDSIZE  512
  3823. #define  NAMSIZ      100
  3824. #define  TUNMLEN      32
  3825. #define  TGNMLEN      32
  3826.  
  3827. union record @{
  3828.     char        charptr[RECORDSIZE];
  3829.     struct header @{
  3830.         char    name[NAMSIZ];
  3831.         char    mode[8];
  3832.         char    uid[8];
  3833.         char    gid[8];
  3834.         char    size[12];
  3835.         char    mtime[12];
  3836.         char    chksum[8];
  3837.         char    linkflag;
  3838.         char    linkname[NAMSIZ];
  3839.         char    magic[8];
  3840.         char    uname[TUNMLEN];
  3841.         char    gname[TGNMLEN];
  3842.         char    devmajor[8];
  3843.         char    devminor[8];
  3844.     @} header;
  3845. @};
  3846.  
  3847. /* The checksum field is filled with this while the checksum is computed. */
  3848. #define    CHKBLANKS    "        "        /* 8 blanks, no null */
  3849.  
  3850. /* The magic field is filled with this if uname and gname are valid. */
  3851. #define    TMAGIC    "ustar  "        /* 7 chars and a null */
  3852.  
  3853. /* The magic field is filled with this if this is a GNU format dump entry */
  3854. #define    GNUMAGIC  "GNUtar "        /* 7 chars and a null */
  3855.  
  3856. /* The linkflag defines the type of file */
  3857. #define  LF_OLDNORMAL '\0'       /* Normal disk file, Unix compatible */
  3858. #define  LF_NORMAL    '0'        /* Normal disk file */
  3859. #define  LF_LINK      '1'        /* Link to previously dumped file */
  3860. #define  LF_SYMLINK   '2'        /* Symbolic link */
  3861. #define  LF_CHR       '3'        /* Character special file */
  3862. #define  LF_BLK       '4'        /* Block special file */
  3863. #define  LF_DIR       '5'        /* Directory */
  3864. #define  LF_FIFO      '6'        /* FIFO special file */
  3865. #define  LF_CONTIG    '7'        /* Contiguous file */
  3866.  
  3867. /* Further link types may be defined later. */
  3868.  
  3869. /* Bits used in the mode field - values in octal */
  3870. #define  TSUID    04000        /* Set UID on execution */
  3871. #define  TSGID    02000        /* Set GID on execution */
  3872. #define  TSVTX    01000        /* Save text (sticky bit) */
  3873.  
  3874. /* File permissions */
  3875. #define  TUREAD   00400        /* read by owner */
  3876. #define  TUWRITE  00200        /* write by owner */
  3877. #define  TUEXEC   00100        /* execute/search by owner */
  3878. #define  TGREAD   00040        /* read by group */
  3879. #define  TGWRITE  00020        /* write by group */
  3880. #define  TGEXEC   00010        /* execute/search by group */
  3881. #define  TOREAD   00004        /* read by other */
  3882. #define  TOWRITE  00002        /* write by other */
  3883. #define  TOEXEC   00001        /* execute/search by other */
  3884. @end example
  3885.  
  3886. All characters in header records are represented by using 8-bit
  3887. characters in the local variant of ASCII.  Each field within the
  3888. structure is contiguous; that is, there is no padding used within
  3889. the structure.  Each character on the archive medium is stored
  3890. contiguously.
  3891.  
  3892. Bytes representing the contents of files (after the header record of
  3893. each file) are not translated in any way and are not constrained to
  3894. represent characters in any character set.  The @code{tar} format
  3895. does not distinguish text files from binary files, and no
  3896. translation of file contents is performed.
  3897.  
  3898. The @code{name}, @code{linkname}, @code{magic}, @code{uname}, and
  3899. @code{gname} are null-terminated character strings.  All other
  3900. fileds are zero-filled octal numbers in ASCII.  Each numeric field
  3901. of width @var{w} contains @var{w}@minus{} 2 digits, a space, and a null,
  3902. except @code{size}, and @code{mtime}, which do not contain the
  3903. trailing null.
  3904.  
  3905. The @code{name} field is the pathname of the file, with directory
  3906. names (if any) preceding the file name, separated by slashes.
  3907.  
  3908. The @code{mode} field provides nine bits specifying file permissions
  3909. and three bits to specify the Set UID, Set GID, and Save Text
  3910. (``stick'') modes.  Values for these bits are defined above.  When
  3911. special permissions are required to create a file with a given mode,
  3912. and the user restoring files from the archive does not hold such
  3913. permissions, the mode bit(s) specifying those special permissions
  3914. are ignored.  Modes which are not supported by the operating system
  3915. restoring files from the archive will be ignored.  Unsupported modes
  3916. should be faked up when creating or updating an archive; e.g. the
  3917. group permission could be copied from the @code{other} permission.
  3918.  
  3919. The @code{uid} and @code{gid} fields are the numeric user and group
  3920. ID of the file owners, respectively.  If the operating system does
  3921. not support numeric user or group IDs, these fields should be
  3922. ignored.
  3923.  
  3924. The @code{size} field is the size of the file in bytes; linked files
  3925. are archived with this field specified as zero.
  3926. @xref{Extraction Options}; in particular the @samp{-G} option.@refill
  3927.  
  3928. The @code{mtime} field is the modification time of the file at the
  3929. time it was archived.  It is the ASCII representation of the octal
  3930. value of the last time the file was modified, represented as an
  3931. integer number of seconds since January 1, 1970, 00:00 Coordinated
  3932. Universal Time.
  3933.  
  3934. The @code{chksum} field is the ASCII representation of the octal
  3935. value of the simple sum of all bytes in the header record.  Each
  3936. 8-bit byte in the header is added to an unsigned integer,
  3937. initialized to zero, the precision of which shall be no less than
  3938. seventeen bits.  When calculating the checksum, the @code{chksum}
  3939. field is treated as if it were all blanks.
  3940.  
  3941. The @code{typeflag} field specifies the type of file archived.  If a
  3942. particular implementation does not recognize or permit the specified
  3943. type, the file will be extracted as if it were a regular file.  As
  3944. this action occurs, @code{tar} issues a warning to the standard
  3945. error.
  3946.  
  3947. @table @code
  3948. @item LF_NORMAL
  3949. @itemx LF_OLDNORMAL
  3950. These represent a regular file.  In order to be compatible with
  3951. older versions of @code{tar}, a @code{typeflag} value of
  3952. @code{LF_OLDNORMAL} should be silently recognized as a regular
  3953. file.  New archives should be created using @code{LF_NORMAL}.  Also,
  3954. for backward compatibility, @code{tar} treats a regular file whose
  3955. name ends with a slash as a directory.
  3956.  
  3957. @item LF_LINK
  3958. This represents a file linked to another file, of any type,
  3959. previously archived.  Such files are identified in Unix by each file
  3960. having the same device and inode number.  The linked-to
  3961. name is specified in the @code{linkname} field with a trailing null.
  3962.  
  3963. @item LF_SYMLINK
  3964. This represents a symbolic link to another file.  The linked-to
  3965. name is specified in the @code{linkname} field with a trailing null.
  3966.  
  3967. @item LF_CHR
  3968. @itemx LF_BLK
  3969. These represent character special files and block special files
  3970. respectively.  In this case the @code{devmajor} and @code{devminor}
  3971. fields will contain the major and minor device numbers
  3972. respectively.  Operating systems may map the device specifications
  3973. to their own local specification, or may ignore the entry.
  3974.  
  3975. @item LF_DIR
  3976. This specifies a directory or sub-directory.  The directory name in
  3977. the @code{name} field should end with a slash.  On systems where
  3978. disk allocation is performed on a directory basis the @code{size}
  3979. field will contain the maximum number of bytes (which may be rounded
  3980. to the nearest disk block allocation unit) which the directory may
  3981. hold.  A @code{size} field of zero indicates no such limiting.
  3982. Systems which do not support limiting in this manner should ignore
  3983. the @code{size} field.
  3984.  
  3985. @item LF_FIFO
  3986. This specifies a FIFO special file.  Note that the archiving of a
  3987. FIFO file archives the existence of this file and not its contents.
  3988.  
  3989. @item LF_CONTIG
  3990. This specifies a contiguous file, which is the same as a normal
  3991. file except that, in operating systems which support it,
  3992. all its space is allocated contiguously on the disk.  Operating
  3993. systems which do not allow contiguous allocation should silently treat
  3994. this type as a normal file.
  3995.  
  3996. @item 'A' @dots{}
  3997. @itemx 'Z'
  3998. These are reserved for custom implementations.  Some of these are
  3999. used in the GNU modified format, as described below.
  4000. @end table
  4001.  
  4002. Other values are reserved for specification in future revisions of
  4003. the P1003 standard, and should not be used by any @code{tar} program.
  4004.  
  4005. The @code{magic} field indicates that this archive was output in the
  4006. P1003 archive format.  If this field contains @code{TMAGIC}, the
  4007. @code{uname} and @code{gname} fields will contain the ASCII
  4008. representation of the owner and group of the file respectively.  If
  4009. found, the user and group ID represented by these names will be used
  4010. rather than the values within the @code{uid} and @code{gid} fields.
  4011.  
  4012. @section GNU Extensions to the Archive Format
  4013. The GNU format uses additional file types to describe new types of
  4014. files in an archive.  These are listed below.
  4015.  
  4016. @table @code
  4017. @item LF_DUMPDIR
  4018. @itemx 'D'
  4019. This represents a directory and a list of files created by the
  4020. @samp{-G} option.  The @code{size} field gives the total size of the
  4021. associated list of files.  Each filename is preceded by either a @code{'Y'}
  4022. (the file should be in this archive) or an @code{'N'} (The file is a
  4023. directory, or is not stored in the archive).  Each filename is
  4024. terminated by a null.  There is an additional null after the last
  4025. filename.
  4026.  
  4027. @item LF_MULTIVOL
  4028. @itemx 'M'
  4029. This represents a file continued from another volume of a
  4030. multi-volume archive created with the @samp{-M} option.  The original
  4031. type of the file is not given here.  The @code{size} field gives the
  4032. maximum size of this piece of the file (assuming the volume does not
  4033. end before the file is written out).  The @code{offset} field gives
  4034. the offset from the beginning of the file where this part of the
  4035. file begins.  Thus @code{size} plus @code{offset} should equal the
  4036. original size of the file.
  4037.  
  4038. @item LF_VOLHDR
  4039. @itemx 'V'
  4040. This file type is used to mark the volume header that was given with
  4041. the @samp{-V} option when the archive was created.  The @code{name}
  4042. field contains the @code{name} given after the @samp{-V} option.
  4043. The @code{size} field is zero.  Only the first file in each volume
  4044. of an archive should have this type.
  4045.  
  4046. @end table
  4047. EXTENSION:
  4048. OCCURENCES:
  4049. PROGRAMS:
  4050. REFERENCE:
  4051. SEE ALSO:
  4052. VALIDATION:
  4053. OFFSET              Count TYPE   Description
  4054. 0000h                 256 byte   Other header info ?
  4055. 0100h                   6 char   ID='ustar',0
  4056. EXTENSION:TAR
  4057. OCCURENCES:PC, Unix
  4058. PROGRAMS:TAR
  4059. --------G-TDDD------------------------------
  4060. This format is used by the Imagine rendering package. The names of the blocks
  4061. are unknown to me.
  4062. OFFSET              Count TYPE   Description
  4063. EXTENSION:IFF
  4064. OCCURENCES:Amiga,PC
  4065. PROGRAMS:Imagine package
  4066. REFERENCE:DDJ0794
  4067. SEE ALSO:IFF
  4068. --------I-TIFF------------------------------
  4069. The TIFF file format was designed jointly by Aldus and Microsoft with leading
  4070. scanner vendors to faciliate incorporating scanned images into publishing.
  4071. The described TIFF specification is TIFF 5.0. A TIFF file consists of several
  4072. different blocks which define the palette data or the LZW-compressed body
  4073. among other things. TIFF files can be in Motorola _or_ Intel byte order,
  4074. depending on the first word. If it is 'II', the byte order is in Intel order,
  4075. if it is 'MM', then you have Motorola byte ordering.
  4076.  
  4077. Each TIFF file begins with a image file header which points to one or more image
  4078. file directories, which contain the image data and image information.
  4079.  
  4080. The format of the image header :
  4081. OFFSET              Count TYPE   Description
  4082. 0000h                   2 char   ID='II', ID='MM'
  4083.                                  This is the identification, 'II' stands for
  4084.                                  Intel byte order, 'MM' for Motorola byte
  4085.                                  order. The following data must be interpreted
  4086.                                  accordingly !
  4087. 0002h                   1 word   TIFF "version number". This version number
  4088.                                  never changed and the value (42) was choosen
  4089.                                  for its deep philosophical value. In fact, if
  4090.                                  the version number ever changes, this means
  4091.                                  that radical changes to the TIFF format have
  4092.                                  been made, and a TIFF reader should give up
  4093.                                  immediately.
  4094.                                  You can consider this word to be a part of the
  4095.                                  header ID.
  4096. 0004h                   1 dword  Offset of first image directory in file form
  4097.                                  start of file.
  4098.                                  The first image directory must begin on an
  4099.                                  even byte boundary. The image directory may
  4100.                                  follow the image data it describes. The
  4101.                                  image directory is described below.
  4102.  
  4103. An organization  may wish to store information that is meaningful to only that
  4104. organization in a TIFF file. Tags numbered 32768 or higher are reserved for
  4105. that purpose. Upon request, the administrator will allocate and register a block
  4106. of private tags for an  organization.
  4107. Private enumerated values can be accommodated in a similar fashion.
  4108.  
  4109. The format of the image file directory (IFD) :
  4110. All entries are sorted in ascending order by the tag field.
  4111. OFFSET              Count TYPE   Description
  4112. 0000h                   1 word   Number of entries
  4113.                                  ="NUM"
  4114. 0002h               "NUM" rec    Field descriptor
  4115.                         1 word   Field tag, see below
  4116.                         1 word   Field type
  4117.                                    1 - byte
  4118.                                    2 - ASCII string, counted in length.
  4119.                                        Most often an ASCIIZ string, the
  4120.                                        trailing zero is counted with the
  4121.                                        data length.
  4122.                                    3 - word
  4123.                                    4 - dword / uword
  4124.                                    5 - rational (2 dwords, numerator and denominator)
  4125.                         1 dword  Length of the field in units of the data type.
  4126.                                  A single 16-bit word has the length 1.
  4127.                         1 dword  Data offset of the field. The data starts
  4128.                                  on a word boundary, thus the dword should
  4129.                                  be even. The data for the field may be
  4130.                                  anywhere in the file, even after the image
  4131.                                  data. If the data size is less or equal to
  4132.                                  4 bytes (determined by the field type and
  4133.                                  length), then this offset is not a offset
  4134.                                  but instead the data itself, to save space.
  4135.                                  If the data size is less than 4 bytes, the
  4136.                                  data is stored left-justified within the 4
  4137.                                  bytes of the offset field.
  4138. 0002h+
  4139.  "NUM"*12               1 dword  Offset of next IFD in file, 0 if none follow
  4140.  
  4141. If a certain field in the IFD does not exist, you have to presume the default
  4142. values. The different fields are :
  4143.           
  4144. --- BitsPerSample
  4145. Tag  = 258  (102)
  4146. Type = word
  4147. N    = SamplesPerPixel
  4148. Default = 1
  4149.           
  4150. Number of bits per sample. Note that this tag allows a different number of
  4151. bits per sample for each sample corresponding to a pixel. For example, RGB
  4152. color data could use a different number of bits per sample for each of the
  4153. three color planes.
  4154.           
  4155. --- ColorMap
  4156. Tag  = 320 (140)
  4157. Type = word
  4158. N    = 3 * (2**BitsPerSample)
  4159. No default.ColorMap must be included in all palette color images.
  4160.           
  4161. This tag defines a Red-Green-Blue color map for palette color images.
  4162. The palette color pixel value is used to index into all 3 subcurves.
  4163. The subcurves are stored sequentially. The Red entries come first, followed
  4164. by the Green entries, followed by the Blue entries.
  4165. The width  of each entry is 16 bits, as implied by the type of word.
  4166. 0 represents the minimum intensity, and 65535 represents the maximum intensity.
  4167.           
  4168. --- ColorResponseCurves
  4169. Tag  = 301 (12D)
  4170. Type = word
  4171. N    = 3 * (2**BitsPerSample)
  4172. Default: curves based on the NTSC recommended gamma of 2.2.
  4173.           
  4174. This tag defines three color response curves, one each for Red, Green and Blue
  4175. color information. The Red entries come first, followed by the Green entries,
  4176. followed by the Blue entries. The length of each subcurve is  2**BitsPerSample,
  4177. using the BitsPerSample value corresponding to the respective primary. The width
  4178. of each entry is 16 bits, as implied by the type of word.
  4179. The purpose of the color response curves is to refine the content of RGB color images.
  4180.  
  4181. --- Compression
  4182. Tag  = 259  (103)
  4183. Type = word
  4184. N    = 1
  4185. Default = 1.
  4186.           
  4187. 1 =  No compression, but pack data into bytes as tightly as possible, with no
  4188.      unused  bits except  at the end of a row. The bytes are stored as an array
  4189.      of bytes, for BitsPerSample <= 8,  word if BitsPerSample > 8 and <= 16, and
  4190.      dword if BitsPerSample > 16 and <= 32. The byte ordering of data >8 bits
  4191.      must be consistent with that specified in the TIFF file header (bytes 0
  4192.      and 1). Rows are required to  begin on byte boundaries.
  4193.           
  4194. 2 =  CCITT Group 3 1-Dimensional Modified Huffman run length encoding.
  4195.      See ALGRTHMS.txt BitsPerSample must be 1, since this type of compression
  4196.      is defined only for bilevel images (like FAX images...)
  4197.           
  4198. 3 =  Facsimile-compatible CCITT  Group 3, exactly as specified in
  4199.      "Standardization of  Group 3  facsimile  apparatus  for  document
  4200.      transmission,"   Recommendation T.4,  Volume VII, Fascicle VII.3,
  4201.      Terminal Equipment  and Protocols  for  Telematic  Services,  The
  4202.      International  Telegraph  and  Telephone  Consultative  Committee
  4203.      (CCITT), Geneva,  1985, pages  16 through  31.   Each strip  must
  4204.      begin on  a byte  boundary.   (But recall  that an image can be a
  4205.      single strip.)   Rows  that are  not the first row of a strip are
  4206.      not required  to begin on a byte boundary.  The data is stored as
  4207.      bytes,  not words - byte-reversal  is   not  allowed.    See  the
  4208.      Group3Options field for Group 3 options such as 1D vs 2D coding.
  4209.           
  4210. 4 =  Facsimile-compatible CCITT  Group 4, exactly as specified in
  4211.      "Facsimile Coding  Schemes and Coding Control Functions for Group
  4212.      4 Facsimile Apparatus,"  Recommendation T.6, Volume VII, Fascicle
  4213.      VII.3, Terminal  Equipment and  Protocols for Telematic Services,
  4214.      The International  Telegraph and Telephone Consultative Committee
  4215.      (CCITT), Geneva,  1985, pages  40 through  48.   Each strip  must
  4216.      begin on  a byte  boundary.  Rows that are not the first row of a
  4217.      strip are  not required to begin on a byte boundary.  The data is
  4218.      stored as  bytes, not  words.   See the  Group4Options field  for
  4219.      Group 4 options.
  4220.  
  4221. 5 =  LZW Compression, for grayscale, mapped color, and full color images.
  4222.      See ALGRTHMS.txt
  4223.           
  4224. 32773 =  PackBits compression, a simple byte oriented run length scheme for
  4225.          1-bit images.  See Appendix C.
  4226.           
  4227.           Data compression only applies to raster image data, as pointed to
  4228.           by StripOffsets.
  4229.           
  4230. --- GrayResponseCurve
  4231. Tag  = 291 (123)
  4232. Type = word
  4233. N    = 2**BitsPerSample
  4234.           
  4235. The purpose  of the  gray response curve and the gray units is to
  4236. provide more  exact photometric  interpretation  information  for
  4237. gray scale image data, in terms of optical density.
  4238.  
  4239. --- GrayResponseUnit
  4240. Tag  = 290 (122)
  4241. Type = word
  4242. N    = 1
  4243. For historical  reasons, the  default is 2.  However, for greater
  4244. accuracy, 3 is recommended.
  4245.  
  4246.   1 = Number represents tenths of a unit.
  4247.   2 = Number represents hundredths of a unit.
  4248.   3 = Number represents thousandths of a unit.
  4249.   4 = Number represents ten-thousandths of a unit.
  4250.   5 = Number represents hundred-thousandths of a unit.
  4251.           
  4252. --- ImageLength
  4253. Tag  = 257  (101)
  4254. Type = word or dword
  4255. N    = 1
  4256. No default.
  4257.           
  4258. The image's length (height) in pixels (Y:vertical). The number of rows
  4259. (sometimes described as "scan lines") in the image.
  4260.           
  4261. --- ImageWidth
  4262. Tag  = 256  (100)
  4263. Type = word or dword
  4264. N    = 1
  4265. No default.
  4266.           
  4267. The image's width, in pixels (X:horizontal). The number of columns in the image.
  4268.           
  4269. --- NewSubfileType
  4270. Tag =  254  (FE)
  4271. Type = dword
  4272. N = 1
  4273. Default is 0.
  4274.  
  4275. A general  indication of  the kind  of data  that is contained in
  4276. this subfile.   This  field is  made up of a set of 32 flag bits.
  4277. Unused bits are expected to be 0.  Bit 0 is the low-order bit.
  4278.           
  4279.           Currently defined values for the bitmap are:
  4280.             0 - Image is reduced of another TIFF image in this file
  4281.             1 - Image is a single page of a multi-page
  4282.             2 - Image is a transparency mask for another image in this file
  4283.           
  4284. --- PhotometricInterpretation
  4285. Tag  = 262  (106)
  4286. Type = word
  4287. N    = 1
  4288. No default.
  4289.           
  4290. 0 =  For bilevel  and grayscale  images:   0 is  imaged as white.
  4291.      2**BitsPerSample-1 is  imaged as  black.    If  GrayResponseCurve
  4292.      exists,  it   overrides  the   PhotometricInterpretation   value.
  4293.           
  4294. 1 =  For bilevel  and grayscale  images:   0 is  imaged as black.
  4295.      2**BitsPerSample-1  is  imaged  as  white.  If  GrayResponseCurve
  4296.      exists,  it   overrides  the   PhotometricInterpretation   value.
  4297.           
  4298. 2 =  RGB.  In the RGB model, a color is described as a combination
  4299.      of the  three primary  colors of  light (red, green, and blue) in
  4300.      particular concentrations.   For  each of  the three  samples,  0
  4301.      represents minimum intensity, and 2**BitsPerSample - 1 represents
  4302.      maximum intensity. For PlanarConfiguration = 1, the samples are stored in
  4303.      the indicated  order:   first Red,  then Green,  then Blue.   For
  4304.      PlanarConfiguration =  2, the  StripOffsets for the sample planes
  4305.      are stored  in the  indicated order:   first the Red sample plane
  4306.      StripOffsets, then  the Green  plane StripOffsets,  then the Blue
  4307.      plane StripOffsets.
  4308.           
  4309. 3 =  "Palette color."     In this  mode, a color is described with a
  4310.      single sample.   The  sample is  used as  an index into ColorMap.
  4311.      The sample  is used to index into each of the red, green and blue
  4312.      curve tables to retrieve an RGB triplet defining an actual color.
  4313.      When this  PhotometricInterpretation value  is  used,  the  color
  4314.      response curves  must also  be supplied.  SamplesPerPixel must be
  4315.      1.
  4316.           
  4317. 4 =  Transparency Mask.   This  means that  the image  is used to
  4318.      define an  irregularly shaped region of another image in the same
  4319.      TIFF  file.     SamplesPerPixel  and  BitsPerSample  must  be  1.
  4320.      PackBits compression  is recommended.    The  1-bits  define  the
  4321.      interior of  the region;  the 0-bits  define the  exterior of the
  4322.      region.  The Transparency Mask must have the same ImageLength and
  4323.      ImageWidth as the main image.
  4324.           
  4325. PlanarConfiguration
  4326. Tag  = 284  (11C)
  4327. Type = word
  4328. N    = 1
  4329. Default is 1.
  4330.           
  4331. 1 =  The sample values for each pixel are stored contiguously, so
  4332.      that there is a single image plane. See PhotometricInterpretation
  4333.      to determine the order of the samples within the  pixel data. So, for
  4334.      RGB data, the data is stored RGBRGBRGB...and so on.
  4335.           
  4336. 2 =  The samples  are stored  in separate  "sample planes."   The
  4337.      values in StripOffsets and StripByteCounts are then arranged as a
  4338.      2-dimensional array, with SamplesPerPixel rows and StripsPerImage
  4339.      columns.      (All of  the columns  for row  0 are  stored first,
  4340.      followed   by    the   columns    of   row   1,   and   so   on.)
  4341.      PhotometricInterpretation describes  the type  of  data  that  is
  4342.      stored in  each sample  plane.   For example,  RGB data is stored
  4343.      with the  Red samples  in one sample plane, the Green in another,
  4344.      and the Blue in another.
  4345.           
  4346.      If SamplesPerPixel  is 1,  PlanarConfiguration is irrelevant, and
  4347.      should not be included.
  4348.           
  4349. Predictor
  4350. Tag  = 317 (13D)
  4351. Type = word
  4352. N    = 1
  4353. Default is 1.
  4354.           
  4355. To be used when Compression=5 (LZW).
  4356.           
  4357. 1 = No prediction scheme used before coding.
  4358. 2 = Horizontal differencing. See Appendix I.
  4359.           
  4360. ResolutionUnit
  4361. Tag  = 296 (128)
  4362. Type = word
  4363. N    = 1
  4364. Default is 2.
  4365.           
  4366. To be used with XResolution and YResolution.
  4367.           
  4368. 1 =  No absolute  unit of  measurement.  Used for images that may
  4369.      have a  non-square  aspect  ratio,  but  no  meaningful  absolute
  4370.      dimensions.   The drawback  of ResolutionUnit=1 is that different
  4371.      applications will  import the  image at different sizes.  Even if
  4372.      the decision  is quite  arbitrary, it might be better to use dots
  4373.      per inch  or  dots  per  centimeter,  and  pick  XResolution  and
  4374.      YResolution such that the aspect ratio is correct and the maximum
  4375.      dimension of  the image is about four inches (the "four" is quite
  4376.      arbitrary.)
  4377. 2 = Inch.
  4378. 3 = Centimeter.
  4379.           
  4380. RowsPerStrip
  4381. Tag  = 278  (116)
  4382. Type = word or dword
  4383. N    = 1
  4384. Default is  2**32 -  1, which  is effectively infinity.  That is,
  4385. the entire  image is  one strip.   Recomended is a strip size of 8K.
  4386.  
  4387. The number  of rows  per strip.  The image data is organized into
  4388. strips for  fast access  to individual  rows  when  the  data  is
  4389. compressed - though this field is valid even  if the  data is not
  4390. compressed.
  4391.           
  4392. --- SamplesPerPixel
  4393. Tag  = 277  (115)
  4394. Type = word
  4395. N    = 1
  4396. Default = 1.
  4397.           
  4398. The number  of samples  per pixel.    SamplesPerPixel  is  1  for
  4399. bilevel, grayscale, and palette color images.  SamplesPerPixel is
  4400. 3 for RGB images.
  4401.           
  4402. --- StripByteCounts
  4403. Tag  = 279  (117)
  4404. Type = word or dword
  4405. N    = StripsPerImage for PlanarConfiguration equal to 1.
  4406.      = SamplesPerPixel  * StripsPerImage  for PlanarConfiguration equal to 2
  4407. No default.
  4408.           
  4409. For each strip, the number of bytes in that strip.  The existence
  4410. of  this   field  greatly   simplifies  the  chore  of  buffering
  4411. compressed data, if the strip size is reasonable.
  4412.           
  4413. --- StripOffsets
  4414. Tag  = 273  (111)
  4415. Type = word or dword
  4416. N    = StripsPerImage for PlanarConfiguration equal to 1.
  4417.      = SamplesPerPixel  * StripsPerImage  for PlanarConfiguration equal to 2
  4418. No default.
  4419.           
  4420. For each  strip, the  byte offset  of that  strip.  The offset is
  4421. specified with  respect to  the beginning of the TIFF file.  Note
  4422. that this  implies that  each strip has a location independent of
  4423. the locations  of other  strips.   This feature may be useful for
  4424. editing applications.  This field is the only way for a reader to
  4425. find the image data, and hence must exist.
  4426.           
  4427. --- XResolution
  4428. Tag  = 282  (11A)
  4429. Type = RATIONAL
  4430. N    = 1
  4431. No default.
  4432.           
  4433. The number of pixels per ResolutionUnit in the X direction, i.e.,
  4434. in the  ImageWidth direction.
  4435.           
  4436.           
  4437. --- YResolution
  4438. Tag  = 283  (11B)
  4439. Type = RATIONAL
  4440. N    = 1
  4441. No default.
  4442.           
  4443. The number of pixels per ResolutionUnit in the Y direction, i.e.,
  4444. in the ImageLength direction.
  4445.           
  4446. --- Artist
  4447. Tag  = 315  (13B)
  4448. Type = ASCII
  4449.           
  4450. Person who created the image. Copyright notice.
  4451.           
  4452. --- DateTime
  4453. Tag  = 306  (132)
  4454. Type = ASCII
  4455. N    = 20
  4456.           
  4457. Date and time of image creation. Uses the format  "YYYY:MM:DD HH:MM:SS", with
  4458. hours on a 24-hour clock, and one space character between the date and the time.
  4459. The length of the string, including the null, is 20 bytes.
  4460.           
  4461. --- HostComputer
  4462. Tag  = 316  (13C)
  4463. Type = ASCII
  4464.           
  4465. "ENIAC", or whatever.
  4466.           
  4467. --- ImageDescription
  4468. Tag  = 270 (10E)
  4469. Type = ASCII
  4470.           
  4471. For example,  a user  may wish  to attach a comment such as "1988 company
  4472. picnic" to an image.
  4473.           
  4474. --- Make
  4475. Tag  = 271  (10F)
  4476. Type = ASCII
  4477.           
  4478. Manufacturer of the scanner, video digitizer, or whatever.
  4479.           
  4480. --- Model
  4481. Tag  = 272  (110)
  4482. Type = ASCII
  4483.           
  4484. The model name/number of the scanner, video digitizer, or whatever.
  4485. This tag is intended for user information only so format is arbitrary.
  4486.           
  4487. --- Software
  4488. Tag  = 305  (131)
  4489. Type = ASCII
  4490.           
  4491. Name and  release number of the software package that created the image.
  4492. User information only.
  4493.           
  4494. --- Group3Options
  4495. Tag  = 292  (124)
  4496. Type = dword
  4497. N    = 1
  4498.           
  4499. Those options are for fax-images stored in TIFF format.
  4500. This  field is  made up  of a set of 32 flag bits. Unused bits are expected
  4501. to be 0. It is probably not safe to try to read the file if any bit of this
  4502. field is set that you don't know the meaning of.
  4503.  
  4504.  Bit map :
  4505.  0 - 2-dimensional coding used.
  4506.  1 - Image is uncompressed
  4507.  2 - Fill bits have been added before EOL codes, so that EOL always ends on a
  4508.      byte boundary.
  4509.           
  4510. --- Group4Options
  4511. Tag  =  293  (125)
  4512. Type = dword
  4513. N    = 1
  4514.           
  4515. This field is made up of a set of 32 flag bits and is used for the images
  4516. with fax group 4 compression. Unused bits are expected to be 0. It is
  4517. probably not safe to try to read the file if any bit of this field is set
  4518. that you don't know the meaning of. Gray scale and color coding schemes are
  4519. under study, and will be added when finalized.
  4520.           
  4521. For 2-D coding, each strip is encoded as if it were a separate image. In
  4522. particular, each strip begins on a byte boundary; and the coding  for the
  4523. first row of a strip is encoded independently of the previous row, using
  4524. horizontal codes, as if the previous row is entirely white. Each strip ends
  4525. with the 24-bit end-of-facsimile block (EOFB).
  4526.           
  4527. Bit map :
  4528.          0 - reserved (unused)
  4529.          1 - uncompressed mode is used
  4530.       2-31 - reserved
  4531.           
  4532. --- DocumentName
  4533. Tag  = 269  (10D)
  4534. Type = ASCII
  4535.  
  4536. The name of the document from which this image was scanned.
  4537.  
  4538. --- PageName
  4539. Tag  = 285  (11D)
  4540. Type = ASCII
  4541.  
  4542. The name of the page from which this image was scanned.
  4543.           
  4544. --- PageNumber
  4545. Tag  = 297  (129)
  4546. Type = word
  4547. N    = 2
  4548.           
  4549. This tag is used to specify page numbers of a multiple page (e.g. facsimile)
  4550. document. Two word values are specified. The first value is the page number;
  4551. the second value is the total number of pages in the document. Note that pages
  4552. need not appear in numerical order. The first page is 0 (zero).
  4553.           
  4554. --- XPosition
  4555. Tag  = 286  (11E)
  4556. Type = RATIONAL
  4557.           
  4558. The X offset of the left side of the image, with respect to the left side of the
  4559. page, in ResolutionUnits.
  4560.           
  4561. --- YPosition
  4562. Tag  = 287  (11F)
  4563. Type = RATIONAL
  4564.           
  4565. The Y  offset of the top of the image, with respect to the top of the page, in
  4566. ResolutionUnits.  In the TIFF coordinate scheme, the positive Y direction is down,
  4567. so that YPosition is always positive.
  4568.           
  4569. --- White Point
  4570. Tag  = 318 (13E)
  4571. Type = RATIONAL
  4572. N    = 2
  4573. Default is the SMPTE white point, D65:  x = 0.313, y = 0.329.
  4574.           
  4575. The white  point of the image.  Note that this value is described using the 1931
  4576. CIE xyY chromaticity diagram and only the chromaticity is specified. The
  4577. luminance component is arbitrary and not  specified. This can correspond to the
  4578. white point of a monitor that the image was painted  on, the filter set/light
  4579. source combination of a scanner, or to the white point of the illumination model
  4580. of a rendering package. The ordering is x, y.
  4581.           
  4582.           
  4583. --- PrimaryChromaticities
  4584. Tag  = 319 (13F)
  4585. Type = RATIONAL
  4586. N    = 6
  4587. Default is the SMPTE primary color chromaticities:
  4588.           
  4589.                Red: x = 0.635 y = 0.340
  4590.                Green:    x = 0.305 y = 0.595
  4591.                Blue:     x = 0.155 y = 0.070
  4592.  
  4593. The primary  color chromaticities. Note that these values are described using
  4594. the 1931 CIE xyY chromaticity diagram and only the chromaticities  are
  4595. specified.For paint images, these represent the chromaticities of the monitor
  4596. and for scanned images they are derived from the filter set/light source
  4597. combination of a scanner.
  4598. The ordering is red x, red y, green x, green y, blue x, blue y.
  4599.           
  4600.   ** The following fields are not recommended except perhaps for local use **
  4601.  
  4602. They have either been superseded by other fields, have been found to have serious
  4603. drawbacks, or are simply not as useful as once thought.
  4604.           
  4605. CellLength
  4606. Tag  = 265  (109)
  4607. Type = word
  4608. N    = 1
  4609.           
  4610. The length, in 1-bit samples, of the dithering/halftoning matrix. Assumes that
  4611. Threshholding = 2.
  4612.           
  4613. This field, plus CellWidth and Threshholding,  are problematic because they cannot
  4614. safely be used to reverse-engineer grayscale image data out of dithered/halftoned
  4615. black-and-white data, which is their only plausible purpose. The only "right" way
  4616. to do it is to not bother with anything like these fields, and instead write some
  4617. sophisticated pattern-matching software that can handle screen angles that are not
  4618. multiples of 45 degrees, and other such challenging dithered/halftoned data.
  4619.           
  4620. FillOrder
  4621. Tag  = 266  (10A)
  4622. Type = word
  4623. N    = 1
  4624.           
  4625. The order of data values within a byte.
  4626. 1 = most significant bits of the byte are filled first.
  4627. 2 = least significant bits are filled first. Since little interest has been
  4628.     expressed in least-significant fill order to date, and since it is easy
  4629.     and inexpensive for writers to reverse bit order (use a 256-byte lookup
  4630.     table), FillOrder=2 is for private (non-interchange) use only.
  4631.           
  4632. FreeByteCounts
  4633. Tag  = 289  (121)
  4634. Type = dword
  4635.           
  4636. For each "free block" in the file, the number of bytes in the block.
  4637.           
  4638. FreeOffsets
  4639. Tag  = 288  (120)
  4640. Type = dword
  4641.           
  4642. For each "free block"  in the file, its byte offset.
  4643.           
  4644. MaxSampleValue
  4645. Tag  = 281  (119)
  4646. Type = word
  4647. N    = SamplesPerPixel
  4648. Default is 2**(BitsPerSample) - 1.
  4649.           
  4650. The maximum used sample value. Statistical use only.
  4651.           
  4652. MinSampleValue
  4653. Tag  = 280  (118)
  4654. Type = word
  4655. N    = SamplesPerPixel
  4656. Default is 0.
  4657.           
  4658. The minimum used sample value. Statistical use only.
  4659.           
  4660. SubfileType
  4661. Tag  = 255  (FF)
  4662. Type = word
  4663. N    = 1
  4664.           
  4665. A general indication of the kind of data that is contained in this subfile.
  4666. Currently defined values are:
  4667.           
  4668. 1 =  full resolution image data - ImageWidth, ImageLength, and StripOffsets are
  4669.      required fields
  4670. 2 =  reduced resolution image data - ImageWidth, ImageLength, and StripOffsets are
  4671.      required fields. It is further assumed that a reduced resolution image is a
  4672.      reduced version of the entire extent of the corresponding full resolution
  4673.      data.
  4674. 3 =  single page of a multi-page image (see the PageNumber tag description).
  4675.           
  4676. Continued use of this field is not recommended. Writers should instead use the
  4677. new and more general NewSubfileType field.
  4678.           
  4679. Orientation
  4680. Tag  = 274 (112)
  4681. Type = word
  4682. N    = 1
  4683. Default is 1.
  4684.           
  4685. 1 =  The 0th  row represents the visual top of the image, and the 0th column
  4686.      represents the visual left hand side.
  4687. 2 =  The 0th  row represents the visual top of the image, and the 0th column
  4688.      represents the visual right hand side.
  4689. 3 =  The 0th  row represents  the visual bottom of the image, and the 0th column
  4690.      represents the visual right hand side.
  4691. 4 =  The 0th  row represents  the visual bottom of the image, and the 0th column
  4692.      represents the visual left hand side.
  4693. 5 =  The 0th row represents the visual left hand side of the image, and the 0th
  4694.      column represents the visual top.
  4695. 6 =  The 0th row represents the visual right hand side of the image, and the 0th
  4696.      column represents the visual top.
  4697. 7 =  The 0th row represents the visual right hand side of the image, and the 0th
  4698.      column represents the visual bottom.
  4699. 8 =  The 0th row represents the visual left hand side of the image, and the 0th
  4700.      column represents the visual bottom.
  4701.           
  4702. It is extremely costly for most readers to perform image rotation "on the  fly",
  4703.  i.e., when importing and printing; and users of most desktop publishing
  4704. applications do not expect a file imported by the application to be altered
  4705. permanently in any way.
  4706.           
  4707. Threshholding
  4708. Tag  = 263  (107)
  4709. Type = word
  4710. N    = 1
  4711.           
  4712. 1 =  a bilevel "line art"  scan. BitsPerSample must be 1.
  4713. 2 =  a "dithered" scan, usually of continuous tone data such as photographs.
  4714.      BitsPerSample must be 1.
  4715. 3 =  Error Diffused.
  4716.           
  4717. ColorImageType
  4718. Tag  = 318 (13E)
  4719. Type = word
  4720. N    = 1
  4721. Default is 1.
  4722.           
  4723. Gives TIFF color image readers a better idea of what kind of color image it is.  There will be borderline cases.
  4724.           
  4725. 1 = Continuous tone, natural image.
  4726. 2 = Synthetic image, using a greatly restricted range of colors.
  4727.     Such images are produced by most color paint programs. See ColorList for
  4728.     a list of colors used in this image.
  4729.           
  4730. ColorList
  4731. Tag  = 319 (13F)
  4732. Type = BYTE or word
  4733. N    = the number of colors that are used in this image, times SamplesPerPixel
  4734.           
  4735. A list of colors that are used in this image. Use of this field is only
  4736. practical for images containing a greatly restricted (usually less than or equal
  4737. to 256) range of colors. ColorImageType should be 2. See ColorImageType.
  4738.           
  4739. The list is organized as an array of RGB triplets, with no pad. The RGB triplets
  4740. are not guaranteed to be in any particular order. Note that the red, green, and
  4741. blue components can either be a BYTE or a word in length. BYTE should be
  4742. sufficient for most applications.
  4743.           
  4744. EXTENSION:TIF,TIFF
  4745. OCCURENCES:PC,MAC,UNIX
  4746. PROGRAMS:Aldus Pagemaker, Paintbrush
  4747. REFERENCE:
  4748. SEE ALSO:
  4749. VALIDATION:
  4750. --------S-TXW-------------------------------
  4751. The TXW files are disk images used by the Yamaha TX-16W.
  4752. Further information wanted.
  4753. EXTENSION:TXW
  4754. --------S-UWF-G-----------------------------
  4755. The UWF files are sample files used by the UltraTracker.
  4756. Further information wanted.
  4757. OFFSET              Count TYPE   Description
  4758. 0000h                  32 char   ASCIIZ sample name
  4759. 0020h                   1 char   ID=1Ah
  4760. 0021h                   1 char   ID=10h
  4761. 0022h                   5 char   ID='MUWFB'
  4762. 0027h                   1 char   ID=0
  4763. 0028h                   6 char   Length of sample as ASCII long integer
  4764. 002Eh                   1 word   Length of sample
  4765. ?????
  4766. EXTENSION:UWF
  4767. SEE ALSO:ULT
  4768. --------M-ULT-------------------------------
  4769. The ULT files are modules used by the UltraTracker. UltraTracker is a
  4770. module editor for the Gravis UltraSound soundcard. The version of the
  4771. file format used now is 6.
  4772.  
  4773. OFFSET              Count TYPE   Description
  4774. 0000h                  11 char   ID="MAS_UTrack_V"
  4775. 000Ch                   4 char   Version number in 4-digit ASCII :
  4776.                                  1 - ULT version 1.0
  4777.                                  2 - ULT version 2.0
  4778.                                  3 - ULT version 2.1
  4779.                                  4 - ULT version 2.2
  4780. 000Fh                  32 char   Song title
  4781. 002Fh                   1 byte   Number of song text lines
  4782.                                  ="NTL"
  4783. 0030h            "NTL"*32 char   Song text
  4784. 0030h+"NTL"*32          1 byte   Number of samples
  4785.                                  ="NOS"
  4786. 0031h+"NTL"*32      "NOS" rec    Sample structure
  4787. ************
  4788. IALL    I 49+NTL*32+NOS*SSIbyte[256]      IPattern Sequence Table             I
  4789. IALL    I305+NTL*32+NOS*SSIbyte           INumber of tracks (NOT) Base 0      I
  4790. I       I306+NTL*32+NOS*SSIbyte           INumber of patterns (NOP) Base 0    I
  4791. I2.1-2.2I307+NTL*32+NOS*SSIbyte[NOT]      IPAN-position table                 I
  4792. I       I                 I               I[0 left]-[F right]                 I
  4793. IALL    I307+NTL*32+NOS*SSI               IEvent structure (see event struct) I
  4794. I       I+NOT             Ivaries         I                                   I
  4795. ├-------+-----------------+---------------+-----------------------------------┤
  4796. IThe remainder of the file is the raw sample data. (signed)                   I
  4797. └-----------------------------------------------------------------------------┘
  4798.  
  4799. ┌-----------------------------------------------------------------------------┐
  4800. ISample Structure (length: ULT 1.0 - ULT 2.1 = 64bytes I ULT 2.2 = 66bytes)   I
  4801. ├-----------------------------------------------------------------------------┤
  4802. ISamplename : 32 bytes Sample name                                            I
  4803. IDosName    : 12 bytes when you load a sample into UT,                        I
  4804. I                      it records the file name here                          I
  4805. ILoopStart  : dbl word loop start point                                       I
  4806. ILoopEnd    : dbl word loop end point                                         I
  4807. ISizeStart  : dbl word see below                                              I
  4808. ISizeEnd    : dbl word see below                                              I
  4809. Ivolume     : byte     UT uses a logarithmic volume setting, ranging          I
  4810. I                      from 0-255 (ULT 1.0)                                   I
  4811. I                      from ULT 2.0: uses linear Volume ranging from 0-255    I
  4812. IBidi Loop  : byte     see below                                              I
  4813. IFineTune   : word     Fine tune setting, uses full word value                I
  4814. I                      Linear Finetune                                        I
  4815. ├---Additional-in-ULT-2.2-----------------------------------------------------┤
  4816. IC2-Freqency: word     This is the frequency, UT uses to play a middle C,     I
  4817. I                      all other notes are calculated relatively to this      I
  4818. I                      value.                                                 I
  4819. └-----------------------------------------------------------------------------┘
  4820.  
  4821. 8 Bit Samples:
  4822. --------------
  4823. SizeStart:
  4824. The SizeStart is the starting offset of the sample. 
  4825. This seems to tell UT how to load the sample into the Gus's onboard memory. 
  4826. All the files I have worked with start with a value of 32 for the first sample, 
  4827. and the previous SizeEnd value for all sample after that. (See Example below)
  4828. If the previous sample was 16bit, then SizeStart = (Last SizeEnd * 2)
  4829. SizeEnd : 
  4830. Like the SizeStart, SizeEnd seems to tell UT where to load the sample into the 
  4831. Gus's onboard memory. SizeEnd equal SizeStart + the length of the sample.
  4832.  
  4833. Example:
  4834. --------
  4835. If a UT file had 3 samples, 1st 12000 bytes, 2nd 5600  bytes, 3rd 8000 byte. 
  4836. The SizeStart and SizeEnd would look like this:
  4837.  
  4838. Sample        SizeStart         SizeEnd
  4839. 1st            32                12032
  4840. 2nd            12032             17632
  4841. 3rd            17632             25632
  4842.  
  4843. ***Note***
  4844. Samples may NOT cross 256k boundaries. If a sample is too large to fit into the
  4845. remaining space, its Sizestart will equal the start of the next 256k boundary.
  4846. UT does keep track of the free space at the top of the 256k boundaries, and
  4847. will load a sample in there if it will fit.
  4848. Example : EndSize = 252144
  4849. If the next sample was 12000 bytes, its SizeStart would be 262144, not 252144.
  4850. Note that this leaves 10000 bytes unused. If any of the following sample could
  4851. fit between 252144 and 262144, its Sizestart would be 252144.
  4852. Say that 2 samples after the 12000 byte sample we had a sample that was only
  4853. 5000 bytes long. Its SizeStart would be 252144 and its SizeEnd would be 257144.
  4854. This also applies to 16 Bit Samples.
  4855.  
  4856. 16 Bit Samples:
  4857. ---------------
  4858. 16 bit samples are handled a little different then 8 bit samples.
  4859. The SizeStart variable is calculated by dividing offset (last SizeEnd)
  4860. by 2. The SizeEnd variable equals SizeStart + (SampleLength / 2).
  4861. If the first sample is 16bit, then SizeStart = 16.
  4862. Example :
  4863.           sample1 = 8bit, 1000 bytes
  4864.           sample2 = 16bit, 5000 bytes
  4865.  
  4866.           sample1 SizeStart = 32
  4867.                   SizeEnd   = 1032 (32 + 1000)
  4868.  
  4869.           sample2 SizeStart = 516 (offset (1032) / 2)
  4870.                   SizeEnd   = 3016 (516 + (5000/2))
  4871.  
  4872. ***Note***
  4873. If a 16bit sample is loaded into banks 2,3, or 4
  4874. the SizeStart variable will be
  4875. (offset / 2) + 262144 (bank 2)
  4876. (offset / 2) + 524288 (bank 3)
  4877. (offset / 2) + 786432 (bank 4)
  4878. The SizeEnd variable will be
  4879. SizeStart + (SampleLength / 2) + 262144 (bank 2)
  4880. SizeStart + (SampleLength / 2) + 524288 (bank 3)
  4881. SizeStart + (SampleLength / 2) + 786432 (bank 4)
  4882.  
  4883. BiDi Loop : (Bidirectional Loop)
  4884. --------------------------------
  4885. UT takes advantage of the Gus's ability to loop a sample in several different
  4886. ways. By setting the Bidi Loop, the sample can be played forward or backwards,
  4887. looped or not looped. The Bidi variable also tracks the sample
  4888. resolution (8 or 16 bit).
  4889.  
  4890. The following table shows the possible values of the Bidi Loop.
  4891. Bidi = 0  : No looping, forward playback,  8bit sample
  4892. Bidi = 4  : No Looping, forward playback, 16bit sample
  4893. Bidi = 8  : Loop Sample, forward playback, 8bit sample
  4894. Bidi = 12 : Loop Sample, forward playback, 16bit sample
  4895. Bidi = 24 : Loop Sample, reverse playback 8bit sample
  4896. Bidi = 28 : Loop Sample, reverse playback, 16bit sample
  4897.  
  4898. ┌-----------------------------------------------------------------------------┐
  4899. IEvent Structure                                                              I
  4900. ├-----------------------------------------------------------------------------┤
  4901. INote                : byte (See note table below)                            I
  4902. ISampleNumber        : byte (Sample Number)                                   I
  4903. IEffect1             : nib (Effect1)                                          I
  4904. IEffect2             : nib (Effect2)                                          I
  4905. IEffectVar           : word (Effect variables)                                I
  4906. I                                                                             I
  4907. I The High order byte of EffectVar is the Effect variable for Effect1.        I
  4908. I The Low order byte of EffectVar is the Effect variable for Effect2.         I
  4909. I***(Note)***                                                                 I
  4910. I UT uses a form of compression on repetitive events. Say we read in the firstI
  4911. I byte, if it = $FC then this signifies a repeat block. The next byte is the  I
  4912. I repeat count. followed by the event structure to repeat.                    I
  4913. I If the first byte read does NOT = $FC then this is the note of the event.   I
  4914. I So repeat blocks will be 7 bytes long : RepFlag      : byte ($FC)           I
  4915. I                                        RepCount     : byte                  I
  4916. I                                        note         : byte                  I
  4917. I                                        samplenumber : byte                  I
  4918. I                                        effect1      : nib                   I
  4919. I                                        effect2      : nib                   I
  4920. I                                        effectVar    : word                  I
  4921. I                                                                             I
  4922. I ! Repeat blocks do NOT bridge patterns. !                                   I
  4923. ├-----------------------------------------------------------------------------┤
  4924. INote Table                                                                   I
  4925. ├-----------------------------------------------------------------------------┤
  4926. Inote value of 0 = pause                                                      I
  4927. IC-0 to B-0    1 to 12                                                        I
  4928. IC-3 to B-3    37 to 48                                                       I
  4929. IC-4 to B-4    49 to 60                                                       I
  4930. IC-5 to B-5    61 to 72                                                       I
  4931. IC-6 to B-6    73 to 84                                                       I
  4932. IC-7 to B-7    85 to 96                                                       I
  4933. └-----------------------------------------------------------------------------┘
  4934.  
  4935. That should about cover it. If you have any questions , feel free
  4936. to e-mail me at
  4937. freejack@shell.portal.com
  4938.  
  4939. I can also be contacted on The UltraSound Connection   (813) 787-8644 
  4940. The UltraSound Connection is a BBS dedicated to the Gravis Ultrasound Card.
  4941.  
  4942. Also I'm the author of Ripper and Gvoc. If anyone has any questions or 
  4943. problems, please contact me.
  4944. EXTENSION:ULT
  4945. SEE ALSO:UWF
  4946. --------S-WAVE------------------------------
  4947. The Windows .WAV files are RIFF format files. Some programs expect the fmt block
  4948. right behind the RIFF header itself, so your programs should write out this
  4949. block as the first block in the RIFF file.
  4950.  
  4951. The subblocks for the wave files are
  4952. RiffBLOCK [data]
  4953. This block contains the raw sample data. The necessary information
  4954. for playback is contained in the [fmt ] block.
  4955.  
  4956. RiffBLOCK [fmt ]
  4957. This block contains the data necessary for playback of the sound
  4958. files. Note the blank after fmt !
  4959. OFFSET              Count TYPE   Description
  4960. 0000h                   1 word   Format tag
  4961.                                    1 = PCM (raw sample data)
  4962.                                    2 etc. for APCDM, a-Law, u-Law ...
  4963. 0002h                   1 word   Channels (1=mono,2=stereo,...)
  4964. 0004h                   1 dword  Sampling rate
  4965. 0008h                   1 dword  Average bytes per second (=sampling rate*channels)
  4966. 000Ch                   1 word   Block alignment / reserved ??
  4967. 000Eh                   1 word   Bits per sample (8/12/16-bit samples)
  4968.  
  4969. RiffBLOCK [loop]
  4970. This block is for looped samples. Very few programs support this block,
  4971. but if your program changes the wave file, it should preserve any unknown
  4972. blocks.
  4973. OFFSET              Count TYPE   Description
  4974. 0000h                   1 dword  Start of sample loop
  4975. 0004h                   1 dword  End of sample loop
  4976.  
  4977. EXTENSION:WAV
  4978. SEE ALSO:RIFF,VOC
  4979. OCCURENCES:PC
  4980. PROGRAMS:Windows,GUSWAV,WAV2VOC
  4981. VALIDATION:NONE
  4982. --------W-WKS-------------------------------
  4983. The WKS files are worksheets/spreadsheets used by the Lotus 1-2-3 and Lotus
  4984. Symphony packages. More information has yet to be found since this information
  4985. origins from a magic file.
  4986. OFFSET              Count TYPE   Description
  4987. 0000h                   5 byte   ID=0,0,2,0,4
  4988. 0005h                   1 byte   WKS type :
  4989.                                      4 - Lotus 1-2-3 v1.A WKS
  4990.                                      5 - Symphony 1.0 WKS
  4991.                                  other - ?WK1 file? (Lotus 2.01+, Symphony 1.1+)
  4992. EXTENSION:WKS
  4993. OCCURENCES:PC
  4994. PROGRAMS:Lotus 1-2-3,Lotus Symphony
  4995. SEE ALSO:WKS
  4996. --------T-WORD-G----------------------------
  4997. The Microsoft Word programs store their documents in files. The info comes
  4998. from a magic file and my own (not working) sources, so it is very unreliable
  4999. except for identification.
  5000. OFFSET              Count TYPE   Description
  5001. 0000h                   1 dword  ID=31BE00
  5002. 0002h                   1 byte   Document type :
  5003.                                  0 - MS Word text
  5004.                                  1 - MS Text building block
  5005.                                  2 - Printer description file(maybe wrong topic)
  5006. 0003h                   1 byte   ID=00
  5007. 0004h                   1 word   ID=AB00h
  5008.                                  ToolID, different for the different versions ?
  5009. 0006h                   6 word   reserved(0)
  5010. 0008h                   1 dword  Textbytes??? Whatever
  5011. 000Ch                   1 word   Paragraph information
  5012. 000Eh                   1 word   Foot note table
  5013. 0010h                   1 word   Section property
  5014. 0012h                   1 word   Section table
  5015. 0014h                   1 word   Page table
  5016. 0016h                  64 char   Style sheet path
  5017. 0056h                   1 word   Windows Write page count
  5018.                                  Can be used to identify Windows Write files,
  5019.                                  because it is 0 for MS Word and nonzero for
  5020.                                  Windows Write documents.
  5021. 0058h                   8 char   Printer name
  5022.                                  Used under MS Word / WinWord only
  5023. 0060h                   1 word   MS Word page count
  5024. 0062h                   8 byte   Document properties
  5025. 006Ah                   1 byte   Word version this file was made by
  5026. 006Bh                   1 bool   Autosave flag
  5027. 006Ch                   1 word   Word 5 page table
  5028. 006Eh                   1 word   Mac bkmk (whatever)
  5029. 0070h                   1 word   ?Offset of file name for autosave?
  5030. 0072h                   1 word   Running head table
  5031. 0074h                   1 word   Code page used making this document
  5032.  
  5033. EXTENSION:DOC
  5034. OCCURENCES:PC
  5035. PROGRAMS:MS Word,Windows Write, WinWord
  5036. SEE ALSO:
  5037. VALIDATION:
  5038. --------T-WORDPERFERCT FILES----------------
  5039. The WordPerfect files all have a common header - even tough I don't know
  5040. anything else about them.
  5041. OFFSET              Count TYPE   Description
  5042. 0000h                   4 char   ID=255,"WPC"
  5043. 0004h                   4 byte   unknown
  5044. 0008h                   1 byte   ID=1
  5045. 0009h                   1 byte   Filetype (see table 0003)
  5046.  
  5047. (Table 0003)
  5048. File types of WordPerfect files
  5049.   01h - macro file
  5050.   02h - WordPerfect help file
  5051.   03h - keyboard definition file
  5052.   0Ah - document file
  5053.   0Bh - dictionary file
  5054.   0Ch - thesaurus file
  5055.   0Dh - block
  5056.   0Eh - rectangular block
  5057.   0Fh - column block
  5058.   10h - printer resource file (PRS)
  5059.   11h - setup file
  5060.   12h - prefix information file
  5061.   13h - printer resource file (ALL)
  5062.   14h - display resource file (DRS)
  5063.   15h - overlay file (WP.FIL)
  5064.   16h - graphics file (WPG)
  5065.   17h - hyphenation code module
  5066.   18h - hyphenation data module
  5067.   19h - macro resource file (MRS)
  5068.   1Ah - graphics driver (WPD)
  5069.   1Bh - hyphenation lex module
  5070. EXTENSION:various
  5071. OCCURENCES:PC
  5072. --------W-WQ1-------------------------------
  5073. Similar to the WKS spreadsheet files, the Quattro Pro spreadsheet files exist,
  5074. and their header is somewhat similar. Info again from a magic file which
  5075. makes only identification possible.
  5076. OFFSET              Count TYPE   Description
  5077. 0000h                   1 dword  ID=00000200h
  5078. 0004h                   1 char   ID='Q'
  5079. EXTENSION:WQ1
  5080. OCCURENCES:PC
  5081. PROGRAMS:Borland Quattro Pro
  5082. REFERENCE:
  5083. SEE ALSO:WKS
  5084. VALIDATION:
  5085. --------M-XM--------------------------------
  5086. The .XM files (Extended Module) are multichannel MOD files created by Triton's
  5087. FastTracker ][. They feature up to 32 channels and different effects. FT 2 is
  5088. a shareware program. After the initial .XM header follows the pattern data,
  5089. after the patterns follow the instruments.
  5090.  
  5091. OFFSET              Count TYPE   Description
  5092. 0000h                  17 char   ID="Extended module: "
  5093. 0011h                  20 char   Module name, padded with zeroes
  5094. 0025h                   1 char   ID=01Ah
  5095. 0026h                  20 char   Tracker name
  5096. 003Ah                   1 word   Tracker revision number, hi-byte is major version
  5097. 003Ch                   1 dword  Header size
  5098. 0040h                   1 word   Song length in patterns
  5099. 0042h                   1 word   Restart position
  5100. 0044h                   1 word   Number of channels
  5101. 0046h                   1 word   Number of patterns (< 256)
  5102.                                  ="PAT"
  5103. 0048h                   1 word   Number of instruments (<128)
  5104. 004Ah                   1 word   Flags :
  5105.                                  0 - Linear frequency table / Amiga freq. table
  5106. 004Ch                   1 word   Default tempo
  5107. 004Eh                   1 word   Default BPM
  5108. 0050h                 256 byte   Pattern order table
  5109.  
  5110. --- Pattern header
  5111. The patterns are stored as ordinary MOD patterns, except that each note is
  5112. stored as 5 bytes:
  5113.  
  5114.       ?      1   (byte) Note (0-71, 0 = C-0)
  5115.      +1      1   (byte) Instrument (0-128)
  5116.      +2      1   (byte) Volume column byte (see below)
  5117.      +3      1   (byte) Effect type
  5118.      +4      1   (byte) Effect parameter
  5119.  
  5120. A simle packing scheme is also adopted, so that the patterns do not become TOO
  5121. large: Since the MSB in the note value is never used, it is used for the
  5122. compression.If the bit is set, then the other bits are interpreted as follows:
  5123.  
  5124.       bit 0 set: Note byte ollows
  5125.           1 set: Instrument byte follows
  5126.           2 set: Volume column byte follows
  5127.           3 set: Effect byte follows
  5128.           4 set: Effect data byte follows
  5129.  
  5130. OFFSET              Count TYPE   Description
  5131. 0000h                   1 dword  Length of pattern block/header ??
  5132. 0004h                   1 byte   Pattern pack type
  5133. 0005h                   1 word   Number of rows in pattern (1..256)
  5134. 0007h                   1 word   Size of pattern data
  5135.                                  ="PSZ"
  5136.                     "PSZ" byte   Pattern data
  5137.  
  5138. --- Instrument header
  5139. Each instrument has one or more sample headers following it.
  5140. OFFSET              Count TYPE   Description
  5141. 0000h                   1 dword  Instrument block/header size
  5142. 0004h                  22 char   ASCII Instrument name, 0 padded ?
  5143. 001Ah                   1 byte   Instrument type (always 0)
  5144. 001Bh                   1 word   Number of samples in instrument
  5145. 001Dh                   1 dword  Sample header size
  5146. 0021h                  96 byte   Sample numbers for all notes
  5147. 0081h                  48 byte   Points of volume envelope
  5148. 00C1h                  48 byte   Points of panning envelope
  5149. 0101h                   1 byte   Number of volume points
  5150. 0102h                   1 byte   Number of panning points
  5151. 0103h                   1 byte   Volume sustain point
  5152. 0104h                   1 byte   Volume loop start point
  5153. 0105h                   1 byte   Volume loop end point
  5154. 0106h                   1 byte   Panning sustain point
  5155. 0107h                   1 byte   Panning loop start point
  5156. 0108h                   1 byte   Panning loop end point
  5157. 0109h                   1 byte   Volume type, bitmapped
  5158.                                  0 - Volume on
  5159.                                  1 - Sustain on
  5160.                                  2 - Loop on
  5161. 010Ah                   1 byte   Panning type, bitmapped
  5162.                                  0 - Panning on
  5163.                                  1 - Sustain on
  5164.                                  2 - Loop on
  5165. 010Bh                   1 byte   Vibrato type
  5166. 010Ch                   1 byte   Vibrato sweep
  5167. 010Dh                   1 byte   Vibrato depth
  5168. 010Eh                   1 byte   Vibrato rate
  5169. 010Fh                   1 word   Volume fadeout
  5170. 0111h                   1 word   Reserved
  5171.  
  5172. --- Sample headers
  5173. OFFSET              Count TYPE   Description
  5174. 0000h                   1 dword  Sample length
  5175.                                  ="LEN"
  5176. 0004h                   1 dword  Sample loop start
  5177. 0008h                   1 dword  Sample loop length
  5178. 000Ch                   1 byte   Volume
  5179. 000Dh                   1 byte   Finetune for sample (-128..+127)
  5180.                                  +-127 is one half tone
  5181. 000Eh                   1 byte   Sample type, bitmapped
  5182.                                  0,1 : Loop type :
  5183.                                         0 - no loop
  5184.                                         1 - forward loop
  5185.                                         2 - ping-pong loop
  5186.                                         3 - reserved
  5187.                                    4?: sample is 16-bit
  5188. 000Fh                   1 byte   Sample pan
  5189. 0010h                   1 byte   Relative note number (signed byte)
  5190.                                  (-96..+95), 0 -> C-4 sounds as C-4
  5191. 0011h                   1 byte   Reserved
  5192. 0012h                  22 char   ASCII name of sample, 0 padded
  5193. 0013h               "LEN" byte   Sample data. The sample data is stored
  5194.                                  as delta compressed data like the ProTracker.
  5195.  
  5196. EXTENSION:XM,MOD
  5197. OCCURENCES:
  5198. PROGRAMS:
  5199. REFERENCE:
  5200. SEE ALSO:MOD,S3M
  5201. VALIDATION:
  5202. --------A-ZIP-------------------------------
  5203. The ZIP archives are created by the PkZIP/PkUnZIP combo produced
  5204. by the PkWare company. The PkZIP programs have with LHArc and ARJ
  5205. the best compression.
  5206. The directory information is stored at the end of the archive, each local
  5207. file in the archive begins with the following header; This header can be used
  5208. to identify a ZIP file as such :
  5209. OFFSET              Count TYPE   Description
  5210. 0000h                   4 char   ID='PK',03,04
  5211. 0004h                   1 word   Version needed to extract archive
  5212. 0006h                   1 word   General purpose bit field (bit mapped)
  5213.                                       0 - file is encrypted
  5214.                                       1 - 8K/4K sliding dictionary used
  5215.                                       2 - 3/2 Shannon-Fano trees were used
  5216.                                     3-4 - unused
  5217.                                    5-15 - used internally by ZIP
  5218.                                  Note:  Bits 1 and 2 are undefined if the
  5219.                                         compression method is other than
  5220.                                         type 6 (Imploding).
  5221. 0008h                   1 word   Compression method (see table 0010)
  5222. 000Ah                   1 dword  Original DOS file date/time (see table 0009)
  5223. 000Eh                   1 dword  32-bit CRC of file (inverse??)
  5224. 0012h                   1 dword  Compressed file size
  5225. 0016h                   1 dword  Uncompressed file size
  5226. 001Ah                   1 word   Length of filename
  5227.                                  ="LEN"
  5228. 001Ch                   1 word   Length of extra field
  5229.                                  ="XLN"
  5230. 001Eh               "LEN" char   path/filename
  5231. 001Eh               "XLN" char   extra field
  5232. +"LEN"
  5233. After all the files, there comes the central directory structure.
  5234. (Table 0010)
  5235. PkZip compression types
  5236. 0 - Stored / No compression
  5237. 1 - Shrunk / LZW, 8K buffer, 9-13 bits with partial clearing
  5238. 2 - Reduced-1 / Probalistic compression, lower 7 bits
  5239. 3 - Reduced-2 / Probalistic compression, lower 6 bits
  5240. 4 - Reduced-3 / Probalistic compression, lower 5 bits
  5241. 5 - Reduced-4 / Probalistic compression, lower 4 bits
  5242. 6 - Imploded / 2/3 Shanno-Fano trees, 4K/8K sliding dictionary
  5243.  
  5244. --- Central directory structure
  5245. The CDS is at the end of the archive and contains additional information
  5246. about the files stored within the archive.
  5247. OFFSET              Count TYPE   Description
  5248. 0000h                   4 char   ID='PK',01,02
  5249. 0004h                   1 byte   Version made by
  5250. 0005h                   1 byte   Host OS (see table 0011)
  5251. 0006h                   1 byte   Minimum version needed to extract
  5252. 0007h                   1 byte   Target OS
  5253.                                  see above "Host OS"
  5254. 0008h                   1 word   General purpose bit flag
  5255.                                  see above "General purpose bit flag"
  5256. 000Ah                   1 word   Compression method
  5257.                                  see above "Compression method"
  5258. 000Ch                   1 dword  DOS date / time of file
  5259. 0010h                   1 dword  32-bit CRC of file (see table 0009)
  5260. 0014h                   1 dword  Compressed size of file
  5261. 0018h                   1 dword  Uncompressed size of file
  5262. 001Ch                   1 word   Length of filename
  5263.                                  ="LEN"
  5264. 001Eh                   1 word   Length of extra field
  5265.                                  ="XLN"
  5266. 0020h                   1 word   Length of file comment
  5267.                                  ="CMT"
  5268. 0022h                   1 word   Disk number ??
  5269. 0024h                   1 word   Internal file attributes (bit mapped)
  5270.                                     0 - file is apparently an ASCII/binary file
  5271.                                  1-15 - unused
  5272. 0026h                   1 dword  External file attributes (OS dependent)
  5273. 002Ah                   1 dword  Relative offset of local header from the
  5274.                                  start of the first disk this file appears on
  5275. 002Eh               "LEN" char   Filename / path; should not contain a drive
  5276.                                  or device letter, all slashes should be forward
  5277.                                  slashes '/'.
  5278. 002Eh+              "XLN" char   Extra field
  5279. +"LEN"
  5280. 002Eh               "CMT" char   File comment
  5281. +"LEN"
  5282. +"XLN"
  5283.  
  5284. (Table 0011)
  5285. PkZip Host OS table
  5286. 0 - MS-DOS and OS/2 (FAT)
  5287. 1 - Amiga
  5288. 2 - VMS
  5289. 3 - *nix
  5290. 4 - VM/CMS
  5291. 5 - Atari ST
  5292. 6 - OS/2 1.2 extended file sys
  5293. 7 - Macintosh
  5294. 8-255 - unused
  5295.  
  5296. --- End of central directory structure
  5297. The End of Central Directory Structure header has following format :
  5298. OFFSET              Count TYPE   Description
  5299. 0000h                   4 char   ID='PK',05,06
  5300. 0004h                   1 word   Number of this disk
  5301. 0006h                   1 word   Number of disk with start of central directory
  5302. 0008h                   1 word   Total number of file/path entries on this disk
  5303. 000Ah                   1 word   Total number of entries in central dir
  5304. 000Ch                   1 dword  Size of central directory
  5305. 0010h                   1 dword  Offset of start of central directory relative
  5306.                                  to starting disk number
  5307. 0014h                   1 word   Archive comment length
  5308.                                  ="CML"
  5309. 0016h               "CML" char   Zip file comment
  5310.  
  5311. EXTENSION:ZIP
  5312. OCCURENCES:PC,Amiga,ST
  5313. PROGRAMS:PkZIP,WinZIP
  5314. REFERENCE:Technote.APP
  5315. --------A-ZOO-------------------------------
  5316. The ZOO archive program by Raoul Dhesi is a file compression program now
  5317. superceeded in both compression and speed by most other compression programs.
  5318. The archive header looks like this :
  5319. OFFSET              Count TYPE   Description
  5320. 0000h                  20 char   Archive header text, ^Z terminated, null padded
  5321. 0014h                   1 dword  ID=0FDC4A7DCh
  5322. 0018h                   1 dword  Offset of first file in archive
  5323. 001Ch                   1 dword  Offset of ????
  5324. 0020h                   1 byte   Version archive was made by
  5325. 0021h                   1 byte   Minimum version needed to extract
  5326.  
  5327. Each stored file has its own header, which looks like this :
  5328. OFFSET              Count TYPE   Description
  5329. 0000h                   1 dword  ID=0FDC4A7DCh
  5330. 0004h                   1 byte   Type of directory entry
  5331. 0005h                   1 byte   Compression method :
  5332.                                  0 - stored
  5333.                                  1 - Crunched : LZW, 4K buffer,
  5334.                                                  var len (9-13 bits)
  5335. 0006h                   1 dword  Offset of next directory entry
  5336. 000Ah                   1 dword  Offset of next header
  5337. 000Dh                   1 word   Original date / time of file (see table 0009)
  5338. 0012h                   1 word   CRC-16 of file
  5339. 0014h                   1 dword  Uncompressed size of file
  5340. 0018h                   1 dword  Compressed size of file
  5341. 001Ch                   1 byte   Version this file was compressed by
  5342. 001Dh                   1 byte   Minimum version needed to extract
  5343. 001Eh                   1 byte   Deleted flag
  5344.                                  0 - file in archive
  5345.                                  1 - file is considered deleted
  5346. 001Fh                   1 dword  Offset of comment field, 0 if none
  5347. 0023h                   1 word   Length of comment field
  5348. 0025h                   ? char   ASCIIZ path / filename
  5349.  
  5350. EXTENSION:ZOO
  5351. OCCURENCES:PC
  5352. PROGRAMS:ZOO.EXE
  5353. REFERENCE:
  5354. VALIDATION:
  5355. --------S-ZyXEL-----------------------------
  5356. The ZyXEL Modems are capable of digitizing speech, the ZFAX software and
  5357. answering machine software like VoiceConnect store the sampled data in those
  5358. files. The Modems are capable of compressing the data down to 19.2k CPS (ADPCM)
  5359. and 9.6k CPS (CELP), the algorithms for the compression may be found in the
  5360. ZyxelVoc package by N. Igl, but as the firmware on the modems changes, so might
  5361. the compression algorithm. Playback on the modem is always possible.
  5362.  
  5363. OFFSET              Count TYPE   Description
  5364. 0000h                   5 char   ID='ZyXEL'
  5365. 0005h                   1 byte   02h, ??? format tag
  5366. 0006h                   4 byte   reserved
  5367. 000Ah                   1 word   Compression scheme
  5368.                                    0 - CELP
  5369.                                    1 - 2 bit ADPCM
  5370.                                    2 - 3 bit ADPCM
  5371. 000Ch                   4 byte   reserved
  5372. 0010h                   ? ????   Raw Data
  5373.                                  The voice data is just
  5374.                                  the data received from U1496
  5375.                                  Modem/Fax.
  5376. EXTENSION:ZVD,ZYX
  5377. OCCURENCES:PC
  5378. PROGRAMS:Voice Connect,ZFAX
  5379. REFERENCE:ZYXELVOC.*
  5380. VALIDATION:NONE
  5381. --------!-ALGORITHMS------------------------
  5382. Some algorithms used for encoding images etc...
  5383. --- TIFF PackBits algorithm
  5384.  
  5385.           Abstract
  5386.           
  5387.           This document  describes a  simple compression scheme for bilevel
  5388.           scanned and paint type files.
  5389.           
  5390.           
  5391.           Motivation
  5392.           
  5393.           The TIFF  specification defines  a number of compression schemes.
  5394.           Compression type  1 is  really no  compression, other  than basic
  5395.           pixel  packing.     Compression   type  2,   based  on  CCITT  1D
  5396.           compression,  is   powerful,  but   not  trivial   to  implement.
  5397.           Compression type  5 is  typically very effective for most bilevel
  5398.           images, as  well as  many deeper images such as palette color and
  5399.           grayscale images, but is also not trivial to implement.  PackBits
  5400.           is a simple but often effective alternative.
  5401.           
  5402.           
  5403.           Description
  5404.           
  5405.           Several good schemes were already in use in various settings.  We
  5406.           somewhat arbitrarily picked the Macintosh PackBits scheme.  It is
  5407.           byte oriented,  so there  is no problem with word alignment.  And
  5408.           it has a good worst case behavior (at most 1 extra byte for every
  5409.           128 input  bytes).    For  Macintosh  users,  there  are  toolbox
  5410.           utilities PackBits  and UnPackBits that will do the work for you,
  5411.           but it is easy to implement your own routines.
  5412.           
  5413.           A pseudo code fragment to unpack might look like this:
  5414.           
  5415.           Loop  until  you  get  the  number  of  unpacked  bytes  you  are
  5416.           expecting:
  5417.                Read the next source byte into n.
  5418.                If n is between 0 and 127 inclusive, copy the next n+1 bytes
  5419.           literally.
  5420.                Else if  n is  between -127  and -1 inclusive, copy the next
  5421.           byte -n+1 times.
  5422.                Else if n is 128, noop.
  5423.           Endloop
  5424.           
  5425.           In the  inverse routine,  it's best to encode a 2-byte repeat run
  5426.           as a replicate run except when preceded and followed by a literal
  5427.           run, in  which case it's best to merge the three into one literal
  5428.           run.  Always encode 3-byte repeats as replicate runs.
  5429.           
  5430.           So that's the algorithm.  Here are some other rules:
  5431.           
  5432.           o    Each row  must be packed separately.  Do not compress across
  5433.           row boundaries.
  5434.  
  5435.           o    The number  of uncompressed  bytes per  row is defined to be
  5436.           (ImageWidth +  7) / 8.  If the uncompressed bitmap is required to
  5437.           have an  even number  of bytes  per row,  decompress  into  word-
  5438.           aligned buffers.
  5439.           o    If a  run is  larger  than  128  bytes,  simply  encode  the
  5440.           remainder of the run as one or more additional replicate runs.
  5441.           
  5442.           When  PackBits   data  is  uncompressed,  the  result  should  be
  5443.           interpreted as per compression type 1 (no compression).
  5444.           
  5445. --- TIFF LZW Compression
  5446.           
  5447.           Abstract
  5448.           
  5449.           This document describes an adaptive compression scheme for raster
  5450.           images.
  5451.           
  5452.           Reference
  5453.           
  5454.           Terry  A.   Welch,  "A   Technique  for   High  Performance  Data
  5455.           Compression",  IEEE   Computer,  vol.   17  no.  6  (June  1984).
  5456.           Describes the  basic Lempel-Ziv  & Welch  (LZW) algorithm.    The
  5457.           author's goal  in the  article is  to describe  a  hardware-based
  5458.           compressor that could be built into a disk controller or database
  5459.           engine, and  used on  all types  of data.   There  is no specific
  5460.           discussion of  raster images.    We  intend  to  give  sufficient
  5461.           information in  this Appendix so that the article is not required
  5462.           reading.
  5463.           
  5464.           Requirements
  5465.           
  5466.           A compression  scheme with  the following  characteristics should
  5467.           work well in a desktop publishing environment:
  5468.           
  5469.           o    Must work well for images of any bit depth, including images
  5470.           deeper than 8 bits per sample.
  5471.           o    Must be effective:  an average compression ratio of at least
  5472.           2:1 or  better.    And  it  must  have  a  reasonable  worst-case
  5473.           behavior, in case something really strange is thrown at it.
  5474.           o    Should  not  depend  on  small  variations  between  pixels.
  5475.           Palette color  images tend  to contain  abrupt changes  in  index
  5476.           values, due to common patterning and dithering techniques.  These
  5477.           abrupt changes  do tend to be repetitive, however, and the scheme
  5478.           should make use of this fact.
  5479.           o    For images  generated by  paint programs,  the scheme should
  5480.           not depend on a particular pattern width.  8x8 pixel patterns are
  5481.           common now, but we should not assume that this situation will not
  5482.           change.
  5483.           o    Must be  fast.   It should  not take  more than 5 seconds to
  5484.           decompress a  100K byte  grayscale image on a 68020- or 386-based
  5485.           computer.   Compression can  be slower,  but probably not by more
  5486.           than a factor of 2 or 3.
  5487.           o    The level  of implementation  complexity must be reasonable.
  5488.           We would like something that can be implemented in no more than a
  5489.           couple of  weeks  by  a competent  software  engineer  with  some
  5490.           experience  in   image  processing.     The   compiled  code  for
  5491.           compression and  decompression combined  should be  no more  than
  5492.           about 10K.
  5493.           o    Does not require floating point software or hardware.
  5494.           
  5495.           
  5496.           The following  sections describe  an algorithm based on the "LZW"
  5497.           (Lempel-Ziv & Welch) technique that meets the above requirements.
  5498.           In addition  meeting our  requirements,  LZW  has  the  following
  5499.           characteristics:
  5500.           
  5501.           o    LZW is fully reversible.  All information is preserved.  But
  5502.           if noise  or information  is removed  from an  image, perhaps  by
  5503.           smoothing or  zeroing some  low-order bitplanes,  LZW  compresses
  5504.           images to  a smaller  size.   Thus,   5-bit, 6-bit, or 7-bit data
  5505.           masquerading as  8-bit data  compresses better  than  true  8-bit
  5506.           data. Smooth  images also  compress better than noisy images, and
  5507.           simple images compress better than complex images.
  5508.           o    On a  68082- or  386-based computer,  LZW  software  can  be
  5509.           written to  compress at  between 30K  and 80K  bytes per  second,
  5510.           depending on image characteristics.  LZW decompression speeds are
  5511.           typically about 50K bytes per second.
  5512.           o    LZW works  well on  bilevel images,  too.   It always  beats
  5513.           PackBits,  and   generally  ties   CCITT  1D  (Modified  Huffman)
  5514.           compression, on our test images.  Tying CCITT 1D is impressive in
  5515.           that LZW  seems to be considerably faster than CCITT 1D, at least
  5516.           in our implementation.
  5517.           o    Our implementation is written in C, and compiles to about 2K
  5518.           bytes of object code each for the compressor and decompressor.
  5519.           o    One of  the nice  things about  LZW is that it is used quite
  5520.           widely in  other applications  such as  archival programs, and is
  5521.           therefore more of a known quantity.
  5522.           
  5523.           
  5524.           The Algorithm
  5525.           
  5526.           Each strip  is compressed  independently.   We strongly recommend
  5527.           that RowsPerStrip  be chosen  such that each strip contains about
  5528.           8K bytes  before compression.   We  want to keep the strips small
  5529.           enough so  that the  compressed and  uncompressed versions of the
  5530.           strip can  be kept entirely in memory even on small machines, but
  5531.           large enough to maintain nearly optimal compression ratios.
  5532.           
  5533.           The LZW  algorithm is  based on  a translation  table, or  string
  5534.           table, that  maps strings  of input  characters into  codes.  The
  5535.           TIFF implementation  uses variable-length  codes, with  a maximum
  5536.           code length of 12 bits.  This string table is different for every
  5537.           strip, and,  remarkably, does  not need to be kept around for the
  5538.           decompressor.     The  trick   is  to   make   the   decompressor
  5539.           automatically build  the same  table as is built when compressing
  5540.           the data.   We  use a  C-like pseudocode  to describe  the coding
  5541.           scheme:
  5542.           
  5543.                InitializeStringTable();
  5544.                WriteCode(ClearCode);
  5545.                Omega = the empty string;
  5546.                for each character in the strip {
  5547.                     K = GetNextCharacter();
  5548.                     if Omega+K is in the string table {
  5549.                          Omega = Omega+K;  /* string concatenation */
  5550.                     } else {
  5551.                          WriteCode (CodeFromString(Omega));
  5552.                          AddTableEntry(Omega+K);
  5553.                          Omega = K;
  5554.                     }
  5555.                } /* end of for loop */
  5556.                WriteCode (CodeFromString(Omega));
  5557.                WriteCode (EndOfInformation);
  5558.                     
  5559.           That's  it.    The  scheme  is  simple,  although  it  is  fairly
  5560.           challenging  to  implement  efficiently.    But  we  need  a  few
  5561.           explanations before we go on to decompression.
  5562.           
  5563.           The  "characters"   that  make  up  the  LZW  strings  are  bytes
  5564.           containing TIFF  uncompressed (Compression=1)  image data, in our
  5565.           implementation.   For example,  if BitsPerSample is 4, each 8-bit
  5566.           LZW character will contain two 4-bit pixels.  If BitsPerSample is
  5567.           16, each 16-bit pixel will span two 8-bit LZW characters.
  5568.           
  5569.           (It is  also possible to implement a version of LZW where the LZW
  5570.           character depth equals BitsPerSample, as was described by Draft 2
  5571.           of Revision  5.0.   But  there  is  a  major  problem  with  this
  5572.           approach.   If BitsPerSample  is greater  than 11, we can not use
  5573.           12-bit-maximum  codes,   so  that  the  resulting  LZW  table  is
  5574.           unacceptably large.   Fortunately,  due to the adaptive nature of
  5575.           LZW, we  do not  pay a  significant compression ratio penalty for
  5576.           combining several  pixels into  one byte before compressing.  For
  5577.           example, our  4-bit sample  images  compressed  about  3  percent
  5578.           worse, and  our 1-bit  images compressed  about 5 percent better.
  5579.           And it  is easier to write an LZW compressor that always uses the
  5580.           same character  depth than  it is  to write  one which can handle
  5581.           varying depths.)
  5582.           
  5583.           We can  now describe  some of the routine and variable references
  5584.           in our pseudocode:
  5585.           
  5586.           InitializeStringTable() initializes  the string  table to contain
  5587.           all possible  single-character strings.   There  are 256 of them,
  5588.           numbered 0 through 255, since our characters are bytes.
  5589.           
  5590.           WriteCode() writes  a code  to the output stream.  The first code
  5591.           written is a Clear code, which is defined to be code #256.
  5592.           
  5593.           Omega is our "prefix string."
  5594.           
  5595.           GetNextCharacter() retrieves  the next  character value  from the
  5596.           input stream.   This  will be number between 0 and 255, since our
  5597.           characters are bytes.
  5598.           
  5599.           The "+" signs indicate string concatenation.
  5600.           
  5601.           AddTableEntry() adds a table entry.  (InitializeStringTable() has
  5602.           already put  256 entries  in our table.  Each entry consists of a
  5603.           single-character string, and its associated code value, which is,
  5604.           in our  application, identical to the character itself.  That is,
  5605.           the 0th  entry in  our table  consists of  the string  <0>,  with
  5606.           corresponding code  value of  <0>, the  1st entry  in  the  table
  5607.           consists of the string <1>, with corresponding code value of <1>,
  5608.           ..., and  the 255th  entry in  our table  consists of  the string
  5609.           <255>, with  corresponding code  value of  <255>.)   So the first
  5610.           entry that  we add  to our  string table will be at position 256,
  5611.           right?   Well, not  quite, since  we will reserve code #256 for a
  5612.           special   "Clear"   code,   and   code   #257   for   a   special
  5613.           "EndOfInformation" code  that we will write out at the end of the
  5614.           strip.  So the first multiple-character entry added to the string
  5615.           table will be at position 258.
  5616.           
  5617.           Let's try  an example.   Suppose  we have  input data  that looks
  5618.           like:
  5619.           
  5620.           Pixel 0:  <7>
  5621.           Pixel 1:  <7>
  5622.           Pixel 2:  <7>
  5623.           Pixel 3:  <8>
  5624.           Pixel 4:  <8>
  5625.           Pixel 5:  <7>
  5626.           Pixel 6:  <7>
  5627.           Pixel 7:  <6>
  5628.           Pixel 8:  <6>
  5629.           
  5630.           First, we read Pixel 0 into K.  OmegaK is then simply <7>, since Omega is
  5631.           the empty string at this point.  Is the string <7> already in the
  5632.           string table?  Of course, since all single character strings were
  5633.           put in the table by InitializeStringTable().  So set Omega equal to
  5634.           <7>, and go to the top of the loop.
  5635.           
  5636.           Read Pixel 1 into K.  Does OmegaK (<7><7>) exist in the string table?
  5637.           No, so we get to do some real work.  We write the code associated
  5638.           with Omega to output (write <7> to output), and add OmegaK (<7><7>) to
  5639.           the table as entry 258.   Store K (<7>) into Omega.    Note  that
  5640.           although we have added the string consisting of Pixel 0 and Pixel
  5641.           1 to  the table, we "re-use" Pixel 1 as the beginning of the next
  5642.           string.
  5643.           
  5644.           Back at the top of the loop.  We read Pixel 2 into K.  Does OmegaK
  5645.           (<7><7>) exist  in the  string table?   Yes,  the entry  we  just
  5646.           added, entry 258, contains exactly <7><7>.  So we just add K onto
  5647.           the end of Omega, so that Omega is now <7><7>.
  5648.           
  5649.           Back at the top of the loop.  We read Pixel 3 into K.  Does OmegaK
  5650.           (<7><7><8>) exist  in the  string table?   No,  so write the code
  5651.           associated with Omega (<258>) to output, and add OmegaK to the table as
  5652.           entry 259.  Store K (<8>) into Omega.
  5653.           
  5654.           Back at the top of the loop.  We read Pixel 4 into K.  Does OmegaK
  5655.           (<8><8>) exist  in the  string table?   No,  so  write  the  code
  5656.           associated with Omega (<8>) to output, and add OmegaK to the table as
  5657.           entry 260.  Store K (<8>) into Omega.
  5658.           
  5659.           Continuing, we get the following results:
  5660.           
  5661.                After reading: We write to output: And add table entry:
  5662.                Pixel 0
  5663.                Pixel 1   <7>  258: <7><7>
  5664.                Pixel 2
  5665.                Pixel 3   <258>     259: <7><7><8>
  5666.                Pixel 4   <8>  260: <8><8>
  5667.                Pixel 5   <8>  261: <8><7>
  5668.                Pixel 6
  5669.                Pixel 7   <258>     262: <7><7><6>
  5670.                Pixel 8   <6>  263: <6><6>
  5671.           
  5672.           WriteCode() also  requires some  explanation.   The  output  code
  5673.           stream,  <7><258><8><8><258><6>...  in  our  example,  should  be
  5674.           written using as few bits as possible.  When we are just starting
  5675.           out, we  can use  9-bit codes, since our new string table entries
  5676.           are greater  than 255  but less  than 512.  But when we add table
  5677.           entry 512,  we must  switch to 10-bit codes.  Likewise, we switch
  5678.           to 11-bit  codes at  1024, and  12-bit codes  at 2048.   We  will
  5679.           somewhat arbitrarily limit ourselves to 12-bit codes, so that our
  5680.           table can  have at most 4096 entries.  If we push it any farther,
  5681.           tables tend to get too large.
  5682.           
  5683.           What happens  if we run out of room in our string table?  This is
  5684.           where the afore-mentioned Clear code comes in.  As soon as we use
  5685.           entry 4094, we write out a (12-bit) Clear code.   (If we wait any
  5686.           dworder to  write the  Clear code,  the decompressor  might try to
  5687.           interpret the  Clear code  as a 13-bit code.)  At this point, the
  5688.           compressor re-initializes the string table and starts writing out
  5689.           9-bit codes again.
  5690.           
  5691.           Note that whenever you write a code and add a table entry, Omega is
  5692.           not left  empty.   It contains exactly one character.  Be careful
  5693.           not to  lose it  when you  write an end-of-table Clear code.  You
  5694.           can either write it out as a 12-bit code before writing the Clear
  5695.           code, in  which case  you will  want to  do it right after adding
  5696.           table entry  4093, or  after the  clear code  as  a  9-bit  code.
  5697.           Decompression gives the same result in either case.
  5698.           
  5699.           To make  things a  little simpler  for the  decompressor, we will
  5700.           require that  each strip  begins with a Clear code, and ends with
  5701.           an EndOfInformation code.
  5702.           
  5703.           Every LZW-compressed  strip must  begin on  a byte  boundary.  It
  5704.           need not  begin on  a word  boundary.   LZW compression codes are
  5705.           stored into  bytes in  high-to-low-order fashion, i.e., FillOrder
  5706.           is assumed  to be  1.  The compressed codes are written as bytes,
  5707.           not  words,  so  that  the  compressed  data  will  be  identical
  5708.           regardless of whether it is an "II" or "MM" file.
  5709.           
  5710.           Note that  the LZW string table is a continuously updated history
  5711.           of the  strings that  have been encountered in the data.  It thus
  5712.           reflects the characteristics of the data, providing a high degree
  5713.           of adaptability.
  5714.           
  5715.           
  5716.           LZW Decoding
  5717.           
  5718.           The procedure for decompression is a little more complicated, but
  5719.           still not too bad:
  5720.                     
  5721.                while ((Code = GetNextCode()) != EoiCode) {
  5722.                     if (Code == ClearCode) {
  5723.                          InitializeTable();
  5724.                          Code = GetNextCode();
  5725.                          if (Code == EoiCode)
  5726.                               break;
  5727.                          WriteString(StringFromCode(Code));
  5728.                          OldCode = Code;
  5729.                     }  /* end of ClearCode case */
  5730.           
  5731.                     else {
  5732.                          if (IsInTable(Code)) {
  5733.                               WriteString(StringFromCode(Code));
  5734.                               AddStringToTable(StringFromCode(OldCode)+
  5735.                                 FirstChar(StringFromCode(Code)));
  5736.                               OldCode = Code;
  5737.                          } else {
  5738.                               OutString = StringFromCode(OldCode) +
  5739.                                   FirstChar(StringFromCode(OldCode));
  5740.                               WriteString(OutString);
  5741.                               AddStringToTable(OutString);
  5742.                               OldCode = Code;
  5743.                          }
  5744.                     } /* end of not-ClearCode case */
  5745.                } /* end of while loop */
  5746.           
  5747.           The function  GetNextCode() retrieves the next code from the LZW-
  5748.           coded data.  It must keep track of bit boundaries.  It knows that
  5749.           the first code that it gets will be a 9-bit code.  We add a table
  5750.           entry each  time we get a code, so GetNextCode() must switch over
  5751.           to 10-bit codes as soon as string #511 is stored into the table.
  5752.           
  5753.           The function  StringFromCode() gets  the string associated with a
  5754.           particular code from the string table.
  5755.           
  5756.           The function  AddStringToTable() adds  a  string  to  the  string
  5757.           table.   The "+"  sign joining  the two  parts of the argument to
  5758.           AddStringToTable indicate string concatenation.
  5759.           
  5760.           StringFromCode() looks  up the  string associated  with  a  given
  5761.           code.
  5762.           
  5763.           WriteString() adds a string to the output stream.
  5764.           
  5765.           
  5766.           When SamplesPerPixel Is Greater Than 1
  5767.           
  5768.           We  have   so  far   described  the   compression  scheme  as  if
  5769.           SamplesPerPixel were  always 1,  as will  be  be  the  case  with
  5770.           palette color  and grayscale  images.  But what do we do with RGB
  5771.           image data?
  5772.           
  5773.           Tests on  our sample  images indicate  that the  LZW  compression
  5774.           ratio    is    nearly    identical    regardless    of    whether
  5775.           PlanarConfiguration=1 or  PlanarConfiguration=2, for  RGB images.
  5776.           So use  whichever configuration  you prefer,  and simply compress
  5777.           the bytes in the strip.
  5778.           
  5779.           It is  worth cautioning  that compression  ratios on our test RGB
  5780.           images were disappointing low: somewhere between 1.1 to 1 and 1.5
  5781.           to 1,  depending on the image.  Vendors are urged to do what they
  5782.           can to  remove as  much noise  from  their  images  as  possible.
  5783.           Preliminary tests  indicate that significantly better compression
  5784.           ratios are  possible with  less noisy  images.  Even something as
  5785.           simple as  zeroing out one or two least-significant bitplanes may
  5786.           be  quite   effective,  with   little  or  no  perceptible  image
  5787.           degradation.
  5788.           
  5789.           
  5790.           Implementation
  5791.           
  5792.           The exact  structure of  the string  table and the method used to
  5793.           determine if  a string  is already  in the table are probably the
  5794.           most significant  design decisions in the implementation of a LZW
  5795.           compressor and  decompressor.   Hashing has  been suggested  as a
  5796.           useful technique for the compressor.  We have chosen a tree based
  5797.           approach, with  good results.   The decompressor is actually more
  5798.           straightforward,  as   well  as   faster,  since   no  search  is
  5799.           involved - strings can be accessed directly by code value.
  5800.           
  5801.           
  5802.           Performance
  5803.           
  5804.           Many  people   do  not   realize  that  the  performance  of  any
  5805.           compression scheme  depends greatly  on the type of data to which
  5806.           it is  applied.   A scheme that works well on one data set may do
  5807.           poorly on the next.
  5808.           
  5809.           But since  we do  not want  to burden  the world  with  too  many
  5810.           compression schemes, an adaptive scheme such as LZW that performs
  5811.           quite well  on a wide range of images is very desirable.  LZW may
  5812.           not always  give optimal  compression ratios,  but  its  adaptive
  5813.           nature and relative simplicity seem to make it a good choice.
  5814.           
  5815.           Experiments thus  far indicate  that we  can  expect  compression
  5816.           ratios of  between 1.5  and 3.0  to 1  from LZW,  with no loss of
  5817.           data, on  continuous tone  grayscale scanned  images.  If we zero
  5818.           the least  significant one or two bitplanes of 8-bit data, higher
  5819.           ratios can be achieved.  These bitplanes often consist chiefly of
  5820.           noise, in  which case  little or no loss in image quality will be
  5821.           perceived.   Palette color  images created  in  a  paint  program
  5822.           generally compress  much  better  than  continuous  tone  scanned
  5823.           images, since paint images tend to be more repetitive.  It is not
  5824.           unusual to  achieve compression  ratios of 10 to 1 or better when
  5825.           using LZW on palette color paint images.
  5826.           
  5827.           By way  of comparison, PackBits, used in TIFF for black and white
  5828.           bilevel images, does not do well on color paint images, much less
  5829.           continuous tone  grayscale and  color images.  1.2 to 1 seemed to
  5830.           be about average for 4-bit images, and 8-bit images are worse.
  5831.           
  5832.           It has  been suggested that the CCITT 1D scheme could be used for
  5833.           continuous tone  images, by compressing each bitplane separately.
  5834.           No doubt  some  compression  could  be  achieved,  but  it  seems
  5835.           unlikely that  a scheme  based on a fixed table that is optimized
  5836.           for word  black runs  separated by  dworder white runs would be a
  5837.           very good choice on any of the bitplanes.  It would do quite well
  5838.           on the  high-order bitplanes  (but so would a simpler scheme like
  5839.           PackBits), and  would do quite poorly on the low-order bitplanes.
  5840.           We believe  that the  compression ratios  would generally  not be
  5841.           very impressive, and the process would in addition be quite slow.
  5842.           Splitting  the  pixels  into  bitplanes  and  putting  them  back
  5843.           together is  somewhat expensive,  and the  coding is  also fairly
  5844.           slow when implemented in software.
  5845.           
  5846.           Another  approach   that  has  been  suggested  uses  uses  a  2D
  5847.           differencing step  following by  coding the  differences using  a
  5848.           fixed table  of variable-length codes.  This type of scheme works
  5849.           quite well  on many  8-bit  grayscale  images,  and  is  probably
  5850.           simpler  to  implement  than  LZW.    But  it  has  a  number  of
  5851.           disadvantages when  used on  a wide variety of images.  First, it
  5852.           is not  adaptive.   This makes  a big difference when compressing
  5853.           data such as 8-bit images that have been "sharpened" using one of
  5854.           the standard  techniques.  Such images tend to get larger instead
  5855.           of smaller  when  compressed.    Another  disadvantage  of  these
  5856.           schemes is  that they  do not  do well  with a  wide range of bit
  5857.           depths.   The built-in  code table  has to  be  optimized  for  a
  5858.           particular bit depth in order to be effective.
  5859.           
  5860.           Finally,  we   should  mention   "lossy"   compression   schemes.
  5861.           Extensive research  has been  done in  the area of lossy, or non-
  5862.           information-preserving  image   compression.    These  techniques
  5863.           generally yield  much  higher  compression  ratios  than  can  be
  5864.           achieved  by   fully-reversible,   information-preserving   image
  5865.           compression  techniques   such  as   PackBits  and   LZW.    Some
  5866.           disadvantages:     many  of   the   lossy   techniques   are   so
  5867.           computationally expensive  that hardware  assists  are  required.
  5868.           Others  are  so  complicated  that  most  microcomputer  software
  5869.           vendors could  not afford either the expense of implementation or
  5870.           the increase  in  application  object  code  size.    Yet  others
  5871.           sacrifice enough  image  quality  to  make  them  unsuitable  for
  5872.           publishing use.
  5873.           
  5874.           In spite  of these  difficulties, we  believe that there will one
  5875.           day be  a standardized  lossy compression  scheme for  full color
  5876.           images  that  will  be  usable  for  publishing  applications  on
  5877.           microcomputers.   An International  Standards Organization group,
  5878.           ISO/IEC/JTC1/SC2/WG8, in cooperation with CCITT Study Group VIII,
  5879.           is hard at work on a scheme that might be appropriate.  We expect
  5880.           that a  future revision of TIFF will incorporate this scheme once
  5881.           it is  finalized, if it turns out to satisfy the needs of desktop
  5882.           publishers and  others in the microcomputer community.  This will
  5883.           augment, not replace, LZW as an approved TIFF compression scheme.
  5884.           LZW will  very likely  remain the  scheme of  choice for  Palette
  5885.           color images,  and perhaps  4-bit grayscale  images, and may well
  5886.           overtake CCITT 1D and PackBits for bilevel images.
  5887.           
  5888.           
  5889.           Future LZW Extensions
  5890.           
  5891.           Some images  compress better  using LZW  coding if they are first
  5892.           subjected to  a process  wherein each  pixel value is replaced by
  5893.           the  difference  between  the  pixel  and  the  preceding  pixel.
  5894.           Performing this  differencing in two dimensions helps some images
  5895.           even more.  However, many images do not compress better with this
  5896.           extra preprocessing,  and for a significant number of images, the
  5897.           compression ratio is actually worse.  We are therefore not making
  5898.           differencing an integral part of the TIFF LZW compression scheme.
  5899.           
  5900.           However,  it   is  possible   that  a   "prediction"  stage  like
  5901.           differencing may  exist which  is effective over a broad range of
  5902.           images.  If such a scheme is found, it may be incorporated in the
  5903.           next major TIFF revision.  If so, a new value will be defined for
  5904.           the new  "Predictor" TIFF  tag.  Therefore, all TIFF readers that
  5905.           read LZW files must pay attention to the Predictor tag.  If it is
  5906.           1, which  is the  default case,  LZW  decompression  may  proceed
  5907.           safely.   If it  is not  1, and the reader does not recognize the
  5908.           specified prediction scheme, the reader should give up.
  5909.           
  5910.           
  5911.           Acknowledgements
  5912.           
  5913.           The original  LZW reference  has already  been given.  The use of
  5914.           ClearCode as a technique to handle overflow was borrowed from the
  5915.           compression scheme used by the Graphics Interchange Format (GIF),
  5916.           a small-color-paint-image-file  format used  by  CompuServe  that
  5917.           also is an adaptation of the LZW technique.  Joff Morgan and Eric
  5918.           Robinson of  Aldus were  each instrumental  in their  own way  in
  5919.           getting LZW off the ground.
  5920.           
  5921.           The TIFF predictor algorithm
  5922.           
  5923.           The idea  is to  make use  of the  fact that many continuous tone
  5924.           images rarely  vary much  in pixel  value from  one pixel  to the
  5925.           next.   In such  images,  if  we  replace  the  pixel  values  by
  5926.           differences between  consecutive pixels,  many of the differences
  5927.           should be  0, plus  or minus  1, and  so on.   This  reduces  the
  5928.           apparent information  content, and  thus allows LZW to encode the
  5929.           data more compactly.
  5930.           
  5931.           Assuming 8-bit  grayscale  pixels  for  the  moment,  a  basic  C
  5932.           implementation might look something like this:
  5933.           
  5934.                char image[ ][ ];
  5935.                int  row, col;
  5936.           
  5937.                /* take horizontal differences:
  5938.                 */
  5939.                for (row = 0; row < nrows; row++)
  5940.                     for (col = ncols - 1; col >= 1; col--)
  5941.                          image[row][col] -= image[row][col-1];
  5942.           
  5943.           If we  don't have 8-bit samples, we need to work a little harder,
  5944.           so that  we can make better use of the architecture of most CPUs.
  5945.           Suppose we  have 4-bit  samples, packed  two to a byte, in normal
  5946.           TIFF uncompressed  (i.e., Compression=1)  fashion.   In order  to
  5947.           find differences,  we want to first expand each 4-bit sample into
  5948.           an 8-bit  byte, so  that we  have one  sample per byte, low-order
  5949.           justified.   We then  perform the  above horizontal differencing.
  5950.           Once the  differencing has  been completed, we then repack the 4-
  5951.           bit differences  two to  a  byte,  in  normal  TIFF  uncompressed
  5952.           fashion.
  5953.           
  5954.           If the  samples are  greater than  8  bits  deep,  expanding  the
  5955.           samples into  16-bit words  instead of 8-bit bytes seems like the
  5956.           best way to perform the subtraction on most computers.
  5957.           
  5958.           Note that we have not lost any data up to this point, nor will we
  5959.           lose any  data later  on.   It  might  at  first  seem  that  our
  5960.           differencing might  turn 8-bit samples into 9-bit differences, 4-
  5961.           bit samples  into 5-bit differences, and so on.  But it turns out
  5962.           that we  can completely  ignore the  "overflow"  bits  caused  by
  5963.           subtracting a  larger number  from a  smaller  number  and  still
  5964.           reverse the  process  without  error.    Normal  twos  complement
  5965.           arithmetic does just what we want.  Try an example by hand if you
  5966.           need more convincing.
  5967.           
  5968.           Up  to  this  point  we  have  implicitly  assumed  that  we  are
  5969.           compressing  bilevel   or  grayscale   images.     An  additional
  5970.           consideration arises in the case of color images.
  5971.           
  5972.           If PlanarConfiguration  is 2,  there is no problem.  Differencing
  5973.           proceeds the same way as it would for grayscale data.
  5974.           
  5975.           If  PlanarConfiguration  is  1,  however,  things  get  a  little
  5976.           trickier.   If  we  didnt  do  anything  special,  we  would  be
  5977.           subtracting red  sample values  from green  sample values,  green
  5978.           sample values  from blue  sample values,  and blue  sample values
  5979.           from red sample values, which would not give the LZW coding stage
  5980.           much redundancy  to work  with.   So we  will do  our  horizontal
  5981.           differences with  an offset  of SamplesPerPixel  (3, in  the  RGB
  5982.           case).  In other words, we will subtract red from red, green from
  5983.           green, and  blue from blue.  The LZW coding stage is identical to
  5984.           the SamplesPerPixel=1 case.  We require that BitsPerSample be the
  5985.           same for all 3 samples.
  5986.           
  5987.           
  5988.           Results and guidelines
  5989.           
  5990.           LZW without  differencing works  well  for  1-bit  images,  4-bit
  5991.           grayscale images, and synthetic color images.  But natural 24-bit
  5992.           color images  and some 8-bit grayscale images do much better with
  5993.           differencing.  For example, our 24-bit natural test images hardly
  5994.           compressed at  all using  "plain" LZW:  the  average  compression
  5995.           ratio was  1.04  to  1.    The  average  compression  ratio  with
  5996.           horizontal differencing  was 1.40  to 1.  (A compression ratio of
  5997.           1.40 to 1 means that if the uncompressed image is 1.40MB in size,
  5998.           the compressed version is 1MB in size.)
  5999.           
  6000.           Although  the   combination  of   LZW  coding   with   horizontal
  6001.           differencing does  not result  in any  loss of  data, it  may  be
  6002.           worthwhile in  some situations  to give  up some  information  by
  6003.           removing as  much noise  as possible  from the  image data before
  6004.           doing the  differencing, especially  with  8-bit  samples.    The
  6005.           simplest way  to get  rid of noise is to mask off one or two low-
  6006.           order bits  of each 8-bit sample.  On our 24-bit test images, LZW
  6007.           with horizontal differencing yielded an average compression ratio
  6008.           of 1.4 to 1.  When the low-orde