Canopus ADVC-300 passthrough line TBC?
 

Hello all,

I've just had to do a small repair on an ADVC-300, however, while it was on the bench I've done a few experiments to try and determine for myself if the unit has an effective line TBC.

I've got 'The Bastard' out, our machine that's deliberately kept because it will give any TBC an absolute workout, it's a 1981 model Sanyo Betamax (or should that be Betacord machine) that's been thoroughly abused and as it has very easy access to the adjustments for timings.... It's routinely and randomly twiddled with, I can also programmatically (with an Arduino) set it to sweep, random field, timings etc purely to give any TBC an absolute hot mess to unpick.

It's been a fun hour before I start posting my findings (which probably won't be until tomorrow as I need to analyse some wave captures etc) who wants to make a guess?

- It has no line TBC functionality?
- It has very limited TBC functionality (feel free to explain)
- Meh, possibly it's doing something?
- It's a fair line TBC
- It's a great line TBC

What I can say, is that it does modify the video wave form, that I can prove conclusively, for better or worse though, or no impact?

Or something else will be interesting to see what my experiments correlate with.

I would like to see a split screen of the HBI/VBI section, Do you have a studio monitor or can modify a regular CRT to display a split screen? That would be the ultimate test.

I'm using a small JVC studio monitor set in A/B switching but it does not allow split screen.

I'm going to make some captures, post up some grabs from the 'scope and diagrams.

Leave it with me, I'll check in the store room and see what's on the rack, we may have an A+B unit somewhere. If not I can probably fudge something.

Depending on sources, it's within this range. Do nothing, to do minimal.

And minimal is actually arguable worse performance. I have some good samples that showcase this (one of my 2020 pandemic projects, but I've not had time to share findings yet). What often happens is the unit struggles to hold the timing corrections. It must have a puny RAM buffer.

The ADVC-300 has another problem, however. Much like the ES10/15, it has filters that are always-on, even when "off". So it's more like high/low, not on/off. Canopus engineers, like Panasonic engineers, consider the users stupid, and they "need" some % of filtering. Such things are not new to video, or even non-video, a "protection" for users to not complain.

So what you have is this:
- cooked colors, aka bad NTSC 4:1:1, and passable PAL 4:2:0
- DV blocks
- a "TBC" that is mostly in name only, minimal corrections
- aggressive NR/filters that messes with quality

The card is garbage.

If you insist on a DV converter, get the ADVC-100, 110, 50, 55. Or the DataVideo DAC-100.

What would you suggest, in terms of capture cards?

I'll chalk that one up.

I'm not testing it for DV functionality, only as a passthrough, just to eliminate that before we wander into that as it's not especially relevant here: we need good SNR.

Remember I am feeding it horrendous, barely displayable video (with waveform captures) through to fair video as part of this.

Small pre-experiment might be easier to share by video, give me a bit.

It has sufficient jitter correction, not as good as the line-tbc in the svhs recorders or the Panasonic DVD recorders in passthrough mode. It also has useful proc-amp functions. But you should turn off all filters. The device also does not like blank spaces without movie content. Another disadvantage is the DV compression and that there is a problem with sound offset that can disturb sensitive ears but also many users do not notice as long as they do not know that it exists.

It is better than using nothing at all. If you can find a cheap device (not more than 50 Euros) definitely worth a try for the PAL capture workflow.

I'm not discussing the DV constraints and merits here, just purely using it in 'passthrough' mode. There's no DV involved in my experiments.

I've got a 'few' TBCs here, I'm just intrigued as there's a lot of conflicting information posted around the web about this device, and as I do have the equipment and knowledge to perform some experiments myself I thought it might be interesting to share.

I'll upload a video in a moment of the first thing I discovered.

RR

Do you have schematics of the unit? I don't think the box does pure passthrough. It hardware encodes all input to DV, period. All output is DV encoded.

At the very moment, I'm testing some DV gear in Win10.
I hate Win10.
@#$%&-ing Win10. :rant:

The big issue with DV boxes is that footage is lost at start/stop of breaks. I have an old family tape for testing, and the clip-show on/off nature of the tape leave a lot of footage "on the cutting room floor" (including salient moments that should never be cut by even 1 second).

https://youtu.be/Dqp3zkumQgQ

Probably a bit of language in it, I shot it and uploaded it one hit so apologies if there is!

Just a very quick and dirty mobile phone video, but I can say with almost certainty it does do something in passthrough mode.

Whether that makes an effective line TBC cannot be determined from this, but signal conditioning is taking place.

Video shows that it does 'something' in passthrough mode.

I also have the unit my collection and have done some testing with some of my test tapes.

But I'm not sure if the device doesn't convert to DV internally, even if you just loop the signal through. Are you using the ADVC controller or the DIP swiches on the unit?

I'm fairly sure this is taking place before DV conversion, however, I can not tell that at the moment.

What I'm feeding it at the moment is of such poor quality, I can not make the determination as the IQ isn't really good enough to work out what's going on!

You could very well be correct, however, that's part of the fun of playing with these things - it could well be a load of nonsense, but at least, on probabilities, we've proven the unit is NFG as a line TBC with evidence and extreme testing.

It may be easier to see if there is DV compression on the output if you send the output to capture card. If there is a lot of noise it should be noticeable.

Are you able to take a photo of the internals? There is a picture of the ADVC-100 on videohelp, showing that it uses a Philips SAA7114H video decoder (same as in the avt TBCs) and a large NEC ic which presumably does the DV conversion and filtering. Haven't seen any images of what the 300 has. Maybe it has a different A/D chip, as at least the SAA7114H does not have line-tbc/jitter stuff built in.

I'm working without access to conventional capture at the moment, I could run it through SDI here but it will add another layer of confusion. I'm in the small office today.

On the 9" monitor I can not perceive a colour difference between A/B with a decent machine, but I'm also aware (through bitter experience) everything looks good on a tiny broadcast monitor. Like the old adage about the HiFi so good, "even Zappa sounds incredible."*

Hmm... Let me have a think about what I can do this afternoon to determine what's going on.

*I'm a Zappa fan, I can take it.

Good call, I'm defrocking her at the moment.

-- merged --

Right, sorry I don't have pictures immediately available, but I believe it's a Panasonic TBC, MN673744. It's fed from the 3D Y/C IC, which is a beast.

The suspected IC datasheet is here.

There's a lot going on in one of these, across two boards.

Full 4:2:2 line (and frame sync) supported by either 16 or 32 MBit (not determined yet) of 'fast' SD RAM. It does output Rec.656 though, which might be where the party ends, but it's been fun to experiment. Datasheet seems truncated so I wonder if there was a bit of protection going on.

I'll dump some pictures and docs' I've found on archive.org when I get a moment.

Interesting thread here -> https://forum.videohelp.com/threads/...BCs-to-die-for Might have saved me a bit of time.

Hmm.. Back to the drawing board.

I used Roland (former Edirol) VMC-1 before and it never looses sync with audio even through static tape noise between scenes. Though never used it as a passthrough the diagram on its top cover shows the passthrough does not involve DV encoding, the signal goes through the ADC, then to an FPGA chip and a bunch of memory clusters and then off to the DAC and analog outputs, Another path goes to the final DV chip and off to firewire port, I don't see why the ADVC-300 should be any different, this was a common design back in that era and makes more sense to avoid multiple unnessary DV encoding decoding therefore more chips and more licensing fees.

The line TBC is weak compared to the VCR one but the frame TBC is the best I've ever seen, Never had any problem even with the bad tapes using a normal Toshiba VCR via composite. I only sold it because I don't want DV anymore, If I've known about this passthrough thing back then I would have kept it.

http://www.digitalfaq.com/forum/atta...1&d=1641677686

Probably.

Nah, there's a lot of gear chip layout variation. You can't extrapolate one from another here.

I also don't think the licensing works that way. It only consider the # of chips, and # of outputs, Anything internal on the boards wouldn't be considered multiple times.

Interesting!

Apparently there is also a switch to route the DV encode - DV decode to the analog outputs through DACs, probably for testing/evaluation purposes

Did not try 300, but I can confirm 100 and 110 both can be used without firewire, you can connect input to vcr, and output of ADVC to some other capture card. I had the same question. It is not a neutral passthrough as robustreviews says, it does "something". But what is exactly that "something" I never had time to find out exactly + I lack material/tapes to test

It does convert analog to digital, apply timing and corrections and convert back to analog, That should count for "something".

A common design means the signal path not the design of a particular product, The common signal path of that era is DV and MPEG chips are always the last in the chain followed by their corresponding ports. If an engineer back then proposed to have something like this: analog input -> ADC -> Timing correction -> DV/MPEG-2 encoding -> DV/MPEG-2 decoding -> DAC -> Analog output, he will be fired on the spot.

It's very (very) good at straightening out timing errors, it's managed to rebuild some rather horrendous PAL signals at least, it's a night & day difference A/B between the unit series and without.

That's only part of the story though, and I'm still trying to determine if it does an internal DV -> baseband conversion as part of the video output. That's indeterminate with my test gear available at the moment, and I do have other things in my life to deal with.

What I can say is, broadly (sample of three people) there's no perceptible colour difference between A/B making me think perhaps this is using the 4:2:2 on the video output? Possibly.

The documented drop-out glitching doesn't appear repeatable for me on the video output, but I've not tested that especially well, 'The Bastard' has a very crude DOC (and the threshold is easily adjustable to bypass it entirely) so it's getting a very screwy mess of a signal.

It would certainly need some explaining. :huh1:

I need to probe around and try and come up with a signal chain for this unit.

DV is a compression scheme, once compressed it cannot be processed as such, meaning when the analog input is digitized for processing and stored in a buffer (TBC, image enhancement ... whatever) it cannot be converted to DV before processing because it would require a super computer to process DV on the fly, heck editing mp3 without converting to wav first wasn't possible until 2010's let alone a video codec.

Now, When the processing is done in the lossless domain frame by frame, Do you still want to encode it to DV and decode it back to lossless and then convert it to analog for analog output? For what reason? you have the lossless stream available already all what's needed is convert it to analog using the ADC.

See, none of this DV processing make any sense at all and certainly not an economical sense back in 2000, DV is the final step for storing the file on tape or HDD to save space, it was never meant for capturing or processing video signals.

This is interesting, and you're of course right. It's unlikely (!) that this unit would go through the stages of converting to DV to then adding extra stages to unpack for baseband output. TBC'ing DV would be daft and wouldn't make a jot of sense either.

The glitching as far as I can see was never determined whether it was an effect of the TBC or synergistically between various stages in the unit.

It would be curious for Canopus to also go to the expense of buying in a high-quality TBC IC from Panasonic (an established player in this), supporting it with good quality components and then not using it effectively. Although anybody who's worked with electronics know that this sort of thing does happen, and there's probably instances in my past where I may have developed things similarly :unsure:

However, I have an 'ology to coin a very old British phrase - my training is in metrology so I only work in shades of uncertainty, any person who'll blindly declare something is 'just so' without any mathematical proof, evidence or comparison can oftentimes be disregarded: I need to experiment as at the moment I can not determine what is going on.

My hypothesis at the moment is that 'The Canopus ADVC300 can be used as an effective in-line field TBC', but it's strictly just that, an hypothesis. My experiments so far indicate that it at least partially can, that's all I can determine at the moment.

Sometimes these interests can extend beyond simple 'x-good, y-bad'. Experimentation (no matter what your technical level) can be a fantastic way to build knowledge and occasionally, somebody will hit on something nobody else has noticed. Whether it's a community of cyclists, bakers or 2CV enthusiasts. I'm a 'ham (don't laugh) and that's one example of a community where experimentation is wholly encouraged.

It could be a massive waste of time, but it refreshes some of my technical knowledge, it's forced me to do a real deep dive on DOCs gaining knowledge I didn't have before and I do adore statistical analysis.

The last probably why various Mrs RR's have come and gone :laugh:

My take on this as I already experimented with the Edirol VMC-1 as it shares some chips with the ADVC-300, they are not good line TBC's, and I believe the ADVC-300 is slightly worse according to this comparison over at videohelp, But as frame TBC's they do work pretty well, As I mentioned above I could let it capture through static between tape sections and it would not loose a second as long as the "Audio lock" jumper is set ON at the bottom side of the unit, ADVC-300 may have that setting in the menu.

And yet, you'd be wrong.

Take certain standards converter TBCs as an example.
input > standards convert > TBC chip

What happens is that the TBC is neutered for any passthrough TBC, ie PAL>PAL and NTSC>NTSC.

Essentially encoding happens before TBC, so you get those extra DA<>AD.

The TBC is for the unit's own post-standards-convert, not as the user's TBC. No line corrections, just frame, video output is as wiggly and crappy as the input. The output is PAL>NTSC or NTSC>PAL, frame corrected for ingest.

If you put the unit into bypass mode, for PAL>PAL or NTSC>NTSC -- an automatic process, you have no control over it -- the "standards convert > TBC" is bypass. So it's a TBC that doesn't TBC.

It's a junk design. And yet, that was as common as anything else at the time.

You can't assume anything in hardware layout.

Even with a diagram, you really cannot assume. I bought multiple standards-convert "TBCs" to see how badly this worked. There was some variation, quirks, exclusions, etc. Some had byproduct uses, others were junk.

@Robust:

The problem I've seen, over and over, with testing the ADVC-300, is giving it limited sources, seeing some corrections of easier or more limited errors, then pronouncing it good. Then other users see the bad advice, find/buy it, give it vastly more varied sources, and it completely crumbles under the pressure. This has been a common occurrence for the past 20 years now.

There's a reason that the ADVC-300 was hated even by ADVC fans in the 2000s. The 300 would actually make video worse, not better. At least the 50/100 (conversations before 55/110 existed) would not rape the signal, just leave it only as ugly as the source, not worse.

No, That's not how those boxes work, and most certainly they are not standard converters. Check the diagram I posted earlier in my post for the VMC-1, it clearly shows the signal path, no blueprint skills needed, Though I've only used mine for capturing not in passthrough so I cannot confirm the audio sync performance in passthrough.

A more simplified version:

http://www.digitalfaq.com/forum/atta...1&d=1641732063

I'm not sure the point you're trying to arrive at here. I'm not sure what the discussion of standards conversion really has to do with this? I might be a misunderstanding.

I can only test one for myself and post up what I find. My methodology (as shown in the video) includes feeding it something far worse than could reasonably be expected for even the most sicky source. I can only test what I have in front of me. I'm about to abuse the living snot out of it with random line jitter just to see what happens. It's not impossible it's better at correcting gross errors than milder ones; again I can not determine this yet.

There's also more to a TBC than jitter correction, but it's as good a place as any to start.

I think if you think I'm feeding it 'gentle' corrections, you've misunderstood some of the tests I've proposed or have carried out.

I can't say anything yet as to my results, my point above being I'm working from a hypothesis. This doesn't say it has any merit in a signal chain, merely sometimes it's fun to experiment. My suspicions were aroused when I saw it do something rather interesting a few days ago.

I'm just capturing more for analysis, I'll update later.

Interestingly in the thread posted by latreche34 there seems to be some confusion over TBCs vs. DOC which is a different concept as most of us know. DOC has been almost standard on most machines since the 70s for line repetition (y'know, things did get processed in the analogue domain, occasionally that gets forgotten) - I have a copy of that book mentioned somewhere in the office, I'll try and clarify as to what they may have been trying to arrive at?

Analogue television could not work without the ability to 'hold' a line.

It could well be junk - I've made not a single value judgement regarding the quality of the unit.

We're not referring to the same exact boxes. You're referring to Roland/Edirol, I'm not. That was my point. You cannot assume/extrapolate all devices work identical because one works a certain way.

The point is as above. You cannot assume that devices all act the same, because there was (and still is not) some universal spec, or majority agreed-upon, or even common sense specs. As per my example, sometimes devices do not consider you, the end user, but rather it's own internal needs.

I've yet to see an ADVC-300 diagram, and data flow pathway. It's completely within reason for the device to input, piss-poor timing correct, throw to the DV converter, and then output that to either the analog output (D>A) or to the Firewire. After all, that's how many (not all) of the DV cameras work.

And I'm not either. My only point here was to not knee-jerk post results. I've seen far too much of that over the years, concerning this exact device. I wouldn't be here reading your posts if I wasn't curious to see what tests you're creating, and the outcomes of those tests.

Right now, you have more time that I do, otherwise I'd join in. :(

I don't see it that way. I see it more as the ADVC-300 making the situation worse.

The vast majority of us have already come to that conclusion, and more do on a regular basis. Quite a few people are seeing the flaws of DV conversion on their nice large HTDV, and are now redoing projects as a result. The ADVC devices are a common mistake. Very often, they see the errors, but not sure where or why. I'm usually able to help them see where they went wrong. And on follow-up, a lossless non-DV redo job (often with a better VCR and TBC) was all they needed.

- The color issues, gone.
- Compression artifacts, gone.
- Video oddities and bothers, gone.

If any "standard" exists, it's that DV is craptastic, and the boxes suck.

FYI, I tried to DV box passthrough idea years ago. It's a no-go, on any model under that has MSRP under $500. Not sure about the higher end boxes, but doubt it.

Might have had a breakthrough lads.

There's a AD7173 ADV7173 (I feel silly for not noticing it) in the chain for the video-passthrough.

That's REC.656 -> Composite and Y/C.

Thankfully it has test points and there's a pinout available if you dig around. I can't see what feasible other purposes it might have in this application other than to take the REC.656 encoded after the TBC and then feed it out the outputs.

It makes far, far more sense than an illogical double-DV operation, that's for sure.

Hopefully, we can just put this DV thing to bed shortly. There's a long way to go but it might eliminate that 'noise' in the experiments.

The way those Rec. versions work is that every time they add a feature or a function they change the Rec. number, For instance Rec.656 adds component for devices equiped with component connectors such as DVD recorders and DVRs, But they are still based on the Rec.601 for basic 525/625 4:2:2 SD standard. Here is the version history of the Rec.656 over the years.

The analog out "through" going via DV could maybe make some sense when a device can go from both analog to dv and dv to analog. I seem to recall someone mentioning analog pass-through on the on the Sony DSR11 DVCAM deck having DV compression on it. Though that's an older device and may have had separate ICs for encoding/decoding etc, may not make as much sense on something more modern with more stuff consolidated in the same IC. Some of these dv boxes were bi-directional but I don't know if the ADVC is. If it's not putting in a DV->rec 6xx decoder wouldn't have much purpose.

That's a good thing to bring up.

It's a bidirectional device, however, I think this is almost certainly doing the REC.6xx to video-out, there's no reason it couldn't serve double-function anyway.

I can't confirm yet, but it certainly looked like I managed to fudge a PAL encode with NTSC video-out simultaneously, clearly it was junk but on my PAL CRT but it didn't affect the encode. I need to double-check that though as I'm very tired and I may have been shorting something else out.

I have a couple of DSR-11P's (and DSR-20Ps, and a DSR30P editor), I have experimented with them in passthrough and I've found them all equally poor even as YC->DV devices, I can't get the 20Ps to capture for more than about 30 seconds without losing the plot. That wasn't what they were designed for though and it's something I've never experimented with further. They're fantastic players though. My other DV standard machines are SDI which we've almost exclusively switched to.

Anyway, back on topic. More to look at in the coming days.

Hodgey, If you remember NLE software from back in the day such as Premiere and Sony vegas, have you noticed the "Print to tape" function? It was meant that you could get the footage from your analog deck into premiere via a DV converter box, premiere would decode the DV footage, do the editing and corrections and then encode it back to DV and then print back to analog tape using the same firewire port but in the reverse direction so the DV box would decode the DV footage from premiere and convert it back to analog for recording on the tape. That was the only case an analog input would go through multiple DV processing that required an entire computer with NLE software. Alternatively you could save the footage on a DV deck connected to another firewire port on a DV tape and that halves the quality loss since there is no going back to analog.

It was a cheaper and dirty way for prosumer crowd such as schools and hobbyists to edit in the digital domain without investing in pro gear, I've seen VHS dubs that used the DV workflow and it was yacky. So it was nowhere near the quality of a Betacam workflow used in pro studios with SDI ports.

Later on "Print to tape" used for importing DV and HDV tapes into computer for editing and send back the edited footage to DV/HDV tape, I've done it myself using Vegas Pro with Sony HVR-M15AU.

So the point is a DV box that size and in that era did not have the processing capabilities to pass an analog signal through multiple DV encoding decodings without using a computer and a software, If the firewire port is not connected successfully to computer and comunicating with an application, the DV chip is turned off and the signal path is going through only the ADC - processing unit - DAC.

I was hoping RobustReview would upload some pictures of the disassembled ADVC 300 to save me the work of disassembling mine.

I think it might be of interest to some so I opened mine up.

You should be able to see everything except the chip under the fan which I haven't disassembled.

On request I can upload more pictures.

High resolution pictures in a zipped folder will be nice, I can't make out numbers from those low res pictures.

I'm spotting a NEC UPD64011BGM Video decoder IC at least, and an empty slot labelled uPD64031 (which seems to be a ghost reduction chip of some sort, maybe the board was also used on something that featured a tuner). So, it's NEC-based, rather than using a panasonic chip it seems, maybe the line-tbc function of it is similar to what found in NEC-based dvd-recorders then.

The video decoder IC can be found in various TVs, and the Toshiba RD-XS32 dvd-recorder, and probably a bunch of other things. It seems to be part of NECs 2nd gen ENHANCED MULTIMEDIA ARCHITECTURE (EMMA2) setup used in various dvd-recorders (i.e newer Pioneer/Sony and some toshibas), tvs etc, though newer devices seem to have bundled the chips together in a larger IC.

Guessing the large IC with fan on could be a FPGA or maybe something akin to the μPD61171 I linked which is the main IC for the NEC setup.

Also spotting:
NJ W1141 audio processor.

NEC D485505g which seem to be memory.

703212YG - probably UPD703212YG microcontroller

Several EtronTech chips which are probably memory but can't make out the part number.

Something that looks like an analog devices chip, guessing it may be audio ADC?

Rest is too small to make out. The ones with legs on one side and a metal thing on the other side probably voltage controllers.

The forum will downsize images if you put them in a post and they are over a certain size so you would have to put them in a zip as suggested to get higher resolution.

Apologies, I do have some sharp high-resolution images, I'll upload them when I'm back at that office.

The Panasonic TBC chip sits parallel with the RAM on the daughterboard, it's not especially clear in this photograph. It sits directly underneath the BB5M sticker on the grey pad.

Underneath this board is the (compartively huge) Y/C filter IC ASIC, this was an NEC flagship (!) or so the marketing seems and as it's application specific it's difficult to find out much information about it. I guess it's using the other RAM IC for 3D integration.

Ah didn't look close enough but yeah there is a MN673744 on top of the sub-board, which has been noted before on videohelp. Wonder why it would have 2 video decoder ICs then, maybe the NEC video decoder chip is set up to take digital input and used for noise reduction or something else.

If you look at the datasheets, there's a lot of things duplicated in here at first glance.

Just about every video IC claims some sort of TBC, but usually, in the crudest sense, there's a range of decoders and encoders in here. I need to get the datasheets out and a 'scope and start probing around in here to try and work out what is doing precisely what. I know you appreciate it though, it's not a ten-minute job. Even then it relies on a bit of guesswork.

The Y/C filtering judging by the 'horsepower' behind it should be immense on these units. I've seen it work as an effective passthrough TBC but we need to check it's not dumping DV back out of the input. I'm struggling with eyesight at the moment and some close-up examination of details is tricky so I can't determine wholly by looking at a small CRT at the moment :depressed:

From this post it looks like it is not far from the VMC-1 I use to have, Though as I mentioned previously line TBC function is not as good as a full fledged line TBC from a JVC VCR, But as far as audio sync and frame problems, none for the duration I used it. I wish I still have the unit so I can test the passthrough mode.

What I like about FPGA boxes is that they don't rely on computer CPU to convert the analog video to digital and stabilize it (or encode it in case of DV and MPEG2), It's all done inside the chip, all what the computer does is collect the stream and store it on the hard drive, whether it be DV over firewire, MPEG-2 over USB, lossless over firewire or lossless over SDI. Though this is not new, future capture devices should go back to this architecture using USB 3.0 for trouble free capturing, not a cheap design but better than a software/CPU under Windows 10.

Here are the pictures in 7zip folder.