I’m new to dBpoweramp, but have been using EAC for YEARS now. Some things I have noticed in my first attempts to use DBPA.
I use a laptop with USB attached drives for ripping, I have several different drives (LiteOn, Optiarc, Plextor) all of which produce the same CRC values in EAC when used to rip discs (after setting the correct offset values for both read & write I am able to dulicate discs which are exact copies of the originals as the duplicates produce the same CRC values as well).
I am currently using a LiteON USB drive (iHAS422 8 4L18) and have been using this for quite some time without issues under EAC. EAC reports it as having C2, no caching, a read offset of +6, and a write offset of -6. The C2 testing in EAC can be run to completion without issue and detects C2 error information properly. These numbers/features agree with those I’ve seen/found online.
With DBPA the C2 detection seems to knock my DVD drive into some goofed up state where I need to power cycle it to get it working again and it doesn’t find any C2 information on the same discs which EAC finds it on.
Also, I did a test rip of a CD and the first track showed the Rip Status as “Accurate (13)” which matched all the other tracks on the disc, but the CRC value was RED in color and according to the output shown at the rip completion, the CRC was different than what AccurateRip has for the CRC value of this track. How can it be verified as being Accurate when the CRC value is different? This makes me wonder if we can trust AccurateRip at all.
I tried re-ripping that same track, and this time the CRC value showed in GREEN and I was asked to upload my result to AccurateRip which I did not do.
Now on further tests with the same disc, the CRC shows as BLACK just like the other tracks do, so what is this CRC value shown in the riper represent as I just noticed that none of these values match the AccurateRip CRC values? Also, I made a copy of this disc using EAC to write it and make it into a C2 test disc using the black marker as suggested in the setup guide, and just for grins I tried to rip it with the drive setup for ultrasecure with C2 turned on and the USB setting for C2 also turned on. I was able to see it go into the secure rip mode, but when it was completed and said it had a secure rip, the CRC value displayed was again different than what the good version of the CD produced. If it were indeed a “good” or “secure” rip, shouldn’t the CRC match that of the same song from the good disc? If the CRC value is different, wouldn’t that indicate that it did not read the track the same between those 2 rips?
And if I make subsequent rips of that same track from the C2 test CD, it always shows as a “secure” rip, but the CRC value is different each and every time, again which would indicate to me that a “secure” rip is not a valid rip (unless I am missing something).
Pasted below are the results of the last rip:
Secure (Warning) [Pass 1, Ultra 1 to 2, Re-Rip 28 Frames]
CRC32: 8B5AB5A5 AccurateRip CRC: E24BEB8E (CRCv2) [DiscID: 011-0012ce59-00a5594a-9f0b6f0b-1]
Re-rip Frame: 5533 (00:01:13.773) matched 10 / 12
Re-rip Frame: 5594 (00:01:14.586) matched 10 / 14
Re-rip Frame: 6022 (00:01:20.293) matched 10 / 12
Re-rip Frame: 6279 (00:01:23.720) matched 10 / 23
Re-rip Frame: 6564 (00:01:27.520) matched 10 / 14
Re-rip Frame: 6565 (00:01:27.533) matched 10 / 11
Re-rip Frame: 6677 (00:01:29.026) matched 10 / 12
Re-rip Frame: 6738 (00:01:29.840) matched 10 / 17
Re-rip Frame: 6739 (00:01:29.853) matched 10 / 13
Re-rip Frame: 6851 (00:01:31.346) matched 10 / 11
Re-rip Frame: 7107 (00:01:34.760) matched 10 / 11
Re-rip Frame: 7108 (00:01:34.773) matched 10 / 13
Re-rip Frame: 7251 (00:01:36.680) matched 10 / 10
Re-rip Frame: 7508 (00:01:40.106) matched 10 / 11
Re-rip Frame: 7764 (00:01:43.520) matched 10 / 16
Re-rip Frame: 7765 (00:01:43.533) matched 10 / 12
Re-rip Frame: 7794 (00:01:43.920) matched 10 / 14
Re-rip Frame: 7795 (00:01:43.933) matched 10 / 13
Re-rip Frame: 8023 (00:01:46.973) matched 10 / 19
Re-rip Frame: 8165 (00:01:48.866) matched 10 / 10
Re-rip Frame: 8424 (00:01:52.320) matched 10 / 16
Re-rip Frame: 8736 (00:01:56.480) matched 10 / 12
Re-rip Frame: 9253 (00:02:03.373) matched 10 / 11
Re-rip Frame: 9481 (00:02:06.413) matched 10 / 12
Re-rip Frame: 9793 (00:02:10.573) matched 10 / 19
Re-rip Frame: 10221 (00:02:16.280) matched 10 / 13
Re-rip Frame: 10567 (00:02:20.893) matched 10 / 12
Re-rip Frame: 10680 (00:02:22.400) matched 10 / 12
Even if the drive is at fault and doesn’t properly handle C2 errors, then every scan should be flagged as bad and none should be stated as being secure unless that CRC value matches (in my opinon).
I just tested with the internal drive of my laptop on the C2 test disk, and the track is shown to be Accurate (13) with the correct (same) CRC value produced which is what I would expect. How can a rip be flagged as secure and considered to be good if that CRC value doesn’t match?
I use a laptop with USB attached drives for ripping, I have several different drives (LiteOn, Optiarc, Plextor) all of which produce the same CRC values in EAC when used to rip discs (after setting the correct offset values for both read & write I am able to dulicate discs which are exact copies of the originals as the duplicates produce the same CRC values as well).
I am currently using a LiteON USB drive (iHAS422 8 4L18) and have been using this for quite some time without issues under EAC. EAC reports it as having C2, no caching, a read offset of +6, and a write offset of -6. The C2 testing in EAC can be run to completion without issue and detects C2 error information properly. These numbers/features agree with those I’ve seen/found online.
With DBPA the C2 detection seems to knock my DVD drive into some goofed up state where I need to power cycle it to get it working again and it doesn’t find any C2 information on the same discs which EAC finds it on.
Also, I did a test rip of a CD and the first track showed the Rip Status as “Accurate (13)” which matched all the other tracks on the disc, but the CRC value was RED in color and according to the output shown at the rip completion, the CRC was different than what AccurateRip has for the CRC value of this track. How can it be verified as being Accurate when the CRC value is different? This makes me wonder if we can trust AccurateRip at all.
I tried re-ripping that same track, and this time the CRC value showed in GREEN and I was asked to upload my result to AccurateRip which I did not do.
Now on further tests with the same disc, the CRC shows as BLACK just like the other tracks do, so what is this CRC value shown in the riper represent as I just noticed that none of these values match the AccurateRip CRC values? Also, I made a copy of this disc using EAC to write it and make it into a C2 test disc using the black marker as suggested in the setup guide, and just for grins I tried to rip it with the drive setup for ultrasecure with C2 turned on and the USB setting for C2 also turned on. I was able to see it go into the secure rip mode, but when it was completed and said it had a secure rip, the CRC value displayed was again different than what the good version of the CD produced. If it were indeed a “good” or “secure” rip, shouldn’t the CRC match that of the same song from the good disc? If the CRC value is different, wouldn’t that indicate that it did not read the track the same between those 2 rips?
And if I make subsequent rips of that same track from the C2 test CD, it always shows as a “secure” rip, but the CRC value is different each and every time, again which would indicate to me that a “secure” rip is not a valid rip (unless I am missing something).
Pasted below are the results of the last rip:
Secure (Warning) [Pass 1, Ultra 1 to 2, Re-Rip 28 Frames]
CRC32: 8B5AB5A5 AccurateRip CRC: E24BEB8E (CRCv2) [DiscID: 011-0012ce59-00a5594a-9f0b6f0b-1]
Re-rip Frame: 5533 (00:01:13.773) matched 10 / 12
Re-rip Frame: 5594 (00:01:14.586) matched 10 / 14
Re-rip Frame: 6022 (00:01:20.293) matched 10 / 12
Re-rip Frame: 6279 (00:01:23.720) matched 10 / 23
Re-rip Frame: 6564 (00:01:27.520) matched 10 / 14
Re-rip Frame: 6565 (00:01:27.533) matched 10 / 11
Re-rip Frame: 6677 (00:01:29.026) matched 10 / 12
Re-rip Frame: 6738 (00:01:29.840) matched 10 / 17
Re-rip Frame: 6739 (00:01:29.853) matched 10 / 13
Re-rip Frame: 6851 (00:01:31.346) matched 10 / 11
Re-rip Frame: 7107 (00:01:34.760) matched 10 / 11
Re-rip Frame: 7108 (00:01:34.773) matched 10 / 13
Re-rip Frame: 7251 (00:01:36.680) matched 10 / 10
Re-rip Frame: 7508 (00:01:40.106) matched 10 / 11
Re-rip Frame: 7764 (00:01:43.520) matched 10 / 16
Re-rip Frame: 7765 (00:01:43.533) matched 10 / 12
Re-rip Frame: 7794 (00:01:43.920) matched 10 / 14
Re-rip Frame: 7795 (00:01:43.933) matched 10 / 13
Re-rip Frame: 8023 (00:01:46.973) matched 10 / 19
Re-rip Frame: 8165 (00:01:48.866) matched 10 / 10
Re-rip Frame: 8424 (00:01:52.320) matched 10 / 16
Re-rip Frame: 8736 (00:01:56.480) matched 10 / 12
Re-rip Frame: 9253 (00:02:03.373) matched 10 / 11
Re-rip Frame: 9481 (00:02:06.413) matched 10 / 12
Re-rip Frame: 9793 (00:02:10.573) matched 10 / 19
Re-rip Frame: 10221 (00:02:16.280) matched 10 / 13
Re-rip Frame: 10567 (00:02:20.893) matched 10 / 12
Re-rip Frame: 10680 (00:02:22.400) matched 10 / 12
Even if the drive is at fault and doesn’t properly handle C2 errors, then every scan should be flagged as bad and none should be stated as being secure unless that CRC value matches (in my opinon).
I just tested with the internal drive of my laptop on the C2 test disk, and the track is shown to be Accurate (13) with the correct (same) CRC value produced which is what I would expect. How can a rip be flagged as secure and considered to be good if that CRC value doesn’t match?
Comment