Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: An attempt to interpret AccurateRip results given by CUETools (Read 8250 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

An attempt to interpret AccurateRip results given by CUETools

I made a slighly more serious test to see how accurate was accuraterip, (my first run was on rips that I knew had problems so it wasn't fair). I took 70 rips made by myself all perfectly ripped EAC secure with offset corrected & all from CD that I bought & own personnaly. So I am 100% sure all these rips are perfects. Here is the result of the test:

70  Total Number of Rips.
------------------------------------
43  Accurate+Matching Offset.
1  Accurate+Without Matching Offset [Due to Pressing not in database]
2  Accurate+Without Matching Offset [Due CDDBId mismatch (Missing Data Track)]
2  Partial Match except on last track.
2  Partial Match on last track.
5  Tangled (All Tracks Accurate somewhere but couldn't match a target offset for all tracks.)
15  Disk not present in database (9 Releases from Non-English Artists , 1 Bootleg, 1 CDDBId mismatch, One part of a 2CD release where CD1 was present & OK)
------------------------------------
Special:
1  Detected as HDCD

So is cuetools & accuraterip usefull ? I would say yes it very usefull. Should you trust it blindly, definitly no.
If the result is "Accurate+Matching Offset" (green results), you can be almost 100% sure that it is accurate, if the result is anything else, you have to rely on the EAC log.
You cannot delete a rip just because there is a Partial Match or a tangled result. If I would do so I would delete 9 of my own rips (red results) which I know are perfect.
For me accuraterip has one use:
If you rip as burst & have a "Accurate+Matching Offset" with accuraterip, your rip is just as perfect as a secure rip.
In the same way, if you have a rip without a log (or a edited/bad log) & have "Accurate+Matching Offset" with accuraterip, your rip is perfect.

In the end it is usefull for people who want to rip faster, for corruption detection &  ... for pirates who wants to be sure they downloaded a perfect rip.
Accuraterip is also very usefull when the CD is so scratched that you have no choice & can only rip it in burst mode.

Gregory:
My idea of a total matches no matter the offset summary was a bad idea. Forget about it, it's only usefull on very special problem case. I tried to fix my problem log by applying various offset & splitting & joining tracks between pressings ... I ended with a useless monster with all track accurate but still matching different pressings. I couldn't fix an accurate track from pressing X to make it match all other accurate from pressing Y. In the end these results should be reported as unknown & not as accurate. So I was wrong & the actual behaviour is right. Thks.

An attempt to interpret AccurateRip results given by CUETools

Reply #1 –
I'd feel better if your statements of "fact" were posed as questions, because I'm still not convinced you know what you're talking about.

As Spoon has stated many times, the order of certainty in catching errors goes as follows:
AccurateRip
C2 pointers
Re-reading

Quote from: sauvage78 on
I took 70 rips made by myself all perfectly ripped EAC secure with offset corrected & all from CD that I bought & own personnaly. So I am 100% sure all these rips are perfects.

100% sure, how exactly?  Because CRCs match?  Because EAC said there were no errors?  These are not a guarantee of 100% perfection.  In fact there is absolutely nothing in an EAC log that can guarantee perfection.

AR verification of tracks all with the same offset value is the closest you can come to certainty.  The only exception is when there is not a match with the last track which could be wrong either with your rip or what is in the AR database because of a bug with EAC when the overreading setting is not checked.  There can also be consistent errors in the database from drives that cannot overread and the setting is checked.  When dealing with the last track, the closest you can come to certainty is with a full match using a drive that is capable of and is configured for overreading.

Mr. Chudov, could you please explain the difference between a partial match and a non-match in layman's terms?

An attempt to interpret AccurateRip results given by CUETools

Reply #2 –
Yes, you're right I am 100% sure of myself but I should have added "within the margin of error of EAC."

All these 70 rips used these settings:

Used drive  : SAMSUNG CDRW/DVD SM-352B  Adapter: 1  ID: 0
Read mode  : Secure with NO C2, accurate stream, disable cache
Read offset correction : 6
Overread into Lead-In and Lead-Out : No

I will always trust my EAC logs better than accuraterip despite the margin of error of EAC. Because for the 9 results in red, there is always the possibility that I own a different pressing that is not in accuraterip database. Accuraterip is often unable to handle such case, just as when your CD is not at all in the database. When you have a perfectly accuraterip of a rare different pressing & that there are already several other more commun perfectly accurate rip of different pressings in the database, this is where the result can be very hard to interpret. That doesn't mean EAC is faulty. Most likely the CD was pressed using a different method. In a way despite being official the pressing is "faulty" due to its rarity. Accuraterip works best with very popular pressing, all pressed the same way. The problem is that if this is a very popular CD then there is a high probability that there are a lot of pressings. Something Spoon Da Man under-estimated. Let's encourage him for accuraterip 2.
 

An attempt to interpret AccurateRip results given by CUETools

Reply #4 –
Yes I know, but I don't know why you seem to think that I oppose Accuraterip & EAC, I don't. I only underline that both are really complementary.

In some case Accuraterip alone is enough, when it is not, you must rely on the EAC log, you don't have the choice.
I never said you should only rely on EAC logs ... personnaly when the Accuraterip log is japanese I trust the EAC log (because I know how badly scratched was or wasn't the CD) but I don't trust it blindly too.

An attempt to interpret AccurateRip results given by CUETools

Reply #5 –
Of course they are complementary.  The problem is you're trying to tell people how to interpret things which you clearly don't understand very well.  When you say EAC's margin of error what do you actually mean by this?

Instead of the bollocks that you gave, the best you can say about your results in red is that they are inconclusive.

Regarding AR2, I don't know what types of miracles you're expecting, but there will never be a way for it to demonstrate your rips of discs which have no other submissions are error-free.  Spoon may have underestimated some things when creating AR, but I don't think rare pressings of discs was one of them.

You do realize that a disc without any visible signs of damage or defect can give undetectable errors, don't you?

An attempt to interpret AccurateRip results given by CUETools

Reply #6 –
I totally agree with you on the red results, I consider them as unknown. So I rely on the EAC log because it's better than nothing.

For AR2, I hope that this will helps accuraterip in case it tells you that all your tracks are accurately ripped somewhere in the log, but ties these accurate results to two different pressings within the same offset. 5 of my logs are like this, if all accurately ripped tracks would be tied to a particular offset, as far as I understund, it would help identify a particular pressing, so tracks from different pressings would not be mixed. My rips with partial matches might be due EAC margin of error. But my tangled results are not.

Code: [Select]
[Verification date: 03/04/2009 05:34:36]
[Disc ID: 001821bb-00f11312-ab0b7f0d]
Track	[ CRC    ] Status
 01	[e8b31938] (08/49) Accurately ripped as in pressing(s) #2
 02	[2270c5ad] (08/50) Accurately ripped as in pressing(s) #2
 03	[d5d3aa81] (08/50) Accurately ripped as in pressing(s) #2
 04	[2da949d5] (09/51) Accurately ripped as in pressing(s) #2
 05	[2d8ec054] (08/50) Accurately ripped as in pressing(s) #2
 06	[2ef6fb03] (08/50) Accurately ripped as in pressing(s) #2
 07	[a42d32ed] (08/50) Accurately ripped as in pressing(s) #2
 08	[ed5a3334] (07/49) Accurately ripped as in pressing(s) #2
 09	[72d73d84] (08/50) Accurately ripped as in pressing(s) #2
 10	[0dad6b83] (08/50) Accurately ripped as in pressing(s) #2
 11	[051a4d96] (08/50) Accurately ripped as in pressing(s) #2
 12	[9869c721] (08/50) Accurately ripped as in pressing(s) #2
 13	[688497e9] (07/49) Accurately ripped as in pressing(s) [color=#FF0000]#3[/color]
Offsetted by -664:
 01	[fb408b16] (11/49) Accurately ripped as in pressing(s) #3
 02	[120ec26c] (11/50) Accurately ripped as in pressing(s) #3
 03	[85f0005e] (11/50) Accurately ripped as in pressing(s) #3
 04	[b8a33a89] (11/51) Accurately ripped as in pressing(s) #3
 05	[9ee9fa8c] (11/50) Accurately ripped as in pressing(s) #3
 06	[05266d98] (11/50) Accurately ripped as in pressing(s) #3
 07	[403cb7a9] (11/50) Accurately ripped as in pressing(s) #3
 08	[edb3f690] (11/49) Accurately ripped as in pressing(s) #3
 09	[5ee9bf2c] (11/50) Accurately ripped as in pressing(s) #3
 10	[db81fbd8] (11/50) Accurately ripped as in pressing(s) #3
 11	[6318fe63] (11/50) Accurately ripped as in pressing(s) #3
 12	[8327d2c8] (11/50) Accurately ripped as in pressing(s) #3
 13	[5450181d] (11/49) Accurately ripped as in pressing(s) [color=#FF0000]#2[/color]

Track	[ CRC32  ]	[W/O NULL]	[  LOG   ]
 --	[C04C0029]	[B504C32B]	 W/O NULL 
 01	[761D8B53]	[3A060ABE]	
 02	[652FA4C0]	[BF458F43]	
 03	[443FC333]	[910C9063]	
 04	[67AF66EB]	[56FF1809]	
 05	[032967CB]	[6D9A284D]	
 06	[F1AF0183]	[5BA95345]	
 07	[3975EA10]	[17357CF5]	
 08	[75689670]	[69435E30]	
 09	[7C7E63EE]	[CE2DC789]	
 10	[BFA70D31]	[E2C57C5D]	
 11	[90D1CACC]	[17DC757E]	
 12	[A28F31AA]	[9F45450E]	
 13	[DA03CD32]	[3D096CE2]

As I am very stupid I may be wrong  but, as far as I understund, these results could be fixed with an accuraterip design improvement, no ?

Edit: I agree you can split the thread in fact all this should be asked to Spoon. I didn't knew where to post, so as I used cuetool I posted here.

An attempt to interpret AccurateRip results given by CUETools

Reply #7 –
Ignore the pressing numbers.  They are not particularly meaningful.

Quit talking about EAC's margin of error unless you wish to make some attempt to define it in some type of meaningful way.

Quote
I agree you can split the thread in fact all this should be asked to Spoon.
Like what?  Very little (if any) of what's been raised here hasn't already been addressed elsewhere in one form or another.

An attempt to interpret AccurateRip results given by CUETools

Reply #8 –
Quote
As Spoon has stated many times, the order of certainty in catching errors goes as follows:
AccurateRip
C2 pointers
Re-reading


On a good drive yes, on drives which support C2 poorly the last two could be inter-changable.

RE Post 7,  AR is designed on tracks, not discs, so the order of the matches mean nothing (tracks from different pressings can be swapped all over the place), a match is a match.

An attempt to interpret AccurateRip results given by CUETools

Reply #9 –
AccurateRip was such a simple, elegant concept. Why do so many people have a problem with it?

An attempt to interpret AccurateRip results given by CUETools

Reply #11 –
I really don't understand why so many people seem to have a problem with the concept. As soon as spoon announced what he was diong, I contacted him and he sent me a CD to calibrate the offset of my drive (there were only a few dozen refernce CDs at the time). I then passed my entire collection through AccurateRip, not to rip them (they had already been ripped), but to help populate the database.

An attempt to interpret AccurateRip results given by CUETools

Reply #12 –
I really have no personal gripes about AR.  Like with any tool, some understanding of how it works can go a long way in getting the most use out of it.

Still, some people seem to think it's magically omniscient.  Others want hard and fast rules about what they read.  "I read once that spoon says you need a confidence of X or else you can't rely on the result."  It's this kind of thing that annoys me to no end.  Except for Murphy's law, there really are no hard and fast rules to DAE.

It used to be that people had a hard time with a program saying their rips aren't accurate.  I did my best to curtail it by seeing that the wording get changed.  It made a lot more sense than getting on my soapbox and preaching to the deaf.  People are still faced with confidence levels for results that don't match.  When there is more than one pressing in the database for a given disc (which has got to be the case for the majority of lookups) the confidence levels for non-matches are often just noise.  Still, an explanation for this behavior for those who come looking is easily managed.

Now we have a program that give results for multiple pressings.  While I am extremely grateful for such a tool and am equally glad for a poorly designed checksum which allowed it to work so quickly, there is a down-side.  With a wealth of data there is an increased risk that people will misinterpret it.  Explanations become harder also.

Gregory, if you are reading this, I implore you to remove the pressing numbers from your output; they are worthless.  The offset is what matters.  There is no point in adding conflicting numbers.  They do nothing more than confuse people.  This discussion provides a perfect example.

An attempt to interpret AccurateRip results given by CUETools

Reply #13 –
Thks, Mr Spoonman.

But ... we're back to the start, if "a match is a match" then showing a total matches per track summary in front of the log wasn't so stupid afterall.

Well, anyway now that I know I shouldn't trust the "#pressing Number", I don't consider it really usefull anymore as I think I know how to read the log now. It would only be usefull in the special case when the same rip is splitted in several offsets which I called "offset mismatch" in the original thread (& only if it was pressing report was accurate, which it is not). This is a very strange case, which I still don't really understand. Personnaly, I put the fault on a "damaged drive" which lose or duplicate samples right in the middle of a rip, introducing an offset lag.

From now on, I will consider my tangled results OK if all tracks match a target offset within the same rip. This is very logic if you consider that, when the offset matches but not the reported pressing, the tracks reported from pressing X usually have the same number of matches than those reported from pressing Y. If it was really two different pressings it would be very unlikely.

Now, I agree with Greynol, I would rather ask Gregory to completely remove the #pressing number which is useless & missleading & only rely on offsets, than ask him for a total matches per track summary like I did.

PS:
As a sidenote, I second the two guys from this thread Accuraterip Update Date, it would be very nice if we would be aware of the database update somewhere. Specially to re-check the "Not present in database" or "confidence 1" results.

"All my friends are skeletons
They beat the rhythm with their bones,
Spoonman" --Soundgarden--

The Spoonman saved me, I'm together with his plan

An attempt to interpret AccurateRip results given by CUETools

Reply #14 –
Quote from: sauvage78 on
But ... we're back to the start, if "a match is a match" then showing a total matches per track summary in front of the log wasn't so stupid afterall.

You're taking liberty with his words that I am certain he didn't intend.  Lumping matches with different offsets when you can't get a full set of matches from any one single offset can be dicey.  In the case of an error due to repeated samples where one track can only give a partial match, as I already mentioned and you were able to give yet another example, it is a bad idea.

Quote from: sauvage78 on
Personnaly, I put the fault on a "damaged drive" which lose or duplicate samples right in the middle of a rip, introducing an offset lag.
This can be a problem with a buggy drive design giving consistent results between different people.