CarlEdman
25th July 2016, 14:27
I am remuxing a MKV I have to MP4. That is, I start by mkvextract-ing all the tracks from the MKV, then I do some transcoding, and finally I remux the trancoded parts as MP4.
Today I encountered a somewhat unusual problem with one AC3 track. The original MKV played fine. The remuxed MP4 started playing fine, but at one point--not coincidentally, I assume, a chapter break--the audio badly jumps out of sync and stays that way for the rest of the file.
So I extracted the time-codes for the AC3 track from the original MKV file and indeed, while almost all had the usual spacing of 32ms, two of them did not. There was a jump of 0.512s at 868.576s and another jump of 0.507s at the timecode at 1778.235s.
As the former timecode exactly matches where the audio goes out of sync the first time, I am confident this is the source of the problem. However, I am somewhat at a loss of how to fix it.
Did mkvextract-ing the AC3 (a format for which I do not have good analytical tools) garble the time-codes? Or transcoding from AC3 using EAC3TO fail to honor the time-codes? Or does AC3 not contain time-codes at all and mkvextract just doesn't include that information? In either case, is there a way to make sure this gets handled automatically and correctly?
Even if there is not, can anyone advice me on how to patch the output of eac3to using the above information to get a correct wav? The -edit and -silence options look like they could do what I want, but they are not very well documented.
Thanks!
Today I encountered a somewhat unusual problem with one AC3 track. The original MKV played fine. The remuxed MP4 started playing fine, but at one point--not coincidentally, I assume, a chapter break--the audio badly jumps out of sync and stays that way for the rest of the file.
So I extracted the time-codes for the AC3 track from the original MKV file and indeed, while almost all had the usual spacing of 32ms, two of them did not. There was a jump of 0.512s at 868.576s and another jump of 0.507s at the timecode at 1778.235s.
As the former timecode exactly matches where the audio goes out of sync the first time, I am confident this is the source of the problem. However, I am somewhat at a loss of how to fix it.
Did mkvextract-ing the AC3 (a format for which I do not have good analytical tools) garble the time-codes? Or transcoding from AC3 using EAC3TO fail to honor the time-codes? Or does AC3 not contain time-codes at all and mkvextract just doesn't include that information? In either case, is there a way to make sure this gets handled automatically and correctly?
Even if there is not, can anyone advice me on how to patch the output of eac3to using the above information to get a correct wav? The -edit and -silence options look like they could do what I want, but they are not very well documented.
Thanks!