I'm trying to capture some PAL Hi8 tapes, but I'm getting a lot of inserted frames in VirtualDub.

Firstly, here's my workflow:
Sony CCD-TRV87E (DNR and TBC turned on) out via S-Video into a green AVT-8710 TBC into an ATI 600 USB (drivers obtained from here) into a Windows XP 32bit desktop PC (fresh install). I'm using the VirtualDub version obtained from here, with Huffyuv. OS is running on an SSD, capturing onto a brand new 2TB Sata HDD. All S-Video cables are brand new and decent quality.

I've got audio playback turned off during capture and I've disabled the network connection, so it's offline.
I'm getting zero dropped frames, but around 150 inserted frames in about an hour, but it's not consistent. If I disable inserting null frames, then the audio and video de-sync.

This doesn't seem to be related to the tape though, as I start seeing inserted frames as soon as I click capture and if I capture a live stream from the camera, I see the same issue.

I even tried capturing on an old laptop (also with Windows XP) and saw the same thing. I've no idea what's causing it though. The only thing I can think of at this point is that it could be the camera, but I've no other device with an S-Video out to test with. The ATI 600 USB and AVT-8710 were purchased from LS, so I doubt they're the problem.

Any advice would be greatly appreciated.

-- merged --

So to update on this, although I don't have anything else with an S-Video out, I was able to test this connected up to my old XBox using the composite connector and I still see exactly the same kind of frame insertion in VirtualDub.
This means it's not the camera. So it could be something to do with the hardware in the PC, but that seems unlikely as I've been testing this on my old laptop as well and seeing the same thing, or it could be to do with the capture card, which also seems unlikely as it's in good condition and is one that is widely recommended here.

I'm running out ideas for things to try now...

https://www.digitalfaq.com/forum/vid...g-default.html

Your CPU usage shouldn’t be in the 30s or above. It it gets around 50 you can expect issues.

Thank you for taking the time to reply. My CPU usage is between about 17% and 23% most of the time while capturing (the laptop I've been backup testing with is probably closer to 50%, but I don't plan on actually capturing with that).
My desktop is fairly powerful for a Windows XP machine:
CPU: AMD Phenom II X4 965
Motherboard: Gigabyte GA-790FXTA-UD5
RAM: 4GB DD3
GPU: NVidia GeForce GTS 250

The frame insertertions seem to happen randomly. I can watch it sitting there stable and then all of a sudden I get 1 or 2 frames inserted and I don't see any correlation with CPU usage or anything else. I even tried dragging a window around to force the CPU usage higher and although the usage jumped to around 50%, I didn't get any frames inserted from that, so I don't think CPU usage is the culprit here.

-- merged --

Does anyone have any other suggestions for this? :depressed:

I bought all the equipment recommended on here in the hope of getting the best capture, so I'd really like to fix this. I've tried with both Windows 7 and Windows XP and I always get about 7-9 inserted frames immediately followed by a 1 or 2 at seemingly random points.

What other factors could be causing this? RAM? Motherboard? PSU?

I'd personally give AmarecTV a try using this guide:
https://aaproductions.net/amarectv.htm

It also reports dropped and inserted frames and can use all of the same hardware. You also can check the log and also see specifically which frames were dropped/inserted after the fact which is kind of nice.

First test I'd do is a direct capture from the Xbox (which won't have timebase errors) to the ATI600 using Amarec. If you still get inserted frames with that, then you're narrowed down to either the capture PC itself or the capture card. Even though you don't plan to use your laptop for captures, try the above combo with the laptop and see if you still get frame insertions with that. If you don't, then it's something about the capture PC. If you get the exact same behavior, I'd say it's likely the capture card. If you get a different set of issues such as frame drops instead, that doesn't really narrow it down.

If either one of those doesn't insert frames, then add the AVT-8710 and see if that reproduces the problem.

To me, groups of frames being inserted one after another suggests that the video feed going into the PC is momentarily pausing. If video was still going in, then it'd get reported as a drop plus insert rather than just a bunch of inserts I'd think.

I had actually been considering trying AmarecTV, but then I'd also seem some stuff in the forums suggesting against it, so wasn't sure. I'm willing to give it a go to see if I get any different results from what I'm seeing with virtualdub though.

I agree with your analysis about the feed to the PC pausing, which is why I keep coming back thinking it's something with the PC hardware or drivers (although the fact I'm seeing the same thing with the laptop makes that theory harder to justify).

I might see if I can salvage together enough parts to build another PC... Between my brothers and I, we've accumulated quite the PC scrapyard over the years :laugh:

I'll try AmarecTV and report back with my findings :salute:

Amarec results seem like a foregone conclusion if VD's already giving you inserted frames but I'm interested in hearing how it works out.

If you haven't, you might also want to try (on VD) setting the Resync mode to Sync Audio to Video per https://www.digitalfaq.com/forum/vid...html#post45242 - there may be brief segments where the audio speeds up, but the frames were mostly accurate in my experience.

Replying as I read...

Hi8 is what I call a "drop-happy format". The output from the camera lacks signal continuity. With this format, frame TBC is required. (Sometimes a non-TBC frame sync works, but it still often gets overrun.) Which you already have...

Looks good.

But the OS needs to be de-crapified. Has that been done? The stock/default OS can still cause capture interruptions.

- What are the VirtualDub capture mode timing settings?
- Did you properly disable DirectX in the main preferences/settings?

150 is not normal.

I agree, not tape, somewhere in OS/software/driver. Possibly HDD I/O, but less likely.

Camera was also my first inclination, but more likely is settings. And no, "another computer" probably has the same settings. So it may be user error, which is a good thing, that can be fixed!

I has to be settings. (Not all computers are alike, hence why settings exist.)

<sigh> Again, for like the 100th time.

AmaRecTV is a Japanese streaming software, intended for specific Japanese capture cards. It's essentially the analog version of OBS. It was not made for capturing videotapes. It was created to stream video games. I hate to use the term "broadcasting" for streaming, but it shares a common element, namely in what it expects, in terms of dropped frames, and how that is reported. Drops are expected when you broadcast (or stream), because you never have 100% perfect I/O. It plays "catch up" in streams, and is part of TS (transport streams). As such, the only dropped frames reported are those that are not expected. Inversely, to archive videotape, you should expect 0 drops, because it's not being broadcast. This is why software matters.

So yes, "it shows 0 drops!". You can finagle the VirtualDub reporting too, by unchecking the top two boxes in the timing settings. It still doesn't mean "no drops". If I close my eyes, you can't see me, right? Right? (NO!)

There are literally two people online that refute this, and suggest AmaRecTV to the newbie lemmings out there. Rather than RTFM and setting up VirtualDub correctly, they want a dummy friendly software that lies to them. Whatever. I give my info, they're free to stick their head in the sand. Note that those two people lack actual frame TBCs.

Nope. Don't use a video game system, it's not 100% compliant. If anything, use a DVD player.

I'm sure it will "work", but it's not what you want.

Sometimes building a new system gives fresh perspective, especially if you're not had to mess with lots of capture systems before. Even I can get rusty, if I don't rebuild systems for a while. When you use computer for actual work -- not just screwing around on Facebook/whatever -- then everything needs to be tweaked. You have to get the environment set right.

Anyway, answer my questions about timing and DirectX in VirtualDub. :)

Apologies for taking so long to reply on this (I'm sure you've been waiting with baited breath!), but my capture PC pretty much died after I posted this. I think it was the motherboard that failed, so I can't answer some of what happened.
Since I needed new parts though, I took the opportunity to buy some components closer to what people here have recommended. I've now got an Intel Q6600 (my previous was an AMD CPU) and an ASRock 4Core1333-FullHD motherboard.
I also decided not to try AmarecTV, as my goal here is to remove variables, not add more!

There were some points you raised that I needed to fix though:
I was using a version of XP I found online, called the "Black Edition", however after searching the forums, I've found that the recommended verison is the "Integral Edition", which I'm using now. Is there anything else needs to be done with this version or is it sufficiently de-crapified out of the box?
I also hadn't disabled DirectX which I've done now as well.

One other major point that may have caused issues is the fact that I'd installed the OS onto an SSD, which I've since realised is not great for Windows XP, so I've now got 2 HDDs instead. One for the OS and the other to capture onto.

I'll start a separate thread to discuss my current issues, but basically, it's working much better now! I'm no longer getting any inserted frames during the capture (I get about 8-11 when I first start the capture, but that's fine, as I start the tape after that). I am however getting some dropped frames now, but that seems much more reasonable/fixable than what I was facing before!

So in conclusion, I think the inserted frames problem was hardware related (PC hardware, not capture hardware).