GV-USB2: lots of frame drops with AmaRecTV (VirtualDub okay)

[lollo]

Easy to fix.

So please fix his Vdub capture

He was joking.

The fix is straightforward, but the (accurate) detection is a nigthmare. I do it manually checking the source running at 10fps or lower in term of speed, in addition to automatic procedures (that gives false positives and false negatives).
In general, you end up with single (or multiple!!!) even or odd or both fields being shifted up or down by 1, 2, ... 7 pixels. As I said, a nigthmare

[Sharc]

Easy to fix.

So please fix his Vdub capture

He was joking.

The fix is straightforward, but the (accurate) detection is a nigthmare. I do it manually checking the source running at 1/10th of the speed, in addition to automatic procedures (that gives false positives and false negatives).
In general, you end up with single (or multiple!!!) even or odd or both fields being shifted up or down by 1, 2, ... 7 pixels. As I said, a nigthmare

100% agree. That's what I meant with "laborious".

[CaptureCraft]

What VD capture logs? It does not exist!

I'm not sure how to respond. Wow? LOL? Back to school?

I don't see much of reasons to respond to your useless posts.

[CaptureCraft]

To get rid of the all vertical jitter (lost lines) you need a really good DVD recorder like Panasonic ES10/15. Other models would be helpful too, but not as efficient as Panasonic.

[CaptureCraft]

I worked enough with IO-DATA GV-USB2 until I sold it. There were always tens of missing frames even with good DVD. Once I switched to professional cards there were no more missing frames.

Which ones?

BM, Magewell, AJA KONA LHi.

So, if you set your VD2 to NOT to add and NOT to drop any frame, then the only reason to have audio and video out of sync is the card, which misses frames.

Probably not necessarily. VirtualDub muxes video and audio signals not necessarily based on timestamps from the card.
Someday I'll finally get together and capture the mkv with the original taimestams and see what comes out of the card/grabber.

If you tell to VD2 not to intervene (do not insert, do not drop, do not re-sync), then timestamps from capture card are useless and the only reason for video and audio be out of sync is to have frames missed by capture card, assuming you don't overload your OS during the capture.
Again, once I switched to good cards, I forgot what is missing frame.

The software won't matter anymore.

I mean, I mean. Software does not capture the signal unchanged. In VirtualDub you can set a lot of things, in AmarecTV practically nothing and in fact it is not known how it works and why it always drops frames.

My goal is to capture unchanged signal. And that's why I use VD2 because you can set there a lot of things.

[rgr]

Easy to fix.

So please fix his Vdub capture

What's the problem?

[rgr]

If you tell to VD2 not to intervene (do not insert, do not drop, do not re-sync), then timestamps from capture card are useless and the only reason for video and audio be out of sync is to have frames missed by capture card, assuming you don't overload your OS during the capture.

But by giving up timestamps you have no guarantee that the video and audio signal from Hauppauge/IO Data is in sync.
And I am even convinced that this is not the case. That's why the audio resampling option in VirtualDub is so crucial to achieving audio video sync.

Again, once I switched to good cards, I forgot what is missing frame.

That's why these are (semi?)professional cards, not USB dongles

[lollo]

What VD capture logs? It does not exist!

I'm not sure how to respond. Wow? LOL? Back to school?

I did not think you were so stupid to refer to the real time logging window, and its oscillating frame frequency parameter as reference. This info is completely useless. The same happens in AmarecTV.

To get rid of the all vertical jitter (lost lines) you need a really good DVD recorder like Panasonic ES10/15. Other models would be helpful too, but not as efficient as Panasonic.

Bullshit! Some references here: https://www.digitalfaq.com/forum/video-restore/7577-reducing-vertical-jitter.html

I don't see much of reasons to respond to your useless posts.

Same here, you should first learn about analog capturing, you know very little about it.

[Sharc]

What VD capture logs? It does not exist!

I'm not sure how to respond. Wow? LOL? Back to school?

I don't see much of reasons to respond to your useless posts.

@lollo:
Capture -> Enable timing log is what @CaptureCraft probably refers to.

[lollo]

Yes Sharc, I already answerd him

[lollo]

Easy to fix.

So please fix his Vdub capture

What's the problem?

That's a completely restored outcomes. Everybody is able to use Denoise filtering, QTGMC cleaning, Stab, Mercalli, or whatever. An example here: https://www.youtube.com/watch?v=A58IGaI5uWA

The point was to find the amount of the vertical shift of the fields and fix just that in an automatic way (the output being the original files with the shifted-fields fixed). We discussed about that few times in doom9 forums.

[CaptureCraft]

If you tell to VD2 not to intervene (do not insert, do not drop, do not re-sync), then timestamps from capture card are useless and the only reason for video and audio be out of sync is to have frames missed by capture card, assuming you don't overload your OS during the capture.

But by giving up timestamps you have no guarantee that the video and audio signal from Hauppauge/IO Data is in sync.
And I am even convinced that this is not the case. That's why the audio resampling option in VirtualDub is so crucial to achieving audio video sync.

If you capture all the frames, then there is no reason for video/audio be out of sync whether you have the timestamps or not.
And I do not do any resampling.
See, all the extra features are for one single purpose - to save your capture from out of sync syndrome, assuming there always will be lost frames.
If you manage to get all the frames, then you don't need to use any of them!

Again, once I switched to good cards, I forgot what is missing frame.

That's why these are (semi?)professional cards, not USB dongles

Yes, having such cards is good, but not good enough. You need DVD recorder/TBC in your chain. Or even 2 DVD recorders, as I have, each serving different purposes.

[The_Doman]

I'm working on digitizing some old family VHS-C tapes

As noted the source is VHS-C.
This also can be a the source of possible playback difficulties/issues because reels are smaller/tighter and the adapters add extra strain/stress on the tapes.
In general you should be very careful with VHS-C adapters specially in the newer quick rewind VCR's.
It is a fragile construction.

And as long as the VCR ist adjusting its tracking the comparison is questionable.

This yes.
What tracking adjustment (automatic?) was used and when?
The playback looks so much different.
Ideally you should not activate (auto) tracking directly at start op the tape/recording, which is often little worn out/damaged but somewhere later on the tape.
Many VCR's auto track only one time when you insert/play the tape.
Beside the manual override having a dedicated auto track button/function is advantageous/essential for good playback/capturing.

[CaptureCraft]

What VD capture logs? It does not exist!

I'm not sure how to respond. Wow? LOL? Back to school?

I don't see much of reasons to respond to your useless posts.

@lollo:
Capture -> Enable timing log is what @CaptureCraft probably refers to.

I doubt he sees that because it doesn't exist.

[Sharc]

Easy to fix.

So please fix his Vdub capture

What's the problem?

By fixing I meant placing the scanlines back to where they belong, rather than "ironing it visually out" (by some filtering, actually damaging the original capture).
Yet your proposal is visually more pleasant and may be a workaround for the OP when all his other capture attempts fail.

[VWestlife]

Finding an S-VHS VCR or a dedicated TBC is nearly impossible where I live,

What about an S-VHS-C camcorder? Most of those have a built-in TBC.

[rgr]

Finding an S-VHS VCR or a dedicated TBC is nearly impossible where I live,

What about an S-VHS-C camcorder? Most of those have a built-in TBC.

[ deleted ]
I misread that it was a miniDV/Digital8 camera.

[rgr]

Easy to fix.

So please fix his Vdub capture

What's the problem?

That's a completely restored outcomes. Everybody is able to use Denoise filtering, QTGMC cleaning, Stab, Mercalli, or whatever.

The denoising was there by the way, I guess you don't think any stabilization or denoising program will fix such glitches.
Or do you think so?

[rgr]

If you tell to VD2 not to intervene (do not insert, do not drop, do not re-sync), then timestamps from capture card are useless and the only reason for video and audio be out of sync is to have frames missed by capture card, assuming you don't overload your OS during the capture.

But by giving up timestamps you have no guarantee that the video and audio signal from Hauppauge/IO Data is in sync.
And I am even convinced that this is not the case. That's why the audio resampling option in VirtualDub is so crucial to achieving audio video sync.

If you capture all the frames, then there is no reason for video/audio be out of sync whether you have the timestamps or not.

You assume that the driver transmits a video frame and an audio packet to the system at the same time and with the same timestamps (and of the same length).
This is rather a false assumption.

[CaptureCraft]

If you tell to VD2 not to intervene (do not insert, do not drop, do not re-sync), then timestamps from capture card are useless and the only reason for video and audio be out of sync is to have frames missed by capture card, assuming you don't overload your OS during the capture.

But by giving up timestamps you have no guarantee that the video and audio signal from Hauppauge/IO Data is in sync.
And I am even convinced that this is not the case. That's why the audio resampling option in VirtualDub is so crucial to achieving audio video sync.

If you capture all the frames, then there is no reason for video/audio be out of sync whether you have the timestamps or not.

You assume that the driver transmits a video frame and an audio packet to the system at the same time and with the same timestamps (and of the same length).
This is rather a false assumption.

First of all no. The collecting video and audio packets are 2 independent asynchronous processes. For example from the same old log previously mentioned. Video frame comes every 40ms (PAL) in average. Audio packet comes every 50ms. They can't be synchronous.
AJA CONA gives 40ms sharp(!) for video and 33.33ms for audio packet (30 packet per second).
Second, how did you even come to such conclusion that capturing all the frames requires synchronous capture video and audio and with the same timestamp?
All you need is not to miss or drop any frame. That's all.

[Sharc]

All you need is not to miss or drop any frame. That's all.

If one connects an oscilloscope to the output of a (mediocre) VCR playing a (mediocre) tape and observes the analog signal with its smeared and distorted and jittery sync, framing and equalizing pulses one can imagine the herculian task of the capture device to restore and reproduce a decent interlaced picture out of such messy input signal. And finally one cannot expect from a 50$ capture card+freeware to perform the same as a full fledged pro setup - but if used correctly the results are usually quite decent and good for post processing.

[rgr]

First of all no. The collecting video and audio packets are 2 independent asynchronous processes. For example from the same old log previously mentioned. Video frame comes every 40ms (PAL) in average. Audio packet comes every 50ms. They can't be synchronous.
AJA CONA gives 40ms sharp(!) for video and 33.33ms for audio packet (30 packet per second).

Second, how did you even come to such conclusion that capturing all the frames requires synchronous capture video and audio and with the same timestamp?
All you need is not to miss or drop any frame. That's all.

A video frame NEVER lasts 40ms - sometimes it will be 40.01ms, sometimes 39.99ms (average for the entire tape). The rigid 40ms means it sometimes has to drop the frame (or insert). In a few hours this will be a concrete value.

(Or save all frames regardless of whether they last 39ms or 41ms - which is how VirtualDub does it by saving them with a duration of 40ms (because it writes to avi) and resampling the audio to be in sync.)

[Sharc]

A video frame NEVER lasts 40ms - sometimes it will be 40.01ms, sometimes 39.99ms (average for the entire tape).

... and there are (static) offsets from the nominal value (e.g. caused by master osc. tolerances, temperature drift and ageing of videocam and/or VHS player and timing/clocking/control circuits of subsequent gear) plus short-time fluctuations (fludder) due to servo mechanism issues and/or mechanical stress and wear (tape mechanics like VHS-C in adaptor, mechanics of the VCR ....). Many imperfections exist in real world. Different strategies how to handle these exist - more or less successful within limits.

Edit:
And b.t.w. how Vdub's capture timing options are supposed to work is nicely documented in its help menu (Video capture -> Timing dialog).

[CaptureCraft]

First of all no. The collecting video and audio packets are 2 independent asynchronous processes. For example from the same old log previously mentioned. Video frame comes every 40ms (PAL) in average. Audio packet comes every 50ms. They can't be synchronous.
AJA CONA gives 40ms sharp(!) for video and 33.33ms for audio packet (30 packet per second).

Second, how did you even come to such conclusion that capturing all the frames requires synchronous capture video and audio and with the same timestamp?
All you need is not to miss or drop any frame. That's all.

A video frame NEVER lasts 40ms - sometimes it will be 40.01ms, sometimes 39.99ms (average for the entire tape). The rigid 40ms means it sometimes has to drop the frame (or insert). In a few hours this will be a concrete value.

How did you come to such conclusion?!?
First of all the timing I provided was for card's notification about new frame is ready to pick up, not the length of the frame.
Second, yes some frame are shorter and some are longer. However, in average is always 40ms, unless, of course, your VCR is screwed up royally.

(Or save all frames regardless of whether they last 39ms or 41ms - which is how VirtualDub does it by saving them with a duration of 40ms (because it writes to avi) and resampling the audio to be in sync.)

Yes, save all the frames and no, don't resample. Why do you need to resample? Your video and audio are hard-coded on the tape. You grab all the frames and all the audio and everything will be in sync.

[CaptureCraft]

A video frame NEVER lasts 40ms - sometimes it will be 40.01ms, sometimes 39.99ms (average for the entire tape).

... and there are (static) offsets from the nominal value (e.g. caused by master osc. tolerances, temperature drift and ageing of videocam and/or VHS player and timing/clocking/control circuits of subsequent gear) plus short-time fluctuations (fludder) due to servo mechanism issues and/or mechanical stress and wear (tape mechanics like VHS-C in adaptor, mechanics of the VCR ....). Many imperfections exist in real world. Different strategies how to handle these exist - more or less successful within limits.

Edit:
And b.t.w. how Vdub's capture timing options are supposed to work is nicely documented in its help menu (Video capture -> Timing dialog).

Why one should care about the actual length of the frame?!? It is either there or not. That's all.
If you can't get all the frames, then yes, you have to take certain measures to keep your video and audio in sync. You can insert frames (the best) or resync the audio (the worst).

Here are my settings.

[Attachment 92571 - Click to enlarge]

[lollo]

Easy to fix.

So please fix his Vdub capture

What's the problem?

That's a completely restored outcomes. Everybody is able to use Denoise filtering, QTGMC cleaning, Stab, Mercalli, or whatever.

The denoising was there by the way, I guess you don't think any stabilization or denoising program will fix such glitches.
Or do you think so?

A stabilization may fix a field shift, obviously. But is not reliable to fix all of them, nor in any condition (as in your attempt, frame 85 for instance).
Or do you think differently?

[Sharc]

Why one should care about the actual length of the frame?!? ...

I don't care (or at playback time only), but the capture SW perhaps in the sense of Vdub's first 2 tickmarks in its 'Timing options' for example - unless you consider these obsolete.
Anyway, I get along with Vdub and Amarec but won't sign that "Amarec always drops frames" (or Vdub "always performs better than Amarec"), especially in view of keeping A/V in sync

[CaptureCraft]

Why one should care about the actual length of the frame?!? ...

I don't care (or at playback time only), but the capture SW perhaps in the sense of Vdub's first 2 tickmarks in its 'Timing options' for example - unless you consider these obsolete.
Anyway, I get along with Vdub and Amarec but won't sign that "Amarec always drops frames" (or Vdub "always performs better than Amarec"), especially in view of keeping A/V in sync

I'm on a side that both software capture the same number of frames because that what comes from the capture card.
However, the way they handle frames they consider missing or duplicate is a different story. And having full control over this process is one of the main reasons why I use VD2.

[Alwyn]

Still, is it normal for AmaRecTV to perform that bad in my case? I wasn't aware that VirtualDub doesn't report frame drops correctly, but even so the transfers using VDub look much more smooth to my eyes. Those very obvious "frame skips" that I can see on the AmaRecTV test file are not present in the VDub file.

As I mentioned before, I think your woes are caused by the lack of any stabilisation. Amarec performs nicely for me; the occasional insert with in-sync audio.

Is the VDub capture actually better than AmaRecTV's? To my eyes, it definitely is.

I wouldn't say so. Here is an example:


[Attachment 92581 - Click to enlarge]

I can get a Sony RDR-GX350 DVD, which is present in this list (thanks @Alwyn). Would that be a 'good enough' solution if I'm not looking to achieve 0/0 frame drops/inserts on every single tape I want to digitize? Would I gain a lot of I somehow find a SVHS VCR (with no TBC) to connect to a DVD of this kind (not ES10/15) using S-Video?

You need some stabilisation of some sort. An S-VHS VCR, without a TBC, will not fix these framing problems. I did my tests with a JVC HR-S5700 and it was a mess with both programs. When I put the Pioneer after it, all problems went away. I'm in the same boat as you; it's virtually impossible to find a VCR with a inbuilt TBC, so the DVD recorder is the only option. And it has been said numerous times that in some cases, the VCR TBC can't deal with bad tapes as well as a DVD recorder (or of course a proper TBC) in the workflow. VWestlife does raise an interesting option, that of a S-VHS TBC-equipped S-VHS C camcorder. They're quite plentiful on EBay but... you pay your money and you take your chances.

Personally, I'd get the Sony, which will be good for other analogue tape captures.

Considering The Doman’s comment, by way of elimination, I’d transfer one of the VHC-C tapes into a full-sized cassette. If you’ve got a good capture from one of your tapes and are prepared to wreck it (not that you will), try putting it into a full-sized cassette. The process is pretty straightforward; the reels just drop in. The YT below explains how to open a full-sized cassette. Note the tape path through the rollers on the corners; take a pic with your phone. I've done it a few times and it works. The VCR just thinks it's got a normal tape in it. That might cure the inserted frames issue.

https://youtu.be/kurE-FuqkbU

[rgr]

A video frame NEVER lasts 40ms - sometimes it will be 40.01ms, sometimes 39.99ms (average for the entire tape). The rigid 40ms means it sometimes has to drop the frame (or insert). In a few hours this will be a concrete value.

How did you come to such conclusion?!?
First of all the timing I provided was for card's notification about new frame is ready to pick up, not the length of the frame.
Second, yes some frame are shorter and some are longer. However, in average is always 40ms, unless, of course, your VCR is screwed up royally.

Attached are the timecodes of the captured video.
As you can see, at first there is always a perfect 40ms, but over time it gradually falls apart.