Bad VCR timing?

[bmichaelb]

I've been dealing with this issue for quite a while now, where the image periodically stutters while capturing. It doesn't seem to be dropping or inserting frames though. I originally thought it was my Hauppauge cards, or even AmaRecTV. So I purchased a Pinnacle USB-510 off of lordsmurf, and although I originally thought it had fixed the issue, it's actually getting worse. Both in VirtualDub and AmaRecTV, on both the Hauppauge cards and the Pinnacle in both apps. I could never get VirtualDub to capture properly with the Hauppauge cards, but the Pinnacle seems to be rock solid... if you ignore this stuttering. I originally couldn't get the Pinnacle working in AmaRecTV, as it won't recognize the audio input, even after fiddling with the 'Crossbar Thing' config app. I found a workaround by using the Hauppauge audio input instead. But it's still the same stuttering.

I'm pulling my hair out with this. I've seen similar stutter watching Netflix, but not as bad as this. And it seems to be doing it on all my tapes, both the Woodstock recordings and a hockey game from 1995. Different tapes from different machines, all having the same issue. So if it's not the capture cards, or the capture programs, is it possible it's the VCR's timing? It's a JVC HR-S7800U that was serviced 2 years ago, and used maybe 100 times since. I also have a JVC HR-S5911U, but it needs repair before I can compare it with the 7800U.

I can only upload a 99mb file here, so I posted to dropbox instead. It looks like crap if played over the web, so best if downloaded. Any help appreciated.

https://www.dropbox.com/scl/fi/9bqcw...=vfwdb3kd&dl=0

[lordsmurf]

The glaring issue I see here is lack of frame TBC in that workflow. However, let's table that for the moment. Your clip is short enough to not showcase typical lack-of-(frame)TBC errors, and this one does not.

Your clip is fine.

Attached is my QTGMC'd 59.94fps version, H.264 in MKV, audio muted. For the sake of file size, and avoiding adding compression artifacts, I zapped it with a strong NR. So you can notice just motion, not noise, not sounds. Do you see how clean that is?

I think the root issue is that your capture computer (or another computer?) is not fast/strong enough to play lossless files without I/O issues. So you get digital file lag, likely also digital tearing. But in an editor, it's fine. On my 2015 i7 build, all Samsung SSDs, your lossless plays in VLC and VirtualDub 99% fine. In VirtualDub and Avisynth, even with filters, smooth as glass/butter, advancing frames at near-realtime.

Literally no error here -- at least none that I can see.

Your captures are fine, though a bit noisy (you're using EDIT mode, yes?)

That Avisynth script, if curious:

AVISource("V:\test.avi")
AssumeTFF
QTGMC
DeGrainMedian(limitY=15,limitUV=7,mode=0, norow=true)

[bmichaelb]

Thanks lordsmurf. I originally had a 2 min 11sec clip, but the last pan of the crowd at 0:40:xx showed the worst of it in the clip I linked. Although it's definitely smoother in your clip, there's still a hiccup at the end of the crowd pan at roughly the 46 second mark. That's in Media Player and VLC. It's still choppy as hell in VirtualDub. I know VDub's not a 'player', but how the heck am I supposed to check my captures? Capturing in VDub, and the preview shows all the jitters. Capturing in AmaRecTV also shows the jitters. I've re-recorded these tapes so many times over this that I'm starting to see wear on my first tape. Playing the HuffYUV file in VLC is just as choppy... is it the conversion to x264 that fixed it for smooth playback? I mentioned in pm that converting it to 30fps seemed to fix it as well. If all I had to do was convert to another format that the pc was happy with, then well... I'm p*'d.

As for the noise... I thought it was the age of the tapes, but looking back at the previous attempt with a vhs to dvd recorder deck, it's the same amount of noise still. I would have used those files, but out of the 2 machines I tried, neither had a TBC, so they all had wavy edges. Even the Sony deck. What a waste of money.

And yes, it's in Edit mode. I've read where you said people who say it shows more detail are confusing noise with detail, but I beg to differ. Even in this clip... the singer has stubble on his face that you can make out the individual hairs. But with Normal/Auto mode, that stubble is blurred out to a shadow. the same with arm hair... you see it in Edit mode, but it's pretty much gone in Auto/Normal mode. And with head hair, you see the individual strands in Edit mode, but they're blurred together in Auto/Normal mode. The same goes for the feathers in his hat in this clip. But even with the noise in Edit mode, I've gotten some pretty good results in Neat Video, and I can still see the individual stubble hairs.

Here's the longer clip btw...

https://www.dropbox.com/scl/fi/g22bp...=emr53qbx&dl=0

[lordsmurf]

Wait, uh oh, let's back up.

Did you make the mistake of disabling the top two checkmarks in the VirtualDub timing setting? Because that effectively just disables dropped frames reporting, not prevent dropped frames. So it shows 0 drops even with actual drops.

I did see some potential dropped frames in your clip, at the end, in the crowd pans. The problem I had was that the pan was wide angle, and the distortion was obscuring some of the smooth motion. I actually reviewed that segment several times, both realtime and slowed down. I just did that again, and my analysis is inconclusive given the facts thus far. It does seem fine.

In my system, I just have the integrated Intel HD iGPU, not some fancy Nvidia/whatever GPU that doubles as a room heater. I edit/restore SD video, I'm not a gamer. So I can get digital tearing in videos where the motion is too fast, which includes these pans. I have to watch those multiple times, or switch to a newer system (like my Mac Mini M2 Pro, and that's not always an option, it's busy).

I'm still not convinced this is a tape/signal/VCR issue, but rather hardware limitations, maybe VirtualDub setup/

- Confirm your VirtualDub timing settings. And VirtualDub 1.9.x, correct? Not 1.10.x, not VirtualDub2?
- What are the spec of the computer being used for playback?

[bmichaelb]

I actually posted my settings in the thread about no audio with the Pinnacle. The only thing different than the recommended settings is I checked the box disabling resync if it detects an integrated audio/video stream from a capture card that handles both on the same chip. With it enabled, the Audio Resample data in the box to the right of the window, it says "+0, -0, +0, -0", and the "total:" at the bottom the window only changes by 0.0000001 up or down, and "0ms jitter, 0ms disp". (Is "disp" disparity?) With it disabled, none of the data changes. I've tried both ways, both have the same jitters.

At the lowest level, it flutters every 5 to 10 seconds like in a cycle. At the worst, it jitters like you see in the pan shots. Most of the captures stuttered in the same spots, while other captures were smooth where it jittered, but then jittered where it was smooth in the original capture. That's why I thought it was a vcr issue.

I do have an Nvida card... an RTX 3060. My cpu is an Intel Core I5-10400F, so no onboard video. I was thinking of upgrading it though, maybe that's the push I need.

Edit: And I guess simply disabling preview during capture wouldn't fix it either(?).

[lordsmurf]

Uncheck "Correct video timing", that often causes problems.

When you see "flutters" during capture, what is the CPU spiking to? Video capture is still a per-core task, so newer fancy CPUs are worthless, especially the newest "efficiency" cores.

Actually, Nvidia cards are historically worse for video, for whatever reason. Those are great for gaming (or so I'm told, I don't game), GPU for editing and restore tasks. etc. But for video ingest, it's an added layer, in the way. Very often, when the iGPU can be switched to in advanced OS settings (Win7 and higher), for use by VirtualDub, it will clear up issues. This is a common problem on many high-end laptops.

Disabling preview does nothing helpful, never do that. Also no reason to disable audio preview.

[bmichaelb]

Thanks, I'll try disabling that then.

The cpu doesn't go over 6% capturing raw YUV in VirtualDub, or 20% capturing HuffYUV. It's not just flutter in the capture window, as I'm noticing it during playback in VirtualDub while checking which frames might need some work done.

As for newer fancy cpu's, that's actually near the bottom of the barrel, and 4 generations old already. The "F" just means no onboard video, so it's cheaper. I had a Core2Duo rig with XP up until 2018, but I got into VR... the only gaming I do. That's a different rig than my capture rig, and I use it for editing as well. I then built a pvr pc, with the Hauppauge tuner card to work with a DIY antenna. That pc is now my capture pc. It's nothing special in today's world. I'd rebuild the Core2Duo rig, but I need a new/used motherboard. I still have DDR3 ram to boot.

I actually used to have an ATI AIW 2006, back in 2006 or 2007 with the Core2Duo rig, but everytime Catalyst updated it was hit and miss. Years later, I wish I knew what I had and actually how to use it better.

[bmichaelb]

Something I forgot to mention... when capturing the dvd's of the same tapes, there's no flutter or jutter whatsoever, they're completely smooth.

[aramkolt]

The "no issues with DVD" capture kind of suggests timebase errors are the issue as DVDs do not have time base errors. The Other test you could do is try capturing from a 480i video game console and those also won't have time base errors. Really you shouldn't be capturing from a DVD for archival purposes (better to just rip the DVD directly), but it does make for a good test of the system in feeding it an ideal "time base error-less" signal.

[bmichaelb]

Quote:

Originally Posted by aramkolt

The "no issues with DVD" capture kind of suggests timebase errors are the issue as DVDs do not have time base errors. The Other test you could do is try capturing from a 480i video game console and those also won't have time base errors. Really you shouldn't be capturing from a DVD for archival purposes (better to just rip the DVD directly), but it does make for a good test of the system in feeding it an ideal "time base error-less" signal.

Thanks for the reply. The only reason I captured the DVDs through capture card, was so I could patch a few frames here and there in the VHS captures, and wanted to keep both sources looking as close as possible to each other. My very first tape got damaged for the opening 30 seconds due to me not waiting long enough after cleaning the heads, with the tape getting stuck on the head drum. I used to use 70% alcohol, but purchased some 824 isopropyl electronics cleaner from MG Chemicals... it took longer to evaporate for some reason. So now the clip has a few thick grey lines rolling down the frame for a few seconds, but I'm able to pull that from the DVD. I've tweaked the input levels and a few color tweaks in VDub to get them almost identical, then found a splice point where the image fades to white out of one sequence, then back into the next sequence, so the transition is invisible. It's still a bit wavy though, but it's only a 60 second intro, and there's not too much going on onscreen, just a shot of the stage and crowd from high up, and a still image for 'Columbia House'.

But after disabling the 'correct video timing for fewer frame drops/inserts' option like lordsmurf suggested, it still had 'some' flutter, but the crowd pans were a lot smoother, and there was no obvious jolts that look like frame drops, but are clean when scanning the timeline. I then did a quick deinterlace using the YADIF option in VDub, using TFF at 2x the speed, and the resulting file is almost perfect in VLC. There's still a tiny bit of flutter, but no jitter, even in the crowd pans. There's still the odd single jerk in some of the crowd pans, but where it used to go '..........||||||' it now goes '.........|'. It's still jerky when played back in VDub though.

As for timing issues... the JVC has the 2mb line tbc, and I'm using the Panasonic DMR-ES16 as passthrough. I have a video mixer, and although I thought it was fine, examining a clip through my TV that's been calibrated for both SDR and HDR, the colors looked a bit dark, smeared and flat. So, I'm only using the mixer for the audio levels instead, and using the DMR-ES16 as the frame sync. Whether the JVC is used on it's own with it's TBC, or disabled then use the DMR-ES16, it's the same timing issues. I did notice the JVC's TBC adds a yellowish or greenish tint to everything though... Bonnie Raitt's blonde hair looks a bit green, while her pink face looks yellow. I also get top edge tearing for 5 minutes on 1 tape, and 8 minutes on another tape with the JVC's TBC enabled, so I have to use the DMR-ES16 for those 2 sets. So to keep them all looking the same, I'm disabling the JVC's TBC, then just using the DMR-ES16 instead. It definitely keeps the colors better than the JVC.

I'm thinking that 'maybe' it's my RAM. I have 32GB DDR4-3600, but it's 2 pairs of 2 sticks, not a single 4 stick bundle. Each pair is paired with it's partner using the serial numbers on the sticks (xxxxxxxx19, xxxxxxxx20), but I have experienced a few system issues here and there that would be tied to RAM. I'm going to pull 2 of the sticks, and if that doesn't improve anything, then I'll disable XMP and just use the stock 2133 speed. And if that doesn't work, then I'll swap them out for some DDR4-2133 RAM. CPU doesn't have any overclocking, except enabling all cores to run at top speed, and my GPU is stock as well. And... this is the 2nd motherboard I've tried.

[aramkolt]

Since DVD doesn't have the problem, I don't think that supports it being the RAM. 2GB of DDR2 RAM is probably still more than is necessary for video capture on an XP machine. You should be able to find an XP capable machine on Facebook marketplace for less than $50 for testing purposes I would think. From there, probably just needs an SSD for the OS and capture drive to be useable. Downside with XP machines is that they tend not to have USB3 and sometimes not even SATA. Any P4 (non-Celeron) desktop processor should be fine.

[bmichaelb]

Quote:

Originally Posted by aramkolt

Since DVD doesn't have the problem, I don't think that supports it being the RAM. 2GB of DDR2 RAM is probably still more than is necessary for video capture on an XP machine. You should be able to find an XP capable machine on Facebook marketplace for less than $50 for testing purposes I would think. From there, probably just needs an SSD for the OS and capture drive to be useable. Downside with XP machines is that they tend not to have USB3 and sometimes not even SATA. Any P4 (non-Celeron) desktop processor should be fine.

As I mentioned earlier, I have a Core2Duo E8500 3.16GHz and some DDR3 RAM already, but when pulling the SATA cable from the socket on the motherboard, it had a locking mechanism in the cable itself, and it wouldn't disconnect. I wound up pulling the socket off the board. The Pinnacle works on USB2, and I'm plugged into one of the sockets on the board itself, not the rear I/O. Although USB2 devices work with USB3, I've had issues in the past where USB2 things worked better with USB2.

After setting the CPU to default and disabling XMP on the RAM, I did notice the crowd pans were a lot choppier. I pulled the RAM and inserted the 2 sticks of 2133... before XMP was a thing. It's still jittery, but not as choppy as it was with 3600 RAM with the XMP disabled. I'm going to see what it's like after deinterlacing.

We used to have a 'Cal's Computer Warehouse' that was a huge building, full of parts from as far back as the early 2000's. They also had a return policy if things didn't work when you got home. Unfortunately it shut down around 2010-ish. We do have a Free Geeks though... and it's within walking distance. I guess I'll truck on over tomorrow or Friday.

[bmichaelb]

Well, this capture definitely plays smoother once deinterlaced. Crowd pans are 'almost' completely jitter free, but there's still a tiny bit of flutter on still shots. But, hitting the rewind button in VLC after seeing some flutter, and some of the scenes are then completely smooth. Go figure.

I just found out that unfortunately Free Geeks closed down in 2022 after a fire, but another store nearby has some older boards. Unfortunately I cannot find my copy of XP. I moved recently but can't remember where it went. I've read Microsoft offers an image to use in a Virtual Machine, but it's only good for 30 days. I'd be able to use it with my current system though, after installing Linux. I used to use Linux quite a bit until I built my VR rig. VR needs Windows... blah.

[lordsmurf]

Quote:

Originally Posted by bmichaelb

As for timing issues... the JVC has the 2mb line tbc, and I'm using the Panasonic DMR-ES16 as passthrough. I have a video mixer,

This doesn't work.

- JVC has quality line TBC.
- ES15 has strong+crippled line TBC, but it also messes with image quality (posterization, off-luma, etc)
- mixers may have weak line TBC, or weak frame TBC, never both -- and most have neither, and I think that's you.

You have no frame TBC. And what you experience (dropped frames, aka "stuttering" or "jerking" of the image) is exactly why frame TBCs exist.

You also cannot use JVC+ES15 line TBC at the same time. The 1st TBC in a workflow "wins". First line, first frame. Like TBCs cannot stack. (Line + frame complements, it's not stacked.)

The ES15 has a non-TBC frame sync, but it's weak, and the signal can run over it.

Now, that specific capture card you have can be more resilient to errors. But "resilient" is sort of like "water resistant" and not "water proof", not at all the same. You get less errors that you would have otherwise, but it's still errors. Over the course of your tape, I can guarantee audio will drift. The reason is because video drops, audio does not. So you have more/longer audio and than video. This cannot be fixed post-capture. Preventing dropped frames is the fix.

It's not RAM.

Deinterlacing is simply hiding the error. It's still there, audio will still drift.

You need a frame TBC. Not just any random TBC, but units that are known to function well with consumer sources (VHS, etc). And it needs to be in refurb'd/recapped condition, not some random "used" POS off eBay. Those recyclers/resellers don't know a TBC from a toaster.

This is extremely typical, and is exactly why TBCs are constantly references.

Nobody likes to buy boring magic boxes, but it's a tool. I don't like buying screwdrivers either, but you need what you need. Refrigerators are expensive, washing machines are expensive. But I like cold food and clean clothes, so I do what I must. If you want video to not suck, buy the TBC, move on with the project.

[bmichaelb]

Well my first 3 tapes in the pile are second generation SP tapes to cover the first 5 1/2 hours where my cable company didn't actually flip the switch for my ppv. I had to borrow the footage from a friend of mine. I used a Go Video dual deck to dub them, and although it had a full frame tbc, the edges look jagged. I didn't notice on a CRT TV, only noticed when viewing on an lcd. The JVC's tbc has an issue with this, and actually makes it look worse, looking a bit wavy. The ES-16 handles it the best.

As for dropped frames though, I'm not experiencing that. You scrubbed through the timeline yourself... no drops and no inserts. It looks more like vfr being forced to run at cfr. I had better results with my i7-7700K rig that died recently... still looking for a Z270 motherboard. The only reason I didn't keep those captures, was the jitter in the crowd pans, but I didn't see any flutter on a timed cycle. that's why I thought it might be the RAM... something with the timings causing a hiccup every few seconds. But with the crowd pans, I've been playing with QTGMC and it's pretty freaking smooth played back in VLC. It still has a tiny bit of flutter though.

# Retain Noise / Grain
QTGMC( Preset="Slower", NoiseProcess=1, NoiseRestore=1.0, Sigma=2.0 ) # Retain *all* the noise / fine detail of a less noisy source
QTGMC( Preset="Slower", NoiseProcess=1, GrainRestore=1.0, Sigma=2.0 ) # Similar to above but only keep the more "stable" noise elements (depends on TR2)

Also, there is no audio issues... no drops, and no inserts with this Pinnacle in VirtualDub. And the Hauppauge was rock solid in AmaRecTV. Audio was in perfect sync.

[lordsmurf]

Quote:

Originally Posted by bmichaelb

I used a Go Video dual deck to dub them, and although it had a full frame tbc

Not correct. No VCR has frame TBC.

Quote:

It looks more like vfr being forced to run at cfr.

That doesn't exist in a videotape context.

Quote:

As for dropped frames though, I'm not experiencing that. You scrubbed through the timeline yourself...

If you see stutter/jerking/"flutter"/whatever, and the capture card software shows zero drops, then it's likely happening within the ES15. Because, again, line TBC only, non-TBC frame sync. The non-TBC frame sync will insert/drop internally, in order to maintain rough self-clocked timing. That all happens before the capture card, hence no reporting.

I did scrub your video, multiple times. I'm not 100% confident that no drops exist, but I didn't see dupes/inserts. That's also just a short clip.

I'm now thinking combination of issues. Both actual dropped frames pre-card (maybe even the source?), and playback issues that cause digital tearing/etc. So bad error amplified. The QTGMC deinterlace, saving as H.264, somewhat hides both.

If audio sync is truly solid, source stutter could be it. After all, these were broadcaster, not original camera shot.

Lack of frame TBC still isn't a good idea. But JVC+ES15+Pinnacle, the exact versions/items in use here, is "least worst". New computer, deinterlace/reencode, and maybe (cross fingers) that will be sufficient. With no funds for a frame TBC, I'm hoping that's all it is for you, I never like to see impasses.

Good luck.

[bmichaelb]

Quote:

Originally Posted by lordsmurf

Not correct. No VCR has frame TBC.

That doesn't exist in a videotape context.

If you see stutter/jerking/"flutter"/whatever, and the capture card software shows zero drops, then it's likely happening within the ES15. Because, again, line TBC only, non-TBC frame sync. The non-TBC frame sync will insert/drop internally, in order to maintain rough self-clocked timing. That all happens before the capture card, hence no reporting.

I did scrub your video, multiple times. I'm not 100% confident that no drops exist, but I didn't see dupes/inserts. That's also just a short clip.

I'm now thinking combination of issues. Both actual dropped frames pre-card (maybe even the source?), and playback issues that cause digital tearing/etc. So bad error amplified. The QTGMC deinterlace, saving as H.264, somewhat hides both.

If audio sync is truly solid, source stutter could be it. After all, these were broadcaster, not original camera shot.

Lack of frame TBC still isn't a good idea. But JVC+ES15+Pinnacle, the exact versions/items in use here, is "least worst". New computer, deinterlace/reencode, and maybe (cross fingers) that will be sufficient. With no funds for a frame TBC, I'm hoping that's all it is for you, I never like to see impasses.

Good luck.

So... full frame TBCs are not what's used to strip Macrovision? Or not what fixes errors caused by creases and dropouts? As far as I knew, that's a full frame TBC. That deck stripped the sync signal associated with Macrovision, fixed vertical jitter, and repaired creases and dropouts like they never existed. It may have sucked at dubbing, but I sure wish I still had it for a playback deck for transfers.

As for the flutter... it happens with either the Hauppauge or the Pinnacle, without the ES16 inline, so no, it's not the Panasonic. And as I said, after deinterlacing and viewed through VLC, as soon as I saw a flutter, I hit the rewind key to go back 5 seconds... as soon as it replays that section, the flutter was gone. That pretty much sounds like no dropped frames. The flutter's definitely on a timed interval though... I can literally see when it's going to happen during playback. There's a scene where the 'this is a ppv, no rebroadcast or showing in commercial establishments' is running along the bottom of the frame, and it's completely smooth. Then it starts to jitter, then goes smooth again, then starts to jitter again... the exact same number of jitters. But as I said, during playback it seems to be fixed if I rewind and play the section again. So, it doesn't seem to be baked into the clip... it's something to do with my pc.

-- merged --

So as I'm reviewing a capture in VirtualDub, I stopped and rewound a bit when I saw flutter, then pressed play again... it was also smooth. That got me thinking maybe it's my GPU, or at least the drivers. It's an Nvidia RTX 3060, with stock settings. I pulled it and inserted my 12yr old Nvidia GTX 660 that I used to have in my previous capture rig that didn't have the flutter issue... no more flutter. It still has the jitter in camera pans, but that's fixed by deinterlacing. So, so far, this seems fixed. Fingers crossed.

[lordsmurf]

Quote:

Originally Posted by bmichaelb

So... full frame TBCs are not what's used to strip Macrovision? Or not what fixes errors caused by creases and dropouts? As far as I knew, that's a full frame TBC. That deck stripped the sync signal associated with Macrovision, fixed vertical jitter, and repaired creases and dropouts like they never existed. It may have sucked at dubbing, but I sure wish I still had it for a playback deck for transfers.

Correct, no, TBCs do not necessarily "strip out" anti-copy (including Macrovision). TBCs remove that part of the signal, while other "clarifier" devices (many non-jargon names existed) attempted to blank out snippets of the signal (without a frame buffer). Those "clarifiers" were very variable in effectiveness, based on the source signal properties. Many 80s and some 90s VCRs simply ignored that part of the non-visual signal, without either a TBC or "clarifier" to be had -- but again, variables effectiveness.

Those Go.Video GV-2000 dual decks (made by Samsung) were literally some of the very worst VCRs ever made.

Perhaps you mean a Go.Video combo VHS/DVD unit from the 00s? And not the infamous double-VHS "dual deck" om the 90s? Those were from another OEM, just a rebadge, and some of the DVD recorders were actually decent (LiteOn rebadge, LSI based).

Or maybe that odd JVC S-VHS rebadge?

"Fixing" jitter tends to be based on transport quality, and I'd have to see it with my own eyes to see a Go.Video GV-2000 actually improving signal quality. Literally every decks I've ever seen, received tapes from, or even read about, was complete crap. The combos may have been better, as Go.Video itself never made anything.

Dropouts are based on the DOC. Everything from low-end to high-end has varying DOC quality. Some of the highest end "professional" VCRs (VTRs) have zero DOC, while some of the cheap $100 specials from the 90s have decent DOC.

BTW, the company was known as:
- Go Video
- GoVideo
- Go-Video
- Go.Video

Such an inconsistent mess of a company. Good riddance.

See also:
https://www.digitalfaq.com/forum/hom...dual-deck.html

Quote:

Originally Posted by bmichaelb

So as I'm reviewing a capture in VirtualDub, I stopped and rewound a bit when I saw flutter, then pressed play again... it was also smooth. That got me thinking maybe it's my GPU, or at least the drivers. It's an Nvidia RTX 3060, with stock settings. I pulled it and inserted my 12yr old Nvidia GTX 660 that I used to have in my previous capture rig that didn't have the flutter issue... no more flutter. It still has the jitter in camera pans, but that's fixed by deinterlacing. So, so far, this seems fixed. Fingers crossed.

So ... I was correct in my very first reply.

For me, the main issue here has been your use of the non-jargon word "flutter", and I find myself trying to guess at what you mean. It does seems like digital tearing, but I could not 100% rule out lack of frame TBC. I think you've confirmed it here.

And Nvidia cards are infamous for messing with interlaced SD analog captures. Not sure which part causes it (the interlace, the SD, whatever). Sometimes fancy is too fancy for it's own god.

[bmichaelb]

No, it was a dual-deck vcr dubber. I "think" it was the DDV9500. As for the stripping of the Macrovision signal, I'm pretty sure I got that from 12voltvids, where he said the frame TBC overwrites the area that holds the sync signal, therefore removing the Macrovision signal. And as far as I knew, only full frame TBCs will fix the image from creases and dropouts... this machine did just that. As a playback device, it was great... I had absolutely no problems. As a dubbing machine though, it had issues with my friend's tapes as I described above. I did however just see the manual... it only had RCA connectors, no svideo, so maybe it wouldn't have been a good choice for a playback device while capturing.

I originally bought/borrowed 4 Sanyo(?) 4-head hifi vcrs, all the exact same model, from the same store a few days before the ppv weekend. I had them connected with a 4-way splitter, then each machine was programmed for the weekend, each on it's own schedule, with 15 minute overlaps so I'd have a good splice. Then after the weekend I brought them back... cashier gave me a hassle, but I said I was using them to dub, and wasn't happy with the results. He suggested the Go-Video unit, saying it even removed Macrovision. I was sold. It was huge and heavy, built like a tank. The only reason I don't have it still is I had to sell it after my injury while awaiting my disability to kick in. Being stuck on Welfare in Vancouver sucks.

As for flutter, I guess the proper term would be microstutter. Not really a jump in picture like jitter, but where the object doesn't move as smoothly, and looks to flutter a bit. As for the GPU though... I noticed after that 1 of the 2 fans wasn't connected. I don't think it overheats while watching a video capture or playback in VIrtualDub, but it may be the clock kept jumping around on a cycle. Heat up, slow down. Cool down a bit, speed back up. I think.

[latreche34]

I maybe late here but I don't see what's wrong with the sample in the first post, I don't see any stuttering.