Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A few years ago, I backed up a directory of family movies in quicktime format to my NAS. Unfortunately, only the data files went, and NOT the resource forks. Months later when I went to import those files to iMovie I found them unusable and the resource forks were long gone. Just my luck!

I've done a bit of poking around with HexEdit, and after a bit of toying with Dumpster, I've only managed to recover a few partial frames. I've tried creating new files in a similar format, but unfortunately I don't recall the frame size/rate. After pasting in a 'recreated' resource fork via HexEdit, in Dumpster I can view frame details, but I don't seem to be able to consistently edit them.

My question is, has anyone else been successful at doing this? I can't imagine this is a very unique problem. Short of creating a file with every possible frame dimension, and doing trial and error, is there an easier way to update the Quicktime atoms/containers? Or to discover the frame dimensions via details in HexEdit?

I've been picking at this for a few years now, coming back to it every 6 months or so for a fresh try, new google searches.

share|improve this question
I didn't know QT used resource forks to store additional (possibly important) video information. Do you know what exactly is stored in there? How exactly are they unusable? It might be possible to just extract the video/audio bitstreams and re-wrap them again using third party tools. – slhck Mar 14 '12 at 9:46
I don't believe the current quicktime spec does. But these were created back when .mov was the default video format. If I remember correctly, the files were created in 2004. This was back when resource forks held the file details separate from the video data, until you re-exported as a 'self-contained' movie. Link to the old-style QTFF: – mattcaffeine Mar 14 '12 at 14:05
Oh, so it's basically the moov atom that's pushed into the data fork and now missing? This might be beyond my knowledge, but you could for example try to run ffmpeg -i -c:a copy -c:v copy and see if it's able to recreate the atom. – slhck Mar 14 '12 at 16:29
I don't suspect it will be that easy, but I will give this a shot tonight. Problem is, with no resource fork, there is no atom, just data. So ffmpeg will not find the necessary details to pick out the audio and video tracks. I can pick out some of those details in HexEdit, but I don't believe ffmpeg will be able to. – mattcaffeine Mar 14 '12 at 20:35
I know this is a tricky issue. You probably already know more about this stuff than I do :) I guess it won't be possible for you to maybe supply a sample file? (I understand if it's private material) – slhck Mar 14 '12 at 21:07

You must log in to answer this question.

Browse other questions tagged .