Yeah I also recall it sometimes corrupted something.
Anyway, I hope you have a good hex editor.
The first thing to try is to fill out the corrupted area with zeroes. Zero data byte means end of row in the file.
Then hope whatever is going to play it will stop when it has read 64 rows in a pattern, no matter how many bytes a packed pattern is said to be.
If that does not help, in addition you need to adjust the size of packed patterns to match 64 empty rows. Then it is easier to also zero out the whole pattern 51 as well so you zero out patterns 51, 52 and 53. These start at file offsets 0x6FB0, 0x7590, 0x7D00. So to these three offsets, you need to write packed pattern length (0x42, 0x00) because the length of 66 includes the two length bytes and 64 zeroes that are end of row markers. This is better, but there are now unused gaps in the file, some S3M loader might expect the next pattern starts after previous has completed.
But it just occured to me that maybe it would be simpler to just keep the corrupted area as it is now, and just edit the order table and headers to remove any reference to patterns 51, 52 and 53. There would still be surprising unused gaps where nothing in the file points to.
OK so I tried that. Replaced references to patterns with end of song markers (5 bytes) and then changed pattern data pointers to point to zero (6 bytes). Before the file did not load in MilkyTracker, now it does.
Here, have a try.