AccurateRip - Revision history

Supermariofan67: /* Software that uses AccurateRip */ cyanrip

2021-11-24T09:12:02Z

Software that uses AccurateRip: cyanrip

← Older revision		Revision as of 09:12, 24 November 2021
Line 44:		Line 44:
	==Software that uses AccurateRip==		==Software that uses AccurateRip==
	* [[CUETools]]		* [[CUETools]]
			* [https://github.com/cyanreg/cyanrip cyanrip]
	* [[dBpoweramp]]		* [[dBpoweramp]]
	* [[Exact Audio Copy]]		* [[Exact Audio Copy]]

77.6.184.6: /* Software that uses AccurateRip */ Fix case of software names, sort alphabetically and add fre:ac

2021-06-29T20:03:08Z

Software that uses AccurateRip: Fix case of software names, sort alphabetically and add fre:ac

← Older revision		Revision as of 20:03, 29 June 2021
Line 43:		Line 43:

	==Software that uses AccurateRip==		==Software that uses AccurateRip==
			* [[CUETools]]
			* [[dBpoweramp]]
	* [[Exact Audio Copy]]		* [[Exact Audio Copy]]
	* [[~~DBpowerAMP with AccurateRip~~]]		* [[foobar2000]]
	* [[~~Foobar2000~~]]		* [[fre:ac]]
	* [[MediaMonkey]]		* [[MediaMonkey]]
	* [~~[CueTools]]~~		* [https://github.com/thomasvs/morituri morituri]
	* [[XLD]]
	* [[Python Audio Tools]]		* [[Python Audio Tools]]
	* [[Rip]]		* [[Rip]]
	* [[Songbook]]		* [[Songbook]]
	* [~~https://github.com/thomasvs/morituri morituri~~]		* [[Whipper]]
	* [[~~whipper~~]]		* [[XLD]]

	==History==		==History==

Speckmade at 00:17, 17 February 2019

2019-02-17T00:17:35Z

← Older revision		Revision as of 00:17, 17 February 2019
Line 1:		Line 1:
	'''AccurateRip''' is an online ripping accuracy database. Using submissions from people all around the world, a bit-perfect verification of an audio track rip can be assured with a positive match. AccurateRip also allows the offsets of drives to be determined.		'''AccurateRip''' is an online ripping accuracy database. Using submissions from people all around the world, a bit-perfect verification of an audio track rip can be assured with a positive match. AccurateRip also allows the offsets of drives to be determined.

	The database is maintained by Illustrate Ltd., the company run by "Spoon", primary developer of [[dBpoweramp]]. All of the data is submitted by the Windows-based ripping programs dBpoweramp and [[Exact Audio Copy]] via a [[wikipedia:Dynamic-link library\|DLL]] licensed from Illustrate.<ref>As per [~~http~~://~~www~~.~~hydrogenaudio.org/forums~~/index.php~~?s=&showtopic=~~77600~~&view=findpost&p=678407~~ a Jan. 2010 post by Spoon], "Only two programs submit to AR, EAC and dBpoweramp, these two submit through the standard AccurateRip access dll, which ensures that offsets are correct, we are not talking submissions to freedb where one record does not effect the submission of future records if keyed with a wrong offset. You might not like it, but it is the only way to ensure that the quality of the database is not impaired."</ref> Other rippers and tools, such as [[CUETools]] and Mac OS-based rippers, can receive info from the database in order to look up drive offsets or check rip quality, but they cannot submit their own rip results to it.		The database is maintained by Illustrate Ltd., the company run by "Spoon", primary developer of [[dBpoweramp]]. All of the data is submitted by the Windows-based ripping programs dBpoweramp and [[Exact Audio Copy]] via a [[wikipedia:Dynamic-link library\|DLL]] licensed from Illustrate.<ref>As per [https://hydrogenaud.io/index.php/topic,77600#msg678407 a Jan. 2010 post by Spoon], "Only two programs submit to AR, EAC and dBpoweramp, these two submit through the standard AccurateRip access dll, which ensures that offsets are correct, we are not talking submissions to freedb where one record does not effect the submission of future records if keyed with a wrong offset. You might not like it, but it is the only way to ensure that the quality of the database is not impaired."</ref> Other rippers and tools, such as [[CUETools]] and Mac OS-based rippers, can receive info from the database in order to look up drive offsets or check rip quality, but they cannot submit their own rip results to it.


	==Drive read offsets==		==Drive read offsets==
Line 14:		Line 13:

	===Offset accuracy===		===Offset accuracy===
	Determining the actual read offset of a drive is difficult. The reference measurements Andre Wiethoff made and which were adopted by Spoon for the AccurateRip database were challenged in late 2006; [~~http~~://web.archive.org/web/20120903210117/~~http://www.~~digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html] to support a claim that the reference is actually off by 30 samples. The offsets are 30 samples too low, or the correction values are 30 samples too high, however you want to look at it. Wiethoff feels that it's too late to change to a different reference now that the database is populated. However, since all submissions are calibrated to the same reference, and the apparent error so small (~680 µs), the reliability of AccurateRip data is not compromised in any way whatsoever.		Determining the actual read offset of a drive is difficult. The reference measurements Andre Wiethoff made and which were adopted by Spoon for the AccurateRip database were challenged in late 2006; [https://web.archive.org/web/20120903210117/digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html] to support a claim that the reference is actually off by 30 samples. The offsets are 30 samples too low, or the correction values are 30 samples too high, however you want to look at it. Wiethoff feels that it's too late to change to a different reference now that the database is populated. However, since all submissions are calibrated to the same reference, and the apparent error so small (~680 µs), the reliability of AccurateRip data is not compromised in any way whatsoever.

	==Ripped track checksums==		==Ripped track checksums==
Line 22:		Line 21:

	===Checksum calculation===		===Checksum calculation===
	Technical details on checksum calculation can be found here: [~~http~~://forum.dbpoweramp.com/showthread.php?20641~~-AccurateRip-CRC-Calculation~~ AccurateRip-CRC-Calculation]		Technical details on checksum calculation can be found here: [https://forum.dbpoweramp.com/showthread.php?20641 AccurateRip-CRC-Calculation]

	A Linux command-line tool to compute AccurateRip checksums can be found here: https://github.com/leo-bogert/accuraterip-checksum		A Linux command-line tool to compute AccurateRip checksums can be found here: https://github.com/leo-bogert/accuraterip-checksum
Line 30:		Line 29:
	The checksum algorithm ignores the first 2939 samples<ref name=Steffensen>Not 2940 samples; see http://jonls.dk/2009/10/calculating-accuraterip-checksums/</ref> (just under 5 frames, a little over 0.013s of audio) at the beginning of the first track, and ignores 2940 samples (exactly 5 frames) at the end of the last track. The largest drive offset in the database, as of late 2011, is only 1776 samples, so when an offset-corrected drive "overreads" beyond the boundaries of the audio data, it normally won't affect the checksum. If the overread were to exceed 2940 samples, though, the algorithm assumes the data is padded with digital silence (nothing but zeroes). If your drive isn't capable of overreading and your DAE software doesn't zero-pad the rip to simulate an overread, then it's unlikely the checksums of your rips will be submitted to or compared against those in the AccurateRip database.		The checksum algorithm ignores the first 2939 samples<ref name=Steffensen>Not 2940 samples; see http://jonls.dk/2009/10/calculating-accuraterip-checksums/</ref> (just under 5 frames, a little over 0.013s of audio) at the beginning of the first track, and ignores 2940 samples (exactly 5 frames) at the end of the last track. The largest drive offset in the database, as of late 2011, is only 1776 samples, so when an offset-corrected drive "overreads" beyond the boundaries of the audio data, it normally won't affect the checksum. If the overread were to exceed 2940 samples, though, the algorithm assumes the data is padded with digital silence (nothing but zeroes). If your drive isn't capable of overreading and your DAE software doesn't zero-pad the rip to simulate an overread, then it's unlikely the checksums of your rips will be submitted to or compared against those in the AccurateRip database.

	An optimization oversight in the original AccurateRip checksum algorithm results in an unintended loss of accuracy: about 3% of the audio data is not counted in the checksum at all. The left channel's samples are fully included, but in a 65,536-sample cycle, half of the right-channel samples are treated as if they're missing anywhere from 1 bit to all 16 bits. [~~http~~://~~www~~.~~hydrogenaudio.org/forums~~/index.php~~?showtopic=~~61468 Proposals for improving the algorithm, the database, and the database's API were made] and an improved algorithm was implemented for AccurateRip v2 checksums, which are now the default calculated by the rippers which support AccurateRip. How much improvement the v2 checksum has over the original is suspect [http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&st=1350&p=756260&#entry756260 link]. The v2 checksums are treated as separate pressings from the old ones, so there's no risk to the integrity of existing data.		An optimization oversight in the original AccurateRip checksum algorithm results in an unintended loss of accuracy: about 3% of the audio data is not counted in the checksum at all. The left channel's samples are fully included, but in a 65,536-sample cycle, half of the right-channel samples are treated as if they're missing anywhere from 1 bit to all 16 bits. [https://hydrogenaud.io/index.php/topic,61468 Proposals for improving the algorithm, the database, and the database's API were made] and an improved algorithm was implemented for AccurateRip v2 checksums, which are now the default calculated by the rippers which support AccurateRip. How much improvement the v2 checksum has over the original is suspect [http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&st=1350&p=756260&#entry756260 link]. The v2 checksums are treated as separate pressings from the old ones, so there's no risk to the integrity of existing data.

	==Pressings==		==Pressings==
Line 36:		Line 35:

	==AccurateRip data analysis==		==AccurateRip data analysis==
	It is possible to run statistical analysis on the hundreds of millions of submissions to AccurateRip to determine how accurate a given drive is, with the idea that with enough spread of drive submissions, anomalous results from damaged CDs will be averaged out. The last such calculation can be found here: [~~http~~://forum.dbpoweramp.com/showthread.php?23074~~-CD-DVD-Drive-Accuracy-List-2011~~ CD-DVD-Drive-Accuracy-List-2011]		It is possible to run statistical analysis on the hundreds of millions of submissions to AccurateRip to determine how accurate a given drive is, with the idea that with enough spread of drive submissions, anomalous results from damaged CDs will be averaged out. The last such calculation can be found here: [https://forum.dbpoweramp.com/showthread.php?23074 CD-DVD-Drive-Accuracy-List-2011]

	There is also a report of drive offsets here: [http://www.accuraterip.com/driveoffsets.htm CD Drive Offsets]		There is also a report of drive offsets here: [http://www.accuraterip.com/driveoffsets.htm CD Drive Offsets]
Line 42:		Line 41:
	==Submitting offsets and checksums==		==Submitting offsets and checksums==
	The database is designed to be anonymously accessed by DAE software, via HTTP. Submitting data should only be done through such software.		The database is designed to be anonymously accessed by DAE software, via HTTP. Submitting data should only be done through such software.


	==Software that uses AccurateRip==		==Software that uses AccurateRip==
Line 55:		Line 53:
	* [[Songbook]]		* [[Songbook]]
	* [https://github.com/thomasvs/morituri morituri]		* [https://github.com/thomasvs/morituri morituri]
	* [~~https://github.com/JoeLametta/whipper~~ whipper]		* [[whipper]]

	==History==		==History==

170.82.211.42 at 16:01, 15 June 2018

2018-06-15T16:01:51Z

← Older revision		Revision as of 16:01, 15 June 2018
Line 1:		Line 1:
	'''AccurateRip''' is a online ripping accuracy database. Using submissions from people all around the world, a bit-perfect verification of an audio track rip can be assured with a positive match. AccurateRip also allows the offsets of drives to be determined.		'''AccurateRip''' is an online ripping accuracy database. Using submissions from people all around the world, a bit-perfect verification of an audio track rip can be assured with a positive match. AccurateRip also allows the offsets of drives to be determined.

	The database is maintained by Illustrate Ltd., the company run by "Spoon", primary developer of [[dBpoweramp]]. All of the data is submitted by the Windows-based ripping programs dBpoweramp and [[Exact Audio Copy]] via a [[wikipedia:Dynamic-link library\|DLL]] licensed from Illustrate.<ref>As per [http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=77600&view=findpost&p=678407 a Jan. 2010 post by Spoon], "Only two programs submit to AR, EAC and dBpoweramp, these two submit through the standard AccurateRip access dll, which ensures that offsets are correct, we are not talking submissions to freedb where one record does not effect the submission of future records if keyed with a wrong offset. You might not like it, but it is the only way to ensure that the quality of the database is not impaired."</ref> Other rippers and tools, such as [[CUETools]] and Mac OS-based rippers, can receive info from the database in order to look up drive offsets or check rip quality, but they cannot submit their own rip results to it.		The database is maintained by Illustrate Ltd., the company run by "Spoon", primary developer of [[dBpoweramp]]. All of the data is submitted by the Windows-based ripping programs dBpoweramp and [[Exact Audio Copy]] via a [[wikipedia:Dynamic-link library\|DLL]] licensed from Illustrate.<ref>As per [http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=77600&view=findpost&p=678407 a Jan. 2010 post by Spoon], "Only two programs submit to AR, EAC and dBpoweramp, these two submit through the standard AccurateRip access dll, which ensures that offsets are correct, we are not talking submissions to freedb where one record does not effect the submission of future records if keyed with a wrong offset. You might not like it, but it is the only way to ensure that the quality of the database is not impaired."</ref> Other rippers and tools, such as [[CUETools]] and Mac OS-based rippers, can receive info from the database in order to look up drive offsets or check rip quality, but they cannot submit their own rip results to it.

15.203.233.87: /* Offset accuracy */ clarified the magnitude of the apparent error (~680 µs)

2017-04-12T13:06:00Z

Offset accuracy: clarified the magnitude of the apparent error (~680 µs)

← Older revision		Revision as of 13:06, 12 April 2017
Line 14:		Line 14:

	===Offset accuracy===		===Offset accuracy===
	Determining the actual read offset of a drive is difficult. The reference measurements Andre Wiethoff made and which were adopted by Spoon for the AccurateRip database were challenged in late 2006; [http://web.archive.org/web/20120903210117/http://www.digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html] to support a claim that the reference is actually off by 30 samples. The offsets are 30 samples too low, or the correction values are 30 samples too high, however you want to look at it. Wiethoff feels that it's too late to change to a different reference now that the database is populated. However, since all submissions are calibrated to the same reference, and the apparent error so small, the reliability of AccurateRip data is not compromised in any way whatsoever.		Determining the actual read offset of a drive is difficult. The reference measurements Andre Wiethoff made and which were adopted by Spoon for the AccurateRip database were challenged in late 2006; [http://web.archive.org/web/20120903210117/http://www.digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html] to support a claim that the reference is actually off by 30 samples. The offsets are 30 samples too low, or the correction values are 30 samples too high, however you want to look at it. Wiethoff feels that it's too late to change to a different reference now that the database is populated. However, since all submissions are calibrated to the same reference, and the apparent error so small (~680 µs), the reliability of AccurateRip data is not compromised in any way whatsoever.


	==Ripped track checksums==		==Ripped track checksums==

172.14.32.230: Added "Whipper" which is a fork of "morituri".

2017-02-08T20:47:27Z

Added "Whipper" which is a fork of "morituri".

← Older revision		Revision as of 20:47, 8 February 2017
Line 56:		Line 56:
	* [[Songbook]]		* [[Songbook]]
	* [https://github.com/thomasvs/morituri morituri]		* [https://github.com/thomasvs/morituri morituri]
			* [https://github.com/JoeLametta/whipper whipper]

	==History==		==History==

142.254.104.104: Undo revision 25700. EAC only attempts to synchronize between every 2MB of data. Furthermore, there is no way of knowing when EAC synchronizes data, let alone whether this was deemed necessary because of a performance fault with the drive.

2016-10-14T17:31:40Z

Undo revision 25700. EAC only attempts to synchronize between every 2MB of data. Furthermore, there is no way of knowing when EAC synchronizes data, let alone whether this was deemed necessary because of a performance fault with the drive.

← Older revision		Revision as of 17:31, 14 October 2016
Line 5:		Line 5:

	==Drive read offsets==		==Drive read offsets==
	Very few CD drives actually start reading data from audio CDs exactly at the sector requested by DAE software. There are drives that are off by over 1 sector (1/75th of a second), but most are off by much less (<sup>1</sup>/<sub>250</sub> to <sup>1</sup>/<sub>350</sub> second). Most modern CD drives have "Accurate Stream" technology, so there's ~~rarely any~~ "jitter", meaning in this case that the variance is ~~usually~~ consistent from read to read, and will tend to be the same for all drives of a certain make & model.		Very few CD drives actually start reading data from audio CDs exactly at the sector requested by DAE software. There are drives that are off by over 1 sector (1/75th of a second), but most are off by much less (<sup>1</sup>/<sub>250</sub> to <sup>1</sup>/<sub>350</sub> second). Most modern CD drives have "Accurate Stream" technology, so there's no "jitter", meaning in this case that the variance is consistent from read to read, and will tend to be the same for all drives of a certain make & model.

	The AccurateRip database allows one to find out the read offset, which is normally constant for given make & model of CD drive. This number can then be used by DAE software to ensure that each track is ripped from its exact start to its exact finish.		The AccurateRip database allows one to find out the read offset, which is normally constant for given make & model of CD drive. This number can then be used by DAE software to ensure that each track is ripped from its exact start to its exact finish.
Line 15:		Line 15:
	===Offset accuracy===		===Offset accuracy===
	Determining the actual read offset of a drive is difficult. The reference measurements Andre Wiethoff made and which were adopted by Spoon for the AccurateRip database were challenged in late 2006; [http://web.archive.org/web/20120903210117/http://www.digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html] to support a claim that the reference is actually off by 30 samples. The offsets are 30 samples too low, or the correction values are 30 samples too high, however you want to look at it. Wiethoff feels that it's too late to change to a different reference now that the database is populated. However, since all submissions are calibrated to the same reference, and the apparent error so small, the reliability of AccurateRip data is not compromised in any way whatsoever.		Determining the actual read offset of a drive is difficult. The reference measurements Andre Wiethoff made and which were adopted by Spoon for the AccurateRip database were challenged in late 2006; [http://web.archive.org/web/20120903210117/http://www.digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html] to support a claim that the reference is actually off by 30 samples. The offsets are 30 samples too low, or the correction values are 30 samples too high, however you want to look at it. Wiethoff feels that it's too late to change to a different reference now that the database is populated. However, since all submissions are calibrated to the same reference, and the apparent error so small, the reliability of AccurateRip data is not compromised in any way whatsoever.


	==Ripped track checksums==		==Ripped track checksums==

72.83.229.68: /* Offset accuracy */ link has gone away, switch to archive.org

2014-12-27T10:55:24Z

Offset accuracy: link has gone away, switch to archive.org

← Older revision		Revision as of 10:55, 27 December 2014
Line 14:		Line 14:

	===Offset accuracy===		===Offset accuracy===
	Determining the actual read offset of a drive is difficult. The reference measurements Andre Wiethoff made and which were adopted by Spoon for the AccurateRip database were challenged in late 2006; [http://www.digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html ~~strong evidence was presented~~] to support a claim that the reference is actually off by 30 samples. The offsets are 30 samples too low, or the correction values are 30 samples too high, however you want to look at it. Wiethoff feels that it's too late to change to a different reference now that the database is populated. However, since all submissions are calibrated to the same reference, and the apparent error so small, the reliability of AccurateRip data is not compromised in any way whatsoever.		Determining the actual read offset of a drive is difficult. The reference measurements Andre Wiethoff made and which were adopted by Spoon for the AccurateRip database were challenged in late 2006; [http://web.archive.org/web/20120903210117/http://www.digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html] to support a claim that the reference is actually off by 30 samples. The offsets are 30 samples too low, or the correction values are 30 samples too high, however you want to look at it. Wiethoff feels that it's too late to change to a different reference now that the database is populated. However, since all submissions are calibrated to the same reference, and the apparent error so small, the reliability of AccurateRip data is not compromised in any way whatsoever.

	==Ripped track checksums==		==Ripped track checksums==

Mjb: /* Drive read offsets */ if Accurate Stream guaranteed consistency, EAC wouldn't have to synchronize at all

2014-02-07T00:14:46Z

Drive read offsets: if Accurate Stream guaranteed consistency, EAC wouldn't have to synchronize at all

← Older revision		Revision as of 00:14, 7 February 2014
Line 5:		Line 5:

	==Drive read offsets==		==Drive read offsets==
	Very few CD drives actually start reading data from audio CDs exactly at the sector requested by DAE software. There are drives that are off by over 1 sector (1/75th of a second), but most are off by much less (<sup>1</sup>/<sub>250</sub> to <sup>1</sup>/<sub>350</sub> second). Most modern CD drives have "Accurate Stream" technology, so there's no "jitter", meaning in this case that the variance is consistent from read to read, and will tend to be the same for all drives of a certain make & model.		Very few CD drives actually start reading data from audio CDs exactly at the sector requested by DAE software. There are drives that are off by over 1 sector (1/75th of a second), but most are off by much less (<sup>1</sup>/<sub>250</sub> to <sup>1</sup>/<sub>350</sub> second). Most modern CD drives have "Accurate Stream" technology, so there's rarely any "jitter", meaning in this case that the variance is usually consistent from read to read, and will tend to be the same for all drives of a certain make & model.

	The AccurateRip database allows one to find out the read offset, which is normally constant for given make & model of CD drive. This number can then be used by DAE software to ensure that each track is ripped from its exact start to its exact finish.		The AccurateRip database allows one to find out the read offset, which is normally constant for given make & model of CD drive. This number can then be used by DAE software to ensure that each track is ripped from its exact start to its exact finish.
Line 15:		Line 15:
	===Offset accuracy===		===Offset accuracy===
	Determining the actual read offset of a drive is difficult. The reference measurements Andre Wiethoff made and which were adopted by Spoon for the AccurateRip database were challenged in late 2006; [http://www.digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html strong evidence was presented] to support a claim that the reference is actually off by 30 samples. The offsets are 30 samples too low, or the correction values are 30 samples too high, however you want to look at it. Wiethoff feels that it's too late to change to a different reference now that the database is populated. However, since all submissions are calibrated to the same reference, and the apparent error so small, the reliability of AccurateRip data is not compromised in any way whatsoever.		Determining the actual read offset of a drive is difficult. The reference measurements Andre Wiethoff made and which were adopted by Spoon for the AccurateRip database were challenged in late 2006; [http://www.digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html strong evidence was presented] to support a claim that the reference is actually off by 30 samples. The offsets are 30 samples too low, or the correction values are 30 samples too high, however you want to look at it. Wiethoff feels that it's too late to change to a different reference now that the database is populated. However, since all submissions are calibrated to the same reference, and the apparent error so small, the reliability of AccurateRip data is not compromised in any way whatsoever.


	==Ripped track checksums==		==Ripped track checksums==

Greynol: /* Pressings */

2013-10-25T05:44:27Z

Pressings

← Older revision		Revision as of 05:44, 25 October 2013
Line 34:		Line 34:

	==Pressings==		==Pressings==
	~~AccurateRip v2 was introduced to lessen the impact of pressings.~~ Pressings, for AccurateRip's purposes, are where a batch of identical audio CDs is created by the pressing plant, then another batch is created, usually at a later date, with the same data but a different offset. The offset is due to variations in the way the master discs are replicated for the pressing machinery. Apart from this offset, discs across pressings are identical; the audio data on them is exactly the same. ~~Previously~~, ~~AccurateRip~~ could only verify results for a specific pressing (same data, same offset), ~~but an~~ AccurateRip v2 ~~compatible program is able~~ to ~~verify a pressing not currently in the database by using results from any of the other~~ pressings ~~that have the same data with a different offset~~.		Pressings, for AccurateRip's purposes, are where a batch of identical audio CDs is created by the pressing plant, then another batch is created, usually at a later date, with the same data but a different offset. The offset is due to variations in the way the master discs are replicated for the pressing machinery. Apart from this offset, discs across pressings are identical; the audio data on them is exactly the same. AccurateRip, as it was originally written, could only verify results for a specific pressing (same data, same offset), though the program's calibration procedure still made checking against alternate pressings possible. A major update to the program CUETools offered a mathematical solution to quickly cross-check a rip against multiple pressings. AccurateRip v2 would later be released to incorporate cross-checking against alternate pressings as well.

	==AccurateRip data analysis==		==AccurateRip data analysis==