Is this a good indication of a working TBC?

[The_Outsider]

I made a capture of a tape, and visually, i cannot tell the difference between the capture I did with the TBC and without it.

Virtualdub reports 1 inserted frame while capturing without the TBC. Capturing with the TBC reports no inserted frames.

Is this a good indication of a working TBC?

(Workflow: Sony TRV66>DV TBC1000>AiW ati p/n 109-56700-10)

[lordsmurf]

That is not a test, no.

[The_Outsider]

I'm going to assume the simplest test is to see if a Macrovision VHS can be captured without distortion.

Are video cassettes that use macrovision marked in any way, like with a logo on the case?

[mbassiouny]

I am not an expert myself, but I had the same question and looked it up for myself, so I will answer based on what I found. Maybe if I manage to establish some protocol to test TBCs I can share in a short thread

First in order to understand if your TBC works (correctly) you need to understand what it does. So you might want to check the famous "what is a tbc" thread by LS.
http://www.digitalfaq.com/forum/vide...#ixzz6yislD6k7

What @The_Outsider mentioned may not be always a sufficient test, but it might be a hint to start your tests. Also, note that this test may not be conclusive if your capture card does already ignore/bypass MV.

So The way I test this on my side is :

1- insert MV protected tape, use it with advc-55 because this device does not ignore MV, or with advc-100/110 but do not do the copy protection Trick.
If that works, it is a good start , it means your device works but not enough to tell it works correctly, a defective cypress ctb-100 will remove MV too.

2- find a tape that has some up/down jitter.

Quote:

A good recent-era standalone external time base corrector will: reduce visual on-screen image jitter (mild up/down image bounce)

I managed to find a tape in my collection that has it, and it is again corrected by my defective ctb-100. So again, it's not enough to confirm.

3-

Quote:

and provide a steady signal that prevents dropped frames on capture cards

I see you already tested this part by checking vdub stats, but you ideally want to test this with a nasty tape, sadly in my case I have none, but if you have an extra tape maybe you can "destroy" it a bit... (dunno if it is a good idea tho)

4- The JVC blue menu, if it works fine, it might a be good indication. If it acts up on the JVC menu, it is a bad indicator, it does not necessarily mean it is not working/it is a bad TBC, I have seen LS mentioning that some TBCs are good and work fine even if they act up on the JVC menu.

5- capture with and without TBC, compare frame by frame using something like avspmod, that the TBC did not add any extra issues, this is the test where defective units like black AVToolbox AVT-8710 will fail, because when you compare you will see ghosting created by the TBC.
You're looking for something that looks like this:

a=LWLibavVideoSource("capture.avi")
b=LWLibavVideoSource("capture_with_tbc.avi")#.trim(XX,YY) # trim the longer video to align both videos
stackHorizontal(a,b) #notbc on the left, with tbc on the right

Personally, I could not see any defects in my captures with a defective cypress, compared to non-TBC captures so again, it is just a step in the process, not enough on its own to confirm.

These are just some indications, but I think they might help

[lordsmurf]

A test, yes.
Sole test, no.
Definitive test, no.

You can have anti-copy (Macrovision, etc) that removes without TBC, and anti-copy that doesn't remove with TBC. There's lots of variables, anti-copy is not binary, on/off, and that's it.

There's even many devices (TBC and not-TBC) that botch removal/bypass, so you end up with partial removal, or even anti-copy that looks worse.

Defective-chip Cypress units, and even defective-cap DataVideos, will correct some degree of jitter. That's not a function that is messed up by the bad chips. Frames jump due to missing lines, and the frame isn't accurate, and the frame TBC recreates that missing data.

Correct, there are some passable TBCs (not really good, but functional) that has problems on lesser signals. So the JVC test will fail, as it's not a true NTSC signal. That's merely an easy test for bad Cypress units, and clones. The issues on Cypress, and rackmounts, go far beyond tripping over menus.

Sometimes certain sources will fool you, and a bad TBC can be deemed "good" at first. But it eventually shows problems, after more use, careful observation (actually watching what you capture).

[mbassiouny]

Quote:

Originally Posted by lordsmurf

A test, yes.
Sole test, no.
Definitive test, no.

I agree.

Quote:

Originally Posted by lordsmurf

Sometimes certain sources will fool you, and a bad TBC can be deemed "good" at first. But it eventually shows problems, after more use, careful observation (actually watching what you capture).

I totally agree, too, watching carefully long capture (not just 3 minutes long) with some software like avspmod, go thought frames and not just real speed will help, but not anyone qualify to do this test, I don't consider that I qualify personally, you need to train your eyes to see the mistakes, which again boils down to understanding what a TBC is supposed to do in the first place.

[hodgey]

Another thing that trips up the bad avtoolbox tbcs was fast forward/rewind and pausing, with a working one it should be smooth and not be dropping frames (though it will slide up/down when starting/ending and maybe a bit during due to how ffwd/rwd/pause works on vcrs). The bad avtoolbox and tvone tbcs I tested ended up with frozen or rolling fields when doing that, the issue on those specifically seems to mostly be a thing when vsync is abnormal, missing or non-standard. Note, may not work on a few vcrs that have digital slow/pause, I think e.g the Samsumg multi system converting ones do, or if it's a dvd-recorder combo that sends evrything thorugh the internal digitizer, as in those cases the signal will already have been digitized and output in a stable way with whatever issues there is baked in.