hello_hello
25th March 2012, 19:50
Tag in "foobar encoded aac.m4a":
00000000 00000A40 000001C0 0000000000140400 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Delay = A40 = 2624 = 55ms (0,054666... s)
Original length = 1311744 = 27.328s
Padding = 1C0 = 448 = 9ms
Checking the length of "original sample dts.mkv": 27.328s (=correct!)
Checking length of "sample aac remuxed.mkv": 27.392s (wtf?)
Remuxing audio of "foobar encoded aac.m4a" and video of "original sample dts.mkv" to "reremux.mkv". Length = 27.337s = 27.328s + 9ms = original length + padding (as expected)
Comparing waveform of "reremux.mkv" and "original sample dts.mkv": no extra delay (as expected)
Comparing waveform of "sample aac remuxed.mkv" and "original sample dts.mkv": delayed by 55ms
So I take you manually entered "55ms" into the delay field of mmg instead of letting it do its work?
If you're still around sneaker_ger I think I found the problem. &$%^%$!! Despite not having found the motivation to do any further experimenting.....
However I was reading through the MKVMerge changelog looking for something else today. At the time I made those samples (8th March) I was running version 5.2.1. (I mentioned it in post #22).
Anyway if I'm reading the change-log correctly the compensation for MP4/AAC audio delay wasn't included until version 5.3.0, which I think was the latest version at the time (release data for 5.4.0 says 10th March) and because you said "newer versions of mkvmerge read and apply the AAC audio delay" I seem to have incorrectly included the version I was using in that category. &*^&%$!!!
I assume from reading your above calculations again the 55ms encoder delay simply wasn't being compensated for by the version of MKVMerge I was using. *&%%^!!
Oh well.... at least I can use MediaInfo to work out which version of MKVMerge I was using when muxing older MKVs, so one day I might get motivated to remux all the AAC files with a -50ms delay, which is pretty much what I worked out would be required earlier in the thread (post #20). Although it shouldn't be too hard. I upgraded from 5.2.1 to 5.4.0 on 11th March, so it's pretty much any video with AAC audio I've encoded prior to that date. &^&%$%!!!
00000000 00000A40 000001C0 0000000000140400 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Delay = A40 = 2624 = 55ms (0,054666... s)
Original length = 1311744 = 27.328s
Padding = 1C0 = 448 = 9ms
Checking the length of "original sample dts.mkv": 27.328s (=correct!)
Checking length of "sample aac remuxed.mkv": 27.392s (wtf?)
Remuxing audio of "foobar encoded aac.m4a" and video of "original sample dts.mkv" to "reremux.mkv". Length = 27.337s = 27.328s + 9ms = original length + padding (as expected)
Comparing waveform of "reremux.mkv" and "original sample dts.mkv": no extra delay (as expected)
Comparing waveform of "sample aac remuxed.mkv" and "original sample dts.mkv": delayed by 55ms
So I take you manually entered "55ms" into the delay field of mmg instead of letting it do its work?
If you're still around sneaker_ger I think I found the problem. &$%^%$!! Despite not having found the motivation to do any further experimenting.....
However I was reading through the MKVMerge changelog looking for something else today. At the time I made those samples (8th March) I was running version 5.2.1. (I mentioned it in post #22).
Anyway if I'm reading the change-log correctly the compensation for MP4/AAC audio delay wasn't included until version 5.3.0, which I think was the latest version at the time (release data for 5.4.0 says 10th March) and because you said "newer versions of mkvmerge read and apply the AAC audio delay" I seem to have incorrectly included the version I was using in that category. &*^&%$!!!
I assume from reading your above calculations again the 55ms encoder delay simply wasn't being compensated for by the version of MKVMerge I was using. *&%%^!!
Oh well.... at least I can use MediaInfo to work out which version of MKVMerge I was using when muxing older MKVs, so one day I might get motivated to remux all the AAC files with a -50ms delay, which is pretty much what I worked out would be required earlier in the thread (post #20). Although it shouldn't be too hard. I upgraded from 5.2.1 to 5.4.0 on 11th March, so it's pretty much any video with AAC audio I've encoded prior to that date. &^&%$%!!!