MKVToolNix v24.0.0 released

[DragonQ]

I always set video tracks to English if that's what's being spoken by the actors. For example, if a film is natively English but you're watching a version with French dubbing then I would say it makes sense to set the video track to English and the audio track to French.

I kinda assumed it made no difference but I'm a completist. :)

[nevcairiel]

Unless the video has burned-in forced subtitles or other image captions, its really more language neutral.... :)

[Mosu]

Well, it might make sense for hearing-impaired people who can read lips. Though I guess that might be a very small minority :)

[hubblec4]

hi Mosu

i have used a chapter.xml with a special command from the mkv specs: <ChapProcessCodecID>

mmg shows this error.

Error: Chapter parser failed for '***\kap 2Editions-test.xml', line 3, column 0: <ChapProcessCodecID> is not a valid child element of <Chapters>.


this is the line from the xml: <ChapProcessCodecID>0</ChapProcessCodecID>
is it worng or is this type not supported by mmg/mkvmerge?

[b66pak]

i have noticed that h264 raw with no fps info is muxed by default to 25fps without any warning...may be reverting to the old "no fps info" warning will be a good ideea for this kind of special case...not everybody is aware of what is muxing and this situation could lead to out of sync av...
_

[Mosu]

hi Mosu

i have used a chapter.xml with a special command from the mkv specs: <ChapProcessCodecID>

The names used by mkvmerge do not always match the specs. Instead, they mostly match libmatroska. For all chapter related elements the names start with "Chapter" and not "Chap", hence <ChapterProcessCodecID>.

[Mosu]

i have noticed that h264 raw with no fps info is muxed by default to 25fps without any warning...may be reverting to the old "no fps info" warning will be a good ideea for this kind of special case...not everybody is aware of what is muxing and this situation could lead to out of sync av...
_

Yeah well, maybe I'll implement such a warning one day. Maybe not.

[hubblec4]

The names used by mkvmerge do not always match the specs. Instead, they mostly match libmatroska. For all chapter related elements the names start with "Chapter" and not "Chap", hence <ChapterProcessCodecID>.

i tested it with "ChapterProcess", but it fails too.

the ChapProcess is a subcommand of the Chapter entry.

my xml-file started with <Chapters>

it looks like so:

<Chapters>
<ChapProcess>
<ChapProcessCodecID>0</ChapProcessCodecID>
<GotoAndPlay>1111100000</GotoAndPlay>
<GotoAndPlay>2222200000</GotoAndPlay>
<EditionEntry>
<EditionUID>1111100000</EditionUID>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>1</EditionFlagDefault>
<EditionFlagOrdered>1</EditionFlagOrdered>
<ChapterAtom><ChapterUID>1111100001</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterTimeEnd>00:02:58.360000000</ChapterTimeEnd>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterDisplay>
<ChapterString>Chapter 1</ChapterString>
<ChapterLanguage>und</ChapterLanguage>
....

i will try to use the Menu function of mkv. (Matroska-Specs (http://matroska.org/technical/specs/index.html)) Below on this side you find information for the Menu entry.
it would be nice if you have a look at this. Perhaps you can implement this in a future version.

[Mosu]

<ChapProcess> mus be <ChapterProcess>. <ChapterProcess> is a level 4 element (look at the specs!), meaning it is a child of <ChapterAtom>.

Please don't post results test cases in which you obviously did NOT change "Chap" to "Chapter". Thanks.

[hubblec4]

thanks for the information. it works with <ChapterProcess>

But GotoandPlay seems to be wrong:
"...
2Editions-test.xml', line 13, column 0: <GotoAndPlay> is not a valid child element of <ChapterProcess>.
..."

Do you have a tip for me.

[Mosu]

GotoAndPlay is not mentioned in the Matroska specs. Where did you find those?

[hubblec4]

GotoAndPlay is not mentioned in the Matroska specs. Where did you find those?

i found this in the matroska-specs
Menu features (http://matroska.org/technical/specs/chapters/index.html#dvd) (scroll a little bit up.

...The one and only command existing for the moment is GotoAndPlay( ChapterUID );. As the same suggests, it means that when this command is encountered, the playback should jump to the Chapter specified by the UID and play it....

[robpdotcom]

Not trying to change this into a chapters thread, but while we're on the subject.... Is ChapterSegmentEditionUID supported by mmg, or am I using it wrong? When I try to drag it into the Chapter Editor, I get the "Does not contain valid chapters" error.

<?xml version="1.0" encoding="UTF-8"?>

<!-- <!DOCTYPE Tags SYSTEM "matroskatags.dtd"> -->

<Chapters>
<EditionEntry>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>1</EditionFlagDefault>
<EditionFlagOrdered>1</EditionFlagOrdered>
<EditionUID>2927856557</EditionUID>
<ChapterAtom>
<ChapterUID>56485314556</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterTimeEnd>02:18:37.412600000</ChapterTimeEnd>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterSegmentUID format="hex">
f7 3d e7 44 df 72 96 6c 58 b9 2b 9f 65 ce f5 76
</ChapterSegmentUID>
<ChapterSegmentEditionUID>1248654321</ChapterSegmentEditionUID>
<ChapterDisplay>
<ChapterString>Part II</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
</EditionEntry>
</Chapters>

[Mosu]

i found this in the matroska-specs
Menu features (http://matroska.org/technical/specs/chapters/index.html#dvd) (scroll a little bit up.

...The one and only command existing for the moment is GotoAndPlay( ChapterUID );. As the same suggests, it means that when this command is encountered, the playback should jump to the Chapter specified by the UID and play it....

Quoting from the specs: "The scripts are stored in ChapProcessData." And not as XML elements, but as binary data (ChapterProcessData is an EBML binary). I have no examples for you how to use this properly as I don't think any software has ever implemented support for this.

[Mosu]

Not trying to change this into a chapters thread, but while we're on the subject.... Is ChapterSegmentEditionUID supported by mmg, or am I using it wrong? When I try to drag it into the Chapter Editor, I get the "Does not contain valid chapters" error.

ChapterEditionSegmentUID is a binary. If you use a tag for a binary element without a "format" attribute then it is assumed to contain Base64 encoded data. For pure ASCII content you can use "<ChapterEditionSegmentUID format="ascii">1234567890...</ChapterEditionSegmentUID>".

[Mosu]

Hmm... I just noticed that libmatroska lists that element as an "unsigned integer" while the specs list it as a "binary". This is a bug in libmatroska that I'll have to fix.

[Mosu]

ChapterEditionSegmentUID is a binary. If you use a tag for a binary element without a "format" attribute then it is assumed to contain Base64 encoded data. For pure ASCII content you can use "<ChapterEditionSegmentUID format="ascii">1234567890...</ChapterEditionSegmentUID>".

I was wrong. Both the specs and libmatroska say that it's an unsigned integer. No bug there. My answer is simply wrong. Also: the XML file you've posted works fine with a mkvmerge build that I haven't released yet. I'm re-writing the complete XML handling code at the moment, and chapters and tags are done. The old code did indeed not recognize ChapterEditionSegmentUID while the new code does. This will be part of the next release, v5.5.0, and I might offer a new Windows build including that code in the next couple of days.

[robpdotcom]

Thanks Mosu. I always hate asking unrelated questions, but now I'm glad I did.;)

[Mosu]

Hey,

I've finally implemented one of the more-often asked for features (https://trac.bunkus.org/ticket/518). mkvmerge can now copy only requested ranges of timecodes. Think of it as splitting by timecodes without writing undesired parts at all. It can even do a bit more: you can tell mkvmerge to write a range to the same file as the previous range.

This is implemented as another syntax for the "--split" option: "--split parts:....". mmg has received the usual update with its own control for that option.

The full documentation for the syntax is available: http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split and I really suggest you read it and its examples before trying it out :)

The usual restrictions to mkvmerge's "--split" option still apply: mkvmerge will only do something on a key frame.

This feature requires some testing though, and that's where you come in :) I've provided a build for Windows at http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (build numbers 433 and higher). Please test and report issues, feedback etc. Thanks.

BTW: Nope, this is not an April fool's joke.

[Selur]

Thanks! Nice!
This feature is really appreciated!
Only missing feature for me regarding splitting is now a --split frame:.. option which works analog to parts:.. but with frame numbers instead of time codes ;)

Cu Selur

[LeMoi]

Is this included in the GUI ?

[Selur]

yes,.. mosu wrote:
mmg has received the usual update with its own control for that option.

[cengizhan]

Hey,

I've finally implemented one of the more-often asked for features (https://trac.bunkus.org/ticket/518). mkvmerge can now copy only requested ranges of timecodes.
....
BTW: Nope, this is not an April fool's joke.

:thanks:

[robpdotcom]

This may be a regression:

I created a chapter file, opened with mmg (the latest version, with the "Split by parts" option), and saved. For the lines <ChapterSegmentUID format="hex">, the segment UID was changed. Opening and saving with older versions of mmg reverses the change.

After saving with old mmg:

<?xml version="1.0" encoding="UTF-8"?>

<!-- <!DOCTYPE Tags SYSTEM "matroskatags.dtd"> -->

<Chapters>
<EditionEntry>
<EditionUID>2606402697</EditionUID>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>0</EditionFlagDefault>
<EditionFlagOrdered>1</EditionFlagOrdered>
<ChapterAtom>
<ChapterUID>90723729</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterTimeEnd>00:00:07.200000000</ChapterTimeEnd>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterSegmentUID format="hex">
b4 1c 1c d0 de c8 84 84 8e a9 b5 c7 7d 5e c6 d3
</ChapterSegmentUID>
<ChapterDisplay>
<ChapterString>1</ChapterString>
<ChapterLanguage>und</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
</EditionEntry>
</Chapters>


After saving with latest mmg:

<?xml version="1.0"?>
<!-- <!DOCTYPE Chapters SYSTEM "matroskachapters.dtd"> -->
<Chapters>
<EditionEntry>
<EditionUID>2606402697</EditionUID>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>0</EditionFlagDefault>
<EditionFlagOrdered>1</EditionFlagOrdered>
<ChapterAtom>
<ChapterUID>90723729</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterTimeEnd>00:00:07.200000000</ChapterTimeEnd>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterSegmentUID format="hex">0xb4 0x1c 0x1c 0xd0 0xde 0xc8 0x84 0x84 0x8e 0xa9 0xb5 0xc7 0x7d 0x5e 0xc6 0xd3 </ChapterSegmentUID>
<ChapterDisplay>
<ChapterString>1</ChapterString>
<ChapterLanguage>und</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
</EditionEntry>
</Chapters>

[Mosu]

That is not a regression. I've completely rewritten the XML handling code. That he XML files don't look he same is OK. Even if elements occur in a different order is OK because Matroska itself does not impose an order (apart from a few places that are not relevant to the current discussion) . As long as the element's content is the same (and it is in this case) everything's fine.

[robpdotcom]

Gotcha. The chapters do still work fine, unless I do this (this is how I discovered something had changed):

Save the file with the new mmg > Open the file in GDS Mux (I use it because it makes adding ordered chapters easy). > Add a new ordered chapter (I copy/paste the segment UID from mmg's Header Editor). > Save, and use mmg to add it to the mkv. > The ordered chapters no longer work.

It happens like this:

I create an ordered chapter file, with a segment UID: b4 1c 1c d0 de c8 84 84 8e a9 b5 c7 7d 5e c6 d3

Open in mmg, save, the UID changes to: 0xb4 0x1c 0x1c 0xd0 0xde 0xc8 0x84 0x84 0x8e 0xa9 0xb5 0xc7 0x7d 0x5e 0xc6 0xd3

Open in GDS Mux, save.

I open the file in the new mmg again, save, and the UID gets changed again, to this: 0x0b 0x40 0x1c 0x01 0xc0 0xd0 0x0d 0xe0 0xc8 0x08 0x40 0x84 0x08 0xe0 0xa9 0x0b 0x50 0xc7 0x07 0xd0 0x5e 0x0c 0x60 0xd3

Apparently, GDS Mux is to blame, but I thought I would pass this along just in case it was useful.

[Mosu]

Let me get this right: GDSMux is not reading the actual XML file, but you're copy & pasting from mmg's XML file into an input control in GDSMux?

Either way, I could be technical and say "I don't care, this is solely mkvmerge's/mmg's format", but adding back the "0x" prefix is so damn trivial that I'll just do it.

[robpdotcom]

Let me get this right: GDSMux is not reading the actual XML file, but you're copy & pasting from mmg's XML file into an input control in GDSMux?

No. Through some experimentation, I found that if I: Load the XML with GDSMux > make no changes > save > open with mmg > save > mmg will try to add the 0x prefix, even though it is already there. But this only happens if I open/save the XML with GDSMux - opening it with notepad, extracting with mkvExtract, etc, all work fine.

[Mosu]

mmg, in its current build, will never add a "0x" prefix when it writes an XML file. The "0x" prefix is purely syntactic sugar for hexadecimal numbers. When mmg reads an XML file it silently discards all "0x" prefixes as if they weren't there.

The "0x" prefixes are ALSO not part of a Matroska file (!). Instead the hexadecimal numbers are converted into binary bytes -- that's the whole reason we're dealing with hex numbers in the first place. You could express the very same _content_ in a Base64 encoding, or, if all of those binary bytes were in the ASCII range, you could even write them out in ASCII.

[Mosu]

I have to apologize. It's exactly the other way around.

Before the XML rewrite the various XML writer routines did not prefix each hex digit pair with "0x". After the XML code rewrite they do.

However, in both cases the "0x" is still syntactic sugar. Neither mkvmerge nor mmg care whether or not a hex digit pair is prefixed with "0x". The hex digit still gets converted to the very same byte in Matroska, e.g. "0x54" would get converted to "T". As a matter of fact with the new code all of the following examples will all result in exactly the same value inside a Matroska file:

<ChapterSegmentUID format="hex">
b4 1c 1c d0 de c8 84 84 8e a9 b5 c7 7d 5e c6 d3
</ChapterSegmentUID>
<ChapterSegmentUID format="hex">0xb4 0x1c 0x1c 0xd0 0xde 0xc8 0x84 0x84 0x8e 0xa9 0xb5 0xc7 0x7d 0x5e 0xc6 0xd3 </ChapterSegmentUID>
<ChapterSegmentUID format="hex">b4 1c 1c d0 de c8 84 84 8e a9 b5 c7 7d 5e c6 d3</ChapterSegmentUID>
<ChapterSegmentUID format="hex">b41c1cd0dec884848ea9b5c77d5ec6d3</ChapterSegmentUID>
<ChapterSegmentUID format="hex">b4 0x1c 1c d0 de 0xc8 84 84 8e a9 0xb5

c7 0x7d 5e c6 d3</ChapterSegmentUID>

Note that earlier versions of mkvmerge/mmg (before the XML rewrite) could just as well deal with all of those examples above. Like I said, having "0x" there or not makes no difference to MKVToolNix.

I'll try to reproduce your issue with GDSMux later.

[Mosu]

What GDSMux does is being lazy. It simply removes everything that is not a valid hex digit (0-9, a-f) and writes the rest into the XML file. This includes spaces and the 'x', but not the '0' of the '0x' prefix. Interestingly it only does this when writing the XML file, not when loading it. I consider this at least a bug.

Even if you only load an XML file that does NOT have the ChapterSegmentUID element in it and then copy & paste to the "Segment ID" control in GDSMux and then save it will still mess it up by only removing 'x' but not '0x'. Still a bug.

But we all know Haali, right? He's going to fix this... never. So I'm changing back to not writing '0x' prefixes because, like I said, MKVToolNix simply doesn't care.

However, don't expect me to pay homage to braindead programs forever, please :)

[Mosu]

And here you go (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) (builds 434 and newer, still building, should be done in five minutes or so).

[robpdotcom]

I really don't expect you to work around other programs bugs, and I don't blame you if you don't. I just noticed that something which used to work no longer did, so I was passing it along.

To be honest, if I were you I probably wouldn't change anything. Hell, it seems like I'm very much alone when it comes to using ordered chapters, and I can always use notepad to write them.;) If Haali weren't the only splitter to support ordered chapters, I probably wouldn't even have it on my system, and I'd be using notepad anyway.

While we're on the subject, will something similar ever be added to mmg's chapter editor? Should I add a request on the "Re-write of mmg" thread?

Anyway, thanks for the explanations, and thanks for all your work.

[Mosu]

Sure, post on the re-write thread. If/when I get around to doing it the chapter editor will definitely be different than it is now :) Please describe what GDSMux does what the current one doesn't regarding ordered chapters -- I never use GDSMux and couldn't tell myself.

[robpdotcom]

lol It seems no one besides me uses GDSMux. All it does is have a checkbox for ordered chapters (to write <EditionFlagOrdered>1</EditionFlagOrdered> to the XML) and provide a box to enter a segment UID. I'll post it on the re-write thread.

Thanks again.

[hubblec4]

i use GDSMux too, because its simple there to generate ordered chapter xml files.
but the files which saved and load in Notepad++ looks not good. all lines written in one and its looks confused.

The best feature in mmg chapter editor is the "Adjust timecodes".

[hubblec4]

...
Hell, it seems like I'm very much alone when it comes to using ordered chapters, and I can always use notepad to write them.;) If Haali weren't the only splitter to support ordered chapters, I probably wouldn't even have it on my system, and I'd be using notepad anyway.


your are not alone with ordered chapters, i use it too.

And i see the same problem with a perfect ordered-chapter-splitter.
Haali works very well, but with the DTS-HD MA or Flac7.1 sound the video plays not good.

The best alternitiv is AVSplitter. It works in ever case!

I hope that Nev will update the LAV Splitter, but it seems it will do not this year :-(

[Mosu]

Hey,

I've released MKVToolNix v5.5.0. It fixes a few issues all across the board. The XML handling has been completely rewritten resulting in the tag, chapter and segment info XML files supporting more of the Matroska specs. A new mode for "--split" has been implemented that let's you keep certain ranges and discard others without the need for temporary files or multiple muxing passes.

A note for package maintainers: Boost's "lexical_cast" and "type traits" libraries is now required. expat is not used anymore.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-5.5.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.5.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.5.0.7z

All of the Linux binaries that I provide have already been built and are available.

Here's the full ChangeLog since release 5.4.0:

2012-04-06 Moritz Bunkus <moritz@bunkus.org>
* Released v5.5.0.
* Build system: Boost's "lexical_cast" and "type traits" libraries are now required.
* mmg: new feature: Added GUI controls for mkvmerge's "file concatenation" feature as "additional file parts". The user can chose which individual files are treated as if they were a single huge source file.
* mkvmerge: bug fix: The handling of the "do not read other files" options (e.g. "=file.vob" and "( file.vob )") was broken for MPEG program stream files.

2012-04-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a wrong assertion about minimum MPEG 1/2 video start code lengths. Fixes ticket 728 (https://www.bunkus.org/trac/ticket/728).

2012-03-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: new feature: Added support for keeping only certain timecode ranges from the source files with a new format to "--split": "--split parts:...". Implements ticket #518 (https://www.bunkus.org/trac/ticket/518).

2012-03-30 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added an option in the preferences dialog called "clear jobs from the job queue after they've been run". Can be set to "only if run was successfull", "even if there were warnings" and "even if there were errors". Defaults to off.

2012-03-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract, mmg: Re-write of the whole XML handling code. It now uses the "pugixml" C++ library instead of the "expat" library. Therefore "expat" is not required for building MKVToolNix anymore. And neither is Boost's "property tree" library. "pugixml" itself is included and not an external requirement either.
* Build system: removed all files and documentation related to building MKVToolNix with Microsoft's Visual Studio because even the most recent version of Visual C++ does not support the C++11 features required for MKVToolNix.
* mkvmerge, mkvextract: removal: Removed support for the CorePicture file format. It was mostly unused and relied on old code that will be removed soon.
* documentation: enhancement: mkvmerge's man page has been updated with a list of valid XML tags for the chapters, tags and segment info XML file formats.
* all: Updated the DTD files with the newly supported elements.
* mkvmerge: enhancement: Chapter XML files: mkvmerge can handle the "ChapterSegmentEditionUID" element.
* mkvmerge: enhancement: Segment info XML files: mkvmerge can handle the "SegmentFilename", "PreviousSegmentFilename" and "NextSegmentFilename" elements.

2012-03-19 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Added "mts" as yet another file extension for MPEG transport streams.

2012-03-18 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed a crash due to a missing argument for a format string when clicking on the "Browse" button for the track-specific tags.

2012-03-15 Moritz Bunkus <moritz@bunkus.org>
* mmg, mkvinfo's GUI, all .exes: enhancement: Added new icons by Eduard Geier. (see AUTHORS).

2012-03-14 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: mkvextract sometimes wrote undefined values to a single reserved header field when extracting into AVI files. Patch by buguser128k. Fix for ticket 727 (https://www.bunkus.org/trac/ticket/727).
* mkvmerge: bug fix: AVC/h.264 mkvmerge was wrongfully writing a default duration of 60 frames/fields even if the source was signalling 60000/1001 frames/fields. The frame timecodes have been correct already.

2012-03-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed timecode calculation for (E)AC3 tracks if the source container (e.g. MPEG transport streams) only provided timecodes for some of the (E)AC3 packets itself.

Have fun.

[wanezhiling]

Thanks Mosu.:)

[Sparktank]

Awesome stuff!!!

I was just running eac3to through a "test" to see how my codecs are doing with it and saw the notification that MKVToolnix has been updated.
I got all excited about it and just had to jump on it right away.

Excellent work, as always! :)

[b66pak]

thanks a lot...
_

[zn]

thanks for #518

2012-03-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: new feature: Added support for keeping only certain timecode ranges from the source files with a new format to "--split": "--split parts:...". Implements ticket #518 (https://www.bunkus.org/trac/ticket/518).

[hello_hello]

Thanks for the new version (5.5.0). BTW, I like the new yo-yo icon. ;)

[Mosu]

Unfortunately the original implementation of the --split parts:... feature contained quite a few bugs: 737 (https://trac.bunkus.org/ticket/737) 738 (https://trac.bunkus.org/ticket/738) 739 (https://trac.bunkus.org/ticket/739) 740 (https://trac.bunkus.org/ticket/740) 742 (https://trac.bunkus.org/ticket/742).

They’ve all been fixed now. But I suggest you get the latest pre-build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) if you want to use this feature. Build numbers 436 and higher include all the fixes.

[FCBarca]

Been trying to figure out how to mux audio into a video file with mkvtoolnix on my MBP...I have a 1080i russian video of a match that I wanted to mux in english broadcast from another file...There's a gap, a couple really...The video on the russian cap has around 1 min less to the start ahead of the whistle than the english cap does...Any tips on how to get this muxed in well?

First attempt at muxing things initially looked good as I added a negative delay to the audio track which seemed to sync perfectly..Then I realized a bit later that the original russian cap has a 12 second video hiccup which loses 12 seconds of video/audio...and of course puts the newly muxed audio track out of sync once again from that point...Can I do multiple syncs or muxes or is there nothing to be done

[sneaker_ger]

You could do it in two steps:
1. Use the new "--split parts:" (see Mosu's post above for latest pre) to cut out the 12 seconds from the English cap
2. Then merge the new file's audio with your Russian cap

(it is theoretically possible to keep the audio and freeze frame the video for 12 seconds, but you would have to manually edit the timecodes or do a combination of clever splits/cats, which is not for beginners and players may not like it)

[Fullmetal Encoder]

Mosu,

Thanks a lot for your work on recent improvements to add the split functionality. It expands the usefulness of the tool tremendously.

I had a couple questions about how mmg/mkvmerge works with VOB and M2TS files.

Currently, when I drag a VOB into mmg for output into an MKV it grabs all of the VOB's in the current disc. This is extremely useful for me because I deal mostly with television shows where I might want to due a lot of splits with timecodes and I can process a whole disc at once. I would bet that it was easiest for you to implement direct input from VOBs this way too as you don't have to deal with VOB and cell ID numbers. However, if I wanted to do the same with a Blu-ray disc I would have go through the stage of appending each separate M2TS and writing one large M2TS, then importing back into mmg for splits or optionally multiple steps for each individual M2TS. When outputting DVD VOBs to MKV there doesn't appear to be any involved process taking place behind the scenes to append all the tracks together for each VOB.

So I guess my question is, how is mkvmerge/mmg handling these VOBs in the background? And is it possible to have this same effect for whole Blu-ray discs?

Also, a while ago I posted here (http://forum.doom9.org/showthread.php?p=1537956#post1537956) about a few things I'd like mkvmerge to be able to do and you said that it would be too much work. If I could code solutions to these problems in C++ would you consider making them a part of mkvmerge/mmg?

[Mosu]

So I guess my question is, how is mkvmerge/mmg handling these VOBs in the background? And is it possible to have this same effect for whole Blu-ray discs?

First, you have to differentiate between mkvmerge and mmg. mkvmerge's low-level file handling code can treat an arbitrary number of files as a single virtual file so that the upper layers only "see" one big input file. The "upper layers" in this case are all the input file type readers (e.g. the MPEG program stream reader, but just as well the MPEG transport stream reader or even the AVI reader -- though you never see an AVI file split binarily these days).

The difference between the program stream reader and all the other readers is that the program stream reader is the only reader that will actively look for split files even if the user doesn't request it -- e.g. if you execute mkvmerge -o out.mkv VTS_01_1.VOB it will look for VTS_01_2.VOB etc. as well. The reason is that DVD-named VOB files have pretty distinct naming patters while most other cases don't. BluRay simply names the files something like title00001.m2ts etc.

If you want to tell mkvmerge manually to read several (M2)TS files as a single file then the general command line syntax for treating multiple input files as a single file is this:

mkvmerge -o out.mkv ( in-part1.m2ts in-part2.m2ts in-part3.m2ts )

Note the spaces before and after the parenthesis. Also note that most Linux/Unix shells treat parenthesis as special characters, meaning you might have to quote them, e.g. mkvmerge -o out.mkv '(' in-part1.m2ts in-part2.m2ts in-part3.m2ts ')'

Now on to mmg. At the moment mmg only supports knowing which MPEG program stream parts mkvmerge will process and will prevent you from appending them manually. Unfortunately you cannot use the general "treat several files as one" feature with mmg at all currently. The QtMmg re-write that I'm actually working on at the moment will have full support for this feature. But for the time being you're restricted to the command line/option files if you want to use it with mkvmerge.

And here's a fair warning: never use mmg's/mkvmerge's "append" feature for files that have been split binarily. You will use information (packets/frames) at the point where a file ends and the next one starts unless the next file starts with whole packets that are I frames for each track type (even then) -- for VOBs this is never the case, I'm not sure about MPEG TS.

Also, a while ago I posted here (http://forum.doom9.org/showthread.php?p=1537956#post1537956) about a few things I'd like mkvmerge to be able to do and you said that it would be too much work. If I could code solutions to these problems in C++ would you consider making them a part of mkvmerge/mmg?

To 1.: This would be a feature of mmg more than of mkvmerge. Of course you could also try implemented "readers" for DVD idx files / BluRay clip files (or wherever the chapter information is stored for BluRays) that only read chapters from those files but no tracks. I will most likely not accept features for the current mmg anymore due to the re-write. I will accept patches for mkvmerge, but be prepared for a shitload of work -- including updating the documentation for mkvmerge (the man page).

To 2.: Has been implemented.

To 3.: If you want to implement it then go ahead, but you'll have to duplicate the functionality of DVDVobSub (or whatever program is used to create separate VobSubs from DVDs). Again you'll have to parse the DVD idx files in order to create the "text" part of a VobSub.

I also expect any patch to be platform-independent. Meaning you cannot use e.g. a library that's only available on Windows -- and that includes all of DirectX, of course. For DVD reading you can use e.g. libdvdread which is generally the standard way of accessing DVDs in the OpenSource world (e.g. VLC, mplayer etc all use it). I will not accept a dependency on ffmpeg either.

[Selur]

small question: is anyone building mkvmerge&co statically for Mac OS X? (the downloads over at bunkus.org are dynamically linked and don't run on my system out of the box)

Also when there are no static build of mkvmerge&co, is there a way to use mkvmerge&co without having to install/copy a bunch of stuff to the /usr/bin etc folders?
-> okay, never mind. I totally overlooked the Framework folder. :)

[Mosu]

So... There was no problem in the first place, right? If there still is then I suggest you contact Jonathan (http://jonthn.free.fr/MKVtoolnix/CONTACT). He is quite helpful