Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #662 > unrolled thread

PAR2 question

Back to article view | Back to comp.compression

Contents

  PAR2 question Industrial One <industrial_one@hotmail.com> - 2011-12-25 13:25 -0800
    Re: PAR2 question Willem <willem@turtle.stack.nl> - 2011-12-25 23:16 +0000
      Re: PAR2 question Industrial One <industrial_one@hotmail.com> - 2011-12-26 08:33 -0800
        Re: PAR2 question Jim Leonard <mobygamer@gmail.com> - 2011-12-27 09:20 -0800
          Re: PAR2 question Industrial One <industrial_one@hotmail.com> - 2011-12-27 09:51 -0800
            Re: PAR2 question Jim Leonard <mobygamer@gmail.com> - 2011-12-29 09:10 -0800
              Re: PAR2 question Willem <willem@toad.stack.nl> - 2011-12-29 18:35 +0000
        Re: PAR2 question "Captain Obvious" <udodenko@users.sourceforge.net> - 2011-12-31 18:26 +0200

#662 — PAR2 question

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.

[toc] | [next] | [standalone]

#663

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

[toc] | [prev] | [next] | [standalone]

#664

On Dec 25, 11:16 pm, Willem <wil...@turtle.stack.nl> wrote:
> 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

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.

[toc] | [prev] | [next] | [standalone]

#665

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.

[toc] | [prev] | [next] | [standalone]

#666

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%.

[toc] | [prev] | [next] | [standalone]

#667

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.

[toc] | [prev] | [next] | [standalone]

#668

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.


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

[toc] | [prev] | [next] | [standalone]

#672

 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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compression

csiph-web