Capturing on a hard drive with long stored files a bad idea?

[Master Tape]

I've been using a 2TB hard drive to capture my tapes for a while, and some files/folders have been stored on there for a few years now. Originally i just used this hard drive for additional storage for some stuff and for whatever reason never transferred the files off it. And capture with the remaining space.

Could doing this cause any artifacts with your captures? As for a while now i've been having this combing lines artifact (i'm guessing duplicated fields) appearing on my captures at random intervals, could happen a couple of times per tape, or once if im lucky.


[Attachment 89798 - Click to enlarge]

[jagabo]

No.

And why does the picture fill only about 496 lines of the 576 frame? Something is resizing an interlaced video improperly.

[CaptureCraft]

If disk is constantly being used it could be heavily fragmented.
Then during the capture process it could take too much time to write to it, assuming it is a spinning drive, not SSD.
That delay might affect your process.
Though, to be honest, it is a little bit of stretch.

[Master Tape]

No.

And why does the picture fill only about 496 lines of the 576 frame? Something is resizing an interlaced video improperly.

Because it was recorded on analogue tv when it started broadcasting in 14:9 during it's latter years.

To troubleshoot further i wonder if it's anything to do with my settings in Virtualdub. Is capturing with a lossless codec like Huffyuv v2.1.1 on a Windows XP era PC fine, or will it be adding extra work for the CPU?

[Alwyn]

To troubleshoot further

Is that still image of an interlaced AVI playing in VLC? Try setting the deinterlacing to ON (Video>Deinterlacing>ON) or post a snippet here for the members to take a look at.

[Master Tape]

To troubleshoot further

Is that still image of an interlaced AVI playing in VLC? Try setting the deinterlacing to ON (Video>Deinterlacing>ON) or post a snippet here for the members to take a look at.

Yes it is from VLC and is set to deinterlacing.

[davexnet]

Best to provide a video sample, a few seconds showing the problem.

[dellsam34]

Whatever codec you're using it is wrongly de-interlacing as Jagabo mentioned, Capture lossless and de-interlace and encode later, you think you're saving time processing on the fly but you are wasting more trying to figure out what just happened.

[lollo]

It is unlikely that that defect is caused by a fault in the writing process to the HD. Generally this shows as a missing frame (or field, which may alter the frame construction, but is rare).

The rule we applied few decades ago was to capture to a dedicated drive, and to defragment it (or better format it) before any capture (the main reasons being the swap memory allocation by the OS and the internal bus congestion, together with a large clean space availibility for writing in the HDD). The main reason is not the data rate of the incoming stream (easily covered by drive devices performances), but the "continuos writing" constraint.

Nowdays, with modern hardware we can easily capture to a modern SDD where the OS is running (provided the rest of the hardware/software is optimized). What is still valid is to do not use external drive (USB, etc) for capturing.

As other said, if you post a sample of the capture we can analyze its video architecture. Also post the the log of the capture if you are using AmarecTV or the VirtualDub captures frame count information if available.