Slashdot Mirror

Some info I found a while back whie looking into the same topic:
Rsbep (Reed-Solomon and Burst Error Protection).
Looks like the current version is 0.0.4 with the caveat "it still gives occasional bit-errors, especially in Long-Play mode or with damaged tapes." The code is doubly FEC'ing data, which seems odd, but supposedly/should increases the integrity of the data.

Just some info...

Are Rsbep - FEC for dvbackup
and dvbackup
Using them is relatively straightforward. Actually, it looks like rspep is a generic implementation of reed solomon error correction, which would make it usefull to storing information on any somewhat lossy or error-prone media.

I worry about hardware obsolescence. I think consumer commodities are relatively stable - for example, drives that read CDs should be available for decades. Similarly, using, say, MiniDV to backup stuff in larger quantities appeals to me; there was a recent Ask Slashdot about that, and the responses pointed out dvbackup (around 10 Gig per tape) and tsbep (for some error correction, making LP available, for 15 Gig per tape).

A dropped frame is a visual symptom. It doesn't tell you how much data was lost. A dropped frame doesn't necessarily mean all of the data or even any of the data for that particular frame is actually unreadable on the tape. Dropped frames have many temporary causes like dust particles on the magnetic tape, faulty cables, cosmic rays or strong RF interference hitting the electronics, buggy software, drivers or slow CPU in the case of computer DV decoding, etc. Granted, it could be a patch of tape is really damaged, causing tens or even x hundreds of bits to be lost.

Whatever the cause, a camcorder's builtin error correction can usually recover from small amounts of bad data. That's good enough for making videos but not for making backups. By using an additional layer of Reed-Solomon error correction as used in Rsbep DV Backup bad data up to 12240 consecutive bytes can be recovered, not counting any additional lower-level bad data the camcorder's internal FEC may have seen and corrected. The Rsbep guy found he could make up to 0.5mm diameter pinholes in the tape without losing data! I've seen professional data-grade backup tapes lose data after damage to a much smaller spot of 0.2mm diameter. I would say backups on MiniDV with RS error correction are feasible and cost-effective at 4USD/10GB. At 3.6Mbps, DV backups are also fast.

IANAFS but I've used a lot of different MiniDV equipment and I've never had a problem like yours with dropped frames. Maybe your DV camcorder has dirty/misaligned/worn heads any of which could cause dropped frames.

(checks page) Cool. There's an accompanying program that does error correction: rsbep takes up 14% with error-correction codes, but it can cope with 12240 consecutive bytes getting botched. So it can cope with (some) drop outs.

DVB is more common in Europe I guess.

I have the "biggest" Hauppauge DVB card, the WinTV-DVBs in my box. This is the card for sattelite broadcasts. A WinTV-DVBc exists as well which is for cable.

I use it daily. Linux support is nice !There are several projects around this family of cards (since they are all built on the same reference design, you can even exchange their software and driver on Windows I have been told). The card I am talking has hardware decoding of the media-stream. There exists a smaller one from Hauppauge which does the decoding with the CPU.

• The main site. Hosts the driver, has implemented the MHP (together with NOKIA, opensourced), and has references to the VDR project (see third link)
• the DVB driver for Linux (download page)
• Linux Video Recorder (DVB) (German, very detailed instrctions on setup and build.
• The VDR main-site
• Since the VDR was built to use the TV-Out the picture will go there. However, since they use the V4L interfaces one can use xawtv, KTV (or so) as well as the specialized Kvdr (which brings the complete VDR to the desktop). It is here (as well as an IPoverIEEE1394 and DV backup project)
• Extensions for the VDR
• VDR-NFSroot (also interesting)
• Resource and FAQ site
• Site of general DVB-s interest
• Now this guy has a dish in his garden that has several meters in diameter :-) (WARNING: for freaks)
• On EfNet IRC there is a channel #LinuxDVB. It is in German but since all Germans (well most) talk english they will help out for sure.

All in all I can say, that this is well supported and heavily used, at least in Germany. MPlayer is going to get DVB support soon (they will use its MPEG decoder for MPEG decoding).

I do not use the card for data-services, however, there is a driver for this on the drivers main-site. DVB data is one-way, so one still needs to have a modem connection open for upstream. I have been told that due to the whole continent using two or three providers the resources (bandwidth) on the sattelite is very used and xfer rates drop easily down to ISDN speed). So I would not recommend this (unless your family has rented their own transpoder).

There are people who have two or three of these cards in a small footprint Linux box, that they access over http or ssh and which is hooked to the TV. Along with some big drives they use it solely as VCR with timeshifting and also for DVD and MP3 playback (which is possible). The VDR project is LIRC compatible and has support for the WinTV-DVBs rev 2.1 IR control as well

1. PVR - record TV to hard drive, pause live TV etc.
2. basic local programming guide
3. advanced local programming guide (recommendations, sophisticated search etc.)
4. modular component fits well into home AV system

1. monthly fee
2. some tracking of user activity

1. find a way to get TV listings for your locality
2. find some PVR software (if it didn't already come with your video hardware)

For example, errors in the definition of an Essential Claim leave many, many loopholes. An example: If some patented technology is included in the later stage of a Recommendation, a patent owner can, in full compliance with the W3C procedures, obtain a patent without the need to disclose it. And that's not the only error. Basically, the patent holder decides which patents to reveal and which to hold back, and W3C cannot do anything about it. This makes most of the draft meaningless.

My submission was wirtten hastily, so it's probably full of typos,strange thoughts and lack of facts, but if you are interested nevertheless, it's available at: http://www.s.netic.de/fw/w3c-patent-policy-2001-09 -30.pdf