MKVToolNix v24.0.0 released

[Mosu]

@Mosu thanks a lot...it looks like your site is down...
_

I know, but I don't know what the issue is yet. I'll try to get the server up and running again as soon as possible.

[Mosu]

The site is back up again.

[MrVideo]

Simple question...

Don't know if this has been previous mentioned somewhere, but is there a tool out there that will display the audio header compression setting? Is there an option within mkvmerge? Does MediaInfo display the setting?

[Zenitram]

A bit out of topic...

Don't know if this has been previous mentioned somewhere, but is there a tool out there that will display the audio header compression setting? Is there an option within mkvmerge? Does MediaInfo display the setting?

MediaInfo displays it:
Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Muxing mode : Header stripping
Codec ID : A_AC3
Duration : 59mn 29s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -28ms
Stream size : 163 MiB
Title : English AC3 5.1
Language : English

MediaInfo has its own Doom9 forum topic (http://forum.doom9.org/showthread.php?p=1513063)

[MrVideo]

Not exactly off topic, as the file is produced by mkvmerge. Even though MediaInfo does have its own thread, normal forum rules don't like the posting of the same question in multiple threads. Since the main subject of this question deals with mkvmerge output, I placed the question here.

That said, I really appreciate the response. Thanks.

[Mosu]

mkvinfo can display it as well. The information you're looking for is the ContentEncodings element. If it exists and contains a sub-sub element called "Algorithm" with a value of "3" then header removal compression is active.

[Merick]

I have a folder full dual audio files, whoever encoded these messed up the streams - they all show up as "undetermined" instead of jpn or eng. Is there any way I can batch process the entire folder to rename the streams without having to load them all into mvkmerg gui?

[robpdotcom]

Open mkvMergeGUI, then open the header editor (File > Header Editor). Drag the file into the editor and you will find options to assign a language and/or name the tracks. Once you make the changes, it only takes a second to save them - no need for re-muxing.

[MrVideo]

mkvinfo can display it as well. The information you're looking for is the ContentEncodings element. If it exists and contains a sub-sub element called "Algorithm" with a value of "3" then header removal compression is active.

Thanks for the info.

While looking at the files with MediaInfo, a couple of us saw the problem. The issue is that a person tries to play some mkv files on his TV, but the TV complains about an incompatible audio codec. We figured, at first, that it was the header compression issue, but none of the files had header compression.

What we noticed is the files not packaged with mkvmerge didn't work. They were marked as being done by x264 or unknown. Repackaging with mkvmerge fixed the problem.

[Mosu]

I have a folder full dual audio files, whoever encoded these messed up the streams - they all show up as "undetermined" instead of jpn or eng. Is there any way I can batch process the entire folder to rename the streams without having to load them all into mvkmerg gui?

Batch processing can be done easily with mkvpropedit and a little bit of scripting (e.g. with a shell or any scripting language you're comfortable with). Also see http://www.bunkus.org/videotools/mkvtoolnix/faq.html#batch_muxing_in_mmg

[Merick]

Thanks, this did it:

for %%X in (*.mkv) do c:\mkvtoolnix\mkvpropedit "%%X" --edit track:a1 --set flag-default=0 --set language=eng --edit track:a2 --set flag-default=1 --set language=jpn

[Thunderbolt8]

has there been any change recently in regards of tag(.xml) files?

I tried to add a tag xml file to my mux, together with a chapter xml file, but the tags are not to be found in the output.

edit: I guess the value for <EditionUID> must be the same in both files?

[Mosu]

Nothing has changed regarding tag handling. Yes, the EdititonUID must be the same if you want the chapter editions to be merged.

[Thunderbolt8]

that was which was wrong then. nvm -.-

[banzemanga]

Are the sequence headers mentioned on this thread (http://forum.doom9.org/showthread.php?t=128768) still being removed for AVC/h.264?

I try muxing raw AVC/h.264 files into MKV container using mkvmerge and when i demux it, it get a smaller raw video file. I can only think that the sequence headers mentioned before are still being removed. Note that i mux my MKV files with the "--compression 'none'" trigger so there should be no headers removed due to compression artifacts.

[Video Dude]

I had the same question regarding this post:

Yes, mkvmerge removes the sequence headers and stores the first ones that it finds in the CodecPrivate. Yes, I know that this a problem with changing sequence headers in the middle of the stream, and yes, I plan to change that someday. That being said, I don't spend any time coding mkvtoolnix at the moment, so your guess is as good as mine when mkvmerge will handle such streams correctly.

Does mkvmerge still remove the sequence headers?

[Mosu]

Nothing has changed.

[sneaker_ger]

What else does mkvmerge change?

Here's a sample:
https://rapidshare.com/files/384744953/iterations.7z

I muxed and demuxed a source a few times and all resulting raws differed from each other. ( source.h264 -> 1.mkv -> 1.h264 -> 2.mkv -> 2.h264 -> .... -> 5.h264 )

[Mosu]

Sorry, I don't have the time or motivation to investigate.

[Chetwood]

I will add such an option in the near future though so that you don't have to edit the source files with the chapter editor before appending them.
Speaking of which, when merging demuxed streams from 2 BDs, how do I append the chapter file of the second BD so that the MKV has all chapters from both discs in proper order? I'm trying to merge the two LOTR-Extended Edition BDs to test how my standalones handle huge files of 70 GB. Thx.

[Mosu]

One way would be to merge each BD separately (including chapters) into its own Matroska file. Then append the two Matroska file into the resulting file. That way mkvmerge will adjust the chapters of the second one automatically. Other than that you'll probably have to edit the chapter files manually.

[Chetwood]

I was afraid you were gonna say that ;) I'm gonna try both methods but I'm wondering what's the difference here cause MKVToolnix already is capable of doing both:

1) appending demuxed streams (.264, .dts, .idx, .sup, etc.) and
2) appending 2 chapter files (when muxed to mkv containers)

So how come, I can't do both, given the chapter files already are present in Matroska Chapter XML file format? Thanks again.

[Mosu]

Because a XML chapter file is not an input file but can only be used with the "--chapters" option.

However, you could try something similar:

1. Create two Matroska files that only contain chapters.
2. Append everthing, e.g. mkvmerge -o out.mkv part1.h264 + part2.h264 part1.dts + part2.dts chapters-part1.mkv + chapters-part2.mkv

Maybe this will work, too.

[Chetwood]

OK, I'm doing baby steps to see how far I get. For starters, I extracted the last chapter of disc 1 and the first of disc 2 with DVDFab and demuxed with TSMuxerGI. Since both have the same amount of streams, appending them with MKVToolnix worked fine. However, when the MKV reaches the disc 2 part, audio and video are out of sync. Muxing only the streams from disc 2, everything is in sync so I guess, MKVToolnix somehow introduces a delay while appending. Any suggestions?

[Mosu]

part1.h264 part1.dts part1.idx part1.xml > part1.mkv
part2.h264 part2.dts part2.idx part2.xml > part2.mkv

part1.mkv + part2.mkv > final.mkv

[Chetwood]

Despite these error messages

Warning: The track number 1 from the file 'D:\2.mkv' can probably not be appended correctly to the track number 1
from the file 'D:\1.mkv':
The codec's private data does not match. Both have the same length (69) but different content.
Warning: The track number 2 from the file 'D:\2.mkv' can probably not be appended correctly to the track number 2
from the file 'D:\1.mkv':
Warning: The track number 3 from the file 'D:\2.mkv' can probably not be appended correctly to the track number 3
from the file 'D:\1.mkv':

Please make sure that the resulting file plays correctly the whole time.
The author of this program will probably not give support for playback issues with the resulting file.
appending apparently worked fine. Gonna try it on the entire movie. Thx.

[NanoBot]

Hi,

Speaking of which, when merging demuxed streams from 2 BDs, how do I append the chapter file of the second BD so that the MKV has all chapters from both discs in proper order? I'm trying to merge the two LOTR-Extended Edition BDs to test how my standalones handle huge files of 70 GB. Thx.

This post primarly does not have something to do with mkvtoolnix, but since I am doing the same thing just ATM like Chetwood one advice from me:

Be aware of the fact that the video track and the audio tracks of the first BDs, at least from "The Fellowship of the ring" and "The two towers", do not have the same playtime. I can't speak about "The return of the king", because I don't have demuxxed those BDs yet. After decoding the audiotracks from DTS-MA to wavs, since I am reencoding them to 5.1 flac, I found the following playtimes:

On the first BD of "The fellowship", the playtime of the video track is 1:45:43.421, while the playtime of the audiotracks is only 1:45:42:336. Therefore you need to add 1085ms of silence to the end of the audiotracks before merging with the second BD, otherwise the audio will be out of sync from the start of the second part.

The same problem applies to "The two towers", here the videotrack of the first BD has a playtime of 1:46:39.185, while the audio is a few 100ms longer. I can't remember the exact audio playtime anymore, since I already successfully created the 5.1 flac and therefore already deleted the wav-files. Nevertheless, with this BD you need to shorten the audiotracks by cutting away a few 100 ms at the end to get a playtime of 1:46:39.185.

It is likely that a playtime correction of the audio tracks of the first BD will also be neccessary when concenating the two parts of "The return of the king".

A little bit more off topic: Does anyone had a look into a wav-file of the german BC track from "The two towers" ? This one looks really borked to me, while the english BC looks ok. I really wonder what kind of quality assurance, if any, the producers of these bluray set have. First, they had the problem with the wrong pitch of the german audio track, and now, on the "corrected" version, the german BC is borked.

C.U. NanoBot

[Chetwood]

This post primarly does not have something to do with mkvtoolnix
Maybe a mod can move these posts over to a new thread in 'Advanced authoring' or something.

Be aware of the fact that the video track and the audio tracks of the first BDs, at least from "The Fellowship of the ring" and "The two towers", do not have the same playtime.
Thanks, I hadn't realized this so far but I guess that's where my error messages came from.

It is likely that a playtime correction of the audio tracks of the first BD will also be neccessary when concenating the two parts of "The return of the king".
Well, I did as Mosu suggested and despite the error messages and no dealy being added, the tracks were completely in sync.

First, they had the problem with the wrong pitch of the german audio track, and now, on the "corrected" version, the german BC is borked.
BC? I was planning on watching the entire movies once I was finished encoding. I really did not expect them to screw it up again. BTW, why did you go for FLAC?

[NanoBot]

BC = Back center, and my statement that the german BC is "borked" is due to the fact, that this channel has a vague, but constant noise at a DC offset of about -66dB in the "positive" sample area throughout both BDs of the "Two towers". "The fellowship of the ring" and "The return the king" do not have this error, here all audio tracks are "clean". If you want to have a look into it, just decode the german DTS-MA track to wavs ( using eac3to together with the arcsoft decoder ) and load the german BC into audacity.

Fortunately, the level of this noise is so weak that you will barely notice it when not listening to the german BC only using a headphone, but looking at the decoded wav shows this constant noise. My best guess is that the producer of the german audio tracks used some kind of equipment with a defective capacitator in it, because that would result in the noise and dc offset I have found. But after my understanding of a quality assurance, such errors should be found and corrected during the authoring and production process before sending the masters to the BD pressing plant.

I have two reasons why I am reencondig to flac: Flac is patent free and a flac file is approximately 20% smaller than a DTS-MA file. Therefore I always reencode lossless formats to flac when remuxxing BDs to Matroska.

[Thunderbolt8]

merging lotr works best using eac3to

eac3to part1.m2ts+part2.m2ts and then all usual options etc.

fixes audio automatically so you get 1 big file for video and another for audio which are both in sync with each other.

after that just mux them together with mkvtoolnix

the new german BD is supposed to be fine btw.

[sneaker_ger]

the error messages and no dealy being added, the tracks were completely in sync.

When appending two mkv files, mkvmerge will make sure that the sync is not lost by default. But there will be gaps in all tracks but the longest of part 1.

There's also "--append-mode track", where there are no gap, but you have to manually edit them first like suggested by NanoBot to make sure sync is not lost. That also goes for appending the raw tracks, instead of creating intermediate mkv files like suggested by Mosu.

[Chetwood]

I've done it now as Mosu suggested
part1.h264 part1.dts part1.idx part1.xml > part1.mkv
part2.h264 part2.dts part2.idx part2.xml > part2.mkv

part1.mkv + part2.mkv > final.mkv
for the entire first movie rather than 2 chapters using mmg.exe (i.e. the GUI) under Win and without any extra tricks. Video, audio and subs are in sync during the course of the entire movie! BUT chapters are off by a longshot. Curiously enough only those of disc 1! As soon as the first scene of disc 2 starts, all chapters are fine.:confused:

[mindbomb]

were there improvements made to the zlib compression? i just compressed some subtitles to less than half their original size. Is this typical? I don't recall it being so potent.

[Mosu]

were there improvements made to the zlib compression? i just compressed some subtitles to less than half their original size. Is this typical? I don't recall it being so potent.

No. Subtitles just happen to contain a lot of redundancy that any compressing algorithm is very happy about.

[Lincoln Burrows]

When are you going to add support for the FLV format? Or it's not possible to append FLV files using the MKV container? *

* Edit: Just found a way of doing that:

http://forum.doom9.org/showpost.php?p=1519867&postcount=13

It seems to be working and now I can append the generated MKV files.

[Mosu]

FLV support is in the works from a third party that also created a TS demuxer. Both need considerable work though.

Also: FLV support will most likely be limited to h264 video and AAC audio (maybe other audio types as well); definitely not the older FLV files with h263 video.

[Chumbo]

There are some FLV tools available here: http://www.moitah.net/
You should be able to use the extract tool to get the elementary streams and then mux them to MKV.

[sneaker_ger]

"--engage remove_bitstream_ar_info" seems to be broken (i.e. does nothing, AR is still kept) atm - can anyone confirm?
Would be nice if mkvmerge would change the AR (although I guess you are probably against this, like you were very reluctant to keep the AR info since you consider container > bitstream info, which I agree with.)

[Mosu]

It's possible that some operations (e.g. h264 read from Matroska files if the codec ID is "V_MPEG4/ISO/AVC") don't go through the code path at all that reacts to "--engage remove_bitstream_ar_info". It should work every time a "raw" ES has to be converted to the Matroska way of storing the info; e.g. if it is read from a raw .h264 file, from an AVI, from an MPEG program stream or from a Matroska file that stores the AVC track in MS compatibility mode (codec ID "V_MS/VFW/FOURCC" with FourCC "AVC1").

[Mosu]

Oh, and my long term goal is to always make the bitstream information match the container information regarding both the aspect ratio and the FPS/default duration. But as I'm trying to get the MPEG transport stream support working passably well this is a bit on the back-burner.

My current priority list, in case anyone is interested: basic MPEG TS support; basic FLV support; bugs 434 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=434), 654 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=654) (which both have to do with h264 tracks and timing information; I will take care of AR information in the bitstream at the same time I guess); bug 652 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=652). Not necessarily in that order.

[sneaker_ger]

Those plans sound very good.
And yes, I was using an mkv source. ES seems to work. Thx, I didn't think of that.

[robpdotcom]

Those plans sound very good.

Agreed, especially the TS support. BTW: Does TS support also mean M2TS support?

[Mosu]

Agreed, especially the TS support. BTW: Does TS support also mean M2TS support?

They're the same, yes.

[sneaker_ger]

There's also a CFR/VFR info in H.264 tracks, would be nice if those were set correctly, too, when you find the time to work on these. (i.e. CFR for --default-duration and VFR for timecode file input.)

[Chumbo]

They're the same, yes.
Thanks Mosu, this is great news. :)

[robpdotcom]

Great new indeed. I'm looking forward to loading the M2TS files from a disc, and muxing them straight into an mkv.

I don't guess it'll be able to open seamless branching playlists, but maybe we could append them manually?

[nautilus7]

mosu,

Can you have a look into this sample (http://www.mediafire.com/?3bedr69hrjlh5r2)? It's from BBC's documentary "Yellowstone" (1080i 60/1.001fps frame blended from 25fps original source to fit blu-ray specs).
What is the proper fps to mux it with? I believe 30/1.001 as it has 29,97 frames per sec. But then it plays back with half speed. If I select 60/1.001 it 's ok.

[Mosu]

You've given yourself the correct answer already. Just use what works.

[nautilus7]

So, for interlaced content I have to put the fps based the number of fields but for progressive I put the fps based on number of frames? That's inconsistent imho.

[Mosu]

That's how it is, at the moment, yes. mkvmerge uses the "--default-duration" parameter for setting the duration for each "packet" output, and for interlaced content that's one field and not one frame. For audio it also has nothing to do with "...per second"; ok you don't usually use "--default-duration" for audio tracks. The input field in the GUI is only labeled "FPS" because people are used to that term.