[vorbis] cdparanoia mailing list ?

[Andy Dale]

yeah, since the original email, [vorbis] cdparanoia mailing list? question
was answered and we all learned that there was a cdparanoia mailing list,
howz about we move this discussion there and off of the [vorbis] user list?
;)

Andy
andycool22 at peoplepc.com

----- Original Message -----
From: "Ed Sweetman" <ed.sweetman at wmich.edu>
To: <vorbis at xiph.org>
Sent: Friday, March 15, 2002 4:44 PM
Subject: Re: [vorbis] cdparanoia mailing list ?

<p>: On Fri, 2002-03-15 at 15:52, Monty wrote:
: >
: >
: >
: > On Fri, Mar 15, 2002 at 03:18:02PM -0500, Ed Sweetman wrote:
: > > I've never seen any atapi ide cdrom not work with the standard ide
cdrom
: > > driver.
: >
: > This is mostly an issue for older drives.  Any MMC compliant drives will
at
: > least mostly work with the ATAPI driver.
: >
: > Cdparanoia knows about fifty different historical/proprietary read
: > commands.  The kernel IDE/ATAPI interface knows one (two if you turn
: > on some ifdefs).
: >
: > > As for configuring as scsi, you may get some kind of driver
: > > error checking, maybe.
: >
: > Yes, bigtime.  The ATAPI interface, upon seeing any reported error will
: > retry forever until it gets 'a good read'.  This is a good way to
: > cause damagaed/defective discs or buggy drives to just randomly never
: > finish.
:
: I dont know about it being random, if it's a damaged disk it's sort of a
: given of when it's going to loop.  On those tracks cdparanoia keeps
: trying and trying and trying with error correction on,  so i resort to
: -Z and take whatever crap i get from that disk error to get the rest of
: the track rather than not get it at all or only partially.  I dont see
: how the scsi interface is going to "fix" these disc errors, It would
: either stop the rip of that track upon the error and thus stop
: cdparanoia or it would stop the rip of the track and cdparanoia would
: continue ahead, giving you a skip (how audio cdplayers deal with errors)
: Something that cdparanoia could very well do on it's own upon meeting an
: error that just wont go away for one reason or another.
:
: > >  But you cant beat the ide cdrom driver for ide
: > > drives, especially with the DMA transfer patch.  Ripping with dma
means
: > > you use about 2% to negligable cpu to read audio cds.
: >
: > That patch breaks some of cdparanoia's error checking badly.
: > Specifically, it will make it harder for cdparanoia to detect
: > unreported sector boundary errors because that DMA patch is actually
: > splitting requests into single sector transfers and cdparanoia will
: > not be able to detect or prevent it.  Cdparanoia's checking algorithms
: > all assume >1 sector transfers.
: >
: > It makes it much more likely that skipping/loss of streaming will not
: > be detected, especially if the drive manages to screw up boundaries
: > consistently, a problem in many models.
:
:
: from what i read in the patch and from what i've understood from the
: maintainer, it only does single sector transfers when it experiences an
: error (single frame dma transfer i'm assuming is your single sector dma
: transfer).   The patch then tries again using this single frame, if it
: recieves another read error it will revert to multi frame pio (plain
: functionality from the ide cdrom driver now).  So you get multi-frame
: dma by default with the patch, but if an error occurs it drops to single
: frame dma and if still an error is found it drops to multi pio.
:
: That said, i haven't had any problems with cdparanoia reporting errors
: in the same places that it used to report errors, just without all the
: cpu usage.
:
: > > The scsi driver
: > > wont do that for ide drives i dont believe.
: >
: > The SCSI driver has always used DMA, even implementing memory
: > scatter/gather, something the IDE patches can't do (thus the single
: > secotr tranfers).
: >
: > Monty
: >
:
: hrmm, I'll have to try the scsi driver to see if it's dma audio ripping
: is any better than this patch is for me.
:
:
: --- >8 ----
: List archives:  http://www.xiph.org/archives/
: Ogg project homepage: http://www.xiph.org/ogg/
: To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
: containing only the word 'unsubscribe' in the body.  No subject is needed.
: Unsubscribe messages sent to the list will be ignored/filtered.
:

<p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.