How to record via IEEE 1394 (Firewire) to Windows XP - Page 190

Yeah, MS included it in Windows 7. Presumably the copy in System32 is 64-bit and the copy in SysWOW64 is 32-bit. (SysWOW64 is the "Windows on Windows" 32-bit area used by 32-bit processes).

Perhaps replacing the SysWOW64 copy of qedit.dll with 32-bit XP's would work...(you'd also need to add the registry otherwise the OS won't know how to locate SampleGrabber).


I created it. When I first encountered the SampleGrabber error message, on Windows Server 2008 x86, I used the Microsoft Sysinternal tools RegMon and ProcMon in order to identify the missing registry that triggers the SampleGrabber error. I then went to another computer where CapDVHS was working and viewed the intact registry, where the InprocServer32 value told me that the file was qedit.dll. After that it was a matter of playing around with it (using things like regsvr32.exe and capturing the self-registration data from qedit) and trying to determine just how much of the qedit registry was really needed in order to satisfy CapDVHS.



I agree that replacing the 64-bit copy of qedit from System32 (lovely misnomer, that) with a 32-bit copy is a bad idea. The SysWOW64 copy is 32-bit (the SysWOW name alludes to the fact that 32-bit processes are emulated; it's a 32-bit Windows emulation on top of 64-bit Windows...WOW stands for Windows On Windows). So, strangely, the stuff in System32 is 64-bit and the stuff in SysWOW64 is 32-bit.


Well, I don't know about that. But certainly don't attempt it if you don't have a backup image or something.

As you found out, thats not gonna work. The way firewire works is that each device (unit) has a node ID and a set of subunits. The node ID is like a mailing address that tells the packets where they are going on the bus. The subunits codes tell other devices (units) (like your windows pc) on the network what kind of functionality the device has. There are distinct subunit codes for Tuner, DVHS, Disc (CD/DVD/SACD/MinidDisc/BluRay), Audio/Music, Conditional Access, Monitor, Bulletin Board / Resource Scheduling Board (Scheduled Recordings), and more.

When windows enumerates device (units) it likely looks at the subunits to determine the driver type (tuner/dvhs/avhdd/panel) required to load and also reads the Configuration ROM for the Model ID / Name (JVC HM-DH100U ....).

The JVC I think exposes both tuner and dvhs subunits.
The comcast stb as I recall exposes tuner and maybe panel subunits.

The firewire devices form a network with each device forwarding packets to the proper destination (node ID).
So unless you have a broadcast connection coming out of the STB, you are out of luck without the proper subunit drivers, which as others have pointed out dont seem to be publicly avaliable on 64 bit windows architecture.

Yup, I did find out the hard way. But at least Microsoft was nice enough to include DVHS Tape Unit drivers on both x86 and x64 Windows 7 and Vista.


That's right. And on 64-bit Windows 7/2008/Vista it'll automatically plug-and-play install the driver for the AV/C Tape Unit, but it will fail to locate a driver for the AV/C Tuner

I just did a test recording on Windows Vista x64 Home Premium and was able to use CapDVHS to capture from a JVC 30k DVHS unit. Everything worked fine. Too bad I have almost zero interest in ever doing that.


Are you aware of any "privately available" 64-bit Windows drivers for AV/C Tuner units?

Don't know what could be different here, such that your launching CapDVHS on Vista x64 does not produce the "SampleGrabber" error that I saw launching CapDVHS on my Win7 x64 system. I don't have a Vista system to experiment with.

On a theoretical level, I'd like to at least understand why CapDVHS shouldn't be able to operate using only the tape device driver which DOES get installed in Win7 x64, even if the tuner device driver is not present. You say this works in Vista x64 with your 30K, and my experience is that it fails in Win7 x64. So there's obviously something still wrong here (at least for me), as the REC/STOP buttons are grayed out... and it seems highly likely tied to the SampleGrabber error situation I would guess.

On the other hand I really have no problem booting to WinXP for those now few and far between very very rare situations where I do want to import a copy-freely HD program from DVHS to the PC (having previously offloaded from DCH3416 DVR to DVHS).


Actually, I'm still waiting and hoping for some DCX34*/35* user with very recent firmware (e.g. 24.07) who also has DVHS VCRs, to report here as to whether or not the long-standing firewire recording failures with DCX boxes has once and for all finally been corrected with this latest-and-greatest firmware, or if it's still unresolved and still failing.

For me, this would be a much more significant subject to see resolved than issues regarding recording from DVR to PC which can only be for copy-freely content, as DVR to DVHS supports both copy-once and copy-freely. So you can offload to DVHS premium content and other cable channel content that's marked copy-once, which you cannot do with a PC as the target device... if only the DCX and firewire finally worked successfully and reliably again.

I asked that question quite a while back, but don't think anyone's ever replied YAY or NAY on the state of firewire recording ability to DVHS with the recent firmware in DCX-family hardware.

One way or the other, I'd like to know the firmware/software version, DCX model, location, and cable system provider.

Okay, I've just finished testing Windows Vista x64 and it has no problem using CapDVHS to record from a JVC 30k DVHS unit.

I did a fresh install of Vista x64, no service pack, no updates or drivers of any sort (other than what was on the DVD). I copied over CapDVHS and installed VLC 1..1.11 (b/c, unlike Windows 7, Vista doesn't like playing back .ts files without dicking around in the registry).

I plugged the FireWire cable from the JVC 30k DVHS unit to my PC and it immediately Plug-and-Play installed the AV/C Tape Unit device driver and then failed to install the AV/C Tuner device.

Then I popped in a DVHS tape that had an episode of the old 1969 "The Bill Cosby Show" and captured it using CapDVHS. It was only MPEG2 standard def, but it recorded without any problem.

I next grabbed an old tape of Star Wars Episode II, recorded from HBO before Comcast switched that channel from Copy-Freely to Copy-Once (this was recorded around Summer 2007, I think). It's 1080i and recorded flawlessly (though I only recorded a few minutes as a test).

The videos looked like garbage playing on that Vista machine and had no sound b/c I never installed a proper video driver or any audio driver whatsoever, but I copied the .ts files to my Windows 7 machine and they played back beautifully.

So anyways, I have to give a resounding thumbs up to using CapDVHS on Windows Vista x64 for DVHS captures .

Next I'm going to install Windows 7 x64 and see if I also encounter the dreaded SampleGrabber error message. I've taken precautions by copying the 64-bit and 32-bit qedit.dll from Vista x64, including the needed registry info...I don't know that I'll need it but it could come in handy, assuming Windows Resource Protection doesn't castrate me for replacing the qedit with an older version.

My plan is to perform a fresh install of Windows 7 x64 w/SP1 (installing absolutely no drivers or updates), and immediately go into Device Manager and have it switch to using the legacy FireWire driver. I'll then copy over CapDVHS and plug in the FireWire to the DVHS unit.

The SampleGrabber error is likely due to changes that Microsoft made to qedit.dll. They're pretty tight-lipped on it, but they admitted to removing "deprecated" functions that they felt should no longer be there...looks like SampleGrabber may have been one of the victims.


It can. But whoever wrote CapDVHS was also relying on DLL functions in qedit.dll for some of the recording functionality. They could have written their own code for that, but I imagine that's super crazy hard. So if Microsoft was doing a code-audit (usually to shore up security), they may have identified dodgy stuff in qedit.dll and decided that nearly nobody was using that code and decided to chuck it. So in that case, CapDVHS is a victim.
*I'll bet that other capture software such as Arcsoft Showbiz would work, as I highly doubt they rely on the SampleGrabber function from qedit.dll.



Yeah, probably the missing SampleGrabber function from the version of qedit.dll that ships with Windows 7.


I'm also dying to know about the FireWire situation with the DCX models.


Nobody's responded. Hopefully somebody with a DCX will try to do some FireWire captures and report back.

Turns out that CapDVHS works flawlessly on Windows 7 x64 with my JVC 30k DVHS unit. I didn't have to anything about qedit.dll.

My steps were ultra basic:
I popped in a DVD of Windows 7 x64 Home Premium (w/ SP1 built in). I performed the install and didn't update anything whatsoever (I had no audio driver, but my video was fairly decent, unlike during my Vista test where the video was pathetic).

I went went to Device Manager and switched the FireWire driver to the legacy FireWire driver.

I then copied over CapDVHS v0.3.0.6 (and a .manifest file that I created that tells Windows 7 to demand Admin rights, and tells it that CapDVHS is Windows 7-compliant...I'm certain that this .manifest file had no material impact on my test; it's just for convenience).

Next I hooked up the FireWire cable from my PC to my JVC 30k DVHS unit. It very quickly successfully installed the AV/C Tape Unit driver and displayed an error message about being unable to install the AV/C Tuner driver.

Finally I captured a few minutes of Star Wars Episode II from my JVC 30k DVHS unit. Everything ran flawlessly.

Well, this is pretty remarkable news. I don't know why you are not getting the SampleGrabber error that I'm getting, but it must surely be tied to other things or Windows Updates that are installed on my system. I suppose I could experiment like you've done, also installing a brand new Win7 to see if I can duplicate your results.

I've retained a bootable WinXP strictly for this one remaining CapDVHS application that I thought was unusable on 64-bit Win7. I have no need for STB firewire drivers or recording from my DCH3416 to PC which won't run on 64-bit Win7. I only need DVHS recording capability, so if this actually can work with the stock MS "legacy" firewire driver and the auto-installed AV/C tape device driver as you have proven on 64-bit Win7 then I can finally ditch my WinXP partition once and for all.

One obstacle to any experiments is that I currently have a number of copy-once recordings on my existing WMC setup, and these would be unplayable if I reinstalled Win7 from scratch. But I can certainly experiment by first taking an up-to-date "system image" and then reinstalling Win7 and trying CapDVHS. If that works, I will store that fact away.

I can then restore the system image and plan to "view down" all of my recordings eventually, at which time in the future I could reinstall Win7 and start over... and have a working CapDVHS/DVHS which is all I need, and no longer keep WinXP.

Fascinating.

Thanks very much for spending all the time testing out these variations.

Hard to say what's going on with your system. It could be a goofy DirectX update (qedit.dll is part of DirectX). You may want to run the latest DirectX End-User Runtime update. You may also want to drop to the command prompt and type SFC /SCANNOW to have Windows 7 verify all of your system files and replace corrupted or old ones with the proper version. It can also re-register some DLL's/OCX's, which could fix the issue.


That sounds like a plan, but hopefully you can get it working without doing a full reinstall.


You're welcome. I was surprised that no additional drivers were needed...I knew that I had recorded from DVHS in the past, but that was nearly always on x86 flavors of Windows 7 with the FireSTB drivers installed and my assumption was that it was using the FireSTB drivers. It's interesting to find that it can be done with built-in Microsoft drivers, even on 64-bit Windows 7 and vista.

I have a DCX3200 from Time Warner. I was thinking about picking up a firewire cable and connecting it to my computer. I've never done this before but this will allow me to record shows correct? I'm on Windows 7 x64. Will this be any problem? I've read part of this thread and saw some people talking about certain copyright flags set on the HD channels. Does this mean it can't be recorded or viewed or how does this work? Thanks

I been using capDVHS on my windows 7 connected to my qip7100-p2 stb with no problems. I was wondering if there is any application that would let me use win7 media center to record?

I remember years ago someone had an app (mytray) for mce 2005 that allowed this but I've yet to find if anyone is using it for win7 media center?

You will only be able to record and play back programs that are marked "copy freely". This is true for all local OTA networks (e.g. ABC, NBC, etc.) that are also carried on your cable system.

If that is your goal, to record local OTA commercial network programming then YES, you can do that.

But you will NOT be able to record and play back programs that are marked "copy once" or "copy never", which varies by cable system and location. In the case of TWC/LA, virtually EVERY non-local-OTA channel is marked as "copy once" so that you would NOT be able to record it to PC via firewire.

I don't know if this is TWC's policy nationally, but for sure here in LA they have taken a general position that almost all channels (i.e. all premium channels and virtually all basic cable channels) are marked "copy-once" and also encrypted. The only equipment capable of playing the program content is a cable STB/DVR, or a TV/tuner or 3rd-party DVR that utilizes a cablecard which you rent from TWC instead of renting a STB/DVR.



This is a bit of a gray area to me.

You say you have a DCX3200 STB rather than a DCX34*/DCX35* DVR. Now Motorola "broke" the firewire interface in the whole DCX DVR family of products (i.e. DCX34*/DCX35*) way back when the product family was first released, and has seemingly never yet fixed it. At least no forum member around the country (even those with very recent firmware upgrades in their DCX equipment) has yet reported this problem to have finally been corrected.

So we have to assume the problem still exists, and that it is physically impossible at the moment to make reliable firewire-based recordings from any DCX-family DVR (i.e. DCX34*/DCX35*) to either (a) PC or (b) DVHS VCR.

Now, recently there's been an unconfirmed and unverified report rumor that firewire recording using the DCX3200 STB actually DOES work, even though it does NOT work in the DCX34*/DCX35* DVR family. You have a DCX3200. So there might be a chance that this could have theoretically worked for you... except...

You also say you have Win7 x64. Unfortunately, the native firewire drivers now in Win7 do not support the AV/C tuner in the STB, and the 3rd-party "STB firewire drivers" discussed in this thread for use with CapDVHS, etc., only work in 32-bit environments, not 64-bit environments.

So I'm afraid you're doomed. Lofty goal, but there are too many issues running against you.

Thanks for the great explanation DSperber. Why would they put these copyright restrictions on these channels when back in the day you could record any channel you wanted right onto your VCR? What is the difference between the "copy once" and "copy never" flags? I thought the whole point of this STB is to decrypt these channels so you can watch / record them as you please and the firewire port was basically another video out.

You STILL can record ANYTHING you want using your VCR... which means feeding it say from the S-video analog video output of the STB/DVR along with L/R-stereo analog audio output. They couldn't care less what you do in the analog world. There is ZERO copy-protection of any kind... including on premium channels. (you may even be able to record pay-per-view using analog)

They also do not protect "analog HD", i.e fed with component video. Again, if you did have a component video recording device then this would be "very good HD quality" but not "100% digitally perfect HD".

What they are protecting is the firewire-source feeding a digital recording device, with a 100% PERFECT digital copy of the original copyrighted program content.

That's why there are no HDMI-facilitated or firewire-facilitated recording devices (e.g. direct to BluRay from original pristine digital-form 720p/1080i) even though there are S-video-facilitated (e.g. direct to DVD from 720p/1080i downconverted-to-480i even if then upconverted to 480p for recording on the DVD, making the end result very far reduced from the original 720p/1080i HD).



Not quite accurate. They don't mind if you WATCH... but they have a big problem with your desire to RECORD.

The idea of "copy never" is strictly for things like pay-per-view, where they don't want to let you even record it to the DVR's hard drive. You are obligated to either (a) watch the event "live", or (b) watch the event during say whenever you want during the purchased 24-hour view-anytime window. In theory there's really no justifiable complaint about either of these two ideas.

But the real meaning of "copy never" is that the program can simply NEVER be recorded. It can only be watched from the stream provided by the cable system, whenever it's available.

As far as "copy once", this means you can record it to DVR hard drive and then watch it whenever you want. Also, if you have a DVHS VCR (connected by firewire, and the recording is 100% perfect digital) then you can offload that program to the DVHS VCR, which actually counts as the "copy once" count of 1. The DVR recording doesn't actually count in this particular situation.

But that DVHS VCR recording is copy-protected by the VCR itself and that 1st-generation tape recording cannot be further duplicated into a 2nd-generation tape recording (e.g. if you had two DVHS VCRs, and tried to copy the 1st-generation recording to a 2nd-generation recording on the second VCR connected via firewire to the first VCR).

So "copy once" means (a) you can record it to DVR, and (b) you can offload it 100% digitally perfect from DVR to [a 5C-compliant, meaning it will obey the copy-once flag] DVHS VCR which then becomes the authorized 1st-generation "copy once" recording. But that 1st-generation DVHS copy cannot be re-copied (via firewire) into a 2nd-generation digitally 100% perfect DVHS copy.

The firewire port is a very significant output option, specifically because it provides 100% digitally perfect datastreams. Note that the onscreen graphics (e.g. the Guide, MyDVR recording list, etc.) is NOT visible on the firewire port. It contains only the pure program content datastream. So even if you were watching something on your HDTV (say via HDMI) from the STB/DVR and pushed the GUIDE button, what graphics you then see on the HDTV is NOT impressed onto the firewire output. The graphics are only impressed onto the true video outputs of the box... composite/S-video, component video, HDMI, but NOT on the firewire output (which strictly speaking is really is a data output, not an official audio/video output).

haha I would never record to VHS now. Hell, I don't even know where my VCR is. I love my HD. Didn't realize how strict they are with recording HD content. I don't think I'll even mess with it. Couldn't I just buy one of these Blackmagic HDMI pci-e cards and bypass the whole firewire port and all its restrictions? I know HDMI has some type of handshake. Not sure how this product deals with that.
http://www.amazon.com/Blackmagic-Des.../dp/B001CN9GEA

I think there are a couple middleware companies which have SDK's compatible with Win64.
I have always been a Windows user, but after my workstation died I decided to try a MacPro (2x4 core) and OSX is fine.
I have been working with Apples Firewire SDK and am just about ready to start testing a library which can control a Disc subunit (AVHDD/Hard Drive, Mini-Disc, CD, DVD, SACD, DVD-A, Changer).
Its a lot of code required to implement the Disc subunit and numerous AVC specifications.
I also have Tuner classes for started (ATSC/DVB).

I have several devices to test with.
AVHDD - IOdate Rec-POT 1TB, several Toshiba disc recorders.
Mini-Disc - Sony Lissa firewire minidisc player I got new for like $40 from england a couple months ago.
DVD/SACD/DVDA - Yamaha 2500 something or other DVD player.
Tuner - EyeTV 500 (ATSC/QAM), FireDTV S2 (DVB-S2), Panasonic 50 tuner, Sharp LC45GX6U flat panel.

Each device implements different subunits. Its neat stuff.

Did I mention its a looooooot of code to control a Disc subnit?
Gotta get back to a implementing video content object parsing routine with bloody info blocks......

You know back in 2000 I threw my VCR in the dumpster and told myself I'd never again own a linear tape device (VCR). I ignored DVHS all the while it was marketed, then in 2009 got interested and did the unthinkable and bought a DVHS deck. I now have VCR's again and own pretty much every HD capable DVHS deck sold in the US except maybe a pro JVC unit!

The reviews are not universally positive.

Also, the point was made in the reviews about incompatibility problems, as well as requiring a very strong CPU/disk setup... which is not a surprise given that data sent over HDMI is de-compressed and arrives at this card at an enormous bitrate.

I don't think that the HDMI handshake between DVR and this card will produce an "HDCP-compliant" result, which will cause the DVR to shut down and NOT DELIVER anything over HDMI. (but to be honest, I don't know for sure that the card is not HDCP-compliant)

Yes, the card can also be used to accept home vidcam-provided HDMI output for editing, etc., as this is conceptually "copy freely".

But as a general 100% digitally perfect and reliable mechanism from STB/DVR to PC... even this approach has serious limitations.

Yes, it's a problem. There are no 64-bit Windows drivers for connecting to a cable box. The reason that there's confusion is that there are 64-bit Windows drivers for connecting to DVHS high definition VCR's, but those drivers are not able to talk to cable boxes.

So...with 64-bit Windows the best you could do is buy a DVHS VCR and record from the cable box to the DVHS, and then play back the DVHS tape to Windows 7 x64. Obviously that's retarded and you should just reinstall using Windows 7 x86 (32-bit), which uses the exact same Product Key as the x64 flavor. 64-bit is overrated and is frequently slower than 32-bit. The vast majority of software is still 32-bit and will continue to be for a good while. There also tends to be more issues with 64-bit drivers b/c many programmers are still ramping up on x64. Do yourself a favor and stick with 32-bit until Windows 8. Unless you do a *lot* with VM's, it's fairly unlikely that you need more than 4 GB of memory (even if you do a bunch of video editing, you'd be surprised at how little memory is needed for that).

Thanks for the info. No big deal. I was just simply looking into it since I had never messed with the firewire out on my STB. I've been on Windows 7 x64 for a while now and never had any problems. I have 8 gigs of ram so I would prefer not to switch to x86. I mainly use my computer for gaming so I have a somewhat powerful system. I've heard of people using those Blackmagic pci-e cards I posted above to capture Xbox 360 and PS3 gameplay onto their computer, but never heard of them being used with a STB.

I have Verizon Fios in Jersey and they mimic your TWC results. I'm finding almost every channel, outside of the locals and basic, are "copy once". Pretty sad as I was first excited to finally get my qip7100-p2 working with firewire to my win7, but now seems not much more I can record over my current vmc7 recording qam256 for my locals and unencrypted.

Yeah, that's cool. The capture cards are pretty good but the software can be a bit buggy/picky, particularly on Windows 7/Vista x64 (they're far more stable on XP 32-bit, as programmers are a lot more used to writing robust drivers on that flavor of Windows. The x86 (32-bit) Vista/7 drivers are also more stable than their x64 counterparts, but not as stable as the XP x86 drivers).

The results produced by the capture cards are good, but certainly not lossless (the FireWire capture gives a 100% bit-perfect lossless copy). The biggest complaint I've had is that sometimes the audio is out-of-sync and must be fixed in post (I use VideoReDo TVsuite v4, which has a simple "adjust audio" feature). This sort of issue can't happen with a FireWire capture, as you end up with the same MPEG2 Transport Stream that was broadcast from your cable company.

I don't think that Windows 7/Vista Media Center can record using the cable box FireWire drivers. I would think that one problem would be changing channels (but you could try something kludgy like the IR blaster and scheduling software).

I have found that Arcsoft Showbiz is able to record using the cable box FireWire drivers.

Very interesting.


Yeah, numerous people have mentioned that they use 64-bit Mac OS X (with the Apple FireWire SDK) to record from their cable box. And they have the exact same reboot-bug with the Motorola A28 Guide update that Windows users experience (which is more evidence that Motorola borked something on their end).


Now that's a lot of FireWire!


Sounds pretty crazy and well beyond my coding capabilities, but I wish you luck. Keep us informed of your FireWire adventures!

I should mention that this is tricky. Capturing Component Video is easy b/c it's analog and there are no protections, but captureing HDMI (using the BlackMagic or Hauppauge Colossus) is much trickier because of HDCP copy protection. Those devices refuse to record from protected sources (it's "meant" for recording from video camera's, etc). You'd need to remove the HDCP, which depending on where you live may not be allowed. Google search "Moome Mux-HD"

That Moome Mux-HD is an interesting little device. So it strips the HDCP and directs the audio to a toslink port? Couple hundred dollars for that box. So it would go STB -> Mux-HD -> BlackMagic. Only problem is I would have to figure out to the audio back in by having a soundcard with a toslink input. Too much work and a lot of money, but it would be nice to have.

It certainly is but, as far as HDCP goes, I'll let you have the last word on that topic...the rules of the AVS forum prevent us from getting into any detail, but it sounds like you get the point.


I don't think you need to worry about the Toslink audio...the Mux-HD has 2 Toslink outs...so 1 can go to your capture card and the other can go to your AVR. And I assume that your PC has HDMI output on your video card, so that's how your audio would output from the PC.

If you look at the MUX-HD's advertised features, it accepts 4 HDMI's and outputs 1 HDMI and 1 DVI video. So it's a HDMI selector switch; you tell it which of the 4 HDMI inputs you want to view and it then splits that signal to both an HDMI and a DVI video output. DVI is the same digital video that HDMI uses and you can buy a cheap DVI-to-HDMI adapter in order to have two HDMI outputs (but only the real HDMI output will also carry the audio).

On the audio side of things, the HDMI output retains the audio (But I believe that only Dolby Digital 5.1 and 2.0 is supported, not 6.1 or DTS or PCM or anything else...but I use this only for the cable box which only deals with Dolby Digital 5.1 or 2.0). However the DVI output is not capable of carrying audio, so there are also two Toslink optical digital audio outputs. So, in addition to splitting the video to two outputs, the Mux-HD also splits the audio to two optical audio outputs. My own experience has been that the audio splitting is a little unreliable; when it works, it's flawless...but sometimes it's as though the audio signal doesn't lock in (when you tell the Mux-HD which of the 4 HDMI inputs to use) and all you get is a terrible static sound. I'd say it does the static thing maybe 25% of the time (but it's easy to identify and all you have to do is cycle through the inputs and it's almost guaranteed to lock in on the second attempt). Anyways, I use the coaxial digital (RCA cable) audio output on my cable box to drive my AVR, so I run the (otherwise unused) optical Toslink digital audio straight from my cable box to the Hauppauge Colossus HDMI capture card, and thus never have to deal with the static crap. So for me, the Mux-HD is just delivering the video and the audio is going straight from the cable box to the Hauppauge Colossus.

The Colossus has HDMI input, Component Video input, analog stereo input (RCA jacks), optical Toslink digital audio input (supporting DD 5.1 and stereo audio...possibly DTS in future driver and software updates). It also has passthrough outputs for Component video and optical Toslink digital audio. It's a pretty sweet capture card.

*BTW, if you read up on the Mux-HD, you'll read that the HDMI output doesn't carry audio. That's not true. Apparently that used to be true with old ones from a couple of years ago and the info on the site hasn't been updated.

It's clear... between 5C-compliance and encryption of most channels for firewire, and HDCP-compliance for HDMI, "the industry" is obviously at least trying their best to prevent digital piracy of 100% perfect digital copies of copyrighted content.

It is obviously either (a) impossible to the normal consumer, or (b) very difficult or nearly impossible and at least fairly expensive even for the dedicated semi-pro, to attempt to accomplish a 100% digital copy.

And for this very reason there is no BluRay-burning home product that connects directly to the STB via firewire or HDMI. Protecting BluRay's from being digitally duplicated has obviously turned out to be a complete failure. But protecting the source digital datastreams themselves (either in compressed and encrypted form over firewire, or in uncompressed and "open" form over HDMI)... well that does seem to have been far more successful.


It's clearly far more practical (and definitely possible) to use a near-HD recording method based on analog-HD component-video.

Or... more sensible even than that, just go with a DVHS VCR (if you can find one and don't mind the tape medium) and either a DCT or DCH family DVR, since Motorola still apparently has not repaired the firewire interface they broke with the DCX family of DVRs (even with the latest 24.50 firmware??).

Still unconfirmed by verified "multiple sightings in the field" is :

(1) is it true that successful firewire recording to DVHS/PC-x86 is really possible with a DCX3200 STB?

(2) does the latest(?) 24.50 firmware now reported on Charter's units still show the DVR->DVHS/PC-x86 firewire failures, or has that finally been fixed?

Ah ok. That makes sense now. I don't even have an AVR right now. I do have HDMI out on my video card.

Interesting setup. Makes me want to buy a Mux-HD and Colossus. About $200 for Mux-HD and ~$140 for Colossus?


Meanwhile HD rips of TV shows pop up online 15 minutes (if that) after airing. No idea what their capture method is though.

From the Hauppauge description of the product:

Colossus also has an HDMI input port, so you can record HD video at up to 1080i from a un-encrypted HDMI source.

Note: most cable and satellite TV set top boxes encrypt HDMI output, so you cannot record from these sources. Unencrypted HDMI comes from the Xbox 360 plus most video cameras.

You'll therefore be limited to analog (i.e. component video) input for recording from the DVR. (Actually, this statement is kind of technically incorrect as I don't believe the HDMI output is "encrypted", as the firewire output would be "encrypted" if the source program was encrypted. HDMI video data is "in the clear", which is why HDCP-compliant display devices and AVRs are typically the only HDMI-enabled devices a DVR will deliver to over HDMI).


Also:

The recording format is AVCHD, which can be used to burn Blu-ray compatible DVD disks. Two hours of HD recordings, recorded at 5 Mbits/sec, can be burnt onto a standard 4.7 GByte DVD-R or DVD-RW disk for playback on a Blu-ray DVD player.

This is all "good, pretty good, near-HD", etc., but it's not 100% digitally identical to the original HD source program.



Can only be analog capture, like the above... which is "pretty good". And after re-sizing/re-compressing for YouTube or wherever/torrent it shows up on, it looks "pretty good" on your computer screen to watch.

I'm certain it is not a 100% digitally accurate copy of the program, unless (a) it is from a copy-freely OTA network program, or (b) it was captured in one of the fast-dwindling areas in the country where the cable provider is not marking everything "copy-once" so that unencrypted digital recording is still possible (e.g. using Windows Media Center, BeyondTV, etc.) through TV/ATSC tuner cards and Ceton/cablecard cards on an HTPC.