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
