Yeah, I'd try the pattern I suggested earlier.
TDecimate(Cycle=111, CycleR=11)
TDecimate also has Mode=7. You specify the desired frame rate and TDecimate will remove duplicates to get you there. Trouble is, if it's not the correct frame rate it'll still leave duplicates behind or sometimes remove non-duplicates. I'd try 27000.0/1001.0 to begin with, as that's what 1-in-10 decimation gives you.
You could also try
dedup. Normally it outputs a timecodes file for VFR encoding, but you might be able to slow the video to 24fps after they're removed instead, and slow the audio to match.
The only thing that might prevent audio time correction from working is if the duplicate frame pattern is very irregular and you don't use M-in-N decimation, or maybe M-in-N decimation with a huge frame cycle. For M-in-N decimation such as 2 in 20, you're always left with 18 frames spread out over the same time period as the original group of 20, and each cycle of frames could be looked at as a reset for the audio sync. As long as you use the frame rate after decimation as the denominator for AudioSpeed (do you check with Info()?), and the AssumeFPS frame rate for the numerator, the A/V sync should be fine.
If after decimation, you check the A/V sync with the original audio and they're in sync (before AssimeFPS), time stretching both by the same amount won't change that. If they're already out of sync it can only be because the duplicate frames were in a such un-even pattern, removing them caused the video to lose sync with the audio, and time stretching both can't fix that.