CUERipper: Result submitted to CTDB even when test & copy CRCs mismatch

[daihakken]

• Version of CUERipper: 2.2.2 (from the official site)
• Used drive: BENQ DVD DD DW1650

As mentioned in the title, CUERipper will submit result with different test & copy CRCs, while the CTDB plugin for EAC will simply refuse that due to insufficient quality.

EAC:

Track  9

     Filename C:\Rip Temp\09 Track09.wav

     Peak level 83.6 %
     Extraction speed 2.0 X
     Track quality 100.0 %
     Test CRC D23BB86A
     Copy CRC 1217DD47
     Cannot be verified as accurate (confidence 1)  [8A326031], AccurateRip returned [0C87D727]  (AR v2)
     Copy OK
(...)


---- CUETools DB Plugin V2.1.6

[CTDB TOCID: 2TTRx1MxLdoohqEB3o58Qvxe8KA-] disk not present in database
Submit result: insufficient quality

CUERipper:

Track  9

     Filename C:\Rip Temp1\09. Track 09.wav

     Peak level 83.6 %
     Track quality 100.0 %
     Test CRC D23BB86A
     Copy CRC 1217DD47
     Cannot be verified as accurate (confidence 2)  [0D4AECC6], AccurateRip returned [0C87D727]
     Copy OK

(...)


Track 13

     Filename C:\Rip Temp1\13. Track 13.wav

     Peak level 94.7 %
     Track quality 100.0 %
     Test CRC 5E83CD6F
     Copy CRC E5B3566D
     Cannot be verified as accurate (confidence 2)  [F6DE7206], AccurateRip returned [ADD8207D]
     Copy OK

Result submitted to CUETools DB: http://db.cuetools.net/?tocid=2TTRx1MxLdoohqEB3o58Qvxe8KA-

Full logs are also attached for your references: EAC.log CUERipper.log

[ha-korth]

This is an old post but I believe CUERipper still behaves the same way https://hydrogenaud.io/index.php?msg=770571

Using the above post as a reference, your CUERipper log shows track quality of 100% for all tracks so rip quality was reported as 100%. Since the above referenced post, the EAC plugin does receive track quality information from EAC and can use to determine rip quality.

[daihakken]

@ha-korth Thank you for bringing up this post. However, I'm actually ripping with "test & copy" option enabled, instead of copy only mode in that post. This makes this issue relevant to that, but it is still somehow a different issue.

From what I have observed, the ~~copy-only mode~~ ripping behaviour in CUERipper acts like T&C mode in EAC, which rip a certain sector (? - I am uncertain about that) and then verifying it by re-read it again.

[ha-korth]

Yeah I should've highlighted the specific text I was referencing.

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,

Real test&copy wasn't added to CUERipper until after the referenced post but I believe CUERipper still calculates rip quality based only on suspicious positions.

This data isn't public but the database shows both of your CUERipper rips were submitted with 100% rip quality.

I understand that you may feel that the test CRC should be used as a test for rip quality. I'm just trying point out that I don't think CUERipper currently works that way.

From what I have observed, the copy-only mode ripping behaviour in CUERipper acts like T&C mode in EAC, which rip a certain sector (? - I am uncertain about that) and then verifying it by re-read it again.

Secure mode is: read (re-read). Secure mode test&copy is Test: read (re-read), Copy: read (re-read). *assuming no C2.

[daihakken]

Yeah I should've highlighted the specific text I was referencing.

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,

Real test&copy wasn't added to CUERipper until after the referenced post but I believe CUERipper still calculates rip quality based only on suspicious positions. This data isn't public but the database shows both of your CUERipper rips were submitted with 100% rip quality.

I understand that you may feel that the test CRC should be used as a test for rip quality. I'm just trying point out that I don't think CUERipper currently works that way.

I read that comment, and in my opinion, it only makes senses when it is in copy-only mode. When it is in test and copy mode, the question from my mind after reading the post and using the ripper is "why not comparing the two attempts?", it sounds like an opportunity missed to avoid introducing results less accurate into CTDB. Hence, I created this issue.

From what I have observed, the copy-only mode ripping behaviour in CUERipper acts like T&C mode in EAC, which rip a certain sector (? - I am uncertain about that) and then verifying it by re-read it again.

Secure mode is: read (re-read). Secure mode test&copy is Test: read (re-read), Copy: read (re-read). *assuming no C2.

Good to hear the fact that is confirming my observation when using CUERipper. I think this is a smarter way to rip discs (compared to EAC).

A bit off-topic, but I also mentioned the following two points in the P.S. of another issue I created. May you please help to point the relevant discussion to let me understand CUERipper better?

1. The gaps detected are different between EAC & CUERipper. I have tried method A&B in EAC against CUERipper, and there are always differences between the detection.
2. How to request drive support, as gap detection in CUERipper doesn't work with the drive mentioned in this issue.

[ha-korth]

May you please help to point the relevant discussion to let me understand CUERipper better?

CUETools discussion WIKI

1. Gaps are detected by reading and re-reading (maybe multiple times) a section of the CD to find silence or near silence. The exact positions are not stored on the CD like the TOC. EAC is closed source so the developer does not share how his program does what it does. The goal is to be reasonably accurate while staying reasonably fast.
2. right here in the issues section

[DarkVoyage]

You have a problematic CD that have such positions that always read differently. The only thing you can do is to compare in AccurateRip/CTDB for the most often result. You can try different drive to rip too. There's no big problem with submitting different or wrong results to either db, they will keep them as a variation. Some popular CDs have 20-30 variations of data, but you can see most popular variants and even fix your rip to any of them with CueTools. It was designed to work like that. If ripping finishes without errors then it is considered proper. Rip in EAC without test will be submitted too. That's just a small difference. But you can rip again and again and you will get matching test&copy once. Does it really mean that this is correct result? It is like coin toss. When you have two or more results that are equiprobable then you can't get a real result no matter how many times you rip the track. Live with it or search for another exemplar of CD, try different drive, try paranoia mode in EAC.