Skip to main content
Topic: Remove Accidentally Submitted Bad Rip from CTDB (Read 1257 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Remove Accidentally Submitted Bad Rip from CTDB

I've experimented with a retail CD trying to get accurate ripping results. Both EAC and dbpowerAMP reported several insecure tracks. After configuring my drive I was able to solve it for a few tracks with EAC. I then found out that CUETools has a repair function and it initially repaired all inaccurate tracks successfully. Due to my perfectionism I decided to rip the CD again, not remembering the exact reason. I'm afraid it might just have been laziness because EAC didn't rip to FLAC initially.

Now I've completed that task, but all of a sudden I can't repair the rip with CUETools anymore! I noticed in the log that the inaccurate tracks now have entries in the database which I attribute to the EAC CTDB plugin somehow submitting the bad rip as accurate. From the wiki:

Quote
CTDB accepts the recovery record portion of a submission when the plugin reports the rip quality as 100%, but since EAC (V1.0 beta 2 through V1.0 beta 4) doesn't report suspicious positions to the plugin, the quality may be reported to CTDB as 100% when it is actually less than that. This causes CTDB to wrongly accept a recovery record which could be used to "repair" future rips to match the bad rip. It is recommended to avoid doing a repair when the CTDB confidence is 1/x.

Code: [Select]
[CUETools log; Date: 7/3/2019 2:08:30 PM; Version: 2.1.6]
[CTDB TOCID: TUhRQR2WhqyYCbEwQ532JKyTFko-] found.
Track | CTDB Status
  1   | (  1/131) Accurately ripped
  2   | ( 63/131) Accurately ripped
  3   | ( 63/131) Accurately ripped
  4   | ( 63/131) Accurately ripped
  5   | ( 61/131) Accurately ripped
  6   | ( 63/131) Accurately ripped
  7   | ( 63/131) Accurately ripped
  8   | ( 63/131) Accurately ripped
  9   | ( 63/131) Accurately ripped
 10   | ( 62/131) Accurately ripped
 11   | ( 62/131) Accurately ripped
 12   | ( 63/131) Accurately ripped
 13   | (  1/131) Accurately ripped
 14   | (  2/131) Accurately ripped
 15   | ( 63/131) Accurately ripped
 16   | (  2/131) Accurately ripped
 17   | (  1/131) Accurately ripped
 18   | (  1/131) Accurately ripped
 19   | ( 63/131) Accurately ripped
 20   | (  1/131) Accurately ripped
 21   | (  1/131) Accurately ripped
 22   | (  1/131) Accurately ripped
 23   | (  1/131) Accurately ripped
[AccurateRip ID: 002f2f9d-030953a3-290d6817] found.
Track   [  CRC   |   V2   ] Status
 01     [92a7c435|fd685ae1] (000+000/097) No match
 02     [e1e28ec6|0d4a8487] (021+035/099) Accurately ripped
 03     [4c9adb09|0e7f1d21] (021+035/099) Accurately ripped
 04     [332896c7|b72db90d] (021+034/098) Accurately ripped
 05     [c2749820|cb8c7416] (021+034/098) Accurately ripped
 06     [f53efee7|6225480f] (021+035/099) Accurately ripped
 07     [51c7f7d1|dcd2e137] (021+035/099) Accurately ripped
 08     [c062c12a|eb97fca8] (021+035/099) Accurately ripped
 09     [26c64da9|5211ff02] (021+035/099) Accurately ripped
 10     [179f61ca|26495001] (021+035/100) Accurately ripped
 11     [defd8aaf|3768a1dc] (021+034/098) Accurately ripped
 12     [0d37ded7|7641290d] (021+035/098) Accurately ripped
 13     [69c23c68|5536e109] (000+000/097) No match
 14     [d21a2c4c|67e2cdcd] (000+000/099) No match
 15     [ddb5eec7|d1dc5815] (021+034/096) Accurately ripped
 16     [409bb24b|7caa5118] (000+000/096) No match
 17     [8f1f52f5|8231634e] (000+000/096) No match
 18     [4f28051d|715cfa3b] (000+000/098) No match
 19     [67419ece|b62c2fa1] (021+035/099) Accurately ripped
 20     [65b7457b|e08e65df] (000+000/096) No match
 21     [6dceb2d9|a2c27aad] (000+000/095) No match
 22     [d886465e|3d23ca81] (000+000/097) No match
 23     [127eed6f|7489355c] (000+000/095) No match

As you can see, the tracks with "no match" in the AccurateRip database are the ones that are found in the CueTools database with confidence level of 1, a few of them 2. I suspect that the EAC plugin submitted bad rips for both of my ripping processes, before and after I configured my drive to reduce ripping errors.

So how can those bad rips be removed from the database now? This is especially important because apparently my rip can't be repaired anymore, since CUETools thinks it is accurate. I was an idiot for deleting the successfully repaired tracks. Fortunately I did keep my dbpowerAMP rip (for comparison), and was able to successfully repair those tracks:

Code: [Select]
[CUETools log; Date: 7/3/2019 1:44:34 PM; Version: 2.1.6]
CUETools DB: corrected 9589 errors.
[AccurateRip ID: 002f2f9d-030953a3-290d6817] found.
Track   [  CRC   |   V2   ] Status
 01     [52e1d67b|bda26e13] (020+034/097) Accurately ripped
 02     [e1e28ec6|0d4a8487] (021+035/099) Accurately ripped
 03     [4c9adb09|0e7f1d21] (021+035/099) Accurately ripped
 04     [332896c7|b72db90d] (021+034/098) Accurately ripped
 05     [c2749820|cb8c7416] (021+034/098) Accurately ripped
 06     [f53efee7|6225480f] (021+035/099) Accurately ripped
 07     [51c7f7d1|dcd2e137] (021+035/099) Accurately ripped
 08     [c062c12a|eb97fca8] (021+035/099) Accurately ripped
 09     [26c64da9|5211ff02] (021+035/099) Accurately ripped
 10     [179f61ca|26495001] (021+035/100) Accurately ripped
 11     [defd8aaf|3768a1dc] (021+034/098) Accurately ripped
 12     [0d37ded7|7641290d] (021+035/098) Accurately ripped
 13     [20ac9224|0c20fdf0] (021+034/097) Accurately ripped
 14     [8e16d2f6|23deccc7] (021+035/099) Accurately ripped
 15     [ddb5eec7|d1dc5815] (021+034/096) Accurately ripped
 16     [8f92518d|cba0f84f] (021+033/096) Accurately ripped
 17     [565e3f45|49704fa6] (021+033/096) Accurately ripped
 18     [a999db63|cbce9a6b] (021+035/098) Accurately ripped
 19     [67419ece|b62c2fa1] (021+035/099) Accurately ripped
 20     [4545d205|c01c4917] (021+034/096) Accurately ripped
 21     [a97a4e86|de904de3] (021+034/095) Accurately ripped
 22     [fab8baeb|5f56995f] (021+035/097) Accurately ripped
 23     [3239d8ed|97552621] (019+034/095) Accurately ripped

Re: Remove Accidentally Submitted Bad Rip from CTDB

Reply #1
Now I've completed that task, but all of a sudden I can't repair the rip with CUETools anymore! I noticed in the log that the inaccurate tracks now have entries in the database which I attribute to the EAC CTDB plugin somehow submitting the bad rip as accurate. From the wiki:

Quote
CTDB accepts the recovery record portion of a submission when the plugin reports the rip quality as 100%, but since EAC (V1.0 beta 2 through V1.0 beta 4) doesn't report suspicious positions to the plugin, the quality may be reported to CTDB as 100% when it is actually less than that. This causes CTDB to wrongly accept a recovery record which could be used to "repair" future rips to match the bad rip. It is recommended to avoid doing a repair when the CTDB confidence is 1/x.
You were using EAC V1.3 with plugin V2.1.6. No recovery record submitted so someone won't be able to repair using a recovery record from your rip. Rip results are submitted. This is normal.

The quality of the previous EAC rip was a little higher than the recent rip. I'm not seeing any "Differs in nn samples" in the CTDB section so if you didn't edit them out, in all likelihood the damaged areas of the recent rip exceed what can be repaired by the recovery record.

See pic. Your rip being in the database doesn't prevent a repair if damaged areas are within the limits of a recovery record.
korth

Re: Remove Accidentally Submitted Bad Rip from CTDB

Reply #2
Thanks a lot! Your explanation provided me with enough clues to come to the conclusion that the earlier rip must have been done with my other drive, and lo and behold, I was able to achieve "differs in samples" this time around:

Code: [Select]
---- CUETools DB Plugin V2.1.6

[CTDB TOCID: TUhRQR2WhqyYCbEwQ532JKyTFko-] found
Submit result: TUhRQR2WhqyYCbEwQ532JKyTFko- has been submitted
Track | CTDB Status
  1   | ( 62/133) Accurately ripped
  2   | ( 64/133) Accurately ripped
  3   | ( 64/133) Accurately ripped
  4   | ( 58/133) Differs in 11 samples @01:28:31,01:28:53
  5   | ( 58/133) Differs in 4 samples @01:00:60
  6   | ( 64/133) Accurately ripped
  7   | ( 64/133) Accurately ripped
  8   | ( 64/133) Accurately ripped
  9   | ( 64/133) Accurately ripped
 10   | ( 63/133) Accurately ripped
 11   | ( 63/133) Accurately ripped
 12   | ( 64/133) Accurately ripped
 13   | ( 58/133) Differs in 3 samples @00:55:72
 14   | ( 62/133) Accurately ripped
 15   | ( 58/133) Differs in 21 samples @01:23:26,01:23:58,01:24:30-01:24:31
 16   | ( 61/133) Accurately ripped
 17   | ( 58/133) Differs in 22 samples @00:00:51,00:05:36,00:05:53,00:06:10
 18   | ( 61/133) Accurately ripped
 19   | ( 64/133) Accurately ripped
 20   | ( 58/133) Differs in 10 samples @00:43:73,01:37:03-01:37:04
 21   | ( 61/133) Accurately ripped
 22   | ( 61/133) Accurately ripped
 23   | ( 58/133) Differs in 16 samples @00:48:18,01:05:41,02:52:36,04:39:57
If you are sure that your rip contains errors, you can use CUETools to repair it.



Code: [Select]
[CUETools log; Date: 7/5/2019 3:09:05 PM; Version: 2.1.6]
CUETools DB: corrected 87 errors.
[AccurateRip ID: 002f2f9d-030953a3-290d6817] found.
Track   [  CRC   |   V2   ] Status
 01     [52e1d67b|bda26e13] (020+034/097) Accurately ripped
 02     [e1e28ec6|0d4a8487] (021+035/099) Accurately ripped
 03     [4c9adb09|0e7f1d21] (021+035/099) Accurately ripped
 04     [332896c7|b72db90d] (021+034/098) Accurately ripped
 05     [c2749820|cb8c7416] (021+034/098) Accurately ripped
 06     [f53efee7|6225480f] (021+035/099) Accurately ripped
 07     [51c7f7d1|dcd2e137] (021+035/099) Accurately ripped
 08     [c062c12a|eb97fca8] (021+035/099) Accurately ripped
 09     [26c64da9|5211ff02] (021+035/099) Accurately ripped
 10     [179f61ca|26495001] (021+035/100) Accurately ripped
 11     [defd8aaf|3768a1dc] (021+034/098) Accurately ripped
 12     [0d37ded7|7641290d] (021+035/098) Accurately ripped
 13     [20ac9224|0c20fdf0] (021+034/097) Accurately ripped
 14     [8e16d2f6|23deccc7] (021+035/099) Accurately ripped
 15     [ddb5eec7|d1dc5815] (021+034/096) Accurately ripped
 16     [8f92518d|cba0f84f] (021+033/096) Accurately ripped
 17     [565e3f45|49704fa6] (021+033/096) Accurately ripped
 18     [a999db63|cbce9a6b] (021+035/098) Accurately ripped
 19     [67419ece|b62c2fa1] (021+035/099) Accurately ripped
 20     [4545d205|c01c4917] (021+034/096) Accurately ripped
 21     [a97a4e86|de904de3] (021+034/095) Accurately ripped
 22     [fab8baeb|5f56995f] (021+035/097) Accurately ripped
 23     [3239d8ed|97552621] (019+034/095) Accurately ripped

Code: [Select]
[CUETools log; Date: 7/5/2019 3:25:38 PM; Version: 2.1.6]
[CTDB TOCID: TUhRQR2WhqyYCbEwQ532JKyTFko-] found.
Track | CTDB Status
  1   | ( 63/134) Accurately ripped
  2   | ( 65/134) Accurately ripped
  3   | ( 65/134) Accurately ripped
  4   | ( 64/134) Accurately ripped
  5   | ( 62/134) Accurately ripped
  6   | ( 65/134) Accurately ripped
  7   | ( 65/134) Accurately ripped
  8   | ( 65/134) Accurately ripped
  9   | ( 65/134) Accurately ripped
 10   | ( 64/134) Accurately ripped
 11   | ( 64/134) Accurately ripped
 12   | ( 65/134) Accurately ripped
 13   | ( 63/134) Accurately ripped
 14   | ( 63/134) Accurately ripped
 15   | ( 64/134) Accurately ripped
 16   | ( 62/134) Accurately ripped
 17   | ( 61/134) Accurately ripped
 18   | ( 62/134) Accurately ripped
 19   | ( 65/134) Accurately ripped
 20   | ( 61/134) Accurately ripped
 21   | ( 62/134) Accurately ripped
 22   | ( 62/134) Accurately ripped
 23   | ( 61/134) Accurately ripped

Beautiful. So I guess my BD drive produces better results than my DVD drive. I only changed because I deemed it sufficient for CD ripping, and didn't want to put unnecessary load on my BD drive. All's well that end's well!

 
SimplePortal 1.0.0 RC1 © 2008-2019