bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ddrescue] Rescueing CDs burned with Track-At-Once


From: John Bokma
Subject: Re: [Bug-ddrescue] Rescueing CDs burned with Track-At-Once
Date: Wed, 03 Sep 2014 18:10:16 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

Hi Antonio,

Thanks for your very quick reply, and your work on ddrescue and this
list, of course.

> John Bokma wrote:
>> rescued:   667650 kB,  errsize:    4096 B,  current rate:        0 B/s
>>    ipos:   667652 kB,   errors:       1,    average rate:     565 kB/s
>>    opos:   667652 kB, run time:    1.88 m,  successful read:      52 s
>> ago
>>
>> Based on what I've read those are most likely 2 blocks created by
>> Track-At-Once: "two unreadable run-out blocks at the end of the track."
> 
> I think so.
> 
> 
>> Based on the above I calculate the size of the ISO image as: 32581 x
>> 2048 = 667342848

It gets weirder, I go through my CDs in chronological order and now am
at CDs written using "Nero". The calculated size seems to include the
two unreadable run-out blocks since of the 4 or so CDs checked all have
2 unreadable blocks at the very end (4096B errsize). I have to check if
this is actually the 150 'nulled' blocks + 2 unreadable ones.

>> The rescued image, however, is 667650048 bytes; 307200 bytes larger, or
>> 150 blocks. Is this also a side effect of Track At Once?
>>
>> Should I use the --size option (on both) to just grab the blocks as
>> reported by isoinfo?
> 
> I am no CD expert, but I remember to have read about some "150 lead-in
> sectors".

The CDs I ripped, so far seem to have those 150 sectors at the end, but:

> If I were to store the iso images, I would store them complete
> just in case I cut the wrong 150 sectors out of them.

Yes, I am now convinced that this is /the best advice/. What I am going
to do:

rip each CD (the ones done, again) and if the last 2 blocks are unreadable:

 - check if the last 150 sectors are all null

and (if not too much coding work) always check that the /last/ file
falls entirely within the ripped image.

And not worry too much about null sectors, etc. The images are not going
to be burnt back to CD anyway. I want to store ~ 6 images with PAR2 (or
similar) on DVDs and on a backup disk for archival purposes.

It's quite a surprise that most CDs, ~14 years old read without a single
problem. And the CDs that cause problems are mostly made by Sony (at
first I joked "Only Sony", but I found a non-Sony one). I can actually
see big holes (few mm) in the top layer. But no worries, because I have
the damaged files on several working CDs.

Thanks again,
John



reply via email to

[Prev in Thread] Current Thread [Next in Thread]