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

[aramkolt]

Thought I'd make a new thread on this one inspired by this video https://youtu.be/amWY9CW6NBA?si=nsZFV0i2TRiukgeW - showing some possible line-TBC-like activity for certain IODATA GV-USB2's.

I've since obtained a total of 4 different GV-USB2 devices and I conclude that at least one of the 4 is different than the others.

For fun, see if you can tell which is different from the 4 samples:

https://mega.nz/file/pQ9zHDhY#0rQrSVVOg1sO390VyIDs3QKW5t6jh8SKXxVllMX-Fg8
https://mega.nz/file/sJsUUAKJ#8GL0SjXr7Xcc3O4r3OE9j-TCu_7k8i6saEiXeB8KSXY
https://mega.nz/file/lcFUxD7b#H5uJwc1eqBQaVXw5obIJMRhXUFCq0W4ZJqSpaHkaw5w
https://mega.nz/file/QBEA2A7a#1Ol-Vu6YNSdKGie7IFqsBYGYYmlO71C_8qVpNuV3tZs

Test setup:
1. My absolute worst VCR - a basic Panasonic Omnivision that I've held onto because it was my family VCR from the 90's that unquestionably saw several thousand hours of use for timeshiftimg TV shows. I can't even feel the head protrusion when cleaning the heads with paper. The heads being extremely worn also explains why the HiFi audio sounds like crap.
2. The tape being played is an original/commercial release of "The Fugitive" - likely an Ex-Rental that is in decent shape. Definitely has Macrovision.
3. Capture was done with AmarecTV 3.10 on a modest 2010 era Windows 7 laptop with an internal SSD, probably similar to the original poster.


I will say that horizontal errors seemed to appear worse when using other random capture programs I had on the machine like ArcSoft ShowBiz and the "Light Capture" app that comes with the IODATA. Not sure why AmarecTV seems to give the most benefit here? I didn't try it with virtual dub yet.

As for dropped frames, the frame drop counter (as shown in the original video) always stays at zero (even with obviously dropped frames if fast forwarding/rewinding) with ALL of the IODATA's for whatever reason with my test setup. On the other hand, a Tevion ATI600 clone did report dropped frames in AmarecTV which was particularly easy to trigger in ff/rew modes with this setup anyway, reporting dropping at least 10 frames immediately with each initiation of FF/REW. FF was definitely worse than rewind for obvious frame drops.

This explains why in the original video we never see the dropped frame counter go up. Could be that some VCRs do appear smooth in both FF/Rew though. I do have a SR-VS30U (which looks like what the original video was using) that I could see if I can further replicate what he did in his original video, but I have no reason to doubt what he showed.

I personally conclude from the test that some versions do improve horizontal stability and therefore DO act "like" a line TBC to a noticeable degree and that there must be multiple hardware variants. The basic frame drop statistics don't work for these on AmarecTV, so you can't really say that they don't drop frames on occasion based on this preliminary testing. Those with better analysis skills could probably compare each of the 4 videos to each other and note if any dropped frames compared to each other though.

I'm sure these don't contain physical memory like a real line or frame TBC would to buffer a line at a time. My guess is they ignore the horizontal line timing (the pause between lines) and just start writing data after the color burst of each line and starts that data at the far left of the digital image it writes. This is just like "left justifying" text and could be done in realtime.

Please feel free to truncate the length so that the files don't need to be accessed via megaupload due to size if you think it'd make it easier for others to view them.

Thoughts? Tests I should do next?

[lordsmurf]

All 4 clips are 99% identical, and I see immediate proof that none have TBC.
I'll have to give more details in a further reply.

The "GV-USB2 has TBC" is just so easy to disprove as Youtuber nonsense.

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

[Alwyn]

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

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

[lordsmurf]

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

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

Are you not reading the posts?

Tip: Trying reading, not skimming.

Quote: "Thought I'd make a new thread on this one inspired by this video"

There's a Youtuber claiming that the GV-USB2 has a TBC, and it most certainly does not.

When I get some spare time -- not tonight -- I can reply more in depth. I'm not my video system right now. I'm busy. It'll be blatantly obvious, even as mere still images.

[Alwyn]

There's a Youtuber claiming that the GV-USB2 has a TBC

Yes, there is. ONE person. On another medium; Youtube. There is NOBODY here claiming so.

Why do you feel it necessary to bust your boiler over something that nobody here is claiming?

[lordsmurf]

There's a Youtuber claiming that the GV-USB2 has a TBC

Yes, there is. ONE person. On another medium; Youtube. There is NOBODY here claiming so.
Why do you feel it necessary to bust your boiler over something that nobody here is claiming?

Others are parroting it on other sites, including this one.

What's you deal? Are you okay? Go watch a movie, have a drink, get laid, smoke a bowl, touch grass ... something. Seriously.

[Alwyn]

That sounds like good advice for yourself. I'm not the one having a meltdown over the TBC in the GV-USB2...

[lordsmurf]

That sounds like good advice for yourself. I'm not the one having a meltdown over the TBC in the GV-USB2...

Projection doesn't work on me.
You're sullying a thread that is intended to debunk the false claim that GV-USB2 has a TBC. Please stop.

[Alwyn]

Aramkolt's 4 files compared...

Ignore frame sizing, colour space (VDub wouldn't let me convert to 709) and of course, no deinterlacing.

[Alwyn]

Now Aramkolt, fire up your XP PC, your $1000 JVC VCR with TBC, your $1500 Cypress frame TBC and your ATI 600 and show us what ya got!

[The 14th Doctor]

1 3 and 4 are all identical. Wiggling lines are present in all three of them.

The outlier is number 2.

Well from the IO-Data I bought that does mention Windows 11 on the box it doesn't have a line TBC, it's just that it and a Pinnacle 510/710 are more resilient to time base errors than an Elgato.

It does not correct wiggling that occurs when I turn off the TBC built into a JVC VCR.

Edit - Was judging the edges, number 2 is suspiciously cropped enough to where I can't easily deduce if it still has wiggling or not.

[Alwyn]

Edit - Was judging the edges, number 2 is suspiciously cropped enough to where I can't easily deduce if it still has wiggling or not.

These are exactly as I downloaded from Aramkolt's post. NO editing at all, Unless the stacking has done some cropping.

Added: the stacking has done no cropping. I've done a couple of captures now myself with the Win 11 version and it shows the same edging.

[lollo]

Being in a rush so no time for a deeper analysis, maybe in the next days.

Image should be checked at field level, being a patterned ntsc field architecture.

No improvement in capture 2.avi compared to 1.avi at "line" correction.







with a slider: https://www.diffchecker.com/image-compare/6aBkivFx/

some metrics:

That sounds like good advice for yourself. I'm not the one having a meltdown over the TBC in the GV-USB2...

Projection doesn't work on me.
You're sullying a thread that is intended to debunk the false claim that GV-USB2 has a TBC. Please stop.

Not really, Alwin is right here.

Nobody here stated that GV-USB has TBC capabilities.

You are just obsessed about belittling the GV-USB2 at anytime, and jumped on this thread starting your usual blah-blah. Post facts and evidences of your tests and analysis instead.

I'll have to give more details in a further reply.

Waiting for it

P.S.: @The 14th Doctor I trusted you that 2.avi is the best candidate, I had not time to check all of them

[Darryl In Canada]

I've since obtained a total of 4 different GV-USB2 devices and I conclude that at least one of the 4 is different than the others.

Can you post the Hardware ID of the four units to see if there is any difference?

The one I bought with Windows 10 on the box and a CD has this hardware ID:
USB\VID_04BB&PID_0532&REV_0005

For anyone else who wishes to share the Hardware ID info of their GVUSB2, here is how to find it:

1. On Windows computer, open Device Manager
2. Look in section Sound Video and Game Controllers
3. Right-click I-O Data GVUSB2
4. Click Properties
5. Click Details tab
6. In Property menu, select Hardware Ids

[Attachment 92078 - Click to enlarge]

[lordsmurf]

Can you post the Hardware ID of the four units to see if there is any difference?

It's just going to pick up the eMPIA bridge. The backend capture chips are unseen to the computer..

[Sharc]

I didn't find the time to go deeper into the comparison, but if a difference exists at all (with some imagination) for this commercial telecined tape I probably wouldn't pay a cent for getting the suspected "revised-improved" capture model. Rewind the tape, play and capture it again with the SAME capture device and peep for the differences ....

[The 14th Doctor]

Nobody here stated that GV-USB has TBC capabilities.

You are just obsessed about belittling the GV-USB2 at anytime, and jumped on this thread starting your usual blah-blah. Post facts and evidences of your tests and analysis instead.

Well nobody in this thread anyway, a YouTuber has though and we are trying to determine if what he is saying is the truth before any further misinformation spreads.

So far the answer is no it does not.

Also thanks for your breakdown of the avi files, I'm more confident in saying that all of them do not have line TBC function, at least, nothing as strong as a Panasonic es10 or es15 or an internal one inside of a VCR/Camcorder.

Trust me if it did, I'd be using that over the es15.

Edit - Hardware ID is the same as Darryl's. I have an IO-Data I bought around a month ago, mentions Windows 11 on the packaging.

[lordsmurf]

Alright, so here we go...

Overview

clips 1,2,4 were almost identical. Visual timing errors were obvious.

clip 3 has the odd "timing NR" applied to it. The bad-timing wiggle isn't as obvious, but all the geometry is distorted. That because is locks on bad timing, and tries to hold it the lines in place. The timing is in sort of semi-stasis, it's not corrected (ie, the C in TBC!). I would be generous to describe this stasis as a PLL. The PLL bleeds across frames, making timing noise less obvious in a preview window. When viewing the content large, it's still quite obvious. Stuff shouldn't bend that way.

This is a terrible test tape, for multiple reasons.
- it's likely contact printed, not recorded, so timing errors are not standard
- the scenes change too much, every few seconds -- typical professional-shot movie camera work
- the original I of I/O is going to be more stable than off-air/cable VCR recorded, or home movie camcorder shot, thus giving the psuedo-PLL something decent to lock on at the I

That said, it only made locating the problems less easy.

Refer to screencap 1. Comments below image.



Left is #3, right is #4 (and effectively 1,2 too)

The red boxes showing where timing issues are. In motion, these are obvious. In stills. the giveaway is interlacing motion. The wall inbox, the shelf, and the chair arm are all moving, as if an amoeba has invaded your TV.

The blue box shows how the unnatural bump is still present on a flat wood shelf. That's a static wiggle. It wasn't corrected with a TBC, just frozen for several frames, distorting geometry.

The green box shows a smearing issue in the luma, extreme ghosting to the right.That's actually less defined in the #4 clip. The interlace wiggle in #4 is a comp showing that the #3 curve of the box is not natural.

Moving on to screencap 2:



The pink arrows show "straighter" geometry, but it's still distorted. The left arrow has a a weird curve outwards from the wood corner, and the right has a weird zigzag jump where the wall seems to bow out above the display board. Again, this is not natural.

The orange boxes show how the timing wiggle changes frame to frame. The left box shows a semi-normal corner, and the right shows how that zig-zaggy jump is actually a timing curve that shows the display aligned with the wall edge.

Preventing dismissives:

I'm sure somebody will come along and make excuses for the card. Perhaps saying the issues "aren't bad". Again, refer to the test tape comments. Mass-produced retail tapes are some of the worst sample tapes. Reproducing this test on most homemade tapes will show more weakness.

And again, geometrical distortions become obvious at normal views sizes, not in tiny preview windows on a computer screen (or tablet, or phone).

I'll reply to some posts above in a new post below...

[lordsmurf]

Rewind the tape, play and capture it again with the SAME capture device and peep for the differences ....

You're a wise man Charlie Brown.

This PLL(ish) setup is non-corrective, and the "phase NR" (we need to find the right term here) applied can lock different input frames. I would assume it's time based (essentially GOP-based to compare it to MPEG decay), and the release/renew will always differ based on exact tape start time.

That's precisely what I noticed.

a YouTuber has though and we are trying to determine if what he is saying is the truth before any further misinformation spreads.

This.

Nobody here stated that GV-USB has TBC capabilities.
You are just obsessed about belittling the GV-USB2 at anytime, and jumped on this thread

Nobody here did, but the misinformation is spreading from a poorly-made Youtube video.

Yes, I jumped into yet another thread about GV-USB2, because these cards have lots of misinformation online.

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

You want to argue these things.
I want to understand them. Why, how, workarounds (if any), etc.

Waiting for it

Well, you didn't have to wait long.

You always want me to work on samples, but I am unable to oblige. Time, family, health. But this time, it was worth doing, so we can nip a myth early. The clips, the samples, the write-up -- this took me hours, most of the afternoon. This is a one-off, don't expect more. I wish I could do more. I cannot.

I continuously try to be friendly toward you. I just do not understand the hostility. If video capture was a war, we'd be on the same side. But you'd always engaging in friendly fire. Why?

1 3 and 4 are all identical. Wiggling lines are present in all three of them.
The outlier is number 2.
Edit - Was judging the edges, number 2 is suspiciously cropped enough to where I can't easily deduce if it still has wiggling or not.

Did you mix up 2 and 3?
I don't think I did. I tried to be very scientific and meticulous here.

BTW, the key here is to ignore the overscan area noises. That can lead you astray. Focus on the in-image.

[lordsmurf]

There's too many recent threads right now, same topic.

It started here with a 2026 bump on pg3:
https://forum.videohelp.com/threads/418238-Developing-a-analogue-capture-card-with-in-...e3#post2794924

Then these posts popped up:
https://forum.videohelp.com/threads/420384-Comparing-I-O-Data-GV-USB2-vs-ATI-600-Flagg...nd-Frame-Drops
https://forum.videohelp.com/threads/420443-4-different-IODATA-GV-USB2-s-tested-with-sa...-Like-Activity
https://forum.videohelp.com/threads/420448-GV-USB2-vs-ATI-TV-Wonder-600-USB

I debunked the TBC claims here in this thread.

[aramkolt]

For me, the difference I saw was in #3, you can kind of tell right away from the hard and very straight edge on the very left, as though each line was "left justified." No cropping was done to any of the samples, they are straight from the AmarecTV app. Usually one of the easier ways to spot line errors is to look to the extreme right and left of the frame to see if you can see horizontal wobbling at the black border. It is possible that there are some additional distortions within the image depending on handling of the lines though. There's really pretty minimal wobbling to be seen on the right side as well in #3.

I think for the next test, I'll record a pattern that has lots of repeating vertical lines so that it'll be easier to see those shifts throughout the frame. I'd record it from a pattern generator onto a VHS tape in EP speed using a VCR in good condition and then play it back on a different VCR and record from that machine's playback.

One key thing to mention for these tests is that you really need a guaranteed first generation tape (so that any horizontal errors weren't baked in from a dub of an original), so you want to make sure it indeed is a recording from a digital source like a pattern generator or even a DVD player with patterns if you're doing a similar test at home.

Agree it is not possible for this to be a line real TBC in the traditional sense, but I do see a visibly significant difference/improvement in horizontal stability in #3 - at least in that test.

Mainly I am trying to draw attention that not all GV-USB2's perform the same and that my findings so far do match what the original Youtube video was showing, though I found dropped frames not to count correctly in Amarec, so you can't say that that it is resistant to frame drops without a lot more testing and via other methods. I do think the other 3 look pretty similar to each other though there could be some playback-to-playback variations - part of that could be due to using the most heavily worn VCR I had for those tests.


For the next batch of tests, I'll make that EP test tape with many fine vertical lines and test most or all of the following (using VCRs that are in good condition):

1. Win11 IODATA (#3 in the examples above)
2. Older IODATA
3. Older IODATA plus ES10 inline
4. Older IODATA with the VCR's internal line TBC turned on.
5. Dell Angel - (records in MPEG2, does improve horizontal stability some from my limited testing)
6. Cloner Alliance box pro - This records/upscales to 1080p60 and is known to zoom/crop, but might be interesting to see if it does improve horizontal stability
7. 12VoltVids setup - VCR to Toshiba upscaling DVD recorder, then from HDMI output to Cloner Alliance box pro - This doesn't cause any zoom/cropping and relies on the DVD upscaler's ability to correct errors and do the scaling.


All tests other than #4 will have line TBC disabled on the playback VCR.

If I do all of those with a stable pattern on the screen, there's really no way I'll be recording identical frames or for each, so I'm hoping I can come up with a setup that has significant severe flagging or persistent horizontal wobble even with that first generation tape.

Not trying to make things more complicated by adding other capture setups to the mix, but the idea is to give a rough idea at the degree of stabilization some of the more easily available setups could give compared to the IODATA. It won't say anything about color accuracy, AGC issues, or frame drops though - this is just to look at horizontal line stabilization for now.

Open to other suggestions for specific tests as well as it might be a while before I get to these.

[lordsmurf]

For the next batch of tests,.

I can appreciate testing. But honestly, this reminds me of a kid in a sandbox playing with dog crap and dead bugs. Nothing useful will come of it. It really is the dredges of capturing. No TBCs, terrible VCRs, HDMI mess, GV-USB2 and various known-junk devices. Why not just add Easycap and Elgato to the mix?

This is interesting, but not that interesting. It just confirms what we already know, and have for years.

[Sharc]

For me, the difference I saw was in #3, you can kind of tell right away from the hard and very straight edge on the very left, as though each line was "left justified." No cropping was done to any of the samples, they are straight from the AmarecTV app. Usually one of the easier ways to spot line errors is to look to the extreme right and left of the frame to see if you can see horizontal wobbling at the black border. It is possible that there are some additional distortions within the image depending on handling of the lines though. There's really pretty minimal wobbling to be seen on the right side as well in #3.

Any particular reason why you captured to 704 width instead of 720? Clearly the capture window of #3 is different from the others (e.g. left vs right "alignment" which is driver dependent). For your future tests I would suggest to capture into 720x480 (NTSC) to see how the active picture gets actually positioned/centered within the 720x480 frame. We would see black borders on the left and on the right and be certain that nothing gets cropped.

[Alwyn]

There's too many recent threads right now, same topic.

If can't handle it, don't read it. Simple.

There are others, I'm sure, who are interested.

[lollo]

clip 3 has the odd "timing NR" applied to it. The bad-timing wiggle isn't as obvious, but all the geometry is distorted. That because is locks on bad timing, and tries to hold it the lines in place. The timing is in sort of semi-stasis, it's not corrected (ie, the C in TBC!). I would be generous to describe this stasis as a PLL. The PLL bleeds across frames, making timing noise less obvious in a preview window. When viewing the content large, it's still quite obvious. Stuff shouldn't bend that way.

Still in a rush , but trying to comments some important concepts.

I really do not understand where this PLL non sense has started. PLL provides a stable clock (generally starting from a low frequecy very accurate reference, i.e. a quartz). Its ky eparameter inside IC usage is the istantaneus jitter and the long term kitter, also know as phase noise. Nothing about that is related to a time base correction (except that this last needs a stable or regenerated clock).

I personally designed several PLLs based on the classic charge pump-vco-phase shift-filter. Attached an example of mine (pdf attached):

This is a terrible test tape, for multiple reasons.
- it's likely contact printed, not recorded, so timing errors are not standard

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.

- the original I of I/O is going to be more stable that off-air/cable VCR recorded, or home movie camcorder shot, thus giving the psuedo-PLL something decent to lock on at the I

You wrote "contact printed, not recorded, so timing errors are not standard" and now "something decent to lock on at the I". Decide yourself, and leave the PLL out of the equations, it has no role.

The red boxes showing where timing issues are. In motion, these are obvious. In stills. the giveaway is interlacing motion. The wall inbox, the shelf, and the chair arm are all moving, as if an amoeba has invaded your TV.

No time to check but considering interlaced frames is wrong. The video is captured at field level and the timing errors (and any TB correction, not present here) are inside the field at first. The red boxes show nothing.

Also remember that we are talking about analog capture so any outcome is different, even the halos.

The pink arrows show "straighter" geometry, but it's still distorted. The left arrow has a a weird curve outwards from the wood corner, and the right has a weird zigzag jump where the wall seems to bow out above the display board. Again, this is not natural.

Correct. It is not natural because there in time base correction, wisible in the vertical straight lines.

The orange boxes show how the timing wiggle changes frame to frame. The left box shows a semi-normal corner, and the right shows how that zig-zaggy jump is actually a timing curve that shows the display aligned with the wall edge.

On a fixed image the orange boxes shows nothing, post an animated gid with 3/4 consecutives frames (or better, fields) to show the wiggle (although not really necessary as experiment).

I'm sure somebody will come along and make excuses for the card. Perhaps saying the issues "aren't bad". Again, refer to the test tape comments. Mass-produced retail tapes are some of the worst sample tapes. Reproducing this test on most homemade tapes will show more weakness.

And again, geometrical distortions become obvious at normal views sizes, not in tiny preview windows on a computer screen (or tablet, or phone).

What's the point here? Excuses for the card? A recommened worklow requires a TBC correction, it is not a role played by the capture card (except few exceptions), so the card is not the actor here.

This PLL(ish) setup is non-corrective, and the "phase NR" (we need to find the right term here) applied can lock different input frames.

Stop this non-sense. You are mixing unralated concepts.

I would assume it's time based (essentially GOP-based to compare it to MPEG decay)

I know you're a fan of MPEG2 compression, but it is absolutely out of context here

Facts:

Falsities

- 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 works with any capture software, VirtualDUb included (which is prone in producing a/v asynch with modern cards and modern OSs). AmarecTV is an excellent (best) capture software available.

- 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 without a clear unnderstanding. First AmaRecTV properly reports any dropped/inserted frames, easy to verify undertanding its log file. Broadcast / streaming concept that you tried also to introduce in the past (like MPEG2 transport streams) are non-sense.

I believe it's only reporting "unexpected" loss, not expected.

That's the top of your non-sense.

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

Your "appearance" is apparently wrong

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

Yes, few are better, but the cards that you recommend/sell are not better that the GV-USB2, as shown several times.

You always want me to work on samples, but I am unable to oblige. Time, family, health. But this time, it was worth doing, so we can nip a myth early. The clips, the samples, the write-up -- this took me hours, most of the afternoon. This is a one-off, don't expect more.

Well, I do not find your contribution very useful. And if you spent most of the afternoon just to show few correct statment in the middle of "smoke in the eyes" is not nice for you.
The early myth is still there.
OTHH I fully understand your constraints

I continuously try to be friendly toward you. I just do not understand the hostility. If video capture was a war, we'd be on the same side. But you'd always engaging in friendly fire. Why?

I am friendly. But you attacked user Alwin without any reason, so I had to act

I will come back on this experiment and the others proposed by users aramkolt and DerrylInCanda next week

[The 14th Doctor]

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.

[The 14th Doctor]

Also this overall is all similar to another "item has line TBC in it when in reality it does not" claim. Being one of those ClonerAlliance devices.

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.


[Attachment 92097 - Click to enlarge]

It's one of those "it's very slightly better" results where they are both overall both crappy, one is just 1% less crappy.

[Alwyn]

Sounds like Lordsmurf 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.

Fixed it for you.

[The 14th Doctor]

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.

I give up at this point.. ugh, honestly I'm glad there are other users like Lollo who agree here that it does not have a TBC built into it, unless I am reading his posts wrong if so then I apologize.

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.

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

[aramkolt]

For me, the difference I saw was in #3, you can kind of tell right away from the hard and very straight edge on the very left, as though each line was "left justified." No cropping was done to any of the samples, they are straight from the AmarecTV app. Usually one of the easier ways to spot line errors is to look to the extreme right and left of the frame to see if you can see horizontal wobbling at the black border. It is possible that there are some additional distortions within the image depending on handling of the lines though. There's really pretty minimal wobbling to be seen on the right side as well in #3.

Any particular reason why you captured to 704 width instead of 720? Clearly the capture window of #3 is different from the others (e.g. left vs right "alignment" which is driver dependent). For your future tests I would suggest to capture into 720x480 (NTSC) to see how the active picture gets actually positioned/centered within the 720x480 frame. We would see black borders on the left and on the right and be certain that nothing gets cropped.

Very good point! I actually hadn't set up Amarec on that laptop before, so the specific settings could be non ideal and I agree that 720 will give more information on what it's actually doing on that left edge. Also makes sense why some have said it appears cropped and I wan't putting that part together that it was my capture settings. For future tests, I'll make sure it is set to 720x480. I'd need to try some other tapes, but perhaps the degree of right vs left crop in 704 capture mode might be a sort of quick way to tell which of those hardware versions you have? So maybe something useful comes of that mistake?

I'll admit I'm more of a hardware guy than a software or post-processing guy, so I definitely appreciate suggestions that could be related to capture settings or issues with the capture chain itself. This is kind of why I want to post clips directly from the capture program without even trimming them, though I think using the FFMPEG command line should be fine for rough trimming without affecting other stuff.