self repairing disc

[DaveEL]

Originally posted by Pamel
@DaveEL: You numbers are not quite right. First you must know that there are two versions of PAR, 1.0 and 2.0.

Check the post date its before par 2.0 this is a very old thread.

DaveEL

[avih]

sounds like PAR2 could be usefull as an extra protection. if one wants, one can put the PAR2 file as a mode2form1 (protected) file on the cd as well. however, i don't think it will be usable in real time playback, since it sounds to me as if it would take quote a long time to correct an error.

however, if one copiees the movie file to the HD (dat2file or xcd2file when the backup protection is incorporated), then the PAR2 file could be used to correct the data.

nice.

[Atamido]

Originally posted by DaveEL
Check the post date its before par 2.0 this is a very old thread.

Though the draft was just finalized, it has been mostly completed for a very long time. In fact, the first drafts were being drawn up shortly after 1.0 was released. Ironically I didn't even realize that the final draft was released until writing this post. Thanks DaveEL

But really, Parchives are just an implementation of the same old Reed-Solomon encoding that have been used on optical discs forever. So, the idea is to use reed-solomon encoding to increase error protection at a non-hardware level to make it more flexible for the amount you want to use each time.

[Atamido]

Originally posted by avih
however, i don't think it will be usable in real time playback, since it sounds to me as if it would take quote a long time to correct an error.

In the case of a whole file, this is very true. But, if you are dealing with much smaller data chunks, as would be used within Matroska, then it should be easy to do on the fly.

[avih]

pamel, i guess you could be right, however, you'd need to implement it at the matroska level, which will make it hard to 'fix' a scratched cd to recreate the original clip without specialized matroska tools.

my idea was of an optional supplemental ECC facility for the file as a whole, to retain the original clip as much as possible, in an off-line type of execution, and with standard tools.

i think it's important that users will be able to correct scratched CDs and recreate the original. although a JIT ECC would be nice as well of course

[DaveEL]

Originally posted by avih
pamel, i guess you could be right, however, you'd need to implement it at the matroska level, which will make it hard to 'fix' a scratched cd to recreate the original clip without specialized matroska tools.

Wouldn't a simple remux do as it would read it and correct the errors and then when you write it creates the ECC again.

DaveEL

[Atamido]

Originally posted by DaveEL
Wouldn't a simple remux do as it would read it and correct the errors and then when you write it creates the ECC again.

Thats the idea. Or rather, you shouldn't even have to worry about it because you SHOULD be able to have the blocks repaired on the fly. This would mean that a damaged CD would still be watchable with a little more CPU power.

[Alestrix]

Kinda "overread" this interesting thread and thought to share my thoughts:

Originally posted by Pamel
Or rather, you shouldn't even have to worry about it because you SHOULD be able to have the blocks repaired on the fly.

Information about the file having (correctable) errors should still be given to the user, though. This way the user can recreate a fixed CD before the number of errors increases to a unrepairable amount.

- Alex

PS: looks like I'm gonna add par2 information to my XCDs from now on

[temporance]

Originally posted by Pamel
Thats the idea. Or rather, you shouldn't even have to worry about it because you SHOULD be able to have the blocks repaired on the fly. This would mean that a damaged CD would still be watchable with a little more CPU power.

Depending on the scheme, it could take a lot more CPU power and disk access to recreate the damaged blocks. If you use a 3MB parity file to protect any contiguous 3MB data segment, then you need to scan in the whole disk in order to reconstruct any of the missing data. Not practical on the fly.

If you use a error correcting code with finer granularity (so that it can be corrected on the fly), you need more overhead to achieve a comparible level of protection - that's what's done on a conventional 650MB CDROM.