MKV demux issue...

Dreamhacker · 12th July 2009, 23:03

Alright... This issue bugs me a bit...

I have a MKV file, which contains H.264 video and AAC audio.

But after I demux the MKV, the length of the video and audio file has about 3 minutes difference.

The video file consist of 33 088 frames, plays 23.976 fps and lasts 23:00 minutes.
The audio file lasts 26:42.

During the demux I also get timecode for the audio-track, though I do not know of any way to sync audio according to this timecode.

Any help?

PS: Dunno if this belongs in the audio-section or container-section of the forums.

Inspector.Gadget · 12th July 2009, 23:28

Timecodes are used to represent where video and audio samples are stored in an MKV container. Given a video stream, audio stream, and timecodes, you can sync them in a new MKV container without much manual intervention. That said, just re-encode from the original source. No point hunting through a dozen applications which may not report accurate lengths when you can begin from a known good point.

Dreamhacker · 12th July 2009, 23:31

Okay... Now I took the AAC file supplied from the demux, ran it through dBpoweramp, resulting in a Nero m4a file with length... 23:00.

So, now I wonder... Why did the length change with 3 minutes through that conversion?

Dreamhacker · 13th July 2009, 11:01

Quote:

Originally Posted by Inspector.Gadget

Timecodes are used to represent where video and audio samples are stored in an MKV container. Given a video stream, audio stream, and timecodes, you can sync them in a new MKV container without much manual intervention. That said, just re-encode from the original source. No point hunting through a dozen applications which may not report accurate lengths when you can begin from a known good point.

I know this. I'm more curious to why it happens. I'm the kind of person that needs to know reasons, or else it's gonna bug my mind forever.

roozhou · 13th July 2009, 13:14

What tool did you use to demux the mkv?

Inspector.Gadget · 13th July 2009, 15:13

Dreamhacker, use MediaInfo to figure out whether you demuxed the audio into a raw AAC file or into an MP4 container. Some apps have problems reporting the correct length of raw AAC files. It wasn't >4 GB in size, was it? Also, be aware of CFR vs. VFR for the video, which will affect how apps perceive its total length once demuxed and treated with an app that only recognizes CFR. How did you encode the file, and how did you demux it?

Dreamhacker · 14th July 2009, 00:21

I demuxed the MKV with MKVToolnix/MKVExtractGUI. The result was a .h264 and .aac file. I checked if the h264 was VFR by running mkv2vfr from the Haali package, it was not. So, I tried playing the .aac file in WMP, as Windows 7 doesn't show any media-info for the file in properties. It reported a length of 26:42 minutes, which was longer than the video, though the audio seemed to cut off at 23:00, where it should end.

Seemed to work fine when I re-encoded/re-muxed (dunno what exactly dBpoweramp does of those in this case) the aac to m4a, it was read with a length of 23:00.

Isn't the length of the audio-file supposed to be stored in the file header? If so, how can the applications even get that wrong to begin with?

Guest · 14th July 2009, 02:37

Quote:

Originally Posted by Dreamhacker

I checked if the h264 was VFR by running mkv2vfr from the Haali package, it was not.

That means you didn't encode it yourself. Therefore, thread closed for rule 6. Further violations will lead to strikes.

12th July 2009, 23:03	#1 \| Link
Dreamhacker Registered User Join Date: Dec 2004 Posts: 64	MKV demux issue... Alright... This issue bugs me a bit... I have a MKV file, which contains H.264 video and AAC audio. But after I demux the MKV, the length of the video and audio file has about 3 minutes difference. The video file consist of 33 088 frames, plays 23.976 fps and lasts 23:00 minutes. The audio file lasts 26:42. During the demux I also get timecode for the audio-track, though I do not know of any way to sync audio according to this timecode. Any help? PS: Dunno if this belongs in the audio-section or container-section of the forums.

12th July 2009, 23:28	#2 \| Link
Inspector.Gadget Registered User Join Date: May 2008 Posts: 1,618	Timecodes are used to represent where video and audio samples are stored in an MKV container. Given a video stream, audio stream, and timecodes, you can sync them in a new MKV container without much manual intervention. That said, just re-encode from the original source. No point hunting through a dozen applications which may not report accurate lengths when you can begin from a known good point.

12th July 2009, 23:31	#3 \| Link
Dreamhacker Registered User Join Date: Dec 2004 Posts: 64	Okay... Now I took the AAC file supplied from the demux, ran it through dBpoweramp, resulting in a Nero m4a file with length... 23:00. So, now I wonder... Why did the length change with 3 minutes through that conversion?

13th July 2009, 13:14	#5 \| Link
roozhou Registered User Join Date: Apr 2008 Posts: 1,181	What tool did you use to demux the mkv?

13th July 2009, 15:13	#6 \| Link
Inspector.Gadget Registered User Join Date: May 2008 Posts: 1,618	Dreamhacker, use MediaInfo to figure out whether you demuxed the audio into a raw AAC file or into an MP4 container. Some apps have problems reporting the correct length of raw AAC files. It wasn't >4 GB in size, was it? Also, be aware of CFR vs. VFR for the video, which will affect how apps perceive its total length once demuxed and treated with an app that only recognizes CFR. How did you encode the file, and how did you demux it?

14th July 2009, 00:21	#7 \| Link
Dreamhacker Registered User Join Date: Dec 2004 Posts: 64	I demuxed the MKV with MKVToolnix/MKVExtractGUI. The result was a .h264 and .aac file. I checked if the h264 was VFR by running mkv2vfr from the Haali package, it was not. So, I tried playing the .aac file in WMP, as Windows 7 doesn't show any media-info for the file in properties. It reported a length of 26:42 minutes, which was longer than the video, though the audio seemed to cut off at 23:00, where it should end. Seemed to work fine when I re-encoded/re-muxed (dunno what exactly dBpoweramp does of those in this case) the aac to m4a, it was read with a length of 23:00. Isn't the length of the audio-file supposed to be stored in the file header? If so, how can the applications even get that wrong to begin with?