Im using WinHex to recover files from disk. Its mostly very good except for MPEG files.It seems to truncate almost every single one of them into files of various sizes, almost always less than 1MB.

It detects the start of file synccode of 0x000001BA but looking through the hex offsets for the end of the file, the EOF markers it has chosen seem totally random. There are a lot ending in 0000 but then my understanding of the format is that an MPEG stream can use null bit stuffing to ensure strict adherence to an overall bit rate... so I wouldn't expect 00000 to be the end of the file marker for that reason.

0000 EOF

Then there are others that end with random byte codes:

random eof

What I'm looking for and can't find is either the "proper" EOF marker codes (not sure why WinHex doesn't use them) or alternatively some kind of content-length header fields a'la HTTP that I can use to infer EOF from SOF.

  • Mpeg what? I would say ends of vids Vary. checking a few, I got the program that it was processed with at the end, or it just ends with 00 or 00 00. The size must be in the headers, because programs will look in those headers. Stream (at least a live one) doesnt know where it will end, so it cant know its size, and it could end cold. Do you have any unbroken ones processed the exact same way? Cant find the end, find the beginning of the next file? This is all beyond me. In the disk structure,doesnt the data ending in the cluster help find the end? – Psycogeek Jul 25 '13 at 2:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.