Re: [parchive-devel] Par2 Par3 comments.

[<te...@ma...>]

Hello, parchive developers.
 I am Yutaka Sawada.
Michael Niedermayer 's proposal to use concatenation
is interesing and will be useful.
But, simple concatenation is hard to implement without using
large temporary file as Michael Nahas said.
When an user protect 5GB data with 500MB recovery file for DVD,
he needs additional 5GB free space to keep joined file temporary.
Because my HDD is slow and small,
I don't want to to use large temporary file for my usage.
How users think additional free disk space ?
Or DVD users have large enough HDD normally ?

 from Niedermayer's previous mail;
> and simply concatenation:
> [.......... 
> ..file1.... 
> ........... 
> .....][.... 
> ........... 
> ...file2... 
> ..........] 
> [.......... 
> ...file3... 
> ...][...... 
> file4...][.  <-- partial damaged slice #1
> file5.][f6]  <-- partial damaged slice #2

> If you now for example loose file5 
> you need 1 slice to recover it not 2 
> In each column you have only 1 lost symbol for file5,
> thus you never need more than 1 slice to recover it 

 The idea is a partial damaged slice.
In PAR2, there are two types of input slices;
complete slice and damaged slice.
I note "partial damaged slice #1 and #2" in your sample.
However those two partial damaged slices are not damaged
in same offset, I need 2 recovery slices anyway.

 Caution: (Unknown position) Error Correction requires
double recovery symbols than (Known position) Erasure Correction.

 There is no way to check, which byte is complete or damaged in
multiple partial damaged slices.
Even if a damaged part is one side of two partial damaged slices,
it is treated as unknown position error,
then it requires two recovery slices.
The problem is information, which part is damaged or complete.
PAR client keeps it for each slices.

 When there are 3 or more partial damaged slices,
Error Correction may help.
For example, 2 recovery slices can recover 3 partial damaged slices,
if only one part is damaged in 3 slices at same offset.
The offset of damaged byte is the key.
Error Correction is useful,
only when they are different each others.
It is possible, but will be rare case ?
In this case: splited slice in simple concatenation,
it can not help.



 from Re: [parchive-devel] QuickPar use cases;
> use libnoe, it will correct your damaged bytes
> (if theres sufficient redundancy of course only)

 I omitted the Error Correction capability from
my sample implementation of PAR3.
I thought the usefulness might be rare.
Only when there are many partial damaged slices,
and the damaged parts are different offsets,
it becomes useful.
However I can modify my sample to use that feature of libnoe,
is this worth to do ?

 Because James Plank's RS implementation is Erasure Correction,
partial damaged slices are available for Niedermayer's libnoe
style RS_FFT only.
Unknown Error Correction will become an interesting feature
of PAR3, or strange gadget ?
There is no problem in implementation,
partial damaged slices can be taken while file verification,
libnoe has that feature already.
But, recoverying speed will become a little slow.


Best regards,
Yutaka Sawada