Questions about using Paranoia and cdparanoia Requirements to run cdparanoia 10 A CDDA capable CDROM drive (in 2008, virtually all CDROM drives are) Linux 2.0 through 2.2: kernel support for the particular CDROM in use kernel support for the generic SCSI interface (if using a SCSI CDROM drive) and proper device (/dev/sg?) files (get them with the MAKEDEV script) in /dev. Most distributions already have the /dev/sg? files. Linux 2.4, through 2.6: kernel support for either the generic SCSI of SG_IO interfaces; most modern kernels are built with SG_IO by default. The cdparanoia binary will likely work with Linux 1.2 and 1.3, but I do not actively support kernels older than 2.0 I do know for a fact that the source will not build on kernel installs older than 2.0, but the problems are mostly related to the ever-changing locations of proprietary cdrom include files. -------------------------------------------------------------------------------- Does Cdparanoia support ATAPI drives? SCSI Emulation? USB drives? Parallel port drives? Cdparanoia 9 and 10 support the full ATAPI, IDE-SCSI and SCSI generic interfaces under Linux. Cdparanoia 10 adds SG_IO support, which it the default interface for all modern CDROM drives under linux 2.6. Note that the native 'cooked' ATAPI driver is supported, but should be considered deprecated; SG_IO and IDE-SCSI emulation both work better with ATAPI drives. This is an issue of control; the other interfaces gives cdparanoia complete control over the drive whereas the native ATAPI driver insists on hiding the device under an abstraction layer with poor error handling capabilities. Note also that a number of ATAPI drives that do not work at all with the ATAPI driver (error 006: Could not read audio) *will* work with SG_IO and IDE-SCSI emulation. USB drives are fully supported through the SG_IO and SG interfaces. Parallel port based CDROM (paride) drives are not yet explicitly supported. -------------------------------------------------------------------------------- I can play audio CDs perfectly; why is reading the CD into a file so difficult and prone to errors? It's just the same thing. Unfortunately, it isn't that easy. The audio CD is not a random access format. It can only be played from some starting point in sequence until it is done, like a vinyl LP. Unlike a data CD, there are no synchronization or positioning headers in the audio data (a CD, audio or data, uses 2352 byte sectors. In a data CD, 304 bytes of each sector is used for header, sync and error correction. An audio CD uses all 2352 bytes for data). The audio CD *does* have a continuous fragmented subchannel, but this is only good for seeking +/-1 second (or 75 sectors or ~176kB) of the desired area, as per the SCSI spec. When the CD is being played as audio, it is not only moving at 1x, the drive is keeping the media data rate (the spin speed) exactly locked to playback speed. Pick up a portable CD player while it's playing and rotate it 90 degrees. Chances are it will skip; you disturbed this delicate balance. In addition, a player is never distracted from what it's doing... it has nothing else taking up its time. Now add a non-realtime, (relatively) high-latency, multitasking kernel into the mess; it's like picking up the player and constantly shaking it. CDROM drives generally assume that any sort of DAE will be linear and throw a readahead buffer at the task. However, the OS is reading the data as broken up, seperated read requests. The drive is doing readahead buffering and attempting to store additional data as it comes in off media while it waits for the OS to get around to reading previous blocks. Seeing as how, at 36x, data is coming in at 6.2MB/second, and each read is only 13 sectors or ~30k (due to DMA restrictions), one has to get off 208 read requests a second, minimum without any interruption, to avoid skipping. A single swap to disc or flush of filesystem cache by the OS will generally result in loss of streaming, assuming the drive is working flawlessly. Oh, and