I agree with Cliff - more likely a hard drive problem than anything else.

First thing to check is if DMA is enabled for your hard drive controller (if EIDE). You get there through Device Manager.
Next, is there a slave device (if on EIDE) that is dragging the speed down because it is a lower UDMA mode?
Next, are there applications writing to the drive during capture? Even a screen saver coming up during capture has been known to cause dropped frames.
Next, try capturing to a different drive than the swap file is on. This often does the trick.
Another thing to check is IRQ sharing, although this usually isn't a problem in XP.

If my ideas (some outdated) don't help, post back because dropped capture frames should not be an issue on modern systems.

I wrote the dropped frame FAQ over at VASST:

Dropped Frames VASST FAQ

The only time hard drives are the problem is if DMA is turned off. If that is the case, you WILL definitely have problems. The FAQ describes how to check and fix.

Since this has happened on multiple computers, my guess is that your problem is background software. If you are running Norton/Symantec Anti-Virus, it is a pig and will cause problems. Ditch the turkey. Use MSCONFIG to turn off all your background programs (you don't need any of them to run the computer and you can turn them back on again with MSCONFIG).

As it says in the first line in my FAQ: How many dropped frames is acceptable? Answer: none. You should NEVER drop a frame when doing digital capture (analog capture is a different beast). Digital capture includes DV, HDV, and AVCHD (although since the last one is almost always on digital media rather than tape, it is simply a copy operation).

John,
That's a great reference page. I'll bookmark it.
It certainly shows that we've had similar experiences and conclusions over the years regarding frame drops.
I don't know if DMA works the same on SATA drives. Anyone?

I don't know if DMA works the same on SATA drives. Anyone? I'm beyond my pay grade in answering that one (i.e., I haven't experienced it myself). However, the function of DMA is to keep all traffic to/from the disk drive from having to be first copied and processed by the CPU. Thus, when doing a capture, once the path is set up, the bits go directly from the camera to Firewire to the drive, without having to be copied to the CPU register. The reason why this is so important when doing capture from a tape is that the tape drive cannot be paused and restarted (well, it can, but not dozens of times a second). Thus, if the bits coming in from the tape can't be stored or buffered, they have to be ignored (dropped). If the CPU has to do something else, especially when controlled by an application that sucks a lot of cycles, the transfer can be interrupted continuously.

I don't think there is anything in the SATA architecture that would make this impact less of an issue than with PATA (formerly IDE). However, others with direct experience may be able to provide better information.

The only other thing I've seen are problems if the 1394 card is also enabled as a network interface. I always disable it so it's been a while since it caused a problem. It may have been a problem because my system was serving up a printer for a few days. I got out from under that duty quick!

If you've gone through several PCs and cameras then unfortunately the only common element left is the operator - probably something you've set up the same way every time.

Rob Mack

Thanks for the replies. I totally agree, it is unacceptable to have any dropped frames when capturing!!! As much as it may hurt after all this time, if I could find out that it was user error, I would be dancing in the isle's to finally be able to capture without any dropped frames!! The only other common elements are all three of my PC’s have been Dell and all three of my cameras are Sony.

Let me provide my current system details and if anyone of you can see an issue with my set up, Please, Please let me know!

Dell XPS 400 3.0GHz Pentium Dual Core
O/S XP Media Edition Service Pack 3
3GB Ram
Three Serial ATA Internal Drives (DMA is turned on):

Seagate - 160gig 7200 rpm (My Boot Drive) Partitioned for Dual Boot
WD - 500gig 7200 rpm
Seagate -750gig 7200 rpm

The fist Seagate 160gig is partitioned so I can Dual Boot. I boot specifically to my second partition for Capture with Minimal Services/Background processes running - no Antivirus running.

Here is a list of Services Started:

Event Log
HDI Input Services
Logical Disk Manager
Remote Procedure Call (RPC)
Security Account Manager
Server
Shell Hardware Detection
System Restore Service
Themes
Window Management Instrumentation
Windows Time
Terminal Services

List of Process running (as shown by Task Manager)

explorer.exe
svchost.exe
mmc.exe
svchost.exe
svchost.exe
lsass.exe
services.exe
winlogon.exe
csrss.exe
System
System Idle Process

List of Programs running per – EndItAll:

winlogon.exe
services.exe
lsass.exe
svchost.exe
svchost.exe
smss.exe
explorer.exe

I would post a screenshot, if there was a way to post an attachment…

Again, any advice, insight, or just general sympathy would be appreciated.

Thanks!

Well, two things to check: turn off system restore for all drives except the boot drive. Also, make sure indexing is turned off for all drives. Get into Windows Explorer, right-click on the drive, go to "Properties" and make sure Indexing it turned off. Do this for each drive.

Everything you posted looks really good, far better than most people's computers.

I'm stumped as to what to suggest. Perhaps a bad cable? But having said that, I would think it would be an all-or-nothing issue. On the other hand, it might be the same cable for each computer and therefore be the common denominator.

I think that the key point here is that the captures are running for 60 to 80 minutes. During that time, pretty much anything could be happening to interrupt the capture software and cause dropped frames. I agree with johnmeyer. You've done just about everything obvious to troubleshoot this problem. There are only a few things left, like he said, like changing the cable.

Here's the rest. Try capturing 60 to 80 minutes with a different camcorder. Why? Because rarely, the Windows AVC driver that handles the captures has bugs that only show up with specific brands and models of camcorders.

Try setting the priority of the capture software to the highest setting with the Task Manager. Doing this will prolly not even allow you to use your mouse smoothly during a capture, but why would you? Next, make sure that all devices are set to stay with "power always on", including your network card, hard drives and anything else that shows such a setting in the device manager. I can't imagine why the power options would make a difference, but you never know. Also you could buy another Firewire card and test it to see if you get the same results. Lastly, you could try disabling any network connections, just to see if any NIC activity is interrupting the capture. These are all "bottom of the barrel" suggestions, but like everyone has said, you've covered all the obvious workarounds.

Have you tried capturing with the demo of the Cineform HDLink software? Maybe that might work. I'd run the Task Manager to see what software is using resources during your captures. A replacement for the built-in Task manager is Process Explorer:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Do you do on-the-fly scene detecting?

I have found that this for the most part causes nothing but trouble. I use HDVsplit and I capture the tape in its entirety (preview OFF, and syncronize audio/video OFF). I will then do scene detect AFTER the tape has been captured. I don't think I've ever had a dropped frame this way.

How many dropped frames are we talking about?

Dropped frames can be caused by many things and may have nothing to do with the computer or cables whatsoever. Of all the dropped frames I get it's been years since I've any that were related to the PC or the cables.
The dropped frame counter can increment because the capture software expected a frame and didn't see one in the stream. Tape dropouts are a common cause. When some cameras go into record they don't get upto speed any too cleanly, that'll also cause the dropped frame counter to up the count.
I can capture with no dropped frames on a very low end PC with the AV software, Skype, iTunesHelper etc, etc all running. With a problem tape on my fastest PC that's very clean I'll always get dropped frames because that's what's on the tape, missing / mangled frames.

Bob.

Bob, I hadn't thought of that: cheap tapes with lots of dropouts causing dropped frames. I can see how that might happen. However, that should be somewhat repeatable, i.e., if you re-capture with the same tape, you should get dropped frames the second time, assuming the tape is bad enough to have lost the bits completely at the bad spots. Also, this would happen across multiple computers and cameras (i.e., the tapes could be another common denominator).

It's not that repeatable surprisingly, it can depend on where the problem is.
One of my clients still has a couple of DSR 300s in service to shoot football. If it's a wet day there'll be dropouts but if I take the effort to recapture sometimes the dropouts are gone. Mostly this happens at the start of a clip, even more likely if the camera's battery got changed as this causes the tape to loose tension.

Last week or so I've been trying to recover some old programs from UMatic tapes. Despite having a TBC in the chain where the tape is really bad the TBC and A/D converter can loose the plot and I get dropped frames. Next pass over the heads the tape might be cleaner and the TBC keeps it together enough to not cause Vidcap to report dropped frames.

One thing's for certain. Using a camera to capture tapes is not a good idea.

Bob.

Thanks Guy’s,

I turned off the System Restore Process and I already had Indexing turned off on all drives. Still no Joy.

I am planning on trying a new cable, although I do agree that a bad cable would - 1) be all or nothing or 2) If intermittent, then by flexing the cable during the capture process I would be able to force dropped frames. But worth a try anyway.

I only user Sony Tapes: either the SONY DVM-60PRL or the DVM-80PRL depending on the length of what I am videoing. Once I start the camera rolling, I do not stop recording until the Act is over (I record archrivals for Amateur Theartre). Neither length of tape seems to have more or less dropped frames over the other. Under HDV Split, I Click the Stop Capture on Dropped frames. I can count on at least one (If not more) failures where I need to backup a couple of seconds and restart the Capture. The dropped frames can occur anywhere during the capture.

I will try ‘Process Explorer’ to see if that will show me anything that may be interfering with the capture process.

I personally believe that it is not the tapes or cable, but is some hidden process that is causing an interrupt. Especially after hearing that you all are capturing flawlessly on lower-end machines. I have watched the CPU performance with Task manger as well as the XP supplied ‘Performance Console’. When a dropped frame occurs, there is not even blip on either CPU or I/O. There is nothing to indicate a drain on the system resources.

Since this has plagued me on different equipment and for so long, it has to be something basic. That is the frustrating part; I have spent hours trying to debug this with no luck.

I do appreciate all your comments and suggestions!

Thanks!

Can you rent, beg or borrow a HDV VCR?
I and I think the rest of us are running out of ideas and after all the grief you've endured you need to try to narrow down your problem. It could be what's on the tape, it could be what's being used to play it or it could be what's being used to capture it.
Try to eliminate two or at least one of the variables.

Bob.