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