Cdparanoia says "could not find generic device to match SCSI cdrom device"
[this error happens only when using the SG interface; modern kernels
offer a newer SG_IO interface which is preferred by cdparanoia]
This error means exactly what it says; the generic SCSI devices are
missing, unusable or have permissions set to deny access by users.
First, a bit of explanation...
When using the old 'sg' (scsi generic) interface, cdparanoia doesn't
actually use the 'normal' SCSI cdrom device, typically /dev/scd* or
/dev/sr*; it uses (and requires) a generic SCSI device (typically
/dev/sg*) to access a drive's audio extraction features. Cdparanoia
does accept the CDROM device name because users are used to this
device specifying a cdrom drive, but only uses the CDROM device name
to map to a matching generic SCSI device.
If cdparanoia can't get to a working set of generic devices, it can't
use a SCSI drive with the sg interface. Before sending mail, check that:
- The kernel has generic SCSI support compiled in (or the generic
module available). Generic SCSI support does *not* mean only SCSI or
SCSI CDROM.
- Those using ATAPI CDROM drives with IDE-SCSI emulation must *not*
have ATAPI CDROM support included. ATAPI IDE-SCSI emulation users
must have all the appropriate SCSI support selected.
- The generic SCSI devices (/dev/sg*) must exist and be accessible.
Check that permissions on the device entries allow user or group read *and*
write access (it's safest to grant user or group access only to the device
matching the cdrom).
My ATAPI performance is slow; cdparanoia is slower on my ATAPI drive than cdda2wav.
Again, this problem is rare on 2.6 with the new SG_IO interface for ATAPI cdrom drives.
On older kernels or with older versions of cdparanoia that are using
the 'cooked ioctl()' kernel interface, the kernel only reads 8 sectors
from an audio CD at a time. If you tell it to read more than eight,
it will divide the request up into 8-sector chunks. Alignment and
jitter errors are most likely to happen on those boundaries.
Cdparanoia is aware of this, and thus only requests 8 sectors at a
time when using the cooked ioctl() interface.
The kernel overhead involved in each request is farily high, so this
is inefficient; however, the goal is to be correct, not fast.
cdparanoia is slower on ATAPI drives than, for example, cdda2wav
because it's being more careful (cdda2wav makes larger requests and
doesn't track boundaries).
If you're concerned about performance and are stuck using an old
kernel or old cdparanoia, use the SG driver and IDE-SCSI hostadapter emulation. SG is superior to
the ATAPI interface for several additional reasons.. However, if you
absolutely *must* use the ATAPI interface, the following
kernel/cdparanoia mods will help you out.
-
In linux/drivers/block/ide-cdrom.h, increase the value of
CDROM_NBLOCKS_BUFFER from 8 to a larger value (eg, 16). Rebuild the
kernel.
-
In cdparanoia/interface/cooked_interface.c, change the
value of d->nsectors on line 205 to the same value you used in the
kernel.
Extraction is very slow; the CDROM is accessed continuously, but cdparanoia makes no apparent (or very slow) progress
I recently discovered the existence of drives with a bimodal jitter
pattern (just before the release of alpha 9.4). Essentially, these
drives jitter in two different patterns; one is a constant amount of
slight jitter followed by periods of very large jitter. The current
automatically adjusting overlap code in cdparanoia will choose too
small an overlap value for these drives to function.
For these drives, I've temporarily provided a switch (-o) to force the
overlap setting to a specific value. If your drive exhibits this
behavior, try forcing the overlap to a specific value. You'll likely
have to experiment to find the best choice; try ten or so to begin.
As before, the next release will update the algorithm to address this
newly discovered problem.
