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.
Moderator Edit: Added CODE box.
Re: Why can't I repair this rip??
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.
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.
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.
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.
The EAC extraction logfile is showing ARv2 results only.
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.
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.
The script in CUETools will only tell you how many samples differ when the difference is close enough to attempt a repair.
"E:\02 Girl Who Got Away (damaged).wav"
"E:\02 Girl Who Got Away.wav"
but then you would have access to a good file .
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?
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.
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.
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?
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.