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

[Blake Jones]

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

> 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