Pro Tools Sessions

Posted on by Thor Leave a comment

One of the most important software titles related to professional audio recording and mixing is Pro Tools. The Digital Audio Workstation by Digidesign, now Avid, has been around since 1991 and was born from the very popular Sound Designer software first released in 1985. When Sound Designer II was released a few years later, the audio format used became the standard file format for audio recordings. Pro Tools progressed from there to become the industry standard for professional audio production, even winning a Technical Grammy, Emmy, and Oscar.

Pro Tools helped produce amazing music for artists such as No Doubt, Maroon 5, Ricky Martin, and many others. Obviously the best part is the final mixed audio used to make the music we love, but the work that goes into creating the audio mixes is saved in a Pro Tools session. The session is where all the magic happens. A Pro Tools session is actually a project file within a folder where all the supporting files are located.

tree PT Sample/
├── Audio Files
│   ├── GTR 1_02.wav
│   ├── GTR 1_03.wav
│   └── GTR 1_04.wav
└── Test.ptx

These Session “Folders” can get pretty complex as more audio and effects are added to the session, adding folders such as Fade Files, Rendered Files, and Plug-in settings. The current version of Pro Tools uses a project session file with the extension PTX, but that wasn’t always the case. The current version of Pro Tools can be run on Macintosh and Windows, but that also was not always the case. Because the software was originally written for Macintosh hardware, the session files were only compatible on the Macintosh file system as well.

Lets start by looking at a session from Pro Tools version 1.1 from 1991.

ls -l@ Demo Disk 1 
total 1504
-rw-r--r--@ 1 thorsted  Domain Users   45056 Sep 13  1991 Backward Kick
	com.apple.FinderInfo	    32 
	com.apple.ResourceFork	  1354 
	com.apple.provenance	    11 
-rw-r--r--@ 1 thorsted  Domain Users       0 Sep 16  1991 Demo Session
	com.apple.FinderInfo	    32 
	com.apple.ResourceFork	 13671 
	com.apple.provenance	    11 
-rw-r--r--@ 1 thorsted  Domain Users       0 Sep 16  1991 Desktop
	com.apple.FinderInfo	    32 
	com.apple.ResourceFork	  3081 
	com.apple.provenance	    11 
-rw-r--r--@ 1 thorsted  Domain Users  339456 Sep 13  1991 Solo 1
	com.apple.FinderInfo	    32 
	com.apple.ResourceFork	  2040 
	com.apple.provenance	    11 
-rw-r--r--@ 1 thorsted  Domain Users  350390 Sep 13  1991 Solo 2
	com.apple.FinderInfo	    32 
	com.apple.ResourceFork	  2006 
	com.apple.provenance	    11

You might notice the “Demo Session” file is Zero Bytes, but the Resource Fork is 13671 bytes in size.

The Pro Tools Sessions from the beginning until version 5 used this method of storing the session data. ALL in the Resource Fork. Because the session data was in the resource fork and the supporting audio files were in the Sound Designer II format, which also stored important information in the resource fork, this made it impossible to use on anything but a Macintosh file system.

Version 10 of Pro Tools allows you to export the full session back into older versions of the software to version 3.2. When you choose version 5 on a Mac, it forces you to also convert the audio formats to SD2 files as well. For versions 1 & 2 of Pro Tools, there was no official extension for the session files, but starting with version 3, you might often find the extension PT3, then PT4, and PT5. With version 4, there was also a version P24 extension used when Pro Tools version 4 made the leap to 24bit. But for each of these versions identification is not possible with current preservation tools like PRONOM. You could encode the session as a MacBinary to retain everything for modern systems, which is identifiable, but you could also use my proposal for a lookup in the TCDB python tool located here.

python3 TC-lookup-draft-uni.py "PT Session 02-41.pt4"
Type Code: PT4S
Creator Code: PTul
Size of Data Fork: 0 bytes
Size of Resource Fork: 14003 bytes
Rows with Type Code b'PT4S' and Creator Code b'PTul': 
Row index: 32813
File Name: Pro Tools 4
Type: PT4S
Creator: PTul
Extension: pt4
Data by Ilan Szekely, Jerusalem: nan
ExtensionVersionTypeCreator
Pro Tools 1.1mtSFTLin
Pro Tools 2PSesPTul
PT3Pro Tools 3.2PSesPTul
PT4Pro Tools 4 16bitPT4SPTul
PT24Pro Tools 4 24bitPT24PTul
PT5Pro Tools 5PT5SPTul
PTSPro Tools 5.1-6.9PTS PTul
PTFPro Tools 7-9PTF PTul
PTXPro Tools 10+PTX PTul

There isn’t a lot of information about when Pro Tools was made for Windows. I found some references to a Windows NT version of the 16bit and 24bit version 4. I did also find a copy of the free Pro Tools version 5.01 for Windows 98. In the Read Me it states:

Cross–platform File Exchange is not supported in this version of Pro Tools FREE

File interchange between Mac and PC versions of Pro Tools FREE is not possible in this 5.0.1 release. We hope to include this functionality in a future release of Pro Tools FREE.You can exchange files with Pro Tools LE and TDM users who use the same platform (Mac or Win98/Me) as you, but remember, Pro Tools FREE is limited to 8 audio and 48 MIDI tracks.

Running the software confirms the session file for this version has the extension PT5 and not the later PTS for version 5.1. This version of Pro Tools also allows you to save back to the P24 and PT4 versions, which are probably the first Windows versions. But they are entirely different file formats from the Macintosh versions. 

hexdump -C PT5-Win-s03.pt5 | head
00000000  00 00 01 00 00 00 45 ae  00 00 44 ae 00 00 03 98  |......E...D.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  00 00 00 5e 50 53 56 45  00 01 04 31 00 52 05 00  |...^PSVE...1.R..|
00000110  45 44 05 00 45 44 19 99  03 26 0c 50 72 6f 54 6f  |ED..ED...&.ProTo|
00000120  6f 6c 73 20 35 2e 30 fc  c5 00 d7 12 00 78 5e 00  |ols 5.0......x^.|
00000130  00 00 0e 32 00 78 5e 00  00 00 00 00 00 00 00 00  |...2.x^.........|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

hexdump -C PT24-Win-s03.p24 | head
00000000  00 00 01 00 00 00 3f d3  00 00 3e d3 00 00 02 f1  |......?...>.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  00 00 01 0a 50 61 74 68  00 01 02 b4 37 0e 2e 48  |....Path....7..H|
00000110  43 3a 5c 57 49 4e 44 4f  57 53 5c 44 65 73 6b 74  |C:\WINDOWS\Deskt|
00000120  6f 70 5c 50 54 5c 50 54  35 2d 57 69 6e 2d 73 30  |op\PT\PT5-Win-s0|
00000130  33 5c 41 75 64 69 6f 20  46 69 6c 65 73 00 00 00  |3\Audio Files...|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

hexdump -C PT4-Win-s03-16.pt4 | head
00000000  00 00 01 00 00 00 3f d9  00 00 3e d9 00 00 02 f1  |......?...>.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  00 00 01 0a 50 61 74 68  00 01 02 b4 37 0e 2e 48  |....Path....7..H|
00000110  43 3a 5c 57 49 4e 44 4f  57 53 5c 44 65 73 6b 74  |C:\WINDOWS\Deskt|
00000120  6f 70 5c 50 54 5c 50 54  35 2d 57 69 6e 2d 73 30  |op\PT\PT5-Win-s0|
00000130  33 5c 41 75 64 69 6f 20  46 69 6c 65 73 00 00 00  |3\Audio Files...|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Starting with Pro Tools 5.1 in 2001 things began to change. Pro Tools has always been tied very closely with hardware and software so with Apple launching Mac OS X, this provided an opportunity for DigiDesign/Avid to revamp their hardware and software for better compatibility and this included a cross-platform session format.

Pro Tools 5.1 used a new session format which used the extension PTS. Let’s take a look at a sample. 

hexdump -C PT Session 02-51.pts | head
00000000  03 30 30 31 30 31 31 31  31 30 30 31 30 31 30 31  |.001011110010101|
00000010  31 00 01 3d 6e 1c 06 eb  d8 c1 aa 16 fd 65 4e 6d  |1..=n........eNm|
00000020  23 09 96 db c4 ad 95 7f  68 5d 3a 23 0c a5 ac a8  |#.......h]:#....|
00000030  90 cd ed 04 38 4e 06 47  bc e2 ca b3 9c 8f 6e 57  |....8N.G......nW|
00000040  40 2a 12 fb e4 c4 b6 9f  88 77 5a 43 2c 24 ce c9  |@*.......wZC,$..|
00000050  e3 97 9b 8a 73 5d 46 2f  4a 64 86 b6 dd d6 eb 77  |....s]F/Jd.....w|
00000060  76 49 32 1b 54 9f b9 9f  fc fe 15 0f 3f 15 4d 62  |vI2.T.......?.Mb|
00000070  83 aa ab c4 fa 5d 20 26  54 44 0b f3 d9 c5 ae 97  |.....] &TD......|
00000080  cd 08 31 74 77 0d f6 df  c8 b5 c0 8b 6c 7c 3f 27  |..1tw.......l|?'|
00000090  10 9e c2 cb b4 9d 86 45  58 41 2a ad e1 78 2d b4  |.......EXA*..x-.|

The session is a new proprietary binary format with an interesting header. There is one byte and then a sequence of ASCII characters in the form of a binary string. 0010111100101011 What it means is unknown to me. In Decimal, the binary reads “12075”, or hex values “2F2B” or in text “/+”. Regardless of what it means, this header was used from versions 5.1 through 9. The extension changed to PTF with version 7-9, but the header is the same. This is why PRONOM PUID fmt/1951 refers to both extensions covering 5.1-9.

hexdump -C PT Session 02-7.ptf | head
00000000  03 30 30 31 30 31 31 31  31 30 30 31 30 31 30 31  |.001011110010101|
00000010  31 00 01 4c 6a cd 68 00  a0 3c d8 d2 c1 ac 48 be  |1..Lj.h..<....H.|
00000020  85 1c 25 54 f0 8c 31 e1  61 fc 98 34 d0 6c 08 a4  |..%T..1.a..4.l..|
00000030  40 dc 79 14 b0 4c eb 84  21 bc 58 f4 90 2c cc 64  |@.y..L..!.X..,.d|
00000040  00 9c 0e a7 15 6f a9 44  e0 7c 18 b4 7a ec 88 24  |.....o.D.|..z..$|
00000050  c6 42 65 77 5d b8 f2 80  a1 3c d8 2e 12 ac 6b e4  |.Bew]....<....k.|
00000060  80 1c a2 71 f0 8c 2c c4  60 fc ae 47 b5 0f 09 a4  |...q..,.`..G....|
00000070  40 dc 78 14 9a 4c e8 84  26 a2 c5 17 fd 58 52 e0  |@.x..L..&....XR.|
00000080  01 9c 38 d4 70 0d a8 44  e0 26 1a b4 73 ec 88 24  |..8.p..D.&..s..$|
00000090  da 79 f8 94 34 cc 68 04  96 4f bd 17 11 ac 48 e4  |.y..4.h..O....H.|

It might be possible to look closer at the two extensions and find something which can distinguish between them, but because they are in a proprietary binary format, there isn’t much to go on. There has been a few attempts at reverse engineering the formats, but they even choose to lump the two extensions together.

The other import byte in this header is the second byte after the odd binary ASCII sequence. Above highlighted in purple. 0x01 is important because in the next version PTX, this changes to 0x05, highlighted below in purple.

Pro Tools version 10 was a big release, it added new features and started to phase out the HD hardware. With this release we see a new session format which is still used by the current version of Pro Tools. 

hexdump -C PT Session 02-10.ptx | head
00000000  03 30 30 31 30 31 31 31  31 30 30 31 30 31 30 31  |.001011110010101|
00000010  31 00 05 13 5a 01 00 04  00 00 00 49 a4 00 00 5a  |1...Z......I...Z|
00000020  03 00 64 00 00 00 03 00  00 0c 00 00 00 50 72 6f  |..d..........Pro|
00000030  20 54 6f 6f 6c 73 20 48  44 03 00 00 00 0a 00 00  | Tools HD.......|
00000040  00 03 00 00 00 09 00 00  00 06 00 00 00 31 30 2e  |.............10.|
00000050  33 2e 39 01 07 00 00 00  52 65 6c 65 61 73 65 00  |3.9.....Release.|
00000060  16 00 00 00 50 72 6f 20  54 6f 6f 6c 73 20 53 65  |....Pro Tools Se|
00000070  73 73 69 6f 6e 20 46 69  6c 65 06 00 05 00 00 00  |ssion File......|
00000080  4d 61 63 4f 53 00 00 00  00 05 5a 08 00 eb 00 00  |MacOS.....Z.....|
00000090  00 67 20 00 00 00 00 2a  00 00 00 be 1d 9d e3 03  |.g ....*........|

This new session format has the same binary ASCII string, but a lot more plain text in the header and throughout the file. This gives us more to explore and understand with even listing the linked Audio files and their paths. PRONOM has this new format assigned to PUID fmt/1727. The signature for these files is the same sequence as the previous version, also the 0x05 byte, but with a couple additional bytes, 5A010004, after the main sequence. I am not sure of the bytes significance, but they are in all the samples I have, even from the current version.

Pro Tools has some other formats which go along with their sessions. One I’ll highlight is the Groove template format. They end with the extension GRV. You can see some samples here. They also have the odd binary ASCII header, but with 0x00 for the second byte after the main header. Highlighted in purple below.

hexdump -C DiskoKonga.grv| head
00000000  03 30 30 31 30 31 31 31  31 30 30 31 30 31 30 31  |.001011110010101|
00000010  31 01 00 5a 00 01 00 00  00 04 00 00 15 f8 5a 00  |1..Z..........Z.|
00000020  01 00 00 15 d3 10 42 04  04 00 64 00 64 00 64 00  |......B...d.d.d.|
00000030  01 00 01 00 01 00 00 00  00 01 d4 c0 00 00 00 00  |................|
00000040  00 00 00 00 81 00 00 00  00 00 00 00 81 5a 00 01  |.............Z..|
00000050  00 00 00 24 10 43 00 00  00 00 00 00 00 00 00 00  |...$.C..........|
00000060  00 00 00 01 d4 c0 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 01 d4 c0 00 49  5a 00 01 00 00 00 24 10  |.......IZ.....$.|
00000080  43 00 00 00 00 00 01 d4  c0 00 00 00 00 00 05 7e  |C..............~|
00000090  40 00 00 00 00 00 04 8e  e0 00 00 00 00 00 01 d4  |@...............|

Other extensions associated with Pro Tools which use the same format are: PIO, PIM, PTT, PTXT, RGRP.

Pro Tools has always been software directly tied to audio hardware and system software. In addition they also used software dongles to control software licensing and the licenses were not cheap. Because of this, trying to use older versions is very difficult. Finding samples for each version is difficult as each version allows for a variety of features that may not be available in another version. Luckily, there are some older “Free” versions out there with limited features we can get some ideas of the session format.

PRONOM has working identification for the two major formats and until PRONOM can incorporate Macintosh Resource Fork identification it will have to do. The PC version 4 and 5 formats could use more research as I only have one source. The groove and other formats all seem to have the same header so they will need more research as well. Until then, enjoy some sample files and also a disk image of some older Macintosh Pro Tools 3 sessions.

Quicktime MooV

Posted on by Thor 2 Comments

During the 1990’s Apple Quicktime became the dominant digital media standard. It is the basis for the MPEG-4 format which is used everywhere now. Technically the Quicktime Movie format is a container or wrapper which can hold a variety of Video and Audio streams.

The basic unit of a Quicktime Movie is an atom. The MooV atom is the most important piece of a Quicktime Movie. Without it and the “mvhd” header atom, all the characteristics of the movie are lost.

Having the MooV atom missing from your movie file seems like it would be a rare thing, but it may happen more often than you think.

What happens when you come across a Quicktime file on an HFS disk, like one of these: https://archive.org/details/quick-clips-cd

If you try and open the movie you might see this.

MediaInfo doesn’t know what to make of the file. You can see the hex values from the beginning of the file, there clearly is no MooV atom.

Enter Macintosh Resource Forks.

Original Quicktime files stored the MOOV atom in a resource fork.

Lets take a look a closer look at one of these files.

derez Wildebeest 
data 'moov' (128) {
	$"0000 0465 6D6F 6F76 0000 006C 6D76 6864"            /* ...emoov...lmvhd */
	$"0000 0000 E143 7EF5 E143 7EF5 0000 0258"            /* ....?C~??C~?...X */
	$"0000 1068 0001 0000 00FF 0000 0000 0000"            /* ...h.....?...... */
	$"0000 0000 0001 0000 0000 0000 0000 0000"            /* ................ */
	$"0000 0000 0001 0000 0000 0000 0000 0000"            /* ................ */
	$"0000 0000 4000 0000 0000 0000 0000 0000"            /* ....@........... */
	$"0000 0924 0000 0000 0000 0000 0000 0000"            /* ...$............ */
	$"0000 0002 0000 03D9 7472 616B 0000 005C"            /* .......?trak...\ */
	$"746B 6864 0000 000F A5EA 1D89 E143 7EF5"            /* tkhd....??.??C~? */
	$"0000 0001 0000 0000 0000 1068 0000 0000"            /* ...........h.... */
	$"0000 0000 0000 0000 0000 0000 0001 0000"            /* ................ */
	$"0000 0000 0000 0000 0000 0000 0001 0000"            /* ................ */
	$"0000 0000 0000 0000 0000 0000 4000 0000"            /* ............@... */
	$"00A0 0000 0078 0000 0000 0024 6564 7473"            /* .?...x.....$edts */
	$"0000 001C 656C 7374 0000 0000 0000 0001"            /* ....elst........ */
	$"0000 1068 0000 0000 0001 0000 0000 0351"            /* ...h...........Q */
	$"6D64 6961 0000 0020 6D64 6864 0000 0000"            /* mdia... mdhd.... */
	$"E143 7EF5 E143 7EF5 0000 0258 0000 1068"            /* ?C~??C~?...X...h */
	$"0000 003C 0000 003A 6864 6C72 0000 0000"            /* ...<...:hdlr.... */
	$"6D68 6C72 7669 6465 6170 706C 4000 0000"            /* mhlrvideappl@... */
	$"0001 002C 1941 7070 6C65 2056 6964 656F"            /* ...,.Apple Video */
	$"204D 6564 6961 2048 616E 646C 6572 0000"            /*  Media Handler.. */

The MooV atom is in the Resource Fork. Apple explains why they did it this way.

FILE MOVIE HEADER

Note: the header is safer when stored at the beginning of the file or in the HFS resource fork as type ‘moov’; ID any. The advantage of using another file fork is that the header can be lengthened without recalculating the sample offsets or new header must be written at the end of the file.

QTM-Layout

If you are playing back a movie on an older Macintosh using an earlier version of Quicktime, you won’t have any issues, but if you plan on playing the movie on a newer system or try and preserve the file, then we run into problems. Especially if the file is moved off of the HFS disk onto a system which doesn’t maintain the resource fork. Then you are stuck with just the data with no way to interpret the movie file.

Solutions.

One solution you can follow is to use MacBinary or AppleSingle to combine the Resource Fork and Data Fork together into one file. You are left with a different format, but one which can be preserved and reverted back to the original when needed.

Another way is to create a Single-Fork Movie file, aka a normal QuickTime file.

“single-fork movie file – A QuickTime movie file
that stores both the movie data and the movie
resource in the data fork of the movie file. You
can use single-fork movie files to ease the
exchange of QuickTime movie data between
Macintosh computers and other computer
systems.”

Inside Macintosh – QuickTime

Creating a Single-Fork can be accomplished a couple different ways. One is to use an older version of QuickTime to “Save As” to a self contained file with the box checked to allow playback on a “non-Apple” computer.

Another method is to use a simple utility called Single Fork Flattener. I found a copy on a old QuickTime disc and uploaded to Macintosh Garden if you want to try it out. No QuickTime needed, just open the file and it updates it to include the MooV resource. Also a tool called FlattenMooV.

Once combined, MediaInfo now sees a complete QuickTime file which VLC can play!

mediainfo Wildebeest2 
General
Complete name                            : Wildebeest
Format                                   : QuickTime
Format/Info                              : Original Apple specifications
File size                                : 565 KiB
Duration                                 : 7 s 0 ms
Overall bit rate                         : 661 kb/s
Frame rate                               : 10.000 FPS
Encoded date                             : 2023-10-02 14:15:15 UTC
Tagged date                              : 2023-10-02 14:15:15 UTC
Writing library                          : Apple QuickTime
FileExtension_Invalid                    : braw mov qt

Video
ID                                       : 0
Format                                   : Road Pizza
Codec ID                                 : rpza
Duration                                 : 7 s 0 ms
Bit rate                                 : 659 kb/s
Width                                    : 160 pixels
Height                                   : 120 pixels
Display aspect ratio                     : 4:3
Frame rate mode                          : Constant
Frame rate                               : 10.000 FPS
Bits/(Pixel*Frame)                       : 3.434
Stream size                              : 563 KiB (100%)
Language                                 : English
Encoded date                             : 1992-03-16 09:40:25 UTC
Tagged date                              : 2023-10-02 14:15:15 UTC

I was hoping I could find a method to use a modern tool to combine into a Single-Fork file, but nothing yet. I did find a C++ source that when compiled does indeed merge the two forks together, which in this case merges the MooV atom at the end of the file. Its called qtmerge. QuickTime 7 is your best bet for a GUI tool which works on recent MacOS, but not the last couple versions. There is a reference out there to a tool called RezWack, but I have been unable to verify.

DiskDoubler

Posted on by Thor Leave a comment

A few years ago I had someone contact me with a desperate plea. They had a disk which contained years of journal entries and letters to loved ones she could no longer access. She had used a Macintosh in the late 1980’s and early 1990’s to create all these files, but wanted to convert them all to PDF so she could make a book. She said she had tried everything, contacted a lot of people and her son had told her it was a lost cause. In talking with others at my institution, they knew I had a background in older Macintosh formats and so she contacted me. I made no promises, but offered to try.

The files she provided were indeed early Macintosh files. One obvious trait was the lack of an extension. One might think a lack of an extension was poor planning for Apple, but they choose a different method for the operating system to know the relationship between files and applications. They did this through the use of a Type/Creator code. If you were a software developer for the Macintosh you could register a four character “Creator” code, then for all the different files you used with your software you could register a “Type” code. This told the Macintosh operating system exactly which software created the file and the type so it could be opened properly. Unlike today where an extension is defaulted to one application even if it isn’t the software which created the file.

ResEdit view of Hypercard Stack Info

In some ways this was a superior identification method as there was many software titles which could all create the same file format, but this way the correct software would open the file and render it correctly.

Looking at the files provided to me, there was a few which at first seemed like they were damaged somehow, they were extremely small compared to the other files. About half the size. When I opened them in a hex editor this is what I saw.

Usually document formats during this time would keep the text in plain ascii, but these files were different, they had binary data. In the header was the only plain text strings in the file, “WDBNMSWD”. I had seen these codes before, a Microsoft Word Document! But they weren’t….. What are they?

The head of the file has the hex values “ABCD0054”, so I started searching the internet for some help. There were others having the same problem I was having. I finally came across a tool called the “Unarchiver“. Running the command line version of the software “unar”, suddenly I had a file twice the size and could be opened by Microsoft Word!

unar Letter 
Letter: DiskDoubler
"./Letter" already exists.
Successfully extracted to "./Letter-1".

Remember back in the 1990’s when storage was expensive? Instead of dropping another $20 for a 100MB ZIP Disk, you could use Symantec’s DiskDoubler. The software would be installed on your Macintosh and then a window would come up showing you all the files on your drive. With one click you could compress a single file or a directory of files saving you tons of space. When you needed the file, just double click and the software would uncompress on the fly and then open the correct application to edit the file.

With a few clicks I was able to uncompress all the affected files and provide a PDF of all the letters and journals my new friend had tried so desperately for years to open. She was thrilled to say the least.

But why stop there? PRONOM needs to know about this format!

Once I had DiskDoubler installed I could make a few more samples, where is where I found there was a few different compression methods used by the software. They are labeled AD 1 & 2 and DD 1, 2 & 3. Making samples of each of the different types I was able to confirm the first 4 bytes of every file was the hex values “ABCD0054”. I was able to submit the format to PRONOM and it was added and given the PUID fmt/1399.

One of the other features of DiskDoubler was an ability to create a Self Extracting Archive (SEA). An sea file could contain a compressed file but also contained the code to uncompress itself. This was mostly seen with the Stuffit software, but there were many other compression tools which could write to this format. The Stuffit formats have been added to PRONOM which include identification of an SEA created by stuffit, but the SEA created by DiskDoubler is different and needs to be added.