I'm not sure why. If you're on a 64 bit Windows MeGUI is probably using avs4x26x.exe to send the video to the encoder, so maybe that's the problem. Some guesses:
It could be an avs4x26x.exe issue because it's not used on 32 bit Windows (I'm running XP), although when I ran a test, the encoder kept rejecting the timecodes file. Eventually I discovered it's not happy with "# timestamp format v2" at the top of the timecodes file. When I changed it to "# timecode format v2" it was accepted, so you probably should try that first.
It seems MKVToolNix will accept timecodes with either heading, so maybe at some stage it was officially changed from "timecode" to "timestamp" to annoy everyone.
If that doesn't help, remux your MKV while adding --timecode-scale -1 to the MKVToolNix command line. When you extract them, instead of looking like this:
# timestamp format v2
0
40
80
They might look like this:
# timestamp format v2
0
39.99744
79.99488
See if that helps.
If you can get the encoder to accept the timecodes file you might have to specify a timebase manually. I don't fully understand how the timebase works, but as a test I fed the encoder timecodes from a CFR 23.976fps MKV (accurate to 1ms) and the result was:
timecode [info]: automatic timebase generation 1/1000000000
So try adding --timebase 1/1000000000 to the custom command line along with the timecodes file if the encoder won't automatically generate one. Maybe someone who understands how the timebase works will come along and explain it.
I'll confess I haven't used v2 timecodes that way for quite a while. I generally convert NTSC DVDs with TIVTC generating timecodes, and it uses the original format, which has never been a problem for me.
# timecode format v1
Assume 54.940030
3735, 8034, 23.976024
8965, 9439, 23.976024
This *&*^ should be easy!!! That'll teach me for saying it is.
