1) The correct way to handle this is to do the split in libopusenc. This will be gapless and glitchless. Everything else is going to be some kind of workaround that can still fail for pathological samples.
2) The signal in this file behaves badly in digital filters when they assume the signal before/after they operate is 0 (this is the default). To prevent this, you need to extend the signal, for example with a simple LPC predictor. Opus does this for the *end* of files, but not at the start. (https://github.com/xiph/libopusenc/blob/master/src/opusenc.c#L1147) I confirmed by mixing the Vorbis and Opus encodes that it's the start of the second file that glitches, not the end of the first one.
3) This needs to happen in both the resampler and the encoder. Easiest would be to have the resampler always do it, and feed the extended output to the encoder.
4) Vorbis implements it also for the start of files (https://github.com/xiph/vorbis/blob/ea8b03fce93444cb3cf0131909e15b4f8856e863/lib/block.c#L416) which is why it behaves so well here. (And obviously it can't fail at the resampling step).
This application has requested the Runtime to terminate it in an unusual way.Windows 7 32 bit, core i3 3245
Please contact the application's support team for more information.
LAME 3.100 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
polyphase lowpass filter disabled
Encoding D:\Music\I Love Disco Diamonds Collection\I Love Disco Diamonds Collection Vol. 14\02. Yeti.wav
to D:\Music\I Love Disco Diamonds Collection\I Love Disco Diamonds Collection Vol. 14\02. Yeti.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=0)
File: ../../libmp3lame/vbrquantize.c, Line 948
Expression: vbrsf[sfb] >= vbrsfmin[sfb]
File is too long to share here, but if someone is interested, i can send link in PM. It is track #2 from CD #14 from compilation "I Love Disco Diamonds Collection"
Pre-resampling everything with Sox doesn't change the result. So it's not a resampler issue.
Actually, it turns out that the resampled files have this glitch *before* encoding to Opus. So this isn't an opus codec problem, it's bad behavior of the resampling in both opus-tools and sox.
[Edit] The latest preview cumulative update is in fact 17763.292.