If the rip doesn't get accurate result for all tracks within the same offset it cannot be AR2 hence it cannot be repaired no matter if the tracks are all accurate separately on several different offsets (which happens sometimes).
CTDB repair function won't activate and encode my files because it doesnt know which offset to use.
independent of one another
If I ever find AR2 faulty be sure I'll complain to the boss !
So even if AR1 is enougth if you own the CD, in the end the fact that a rip can be AR1 in April & not in database in May makes you feel that AR1 is not enougth.
CTDB is AR dependent.
How so exactly?
Must there be a record in the AR database for something to be in the CT database?
A confidence of one that vanished is really no better than a confidence of one that did not vanish, or any better than a confidence of two provided it was not your previous submission.
Just like you said Greg uses AR2 to accept submission, so no AR no CTDB simply.
Yes AR2 in AR database before being accepted in CTDB
I am not sure that I get what you meant but a confidence of 2 no matter if one is your own "precious" submission is better than a confidence of 1 because a confidence of 1 is almost like no confidence at all for me ... as it can disapear. To trust AR1 you have to keep records of what you submitted to the database which is insane in the long time.
[CUETools log; Date: 24/05/2010 5:27:41 PM; Version: 2.0.9][CTDB TOCID: be8vy8P3FbyY5zsvkRW5op85K_o-] found. [ CTDBID ] Status [4135cf03] (337/337) No match[AccurateRip ID: 0017deff-00cf9b72-890dd20b] found.Track [ CRC ] Status 01 [8164b9a6] (000/562) No match 02 [8d6e86c8] (000/563) No match 03 [1ad0833b] (000/565) No match 04 [458425a6] (000/565) No match 05 [b2b0db89] (000/568) No match 06 [b87e1bef] (000/562) No match 07 [c4209825] (000/557) No match 08 [de139d6c] (000/566) No match 09 [ab4603ce] (000/563) No match 10 [49f419f5] (000/558) No match 11 [71e15541] (000/540) No matchOffsetted by 112: 01 [4e5b16c2] (039/562) Accurately ripped 02 [3cf51194] (039/563) Accurately ripped 03 [c9ba3e97] (039/565) No match but offset 04 [fc7c30b5] (040/565) Accurately ripped 05 [a548029a] (040/568) Accurately ripped 06 [e4ed989c] (038/562) No match but offset 07 [3f9d7f5d] (039/557) No match but offset 08 [c37a916d] (039/566) No match but offset 09 [ac5ad610] (038/563) Accurately ripped 10 [5ea5e171] (039/558) No match but offset 11 [cc46d7c1] (039/540) No match but offsetTrack Peak [ CRC32 ] [W/O NULL] [ LOG ] -- 97.7 [676A08B4] [F6C8BC1A] 01 97.7 [04B564BA] [6A33D5F9] CRC32 02 97.7 [3DC55F78] [0296C6D0] CRC32 03 97.7 [AA7422DC]  CRC32 04 97.7 [0251F8EF] [A91411AA] CRC32 05 97.7 [4FD3CD70] [24E1DABF] CRC32 06 97.7 [43E1D1C6] [E45B33D8] CRC32 07 97.1 [618BD826] [5C35B999] CRC32 08 97.7 [5A9E0514] [23BB1B34] CRC32 09 97.7 [645C41ED] [DF1D3E84] CRC32 10 97.7 [DABC5DF3] [90290BF6] CRC32 11 97.7 [C8636CF9] [8B7161C9] CRC32
- I thought i saw one of you mention something about a bad log file or something. Could my original EAC log files be confusing CT somehow?
337 CTDB confidence
- Yes Greynol, CTDB submissions require AR confidence >=2
With your last cuetools log: this rip is not accurate with a very very high confidence
2: Very unlikely: you own a rare pressing that is not in AR & doesn't match CTDB too
- So how do i know the difference between an album that is unrepairable by CTDB and any other error i'm having? Do you think I should suggest to the developer that he uses different messages? One that notifies you that your album has too many errors to repair and one that says your album is not being recognized by the database or something?