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.

[Master Tape]

Here's a couple of examples.

[Master Tape]

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.

I have been capturing lossless. I don't deinterlace until i edit and render the video. It's like this to start with.

[CaptureCraft]

Have you ever tried to re-capture the same fragment?

[Master Tape]

Have you ever tried to re-capture the same fragment?

Yes i've had to go back and recapture those parts and splice them in. It only happens during random intervals.

[dellsam34]

Your captures look wrong on my end, looks like the fields are blended somehow, What's your workflow hardware and what software are you using and what output setting you selected?

[Sharc]

To me it looks like intermittent TBC failures/TBC processing artifacts.
@MasterTape: Disable the TBC in your setup (and accept some flagging): Do you still get these artifacts?


[Attachment 89841 - Click to enlarge]

[CaptureCraft]

Here's a couple of examples.

I checked your videos. It looks like you get some lines from the next half-frame.
You need to eliminate devices from you chain on-by-one until you will have just the capture card.
If that not gonna help, then you have to consider to change your capture card. Buy EZcap just for the sake of testing.

[jagabo]

I agree with Sharc, the TBC's dropout compensation is kicking in on the bad frames.

[Master Tape]

Your captures look wrong on my end, looks like the fields are blended somehow, What's your workflow hardware and what software are you using and what output setting you selected?

Panasonic NV-HS860 > DataVideo TBC-3000 > ATI All-In-Wonder 9600 Pro. Capturing it on Virtualdub lossless AVI with Huffyuv codec. It's on a legacy PC running Windows XP for the purpose of the capture card.

To me it looks like intermittent TBC failures/TBC processing artifacts.
@MasterTape: Disable the TBC in your setup (and accept some flagging): Do you still get these artifacts?

The TBC inside my VCR or my external TBC?

Here's a couple of examples.

I checked your videos. It looks like you get some lines from the next half-frame.
You need to eliminate devices from you chain on-by-one until you will have just the capture card.
If that not gonna help, then you have to consider to change your capture card. Buy EZcap just for the sake of testing.

I do have a cheap capture device somewhere. I could always capture a tape and see what happens.

[Sharc]

To me it looks like intermittent TBC failures/TBC processing artifacts.
@MasterTape: Disable the TBC in your setup (and accept some flagging): Do you still get these artifacts?

The TBC inside my VCR or my external TBC?

Both. (It's usually a bad idea to have both enabled anyway).
If switching off both helps, you may enable the TBC in the VCR or the external TBC and try again, and draw your conclusion of which one is the culprit.

[lollo]

Both. (It's usually a bad idea to have both enabled anyway).

In fact the TBC of the NV-HS86 VCR and the TBC of the DataVideo can cohesist very well, addressing different issues.
As always, check that the external DataVideo TBC is really needed, it migth not be the case (and when not needed we reduce the quality and may introduce errors, because they are never fully transparent).

In the samples provided the captures are bad, because the single fields are corrupted (and the first is of a tape in really bad shape). It could be a problem inside the tape (i.e. at the time of recording). If OP can use an alternative (to his excellent) capture workflow as suggested by CaptureCraft, this can help for a better assessment.

[dellsam34]

I can put my money on the DataVideo TBC-3000 being the culprit, We've seen it before. Add an external TBC only if you run into problems, if your captures are fine there is no need to add an extra analog to digital and digital to analog conversion, If you do need it, it may need to be fully serviced including replacing some caps.

[Master Tape]

To me it looks like intermittent TBC failures/TBC processing artifacts.
@MasterTape: Disable the TBC in your setup (and accept some flagging): Do you still get these artifacts?

The TBC inside my VCR or my external TBC?

Both. (It's usually a bad idea to have both enabled anyway).
If switching off both helps, you may enable the TBC in the VCR or the external TBC and try again, and draw your conclusion of which one is the culprit.

Well the first example was captured with the TBC in the VCR turned off, so all signs point to it being the external. I normally use a Panasonic ES-10 whenever i have to with tapes the VCR's TBC doesn't like, or to straighten things up a bit better on analogue cable channel recordings which are usually a bit more unsteady due to the encryption.

I can put my money on the DataVideo TBC-3000 being the culprit, We've seen it before. Add an external TBC only if you run into problems, if your captures are fine there is no need to add an extra analog to digital and digital to analog conversion, If you do need it, it may need to be fully serviced including replacing some caps.

I just had all the capacitors replaced inside it, but still having this issue. It did fix another issue i had with the proc-amp buttons not working on one side.

Would trying Side B instead Side A make any difference to my captures?

It does make me wonder if i should just get a different TBC. Maybe something like a TBC-1000 as this has more features and is bigger, which probably means more things can go wrong.

Both. (It's usually a bad idea to have both enabled anyway).

In fact the TBC of the NV-HS86 VCR and the TBC of the DataVideo can cohesist very well, addressing different issues.
As always, check that the external DataVideo TBC is really needed, it migth not be the case (and when not needed we reduce the quality and may introduce errors, because they are never fully transparent).

In the samples provided the captures are bad, because the single fields are corrupted (and the first is of a tape in really bad shape). It could be a problem inside the tape (i.e. at the time of recording). If OP can use an alternative (to his excellent) capture workflow as suggested by CaptureCraft, this can help for a better assessment.

Isnt a TBC always needed though? It purifies the signal and helps with sync. When i've went without it i get terrible syncing issues, and need to fix it manually.

Those two sample clips were from LP recordings. It's all i could find for now. They have done it during SP recordings aswell though.

Interestingly when i recaptured that sample, it played fine with no issue. So it's a bit inconsistent.