4 different IODATA GV-USB2's tested with samples. Line-TBC-Like-Activity?

[Gary34]

Guess I'm stupid or something but I'm reading your messages as you being mad at him because he's saying that this card doesn't a TBC built into it. You believe this is a claim he found out of thin air or a claim anybody on Videohelp came up with

It’s a misunderstanding. Alwyn actually corrected the statement. I don’t think he was trying to be a jerk there.

The YouTuber is the only one making the claim the card has an actual TBC in it. Aramkolt is testing for card resiliency and there is some talk about PLL. LS just doesn’t want things to be confusing for a new person or them to think I don’t need a TBC if I get this card because it has a TBC like effect when it doesn’t.

VideoCaptureGuide did a video on it, claimed it had a line TBC in it. Lordsmurf just recently made a response debunking it. A response that I agree with.

That was a card being more resilient than another card and the conclusion being made it had a TBC. It’s the conclusion people are trying to avoid with the GV USB. Still great channel.

[aramkolt]

I will admit that I generally equate "horizontal stability/alignment" with "line-tbc-like" activity. It is probably more accurate to say that horizontal stability is the end visual result of what an ideal line TBC does, but conceptually, there are other ways to get at least partially there - "left justifying" each horizontal line of the frame to the far left and then starting a new line once it sees the colorburst for the next line as an example.

That's not to say that "left justify" method would correct all straight lines within a frame, but for something like flagging at the top of an image, it should help quite a bit. Left justifying also kind of seems like something you could do in post capture, (as long as the lines don't go too far off the screen to where they are clipped in a 720 pixel frame.

Main purpose of the post and tests is to point out that some GV-USB2's seem to behave differently - and it's looking like in a good way - though perhaps there's some other tradeoff like sharpness/undesirable noise reduction that still makes it not worth seeking out. That's why I leave it to those smarter than me to point those things out from the samples given. I think comparing them to what are more generally accepted as solid line-TBC-like devices (ES10) or machines with internal line TBCs should be better - but doing the test will show "how much better" they probably are. It might save others from going down the rabbit hole of finding one of these if they see the usually recommended hardware is way better and by how much.

I think it's an interesting topic worth discussion/testing because people are getting different results with a capture device of the same part number which causes a lot of confusion. It does also sound like VideoCaptureGuide/DarrylInCanada has the original GV-USB2 (his was Windows10 boxed) per a post he made on the other thread, so his results may not be the same as what I or TheTechGenie saw. It's also impossible to really get identical results since there's always variability on the tape being used, player, and condition of equipment, but doing a bunch of tests in the same place and trying to only change one variable at a time is still useful I think.

Very odd that the company itself doesn't acknowledge there being a hardware difference in models when I think there's enough information here to say there are differences.

As for frame drop reporting, I likely don't have Amarec set up correctly if the Frame dropping statistics for others work fine with any GV-USB2 as they were all doing the same zero frame thing for me. Could be that may be there were no drops, but maybe there were a bunch of inserts? I've only looked at the statistic that shows up at the bottom of the frame and not the actual "log" file that I think Amarec can produce.

Wouldn't be a lively discussion or for there to be anything learned if we all agreed on everything. I like hearing *why* you all think one way or another - I'm open to changing my mind with the right evidence for sure and on a lot of this, I'm kind of in the opposite mindset of the Dunning Kruger Effect where I've seen enough about the topic that I realize I know relatively little (beyond well established basics) and don't ever want to come across claiming to be an expert.

[Gary34]

The marketing department at GV USB2 would really like the term “line TBC like activity”.

[The 14th Doctor]

The YouTuber is the only one making the claim the card has an actual TBC in it. Aramkolt is testing for card resiliency and there is some talk about PLL. LS just doesn’t want things to be confusing for a new person or them to think I don’t need a TBC if I get this card because it has a TBC like effect when it doesn’t.

VideoCaptureGuide did a video on it, claimed it had a line TBC in it. Lordsmurf just recently made a response debunking it. A response that I agree with.

That was a card being more resilient than another card and the conclusion being made it had a TBC. It’s the conclusion people are trying to avoid with the GV USB. Still great channel.

I get that, seems like you understand his concern with it.

I dunno when I hear the claim that the card has a TBC, I view that as the card is as strong as an ES15 or internal line TBC. But that's not the case. Heck that Sony DV device Vwestlife made a video on has a line TBC like device in it.

These USB cards do not, at the very least they do not to the same degree as those other two devices I just mentioned. I wish it did but it does not.

Also yeah, no offense to VCG his channel is great, but that was the wrong conclusion to be made imo.

[lordsmurf]

That's not to say that "left justify" method would correct all straight lines within a frame, but for something like flagging at the top of an image, it should help quite a bit.

This is mostly wrong, because tearing/flagging is almost always caused by line-length errors. The tearing is actually caused by simpleton justification within the VCR.

Left justifying also kind of seems like something you could do in post capture, (as long as the lines don't go too far off the screen to where they are clipped in a 720 pixel frame.

This is why "software TBCs" failed 20 years ago. It's not that simple.

though perhaps there's some other tradeoff like sharpness/undesirable noise reduction that still makes it not worth seeking out.

Geometric distortion is the #1 issue. I like Sharc's recent sample showing background antennas that looked like boomerangs.

As for frame drop reporting, I likely don't have Amarec set up correctly

You see what you see, and no need to feel bullied out of your observation. Many of us see it. There are no facts to the contrary. In fact, there are fact to back you up.

I'm kind of in the opposite mindset of the Dunning Kruger Effect where I've seen enough about the topic that I realize I know relatively little (beyond well established basics) and don't ever want to come across claiming to be an expert.

You're wise. You realize that you don't know what you don't know, and it could bite you in the ass at any time. I've been this way my entire life.

I feel like this argument is all boiling down to confusion.

I'm reading this like Alwin misunderstood why Lordsmurf put his blue foot down on this 'debate'. Him, you, Sharc and myself are all saying that the IO-Data does not have line TBC capabilities, certainly not to the degree that an ES15 or internal VCR TBC has. Trust me if it had the same strengths as an ES15 but without the drawbacks of one I'd use it.

If anything it feels like Alwyn started the attack, believing we were making this claim.

I agree with you Lollo that from my own test, with the worse tape I have in my collection signal wise, that it does not correct time base errors, rather it is as resilient as a Pinnacle 510/710 is to them. At least when being fed from an S-VHS VCR with it's internal TBC turned off and on (as the tape has it's own problems with that internal TBC turned on)

Sounds like Alwyn thought that one of us was making this "IO-Data has a TBC built into guys!" claim. When it isn't any of us, rather it's thetechgenie on YouTube. He's the one who is causing this false notion, not to rag on the guy but still.

We are trying to put the fire out before it spreads even further.

No offense to Aramkolt or Darryal/VideoCaptureGuide but it seems like they are maybe falling under this notion, I appreciate their tests but I feel like we are all trying to put a stop for this misinformation before it gets out there.

Look the IO-Data is a fine enough card to me, it ain't the worse but I personally prefer sticking with Pinnacles for audio sync reasons.

But I feel like we are trying to deny that it has a line TBC, we are not trying to make "it has a line TBC built into it!" a reason to use that card.

Especially if it only happens in newer revisions, then that'd lead to a huge gamble.

^ Agreed, 100%, all of it.

Congrats you made it worse. This seriously ain't helping here.

'Aw yeah I love drama in my internet forums'

Guess I'm stupid or something but I'm reading your messages as you being mad at him because he's saying that this card doesn't a TBC built into it. You believe this is a claim he found out of thin air or a claim anybody on Videohelp came up with.

This isn't a claim he is making, not me, not Lollo, but TheTechGenie over at YouTube. What is this, Retrotink propaganda all over again or something?

He disagrees with that claim being made and so do I. We are trying to debunk this until it spreads too far. We are not hating on the guy as a person, but some of us are trying to correct him here.

Honestly post #7 sounds like you are in this "it has a TBC" camp.

{...}

This all started from a YouTube video, and now it is spreading, we are trying to make it stop and you sadly are not helping.

You make it sound like he is accusing any one of us on making this claim but he isn't. God, I know that he and Lollo argue about the IO-Data a lot but this "It has a line TBC baked into it, it can correct wiggling all on it's own!" isn't one of those reasons from my understanding.

It does not, I wish it did, I wish it was as strong as a Panasonic ES10 or ES15 but it just ain't. The IO-Data does not correct that stuff on it's own. But an ES15/ES10 does, sometimes even stronger than a JVC's internal TBC depending on the tape.

That is why we use them for those rare situations where you'd rather deal with the drawbacks because the end result is an actually stable picture

Correct.

I personally designed several PLLs based on the classic charge pump-vco-phase shift-filter.

Uh-huh, great. My point is that this implementation of PLL, if it is believed to be responsible for what we see, is some sort of "phase NR", for lack of a better term. Since you claim to know so much about PLL, why not be part of the constructive conversation, not the drama queen part of it?

The contact printed only refers to how the signal is written to the tape and does not impact (or only marginally) the time based errors.

With comments like that, it's quite clear that you just want to be contrarian. The fact is that contact print method changes how timing errors exist and present on playback. It's a bad sample choice for this sort of error. You just want to argue with me, hen backdoor agree -- and in the same sentence!

The red boxes show nothing.

Then you're blind. It's interlacing caused by timing wiggle.

On a fixed image the orange boxes shows nothing,

If you want to see it in motion, use those location boxes to self-locate in the attached videos. Then step in a timeline.

What's the point here? Excuses for the card? A recommened worklow requires a TBC correction,

Why are you even participating in this thread? Clearly you've not read the topic, and are just here to defend "my precious" GV-USB2. It's just a capture card, hopefully, not something you spoon in bed at night. We're trying to dispel a myth about it having a TBC, so you don't need to "defend it's honor".

While I enjoy my tools, be it AIW cards or TBCs, I don't want to fellate them. It gives all-new meaning to "USB stick".

- GV-USB2 in AmaRecTV does not properly report insert/dropped frames. That's because the internal mechanics of broadcast software is about continuity, not signal integrity. Dropping/inserting frames is an expected action of broadcast/streaming software. While AmaRecTV does some reporting, the exact reporting done, and why, is not clearly understood by anyone.

Complete bullshit. You are parroting false statements from others

Yeah, yeah, whatever. I see it, others see it.

But you attacked user Alwin without any reason,

WTF? His first comment was "You and your group-thinkers"
GTFOOH with that BS.

Yes, few are better, but the cards that you recommend/sell are not better that the GV-USB2

STFU.

I'm done, this ain't doing you any favors man.. meh, this sucks on ice.

Sad, isn't it? The site has devolved into a trolling board. No wonder people are just going to Reddit and Youtube now. This isn't the VH I knew in the '00s and '10s. We can't even have a damned constructive conversation here anymore, without the peanut gallery interjecting at everything, arguing for sport.

[Gary34]

The title of the thread makes it kind of hard to defend. It would be different if it was titled testing GV USB2 resiliency or something about PLLs instead of TBC like activity. That's close to what the YouTuber is claiming. It's just you're proposing it may act like a TBC instead of has a TBC.

[The 14th Doctor]

Who is doing that now? Aramkolt? I guess that's how he views it so far.

I don't think anybody here on this site is claiming it has a line TBC built into it. So why are we attacking each other like somebody is accusing one of us for making such a claim?

We aren't. Lollo and LS have had arguments about this card and will probably continue to do so until one of them retires, but the TBC claim is not one of those arguments.

I'm probably just repeating myself here.. meh.

If anything I appreciate Aram stating that #3 was the Windows 11 branded version, shows that it does not have a line TBC built into it.

I've done my own test myself with the worse tape I have signal wise.

Who knows anymore, maybe I bought the wrong one on Amazon a month and a half ago and would have to gamble buying a crap ton from Japan using Buyee or something. I'd rather not waste my money like that.

What is the truth so far, that the IO-Data can not correct time base errors by itself and is only as resilient to them as a Pinnacle 510 is.

It needs a proper line TBC first, that can be an internal one built into an S-VHS VCR/Hi8 Camcorder or as the least worse option, a Panasonic ES10/ES15 DVD Recorder.

I feel like this claim can be taken as "oh you don't need an ES15 anymore, this capture card is enough" which it ain't.

[Sharc]

Instead of getting lost in semantics an verbal sparring let's try to confirm or reject whether one (ore some) of aramkolt's four GV-USB2 sticks and drivers produces systematically, repeatedly, reproducible, understandable and plausible less line wiggle/jitter/geometric distortions than the others. If so we may go on sepculating as to why, like (silent) design change, new drivers, random pick, his source, setup etc.
I think that was the OP's original intention.

[The 14th Doctor]

Okay so I went through Aramkolt's videos again and can determine that 1 2 and 4 are identical

3 is the outlier. But to me it doesn't look fully straight, like okay it corrects wiggling to an extent, but not to the same degree as an ES15 or internal TBC does.


[Attachment 92101 - Click to enlarge]
[Attachment 92102 - Click to enlarge]
[Attachment 92103 - Click to enlarge]
[Attachment 92104 - Click to enlarge]

Man do tiny images not show up good.

Anyway to me it feels like that okay it does have a line TBC in it, or something that is kind of like it but it is not as strong as a proper TBC built into a deck or even a DVD recorder like the ES15.

So the card by itself can not act as a full on replacement for either of those kind of devices. So if you wanted to pair a consumer no TBC VCR with something, you'd be better off still using a Panasonic ES10 or ES15 despite it's drawbacks for that workflow.


So like it has a 'TBC' in it but when you read the fine print it's a very very weak one that is not as powerful as proper ones. Can not be used as a proper replacement for one

[lordsmurf]

So like it has a 'TBC' in it but when you read the fine print it's a very very weak one that is not as powerful as proper ones. Can not be used as a proper replacement for one

- TBC = whiskey
- GV-USB2/PLL/whatever = water

"Water is like very very weak whiskey."

In fact, so weak, that it's not that at all. 0% alcohol by volume. Calling water "weak whiskey" is a joke, as is calling a non-TBC a weak TBC.

[Sharc]

I was hoping from this thread to eventually come to a conclusion, evidence or proof even whether the GV-USB2 has at some stage undergone a design change - or a drivers change - which affects its line wiggle behaviour. No less and no more. Not to defend anything or anyone.

[The 14th Doctor]

Could a driver change even do that? I know there have been talks about the recent drivers. But that seems to be relating more so to color ranges. If I needed to use an IO-Data I'd just stick with driver version 1.11. I dunno I've heard that's the most stable?

Which makes sense as that aspect of the card can be adjusted further by the end user.

[lollo]

Uh-huh, great. My point is that this implementation of PLL, if it is believed to be responsible for what we see, is some sort of "phase NR", for lack of a better term. Since you claim to know so much about PLL, why not be part of the constructive conversation, not the drama queen part of it?

Because you're using technical terms to put smoke in the eyes of the readers without understanding a bit. Phase NR does not exists in the time base correction. It is intrinsic to the internal characteristics of a generated clock.
Sharc talked about PLL and you started to build a fantasy castel on top of it without any knowledge.

I do not wish to be rude, but I really dislike this aptitude of yours, also when you try to deceive people talking about MPEG-2 architecture, Transport Streams similarity and so on. If you want a constructive conversation, start from the basics.

The fact is that contact print method changes how timing errors exist and present on playback. It's a bad sample choice for this sort of error. You just want to argue with me

I do not need to argue with you, the fact that this commercial tape is (probably) made by contact print is irrelevant. We are judging if a time base error is corrected or not in a test, not its nature, which does not impact the results.

Then you're blind. It's interlacing caused by timing wiggle.

Interlacing? Interlacing is the effect of two fields from a different moment in time building a frame. It has nothing to do with a timing error. I ignore the analysis you did (and showing the frames instead of the fields is somehow misleading here), but your conclusions are suspicious there.

If you want to see it in motion, use those location boxes to self-locate in the attached videos. Then step in a timeline.

Seriosly? You are suggesting me how to analyze the videos?

We're trying to dispel a myth about it having a TBC, so you don't need to "defend it's honor".

You must be joking, I was probably the first to say the GV-USB2 has no time base correction capability.
The problem is that you go much much far away in post #19 when you wrote one right statement (no TBC capability) and your usual bullshit, reported above. So I had to correct you because you are not allowed to spread misinformation here. It is very clear to any reader who is extending the discussion beyond its initial purpose.

- GV-USB2 only really works well, or at all, with AmaRecTV, and Japanese software intended for streaming video games using analog cards. It's very much a pre-OBS in this way.
- GV-USB2 in AmaRecTV does not properly report insert/dropped frames. That's because the internal mechanics of broadcast software is about continuity, not signal integrity. Dropping/inserting frames is an expected action of broadcast/streaming software. While AmaRecTV does some reporting, the exact reporting done, and why, is not clearly understood by anyone. I believe it's only reporting "unexpected" loss, not expected.
- GV-USB2 does not contain any sort of TBC. If GV-USB2 has a TBC, then so does my toaster.
- GV-USB2 is a long-lived card, with known production changes in the past 15 years. Mostly secondary chips, but this time was apparently the main capture chip.
- GV-USB2 has quite decent color/exposure/values. Few are better, many are worse. So I understand the draw to the card. Unfortunately, for me, for most (most?) people, that's just not enough.

So, false and off-topic.

WTF? His first comment was "You and your group-thinkers"
GTFOOH with that BS.

GTFOOH yourself! the bullshit is yours.

You wrote

I almost can't believe we're having to have this discussion. It's almost like having to prove car tires aren't square.

Alwin wrote

You and your group-thinkers are the ones giving this oxygen. NOBODY here has said the GV-USB2 has a TBC.

So the truth is that he said you and your accolytes were encouraging the discussion, and he said that "NOBODY here has said the GV-USB2 has a TBC" since the beginning!!!

Yes, few are better, but the cards that you recommend/sell are not better that the GV-USB2

STFU.

STFU yourself! You have a conflict of interest big like a house, and continue to belittle competitors to the cards you sell spreading misinformation.
You can fool one person for a long time or many people for a short time, but you cannot fool many people for long.

User The 14th Doctor and aramkolt proposed interesiting ideas and contributions, but this thread became so toxic (and the reason is always the same, your false and out of topic statements) that I do not think is worth to spend any more time. Unfortunately.

[The 14th Doctor]

Encouraging what decision, shitting on an IO-Data? I dunno man but me personally I viewed the discussion LS was talking about is "Does the IO-Data have a TBC inside it?" He's probably thinking "Why are we having this talk about the IO-Data having a TBC, it's clearly false, you are all wasting your time with these tests"

Just wanting to ignore his usual talk about Amarec and dropped frame reporting n' stuff like that, you two would probably argue about that till the end of time...

I view this IO-Data talk as specifically relating to a TBC and the claim that it has one built in, which is false, at most it is extremely weak and can not be a full on replacement for one built into a DVD recorder or VCR/Camera, not the overall general "why it's a very great card!" That's for you two to argue about, that's honestly been your guy's 'thing' for a while.

I've made my stance on that matter, the card is fine but I prefer my Pinnacles, they do better with overall audio sync. The differences in color can be corrected. Hell for me personally I'd rather adjust the IO-Data proc amp so everything matches the Pinnacle's proc as close as possible because I like being consistent.

But the audio sync is what kills me from fully switching over, if it was exactly the same as a Pinnacle, then I'd switch, but it isn't. I can't just delay the audio by 1 frame to compensate for my external TBC then call it day when using an IO-Data like I can with a Pinnacle. I know running the IO-Data with 'Correct Video Timing' set in VirtualDub causes the audio sync to varry wildly. With that setting unchecked I'd have to delay the audio by 4 frames instead of one (3 to 4 frames are inserted at the start of capture). I dunno might run another test using those timing settings then with Amarec.

But for now until I get that squared away I'd use the card as a preview monitor and as a rare backup if needed while I still continue to capture with a Pinnacle 710 as I am a person who does not mind needing to bust out a 2013 laptop running Windows XP.

[Alwyn]

Here are some captures with one of my dodgy tapes. The GV driver is the 2010 version. The Win 11 version of the GV does a great job of straightening out the wiggles. Can I tell the difference between it and using an ES-15? If I cropped off the smooth edges, I'm not sure. Has something changed with the Win 11 version? Obviously, Yes.

I've attached two MP4s showing the differences between the two GVs without and with the ES-15 (FYI, 5db attenuator inline ). The tape is so bad that I had to split it up into two portions, as there was a few seconds of blue screen shenanigans after the first bit. They're big files because I wanted maximum quality transfer from the stack AVIs.

These are VDub captures. No drops or inserts were announced by VDub and I did the same captures with AmaRecTV; once again, no inserts or drops were recorded, despite the lack of external stabilisation and signal break.

A still frame looking at the top of the building:

[Attachment 92110 - Click to enlarge]

Added: it goes without saying that the frame offset is noted and a bit odd. But no video has been cropped off the left edge.

[lollo]

@The 14th Doctor

just give AmarecTV a try

[The 14th Doctor]

@The 14th Doctor

just give AmarecTV a try

I did a while back and from what I remember while the audio sync was better it still wasn't the same as a Pinnacle. That and I do remember running a test capture in which frame inserts were being picked up on Vdub's timeline. Nobody can get Pinnacle cards to work with Amarec so alas, can't do a comparison between just capture programs.

Guess I'll go try again eventually.

Anyway I see Alwyn, well now this complicate matters. At least with your test it looks like that the new one on it's own is better, but not to the same level as an ES15, therefore it's probably not as reliable.

Yet my findings aren't as lucky, I dunno anymore at this point.. Who knows if I was unlucky and bought an old card with an updated package.

[Gary34]

The fact that this tape is contact duplicated seems like a valid reason to say it’s not an ideal tape for testing how a device handles timebase errors since it won’t have as many timebase errors as home shot videos.

[lollo]

since it won’t have as many timebase errors as home shot videos.

And you extrapolated this from where? Is likely to be the opposite!

[Gary34]

Why is it likely to be the opposite?

[lordsmurf]

I was hoping from this thread to eventually come to a conclusion, evidence or proof even whether the GV-USB2 has at some stage undergone a design change - or a drivers change - which affects its line wiggle behaviour. No less and no more. Not to defend anything or anyone.

Conclusions were made.
To me, those were immediately obvious. And I think to you, too?

(1) GV-USB2 does not have a TBC whatsoever
(2) The "Win11 version" has some sort of aggressive temporal NR that holds fields/frames in a release/renew pattern. This gives "stability" at the sacrifice of geometric distortion. In some ways, this is actually worse than just letting it wiggle about. Nothing is corrected.
(3) Versions exist, and I've said this for years. No long-lived devices can escape chip changes over time, as that's the nature of the semiconductor industry. Fabs end, sometimes within a year. 99% within a few years.

To me, this thread was over after the 1st post. Case already closed.

Notice @all
FYI, I'm not even bothering to read lollo's/Alwyn's "GV-USB2 can do no wrong" bullshit anymore. My time is worth more than that. If they can't see the difference (for example) between a contact-duped tape, and a recorded tape, when the topic is timing correction, then there's simply no way to have a proper educated discussion here. Disagreeing is fine, head-up-ass about facts and evidence (and even valid hypothesis and theory) is not.

Seriously, I don't have the energy for this.

[Sharc]

So far we have seen 2 sources (from @aramkolt and @Alwyn) which indicate that there exist systematic (as opposed to random) differences between at least 2 GV-USB2 versions/generations. That's all I wanted to know/see. Thanks.

It also seems that the "Win11 version" (or however it is called) is somewhat less prone to wiggling, but it also appears to be less noisy and less detailed, and the capture window is slightly shifted, which supports the existence of "versions" with different characteristics IMO. My curiosity is satisfied . No rating, just taking note. (No problem if I stand corrected by others though).

[lordsmurf]

So far we have seen 2 sources (from @aramkolt and @Alwyn) which indicate that there exist systematic (as opposed to random) differences between at least 2 GV-USB2 versions/generations. That's all I wanted to know/see. Thanks.

It also seems that the "Win11 version" (or however it is called) is somewhat less prone to wiggling, but it also appears to be less noisy and less detailed, and the capture window is slightly shifted, which supports the existence of "versions" with different characteristics IMO. My curiosity is satisfied . No rating, just taking note. (No problem if I stand corrected by others though).

Always a pleasure to interact with you Sharc.

[lollo]

Notice @all
FYI, I'm not even bothering to read lollo's/Alwyn's "GV-USB2 can do no wrong" bullshit anymore. My time is worth more than that. If they can't see the difference (for example) between a contact-duped tape, and a recorded tape, when the topic is timing correction, then there's simply no way to have a proper educated discussion here. Disagreeing is fine, head-up-ass about facts and evidence (and even valid hypothesis and theory) is not.

Seriously, I don't have the energy for this.

Same here. In this thread I won't reply to lordsmurf bullshit anymore.

Any reader can download the videos provided by "active" members providing data (aramkolt and Alwin, nobody else in this thread), analyze them in a proper and scientific way and make his own conclusion.

To the next

[The 14th Doctor]

These are VDub captures. No drops or inserts were announced by VDub and I did the same captures with AmaRecTV; once again, no inserts or drops were recorded, despite the lack of external stabilisation and signal break.

Wait so what are your timing settings like for VirtualDub? Unless you mean during capture, as I (and another IO-Data user) always get 3 to 4 inserts at the start of the capture, leads me to need to delay the audio by how many frames were inserted.

IE 4 frames inserted means delay the audio by 132ms, with 33ms (1 extra frame) due to me using an external TBC. But that's the case no matter the card. It's just with a Pinnacle I only have to delay the audio by 1 frame until everything is in sync.

Also to the talk about frame positioning, my comparison shows it but the IO-Data has always been more 'right side focused' meaning there is more black bars on the right side than left, whereas with an ideal tape, the Pinnacle is more even.

That doesn't really matter, just changes the cropping numbers.

[lordsmurf]

Re-read your statement:

always get 3 to 4 inserts at the start of the capture, leads me to need to delay the audio by how many frames were inserted.

Inserts generally take the place of drops.
So the answer = 0ms, no delay

IE 4 frames inserted means delay the audio by 132ms,

Nope.

with 33ms (1 extra frame) due to me using an external TBC.

Arguable. 33ms is essentially 0ms, rounding error to natural offset (which is never 100% perfect and static).

my comparison shows it but the IO-Data

Audio issue with this card generally points back to AmaRecTV reporting, or lack thereof. Flying blind. It generally works out for the users, but there are enough reporting to not just shrug it off or ignore it. It exists.

[The 14th Doctor]

This is the one time I disagree with you I'm sorry, you've taught me very well and I appreciate your posts and overall help but still..

I haven't tested the audio in AmaRec yet but when using the Pinnacle and IO-Data with the exact same timing settings (re-syncing is 100% turned off) with my specific setup.

Delay audio by 1 frame (equals to 33ms) with Pinnacle (delay it by 1 frame due to external TBC in use, that adds in a 1 frame delay in which the audio is not compensated for as it comes directly from the playback device)

Delay audio by 4 frames with IO-Data. (IO-Data is delayed by 3 frames due to starting with frame inserts, and 1 extra frame due to an external TBC in use)

If a tape has a 1 frame delay baked in, then delay the audio by 2 frames (66ms)

Do not have correct video timing enabled when using the IO-Data, audio sync varies to the point that simply delaying the whole stream by a set amount of milliseconds does not work.

Needing to always delay the audio by one frame is not a big deal for me, I can just use audio interleave while trimming down the raw capture to save it as a new file. At least with a Pinnacle the audio does not get further out of sync so I can delay the whole stream and it just works, unlike when I've tried an IO-Data.

Also this is getting out of topic with the line TBC claims.. I'm done. The last quote you replied to was in talks with how the frame positioning is different with the IO-Data (I just wrote that as confirmation to other comments about that). You morphed it into Amarec slander.

And this is coming from me, somebody who prefers sticking with a Pinnacle and VirtualDub.


TL;DR always need to delay the audio by 1 frame with a Pinnacle in use, which is fine with me as that just works, audio sync does not get any worse overtime.

I've not been so lucky with an IO-Data so that's why I do not use it over a Pinnacle.

[lordsmurf]

Also this is getting out of topic with the line TBC claims..

Yep, too OT again.

. You morphed it into Amarec slander.

Huh?

There are many reports online of odd audio/video offset, when using AmaRecTV (and contrary to its reporting/logfiles). I'm convinced this is because it was not intended for videotape capture, but rather streaming/"broadcast" use. Those uses have fundamentally different requirements. Continuity vs. integrity. I was just reiterating this.

That's not too dissimilar from people that claim "ADVC audio is locked", when in fact that's not what "audio lock" is (and not even possible in DV25), and heavy resampling can happen in the background, invisible to the user. There's no magic to "maintain sync", but rather machinations merely being hidden from the user. That's not at all uncommon with technology.

Capturing, capture cards, can have lots of concurrent moving parts. That's why false claims about capture cards having TBCs is just needlessly dogpiling onto an already-complex situation.

I'm just trying to help others understand what they see/hear, and why. There's always science to explain it.

[Alwyn]

Always a pleasure to interact with you Sharc.

Oh, the delicious irony. @Sharc, with his detailed analysis over recent times, has done more than @Lollo or I to promote the GV-USB2 as a good, modern digitiser.

Notice @all
FYI, I'm not even bothering to read lollo's/Alwyn's "GV-USB2 can do no wrong" bullshit anymore. My time is worth more than that.

And yet another thread gets shut down by vitriolic diatribe.

[lollo]

There are many reports online of odd audio/video offset, when using AmaRecTV (and contrary to its reporting/logfiles).

Where?

The only negative post around about AmarecTV is from user rgr about not reported dropped frames https://forum.videohelp.com/threads/416658-Nero-Video-Grabber-vs-Hauppauge-WinTV-USBli...-August-VGB300 to which I replied several times here and on doom9's forums.