file/Magdir/compress

#------------------------------------------------------------------------------
# compress:  file(1) magic for pure-compression formats (no archives)
#
# compress, gzip, pack, compact, huf, squeeze, crunch, freeze, yabba, etc.
#
# Formats for various forms of compressed data
# Formats for "compress" proper have been moved into "compress.c",
# because it tries to uncompress it to figure out what's inside.

# standard unix compress
0	string		\037\235	compress'd data
>2	byte&0x80	>0		block compressed
>2	byte&0x1f	x		%d bits

# gzip (GNU zip, not to be confused with Info-ZIP or PKWARE zip archiver)
0       string          \037\213        gzip compressed data
>2      byte            <8              \b, reserved method,
>2      byte            8               \b, deflated,
>3	byte		&0x01		ASCII,
>3	byte		&0x02		continuation,
>3	byte		&0x04		extra field,
>3	byte		&0x08		original filename,
>3	byte		&0x10		comment,
>3	byte		&0x20		encrypted,
>4	ledate		x		last modified: %s,
>8	byte		2		max compression,
>8	byte		4		max speed,
>9	byte		=0x00		os: MS-DOS
>9	byte		=0x01		os: Amiga
>9	byte		=0x02		os: VMS
>9	byte		=0x03		os: Unix
>9	byte		=0x05		os: Atari
>9	byte		=0x06		os: OS/2
>9	byte		=0x07		os: MacOS
>9	byte		=0x0A		os: Tops/20
>9	byte		=0x0B		os: Win/32

# packed data, Huffman (minimum redundancy) codes on a byte-by-byte basis
0	string		\037\036	packed data
>2	belong		>1		\b, %d characters originally
>2	belong		=1		\b, %d character originally
#
# This magic number is byte-order-independent.  XXX - Does that mean this
# is big-endian, little-endian, either, or that you can't tell?
# this short is valid for SunOS
0	short		017437		old packed data

# XXX - why *two* entries for "compacted data", one of which is
# byte-order independent, and one of which is byte-order dependent?
#
0	short		0x1fff		compacted data
# This string is valid for SunOS (BE) and a matching "short" is listed
# in the Ultrix (LE) magic file.
0	string		\377\037	compacted data
0	short		0145405		huf output

# Squeeze and Crunch...
# These numbers were gleaned from the Unix versions of the programs to
# handle these formats.  Note that I can only uncrunch, not crunch, and
# I didn't have a crunched file handy, so the crunch number is untested.
#				Keith Waclena <keith@cerberus.uchicago.edu>
0	leshort		0x76FF		squeezed data (CP/M, DOS)
0	leshort		0x76FE		crunched data (CP/M, DOS)

# Freeze
0	string		\037\237	frozen file 2.1
0	string		\037\236	frozen file 1.0 (or gzip 0.5)

# SCO compress -H (LZH)
0	string		\037\240	SCO compress -H (LZH) data

# European GSM 06.10 is a provisional standard for full-rate speech
# transcoding, prI-ETS 300 036, which uses RPE/LTP (residual pulse
# excitation/long term prediction) coding at 13 kbit/s.
#
# There's only a magic nibble (4 bits); that nibble repeats every 33
# bytes.  This isn't suited for use, but maybe we can use it someday.
#
# This will cause very short GSM files to be declared as data and
# mismatches to be declared as data too!
#0	byte&0xF0	0xd0	data
#>33	byte&0xF0	0xd0
#>66	byte&0xF0	0xd0
#>99	byte&0xF0	0xd0
#>132	byte&0xF0	0xd0	GSM 06.10 compressed audio