[Paranoia] Getting paranoia to quit on CD eject

Bill Davidsen davidsen at tmr.com
Wed Oct 20 10:16:43 PDT 2004


On Tue, 19 Oct 2004, Peter Jones wrote:

> On Tue, 2004-10-19 at 10:27 -0400, Bill Davidsen wrote:
> 
> > What I had in mind was either (a) have a signal like usr1 mean skip to
> > start of next track and just give up, or (b) putting a limit on how long
> > in real time will be spent on a track before punting to the next.
> 
> Ick, anything with signals is bad.  This is a library, after all.  What
> if the calling appliation wants to use SIGUSR1 itself?

Paranoia IS the application, I wasn't suggesting to put it in the library.
> 
> > These are not mutually exclusive, nor the only useful ways to tackle the
> > problem. But options to quit after N errors (or try less hard on that
> > track) and/or do the same after some elapsed clock time might be generally
> > useful.
> 
> Yeah, that's my thought.  But really, I'd rather if there were just a
> way to let the calling application decide the policy when the situation
> occurs.
> 
> > The harder any ripping program has to work the less confidence I have 
> > in the result.
> 
> I'm not at all sure what you mean by that.

The more times data needs to read from the media before the application
decides it probably has valid data the less likely it does. If no reads
return without error, then even if 80% return the same value it's not 80%
probable that it's the original data. If it takes ten reads to get two
without error and they match then the read data is more likely to be
correct. And if multiple reads without error *don't* return the same data
then the error detection just isn't working, usually due to bad hardware
or firmware.

-- 
bill davidsen <davidsen at tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.



More information about the Paranoia mailing list