Secure ripping: Difference between revisions
m (→CDex) |
|||
| (110 intermediate revisions by 7 users not shown) | |||
| Line 2: | Line 2: | ||
=Secure Ripping= | =Secure Ripping= | ||
===What is Secure Ripping?=== | ===What is Secure Ripping?=== | ||
Secure ripping is the process of making sure there were no errors during the extraction of audio from a CD. It normally involves attempting to get consistent results from successive re-reads of the same sectors, and is sometimes combined with other strategies, such as | |||
* using the drive's own error reporting (after its own error correction fails) to know which sectors to re-read | |||
* defeating caches (some drives cache audio data during DAE) | |||
* and comparing checksums of extracted audio with those obtained by others. | |||
The basic function of ripping software is to get the CD's table of contents (an index of track start positions), and then for each track to be ripped, it tells the CD drive to go to the beginning of each of the track's data blocks (sectors) and read them in, one at a time. On an ordinary audio CD, each block is 2352 bytes and corresponds to 1/75th of a second of sound. The software saves that incoming data into an audio file (WAV or AIFF format, usually, as those formats are almost identical to the data coming in from the drive), or the software streams the data into another audio encoder "on the fly", so the user doesn't have to convert it to another format like MP3 in a separate step. | |||
A bit-perfect rip may not always be possible, and so these programs | This sounds simple, but it becomes complicated when parts of the CD can't be read accurately, for example due to scratches. And there's actually a lot of variation in whether each drive can reliably and accurately go to the spot it's told to read, and in the way it detects, reports, and handles errors, such as those caused by scratches. That is, every CD drive will give the ripping software 2352 bytes of data for each block the drive is told to read, but that data might be different each time, due to physical problems with the disc or limitations of the drive's hardware. Or the data might be the same each time, but is different when obtained from a different drive. | ||
Ripping software that claims to have "secure ripping" will take into account the capabilities and limitations of the drive, and will make the drive read each sector multiple times. Then it will use various methods of analysis and re-reading to ensure that the data was read as correctly as possible. A bit-perfect rip may not always be possible, and so these programs will report on any errors that could not be corrected, allowing you to examine or attempt to correct the problems, such as by generating a log of suspicious positions or doing some kind of automatic "glitch removal". | |||
The term "secure ripping" is usually used in opposition to "burst mode", which implies the drive is simply told to read a range of blocks just once, and the incoming data is accepted without any extra error detection or correction by the software. Since it doesn't involve re-reading of data (other than what the drive might always do automatically), burst mode is naturally faster than secure ripping. | |||
=Secure Ripping Comparison= | =Secure Ripping Comparison= | ||
==Definitions== | |||
===Accurate Stream=== | |||
Accurate Stream is a CD drive's ability to avoid "jitter". A CD drive, when told to go to a particular point on an audio disc, will usually go to a certain number of samples ahead or behind that point, and all the data blocks it reads will be relative to that starting point. If your CD drive supports 'Accurate Stream', this offset will be a constant value, and should be the same for each particular make and model of drive. Usually the offset is not very large (around 1/250th of a second or less). Secure ripping software can take into account whether the drive has Accurate Stream, in order to know whether extra analysis needs to be done to compensate for jitter. It's still possible to do secure ripping with drives that don't have the Accurate Stream feature; it's just easier and faster when they do. | |||
===Caching=== | |||
Caching is the ability of the CD-ROM drive to hold a certain amount of data in its buffer so that it can be readily available in the event that it is requested more than once. This can cause problems for ripping programs when they request the same data be extracted more than once in order to detect errors. When the drive is told to re-read something, it might just send the cached data instead of actually re-reading the disc. | |||
In order to get around this problem, the ripping software will typically request additional data in order to flush the cache of the information it wants to re-read. FUA (force unit access) can be a more efficient method of defeating the caching of audio data, but doesn't have wide hardware support. Of the ripping software listed in the article, the only ones that use of this method are EAC and dBpoweramp. | |||
===C2 error pointers (software)=== | |||
Some drives have the ability to provide additional information about the audio data that has been extracted in order to alert the ripping program when there are uncorrectable errors. This category lists whether the secure ripping software is able to request and utilizes C2 pointers from drives that provide them. | |||
===AccurateRip=== | |||
[[AccurateRip]] is a database that allows you to find out if your CD rips are the same as those ripped by other people; if they were, then it's likely the rips are truly error-free. The database stores checksums for ripped tracks in order to accomplish this. The checksums are generated when ripping and can be submitted to the database through the ripping software if the user so chooses. | |||
=Windows= | |||
==EAC and dBPowerAMP== | ==EAC and dBPowerAMP== | ||
[[EAC]] and [[dbPowerAMP]] both feature powerful correction mechanisms that works with your CD-ROM drive. Some of these features include AccurateStream, Caching, C2 error pointers, and AccurateRip. | [[EAC]] and [[dbPowerAMP]] both feature powerful correction mechanisms that works with your CD-ROM drive. Some of these features include AccurateStream, Caching, C2 error pointers, and AccurateRip. For a description of the Exraction techology used on each of these consult their respective wiki pages above. | ||
===Accurate Stream=== | ===Accurate Stream=== | ||
Question: Do EAC and dbPowerAMP work on drives that don't have AccurateStream? <br> | |||
Yes: EAC and dbPowerAMP work on drives that don't have AccurateStream | |||
===Caching=== | ===Caching=== | ||
Question: Do EAC and dbPowerAMP work on drives that support caching? <br> | |||
Yes: EAC and dbPowerAMP work on drives that support caching | |||
=== | ===C2 Error pointers=== | ||
Question: Do EAC and dbPowerAMP work on drives that utilize C2 error pointers? <br> | |||
Yes: EAC and dbPowerAMP work on drives that support C2 error pointers | |||
===Log file=== | |||
Question: Does the current existing secure ripper print out a log file? <br> | |||
Yes: EAC and dbPowerAMP current existing libraries do print out a log file | |||
===AccurateRip=== | |||
EAC and dbPowerAMP support AccurateRip. | |||
===Ripping Modes=== | |||
[[dbPowerAMP]] and [[EAC]] have two additional modes that can be configured. One is known as "Secure Mode" and the other is known as "Burst Mode". Secure Mode is the recommended mode to use as it goes through the pain staking process of over-anaylzing CD's that may have scratches on them and correcting any bad sectors of audio data. Burst Mode is used for CD's that either have "copy protection" on them or are extremely scratched. It's considered a last ditch effort to recover the audio data from your CD's. | |||
* Secure Mode | |||
* Burst Mode | |||
[[dbPowerAMP]] offers an additional mode, known as "Defective by Design", specifically designed to rip discs with intentional errors, such as those found on many discs with "copy protection" | |||
* Defective by Design | |||
==CDex== | ==CDex== | ||
CDex externally uses the [[cdparanoia]] libraries. It is a bit different than most other CD-DA extration tools. It contains few-to-no extra features ("Too many features spoil the broth"), 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 using interpolation and padding sectors with silence or 0 bytes. | CDex externally uses the [[cdparanoia]] libraries. It is a bit different than most other CD-DA extration tools. It contains few-to-no extra features ("Too many features spoil the broth"), 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 using interpolation and padding sectors with silence or 0 bytes. | ||
==Accurate Stream= | ===Accurate Stream=== | ||
Yes: cdparanoia works on | Question: Does cdparanoia work on drives that don't have AccurateStream? <br> | ||
Yes: cdparanoia works on drives that don't have AccurateStream | |||
===Caching=== | |||
Question: Does cdparanoia work on drives that support caching? <br> | |||
Yes/No: cdparanoia works best on drives that don't support caching, although recent libraries do work on drives that support caching. | |||
===C2 error pointers=== | |||
Question: Does cdparanoia work on drives that utilize C2 error pointers? <br> | |||
No: The current existing philosophy in CDex is that not all drives support C2 error pointers so therefore the libraries do not support C2 error pointers. | |||
===Log file=== | |||
Question: Does the current existing secure ripper print out a log file? <br> | |||
No: CDex current existing libraries do not print out a log file | |||
==C2 error pointers== | ===Ripping Modes=== | ||
There are several modes in cdparanoia that can be controlled by the user in CDex. These modes include: | |||
* Full, Paranoia | |||
* Overlap | |||
* No Verify | |||
* No Scratch Detection | |||
It is best to use '''Full, Paranoia''' mode unless otherwise specified (this is the default mode). '''Overlap''' and '''No Verify''' will just check read boundaries of a buffer and are therefore not recommended. '''No Scratch''' detection skips any error correcting and interpolation (compensation for missing gaps in the audio data) and should therefore be used on CD's that are brand new or have minimal scratches. | |||
=Mac OS/X= | |||
==XLD== | |||
XLD (X lossless Decoder) version 20080812 uses newest [[cdparanoia]] 10.2 libraries for secure ripping and error correcting, which includes AccurateStream and caching. In addition it's the only application for Mac OS/X that utilizes [[AccurateRip]] database used by both [[EAC]] and [[dbPowerAMP]]. | |||
===Accurate Stream=== | |||
Question: Does XLD work on drives that don't have AccurateStream? <br> | |||
Yes: XLD works on drive that don't have AccurateStream | |||
===Caching=== | |||
Question: Does XLD work on drives that support caching? <br> | |||
Yes: XLD works on drives that support caching | |||
===C2 error pointers=== | |||
Question: Does XLD work on drives that utilize C2 error pointers? <br> | |||
Yes: XLD does work on drives that support C2 error pointers. | |||
===Log file=== | |||
Question: Does the current existing secure ripper print out a log file? <br> | |||
Yes: XLD current existing libraries print out a log file | |||
===AccurateRip=== | |||
XLD supports AccurateRip technology utilized by both [[EAC]] and [[dbPowerAMP]]. | |||
==Max== | ==Max== | ||
Max externally uses the [[cdparanoia]] libraries in conjunction with it's own secure ripping algorithm. Max correction mechanism is quite similiar to [[Rubyripper]]. The algorithm uses a comparison feature in order to determine how many times Max should rip and compare sections (maximum retries). It is done on a sector-by-sector basis, rather then byte-by-byte basis. Max can additionally generate a ''SHA-256'' checksum for each additional section in order to more accuratly determine dissimiliarities in a rip. Max differs in that it does not have a direct reliance on [[cdparanoia]] for extraction, but instead uses [[C1/C2 errors|C2 error]] pointers very similiar to [[EAC]]. | |||
==Rubyripper== | |||
===Accurate Stream=== | |||
Question: Does Max work on drives that don't have AccurateStream? <br> | |||
Yes: Max works on drives that don't have AccurateStream | |||
===Caching=== | |||
Question: Does Max work on drives that support caching? <br> | |||
No: Max works on drives that don't support caching | |||
===C2 error pointers=== | |||
Question: Does Max work on drives that utilize C2 error pointers? <br> | |||
Yes: Max current existing libraries support C2 error pointers | |||
===Log file=== | |||
Question: Does the current existing secure ripper print out a log file? <br> | |||
No: Max current existing libraries do not print out a log file | |||
=Linux= | |||
==Rubyripper== | |||
Rubyripper externally uses the [[cdparanoia]] libraries in conjunction with its own secure ripping algorithm. Rubyripper correction mechanism goes beyond that of cdparanoia. Every track gets ripped at least twice and is byte compared with the Ruby cmp feature. If any differences are found, each of the 1,000 bytes of the two files is compared. The next trial run looks to see if differing positions or a match can be found. (1,000 bytes is about 0.006 seconds). | |||
Rubyripper won't guarantee a constant ''MD5-sum'' on tracks that needed correction. However it will repair any files so that it's impossible to successfully blind-test with the original. The log file will report any position that needed more than 3 trials, so you can check the position yourself. | |||
===Accurate Stream=== | |||
Question: Does Rubyripper work on drives that don't have AccurateStream? <br> | |||
Yes: Rubyripper works on drives that don't have AccurateStream | |||
===Caching=== | |||
Question: Does Rubyripper work on drives that support caching? <br> | |||
No: Rubyripper works best on drives that don't support caching. | |||
===C2 error pointers=== | |||
Question: Does Rubyripper work on drives that utilize C2 error pointers? <br> | |||
No: Rubyripper and the current existing libraries do not support C2 error pointers | |||
===Log file=== | |||
Question: Does the current existing secure ripper print out a log file? <br> | |||
Yes: Rubyripper current existing libraries do print out a log file if specified | |||
==External links== | ==External links== | ||
* [http://www.accuraterip.com/ AccurateRip Database] a large database that works with [[EAC]] and [[DBpowerAMP]] | * [http://www.accuraterip.com/ AccurateRip Database] a large database that works with [[EAC]] and [[DBpowerAMP]] | ||
* [http://www.daefeatures.co.uk/search.php DAE Drive Database] a large database that lists CD/DVD-ROM drives and there digital audio extraction features. | * [http://www.daefeatures.co.uk/search.php DAE Drive Database] a large database that lists CD/DVD-ROM drives and there digital audio extraction features. | ||
* [http://www.feurio.com/English/faq/faq_vocable_c2error.shtml FAQ C2 Errors] a frequently asked question page in regard to C2 errors. | |||
[[Category:Guides]] | [[Category:Guides]] | ||
[[Category:Comparison of CD ripping techniques]] | |||
Latest revision as of 22:46, 20 August 2017
This article is a stub. You can help the Hydrogenaudio Knowledgebase by expanding it.
Secure Ripping
What is Secure Ripping?
Secure ripping is the process of making sure there were no errors during the extraction of audio from a CD. It normally involves attempting to get consistent results from successive re-reads of the same sectors, and is sometimes combined with other strategies, such as
- using the drive's own error reporting (after its own error correction fails) to know which sectors to re-read
- defeating caches (some drives cache audio data during DAE)
- and comparing checksums of extracted audio with those obtained by others.
The basic function of ripping software is to get the CD's table of contents (an index of track start positions), and then for each track to be ripped, it tells the CD drive to go to the beginning of each of the track's data blocks (sectors) and read them in, one at a time. On an ordinary audio CD, each block is 2352 bytes and corresponds to 1/75th of a second of sound. The software saves that incoming data into an audio file (WAV or AIFF format, usually, as those formats are almost identical to the data coming in from the drive), or the software streams the data into another audio encoder "on the fly", so the user doesn't have to convert it to another format like MP3 in a separate step.
This sounds simple, but it becomes complicated when parts of the CD can't be read accurately, for example due to scratches. And there's actually a lot of variation in whether each drive can reliably and accurately go to the spot it's told to read, and in the way it detects, reports, and handles errors, such as those caused by scratches. That is, every CD drive will give the ripping software 2352 bytes of data for each block the drive is told to read, but that data might be different each time, due to physical problems with the disc or limitations of the drive's hardware. Or the data might be the same each time, but is different when obtained from a different drive.
Ripping software that claims to have "secure ripping" will take into account the capabilities and limitations of the drive, and will make the drive read each sector multiple times. Then it will use various methods of analysis and re-reading to ensure that the data was read as correctly as possible. A bit-perfect rip may not always be possible, and so these programs will report on any errors that could not be corrected, allowing you to examine or attempt to correct the problems, such as by generating a log of suspicious positions or doing some kind of automatic "glitch removal".
The term "secure ripping" is usually used in opposition to "burst mode", which implies the drive is simply told to read a range of blocks just once, and the incoming data is accepted without any extra error detection or correction by the software. Since it doesn't involve re-reading of data (other than what the drive might always do automatically), burst mode is naturally faster than secure ripping.
Secure Ripping Comparison
Definitions
Accurate Stream
Accurate Stream is a CD drive's ability to avoid "jitter". A CD drive, when told to go to a particular point on an audio disc, will usually go to a certain number of samples ahead or behind that point, and all the data blocks it reads will be relative to that starting point. If your CD drive supports 'Accurate Stream', this offset will be a constant value, and should be the same for each particular make and model of drive. Usually the offset is not very large (around 1/250th of a second or less). Secure ripping software can take into account whether the drive has Accurate Stream, in order to know whether extra analysis needs to be done to compensate for jitter. It's still possible to do secure ripping with drives that don't have the Accurate Stream feature; it's just easier and faster when they do.
Caching
Caching is the ability of the CD-ROM drive to hold a certain amount of data in its buffer so that it can be readily available in the event that it is requested more than once. This can cause problems for ripping programs when they request the same data be extracted more than once in order to detect errors. When the drive is told to re-read something, it might just send the cached data instead of actually re-reading the disc.
In order to get around this problem, the ripping software will typically request additional data in order to flush the cache of the information it wants to re-read. FUA (force unit access) can be a more efficient method of defeating the caching of audio data, but doesn't have wide hardware support. Of the ripping software listed in the article, the only ones that use of this method are EAC and dBpoweramp.
C2 error pointers (software)
Some drives have the ability to provide additional information about the audio data that has been extracted in order to alert the ripping program when there are uncorrectable errors. This category lists whether the secure ripping software is able to request and utilizes C2 pointers from drives that provide them.
AccurateRip
AccurateRip is a database that allows you to find out if your CD rips are the same as those ripped by other people; if they were, then it's likely the rips are truly error-free. The database stores checksums for ripped tracks in order to accomplish this. The checksums are generated when ripping and can be submitted to the database through the ripping software if the user so chooses.
Windows
EAC and dBPowerAMP
EAC and dbPowerAMP both feature powerful correction mechanisms that works with your CD-ROM drive. Some of these features include AccurateStream, Caching, C2 error pointers, and AccurateRip. For a description of the Exraction techology used on each of these consult their respective wiki pages above.
Accurate Stream
Question: Do EAC and dbPowerAMP work on drives that don't have AccurateStream?
Yes: EAC and dbPowerAMP work on drives that don't have AccurateStream
Caching
Question: Do EAC and dbPowerAMP work on drives that support caching?
Yes: EAC and dbPowerAMP work on drives that support caching
C2 Error pointers
Question: Do EAC and dbPowerAMP work on drives that utilize C2 error pointers?
Yes: EAC and dbPowerAMP work on drives that support C2 error pointers
Log file
Question: Does the current existing secure ripper print out a log file?
Yes: EAC and dbPowerAMP current existing libraries do print out a log file
AccurateRip
EAC and dbPowerAMP support AccurateRip.
Ripping Modes
dbPowerAMP and EAC have two additional modes that can be configured. One is known as "Secure Mode" and the other is known as "Burst Mode". Secure Mode is the recommended mode to use as it goes through the pain staking process of over-anaylzing CD's that may have scratches on them and correcting any bad sectors of audio data. Burst Mode is used for CD's that either have "copy protection" on them or are extremely scratched. It's considered a last ditch effort to recover the audio data from your CD's.
- Secure Mode
- Burst Mode
dbPowerAMP offers an additional mode, known as "Defective by Design", specifically designed to rip discs with intentional errors, such as those found on many discs with "copy protection"
- Defective by Design
CDex
CDex externally uses the cdparanoia libraries. It is a bit different than most other CD-DA extration tools. It contains few-to-no extra features ("Too many features spoil the broth"), 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 using interpolation and padding sectors with silence or 0 bytes.
Accurate Stream
Question: Does cdparanoia work on drives that don't have AccurateStream?
Yes: cdparanoia works on drives that don't have AccurateStream
Caching
Question: Does cdparanoia work on drives that support caching?
Yes/No: cdparanoia works best on drives that don't support caching, although recent libraries do work on drives that support caching.
C2 error pointers
Question: Does cdparanoia work on drives that utilize C2 error pointers?
No: The current existing philosophy in CDex is that not all drives support C2 error pointers so therefore the libraries do not support C2 error pointers.
Log file
Question: Does the current existing secure ripper print out a log file?
No: CDex current existing libraries do not print out a log file
Ripping Modes
There are several modes in cdparanoia that can be controlled by the user in CDex. These modes include:
- Full, Paranoia
- Overlap
- No Verify
- No Scratch Detection
It is best to use Full, Paranoia mode unless otherwise specified (this is the default mode). Overlap and No Verify will just check read boundaries of a buffer and are therefore not recommended. No Scratch detection skips any error correcting and interpolation (compensation for missing gaps in the audio data) and should therefore be used on CD's that are brand new or have minimal scratches.
Mac OS/X
XLD
XLD (X lossless Decoder) version 20080812 uses newest cdparanoia 10.2 libraries for secure ripping and error correcting, which includes AccurateStream and caching. In addition it's the only application for Mac OS/X that utilizes AccurateRip database used by both EAC and dbPowerAMP.
Accurate Stream
Question: Does XLD work on drives that don't have AccurateStream?
Yes: XLD works on drive that don't have AccurateStream
Caching
Question: Does XLD work on drives that support caching?
Yes: XLD works on drives that support caching
C2 error pointers
Question: Does XLD work on drives that utilize C2 error pointers?
Yes: XLD does work on drives that support C2 error pointers.
Log file
Question: Does the current existing secure ripper print out a log file?
Yes: XLD current existing libraries print out a log file
AccurateRip
XLD supports AccurateRip technology utilized by both EAC and dbPowerAMP.
Max
Max externally uses the cdparanoia libraries in conjunction with it's own secure ripping algorithm. Max correction mechanism is quite similiar to Rubyripper. The algorithm uses a comparison feature in order to determine how many times Max should rip and compare sections (maximum retries). It is done on a sector-by-sector basis, rather then byte-by-byte basis. Max can additionally generate a SHA-256 checksum for each additional section in order to more accuratly determine dissimiliarities in a rip. Max differs in that it does not have a direct reliance on cdparanoia for extraction, but instead uses C2 error pointers very similiar to EAC.
Accurate Stream
Question: Does Max work on drives that don't have AccurateStream?
Yes: Max works on drives that don't have AccurateStream
Caching
Question: Does Max work on drives that support caching?
No: Max works on drives that don't support caching
C2 error pointers
Question: Does Max work on drives that utilize C2 error pointers?
Yes: Max current existing libraries support C2 error pointers
Log file
Question: Does the current existing secure ripper print out a log file?
No: Max current existing libraries do not print out a log file
Linux
Rubyripper
Rubyripper externally uses the cdparanoia libraries in conjunction with its own secure ripping algorithm. Rubyripper correction mechanism goes beyond that of cdparanoia. Every track gets ripped at least twice and is byte compared with the Ruby cmp feature. If any differences are found, each of the 1,000 bytes of the two files is compared. The next trial run looks to see if differing positions or a match can be found. (1,000 bytes is about 0.006 seconds).
Rubyripper won't guarantee a constant MD5-sum on tracks that needed correction. However it will repair any files so that it's impossible to successfully blind-test with the original. The log file will report any position that needed more than 3 trials, so you can check the position yourself.
Accurate Stream
Question: Does Rubyripper work on drives that don't have AccurateStream?
Yes: Rubyripper works on drives that don't have AccurateStream
Caching
Question: Does Rubyripper work on drives that support caching?
No: Rubyripper works best on drives that don't support caching.
C2 error pointers
Question: Does Rubyripper work on drives that utilize C2 error pointers?
No: Rubyripper and the current existing libraries do not support C2 error pointers
Log file
Question: Does the current existing secure ripper print out a log file?
Yes: Rubyripper current existing libraries do print out a log file if specified
External links
- AccurateRip Database a large database that works with EAC and DBpowerAMP
- DAE Drive Database a large database that lists CD/DVD-ROM drives and there digital audio extraction features.
- FAQ C2 Errors a frequently asked question page in regard to C2 errors.