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