(quicktime file format, first impression:)
Significant difference in headers between two good mov files seem to start with the "stss" atom.
Main problem is with the "Sync Sample Table".
These will probably have different sizes for different movies.
This will make it a bit harder to guess where the actually movie data starts... if I am to attempt a reconstruction of the headers with best guesses ;)
I can imagine a program that quickly tries out all kinds of possibilities where the user will have to pay attention to when it's a bingo and a good image comes out...
Even better would be a program/repair tool which saves the first image of each try to the harddisk... with the header information that was used.
This way with window's icon view it should be possible to quickly figure out which image is good and has good header information to then quickly do a repair attempt with those settings and a full movie playback.
Further similiar problems are with "stsz" atom. "Sample Size Table".
This will make it more complex to try and repair...
This also seems to use sizes which will be even more difficult to guess ;) Except maybe if the file does contain this data it might be easier to guess.
It's kinda strange that this viewer doesn't recgonize any moov data... maybe it just needs a signature to be placed there ? Hmm... I will have to look into that a bit later on...
Then the same kind of problem is with the "Chunk Offset Table".
These three tables will have a different number of entries for each mov file... (thus a different table size) these tables seem to be located at the start of the file.
Guessing the number of entries for these tables might get a bit tricky... also guessing the offsets might become a bit tricky.
However there is also seems to be a "udta" "User Data" section at the end of the file. (actually not end of file... but end of header ;) See below ;))
This seems to be a place where the manufacturer of the file can place it's signature.
It seems to say something like:
"Digital Camera...=... some more crap followed by: "NIKON DIGITAL CAMERA".
This seems to be the same for both good movie files so this could be a nice marker to find the end of the file...
Or at least give a possibility to work backwards from the end.
Another idea could be to simply search and try to find images or any other compressed data and try to extract this image by image... by simply trying out all offsets.
To be able to do this I need more information than the atom viewer is currently providing.
But the atom viewer does give me a chance to simply go to such an offset and attempt to decode it or so...
Or maybe stuff it through some kind of windows decoder... to see how that works out.
So not all hope is lost... technically it might be possible.
Question is... is there actually any image content in the file ;)
Time to start up Skybuck's homemade File Viewer ;) :) (unreleased ;))
Actually now that I view it with Skybucks Viewer there is no signature to be found at the end of the file which is logical...
Because the signature is not at the end of the file format specification lol ! Dumb me lol.
It's at the end of the header... Which in itself is kinda interesting too...
So now I travel back to the start of file to see if I can find it ?! ;)
But maybe this camera only stores it there once it's done recording but I will see anyway... ;)
There is no search functionality yet... actually I made this tool for 64 bit support.
So instead because the file is only 100 MB I am gonna use textpad to view it binary... maybe textpad can find this signature ;) First have to copy file and rename it to *.bin so it opens it in hex mode.
Actually looking at it in textmode did reveal some stuff too..
Ok so far I see "NIKO" but not "NIKON".
This could be a left over of previous data...
I am starting to see what the problem could be.
The problem could be that the header is only written at the end of the recording ?!?!?
But that doesn't seem to make much sense...
Also how would this video file reserve space for such large headers ?!
Doesn't seem to make much sense to me...
Maybe the atom viewer is fooling me... and the data is maybe coming from across the file...
I'll have to read the file specification to know for sure...
Actually that's not necessary... the atom viewer shows the offset/location where the data is coming from at the start.
Example: pnot is located somewhere at offset hex 0 pict is located somewhere at offset hex 10 (bit later on probably it's not super accurate) mdat is located somewhere at offset hex A70 moov is located somewhere at offset hex EC68D0 udta is located somewhere at offset hex ECB230
In decimal this is:
15.512.112
Which is no where near the end and also not really at the start unless the header is actually 15 MB big ?!?
No way it could be 15 MB unless maybe this is "reserved space ?"
Hard to tell if this is reserved space... could be garbage that's just skipped over...
If it is reserved space it should have been cleared first or so for better compression later on... but ok... clearing costs time...
I would be amazed if that is reserved space... because that's pretty wastefull ?! ;)
Well so far lot's and lot's and lot's of speculations.
This post could be full with errors so don't rely on it people.
This just my first impression of things ;)
Bye, Skybuck =D