I released the fix for the choke.
Nice to see you have solved the NFA issue for Aufit.
The track duration is the index to index time - how long it took for the revolution to be spooled. Adding up all of the bitcell times should equal that time (but it won't be perfect due to drive speed variations). I am not sure why your first revoluion (revolution 0) has a smaller than normal time value vs. the duration. It shouldn't. I will look into that.
You guys and your 0xA1 syncs... call them 0x4489!
There are quite a few programs for the Amiga that use a huge difference in the clocking window - way more than 5%, this is how they get really long tracks. As far as I can tell, the WD1772 is not limited in the length of the data it will decode when issued a Type III command (read track). What I did see mentioned is that all sync patterns (0x4489) will cause a re-sync of the data. If you look at an Atari formatted disk, there are all kinds of issues because the sectors are written individually. The Amiga writes an entire track at once, even if a single sector is updated (there is a queue time courtesy of the multitasking, so multiple sector writes don't actually re-write the track for each sector - only when the head is stepped or a timeout occurs). So, with an Atari ST track you have to bitshift the data back and forth to locate the sync for just about every sector. With an Amiga track, you bitshift the data and the rest of the syncs will automatically be on the same shift value because they were written all together.
By the way, you can EASILY read and write NFA protections with the stock Amiga. I called this "strongbit" protections because when you read the protection data (NFA) it shows up as all MFM 0's (0x0000 over and over). Writing 0x0000 generated weakbits. So to write strongbits you just turned the 0x0000 into 0xFFFF (from weak to strong) and like magic, you duplicated the protection.