Datavideo TBC-1000 broken?

[illicit1]

Seems like my TBC-1000 is broken. Video actually looks worse through the device than with it removed from the workflow. I've attached a video showing 5 different sources, 1 without the tbc and then from each of it's ports. You can see on both ports C and D the video has gray frames at the same time 00:20 There's also visible tearing on all the ports, like in the spot where the car drives in front of the sign. Not visible the same without the TBC.

Video is at 50% speed and then full speed on second half.

Why is the TBC doing this and what can be done about it?

JVC HR-S7100U->S-Video to TBC-1000->S-Video to Sony HVR-M35U->Firewire to ffmpeg rawcapture M1 MacBook

[latreche34]

You need line TBC on on VCR and remove the TBC-1000, you don't need it if you are not losing frames.

[lordsmurf]

Quote:

Originally Posted by illicit1

Seems like my TBC-1000 is broken.

No. Keep reading...

Quote:

Video actually looks worse through the device than with it removed from the workflow.

No. The "without" is not better, just bad in a different way.

TBCs, as the full name implies, literally "corrects" video.

- Line TBCs ("internal" TBCs) fix the image.
- Frame TBCs ("external TBCs") fix the signal.
- You need both.

You lack line TBC. So the bad signal is "corrected", but the consequence of input this non(line)-corrected video into a frame TBC is that it looks still looks bad. Just bad in a different way.

Quote:

There's also visible tearing on all the ports

The "jitter" (jargon term), aka wiggles, was on the no-TBC sample. The DataVideo simply emphasized the error, because it was being frame-corrected. Jitter happens because portions of the field/frame are short, or missing. The "corrected" field is uglier as a result. Line TBC fixes jitter/wiggling, not frame TBC.

Quote:

Originally Posted by latreche34

you don't need it if you are not losing frames.

No, refer back:

Quote:

Originally Posted by illicit1

JVC HR-S7100U->S-Video to TBC-1000->S-Video to Sony HVR-M35U->Firewire to ffmpeg rawcapture M1 MacBook

This DV unit will hide dropped frames, and there is literally zero way to have drops reported. Note how the attached samples seems to drift.

Rarely is a frame TBC not needed. In fact, literally almost never. It essentially ensures file/time integrity, no loss of temporal data. No dropped frames, no audio sync errors.

Quote:

Originally Posted by illicit1

JVC HR-S7100U

The JVC 7100 is an ancient non-suggested VCR for a reason: lack of line TBC.

It's a simple fix, swap to a known-good/better VCR. And done.

Or add ES10/15 after VCR, before TBC-1000.

Or both.

Sometimes old VCRs like the 7100 actually induce/create the problems inside the deck, and the tape plays much better in newer/better/suggested decks.

[aramkolt]

First question - how did you set up your clips like that to show what looks to be 6 clips in a single comparison? I've been meaning to test my TBCs and VCRs against each other and this looks like a good way to show it at a glance in terms of larger picture issues.

Next, each of the different ports on the TBC1000 really shouldn't be different from each other - it's really just a distribution amplifier meaning that it amplifies the signal depending on how many devices are attached to get to the same final level as each connected output adds a 75 ohm load to the original signal. It is likely that the distribution amplifier has bad capacitors, (and there are lots of them), so generally I'd recommend bypassing that distribution amplifier altogether if you have the means.

What you are mainly seeing off of the different ports in this case in terms of differences are from one playback to the next variances. Color differences would be more likely due to bad capacitors in one section of the amplifier.

Here was my take on how to bypass the amplifier if you're curious:
https://www.digitalfaq.com/forum/vcr...tribution.html

Jury is out as to whether the fan really matters or if it adds any signal noise, but there's a switch in front to turn the fan off as well - it definitely does run 15 degrees cooler with the fan though and would probably run even cooler if little heatsinks were applied to the hotter chips, but I'm not as big into non-reversible modding. I ditched all of the original board connectors as well since they are stress points and require the cables to come off at odd angles and produced longer "unshielded" portions of the signal path.

But anyhow, my guess is why the "no TBC" looks the best is because DV conversion chips almost always have a "line-TBC-like-effect" to them whether advertised or not, so in this case, that's the HVR-M35U. If you put a frame TBC (The TBC1000 in this case) before a line TBC in a chain, it'll bake in the horizontal errors to the point that the line TBC afterwords doesn't see any timing errors because they've already been baked-in by the frame TBC during it's analog to digital and then back to analog process.

LS is correct that if you had used a recommended VCR with a line TBC that this wouldn't be an issue because it doesn't give you the opportunity to put the frame TBC before the line TBC in the chain because it comes out of the VCR already line-TBC-corrected.

But anyhow, the real test to show how good the line-TBC-like-effect is in your hardware DV converter would be having a recommended VCR with a line TBC and then capturing directly through the DV converter in both cases with the VCR's line TBC on versus off. If you can't tell the difference in what comes out of the DV converter in both situations, then the DV converter's line TBC is as good as the internal one. Most likely will be that the internal line TBC does a little better on rough tapes, but you can see that it does much better than nothing given your "no TBC" example is the DV converter alone having that effect.

DV converters also tend not to drop frames because they were made in a time when timebase errors were to be expected and they were more tolerant of them. Can you imagine if every Sony camcorder or Canopus ADVC product that was bought for analog conversion gave the sort of obvious errors you are seeing when used with an average VHS player without a line TBC? They'd have all been returned to the store within 5 minutes of use.

LS is also correct that the DV converter (and the TBC1000 or ANY TBC for that matter) will not tell you if it is dropping or duplicating frames. The way around knowing that FOR SURE in my opinion would be to use a timecode generator which visually overlays/burns in a unique timecode onto each field. If that is placed right after the VCR, you could then go back to the captured file and see if all the frames are there by manually scrolling through the captured frames and looking for the time code to change on each field/frame. If a time code in the sequence gets skipped or you see the same frame code show up twice or more on sequential frames, then frames were indeed dropped or duplicated at one point in your chain. I wouldn't suggest actually capturing that way since no one really wants to see timecode over their footage, but it will tell you (as a test) if your chain likes to drop or duplicate frames or not. If you do a capture of what appears to be a rough-tracking/jittery tape and there are no dropped frames or audio sync issues, you can be fairly confident that your chain is at least very tolerant to timebase errors and is unlikely to drop frames with better quality/better tracking tapes.

Something like this would work: https://www.ebay.com/itm/223820128759

That can actually work with S-Video as well, you'd just pass the luma wire only through it, but composite for testing for dropped frames is perfectly fine to use as is. Downside to the one above is that it is missing the power supply, but hopefully you get the idea.

This sort of testing has been on my list of things to try for a while, but I have been busy refurbishing AG1980's/Umatic/Betacam decks of late.

[timtape]

Quote:

Originally Posted by aramkolt

...It is likely that the distribution amplifier has bad capacitors, (and there are lots of them), ...

I looked at one recently. At first I just replaced the obviously bulging larger caps but later found many smaller caps measured bad or questionable. They were all the longer lasting through hole types not the SMD types. I suspect the internal heat buildup (no ventilation holes or slits in the small case) had shortened the life of these many caps. One design error can compromise an otherwise good product.

[lordsmurf]

Quote:

Originally Posted by timtape

I looked at one recently. At first I just replaced the obviously bulging larger caps but later found many smaller caps measured bad or questionable. They were all the longer lasting through hole types not the SMD types. I suspect the internal heat buildup (no ventilation holes or slits in the small case) had shortened the life of these many caps. One design error can compromise an otherwise good product.

DataVideo products were great, but it was often more of a "in spite of" situation. Some of the products were not just badly designed, but performed badly.

Quote:

Originally Posted by aramkolt

Next, each of the different ports on the TBC1000 really shouldn't be different

This isn't true. The outputs from the VP-299 are isolated pairs. So A/B and C/D can, and do, differ. If everything is in tip-top shape (perfect caps, etc), then it should be almost imperceptible. But differences will still exist. It's analog.

Quote:

depending on how many devices are attached

This is not what you meant, but it bring up another good point. Signals are bidirectional currents, not one-way. So, for example, you can get feedback on TBCs from craptastic capture cards. One of my quality tests for TBCs involves noise spew from downstream devices, not just upstream (VCR, ES10/15, whatever pre-frame in the workflow).

Quote:

It is likely that the distribution amplifier has bad capacitors,

I think we've reached the point in time where it's not even "likely", it's just assured now in the 2020s. Any DataVideo TBC issues is an automatic recap scenario now.

Quote:

I'd recommend bypassing that distribution amplifier

Agreed.

Quote:

Color differences would be more likely due to bad capacitors in one section of the amplifier.

That part isn't necessarily true. There is some inherent shift, even on refurb'd/re-cap'd units. Even bypass strips you down to composite vs. s-video, where changes still exists. Because, again, analog. That's why test patterns and proc amps existed. TBCs have never been, and never will be, 100% transparent. (No, FM/RF does not alter this fact. If anything, it makes it vastly worse due to absence of baseline values.)

Quote:

Jury is out as to whether the fan really matters or if it adds any signal noise, but there's a switch in front to turn the fan off as well - it definitely does run 15 degrees cooler with the fan though and would probably run even cooler if little heatsinks were applied to the hotter chips, but I'm not as big into non-reversible modding.

No jury, it's long ago proven science/fact for the OEM specs. It would take a new case/design to implement properly. DataVideo was really a "kit recycler" at times, and the TBC-1000 housing truly sucks. The DVK units are not much better. DataVideo had like 4 base designs for probably 50 products, and I'd suggest at least 40 of those 50 should have had better boxes.

Quote:

I ditched all of the original board connectors as well since they are stress points and require the cables to come off at odd angles and produced longer "unshielded" portions of the signal path.

Oh yeah? We should talk. Note to self: aramkolt, TBC-1000, new internal cables.

Quote:

But anyhow, my guess is why the "no TBC" looks the best is because DV conversion chips almost always have a "line-TBC-like-effect" to them whether advertised or not,

This is literally almost never true. And then something like the ADVC-300, which did tout a (line) "TBC", was using a truly beta-grade weenie/weak Panasonic chip (pre-ES10) that did almost nothing. Worse yet, often bad.

Quote:

so in this case, that's the HVR-M35U. If you put a frame TBC (The TBC1000 in this case) before a line TBC in a chain, it'll bake in the horizontal errors to the point that the line TBC

This is not true, because there is no line TBC here. It's very obvious, even in this "no TBC" sample.

|
|
-- Below this point is veering off-topic from the topic of TBC --
|
|

Quote:

DV converters also tend not to drop frames because they were made in a time when timebase errors were to be expected and they were more tolerant of them.

This is not true, and I wish you'd stop repeating this myth.

In the late 1990s, Canopus marketing misunderstood the jargon term "audio lock" as it pertained to professional DV workflows. It has nothing to do with audio capture on ingest/capture. DV is a codec, nothing more. DV boxes are just capture cards that hardware encode with a DV codec. There were also MPEG capture cards, MJPEG capture cards, etc, and nobody ever claims this -- because it's not true. The company (Canopus) that claimed this hasn't exist in 20 years now (mostly liquidated by Thomson Grass Valley).

Quote:

Can you imagine if every Sony camcorder or Canopus ADVC product that was bought for analog conversion gave the sort of obvious errors you are seeing when used with an average VHS player without a line TBC? They'd have all been returned to the store within 5 minutes of use.

This isn't true either.

99%+ of people are/were totally unaware of this "bonus feature" found on certain camcorders. And it was only available very specific models of camcorder, too, not just any random camcorder.

The primary audience for DV converters was small-time studio operations, like wedding photographer. The main use-case even pre-dated DVDs, as the DVD-R(G) didn't even exist yet. You'd have to pay $$$$ for DVD-R(A) and pressing back then. So what is it good for, you ask? You'd ingest analog to DV, edit in the Pentium III-era NLEs (Premiere, Edius), then export the DV back to DV tape. Then duplicate to your S-VHS masters, and duplicate VHS tapes for distribution. That was the analog+digital workflow of the day. That was how the digital video world existed when I started my late-hobby/early-career days into digital video. Streaming low-res Real/WMV/MOV was the format of the day, and was exported by the NLE via software like Cleaner.

So, at the time,
- DV loss didn't matter, as the output/workflow couldn't sustain it any higher anyway.
- Making DVDs wasn't a thing.
- Archiving permanent wasn't a thing, as we all knew the loss would require re-capture when the tech matured. (FYI, it matured in 2001, when I bought my ATI/DVD-R setup.)

The member @NJRoadfan has a lot of knowledge from this era. Maybe even more than me?

So claims about DV being good, having TBC, whatever. That's all revisionist hooey from people who were not there 20-30 years ago. I still remember using software that 99%+ of people have never heard of, but was the tool of the time. Nobody remembers stuff like SGI MediaBase, or even that companies like SGI existed. (SGI was an early user of RISC chips, a pre-cursor to modern ARM. The R is ARM is for RISC. SGI servers back-ended early streaming software.)

If you go back to 1990s and early 00s posts -- which is hard to do, because lots of those sites are now gone -- you'll see no love for these. More often, you'd see newbies asking about them, often repeating wrong information about them. That's because they didn't know -- in addition to not knowing what they didn't know.

For whatever dumb reason, within the past decade, especially during the pandemic, people "found" the devices for cheap, and then started to make some really wrong claims about them.

I posit one back at you:

If DV converters truly had TBCs, and did all that is/was needed, why would we have all bought line TBC VCRs and frame TBCs back then? Do you think that people "in the know" (at that time) were just dumb?

What's more believable here?
- Knowledgeable pro/hobby users in the 90s-00s were dumb?
- Modern newbies still know nothing?

That's really the entire crux of these arguments on how good/bad DV boxes are. Including claims of "it has TBC" and "it doesn't lose audio sync", etc..

Quote:

LS is also correct that the DV converter (and the TBC1000 or ANY TBC for that matter) will not tell you if it is dropping or duplicating frames. The way around knowing that FOR SURE in my opinion would be to use a timecode generator which visually overlays/burns in a unique timecode onto each field. If that is placed right after the VCR, you could then go back to the captured file and see if all the frames are there by manually scrolling through the captured frames and looking for the time code to change on each field/frame. If a time code in the sequence gets skipped or you see the same frame code show up twice or more on sequential frames, then frames were indeed dropped or duplicated at one point in your chain. I wouldn't suggest actually capturing that way since no one really wants to see timecode over their footage, but it will tell you (as a test) if your chain likes to drop or duplicate frames or not. If you do a capture of what appears to be a rough-tracking/jittery tape and there are no dropped frames or audio sync issues, you can be fairly confident that your chain is at least very tolerant to timebase errors and is unlikely to drop frames with better quality/better tracking tapes.
That can actually work with S-Video as well, you'd just pass the luma wire only through it, but composite for testing for dropped frames is perfectly fine to use as is. Downside to the one above is that it is missing the power supply, but hopefully you get the idea.

I like the hypotheses, but my well-founded fear is that adding another devices, into an analog workflow, will only serve to introduce more problems. And for what? To "prove" that a known-inferior device is maybe less inferior? It's a lot of effort, and added expense, for no actual gains.

Quote:

This sort of testing has been on my list of things to try for a while, but I have been busy refurbishing AG1980's/Umatic/Betacam decks of late.

Always remember that you enjoy testing, for the sake of testing. Most people are not interested in that. They need results.

It reminds me of people who enjoy churning butter. That's great and all, but it doesn't help the person who wants to smear some on their roll while sitting at the dinner table. I enjoy** testing, but I discuss it less for that reason.

(**Honestly, I often view my enjoyment as a distraction, a black hole that sucks me in, and prevents me from better use of my time. It can be no better than "surfing" the web, or "doomscrolling" social media. I see a lot of that in you, with gear testing. You have to be careful. Moderation is not just doing it, but sidetracking conversations by discussing it. I like the meme "Sir, this is a Wendy's!")

[illicit1]

Just chiming in to say thanks for the responses, i'm still processing everything I see here and will certainly have some questions when I get a moment to reply.

[aramkolt]

The point of the visibly burnt in timecode test would be to prove that frames are not dropped or duplicated on with a given tape/chain. This should also be useful when testing other devices that can't report frame drop statistics.

I wouldn't say the DV boxes have/are a TBC, I just think they were designed to be more tolerant to timebase errors because they were meant to be used in an era when most sources going through them would have had significant timebase errors. This is probably also the reason that DVD recorders of the error had similar functionality at least for visible/line errors, perhaps at a cost of not a perfectly accurate frame rate.

DV converters certainly are not technically TBCs in that they do not contain significant memory to store lines/frames worth of data and then release them at a regular rate. That may not actually be needed though if they are just outputting a constant digital stream and they don't have to reconstruct an analog stream in realtime afterwords like most TBCs need to do. Since each line has a pause between it (the horizontal blanking interval) and the start of a new line is indicated by the sync pulse and each frame has even more of a gap between it (the vertical blanking interval), memory may not be required to achieve a line-TBC-like-effect. The device would just need to write digital data for the video line when it sees a new sync pulse and ignore the blanking intervals between lines and frames.

Really the main missing piece would be making each horizontal line of active video data the same "length" and I think that's what AnalogDevices ADLLT (Adaptive line length technology) did - though that does require memory to store all data from a single line and then compress or expand it linearly to take up the same horizontal space.

What "test design" would best show that a DV conversion box produces a similar effect to either line or frame TBCs? There shouldn't be a debate when we can just do a test to show what it does or doesn't do. The results of course are also important, and I'd rather just skip to the result part, but there's not much point in doing the test if the design of the test will be criticized after the test.

Again, DV has other limitations, so I'm not saying it is an ideal transfer format (bitrate/macroblocking/color depth/color subsampling could be better), I just think it does avoid a lot of the timebase error problems, obvious geometry problems (flagging/tearing), and audio sync problems in my *admittedly* very limited testing.

[lordsmurf]

Quote:

Originally Posted by aramkolt

The point of the visibly burnt in timecode test would be

The timecode generator may mess with the signal, between VCR and capture card. It may "burn in" data to an acceptable level for non-drop in the converter. So you have to test the tool before you can use it as part of a test.

Quote:

I just think they were designed to be more tolerant to timebase errors because they were meant to be used in an era when most sources going through them would have had significant timebase errors.

Nope.

Quote:

This is probably also the reason that DVD recorders of the error

Era. Yep, this part is accurate. Early DVD recorders, 2002-2003 especially, were largely crap. The ES10 and JVC were a "2nd generation" where you saw consumer-format defects being addressed finally, such as cNR and line TBC(ish). Sadly, there was never unit that could do it all, nor screw up the encoding specs (ie, 720x480 was ridiculous, starved for bitrate). The resiliency of capture cards also improved around 2005. The AIW cards have some of the best quality, but resiliency (freaking out to timing errors) is basically non-existent.

Quote:

That may not actually be needed though if they are just outputting
and they don't have to reconstruct an analog stream in realtime afterwords like most TBCs need to do.

It's required somewhere. If not on output, then on input, or in-between processing. It's can't simply not exist.

Quote:

and I think that's what AnalogDevices ADLLT (Adaptive line length technology) did - though that does require memory to store all data from a single line and then compress or expand it linearly to take up the same horizontal space.

That chip is such a POS. Even with ample RAM bank, it doesn't do what people think. It's just really unstable, very erratic. It's been discussed as a "maybe TBC" for 10 years now, and I don't know that's it's even made anymore. All tests always failed.

Quote:

I just think it does avoid a lot of the timebase error problems, obvious geometry problems (flagging/tearing), and audio sync problems in my *admittedly* very limited testing.

Oh no, ADVC-300 definitely adds tearing issues. I have samples of that somewhere. (I'm in process of gathering 20 years of samples, and will attempt to share some/most/all after the new site is finished. I just need time.)

[Gary34]

Quote:

Oh no, ADVC-300 definitely adds tearing issues. I have samples of that somewhere. (I'm in process of gathering 20 years of samples, and will attempt to share some/most/all after the new site is finished. I just need time.)

That’s great! That sounds like a really tough task. That is a bunch to dig through. It will be interesting to see samples from gear that is in good shape instead of the samples people normally see representing conventional capture. I’m really looking forward to the new site.

[illicit1]

Sorry for the delay here, got real busy with some unexpected things. So in the end, i'm still not sure if I have a bad TBC (capacitors) or not. But my main takeaway is to get Line TBC either via a different VCR or add a ES10/15. I'll do this and report back my results.

Quote:

Originally Posted by lordsmurf

You lack line TBC. So the bad signal is "corrected", but the consequence of input this non(line)-corrected video into a frame TBC is that it looks still looks bad. Just bad in a different way.

The "jitter" (jargon term), aka wiggles, was on the no-TBC sample. The DataVideo simply emphasized the error, because it was being frame-corrected. Jitter happens because portions of the field/frame are short, or missing. The "corrected" field is uglier as a result. Line TBC fixes jitter/wiggling, not frame TBC.

This makes sense to me.

Quote:

Originally Posted by lordsmurf

This DV unit will hide dropped frames, and there is literally zero way to have drops reported. Note how the attached samples seems to drift.

While I understand theres no way to report on actual dropped frames, would it be accurate that when I receive this error from ffmpeg that this would be an indication of at least 1 dropped frame? My understanding of the actual error is limited to various forum posts i've found, which don't seem entirely accurate. So if anyone has a more solid answer on this error i'm interested in hearing more. (attached video: increasingdts.mov)

[rawvideo @ 0x126e3c510] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 39906533 >= 433766

Quote:

Originally Posted by lordsmurf

Or add ES10/15 after VCR, before TBC-1000.

Will do this.

Quote:

Originally Posted by aramkolt

First question - how did you set up your clips like that to show what looks to be 6 clips in a single comparison? I've been meaning to test my TBCs and VCRs against each other and this looks like a good way to show it at a glance in terms of larger picture issues.

I added them all to a 2k project in Final Cut Pro, lined them up in the timeline using a specific frame in the video.

Quote:

Originally Posted by aramkolt

Next, each of the different ports on the TBC1000 really shouldn't be different from each other - it's really just a distribution amplifier meaning that it amplifies the signal depending on how many devices are attached to get to the same final level as each connected output adds a 75 ohm load to the original signal. It is likely that the distribution amplifier has bad capacitors, (and there are lots of them), so generally I'd recommend bypassing that distribution amplifier altogether if you have the means.

Thanks for the background and link here, will be looking into this as well.

Quote:

Originally Posted by aramkolt

What you are mainly seeing off of the different ports in this case in terms of differences are from one playback to the next variances. Color differences would be more likely due to bad capacitors in one section of the amplifier.

I considered these were playback differences but it just seem too much a coincidence that ports A & B seem to match while C & D match, but AB and CD don't match each other. See attached video (framebyframe.mov), with location line in the timeline where im moving frame by frame and you can see where they match up. I also did a quick visual for bad capacitors and I didn't notice anything obvious. Thanks for your link on the bypass, will look at doing this.

[timtape]

Quote:

Originally Posted by illicit1

I also did a quick visual for bad capacitors and I didn't notice anything obvious. .

I'm a tech. I worked on one the other week. Many small capacitors looked fine but measured poor . Techs use an ESR meter to test caps.

[aramkolt]

Quote:

Originally Posted by lordsmurf

This is not true, and I wish you'd stop repeating this myth.

This would be an easy enough test and I think I can squeeze it in this weekend - I will take the video output off of an SLV-R1000 (which has no line TBC and loves to create extreme flagging with just about any tape) and capture it via DV (ADVC-110) versus an AIW 9200 with no other TBC present. I suspect that the DV capture will not have any flagging or geometry issues, whereas the AIW will have those issues, but I'll be perfectly fine admitting if I'm wrong about the line-tbc-like-effect of DV hardware capture cards.

Why do I think this will be the case? Because this test has already basically been done here:
https://www.youtube.com/watch?v=3SRoGgJZbwc

It shows that ATI600 and the DV capture chain both have line-TBC effects - VideoCaptureGuide attributes that effect to the DV camcorder having a line TBC, though we really don't know if that line TBC technically works on incoming AV sources, I'd say it is more likely that the DV conversion chip is doing that. If line TBC tape playback devices could do that, you'd expect to be able to use a line-TBC-containing VCR as a passthrough device for a device that doesn't have a line TBC, which simply does not work at least in 95%+ of cases. I speculate that even the ES10/15's effect is the MPEG2 conversion chip doing that as part of it's feature set, it isn't actually a line TBC where data is buffered into memory. MPEG2 and DV conversion chips aren't too dissimilar is my understanding anyway and they are also from the same era where sources were expected to have timebase errors.

We also know that the ATI600 does not have an actual line TBC in it (yet acts like one). The interesting thing is that if a frame TBC like the TBC1000 was put before it in the chain, it likely would have baked in the line errors and you would not get that effect - just like the original poster here is seeing.

VideoCaptureGuide also did a comparison on a VS30U where the line TBC was turned OFF and played out VHS as DV, the same line-TBC-effect was still seen: https://www.youtube.com/watch?v=Z5vL-3kpD6Q

This proves the DV chip alone will give the same (or visually very similar) results as a line TBC despite not containing a line TBC (which requires a separate memory buffer to technically be one in my book).

As far as whether ADLLT actually works or not, there's only one device that I'm aware of that contains the actual extra memory required to make that feature work which is the TBS800 demoed here by Delisam34: https://www.youtube.com/watch?v=3SRoGgJZbwc Check out post #13. That's also a second generation tape which should be extra challenging.

There are lots of ADLLT supporting Analog Devices chips out there, but 99% of the devices did not have the required extra memory installed for that feature to be active or enabled - likely because of cost and complexity.

So to summarize, I'm not saying DV chips have a line TBC, I'm saying they produce a near-identical result in terms of GEOMETRY/Flagging compared to devices that do have "real memory buffer line TBCs" which is the main reason you'd want to use a line TBC. The usual DV limitations of bitrate, possibly color accuracy, and possible macroblocking in certain scenes still apply, and it is only likely to work on first generation tapes.

Now whether frames get dropped in the DV conversion, that's another question altogether. I think the answer to that can be found by using a digital source with burnt in timecode that can be done in Davinci - then recording that onto VHS, then capturing that tape with the DV converter and looking for dropped frames over a longer capture. It'll be pretty annoying to have to actually look at all the frames one by one for a unique timecode without skips, but it'd work. You could also just look at the total number of frames in the captured timeline and see if it matches the timecode number of frames, but that won't rule out a dropped and then duplicated frame.

[Gary34]

Quote:

This would be an easy enough test and I think I can squeeze it in this weekend - I will take the video output off of an SLV-R1000 (which has no line TBC and loves to create extreme flagging with just about any tape) and capture it via DV (ADVC-110) versus an AIW 9200 with no other TBC present. I suspect that the DV capture will not have any flagging or geometry issues, whereas the AIW will have those issues, but I'll be perfectly fine admitting if I'm wrong about the line-tbc-like-effect of DV hardware capture cards.

Why do I think this will be the case? Because this test has already basically been done here:
https://www.youtube.com/watch?v=3SRoGgJZbwc

It shows that ATI600 and the DV capture chain both have line-TBC effects

Around 2005 cards started being more resilient. The AIW card may be great but it handles an unsteady signal worse than a lot of cards. That doesn’t mean all the cards made after 2005 have a TBC like effect. The AIW really shouldn’t be the bar in that test.

[illicit1]

Alright, so i've acquired a DMR-ES10 to throw into the mix and did some tests. I've attached a screenshot that shows the last set of videos i've taken, labeled. It's pretty much useful only to show the different spots there are dropouts and how vastly different each playback is in this regard.

My observations:
I think theres plenty of evidence to show there really is no specific difference between the ports but rather difference in each playback regardless of the ports.

Obviously this is a very short clip being used, but for this tape im using as a test it does appear removing the TBCs and going straight from VCR to DV to computer eliminates the visible drops? Looks like only once in my tests did I get no visible dropped frames when using the Datavideo TBC (the very bottom clip).

-- merged --

Think I forgot to attach the screenshot..

[aramkolt]

I think DFAQ is compressing your image there as you can't really make anything out detail-wise. Could you upload it to something like dropbox or maybe put it into a zip file first and attach that way?

[lordsmurf]

Attach into a zip.
Not on external site (because it always eventually disappears, making the conversation worthless).