View Full Version : WinDV: a good program?
arnie.d
15th August 2005, 22:52
Hi,
I've captured DV with a few different programs now, but only programs that show if frames are being dropped. WinDV looks like a nice, very handy little program to me and it seems to show if frames are dropped. I tried to let it drop frames by putting my harddrive to work while capturing. I've run a lot of demanding programs, copied heaps of files while downloading but not a single frame is dropped, or so WinDV says. With other programs I couldn't do anything else on my pc while capturing or frames would be dropped. So does WinDV show correctly if frames are dropped?
DrP
15th August 2005, 23:20
WinDV appears to have some good deep buffering going on in it. I find its almost impossible to make it drop a frame, even writing to an extremely busy hard disk just makes the Q value jostle around a bit. Looking at the resulting captures, there are no pauses or jumps which suggests that no frames were actually dropped / replaced.
The only problem I've ever had with WinDV is that sometimes it won't full close down. Its window closes, but the program continues to run. When that happens, the only way to get rid of it is restarting the PC (can't kill it W2k / XP) or power cycle / unplug firewire from my Canopus. DVIO doesn't have that problem, but its far easier to cause DVIO to drop a frame or two.
neily
16th August 2005, 12:26
WinDV is a little gem. I have tried various programs such as Vegas, DVIO, Scenalyzer, but always come back to WinDV. I wrote a small program that checks the integrity of DV files and looks for dropped frames, and all I can say is that WinDV is reliable, and very resistant to drops. It only ever seems to "drop" with garbage at clip boundaries caused by tape reinsertion.
It is a shame that it is no longer being developed at all. It would be really handy if it not only reported drops but produced a log file to show in which clip the drop(s) occurred. I also found that certain values for the threshold for splitting files caused the length of video and audio to differ, causing sync problems. Also, for some reason, it stopped working - closing down when starting capturing. I spent a long time reinstalling DirectX and various other DV-related files, as was the suggestion I found googling, but in the end all I had needed to do was delete the registry entries for WinDV and reinstall.
trolltuning
17th August 2005, 17:21
(edited)
It is a shame that it is no longer being developed at all. It would be really handy if it not only reported drops but produced a log file to show in which clip the drop(s) occurred. I also found that certain values for the threshold for splitting files caused the length of video and audio to differ, causing sync problems. Also, for some reason, it stopped working - closing down when starting capturing. I spent a long time reinstalling DirectX and various other DV-related files, as was the suggestion I found googling, but in the end all I had needed to do was delete the registry entries for WinDV and reinstall.
Can you explain what type of thresholds were a problem. It would be nice to know before ending up with desynced files :D
neily
18th August 2005, 03:57
Capturing PAL, Type 2, I consistently had problems using 2000 frames. The file segments contained 80 secs of video, but 80.0013 of audio. I tried using this value as it was a nice integral number of seconds and frames, and also could be backed up onto DVD without too much disc wastage.
I went up to 8000 frames I think, which was OK, but in the end decided to capture to Type 1, which obviously completely circumvented the problem. It was a while ago, and fortuitously I came across the problem at about the same time VDub started supporting Type 1 DV files. Had this not been the case, I would have been more stuck.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.