Comparison of CD rippers

From Hydrogenaudio Knowledgebase
Revision as of 21:02, 6 November 2012 by Mjb (Talk | contribs)

Jump to: navigation, search

On the Hydrogenaudio forums (e.g. here and here) there have been many discussions and questions about the differences between different Digital Audio Extraction (DAE) software packages (CD rippers). New rippers with secure ripping facilities have emerged in recent years, and it is now difficult to judge compared to some years ago when the only answer was Exact Audio Copy (EAC).

Comparison chart

Features Cdparanoiaa EAC dBpoweramp CD Ripper foobar2000 ITunes Windows Media Player CUETools XLD Rip MusicBee
Data acquisition
One track per file yes yes yes yes yes yes yes yes yes yes
Image as single file   yes yes yes no no yes yes   yes
CUE sheet generation   yesb limited, more in beta limited no no yesc yes yes limited
gap detection   yes in beta no no no yes yes yes no
Offset correction yes yes yes yes no no yes yes yes yes
HTOA   yes yes yes no no yes     no
C2 pointers no initial pass initial pass, on re-reads no no no initial pass, on re-reads initial pass initial pass, on re-reads initial pass
Defeat cache over-reading over-reading, FUA over-reading, FUA over-reading N/A N/A over-reading over-reading over-reading yes
Additional features
AccurateRip no yes yes yes no no yes yes yes yes
AccurateRip checking across pressings/offsets no no yes yes no no yes yes    
CUEtools db no plugin no no no no yes no no no
log file yes yes yes no no no yes yes yes no
Metadata no freedb,e MusicBrainz,e Discogs,e CD-Text freedb, MusicBrainz, AMG, GD3, SonataDB, CD-Text, PerfectMeta™d freedb, MusicBrainz (plugin), Discogs (plugin), CD-Text gracenote, MusicBrainz (Mac-only hack), CD-Text AMG, CD-Text (plugin) freedb, MusicBrainz, Discogs freedb, MusicBrainz freedb, MusicBrainz freedb, MusicBrainz, CD-Text
Download Album Art no yes yes foo_discogs yes yes yes yes   yes
Cost free free $38 (as listed) free free free free free free free
License GPL proprietary, freeware freeware, shareware proprietary, freeware proprietary, freeware proprietary, freeware GPL GPL   proprietary, freeware
OS Mac OS X, Linux/BSD, Windows via Cygwina Windows Windows Windows Windows, Mac Windows Windows Mac Mac Windows

Notes:

  • ^a Cdparanoia, a console application for Unix-like OSes, is one of many frontends to the Paranoia library, libparanoia. Additional OSes and features not directly related to the ripping process might be supported in other frontends. See Cdparanoia for details.
  • ^b A number of different types CUE sheet types are available.
  • ^c The EAC-style "Multiple WAV Files With Gaps (Noncompliant)" type will be used in single track mode.
  • ^d dBpoweramp is unique in being able to compare metadata from several sources automatically to eliminate erroneous data.
  • ^e freedb access can be direct (via the legacy built-in engine), via the bundled freedb plug-in, or via the bundled CTDB plug-in. MusicBrainz access can be via the bundled CTDB plug-in, or via the freedb options with the MusicBrainz-to-freedb gateway. Discogs access is via the bundled CTDB plug-in only.

Explanation of features

One track per file

A standard feature of rippers is the ability to rip each audio track to a separate file.

Image as single file

Some rippers can rip all the audio tracks to a single "image" file. This normally doesn't include data tracks on Enhanced CDs. This feature can be useful when combined with cue sheets.

Cue sheet generation

Cue sheet generation means the ripper can create a cue sheet to preserve, at a minimum, the relationship between extracted audio and the disc layout (e.g., a list of how an image file is to be split back up into tracks). It usually also indicates the ability to read at least some of the following info from the CD subcode for inclusion in the cue sheet: disc catalog number, track ISRC codes, track indexes (including gaps), disc & track CD-Text data, and track flags. Depending on the ripper, copyright & pre-emphasis flags might only be taken from the TOC, and CD-Text data might only be filled in with metadata from external sources.

A "no" or "limited" in this row shouldn't be considered serious unless you're seeking to preserve as much info as possible, aside from the audio data.

Gap detection

Some rippers can read the disc's subcode to find each track's index 00 portion, i.e. the "gap" or "pre-gap", if one exists. Once detected, this info can be used to control whether & how these portions of the tracks are extracted, and the info can be written to a cue sheet so it can be written to a new CD later. Gap detection only refers to scanning for index 00, regardless of whether it contains silence or audible sound.

A "no" in this row is minor, unless, for example, you're 1. ripping a CD-R that was burned with pure-silence gaps that you want to remove, or 2. planning to burn a copy from the extracted audio (plus accompanying cue sheet) and you want the display on a regular CD player to count up from a negative number to 0:00 between certain tracks, just as it did on the original CD.

The ability to scan for other index points in the subcode is a related feature not yet covered by this table, and may be connected to other features like cue sheet generation. For example, EAC always scans the subcode for gaps and 02-and-higher index points when generating a cue sheet or when doing an index-based rip. Similarly, a ripper might have the option to scan for 01-index points (track boundaries) in the subcode rather than relying on the TOC, which is sometimes deliberately incorrect or unreadable on some drives, as a copy-protection measure.

Offset correction

The ability of a ripper to compensate for a CD drive's inherent read offset, with sample-level precision, very slightly affects the accuracy of track boundaries, and plays a role in whether & how the fraction of a second of audio at the very beginning or very end of a disc is read. Properly configured rippers which correct for read offsets will produce consistent track boundaries, given the same discs to rip, thus allowing comparisons of ripped audio data made on different drives, e.g. via AccurateRip.

A "no" in this row should only be cause for concern if you need to be sure track boundaries aren't very slightly off from how they were encoded on the disc.

HTOA

This indicates the ability to read data in the portion of the disc where Hidden Track One Audio (HTOA) may be located, if the drive also supports it. This is the index 00 portion of track 01, and if it exists at all, normally only contains a tiny amount of silence. If it does have non-silent audio, then to hear it, you would have to start playing track 1, then scan backward.

Very few CDs have HTOA, and not all drives support reading it, so a "no" in this row shouldn't be considered serious unless you're sure you need to read such CDs.

C2 pointers

This row indicates whether & how the ripper makes use of C2 pointers, which are info the drive provides about read errors that the drive detected but wasn't able to correct on its own.

  • "None" means C2 pointers are ignored.
  • "Initial pass" means that during the first read of a sector, a C2 pointer results in the data being considered bad. This will prompt re-reads or flagging of the data as bad, depending on the ripper and its configuration.
  • "On re-reads" means that the same check is done during re-reads, as well.

Defeat cache

This row indicates whether & how the ripper works around the automatic data caching that occurs in some drives. Overreading is a brute-force, slow method where extra data is read in order to flush the cache. Force Unit Access (FUA) is a more efficient method that is only supported in some drives. If you don't have a drive that caches during DAE, this row may not be of interest to you.