IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
CTDB EAC plugin and a defective CD, CTDB newbie needs help interpreting rip logs & general CTDB usage
mjb2006
post Sep 28 2011, 09:57
Post #1





Group: Members
Posts: 811
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



I have some Warner promo CDs pressed by Discovery Systems in the late '80s that are now difficult to read, despite not having any visible flaws. I am confused about the results of ripping one of them. I'm not even sure what questions to ask.

I'll start by saying it's a 4-track disc. ARv2 has a checksum for track 1, with confidence 2. ARv2 apparently has no checksums for tracks 2-4.

The first rip, with EAC 1.0b3, yielded suspicious positions in every track, and no AR match on track 1. Yet despite this, a submission was made to CTDB:
CODE
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 27. September 2011, 23:12

Information Society / Walking Away

Used drive : ATAPI DVD A DH16ABSH Adapter: 0 ID: 1

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No

Read offset correction : 6
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 4:02.70 | 0 | 18219
2 | 4:02.70 | 5:04.67 | 18220 | 41086
3 | 9:07.62 | 6:40.60 | 41087 | 71146
4 | 15:48.47 | 7:10.68 | 71147 | 103464


Range status and errors

Selected range

Filename C:\Users\Public\Music\[1988] Information Society - Walking Away [PRO-CD-3253]\Information Society - Walking Away.wav

Suspicious position 0:02:13 - 0:02:14
Suspicious position 0:02:20
Suspicious position 0:04:18
Suspicious position 0:04:39
Suspicious position 0:09:10 - 0:09:11
Suspicious position 0:10:15
Suspicious position 0:10:27
Suspicious position 0:12:53
Suspicious position 0:13:02
Suspicious position 0:13:17
Suspicious position 0:17:21
Suspicious position 0:19:53
Suspicious position 0:20:26
Suspicious position 0:22:11

Peak level 98.2 %
Extraction speed 0.4 X
Range quality 98.9 %
Copy CRC 10FCFC75
Copy finished

There were errors


AccurateRip summary

Track 1 cannot be verified as accurate (confidence 2) [DE0F3C81], AccurateRip returned [7FAF23A3] (AR v2)
Track 2 not present in database
Track 3 not present in database
Track 4 not present in database

1 track(s) could not be verified as accurate
3 track(s) not present in the AccurateRip database

No tracks could be verified as accurate

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: jFIQSt.4_Wb36AJFzJbDBIdsyjw-] disk not present in database, Submit result: jFIQSt.4_Wb36AJFzJbDBIdsyjw- has been uploaded


==== Log checksum 6A7AC0CAEBD57EB1EBA20152E4E43B5DDC2F4C0C7B9608C9DE8BC4ED26BF3DC4 ====


Was it really supposed to submit this result? I thought there would have to be an AR confidence of at least 2 on the entire disc, not just 1 track, before it was acceptable for CTDB.

I then tried ripping the disc again, but in burst mode. The result was three timing problems, different audio data, and another AR mismatch on track 1:

CODE
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 27. September 2011, 23:19

Information Society / Walking Away

Used drive : ATAPI DVD A DH16ABSH Adapter: 0 ID: 1

Read mode : Burst

Read offset correction : 6
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 4:02.70 | 0 | 18219
2 | 4:02.70 | 5:04.67 | 18220 | 41086
3 | 9:07.62 | 6:40.60 | 41087 | 71146
4 | 15:48.47 | 7:10.68 | 71147 | 103464


Range status and errors

Selected range (Sectors 0-103464)

Filename C:\Users\Public\Music\[1988] Information Society - Walking Away [PRO-CD-3253]\Range.wav

Timing problem 0:00:26
Timing problem 0:00:34
Timing problem 0:00:44

Peak level 98.2 %
Extraction speed 14.6 X
Copy CRC 0C5F4F30
Copy finished

No errors occurred


AccurateRip summary

Track 1 cannot be verified as accurate (confidence 2) [DF961C01], AccurateRip returned [7FAF23A3] (AR v2)
Track 2 not present in database
Track 3 not present in database
Track 4 not present in database

1 track(s) could not be verified as accurate
3 track(s) not present in the AccurateRip database

No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: jFIQSt.4_Wb36AJFzJbDBIdsyjw-] found, Submit result: insufficient quality
[cf619211] (1/1) Differs in 2533 samples
@00:20:08,00:20:17-00:20:18,00:26:06,00:26:15,01:20:17,01:31:11-01:31:12,01:31:58-01:31:59,01:35:33,01:35:62,01:36:71,01:55:45,02:01:54-02:01:55,
02:10:23-02:10:24,02:13:58,02:14:02-02:14:03,02:20:45-02:20:46,03:13:22,03:42:38,04:08:33,04:08:54,04:18:65,04:27:02,04:39:23,04:39:34,05:36:29,
05:49:33-05:49:34,06:10:50,06:12:07-06:12:08,06:44:54-06:44:55,06:45:22,07:20:17,08:06:19,08:19:02,08:35:66,09:10:73,09:11:09,09:11:20,09:12:37,
09:18:54,10:15:06,10:20:03,10:26:41,10:26:53,10:27:01-10:27:02,10:53:51,11:08:44,11:12:16-11:12:17,11:39:20,11:41:01-11:41:02,11:41:13,
11:41:25-11:41:26,12:00:34-12:00:35,12:10:41-12:10:42,12:10:53-12:10:54,12:53:38,13:01:46-13:01:47,13:02:08-13:02:09,13:17:09-13:17:10,
13:17:22-13:17:23,13:28:09,14:11:41,14:24:66-14:24:67,14:54:37,15:08:34,15:17:69,15:42:00-15:42:01,15:45:06,15:45:45,15:57:39-15:57:40,
15:57:65,15:58:29,15:58:67,15:59:18,16:21:52-16:21:53,16:24:34-16:24:35,16:24:47,16:32:16,17:20:44-17:20:45,17:21:08-17:21:09,18:11:53-18:11:54,
18:12:45,18:46:12,18:46:25,18:53:49,19:30:46,19:53:02,19:57:15,19:57:69-19:57:70,20:10:35,20:11:27-20:11:28,20:14:09,20:22:66,20:23:05,
20:26:13,20:34:55,20:35:35,20:35:49,21:48:42,21:56:29,22:07:02,22:11:11,22:11:25,22:13:01,22:13:57,2
2:16:56,22:55:50
You can use CUETools to repair this rip.


==== Log checksum F436229CDD7ACED1E02402B5AB92F55672E0128CFF9A753CC9226709DAFBEF29 ====


What's weird here is that the CTDB plugin tells me about how drastically different it is from the previous rip, and says I can use CUETools to "repair" it. This seems troublesome. I am pretty sure that first rip was no better than this one. What happens if someone has a readable copy of this CD? Are they going to be told that they need to repair it, when really theirs is the good one?


So then I tried using CUERipper:

CODE
CUERipper v2.1.2 Copyright 2008-10 Gregory S. Chudov

EAC extraction logfile from 28. September 2011, 0:57

Information Society / Walking Away

Used drive : ATAPI DVD A DH16ABSH Adapter: 1 ID: 0

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No

Read offset correction : 6
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 4:02.70 | 0 | 18219
2 | 4:02.70 | 5:04.67 | 18220 | 41086
3 | 9:07.62 | 6:40.60 | 41087 | 71146
4 | 15:48.47 | 7:10.68 | 71147 | 103464


Range status and errors

Selected range

Filename C:\Users\yyyyy\Music\Information Society\Walking Away\Information Society - Walking Away.wav

Suspicious position 0:00:20
Suspicious position 0:00:25
Suspicious position 0:01:19
Suspicious position 0:01:31
Suspicious position 0:01:36
Suspicious position 0:01:55
Suspicious position 0:02:10
Suspicious position 0:02:14
Suspicious position 0:03:13
Suspicious position 0:03:42
Suspicious position 0:04:08
Suspicious position 0:04:24
Suspicious position 0:04:27
Suspicious position 0:04:49
Suspicious position 0:05:10
Suspicious position 0:05:27
Suspicious position 0:05:35
Suspicious position 0:05:48 - 0:05:49
Suspicious position 0:06:10
Suspicious position 0:06:12
Suspicious position 0:06:59

Peak level 98.2 %
Range quality 100.0 %
Test CRC 3EE4EEBF
Copy CRC 3EE4EEBF
Copy OK

There were errors


AccurateRip summary

Track 1 cannot be verified as accurate (confidence 2) [13352C10], AccurateRip returned [7FAF23A3]
Track 2 not present in database
Track 3 not present in database
Track 4 not present in database

No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report


I am surprised to see matching test & copy CRCs in the CUERipper log. CUERipper was not very clear about what it was doing when it ran, but I know it didn't do a read-only 'test' pass the way EAC does. Should I accept this test & copy result as evidence of a good rip?

Here's the .accurip log for that rip:

CODE
[CUETools log; Date: 9/28/2011 12:57:10 AM; Version: 2.1.2a]
[CTDB TOCID: jFIQSt.4_Wb36AJFzJbDBIdsyjw-] found.
[ CTDBID ] Status
[cf619211] (1/1) Differs in 4479 samples
@00:05:26,00:19:56,00:20:09,00:20:17-00:20:18,00:25:26-00:25:27,00:25:36,00:25:45,00:25:63,00:26:06,00:26:24-00:26:25,00:55:42,01:20:17,
01:35:33,01:35:52,01:36:71-01:36:72,01:47:54,01:55:17,01:55:45-01:55:46,01:55:74-01:56:00,01:56:18,02:01:54-02:01:55,02:10:13-02:10:14,
02:10:23-02:10:24,02:13:58,02:14:03,02:36:38,02:36:48,02:52:60-02:52:61,03:13:12,03:13:22,03:27:34,03:28:38-03:28:39,03:28:58,03:42:38,
03:42:58,03:42:68,04:08:22-04:08:23,04:08:32-04:08:33,04:08:43,04:08:53,04:08:63,04:09:18,04:11:00-04:11:01,04:11:11,04:19:00,04:24:53,
04:24:63,04:27:02,04:27:43,04:39:34,04:39:44,04:45:15,05:09:46,05:36:29,05:48:13-05:48:14,05:48:56,05:49:33-05:49:34,06:10:30,06:10:51,
06:12:08,06:38:30,06:44:54-06:44:55,06:45:22,07:13:39,07:20:17,07:24:57,07:25:03-07:25:04,07:35:44,08:04:69,08:26:01-08:26:02,
09:10:72-09:10:73,09:11:09,09:11:20,09:12:37,10:15:06,10:15:19,10:15:42,10:15:53-10:15:54,10:16:02,10:26:41,10:27:01-10:27:02,10:31:39,
10:40:65-10:40:66,10:46:48,10:59:60,11:01:04-11:01:05,11:08:45,11:12:40,11:33:65,11:39:20,11:41:13,11:41:25-11:41:26,12:00:34-12:00:35,
12:10:29-12:10:30,12:10:42,12:10:53,12:10:65,12:53:38,12:53:50,12:53:74,13:01:72,13:02:08-13:02:09,13:17:10,13:17:46-13:17:47,13:17:59,
13:57:59,13:57:72,14:24:66-14:24:67,15:08:34,15:08:59-15:08:60,15:42:00-15:42:01,15:45:06,15:58:03-15:58:04,15:58:16,15:58:28-15:58:29,
15:58:41-15:58:42,15:58:54-15:58:55,15:58:67,15:59:04-15:59:05,15:59:17,16:21:40,16:21:52-16:21:53,16:24:08-16:24:09,16:24:34-16:24:35,
16:24:47,16:32:29,16:36:41,16:37:29,16:37:42,16:59:14,17:20:44-17:20:45,17:47:19,18:08:29,18:09:20-18:09:21,18:11:27-18:11:28,
18:12:18-18:12:19,18:45:20,18:45:60,18:45:73,18:46:12,19:18:55-19:18:56,19:23:58,19:30:19,19:52:64,19:53:02,19:57:29,19:57:42-19:57:43,
19:57:56,19:57:69-19:57:70,20:11:27-20:11:28,20:14:09,20:14:50,20:22:66,20:23:05,20:26:00,20:26:13-20:26:14,20:33:61-20:33:62,20:34:00,
20:35:35,21:05:45,21:42:60,21:42:73-21:42:74,22:06:63,22:07:02,22:10:72,22:11:11,22:11:25,22:13:01,22:13:29,22:13:43-22:13:44,22:13:57
[AccurateRip ID: 000391bf-000eac4f-2c056304] found.
Track [ CRC ] Status
01 [13352c10] (0/2) No match but offset
02 [7228bf9e] (0/0) No match
03 [00c9cd9c] (0/0) No match
04 [cc00728d] (0/0) No match

Track Peak [ CRC32 ] [W/O NULL]
-- 98.2 [3EE4EEBF] [63CB2828]
01 98.2 [12E3AD95] [7C8671B2]
02 95.8 [CA7CBA9A] [C42C03AE]
03 97.6 [33249C15] [552F41D3]
04 94.6 [E692929F] [8452C4B5]



I also tried burst mode again, but from dbPowerAmp. I would've done secure mode, but my trial copy expired. For some reason it didn't write a log, so all I have to show for it are four .wav files, and the .accurip log from running a CUETools verify on them:
CODE
[CUETools log; Date: 9/28/2011 2:00:26 AM; Version: 2.1.2a]
[CTDB TOCID: jFIQSt.4_Wb36AJFzJbDBIdsyjw-] found.
[ CTDBID ] Status
[f6b20c64] (1/2) No match
[cf619211] (1/2) Differs in 3555 samples
@00:05:26,00:20:08-00:20:09,00:26:06,00:55:42,01:20:07-01:20:08,01:20:17,01:30:68,01:35:33,01:35:52,01:35:71,01:36:15-01:36:16,
01:36:71-01:36:72,01:47:54,01:54:72,01:55:17,01:55:45-01:55:46,01:55:74-01:56:00,01:56:18,02:01:54-02:01:55,02:10:13-02:10:14,02:13:58,
02:14:02-02:14:03,02:36:38,02:36:48,02:52:60-02:52:61,03:13:12,03:27:34,03:28:38-03:28:39,03:42:38,04:08:32-04:08:33,04:08:63,04:09:18,
04:11:00-04:11:01,04:11:11,04:19:00,04:24:32-04:24:33,04:27:02,04:38:36-04:38:37,04:39:34,04:39:44,04:45:15,05:02:10-05:02:11,05:09:46,
05:48:13-05:48:14,05:49:33-05:49:34,06:10:29,06:10:51,06:10:72,06:12:08,06:44:54-06:44:55,06:45:22,06:59:44,07:20:06,07:35:11,08:04:69,
08:26:01-08:26:02,09:10:73,09:11:08-09:11:09,09:11:20,09:12:37,09:18:54,10:15:06,10:15:53-10:15:54,10:26:53,10:27:01-10:27:02,
10:40:65-10:40:66,10:59:60,11:08:44,11:09:41,11:12:16-11:12:17,11:33:65,11:39:20,11:39:32,11:41:13,11:41:25-11:41:26,12:00:34-12:00:35,
12:09:44,12:10:41-12:10:42,12:10:53,12:10:65,12:53:38,13:01:46-13:01:47,13:02:08-13:02:09,13:17:09-13:17:10,13:17:22-13:17:23,
13:17:46-13:17:47,13:57:72,15:08:34,15:08:59-15:08:60,15:45:06,15:45:19,15:45:45,15:57:65,15:58:41,15:58:67,15:59:04-15:59:06,
15:59:17,16:21:52-16:21:53,16:28:44,16:37:29,16:57:47-16:57:48,17:21:48,18:11:27-18:11:28,18:11:53-18:11:54,18:12:18-18:12:19,18:13:36,
18:14:27-18:14:28,18:45:20,18:45:60,18:46:12,18:46:25,19:01:12,19:35:64,19:41:21,19:53:02,19:57:15,19:57:42,1
9:57:69-19:57:70,20:10:35,
20:11:14,20:11:27-20:11:28,20:14:09,20:14:50,20:23:05,20:23:19,20:26:13,20:34:00,20:35:21,20:35:35,20:35:49,21:42:60,2
1:50:18,21:56:29,
22:06:63,22:07:02,22:11:25,22:13:01,22:13:29,22:13:43-22:13:44,22:13:57,22:40:17
[AccurateRip ID: 000391bf-000eac4f-2c056304] found.
Track [ CRC ] Status
01 [041686b1] (0/2) No match but offset
02 [6e3034bf] (0/0) No match
03 [0d867e93] (0/0) No match
04 [b27efa63] (0/0) No match

Track Peak [ CRC32 ] [W/O NULL]
-- 98.2 [9DCCC72E] [57397AFB]
01 98.2 [3FF6116C] [B027DA91]
02 95.8 [55817C40] [50C266A7]
03 97.6 [6F73B726] [868C03B5]
04 94.6 [6BA02A13] [52CB1E81]


I mean it looks to me like I'm getting different results with every read, and I can't trust any of them, right?

I'm mainly just confused as to why the first rip was submitted and accepted and treated as if it were a good rip. Clearly it's not. Is this all working as intended, then? Is it user error? Am I missing something? How do I proceed?

Also why are the "(1/1)"s now "(1/2)"s? e.g. in the last log above, and also if I run CUETools verify or repair on that first EAC burst rip. Btw, after posting all of the above, I went ahead and "repaired" the first burst rip, and sure enough, the result was the same as the original rip.

This post has been edited by mjb2006: Sep 28 2011, 10:08
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Sep 28 2011, 17:11
Post #2





Group: Developer
Posts: 699
Joined: 2-October 08
From: Ottawa
Member No.: 59035



> I thought there would have to be an AR confidence of at least 2 on the entire disc, not just 1 track, before it was acceptable for CTDB.
That's how CUETools submissions work. Rippers don't need AR to work with CTDB. In fact, CTDB EAC plugin doesn't bother with AR at all.

You can never trust a result with confidence level 1, especially when you submitted it yourself smile.gif That was true for AR, and remains true for CTDB.
AccurateRip didn't care at all if there were errors during extraction, it just collected CRCs. Uncorroborated CRC means nothing.
CTDB cares somewhat about that, because recovery records are much larger. EAC/CUERipper always submit their result, but the
database can reject the recovery record (keeping only CRCs) when rip quality is insufficient.

Your example demonstrates two things that don't yet work the way they probably should:
1) EAC doesn't report suspicious positions/rip quality to the plugin, so it can only rely on test&copy CRCs to detect rip quality. I will ask Andre if we can add this feature in the next release.
2) CUERipper doesn't do real test&copy, but calculates rip quality based only on suspicious positions. I'm still trying to decide what should i do with that, because the way CUERipper works,
actual test&copy would just unnecessarily make it work twice slower. Paranoid mode is much more useful. So i guess i will just remove those Test CRCs.

On your first rip EAC plugin was wrong when it told CTDB that the rip quality was 100%, so CTDB wrongly accepted recovery record.
In burst mode rip quality was calculated as 0%, so CTDB rejected the second submission.
CUERipper was right when it told CTDB that the rip quality was 60%, so CTDB didn't accept second recovery record, only CRCs.

So now there are two sets of CRCs in the database, which is as it should be, and one of them with recovery record which shouldn't have been accepted.

The moral of the story: don't repair when when confidence is 1/x. I should probably replace that "You can use CUETools to repair this rip." message with something more cautious.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th September 2014 - 06:17