resource fork – Obsolete Thor

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.

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.

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.

Tag: resource fork

Quicktime MooV

DiskDoubler