Bad Sector dumping AmigaDOS disk with KF but not when copying with X-Copy?

[BarryB]

Dumping a copy of Colonel's Bequest, plain AmigaDOS disks, and hit a strange issue (to me at least). Disk #3 is reported to have a bad sector on track 06.0 (luckily this track is empty), but if I copy the disk with X-Copy or run a checkdisk then track 06.0 shows green and copies, no error?

I've tried 3 different drives and commands ranging from -r10 to -r50 and -t10 and -t20 but cannot get a good read of this track! Is this a case of KF being too smart or is it a known mastering error?

[Feltzkrone]

Can you upload that track (.raw) somewhere so one can take a look? Thanks.

[BarryB]

Have a look at the attached please. One other thing, KF says 1 bad sector when dumping but if I put the streams through Keir's Disk-Utilities it says it has 2 sectors missing?

EDIT: The disk has been modified, there should be a 'resource.003' file on the disk but it's been deleted and does go through the bad track! Still doesn't explain why it seems fine on a real Amiga but not with KF?

[mr.vince]

Because X-Copy could eg "repair" a damaged track by correcting the checksum. Your data would still be damaged but AOS would stop complaining. I worked for Cachet. Still, not all decisions made sense. We can't comment on Keir's code, it is not ours...

[BarryB]

Ok, that makes sense, KF is doing it's job of reporting the track bad when x-copy is just 'cheating'

As for Keir's code, no, I wouldn't expect any comment for that here. It was an observation I made when creating IPFs with it, that's all.

[Feltzkrone]

There is noise on the third sector of 6 MFM bits width. The recorded flux timings are about 3.5, 2.6, 2.7 and 3.4 µs (hex 52 40 42 50). When manually changed to 8.8 and 3.4 µs (very unusual combination as flux reversals repell each other) the stored checksum matches the one calculated during decoding, and it does also when changed to 6.1, 2.7 and 3.4 µs.

In the latter case the first 6.1 µs results in a clock bit set to 1 where it really should be 0, followed immediately by a 1 bit (which is illegal MFM) but data bits remain the same. I'm curious what data a DD drive would deliver here as I think that due to filtering it possibly ignores one or two of these very short timings. Also it would be interesting to see how the track buffer looks like when read using Amiga hardware (is the illegal clock bit present or not, or is X-Copy really just cheating).

Normally there shouldn't be any flux reversal that has a timing substantially lower than 4 µs when using DD disks, so what one could do here is a best guess, especially when more than 6 bits are affected, but that's not exactly brilliant if the intention is to preserve data.

[BarryB]

Nice explanation, pity I'm too dense to understand it

The disk has been modified, a file has been deleted, could it be the person realised his mistake and pulled the disk out mid erase?

[Feltzkrone]

I think that it's bit rot of rather low degree ("only" 6 bits affected but still these might render the whole game useless) and the coincidence that the affected sector could -in theory- still be read ok using a DD drive - or X-Copy is really cheating here.

[BarryB]

Well seeing as the disk has issues anyway I'm going to write an IPF to a blank disk and use that in it's place.