Using a Digital Camcorder as a Tape Drive? 30
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?!
There's such a thing (Score:3)
available (Score:2)
It's as easy as 1,2,3... (Score:3)
Re:It's as easy as 1,2,3... (Score:1)
:-)
Not quite the same thing (Score:2)
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...
Re:can be done, BUT (Score:2)
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.
This kind of stuff ancient technology (Score:1)
can be done, BUT (Score:2)
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.
Not to be a jerk, but... (Score:2)
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
I asked SONY ! (Score:1)
Re:can be done, BUT (Score:1)
Yes, the compression rate for digital video used on mini-DV and Digital8 camcorders is fixed at 5:1, but that's when it's doing its normal recording of video data provided by the camera's internals. If you manage the error correction on the PC side then it might be possible to store generic data on a DV camcorder. The trick would be to implement lossless data transfer instead of the regular DV codec which is lossy. That and figuring out the camera transport controls, data redundacy, calculations for the jump to lightspeed, etc.
I obviously don't know much about the details but there is an excellent DV list at DV Central [dvcentral.org]. Someone there will have better answers than I do.
I do know that:
Eric Donaldson
ericdonaldson@bigfoot.com [mailto]
I applied for a slashdot account earlier today but haven't received my password yet. So, until then, I guess I'm still just... ;o)
another Anonymous Coward.
video editing? (Score:1)
---
Back in the day.. (Score:1)
Re:VCR Tape drives. (Score:1)
You might be thinking of Backer [danmere.com] from Danmere Electronics. [danmere.com] 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 [stack.nl] 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. [ddj.com]
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.
VCR Tape drives. (Score:1)
--
Re:MD Drive (Score:2)
However, Minidiscs have a native capacity of 140MB of compressed ATRAC audio. There is a read-only label track on each MD that distinguishes an MD Audio and MD Data disc; MD equipment looks at this label to determine what kind of disc it is accessing.
Normal Minidisc recorders, unless modified, refuse to touch MD-Data discs, thus would not work. MD-Data drives would be of questionable value because of their small 140MB capacity. 640MB MD-Data drives are supposedly in the works, but I've yet to see any concrete product.
Re:Not to be a jerk, but... (Score:2)
Re:can be done, BUT (Score:1)
Repost: Observations and Comments (Score:1)
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 [mailto] .
Re:It's as easy as 1,2,3... (Score:1)
Ill be filing for a patent on this process tommorrow.
clarifying perhaps (Score:1)
Re:Huh? (Score:1)
Huh? (Score:2)
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
No (Score:2)
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.