I couldn't find an exact answer to this, neither here nor via Google. Even a "partial answer" would be nice...
This is my log:
[Verification date: 22.02.2010 22:39:34]
[Disc ID: 001981ca-00f038f7-950ded0c]
Offset applied: 6
Track [ CRC ] Status
01 [21732149] (15/15) Accurately ripped
02 [b80cf282] (15/15) Partial match
03 [d58ef0a7] (15/15) Accurately ripped
04 [a2fea1b1] (15/15) Accurately ripped
05 [1e16a8ad] (15/15) Accurately ripped
06 [98890d9d] (15/15) Accurately ripped
07 [7c96fb58] (15/15) Accurately ripped
08 [7b334595] (16/16) Accurately ripped
09 [4ff920c5] (15/15) Accurately ripped
10 [158c4934] (15/15) Accurately ripped
11 [c8e5b461] (15/15) Accurately ripped
12 [3a227c63] (13/13) Accurately ripped
It means that the small part of the checksum that is used for the offset/pressing detection match, but the overall checksum for the track doesn't match.
When it happens it's either that there is a scratch or that you have a pressing that is not in database which only differ by the offset & a few samples. (Due to more or less silence at the beginning/end of tracks)
Usually this is not good, but there are exceptions: when the offset only affect the checksum of the track that does not match but not the checksums of the other tracks.
Edit:
For exemple the rip below is perfectly accurate but IF the first pressing would NOT be in database, you may think that it could be scratched which it is not.
Overall you cannot rely on "Partial match" alone to tell if a rip is scratched, specially if there is "no matches" with the current offset. All you can say is that if differs from the current status of the database.
[Verification date: 27/08/2009 16:13:57]
[Disc ID: 0019af0c-00df8b28-a50fa70b]
Track [ CRC ] Status
01 [8a2b7666] (08/10) Accurately ripped
02 [1ad155bd] (06/10) Accurately ripped
03 [4716c306] (08/10) Accurately ripped
04 [192d975c] (06/10) Accurately ripped
05 [7e0f6068] (08/10) Accurately ripped
06 [fcbdb5e9] (06/10) Accurately ripped
07 [56a40d24] (07/09) Accurately ripped
08 [c9fe3e3a] (06/08) Accurately ripped
09 [6592c040] (08/10) Accurately ripped
10 [49316653] (06/10) Accurately ripped
11 [8826fae8] (07/09) Accurately ripped
Offsetted by -517:
01 [2dc40d18] (02/10) Accurately ripped
02 [94148715] (02/10) Partial match
03 [fc026d53] (02/10) Accurately ripped
04 [3112c236] (02/10) Partial match
05 [1a44cc9e] (02/10) Accurately ripped
06 [10cc7bb4] (02/10) Partial match
07 [56e255d2] (02/09) Accurately ripped
08 [eb3f8a06] (02/08) Partial match
09 [0bc5ccea] (02/10) Accurately ripped
10 [a16f98af] (02/10) Partial match
11 [289bb4f2] (02/09) Accurately ripped
Track [ CRC32 ] [W/O NULL] [ LOG ]
-- [33F1533B] [5E49088C] W/O NULL
01 [7AAD7E83] [B0749A9D]
02 [F31F13A2] [BB79B7F4]
03 [7F2DFAD6] [65C153C0]
04 [046B79E3] [9D791AAE]
05 [B56C2ECB] [7E50C46A]
06 [44DDC7E6] [C30DE29E]
07 [10DA731E] [BB7093BA]
08 [A1730998] [4F26BF50]
09 [D79ABF51] [A7FEE9F8]
10 [74A6A071] [928E483A]
11 [464FF75B] [3083A264]
http://www.hydrogenaudio.org/forums/index....st&p=593356 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=593356)
I would refrain from drawing any conclusions about a partial match considering that the offset checksum is generated over just one frame of audio data (only 588 samples!).
Thank you both very much!
Since there seems to be
just one pressing
(see log before offset correction), I guess the track is irreparably damaged, then. And I can't re-rip, either.
[Verification date: 23.02.2010 00:24:41]
[Disc ID: 001981ca-00f038f7-950ded0c]
Track [ CRC ] Status
01 [bf93b913] (00/15) No matches
02 [f4341d88] (00/15) No matches
03 [19f191dd] (00/15) No matches
04 [e7d4401b] (00/15) No matches
05 [823ed4cb] (00/15) No matches
06 [3415d12b] (00/15) No matches
07 [d4092951] (00/15) No matches
08 [37415c1a] (00/16) No matches
09 [9c9abce3] (00/15) No matches
10 [a2f1d8d6] (00/15) No matches
11 [8106c863] (00/15) No matches
12 [130b75c5] (00/13) No matches
Offsetted by 6:
01 [21732149] (15/15) Accurately ripped
02 [b80cf282] (15/15) Partial match
03 [d58ef0a7] (15/15) Accurately ripped
04 [a2fea1b1] (15/15) Accurately ripped
05 [1e16a8ad] (15/15) Accurately ripped
06 [98890d9d] (15/15) Accurately ripped
07 [7c96fb58] (15/15) Accurately ripped
08 [7b334595] (16/16) Accurately ripped
09 [4ff920c5] (15/15) Accurately ripped
10 [158c4934] (15/15) Accurately ripped
11 [c8e5b461] (15/15) Accurately ripped
12 [3a227c63] (13/13) Accurately ripped
Track [ CRC32 ] [W/O NULL] [ LOG ]
-- [48757673] [BF7722FB]
01 [3F5FA623] [28DE9AC4] W/O NULL
02 [75BB40A0] [E925015F] W/O NULL
03 [0C608F4F] [9AACA549] W/O NULL
04 [FE40ACE7] [C403E546] W/O NULL
05 [E5A4C6AE] [0D7489A2] W/O NULL
06 [170ADB65] [1E4CC506] W/O NULL
07 [51425268] [79E65EFF] W/O NULL
08 [C8554435] [96CD8A4B] W/O NULL
09 [204B4FEA] [C2263399] W/O NULL
10 [A4E2BCB5] [96C12BEB] W/O NULL
11 [F8964949] [33632CA9] W/O NULL
12 [45C18ABC] [CC86E193] W/O NULL
Edit set in italics.
For your exemple, unless you know that the offset wasn't corrected in the original rip & unless you know that the drive offset was 6, you shouldn't have corrected offset "Offset applied: 6", because you know for sure that with "Offset applied: 6" track 2 doesn't match, while maybe without correcting the offset the rip would be accurate but this matching pressing is just currently not present in database.
This is why, personnaly, I only correct offset if & only if:
-all tracks match within a target pressing/offset.
-& with a confidence of 2 minimum.
Edit: Typo Doesn't
As for drawing a conclusion, if your drive offset is 6 then yes it is likely scratched, if your drive offset is not 6, all you can say is unknown yet, re-check later.
The EAC log can help you draw a definitive answer for yourself, if both EAC log & Accuraterip says it is scratched then it is scratched. Usually Accuraterip never match when EAC log says "there were errors". But Accuraterip often disagree when EAC says everything is OK, specially with bad EAC settings. If used correctly both are complementary.
The log says "Track quality 99.9 %, Copy OK". Settings were "Secure with NO C2, accurate stream, disable cache", so everything looks good. But I think I'll trust AR on this. The record "Björk: Family Tree" is quite rare. There possibly aren't many different pressings. And 15 identical matches except my rip looks pretty convincing. The term "partial match" had just raised some hope that the whole thing might be fixable somehow. Thanks for explaining all this in detail!
Can you hear any problems?
I have seen lots of "bad" rips that appear to be just fine when the tracks are listened to. (Yes, it is actually possible to listen to them. )
In addition, quite often when re-ripping doesn't help it is still possible to fix minor clicks (or at least make them significantly less audible) with an audio editor.
Edit: fixed a typo
Can you hear any problems?
No, not really. It is rather some kind of fetish... Having a collection with thousands of tracks each having an "AR verified"-tag, except for one, just annoys me much more than it should.
http://www.hydrogenaudio.org/forums/index....st&p=593356 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=593356)
I would refrain from drawing any conclusions about a partial match considering that the offset checksum is generated over just one frame of audio data (only 588 samples!).
I do not think the offset checksum applies here (cuetools does not use it?), even if the offset checksum was used to find muliple pressing offsets and there were false offsets detected from those 588 samples, it would not matter as that false pressing offset would never match a real pressing in AR and would be ignored.
Actually, greynol is right. Partial match is an offset checksum match, and this message is the only case when CUETools uses it. Basically, "partial match" is the same as "no match".
'Partial Match' is very misleading then, I would suggest that it is removed as the offset CRC means nothing as far as audio quality.
I was thinking of renaming it to something like "No match, but offset is probably right". If only i can think of a shorter wording for that.
'Offset Match'
Thanks!
Personnaly, I prefer a mix of the two: either "No match, but offset match" or "No match, except offset".
IMHO keeping "No match" in front makes it clear that something might not be right.
"Offset Match" alone seems too positive for newbie, if you don't know what it means.
The problem with "Partial match" is that it matches, "Offset Match" still creates the same confusion (even if slightly better). Whatever you chose, IMHO the new wording must make it clear that in fact it doesn't match.
Offset match only