It sounds like you have basic disc protection working (Lotus Turbo Challenge - Daniel Simms X Lock), but need a few further tweaks for the more complex methods.
If you look at the link above Magic Pockets doesn't have duplicate sectors, it uses the "R.A. North" protection which is also used by Zarch. That has the following structure:
Magic Pockets (12) - Track 105, sector 1 bad CRC - Track 107, sector 1 bad CRC - Track 109, sector 1 bad CRC - Track 110, sector 1 bad CRC - Track 158, 4 x 512 byte sectors 240, 241, 242, 243 - Track 158 is SD - Track 158, sector 241 bad CRC and nested sector - Track 158, sector 242 - Track 158, sector 243 bad CRC - Track 159, no sectors
When loading the game performs the following:
Reads: <bytes> from <sector addr> ([byte addr]) - <track>.<sector> (<log2secsize>, <secspertrk>, <heads>, <density>, [disc size in bytes]) Reads: &200 from &9B3C (&1367800) - 158.240 (9, 250, 2, 1, &1388000) Reads: &200 from &9D3E (&1367C00) - 158.242 (9, 250, 2, 1, &1388000) Reads: &200 from &9B3C (&1367800) - 158.240 (9, 250, 2, 2, &1388000) Reads: &200 from &9D3E (&1367C00) - 158.242 (9, 250, 2, 2, &1388000)
So it's reading sector 240 and 242 from track 158 twice - once as Single Density and then again as Double Density. As the track is SD, the first two reads should succeed and the second two will probably return an error - hence the additional duplicated sector in the JFD file.
For some of the more complex methods, I wonder if you might be better off replaying the recording file against the JFD as you'll be able to interpret the output with more information to hand. The recording file explicitly marks duplicate sectors for example and details the type of DiscOp3 response for Gordian Lock (Fire & Ice) and general track reads (Slappit)