Just Solve the File Format Problem - User contributions [en]

KTX

2024-02-13T19:21:37Z

AmigoJack: archive.org links

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|ktx}}
|mimetypes={{mimetype|image/ktx}}
|pronom={{PRONOM|fmt/970}}
|released=2010
}}
'''KTX''' (Khronos Texture) is, according to its documentation, "a format for storing textures for OpenGL and OpenGL ES applications."

== Identification ==
KTX files begin with a 12-byte signature: {{magic|AB 4B 54 58 20 ?? ?? BB 0D 0A 1A 0A}}.

The "??" bytes are for a version number. Possible values include ASCII "{{magic|11}}" and "{{magic|20}}".

== Specifications ==
* [https://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/ KTX File Format Specification]; archived: https://web.archive.org/web/20200414231150/https://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/
* [http://github.khronos.org/KTX-Specification/ KTX™️ File Format Specification] (version 2.0); archived: https://web.archive.org/web/20191123013209/http://github.khronos.org/KTX-Specification/

== Sample files ==
* https://github.com/KhronosGroup/KTX/tree/master/testimages

== Links ==
* [https://www.khronos.org/opengles/sdk/tools/KTX/ OpenGL ES SDK: KTX tool set]
** [https://github.com/KhronosGroup/KTX Khronos KTX Repository at GitHub]

Kolor Raw

2024-02-13T10:08:18Z

AmigoJack: more precise identification; working link

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|kro}}
}}
'''Kolor Raw''' format ('''KRO''') is a simple uncompressed raster image format, presumably associated with Kolor products such as Autopano.

It supports RGB and RGBA color types. It supports 8 or 16 bits per sample, or floating point with 32 bits per sample.

== Format ==
Files have a 20-byte header, followed by the pixel data.

== Identification ==
Files begin with ASCII characters "<code>KRO</code>", followed by <code>0x01</code> for the version, followed by width and height in 4 BE bytes each.

== Specifications ==
* (formerly http://www.autopano.net/wiki-en/Format_KRO) https://web.archive.org/web/20140202144715/http://www.autopano.net/wiki-en/Format_KRO

== Software ==
* [[Konvertor]]
* [[XnView]]

== Sample files ==
* {{DexvertSamples|image/kro}}

JPEG XS

2024-02-10T10:55:47Z

AmigoJack: identification

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|wikidata={{wikidata|Q60776453}}
|released=2019
}}
'''JPEG XS''' is a compressed image and video format, and related standards. It is published as ISO/IEC 21122. As of 2019-08, all the critical parts of the standard had been published.

== Format details ==
From the standard's table of contents, we surmise that there is a still image file format called '''JXS''', and an [[ISO Base Media File Format|ISOBMFF]]-based format called '''Motion JPEG XS'''. There is also a standard way to use JPEG XS in [[HEIF]].

== Identification ==
* Can be wrapped in an ISOBMFF-based file format ([https://gitlab.com/wg1/jpeg-xl/-/blob/master/tools/box/box.cc implementation], see [https://gitlab.com/wg1/jpeg-xl/-/blob/main/doc/format_overview.md format overview]), similar to [[JPEG XL]]:
** the first 4 bytes would be the size of the box (<code>00 00 00 0C</code>, meaning 12 bytes long),
** the box ID would be <code>4A 58 53 20</code> (in ASCII <code>JXS </code>) and
** the box content would be the overall signature <code>0D 0A 87 0A</code>.

== Specifications ==

* ISO/IEC 21122 - JPEG XS low-latency lightweight image coding system. ''(These documents are probably not free to download.)''
** [https://www.iso.org/standard/74535.html ISO/IEC 21122-1:2019] - Part 1: Core coding system
** [https://www.iso.org/standard/74536.html ISO/IEC 21122-2:2019] - Part 2: Profiles and buffer models
** [https://www.iso.org/standard/74537.html ISO/IEC 21122-3:2019] - Part 3: Transport and container formats
** [https://www.iso.org/standard/74538.html ISO/IEC 21122-4] - Part 4: Conformance testing
** [https://www.iso.org/standard/74539.html ISO/IEC 21122-5] - Part 5: Reference software

== Links ==
* [https://jpeg.org/jpegxs/index.html jpeg.org: Overview of JPEG XS]
* [[Wikipedia: JPEG XS]]

[[Category:Video]]
[[Category:Box file format]]
[[Category:JPEG (organization)]]

JPEG XL

2024-02-10T10:50:38Z

AmigoJack: more precise identification

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|jxl}}
|mimetypes={{mimetype|image/jxl}}
|extended from=[[JPEG]], [[PIK]], [[FUIF]]
|pronom={{PRONOM|fmt/1484}}, {{PRONOM|fmt/1485}}
|magic={{magic|FF 0A}} or {{magic|00 00 00 0C 4A 58 4C 20 0D 0A 87 0A}}
|patent license=Royalty-Free
|released=2021
}}
'''JPEG XL''' is a compressed image format and/or file format that is yet another attempt to be the next [[JPEG]]. It was first announced around 2017-08. It is expected to be published as ISO/IEC 18181.

JPEG XL is based in part on the [[FUIF]] and [[PIK]] formats.[https://github.com/cloudinary/fuif/blob/3ed48249a9cbe68740aa4ea58098ab0cd4b87eaa/README.md] The standard also supports recompression of JPEG files with bit-exact reconstruction.

== Identification ==
* Based on the [https://gitlab.com/wg1/jpeg-xl/-/blob/master/lib/jxl/decode.cc reference implementation], JPEG XL codestreams start with bytes {{magic|ff 0a}}.
* Codestreams may also be wrapped in an ISOBMFF-based file format ([https://gitlab.com/wg1/jpeg-xl/-/blob/master/tools/box/box.cc implementation]). See [https://gitlab.com/wg1/jpeg-xl/-/blob/main/doc/format_overview.md format overview]:
** the first 4 bytes would be the size of the box (<code>00 00 00 0C</code>, meaning 12 bytes long),
** the box ID would be <code>4A 58 4C 20</code> (in ASCII <code>JXL </code>) and
** the box content would be the overall signature <code>0D 0A 87 0A</code>.

== Specifications ==
* [https://arxiv.org/abs/1908.03565 Committee Draft of JPEG XL] (2019-08)
* [https://www.iso.org/standard/77977.html ISO/IEC 18181]

== Software ==
* [https://gitlab.com/wg1/jpeg-xl Open-source reference software]
* [https://jpegxl-converter.com/ Online converter to JXL]
* [https://www.reddit.com/r/jpegxl/comments/qcd0ao/gimp_3_to_support_jpeg_xl/ GIMP Support]

== Sample files ==
* {{DexvertSamples|image/jpegXL}}

== Links ==
* [https://jpeg.org/jpegxl/ Overview of JPEG XL]
* [https://jpeg.org/items/20171107_cfp_jpeg_xl.html Next-Generation Image Compression (JPEG XL) Draft Call for Proposals] (2017-11)
* [https://jpeg.org/items/20180221_cfp_jpeg_xl.html Revised Draft Call for Proposals] (2018-02)
* [https://jpeg.org/items/20180423_cfp_jpeg_xl.html Final Call for Proposals] (2018-04)
* [http://gigazine.net/gsc_news/en/20170815-jpeg-xl-call-for-draft/ Gigazine article] (2017-08-15)
* [https://www.slideshare.net/cloudinarymarketing/imagecon-2019-jon-sneyer Slides from Imagecon 2019 presentation]
* [https://www.spiedigitallibrary.org/proceedings/Download?fullDOI=10.1117%2F12.2529237 Introductory paper (open access)]
* [https://doi.org/10.1117/12.2556264 Benchmarking JPEG XL image compression]
* [https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs How JPEG XL Compares to Other Image Codecs] (2020-05-26)
* [https://github.com/exiftool/exiftool/issues/77 Codestream vs Container discussion]

[[Category:JPEG (organization)]]
[[Category:JPEG]]
[[Category:Box file format]]

RealMedia

2023-11-30T22:05:42Z

AmigoJack: alternative identification with link

{{FormatInfo
|formattype=electronic
|subcat=Video
|extensions={{ext|rm}}, {{ext|ra}}, {{ext|rma}}, {{ext|ram}}, {{ext|rv}}, {{ext|rmvb}}
|mimetypes={{mimetype|application/vnd.rn-realmedia}}, {{mimetype|audio/application/x-pn-realmedia}}, others
|pronom={{PRONOM|x-fmt/190}}, {{PRONOM|fmt/404}}
}}
'''RealMedia''' (sometimes called '''RMFF''') is a multimedia container format associated with the RealVideo/RealAudio/RealPlayer ecosystem.

== Disambiguation ==
At the end user level, a RealMedia file is likely to be described as being in '''RealVideo''' (if it contains video) or '''RealAudio''' (if it contains only audio) format, instead of "RealMedia". But note that the terms ''RealVideo'' and ''RealAudio'' can also encompass other things, such as codecs, and the older [[RealAudio]] format.

''RealMedia'' can mean just the (newer) format with signature ".RMF", or it can be expanded to also encompass the older audio-only [[RealAudio]] format with signature ".ra". This article is mainly about the newer format. For the older format, see [[RealAudio]].

[[RealMedia HD]][https://www.realnetworks.com/realmediaHD] is the same file format but just starts with ASCII "{{magic|.RMP}}" instead of ASCII "{{magic|.RMF}}".

== See also ==
* [[RealMedia Variable Bitrate]]
* [[RealAudio]]
* [[RAM (RealAudio)]]
* [[RALF]]

== Identification ==
Files begin with [https://wiki.multimedia.cx/index.php/RealMedia#RealMedia_file_header_(.RMF_or_.RMP) ASCII "{{magic|.RMF}}" (normal) or ASCII "{{magic|.RMP}}" (HD)].

== Specifications ==
* [https://common.helixcommunity.org/2003/HCS_SDK_r5/htmfiles/rmff.htm RealMedia File Format (RMFF) Reference]
* [https://wiki.multimedia.cx/index.php/RealMedia MultimediaWiki article]
* [https://tools.ietf.org/html/draft-heftagaub-rmff-00 RealMedia File Format] (RFC draft)

== Software ==
* [[VLC]]

== Sample files ==
* Most files at https://samples.ffmpeg.org/real/
* https://telparia.com/fileFormatSamples/audio/realAudio/
* https://telparia.com/fileFormatSamples/video/realVideo/

== Links ==
* [[Wikipedia: RealAudio]]
* [[Wikipedia: RealMedia]]
* [https://wiki.videolan.org/RealMedia/ VideoLAN Wiki article]

See also [[RealAudio#Links]].

[[Category:Audio and Music]]

Graph2Font

2023-11-21T18:20:05Z

AmigoJack: Engrish

{{FormatInfo
|name=Graph2Font
|formattype=electronic
|subcat=Graphics
|extensions={{ext|g2f}} {{ext|mch}}
}}
'''Graph2Font''' is a graphics program for Windows.

== Identification ==
<code>.g2f</code> files begin with ASCII "{{magic|G2FZLIB}}".

== Software ==
* [[RECOIL]]

== Sample files ==
* https://telparia.com/fileFormatSamples/image/graph2Font/

== Links ==
* [http://g2f.atari8.info/ Graph2Font Website]

AFCP

2023-10-27T21:58:32Z

AmigoJack: AXS guesswork

{{FormatInfo
|formattype=electronic
|subcat=Metadata
|released=1992?
}}
'''AFCP''' (AXS File Concatenation Protocol) is a metadata format for image files. Its main uses are embedding [[IPTC-IIM]] data, and thumbnail images. It's not clear what ''AXS'' refers to (since it [https://en.wikipedia.org/wiki/Todd_Lawrence_Carter#AXS was a business in Berkely, CA, US] the initials may refer to [https://axs.berkeley.edu "Alpha Chi Sigma", a university's fraternity]).

It is designed to be used as a "trailer" that can be appended to a number of different file formats. It could potentially be used in other ways, and even has [[TIFF]] tag 34152 assigned to it. But it is not a ''self-contained'' format (it contains pointers relative to the beginning of the ''file''), so such use would be problematic.

== Identification ==
In most cases, the signature "{{magic|ASX!}}" or "{{magic|ASX*}}" appears beginning 12 bytes from the end of the file.

== Specifications ==
* [https://www.slideshare.net/tocarte/axs-afcp-spec AXS File Concatenation Protocol]
** [https://web.archive.org/web/20080828211305/http://www.tocarte.com/media/axs_afcp_spec.pdf Another copy], from archive.org

== Software ==
* [https://exiftool.org/ ExifTool]
* [https://www.logipole.com/metadata++-en.htm Metadata++]

== Sample files ==
* [https://github.com/exiftool/exiftool/blob/master/t/images/AFCP.jpg AFCP.jpg]
* [https://commons.wikimedia.org/wiki/File:U.S._Department_of_Energy_-_Science_-_298_022_004_(30871102953).jpg]

== Links ==
* [https://exiftool.org/TagNames/AFCP.html Information from ExifTool]

[[Category:Graphics]]

Fujifilm RAF

2023-10-25T15:30:00Z

AmigoJack: correct magic with space

{{FormatInfo
|formattype=electronic
|subcat=Cameras and Digital Image Sensors
|extensions={{ext|raf}}
|pronom={{PRONOM|fmt/642}}
}}
'''RAF''', or '''Fujifilm RAW''', is a raw image format used by some Fujifilm digital cameras.

== Format ==
Byte order is Motorola (Big Endian)

* 16 bytes string to identify the file (magic)
** "<code>FUJIFILMCCD-RAW </code>"
* 4 bytes
** Format version. E.g. "<code>0201</code>"
* 8 bytes
** Camera number ID. E.g. "<code>FF389501</code>"
* 32 bytes for the camera string, \0 terminated
* offset directory
** Version (4 bytes) for the directory. E.g. "<code>0100</code>" or "<code>0159</code>".
** 20 bytes "unknown"
** Jpeg image offset (4 bytes)
** Jpeg Image length (4 bytes)
** CFA Header Offset (4 bytes)
** CFA Header Length (4 bytes)
** CFA Offset (4 bytes)
** CFA Length (4 bytes)
** rest unused
* Jpeg image offset
** Exif JFIF with thumbnail + preview
* CFA Header offset - Big Endian
** 4 bytes: count of records
** Records, one after the other
*** 2 bytes: tag ID
*** 2 bytes: size of record (N)
*** N bytes: data
* CFA Offset
** Uncompressed RAW

== Software ==
* Refer to [[Cameras and Digital Image Sensors#Software|Cameras and Digital Image Sensors]].

== Sample files ==
* [http://www.photographyblog.com/reviews/fujifilm_x_e1_review/sample_images/ Fujifilm X-E1 Review] → Sample RAW Images
* [http://www.photographyblog.com/previews/fujifilm_x_t1_photos/ Fujifilm X-T1 Sample Images] → Fujifilm X-T1 RAW Images
* [http://www.rawsamples.ch/index.php/en/fuji RAW-Samples: Fuji]
* http://digikam3rdparty.free.fr/TEST_IMAGES/ → [http://digikam3rdparty.free.fr/TEST_IMAGES/RAW/HORIZONTAL/ RAW/HORIZONTAL/], [http://digikam3rdparty.free.fr/TEST_IMAGES/RAW/VERTICAL/ RAW/VERTICAL/], [http://digikam3rdparty.free.fr/TEST_IMAGES/FUJI-X10/ FUJI-X10/]
* https://telparia.com/fileFormatSamples/image/raf/

== Links ==
* [https://web.archive.org/web/20090214101740/http://crousseau.free.fr/imgfmt_raw.htm Formats d'image - RAW] (from archive.org)

RCL

2023-10-25T14:58:59Z

AmigoJack: UTF-16 warning

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|rcl}}
|released=2003
}}

Roxio Easy Media Creator<ref>https://web.archive.org/web/20030602181520/http://www.roxio.com:80/en/products/ecdc/index.jhtml</ref> Classic versions 6 & 7 uses the extension RCL for their data/audio CD project files. [[Easy CD Creator]] software allowed the user to create a Data or Audio CD layout by adding files or music in order to burn a disc. This layout could be saved for later use. The layout only referenced the file location and not the files themselves.

==File Identification==
RCL 7 files are not compatible with earlier [[CL5]]. Later versions of Roxio will open RCL and [[CL5]] project files<ref>https://forums.support.roxio.com/topic/91082-rox-and-roxio-sample-files-to-download/</ref>, but may not open if they are audio projects<ref>https://forums.support.roxio.com/topic/8853-creator-classic-wont-read-70-rcl-files/</ref>. The last suite to have Creator Classic and use .RCL files was Creator 2012.<ref>https://forums.support.roxio.com/topic/91082-rox-and-roxio-sample-files-to-download/</ref>

Version 6 & 7 RCL files have different structures.
* Version 6 files seem to have the header value {{magic|10000000 01000000 01000000 11000000}} followed by plain text indicating directory paths to content to be burned to disc. Can be opened in [[CL5]] software.
* Version 7 files seem to have the header value {{magic|FFFE2300}} followed later by the plain text "[RoxioINF20] [ProjectSettings] RCLVer=70"
* Later versions of Easy Media Creator saved in the [[ROXIO]] format, but also included Creator Classic which saved to RCL. These RCL files have the header value {{magic|FFFE2300}} followed later by the plain text "[RoxioINF80] [ProjectSettings] RCLVer=80"

Be aware that the bytes {{magic|0xFF 0xFE 0x23 0x00}} equal an [[UTF-16]] text encoding with U+FEFF as BOM (for [[Endianness|Intel=LE]] byte order) and U+0023 (hash symbol). Checking these 4 bytes alone may misidentify many text files (save the file content {{magic|#}} in Windows' Notepad with the encoding "Unicode" and you get exactly this signature in bytes).

==Software==
* [https://archive.org/details/PlextorDVDWritingSoftwareDVD Easy Media Creator 7 software]
* [https://web.archive.org/web/20120114150733/http://www.audiodude.nl/?p=597 Code written to convert RCL 7 files to later [[ROX]] format]

==References==
<references/>

[[Category:Roxio]]

NRG

2023-10-25T14:16:10Z

AmigoJack: more precise identification

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|nrg}}
|wikidata={{wikidata|Q1213743}}
|pronom={{PRONOM|fmt/1743}}
}}
'''NRG''' is a [[CD]] image format associated with the ''Nero Burning ROM'' software.

== Identification ==
An ASCII signature appears near the end of the file:
* either "{{magic|NERO}}" with 4 bytes following (32 bit offset),
* or "{{magic|NER5}}" with 8 bytes following (64 bit offset).
Nero's file format is built on this footer and has no header.

== Sample files ==
* [https://www.gnu.org/software/libcdio/ libcdio] → [https://ftp.gnu.org/gnu/libcdio/libcdio-2.0.0.tar.bz2 libcdio-2.0.0.tar.bz2] → test/data/*.nrg
* https://telparia.com/fileFormatSamples/archive/nrg/test.nrg

== Software ==
* [https://github.com/saur0n/nrg2iso NRG to ISO]

== Links ==
* [[Wikipedia: NRG (file format)]]
* [https://www.nero.com/enu/products/nero-burning-rom/ Nero Burning ROM website]

[[Category:Nero]]

ISZ

2023-10-25T13:58:31Z

AmigoJack: identification

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
}}

"This specification is intended to define an interoperable ISO CD/DVD image storage and transfer format."
* http://www.ezbsystems.com/isz/iszspec.txt

== Identification ==

Files start with 4 bytes ASCII {{magic|IsZ!}}.

GI

2023-10-25T13:50:34Z

AmigoJack: typo; hex prefixes

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|gi}}
|wikidata={{wikidata|Q105857991}}
}}

Roxio Creator software can save an optical disc i_ its own proprietary image format called "Sonic Global Image File". Data or Audio disc can be saved to the format. Files have the extension .GI.

==File Identification==

GI files have the hex values "{{magic|0xDA 0xDA 0xFE 0xFE}}" for the first 4 bytes<ref>https://git.cgsecurity.org/cgit/testdisk/tree/src/file_gi.c</ref>.

==Software==
* [https://archive.org/details/DELL_OEM_Roxio_Creator_DE_10.3_-_Win95_ENG Roxio Creator DE 10.3 Software]
* [https://forums.support.roxio.com/topic/52235-is-it-possible-to-convert-a-gi-file-to-an-iso-file/ Conversion Solutions]

==References==
<references/>

[[Category:Roxio]]

Quick Release Sector Transfer

2023-10-25T11:16:44Z

AmigoJack: correct description length as per sample file

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
}}

The QRST disc image format was used by Compaq to distribute disk images of diagnostic software. The file QRST.EXE or QRST5.EXE would be supplied with the disc images to write them to a floppy drive.

== Identification ==

QRST files start with the 4-character ASCII string <code>QRST</code>. The first character of the file extension is an underscore, followed by a 2-digit hexadecimal (version <5) or decimal (version 5) volume number.

== Structure ==

=== File header ===

The file begins with a 796-byte header:

{| class="wikitable"
! Offset
! Size
! Description
|-
|0x000 || 4 bytes || Magic number, <code>QRST</code>
|-
|0x004 || 4 bytes || Version number, floating point
|-
|0x008 || 4 bytes || Checksum (version <5), unused (version 5)
|-
|0x00C || 1 byte || Disk capacity:
{| class="wikitable"
! Value
! Meaning
|-
|0 || unknown
|-
|1 || 360k
|-
|2 || 1.2M
|-
|3 || 720k
|-
|4 || 1.4M
|-
|5 || 160k
|-
|6 || 180k
|-
|7 || 320k
|}
|-
|0x00D || 1 byte || Current volume number in set
|-
|0x00E || 1 byte || Count of volumes in set
|-
|0x00F || 60 bytes || Description, ASCIIZ
|-
|0x04B || 720 bytes || Disk label, ASCIIZ
|-
|0x31B || 1 byte || Always 0 (version <5), always 2 (version 5)
|}

Version 5 extends the header with an additional 25 bytes:

{| class="wikitable"
! Offset
! Size
! Description
|-
|0x31C || 1 byte || Unknown
|-
|0x31D || 4 bytes || Start of compressed data
|-
|0x321 || 4 bytes || Length of compressed data
|-
|0x325 || 4 bytes || [[CRC-32]] of compressed data
|-
|0x329 || 4 bytes || Unused (start)
|-
|0x32D || 4 bytes || Unused (length)
|-
|0x331 || 4 bytes || Unused (CRC-32)
|}

=== Version <5 data ===

In versions below 5, the header will be followed by the data tracks. These can be in one of three forms:

==== Uncompressed track ====
{| class="wikitable"
! Offset
! Size
! Description
|-
|0x00 || 1 byte || Cylinder
|-
|0x01 || 1 byte || Head
|-
|0x02 || 1 byte || 0 indicates uncompressed track
|-
|0x03 || calculated from disk type in header || Track data, uncompressed
|}

==== Blank track ====
{| class="wikitable"
! Offset
! Size
! Description
|-
|0x00 || 1 byte || Cylinder
|-
|0x01 || 1 byte || Head
|-
|0x02 || 1 byte || 1 indicates blank track
|-
|0x03 || 1 byte || Filler byte
|}

==== Compressed track ====
{| class="wikitable"
! Offset
! Size
! Description
|-
|0x00 || 1 byte || Cylinder
|-
|0x01 || 1 byte || Head
|-
|0x02 || 1 byte || 2 indicates compressed track
|-
|0x03 || 2 bytes || Length of compressed data
|-
|0x05 || As specified above || Compressed data
|}

The compressed data stream consists of alternating literal runs (a byte giving the length of the run, followed by that number of bytes data) and compressed runs (two bytes; first gives number of repeats, second gives byte to repeat).

=== Version 5 data ===

In version 5, the data is an entire disk image compressed with PKWARE Data Compression Library's Implode. (This is not the same as PKZIP's Implode.)

=== Checksum ===

In versions below 5, the checksum is the sum of all bytes on the disc, each byte multiplied by (1 + its offset on the disc). So for a 360k disc it would be (1 * first byte of first sector) + (2 * second byte of first sector) + ... + (368640 * last byte of last sector).

In version 5, the [[CRC-32]] covers the compressed data.

=== Multiple disc images in one file ===

At least one QRST file is known to exist which contains two disc images -- it has the structure of two separate QRST files concatenated together, each one describing itself as volume 1 of 1.

== Sample files ==

* [ftp://ftp.oldskool.org/pub/drivers/Compaq/Portable%20III/setup%20and%20diags/ Compaq Portable III setup and diagnostics]
* [https://ftp.zx.net.nz/pub/archive/ftp.hp.com/pub/softpaq/sp0000-0500/sp0484.zip QRST file containing two concatenated disc images]

User:AmigoJack

2023-10-20T12:37:28Z

AmigoJack: Created page with "== About me == I know Pascal since 1995 and up to its Delphi 7 dialect. Maintaining and heavily augmenting Mansion of Celebs (picture board) since 2010 and thus I know..."

== About me ==
I know [[Pascal]] since 1995 and up to its [[Delphi]] 7 dialect. Maintaining and heavily augmenting Mansion of Celebs (picture board) since 2010 and thus I know [[phpBB]]3.0.x inside out, resulting in knowing [[PHP]] up to 7.2, [[HTML#HTML_vs._XHTML|XHTML]] and [[Cascading Style Sheets|CSS]]3. I avoid frameworks for their added complexity and getting dependant on them, so I'm able to write code (Pascal, PHP, XHTML, CSS and most notably [[JS]]) in the most reliable and readible way. As a side effect I'm also fond of regular expressions, text encodings (i.e. [[Unicode#Encodings|UTF]]) and the Win32 API.

Solving problems mostly comes down at misunderstood or inexistent basics:

* Want to download via code without knowing how [[HTTP]] works? After I grasped how methods, status codes, headers and encodings work I was also able to achieve everything else, like writing mass down- and uploaders which are able to cope with unsuccessful cases.
* Want to extract file information without knowing file structures? After starting to read documentations about file formats I was able to parse them, then even deal with corrupt data. Now I can spot dozens of formats by looking at the binary data and extract whatever I want, no matter how recursively containers are stored (i.e. [[XMP]] in [[ID3]] in [[MP3]] in [[MKV]]).
* Want to find duplicates without having an idea how? My learning curve led me thru hashing file contents to recognizing file contents and ignoring its metadata (i.e. audio files ignoring their tags) or hashing the rendered data (i.e. picture bitmaps from either [[JPEG]] or [[PNG]] or [[GIF]]).

I spent much time with anything [[ID3]] related, including informal standards and how to expect anything in an [[MP3]] file (including [[APE tag|APE]], or a {{magic|*[[RIFF]]}} identification in very old files that were embedded into a [[WAV]] container).

ID3

2023-10-20T12:18:45Z

AmigoJack: adding informal formats; more correct way to skip ID3v2

{{FormatInfo
|formattype=electronic
|subcat=Metadata
|extensions={{ext|mp3}}, others
|locfdd={{LoCFDD|fdd000106}}, {{LoCFDD|fdd000107}}, {{LoCFDD|fdd000108}}
|released=1996
|kaitai struct=id3v1_1
|wikidata={{wikidata|Q1054220}}
}}
'''ID3''', or '''ID3 tag''', is a metadata format, mainly used in [[MP3]] audio files. It stores information such as the song title, artist, and album.

Although designed for use with (and named after) MP3, ID3 is sometimes used with other audio formats. This can be done in two fundamental ways:
* Embedding the ID3 data inside the file, in a manner appropriate for that audio format. For example, [https://samples.libav.org/asf-wmv/wma_with_cover_art/wma_with_ID3_APIC.wma here] is a [[WMA]] file containing ID3 data.
* Prepending and/or appending the ID3 data to the file, MP3-style. This practice is not necessarily approved by any standard, but it has been done, for example with [[Ogg]] and [[FLAC]]. Here, the tail is wagging the dog, and ID3 can be thought of as a container format for an arbitrary audio format.

== Format details ==
There are two major versions. ID3v1 defines a fixed-length data block that is always placed at the end of the file. ID3v2, which has very little in common with ID3v1, defines a block with variable-length frames and allows more flexibility and verbosity. ID3v2 data usually appears at the beginning of the file. It is possible, and common, for a file to have both ID3v1 and ID3v2 metadata.

As of 2017, there are three versions of ID3v2 to be aware of: v2.2.x, v2.3.x, and v2.4.x. These formats have some critical differences, and are definitely ''not'' compatible with each other.

== Identification ==
* For an MP3 file with an ID3v1 tag, ASCII "{{magic|TAG}}" appears beginning 128 bytes from the end of the file.
* An MP3 file with an ID3v2 tag usually begins with ASCII "{{magic|ID3}}".
* Alternatively, the signature "{{magic|3DI}}" could appear 10 bytes from the ''end'' of the file, or 138 bytes from the end of the file if there is also an ID3v1 tag. This is much less likely.

There are other (rare) ways to use ID3v2, not covered by the above identification logic.

=== How to skip past an ID3v2 segment ===
To identify an audio file's format, it is best to skip past any ID3v2 segment at the beginning of the file before looking for a magic signature, and not just assume that ID3 implies MP3. Unfortunately, doing so is not trivial. Here is an attempt to summarize the algorithm:
# Let OFFSET = 0.
# Read and remember the first 10 bytes of the file.
# If bytes 0-2 are not ASCII "ID3", stop. An ID3v2 segment is not present.
# Let OFFSET = 10 (for the 10-byte header).
# Decode bytes 6-9 as a 32-bit "synchsafe int" (which are 28 bit of size, because you only read 7 bit of each 4 bytes, refer to any ID3v2 spec). Let OFFSET = OFFSET + this decoded int.
# If the 0x10 bit of byte 5 is set, the file's last 10 bytes have an ID3 footer, which is not audio data.
# OFFSET is now behind the ID3v2 tag. Although uncommon, the docs nowhere forbid to have multiple ID3v2 tags (f.e. v2.2 and v2.3 following), so the whole scannings may start anew at the current offset and you should go back to 1. while your true exit condition is 3. when not seeing the "ID3" magic.

== Similar/Depending, but informal formats ==
All are in front of an ID3v1.0 or ID3v1.1 tag at the end of the file, but there's no priority between them and they're somewhat mutually exclusive:
* [http://www.birdcagesoft.com/ID3v12.txt ID3.1v2], extending ID3v1 fields by 15-30 more bytes. Identification: {{magic|EXT}} 128 bytes in front.
* [https://web.archive.org/web/20120310015458/http://www.fortunecity.com/underworld/sonic/3/id3tag.html Enhanced TAG], extending ID3v1 fields by 60 more bytes. Identification: {{magic|TAG+}} 227 bytes in front.
* [https://web.archive.org/web/20220217102229/https://id3.org/Lyrics3 Lyrics3], adding subtitles=lyrics with a precision down to 1 second. Identification: {{magic|LYRICSEND}} in front.
* [https://web.archive.org/web/20220416222957/https://id3.org/Lyrics3v2 Lyrics3v2], adding subtitles=lyrics, allowing up to 250 bytes for fields, adding cover picture. Identification: {{magic|LYRICS200}} in front.

== Specifications ==
* [http://id3.org/Developer%20Information ID3.org Developer Information]
** [http://id3.org/ID3v1 ID3v1]
** [http://id3.org/id3v2-00 ID3v2.2.0]
** ID3v2.3.0: [http://id3.org/d3v2.3.0 Plain text] · [http://id3.org/id3v2.3.0 HTML]
** ID3v2.4.0: [http://id3.org/id3v2.4.0-structure Main Structure] · [http://id3.org/id3v2.4.0-frames Native Frames]
* [http://id3lib.sourceforge.net/id3/id3v2-00.txt ID3 tag version 2] (Another copy of v2.2.0)
* [http://mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm#MPEGTAG MPEG Audio Tag ID3v1]
* [http://wiki.hydrogenaud.io/index.php?title=ID3v1 Hydrogenaudio Knowledgebase: ID3v1]
* [http://wiki.hydrogenaud.io/index.php?title=ID3v1.1 Hydrogenaudio Knowledgebase: ID3v1.1]
* [http://wiki.hydrogenaud.io/index.php?title=ID3v2 Hydrogenaudio Knowledgebase: ID3v2]
* [https://formats.kaitai.io/id3v1_1/ Kaitai Struct: ID3v1.1]
* [https://formats.kaitai.io/id3v2_3/ Kaitai Struct: ID3v2.3]
* [https://formats.kaitai.io/id3v2_4/ Kaitai Struct: ID3.2.4]

== Software ==
* [http://id3lib.sourceforge.net/ id3lib]
* [http://taglib.github.com/ TagLib]
* [https://www.logipole.com/metadata++-en.htm Metadata++]

''[Ed. note: There are many utilities that can read and write ID3 tags, including Windows Explorer to some extent. We suggest searching the web.]''

== Resources ==
* [http://id3.org/ ID3.org]
* [[Wikipedia:ID3|Wikipedia article]]
* [http://www.codinghorror.com/blog/2006/08/a-spec-tacular-failure.html Coding Horror: A Spec-tacular Failure]
* [https://underjord.io/id3-specification-and-speculation.html What ID3v2 could have been]

[[Category:Audio and Music]]

XP3

2023-10-19T15:02:53Z

AmigoJack: identification, source link

{{FormatInfo
|subcat=Archiving
|extensions={{ext|xp3}}
}}

'''XP3''' is an archiving format used in the [[KiriKiri Adventure Game System]], a Japanese interactive fiction engine. Information about it in English is hard to find.

== Identification ==
Files start with ASCII {{magic|XP3}}, followed by the Windows line break bytes {{magic|0x0D 0x0A}} and the 6 bytes {{magic|0x20 0x0A 0x1A 0x8B 0x67 0x01}}.

== Links ==
* [http://www.insani.org/tools/ Some related tools]
* [https://github.com/awaken1ng/krkr-xp3/blob/master/structs/constants.py Signature definition in Python]

RARC

2023-10-18T15:18:05Z

AmigoJack: identification

{{FormatInfo
|formattype=electronic
|subcat=Archiving
|extensions={{ext|arc}}
}}

RARC is an archive file developed by Nintendo, appearing in many games on the Wii and Gamecube. It is often compressed using the [[Yaz0]] compression format, whereupon it takes the extension .szs.

== Identification ==
Files start with ASCII {{magic|RARC}}.

== Tools that handle RARC files ==
*[http://www.wiibrew.org/wiki/ARCTool ARC Tool by tpw_rules]
*[http://www.amnoid.de/gc/ Szs tools by thakis contains a "RARC Dump" tool]
*[https://szs.wiimm.de/ Wiimms SZS Tools, by Wiimm]

== Further Reading ==
*[http://www.amnoid.de/gc/Rarc.txt Original documentation and specs written by thakis]
* [http://wiki.tockdom.com/wiki/RARC_(File_Format) RARC on The Custom Mario Kart Wiki]

[[Category:Game data files]]
[[Category:Nintendo]]

PAK (ARC extension)

2023-10-18T14:21:14Z

AmigoJack: fixing hex prefixes

{{FormatInfo
|formattype=electronic
|subcat=Archiving
|extensions={{ext|pak}}, {{ext|sdn}}
|released=1988
}}
'''PAK''' is a DOS utility for managing compressed archive files, developed by NoGate Consulting. It is also the name of one of the file formats it supports: .PAK format.

PAK format is an extension of [[ARC (compression format)|ARC]] format. The differences are that it may use some PAK-specific compression methods (see below), and that it has some features made possible by "extended records" stored after the end-of-archive marker.

PAK was originally named '''GSARC''' (and used filename extension .ARC), but was quickly renamed to PAK (and the default extension changed to .PAK).

See [[ARC (compression format)|ARC]] for more information relevant to PAK format. See also [[SDN (SDN Project)]].

== Disambiguation ==
See [[PAK]] for more formats named PAK.

== Format details ==

=== Compression methods ===
ARC compression methods unique to PAK:

{| class="wikitable"
! ID !! Name !! Description and remarks
|-
|10 || Crushed || [[RLE90]] + [[LZW]] (or [[LZMW]]?)
|-
|11 || Distilled || [[LZ77 with Huffman coding|LZ77 + static Huffman coding]]. Introduced in PAK v2.0.
|}

For other ARC compression methods, see [[ARC (compression format)#Compression methods]].

== Self-extracting archives ==
All versions of PAK and GSARC can create self-extracting [[MS-DOS EXE|EXE]] archives, either with the <code>/EXE</code> option, or the included EXEMAKE.EXE utility. The original distribution files (e.g. PAK251.EXE) use this format.

Such archives contain an embedded PAK file, with apparently one special case: PAK v1.6 (and only that version) when the file includes remarks (comments). In that case, the remarks are interleaved with the member files in a way that is not normal for PAK format.

== Identification ==

PAK format files made by PAK/GSARC v1.0 typically start with bytes <code>0x1a 0x0a</code>, and end with <code>0x1a 0x00</code>.

Files made by PAK v1.5–1.6 typically start with <code>0x1a 0x0a</code>, and end with <code>0xfe 0x00</code>.

Files made by PAK v2.0+ typically start with <code>0x1a 0x0b</code>, and end with <code>0xfe 0x00</code>.

A file that ends with <code>0xfe 0x00</code> could also be identifiable as PAK format if the first byte is <code>0x1a</code> and the second is <code>0x02</code>, <code>0x08</code>, or <code>0x09</code>. That could happen if the first member file was not compressible, or was compressed with non-default options.

== Specifications ==
The PAK.DOC file contained in the v2.51 distribution includes basic information about .PAK/.ARC format, including the extended records. It does not document the compression schemes in detail.

== Software ==
* {{CdTextfiles|hof91/ARC/GSARC10.EXE|GSARC v1.0}} (1988-10-13) (DOS binary)
* PAK (DOS binaries)
** {{CdTextfiles|hof91/ARC/PAK10.EXE|v1.0}} (1988-10-17)
** {{CdTextfiles|rbbsv3n1/pc_s/pak16.zip|v1.6}} (1989-01-24)
** {{CdTextfiles|rbbsv3n1/pc_s/pak210.exe|v2.10}} (1989-08-10)
** {{CdTextfiles|rbbsv3n1/pc_s/pak250.exe|v2.50}} (1990-09-20)
** {{CdTextfiles|simtel/simtel20/MSDOS/ARCHIVRS/PAK251.EXE|v2.51}} (1990-10-08)
*** {{CdTextfiles|ftp.wwiv.com/pub/COMPRESS/PAK251.EXE|Another copy}}, packaged differently
* [[The Unarchiver]] - Supports the PAK-specific compression schemes

== Sample files ==
* {{CdTextfiles|carousel/ATARI/ARC2PAK1.PAK|ARC2PAK1.PAK}}
* [{{SACFTPURL|utiltext|asa57.zip}} asa57.zip] → ASA57U.EXE - Example of a self-extracting PAK archive

Quake PAK

2023-10-18T13:56:32Z

AmigoJack: warning about similar identifications

{{FormatInfo
| name = Quake PAK
| formattype = electronic
| subcat = Game data files
| subcat2 =
| subcat3 =
| subcat4 =
| subcat5 =
| thiscat =
| extensions = {{ext|pak}}
| mimetypes =
| locfdd =
| fourccs =
| pronom =
| type code =
| uniform type =
| kaitai struct = quake_pak
| conforms to =
| released =
| image =
| caption =

| magic = PACK
}}

'''Quake .pak''' is the container file format for storing game assets in versions 1 and 2 of [https://en.wikipedia.org/wiki/Id_Tech ID Tech] game engine and some derivatives of it, including following games:

* [[Quake]]
* [[Quake 2]]
* [[Hexen II]]
* [[Half-Life]]

Later Id Tech games (starting from Quake 3/ID Tech 3) switched to [[ZIP]] format with '''[[Quake PK3|.pk3]]''' extension.

== Description ==
This file format is very simple. File starts with <code>PACK</code> magic string (4 octets), then 4-byte offset to file table and 4-byte length (measured in bytes) of it.

File table consists of entries consisting of:

* file name, including path: 56-byte null-terminated string. No leading slash.
* file contents offset (from beginning of .pak file), 4 bytes
* file contents length, 4 bytes

All numbers are [[Endianness|little-endian]]. Since each file entry of the table consists of 64 bytes, the header's file table length (offset 8 to 11) must always be a multiple of 64, and most likely never 0. If the 4 bytes for the file table offset (offset 4 to 7) would be <code>0x02 0x00 0x00 0x00</code> or <code>0x03 0x00 0x00 0x00</code> it would also match [[Git]]'s .pack files. If the first byte is <code>0x00</code> it would also match [[Packdir]].

== Software ==
* [http://www.watto.org/game_extractor.html Game Extractor]

== Sample files ==
* https://telparia.com/fileFormatSamples/archive/quakePAK/

== Links ==
* [https://quakewiki.org/wiki/.pak .pak — Quake Wiki]
* [https://web.archive.org/web/20160711041711/http://debian.fmi.uni-sofia.bg/~sergei/cgsr/docs/pak.txt Quake PAK Format] (from archive.org)

[[Category:Id Software]]
[[Category:Archiving]]

Git

2023-10-18T13:48:20Z

AmigoJack: adding link, warning to false identifications

{{DISPLAYTITLE:git}}
{{FormatInfo
|formattype=electronic
|subcat=Development
|extensions={{noext}}, {{ext|pack}}, {{ext|idx}}
|released=2005
}}
'''git''' is an open-source revision control system for software development, originally developed by Linus Torvalds for tracking [[Linux]] kernel sources, before being widely adopted by many other projects and companies.

== Specifications ==
* [http://git-scm.com/docs/gitrepository-layout GIT repository layout]
* [https://github.com/git/git/blob/master/Documentation/technical/pack-format.txt Git pack format]
* [https://git-scm.com/docs/pack-format pack-*.pack files format] (identification easily clashes with [[Packdir]] and [[Quake PAK]])
* [https://codewords.recurse.com/issues/three/unpacking-git-packfiles/ Unpacking Git packfiles]
* [http://www.gitguys.com/topics/what-is-the-format-of-a-git-blob/ What is the format of a git “blob”?]
* [https://git-scm.com/docs/gitignore gitignore format]

== Related formats ==
* [[SHA-1]] - Used to create object identifiers
* [[zlib]] - Used to compress data
* [[Virtual File System for Git]]

== Links ==
* [[Wikipedia:Git (software)|Wikipedia article]]
* [https://git-scm.com/ Official site]
* [https://libgit2.org/ libgit2]
* [http://stevelosh.com/blog/2013/04/git-koans/ Git koans]
* [https://bup.github.io/ bup: backup system based on Git packfile]
* [http://think-like-a-git.net/ Think like a Git: A guide for the perplexed]

PackDir

2023-10-18T13:44:46Z

AmigoJack: distinction from Quake PAK and Git Pack

{{FormatInfo
|formattype=electronic
|subcat=Archiving
}}
'''PackDir''' is an archiving tool for RISC OS, and its associated file format. It can compress file using an [[LZW]] algorithm, or store uncompressed files.

The LZW algorithm is the variant used in the [[Zoo]] archiver, except that the "max bits" parameter is configurable.

Its [[RISC OS filetype]] is 68E.

== File format ==
''This section contains reverse-engineered information about the format.''

32bit ints are in LSB format. Strings are NULL-terminated ASCII.

File/directory dates and times are stored in a RISC OS format: The low 8 bits of the "load" address, combined with the "exec" address, form a 40-bit integer representing the number of 0.01-second intervals since the beginning of the year 1900.

File format:
Header
object_entry_1
object_entry_2
...
object_entry_N

Header:
String: "PACK\0"
32bit_int: LZW maxbits - 12

object_entry:
string: object_name (including trailing NULL)
32bit_int: load (RISC OS load address)
32bit_int: exec (RISC OS exec address)
32bit_int: original_file_length if this object is a file, number_of_child_entries otherwise
32bit_int: attributes (RISC OS read/write permissions)
32bit_int: entry_type: 1 == directory, 0 == file. NB: This field is missing for the first entry in the file -
the first entry is always a directory

If the entry is a file, then these fields follow:
32bit_int: Compressed_file_length or special code - If this field is -1 the file is not compressed,
otherwise compressed with LZW.
N bytes: archived file data. N == compressed_file_length if file is compressed, otherwise original_file_length

== Identification ==
Files begin with "{{magic|PACK}}", followed by {{magic|0x00}}. Note that this is not enough to distinguish them from [[Quake_PAK]] pack format. However, it cannot be a [[Git]] pack format, because Git expects a 4 byte version number in big endian, which means byte {{magic|0x02}} or {{magic|0x03}} would be there.

== Software ==
* [http://www.zeridajh.org/software/packdir/index.htm PackDir download page] (RISC OS software)
* [https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20SparkFS%20(self-extracting) SparkFS]
* [https://github.com/mjwoodcock/riscosarc riscosarc]
* {{Deark}}

== Example files ==
* [http://www.zeridajh.org/software/earthmap/downloads/earthmap_120.bin earthmap_120.bin]
* {{ArcadeBBSLink|079556|MyXCard95A}}

[[Category:RISC OS]]

MDCD

2023-10-18T12:13:52Z

AmigoJack: more precise identification, hints for using compilers from this century

{{FormatInfo
|formattype=electronic
|subcat=Archiving
|extensions={{ext|md}}, {{ext|cd}}, others
|released=1988
}}
'''MDCD''' is a compressed archiving utility, and its associated native file format. It was developed by Mike Davenport.

It was apparently used in some capacity by the Links 386 Pro video game.

== Format details ==
The compression scheme is [[LZW]] with an 8K table, possibly identical to that used by [[Zoo]]. The CRC algorithm is [[CRC-16#CRC-16/XMODEM|CRC-16/XMODEM]].

== Identifiers ==
The default filename extension is '''.md''', though some of the example commands inexplicably use '''.cd''' instead.

== Identification ==
* Files begin with the ASCII signature "{{magic|MDmd}}".
* Offset 5 should always be {{magic|0x01}} (the header type).
* Offset 6 and 7 have the bytes {{magic|0x7a 0x00}}, which is a word telling you that the whole header sizes 122 bytes.
* Offset 24 has the byte {{magic|0x00}} (uncompressed) or {{magic|0x01}} (compressed) for the stored content. If uncompressed, two following pairs of 4 bytes must be identical (same file size for original and compressed). If compressed, the former should always be bigger than the latter, because MDCD will never store compressed files which turn out bigger than their original.

== Specifications ==
* For information about the header format, see the source code, MDCD.PAS, look for "FileHeader = Record". As per Pascal for DOS the record is byte aligned, sizing 122 bytes in total (in FreePascal you'd need to define it as "Packed Record"). Type "DirStr" is a "String[67]" from the DOS unit. All "String[]" types store their length in a preceding byte, so "String[12]" means 13 bytes in total.

== Software ==
* {{CdTextfiles|megarom/megarom1/ARC_LBR/MDCD10.ZIP|MDCD v1.0}} - DOS binary + source code
* {{Deark}}

== Sample files ==
* https://telparia.com/fileFormatSamples/archive/mdcd/
* {{CdTextfiles|swextrav8/swextrav8-6/wingame2/lcd95.zip|lcd95.zip}} → CDGRAPHI.LZ
* {{CdTextfiles|ccbgames1994/golf/links108.zip|links108.zip}} → *.TIL

PAQ

2023-10-17T22:30:52Z

AmigoJack: identification as per KGB Archiver 2 beta 2 source code

{{FormatInfo
|formattype=electronic
|subcat=Archiving
|extensions={{ext|pa6}}, {{ext|pa7}}, {{ext|pa8}}, {{ext|paq8p}}, others
|released=2002
}}
:''For other "PAQ" formats, see [[oPAQue]], [[PAQJ]], and [[Quantum compressed archive]].''

'''PAQ''' is actually a whole series of different compression programs and their associated file formats, designed to achieve maximum compression (for which the various versions have won some awards) at the possible expense of being slow and taking a lot of memory. Since compatibility (either forward or backward) among the different PAQ versions was not preserved, there are a wide assortment of incompatible formats associated with this group of programs, with new versions devised to implement improved compression techniques or techniques carefully tailored for particular sorts of data without regard for retaining the ability to compress or decompress the files created by earlier versions.

Since PAQ is open-source, there have been "forks" producing yet more adapted and incompatible versions.

The author of PAQ (Matt Mahoney) also created [[BARF]] as a sort of ''reducio ad absurdum'' of file compression techniques.

== Identification ==
* PAQ1, PAQ2, PAQ3, PAQ4 and PAQ5 files start with ASCII {{magic|PAQ}}, followed by ASCII {{magic|1}} to {{magic|5}} respectively, followed by a Windows line break (bytes {{magic|0x0d 0x0a}} = CRLF = \r\n).
* PAQ6 files start with ASCII {{magic|PAQ6 -}}, followed most likely by ASCII {{magic|0}} to {{magic|9}} for the chosen memory consumption model, followed by a Windows line break (bytes {{magic|0x0d 0x0a}} = CRLF = \r\n).
* PAQ7 files start with ASCII {{magic|paq7 -}}, followed most likely by ASCII {{magic|1}} to {{magic|5}} for the chosen memory consumption model, followed by a Windows line break (bytes {{magic|0x0d 0x0a}} = CRLF = \r\n).

== See also ==
* [[ZPAQ]]

== References ==
* [[Wikipedia:PAQ|Wikipedia article]]
* [http://mattmahoney.net/dc/ Official site]

[[Category:Compression research]]

KGB Archiver

2023-10-17T22:16:55Z

AmigoJack: distinguishing between version 1 and 2

{{FormatInfo
|formattype=electronic
|subcat=Archiving
|extensions={{ext|kgb}}
|released=2006
}}

The '''KGB Archiver''' is an archiving and compression program for MS Windows and Unix-like systems. The program supports the [[ZIP]] format, but also has its own native KGB format which is based on the algorithm of [[PAQ|PAQ6]]. This format is designed for high compression rather than speed of compression or decompression.

It doesn't appear to spy on you like its namesake in the old Soviet Union.

There hasn't been any update to it in a number of years now, and its official website is no longer up.

== Identification ==
* As per source code's "compress.cpp" for version 2 beta 2 from 2007-10-03 an archive starts with ASCII {{magic|KGB2}}.
* As per "compress.cpp" for version 1.2.1.24 from 2008-02-09 an archive starts with ASCII {{magic|KGB_arch -}} followed by an ASCII number most likely from {{magic|0}} to {{magic|9}} for the chosen memory consumption model.

== References ==
* [[Wikipedia:KGB Archiver|Wikipedia article]]
* [http://sourceforge.net/projects/kgbarchiver/ SourceForge project]

KGB Archiver

2023-10-17T21:58:32Z

AmigoJack: adding identification as per source code

{{FormatInfo
|formattype=electronic
|subcat=Archiving
|extensions={{ext|kgb}}
|released=2006
}}

The '''KGB Archiver''' is an archiving and compression program for MS Windows and Unix-like systems. The program supports the [[ZIP]] format, but also has its own native KGB format which is based on the algorithm of [[PAQ|PAQ6]]. This format is designed for high compression rather than speed of compression or decompression.

It doesn't appear to spy on you like its namesake in the old Soviet Union.

There hasn't been any update to it in a number of years now, and its official website is no longer up.

== Identification ==
As per source code's "compress.cpp" from 2007-10-03 an archive starts with ASCII {{magic|KGB2}}.

== References ==
* [[Wikipedia:KGB Archiver|Wikipedia article]]
* [http://sourceforge.net/projects/kgbarchiver/ SourceForge project]

HKI

2023-10-17T20:57:30Z

AmigoJack: adding identification as per executing freeware and creating HKI1 archive

{{FormatInfo
|subcat=Archiving
|extensions={{ext|hki}}
}}

'''HKI''' is the "native" format of WinHKI, another of the many archiving programs which supports a number of popular archive formats as well as introducing a new one of its own. It is named after the initials of its author (Hanspeter Karl Imp).

The WinHKI program (for Windows, as its name implies) comes in both free and paid versions. The paid version will create HKI archives using any of three compression techniques optimized for different sorts of files, while the free one will only compress with one of these techniques (though it will decompress archives compressed with any of them).

The compression methods are:

* '''HKI1''': best for [[MP3]], [[CD]] images. Supported by free version.
* '''HKI2''': best for programs and documents.
* '''HKI3''': best for some other sorts of data; very fast.

== Identification ==
Files start with ASCII {{magic|HKI}} and format '''HKI1'''<nowiki>'</nowiki>s following byte is {{magic|0x01}}, so '''HKI2''' and '''HKI3''' most likely have byte {{magic|0x02}} and {{magic|0x03}} at that position.

== Links ==
* [http://www.winhki.com/en/winhki1.htm Official site]