my question here is…is there a provision within the program to NOT have the program auto sync the video stream to the audio stream when one is running the program to mux the two streams BACK into the mkv container?…instead take a dumb approach & mux both streams together as they present themselves?
my issue is this..when I am processing a given movie/tv show/live recorded event & I have to edit the audio for volume/channel mix/separation I demux the audio stream, convert all channels back into wav….after the editing has completed I re-encode the audio back into either EAC3 or DTS ….& when I remux the revised audio back into the container with the video mkvmerge will *on it’s own* resync the the two to where IT wants the audio to begin. Doing this is throwing the audio out of sync by -200 milliseconds (2 tenths of a second). I have to run the program a second time & adjust the audio delay to remove that -200 to properly sync the two streams. Why is the program doing this & how does one adjust the program (permanently) to get around this?
mkvmerge can only keep multiple tracks (type doesn’t matter, applies to all audio/video/subs) in-sync when all tracks are read from the same source file. Otherwise there is simply no cross-file timestamp information for it to do the sync.
Therefore extracting one of the tracks loses that information, and you cannot add it back safe for manully tweaking the sync settings, as you seem to be doing.
It is taking the “dumb approach” (your words) in such a case.
For example, let’s assume you have a source file (let’s call it example-both.mkv) with one video & one audio track. The video track starts (has its first frame/packet) at 0ms whereas the audio track has its first packet at 80ms.
Now you extract the audio track into example-audio-only.aac . If you feed example-audio-only.aac` back into mkvmerge it’ll see the first audio packet now starting at 0ms.
If you then take only the video from example-both.mkv & mux that with the audio from example-audio-only.aac you now have both tracks starting at 0ms in the resulting file as a) that’s where they both start in their respective source files & b) there’s no way to auto-guess that example-audio-only.aac really contains the audio from example-both.mkv. Even if there were, due to you editing & re-encoding there simply is no way to reuse the timestamp information present for the audio track in example-both.mkv when muxing the modified audio from somewhere else.