Ripping CDs: Is AccurateRip really necessary, or just being anal?

That is just the number of people that have submitted accurate rips to the database. It is irrelevant because even if there's only one match, the chances of them being being identically wrong is less than negligible. If it says "accurate" you're fine.

 

Thanks.

 

I think that if the accurate number on many tracks is say accurate (11), and you have inaccurate on one song and that number is even larger say inaccurate (18), then I suspect that your inaccurate song matches up with more folks than the (original) accurate ones do, thus it is likely that some differences in pressings/mastering have made some differences in a track or two (or a CD-R copy with error has been entered into the database but many people), and I would expect that the inaccurate (18) is just fine, and absolutely nothing to be concerned about. If the inaccurate is very low, lower then the accurate, then you have a bum read or the track. The CD-R scenario is not a good thing, but otherwise I am fine with high number on a inaccurate read.

Any others see this happen and agree, or not?

 

Thanks.

 

I wouldn't try to read too much into the whys or consequences of certain tracks having a very different inaccurate number than other tracks. There can be various reasons for that. Perhaps just one person has a badly scratched CD and tries ripping that track in 5 different drives (I've done that) to try to get a good rip. Perhaps there's a badly ripped version with a bad track out on the pirate sites and some people are running that bad rip through AccurateRip verification. Or someone ripping a CD-R copy. Or some discs being out there that have much larger offsets than other versions of the disc. Or other reasons. I try not to assume too much about how high or low the inaccurate number(s) is. Too many unknowns.

The only important part is getting at least one accurate match. Getting just one accurate match is good enough.

Another issue with AccurateRip is that it is track based rather than disc based. And it doesn't handle large offsets well. It can't get a match to other pressings if the offsets for the other pressings is too high. The CUETools database is disc based and is able to handle offsets better.

 

No. The (number) always means the same thing - the quantity of accurate rips in the database.

 

Again please? What does an inaccurate (18) mean against an accurite(13) on same disc? They both are number of accurite rips? Why is one number much higher? Thanks in advance for clarification.

Btw I am hearing no glitches on discs playing back when they get this high number in the inaccurate (18) reading. They could have an error but glad I never heard it.

It's been stated here in the forum that bad error infected discs have made it into the database, so why would there be no record of theses such as (18) as seen on that Stax 72-75 box set disc last night which I almost screen capped for this thread?

 

I've never seen a reading that specifies an inaccurate number. Do you mean when there are two numbers in parentheses, like "(43/18)" or "(4/25)"?

The first number is the number of matches in the database, and the second number is the number of non-matches. But non-matches don't mean your rip is inaccurate - it just means there's more than one variation of this CD in the database. Repressings of the same CD from different plants, different runs, etc. can have different offsets, volume/level shifts, even the occasional undocumented "secret" remastering. But as others have said, if you get at least one match in the database (and you are ripping a real, pressed CD, not a CD-R copy), then it's almost certain your rip is accurate. And if you get two or more matches, it's virtually certain your rip is accurate. So even a "(3/167)" result is an accurate rip - it just means that your particular variation of the CD is less common.

 

I was pretty clear in my post that there were different numbers for accurate and inaccurate songs (on same disc). Where is there confusion?

Pervious poster stated that both numbers were numbers for accurate, which sounds odd to me.

Perhaps I should have posted a scream cap if this is not clear.

 

It’s simply the total number of accurate rips for that track.

Different numbers among tracks of the same album is evidence that there have been submittals of rips with some tracks having errors. The more popular the disc, the larger the total number and the greater likelihood of the numbers diverging.

I suggest that you find a popular disc that you’ve ripped that has errors that couldn’t be corrected and let cuetools correct the rip. The accurate rip total number doesn’t change from before and after the correction.

This is a corrected rip of Chris Isaak’s “Heart Shaped World” and the total numbers didn't change:

Code:

[CUETools log; Date: 2/21/2013 1:45:11 PM; Version: 2.1.4]
Pregap length 00:00:32.
CUETools DB: corrected 1587 errors.
[AccurateRip ID: 001215ba-009f04d7-990ad20b] found.
Track  [  CRC  |  V2  ] Status
01  [8cc49448|97bf8e82] (082+010/558) Accurately ripped
02  [5c7fd0ea|7c50aa50] (080+010/547) Accurately ripped
03  [f7644b52|e4ffb1cf] (080+010/549) Accurately ripped
04  [726995f0|4703ad9e] (080+010/553) Accurately ripped
05  [432edfec|8de7d1ed] (083+010/564) Accurately ripped
06  [b217f658|201b5196] (082+010/552) Accurately ripped
07  [3b59ed06|4d3752ab] (082+010/553) Accurately ripped
08  [48c02112|7e86b0d0] (081+010/545) Accurately ripped
09  [54a7ea29|e8e41ae5] (080+010/547) Accurately ripped
10  [e2a29c05|891fa830] (078+010/537) Accurately ripped
11  [d2e3bf38|1e09cfe0] (076+010/528) Accurately ripped
Offsetted by -2532:
01  [a11bf584] (049/558) Accurately ripped
02  [b2daecd6] (048/547) Accurately ripped
03  [1376e7e2] (046/549) Accurately ripped
04  [d0a32274] (047/553) Accurately ripped
05  [458f0360] (048/564) Accurately ripped
06  [4fd12b0c] (047/552) Accurately ripped
07  [f9398f26] (046/553) Accurately ripped
08  [1d2041f2] (046/545) Accurately ripped
09  [317db52d] (047/547) Accurately ripped
10  [dfa47d89] (047/537) Accurately ripped
11  [6a6cd2ac] (047/528) Accurately ripped
Offsetted by -697:
01  [c46a2e57] (045/558) Accurately ripped
02  [0b6c9ca5] (045/547) Accurately ripped
03  [9576c376] (045/549) Accurately ripped
04  [5916f351] (045/553) Accurately ripped
05  [6af70a09] (045/564) Accurately ripped
06  [fe2b18c5] (045/552) Accurately ripped
07  [68a4878e] (045/553) Accurately ripped
08  [6a57274a] (045/545) Accurately ripped
09  [bf257f2a] (045/547) Accurately ripped
10  [26dddea6] (042/537) Accurately ripped
11  [230d3953] (042/528) Accurately ripped
Offsetted by -102:
01  [d359b112] (107/558) Accurately ripped
02  [56e0e87c] (104/547) Accurately ripped
03  [9e22506a] (105/549) Accurately ripped
04  [3682f4c6] (105/553) Accurately ripped
05  [bfa394ea] (107/564) Accurately ripped
06  [aa7eaa36] (104/552) Accurately ripped
07  [a5e1b8b6] (105/553) Accurately ripped
08  [4daa85e2] (105/545) Accurately ripped
09  [ce62e0bf] (106/547) Accurately ripped
10  [1e924e5b] (101/537) Accurately ripped
11  [97cbfafa] (100/528) Accurately ripped
Offsetted by -68:
01  [667d5224] (148/558) Accurately ripped
02  [036b35f6] (144/547) Accurately ripped
03  [bbe2f962] (147/549) Accurately ripped
04  [4a7a7fd4] (150/553) Accurately ripped
05  [40d20340] (155/564) Accurately ripped
06  [ad0718ec] (147/552) Accurately ripped
07  [2d09ca26] (148/553) Accurately ripped
08  [4c070ef2] (144/545) Accurately ripped
09  [fb248e8d] (145/547) Accurately ripped
10  [5fed12e9] (146/537) Accurately ripped
11  [4a2763fe] (143/528) Accurately ripped
Offsetted by 92:
01  [31216f90] (048/558) Accurately ripped
02  [e4142a16] (049/547) Accurately ripped
03  [a2406ee2] (048/549) Accurately ripped
04  [e4ad0e34] (049/553) Accurately ripped
05  [bed9b020] (048/564) Accurately ripped
06  [316b03cc] (049/552) Accurately ripped
07  [127b0d26] (049/553) Accurately ripped
08  [bcc993f2] (047/545) Accurately ripped
09  [faf038ed] (047/547) Accurately ripped
10  [937a1949] (047/537) Accurately ripped
11  [d71f55ed] (043/528) Accurately ripped
Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
--  99.9 [63718302] [D34E20FC] [47E86491]
01  85.4 [1EAE4F40] [FECA415F] 
02  83.5 [AB4E8DC4] [B9C01D58] 
03  84.8 [4C758946] [EAEECE67] 
04  80.6 [9464D8BD] [599E5E60] 
05  69.4 [724C9B7B] [EEFFEB8D] 
06  57.7 [A3EE6A6C] [F6ABAF27] 
07  93.4 [D80C5FE2] [27736067] 
08  74.3 [DD944015] [95D6708D] 
09  72.8 [E68D6AEB] [2E0DABA4] 
10  95.0 [F5DC38F5] [AE85942D] 
11  99.9 [B87337E6] [19E5C62E] 

 

Here's the disc before correction (I edited out the error sample times becuase it was huge amount of text):

Code:

[CUETools log; Date: 2/21/2013 1:44:14 PM; Version: 2.1.4]
Pregap length 00:00:32.
[CTDB TOCID: 3P03YwFP1EaiQK_87c0_H6peWmo-] found.
  [ CTDBID ] Status
  [230d64b6] (8/8) Differs in 1587 samples
Track | CTDB Status
  1  | (8/8) Differs in 852 samples
  2  | (8/8) Differs in 449 samples
  3  | (8/8) Differs in 119 samples
  4  | (8/8) Accurately ripped
  5  | (8/8) Accurately ripped
  6  | (8/8) Accurately ripped
  7  | (8/8) Differs in 165 samples
  8  | (8/8) Accurately ripped
  9  | (8/8) Accurately ripped
 10  | (8/8) Differs in 2 samples
 11  | (8/8) Accurately ripped
[AccurateRip ID: 001215ba-009f04d7-990ad20b] found.
Track  [  CRC  |  V2  ] Status
 01  [f87ee303|03695510] (000+000/558) No match
 02  [35e0cd57|55b074c2] (000+000/547) No match
 03  [aa45d032|97e6d237] (000+000/549) No match
 04  [726995f0|4703ad9e] (080+010/553) Accurately ripped
 05  [432edfec|8de7d1ed] (083+010/564) Accurately ripped
 06  [b217f658|201b5196] (082+010/552) Accurately ripped
 07  [2899a037|3a213ad3] (000+000/553) No match
 08  [48c02112|7e86b0d0] (081+010/545) Accurately ripped
 09  [54a7ea29|e8e41ae5] (080+010/547) Accurately ripped
 10  [9efc9c05|45798fb0] (000+000/537) No match
 11  [d2e3bf38|1e09cfe0] (076+010/528) Accurately ripped
Offsetted by -2532:
 01  [fa31390f] (000/558) No match (V2 was not tested)
 02  [a9a34873] (000/547) No match (V2 was not tested)
 03  [01aeba5a] (000/549) No match (V2 was not tested)
 04  [d0a32274] (047/553) Accurately ripped
 05  [458f0360] (048/564) Accurately ripped
 06  [4fd12b0c] (047/552) Accurately ripped
 07  [d030bcc7] (000/553) No match (V2 was not tested)
 08  [1d2041f2] (046/545) Accurately ripped
 09  [317db52d] (047/547) Accurately ripped
 10  [105e7d89] (000/537) No match (V2 was not tested)
 11  [6a6cd2ac] (047/528) Accurately ripped
Offsetted by -697:
 01  [b0f9af46] (000/558) No match (V2 was not tested)
 02  [c4a83bde] (000/547) No match (V2 was not tested)
 03  [4b6f213c] (000/549) No match (V2 was not tested)
 04  [5916f351] (045/553) Accurately ripped
 05  [6af70a09] (045/564) Accurately ripped
 06  [fe2b18c5] (045/552) Accurately ripped
 07  [9215385b] (000/553) No match (V2 was not tested)
 08  [6a57274a] (045/545) Accurately ripped
 09  [bf257f2a] (045/547) Accurately ripped
 10  [764fdea6] (000/537) No match (V2 was not tested)
 11  [230d3953] (042/528) Accurately ripped
Offsetted by -102:
 01  [b5d58a45] (000/558) No match (V2 was not tested)
 02  [254f2871] (000/547) No match (V2 was not tested)
 03  [004bdc0e] (000/549) No match (V2 was not tested)
 04  [3682f4c6] (105/553) Accurately ripped
 05  [bfa394ea] (107/564) Accurately ripped
 06  [aa7eaa36] (104/552) Accurately ripped
 07  [9bf0654f] (000/553) No match (V2 was not tested)
 08  [4daa85e2] (105/545) Accurately ripped
 09  [ce62e0bf] (106/547) Accurately ripped
 10  [cafc4e5b] (000/537) No match (V2 was not tested)
 11  [97cbfafa] (100/528) Accurately ripped
Offsetted by -68:
 01  [cc0dfd2f] (000/558) No match (V2 was not tested)
 02  [2ad50a13] (000/547) No match (V2 was not tested)
 03  [8e49d81a] (000/549) No match (V2 was not tested)
 04  [4a7a7fd4] (150/553) Accurately ripped
 05  [40d20340] (155/564) Accurately ripped
 06  [ad0718ec] (147/552) Accurately ripped
 07  [2028ce47] (000/553) No match (V2 was not tested)
 08  [4c070ef2] (144/545) Accurately ripped
 09  [fb248e8d] (145/547) Accurately ripped
 10  [11a712e9] (000/537) No match (V2 was not tested)
 11  [4a2763fe] (143/528) Accurately ripped
Offsetted by 92:
 01  [68f5f61b] (000/558) No match (V2 was not tested)
 02  [ae3c02b3] (000/547) No match (V2 was not tested)
 03  [b2041fda] (000/549) No match (V2 was not tested)
 04  [e4ad0e34] (049/553) Accurately ripped
 05  [bed9b020] (048/564) Accurately ripped
 06  [316b03cc] (049/552) Accurately ripped
 07  [613243c7] (000/553) No match (V2 was not tested)
 08  [bcc993f2] (047/545) Accurately ripped
 09  [faf038ed] (047/547) Accurately ripped
 10  [5e341949] (000/537) No match (V2 was not tested)
 11  [d71f55ed] (043/528) Accurately ripped
Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  99.9 [B1BB506A] [47E86491]  W/O NULL 
 01  85.4 [5EE6B9AD] [BF358621]  
 02  83.5 [6B1381AB] [3B6BF073]  
 03  84.8 [CBF2C497] [19814945]  
 04  80.6 [9464D8BD] [599E5E60]  
 05  69.4 [724C9B7B] [EEFFEB8D]  
 06  57.7 [A3EE6A6C] [F6ABAF27]  
 07  93.4 [6C39A580] [4D8132E0]  
 08  74.3 [DD944015] [95D6708D]  
 09  72.8 [E68D6AEB] [2E0DABA4]  
 10  95.0 [BD53E77E] [7F343AC5]  
 11  99.9 [B87337E6] [19E5C62E]  

 

If you look at all those examples, they say things like (107/564) Accurately ripped.

My understanding is that this means that your rip matches 107 out of 564 total entries for this CD in the Accuraterip database.

My understanding also is that the other 457 rips (564 minus 107) might or might not match each other, but they are not necessarily inaccurate, and chances are most of them are simply from a slightly different version of the CD and most of them match each other.

Once again if AccurateRip reports (107/564), it's an accurate rip - and it's no more or less accurate that a rip that would report (15/564) or (500/564). Those different numbers simply refer to different variations of the CD which may be more or less plentiful out there in the world. The different numbers don't refer to how accurate the rip is.

 

No, that makes no sense. If it says "Inaccurate (18)" it means there are 18 matching CRCs in the database and yours doesn't match any of them. It doesn't mean there are 18 inaccurate submissions that are all the same.

It's been demonstrated time and time again that different pressings produce identical digital outputs, as long as offsets are correctly accounted for (which they should be when using AccurateRip).

Correct. Different masterings of the same album, for example, would cause this to happen.

 

I believe that everything is now less clear to me. Thanks all.

 

Then please explain this inaccurate(18) in the context of the accurate(11), that is the crust of the biscuit here. Not simply saying that my disc does not match 18 matching entries -- that does not cover the topic as I discussed it.

Did you just say that there are 18 matching entries, and mine does not match any of them, or did you mean there are 18 matching entries and mine did not match them? Difference in wording is the key here.

By saying mine did not match any of them -- you could have stated that there are 18 different entries (for the track in question), and yours did not match any of them.

Yes, the wording needs to be more clear here.

 

I agree that the writing cod use better clarity. And screen caps should be used.

I want to know why the number is so much larger for the inaccurate number than the accurate one. We know they have been submitted by users, but why a difference? Unless the pool is contaminated with bum tracks.

I say we avoid talk of different pressings and masterings and stick to a given cd and it's rip results when shown in accurateRip.

 

The latter. Each track having a different number of matching entries is not surprising, considering different rips will have different numbers of accurate and inaccurate tracks (like yours).

 

No, in my case all accurate tracks come up with exact same numbers (11) and the two inaccurate tracks are at (18). Nothing you have said explains this oddity.

 

I see. Are you using dbPowerAmp? I have only ever used EAC and they might report different things in their logs.

 

Sure I did. Please read my previous 2 posts and the log sheets. The total number did not change for the inaccurate tracks after they were corrected.

 

With all due respect, you seem to be repeating a basic incorrect piece of information that keeps muddying the waters. As stereoptic noted above, AccurateRip results don't actually say "Inaccurate" with a number in parentheses.

Instead, the results tell you if the track on the CD was ripped Accurately. If so, you then get two numbers in parentheses. The first number is how many rips in the database match yours. The second number is how many rips are in the database.

The point is, this second number has nothing to do with inaccurate rips. The reason the second number is bigger than the first number is because the second number is the total number of rips in the database. So the first number by definition will always be equal to or (more commonly) less than the first number.

So your premise - that Accuraterip results include a number representing "inaccurate" rips (or some kind of level of inaccuracy in your own individual rip) - is mistaken.

 

It's not odd at all. It is the expected result. The tracks that were imported accurately match a smaller number (11) of entries in the database that were also imported accurately. The tracks that came up as not matching other entries are being compared to a larger database (18), that's because it is comparing against all tracks in the database, not just those judged to have been ripped accurately. In this case yours didn't match any of the submissions, the "accurate" ones or the "inaccurate" ones. The probability of two "inaccurate" rips matching exactly is small enough to disregard. Keep in mind, the only way it "knows" the rip is "accurate" is by comparing to other entries.

 

This is not true. I am using dbPowerAmp on an old Windows 7 machine. I rip about 30 or 40 discs a week, just part time and just for fun. These are all CDs, I do not rip CDRs. I often get one song or even two songs that say "Inaccurate (8)" or something like that. For an example, a disc might have 15 songs on it, and 14 might come back as Accurate (4) and one might come back as Inaccurate (7). I just want to know why the one song, in the middle of a disc, might come back as Inaccurate (X).

 

A song in the middle of the disc will fail the AccurateRip check if the song wasn't accurately ripped. You aren't going to get a more useful answer than this until you post the full AR log for a rip where you're seeing this behavior and explain exactly what it is about the log that you don't understand, so people can directly respond to your specific issue rather than having to speak in generalities.