copying files with bad CRCs

[yawnmoth]

Say I wanted to copy a *.avi video file (xvid encoded; it's currently
on a hard drive)) but was told (by Windows XP) I couldn't because it
had a bad CRC. Is there a way I could sorta just copy it in spite of
the bad CRC?

The reason I ask is because xvid (and MPEG1/2/4, in general) is a
rather resiliant format. A single corrupt byte may just mean that one
frame is bad. If every 20th frame is a keyframes (ie. i-frames, or
whatever), this means that only 20 - (frame position) % 20 frames are
bad. If there are 100,000+ frames, having less then 20 bad frames is
fairly insignificant. Yet it's significant enough for Windows to deny
you access to the whole file?

So, anyway, I think, in some cases, Windows' seeming refusal to let you
do anything with corrupt files is inappropriate. Is there any
work-around that I'm not aware of?

Thanks!

 

[Rod Speed]

Say I wanted to copy a *.avi video file (xvid encoded; it's currently
on a hard drive)) but was told (by Windows XP) I couldn't because it
had a bad CRC. Is there a way I could sorta just copy it in spite of
the bad CRC?

The reason I ask is because xvid (and MPEG1/2/4, in general) is a
rather resiliant format. A single corrupt byte may just mean that one
frame is bad. If every 20th frame is a keyframes (ie. i-frames, or
whatever), this means that only 20 - (frame position) % 20 frames are
bad. If there are 100,000+ frames, having less then 20 bad frames is
fairly insignificant.

Trouble is that Win is saying you have a bad
sector in that file. Thats quite a few bytes, 512

Yet it's significant enough for Windows
to deny you access to the whole file?

Its not denying you access, thats what the Abort Retry Fail is for.

So, anyway, I think, in some cases, Windows' seeming
refusal to let you do anything with corrupt files is inappropriate.
Is there any work-around that I'm not aware of?

Spinrite claims to try hard to get what is obtainable from the file.

 

[Arno Wagner]

Say I wanted to copy a *.avi video file (xvid encoded; it's currently
on a hard drive)) but was told (by Windows XP) I couldn't because it
had a bad CRC. Is there a way I could sorta just copy it in spite of
the bad CRC?

The reason I ask is because xvid (and MPEG1/2/4, in general) is a
rather resiliant format. A single corrupt byte may just mean that one
frame is bad. If every 20th frame is a keyframes (ie. i-frames, or
whatever), this means that only 20 - (frame position) % 20 frames are
bad. If there are 100,000+ frames, having less then 20 bad frames is
fairly insignificant.

Agreed. Matches my experience.

Yet it's significant enough for Windows to deny
you access to the whole file?

The problem here is that the underlying OS functionality
is not prepared to deal with bad CRCs in any way. It can only
report the error.

So, anyway, I think, in some cases, Windows' seeming refusal to let you
do anything with corrupt files is inappropriate. Is there any
work-around that I'm not aware of?

For the defective sector itself, there is not. The disk does not
deliver it to the OS. Some data-recovery siftware may still be
able to do a raw read or the like, but I have no experience
with that. For the rest of the file, there is.

The problem really is not with Windoes, but with the application
that stops to read when encountering a read error.

There is a tool called dd_rescue on Linux, that can serve as an
example. It will skip a 512 byte sector (or other size if set
on the commandline) if it reads bad and continue with the next
sector. It does this on the normal file-access layer and the
approach should work with Windows also.

However, I think that you will either have to programm this yourself
or use Linux dd_rescue to copy the file. Should not be too difficult
to write if you have some programming experience.

Arno

 

[Frazer Jolly Goodfellow]

Say I wanted to copy a *.avi video file (xvid encoded; it's
currently on a hard drive)) but was told (by Windows XP) I
couldn't because it had a bad CRC. Is there a way I could sorta
just copy it in spite of the bad CRC?

The reason I ask is because xvid (and MPEG1/2/4, in general) is
a rather resiliant format. A single corrupt byte may just mean
that one frame is bad. If every 20th frame is a keyframes (ie.
i-frames, or whatever), this means that only 20 - (frame
position) % 20 frames are bad. If there are 100,000+ frames,
having less then 20 bad frames is fairly insignificant. Yet
it's significant enough for Windows to deny you access to the
whole file?

So, anyway, I think, in some cases, Windows' seeming refusal to
let you do anything with corrupt files is inappropriate. Is
there any work-around that I'm not aware of?

Thanks!

I've no direct experience of it, but it is claimed to do what you
need...

http://www.roadkil.net/unstopcp.html

"Product Description

Recovers files from disks with physical damage. Allows you to copy
files from disks with problems such as bad sectors, scratches or
that just give errors when reading data. The program will attempt
to recover every readable piece of a file and put the pieces
together. Using this method most types of files can be made useable
even if some parts were not recoverable in the end. "

 

[Folkert Rienstra]

Agreed. Matches my experience.

Probably not, given the solution you come up with.

The problem here is that the underlying OS functionality is not pre-
pared to deal with bad CRCs in any way. It can only report the error.

Actually it will do retries and unless the interface is completely dead
next commands will just succeed.

For the defective sector itself, there is not.

Nonsense. CRC errors are not sector errors.

The disk does not deliver it to the OS.

So, now assuming ECC errors, (not CRC errors):
Depends on what IDE command is issued to the drive.
Some read commands stop at the sector in error but *do* deliver the faulty
sector data in the receive buffer.
If the app reads the buffer despite of the error the (faulty) data will be
there. Not clear though whether the OS will allow that (or facilitate it).

Some data-recovery siftware may still be able to do a raw read or the like,
but I have no experience with that.
For the rest of the file, there is.

The problem really is not with Windoes, but with the application
that stops to read when encountering a read error.

(Which in this case is 'Windoes' Explorer)

The problem is with the IDE command that is aborted up to the sector
in error, by the disk. The actual IDE command is issued by the OS.
If the OS doesn't allow any other options than to read a file without
error or not at all then obviously that's not the application's fault.
And why the hell would an user application want to read faulty data?

There is a tool called dd_rescue on Linux, that can serve as an example.
It will skip a 512 byte sector (or other size if set on the commandline)
if it reads bad and continue with the next sector.

He wants the bad sector as well, bad and all.

It does this on the normal file-access layer

But obviously with a different from 'normal' or usual access pattern.

and the approach should work with Windows also.

However, I think that you will either have to programm this yourself
or use Linux dd_rescue to copy the file.

The file isn't resqued. It will be a damaged file with missing data.

Should not be too difficult to write if you have some programming experience.

Then program it to read the bad sector as well, instead of skipping it.

 

[yawnmoth]

Trouble is that Win is saying you have a bad
sector in that file. Thats quite a few bytes, 512

The fact that a sectors CRC isn't what it should be doesn't necessarily
mean that all the bytes are corrupted, does it? I mean, wouldn't just
one of those bytes being corrupted result in a CRC mismatch?

 

[Arno Wagner]

The fact that a sectors CRC isn't what it should be doesn't necessarily
mean that all the bytes are corrupted, does it? I mean, wouldn't just
one of those bytes being corrupted result in a CRC mismatch?

A single bit would be enough. However since HDDs do not really use
CRC but a more elaboraate ECC, you will likely get some real
corruption. If you can get the disk to give the raw data to you.

In SCSI there is a command to read the raw data. There might be one
in ATA too. Might mean that you have to do some programming
yourself. But the easiest approach is to try to do without the
defective sector.

Arno

 

[Rod Speed]

Rod Speed wrote

The fact that a sectors CRC isn't what it should be doesn't
necessarily mean that all the bytes are corrupted, does it?

Sure, I meant that mostly when the sector isnt readable,
you basically lose all 512 bytes, not just a few bytes.

I mean, wouldn't just one of those bytes being
corrupted result in a CRC mismatch?

ECC, yes. But what normally happens is that you
dont get anything much of the bytes you should get.

 

[Folkert Rienstra]

The fact that a sectors CRC

ECC, not CRC.

isn't what it should be doesn't necessarily mean that all the bytes are corrupted, does it?

A sufficient number of them that the contents can't be repaired by the ECC.

I mean, wouldn't just one of those bytes being corrupted result in a CRC mismatch?

The problem is that Windows won't give them to you, all 512 of them.

 

[Horst Franke]

In yawnmoth
typed:
Hi "yawnmoth" (who what so ever named You so?)
A CRC does no longer looks like a HW fault but may also result
from a SW CRC checksum.

No, from a HW point of view every 512 bytes are checked (ECC).
From a SW point of view the comlete file is checked.
But both are regaining You from reading the data correctly.

The fact that a sectors CRC isn't what it should be doesn't
necessarily mean that all the bytes are corrupted, does it? I mean,
wouldn't just one of those bytes being corrupted result in a CRC
mismatch?

Any of CRC or ECC error might prevent You from reading the data.
Then You would have to reconstruct that data (rewrite or rebuild).
Some extern utilities may be able to read these data.
But this matter has too much culprits to give You a single solution.
Horst

 

[Horst Franke]

In news:[email protected] Rod Speed typed:

Sure, I meant that mostly when the sector isnt readable,
you basically lose all 512 bytes, not just a few bytes.

Hi Rod, not only even that but a complete cluster,
which is normally 4096 bytes (by NTFS).
But ECC might recover some of the 8 sectors involved.
Horst

 

[Rod Speed]

Rod Speed wrote

Hi Rod, not only even that but a complete cluster,
which is normally 4096 bytes (by NTFS).

But ECC might recover some of the 8 sectors involved.

The ECC applys at the sector level, not the cluster level.

And you wont necessarily lose an entire cluster on a single bad sector either.

 

[Horst Franke]

In news:[email protected] Rod Speed typed:

The ECC applys at the sector level, not the cluster level.

Hi Rod, please see above = some of the 8 sectors involved!

And you wont necessarily lose an entire cluster on a single bad
sector either.

The "read" is on a cluster level - and if any part of it will not be
readable then the complete cluster will be treated as not readable.
Horst

 

[Rod Speed]

In news:[email protected] Rod Speed typed:
Hi Rod, please see above = some of the 8 sectors involved!

The "read" is on a cluster level - and if any part of it will not be
readable then the complete cluster will be treated as not readable.

Wrong as far as the data is concerned.

 

[mscotgrove]

www.cnwrecovery.com

The program will continue reading even with CRC errors. Blocks of
fixed data will be inserted, but you maybe able to recover your file.
The beta program is still free

Michael (CnW Recovery)

 

[Folkert Rienstra]

www.cnwrecovery.com

The program will continue reading even with CRC errors. Blocks of
fixed data will be inserted,

but you maybe able to recover your file.

But that's the point, you don't.
You may be able to play the file from where it is by sofware that uses
the streaming command set (if the drive/driver supports it) and then
capture it from there.