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

[rgr]

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.

Because you need to match the audio to the video that was captured as 50fps, even though it went to the capture device with a minimally different framerate.
Of course, a card or other capture device can also do this - then VirtualDub doesn't have to do it. It can also capture with a stiff 50fps - but then you'll get drops or inserts.

[CaptureCraft]

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.

Well, that's yours. My logs stay sharp till the last line.

VFrames,VReps,VCapTime,VGlobalTime
128997,0,5159840.000,5159890.000
128998,0,5159880.000,5159930.000
128999,0,5159920.000,5159970.000
129000,0,5159960.000,5160010.000

The timing might be important if the capture software is trying to analyze it for the purpose inserting or deleting frames or resample the audio.
If not, then it doesn't mater.
I stopped looking the the logs when my gear stopped missing the frames.

[CaptureCraft]

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.

Because you need to match the audio to the video that was captured as 50fps, even though it went to the capture device with a minimally different framerate.
Of course, a card or other capture device can also do this - then VirtualDub doesn't have to do it. It can also capture with a stiff 50fps - but then you'll get drops or inserts.

I still don't get your logic. Why should I have drops or inserts?

[rgr]

Well, that's yours. My logs stay sharp till the last line.

VFrames,VReps,VCapTime,VGlobalTime
128997,0,5159840.000,5159890.000
128998,0,5159880.000,5159930.000
128999,0,5159920.000,5159970.000
129000,0,5159960.000,5160010.000

The timing might be important if the capture software is trying to analyze it for the purpose inserting or deleting frames or resample the audio.
If not, then it doesn't mater.
I stopped looking the the logs when my gear stopped missing the frames.

I suspect these are timestamps generated by the card driver and not based on the source signal.
The very accuracy of 3 decimal places is proof of this.

[rgr]

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.

Because you need to match the audio to the video that was captured as 50fps, even though it went to the capture device with a minimally different framerate.
Of course, a card or other capture device can also do this - then VirtualDub doesn't have to do it. It can also capture with a stiff 50fps - but then you'll get drops or inserts.

I still don't get your logic. Why should I have drops or inserts?

AJA KONA LHi returns the video as a perfect 50fps, regardless of any deviations (for PAL).
That's why your log looks the way it does - because these are not analog signal timestamps, but generated by the driver. The originals are different.

So why does sound remain synchronized?
Because the controller resamples audio on-the-fly.
"KONA 4/3G's high-quality input sample-rate conversion on AES inputs eliminates the
need for audio source synchronization. Sample rate converters auto-lock to any AES
input, 32-96kHz, and then convert it to 24-bit 48kHZ audio, locked to internal KONA 4/3G
video. Sample rate conversion is done at very high quality (over 120db THD). "

Technically, this is the same thing VirtualDub does with audio resampling enabled. You may have it disabled because the audio resampling is already done by the driver.
You get a video with the fps changed to 50 (from 49.99 or 50.01fps) and appropriately resampled audio with modified timestamps.
And when capturing, VirtualDub uses these video and audio timestamps because you have it enabled.

[CaptureCraft]

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.

Because you need to match the audio to the video that was captured as 50fps, even though it went to the capture device with a minimally different framerate.
Of course, a card or other capture device can also do this - then VirtualDub doesn't have to do it. It can also capture with a stiff 50fps - but then you'll get drops or inserts.

I still don't get your logic. Why should I have drops or inserts?

AJA KONA LHi returns the video as a perfect 50fps, regardless of any deviations (for PAL).
That's why your log looks the way it does - because these are not analog signal timestamps, but generated by the driver. The originals are different.

So why does sound remain synchronized?
Because the controller resamples audio on-the-fly.
"KONA 4/3G's high-quality input sample-rate conversion on AES inputs eliminates the
need for audio source synchronization. Sample rate converters auto-lock to any AES
input, 32-96kHz, and then convert it to 24-bit 48kHZ audio, locked to internal KONA 4/3G
video. Sample rate conversion is done at very high quality (over 120db THD). "

Technically, this is the same thing VirtualDub does with audio resampling enabled. You may have it disabled because the audio resampling is already done by the driver.
You get converted video to 50fps (from 49.99 or 50.01fps) and resampled audio with modified timestamps.
And when capturing, VirtualDub uses these video and audio timestamps because you have it enabled.

Yes, AJA KONA has AES input for DIGITAL audio. And by some reason you ASSUME I use that.
However, in reality I use analog input.
Oh, forgot to mention, AJA KONA is not the only card I used. Still video and audio were in sync.

[rgr]

This works for any input.

"KONA LHi also features AES input sample rate conversion; this feature eliminates the
requirement for audio source synchronization. Sample rate converters auto-lock to any
AES or HDMI input, 32-96KHz, and then convert it to 24 bit 48KHz audio, perfectly locked
to internal KONA LHi video. Sample rate conversion is done at very high quality (over
120db THD). (HDMI audio can be 20 to 24 bit and will be saved as 24 bit samples.)"

If it doesn't do this for analog inputs, i.e. you have lost or added frames depending on the deviation from the standard 50fps.

Other cards work the same way to keep in sync. Because they have to.
That's why they don't cost 50 euros like Hauppauge or IO Data. And whether it's worth that much is a matter of debate.

[CaptureCraft]

This works for any input.

"KONA LHi also features AES input sample rate conversion; this feature eliminates the
requirement for audio source synchronization. Sample rate converters auto-lock to any
AES or HDMI input, 32-96KHz, and then convert it to 24 bit 48KHz audio, perfectly locked
to internal KONA LHi video. Sample rate conversion is done at very high quality (over
120db THD). (HDMI audio can be 20 to 24 bit and will be saved as 24 bit samples.)"

If it doesn't do this for analog inputs, i.e. you have lost or added frames depending on the deviation from the standard 50fps.

Other cards work the same way to keep in sync. Because they have to.
That's why they don't cost 50 euros like Hauppauge or IO Data. And whether it's worth that much is a matter of debate.

This rate conversion has nothing to do with capture. It is absolutely not related to the matter. It is for broadcasting and mixing different digital audio sources to make sure they are running in sync, which normally requires external master clock.
As for capture I do at least 2 of them and verify against each other to make sure there are no lost or duplicate frames.
Yes, I had 2 duplicated frames inserted on 3 hours video. It is incomparable with about 100 lost frames by GV-USB2.

[Sharc]

As for capture I do at least 2 of them and verify against each other to make sure there are no lost or duplicate frames.
Yes, I had 2 duplicated frames inserted on 3 hours video. It is incomparable with about 100 lost frames by GV-USB2.

Btw. duplicate frames are relatively easy and reliably to detect using an Avisynth script. Dropped frames are more difficult to identify, especially if there is little motion.
Did you verify whether these duplicates were duplicates only, or duplicates as substitutes of dropped frames?
100 lost frames with GV-USB2 using Vdub or Amarec? Seems odd to me .....

[CaptureCraft]

As for capture I do at least 2 of them and verify against each other to make sure there are no lost or duplicate frames.
Yes, I had 2 duplicated frames inserted on 3 hours video. It is incomparable with about 100 lost frames by GV-USB2.

Btw. duplicate frames are relatively easy and reliably to detect using an Avisynth script. Dropped frames are more difficult to identify, especially if there is little motion.
100 lost frames with GV-USB2 using Vdub or Amarec? Seems odd to me .....

Vdub. Keep in mind the quality of the source matters.

[Sharc]

...Keep in mind the quality of the source matters.

Absolutely. And this is where it all starts with: Tape and tape player condition outputting a decent analog signal to the capture gear.
From there onwards we depend on the capabilities of the capture setup: Capture card+drivers/firmware+capture software, plus possibly extra supporting equipment as discussed. Performance differences exist for sure. Similar for valid (fair) comparisons, ease of use considerations and cost.
A detailed capture log is helpful to identify issues pointing to where to look in the captured file and possibly apply fixes in post - unless it is obvious.
Just to mention that nifty Avisynth scripts for automated finding of duplicates (easy) and drops (more difficult, less reliable) - and even apply fixes automatically (more or less successful) - have been proposed in the past over at doom9 - for those interested.