Qtch

Comparison with QuickTime Player 6.x

Previously QuickTime Player 6.x would store these audio and video(a/v) streams as files on the hard drive that had auto generated names such as '59B8794Ad01'. Unlike qtch files, these files had the correct a/v magic number and could be played by an appropriate player.

For example, the first 16 bytes of an m4v file are:

Hex ; ASCII 00 00 00 20 66 74 79 70 4D 34 56 20 00 00 00 ; ... ftypM4V ...

Using the Firefox browser the location of these files would be:

File Format Comparison between QuickTime Player 6.x and QuickTime Player 7.x

Although the files have different headers their a/v payload can often be the same(see iTunes exception below). In this example the same a/v file was streamed from a server and stored on the hard drive using QuickTime Player 6.x and QuickTime Player 7.x respectively :

The first 16 bytes of the file are totally different:

From here both files are identical. To prove that the a/v information is intact within the qtch file you can replace the qtch file contents above this start a/v hex value with that from the QuickTime Player 6.x file and it will play normally.

Identifying embedded file types within qtch

It may be impossible to know the filetype embedded within a qtch file without having a side-by-side comparison with the same file streamed using QuickTime Player 6.x (as above). Tools such as TrID/32 - File Identifier would, when analysing the file in the above example, only give you this information:

75.0% (.QTCH) QuickTime Cached data (9000/1)

It would not tell you the embedded file type.

Currently the only known way to establish the file type of a qtch file is to employ a packet sniffer and search for the stream's file type as it is received by the network card e.g. for QuickTime you would search for the leaf atom called ftyp. Even then knowledge would be required to build the correct header to the point of the actual a/v data start.

qtch files and iTunes

Although iTunes stores qtch files in the same way as described above the a/v content appears to be scrambled in some fashion so that a side-by-side comparison of the original file with the stored streamed file would find no match in the a/v data.