Fixing / Repairing a MJPG AVI video

[DBennett]

Heya,

I'm having trouble restoring a MJPG AVI video.
The content is there; I'm pretty sure the header is broken, but Hex editors make my head swim...

If anyone is able to get the video working, or can provide information which makes it play: I will Paypal a very generous tip for your effort.
It's footage of my recently departed springer spaniel...every AV memory of him is precious.

I've attached 2 files: 1 is the broken video, the other is a working video from the same Fuji camera recorded the day before.

Thank you!
David Bennett

[jagabo]

Large parts of the broken file don't even come from the video. Was it recovered by a file undelete utility? It does have a damaged RIFF header in the middle of the file and auds and movi chunks.

[intracube]

EDIT: jagabo beat me to it... by 40 minutes. Serves me right for leaving the reply form open for that long.

I've had a look at the two attachments. The first one doesn't seem to be a video - it looks like it has a different structure throughout. The linux 'strings' command can often give useful information about files, and it returned a total of 90,000 lines for the first attachment. Here's an example of the contents of the file:

ERNEL32.
NTDL
USER
ADVAPI
MSCTF
Software
\Micros
\Speech\
Recogniz
ers\Toke
Attri
bute
Lan guage
,H]`
C]`N8]`
cicpad_
mainwn
b%mf%windo
ws\curre
%ion\
control 
panel\cp

and towards the bottom of the file:

LsaRegisterPolicyChangeNotification
LsaUnregisterPolicyChangeNotification
LsaFreeReturnBuffer
LsaCallAuthenticationPackage
LsaLookupAuthenticationPackage
LsaConnectUntrusted
DsFreePasswordCredentials
DsUnBindW
DsCrackNamesW
DsFreeNameResultW
DsBindWithCredW
DsMakePasswordCredentialsW
RapConvertSingleEntry
RapStructureSize
RapAsciiToDecimal
RapArrayLength
RapGetFieldSize
RapParmNumDescriptor

It looks like you might have copied a system file by accident.

Someone else may be able to suggest something, so hold on to the file in case there's anything retrievable in there. But it doesn't look hopeful .

[jagabo]

The file contains parts of an AVI file (hence the RIFF header, movi and auds chunks). But it also contains parts of some EXE file and maybe other junk. That's why I speculate it's the result of a file undelete, after the file has been overwritten. It's probably too far gone to restore anything.

[DBennett]

Darn...thanks very much =( it was my favourite video of him, trying to rev up the chocolate labs...

The corruption happened after a restart on WinXP, the bluescreen repair utility that goes ahead if you don't notice it & hit any key to cancel...it always messes everything up...

Thanks very much for the attempts, I heavily appreciate the detailed information...no wonder I was getting stressed =(
-David Bennett

[intracube]

It might be possible to retrieve the data, but without knowing how the file was corrupted it would be challenging. Are you saying you haven't used a file restoration program, but instead the Windows repair utility has corrupted the file?

Even if the example file you uploaded is corrupted beyond repair, the data may still be on the disk and might be retrievable under certain conditions (not wanting to get your hopes up, though). In some cases it's possible to recover files weeks after being deleted - several years ago I managed to restore some videos after having deleted them over a month before.

There are a lot of variables that can impact on file recovery: disk fragmentation, length of time since the file was deleted, filesystem type, etc.

If the level of disk fragmentation is low you might be able to map out the probable location of the data (blocks) on the hard disk from looking at the block locations of other videos in the same folder. I used this technique a couple of days ago to restore sections of a video from an ext3 (Linux) filesystem. The file wasn't particularly important, but I was interested to see if it could be done.

Here's a simplistic example of a folder with some videos:
DSCF0954.AVI 200124200-200125440
DSCF0955.AVI 200125441-200127814
DSCF0956.AVI 200127815-200131222
DSCF0957.AVI 200131223-200132756
DSCF0958.AVI -------------------
DSCF0959.AVI 200134893-200135242
DSCF0960.AVI 200135243-200139580

The values in bold are the block ranges for the data. Notice how the start of one file leads on from the end of the previous. In this example the details about the blocks for one of the files is missing. It's reasonable to guess that the original file was stored between blocks 200132757-200134892. It's possible to dump that data to a new file, and then analyse it for valid video streams.

Although in a lot of cases, the data for a particular file might be split into lots of chunks at different locations on the disk, rather than a single chunk. There may be specialist software for Windows to automate the process, although I don't have any specific knowledge about Windows filesystems/file recovery.

[jagabo]

What you're describing is basically the way file undelete programs work (and probably what CHKDSK did when he rebooted). I don't know NTFS well, but with FAT file system, the directory entry to the deleted file still contains the file name (except for the first character which is changed to indicate it's been deleted), the pointer to the first allocation unit, and the length of the file. So the undelete program knows most of the filename, where the first allocation unit was, and the total length of the file. It would assume the following unused allocation units constitute the rest of the file. If there aren't enough consecutive free allocation units it will skip over any used units and use the next free one(s). The smaller the file, the less defragmented the drive, and the less it's been used since deleting the file, the more likely it is you'll be able to retrieve the file intact.