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

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.

share|improve this question
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

You must log in to answer this question.

Browse other questions tagged .