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: CTDB EAC plugin and a defective CD (Read 6329 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CTDB EAC plugin and a defective CD

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: [Select]
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: [Select]
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: [Select]
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: [Select]
[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: [Select]
[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.

CTDB EAC plugin and a defective CD

Reply #1
> 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  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.6