| Home | cripple | x86test | boot stuff | ASCII converter | links | ||||||
cripple - CD ripper wrapperCripple is a simple command line CD ripper wrapper. By default it uses CDparanoia or cdda2wav and BladeEnc or LAME to rip and encode tracks from a CD. Cripple retrives naming information for filenames and ID3 tags from the freedb (CDDB) or local xmcd/CDDB format files, which it can write. CDDB access is implemented via HTTP and works through proxies. There is built-in support for writing ID3v1.1 tags to output files. On the majority of systems cripple requires no special libraries, interpreters etc. However by its very nature it requires a command line ripper such as cdparanoia or cdda2wav and an encoder such as lame or bladeenc. cripple is released under the GNU General Public License. Features
Saving CDDB responses to files allows you to query a load of CDs in a couple of minutes and rip them later (and obviously you can edit the information). By default filenames have a logical structure: Artist - Album - Track no. - Track name.mp3 or For more information see the README and man page included with the source. CompatibilityCripple has been extensively tested on GNU/Linux and cygwin/win32-NT. It has also been reported to work out of the box on NetBSD. There is untested support for (at least) FreeBSD and SunOS. There is no support for IRIX or win32 95/98/Me. Porting to other UNIX-ish systems should be straightforward, but native win32 would be a pain. Using different rippers or encoders should be simple. *BSD users will probably want to edit the default cdrom device in cripple.h (to /dev/rcd0d on NetBSD I believe). This should be fixed in any future release. Here is a tiny patch for cripple-0.06b on NetBSD: cripple.h.patch. Download
General NotesLinux with ATAPI If you are using an ATAPI CD drive with Linux for anything other than mounting CDROMs or playing audio CDs, I strongly recommend configuring your kernel to use the SCSI host adapter emulation. ATAPI drives use much the same command set as SCSI/MMC drives, so the emulation contributes very little overhead whilst allowing software total control of the device. This is esential for CD burning and very useful for audio ripping, especially for damaged CDs. CDparanoia is a lot faster with the SCSI interface. Newer linux kernels (>=2.4?) do have a direct ATAPI packet ioctl() interface, but as far as I'm aware CDparanoia doesn't support it. Speed, jitter and errors People often don't realise the large differences between audio and data tracks on CDs. The low-level structure of a CD is fairly simple -- it can be difficult to exactly locate frames (causing jitter) and it is unreliable (can only correct a small number of errors). Audio data is simply placed into the low-level frames on the CD. Data tracks however, use some of each frame for syncronisation data to let drives more easily locate frames. Mode 1 data tracks (almost all CDROMs) also use a large portion of each frame for an Error Correction Code to correct up to about 100 bit errors per frame. This means that whilst your CDROM drive might be able to reliably read data tracks at ridiculous speeds from discs that are quite badly scratched, when you try to read audio tracks like this some of what you get is likely to be garbage, and it can be hard for your ripper to detect this. To be on the safe side I would recommend ripping audio tracks at no more than half the maximum rated speed of the drive. For damaged CDs you may want to slow down to 4x or lower to get as much correct data as possible. Also if you are writing audio CDs it is a good idea to keep the speed down to make sure that the result is as consistent as possible. Again about half the rated drive/media speed is probably a good starting point. |
|||||||