Some file formats have a unique extension. Some formats use three character extensions which are well known, so its not common for them to be used with other software. Take the extension PDF for example, pretty sure no one else will use it as it is so well known. Other extensions often get reused by a few different software titles. There are plenty of titles which use the DOC extension.
Part of defining a file format I come across is also defining other formats which use the same extension or the same basic patterns within the format. I want the format I am researching to be identified correctly, but I also don’t want other formats to falsely identify as them either.
When using the DROID tool, if a file can’t be identified using a signature, the tool will then look to see if the extension matches any formats within the PRONOM registry, if it finds one, it will identify as that format with the identification method as “Extension”. This can be confusing and dangerous.
The topic of a format came up recently in reference to the extension PAR. Lets take a look at what we know about files with the extension PAR. Using the handy tool at digipres.org, we can see there are many formats using the PAR extension.
Apparently many people like to use the extension with their software. One might think their files with the PAR extension have to be in this list, and they would be wrong in that assumption. The PRONOM registry has no records of any format using the PAR extension. Hopefully we can add a few to help with proper identification instead of using the extension only.
A PArchive or Parity Volume Set is a group of file formats used in error correction and data integrity. Only the first version used the PAR extension, it is now obsolete with version 2 being the last stable version.
hexdump -C archive.par | head
00000000 50 41 52 00 00 00 00 00 00 00 01 00 00 09 00 02 |PAR.............|
00000010 8f d0 ce 2e 21 db 3b e5 41 d5 18 be d3 0e 52 f0 |....!.;.A.....R.|
00000020 de b6 b3 9f 53 09 ff ba 16 6b ca d2 48 a6 ca 45 |....S....k..H..E|
00000030 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |................|
00000040 60 00 00 00 00 00 00 00 4e 00 00 00 00 00 00 00 |`.......N.......|
00000050 ae 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 4e 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |N...............|
00000070 45 16 01 00 00 00 00 00 76 da 44 2b 43 5f b5 bd |E.......v.D+C_..|
00000080 08 7b d2 b0 2e 16 7d 86 46 75 7b 79 f0 36 75 3b |.{....}.Fu{y.6u;|
00000090 a1 14 22 f3 0c 77 85 3c 70 00 61 00 72 00 2d 00 |.."..w.<p.a.r.-.|
hexdump -C Testing.docx.par2 | head
00000000 50 41 52 32 00 50 4b 54 84 00 00 00 00 00 00 00 |PAR2.PKT........|
00000010 76 1f e0 a4 5a 32 e0 84 d9 e9 32 32 06 9f 03 ff |v...Z2....22....|
00000020 71 48 73 d5 59 c6 ae 7c c7 21 3d ba 8d e5 ea 04 |qHs.Y..|.!=.....|
00000030 50 41 52 20 32 2e 30 00 46 69 6c 65 44 65 73 63 |PAR 2.0.FileDesc|
00000040 5d 74 b5 3d 64 ae 1f d8 ae 41 f1 8c 2f 7a cc c1 |]t.=d....A../z..|
00000050 27 9b bc 61 46 21 4d 37 a3 c7 f2 07 b4 b8 df 81 |'..aF!M7........|
Pretty straightforward. The only thing that would have made it easier is if the first version used “PAR1”, but be glad they didn’t as that signature is used by another!
hexdump -C null_list.parquet | head
00000000 50 41 52 31 15 00 15 18 15 18 2c 15 02 15 00 15 |PAR1......,.....|
00000010 06 15 06 00 00 02 00 00 00 02 00 02 00 00 00 02 |................|
00000020 01 26 42 1c 15 02 19 25 00 06 19 38 09 65 6d 70 |.&B....%...8.emp|
00000030 74 79 6c 69 73 74 04 6c 69 73 74 04 69 74 65 6d |tylist.list.item|
00000040 15 00 16 02 16 3a 16 3a 26 08 3c 36 02 00 00 00 |.....:.:&.<6....|
00000050 15 02 19 4c 48 0c 61 72 72 6f 77 5f 73 63 68 65 |...LH.arrow_sche|
00000060 6d 61 15 02 00 35 02 18 09 65 6d 70 74 79 6c 69 |ma...5...emptyli|
00000070 73 74 15 02 15 06 4c 3c 00 00 00 35 04 18 04 6c |st....L<...5...l|
00000080 69 73 74 15 02 00 15 02 25 02 18 04 69 74 65 6d |ist.....%...item|
00000090 6c bc 00 00 00 16 02 19 1c 19 1c 26 42 1c 15 02 |l..........&B...|
Apache Parquet is a more modern format used to store column-oriented data. At least they used a unique file extension!
Another common bit of software which uses the PAR extension is Solid Edge by Siemens. They use the PAR extension to encode their 3D parts format. For some reason this format still uses the OLE compound object container.
7z l tinyscrew.par
Path = tinyscrew.par
Type = Compound
Physical Size = 86528
Extension = compound
Cluster Size = 512
Sector Size = 64
Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
..... 31964 32256 PSMcluster0
..... 12 64 Versions
2001-12-19 15:44:14 D.... Display
2001-12-19 15:44:14 D.... ACIS
..... 8462 8704 ACIS/Solid1.sab
..... 238 256 PSMroots
2001-12-19 15:44:14 D.... Display/Cache0
2001-12-19 15:44:14 D.... Display/Styles
..... 1725 1728 Display/Styles/Library0
..... 12 64 Display/Styles/DefaultStyles
..... 88 128 Display/Cache0/Info
..... 4248 4608 Display/Cache0/L1-T1
..... 8 64 JSitesList
2001-12-19 15:44:14 D.... PARASOLID
..... 3389 3392 PARASOLID/STREAM434.D_B
..... 10402 10752 PARASOLID/STREAM434.P_B
..... 4 64 DocVersion2
..... 199 256 PSMclustertable
..... 8 64 PSMuserroots
..... 512 512 JVisibleData
2001-12-19 15:44:14 D.... PSMspacemap
..... 66 128 PSMspacemap/0x00002000
..... 6090 6144 PSMspacemap/0x00000000
..... 174 192 PSMspacemap/0x00004000
..... 4716 5120 PSMtypetable
..... 8 64 FamilyMembers
..... 8 64 BuildVersions
..... 150 192 PartsLiteData
..... 596 640 [5]C3teagxwOttdbfkuIaamtae3Ie
..... 476 512 [5]SummaryInformation
..... 12 64 PSMsegmenttable
..... 96 128 MSConvertedPropertyset
..... 148 192 [5]K4teagxwOttdbfkuIaamtae3Ie
..... 280 320 [5]DocumentSummaryInformation
..... 116 128 [5]SszbwomgY1udb2whAaq5u2jwCg
..... 264 320 [5]Rfunnyd1AvtdbfkuIaamtae3Ie
..... 140 192 Dynamic Attributes Metadata
..... 458 512 Unclustered Dynamic Attributes
------------------- ----- ------------ ------------ ------------------------
2001-12-19 15:44:14 75069 77824 32 files, 6 folders
We will have to use the a container signature to correctly identify this format. There are also ASM and DFT formats which are also Solid Edge formats which use the same OLE container. Hopefully there are some unique features we can use to identify them.
One other file format which uses the PAR extension is not listed in any of the registries. Not in PRONOM, TrID, Wikidata, or others. I came across it while researching another format, DVD Studio Pro. On a Macintosh computer running the now discontinued DVD Studio Pro, one could save their DVD mastering project as a “file” which used the DSPPROJ extension. I use the term file loosely here as it wasn’t actually a file, it was a folder with an extension which MacOS would interpret as a single file. These are the package formats Apple used and still uses quite frequently. Moving this folder to another other system results in a folder of content.
tree sample.dspproj
/sample.dspproj
└── Contents
├── PkgInfo
└── Resources
├── Audio
├── MPEG
├── Menu
├── ModuleDataB
├── ObjectDataB
├── Openers.plist
├── Overlay
├── Picture
├── Render Data
│ ├── C4272B0100797459.M2V
│ └── PAR
│ └── C4272B0100797459.M2V.par
├── Styles
├── Temp
├── Templates
└── Thumbnails
14 directories, 6 files
This PAR extension is explained in the DVD Studio Pro manual:
About the Parse Files
To use an asset in a project, DVD Studio Pro needs to know some general information about it, such as its length, type, and integrity. Video assets encoded within DVD Studio Pro can include this information in the encoded files, or can create separate files for it. Assets encoded by Compressor outside of DVD Studio Pro can include this information if you select the “Add DVD Studio Pro meta-data” option in the Extras pane of the Encoder settings.
Assets encoded with other encoders, or with the “Add DVD Studio Pro meta-data” option disabled when using Compressor, must be parsed before DVD Studio Pro can use them. Parsing creates a small file, with the same name as the video asset and a “.par” extension that contains the required information. The parse file can take from several seconds to several minutes to create, depending on the size of the asset file.
hexdump -C E4712E541A60E300.M2V.par | head
00000000 56 50 41 52 00 00 00 20 00 00 00 00 00 01 e2 40 |VPAR... .......@|
00000010 00 00 00 00 00 c6 19 7c 2f 55 73 65 72 73 2f 74 |.......|/Users/t|
00000020 79 6c 65 72 2f 44 6f 63 75 6d 65 6e 74 73 2f 46 |yler/Documents/F|
00000030 69 6e 61 6c 20 52 65 6e 64 65 72 20 66 6f 72 20 |inal Render for |
00000040 44 56 44 20 56 51 42 2f 56 61 72 73 69 74 79 51 |DVD VQB/VarsityQ|
00000050 42 20 44 56 44 2f 56 61 72 73 69 74 79 51 42 2d |B DVD/VarsityQB-|
00000060 44 69 73 63 32 2e 64 73 70 70 72 6f 6a 2f 43 6f |Disc2.dspproj/Co|
00000070 6e 74 65 6e 74 73 2f 52 65 73 6f 75 72 63 65 73 |ntents/Resources|
00000080 2f 52 65 6e 64 65 72 20 44 61 74 61 2f 45 34 37 |/Render Data/E47|
00000090 31 32 45 35 34 31 41 36 30 45 33 30 30 2e 4d 32 |12E541A60E300.M2|
Parity, Parts, and Parse files, oh my.
If you thought we were done, you would be wrong! Let’s look at yet another PAR format.
hexdump -C MESSROH.PAR | head
00000000 08 69 64 73 32 30 30 30 30 d0 4e 01 51 46 42 00 |.ids20000.N.QFB.|
00000010 98 d0 4e 01 80 01 58 01 b6 b9 f7 bf 82 30 00 00 |..N...X......0..|
00000020 dc 08 00 00 60 51 f2 bf 82 30 01 59 ff ff ff ff |....`Q...0.Y....|
00000030 a4 d0 4e 01 28 3e f2 bf 78 63 a4 01 dc 08 00 0b |..N.(>..xc......|
00000040 5a 45 52 4f 2d 4f 46 46 53 45 54 01 18 0e ac 01 |ZERO-OFFSET.....|
00000050 d4 d0 4e 01 00 ac 43 00 18 0e ac 01 d4 d0 4e 01 |..N...C.......N.|
00000060 51 46 42 00 ec d0 4e 01 d4 00 4e 01 b6 b9 f7 bf |QFB...N...N.....|
00000070 5c 4c 75 81 5c 81 00 00 45 07 41 00 c0 0a 00 01 |\Lu.\...E.A.....|
00000080 cd d0 41 00 d5 d0 41 00 5c 81 00 00 dc 0a a4 01 |..A...A.\.......|
00000090 5b 5d 42 00 cc d0 4e 01 72 5d 42 00 7a 5d 42 00 |[]B...N.r]B.z]B.|
hexdump -C DUMMYDAT.PAR | head
00000000 08 73 65 69 73 6d 69 63 31 00 00 00 00 00 00 00 |.seismic1.......|
00000010 00 00 00 00 00 01 58 00 00 00 00 00 00 00 00 00 |......X.........|
00000020 00 00 00 00 00 00 00 00 00 00 01 59 00 00 00 00 |...........Y....|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a |................|
00000040 41 4b 55 53 54 49 4b 4c 4f 47 00 00 00 00 00 00 |AKUSTIKLOG......|
00000050 00 00 00 00 02 2f 2f 00 08 41 47 43 2d 47 41 49 |.....//..AGC-GAI|
00000060 4e 00 00 00 00 00 00 00 00 00 00 00 00 32 00 00 |N............2..|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
This PAR format is called “Reflexw data-format“. This is a RAW format header that always is paired with a DAT file, together used to store geophysical wave data from devices such as GPR. Relexw is software made by Sandmeier geophysical research.
The PAR file samples I have don’t seem to have a consistent header as each have a unique set of bytes, but all of them have some similar bytes later in the file at around the 0x1D8 (472) offset:
000001d0 00 00 a0 3d 00 00 a0 41 00 00 00 00 00 00 00 00 |...=...A........|
000001e0 0a d7 23 3c 00 00 80 3f 00 00 00 00 00 00 00 00 |..#<...?........|
000001f0 00 00 00 00 cc cc dc 40 00 00 00 00 00 00 00 00 |.......@........|
00000200 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 00 00 |...?............|
00000210 00 00 00 00 00 00 00 00 17 b7 d1 38 00 00 00 00 |...........8....|
It seems these sequence of bytes are the only consistent bytes among all my samples. I have no idea what they mean or reference. The specification does indicate some bytes which should lead to proper identification, but the integer used for the “HeaderMarker” is looking for a 4 byte “00 00 00 01”, which won’t be enough to cleanly identify the format. Love to hear what others can see from the spec. You can find some samples files here.
So we have some Parity files, Parts files, Parse files, Parquet files, and a Header file. I am sure other will be found and added to this lot. Hopefully the PAR files you run across will match one of these patterns! I am still working on a signature proposal. Stay Tuned!