View Single Post
Old 11th March 2014, 03:17   #44  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by gpower2 View Post
First of all... wow! I never expected such a detailed post!
I do tend to ramble on a bit sometimes....

Quote:
Originally Posted by gpower2 View Post
I really tried to avoid popup and other "hidden" forms from showing up out of the blue. That's why I insist on leaving MKVToolnix location in the main form. Perhaps I will add a question when the user tries to alter the location, when it's already set, so that it will not get accidentally changed. I may also have forgotten to check for whether the user has pressed OK or Cancel, I'll also look into it.
I can think of a few programs which pop up to ask for the location of a particular utility and to me it seems to work pretty well. Foobar2000 for instance. The first time you use one of it's converter presets, such as converting to MP3, a window pops up asking where the LAME encoder resides. You navigate to the location once and never have to think about it again.

I checked and I was wrong. Sorry. If you select Cancel in the browse window the MKVToolNix location remains unchanged. I must have hit okay instead without thinking. However....
On my PC when you do select the Browse button, the browse window defaults to the desktop location. If instead it defaulted to the "already specified" location for MKVToolNix (for example "C:\Program Files\MKVToolnix") you could dismiss the browse window using either okay or cancel and nothing would change.

Quote:
Originally Posted by gpower2 View Post
This is the expected behavior, since Matroska does not keep the delays in the audio tracks. Mkvmerge simply rewrites the timestamps on the audio track and drops the delay. More on that here:
https://trac.bunkus.org/wiki/FAQ%3ADelayNotShownInMmg.
But extracted streams, once they're extracted, no longer have timestamps. In order to remux the extracted audio using the original timestamps you need to specify the appropriate audio delay when muxing. Either that or the timestamps should always be extracted along with the audio and used when remuxing it. From the page you linked to:

"Let's take an AC3 track for example. Those often have packets with a duration of 32ms. Now if you offset that by -40ms mkvmerge subtracts those 40ms from all timestamps. The very first two timestamps would then be at -40ms and -8ms; however, Matroska doesn't allow negative timestamps. Therefore the first two packets will be dropped. The new first packet is the old third packet at the new timestamp 24ms (old timestamp 64ms, subtract delay 40ms = 24ms). MediaInfo would then report a positive offset of 24ms."

So that's all good. You now have a file with a positive audio delay of 24ms, in human terminology, but what if you later extract the audio from that particular MKV, re-encode it (or whatever) and then remux it? For it to be muxed the same way as the original, a 24ms delay needs to be applied. Currently the only way to determine if a delay is needed is to check the original MKV using MediaInfo.
How MeGUI determines the delay when extracting I'm not sure. It may work it out from the timestamps or it may use the delay reported by MediaInfo.

It's pretty much the same logic behind DGIndex writing audio delays to the file names of extracted audio. When muxing it into an MKV/MP4/AVI, the way the muxing program handles the audio doesn't really matter, the correct audio delay still needs to be specified.

Last edited by hello_hello; 11th March 2014 at 03:29.
hello_hello is offline   Reply With Quote