Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PAR2 question

64 views
Skip to first unread message

Industrial One

unread,
Dec 25, 2011, 4:25:40 PM12/25/11
to
I am using Quickpar and have experimented by manually damaging a WAV
file to test the limits of PAR2. Obviously, at some point it refuses
to repair as it needs one more block. Why can it not just repair the
damaged file as much as it can?

It would be far more preferable to have 99% of the original song/video
clip than only 80% because QuickPar bitches about the file being one
bit too damaged for it to do anything.

Willem

unread,
Dec 25, 2011, 6:16:20 PM12/25/11
to
Industrial One wrote:
) I am using Quickpar and have experimented by manually damaging a WAV
) file to test the limits of PAR2. Obviously, at some point it refuses
) to repair as it needs one more block. Why can it not just repair the
) damaged file as much as it can?
)
) It would be far more preferable to have 99% of the original song/video
) clip than only 80% because QuickPar bitches about the file being one
) bit too damaged for it to do anything.

Because that's how the underlying mathematics work.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Industrial One

unread,
Dec 26, 2011, 11:33:16 AM12/26/11
to
So if my file is 20% damaged it will completely fix it but if it's
20.1% damaged it won't do shit? That is gay.

Jim Leonard

unread,
Dec 27, 2011, 12:20:59 PM12/27/11
to
On Dec 26, 10:33 am, Industrial One <industrial_...@hotmail.com>
wrote:
> So if my file is 20% damaged it will completely fix it but if it's
> 20.1% damaged it won't do shit? That is gay.

You could "force" quickpar to "repair" the file if you lacked
sufficient parity info, but there would be (in your above example) .1%
bits incorrect all over the file. So what's worse: Knowing your file
cannot be 100% repaired, or not knowing where in your file bits are
incorrect?

PAR/PAR2 are protection against transmission error; they are not meant
to be a replacement for backups.

Industrial One

unread,
Dec 27, 2011, 12:51:19 PM12/27/11
to
On Dec 27, 5:20 pm, Jim Leonard <mobyga...@gmail.com> wrote:
> On Dec 26, 10:33 am, Industrial One <industrial_...@hotmail.com>
> wrote:
>
> > So if my file is 20% damaged it will completely fix it but if it's
> > 20.1% damaged it won't do shit? That is gay.
>
> You could "force" quickpar to "repair" the file if you lacked
> sufficient parity info, but there would be (in your above example) .1%
> bits incorrect all over the file.  So what's worse:  Knowing your file
> cannot be 100% repaired, or not knowing where in your file bits are
> incorrect?

How do I do that? I don't see that option anywhere in Quickpar.

And if it's a song or a video then it's always better to have 99.9% of
the file instead of only 80%.

Jim Leonard

unread,
Dec 29, 2011, 12:10:23 PM12/29/11
to
On Dec 27, 11:51 am, Industrial One <industrial_...@hotmail.com>
wrote:
> > You could "force" quickpar to "repair" the file if you lacked
> > sufficient parity info, but there would be (in your above example) .1%
> > bits incorrect all over the file.  So what's worse:  Knowing your file
> > cannot be 100% repaired, or not knowing where in your file bits are
> > incorrect?
>
> How do I do that? I don't see that option anywhere in Quickpar.

By using quotes, I was implying a theoretical operation. You cannot
actually force quickpar (or PAR2, which is what you should actually be
using since it's not memory-constrained, slow, or broken like quickpar
is) to just make up parity information.

> And if it's a song or a video then it's always better to have 99.9% of
> the file instead of only 80%.

Personal preference. Some media players can deal with and discard bad
bits; others crash.

Willem

unread,
Dec 29, 2011, 1:35:38 PM12/29/11
to
Jim Leonard wrote:
) On Dec 27, 11:51?am, Industrial One <industrial_...@hotmail.com>
) wrote:
)> > You could "force" quickpar to "repair" the file if you lacked
)> > sufficient parity info, but there would be (in your above example) .1%
)> > bits incorrect all over the file. ?So what's worse: ?Knowing your file
)> > cannot be 100% repaired, or not knowing where in your file bits are
)> > incorrect?
)>
)> How do I do that? I don't see that option anywhere in Quickpar.
)
) By using quotes, I was implying a theoretical operation. You cannot
) actually force quickpar (or PAR2, which is what you should actually be
) using since it's not memory-constrained, slow, or broken like quickpar
) is) to just make up parity information.

I'm not sure that it's even theoretically possible to have quickpar/par2
partially repair a file. They use one CRC per block to identify the bad
blocks, and you need N 'good' blocks (of the N+M data+parity) to get the
original N data blocks back at all. So too much damage is just too much
damage.

Captain Obvious

unread,
Dec 31, 2011, 11:26:07 AM12/31/11
to
IO> So if my file is 20% damaged it will completely fix it but if it's
IO> 20.1% damaged it won't do shit? That is gay.

There is a tradeoff between being able to fix as much damage as possible no
matter where it is and providing a partial recovery options.

That is, if checksum information is enough to repair 20% of damage on the
whole file, same amount of information can be used to repair 10% of damage
in each half.

I.e. in the first case, you can have damage distributed in any way -- it can
be 20% of damage in the beginning or 20% of damage in the end. or split
10%/10% or split 5%/15% -- no matter what, it would be repair.

In the second case it would repair up to 10% of damage in each part. I.e. if
first part is 7% damaged and second is 13% damaged, first will be repair
while second will be not, even though total damage is only 20%.

There are other kinds of tradeoffs, of course, but I doubt they will suit
you better.

0 new messages