The Laser Playback Head of Omniscience

 

paranoia: troubleshooting

"You keep saying that word. I do not think it means what you think it means."
--Inigo Montoya, The Princess Bride

[ home | news | faq | download/svn | links/resources | documentation ]


August 29, 2006

This document describes common problems using cdparanoia. Note that "troubleshooting" addresses examples of system setup or 'pilot error'. Bugs in Paranoia are documented elsewhere (on the bugs page).

A quick note: Long ago, the only ways to read from a cdrom were to use one of two interfaces, the 'ATAPI cooked ioctl' interface or the 'generic scsi (SG)' interface. The setup and usage of these interfaces could be very tricky for users, and much of theis FAQ deals with these now-dead methods. If you're using cdparanoia 10 and a modern (2.6 or later) Linux kernel, chances are that nothing below about 'SG' or 'cooked ioctl()' interface applies to you.

Table of contents

  1. "./cdparanoia: error in loading shared libraries..."

  2. Cdparanoia says "could not find generic device to match SCSI cdrom device"

  3. Cdparanoia produces a .WAV file, but it's garbage when I play it back.

  4. (Linux) My ATAPI drive is *very* slow and /var/log/messages contains hundreds of "data underrun" messages

  5. (Linux) My ATAPI performance is poor; cdparanoia is slower than cdda2wav

  6. Extraction is very slow; the CDROM is accessed only occasionally and CPU usage is 100%

  7. Extraction is very slow; the CDROM is accessed continuously, but cdparanoia makes no apparent (or very slow) progress

  8. Cdparanoia doesn't get the track beginning and end exactly correct

  9. I can't rip the first track; I get timeout errors. Ripping later tracks works fine.

  10. Ripping across track boundaries of a TAO disc causes lots of errors

  11. When ripping the last track on a disc, the rip stops and I get "packet command error" messages.

  12. Cdparanoia says "could not find cdrom drive accessible to user"

  13. Finding my CDROM drive takes a long time!

  14. (Linux) I get an error about not having SG_BIG_BUFF defined in my kernel

  15. (Linux) I'm trying to use an ATAPI drive with SCSI emulation (or a SCSI MMC drive), and I get a file full of zeroes (silence)!

  16. My ATAPI CDROM drive reports 'unable to read any data'!

  17. (Linux) I'm trying to use SCSI emulation, but my ATAPI cdrom drive is still using the IDE ATAPI kernel driver

  18. (Linux) How do I use my ATAPI drive through IDE-SCSI hostadapter emulation?

  19. My SCSI drive is unable to read some tracks, occasionally locks up, or just behaves strangely in general

  20. (Linux) Sbpcd interface drives work poorly or not at all!


Running cdparanoia results in: "./cdparanoia: error in loading shared libraries: libcdda_interface.so.0: cannot open shared object file: No such file or directory"

These days, cdparanoia builds as an app and two shared libraries. Make install does not try to patch /etc/ld.so.conf or run ldconfig, just for safety's sake (screwing up isn't likely, but it can render a machine unusable).

First, make sure that /usr/local/lib/ (or whever you actually installed the shared libs; /usr/local/lib/ is the default for a build from source) has an entry is /etc/ld.so.conf. Second, run 'ldconfig'. Now your system knows about the shared libs.

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:

  1. The kernel has generic SCSI support compiled in (or the generic module available). Generic SCSI support does *not* mean only SCSI or SCSI CDROM.

  2. 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.

  3. 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).


Cdparanoia produces a .WAV file, but it's garbage when I play it back.

Make sure you're using a WAV player that can play CD quality data. So far, every case of a 'garbage' .WAV file has been due to a bad player. Note particularly that the 'play' utility packaged with old RedHat distros is incapable of playing CD quality WAV files.


(Linux) My ATAPI drive is *very* slow and /var/log/messages contains hundreds of "data underrun" messages

Due to a bug (either in the kernel or the CDROM itself), the CDROM drive is returning too little data for a given request. The ATAPI driver, then tries to repeat the request (and likely gets the same error again).

This error is rare these days as modern (2.6) Linux kernels offer a new default interface named SG_IO for raw access of IDE CDROMs, and cdparanoia 10 will use this interface by default. If you're stuck using an older version of linux without SG_IO (or an older versionof cdparanoia), the solution is to use your ATAPI drive with IDE-SCSI hotadapter emulation.


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 only occasionally and CPU usage is 100%

Most likely, you're using a drive that suffers from fragmentation with an older version of cdparanoia. Upgrade to a recent release.


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.


Cdparanoia doesn't get the track beginning and end exactly correct

This can happen for two reasons; one is the drive's/discs fault (discussed here) and the other is bug when using -B; that one is discussed on the
bugs page.

Drives are not required to be able to seek exactly to any position; they simply must be able to hit within one second. Add to this the fact that the disc itself is premitted to be off by a bit as well, and you can well land well too early or too late.

The good news is that such discs and CDROM drives are rare. I've not been able to reproduce reports of drive models with this problem myself, and all the untested reports are currently by Toshiba drive owners. More news on this subject as I get it; new TOC code to appear at some point in alpha 10 might provide a good workaround for this problem.


I can't rip the first track; I get timeout errors. Ripping later tracks works fine.

Alpha release 9.4 added a patch by Andreas Mueller that allows cdparanoia to read the pregap of track one. Because cdparanoia likes to begin reading a track early (to get additional information in case an error happens on a track boundary), this means that cdparanoia normally begins reading track one a few sectors early (although it does not output this data). After discussion, the developers involved and myself decided this patch wouldn't cause trouble.

Unfortunately, it turns out a small fraction of drives are totally incapable of reading the track one pregap (mostly NEC and Toshiba drives). 9.3 does not have this problem; use this older version should your drive have track one trouble with 9.4. The next release will avoid this drive limitation.


Ripping across track boundaries of a TAO disc causes lots of errors

TAO discs place a total of seven physically unreadable sectors between tracks; it's not an issue of 'a new kind of sector that old drives can't read'; the seven sectors really don't physically exist. Most drives either ignore these sectors on TAO discs, or just return a harmless error along the lines of "hey, I saw unreadable sectors". Some drives react very poorly to these sectors.

Cdparanoia will eventually include workarounds for these drives.


(Linux) When ripping the last track on a disc, the rip stops and I get "packet command error" messages.

Most likely, the session ended just before the TOC said it would, or the drive's positioning isn't exactly correct and it's managing to read a bit too far.

The problem would not be serious except that the Linux cooked-ioctl kernel interface (used by older kernels and older versions of cdparanoia) automatically tells the drive to retry.... and gets the same error which triggers a retry, etc. In this case, the solution, as above, is to use the drive with IDE-SCSI hostadapter emulation. The errors will become harmless.

Also, discs with sectors in the gaps between tracks marked as non-audio are becoming more common. Some cdrom drives complain about it. Is this another really lame attempt at copy protection? Gotta wonder....


Cdparanoia says "could not find cdrom drive accessible to user"

First, get more information about the problem by running cdparanoia with the -v option; this will show every place that cdparanoia is looking for the drive and the result of searching in each place. Chances are the problem is one of two things:

  • Permission denied: CDROM devices must be readable and writable by the user for cdparanoia to work (write access is required to send commands to the drive). When using the older SG interface, the CDROM and generic scsi devices both must be accessible. The newer SG_IO interface uses only the CDROM device.
  • No such file or device: Support for the CDROM (or generic SCSI if a drive is being used with SG) is not built into the kernel.


Finding my CDROM drive takes a long time!

Run cdparanoia with the -v option; look for the CDROM device it finds. Make a symlink from /dev/cdrom (where cdparanoia checks first) to the real device name of the CDROM drive. Things should become much faster.


(Linux) I get an error about not having SG_BIG_BUFF defined in my kernel

[This note does not apply to modern (2.6) kernels]

This was a common problem in Linux distributions until about 1999. Without the big buffer for generic SCSI reads, cdparanoia can only read a single sector from a SCSI cdrom at a time. This is too small for cdparanoia to function.

To add the big buffer, add the line:

#define SG_BIG_BUFF 65536

To the end of linux/src/include/scsi/sg.h just before the last #endif, then rebuild and install the new kernel.


(Linux) I'm trying to use an ATAPI drive with SCSI emulation (or a SCSI MMC drive), and I get a file full of zeroes (silence)!

You are using an old version of cdparanoia that doesn't know when a packet command has been rejected (this is actually hard to do under Linux). Use alpha 6 or later.

My ATAPI CDROM drive reports 'unable to read any data'!

The information below applies to older Linux kernels (2.4 and earlier) without the SG_IO interface, or older versions of cdparanoia (earlier than cdparanaoia 10) that could not use SG_IO.

Chances are that the drive is not capable of reading audio discs. To be certain, try using the drive under Linux IDE-SCSI emulation rather than with the cooked ioctl ATAPI driver. The emulation is more flexible, and cdparanoia will be able to try more possible read techniques.

Note that a few Matsushita drives (and Panasonics which are made by Matsushita) that certainly *are* CDDA capable are currently not working with cdparanoia. I'm trying to get technical information from Matsushita to correct the problem.


(Linux) I'm trying to use SCSI emulation, but my ATAPI cdrom drive is still using the IDE ATAPI kernel driver

Follow the directions in the next section *exactly*.


(Linux) How do I use my ATAPI drive through IDE-SCSI hostadapter emulation?

First off, if you're using a recent (2.6) kernel, there's no reason to do so; the 2.6 kernel offers SG_IO, which can do everything the old IDE-SCSI emulation could.

If you're stuck with Linux older than 2.6 or a version of cdparanoia before cdparanoia 10, then IDE-SCSI hostadapter emulation is recommended for ATAPI drives. To use the SCSI emulation with an ATAPI cdrom, the kernel must be configured with SCSI support, generic SCSI device support and IDE-SCSI emulation, and without ATAPI (IDE) CDROM drive support. If the kernel includes cooked ioctl ATAPI (IDE CDROM drive) support, then the kernel will always use it over the emulation interface.


My SCSI drive is unable to read some tracks, occasionally locks up, or just behaves strangely in general

Check your termination! All sorts of incredibly weird errors happen on SCSI chains without (or with too much!) termination. Real examples of termination troubles include users whose drives would work under windows but not Linux (the windows driver was turning on active termination; the Linux driver was not) all the way to a user whose computer would crash every time he tried to rip track seven of a particular disc (and he's already checked termination twice!)

As Dave Barry would say, "I'm not making this up."


(Linux) Sbpcd interface drives work poorly or not at all!

Stig Landro <slandroe@online.no> submits the following explanation and kernel patch:
cdparanoia will not work with the sbpcd.o module that comes with the 2.0.x kernels. It hangs when checking the endianness of the data. The problem is that the sbpcd module that comes with the kernel can not read more than 1 sector correctly, at least not with my type of drive. I looked into this problem some time ago and managed to get good results with your paranoia patch to cdda2wav and some small modifications of the sbpcd.c module, fixing some timing and syncronization problems. Using the same modified sbpcd module, cdparanoia III seemes to work fine, although slow. I think the reason is that only 8 sectors are read at a time. With cdda2wav(paranoiaII) I use 75 sectors as default, and it is a factor 2-3 faster. There are still some remaining problems with the sbpcd.c module though, but since this interface is getting obsolete, I guess noone bothers to fix them:

1) I must load the module manually (not automatically with kerneld) otherwise all data (at least in the first invocation of cdparanoia) seems to be set to 0.

2) It does not handle a CD change properly (does not affect cdparanoia).

I include my sbpcd.c patch below, which at least is working reasonably well on my system (100 MHz Cyrix 586 cpu & Panasonic CR563 drive).

SBPCD patch

Cdparanoia and the Laser-Playback-Head-of-Omniscience logo are trademarks (tm) of Xiphophorus. These pages are copyright (C) 1994-1999 Xiphophorus. All rights reserved.
Comments and questions about this web site are welcome.