split DV when time+date intermittent dgfsf

[2Bdecided]

I usually use WinDV to auto-split my DV tapes into clips, named by shooting date and time.

I've got some tapes which don't play back properly. On most, the video is good enough, but the date+time information keeps dropping out - in the camcorder viewfinder the recorded date and time metadata flashes intermittently when the tape is played back.

This messes up WinDV's auto split. Most of the time the correct date+time is there, but when the time drops out or is wrong, even for a single frame!, WinDV splits to a new file. So I'll get some files named with today's date and time, and files named with random dates and times, instead of the correct ones - and a single clip is split into tens of files with bizarre file names!

All the video is there, and the files can be stitched back together to get complete clips, but I don't know a way of automating this. Even manually, VirtualDub only lets you append one file at a time - not the tens of files per clip I'm getting at bad points on the tape!

The alternative is to capture without splitting, getting one tape per file. The (erratic) time+date information will still be embedded in this file - how can I use this to split the file by time/date, while ignoring the errant frame or few frames when the date jumps wildly (e.g. from 1999 to 2038!!!)?

Any suggestions? It seems a shame to lose the time and date information, and have to split manually (would windows movie maker split automatically on scene detection instead of date/time? Any other suggestions?), when the correct date+time is somewhere in the data most of the time.

Cheers,
David.

[minidv2dvd]

ScenalyzerLive might do it.

[JohnnyMalaria]

Try cleaning you cam's heads. It's possible that other parts of the signal are corrupted but being masked by error correction.

I'd be curious to see how our DV processor interprets the time/date. DV records time/date at a number different levels and multiple times within a single frame. The DV processor drills deeply until it finds something. Other software will give up if time/date aren't find at the first valid location. I also wonder...is the timecode also affected? Are the funky times/dates always 2038 - if so then this is your software's interpretation of empty time/date (0xFFFFFFFF in both cases). If that is the case then the DV processor could be used to replace errant time/date with the last good time/date. It might even work out-of-the-box using its scene detection mode which works with *valid* time/date info. I'd have to dig out the code to be sure.

[2Bdecided]

Thanks Johnny - I'll try your software.

There's no problem with the playback camcorder - these are tapes that were recorded on a camera "with problems", and have never played back properly on anything else. The original camera is now dead.

Getting sound+picture OK but with mangled timecode is the best I can do on the three cameras I have available.

It seems different cameras, when playing back, are sending different data to WinDV. On one, the date code drops out in a way that causes WinDV to split the file. On another, there's still a drop out, it doesn't split the file! Unfortunately that particular camera can't play the video itself so well on that specific tape.

Thanks for the suggestions both of you - I'll see what works.

Cheers,
David.