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: Various questions regarding EAC's error detection and correction ability (Read 4528 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Various questions regarding EAC's error detection and correction ability

I'm using EAC to rip a CD and the last track will not rip correctly.  The extraction completes, but the last 30 seconds of the resulting .wav file are silence.  After searching around on these and other forums, I have some questions regarding EAC's error detection and correction ability.  First, here is the log file of the track that will not rip:

Code: [Select]
Exact Audio Copy V1.5 from 20. February 2020

EAC extraction logfile from 22. December 2020, 16:35

Metallica / Hardwired… to Self‐Destruct

Used drive  : HL-DT-STBDDVDRW GGC-H20L   Adapter: 1  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : Yes

Read offset correction                      : 667
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
Gap handling                                : Not detected, thus appended to previous track

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 |  7:10.00 |         0    |    32249   
        2  |  7:10.00 |  9:03.11 |     32250    |    72985   
        3  | 16:13.11 |  4:35.01 |     72986    |    93611   
        4  | 20:48.12 |  5:50.05 |     93612    |   119866   
        5  | 26:38.17 |  3:08.01 |    119867    |   133967   
        6  | 29:46.18 |  4:07.00 |    133968    |   152492   
        7  | 33:53.18 |  5:19.18 |    152493    |   176435   
        8  | 39:12.36 |  6:56.27 |    176436    |   207662   
        9  | 46:08.63 |  7:24.07 |    207663    |   240969   
       10  | 53:32.70 |  5:13.09 |    240970    |   264453   
       11  | 58:46.04 |  4:32.00 |    264454    |   284853   
       12  | 63:18.04 |  6:43.13 |    284854    |   315091   
       13  | 70:01.17 |  6:07.36 |    315092    |   342652   
       14  | 76:08.53 |  3:30.06 |    342653    |   358408   


Track 14

     Filename D:\Music\Rips\Hardwired to Self Destruct V0\Disc 3\14 - Hardwired (live).wav

     Peak level 100.0 %
     Extraction speed 0.0 X
     Track quality 97.0 %
     Copy CRC B83FDD9B
     Cannot be verified as accurate (confidence 200)  [BF0C6AB5], AccurateRip returned [94999B95]  (AR v2)
     Copy OK


No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

No errors occurred

End of status report

==== Log checksum 7A479EAAEE362DF1229F099D04C9EFBC450B0FB6F4807AD7CF475827D837481E ====

My first question is about this line taken from https://www.exactaudiocopy.de/en/index.php/overview/basic-technology/extraction-technology/:

Quote
But by using this technique non-identical sectors are detected. If an error occurs (read or sync error), the program keeps on reading this sector, until eight of 16 retries are identical, but at maximum one, three or five times (according to the selected error recovery quality) these 16 retries are read. So, in the worst case, bad sectors are read up to 82 times! But this effort will help the program to obtain the best result by comparing all of the retries.

If I'm understanding the above paragraph correctly, EAC will repeatedly read each sector (2352 bytes according to https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio) until either 8 reads have returned the same value OR a maximum of 16 reads are performed, whichever comes first.  Then it repeats that process either 1, 3, or 5 times.  Here are my questions:

  • If the process is repeated 5 times, that would give a maximum of 16x5=80 reads, not 82.  Where do the extra 2 reads come from?
  • If the "read the sector until 8/16 retries are identical" process is repeated 1, 3, or 5 times, are the results of each set of retries (in the case of 3 or 5 retries) compared against each other to determine the "final" answer, and then if those don't match EAC concludes the sector is completely unreadable/unrecoverable?  If not, then how are each set of retries used?
  • The EAC ripping status window has a grid with 80 red boxes labeled "Error correction".  When I'm ripping my unreadable/unrecoverable track, I notice boxes in this grid being incrementally lit up.  Does that mean an error was detected, an error was detected and corrected, or an error was detected and not corrected?
  • Finally, given the information in the above log file, is there anything else in EAC I can try to get that track to rip successfully?
 

Re: Various questions regarding EAC's error detection and correction ability

Reply #1 –
Your log doesn't show any read or sync errors.
C2 Error detection is enabled. EAC will not re-read and try to get consistent data from sectors which the drive reports as being error-free using C2 Pointers. Have you tried to rip the CD with C2 off?
The CD is over 79:38 long. This length can be an issue for some drives. If the drive is not capable of reading to the end of the CD, the premature stop will corrupt the last data read by EAC.
korth

Re: Various questions regarding EAC's error detection and correction ability

Reply #2 –
Quote from: korth on
Your log doesn't show any read or sync errors.

True, but it took EAC 5.5 hours to rip that last track, plus there is this:

Code: [Select]
Cannot be verified as accurate (confidence 200)  [BF0C6AB5], AccurateRip returned [94999B95]  (AR v2)

I took that to be an error given that all other tracks ripped from this CD have a message similar to the following (complete log not shown):

Code: [Select]
Accurately ripped (confidence 200)  [4B52823E]  (AR v2)

Quote from: korth on
C2 Error detection is enabled. EAC will not re-read and try to get consistent data from sectors which the drive reports as being error-free using C2 Pointers. Have you tried to rip the CD with C2 off?

I have not tried that but can.  Related to that, can you answer this question:

Quote
The EAC ripping status window has a grid with 80 red boxes labeled "Error correction".  When I'm ripping my unreadable/unrecoverable track, I notice boxes in this grid being incrementally lit up.  Does that mean an error was detected, an error was detected and corrected, or an error was detected and not corrected?

Quote from: korth on
The CD is over 79:38 long. This length can be an issue for some drives. If the drive is not capable of reading to the end of the CD, the premature stop will corrupt the last data read by EAC.

The last track was ripped separately from all of the others due to the presence of the error.  Does that CD length matter in that case?


MOD Edit: Fix quote

Re: Various questions regarding EAC's error detection and correction ability

Reply #3 –
Quote from: hudson4351 on
  • If the process is repeated 5 times, that would give a maximum of 16x5=80 reads, not 82.  Where do the extra 2 reads come from?
  • If the "read the sector until 8/16 retries are identical" process is repeated 1, 3, or 5 times, are the results of each set of retries (in the case of 3 or 5 retries) compared against each other to determine the "final" answer, and then if those don't match EAC concludes the sector is completely unreadable/unrecoverable?  If not, then how are each set of retries used?
  • The EAC ripping status window has a grid with 80 red boxes labeled "Error correction".  When I'm ripping my unreadable/unrecoverable track, I notice boxes in this grid being incrementally lit up.  Does that mean an error was detected, an error was detected and corrected, or an error was detected and not corrected?
1.) 1 read + 1 retry. If they don't match then up to 80 more retries.
2.) If "Error recovery quality" is set to medium or high, after the first unsuccessful 8 identical reads out of (up to) 16 retries, that retry data is discarded and a new set of 16 retries is attempted. And so on... EAC will report a read error if 8 identical reads weren't achieved. (edited, rushed post)
3.) Each red box is showing a retry in groups of 16. If they light then first two reads didn't match and error correction has started.
korth

Re: Various questions regarding EAC's error detection and correction ability

Reply #4 –
Quote from: hudson4351 on
plus there is this:
Code: [Select]
Cannot be verified as accurate (confidence 200)  [BF0C6AB5], AccurateRip returned [94999B95]  (AR v2)
I took that to be an error given that all other tracks ripped from this CD have a message similar to the following (complete log not shown):
Code: [Select]
Accurately ripped (confidence 200)  [4B52823E]  (AR v2)
That's an error reported by the AccurateRip plugin, not EAC.

Quote
The last track was ripped separately from all of the others due to the presence of the error.  Does that CD length matter in that case?
Yes, if the drive cannot read to the end of the CD there will be a sudden stop that EAC doesn't expect.
korth

Re: Various questions regarding EAC's error detection and correction ability

Reply #5 –
Quote from: korth on
C2 Error detection is enabled. EAC will not re-read and try to get consistent data from sectors which the drive reports as being error-free using C2 Pointers. Have you tried to rip the CD with C2 off?

If C2 error detection being enabled causes EAC to not re-read any sectors which the drive reports as being error free using C2 pointers, and my log above shows that no errors were found, then why did ripping that one track take 5.5 hours?  Based on your quote above it seems no sectors should have been re-read because no errors were found.

I am trying it now with C2 off but the ripping speed slows down dramatically at around the same point in the last track.  I'll let it finish but isn't the slow rip speed an indication the result will be the same as with C2 enabled?

Quote from: korth on
The CD is over 79:38 long. This length can be an issue for some drives. If the drive is not capable of reading to the end of the CD, the premature stop will corrupt the last data read by EAC.

If this is due to a limitation of my CD drive, is there anything that can be done as a workaround aside from buying a new drive?

Is there a very specific length beyond which drives tend to have problems?

Is there a database of drives that are known to have this issue?

Re: Various questions regarding EAC's error detection and correction ability

Reply #6 –
I wouldn't let the drive attempt to rip the CD again for hours.

For secure ripping, each section is read twice. If a section contains an error it is likely that the two reads are not identical. If the two reads are not identical, error correction is triggered. With eight identical reads out of sixteen the [possible] error is assumed corrected and no error is reported. (Consistent errors are possible but may or may not be relevant to your issue.)
Because C2 overrides secure ripping, a drive that incorrectly reports C2 pointers can report errors that don't exist which can trigger excessive unneeded retries or report the section error-free preventing retries that may have been needed.

Do you have the CTDB plugin installed? If so can I see the full EAC log including the CTDB section?

Edit: The knowledgebase article recommends setting "Error recovery quality" to "low" (one set of 16 retries) to reduce wear on your drive.
korth

Re: Various questions regarding EAC's error detection and correction ability

Reply #7 –
Quote from: korth on
I wouldn't let the drive attempt to rip the CD again for hours.

For secure ripping, each section is read twice. If a section contains an error it is likely that the two reads are not identical. If the two reads are not identical, error correction is triggered. With eight identical reads out of sixteen the [possible] error is assumed corrected and no error is reported. (Consistent errors are possible but not relevant to your issue.)
Because C2 overrides secure ripping, a drive that incorrectly reports C2 pointers can report errors that don't exist which can trigger excessive unneeded retries or report the section error-free preventing retries that may have been needed.

When I click EAC->Drive Options->Detect Read Features, the "C2 Error Info" box in the "Analyzing" box that pops up says "Yes".  Doesn't that mean my drive correctly supports C2?

In any case ripping that last track with C2 turned off was taking hours so I canceled it.

Quote from: korth on
Do you have the CTDB plugin installed? If so can I see the full EAC log including the CTDB section?

When I click EAC->EAC Options->Audio Plugins, I see "CUETools DB Plugin V2.1.6" listed, which I assume is the CTDB.  How do I identify the CTDB section of the log file?  The log posted in my OP is all I have from ripping that last track (at least AFAIK).

Also can you comment on the questions in my previous post regarding CD length and drive limitations?

Re: Various questions regarding EAC's error detection and correction ability

Reply #8 –
Quote
Doesn't that mean my drive correctly supports C2?
https://wiki.hydrogenaud.io/index.php?title=EAC_Drive_Options#Drive_is_capable_of_retrieving_C2_error_information

Quote
How do I identify the CTDB section of the log file?
Quote from: korth on
[...] full EAC log including the CTDB section?
The CTDB section is only available when all 14 tracks are ripped. If you aborted the initial rip before completing all 14 tracks then you won't have it. I was curious if it said the rip was repairable but after looking at the end of that track I don't know if this is a suitable workaround. Not that much silence showing.
X

Quote
If this is due to a limitation of my CD drive, is there anything that can be done as a workaround aside from buying a new drive? Is there a very specific length beyond which drives tend to have problems?

The limit is 80 minutes but not all drives can read that far (79+?). According to at least one site, your drive can over-burn to 95:10. You can try a different drive or computer. You could try a different ripper, CUERipper (part or CUETools) or dBpoweramp or see if repair is an option with CUETools.
 
Quote
Is there a database of drives that are known to have this issue?

Not that I know of.
korth

Re: Various questions regarding EAC's error detection and correction ability

Reply #9 –
Quote from: korth on
The CTDB section is only available when all 14 tracks are ripped. If you aborted the initial rip before completing all 14 tracks then you won't have it. I was curious if it said the rip was repairable but after looking at the end of that track I don't know if this is a suitable workaround. Not that much silence showing.

I did some searching and found this thread that talks about verifying/repairing a rip using CUETools:

https://hydrogenaud.io/index.php?topic=102046.0

Following the advice in that thread, I generated a .cue file from the entire CD using Action->Create CUE Sheet->Multiple WAV Files... from within EAC.  From there, I followed the instructions in the above thread for repairing a disc image using CUETools.  Here is the resulting log file:

Code: [Select]
[CUETools log; Date: 12/24/2020 11:03:38 AM; Version: 2.1.6]
[CTDB TOCID: LAKt5weTVF0XT.nj2dxWRxoHD4k-] found.
Track | CTDB Status
  1   | (3413/3427) Accurately ripped
  2   | (3419/3427) Accurately ripped
  3   | (3420/3427) Accurately ripped
  4   | (3184/3427) Accurately ripped
  5   | (3416/3427) Accurately ripped
  6   | (3412/3427) Accurately ripped
  7   | (3414/3427) Accurately ripped
  8   | (3415/3427) Accurately ripped
  9   | (3411/3427) Accurately ripped
 10   | (3416/3427) Accurately ripped
 11   | (3417/3427) Accurately ripped
 12   | (3416/3427) Accurately ripped
 13   | (3410/3427) Accurately ripped
 14   | (  0/3427) No match
[AccurateRip ID: 002aa8bb-01c0d7cb-af12aa0e] found.
Track   [  CRC   |   V2   ] Status
 01     [cb615b2a|4b52823e] (003+200/424) Accurately ripped
 02     [60b56d5a|1cf1f676] (003+200/425) Accurately ripped
 03     [fa4c06c1|b46f3e0c] (003+200/425) Accurately ripped
 04     [ce84c17f|ac59d907] (003+183/411) Accurately ripped
 05     [fc55bed8|2780d863] (003+200/425) Accurately ripped
 06     [edc0d057|530b82d5] (003+200/425) Accurately ripped
 07     [1cdd5b19|5350a05e] (003+200/425) Accurately ripped
 08     [8e8aacf6|c7287183] (003+200/425) Accurately ripped
 09     [0b9f61d4|545501b9] (003+200/425) Accurately ripped
 10     [a11a23eb|46d7002c] (003+200/425) Accurately ripped
 11     [188f7e02|b49bd351] (003+200/425) Accurately ripped
 12     [7e3dceff|778fe682] (003+200/425) Accurately ripped
 13     [6a2ce34a|a2477932] (003+200/425) Accurately ripped
 14     [02eb0204|bf0c6ab5] (000+000/424) No match
Offsetted by -29:
 01     [a616d061] (000/424) No match (V2 was not tested)
 02     [41ce41c1] (000/425) No match (V2 was not tested)
 03     [4aeaedfd] (000/425) No match (V2 was not tested)
 04     [95b1d1e5] (000/411) No match (V2 was not tested)
 05     [21137406] (000/425) No match (V2 was not tested)
 06     [9ba45eef] (000/425) No match (V2 was not tested)
 07     [1e4491d9] (000/425) No match (V2 was not tested)
 08     [959ef6dc] (000/425) No match (V2 was not tested)
 09     [4f675db7] (000/425) No match (V2 was not tested)
 10     [4933df3f] (000/425) No match (V2 was not tested)
 11     [42dc6a44] (000/425) No match (V2 was not tested)
 12     [8bff785d] (000/425) No match (V2 was not tested)
 13     [9f8120ab] (000/425) No match (V2 was not tested)
 14     [e2370eab] (000/424) No match (V2 was not tested)
Offsetted by -11:
 01     [5c21c56b] (000/424) No match (V2 was not tested)
 02     [0e5dbdeb] (000/425) No match (V2 was not tested)
 03     [8ba2c865] (000/425) No match (V2 was not tested)
 04     [9e7b5dc9] (000/411) No match (V2 was not tested)
 05     [d925c9cd] (000/425) No match (V2 was not tested)
 06     [b34fb9f6] (000/425) No match (V2 was not tested)
 07     [7bfe414d] (000/425) No match (V2 was not tested)
 08     [cf1b613c] (000/425) No match (V2 was not tested)
 09     [0ee608e8] (000/425) No match (V2 was not tested)
 10     [60b5c2a2] (000/425) No match (V2 was not tested)
 11     [66928674] (000/425) No match (V2 was not tested)
 12     [97195691] (000/425) No match (V2 was not tested)
 13     [55cd86bd] (000/425) No match (V2 was not tested)
 14     [579dec55] (000/424) No match (V2 was not tested)
Offsetted by 1:
 01     [d57e68c7] (016/424) Accurately ripped
 02     [96bd6607] (016/425) Accurately ripped
 03     [6172af55] (016/425) Accurately ripped
 04     [a4571061] (015/411) Accurately ripped
 05     [4be940de] (016/425) Accurately ripped
 06     [a6759cca] (016/425) Accurately ripped
 07     [02fb7842] (016/425) Accurately ripped
 08     [19eb3372] (016/425) Accurately ripped
 09     [6693f3ec] (016/425) Accurately ripped
 10     [b2c40d64] (016/425) Accurately ripped
 11     [76f8379a] (016/425) Accurately ripped
 12     [751c80f4] (016/425) Accurately ripped
 13     [9618f37e] (016/425) Accurately ripped
 14     [fb37d571] (000/424) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --  100.0 [DA3FE469] [EB73E7BC]           
 01  100.0 [65D39AD5] [21CD0451] [B83FDD9B]: CRC32 for track 14
 02  100.0 [056C4007] [39CA454B] [65D39AD5]: CRC32 for track 1
 03  100.0 [2AB89195] [E0A86516] [056C4007]: CRC32 for track 2
 04  100.0 [BBEAC75C] [78237A97] [2AB89195]: CRC32 for track 3
 05  100.0 [B3A499E5] [5A64F3CB] [BBEAC75C]: CRC32 for track 4
 06  100.0 [54772614] [4A748A83] [B3A499E5]: CRC32 for track 5
 07  100.0 [796B6543] [ECC8718B] [54772614]: CRC32 for track 6
 08  100.0 [05F090CB] [9EACB312] [796B6543]: CRC32 for track 7
 09  100.0 [107A59C8] [A3D34F4D] [05F090CB]: CRC32 for track 8
 10  100.0 [22837FC1] [35B7F2B8] [107A59C8]: CRC32 for track 9
 11  100.0 [151B1659] [4C3538C5] [22837FC1]: CRC32 for track 10
 12  100.0 [28F2C024] [EA2EB48E] [151B1659]: CRC32 for track 11
 13  100.0 [6A5C6D6D] [DC279EF7] [28F2C024]: CRC32 for track 12
 14  100.0 [B83FDD9B] [1488477C] [6A5C6D6D]: CRC32 for track 13

Based on the following line and the information in the above thread:

Code: [Select]
 14     [fb37d571] (000/424) No match (V2 was not tested)

It seems CUETools cannot be used to repair the track.  Given that nearly 30 seconds of audio are missing from the rip I'm not surprised.  Is this the same method you were suggesting with the CTDB file that is created when the entire album is ripped?  Does a CUE file contain the same information as the CTDB section of the EAC log file when all tracks are ripped?

Quote from: korth on
You could try a different ripper, CUERipper (part or CUETools) or dBpoweramp

Is EAC generally considered to be the best ripper?  Or do different rippers tend to do better/worse with different issues?

Re: Various questions regarding EAC's error detection and correction ability

Reply #10 –
Actually the 'No match' line below shows the rip is not repairable but yes this line would have been similar in the CTDB section of the EAC extraction log of a full 14 track rip.
Code: [Select]
[CTDB TOCID: LAKt5weTVF0XT.nj2dxWRxoHD4k-] found.
[...]
 14   | (  0/3427) No match

One reason for suggesting a different ripper was to see if the same issue existed at the end of the 14th track. CUERipper can only rip the full CD and can only use a single encoder but doesn't require any setup to try it.

I currently use CUERipper as my primary ripper and EAC as a backup when issues occur, or I don't need to rip the whole CD. I also use Easy Audio Copy.
Many use dBpoweramp which includes a 'stepping' option (starts with Burst mode + AccurateRip then moves to Secure mode only on tracks that do not match AccurateRip). This is faster than just using Secure mode all the time and reduces drive wear. EAC's sister program, Easy Audio Copy, also uses Burst + AccurateRip then moves on to Secure mode if needed.
korth

Re: Various questions regarding EAC's error detection and correction ability

Reply #11 –
Quote from: korth on
Actually the 'No match' line below shows the rip is not repairable but yes this line would have been similar in the CTDB section of the EAC extraction log of a full 14 track rip.
Code: [Select]
[CTDB TOCID: LAKt5weTVF0XT.nj2dxWRxoHD4k-] found.
[...]
 14   | (  0/3427) No match

One reason for suggesting a different ripper was to see if the same issue existed at the end of the 14th track. CUERipper can only rip the full CD and can only use a single encoder but doesn't require any setup to try it.

I currently use CUERipper as my primary ripper and EAC as a backup when issues occur, or I don't need to rip the whole CD. I also use Easy Audio Copy.
Many use dBpoweramp which includes a 'stepping' option (starts with Burst mode + AccurateRip then moves to Secure mode only on tracks that do not match AccurateRip). This is faster than just using Secure mode all the time and reduces drive wear. EAC's sister program, Easy Audio Copy, also uses Burst + AccurateRip then moves on to Secure mode if needed.

CUERipper ran for about an hour and then errored out with "Exception: Error reading CD: loctlFailed".

dBpoweramp was run using the following settings (more or less taken from this page https://www.dbpoweramp.com/secure-ripper.htm under "The Test" section; I used a lower number of maximum re-reads):

Pass 1: AccurateRip Verified
Pass 2: Limit Drive Speed (Maximum)

Ultra Secure
    - Enable Ultra Secure Ripping
    - Minimum Ultra Passes: 6
    - Maximum Ultra Passes: 10
    - End After Clean Passes: 2
    - Maximum Re-Reads 34 times
   
No other options checked.  I killed the run after 12 hours assuming if it hadn't completed by that point it wasn't going to.  The dbpoweramp link above doesn't appear to list how long it took to rip the tracks with errors.