Ok, do you think that the following example too fall on that "offset pressings exist outside of the offset test range" reason too?
Just 1st track, other tracks with 14-16 matches (that can't be verified too):
Track 1
Various - Austin Powers (OST) - 01 - The Magic Piper (Of Love) [Edwyn Collins].flac
Peak level 99.8 %
Copy CRC 8A417A8F
Cannot be verified as accurate (confidence 14) [49A69F0B], AccurateRip returned [6251A88D]
Copy OK
CUETools log:
[Disc ID: 002205c8-01b2cffd-f10d7a11]
Track [ CRC ] Status
01 [49a69f0b] (00/31) No matches
02 [53298dcd] (00/32) No matches
03 [e6993d2b] (00/32) No matches
04 [10534e40] (00/31) No matches
05 [1458a289] (00/32) No matches
06 [d3517978] (00/32) No matches
07 [8ccbd6a4] (00/32) No matches
08 [6ab36e8e] (00/33) No matches
09 [aa656e8a] (00/34) No matches
10 [c6db7642] (00/33) No matches
11 [972d4ece] (00/32) No matches
12 [0897dc11] (00/32) No matches
13 [169ed3b5] (00/33) No matches
14 [4d5e88c7] (00/32) No matches
15 [b2f3d22c] (00/32) No matches
16 [fb0e8a8a] (00/32) No matches
17 [9da6fa2e] (00/30) No matches
Offsetted by 259:
01 [8d45c8cf] (07/31) Accurately ripped
02 [7792a015] (07/32) Accurately ripped
03 [0c249e17] (07/32) Accurately ripped
04 [c466be04] (07/31) Accurately ripped
05 [8501c6f3] (07/32) Accurately ripped
06 [57f8c17b] (07/32) Accurately ripped
07 [1ed5a1fa] (07/32) Accurately ripped
08 [fd9f995b] (07/33) Accurately ripped
09 [786e71f1] (07/34) Accurately ripped
10 [183130a6] (07/33) Accurately ripped
11 [cd7c6f1b] (06/32) Accurately ripped
12 [b6a5d94d] (06/32) Accurately ripped
13 [17620c6d] (07/33) Accurately ripped
14 [53cc68b0] (07/32) Accurately ripped
15 [d187cb41] (07/32) Accurately ripped
16 [b219666e] (07/32) Accurately ripped
17 [4fd31c1b] (07/30) Accurately ripped
Track [ CRC32 ] [W/O NULL] [ LOG ]
-- [516229E9] [EA29550D]
01 [8A417A8F] [3CC73389] CRC32
02 [76C83C34] [880A5BFC] CRC32
03 [EB9CBF19] [4401D4AE] CRC32
04 [083B9C3B] [E8F3347A] CRC32
05 [00E06EB4] [C34241A9] CRC32
06 [F648BA60] [5EBB9B83] CRC32
07 [F0FB4D47] [EBABE622] CRC32
08 [79B89256] [2296146F] CRC32
09 [C52AB8A5] [E2F1CA76] CRC32
10 [8DDA4A24] [BC559BE1] CRC32
11 [C5F11D31] [056E8347] CRC32
12 [33AFCB40] [412C2682] CRC32
13 [0342D326] [2E9F0BF8] CRC32
14 [35A041B4] [EBF31511] CRC32
15 [90932B20] [B6DE5CCF] CRC32
16 [EC5B9A7E] [B058F567] CRC32
17 [4B995D3A] [A0E16F16] CRC32
EAC sees a record of 14-16 matches (that don't match), why isn't that in CUETools log? Also there seems to be missing 1+ records where the rest of the matches are.
Maybe this whole thing is NOT odd to people that fully understand (or had the time and interest to learn) what's going on, the regular end user IMHO is going to be confused and find this whole AR stuff a bit odd and too complicated. And that's the target audience, right? Not the techno savvy users/devs.
Personally I see AR as very useful I thank for making it, but I'm constantly finding odd and confusing things about it. Yeah yeah, just use it and be grateful what you got, right? Well, not quite, if everybody would follow that, there would not be any feedback.. and sometimes (not necessarily this topic) feedback is what makes the app/service progress. Rambling, my 2c's.
Gregory S. Chudov, do you have any insights to this topic? Thanks.
Topic: AccurateRip "total" matches count (Read 7359 times)
previous topic - next topic