Check integrity of DV file

[geohei]

Hi.

I suspect that my harddisk corrupted some DV files (for some reason).

How can I check the integrity of DV files?

I thought of some kind of software, which is able to report interruptions in the DV headers in terms of datacode, or some other method to determine whether the files content is corrupted.

Thanks.

[redwudz]

Might be a little too simple, but I run them through Virtualdub, using the Panasonic DV codec for checking.

[Safesurfer]

Gspot will give you info on corrupt files.

[geohei]

Virtualdub / Panasonic DV codec and Gspot work!
Thanks a lot !!!

[geohei]

@redwudz

Does checking the file consist of simply loading it without error, or is there a specific function of VirtualDub which permits to check the file more thoroughly?

Thanks.

[Safesurfer]

@redwudz

Does checking the file consist of simply loading it without error, or is there a specific function of VirtualDub which permits to check the file more thoroughly?

Thanks.

Once you've loaded the file in Vdub, go to Video on the menu, and choose "Scan video stream for errors."

[geohei]

Once you've loaded the file in Vdub, go to Video on the menu, and choose "Scan video stream for errors."

Thanks!

[geohei]

Using VirtualDub, I got this error now when playing the clip. It shows up at the very end of the clip.

[!] Dub: I/O thread has not cycled for ten seconds -- possible livelock. 
    (Thread location: 77F94091)

The "Scan video stream for errors." function didn't report any problem.

Is this an indication of a problem?

Thanks,

[geohei]

I noticed that the function "Scan video stream for errors...." does not reveal errors within a corrupt MPEG-2 file. The only indication of a problem I get is when loading the file. After loading is finished, I get this here:

[!] MPEG: Anachronistic or discontinuous timestamp found in audio stream 0 at 
    byte position 932575250, from 141883259 to 143730059. This may indicate an
    improper join.

[!] MPEG: Anachronistic or discontinuous timestamp found in video stream 0 at 
    byte position 932802578, from 141871019 to 143768219. This may indicate an
    improper join.

Why does the "Scan video stream for errors...." function not show any error?

Thanks.

[redwudz]

Why does the "Scan video stream for errors...." function not show any error?

Probably because that's not really an error in the video, just a part missing, usually because of a bad join. It's pretty common with videos that I have downloaded.

I usually just resave the video with direct stream copy and this gets rid of the problem. If the missing part is very long, then you have a problem. You can preview in VD and see what is missing.

Not sure about the 'livelock', but it may be related to the missing video.

[edDV]

Hi.

I suspect that my harddisk corrupted some DV files (for some reason).

How can I check the integrity of DV files?

I thought of some kind of software, which is able to report interruptions in the DV headers in terms of datacode, or some other method to determine whether the files content is corrupted.

Thanks.

Explain the history of this DV file.
Was it a direct transfer from a camcorder?

Keep in mind that a IEEE-1394 stream to a DV-AVI file on the computer is not the same as a file transfer. It's a stream capture and any gaps in the stream just go to the file. There is no provision for resending bad packets as there is in a true file transfer. Otherwise you would see the DV cam rewinding and resending data (this is not part of the driver). What you see is what you get.

I wonder how a "error check" in Virtualdub would pick up gaps in the stream? I'm sure that Windows XP (or OSX) made a technically good file even if the stream had drops. Is this error check in Virtualdub just a file check?

Now if the HDD corrupted the file, maybe this error check would pick that up.

[geohei]

Explain the history of this DV file.
Was it a direct transfer from a camcorder?

Yes, it was a direct capture from the camcorder, using the "stop if frames drop" feature. Hence no frames were dropped. However I did signatures (using PGP) of several .avi footages. These one allowed me to find out that there was a problem with the harddisk. Probably sectors were declared unreadle, dropped replaced by the reserve sectors.

Keep in mind that a IEEE-1394 stream to a DV-AVI file on the computer is not the same as a file transfer. It's a stream capture and any gaps in the stream just go to the file. There is no provision for resending bad packets as there is in a true file transfer. Otherwise you would see the DV cam rewinding and resending data (this is not part of the driver). What you see is what you get.

This is clear and not the source of the problem in my situation.

I wonder how a "error check" in Virtualdub would pick up gaps in the stream? I'm sure that Windows XP (or OSX) made a technically good file even if the stream had drops. Is this error check in Virtualdub just a file check?

Now if the HDD corrupted the file, maybe this error check would pick that up.

The error check in VirtualDub should see that the file is corrupt at a certain stage because the frames are interrupted just in the middle. If my theory about the harddisk problem is correct, the .avi files must be corrupted and there must be software which is able to detect this corruption. That's what I am looking for.

It would not be very likely that the missing parts inside an .avi file would be cut exactly at frame boundaries. On top of that, the continous IDs of the frames would indicate a problem.

Bye,

[edDV]

OK, I'm out of ideas.