MKVToolNix v99.0 released

[Mosu]

Is there a way to force MKVToolnix into saying all UNDETERMINED languages are english (or other language)? When I add an AVI into a new MKV file the english audio track is said to be UND. I always need to modify that to english, the problem is doing that with dozens of files.

In the GUI's preferences you can configure it to use a default languages for tracks that don't have such a property, or even for those whose language property is "und": "Preferences" → "Multiplexer" → "Default values" → "Default track languages to set". You can configure it per track type (mostly for handling video tracks differently than audio & subtitle tracks). This setting is evaluated whenever you add new files to multiplex settings.

If you want to modify existing files, you can look into scripting mkvpropedit to change the properties of existing tracks. This automation example (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Automation-examples#example-2-remove-default-track-flag-from-all-subtitle-tracks) does something very similar and can serve as a basis for your own script.

If scripting isn't your thing, there's also JMkvpropedit (https://github.com/BrunoReX/jmkvpropedit), though I've never used it myself and cannot attest to its suitability to your problem.

[Mosu]

Heydiho,

trying to keep up my usual schedule in 2021 of about four to five weeks between releases. This time it's even a bit less than four weeks. Several bug fixes and small enhancements were made.

There have been no changes for package maintainers.

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 53.0.0 "Fool's Gold" 2021-01-30
New features and enhancements

mkvmerge: AVI reader: added support for reading the video aspect ratio from the video properties header ("vprp" chunk) if present and setting the display dimensions accordingly. Implements #2993 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2993).
mkvmerge: MP4 reader: for h.264/AVC tracks that don't have an "AVCConfigurationBox" ("avcC" atom) in their sample description ("stsd") atom or whose "avcC" atom contains no content "mkvmerge" will now re-derive the "AVCConfigurationBox" from the bitstream. Implements #2995 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2995).
mkvextract: mkvextract will now check if any of the destination file names is the same as the source file name and abort with an error if that's the case. Implements #3001 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3001).
MKVToolNix GUI: when querying the user for a file name for saving things (e.g. multiplexer settings or an attachment in the header editor), the automatically suggested file name will now be based on the situation-specific file names (e.g. the destination file name for multiplexer settings or the attachment's name when saving an attachment in the header editor) instead of the directory's name. Implements #3012 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3012).
MKVToolNix GUI: multiplexer: when deriving track languages from file names the GUI will now select the right-most match instead of the left-most one. For example, "La.vie.en.rose.(fr).srt" will now be detected as French (fr) instead of English (en). Implements #3013 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3013).
MKVToolNix GUI: preferences: the items in the "pre-defined …" lists can now be renamed by double-clicking with the mouse or pressing the F2 key.
Windows installer: the "bluray_dump" command-line utility will be installed into the "tools" sub-directory. "bluray_dump" can read & dump certain file types used on Blu-rays: ".mpls" playlists, ".clpi" clip information databases, ".bdmv" index files, "bdmt_….xml" disc library databases and "tnmt_….xml" track & chapter name databases.

Bug fixes

mkvmerge: stretching chapter timestamps with "--chapter-sync" now works correctly with floating point values including fractions of floating point numbers (e.g. "12.3/45.67"). The tooltips in the GUI have been adjusted accordingly. Fixes #3002 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3002).
mkvmerge: MPEG 1/2 video handling: the "default duration" header field was often half the value it actually should be, resulting in all video frames having an explicit block duration with the correct value. This has been fixed with a patch by Tom Yan.
mkvmerge: MPEG 1/2 video handling: the data stored in "Codec private" and "Codec state" doesn't contain extensions other than sequence & sequence display extensions anymore. Fix by Tom Yan.
mkvmerge: tag handling: when remuxing a Matroska file with the "--no-track-tags", existing "SOURCE_ID" track tags are now skipped, too.
MKVToolNix GUI: multiplexer: the drop-down boxes with pre-defined track names now follow the order set in the preferences instead of sorting the entries alphabetically. Fixes #2999 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2999).


Have fun :)

[hubblec4]

Hi Mosu


Bug fixes

mkvmerge: MPEG 1/2 video handling: the "default duration" header field was often half the value it actually should be, resulting in all video frames having an explicit block duration with the correct value. This has been fixed with a patch by Tom Yan.



What a lucky coincidence. I got yesterday the Star Trek Voyager DVD's and had muxed the episodes from DVD 1.

With the new MTX version, I can confirm for the video frames is no longer a BlockGroup used.

I was always wondering why the "default duration" header field shows the half and in the BlockGroup shows the block duration the correct value.



Bug fixes

mkvmerge: MPEG 1/2 video handling: the data stored in "Codec private" and "Codec state" doesn't contain extensions other than sequence & sequence display extensions anymore. Fix by Tom Yan.



In the mkv's muxed with MTX 52 there are "Codec state" elements which now not anymore present.
This data was really superfluous?

[Mosu]

In the mkv's muxed with MTX 52 there are "Codec state" elements which now not anymore present.
This data was really superfluous?

Yes. A "codec state" says that the initialization data from that state element is to be used instead of "codec private" from the point where the state element occurs in the file.

All the change does is removing the very first state element if and only if its content is the same as the private element. Semantically nothing changes by leaving out that particular state element.

[hubblec4]

Fine. I'm glad to have this improvement now.
The file size is round about 700kb smaller. For 178 episodes it is more than 100mb.

[stax76]

staxrip always re-muxes mkvextract extracted AAC files to M4A using MP4Box, but is this necessary or do the AAC files contain all important metadata?

There is currently a discussion here:

https://github.com/staxrip/staxrip/issues/489

[Mosu]

ADTS AAC files only include as much information as necessary for decoding. Extracting to it loses quite a lot of meta data, of course, such as the timestamps or user-supplied data such as track names, tagging, chapter information. Most of those could be stored in MP4, but they don't survive the .mkv → .aac step.

Or to put it differently: the .aac → .mp4 step cannot invent metadata that isn't present in the .aac already.

So no, .mkv → .aac → .mp4 doesn't make much sense. One exception would be to feed the .mp4 to programs that don't support ADTS AAC files.

If you want to keep more metadata intact, you'll have to use other applications that support reading Matroska and writing MP4 files. An obvious one is ffmpeg, another choice might be the gstreamer framework (no idea if that offers more than what libavformet does, though).

Edited to add: mkvextract doesn't support extraction of 7.1 AAC to ADTS AAC files at the moment due to a more or less easily fixed but. Other channel configurations (7.0, 8.0 and more than 8 channels in general) aren't suported at all. The reason is that things get somewhat dicey with ADTS AAC files and the higher channel counts; the stream will have to contain a program_config_element to signal the higher channel count. mkvextract cannot generate said program_config_element at the moment.

[pson80]

I'm trying to figure out how to use the 'Directory relative to first source file's directory'-setting but can't find any info about it other than this post (https://forum.doom9.org/showthread.php?p=1861871#post1861871) that just says it now remembers your setting and there's nothing in the FAQ or documentation either. Maybe it's so obvious for the most you of that it isn't needed :D

Maybe it isn't even possible to do what I want to do anyway.
I would like to set the output directory to Y:\CurrentJobName (remote server) if the input is located locally in D:\Incoming\CurrentJobName. Is that doable or am I stuck to changing it manually every time?

[Mosu]

That scheme isn't supported by MKVToolNix GUI. What "parent directory" means is: same drive, one directory up. For example, if the first file is located in "D:\Some\Where", the destination file name will be set to "D:\Some".

[Nejiro]

Hello everyone, I am using version 53.0.0 on Ubuntu 20.04 lts and I cannot merge two files, I get the error that a file cannot be merged with itself, this is the first time this happens to me and I don't know how Obviously they are two compatible files and it is an operation that I have done many times, I load the first file then with the function "append to an existing source file" I put the second file, only I get this error ... .... I hope someone can help me.
Thank you

[Mosu]

This happens mostly when the appended files has more tracks than the file it's being appended to. In that case the GUI cannot really find a good place where to place the superfluous tracks, and it ends up laying them out in way that the superfluous tracks would be appended to the last non-superfluous track of the appended file.

You'll have to deactivate those appended tracks for which there's no corresponding track in the file they're appended to.

Example: Let's assume your first file contains one video, one audio track, and that your second file (the one you're trying to append to) contains one video, one audio and one subtitle track. In such a setup the GUI will set up things this way by default:


the video track from file 2 will be appended to the video track from file 1
the audio track from file 2 will be appended to the audio track from file 1
the subtitle track from file 2 has no corresponding track in file 1, but it must be placed _somewhere_; in this case it'll likely be appended to the audio track from file 1, to which the audio track from file 2 is already appended

In that case you'd have to deactivate the subtile track from file 2.

[Nejiro]

I apologize but it was my mistake, the two files did not have the same audio tracks, I fixed and now everything is fine.
Thank you

[odino]

Hi Moritz,
I have a question on stretching chapters. I have subtitles and chapters from an old mkv file @ 23.976 and the new on is 24fps. I can stretch the subs to perfectly match by stretching it by 0.999 but if I do the same for the chapters they all end up as 0s. I had first extracted it as XML and added it via "Chapter file". Additionally: is there any reason one cannot delay the chapters directly from the properties tab rather than extracting it, re-adding it and then adding a delay in the Chapters section?

It would also be helpful if you could give some examples of the stretching in the wiki you wrote about avoiding to stretch audio? E.g. 23.976fps->24fps, 25fps -> 23.975 and so on. https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Stretch-or-shrink-audio-tracks
I tried to look everywhere for help on this but didn't find any examples.

Lastly, your contact page is still linking to the old forum post: https://mkvtoolnix.download/community.html

Thank you.

[Mosu]

mkvmerge treats chapters completely differently than regular tracks. This means that all calculating operations on chapters are pretty hacky and not tested well.

Use the chapter editor, open the chapters, right-click on the top-most item, select "Additional modifications" from the popup menu, enable "Multiply start and end timestamps…". Calculate 23.976/24 and enter the result in the dialog.

I'm not keen on giving a lot of examples. It's better to understand what you're doing/what you're calculating, 'cause then you don't have to look for the exact example matching your current use case, but you can calculate it yourself. If your original video track plays at x FPS, and your new one at y FPS, then the factor to use is always x/y. If you're going from 23.976 FPS to 24 FPS you play _more_ frames per second meaning same number of frames will result in a _shorter_ video meaning the resulting factor for adjusting other tracks to the new rate must be < 1. That's your check to see if you swapped the two values.

I'll fix the link. Thanks.

[Mosu]

Addendum: which MKVToolNix version are you trying the chapter sync with? 'cause there was a pretty important fix in v53 for --chapter-sync.

I also just tried the following:

mkvmerge -o out.mkv --chapter-sync 0,0.999 in.mkv

with v53 and the resulting chapter timestamps in out.mkv are just; they're exactly the original timestamps * 0.999.

[Perenista]

*******
PnS Rotate Y- flips horizontally
*******

I noticed a video I have here needs me to apply this MPC-HC feature, which also doesn't seem to work with madVR, only Enhanced Video Renderer. Alt + num 6 will do the trick.

I was wondering if it's possible to apply this without reencode, and using MKVToolnix. The file is a Matroska.

Or perhaps a lossless change as suggested here:
https://stackoverflow.com/questions/25031557/rotate-mp4-videos-without-re-encoding

However this one only applies to MP4.

[Barabba]

Hi, I?ve some mp4 produced by an Hikvision DVR that I want to join.. they are without timestamps, as the the recorder don't care do well pack the mp4 before close it, so it's up to the software solve this problem. Avidemux doesn't accept these files, so I try to join to mkv but the result isn't so good, half of the video is "masked/corrupted" and it appears only when people are passing by it. I attach 2 files here, maybe they can be helpful to solve the problem, if possibile.Thanks
https://drive.google.com/file/d/1WIwtbO7VYG_7SoXzzY6AfM6Vylxzos23/view?usp=sharing

PS: if you may suggest me a way to correct the problem, maybe a command line with ffmpeg, I'll be glad to try. Thank you!
PS2: I've the latest version 53

EDIT: I can solve the error in files using this command: ffmpeg -err_detect ignore_err -i 1.mp4 -c copy output.mp4
I suppose you use ffmpeg too to manage and merge mp4 files, may you please introduce che chance to apply a ffmpeg command to any input file boefore processing? It would be great to have a batch/gui interface to do that.. thanks

[stax76]

I think there is a Unicode issue:


mkvextract .\unicode-🙂.mkv tracks 1:.\unicode-🙂.aac


Error: Unknown mode '.\unicode-🙂.aac'.

[Mosu]

I think there is a Unicode issue:

Thanks, that should be fixed now.

[stax76]

Thanks! :thanks:

[Mosu]

Heya,

again I'm releasing a bit early, not even four weeks after the previous one. This release, however, does pack quite a bit more of a punch than the previous ones, both in terms of enhancements and bug fixes. On top of that one of the libraries used (libEBML) has just been released fixing several heap overflow bugs, and I didn't want to wait too long to get those fixes into a new MKVToolNix release.

There have been several changes concerning package maintainers. Please refer to the NEWS below for details.

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 54.0.0 "F Maj Pixie" 2021-02-26
New features and enhancements

mkvmerge: added support for using ISO 639-3 language codes in IETF BF47 language tags. Part of the implementation of #3007 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3007).
mkvmerge: AC-3 parser: added support for byte-swapped AC-3 data. Implements #3022 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3022).
mkvmerge: Matroska reader: for audio tracks that have the bit depth track header set mkvmerge will now keep that header even for codecs that don't require it for decoding. Implements #3009 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3009).
mkvmerge: MPEG transport stream reader, PCM audio tracks: mkvmerge will now re-order the channels for 5.1, 7.0 and 7.1 channel tracks from the Blu-ray layout to the WAVEFORMATEXTENSIBLE layout expected in Matroska. Patch by Tom Yan. Implements #2988 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2988).
mkvmerge, mkvinfo, mkvpropedit, MKVToolNix GUI: added support for the following new track header elements: "hearing impaired" flag, "visual impaired" flag, "text descriptions" flag, "original" flag, "commentary" flag. Implements #3011 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3011).
MKVToolNix GUI: added support for using ISO 639-3 language codes in IETF BF47 language tags. As there are several thousand of them, they're deactivated by default and must be activated in the preferences ("GUI" → "Often used selections" → "Languages"). Part of the implementation of #3007 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3007).
MKVToolNix GUI: multiplexer: when adding Blu-rays the user can select multiple playlists to add simultaneously in the "select playlist to add" dialog. Implements #2961 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2961).
MKVToolNix GUI: multiplexer: the file name extensions "eb3" and "ec3" were added for Dolby Digital Plus & "mpl" for Dolby TrueHD in the file dialogs. Part of the implementation of #3027 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3027).
MKVToolNix GUI: multiplexer: when adding multiple files the dialog asking the user what to do with them has gained a new checkbox. If enabled, all files containing at least one video track will always be placed in newly created multiplex setting. Implements #2966 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2966).
MKVToolNix GUI: multiplexer: added a menu entry in the "Multiplexer" for adding all files that are currently in the clipboard. Implements #3006 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3006).

Bug fixes

all: Windows: fixed compatibility with gettext 0.21 and newer on mingw.
all: Windows: fixed several of the programs having problems with certain Unicode characters (primarily emojis) in file names (e.g. mkvextract wrongfully complaining about an "invalid mode" or the GUI not being able to find parts of Blu-ray file structures).
mkvextract: AAC: fixed wrong channel mask field in the ADTS headers for 7.1 channel layouts. Fix by Tom Yan. Fixes #2636 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2636).
mkvextract: h.265/HEVC extraction: if the first frame starts with the parameter sets (SPS, PPS & VPS), the ones from CodecPrivate aren't written and the ones from the first frame are kept. Fixes #3031 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3031).
mkvmerge: fixed the calculation of chapter timestamps read from NTSC DVDs. Fix by Tom Yan.
MKVToolNix GUI: IETF BCP 47 language widget: the language combo box will now always contain the language code the user enters in the free-form field, even if it isn't in the list of often-used languages the user configured in the preferences.
MKVToolNix GUI: multiplexer: when browsing for the destination file name the default directory is now chosen according to the preferences regarding how the destination file name should be formed. For example, if the policy is set to "fixed output directory" then that output directory will be the one initially set when the directory selection dialog is opened. Fixes #3021 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3021).
MKVToolNix GUI: multiplexer: fixed the removal of appended source files if the "delete source files" end-of-job action is enabled. Fixes #3029 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3029).
MKVToolNix GUI: chapter editor: when importing chapters from DVDs the IETF BCP 47 language elements will be set, too, not just the legacy language elements.

Build system changes

libEBML v1.4.2 and libMatroska v1.6.3 are now required. The optional, bundled copies of both libraries have been updated to those versions. This bump in requirements fixes several heap overflow bugs in libEBML.
MKVToolNix is now using the C++17 library feature "file system library" instead of Boost's "file system" and "system" libraries. For the GNU Compiler Collection (gcc) libstdc++ this means v8 or newer is required; for clang's libc++ it means v7 or newer. For macOS this means that provided disk image will only run on 10.15 "Catalina" or newer.


Have fun :)

[manolito]

Thanks for the new version... :D

I found one small issue (using the 32-bit portable version under Win7-64):
After overinstalling over the previous version keeping the old INI file the program always hangs when trying to open a file via right-click in the source window. Drag and Drop with Explorer works.

What fixed it was deleting the old INI file and reentering my settings. Must be some inconsistency with the INI entries between the old and the new version. No big deal...

[Mosu]

Too bad you removed the file. I would surely have liked to take a look at the issue, but without… Well.

[manolito]

Just repeated the installation on another ThinkPad with almost identical setup. No problems with this one, and I believe it has something to do with the font size setting.

The laptop which had no issues uses a font size of 100%. The other one which had the issues has a higher resolution screen and uses a font size of 125% (my eyes getting a little old). And this bigger font size made the difference.


//EDIT//
Oh damn, I mixed it all up...
The laptop which had the issue also uses a display setting of 100%. What I did to improve readability was to reduce the screen resolution from the native 1600x900 to a smaller resolution of 1360x768. This usually does not cause problems, but the Qt library might behave differently.

//EDIT2//
If you still want to look at my previous INI file, I do have Rollback RX installed so I can easily retrieve the old INI file and upload it. Let me know...

[Mosu]

Yeah, I don't support such low resolutions. The GUI has certain minimum required sizes that depend on the active language (as labels, combo box contents etc. have different lengths in different languages). There will be weird interactions if the automatically stored/remembered frame positions & sizes don't fit into the screen anymore and similar things. Nothing I want to spend time on.

[manolito]

Still a little bit weird...

The laptop which has no problems has a screen resolution of 1280x800. The other one which showed the problem has a resolution of 1360x768. This is in the same ballpark for me, and both resolutions are certainly HD resolutions.

So I don't really understand why one of these screen resolutions works and the other does not... :confused:
Well, at least it does work after deleting the INI file, so no real problem...

[ryrynz]

Still a little bit weird...


Attempt recovery of the ini imo.

[DavidRyan]

Hi - Thanks for the continued development of this very useful tool.

Wanted to add that I have the same issue as reported above with v54.0. I usually open sources via the 'Add source files' button but doing that in this version results in the application hanging and having to be killed. Folders/sources don't appear, it just hangs. This is on a laptop with a 1920*1080 display with text/apps display set to 125% if that matters, saw it mentioned above.

I can still use mkvtoolnix by dragging and dropping sources. And I guess a clean install may resolve the issue if that worked for others. But before I do that if you want me to send in the configuration settings file let me know.

[kuchikirukia]

I used to be able to cut off audio/sub tracks that ran longer than the video with the split function. This no longer works.

>have 22:09 video
>audio and sub tracks are 23:40 because they have an ending I cut from the video
>set to split after 22:09
>Doesn't split.

[Mosu]

Wanted to add that I have the same issue as reported above with v54.0. I usually open sources via the 'Add source files' button but doing that in this version results in the application hanging and having to be killed.

Can you please do two things:

Upload your settings file (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Location-of-settings,-job-queue,-cache-folder) to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server). Include your user name in the file name (or create a directory with your name) so I can associate it with you.
Get the latest continuous build (https://mkvtoolnix.download/windows/continuous/64-bit/54.0.0/) and give that one a try. I've fixed several issues over the last couple of days that may very well be the cause of what you observed. Try this without deleting the settings file first.

Thanks.

[Mosu]

I used to be able to cut off audio/sub tracks that ran longer than the video with the split function. This no longer works.

Nothing has changed wrt. splitting for a long time now. If it worked before for you, that was certainly by accident, or the situation was subtly different with the files.

[DavidRyan]

Can you please do two things:

Upload your settings file (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Location-of-settings,-job-queue,-cache-folder) to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server). Include your user name in the file name (or create a directory with your name) so I can associate it with you.
Get the latest continuous build (https://mkvtoolnix.download/windows/continuous/64-bit/54.0.0/) and give that one a try. I've fixed several issues over the last couple of days that may very well be the cause of what you observed. Try this without deleting the settings file first.

Thanks.

OK, I've:
- Uploaded settings file to your server, folder named "DavidRyan"
- Tried the latest continuous build and sources open fine from the button now. Tried a couple of times (as wasn't sure if it worked once last time and then failed or failed from the time I used the build) and all seems good so far.

Thanks.

[Mosu]

Great. Thanks for the feedback.

[Atlantis]

Language is not recognized. When adding movie.English.srt for example, it doesn't recognize English. It worked with the previous versions.

[Atlantis]

What has happened to this software. It's been 2 hours I'm unable to add a subtitle with MKVToolNix recognizing the language. Tried almost everything .English.srt .en.srt .eng.srt in () and other stuff. It does not recognize.

[ryrynz]

What has happened to this software.

Revert to an earlier version until it's fixed or someone can help.

Windows (https://mkvtoolnix.download/windows/releases/)
macOS (https://mkvtoolnix.download/macos/)

[Atlantis]

So everyone has this problem too or is it just me?

Update: I just went to 53 and it is working. The problem is with 54. It was driving me crazy.

[videoh]

What has happened to this software. Be patient and let Mosu do the needful. Improvements very often come with temporary regressions. IMHO, it's a fair price to pay for improved functionality and new features.

[Mosu]

I can reproduce it with default settings & will look into it. As a workaround:

Open the preferences, go to "Multiplexer" → "Deriving track languages"
Under "Recognized languages" remove all languages from the "selected" list
Under "Recognized languages" re-add those languages you want recognized back to the "selected" list

The default is to recognize all languages. That doesn't seem to work anymore (v54 added tons of new language codes).

[Mosu]

Technical details why it isn't working out-of-the-box with v54. The problem is a combination of two separate issues.

v54 added ISO 639-3 language codes. That list is loooong: 7.143 entries. Those codes should be deactivated by default in order not to overwhelm users. The user has to enable them in the "Often used selections" part of the GUI's preferences.

Unfortunately the "deriving track languages" selection always includes all 639-3 codes, no matter what the checkbox in the "often used selections" is set to. This is the first issue.

For deriving the track languages the GUI creates a regular expression (regex) of all the possible matches; usually both the two- and three-letter-codes and their English names (so that it'll recognize "fr", "fre" and "French" for… well… French, obviously).

Now, if all 7.143 languages are enabled (which they are by default) the resulting regex is a bit bigger than 100 KB. While there are regex engines that can handle such large regexes, the one used by the Qt project (the well-known "pcre" = Perl-compatible regex library) can't, or at least not without recompiling it — its limit is at 65.535 bytes (yeah, they use two-byte numbers for string offsets).

And that's issue two.

The first issue is easy enough to fix. The second, however, is a problem as I have to redesign how the GUI derives languages. I definitely cannot use a regex of all enabled languages; it'll have to be something else.

Luckily there's an easy workaround: deactivate most languages in the "deriving track languages" preferences and only enable those you actually want to use.

[DavidRyan]

Just been trying out the new IETF BCP 47 language tags, and I would appreciate any feedback in terms of best practice. I identified an audio track as the Hokkien / Min Nan dialect as spoken in Taiwan, so used the "nan" tag. I got the warning that it was a valid tag but would show up as "und" in applications which don't support this yet. Which is fine, would rather my files were tagged correctly and other apps will surely catch up in time. But I notice in the header editor there is also that entry for language which is currently "und", in the line above:

https://images2.imgbox.com/5b/01/74isCHhI_o.png

I read your recent wiki on languages which specified that mkvpropedit would also fill in the legacy tag based on the BCP 47 tag, but that mkvtoolnix wouldn't at this stage - if I do it myself and put, say, "chinese" in this example, would there be any problem with that? Just wanted to check before tagging a bunch of files.

[Atlantis]

Please add support for recognizing forced subtitles. Like:
movie.English.Forced.srt

[Mosu]

if I do it myself and put, say, "chinese" in this example, would there be any problem with that?

That should be fine. My goal was twofold:

Do the right thing automatically whenever possible.
Don't force the user to make too many choices.

The first goal was met by always providing the BCP47 language control and deriving the legacy language to set from the BCP47 value.

The second goal was met by not providing extra controls for the legacy language controls.

Of course the drawback is that the user loses fine-grained control for cases where there is no way to set the legacy value correct automatically. That's a drawback I was willing to make.

From the point of view of the specs, though, there are no restrictions set on the BCP47 and corresponding legacy elements. You could set BCP47 to German and legacy to Spanish, for example; wouldn't make much sense, but it wouldn't violate the specs either.

And that's where it ties back to you: the choice of using "und" for legacy for BCP47 values that don't have an ISO 639-2 code was meant as a default. You're free to change the legacy values to "chi" or whatever else fits your need best. Both the GUI's header editor as well as mkvpropedit allow editing the legacy value independently of the BCP47 value for that purpose.

[Mosu]

Please add support for recognizing forced subtitles. Like:
movie.English.Forced.srt

I won't.

[DavidRyan]

And that's where it ties back to you: the choice of using "und" for legacy for BCP47 values that don't have an ISO 639-2 code was meant as a default. You're free to change the legacy values to "chi" or whatever else fits your need best. Both the GUI's header editor as well as mkvpropedit allow editing the legacy value independently of the BCP47 value for that purpose.

Great, thanks

[Atlantis]

I won't.
Could you please explain more why not?

[Mosu]

Could you please explain more why not?

Because it's hard to get right (= without having files flagged that use the word "forced" somewhere but which is actually part of the movie title) and I simply don't want to spend the time.

[kuchikirukia]

Neat, I just figured out you can copy cells from the info tool. There's no indication that you can do this since clicking in it highlights the entire row, and there's no right-click "copy" option.

I've been manually entering the timestamps for the segment ending in ordered chapters for a couple years now when apparently I could've copy/pasted it the whole time.

Oh, minor quibble, but entries in the chapter editor don't stick unless you click on another chapter or Edition Entry.

>Open two chapter files in separate tabs
>copy and paste one chapter 2 start time to its chapter 1 end time
>move to the second chapter file tab
>Use the "copy to other tab" function to copy a chapter over
>go back to the other tab. Chapter 1 end time is still showing, but if you click out of it it disappears.

[Mosu]

Neat, I just figured out you can copy cells from the info tool. There's no indication that you can do this since clicking in it highlights the entire row, and there's no right-click "copy" option.

That's functionality that's built into Qt. It isn't MKVToolNix-specific.

Oh, minor quibble, but entries in the chapter editor don't stick unless you click on another chapter or Edition Entry.

Yep. That's by design, mostly, and not something I'm willing to spend time on.

[Perenista]

Why is it that now MKVToolnix can't split files that use diacritical signs without messing with the filenames?

This bug was not happening in prior versions.

I tried splitting two different files and the bug appeared in both.

The last file I checked had the acute accent. MKVToolnix changed this:

*************
á
*************

Into this:

*************
á
*************

Using: Windows 10-64 bit.

Note: I told this program (54.0.0) to split a 15.8 GB MKV into two parts with 15200M each one. That was needed to fit a single Google Drive free 15 GB account (so 14.84 GB).