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
Inside Macintosh – QuickTime
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.”
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.
Great article.
So discmaster has encountered ‘thousands’ of .mov files on PC CD’s (or on the ‘PC’ side of ‘hybrid’ CDs) that only have the ‘mdat’ movie data and the resource fork ‘moov’ data is missing entirely.
I take it there isn’t likely any way to ‘generate’ or ‘deduce’ the ‘moov’ data based on just the ‘mdata’ data?
I’m guessing this ‘mdat’ data is useless without the ‘moov’ info?
Thanks for the comment, it would be best to pull from the HFS side of a disc for an older Quicktime moov file, but I have heard of some success using the header from another file with similar specs. Might be an interesting project to pull from the many files on discmaster and see if one could append the moov atom based on some known values.