MKVToolNix v99.0 released

[markfilipak]

I'm not sure what MKV supports and I doubt that what I want can be done, but perhaps someone less ignorant than me will pitch in.

What I want, and what a BD player does, is pair audio & subtitles in particular ways.

A particular BD movie has English dialog & French dubs. It has infrequent German dialog during scenes set in Berlin. If English dialog is selected (default), then German-to-English translation subs are automatic. If French dubs, then German-to-French translation subs are automatic.

Streams:
1 English audio
2 French dub
3 English subs
4 French subs
5 German-to-English translation subs for scenes in Berlin
6 German-to-French translation subs for scenes in Berlin

Playback of BD disc (e.g., PowerDVD):
1 (+5 automatic) -- part-time translations only
2 (+6 automatic) -- part-time translations only
1 (+5 automatic) + 3 -- full-time English subs & translations
2 (+6 automatic) + 4 -- full-time French subs & translations

Playback of MKV remux (e.g., MPV):
1 -- no subs, no translations
2 -- no subs, no translations
1 + 3 -- English subs but no translations
2 + 4 -- French subs but no translations
1 + 5 -- translations but no English subs
2 + 6 -- translations but no French subs

Is there any way to pair 1 & 5 and 2 & 6 (as though forced subs) so that an MKV remux duplicates the behavior of a BD disc player?
1 (+5 automatic) + 3 -- full-time English subs & translations
2 (+6 automatic) + 4 -- full-time French subs & translations

Thanks,
Mark.

[sneaker_ger]

The MKV specs don't offer the possibility to bind any specific audio track to a specific subtitle track (or vice versa). I vaguely remember something about a possibility using editions though I think players didn't support it anyways so ...


(Back in the day "Haali's Splitter" offered support for non-spec "TRACKSETEX" to offer such pairings but I don't know if there is any player support outside of the deprecated Haali Splitter.)

[odino]

Is there a way to delete a language from the ISO list? Church Slavic bla bla bla is so long the right-hand panel in the multiplexer is stretched unnecessarily. I will never ever use it among a few others I could trim.

[stax76]

Dotnet just calls this Church Slavic. Maybe somebody finds the staxrip approach interesting:

https://postimg.cc/XXzpvxdX

[markfilipak]

The MKV specs don't offer the possibility to bind any specific audio track to a specific subtitle track (or vice versa).

Thanks for the info. -- Mark.

PS: I found the MKV specification, but github is a show stopper. I searched for MKV editors, but turned up only video editors.

Is there an IFOEdit-style editor for MKV that will at least allow me to see into an MKV and see/copy metadata?

[odino]

Dotnet just calls this Church Slavic. Maybe somebody finds the staxrip approach interesting:

https://postimg.cc/XXzpvxdX

Yeah, so I'm sure it can be configured somehow.

[Mosu]

Is there a way to delete a language from the ISO list? Church Slavic bla bla bla is so long the right-hand panel in the multiplexer is stretched unnecessarily. I will never ever use it among a few others I could trim.

Preferences → GUI → Often used selections

[foxyshadis]

Thanks for the info. -- Mark.

PS: I found the MKV specification, but github is a show stopper. I searched for MKV editors, but turned up only video editors.

Is there an IFOEdit-style editor for MKV that will at least allow me to see into an MKV and see/copy metadata?

The GUI's info tool and header editor give you access to pretty much all of that.

[odino]

Preferences → GUI → Often used selections

That only works if I select the tickbox to "only include often used in list" but that defeats the point of an often used list.

[Mosu]

That only works if I select the tickbox to "only include often used in list" but that defeats the point of an often used list.

Not really, it just allows you to use the selections in two different modes, depending on what you prefer: either the full list with certain entries located at the top or only those entries you tend to use over and over. Most people I talk to prefer the latter.

Don't get hung up on the name.

[odino]

Alright thanks, I'll use it that way.

[kuchikirukia]

I just tried to do a weird workflow which had a bugged result:

I have a Blu-ray with 3 episodes in 3 M2TS files. I wanted chapters in them but the Blu-ray playlist for them combines the episodes together, so I threw the playlist into mkvtoolnix and then split it at the episode chapter marks to get 3 MKVs with BD video and PCM audio with chapters.
Here's the oddity: When trying to mux in AAC audio and subtitle tracks from a previous encode, it ends up delaying the video and original audio of the split mkvs. Ep 1 will mux fine, but on eps 2 and 3 the black lead-in will play for ~1 second longer than simply the BD video + PCM alone, the Info Tool will show an additional 1 second of playtime, and the AAC and subs will be out of sync with the BD video and PCM, even though if you throw both audio tracks in Audacity it shows them to be in perfect sync.

If you mux the AAC audio and subs into the original M2TS' there's no issue.

E: it seems to be setting an audio delay relative to video of -1.3 seconds. That's weird because doesn't mkvtoolnix usually cut AAC with a negative delay?

[Perenista]

I noticed what appears to be an issue with MKVToolnix, or with what I have in mind...

I have an ISO (DVD) from a TV recording. When I use MPC-HC to open the DVD, the disc is able to play the 2 parts together. When I use MAKEMKV it generates 2 Matroskas. That's OK, but when I append the 2nd file to the 1st, there is an audio bug that is never seen (heard) in these individual files. So this must be a) MKVToolnix's doing, or b) a bug inherent to this idea of appending. Important: I noticed with other disc that is totally different, so this isn't an isolated case, it's valid for ALL appendings we ever do.

Let's see if I can explain this...

We will assume each video has 2 minutes. Appending would make a single 4 minute MKV file, right?

The problem is that the 4 minute file mutes the audio for a second after the point in which they are joined together.

Like this:

>>>>>> 4 minute file when analyzed further:

2 minutes 2 minutes
====== =/====

/ = the muting.

/ would be at 2:02 or 2:03.

Then at 2:04 the video and audio continue just fine.

But (and here's the catch) if we open file2.mkv and play it... we never notice the / I just mentioned above.

Here's proof of what happened. Instead of just posting a written explanation, I have actually recorded the bug happening

First, I want to show how I am putting these files together:

https://i.imgur.com/1QQDF2s.png

Second, download this file from Google Drive and play in your PC:

-LINK REMOVED-, problem solved

PROOF.mpg;

Pay attention of what happens in the following moments:

- 0:00 until 20 seconds - file1.mkv is played.
- 20 seconds until 47: file2.mkv is played

- Starting at 50 seconds I play this "4 minute" file, which is file1.mkv and file2.mkv appended.

1 minute and 7 seconds: exactly the moment in which the / (bug) can be noticed: the audio is briefly muted. This would be in a 4 minute file the moment 2:02 or 2:03, approximately.

Note that file2.mkv at 30 seconds onwards don't show anything wrong. This is how it should have been in the 4 minute file.

In theory the appending of file1.mkv and file2.mkv should generate a 4 minute file spotless. Why is that not happening?

MEDIAINFO from file1.mkv:

https://pastebin.com/1BgabbRa

[kuchikirukia]

Cut out 20 seconds at the end of mkv1, 20 seconds out of the beginning of mkv2, and upload both along with a merged 40 second copy. That will give mosu something to look at.

Also you can probably get around this issue by appending the audio and video tracks separately and them muxing them together.

[sneaker_ger]

Mkvmerge has 2 different --append-mode settings. It's common for the default setting to create audio or video gaps. You can read in the docs about them:
https://mkvtoolnix.download/doc/mkvmerge.html

MEDIAINFO from file1.mkv:

https://pastebin.com/1BgabbRa
It says video is 48m39s, audio is 48m38s. If you use the default append mode a 1 second audio gap is expected. (Feature, not bug.)

[Perenista]

Mkvmerge has 2 different --append-mode settings. It's common for the default setting to create audio or video gaps. You can read in the docs about them:
https://mkvtoolnix.download/doc/mkvmerge.html


It says video is 48m39s, audio is 48m38s. If you use the default append mode a 1 second audio gap is expected. (Feature, not bug.)But how do I tell MKVToolnix to use TRACK mode instead? I am using the GUI. Should I only use command lines for that?

Yeah, this is a case of a DVD (VOB...) splitted into 2 different MKVs by MAKEMKV, so when appending them I need to use TRACK instead of "FILE" (see below), otherwise this problem will happen.

These splitted MKVs are 2 parts of a single content, not two independent recordings from the same DVD that I wanted to put together, yet were always apart from each other.

The only reason MAKEMKV created 2 MAKEMKVs is because the DVD was created with 2 options: WATCH ALL (which in the end just put them together) and watch 1st half of the match and 2nd half (it's a broadcast from a sports event).

--append-mode mode
*********
Determines how timestamps are calculated when appending files. The parameter mode can have two values: 'file' which is also the default and 'track'.

When mkvmerge appends a track (called 'track2_1' from now on) from a second file (called 'file2') to a track (called 'track1_1') from the first file (called 'file1') then it has to offset all timestamps for 'track2_1' by an amount. For 'file' mode this amount is the highest timestamp encountered in 'file1' even if that timestamp was from a different track than 'track1_1'. In track mode the offset is the highest timestamp of 'track1_1'.

Unfortunately mkvmerge cannot detect which mode to use reliably. Therefore it defaults to 'file' mode. 'file' mode usually works better for files that have been created independently of each other; e.g. when appending AVI or MP4 files. 'track' mode may work better for sources that are essentially just parts of one big file, e.g. for VOB and EVO files.
*********

[kuchikirukia]

Also you can probably get around this issue by appending the audio and video tracks separately and them muxing them together.

^^^^^

[Perenista]

^^^^^It worked! I read your message and was reluctant to try. Now I figured out how it's done:

I had to do the following:

1) gMKVExtractGUI: extract the video and chapter tracks from file1.mkv. Repeat procedure for file2.mkv.

2) MKVToolnix: create a MKV with extracted tracks from file 1. Repeat for tracks from file2.

2.1) Merge the two resulting MKVs (append option).

3) gMKVExtractGUI: extract the audio track from file1.mkv. Repeat procedure for file2.mkv.

4) MKVToolnix: create a MKA with extracted tracks from file 1. Repeat for tracks from file2.

4.1) Merge the two resulting MKAs (append option).

5) Insert the MKA inside the MKV and save as a new MKV.

A little more work, but it fixed the problem. What I am not sure is how can we tell exactly if appending will cause this issue... I only noticed after checking, otherwise it would be still there.

********
Unfortunately mkvmerge cannot detect which mode to use reliably. Therefore it defaults to 'file' mode. 'file' mode usually works better for files that have been created independently of each other; e.g. when appending AVI or MP4 files. 'track' mode may work better for sources that are essentially just parts of one big file, e.g. for VOB and EVO files.
********

In this case it was easy to spot the error because:

a) It's a DVD, so VOB files;

b) It's a sports event, a match with 1st and 2nd half, and when we open the DVD it offers us the option to play all together or select one of the two.

Another case in which I saw this problem was a TV show episode that is probably viewed as a single one (with 44 instead of 22 minutes) during DVD playback, but it's actually splitted into two when MAKEMKV is extracting.

When I tried appending the MKVs the same thing happened, so I let them separated.

I never stopped to read mkvmerge's documentation, this is very interesting.

[kuchikirukia]

Uh, alternately you could've just put file1 and 2 into mkvtoolnix set to append, selected only the video track and hit merge, then deselected the video track and selected the audio track and hit merge, then muxed the resulting mkv and mka files together.

You just always need to check your joins. There's no way to automatically tell which way is the right way to append. Subtitles especially will wreck things if you're splitting and appending since the lines don't get cut on split (it only splits between subtitle lines). So your audio and video will get cut on the keyframe, the subtitle line will extend further, and so when you try to append, everything in the next file will get pushed back to the end of the subtitle line.

[sneaker_ger]

JFYI:
https://i.imgur.com/xmtFNhh.png

(Whether or not to use track append mode on these files is a different question. I would have expected a sync issue if the two files weren't originally from the same VOB.)

[kuchikirukia]

Yeah, he probably needs to cut the last 1 second of file1 to get the dangling track back in line.

[Masutin]

What do you use to find key frames? In mkvmerge 29 (XP), times according to PotPlayer may result in one KF too early or late.

[Mosu]

Well hello, gentle people.

Surprisingly it's still May, even though it feels much longer since… well everything, really. Anyway, roughly four weeks since the previous release means it's a good time for another MKVToolNix release.

v47 contains a couple of new enhancements and few bug fixes. However, under the hood big chunks of the source code was changed in an ongoing effort of switching from using Boost libraries to the C++ standard library. For end users this replacement doesn't mean much — apart from the usual danger of accidentally introducing bugs. Hopefully not too many.

For package maintainers the situation is different. There were several changes, not only due to this migration. Please read the news below carefully. Thanks.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG & Linux AppImage (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

Version 47.0.0 "Black Flag" 2020-05-30
New features and enhancements

mkvmerge: chapters: mkvmerge can now read chapters from DVDs if the user specifies the path to a DVD folder structure via the "--chapters …" parameter. By default chapters from the first title will be imported. This can be changed by append ":<title number>" to the file/directory name in the "--chapters …" argument, e.g. "--chapters /srv/dvds/BigBuckBunny/VIDEO_TS:3" This feature requires mkvmerge to have been built with the "libdvdread" library. Part of the implementation of #2808 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2808).
mkvmerge: added "--engage append_and_split_flac" that enables mkvmerge to append and split FLAC tracks, restoring pre-v45 behavior. The resulting tracks will be broken: the official FLAC tools will not be able to decode them and seeking will not work as expected.
MKVToolNix GUI: multiplexer: added support for mkvmerge's new support for reading chapters from DVDs if both have been built with the "libdvdread" library. Part of the implementation of #2808 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2808).
MKVToolNix GUI: multiplexer: when deriving languages from file names the GUI will now look for simplified language names instead of the full ones (e.g. instead of looking for "Greek, Modern (1453-)" it would simply look for "Greek").
MKVToolNix GUI: multiplexer: the options in the "additional command-line options" dialog are now sorted alphabetically. Additionally the "--append-mode" option has been added as one of the only missing global options.
MKVToolNix GUI: chapter editor: the chapter editor can now read chapters from DVDs if MKVToolNix has been build with the "libdvdread" library. Part of the implementation of #2808 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2808).
MKVToolNix GUI: header editor: added an option in the preferences for displaying all date & time values in UTC instead of the local time zone. Implements #2814 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2814).

Bug fixes
all: fixed a crash when using the "MTX_LOGGER=file" syntax for logging debug messages without specifying a file name to log to. It will now log to a file called "mkvtoolnix-debug.log" in the system's default temporary directory, as initially intended.

Build system changes
The "libdvdread" (https://www.videolan.org/developers/libdvdnav.html) library will be used if found via "pkg-config". If it is found, support for reading chapters from DVDs will be enabled in "mkvmerge" and the MKVToolNix GUI. Part of the implementation of #2808 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2808).
Boost's Date/Time, Lexical Cast, Range, Range Adaptors, Tri-Bool, Variant libraries are not used anymore.
MKVToolNix now requires a C++ compiler & standard library that support the following features of the C++17 standard: ""std::variant"", ""std::gcd"". For the GNU Compiler Collection (gcc) this means v7 or newer; for clang it means v4 or newer — the same versions required by earlier MKVToolNix versions.
MKVToolNix now requires version 6.1.0 of fmtlib or later for the "fmt::to_string" function and bugfixes to the formatting of floating point numbers. If a system-wide version is installed that's older, the bundled copy will be used.
The bundled version of fmtlib has been updated to release 6.2.1.

Have fun :)

[hubblec4]

Hi Mosu

Maybe there is a bug for IFO support.
I have opened a ticket (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2830).
Can someone confirm this?

[Mosu]

The thing is: I'm using libdvdread for reading DVDs. That library has the same problem a lot of other Unix-originating libraries have: they use the "open()" or "fopen()" function which only takes a char* as the file name argument, or to put it differently: they don't support reading from file names/paths that contain non-ASCII (non-ANSI, but due to how mkvmerge works internall, non-7bit-ASCII effectively) characters on Windows (on Linux/macOS that's not a concern as those functions take UTF-8 encoded char* strings there).

Bummer. But something I did know about when I made the decision to use libdvdread. Classical tradeoff between the amount of time I was willing to invest into this feature (it already took several hours to implement) and the importance of the feature (DVD? nowadays? Pleeease… and there are other tools that can get you the same information).

[hubblec4]

All fine, and I know you have more important things to do.

[Liisachan]

@Mosu
Thanks again for your passionate work :)
It's unfortunate that FLAC support is limited; one doesn't have this problem if WavPack is used instead?
[Btw I don't think you need to bad-mouth (?) DVD just because it's not the newest format; there are some hidden gems - old shows - only available as DVDs, and in some cases BD versions may even look worse when the show was originally created as SD but forcefully up-scaled to HD w/o careful remastering...]

@hubblec4
On Windows, Unicode (non "ANSI") file names often have ascii file names too, as seen by dir /x. Which may help in some cases, transparently recognized as the alias of the Unicode file name. E.g. Avisynth can read Unicode file names if you use such short (ascii) names.

@Masutin
Not sure if this will help you with your specific problem, but if you just open a file (e.g. MKV) with VirtualDub2, Keyframes are shows as scuh (Shift + arrow keys). You could also do ffmsindex.exe -f -k "path\to\your file.mkv" to quickly get the keyframe list.

[stax76]

Since Windows 10 the code page can be changed to UTF8, most but not all apps work well with it.

On Windows, Unicode (non "ANSI") file names often have ascii file names too, as seen by dir /x.

Does anybody know an API or command to get this name?

[Liisachan]

GetShortPathName

[stax76]

Thanks, I hope it will be useful.

[lvqcl]

According to this page (https://superuser.com/questions/1505174/how-comes-that-short-filenames-8-3-are-created-in-one-partition-and-not-in-ano), "Since Windows 8 and Windows Server 2012 newly formatted volumes will have 8.3 name generation disabled by default." So GetShortPathName() is not a reliable workaround.

[stax76]

According to this page (https://superuser.com/questions/1505174/how-comes-that-short-filenames-8-3-are-created-in-one-partition-and-not-in-ano), "Since Windows 8 and Windows Server 2012 newly formatted volumes will have 8.3 name generation disabled by default." So GetShortPathName() is not a reliable workaround.

Here in the terminal short paths work, apparently using UTF8 as code page is better anyway because only then Emoji show in the terminal.

https://i.postimg.cc/0NJtDNg2/Untitled.png

[Mosu]

I'm aware of GetShortPathName(), and I do have experimental code that re-tries with the short path name if opening with the regular one fails. The problem is: it doesn't actual solve the problem. It's not even a good workaround. It's a workaround that works _sometimes_ under _specific circumstances_. For example: It doesn't work if the file system doesn't store short path names. It doesn't work on network drives.

Sooooo… no.

[Mosu]

It's unfortunate that FLAC support is limited; one doesn't have this problem if WavPack is used instead?

Nope. Neither do the other supported, lossless formats: ALAC & TrueAudio. Neither of the three formats has the same type of unfortunate design decisions that FLAC does.

Note that support for files created by WavPack5 is currently slightly broken. Just within the last couple of hours a PR was opened to fix those issues, though, and the next MKVToolNix release will handle them correctly.

[Liisachan]

Neither of the three formats has the same type of unfortunate design decisions that FLAC does. Is the design of FLAC somehow strange? Hypothetically, what if one uses flac --ogg to write it as .oga? The current version of MKVToolNix doesn't support it, but it's an Ogg so MKVToolNix could read it alright in theory and handle it right? If so, maybe you could store FLAC as ogg, or would that simply confuse splitters/players and the resulted MKV wouldn't play even if one could create it?

As for GetShortPathName(), like you know very well, the resulted string is char* encoded in a Window-specific "ANSI" code page, after WideCharToMultiByte(CP_ACP); so even if short paths are enabled, they do not play nicely with a pure ASCII library not written specifically for Windows. For one thing, if the code page is Asian, the char string may contain the same byte as a backslash as the 2nd byte of a multi-byte character.

But unlike others say, using the short path name for a Unicode file name is often a usable workaround *IF* you're using a legacy non-Unicode program written for Windows; e.g. AVISource() in .avs can open Unicode.avi this way [though of course FFVideoSource(utf8=true) may be more elegant].

[sneaker_ger]

If so, maybe you could store FLAC as ogg
Since when does mkvmerge output anything other than mkv? ;)


See:
https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Appending-&-splitting-FLAC-audio-tracks-not-supported#technical-background

[Mosu]

Is the design of FLAC somehow strange?

The FLAC file headers (which are stored in Matroska's CodecPrivate) contain a checksum _of the decoded data_. In order to add or remove _encoded_ data to/from the track, the checksum would have to be re-calculated & updated. That would require actually decoding the whole encoded audio stream. No other format I know of uses a checksum of the decoded data because even validating the checksum would require a costly decoding process.

Sure, lots of formats have checksums, but those are checksums of the encoded data and the header data, and most of those checksums only cover single frames instead of _the whole stream_. Those single-frame checksums over encoded data are _fine_.

Here we run into the next problem: the API of libFLAC which is completely incompatible to how mkvmerge works (and other similar programs such as ffmpeg which has its own FLAC encoder & decoder). Meaning there's no easy way to decode FLAC blocks safe for linking to & requiring ffmpeg (which I'm not willing to do) or writing my own FLAC decoder (which I'm even less willing to do).

All of this is independent of where FLAC is stored (raw, in Ogg, in Matroska…).

[Liisachan]

Thanks for clear explanation. While it's understandable that audiophiles may want to store the checksum of the decoded (i.e. original) data, the situation seems surely inconvenient for Matroska.

@sneaker_ger
I trust you know that, by "store FLAC as ogg" I vaguely meant "store FLAC in the same way Vorbis.ogg is stored in Matroska". But you're right: .ogg is just a container, and FLAC in flac and FLAC in ogg are the same thing for Matroska. It was a stupid question :)

Technically, you have to scan the whole file(s) to re-calculate checksums and checkSumAdjustment when you edit a TTF file or split a TTC into TTF files too. But in this case, of course you don't have to decode any compressed data.

[foxyshadis]

The FLAC file headers (which are stored in Matroska's CodecPrivate) contain a checksum _of the decoded data_. In order to add or remove _encoded_ data to/from the track, the checksum would have to be re-calculated & updated. That would require actually decoding the whole encoded audio stream. No other format I know of uses a checksum of the decoded data because even validating the checksum would require a costly decoding process.

Sure, lots of formats have checksums, but those are checksums of the encoded data and the header data, and most of those checksums only cover single frames instead of _the whole stream_. Those single-frame checksums over encoded data are _fine_.

Here we run into the next problem: the API of libFLAC which is completely incompatible to how mkvmerge works (and other similar programs such as ffmpeg which has its own FLAC encoder & decoder). Meaning there's no easy way to decode FLAC blocks safe for linking to & requiring ffmpeg (which I'm not willing to do) or writing my own FLAC decoder (which I'm even less willing to do).

All of this is independent of where FLAC is stored (raw, in Ogg, in Matroska…).

Does anything actually care? FFMpeg generates it, but it also just skips over that value completely while decoding. Never even tries to store it, let alone validate it. flac has this:
FLAC__bool do_md5_checking; /* initially gets protected_->md5_checking but is turned off after a seek or if the metadata has a zero MD5 */
and the decoder does compare against a block of all-zeros to see if it's set. Seems like that would be a perfectly valid thing to set. Of course it's not in the spec, but that's good ol' FLAC.

[lvqcl]

Flac encoder creates a file with zero checksum if it writes to stdout:

> flac test.wav -o - > test.flac

...or if MD5 calculation is disabled during encoding (undocumented option --no-md5-sum):

> flac --no-md5-sum test.wav

In both cases metaflac shows:

> metaflac --show-md5sum test.flac
00000000000000000000000000000000

It's also possible to change MD5 checksum of an existing flac file with the (another undocumented) option --set-md5sum:

> metaflac --set-md5sum 00000000000000000000000000000000 test.flac

In any case, there's no problems with decoding etc. of such files.

[tormento]

Would it be possible to introduce batch muxing?

Let's say I have some streams thus named:

01 My movie.mkv (or whatever video format)
01 My movie [ita].ac3 (or whatever audio format)
01 My movie [ita] Forced.srt (or whatever sub format)
01 My movie [eng].ac3 (or whatever audio format)
01 My movie [eng].srt (or whatever sub format)
01 My movie [ita].srt (or whatever sub format)
01 My movie.txt (or whatever chapter format)

Picture that I set the "template" thru that streams and I want to repeat the same thing for "My movie 02" thru "My movie 10".

I have tried to use a "for" command but the string starts to get out of control soon, setting languages, order, forced etc.

Would it be possible to create a batch system for that, changing the number only of the streams?

That would be terrific for muxing entire episode seasons.

[Mosu]

My stance on batch muxing (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Batch-muxing-with-the-GUI) hasn't changed.

Note that there are third-party applications (https://mkvtoolnix.download/links.html) that implement some type of batch muxing.

[tormento]

Note that there are third-party applications (https://mkvtoolnix.download/links.html) that implement some type of batch muxing.
Will try them or fight with command line. :p

[stax76]

For batch muxing in staxrip you would:

-Disable indexing by installing LAV Filter and set source filter to DSS2.
-Select Copy/Mux video encoding profile.
-Select Copy/Mux audio profile.

[tormento]

For batch muxing in staxrip you would
Thank, will try.

My yesterday attempt (and success) was the following command line:
for %%a in (*.mkv) do "D:\Eseguibili\Media\MKV Toolnix\mkvmerge.exe" --output ^"F:\Out\%%~na.mkv^" --audio-tracks 3 --language 0:jpn --track-name 0: --default-track 0:yes --compression 0:none --language 3:jpn --track-name 3: --compression 3:none --language 4:ita --track-name 4:F --default-track 4:yes --compression 4:none --language 5:ita --track-name 5: --compression 5:none ^"^(^" ^"%%a^" ^"^)^" --language 0:ita --compression 0:none ^"^(^" ^"%%~na.mp4^" ^"^)^" --track-order 0:0,1:0,0:4,0:3,0:5
Funny, uh? :D

[Boulder]

My method for batch muxing of entire seasons is to 1) name all the files so that they can be easily muxed as episodes, 2) create a project in MKVToolNix GUI out of the files for the first episode, 3) copy the actual commandline, 4) edit it in Notepad++ by replacing "episodefilename" with %~nf and run the whole mess in a command prompt window with for %f in (*.hevc) do "..."

[tormento]

@Mosu

Would be possible to have an abort job in the Multiplexer window too, without having to switch to Job output one?

That plus a switch in preferences to remove or not the muxed file if a job is aborted.

[tormento]

My method for batch muxing of entire seasons is
Sometimes I have replace audio and subs from external sources. There is where real fun starts. :p

[Perenista]

Hey, what happened with appending this kind of MKV?

2-3.mkv' cannot be appended to the track number 1 from the file '1-3.mkv'. Appending tracks of this type is not supported.

It's funny, I remember having splitted these with MKVToolnix before... Now I can't merge them?

MEDIAINFO from file1.mkv:

https://pastebin.com/3bwkggYY

Should I get an older MKVToolnix version for that? If so, which one?

Note: The whole thing was splitted into 3 files. I tried appending file 1.mkv to file2.mkv and file3.mkv.

P.S. This was indeed splitted with help from MKVToolnix, in May 26, 2018 (v23.0.0). I can confirm that, because file 1 continues in file 2 and I did the splitting because I store them in Google Drive, and part1 has almost 15 GB, which is the max Google Drive space allowed. I need to use append for all 3 to further proceed with another splitting. File1 has 6 hours and file 2 another 6 hours I believe, and I need to do a splitting after 8 hours.

(((((((((((()))))))))

Wait a minute! I got the 23.0.0 version * and this appending is working!!!!!!!!!!!!

* From here:
https://mkvtoolnix.download/windows/releases/23.0.0/

What is going on?

Proof it's working:

https://i.imgur.com/FAImk8s.png

https://i.imgur.com/eIAuGNp.png

*******
RESULTED FILE:

Appending worked in 23.0.0!

https://pastebin.com/YX3KAWCh

So why was this feature removed? I had to install this older version in another folder, just to merge the 3 parts again.

And there are no anomalies in this 35 GB file with all 3 combined.

>>>>>>>>>
Another problem: Splitting is also being denied in this newer version. Again I had to resort to 23.0.0 to do this.

https://i.imgur.com/HtIV7wO.png

https://i.imgur.com/R9Pt34V.png

[sneaker_ger]

Read:
https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Appending-&-splitting-FLAC-audio-tracks-not-supported