Skip to main content
Topic: Why can't I repair this rip?? (Read 825 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Why can't I repair this rip??

I have the cd 'Girl Who Got Away' by Dido.  Track 2 has a slight scratch, but after a few re-reads it rips successfully (no 'suspicious position' errors, and 99.3% track quality).  However, CueTools gives me a 'no match' for this track and no repair option.

This is really puzzling - especially when I have another cd (Pink Floyd's 'Meddle') where the last track is scratched much worse with multiple 'suspicious position' errors - but CueTools does give me a repair option (for 20,281 errors!!)

Does anyone know why the Dido cd won't let me repair it?  Below is the CueTools verify log for this disc:


Code: [Select]
[CUETools log; Date: 11/22/2018 9:32:32 PM; Version: 2.1.5]
[CTDB TOCID: QxDMzHoudA.NAsw6P5H5Ad0no.o-] found.
Track | CTDB Status
  1   | (750/750) Accurately ripped
  2   | (  0/750) No match
  3   | (744/750) Accurately ripped
  4   | (743/750) Accurately ripped
  5   | (750/750) Accurately ripped
  6   | (750/750) Accurately ripped
  7   | (749/750) Accurately ripped
  8   | (750/750) Accurately ripped
  9   | (750/750) Accurately ripped
 10   | (750/750) Accurately ripped
 11   | (749/750) Accurately ripped
[AccurateRip ID: 00114858-0096ffac-8f0a1f0b] found.
Track   [  CRC   |   V2   ] Status
 01     [e8097b45|b89f3f17] (042+200/283) Accurately ripped
 02     [f8f18b52|b67091d8] (000+000/283) No match
 03     [0edfdb8e|be26fe21] (041+200/283) Accurately ripped
 04     [729c77af|f4db704c] (041+200/283) Accurately ripped
 05     [baa4d00b|cea374f1] (041+200/283) Accurately ripped
 06     [818c51f2|f330f5c6] (041+200/283) Accurately ripped
 07     [9cc4f9a9|9d2fbf7d] (041+200/281) Accurately ripped
 08     [8a424662|664e6493] (041+200/281) Accurately ripped
 09     [fc036ca4|565bde2c] (041+200/281) Accurately ripped
 10     [1bb345d5|a99e01fe] (040+200/280) Accurately ripped
 11     [f7eaf59b|f16d6a51] (040+200/277) Accurately ripped
Offsetted by -646:
 01     [e49c9361] (000/283) No match (V2 was not tested)
 02     [291e0c70] (000/283) No match (V2 was not tested)
 03     [8d29e4c2] (000/283) No match (V2 was not tested)
 04     [25d46a9b] (000/283) No match (V2 was not tested)
 05     [9639f9f7] (000/283) No match (V2 was not tested)
 06     [5f6588f8] (000/283) No match (V2 was not tested)
 07     [3ceeb4ab] (000/281) No match (V2 was not tested)
 08     [75a82516] (000/281) No match (V2 was not tested)
 09     [6d01c80c] (000/281) No match (V2 was not tested)
 10     [06b8800f] (000/280) No match (V2 was not tested)
 11     [20236d84] (000/277) No match (V2 was not tested)
Offsetted by -42:
 01     [ce73bd09] (000/283) No match (V2 was not tested)
 02     [9cf79ba4] (000/283) No match (V2 was not tested)
 03     [b338aefa] (000/283) No match (V2 was not tested)
 04     [4eb58123] (000/283) No match (V2 was not tested)
 05     [b1249a7f] (000/283) No match (V2 was not tested)
 06     [2c1ba19c] (000/283) No match (V2 was not tested)
 07     [81ee8637] (000/281) No match (V2 was not tested)
 08     [686c904e] (000/281) No match (V2 was not tested)
 09     [f5e2d27c] (000/281) No match (V2 was not tested)
 10     [05babeeb] (000/280) No match (V2 was not tested)
 11     [971acff7] (000/277) No match (V2 was not tested)
Offsetted by -30:
 01     [b130ced1] (000/283) No match (V2 was not tested)
 02     [6e1a7268] (000/283) No match (V2 was not tested)
 03     [cd687292] (000/283) No match (V2 was not tested)
 04     [3465354b] (000/283) No match (V2 was not tested)
 05     [219260a7] (000/283) No match (V2 was not tested)
 06     [4484f890] (000/283) No match (V2 was not tested)
 07     [1be2a733] (000/281) No match (V2 was not tested)
 08     [bb3be8e6] (000/281) No match (V2 was not tested)
 09     [1c3547ac] (000/281) No match (V2 was not tested)
 10     [9e4ae577] (000/280) No match (V2 was not tested)
 11     [d756486f] (000/277) No match (V2 was not tested)
Offsetted by -12:
 01     [054c697d] (000/283) No match (V2 was not tested)
 02     [27ceb48e] (000/283) No match (V2 was not tested)
 03     [f4b017f6] (000/283) No match (V2 was not tested)
 04     [8cecc387] (000/283) No match (V2 was not tested)
 05     [4a3709e3] (000/283) No match (V2 was not tested)
 06     [6922fafe] (000/283) No match (V2 was not tested)
 07     [02d0d8ad] (000/281) No match (V2 was not tested)
 08     [3772edca] (000/281) No match (V2 was not tested)
 09     [d5b0f774] (000/281) No match (V2 was not tested)
 10     [83231f49] (000/280) No match (V2 was not tested)
 11     [b7af7d23] (000/277) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --   99.8 [91F97D79] [8F6D27CD] [97101259]: CRC32 for track 2
 01   99.8 [CFB9E5E3] [C53A640F]          
 02   99.8 [97101259] [3C75A2B1]          
 03   99.8 [EF18FB11] [4740D728]          
 04   99.8 [89C07963] [C02CE3F9]          
 05   89.1 [AFC85D9F] [401E51A3]          
 06   97.6 [1E97E43E] [DC75AA5E]          
 07   99.8 [CBB4D418] [E84BA229]          
 08   94.4 [A358BB3D] [6248F896]          
 09   94.4 [2A1B8E1F] [E90D98DC]          
 10   99.8 [CC92C795] [4E2F4531]          
 11   94.4 [64BA3337] [36C478C0]
         

Moderator Edit: Added CODE box.

Re: Why can't I repair this rip??

Reply #1
Consistent errors are possible. Some of the damaged areas may consistently produce the same data, just not the data that matches the database.

The positions of the errors matter as well.
http://cue.tools/wiki/CUETools_Database#How_many_errors_can_a_rip_contain_and_still_be_repairable.3F
Quote
How many errors can a rip contain and still be repairable?

    That depends. The best case scenario is when there's one continuous damaged area up to 30-40 sectors (about half a second) long for most discs. As of CTDB 2.0, one continuous damaged area up to about 75 sectors (a second) on popular discs.
    The worst case scenario is 4 non-continuous damaged sectors in (very) unlucky positions.

The [LOG] column in the verify log you provided is showing the presence of an extraction log containing only a single file (track 2) so I think you left a few details out. If the track you're substituting for the original track 2 wasn't ripped using the proper read offset then all the samples in that track wouldn't match the original rip.
korth

Re: Why can't I repair this rip??

Reply #2
Thanks for the reply korth.  I actually did rip that track individually in Exact Audio Copy - I did that after ripping the other 10 error-free tracks from the same cd.  The reason I did it that way was to prevent EAC from uploading erroneous results to the main database (hopefully that makes sense?)

All 11 tracks in the CueTools verify log were ripped on the same pc.  However, is there still an offset issue?  I'm wondering as near the top of the log track 2 shows '+000/' while all other tracks show '+200/' (or does any 'no match' show '+000/' regardless of what the error is?)

Here is the EAC log for Track 2 when I ripped it separately - and then below that the log for the other 10 tracks:

Code: [Select]
Exact Audio Copy V1.3 from 2. September 2016

EAC extraction logfile from 20. November 2018, 0:13

Dido / Girl Who Got Away

Used drive  : hp      DVDRW GUD1N   Adapter: 1  ID: 0

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

Read offset correction                      : 6
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 |  3:17.33 |         0    |    14807  
        2  |  3:17.33 |  3:24.19 |     14808    |    30126  
        3  |  6:41.52 |  4:11.46 |     30127    |    48997  
        4  | 10:53.23 |  4:09.08 |     48998    |    67680  
        5  | 15:02.31 |  4:00.06 |     67681    |    85686  
        6  | 19:02.37 |  3:18.42 |     85687    |   100578  
        7  | 22:21.04 |  4:36.68 |    100579    |   121346  
        8  | 26:57.72 |  4:24.29 |    121347    |   141175  
        9  | 31:22.26 |  3:30.26 |    141176    |   156951  
       10  | 34:52.52 |  3:06.20 |    156952    |   170921  
       11  | 37:58.72 |  5:12.33 |    170922    |   194354  


Track  2

     Filename C:\Users\daytr\Music\EAC\Dido\WAVs7\02 Girl Who Got Away.wav

     Peak level 99.8 %
     Extraction speed 1.4 X
     Track quality 99.3 %
     Copy CRC 97101259
     Cannot be verified as accurate (confidence 200)  [B67091D8], AccurateRip returned [94EB8111]  (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 DAB6680D6871F09AAC7E122D55EE89D8AB25245E0E86DF10A015DA9430A9D865 ====

------------------------------------------------------------

Exact Audio Copy V1.3 from 2. September 2016

EAC extraction logfile from 19. November 2018, 18:04

Dido / Girl Who Got Away

Used drive  : hp      DVDRW GUD1N   Adapter: 1  ID: 0

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

Read offset correction                      : 6
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 |  3:17.33 |         0    |    14807  
        2  |  3:17.33 |  3:24.19 |     14808    |    30126  
        3  |  6:41.52 |  4:11.46 |     30127    |    48997  
        4  | 10:53.23 |  4:09.08 |     48998    |    67680  
        5  | 15:02.31 |  4:00.06 |     67681    |    85686  
        6  | 19:02.37 |  3:18.42 |     85687    |   100578  
        7  | 22:21.04 |  4:36.68 |    100579    |   121346  
        8  | 26:57.72 |  4:24.29 |    121347    |   141175  
        9  | 31:22.26 |  3:30.26 |    141176    |   156951  
       10  | 34:52.52 |  3:06.20 |    156952    |   170921  
       11  | 37:58.72 |  5:12.33 |    170922    |   194354  


Track  1

     Filename C:\Users\daytr\Music\EAC\Dido\01 No Freedom.wav

     Peak level 99.8 %
     Extraction speed 1.2 X
     Track quality 100.0 %
     Copy CRC CFB9E5E3
     Accurately ripped (confidence 200)  [B89F3F17]  (AR v2)
     Copy OK

Track  3

     Filename C:\Users\daytr\Music\EAC\Dido\03 Let Us Move On.wav

     Peak level 99.8 %
     Extraction speed 1.5 X
     Track quality 100.0 %
     Copy CRC EF18FB11
     Accurately ripped (confidence 200)  [BE26FE21]  (AR v2)
     Copy OK

Track  4

     Filename C:\Users\daytr\Music\EAC\Dido\04 Blackbird.wav

     Peak level 99.8 %
     Extraction speed 1.6 X
     Track quality 100.0 %
     Copy CRC 89C07963
     Accurately ripped (confidence 200)  [F4DB704C]  (AR v2)
     Copy OK

Track  5

     Filename C:\Users\daytr\Music\EAC\Dido\05 End Of Night.wav

     Peak level 89.1 %
     Extraction speed 1.7 X
     Track quality 100.0 %
     Copy CRC AFC85D9F
     Accurately ripped (confidence 200)  [CEA374F1]  (AR v2)
     Copy OK

Track  6

     Filename C:\Users\daytr\Music\EAC\Dido\06 Sitting On The Roof Of The World.wav

     Peak level 97.6 %
     Extraction speed 1.5 X
     Track quality 99.9 %
     Copy CRC 1E97E43E
     Accurately ripped (confidence 200)  [F330F5C6]  (AR v2)
     Copy OK

Track  7

     Filename C:\Users\daytr\Music\EAC\Dido\07 Love To Blame.wav

     Peak level 99.8 %
     Extraction speed 1.7 X
     Track quality 99.9 %
     Copy CRC CBB4D418
     Accurately ripped (confidence 200)  [9D2FBF7D]  (AR v2)
     Copy OK

Track  8

     Filename C:\Users\daytr\Music\EAC\Dido\08 Go Dreaming.wav

     Peak level 94.4 %
     Extraction speed 2.0 X
     Track quality 100.0 %
     Copy CRC A358BB3D
     Accurately ripped (confidence 200)  [664E6493]  (AR v2)
     Copy OK

Track  9

     Filename C:\Users\daytr\Music\EAC\Dido\09 Happy New Year.wav

     Peak level 94.4 %
     Extraction speed 2.0 X
     Track quality 100.0 %
     Copy CRC 2A1B8E1F
     Accurately ripped (confidence 200)  [565BDE2C]  (AR v2)
     Copy OK

Track 10

     Filename C:\Users\daytr\Music\EAC\Dido\10 Loveless Hearts.wav

     Peak level 99.8 %
     Extraction speed 1.8 X
     Track quality 99.9 %
     Copy CRC CC92C795
     Accurately ripped (confidence 200)  [A99E01FE]  (AR v2)
     Copy OK

Track 11

     Filename C:\Users\daytr\Music\EAC\Dido\11 Day Before We Went To War.wav

     Peak level 94.4 %
     Extraction speed 2.1 X
     Track quality 99.9 %
     Copy CRC 64BA3337
     Accurately ripped (confidence 200)  [F16D6A51]  (AR v2)
     Copy OK


All tracks accurately ripped

No errors occurred

End of status report

==== Log checksum 081447E86268250F56DBDD17FFE126F36DFBBC8F3910B37A01E9593EB5ED1379 ====

Moderator Edit: Added CODE box.

Re: Why can't I repair this rip??

Reply #3
I was only trying to provide possible reasons why the rip wouldn't be repairable.
A fourth reason might be a damaged, corrupt or missing recovery record on the server. I doubt that but a possible reason.
A fifth reason might be that your CD is not the same as the one in the database and you would need to wait for a recovery record that matches that version of the CD.

Quote
However, is there still an offset issue?  I'm wondering as near the top of the log track 2 shows '+000/' while all other tracks show '+200/'.
Not evident in the EAC log.
The CUETools verify log shows ARv1 + ARv2 in the top section of the AccurateRip portion of the log. All of the alternate offset sections that follow are ARv1 only.
(042+200/283) Accurately ripped > 042 ARv1 matches + 200 ARv2 matches / out of the 283 entries found.
(000+000/283) No match > 000 ARv1 matches + 000 ARv2 matches / out of the 283 entries found.
More info at http://cue.tools/wiki/CUETools_log#AccurateRip_Section

The EAC extraction logfile is showing ARv2 results only.


Moderator Edit: Added 5th reason
korth

Re: Why can't I repair this rip??

Reply #4
Thanks again korth - so I guess there's really nothing else I can try? (besides attempting to smooth out the scratch?)

Re: Why can't I repair this rip??

Reply #5
You could try ripping from a different drive.
You could try ripping in burst mode.
You could try a different program.
Maybe you can close enough to repair.

The recovery record is good (actually there are two). I intentionally damaged about 30 sectors from a rip that verified as accurate.
Code: [Select]
[CTDB TOCID: QxDMzHoudA.NAsw6P5H5Ad0no.o-] found.
Track | CTDB Status
  1   | (750/750) Accurately ripped
  2   | (728/750) Differs in 35274 samples @02:11:11-02:11:40, or (4/750) differs in 35274 samples @02:11:11-02:11:40
  3   | (744/750) Accurately ripped, or (4/750) differs in 178 samples @01:55:42
  4   | (743/750) Accurately ripped
  5   | (750/750) Accurately ripped
  6   | (750/750) Accurately ripped
  7   | (749/750) Accurately ripped
  8   | (750/750) Accurately ripped
  9   | (750/750) Accurately ripped
 10   | (750/750) Accurately ripped
 11   | (749/750) Accurately ripped
[AccurateRip ID: 00114858-0096ffac-8f0a1f0b] found.
Track   [  CRC   |   V2   ] Status
 01     [e8097b45|b89f3f17] (042+200/283) Accurately ripped
 02     [39bd0ad4|e9ff4712] (000+000/283) No match
 03     [0edfdb8e|be26fe21] (041+200/283) Accurately ripped
 04     [729c77af|f4db704c] (041+200/283) Accurately ripped
 05     [baa4d00b|cea374f1] (041+200/283) Accurately ripped
 06     [818c51f2|f330f5c6] (041+200/283) Accurately ripped
 07     [9cc4f9a9|9d2fbf7d] (041+200/281) Accurately ripped
 08     [8a424662|664e6493] (041+200/281) Accurately ripped
 09     [fc036ca4|565bde2c] (041+200/281) Accurately ripped
 10     [1bb345d5|a99e01fe] (040+200/280) Accurately ripped
 11     [f7eaf59b|f16d6a51] (040+200/277) Accurately ripped
[...]

Track Peak [ CRC32  ] [W/O NULL]
 --   99.8 [6804EB7E] [39AB8102]          
 01   99.8 [CFB9E5E3] [C53A640F]          
 02   99.8 [D3404D86] [86F5D0C1]          
 03   99.8 [EF18FB11] [4740D728]          
 04   99.8 [89C07963] [C02CE3F9]          
 05   89.1 [AFC85D9F] [401E51A3]          
 06   97.6 [1E97E43E] [DC75AA5E]          
 07   99.8 [CBB4D418] [E84BA229]          
 08   94.4 [A358BB3D] [6248F896]          
 09   94.4 [2A1B8E1F] [E90D98DC]          
 10   99.8 [CC92C795] [4E2F4531]          
 11   94.4 [64BA3337] [36C478C0]
korth

Re: Why can't I repair this rip??

Reply #6
Thanks again for all the help.  Last thing - is there any way to tell how many samples different my track 2 rip is from that in the database? (regardless of whether or not I can do a repair)?  I'm just curious how 'close' I am to getting a repair match.

Re: Why can't I repair this rip??

Reply #7
The script in CUETools will only tell you how many samples differ when the difference is close enough to attempt a repair.

Now if you had access to a good file there's EAC's 'Compare WAVs' or foobar2000 'foo_bitcompare'
Code: [Select]
Differences found in compared tracks.

Comparing:
"E:\02 Girl Who Got Away (damaged).wav"
"E:\02 Girl Who Got Away.wav"
Compared 9009336 samples.
Differences found: 43501 values, starting at 1:11.826667, peak: 0.5267029 at 1:11.840204, 1ch
Channel difference peaks: 0.5267029 0.4248352
File #1 peaks: 0.9988403 0.9988403
File #2 peaks: 0.9988403 0.9988403



Total duration processed: 3:24.293
Time elapsed: 0:03.235
63.16x realtime

but then you would have access to a good file  ::) .
korth


Re: Why can't I repair this rip??

Reply #9
I've used both brasso and had CDs machine polished in order to successfully rip damaged CDs, however, it generally leaves the CD itself valueless as far as resale is concerned. This all assumes, of course, that the scratch is on the plastic surface layer and not the metal data layer.
Quis custodiet ipsos custodes?  ;~)

Re: Why can't I repair this rip??

Reply #10
I've used both brasso and had CDs machine polished in order to successfully rip damaged CDs, however, it generally leaves the CD itself valueless as far as resale is concerned. This all assumes, of course, that the scratch is on the plastic surface layer and not the metal data layer.

Thanks 2tec.  Quick question though - why wouldn't you be able to sell the cd once you've fixed the scratch?

Re: Why can't I repair this rip??

Reply #11
Thanks 2tec.  Quick question though - why wouldn't you be able to sell the cd once you've fixed the scratch?

The value of used CDs is dependent upon condition. According to the goldmine standard at Discogs I would grade a polished CD as Good (G), or maybe Good Plus (G+) which is worth maybe 20% of retail, if that.

Discogs grading

Personally, I would only buy a polished CD if there were no alternatives. Most CDs are common enough, it's often easy to find one in very good plus condition.
Quis custodiet ipsos custodes?  ;~)

Re: Why can't I repair this rip??

Reply #12
korth - I tried ripping that track with dbPowerAmp and was told there were 170 frames with errors - do you happen to know around how many samples that represents?

 

Re: Why can't I repair this rip??

Reply #13
Well CUETools gave a figure of 35274 samples ...

170 frames

1 frame (also known as "sector") is 1/75th of a second. So 170 frames close in on 200k samples (2 * 44100 * 170 / 75; the 44100 is the samplerate and the 2 is the number of channels)
High Voltage socket-nose-avatar

Re: Why can't I repair this rip??

Reply #14
Well CUETools gave a figure of 35274 samples ...
That figure came from my CD rip example with continuous damage intentionally added using Audacity (I was checking the recovery record on CTDB).

But a frame with errors reported by dbPowerAmp doesn't necessarily mean every sample in that frame had errors.
korth

 
SimplePortal 1.0.0 RC1 © 2008-2019