Canopus ADVC-300 passthrough line TBC?

[latreche34]

Quote:

Originally Posted by RobustReviews

It would certainly need some explaining.

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.

[RobustReviews]

Quote:

Originally Posted by latreche34

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

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

[latreche34]

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.

[lordsmurf]

Quote:

Originally Posted by latreche34

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.

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.

[latreche34]

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:

[RobustReviews]

Quote:

Originally Posted by lordsmurf

And yet, you'd be wrong.

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

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.

Quote:

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

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.

[lordsmurf]

Quote:

Originally Posted by latreche34

No, That's not how those boxes work, and most certainly they are not standard converters. Check the diagram I posted earlier

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.

Quote:

Originally Posted by RobustReviews

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.

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.

Quote:

I can't say anything yet

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.

Quote:

there seems to be some confusion over TBCs vs. DOC which is a different concept as most of us know.

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

Quote:

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

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.

[RobustReviews]

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.

[latreche34]

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.

[hodgey]

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.

[RobustReviews]

Quote:

Originally Posted by hodgey

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.

[latreche34]

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.

[Bogilein]

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.

[latreche34]

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

[hodgey]

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.

[RobustReviews]

Quote:

Originally Posted by hodgey

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.

[hodgey]

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.

[RobustReviews]

Quote:

Originally Posted by hodgey

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

[latreche34]

Quote:

Originally Posted by hodgey

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.

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.

[Bogilein]

Here are the pictures in 7zip folder.