Bad VCR timing?
 

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

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:

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. :smack:

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

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?

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(?).

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.

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.

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.

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'. :P

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.

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.

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. :P

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.

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.

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.

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.

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

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

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.

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. :P

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.

You didn't see it in the camera pan on the crowd at the end of the clip? Maybe that has to do with GPU's display settings as well then.

-- merged --

OK... I recorded my screen with my camera for the first 10 minutes of a capture. It's recording a 29.970 capture at 30.091, but still shows what I'm seeing.

https://drive.google.com/file/d/1WtM...ew?usp=sharing

The opening has the damage I mentioned earlier, but I'm planning on splicing in the footage from the dvd trial. Or, I can just leave it in and say it's part of the nostalgia. It's only ~20 seconds worth. :P It has some vertical jitter, but that can be fixed with avisynth. But... the worst of the damage is that line scratched halfway up the frame. It pops in and out for the first 8 minutes, then fades to a blueish line for the rest of the tape. Not the whole tape though, as it fades in and out. I'm freaking heartbroken over that. It's not always in both fields at the same time though, so I may be able to fix some of it with a script by johnmeyer that fixes bad fields. But, it's still only 2 hours of footage out of 65 in total, so it's no 'too' bad I guess.

What's really strange though is the kink at the top of the frame... I'm guessing that's from the GoVideo deck that did the dubbing of my friend's sources. I never saw it on a CRT TV, only on an LCD while trying to edit it. Her tapes were SP, recorded on high end Sony decks, with Sony tapes. I used Fuji HQ160's for all my sources, and Fuji HQ120's for her tapes. I'm able to crop and shift that kink, but there's a colored line that appears when there's a colored background. Camcorder Color Denoise in VirtualDub removes almost all of it at full strength, but then it also reduces color everywhere else.

I'd like to save that top area as it's 13 pixels worth... top 5 pixels are black and can be cropped, so there's still 8 pixels worth of real estate. My sources are fine at top, but have 7 pixels worth of head switching noise at the bottom. To even everything up between the sources, I'd have to crop both the same, so that's 20 pixels worth in all. 720x480 just became 720x460. 680x460 total viewing area. Then looking at the dub of my friend's sources, the edges are spikey. If I want to clean that up, I'm looking closer to 670x460. It's still a decent size, I'd just like to squeeze as much as possible out of it.

I couldn't see any stutter, which means it could be a dropped frame somewhere that I didn't catch, The top of the frame is normal it is not meant to be seen, it falls in the overscan area of television back in the day. I see a lot of people complain about captured files thinking they should look like modern videos, They don't, especially consumer tape formats, It is what it is. Check your capture program if it is dropping frames, less than 10 frames in a 2hr tape is normal.

I've also downloaded the file in post #1 and played it and it played perfectly, not sure what's the concern here.

-- merged --

Just put the clip into vdub2 and skipped it frame by frame of the last 40 seconds that you said problematic, not a single frame drop, you have a playback issue to address.

There's no dropped or inserted frames reported in VirtualDub, and with 3 captures to use with Median, all 3 clips have the same amount of frames (after lining up in AviSynth), and display the same frame when choosing a frame near the end of the timeline.

That kink at the top is definitely not normal. It may be in the overscan, but every other tape I've ever captured, or seen uploaded to YouTube, that top area should be flat on the sides... no shifting. And when played through my JVC with the TBC turned on, its screws up even more, with the individual lines of the kink sticking out unevenly. And as I said, my sources, from the same ppv, don't have that kink. It's only the tapes that were dubbed.

As for the file I just uploaded... there's tons of jitter, starting from the drummer at 0:02:15... it's jerky as the camera moves upwards. then the crowd pans... look at 0:02:42. It jerks a few times in that scene. It's not just my eyes. :P

On my computer there is no jerking on the file in post #1, which means you have a playback issue as I said. FYI vdub is not a player, Use a dedicated player and see.

Sometimes frame-by-frame is misleading.

When I played the file, I saw would could have been dropped frames. But unknown when that happened. It could be the source (pre-tape), the ES15, the capture card. I played it forwards at realtime, halt-time, 2x time, and backwards realtime. I also went frame by frame.

After all of that, still inconclusive.

The main issue here is the computer playing these has issues. It could even be the version of VLC, as not all have been good, and sometimes the new version has problems. This is why most of us have multiple players for testing, and that depends on OS. I forget the Mac and Linux softwares, but for Windows it's MPC-HC (or MPC-BE).

I've already mentioned VDub is not a player. And as for the issues I was seeing, yes, some of it was fixed by swapping my GPU. That issue was microstutter on a timed interval, where it would like:
As I also said, I later discovered that one of the 2 GPU fans wasn't connected, so wasn't being powered on. I originally had done a Noctua mod, but decided to replace the original fans back on. The wire plug is still on the pins, but seem to be pushed to the top of the pins, so not really making contact. It's only an RTX 3060, stock settings, but my guess is it was hitting one of the Nvidia GPU Boost temperature limits where it starts to decrease slightly, then boost back up once it dropped below that threshold. I also said that while viewing in VirtualDub, if I saw a flutter/microstutter, I'd stop and rewind a few frames and watch it again... it was gone. But... it would then happen a few seconds later on a stretch that normally didn't flutter.

But the other issue was stuttering when the camera panned over the audience, or even sometimes on stage. Even after lordsmurf deinterlaced it, it still had a single hiccup at the end of the crowd pan. It's the exact same on both my capture pc, and sitting here on my VR gaming/Editing PC with an RTX 3080. But as I also said, as soon as I deinterlaced that, it was fine. But to say there's absolutely no jitter while watching the files I uploaded may be 'your' eyes. I'm fairly sensitive to tiny stutters.

Edit: Also, on the original dvd trials, it's 100% smooth, even on crowd pans.

That's the nature of interlaced video, it is not smooth, period, While it looks stutter to you, it is the way SD video has been for last few decades compared to modern progressive 60p. Having another version on DVD doesn't make the capture bad, it was probably recorded from a better master.
Upload another file that looks worse and I'll take a look at it, The one in post #1 does not have stutter.

I realize that's what interlaced video on a progressive screen is like, we already covered that, and I said I felt like an idiot for not realizing it a lot earlier... like years earlier. This is my 4th attempt, each time either not happy with the results, or as I stated above, my last attempt didn't have the levels corrected before capturing, and after reading about the histogram in VirtualDub, I ran a test capture with my previous settings... it was far in the red on the contrast side, and bit red on the brightness side. So this is my next, and hopefully last attempt. But... my previous attempt also has strange black dots appearing down a single line, about 20 pixels in from the left side. I thought it was satellite transmission artifacts, but they weren't there in the DVDs. I chalked it up to my Hauppauge HVR-1850 finally giving up the ghost. The ATSC chip died a few years before that. That's when I got the Hauppauge USB-Live2, but the thing wouldn't keep it's proc amp settings between captures or reboots, and needing to keep all 65 hours looking the same, I decided to get the Pinnacle USB-510 from lordsmurf. It's timing is rock solid, and allows me to use VirtualDub. And it keeps it's proc amp settings. Hauppauge doesn't play nice with VDub, so I was using AmarecTV. But both cards, and both apps still give the same issues.

The masters for the DVD are these exact same tapes. I originally wrapped each tape box in saran wrap, then boxed them up until I was ready to transfer. Then after each attempt, they got rewrapped. That's why I'm p*d at this attempt... they were pretty much pristine until I started again. But as for the DVDs... I'm just pointing out that whether the VOBs are played on the pc, or the disc is played through the ES16, the videos are completely smooth. (ES16, not ES15... it's the Canadian version of the ES15). But seeing as the DVDs are still interlaced, it boggles me as to why the vhs captures are choppy until deinterlaced.

I posted the full 2min clip that the first clip came from in post #3.

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

I also uploaded that 10min screen capture of the vdub capture window, where there's quite a bit of stutter, especially where the camera pans over the crowd. It's not always the entire pan, or every crowd pan. Sometimes it's near the end of the pan, or starts 1/2 way through. And as I said in my first post, I see the same thing in Netflix as the camera pans sometimes. And I know that's not just my eyes, as that's what the 'smooth' settings in the tv configs are for, but people complain about the soap opera effect. But it's the same type of jitter I'm seeing. And it's not display hardware, as a rewind still has the same jitter during those shots, and on both PCs.

Edit: And the screen cap file shows the stutter when played back on my phone that it was recorded with, so it's definitely not just my PCs.

Never seal tapes in plastic wrap, it taps moisture.

MPEG interlacing is different than lossless interlacing due to the compression. There's a slop in it, and it can go either way in terms of visual quality, either hiding issues, or highlighting issues. DVD-Video is not the measuring stick of quality.

MPEG-2 playback is much easier on most media players compared to lossless AVI, it is not about how powerful a CPU or the graphic card, it is how stable the player is, I've had VLC stutters on a powerful modern PC and MPC-HC played smooth on Win 7 2008 machine, I've seen threads like this before where the OP thinks the capture card is at fault, but the file playback is the issue.

But the tapes are sealed to begin with, and even when people store batches of tapes in plastic bins, it's the same concept. Heck, they even sold individual closable plastic containers for VHS tapes... which is what any video store stored them in. It's also what tv stations store their tapes in. Yes, if it's humid out, then maybe you might get moisture. But not in the middle of July. And being a chef, I wrapped them fairly well, both individual boxes, then in stacks of 5. So unless the wrap was done poorly, then no moisture should ever enter the tapes. And, always stored them in a warm place... not hot, but definitely not cool. That's where mold starts to grow. Also, mold needs oxygen to live, so being sealed prevents that.

That makes sense about the MPEG vs uncompressed avi, as I said in pm that converting did seem to fix it as well, even when still interlaced. I seriously wish I'd come here 10 years ago... lol.

People do dumb stuff all the time, sometimes even a majority of the time. (Give me time to ponder, and I'm sure I can think of something dumb I was doing, before I learned better. EDIT: Yep, here's one: Reusing random old rags to clean the car, then wonder why it has scratches. Youtube has good car cleaning advice, unlike videotape related advice. Bought a pack of microfiber disposable clothes, no more issues!)

Sealed new tapes had an intended shelf life, not to be hoarded/warehoused and sold 20+ years later as "new" (because they're not at all new anymore, merely unused for recording).

Plastic bins offgas, that's very damaging, and a common source for tape condition issues.

Time of year has nothing to do with it. Humidity is 24/7/365. In fact, in many places (mine especially), summer is vastly more humid than winter.

You didn't wrap it down to a molecular level. In fact, the plastic wrap itself is porous. Saran Wrap, all kitchen plastic wrap, is especially porous, to let steam escape (microwaves excite water molecules).

Very, very bad. :smack:

Mold grows in all environments.

You're here now, that's what matters. :congrats:

And I think you need some good storage advice, not just playback or interlace advice. ;)
Topic for a new thread.

And yet that's how the tv industry has done it since the days of betamax using individual plastic boxes.

I definitely disagree with that one. Here on the coast, it's more humid in the fall/winter. Books left in a garage are dry in the summer, moist in the fall/winter. And I'm beside the ocean, so we're naturally more humid than the interior.

And yet chefs have been doing this for close to 100 years already. Have you ever had meat in the freezer, and gotten freezer burn? It's because it wasn't wrapped properly. This is literally what they teach you in chef school, or by the sous chef in a restaurant. You wrap an item top to bottom... 5 or 6 times, then you rotate 90 degrees and do the same. It's also how they make gravlox... if it's not wrapped properly, it won't cure properly due to the outside air and moisture seeping in. Chef would tear your hide if his gravlox was soggy.

Thanks, but we're definitely going to have to agree to disagree on this one bud. But cheers... I'm going to bed. :P

-- merged --

Damn... forgot another example... Hollywood. Every single film archive is kept in those film cannisters, even to this day. If mold was an issue by storing tape in a sealed container, then they would never have done it.

I'm not aware of anybody in the TV industry that stores videotapes in plastic kitchen wrap, nor plastic storage bins. That's not a thing.

And at other times, it's less humid. But the humidity exists. More is more damaging, less is less damaging, both damage.

Plastic wrap is porous, and allows in moisture, which then freezes. Freezer burn is caused due to moisture wicking out of the meat. You'll get initial freeze-time water molecules that freeze up, plus any that form from power dips that lower freezer temperature temporarily. Plastic wrap actually induces freezer burn, because it allows in air, while freezer paper does not. I don't need to be a chef to know science, nor to see how this plays out in my own freezer.

I store meat in freezer paper, which is what professional meatpackers do. They don't store in Saran Wrap -- which was made by Dow Chemical, and the food storage version was made for temporary fridge storage. Not freezer, not long-term. Plastic wrap was later used to nuke/microwave food, because it was convenient to reheat leftovers, which was often already on the plate/container.

Due to dangerous chemicals, Saran Wrap was reformulated 20 years ago, also made thinner, and has been crap ever since. We (family) quit using it for food long ago (we now move all leftovers to plastic storage tubs), and the modern version of plastic wrap is pretty miserable for most things. We use a paper plate, upside down, to nuke our leftovers.

This may be true, but I would wager it's "old school" knowledge that never got the memo from 20 years ago. Things changed, they didn't. You see that in many industries.

I never heard of gravlox. Wow, that looks yummy! :D

Film is not tape. Vastly different.

lol... I didn't say that. I said wrapping is the same as using those plastic boxes made for VHS tapes, and the industry puts all tapes in those plastic VHS boxes. The lid folds, and it seals fairly well.

Yes, but the fact of the matter is that whether the air already in the plastic VHS shell is wrapped in plastic or in a carboard sleeve, it's only going to get affected by the outside humidity if that air gets into the plastic shell. It's not a living breathing item. If you seal it properly, the outside humidity will never affect it. Period. And as I said... humidity needs oxygen to even begin. A sealed box won't allow any more to ever enter it. And as long as the tapes are kept within the acceptable temperature, you should be fine.

Freezer burn is caused by cold, dry air getting in. Period.

And yet every single food supplier delivers plastic sealed meats without issues.

And yet restaurants have absolutely no problem with it.

What they teach in chef school is techniques that have been honed for centuries. If there was a better way, they would have done it.

It's cured salmon. It's huge with the Jewish community... 'lox and bagels'. It is really good indeed. :)

True, but it does get mold as well. I actually just read an article about film restoration from nyu. but... those reels were pulled from tins, so that blows my theory out of the water. But as I said, the air in the tape shell is no different in a cardboard sleeve than if it's wrapped. It's only the air that seeps in that causes issues.

-- merged --

I also remember having Fuji tapes that came with a plastic sleeve, not a cardboard sleeve. That would protect the tapes far more than cardboard. Cardboard can suck up the moisture in the air and transfer to the tape on it's own, while plastic sleeves would prevent that, as long as the sleeve has a tight enough seal with the tape inserted.

The key here is that it's not just any random plastic. Kitchen food wrap isn't the same materials or specs of videotape cases.

Storage needs to be indoor temperate, preferably on the cooler side (60s to low 70s F), with the RH% as low as possible under normal conditions (50% target range, less is great).

TV stations, museoms, etc -- this is what they do. I should know, I work with many.

The cardboard cases are generally fine, because those are slick "cardboard" (more like thick paper stock), not corrugated cardboard. The coated outer layer can act very much like plastic, because it often is a form of plastic that creates the coating.

You have to realize this is something I have about 30 years of knowledge on. I actually knew quite a bit about paper/cardboard at least a decade before I ever did anything with video.

But when plastic is wrapped in many layers around the object, then it's no different. If it prevents freezer burn when wrapped properly, then it would work with tapes as well. It's not rocket science.

This is why I said kept within a proper temperature, and not out in the garage. It's also why I said that whether the air in the plastic shell is then boxed in cardboard or plastic makes no difference to the air already inside. Only any air or moisture that leaks into it will make a difference.

Cool... but TV stations still keep them in those plastic cases. So after that, it comes down to storage temperature.

Yes, they have a coating on the outer surface of the cardboard, but not the edges of the opening where the cardboard was cut in the factory, or the inside of the cardboard sleeve. I spilled coffee once... outer surface only beaded up, but the edge got soaked, and so did the inside. The open edge will be a wick in a humid environment.

Cool. You have to realize I'm not new to VHS as I'm pushing 60, and besides the physics I already know from school, my 20 years in the kitchen gives the experience and knowledge about the use of plastic wrap. Cooking is science, both physics and chemistry. Saran wrap is not 'porous'. It doesn't leak on it's own. Fill a jar with water, lay Saran over top, and use an elastic to seal it. Then support it upside down. It's not going to leak.

I'm done. Cheers, and good night.

-- merged --

Well, I found the issue in the sequence with the drummer... one of the frames was glitched in the top field causing the jitter. It wasn't just my eyes. :P But using johnmeyer's script, I was able to fix that frame. But... it's slightly higher than the original, and cropping a single line off the bottom doesn't do it. If fixing bottom field, then the frames are the same height. So I may have to splice by sequence, or at least find a spot where the camera's not panning up or down. I'm planning on using this method to fix a few dropouts as well. They aren't always in both fields at the same time. It may not always work, but it's definitely better than a filter that blurs.

Interesting. I have a complicated video with similar jitter issues. Personal (family) video, 10 minutes long, not too important, but I do want to fix it eventually. I need to tuck this script away for my next attempt. Honestly, I may have already tried it, but forgotten.

It woks quite well, as long as there's not too much movement... like drum sticks with tracers due to moving so fast. But when trying to fix the upper field, as I say, it's not lining up identically to the original. I guess it's shifted slightly due to using the bottom field as the guide to interpolate the top field. I have at least 1 streak where it spans 3 frames... starts in the top field, ends in the bottom field, but the middle frame it's in both fields. So the plan was to repair 1st and 3rd frame, then interpolate the middle frame with the newly created neighbor frames. Hopefully. :P

I've been trying to play with the script lollo2 supplied in a previous thread of mine to shift fields in individual frames, but when he first shared it, all the code was kinda Greek to me. If I see it in an example, I can apply it to what I need. But looking at it last night/this morning, it's kinda makings sense, but it's giving me an error in my settings:

The frame I testing with is 58, bottom field shift by up by 1:


Line 3, column 28 is between 5 and 8 of 58.

So... what the heck am I doing wrong?

Here's more info from lollo2: