http://reveng.sourceforge.net/

My approach is to first figure out what marks the start
of the sector header and data. Your sample below shows it is the
0xA1 with dropped clock. Controllers use various methods to mark the
sectors. Some use other patterns than A1 along with time from
index for finding the sectors. Some don't have separate markers for the
data. One even used a non standard bit rate.

Next is to determine what bytes go in the CRC and what the
polynomal and associated parameters are. It looks like the tool I
pointed you to is probably better than my code for this. Frequently
header and data will have different polynomials. Sometimes the first
header bytes aren't included though.
My code does have a quick way to find the polynomial if you have the
correect data pattern. I'm not sure if the tool can make use of that.
http://www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html
The header has the patters to make this easy. Data may not unless you can
write to the disk before dumping.

Next is figuring out how they stored the cylinder (broken across 2 bytes),
head, sector, and other flags in the header.

All the above except the CRC is by staring at the data dumps.

If I understand your approach you will also need to determine the
various gap lengths and fill patterns. Those will be useful to me if
I make the opposite of mfm_util to convert a sector image back into
the track bits.



--header_crc 0,0,16
../mfm/mfm_util --emu 3640-pass\ 1.emufile --ext /tmp/t --sectors 17 --header_crc 0,0,64 --data_crc 0,0,32 --format WD_1006 --sector_length 1500 --quiet 0  > /tmp/tt