Slashdot Mirror
Using a Digital Camcorder as a Tape Drive?
mookie_black asks this interesting question: "I have a Sony Digital Camcorder and an ADS firewire card. I am able to offload the tape information from my camcorder to my computer in the DV format and edit the video. My video editing software allows me to edit the DV format and then place it back on the tape in the camcorder. Since 40 minutes of tape takes up several gigs on my hard drive I thought it would be nice and cheap if I could back up my stuff to camcorder. I do not have a tape drive and was wondering if there is a way to backup my system into a DV format put the backup on the 8mm tape in my digital camcorder."
What an interesting idea! Would such a hack work?!
With DV-format cameras, one does not send in raw video to be compressed in the camera-- the compression is done by the sending device. The misconception you cite seems to be quite common.
In Russia, there's such a beast. It's called Arvid, IIRC, and it's exactly for this - for backing up data from the computer to video-tape. It works, though I don't know details - never used it.
-- Si hoc legere scis nimium eruditionis habes.
Yes, these are available. They hold approx 4 gigs, and work like an external drive, although I have never used one. Just write a prog to reformat the data as a "movie" ie each byte in your archive makes a byte in the bitmap for the frame, then just pretend like its a movie (it might even look cool) and save it to tape. Kinda a kludge, but it would work. You can also buy drives with software that provides easier access to the data.
I have wondered if you could do the same thing wiht a minie disc player?
There exist SCSI tape drives that use VHS t120 tapes and can put 15GB on 'em. This place has one such beast in the "Exotic hardware" section.
If you figure out a way to get dual use from your camcorder, I'll just bet the next generation has a "feature" that prevents it from working. Can't have the camcorder sales cannibalizing the tape drive sales, ya know...
This could depend on one thing: is the 5:1 compression fixed (aka for every 5 bytes of data it writes 1) or does it vary, like gzip? Even if the compression is lossy, if the data was already compressed, there would not be much for it to compress (since the data will be mostly random) in the variable case.
In either case, I would try using Reed-Solomon (sp?) error correction for it. I have not done so myself but someone should research to see if there is anything to do it that has some source code. By the way, since we are talking about video, this error correction is what is used on DTV for error correction when the data is broadcast (talk about lossy!). The way it is corrected for in TV is lossy because you usually don't care about each individual pixel, but theoretically the system could be used to do it without loss if it is coded heavily enough.
Wouldn't it be neat to have a kernel module that could wrap around a block device and automatically do error-correction coding? Never have to fsck again! Every read it could figure out how many bytes were incorrect and give you a warning / automatically fix any errors it finds. Yeah I know it could get a little slow, but on today's fast computers no one should notice. It's not a very CPU-intensive algorithm. It's performed on 19.2 megabits-per-second data in real time for a set-top box.
Sorry I got a little carried away on a useless idea.
Kenneth Arnold
P.S. If you are going to contribute great stuff to slashdot, get a user account. Anonymous Cowards start at Score 0 and generally have a negative connotation around them. Besides, it's free and you have another reason to check on all the cool stuff every day.
Where have you been? I worked for a company that made VHS recorders for the Government (military, etc) that stored data it obtained from various devices filtered through a multiplexer. The heads were specially made (we had one guy assemble them in the back room -- painstaking work!) but the other parts were straight out of panasonic or whoever we could get. So, the answer is -- sort of -- but we were dealing with the government here. The problem we constantly had was that people were constantly thinking that because it was VHS meant that they could go out to their local Wally World and pick up a 10 pack of T120s and put them in. Problem with that is the VHS tapes you buy at the supermarket are so dirty and such poor quality that they stripped the data heads. So, I don't know how good the 8 mm tapes would be unless you used tapes intended for data.
There are some problems. Most camcorders are not high quality. Good enough for video where you won't notice a byte being off a little, but fatal to a comptuer when some of the bytes are off.
You may get 40 gig of movie, but I'd be surprized if you can get more then 10 gig of data and still have a chance of recovering it.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
and I asked for a few similar things ... like possibility of inplementing a mp3 player in new D8 camcorders ... and they just haven't answered ... it is a pitty they are so ortodox in their stuff ... I think they have quite good technology in several areas they don't plan/want to integrate .. HiFD disketts of 200MB are one of bests ... I would love to use them for storying mp3 files or short DV footage ... they get the money eithr way so it is not as interesting for them as it might be for the 3rd prty developers that make take it ...
Is this a Linux box you are doing the editing on? I'm in DESPERATE need of some good, cheap (free?), Linux-based video-editing software.
---
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
I remember back when BBS's were the thing, and the net was only a rumor...I say a hack for backing up your harddrive on a VCR... I'm sure the file is floating around somewhere.. but I'd have no clue where to find it...
I post links to stuff here
You might be thinking of Backer from Danmere Electronics. It holds up to 4 gig. I don't have time just now to convert prices to U.S. dollars...
Years ago, the Video Backup System for the Amiga did much the same thing. The author wrote up the Reed-Solomon error correction code in the January 1997 issue of Dr. Dobbs' Journal.
I like these concepts, but I would love to write a broader replacement for these that uses generic video capture boards, for example.
I'd love to elaborate more, but I have to go back to work now. I might write more when I get home.
--
--
"Insert witty quote here."
I bought one of these about 6 months or so ago and it works just great with my linux machine. No problems getting it to work with the SCSI card or the tapes. It was labeled as an OEM product, so it's not going to come with any documentation, but I contacted Aiwa's tech. support department and they emailed and faxed the documentation that I wanted. I've been very happy with this little $100 device. I want to get the USB version for my wife's Mac.
Maybe you got a bad batch of tapes. What brand of tapes are you using?
One would not implement this by making a sequence of pictures (frames) and sending them to tape through a usual DV codec: DV-format video is based on a quantized DCT (like JPEG) as is thus not lossless. However, one can format an arbitrary data stream to fit the same format as what comes out of a DV codec and pass that to the camera. Played as video, it would look like whatever (noise) but the tape backup system would, as before, not use a DV codec, it would just lift the data out of the stream directly. In other words, the communications channel to the camera is not raw video-- it is lossless transmission of (usually, but not necessarily, DV-encoded) data.
Some people have brought up concerns of reliability. As mentioned above, the DV tape format includes error correction (which is *not* error concealment, which is what you do when error correction fails-- that is included too, but is device-dependent and another layer up whereas the error correction is an integral part of the standard). I do not recall offhand to what typical rate (i.e., 1 uncorrectable bit per x bits read) this is supposed to work, but one of the points of DV is its lack of generational loss. In other words, even video people care about not losing any data. In my experience, data loss in DV tape (even with tape that has undergone many passes) in video applications is pretty minimal to non-existant.
Of course, this is not much of a reassurance. But that is no problem really, because there is nothing stopping your backup software from pumping its output through the error-correcting code of your choice, say your favorite variant of cross-interleaved Reed-Solomon. Just about any storage system at all can be made as reliable as you want by layering error-correcting codes on top of it. There's no reason hard drives couldn't be made without any error correction at all (and they do plenty-- today's average HD is correcting lots of "errors" all the time and this is the way it's designed to operate) except for the fact it makes for a cleaner and more efficient implementation to have it done in the HD and not your CPU. It's no big deal.
Actually, DV is so cool a lot of us are wondering how it escaped product development before the marketers/biz people/bean counters dumbed it down...
If I ever get any free time (chewing through 4 3" binders of Firewire/DV docs. takes a while even when you have nothing else to do) this will be one of the things I'll implement, but it'll have to wait until I finish a subcode-preserving footage-mover first...
--Shawn, Cokus@math.washington.edu .
First off, the existing computer-to-video-tape is something different... what I believe he wants here is to use an IEEE-1394 (Firewire) equipped digital camcorder that uses MiniDV video tape as a data storage device. There are a good number of reasons one would want to do so: One, these cameras are selling very well and a lot of us already have one. Two, they are quite cheap (with low-end cameras less than $1,000 and tapes less than $10). Three, the tapes hold a *lot* of data: the DV-format video stream is 25Mbps (not including audio, subcode, and error correction: with these 36Mbps) and tapes generally hold 90 minutes giving a tape capacity of roughly 12.5GB (more if you include audio) so that we have a data storage cost of less than $1/GB with a read/write rate of 150MB/min (more if you use audio). While I have not investigated reliability issues from this angle, these figures compare very favorably with current traditional tape backup solutions. Plus, the average current SCSI tape drive takes very poor movies! :-)
Camera control is standardized so complete computer control over the tape's transport is trivial through the same (100-400Mb/s, gigabit coming soon) Firewire channel that the data flows over. Firewire and DV-over-Firewire is actually a peer-to-peer sophisticated networking architecture and stack of protocols and is very cool and much superior to USB (including USB 2.0). I'm very surprised it doesn't show up more on Slashdot and that more people aren't working on it.
One would not implement this by making a sequence of pictures (frames) and sending them to tape through a usual DV codec: DV-format video is based on a quantized DCT (like JPEG) as is thus not lossless. However, one can format an arbitrary data stream to fit the same format as what comes out of a DV codec and pass that to the camera. Played as video, it would look like whatever (noise) but the tape backup system would, as before, not use a DV codec, it would just lift the data out of the stream directly. In other words, the communications channel to the camera is not raw video-- it is lossless transmission of (usually, but not necessarily, DV-encoded) data.
Some people have brought up concerns of reliability. As mentioned above, the DV tape format includes error correction (which is *not* error concealment, which is what you do when error correction fails-- that is included too, but is device-dependent and another layer up whereas the error correction is an integral part of the standard). I do not recall offhand to what typical rate (i.e., 1 uncorrectable bit per x bits read) this is supposed to work, but one of the points of DV is its lack of generational loss. In other words, even video people care about not losing any data. In my experience, data loss in DV tape (even with tape that has undergone many passes) in video applications is pretty minimal to non-existant.
Of course, this is not much of a reassurance. But that is no problem really, because there is nothing stopping your backup software from pumping its output through the error-correcting code of your choice, say your favorite variant of cross-interleaved Reed-Solomon. Just about any storage system at all can be made as reliable as you want by layering error-correcting codes on top of it. There's no reason hard drives couldn't be made without any error correction at all (and they do plenty-- today's average HD is correcting lots of ``errors'' all the time and this is the way it's designed to operate) except for the fact it makes for a cleaner and more efficient implementation to have it done in the HD and not your CPU. It's no big deal.
Actually, DV is so cool a lot of us are wondering how it escaped product development before the marketers/biz people/bean counters dumbed it down...
If I ever get any free time (chewing through 4 3" binders of Firewire/DV docs. takes a while even when you have nothing else to do) this will be one of the things I'll implement, but it'll have to wait until I finish a subcode- preserving footage-mover first...
--Shawn, Cokus@math.washington.edu .
[The less-than signs I had used (entered as ampersand-ell-tee-semicolon) previewed ok, but got munged on the Submit. Is this a Slashdot bug?]
I think what he is specifically looking for is a way to basically mount the camcorder via the firewire interface, and move data to it to be stored completely digitally. With the solutions mentioned thus far, they are basically taking the digital data, making it into an analog picture and letting the digital camcorder recapture it. Data integrity is *probably* not a big issue with a system like that, since the ones i've seen using VCr's have redundant data and such, but that is besides the point. I think it would be very neat to be able to do mount /dev/camcorder /backup -t minidv and then just copy files right out to the camcorder. As far as I know, this isn't possible right now, but I dont know why it shouldn't be eventually, since I dont believe digital camcorders do much to the signal coming in off firewire other than write it to the tape. Recovery might be a bit more difficult, but not impossible.
That's a broken link. Sorry; I'm not saying you lied, but I did happen to procure a drive from the exact same site, for the exact same price, from the exact same manufacturer (Aiwa). I hope you understand my confusion.
I think there is a world market for maybe five personal web logs.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Well the digital camcorder itself uses MPEG-II compression, hence the "enormous" capacity. You could just encode your data in an MPEG-II movie and achieve the same enormous capacity out of a CD-R. There's one problem. The enormous capacity exists because MPEG-II throws out 90% of the information. For highly repetitive data you might get some of your data back but for varying data you wouldn't be able to recover anything after MPEG-II compression.
Also normally you capture video off a camcorder and store it on a CD because the quality and reliability is better, hence the existance of capture boards. You're trying to do the opposite: go from a high quality storage medium to a low quality, unreliable medium.