Re: [parchive-devel] Par2 Par3 comments.

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

Hello, Michael Nahas
 I am Yutaka Sawada.
Even if you are not writing PAR3 specifications,
your comments as PAR2 designer are helpful.


> "My programing skill is not so high, and I can not write
> standard C++ code." - Yutaka Sawada
> Does this not worry anyone?!

 Don't worry.
I am making only a sample application of PAR3.
When PAR3 spec becomes stable,
other high skill programers like Peter Clements or 
Peter Cordes will create much better PAR3 clients.
If I miss something, other one may find the bug.


> What problems are you trying to solve with Par3?

 I want to solve as possible as I can.
Michael Nahas did very good job at PAR2 design.
I copy most of PAR2 spec and fix only some small parts.
In PAR2 specifications, there seems to be no serious problem,
which can not be solved by conbining other method.
Many people use old obsolete PAR2 clients still now.
A simple solution by users are like below;

> * Fix the bug in the Reed-Solomon algorithm.
 Create more recovery slices.

> * Support a faster algorithm
 Use faster PC.

> * Support for Unicode/UTF-8?
 Don't use Unicode filename.

> * Support for large files / more slices?
 Use RAR (archive files and split).

> * Lower overhead in Par2 files?
 Use larger media/drive or faster network.

> * Support large numbers of files?
> * Better support for directories?
> * Use with CD/DVD/? disk images.
 Use archiver like TAR/ZIP/RAR.

 But, those solutions are not convenient for users.
When PAR3 will be used widely, it is not only for skilled PC users,
but it is for novice lazy users also.
This is a difference between, possible to do, and easy to do.
I think users want utility.


>  mail by me at 2010-05-23
> User can make both PAR2 and PAR3 files for same recovery set.
> Even if there is no compatibility in packet level,
> PAR files can contain both PAR2 packets and PAR3 packets same time.
> PAR2 client reads PAR2 packets, and PAR3 client reads PAR3 packets.

 As I write ago, PAR3 file can be constructed as PAR2 format
by adding some extra packets.
There are three packet form selections;
(2.0) PAR2 body data with PAR2 packet header - PAR2 spec,
(2.5) PAR3 body data with PAR2 packet header - previous PAR3 spec, and
(3.0) PAR3 body data with PAR3 packet header - new PAR3 spec.

 Because a PAR2 client can not understand PAR3 data anyway,
I thought using PAR2 packet header for PAR3 data might be useless.
The difference is parser of a PAR3 client.
In (2.5), a PAR3 client search PAR2 packet header,
and read PAR3 body data and common PAR2 body data.
In (3.0), a PAR3 client search PAR3 packet header,
and read PAR3 body data.
Both method works well to collect PAR3 data.

 Only the problem of using packet (2.5) is that,
PAR2 packet header is inefficient.
Then I made smaller compact PAR3 packet header.
If PAR3 file consists in PAR2 packets and additional PAR3 packets,
it becomes larger than PAR2 file.
If PAR3 file consists in PAR3 packets with smaller header,
it becomes smaller than PAR2 file.

 To be clear compatibility, I updated PAR3 specification draft.
I added a new optional packet, "PAR2 Container packet".
PAR2 index file can be included in PAR3 file.
In my latest PAR3 sample of MultiPar v1.1.5.5,
there is a option, "Create PAR 2.0 compatible PAR3 file".
Because basic mechanism of PAR3 is same as PAR2,
(just packet header and checksum are different)
PAR3 client can create PAR3 packets and PAR2 packets in same time.
I tested with QuickPar and phpar2.exe.
Both PAR2 clients can read PAR3 files and verify input files with them.


> I don't know if libpar2 uses the trick I showed Peter Clements,
> but it was to split 16-bit computations into high and low-byte operations.

 It uses the trick. (and my PAR2 client also.)
Thank you for good sample implementation.
I hope that you would make a sample of PAR3.


> I strongly recommend against changing exist ASCII names to be UTF-8,
> since it would not be backwards compatible.

 You may be miss-understanding.
UTF-8 is compatible when the filename is ASCII.
So, ASCII filenames are not changed by UTF-8 encoding.

 If a filename contains non-ASCII characters,
"ASCII char array" can not represent it anyway.
By following standard PAR 2.0 specifications,
Unicode Filename packet is required to support Japanese characters,
but there were no PAR2 clients which support the optional packet.
(This was why I made my PAR2 client for Japanese.)
Because converting between UTF-16 and UTF-8 is always possible,
UTF-8 will be better than optional Unicode Filename packet.


> what will convince people to switch from Par2 to Par3?

 Read forums of QuickPar and ICE ECC.
Both are well used file repairing soft with GUI for Windows OS.
The lack/weak-point of them will become the reason.
There are some other applications without GUI,
but they are not useful for general novice users.

 Now, PAR3 file is compatible with PAR2,
and it is smaller/faster/convenient than PAR2.
PAR3 can solve most problems of PAR2.
While the problems of PAR2 are not serious for skilled users,
some novice users are annoying to solve them by themselves.
I am making PAR3 for the general public users.


Best regards,
Yutaka Sawada