Dazzle DVC107 video decoder chip info wanted
 

Hi everyone,

Does anyone know for sure which analog video decoder chip is used in the latest Pinnacle Dazzle DVC107?

I have read that some versions of the Dazzle Video Creator Platinum use the ADV7180 chip, which has a very nice feature called "Adaptive Digital Line Length Tracking" or "mini-TBC" which can help stabilize analog video.

Pinnacle haven't been any help (no reply).

There's no way that a TBC will be inside such a small and cheap device.
The Dazzle devices have not really changed much in the past 6-7 years now. Only the Studio software really has.

Maybe you should have a read of these then...

This page mentions the Dazzle Platinum using the ADV7180: (but not the DVCxxx version)
http://www.hardwarest.com/product/Pi...num-34899.html

The ADV7180 datasheet is on this page:
http://www.analog.com/en/analog-to-d...s/product.html

This is an application note regarding the "ADDLT" "mini-TBC" feature:
http://www.analog.com/static/importe...7357AN_850.pdf

I'm trying to find someone who actually knows what chip is in the latest DVC107, not conjecture about what it could or could not contain.

If you think about how TBC works, it makes sense to put the TBC function into the capture device.
Why? Several reasons:
1. It avoids the need for an additional conversion from analog to digital and back
2. The capture device has direct access to the sync pulses
3. The capture device has control over it's own timing of when it samples the video
4. The capture device feeds it's output into a RAM buffer, isolating the output timing from the input timing
5. It's the cheapest solution!

I reviewed one of these in 2009. It did nothing at all to help clean up VHS tapes. It looked awful.

- Do you have any idea how many devices have claimed to have "TBC functionality" in the past decade?
- Would you like to guess at how many of them actually had TBC-like performance? (Hint: It's a round number.)

Pay close attention to the exact word: "TBC functionality" -- not a TBC. This is the kind of literary trickery you find on kids cereals, where it lists out the health benefits of eating sugar for breakfast. This is going to be another case of timebase correction being used as a marketing term, instead of actually referring to a real TBC.

Note the actual description:
Lots of companies have made claims of patented proprietary technology that acts like a TBC -- yet it's not a TBC. Why? Well because a TBC costs money to manufacture, and takes up space. Bigger and more expensive is rarely on the wish list for consumers buying consumer devices, which is what this is.

Canopus used to insist the ADVC boxes had a "TBC", but you saw no visual proof of it. Wiggle wobbly video input came out just as wiggly wobbly as it went in. Same for chroma noise splotches. If there's a TBC inside, it must be broken or asleep.

I addressed this concept of fake TBCs in the TBC FAQ: http://www.digitalfaq.com/forum/vide...time-base.html

Oh dear.. The arguments are starting and we still haven't even found out if the Dazzle DVC107 contains the ADV7180 chip yet! :) (which is the reason I started this thread)

I would like to read your review of the DVC107 lordsmurf, is it available online? Are you really saying that ADLLT is some kind of useless con and doesn't offer any benefit on typical VHS tapes???

Isn't it amazing how good the TBC performance of some MiniDV cams is.. which is what got me thinking about this subject in the first place. I wonder what chipsets they use?

My point was: There is nothing you can do in a stand-alone TBC that couldn't be designed into a capture device. Basically it's resampling the video to correct the timing jitter (there is even someone working on a SOFTWARE TBC). You could look at it as a type of unwanted Frequency Modulation of the video. All that's needed is an inverse type of FM to undo the "wiggly wobbly" part. With modern ICs it doesn't have to be big or expensive to do the job. Whether a particular manufacturer of a capture device can get their hardware and software working together to make it happen is a separate issue altogether.

I am still looking for the answer to my original question (in case anyone reading this knows): Is the ADV7180 video decoder chip used in the latest Dazzle (Platinum HD) DVC107? At this rate it looks like I will have to actually buy one before I can find out...

I don't know if the Dazzle DVC107 contains this specific chipset...

... but I do know that the Dazzle unit has no TBC functionality whatsoever. "Enhancing" video was hyped on the box, but it was a dud in reality.
The full review is no longer online, but I do have an editor draft of it. Here's the important excerpt:
The software TBC is being worked on by a member from this site (jmac). He's on this site plus at least two others. I've submitted research samples to him, so he can try to perfect the software TBC. It's a nice start, but it still has a long way to go still. And it may never work out properly, though I'd really like to be wrong here. The major problem is that the analog signal timing is lost by the time you get to software, so you're having to guess at timing based on visual content errors. And that gets tricky.

Another site online claims that the DVC107 contains the Empia chipset, which is also found in the EasyCap devices. Now that would be more believable, as the quality from both of those units matches up pretty well.

Looking back at the spec sheet one more time, the ADV7180 appears to be a television decoder, not chipset used in capture cards or recording devices. Though I still have doubts about the qualified term "TBC functionality" instead of simply stating that it has time base correction.

Yes, some DV cameras do have very impressive TBCs. Some do not. The same can be said about S-VHS and Hi8 video cameras, too. However the presence and quality of TBCs in cameras varies quite a bit. Much like the suggested VCR list maintained on this site, there are definitely lists of preferred cameras for this same reason. (Those lists area also floating around this forum, thanks to NJroadfan and some others who post here.)

I also don't think anybody is arguing. Just giving input. :)

Hi AusDaz,

I believe lordsmurf is right on this one, and that the Dazzle DVC107 uses the Empia 2861 chipset.

ref.

• VideoGlide's software page -- software only works for Empia 2861 products (which includes the EasyCap DC60+ and Dazzle DVC107
  http://www.echofx.com/videoglide.html
  
  
• Dazzle DVC 107 Question on Se7ensins Forum -- pls browse the whole thread
  http://www.se7ensins.com/forums/thre...estion.447613/

Hi lordsmurf,


I also saw this 2004 factsheet on the Empia 2860 chipset which describes a clock, sync and field ID generator for the Empia 2860 chipset. Would this sort of qualify as some kind of TBC (in the sense of synchronising video and audio out-of-sync issues), but not necessarily that of fixing "video tearing" issues like a Panasonic DVD recorder might? (ref. page 3 of 2004 factsheet, http://wenku.baidu.com/view/0ce94f1a...1b90dd8e3.html)

An updated factsheet and Windows 7 drivers can be found here. (ref. http://home.eeti.com.tw/web20/pdfs/2...TI_2008_VA.pdf + http://home.eeti.com.tw/web20/eg/IC_support.htm)


Cheers,
Stephen
Singapore

Hi Stephen,

That chip performs a different function.

The Empia 2861 chipset is a USB 2.0 interface chip used by many capture devices. It's the chip that handles the data flow from the capture device to the PC.

The chip I've been talking about (ADV7180) is a multistandard video decoder + analog to digital converter (ADC). It decodes the analog PAL/NTSC/SECAM colour signal and digitizes it. There are also other chips in a typical capture device for audio ADC and hardware MPEG encoding (and possibly others still).

Daz

Hi AusDaz,

Sorry, this is beyond me then.

I had the impression that the price difference between an EasyCap and the Dazzle is mainly due to branding and software bundle, not to additional or better hardware.

Perhaps you can try corresponding with the developer of the VideoGlide software to see if he has any knowledge of the presence of the Analog Devices chip, since I would imagine the presence of the chip in the video processing workflow would affect the video that his software is able to capture (especially if it is written specifically to address the Empia 2861 chip).

You might also like to note that Avid has just announced that they will be selling their consumer business (including Dazzle) to Corel. (ref. http://www.avid.com/US/press-room/Av...nes-Operations + http://www.photographyblog.com/news/...ting_products/)


Cheers,
Stephen
Singapore

I agree with AusDaz - in fact, the chips in "real TBC's" are just the usual video deccoder chips that are also found in other devices like tv's, camcorders, digital recorders, and yes, capture cards*. Maybe some of these chips work better than others in their TBC aspects. I also have no doubt that a capture card can do the "line TBC" function as defined by Mr. Smurf.

I've created a test video that allows me to independently re-align video via a mathematical equation, when I captured it, I could measure the resulting line jitter. I got +-.5 pixels on the left side and +-.25 pixels on the right side; in other words the capture card functioned as a line TBC to an accuracy of less than 1 pixel.

Mr. Smurf seems concerned with other important problems such as vertical jitter and flagging. I take his word for it that a capture card doesn't fix these problems. However it's true that I've made a software "line TBC", and also I've been able to capture the synchronization signals with an ordinary capture card, so the horizontal timing information is NOT lost. I've just turned this into a plugin if you want to test. The vertical jumping I believe I can fix in software too. The flagging, and improved quality of line TBC will be much further in the future, but I have a proven algorithm for it (just need to write the plugin).

There's also capture cards that allow full, raw capturing, including all timing information, so if you have a supported card, it would be possible to make as "real" a TBC, even a BBC PAL decoder or PalPlus decoder, as you like in software. There is a lot of research into these cards because of the software project GNURadio, which is looking for cheap hardware to digitize radio signals (and a tv capture card is perfect for that!). They found that some chips have a test mode which captures raw signals, like a Digital Storage Oscillscope.

There is also a question of semantics in this disussion, in agreeing on what a "real TBC" does, but I agree with Mr. Smurf that the capture card won't fix *all* your possible problems in capturing.

Software TBC beta
http://forum.doom9.org/showthread.php?t=162726

3MHz Digital Storage Oscilloscope or Software Defined Radio for $20!
http://sdr.osmocom.org/trac/wiki/rtl-sdr

*This is off the top of my head; I just recall reading about the chips in a TBC device and recognizing the chip, and a few other instances of trivia I've come across.

ps if you do a patent search, you'll eventually find this "patented ADLLT algorithm", and you can read a full disclosure of how it works. If you find it, I can probably tell you what's innovative about it. However, most chips have something like this anyhow. They sample the line more than they have to, find the two endpoints, then resize the pixels in-between to a standard length, just like I do in software. No more than a bicubic resizer. The innovation mgiht come from missing sync pulses, or severely distorted ones, maybe they make a good guess about these.

I didn't think that had yet been agreed upon. The visual sync lines are still wibbly-wobbly even after correction of the image. This has been a concern of mine since the start of the project, and both johnmeyer and sven_x mentioned it early into one of the doom9 threads. Ghitulescu also pointed out the physical tape warping effects that a hardware TBC has to overcome, and that does require more than realigning the lines -- now digitized into pixels, when a video file is the source -- though I think you have addressed that aspect.

(Ghitulescu and johnmeyer are two people that I've been in contact with multiple times in the past decade, often with discussions that headed into advanced and theoretical video topics. Ghitulescu is also a member here. Definitely not dummies.)

In terms of real-world application, I'm not yet sure how your software TBC is going to work. So far, it seems that the filter requires atypical data be captured (sync), using an outdated card chipset. But if somebody still has the tape, running it through hardware TBC would be ideal. The software is also not realtime, like hardware-based solutions.

The primary demand for a software TBC is for situations where the initial capture was lousy, and the tape is now gone or unavailable -- Youtube clips, bad DVD conversions, nth generation tapes where sync errors are now embedded. Such a software TBC would have to rely on image information, likely a retained overscan that shows image content borders.

Wihle a good software TBC could complement a hardware TBC, I'm not yet convinced software could replace hardware, nor that it does just as good and thorough of a clean-up job.

Anyway, you know I support you on this project, wherever it ends up. :thumb:


Also PM me whenever you're ready for that thing we've talked about. :)

Thanks for your efforts Steven.

Yes, I was aware of the company changing hands.. What bad timing! (is that a TBC joke?) Maybe that's why I'm having so much trouble getting an answer from them..


Hello jmac,

I have been following your software TBC project with great interest. Well done! :)

I will check out your TBC plugin, but I will need to find a way to capture with syncs using my existing card (HVR-2200).

Sounds like you already have (or are developing) a good knowledge of DSP. Nice to see you measuring your results also! Great stuff!

Software Defined Radio (SDR) is a future project of mine.. I'm also wondering how hard it would be to use SDR techniques to demodulate signals from a VCR head amp like juhok mentioned to you about 2 years back.. I can just imagine finally getting some good video capture hardware working, then immediately it's made obsolete by "software capture".. :)

There is an example in the ADI Application Note AN850, page 5 (the link is in my 2nd post) of the ADLLT process totally fixing flag waving on a video frame. Vertical jitter is probably caused by loss of vertical sync, or loss of horizontal sync over a longer period. An intelligent capture device (or software TBC) could just ignore the corrupted sync pulses and keep capturing using it's current timing until the sync returns. This takes decision making logic to accomplish. ADI claim their process is tolerant of corrupted syncs - I am looking forward to seeing it for myself (if I can ever find a capture device with their chip in!!!).

If there is disagreement on where the Hsync is:
The Hsync pulse looks like a blacker-than-black vertical bar. Even though it denotes the beginning of a line, it's actually closer to the right side of the picture than the left, and the sync reference point is ONLY taken from the leading edge of the pulse (the left side, going negative).

You can see it in the AN850 document mentioned above.

Daz

You're right on, I agree. It has one main use case, where you can't get the original tape anymore. Otherwise, buy some good equipment and do it properly. The technique with the obsolete card was useful for me for testing and education. There are in fact modern versions though, and I'll be ordering one to test with. What this would mean, ultimately, is a hardware/software combination that costs $20 but can theoretically do anything a "real" TBC can, depending of course on my software skills - and I'm not promising anything here!. So I am convinced it is *theoretically* possible.

There is one part that you are out of date upon. In my initial experiment I found this light green line that I tried to line-up with. It turns out, this wasn't HSYNC at all, but an artifact of the AGC controls. I did eventually find the real HSYNC signal, and by capturing to NTSC-J (the Japanese version, which has black level setup), the start of the video was unmistakably clearly marked, even if it was pure black.

I have some more ideas I won't get into, but there's definitely hope for a quality improvement, and a wider range of use cases in the future.

If my skills improve to the point where I can hack Linux drivers, I could probably make any modern/popular card work on the capturing end, as well. I could put the whole setup on a USB stick and you would have to boot with it, but it would work.

Oh - as for real-time, that can be done too, there is a way to capture with my TBC in real-time but I have to write up instructions for it. This is a new ability, since I just made a plugin version which is fast enough.

AusDaz,

Yes I got the sync, you can see it here
http://screenshotcomparison.com/comparison/88810
It's NOT the green line, but the black bar. I don't have the left edge, but I'm assuming the right edge is fairly consistent. I forced the video to be LIGHTER than black by using setup, with NTSC-J. I increased the brightness to clearly distinguish blacker-than-black, and captured values above 235 so there's no loss of dynamic range.

Yes that Swedish company's results were amazing, I wonder if that's just from a straight digital demodulation? You'd need about 10Ms/s, the FM luma varies from 3.4 to 4.4 MHz. You could downconvert that to about 1MHz of course, but then there's color at 740KHz and audio at 1.6MHz or so. You could do much better tracking and know precisely where dropouts are.

As for flagging, I agree it's probably missing sync, guessing where it was could be done in software with motion estimation, but also I've found that jitter followed a close normal distribution so you could guess that way - however, I think the main problem with flagging is the VCR trying to compensate so you'd need a model of how it does this and undo it. That's easy to find, if you can get known material with a flagging problem then find the exact flagging against the DVD version.

Anyhow I'm sure their method is just normal engineering and putting some work into analyzing the problem, the same as I'm doing.

jmac,

I actually meant missing/damaged sync could cause vertical picture jumping. Most minor vcr picture instabilities are probably caused by unwanted tape movement or deformation/stretching (not counting dropouts, loss of signal etc).

You should find that locking to the left edge of the Hsync pulse is more stable. That's the timing reference for the hardware, and pulse widths can change due to black clipping, non-linearity and bandwidth limitations - causing the right side of the Hsync pulse to shift depending on video conditions. It might be easier to capture the left Hsync edge on the RIGHT hand side of the video, then work backwards. Getting the most accurate sync will be especially important if you go for better sub-pixel accuracy - but that's when things will REALLY get tricky...

I seem to have an answer to my original question..

A reply came in on another forum showing that the Dazzle DVC107 does NOT use the ADV7180, but instead uses the older SAA7113H. The link is here. This might explain the poor performance that lordsmurf found with unstable video timing.

A Russian forum mentions the ADV7180 is used in the older DVC130 and DVC170 models, but they have no 64 bit drivers (which I would need).

Still no answer from Pinnacle or Avid, but I have made new enquiries, and am looking for another capture device featuring the ADV7180 or similar.

That's really the catch ( 64 bit), some of the older cap cards are superior but no way to run them on
today's more powerful computers. I remember seeing a TBC PCI cap card but I forget who made it, it probably
wouldn't work with 64 bit.

Actually it is the Datavideo card and perhaps it will work with 64 bit but I am sure it has a steep price.
I had a memory jog so decided to edit.

Oh, there's a way around that!
Virtualbox lets you install 32bit drivers and run them in 64bit. It allows access to the PCI bus.
This is pretty advanced virtualization tech.
Ironically, you need a high end machine to do it, because it requires a CPU with virtualization extensions, so you need an i7 or so.
Give it a try! www.virtualbox.org

Some new information has come in..

From another forum I am told that:
The Hauppauge Colossus uses an ADI chip that has the ADLLT feature. It is advertised as having TBC.

And I just received a reply from the Australian BlackMagic Design distributor, confirming that their Intensity Pro card uses the ADV7180. Though they tell me it doesn't handle timebase errors well, and they recommend an external TBC! That's disappointing! Sounds like it's been configured for very stable professional equipment.

That's kind of what I figured.

Most of these so-called "TBCs" are really just filters with minimal abilities. If you feed a typical timing-damaged source into it, it fails, or it makes only minimal corrections. That's why you really have to be careful with anything that claims TBC functionality.

There's things like this in every industry. In the web hosting industry, it's the loosely-used term "cloud" to describe hosting or file storage lockers. While "TBC" and "cloud" were both terms initially created for a very specific type of hardware setup, others have taken extreme liberties in how it's used. People most often learn about these false claims and fudging of facts after they've parted with money (or tragedy has struck).

This site is more concerned for its readers and users, and will warn others of potential problems. We won't just reply with "Oh yeah, works great, here's a link to go buy it!" like you tend to find elsewhere online. Hence the occasional accusation of "negativity" when Site Staff try to warn others about potential issues with various hardware and software. We consider ourselves to be consumer advocates, to some degree.

Glad you found this out without having to buy something. :)

I am curious about these HD cards as I might buy one sometime in the future but would like to hear input.
Certainly the Colossus if it has a form of TBC would make it attractive for old video captures.
It seems the most popular are the Avermedia PCI version, the 1212 and perhaps the Intensity.
Anyone care to go into detail about the +s and -s of each card to provide intelligent info?
For myself I am more interested in their high def. abilities.
It appears the movie industry has killed any chance of us having a decent Blu-ray recorder (here in US).

I'm curious about them too.. Anyone know how well the Hauppauge Colossus does with timebase errors after you enable it's TBC option? (I'm getting burned out from constant searching)

kpmedia:
I'm more inclined to believe component manufacturers (who supply copious data) than some product manufacturers. Still - not many capture products I've looked at claimed to have any TBC function.

I guess I'm approaching this from an engineering point of view, rather than a user point of view... I've even considered building my own capture device (don't laugh) but high-speed data interfacing and writing a software driver is not trivial... Also the DIY approach often turns out being a lot more work than first thought.

That actually sounds quite interesting. :thumb:

I think the biggest problem is when manufacturers don't pay attention to the needs of users, or they somehow think users are stupid, and will buy into hogwash marketing. From my observations, Canopus paid dearly for blowing smoke up customer's butts (or attempting to do so), and have lost market share in a number of arenas as a result. In fact, the only time I really hear anything about Canopus is when the parent corp (Grass Valley) does a broadcast install at a college or university. Case in point: the so-called "TBC" function in DV converters boxes, which does absolutely nothing.

What's equally sad is when quality components are made, and not well utilized, or used only by inferior manufacturers. LSI Logic chipsets were underused by virtually everybody but JVC. All DVD recorders should have been based on LSI, as it was superior to pretty much every other chipset save Zoran (which lacked chroma NR, but was otherwise excellent).

I've considered this as well. The main problem is the high data rate. It would require FPGA technology. It would take some time. I think the simplest approach is a decoder chip, fpga, and SD card.

But I've found that there's cheap ways to digitize raw, high speed signals that I could process in software, which is good enough for me. Soon I might hack apart a VCR and try to decode the raw signal.

But if you ever want to collaborate on an open-source hardware capture card, let me know :)
I can program an FPGA and am pretty good at the video standards.

If either of you want to chronicle projects, we'll open a special developer section here on this site, where you can do that easily.
I want to bring more advanced video users here to this site, as it's a shenanigans-free professional environment.

And we'll help you manage the pages, so you can spend your effort on the actual development of the tech.

I have often wondered why this hasn't been done on a much wider scale, think of the opportunity not only to learn but for advancement in creating useful software.
Too bad too Manufacturers would likely not be willing to divulge old technologies.
Some TVs have very effective filters...I am surprised no one hasn't figured a way to intercept
outgoing streams then put them "inline".
I would imagine they might even frown on consumers learning to salvage.
Then what about upconversion....

Zoran had its on fair share of issues related to their MJPEG codec chip and capture devices. namely, they refused to support them at all and didn't bother to assist manufacturers that wanted to write drivers for newer OSes for their products.

Honestly, I just wanted to digitize some old tapes, not start a revolution! hehe :)

jmac & kpmedia:
Thanks for your generous offers

Steve(MS):
Video tape recording technology is well known - The main problem with the software VCR demodulation approach is it uses a huge amount of processing power.

jmac:
Not sure if I really want to take on so much work, but it sounds interesting. I was thinking of a PC interface, first FireWire (then I read it's "complex and convoluted"), then USB2 (maybe a bit too slow, but development boards are available), now PCIe... I've never worked with FPGAs but they are very powerful devices. I figure the data rate is just over 31 megabytes per second, for RGB24 video (there might be better choices).

As for digitizing from a VCR head amp, there are actually 4 outputs.. 2 from the video heads, and 2 from the hifi audio heads. You could use the headswitching in the VCR and halve the number of signals, but then you lose the option of overlapping DSP demodulation and glitchless baseband switching. Either way it's a lot of data. I'd guess about 12 Meg sampling for the video channels and about 4 or 5 Meg each for the sound might be just enough. The frequency response of the heads is not flat, it may need EQ before you digitize.

In DSP many deluxe features become available, such as glitchless headswitching for video and sound, dropout concealment, better linearity, better filtering, and demodulation that can reject noise. Oh and yes - software TBC! Or should it be called "Picture realignment" when it's no longer analog? :)

PCI Express is long in the tooth, and was really nothing more than a video gamer's expansion of AGP. It didn't do a whole lot outside of graphics cards used for playing games. I'd instead look at USB3 or straight ethernet appliances. (Thunderbolt is more proprietary Apple hardware, and that means 3 things: expensive, complicated, future unknown. Otherwise I'd have mentioned it, too.) Remember that most broadcast hardware works over ethernet now, not inside computer towers. SO much, in fact, that broadcasting subjects are now dominated by networking details.

I actually liked your assessment of failed TBCs over at VH: "it won't be able to follow the rapid timebase errors from typical VCR video. So people may think the TBC is useless when in fact it is just too slow for their purposes." ... which comes from an engineering outlook, of course.

Though to repeat what I wrote there, "I will accept this theory, but reject the conclusion. If it doesn't perform to the expected norms, I don't think it should be considered a TBC. I've long held this belief with hardware from Sima and others. Too much confusion is caused by people looking for effective TBCs. I often think it's intentional deceptive marketing."

You also make a good point on the "software TBC". Since timing does get lost on typical digital files (excluding jmac's driver hack), it very much is a picture realignment process. But I'd still give some leeway on the name, since it provides the desired TBC functionality.

I think we've had a great conversation thus far. :)

lordsmurf:
I've enjoyed all the discussions - they've been very informative. Great forum you guys have here.
I'm glad you've enjoyed the conversations also - it didn't seem that way at first! :)


Well, I've ordered a Hauppauge Colossus.

I was able to order the card locally online, but the retailer doesn't stock the s-video adaptor cables for the Colossus. They are a special input adaptor, Hauppauge model number 6021291

Hopefully an s-video to 2 x RCA patch lead (Y/C) will work with the existing adaptor cables. Otherwise I'll have to order the Hauppauge s-video adaptor from somewhere.

Do let us know how it works out.

Hi AusDaz,

I took a look at the picture of the special input adaptor and find it interesting that the cables leading to the adaptor look really skinny.

I mean, we can use Monster-quality RCA or S-video cables out from the tape deck or TBC, and then for the "last-mile" before the recording chip, we have to run the signal through a skinny little and probably unshielded cable?

Or does the quality of the cable not matter that much for such a short distance?

(The same thing can be said about the AV-cable adaptors for the year 2010 models of Samsung LED TV's. The skinny breakout cables just don't seem very appropriate.)


Cheers,
Stephen
Singapore

I've actually tested cables. First, I've seen some tests of cables with high-end equipment, and yes there's measureable differences. In fact there's some very special bridge type procedures for measuring impedance. However, over short lengths, I've found only one slight difference.
I used a sensitive measurement program http://audio.rightmark.org/index_new.shtml
And various cables, some expensive and some cheap. The worst condition was many $1 cables put together with adapter plugs, and loops around a power bar, along with a dozen other cables behind my desk.
I tested with an XFi external usb soundcard in 24bit.
There was no measureable difference, except in the distortion test if I coiled the cable.
That's it.
No hum was picked up.

My guess is that the main use for good cables is over long runs, like on stage for audio or to a ceiling home video projector for video. I've also seen sparkle coming from a cheap HDMI cable.
There's other factors which are important though; the plating material used makes a difference, because of the effect of two metals bonding together, and because of corrosion. There's the possibility of breakage when repeatedly bent. The firmness of the plugs. Being properly stored without a twist in them, and so on.
But for me, $1 cables work perfectly fine and out of some 30, I've only got 3 bad ones over the years.

Note: your skin has acids and salts which can corrode.

Uhh.. What he said! :)

Such a small length of cable won't make much difference, unless there is something seriously wrong with it. The frequencies and impedances used in SD video cabling are low enough that they don't make much difference for short runs (HD uses would be more critical, but I have never used HD analog). But the cables should be real coaxial cables (75 ohms), not just shielded cable (though you can get away with using that if you're stuck).

Expensive "super" cables are mostly just a gimmick to part you from your money.

The most likely problem with such a thin cable is that it will eventually break (especially if it has a heavy cable hanging off it).

While thin cables should not be an issue according to theory, they often are in practice.
The longer the run, yes, the more important the quality. But that doesn't mean it's unimportant on short runs.

We have to toss about a dozen cables in the trash every year, and most of them are thinner ones that came with hardware. The thin cables are not just more fragile, but have a habit of adding (picking up) noise in the signal path. It doesn't matter what kind of wire it is, ethier -- HDMI, VGA, s-video, component, composite, coaxial (RG59 and RG6).

Monster is overpriced, yet convenient. Some of the Philips wires sold at Lowe's and Walmart are pretty good. The better cabling is often sold from specialty stores, online only, or in bulk only. Last time I wanted to wire a house with quality RG6, I had to buy 200 feet of it on a small spool, and then add heads myself. Best RG6 wire ever. Not so much as a hiccup in 6+ years.

Thin wimpy-shielded cables are cheap to produce, and are given away in consumer devices because it's expected. But serious users will almost always need/want to replace them with better grade cables. We want actual quality, not "good enough" (a sorry excuse for accepting lousy quality). The hard-to-accept rub is that a small box of good wires can cost just as much as a hardware component (VCR, small TV, DVD recorder, Blu-ray player, etc), and it's one of those hidden costs of running a serious video business, or having a serious video hobby.

DataVideo, Nintendo (1980s), and ATI (pre-AMD) are companies that gave out quality wires with their hardware.

What makes it interesting is when you get engineers/developers together with full-time hardware/software users. Too often hardware and software seemed to be developed from a very narrow set of sample parameters, and then when released, it consistently fails to live up to promises made by the lab. When end users get direct access to the devs, magic happens. Management, marketing and bean counters need to sit in the back seat and STFU sometimes.

I'll be the first to admit that I don't completely understand everything, in terms of how the drivers work, how the hardware chips work, etc. But at the same time, I probably do more video work in a single week than most people do in a whole year. And my specialty is handling signal-damaged consumer formats, mostly analog videotapes, and especially VHS. I have a drawer full of bad digital video samples (DVDs on spindles), and a large box full of bad analog tapes (mostly VHS), that should make any forensic/restoration tool developer drool.

That's why I like interacting with "the other half" of the equation. You make it, I use it. But I'd also like to help you make it, because long-term it's going to be that much better of a tool that I can use.

Part of the problem, however, is making the engineers/devs understand what doesn't currently work. There's a big issue -- and has been for as long as I've discussed video online -- in discerning theory from reality (practical application). Too often, devs get defensive, and start to spout math, ignoring the issue. In the context of TBCs, we get a lot of promises from ultimately non-functional/non-effective hardware. And your reasoning is sound as to why that happens (not enough RAM, too slow, etc), though it doesn't change anything for the end users. To us, it's broken crap and lies, and I think that's where you observed animosity on the topic.

LS,
I totally know what you mean. I think there's a personality thing that goes along with the analytical mind, you can get idealistic and theoretical, but I totally understand. I can appreciate when something doesn't practically work, but in order to fix it, I need to define what exactly is happening.
As for TBC, you're right, but it took a while for me to understand what you expect from a TBC in terms of the practical visual effects.
I'll get around to the vertical jumping sometime, that should work out better than the line jitter problem I've been on.

I have at least 2-3 varied samples that I want to submit to you, for any vertical-only anti-jitter filter.
Probably 2-3 more beyond that, if I get some time to think about it.
Current methods all rely on demotion/deshaker, but it's far from usable on vertical-only jitter.

This is probably best left to another thread -- or the special dev site we've talked about creating. ;)

I have one sample to try, you posted a faq about tbc. It was some cartoon.