26 Jul
2007
26 Jul
'07
9:55 p.m.
From: "Chuck Guzis" <cclist at
sydex.com>
Hi
I know what you mean about putting it first. Still, you can experiment
with clock and data shifts until you find a CRC that give an error in the
256 byte data field. If it is a single burst error, odds are it will appear
in the data field. If there are more than one error or the CRC is
not aligned correctly, the odds are that it will never get the zeros
at both ends.
I don't recall the burst size for the 16 bit CRC but I thing it is
6 or 7 bits. I recall that the normal 32 bit CRC that is used for
communications was a 12 bit burst.
In any case, one could write a program to try different combinations
of clock and data shifting and walking the CRC backwards. If it
finds a combination that works, your job is that much easier.
I used a similar program several years ago to recover data from
tapes that had been damaged. Most was BASIC programs so
it was relatively easy to check. Still, it was compressed BASIC.
The tapes were manchester encoded.
Dwight
_________________________________________________________________
http://newlivehotmail.com
On 26 Jul 2007 at 6:40, dwight elvey wrote:
Your right, not too good on multiple errors.
Actually, on MFM, not even that good for single errors. Recall that
the CRC on a 256-byte sector is the 257th and 258th byte of the
sector. So, if an MFM error throws the data stream off, you don't
even get a valid CRC to work with. And MFM data errors can result in
data shifting and clock data "swapping". It might have been a whole
'nother story had the convention been that the CRC precedes the data.