Inside QuickTime Movies
If you need to repair damaged QuickTime movies take a look at Aero Quartet's Movie Repair Service
If you want to learn about the technical internal details of QuickTime - read on.The QuickTime file format specification explains how a QuickTime movie is laid out, but before reading it you may just take a quick look with other tools.
A hex editor (like HexEdit), can reveal a bit of this, as the structure of the movie is in the beginning of the file.
QuickTime files are arranged internally as files and folders nested in folders - in QuickTime lingo they are called "Atoms".
The selected 4 bytes on the screen shot is the atom type of the first "atom" in this QuickTime file. The preceding 4 bytes is the atom size in big endian byte order. All atom types have 4 byte human readable identifiers, and the preceding 4 bytes are the size. Usually all the information defining the structure of a QuickTime movie is in the first few pages of the file, and the rest is the movie data (mdat atom).
To view this tree in more readable form you could get "Dumpster" (also for Windows) from Apples QuickTime Developer Tools page.
Repair of QuickTime movies where the resource has been lostIn old versions (before 2000?) of the QuickTime Player, the structure of the movie could be stored in the "Resource Fork" of the file. In MacOS 9 you could inspect the resource fork with ResEdit. This feature rarely used any longer as this could get lost when copied to a PC.
To restore a damaged movie, you could copy the "header" from a movie compressed the exact same way, to the damaged file and get a repaired movie. This require a lot of guesswork, as there has always been many options for saving QuickTime movies, and guessing the right combination require that you have a good idea of how the movie was saved originally.
Historically the movie did not even need to contain the data itself. It could even be stored on analog media, and the QuickTime movie was just instructions on how to access and control the display from this media. The Quicktime plugin architecture was made so this was possible. This is still true, if you copy and paste from one movie to another with QuickTime Pro - the data is not moved, but only the reference to where to find the data is copied. To save such a copied and pasted together movie as a stand alone movie, you choose "save as self contained" movie.
One case of repair which can be simple, is if the resource fork has been lost, and the movie had no sound. Then you can try to copy a resource fork from a similar movie. If it had sound it is much harder, as the sound and video must be manually separated "demuxed" with a tool like HexEdit.
You could be lucky with an easy repair if you found the lost resource fork. Software which was aware of MacOS when it copied the data away form the HFS formatted Mac disk, would save the resource data along with the file. One way is with an extra file with the same name prefixed with "._". So "MyMovie.mov" would have its resource fork in a file called "._MyMovie.mov" Other ways which have been used for keeping resources stored together with the data on non HFS file systems:
DOS floppy mode: data: myfile.blah resource: RESOURCE.FRK\myfile.blah PCMacLan mode: data: myfile.blah resource: myfile.blah.#res .QTR (QuickTime resource) mode: data: myfile.blah resource: myfile.qtrSource: QA1132
You can also contact a receovery service provider and ask for a quote.Professional File Repair Services is one of many which Google may help you find.