Impossible flux sequence for FM encoding?

[RebeccaPhu]

I humbly seek knowledge from the assembled masses.

If you remember, I'm trying to integrate GreaseWeazle directly into my retro filing system processor program. Having interrogated usb.py I've got the serial protocol up and running; selecting drive, seeking to track 0, and even reading a flux stream.

After porting _decode_flux from usb.py, I have a track's worth of flux data. If I understand right, the first list is ticks since index pulse, and the second list is time between flux transitions measured in ticks. At this point, the length of a "tick" doesn't matter, as long as it's consistent. All good.

So now I'm trying to interpret those flux transitions according to FM encoding, and I'm missing some vital knowledge that my Google-Fu is refusing to surrender.

Everything I've read says that a 1 is two short "pulses" (= short time between flux transitions) and a 0 is one long pulse. According to the IBM format, there should be a bunch of FF bytes (lots of short pulses) followed by some 0 bytes (lots of long pulses) representing a "gap" and "sync".

But in the middle of my long pulses, I have 3 short pulses, and a group of 5 short pulses, which as far as I can tell, should be impossible. I've compared this with the gw tools outputting to SCP - I can see the same pulse set in the SCP image. Conversely, if I ask gw to process the data into a known format (in this case acorn.dfs.ss), perfect data.

This is not only consistent in different reads of the same disk, but between different disks of the same format.

What am I missing here?!?