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: EAC and CTDB - is this a problem? Can't repair it... (Read 3976 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC and CTDB - is this a problem? Can't repair it...

I have a CD that I've tried to rip with EAC that gets the following problem listed in the log file
 8   | (306/321) Accurately ripped, or (1/321) differs in 715 samples @05:03:26-05:03:27.

The log file from EAC is below.
- It shows AR resulting indicating that the CD is accurately RIP ed.
- No errors

But the CUETools DB Plugin is showing a problem with track 8... differing in 715 samples.
- I'm not sure this is a problem, but I think it is as it is listed when I encode to flac as well
- I've tried ripping on several drives in various extraction modes.
- I've tried repairing with Cuetools and picking the alternative with a confidence level of > 200 (can't remember the number)

Is this a problem?
How can I fix it?
Thanks

Code: [Select]
Exact Audio Copy V1.6 from 23. October 2020

EAC extraction logfile from 24. February 2023, 8:17

Joni Mitchell / Hejira

Used drive  : PLEXTOR CD-R   PX-W124TS   Adapter: 1  ID: 1

Read mode : Paranoid

Read offset correction                      : 943
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.33 |  5:01.17 |        33    |    22624   
        2  |  5:01.50 |  6:01.60 |     22625    |    49759   
        3  | 11:03.35 |  5:07.55 |     49760    |    72839   
        4  | 16:11.15 |  4:18.73 |     72840    |    92262   
        5  | 20:30.13 |  6:41.17 |     92263    |   122354   
        6  | 27:11.30 |  8:38.58 |    122355    |   161262   
        7  | 35:50.13 |  4:22.62 |    161263    |   180974   
        8  | 40:13.00 |  5:04.05 |    180975    |   203779   
        9  | 45:17.05 |  6:38.00 |    203780    |   233629   


Range status and errors

Selected range

     Filename E:\inprogress\jm - hejira paranoid no cache p124 3\Joni Mitchell - Hejira.wav

     Peak level 98.7 %
     Extraction speed 0.0 X
     Range quality 99.9 %
     Copy CRC 5A60F7F9
     Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 16)  [FB4541D5]  (AR v2)
Track  2  accurately ripped (confidence 16)  [15F06798]  (AR v2)
Track  3  accurately ripped (confidence 17)  [3E894E48]  (AR v2)
Track  4  accurately ripped (confidence 17)  [D28094F0]  (AR v2)
Track  5  accurately ripped (confidence 15)  [FEBA270A]  (AR v2)
Track  6  accurately ripped (confidence 15)  [A61887AF]  (AR v2)
Track  7  accurately ripped (confidence 16)  [E22112C6]  (AR v2)
Track  8  accurately ripped (confidence 17)  [5D424D4C]  (AR v2)
Track  9  accurately ripped (confidence 16)  [680AF11D]  (AR v2)
 
All tracks accurately ripped

End of status report

---- CUETools DB Plugin V2.1.6

[CTDB TOCID: YE5q7FGx4Abbl7wbtDjgihufksM-] found
Submit result: already submitted
Track | CTDB Status
  1   | (304/321) Accurately ripped
  2   | (311/321) Accurately ripped
  3   | (305/321) Accurately ripped
  4   | (308/321) Accurately ripped
  5   | (303/321) Accurately ripped
  6   | (304/321) Accurately ripped
  7   | (307/321) Accurately ripped
  8   | (306/321) Accurately ripped, or (1/321) differs in 715 samples @05:03:26-05:03:27
  9   | (309/321) Accurately ripped


==== Log checksum 90830B9372AE2F099ABA1215FA42C0D1E6946142BAE8AA223AF608F05FEE4F1D ====



MOD edit: Copy log to code for easier viewing

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #1 –
Quote from: dpr on
that gets the following problem listed in the log file
 8   | (306/321) Accurately ripped, or (1/321) differs in 715 samples @05:03:26-05:03:27.

You are matching 306 out of 321 submissions, so it is the lone "1/321" that is wrong. The problem is theirs, not yours :-)

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #2 –
Thanks.

A perhaps controversial follow-up question. If I’m using Accurate Rip, why also use CTDB? If all of the tracks get good checksums in AR, then why also check CTDB, which seems to have some issues such as people with bad rips can end up submitting multiple times.

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #3 –
Quote from: dpr on
A perhaps controversial follow-up question. If I’m using Accurate Rip, why also use CTDB? If all of the tracks get good checksums in AR, then why also check CTDB, which seems to have some issues such as people with bad rips can end up submitting multiple times.
Rather ask "why not". The issues you mention are first and foremost troublesome for people who download others' defective rips - don't worry about them! Do both. If you get into your logs that both verify it, then no harm done - and if not, it was a good thing to have them both checked. You don't want to do the rip job again.

There is a long history, AR being a much older verification tool and the much more recent CUETools database also uploading recovery bits to repair rips, emerging not far in time from when a second version of AccurateRip came about to accommodate cross-pressing validation (and solving a problem that frankly wasn't a problem).

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #4 –
Quote from: Porcus on
Quote from: dpr on
A perhaps controversial follow-up question. If I’m using Accurate Rip, why also use CTDB? If all of the tracks get good checksums in AR, then why also check CTDB, which seems to have some issues such as people with bad rips can end up submitting multiple times.
Rather ask "why not". The issues you mention are first and foremost troublesome for people who download others' defective rips - don't worry about them! Do both. If you get into your logs that both verify it, then no harm done - and if not, it was a good thing to have them both checked. You don't want to do the rip job again.



Well, maybe on RIPs it is ok, but if CTDB is polluted with bad rips, it's a hassle and annoying. Why aren't this not accepted?
I like to see a log file with no errors and I see errors in my logfile! ... I've noticed the total creeping up as  I've been ripping which also has errors... from successive log files:

 8   | (304/319) Accurately ripped, or (1/319) differs in 715 samples @05:03:26-05:03:27
 8   | (305/320) Accurately ripped, or (1/320) differs in 715 samples @05:03:26-05:03:27
 8   | (306/321) Accurately ripped, or (1/321) differs in 715 samples @05:03:26-05:03:27

I also have check CTDB turned on in CUEtools for encoding which creates lots of errors in a batch log file... maybe I should turn it off?

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #5 –
The "or" matches mean that it is possible to repair your rip to match that particular entry. IMHO CUETools should not display these alternate results if your rip is confirmed to be accurate, and especially if your rip conforms to the majority of results, because it causes unnecessary confusion. The "or" matches should only be shown if your rip is not confirmed to be accurate, because that means you need to repair it, and a valid repair entry exists. Unfortunately, this is not how CUETools works.

I wouldn't turn CUETools off, though, because it's useful when you have a bad CD. I ripped a new CD this week that had three damaged tracks, and I was able to repair all three with CUETools, which saved me from having to buy the CD again to get an accurate rip.

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #6 –
Quote from: Aleron Ives on
The "or" matches mean that it is possible to repair your rip to match that particular entry. IMHO CUETools should not display these alternate results if your rip is confirmed to be accurate, and especially if your rip conforms to the majority of results, because it causes unnecessary confusion. The "or" matches should only be shown if your rip is not confirmed to be accurate, because that means you need to repair it, and a valid repair entry exists. Unfortunately, this is not how CUETools works.
That would make certain manufacturing defects unrepairable. My copy of Pink Floyd's "Pulse" had one track with much lower confidence than the rest. Indeed, scrutinizing the bits it was pretty obvious that mine was "wrong", but had mine been the "majority vote" it couldn't have been repaired and compared.

So either CUETools must implement some very smart algorithm to hide some of its resources from the users, or it can accept such uploads mechanically and leave it to the user to interpret the output.

Quote from: dpr on
if CTDB is polluted with bad rips, it's a hassle and annoying. Why aren't this not accepted?
Explained above. CUETools can either do as it does, or the developer would have to invest human effort to come up with a smart algorithm that would risk making wrong choices.

Quote from: dpr on
I like to see a log file with no errors and I see errors in my logfile!
No, you don't. Well you see that others have had errors - even the "304/321" for track 1 indicates that someone has had an error.
But there is nothing wrong reported with your rip.

Quote from: dpr on
... I've noticed the total creeping up as  I've been ripping which also has errors... from successive log files:
Yes, and that is one reason not to ditch the lowest-counting recovery record. What if one with 2 hits is correct and then someone tries to re-rip ten times to get something consistent and finally gets three identical but wrong rips?

AccurateRip knows your hardware profile and rejects multiple submissions from the same computer, also it purges submissions from drives known to be unreliable - and it updates only periodically after running checks on the input data.
CUETools updates instantly, and produces numbers that say something slightly different. Just fine with me, they are two different tools and there wouldn't be much need for both if the did precisely the same.

Quote from: dpr on
8   | (304/319) Accurately ripped, or (1/319) differs in 715 samples @05:03:26-05:03:27
 8   | (305/320) Accurately ripped, or (1/320) differs in 715 samples @05:03:26-05:03:27
 8   | (306/321) Accurately ripped, or (1/321) differs in 715 samples @05:03:26-05:03:27

I also have check CTDB turned on in CUEtools for encoding which creates lots of errors in a batch log file... maybe I should turn it off?
"errors"? If you have a peculiar aversion against seeing a report that "many others someone else also ripped this like yours but <numbers indicating that someone got a wrong rip as well>" then make your choice, but don't blame anyone else.

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #7 –
Quote from: Porcus on
Quote from: dpr on
that gets the following problem listed in the log file
 8   | (306/321) Accurately ripped, or (1/321) differs in 715 samples @05:03:26-05:03:27.

You are matching 306 out of 321 submissions, so it is the lone "1/321" that is wrong. The problem is theirs, not yours :-)

My example of

8   | (304/319) Accurately ripped, or (1/319) differs in 715 samples @05:03:26-05:03:27
 8   | (305/320) Accurately ripped, or (1/320) differs in 715 samples @05:03:26-05:03:27
 8   | (306/321) Accurately ripped, or (1/321) differs in 715 samples @05:03:26-05:03:27

Is that it was me increasing the count of 304/319 to 306/321 by doing successive rips…. Why is it counting them?


When I’m batch encoding, I don’t want to analyse this info in the log file for 1000 CDs, so it seems like turning off checking CTDB at when encoding makes sense.

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #8 –
Quote
Is that it was me increasing the count of 304/319 to 306/321 by doing successive rips…. Why is it counting them?
looks like you used 3 different drives
Code: [Select]
DVDRAM GP57EB40
CD-R PX-W124TS
CD-ROM PX-40TS
and had 3 different CTDB IDs (a modified CRC32 of the whole CD)
Code: [Select]
E1CE253C
EFCDD77E
A2F3B354

But...
Even if you used the same drive, the 3 rips are different. All 9 tracks are not the same.
The CUETools DB is based on whole CD rips. Your rip has to match the modified CRC32 for all 9 tracks to be confirmed and added to a CTDB ID. If one of the tracks are a little different, the whole rip goes under a different CTDB ID.
The (306/321) is a per track summary of all CTDB IDs. The first number shows how many times your ripped track matches in all CTDB IDs and the second number shows the total number of rips in all CTDB IDs.

The same user cannot confirm and/or add to a CTDB ID more than once.
korth

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #9 –
Quote from: dpr on
When I’m batch encoding, I don’t want to analyse this info in the log file for 1000 CDs, so it seems like turning off checking CTDB at when encoding makes sense.
Again, why? The information is there for if and when you need it.


Quote from: korth on
The same user cannot confirm and/or add to a CTDB ID more than once.
Same computer with same drive?

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #10 –
Same user hardware ID using same drive.
korth

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #11 –
Quote from: korth on
Quote
Is that it was me increasing the count of 304/319 to 306/321 by doing successive rips…. Why is it counting them?
looks like you used 3 different drives
Code: [Select]
DVDRAM GP57EB40
CD-R PX-W124TS
CD-ROM PX-40TS
and had 3 different CTDB IDs (a modified CRC32 of the whole CD)
Code: [Select]
E1CE253C
EFCDD77E
A2F3B354
Yes, my mistake! Sorry. (there's also probably a 4th drive  in the db as well!)

Quote from: Porcus on
Quote from: dpr on
When I’m batch encoding, I don’t want to analyse this info in the log file for 1000 CDs, so it seems like turning off checking CTDB at when encoding makes sense.
Again, why? The information is there for if and when you need it.

Yes, but on a batch encode, I've done my rips previously. I just want to know if the encodes worked... turning off the check makes it easier to review the logfile....So, back to the original question, what's the downside of turning off checking CTDB?


 

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #12 –
Quote from: dpr on
So, back to the original question, what's the downside of turning off checking CTDB?
Rips that are not in the AccurateRip database. They might be in the CTDB. For example, I think CUERipper does not submit to AR, only to CTDB.

You can do as follows with CUETools: Make sure you have set it to write AccurateRip tags.
Then post encode, dump them into say foobar2000 or Mp3tag and search for those that do not verify as "Accurate" (or with confidence only 1, avoiding your own ... I am not completely sure, but I think CUETools will find lonely entries). Those you dump into the CUETools drag and drop window again, and run a query with CUETools.

Alternatively, you can run with CUETools and both AR and CTDB tags written. And search up those with high enough AccurateRip confidence, and delete the CTDB tags from those. The ones that still have CTDB tags are where you will want to look further into CTDB reporting to consider whether they should/can be repaired.

Re: EAC and CTDB - is this a problem? Can't repair it...

Reply #13 –
Quote from: Porcus on
Quote from: dpr on
So, back to the original question, what's the downside of turning off checking CTDB?
Rips that are not in the AccurateRip database. They might be in the CTDB. For example, I think CUERipper does not submit to AR, only to CTDB.

You can do as follows with CUETools: Make sure you have set it to write AccurateRip tags.
Then post encode, dump them into say foobar2000 or Mp3tag and search for those that do not verify as "Accurate" (or with confidence only 1, avoiding your own ... I am not completely sure, but I think CUETools will find lonely entries). Those you dump into the CUETools drag and drop window again, and run a query with CUETools.

Alternatively, you can run with CUETools and both AR and CTDB tags written. And search up those with high enough AccurateRip confidence, and delete the CTDB tags from those. The ones that still have CTDB tags are where you will want to look further into CTDB reporting to consider whether they should/can be repaired.

My practice is to get a good cd rip  EAC and checking with AR and CTDB and creating an single .wav image with a .cue file and a .log file…. If needed, I will now use the repair function in Cuetools. Only then do I encode. I’ve no insight into which is larger. I assumed that AR is because I have the impression that more rippers submit to AR.

The EAC log file is a good record of the extraction of the large .wav (image) file. Once I’ve successfully repaired one with errors, I assume the log file is out of date as it lists errors  that have been fixed. Is there a way of generating an updated version? Should I care?