CDDA Paranoia FAQ ---------------------------------------------------------------------------- "Suspicion Breeds Confidence!" --Brazil ---------------------------------------------------------------------------- April 4, 1998 If you have a question I haven't answered below, send me mail; good ones go on the list :-) cdparanoia (Paranoia III) FAQ file ---------------------------------------------------------------------------- What is cdparanoia? The Paranoia-III CDDA reader distribution ('cdparanoia') is a complete rewrite of Heiko Eissfeldt's 'cdda2wav' and my own 'Paranoia' series of patches. Like the original cdda2wav, this package reads audio from the CDROM directly as data, with no analog step between, and writes the data to a file or pipe in WAV, AIFC or raw 16 bit linear PCM. However, cdparanoia takes a different angle on the cdda ripping process. It contains few-to-no 'extra' features, concentrating only on the ripping process and knowing as much as possible about the hardware performing it. Cdparanoia will read correct, rock-solid audio data from inexpensive drives prone to misalignment, frame jitter and loss of streaming during atomic reads. Cdparanoia will also read and repair data from CDs that have been damaged in some way. At the same time, however, cdparanoia turns out to be easy to use and administrate; It has no compile time configuration, happily autodetecting the CDROM, its type, its interface and other aspects of the ripping process at runtime. A single binary can serve the diverse hardware of the do-it-yourself computer laboratory from Hell... Bundled with cdparanoia are the cdda_interface and cdda_paranoia libraries which allow Paranoia III functionality to be used by any application. Contact me for more details about the Paranoia III standalone libs. ---------------------------------------------------------------------------- Requirements to run cdparanoia (as of alpha 3) 1. A CDDA capable CDROM drive (ATAPI, SCSI, or proprietary) 2. Linux 2.x.x 1. kernel support for the particular CDROM in use 2. 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. The cdparanoia binary will likely work with Linux 1.2 and 1.3, but I do not actively support kernels older than 2.0.x. 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. Also, although a stock SCSI setup will work, performance will be better if linux/include/scsi/sg.h defines SG_BIG_BUFF to 65536 (it can't be bigger). Recent kernels (2.0.x+?) already set it to 32768; that's OK. Cdparanoia will tell you how big your generic SCSI buffer is. Unlike cdda2wav, cdparanoia does not require threading, IPC or (optionally) sound card support. /proc filesystem support is no longer required, and /dev/sr? or /dev/scd? devices are not required for SCSI, although they do add functionality if present. ---------------------------------------------------------------------------- Is cdparanoia / Paranoia III portable? Not yet, although they will be ported to other UNIX flavors in the near future. Quite a bit of code is devoted to OS-specific problems, and that will require painful re-writing. OTOH, Linux was probably the most painful UNIX flavor to implement cdparanoia for, so the others should take less effort. The CDROM drives themselves are all the same models as various Linux machines would use, so there are no changes there. ---------------------------------------------------------------------------- Missing Features (relative to cdda2wav) Specifically, 'cdparanoia' will not play to sound cards, do MD5 signatures, read CD catalog or serial numbers, search indexes, do rate reduction, or generally make use of the maximum speed available from a CDROM drive. If your CDROM drive is *not* prone to jitter and you don't have scratched discs to worry about, you might want to look at the original cdda2wav for features cdparanoia does not have. ---------------------------------------------------------------------------- What is that weird bargraph during ripping? It's a progress/status indicator. There's a completion bargraph, a number indicating the sector number of the read currently happening, and a heartbeat indicator to show if the process is still alive, hung, or spinning. The bargraph also marks points during the read with characters to indicate where various 'paranoia' features were tripped into action. - A hyphen indicates that two blocks overlapped properly, but they were skewed (frame jitter) + A plus indicates not only frame jitter, but the presence of jitter in the middle of an atomic read from the hardware X An "X" indicates a scratch was caught * An asterisk indicates a scratch and jitter both occurred in this general area of the read V A V indicates a skip that could not be repaired or a sector totally obliterated on the medium (hard read error). ---------------------------------------------------------------------------- How can I tell if my drive would be OK with regular cdda2wav? Easy. Run cdparanoia; if the progress meter never shows any characters but the little arrow going across the screen, the CDROM drive is probably one of the (currently) few drives that can read a pristine stream of data off an audio disc regardless of circumstances. This drive will work quite well with cdda2wav (or cdparanoia using the '-Z' option) A drive that results in a bargraph of all hyphens would *likely* work OK with cdda2wav, but it's less certain. Any other characters in the bargraph (colons, semicolons, pluses, Xs, etc..) indicate that a fixups had to be performed at that point during the read; that read would have failed or 'popped' using cdda2wav. ---------------------------------------------------------------------------- I have a 10x (or 18x or 24x) CDROM drive; Why does cdparanoia only read at 1x or less? Cdparanoia must make multiple short passes over the data to verify it. On average, cdparanoia reads each sector on the cd three times before writing it. Rereading sectors is vital to cdparanoia's verification and cache-defeating algorithm (tell me, please, what moron decided to make the ATAPI spec such that there's no way to force media access or invalidate the cache?) In addition to the 3-4x hit from using cdparanoia with default options, many CDROM drives advertised from 2x all the way up to 24x can only read CDDA at 1x. Eit. You're doomed to wait. For these reasons, the read can be very slow on otherwise 'high speed' drives... Various stages of Paranoia checking can be disabled for faster performance if necessary; with -Z, cdparanoia will operate like cdda2wav. ---------------------------------------------------------------------------- What is the biggest value of SG_BIG_BUFF I can use? 65536 (64 kilobytes). The big buffer is only useful up to the size of the largest possible DMA transfer block, which is 64kB. If set larger, the kernel will allocate the buffer, but making requests of greater than 64kB will hang. cdparanoia will not use larger than 64kB requests. ---------------------------------------------------------------------------- What about -B (batch grab) like cdda2wav? Enough people asked for it, so as of cdparanoia alpha 3, -B exists and works like it does in cdda2wav. ---------------------------------------------------------------------------- Why not integrate cdparanoia with a CDDB database so it knows the names of the songs? Right now, I don't grab the catalogue number from the disc. Once I do, this feature can also be scripted; this is a feature that doesn't really belong in the cdparanoia core. ---------------------------------------------------------------------------- Will you add an X interface? I won't (got no use for it myself), but any developer out there who feels like it should consider themselves welcome. I'm happy to lend support. ---------------------------------------------------------------------------- Why do the binary files from two reads differ when compared? The problem is the beginning point of the read. Cdparanoia enforces consistency from whatever the drive considers to be the starting point of the data, and the drive is returning a slightly different beginning point each time. The beginning point should not vary by much, and if this shift is accounted for when comparing the files, they should indeed turn out to be the same (aside from errors duly reported during the read; scrath correction or any reported skips will very likely also result in different files). ---------------------------------------------------------------------------- Why do CDParanoia, CDDA2WAV et al. rip files off into WAV format (and other sample formats) but not CDDA format? WAV and AIFC are simply convenient formats that include enough header information such that multipurpose audio software can uniquely identify the form of the data in the sample. In raw form, mulaw, SND and CDDA look exactly alike to a program like xplay, and are very likely to blow your ears (and stereo) out when played! Header formats are more versatile and safer. By default, cdparanoia and cdda2wav write WAV files. That said, cdparanoia (and cdda2wav) will write raw, headerless formats if explicitly told to. Cdparanoia writes headerless, signed 16 bit, 44.1kHz stero files in little endian format (LSB first) when given the -r option, and the same in big endian (MSB) format when given -R. All files written by cdparanoia are a multiple of 2352 bytes long (minus the header, if any) as required by cd writer software. Cdda2wav will do other format conversions thew cdparanoia cannot. ---------------------------------------------------------------------------- Why cdparanoia? We already have cdda2wav... All CDROM drives are not created equal. You'll need cdparanoia if yours is a little less equal than others-- or maybe you just keep your CD collection in a box of full of gravel. Jewel cases are for wimps; you know what I'm talking about. Unfortunately, cdda2wav cannot work properly with a large number of CDROM drives in the Linux world today. The most common problem is sporadic or regular clicks and pops in the read sample, regardless of 'nsector' or 'overlap' settings. Cdda2wav also cannot do anything about scratches (and they can cause cdda2wav to break). Paranoia II was the last attempt to enhance cdda2wav and proved to be buggy; Paranoia III is a clean break to brand new code. I decided to write a new utility instead of continuing to patch cdda2wav as the structure of cdda2wav doesn't easily let me do the things I want to; the majority of bugs reported in the Paranoia and Paranoia II series of patches were due to not coping correctly with Heiko's code structure. Rather than continuing to roll for damage on cdda2wav, I decided to finally strike out on my own. ---------------------------------------------------------------------------- Is cdparanoia the same as the 'SaneCDDA' project I've heard of? No, cdparanoia is not part of the SaneCDDA project, although it shares most of SaneCDDA's goals. ---------------------------------------------------------------------------- Will cdparanoia, and cdda2wav or xcdroast merge anytime in the future? Very possible. There's already cooperation amongst Joerg Schilling, Heiko Eissfeldt and Thomas Neiderreiter to coordinate and integrate the development of these utilities (as well as cdrecord), and I've been contacted about reintegrating with these projects (cdparanoia began life as extention patches to cdda2wav). Once the engineering details are worked out (which will take a little time; I want to work some of my own internal bugs out first), cdparanoia will probably become part of this 'greater effort'. ---------------------------------------------------------------------------- Monty (No, I don't have a homepage)