Re: [Libcdio-devel] Spurious corrections from cdparanoia?

[Rocky Bernstein]

On Fri, Nov 4, 2011 at 10:26 AM, Blake Jones <address@hidden> wrote:

> On Tue, Nov 1, 2011 at 11:00 PM, Rocky Bernstein wrote:
> > The first and obvious question is what do CD paranoia 10.2, cued
> > or EAC do with ths?
>
> I haven't tried cued, and I don't have access to a Windows machine to
> try EAC.  And I should have said in my previous message that the
> "libcdio 0.83" that I was using was, in fact, the prototype merge with
> CD Paranoia 10.2 that you had alluded to in an earlier email.
>
> > I had a vague and second-hand understanding that cdparanoia had a way
> > to figure out from the drive when it is better and totally burning of
> > paranoia. It is possible that cued or EAC compares rips with and
> > without paranoia.
>
> Do you (or does anyone else) have enough experience with modern drives
> to suggest how important paranoia's corrections are these days?


I don't. Perhaps someone else does.


> Maybe
> the right answer is just to revert back to straight rips for most
> things.
>
> > Is this a fair paraphrase of the situation?: Because two noncontiguous
> > final blocks are zero (which probably means there is silence),
> > cdparanoia considers the second a jitter of the first or vice versa?
>

The comment (presumably Monty's) in lib/paranoia/paranoia.c suggests that I
have this wrong, or at least
this is not the intent:

    audio is now treated as great continents of values floating on a
    mantle of molten silence.  Silence is not handled by basic
    verification at all; we simply anchor sections of nonzero audio to a
    position and fill in everything else as silence.  We also note the
    audio that interfaces with silence; an edge must be 'wet'.

So if I understand correctly two blocks of silence should not get confused
since they don't exist.



> And those other two blocks which were confused are also silence as
> > well?
>
> Yes, I believe this is what's happening.
>
> > Do I have it correct that things that are uniformly close to 0000 or
> > ffff are both silence because it what is looked for is lots of
> > *changes* in amplitude. (If this is correct, would any repeated 16-bit
> > value also be silence? For example 5555, 5555, or even 1234 1234?)
>
> I'm no expert here, but according to Wikipedia, the digital audio data
> on the CD is stored as *signed* 16-bit Linear PCM -- so 0xffff is
> actually very close to 0x0000.  So I believe your examples of 0x5555 and
> 0x1234 would not be treated as silence.
>

Ok. Thanks for the information.

>
> > Since talk is cheap.  So suppose one measured the amount of entropy in
> > the block. One way this could be done is by running a compressor like
> > bz2 and seeing that the data greatly compresses. Or perhaps a
> > compression library has the ability to give you the entropy without
> > compressing.)
> >
> > So is the suggestion to do discourage jitter if the entropy is low?
>
> That was the general thought that had occurred to me.  Given the amount
> of data being crunched, one would want to use the most absolutely
> stone-simple compressor possible; bzip2 would cause rip times to go
> through the roof.  Ultimately it would just be another heuristic, but
> I don't think there are any perfect answers here.
>
> Blake
>
>