MKVToolNix v100.0 released

[Mosu]

Interesting. Another user reported the same problem (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3049) (splitting has nothing to do with it). Unfortunately I haven't been able to reproduce the issue. I can use non-ASCII characters just fine, both German Umlaute, accented French characters, various Asian characters and Emojis.

So far I haven't received any more information that was useful in tracking it down either. So… yeah.

(Two minutes later.)

Ooooh I just stumbled across one instance where this happens: when the destination file name is set to a name with non-ASCII characters and you press the "browse" button to the right of the, the pre-selected file name will have its non-ASCII characters mangled. I'll fix that.

How exactly did you end up with the mangled characters? Can you give me an exact list of the steps you took? Maybe even record a screencast? Thanks!

[Mosu]

…and it DOES have something to do with splitting. Those are two separate issues after all.

[Mosu]

Both problems have been fixed in the latest continuous builds (https://mkvtoolnix.download/windows/continuous/).

[Mosu]

Heya everyone,

wait! We've just had a release of MKVToolNix. What's up with doing another one so soon? Well, thing is, that previous release is buggy. Quite a bit. It included three major changes to its internals: the change from boost::filesystem to std::filesystem, the extension of languages to include ISO 639-3 codes and a complete rewrite how file identification works in the GUI.

The first of those rewrites caused a lot of pain for users on Windows. First of all UNC paths such as \\server\share\directory\file.mkv didn't work at all: the GUI might hang, not remember the most recently used directory, refuse to create missing directories, things like that. Second, there were several situations in which non-ASCII characters (think German Umlauts, Asian characters, Emojis) were mangled. Users are constantly opening new issues in my bug tracker which is always a good indicator that quick bug fix release is warranted.

The other two rewrites also caused bugs that, while not as severe, were annoying, too. This release includes fixes for them, too.

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 55.0.0 "Waiting For Space" 2021-03-06
Bug fixes

all programs, only on Windows: fixed checking existence of & creating directories with UNC paths such as "\\server\share\folder\file.mkv". Fixes #3041 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3041).
all programs, only on Windows: implemented several workarounds for bugs in "std::filesystem" wrt. UNC paths. The effect of those bugs was that Blu-rays and DVDs couldn't be added from UNC paths. Fixes #3037 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3037).
mkvmerge, only on Windows: fixed non-ASCII characters getting mangled in the destination file name when splitting is active.
MKVToolNix GUI, only on Windows: fixed the GUI hanging when trying to browse for files on drives that don't actually exist. Fixes #3046 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3046).
MKVToolNix GUI, only on Windows: the GUI did not remember UNC paths as the "most recently used source directory" properly.
MKVToolNix GUI: only on Windows: when dragging & dropping files from other applications to MKVToolNix GUI the GUI will force the drop action to be a copy action, no matter which keys were pressed by the users. This prevents Windows Explorer from deleting the dragged file when the user presses shift while dropping the file onto MKVToolNix GUI.
MKVToolNix GUI, only on Windows: when using the file dialog for selecting a file name to save to (e.g. when browsing for the destination file name in the multiplexer or saving an attachment in the header editor) non-ASCII characters in the default file name were mangled. Fixes #3049 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3049).
MKVToolNix GUI: multiplexer: the user can now configure what to do when using the "Add source files" button independently of the setting for what happens when files are dragged & dropped onto the GUI. The same options are available, but they're distinct settings, allowing for different use cases. Fixes #3035 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3035).
MKVToolNix GUI: multiplexer: deriving the track language from file names doesn't use one big regular expression of all enabled languages anymore. Instead, the file name is split into parts on a list of characters (such as "." or "(" and ")"; configurable in the preferences). This prevents the regular expression becoming too big for the regular expression library to handle when many languages are enabled. Fixes #3048 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3048).
MKVToolNix GUI: preferences: the language lists for "deriving track languages" and "enabling items by language" always included all the ISO 639-3 languages, even if those weren't enabled in the "often-used languages" pane. Fixes #3047 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3047).

Other changes

mkvmerge, MKVToolNix GUI multiplexer: the functionality for changing the length of the NALU "size" field for AVC/H.264 and HEVC/H.265 tracks has been removed. The corresponding command-line option will continue to be recognized by mkvmerge as not to break existing third-party applications, but it won't actually do anything.


Have fun 😊

[Perenista]

https://i.postimg.cc/sfkvXFzW/11x.png

Subtitles:

I configured MKVToolnix to consider every subtitle added to a MKV as english (default language). However depending on the filename this is ignored (if I am not mistaken) and MKVToolnix assumes it's language X. For example: portuguese.

However renaming the file to something like this:

File #1 - The Adventures-en.srt
File #2 - The Adventures-pt.srt

Isn't working. If I add file #2 MKVtoolnix will still say the language from the file is ENGLISH.

Even if I rename to this:

The Adventures-portuguese.srt

It will also say it's ENGLISH.

So, considering I only need to type EN or PT in the "free form input", why is it the filename:

The Adventures-pt.srt

Isn't automatically considered portuguese and the default option I configured ignored?

Or perhaps I am forgetting some internal setting?

[Mosu]

For v55 you have to be aware of the following:

The algorithm has changed. The old algorithm used a regular expression looking for the languages enabled for track language detection. The new algorithm splits the whole file name on certain characters (called "boundary characters" in the preferences) and starts looking for a language from right to left.
The new "boundary characters" do not contain dashes ("-") by default. Therefore the new algorithm doesn't split "The adventures-pt" into two entries "The advenctures" and "pt"; instead it thinks this is one big entry. Obviously there's no language called "The adventures-pt". You can add the dash to the "boundary characters" in the preferences.
v55 contained a bug: it compared languages case sensitively (meaning it wouldn't detect "PT" as the internal entry is called "pt"). This is different than how the prior algorithm worked. I've fixed that issue since the release. You can get the latest continuous build (https://mkvtoolnix.download/windows/continuous/) for Windows.
Track language detection from file names has precedence over the default track language to use set in the preferences. This hasn't changed. The track language detection from file names simply didn't work for you due to points 2 & 3.

[Thunderbolt8]

would it be possible to move the "undetermined (und)" item from the often used language selection to the top of the list/let us configure the order of this list? I want to be able to set my language settings to English or German just with hitting 'e' and 'g', but when I do so it jumps to the next entry below the starting item "undetermined (und)" which is not either of those and I always have to use the mouse then to get to scroll up again. if the entry "undetermined (und)" was at the top, then just hitting 'e' or 'g' would get me there directly and with less hassle. I remember that it worked this way in older builds.

[Mosu]

I will definitely not implement letting you configure the order of those entries as that leads to a LOT of corner cases & requires way too much work to implement.

You're right insofar as there's special handling for "und": it will be included at the top if and only if:

"Only include often used selections" is off and
"und" is NOT part of the "often used languages".

This behavior hasn't changed for ages.

Another tip: you can press the Home/Pos1 key to jump to the first entry in the list, then hit "e" or "g" for English or German.

[fAy01]

Hello,

Thanks for creating this amazing tool. I really appreciate it. I've run into a problem because I am not too familiar with mkvmerge because I usually use the gui. I want to combine three files but I have encountered an issue related to mapping.
I get the following error with this command: "C:\Program Files\MKVToolNix\mkvmerge.exe" -o "nhk_01.mka" "nhk_op_01 - DELAY -66ms.ac3" + "nhk_01 - DELAY -261ms.ac3" + "nhk_ed_01 - DELAY -219ms.ac3"

D:\XT1864>"C:\Program Files\MKVToolNix\mkvmerge.exe" -o "nhk_01.mka" "nhk_op_01 - DELAY -66ms.ac3" + "nhk_01 - DELAY -261ms.ac3" + "nhk_ed_01 - DELAY -219ms.ac3"
mkvmerge v55.0.0 ('Waiting For Space') 64-bit
'nhk_op_01 - DELAY -66ms.ac3': Using the demultiplexer for the format 'AC-3'.
'nhk_01 - DELAY -261ms.ac3': Using the demultiplexer for the format 'AC-3'.
'nhk_ed_01 - DELAY -219ms.ac3': Using the demultiplexer for the format 'AC-3'.
'nhk_op_01 - DELAY -66ms.ac3' track 0: Using the output module for the format 'AC-3'.
'nhk_01 - DELAY -261ms.ac3' track 0: Using the output module for the format 'AC-3'.
'nhk_ed_01 - DELAY -219ms.ac3' track 0: Using the output module for the format 'AC-3'.
No append mapping was given for the file no. 1 ('nhk_01 - DELAY -261ms.ac3'). A default mapping of 1:0:0:0 will be used instead. Please keep that in mind if mkvmerge aborts with an error message regarding invalid '--append-to' options.
No append mapping was given for the file no. 2 ('nhk_ed_01 - DELAY -219ms.ac3'). A default mapping of 2:0:1:0 will be used instead. Please keep that in mind if mkvmerge aborts with an error message regarding invalid '--append-to' options.
The file 'nhk_01.mka' has been opened for writing.
Appending track 0 from file no. 1 ('nhk_01 - DELAY -261ms.ac3') to track 0 from file no. 0 ('nhk_op_01 - DELAY -66ms.ac3').
Appending track 0 from file no. 2 ('nhk_ed_01 - DELAY -219ms.ac3') to track 0 from file no. 1 ('nhk_01 - DELAY -261ms.ac3').
Progress: 100%
The cue entries (the index) are being written...
Multiplexing took 0 seconds.

1 - Is the delay applied by default or not?
2 - Is there an easier way to append audio files without the gui?
3 - Does my command achieve the same result or is it wrong? Since sync and append-to mapping is missing from mine.

However, copying the command from gui it's different and doesn't result in any errors.
D:\XT1864>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --output "D:\XT1864\nhk_op_01 - DELAY -66ms (1).mka" --language 0:ja --sync 0:-66 "(" "D:\XT1864\nhk_op_01 - DELAY -66ms.AC3" ")" --sync 0:-261 + "(" "D:\XT1864\nhk_01 - DELAY -261ms.AC3" ")" --sync 0:-219 + "(" "D:\XT1864\nhk_ed_01 - DELAY -219ms.AC3" ")" --append-to 1:0:0:0,2:0:1:0
mkvmerge v55.0.0 ('Waiting For Space') 64-bit
'D:\XT1864\nhk_op_01 - DELAY -66ms.AC3': Using the demultiplexer for the format 'AC-3'.
'D:\XT1864\nhk_01 - DELAY -261ms.AC3': Using the demultiplexer for the format 'AC-3'.
'D:\XT1864\nhk_ed_01 - DELAY -219ms.AC3': Using the demultiplexer for the format 'AC-3'.
'D:\XT1864\nhk_op_01 - DELAY -66ms.AC3' track 0: Using the output module for the format 'AC-3'.
'D:\XT1864\nhk_01 - DELAY -261ms.AC3' track 0: Using the output module for the format 'AC-3'.
'D:\XT1864\nhk_ed_01 - DELAY -219ms.AC3' track 0: Using the output module for the format 'AC-3'.
The file 'D:\XT1864\nhk_op_01 - DELAY -66ms (1).mka' has been opened for writing.
Appending track 0 from file no. 1 ('D:\XT1864\nhk_01 - DELAY -261ms.AC3') to track 0 from file no. 0 ('D:\XT1864\nhk_op_01 - DELAY -66ms.AC3').
Appending track 0 from file no. 2 ('D:\XT1864\nhk_ed_01 - DELAY -219ms.AC3') to track 0 from file no. 1 ('D:\XT1864\nhk_01 - DELAY -261ms.AC3').
Progress: 100%
The cue entries (the index) are being written...
Multiplexing took 0 seconds.

Kind Regards

[Mosu]

The messages you've cited aren't errors. There are hints that the program had to use default settings for the decision which track to append to which other track, and SHOULD the program emit any further error messages about track types etc., that you should keep those defaults in mind to better understand the error.

This doesn't happen with the GUI as the GUI tells mkvmerge explicitly which track to append to which other track via the "--append-to" parameter. It can do that because it shows you, the user, which tracks it will append to which other tracks, and you, the user, can easily drag & drop them around if the GUI's defaults don't work for you.

For most situations mkvmerge's defaults in case of missing "--append-to" parameters are just fine. It assumes that, when you have file1 & file2 with file2 being appended to file1 (think this: "mkvmerge -o out.mkv file1 + file2"), each n-th track of file2 will be appended to the n-th track of file1. If both files have three tracks (e.g. one video, one audio & one subtitle track, in the same order) this is exactly what you want the program to do.

So again, those messages are not errors. Errors are things where a line starts with "Error:".

[fAy01]

Okay. So what about Delay/Sync?

[Mosu]

mkvmerge has no automatism based on file names. It will neither try to detect an additional delay mentioned in the file name for the track languages. Those are things only the GUI does.

[Masutin]

About mkvpropedit and XML. Is there a way to add a section for the tags being added to appear in that section other than General?<Tags><Tag>
<Simple><Name>1</Name>
<String>a</String></Simple>
<Simple><Name>2</Name>
<String>b</String></Simple>
</Tag></Tags>

[Mosu]

Heyo everyone,

time for the April release of MKVToolNix. It's mostly a bug fix release focussing on improving a lot of fundamental functionality such as chapters & tags.

The most notable thing to have happened, though, is that the Windows version of MKVToolNix is now available from the Microsoft Store. It isn't free there, though, as it is meant to be a way for you to actively support the development of MKVToolNix (you get automatic updates in return). Please note that this is purely optional and will forever remain optional: completely free variants for Windows will always be available from the home page, just like in the past. See this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/MKVToolNix-costs-money-in-stores) for more information.

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 56.0.0 "Strasbourg / St. Denis" 2021-04-05
New features and enhancements

mkvmerge, mkvpropedit: tags: the programs will no longer write tag elements that are mandatory and set to their default value (e.g. "tag language" set to "und" = undetermined).
mkvmerge, mkvpropedit, MKVToolNix GUI chapter editor: chapters: the programs will no longer write chapter elements that are mandatory and set to their default value (e.g. "chapter language" set to "eng" = English or "Chapter flag enabled" = 1).
mkvextract: chapters: mkvextract will no longer add a "ChapterLanguage" element set to "eng" to the generated XML content if the source file doesn't contain such an element.
MKVToolNix GUI: multiplexer: when using the "tab widget below the files & tracks" layout option for the track properties the elements in the "general options" tab will use six rows à four columns instead of twelve rows à two columns, greatly reducing the required height. Implements #3062 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3062).

Bug fixes

mkvmerge: AAC reader: fixed mkvmerge aborting to read AAC files bigger than 2 GB with a message about not being able to allocate memory. Fixes #3059 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3059).
mkvmerge: chapters: "ChapLanguageIETF" elements were still created when the option "--disable-language-ietf" was given after an option leading to the creation of chapters. Now the position doesn't matter anymore. Part of the fix of #3069 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3069).
mkvmerge: chapters: when the option "--disable-language-ietf" is used, "ChapLanguageIETF" elements won't be written even when sources are read (Matroska files or XML chapters files) that do contain those elements. Part of the fix of #3069 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3069).
mkvmerge: tags: when the option "--disable-language-ietf" is used, "TagLanguageIETF" elements won't be written. Fixes #3070 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3070).
mkvmerge: tags: mkvmerge will no longer write language elements for the track statistics tags it creates, making the effective language "undetermined" due to "und" being the default value for the legacy tag language element. Fixes #3073 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3073).
mkvmerge: tags: the XML tag parser will now validate all "&lt;Simple>" children of "&lt;Tag>" elements, not just the first for each "&lt;Tag>". Part of the fix of #3071 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3071).
mkvmerge: tags: the XML tag parser now uses the spec-compliant "und" ("undetermined") as the default language for "&lt;Simple>" tags instead of "eng". Part of the fix of #3071 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3071).
mkvmerge, mkvpropedit: tags: mkvmerge will no longer set the "target type" for track statistics tags (earlier it used "MOVIE"). The "target type value" will still be set to "50". Fixes #3074 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3074).
mkvmerge, mkvextract: HEVC/H.265: both programs will now normalize the placement of VPS, SPS and PPS NALUs. Each key frame is prefixed with exactly one copy of the currently active parameter sets. This fixes certain classes of bugs related to splitting/appending. Fixes #3034 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3034).
mkvinfo: when compiled with newer versions of the "fmt" library, certain numbers were not output correctly (e.g. a track's audio sampling frequency of 48000 might be output as 48).
MKVToolNix GUI: multiplexer: deriving the track language from the file name will match languages case insensitively again (like versions prior to v55). Fixes #3068 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3068).
MKVToolNix GUI: multiplexer: under certain circumstances keyboard shortcuts such as "Ctrl+W" for closing the active tab or "Ctrl+R" for starting to multiplex ceased to work until the user did certain other things (such as switching to a different tool & back to the multiplexer or opening the multiplexer menu). This started with v54. Fixes #3051 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3051).
MKVToolNix GUI: chapter editor: the editor will no longer create empty "ChapterCountry" elements when adding a chapter name with no default country selected in the preferences. Fixes #3072 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3072).

Build system changes

The bundled "fmt" library was updated to v7.1.3.


Have fun :)

[rco133]

Hi.

I know it is a long time since it has been changed, and it is the reason why I am still using an older version. Would like to update though.

Is there any way to get the language selection to work like before?

In older version when adding a track, and wanting to change track name and Language, once one had entered the track name, one could just press TAB and then enter "eng" or "fre" to change the language.

Now, one have to physically click the language or the pencil with the mouse, to get into a menu, where one can then type for example "fre" to change the language.

I am sure this was changed for a reason. But it just means that instead of all being done from the keyboard, one will have to use the mouse to click on the language and open the menu to change it.

When I have entered the track name and press TAB, it seems to move to the square with the pencil in it. But pressing Enter doesn't open the menu. Only a mouse click will open the menu.

Is this by design?

Hope my explanation makes sense.

rco133

[Mosu]

Is there any way to get the language selection to work like before?

No, and there won't be.

But it just means that instead of all being done from the keyboard, one will have to use the mouse to click on the language and open the menu to change it.

Nope, you just have to adjust a bit. First, go to the preferences → "GUI" → "Layout" and change "Default IETF BCP47 language editing mode" to "Individually selected components". Now the keyboard sequence becomes:

Starting on the "Track name" input (which you can focus by pressing ALT+K, BTW, at least with the English interface language), press TAB.
You're now on the language edit button. Press SPACE.
The dialog will have opened. The focus is already on the "Language" drop-down box. Therefore simply type the language code just like you did before.
When done, press ENTER which closes the dialog.

One SPACE, one ENTER more than before.

Edit: you could also go with the free-form editing mode instead of the "individually selected components". That way you can enter the code directly, whichever code it is, no matter if the language is part of the "often used languages". For languages that have two-letter codes (such as "en" for English or "fr" for French), this is potentially even quicker.

[rco133]

No, and there won't be.



Nope, you just have to adjust a bit. First, go to the preferences → "GUI" → "Layout" and change "Default IETF BCP47 language editing mode" to "Individually selected components". Now the keyboard sequence becomes:

Starting on the "Track name" input (which you can focus by pressing ALT+K, BTW, at least with the English interface language), press TAB.
You're now on the language edit button. Press SPACE.
The dialog will have opened. The focus is already on the "Language" drop-down box. Therefore simply type the language code just like you did before.
When done, press ENTER which closes the dialog.

One SPACE, one ENTER more than before.

Edit: you could also go with the free-form editing mode instead of the "individually selected components". That way you can enter the code directly, whichever code it is, no matter if the language is part of the "often used languages". For languages that have two-letter codes (such as "en" for English or "fr" for French), this is potentially even quicker.

Thank you for the tips. Guess I tried everything else than pressing the SPACE bar once the pencil box had been selected.

No problem at all to do one SPACE and one ENTER extra. It was that I had to use the mouse that was kinda annoying :-)

rco133

[ChaosKing]

Congrats on the Microsoft Store release. The store updates are the opposite of windows updates, they are not annoying! The update magic silently happens in the background.:thanks:

[ChaosKing]

at the moment it isn't possible to run the command-line tools when the app is installed from the Windows Store. See this FAQ entry for details.

For the CLI part. I looked at the store 7zip package (https://www.microsoft.com/de-de/p/7-zip-file-manager-unofficial/9mz81rmk8jfd?activetab=pivot:overviewtab) (7z works from console) and found this in the AppxManifest.xml

<Applications>
<Application EntryPoint="Windows.FullTrustApplication" Executable="7zFM.exe" Id="zFM.exe" desktop4:Subsystem="console" desktop4:SupportsMultipleInstances="true">
<uap:VisualElements BackgroundColor="transparent" Description="7zFM.exe" DisplayName="7-Zip File Manager" Square150x150Logo="Assets\zFM.exeSquare150x150Logo.png" Square44x44Logo="Assets\zFM.exeSquare44x44Logo.png">

</uap:VisualElements>
<Extensions>
<rescap3:Extension Category="windows.desktopAppMigration" EntryPoint="Windows.FullTrustApplication" Executable="7zFM.exe">
<rescap3:DesktopAppMigration>
<rescap3:DesktopApp ShortcutPath="%APPDATA%\Microsoft\Windows\Start Menu\Programs\7-Zip\7zFM.exe.lnk" />
<rescap3:DesktopApp ShortcutPath="%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\7-Zip\7zFM.exe.lnk" />
</rescap3:DesktopAppMigration>
</rescap3:Extension>


<uap5:Extension Category="windows.appExecutionAlias" EntryPoint="Windows.FullTrustApplication" Executable="7z.exe">
<uap5:AppExecutionAlias desktop4:Subsystem="console">
<uap5:ExecutionAlias Alias="7z.exe" />
</uap5:AppExecutionAlias>
</uap5:Extension>
</Extensions>
</Application>
</Applications>

[Mosu]

That's great, thanks. I'll try to extend my package accordingly.

[Mosu]

Got it! Uploading a new build to the Microsoft Store as we speak. All command-line applications will be runnable in the future. Thanks again for the pointer!

[Thunderbolt8]

I encountered a problem when muxing a HEVC HDR & EAC3 video file. basically the process stopped at 35% and said "failed". cant tell if related to the latest version as I only tested it with this one. is there any kind of error log?

btw. I tried to use file splitting here (max. 2 files, but the error occured before the splitting point was reached. I tried not to use splitting thrice, then the error occured at 35%, and 2x at 98%.

[Mosu]

That sounds… interesting. Might be a bug, might be bad hardware. Can you upload the source file(s) in question to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server), please? And paste the command line of how your mux job was set up? Thans.

[rsotome]

MKVToolNix v56, does the newest build no longer write the language to the chapters?

When muxing an mkv, whether using a .txt or .xml chapter file, I have the setting under output language, set to English (eng), but the info doesn't show up under mediainfo.

Now if I use JMKvpropedit to stip out the chapter info of the muxed video & then add it back in, the language is properly ID'd under the chapters as en:, plus the chapter name.

[rco133]

MKVToolNix v56, does the newest build no longer write the language to the chapters?

When muxing an mkv, whether using a .txt or .xml chapter file, I have the setting under output language, set to English (eng), but the info doesn't show up under mediainfo.

Now if I use JMKvpropedit to stip out the chapter info of the muxed video & then add it back in, the language is properly ID'd under the chapters as en:, plus the chapter name.

Hi.

v56 defenately behaves different than v55 in this matter.

v55 has en:Chapter while v56 just has :Chapter

The changelog mentions this:

* mkvmerge, mkvpropedit, MKVToolNix GUI chapter editor: chapters: the programs
will no longer write chapter elements that are mandatory and set to their
default value (e.g. "chapter language" set to `eng` = English or "Chapter
flag enabled" = 1).

Not sure if thats the reason.

[Mosu]

Well, the chapter language element is a mandatory element with a default value of "eng". What this means is that any reader MUST use the value "eng" if the chapter language element is not present in a "ChapString" parent. If MediaInfo doesn't follow that rule, that's a bug in MediaInfo.

rco133 has correctly identified the news entry relating to this change.

[Thunderbolt8]

That sounds… interesting. Might be a bug, might be bad hardware. Can you upload the source file(s) in question to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server), please? And paste the command line of how your mux job was set up? Thans.the source file is 31Gg though. would it still fit? and can the upload be resumed?

[Mosu]

The server has more than enough space, and upload resuming is supported. Thanks.

[Perenista]

Am I wrong when I say that if I do this:

- Split a 89 GB Matroska file (4K resolution) into 15200M or 15300M parts;
- Then append all these parts...

The resulting file will somehow grow a few seconds longer, thus messing with audio sync in the middle?

Because that's exactly what happened here.

And no reports of any error with this job. I will try to create the original Matroska again, and repeat all previous steps.

But I am concerned now that splitting poses a serious risk of damaging the content forever, and if this is the only copy, then I need to identify what has caused this issue.

Because I've been doing exactly this: splitting and appending many different contents, yet I doubt I have seen this happening before.

The only change I did to the original MKV which was more or less 4 seconds shorter was to add a few audio/subtitle tracks. Mosu needs to clarify if splitting and appending sometimes breaks the file the way I described. Or perhaps I did something wrong during my edits...

*****
This is the file I just appended all 6 parts:

https://pastebin.com/dTMTJ70W

This is veeeeery odd. Because when I compare to a smaller one (4 GB, 1080p instead of 4K) the 1080p file has 3 hours, 51 minutes and 38 seconds. While the 4K has 3h51m42s.

For example, if we pause at these moments they will be different:

4K:
00:39:04.431

1080p:
00:39:04.282

******

4K:
02:08:46.470

1080p:
02:08:43.518

******

This can't happen. In the 2nd scene the moments should be the same. Not a 2-3 second difference between them.

I am now thinking this could be it:

4K:
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 23.976 (24000/1001) FPS

1080p:
Frame rate : 23.976 (24000/1001) FPS

1080p MEDIA INFO: https://pastebin.com/nDB5gZd7

Apparently MKVTOOLNIX inadvertently changed the FPS to something else, which could account for this abnormal result while appending the splitted 4K file.

Or it could be MAKEMKV's fault, while creating the Matroska.

I am going to have to redo this MKV, from the original 4K disc.

What is odd is that this disc shows the following info in the playlist report:

************
PLAYLIST REPORT:

Name: 00040.MPLS
Length: 3:51:36.549 (h:m:s.ms)
Size: 98,182,275,072 bytes
Total Bitrate: 56.52 Mbps

(*) Indicates included stream hidden by this playlist.

VIDEO:

Codec Bitrate Description
----- ------- -----------
MPEG-H HEVC Video 47387 kbps 2160p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 4000nits / HDR10 / BT.2020
* MPEG-H HEVC Video 2101 kbps (4.25%) 1080p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 4000nits / Dolby Vision FEL / BT.2020

************

So what is going on here?

*****
Update: confirmed: recreated MKV from the 4K disc (using MAKEMKV) has now 3h51m36s. I am going to do further tests to see if something changes.

MEDIAINFO:
https://pastebin.com/6pMt4ki9

Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS

Next tests:

- Check if using MKVToolnix adds a few more seconds to it, and/or change the FPS.

- I am going to add a few audio/subtitle tracks, and also rename the current ones internally.

MAKEMKV log says nothing wrong: https://pastebin.com/hJu80ZBx (ignore the A/V sync issue, it says this for every disc it tries to rip).

*****
Test result: changing the names of the tracks using MKVToolnix didn't mess with anything:

https://pastebin.com/jpGsrKNj

******
Next verification: add new audio/subtitle tracks.

Then once this is also OK, I'll try splitting and appending.

*******
New test also passed, which was adding new audio and subtitle tracks: https://pastebin.com/ucYccVVe

Again no change. Same fps, same 3h51m36s.

FINAL TEST GOING NEXT: splitting into 15300M parts and then appending. If this final test fails, then it's MKVToolnix's fault.

[Thunderbolt8]

The server has more than enough space, and upload resuming is supported. Thanks.done.

btw. my TV has trouble playing the file. it can be started, but then playback stops around 4mins.

[Mosu]

I encountered a problem when muxing a HEVC HDR & EAC3 video file. basically the process stopped at 35% and said "failed".

I haven't looked at your particular file yet, but I've fixed a rather serious bug in the HEVC code yesterday, and the symptoms you describe match what I was seeing in another issue (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3083). Can you please give latest continuous build (https://mkvtoolnix.download/windows/continuous/) a try? It contains said fix.

[Perenista]

I did everything again and didn't notice anything wrong with the audio sync. Looks like something wrong in the first attempt, or the rip failed somehow. So no bug from MKVToolnix. No problems splitting and then appending all 6 parts.

Yet I noticed something interesting:

https://i.postimg.cc/MGgqXqsn/BUG1.png

This is the file BEFORE I split anything:

https://pastebin.com/NMHFEsE4

Then I asked MKVToolnix to split into 15300M parts.

Part 1: https://pastebin.com/zM91VSkE
Part 2: https://pastebin.com/nzjt9LjE
Part 3: https://pastebin.com/iipEjchr
Part 4: https://pastebin.com/xkjeKAc6
Part 5: https://pastebin.com/fFWUKD2e
Part 6: https://pastebin.com/dx3Gy7Ri

As you can see all of them have the same information:

Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS

****
Now look what happens when files 1-2-3-4-5-6 are APPENDED:

https://pastebin.com/n4FfXuVG

Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 23.976 (24000/1001) FPS

What does that mean?

Also, as the first picture shows, the file when I didn't split was shorter. It had:

https://i.postimg.cc/bYGcssW-L/XU1.png

Now look what MPC says about the appended file:

https://i.postimg.cc/C1BPLf5q/XU2.png

And this is also reflected in the 6 splitted files. Because if we add 36+38+38+40+41+36 minutes, plus 161 seconds, that will result in 229 minutes, plus another 2 (120 seconds) = 231, then 41s = 231 minutes and 41 seconds. Or 3h51m41s.

I tried freezing the same frame/scene in all three. These two are both the same:

1080p small file:
01:35:01.167

4K file that had never been splitted.
01:35:01.167

The appended file is different. That same frame/scene is located at:

4K appended
01:35:01.641

Still, the 4K file has no signs of sync issues. So, we can all conclude it is the same content, and the length is different because the fps is different.

But... why is MKVToolnix doing this?

P.S. Another movie affected by this bug:

4K appended:

Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.904 FPS
Original frame rate : 23.976 (24000/1001) FPS

https://i.postimg.cc/ZnHJ2Jvj/111111111.png

1080p smaller file:

Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS

https://i.postimg.cc/XNkNpk1F/22222222222222222.png

As a result of this bug it's impossible to put any audio/subtitle track from 1080p smaller file into the 4K.

The resulting file is the same (I mean the content), but it grew 23 seconds.

The bug oddly changed the framerate to 23.904.

I know what was said here:

https://forum.doom9.org/showthread.php?p=1932607#post1932607

As one user pointed out. Still, that doesn't justify MKVtoolnix messing with the files only because we splitted and appended. If this doesn't work then I suggest the option is removed.

I will try to investigate if I can a) if this bug can happen again if I repeat all steps, and b) if an older MKVToolnix version creates the same scenario.

If this is something only the newer ones are causing then I'll have my answer: splitting and appended was broken. Or it could be due to the tracks involved.

4K has the following:

https://pastebin.com/Kxs74AEY

I have an old suspicion splitting and appending always worked, but when we introduced certain new codecs some of them created all these issues. Remember when I blamed MakeMKV for a few failures?

https://forum.makemkv.com/forum/viewtopic.php?f=1&t=23937

Of course I need to repeat ALL steps, including a new rip from the UHD disc, because this 4K for example had been splitted in August 2020. Ever since this date MAKEMKV and MKVTOOLNIX received many updates.

All these 4K discs are causing me a lot of troubles.

*******
Update: the bug has been confirmed. At least for my Matrix Reloaded UHD disc.

Splitting and appending causes the fps to change. This time into this:

Frame rate : 23.906 FPS
Original frame rate : 23.976 (24000/1001) FPS

I put the disc again through MAKEMKV. Then did all steps, and saved as MKV. As long as we don't split and append, then everything remains the same.

2h18m17s.

If we do split and then append, the length changes to 2h18m40s. Still that doesn't mess with the video/audio/subtitle sync, since these tracks were already all in sync with each other prior to the splitting and appending.

But that also means we won't be able to insert a new audio/subtitle track if these have been created for the old 2h18m17s content.

So, if you all wanted a proof that splitting and appending can cause an issue, this is it. And this time MAKEMKV isn't involved.

I'll just do a final check, I'll look into an old MKVToolnix version to see if splitting and appending are OK in it. Or if the bug is still there.

*********

I'll try this one:
https://mkvtoolnix.en.uptodown.com/windows/download/1690774

19.0.0
Dec 19th, 2017

Result: same issue, same lenght. Nothing changed:

Taxa de quadros : 23.911 FPS
Taxa de quadros original : 23.976 (24000/1001) FPS

[Mosu]

Hello again,

unfortunately the release I've done only four days ago contains a nasty bug in the HEVC/H.265 code, and people are hitting it in droves. Therefore I'm releasing a fix for that today.

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 56.1.0 "My Friend" 2021-04-09
New features and enhancements

mkvmerge: AAC: added support for LOAS/LATM files with channel configuration indexes 9–21 (e.g. channel count 22.2 for index 13) according to Rec. ITU-R BS.1196-7 & ISO/IEC 23008-3:2019. Fixes #3081 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3081).

Bug fixes

mkvmerge: HEVC/H.265 parser: fixed invalid memory access that could happen when reading certain types of HEVC data (e.g. with changing parameter sets mid-stream) from certain containers (e.g. Matroska). This bug was introduced in release 56.0.0. Fixes #3083 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3083).
mkvextract: AAC: mkvextract will now abort with an useful error message when the user tries to extract a track whose 'audio-specific config' element in "CodecPrivate" signals a number of channels of 7 or greater than 8 as that isn't supported by the ADTS format.

Build system changes

configure: the "--enable-ubsan" option hasn't actually enabled anything since release 39.0.0.


Have fun :)

[Perenista]

After doing some research I just found out why the length increased after splitting and appending.

The answer is precisely here:
https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2747

>>>>>> Appending Constant Framerate Videos results in a Variable Framerate Video with wrong duration

https://www.reddit.com/r/mkvtoolnix/comments/hjbb5d/fps_variable_with_mkvtoolnix/

Appending in my case changed the original file from CONSTANT to VARIABLE in the fps department.

That's why the length from the movie increased from 2h18m17s to 2h18m39s.

Do you have any idea when will this be fixed?

As you saw before, while this didn't mess with the file internally, it makes impossible for me, for example, to do this:


>>>>>>>>>>>>>>>>>>
- Extract any audio/subtitle track from a smaller 1080p rip...
and
- Insert (using MKVToolnix) into the big 4K file.
>>>>>>>>>>>>>>>>>>>>>

For example, say if I pause into scene A at 16 minutes and 1 second, in both files...

They will be frozen at the same spot, if I wanted to take a picture and compare both.

But if I do this at scene B located at 1 hour and 13 seconds then 4K's scene will have moved to 1h 1 minute, for example. More or less.

If this bug wasn't there, then both would be at 1 hour and 13s, not just earlier at 16m01s. This means as the movie progresses the 4K becomes out of sync with the smaller 1080p rip.

Meaning without the bug I can split and append as much as I want and there will be no change from CONSTANT to variable fps.

P.S. Contrary to what was said in that link, the bug was NOT fixed in 44.0.0, 1 year ago.

It's still there.

P.S. 2:

In that same link an user said:

>>>>>>> Did some further testing. After manually setting the Default duration to 24000/1001, MKVtoolnix finally muxed a file with the correct constant framerate and correct duration. It seems that the issue only occurs when you leave the Default duration field blank. <<<<<<<<<<

https://i.postimg.cc/xCx2xCbR/xx1.png

But why should I always have manually input this when splitting and appending? Couldn't you simply modify this program to always enforce the default fps without us having to type that?

I'll try splitting and appending again with this tweak, to see if it will work.

Remember I am talking about a MKV created by MAKEMKV from my UHD/4K disc.

So the resulting file is this:

Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS

Trying now (spliting and appending) with this setting:

https://i.postimg.cc/3JN9sZk7/XX1.png

I'll see if this works....

[Perenista]

LOL... it didn't work!

The file now has a constant fps, I manually inserted this while splitting and appending, and still it shows here

2h18m39s.

PASTEBIN from the appended 4K: https://pastebin.com/DV9pCuQt

I give up trying to understand what is going on.

hubblec told me "the splitting/appending issue comes directly from Matroska and has nothing to do with makemkv or MKVToolNix(MTX). It is a Matroska design issue".

The problem is there, but MediaINFO reads as this:

Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS

How is that possible? MEDIAINFO is being tricked.

I even inserted 24000/1001p for the 2nd track, which is 1080p (Dolby Vision).

[Lupin]

Hey I have encountered a strange problem after muxing a video.
I have ripped a video via youtube-dl. The video itself has a constant 23,976 fps but the mp4 shows a variable framerate.

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

Remuxing the mp4 to mkv using mkvtoolnix without setting a framerate results in a constant 23,976 fps like it should be.
However mediainfo now shows a delay relative to video of -88ms.
Playing the video I don't notice any delay.

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

If I set a framerate of 24000/1001 in mkvtoolnix the delay relative to video doesn't show up in mediainfo.

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

Now I'm a bit confused on what to believe. Normally remuxing doesn't change the streams but why does mediainfo report this delay in a simple remux? Is the delay already present in the mp4? Is it a bug of mediainfo? And why I'm not noticing any delay when playing the file?

[Nejiro]

Hello everyone, I inserted 5.1 PCM tracks in a mkv taken from an original bluray, I noticed that once put in the mkv container the audio sounds very quiet, almost inaudible while instead it has no problem if I listen to it in the m2ts file, it's normal?
Thank you

[Perenista]

I was looking for a proof that splitting and appending doesn't work and it's buggy.

It was important to me to split and append because I put my backups in 15 GB free Google Drive accounts. And I also use an app called nPlayer Plus to stream and/or download them. And sometimes while using my PC I downloaded them back and reconstructed (appending) with MKVToolnix.

I haven't been able to prove this doesn't work with ACTUAL evidence, so I suspected this was somehow MAKEMKV's or MKVToolnix's fault, or due to some codec used in the first attempt to rip from the disc.

I thought splitting and appending worked just fine, so I imagined the disc or first rip were the ones flawed. :rolleyes:

Now I have definitive proof that if I use splitting and later try to reconstruct the movie (appending) this will damage the content. Meaning splitting and appending should NEVER be used.

The fact other movies were able to work with this idea, under other circumstances or even using other codecs doesn't matter.

What it matters is that if you do this you are now aware in advance it will break things:

https://www.youtube.com/watch?v=90jcjpomH1s

This video shows a lossless rip from my UHD/4K disc.

Now here's the thing: the original 4K rip was edited by MKVToolnix, so I could add new audio/subtitle tracks to it. And saved again. No problems.

This file ended up having 78 GB. This is its MEDIAINFO: https://pastebin.com/G4LBiViV

If I edit this thing a million times it will still be 100% OK. From the 1st second to the last. ALL SCENES. Notice in the Youtube video this 78 GB file is displayed in the first 45 seconds. You can clearly see a specific scene plays just fine.

Yet...

I wanted to split to put into 6 Google Drive accounts. So 14.97 GB in each one.

https://i.postimg.cc/DygnWhpC/X1.png

This is part 1: https://pastebin.com/YZs9A4YT

If I do this then the first file will have 22m20s, the second 22m04s, etc.

Now go back to the Youtube video. Pause at 1 minute and 6 seconds.

You are now seeing that if we try to play part 2 of 6, then right at the first seconds this is going to happen:

https://i.postimg.cc/BvdXhs0T/MAL.png

Some sort of macro blocking. The entire image (for a couple of seconds) stays that way.

A reconstruction error.

Now, when I saw this I didn't worry about it. Why? Because I thought that splitting did, however if I appended all 6 parts everything would be fine.

That macro blocking at the first seconds was only because I had splitted, so this was a way of the file to indicate that suffered an abrupt split into a sensitive moment. Some sort of anomaly we had to live with, an inconvenience, yet nothing to worry about.

*****
2 minutes into that Youtube video I play for the first time the APPENDED file. This one is a result of all 6 parts that I had splitted... combined. PASTEBIN: https://pastebin.com/qSvB3CHk

Remember what I said earlier:

- ORIGINAL 4K RIP = 100% fine
- SPLITTED PARTS = appeared fine, except for this macro blocking only seen at the 1st seconds from a few of them.

Before I reach a conclusion, please note that for the first time ever we are seeing MEDIAINFO reporting a different fps.

Frame rate : 23.940 FPS
Original frame rate : 23.976 (24000/1001) FPS

And for the Dolby Vision 1080p track:

Frame rate mode : Variable
Frame rate : 23.939 FPS

Since MEDIAINFO is not accurate when dealing with Matroskas, I am not going to bother with that. So nevermind the fps and the fact this one also grew from 1h58m24s to 1h58m32s.

Because my last 4K video also increased in length but that was all that happened (and the fact if I extract anything from a shorter 1080p source, it wouldn't sync with the 4K one appended with the fuzzy fps - I mean, I can't insert tracks from the 1080p into 4K due to this bug).

What I really wanted to do was this:

- Check the APPENDED file if at the same scene, at the exact moment, we would see macroblocking. If not then that could mean everything else was OK.

If macroblocking was not there again, then that would have proved my previous point:

- SPLITTED PARTS = appeared fine, except for this macro blocking only seen at the 1st seconds from a few of them.

APPENDED = was supposed to be fine, despite the macro blocking.

Now skip in the Youtube video to 2 minutes and 58 seconds.

You'll see the APPENDED file has been DAMAGED. Not only the scene freezes, there is also macro blocking AGAIN. And this happens with any player I use with the resulting 78 GB video.

There, I just produced proof this feature should be avoided. If this is due to Matroska's nature or something else I don't know.

What all this means to me is a disappointment. Now the only splitting I'll be able to do is putting all my contents into RAR parts. I never liked this idea, yet it's the only way.

It's really unfortunate this can't work.

[SeeMoreDigital]

...I noticed that once put in the mkv container the audio sounds very quiet, almost inaudible...What's your playback device(s)?

[Nejiro]

VLC on Ubuntu 20.04 and I think the problem is vlc and not mkv .......

[stax76]

Splits UHD/4K files to be able to use free google accounts as backup, genius.

[manolito]

Splits UHD/4K files to be able to use free google accounts as backup, genius.

Hey, why not? This is not illegal...

What I do not understand for this use case is why doesn't he just split the source using either a binary splitter or a software like 7-Zip or WinRar? Of course the single chunks will not play by themselves, but after rejoining them they will be bit-identical to the source.

[Perenista]

Splits UHD/4K files to be able to use free google accounts as backup, genius.Not only hosting would be very expensive for what I have stored for free (spread over multiple Google accounts), I am also not investing in portable drives or buying anything for the time being for my own computer. NAS are expensive, SSDs even more.

Frankly I had enough of hard drives failing (and this usually happens when you can't rely on your warranty) and corrupting your data, for whatever reason and all of sudden, not just when you drop them (and when that happens you can't recover even if you spend a lot of $$$$$$$$) and SSDs still expensive as of 2021. It's pathetic beyond belief that almost 20 years ago we had the first 1 TB HDD and right now you pay 10 times more for a SSD of the same size.

So it makes total sense to not pay a dime if you happen to own multiple accounts, because this isn't against Google's TOS, you only have to return to them due to a 2 year inactivity period. Hosting your own content isn't illegal, provided it's not shared in public.

I prefer to take my chances with a multibillion-dollar company that somehow protects all the data I upload to them. The odds of losing or corrupting my data are slim compared to investing in physical drives.

The 15 GB limit means you can't store in lossless any 1080p or 4K disc. So that means splitting and appending or compress the files in RAR in 15 GB parts and then download and extract all of them later.

The problem with that idea of using WinRAR is that prevents you from streaming or downloading, say, part 4 of 6 whenever you want, and watching only that bit from the movie. You would be forced to download the whole thing, or give up this idea and watch the smaller, lossy files.

I said splitting and appending don't work, yet it's funny to realize I am only seeing a problem with 4K content. I have been doing this FOR YEARS and only now that I am trying with these new UHD discs I am detecting all those issues.

If you try to split a smaller file with the usual tracks nothing I reported happens.

Once I started dealing with Dolby Atmos, DTS-HD MA, Dolby Vision, etc. and increased the filesize all these problems started to appear.

Is this a coincidence or splitting and appending always had problems?

If this is always to be expected then no one should split and append MKVs anymore.

Hey, why not? This is not illegal...

What I do not understand for this use case is why doesn't he just split the source using either a binary splitter or a software like 7-Zip or WinRar? Of course the single chunks will not play by themselves, but after rejoining them they will be bit-identical to the source.This is what I am going to do from now on.

I resisted this idea because if I store a 70 GB file in GDrive first I'll need 140 GB to extract the whole thing. Second I will be unable to stream or download only part X of X to my tablet if that's all I wanted to watch.

Using Google Drive was meant to avoid that. Otherwise you might store in RAR anywhere else, you would not have easy and quick access to this content. That was not what I had in mind, and also the reason why I don't like watching movies from discs, instead I prefer MKVs, where I can also add my own audio/subtitle tracks.

[SeeMoreDigital]

It's pathetic beyond belief that almost 20 years ago we had the first 1 TB HDD and right now you pay 10 times more for a SSD of the same size.Actually it was 2007 (so 14 years ago). And they cost around $400.00!

Today, you can buy a 1TB SSD's for around $50.00. So way cheaper!

[VAMET]

Dear Friends

It's been a while, when I was using MKVToolNix. There are Zidoo Z9X and NVIDIA Shield 2019 Pro, which are able to play DV from .mkv files. Lots of people say, to use MakeMKV (which has got in changelog: "MakeMKV now can extract Dolby Vision metadata from elementary stream data and rebuild missing or invalid DV descriptors" and "MakeMKV now recognizes and converts double-track Dolby Vision MKV files"), but I would like to use MKVToolNix for my UHD Backups with DV. Is it possible in the newest version of MKVToolNix?

Thank you in advance for your help and support.

Sincerely

[SeeMoreDigital]

It's been a while, when I was using MKVToolNix. There are Zidoo Z9X and NVIDIA Shield 2019 Pro, which are able to play DV from .mkv files.
Out of interest...

Which software media player application(s) currently offers support for Dolby Vision in .mkv?

[VAMET]

Dear SeeMoreDigital

Out of interest...

Which software media player application(s) currently offers support for Dolby Vision in .mkv?

In NVIDIA SHIELD 2019 Pro, Kodi 19.0 Matrix special DV version and Plex. In Zidoo Z9X their native player.

- Kodi Android build with support for Dolby Vision MKV (https://forum.kodi.tv/showthread.php?tid=360018)
- Beta version v6.2.5 for Z9X/Z10 Pro/Z1000 Pro/UHD3000 (http://forum.zidoo.tv/index.php?threads/beta-version-v6-2-5-for-z9x-z10-pro-z1000-pro-uhd3000.87540/)

Zidoo Z9X also DV from ISO and BDMV.

Sincerely

[SeeMoreDigital]

In NVIDIA SHIELD 2019 Pro, Kodi 19.0 Matrix special DV version and Plex.
- Kodi Android build with support for Dolby Vision MKV (https://forum.kodi.tv/showthread.php?tid=360018)

Does this mean that Nvidia Shield users no longer need to create Dolby Vision (Profile 5) .mkv muxes and play them using Infuse Media Player?

[VAMET]

Dear SeeMoreDigital

Does this mean that Nvidia Shield users no longer need to create Dolby Vision (Profile 5) .mkv muxes and play them using Infuse Media Player?

There is only a need to create backups in .mkv via the newest MakeMKV and use Kodi 19.0 DV version from my last post.

Kodi Matrix 19 final with Dolby Vision MKV and Libbluray support (https://github.com/fandangos/Kodi-HDR-Edition/releases/tag/19) - Based on Kodi Matrix 19 final with Dolby Vision and libbluray support

Sincerely

[quietvoid]

Hello, I've been working on a first attempt at parsing HEVC to add Dolby Vision configuration block addition mapping, however I currently am unable to properly playback the files it's muxing.
MediaInfo, FFmpeg and MakeMKV are able to detect the mapping just fine.

I just can't seem to be able to get a working mux. Only HDR/SDR playback instead of Dolby Vision.
The extracted bitstreams are identical, however.

I'm not sure if this discussion would be better in a draft PR, but the code I did isn't organized properly right now.
The branch I'm testing: https://gitlab.com/quietvoid/mkvtoolnix/-/commits/hevc_st_dovi

Thanks.

[odino]

Hi Moritz,
I don't know if this is a bug or a setting I missed but often the GUI will attach (1) to a filename, presumably when it has noticed there is an existing filename. Now, I don't mind it per se, but usually I DO want to overwrite a file, but my bigger beef with it is that it sometimes, almost at random, only does this AFTER I have clicked on "start multiplexing", suddenly attaching the "(1)" in a millisecond. This behavior seems unpredicable. Any thoughts? Thanks for your time.

[Mosu]

I'm not sure if this discussion would be better in a draft PR, but the code I did isn't organized properly right now.

Thanks for looking into it! Discussion about code is definitely better done on Gitlab in a MR, even if the code isn't working yet.

[Mosu]

Hi Moritz,
I don't know if this is a bug or a setting I missed but often the GUI will attach (1) to a filename, presumably when it has noticed there is an existing filename. Now, I don't mind it per se, but usually I DO want to overwrite a file, but my bigger beef with it is that it sometimes, almost at random, only does this AFTER I have clicked on "start multiplexing", suddenly attaching the "(1)" in a millisecond. This behavior seems unpredicable. Any thoughts? Thanks for your time.

It's a setting called "Ensure the file name is unique" in the preferences → "Multiplexer" → "Destination file name". What you describe is intended behavior if the option is on as the GUI cannot read your mind (as in "oh, in general I do want it to be unique but _this_ time I don't!").

[odino]

It's a setting called "Ensure the file name is unique" in the preferences → "Multiplexer" → "Destination file name". What you describe is intended behavior if the option is on as the GUI cannot read your mind (as in "oh, in general I do want it to be unique but _this_ time I don't!").

Ok great, thanks, I have switched that off for now. Greetings.

[-QfG-]

There is a bug till v55 (latest Build) and HDR10+DV (Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible) muxes. You have artefacts at the Oppo Player, the Clones and the internal LG Players.
I know that this Players uses the fallback HDR versions from the mkvs. v54 works fine.

[quietvoid]

There is a bug till v55 (latest Build) and HDR10+DV (Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible) muxes. You have artefacts at the Oppo Player, the Clones and the internal LG Players.
I know that this Players uses the fallback HDR versions from the mkvs. v54 works fine.

I think this is the related issue: https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3093

I've also noticed both 56 and 56.1 do not trigger Dolby Vision when played back, while 55 does.
I tried the --engage dont_normalize_parameter_sets flag but it made no difference.

[SeeMoreDigital]

Playback of Dolby Vision encoded video placed within .mkv container using an OPPO or LG or Sony player!!! When did this happen?

[quietvoid]

I don't think it has, they mention HDR fallback (which is broken with last MKVToolNix version).
I know I can't play MKVs in Dolby Vision on my 2018 LG (with the internal player).

[VAMET]

Dear Friends

I have created via MakeMKV .mkv with Dolby Vision from my physical disc. There are untouched video and audio tracks and chapters. MakeMKV doesn't allow to remove chapters from .mkv. Are there any possibilities to remove chapters from .mkv without touching/processing video and audio tracks? Is it done via MKVToolNix>Multiplexer>Add file, then untick Chapters and Start Multiplexing or other method (simple command line)?

Thank you in advance for your help and support.

Sincerely

[Mosu]

That should work. You could also just use the GUI's chapter editor's "Remove chapters from existing Matroska file" feature (in the "Chapter editor" menu).

[Perenista]

I am having a new problem with MKVToolnix and subtitles.

https://i.postimg.cc/QtvWbwDS/X1.png

https://i.postimg.cc/brbSFgNP/X2.png

Whenever I add one of these subtitles to any of these Matroskas MKVTOOLNIX disregard my advice to tell all of them are english, and somehow interprets the "de" among the words means it should be german.

https://i.postimg.cc/j2zChjZd/PRO.png

There's just one problem here, the words "de" are part of "cor-de-rosa" which means "pink color" in portuguese.

The mistake MKVToolnix is making would be similar to telling me this:

The Adventures.mkv
The Adventures.srt

Would result in this:

https://i.postimg.cc/T1X3h6f8/PRO2.png

Since this is a primary mistake I need to disable this for good. Whatever language I said the program to assume it is (in this case english) needs to be the one attributed to ALL subtitles. No matter what.

[Mosu]

You can configure the languages the GUI tries to find in the file name in the preferences ("Multiplexer" → "Deriving track languages"). Just remove all languages safe for those you usually use.

If you don't want dashes to be recognized as valid separators for words for the purpose of deriving track languages, you can simply remove the dash from the list of boundary characters there, too.

Or simply deactivate that feature altogether, again at the same place.

[von Suppé]

Hi Mosu,

I noticed you opened https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3113 recently.
For my reassurance, two questions please.

With the "no support for DV two separate files" in your last post there, I assume you mean when importing previously demuxed BL and EL streams?
Secondly, am I right to think that using v55.0.0 is - for now - recommended for (re-)muxing Dolby Vision?

[Mosu]

With the "no support for DV two separate files" in your last post there, I assume you mean when importing previously demuxed BL and EL streams?

I don' t know the verbiage around Dolby Vision, so I cannot really say with certainty that this is what I meant. If I understood things correctly, Dolby Vision on Blu-rays is packaged in a way that means the player has to read the regular HEVC data from one file and the Dolby Vision data from another file, as opposed to having both in a single file. I will most likely not support the former (at least not initially or anytime soon).

Secondly, am I right to think that using v55.0.0 is - for now - recommended for (re-)muxing Dolby Vision?

You can also use 56.1.0. If the resulting file works, great; so far I don't have concrete evidence that all files containing DV created by ≥ 56.1.0 show playback issues.

If it doesn't, try adding "--engage dont_normalize_parameter_sets" which is basically the same behavior as in versions prior to v56.

Even better would be if you could follow issue 3093 (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3093) and give the test files I upload there a try & give feedback on whether they play fine or not. That would actually help in fixing the bug whereas going back to v55 doesn't help me at all.

[Mosu]

Addendum: I've just realized that mkvmerge ≥ v56 places the Dolby Vision NALUs in the wrong Matroska block, even if "--engage dont_normalize_parameter_sets" is used. Therefore yes, at this point using v55 for Dolby Vision is the way to go until I've fixed that. You can follow issue 2784 (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2784) where this is currently discussed.

[Mosu]

Hello, hello!

fresh of the presses here's MKVToolNix v57.0.0. A lot of work has gone into the HEVC/H.265 code over the last couple days, fixing most issues with Dolby Vision and HDR content, but also fixing a couple of general issues with the HEVC/H.265 code. Everyone using that codec should definitely update.

The state of Dolby Vision & HDR is pretty good right now. The only thing still missing is reading Dolby Vision from Annex B type elementary streams (raw .h265 files or MPEG transport streams), but we're working on that as well.

By the way: a lot of you have decided to support MKVToolNix by buying it from the Microsoft Store (https://www.microsoft.com/store/apps/9NS0Q4ZM8MW2) for which I'm very, very grateful. At the point of writing it has been sold 544 times already. One immediate benefit is that I've invested in Dolby Vision capable hardware in order to be better able to test & improve that part of MKVToolNix. Your support is definitely making a difference.

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 57.0.0 "Till The End" 2021-05-22
New features and enhancements

mkvmerge: MP4 reader: added support for reading Dolby Vision from MP4 files (FourCCs "dvh1" and "dvhe"; configuration records "dvcC", "dvvC" and "hvcE" will be converted into block addition mappings). Implements #2784 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2784).
mkvmerge: SRT subtitles: mkvmerge now accepts empty text files with the extension ".srt" as SRT subtitle files, enabling the creation of empty SRT tracks. Implements #3089 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3089).
mkvmerge, mkvextract: HEVC/H.265: access unit delimiter NALUs will no longer be discarded, neither during muxing nor during extraction.
MKVToolNix GUI: preferences: switched the order & wording of controls in the "enabling items" panel to make it clearer that certain controls define exceptions. Inspired by 3086.

Bug fixes

mkvmerge: HEVC/H.265 parser: several NALU types, notably the Dolby Vision-specific NALUs ("unspecified 62" and "unspecified 63") and suffix SEI NALUs, are now stored with the frame they belong to instead of with the next frame. Part of fixing & implementing #2784 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2784), #2818 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2818), #3093 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3093) and #3113 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3113).
mkvmerge: HEVC/H.265 packetizer: fixed setting the track's default duration when reading HEVC/H.265 from Matroska files that don't have a default duration set.
mkvmerge: HEVC/H.265 packetizer: fixed the calculation of the duration of frames so that "SimpleBlock" elements can be used again instead of "BlockGroups" with "BlockDuration" elements. Fixes #3114 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3114).
mkvmerge, mkvextract: HEVC/H.265 parser: fixed issues with ordering & duplication of certain NALUs (parameter set & prefix SEI NALUs). Part of fixing & implementing of #2784 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2784), #2818 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2818), #3093 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3093) and #3113 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3113).
MKVToolNix GUI: multiplexer: when dragging & dropping files to the multiplexer, the source directory will be remembered as the "last open directory" again, causing subsequent uses of the "open file" dialog to start in the same directory. Fixes #3110 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3110).
mkvinfo: fixed the position of frames in block groups containing "block duration" elements in summary mode (e.g. for subtitle tracks).

Build system changes

"configure" will now try to detect "libmagic" via "pkg-config" and fall back to including & linking directly if it cannot be found via "pkg-config".


Have fun :)

[filler56789]

fresh of the presses here's MKVToolNix v57.0.0.

Thanks! :thanks:

[quietvoid]

Thank you!

[von Suppé]

Thanks, Mosu.

[Perenista]

I am having a problem with both MKVToolnix and gMKVExtractGUI. This needs clarification because I am always confused about this.

Let's say I have two MKVs from a movie, a Blu-ray released in 2010 and another in 2020. Both are the same in terms of sync/length, just different discs.

Then I create a new audio track to be added to both. A dubbing.

Later I discover I need to introduce a positive delay of 1 second (or 1000 ms) while adding to MKVToolnix. So this works and track #2 is 100% synchronized with video #1.

This is WHAT I AM TRYING TO DO:

a) Remove track #2 from video #1 (from there only, assume I lost my original recording);
b) Add track #2 to video #2.

I always use gMKVExtractGUI for that extraction.

When I open this program I see that track has the 1000 ms information in there. This is also added to the file when we extract, so it's now being called track-2-1000ms.mp3.

My question:

If I simply add track #2 (after extracting from video #1) to video #2 it will be out of sync.

So that means I need to insert the 1000 ms information again?

That would be the logical next step.

Even if the answer is YES, what if I informed a positive (or negative) delay to subtitles? If I did that then I would have no way of knowing what to do next.

This is how gMKVExtractGUI is reading video #1:

https://i.postimg.cc/wTY6VLyp/X1.png

Are there any chances of these positive and negative delays not working with some players/hardware? At least in my PC I never had issues.

Of course if we are talking about SRT subtitles, for example, it would be better to already add the positive delay with a dedicated program:

https://i.postimg.cc/FKY5mHdp/X2.png

In this case Subtitle Workshop, which adds 1 second to the entire file.

That would spare MKVToolnix from doing the same.

But we can't insert a 1 second of silence into a MP3 or any other track without reencoding, which is why when needed I always insert these delays using MKVToolnix.

[von Suppé]

Using MKVToolnix for years, I never tried delays on subtitles so I couln't tell you about player issues for that matter.
I don't know whether MKVToolnix would define srt-delay by header or that it will adjust the timestamps within the srt itself.
I think that, for your own reassurance, it may be a good idea to make a sample mkv where you apply delay on srt (maybe two srt's: one with postive and one with negative value). After that, demux the mkv and compare the "original" srt to the demuxed one(s). Then you can make out how MKVToolnix handles srt delays, my guess.

BTW, a bit off-topic, but beware that negative delays on audio means that MKVToolnix will simply chop off the given time from the beginning of the soundtrack. Thus, that (small) part will be lost in the mux and can't be recovered.

[Atak_Snajpera]

How to correctly convert this command line
"mkvextract.exe" tracks "C:\video.mkv" 1:"C:\Temp\RipBot264temp\job1\audio.opus"

to json file?

I tried that...
[
"tracks",
"C:\\video.mkv",
"1:",
"C:\\Temp\\RipBot264temp\\job1\\audio.opus"
]

...and i got this error
https://i.postimg.cc/9MtmhbYn/Capture.png

[Mosu]

a) Remove track #2 from video #1 (from there only, assume I lost my original recording);
b) Add track #2 to video #2.

I always use gMKVExtractGUI for that extraction.

Why? You should rather simply remux from the original Matroska file. Add the first file. Deactivate muxing of track #2. Add the second file. Deactivate everything but track #2 from the second file. Multiplex.

Extraction is a lossy process as a lot of information (most importantly timestamps, but also track languages, titles etc.) cannot be stored in the elementary streams produced by mkvextract.

When you mux directly from Matroska you don't have to worry about losing existing delays.

Extraction should only be necessary if you need modifications to the content of a track, e.g. re-encode to a different codec or change the wording in subtitle tracks.

As for delays, there's a FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Delay-not-shown-in-the-GUI) about how delays work in Matroska files.

Of course if we are talking about SRT subtitles, for example, it would be better to already add the positive delay with a dedicated program:

Both that external program as well as mkvmerge simply modify the timestamps by adding your delay. It's the same modification.

[Mosu]

How to correctly convert this command line
"mkvextract.exe" tracks "C:\video.mkv" 1:"C:\Temp\RipBot264temp\job1\audio.opus"

to json file?

Command line arguments are split on spaces not enclosed in quotation marks. Your command line has three arguments, not four. Therefore the correct JSON is:

[
"tracks",
"C:\\video.mkv",
"1:C:\\Temp\\RipBot264temp\\job1\\audio.opus"
]

"The file could not be opened or parsed" usually means that the source file's name is wrong. Are you sure your source file is located directly in C:\ ? Another possibility is that the video.mkv is still open in another program that has a exclusive lock on it.

[Atak_Snajpera]

Ok! Thanks mosu. Problem solved.

[Mosu]

With the "no support for DV two separate files" in your last post there, I assume you mean when importing previously demuxed BL and EL streams?

After reading up about Dolby Vision some more[1][2], I'm more confident in my wording. As far as I understood things, Dolby Vision always comes with a Base Layer (BL) and, depending on the profile, might come with a second layer, the Enhancement Layer (EL). There are two different ways to store that Enhancement Layer:

Intermixed with the Base Layer in a single track. The EL NALUs are transported as NALUs of type UNSPECIFIED_63. If the container has global codec initialization data (e.g. MP4 or Matroska), the track headers might store an HEVCDecoderConfigurationRecord for that Enhancement Layer in addition to the HEVCDecoderConfigurationRecord & the DolbyVisionConfigurationRecord for the Base Layer. For MP4 files, the HEVCDecoderConfigurationRecord for the Enhancement Layer is stored in a hvcE atom. Alternatively the data (VPS, SPS & PPS of the EL) can be stored in the bitstream wrapped into UNSPECIFIED_63 NALUs. For containers that do not have global codec initialization data (e.g. MPEG transport streams), the Enhancement Layer initialization data can only be transmitted in the bitstream wrapped as UNSPECIFIED_63 NALUs.
As two separate tracks: the Base Layer and the Enhancement Layer are a track each, the container signals their connection somehow (MP4 & MPEG-TS do this differently). Containers with global codec initialization data (MP4) will only use one regular HEVCDecoderConfigurationRecord (hvcC atom in MP4) for each track and a DolbyVisionConfiguration (dvcC or dvvC for MP4) for… one of them (EL?), but there will be no hvcE atom necessary.

What mkvmerge 57.0.0 already supports is reading single-layer DV from MP4 & Matroska as well as dual-layer-with-both-layers-in-the-same-track from MP4 & Matroska.

What mkvmerge will support soon (see MR 2232 (https://gitlab.com/mbunkus/mkvtoolnix/-/merge_requests/2232)) is reading single-layer DV from raw HEVC elementary streams (ITU-T H.265 Annex B) or from MPEG transport streams.

What mkvmerge will NOT support anytime soon is reading dual-layer DV with the BL & the EL being in different tracks, no matter where they might come from (MP4, MPEG-TS, HEVC elementary streams in different files) for two reasons:

Matroska doesn't have facilities to flag that two tracks belong together in the way required for it.
It is unclear if it would be possible to convert dual-layer-in-two-tracks to dual-layer-in-single-track by simply re-wrapping/converting the regular HEVC NALUs of the EL to the UNSPECIFIED_63 style NALUs intermixed with the BL. Finding information about that is… hard, and the specs are obviously not public.

Does that makes things clearer?

[1] "Dolby Vision Streams Within the ISO Base Media File Format" (https://dolby.my.salesforce.com/sfc/p/#700000009YuG/a/4u000000l6FB/076wHYEmyEfz09m0V1bo85_25hlUJjaiWTbzorNmYY4)
[2] "Dolby Vision in MPEG-TS" (https://professional.dolby.com/siteassets/content-creation/dolby-vision-for-content-creators/dolby-vision-bitstreams-in-mpeg-2-transport-stream-multiplex-v1.2.pdf)

[Perenista]

Why? You should rather simply remux from the original Matroska file. Add the first file. Deactivate muxing of track #2. Add the second file. Deactivate everything but track #2 from the second file. Multiplex.

Extraction is a lossy process as a lot of information (most importantly timestamps, but also track languages, titles etc.) cannot be stored in the elementary streams produced by mkvextract.

When you mux directly from Matroska you don't have to worry about losing existing delays.

Extraction should only be necessary if you need modifications to the content of a track, e.g. re-encode to a different codec or change the wording in subtitle tracks.

As for delays, there's a FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Delay-not-shown-in-the-GUI) about how delays work in Matroska files.

Both that external program as well as mkvmerge simply modify the timestamps by adding your delay. It's the same modification.About my message, this is what I discovered:

- If you add any audio/subtitle track and insert a delay (let's say 1 second or 1000 ms, positive), then that information is stored in your Matroska, but the track itself remains untouched.

So 1000 ms is just an internal information like the language your track reffers to, if it's a forced subtitle, etc. The track itself of course is not modified, because there's no reencode, so the 1000 ms was not permanently inserted into it. This was a confusion I made in the past, because I am always moving these from one source to another.

And since there's no reencode it's true that if it's reading that way:

https://i.postimg.cc/wTY6VLyp/X1.png

Then that "descriptive" track once extracted I'll need to inform MKVToolnix again it has to add a 1820 ms delay, if I put into another video.

With subtitles, no matter what (SRT, VobSub or PGS) this information is not being displayed (see above), but again they are not being modified, so even if you added a 5000 ms positive delay into your MKV the subtitle track is untouched.

What I have been doing here in order to check if two videos are in sync is to skip to a specific scene, say, at 29m32s-500s, and freeze at that moment. If video #2 happens to be at this exact moment with a very small variation, say, 29m32s-450s, then we know they may be from different sources, however are the same (other moments need to be checked because it may be in sync for the first 30 minutes, then gradually change).

Example: Jurassic Park (1993) in UHD/4K and 1080p Blu-ray, no differences there, for the entire movie (note: some movies do have a difference, it may be a small one, say, 200 ms, others more, usually 1 or 2 seconds).

I didn't know it was possible to simply add one specific content/track from one MKV inside another.

I thought you always had to extract anything, otherwise it wouldn't work somehow.

Really, you just have to disable the other tracks that you don't want to add there.

[Mosu]

You're not entirely wrong, but not entirely right either.

When you use a delay in Matroska what happens is that the timestamps are modified but not the frame content.

Whether or not that modification survives a roundtrip through extraction & re-muxing solely depends on the container used during extraction. For example, AC-3 tracks are written to raw AC-3 files, and those do not support timestamps. Therefore modification of Matroska's timestamps don't survive extraction. (Things are slightly different with negative delays as in that case frames are actively dropped during the initial muxing step, and of course those cannot be re-inventeded during the extraction. For example, if you have a delay of -400ms and each frame is 32ms long, then mkvmerge would drop 13 frames (-400ms + 13 * 32ms = 16ms). Of course you don't have to specify -400 again if you extract & remux as that would drop ANOTHER 13 frames. Instead you'd have to specify 16ms now.)

All subtitles formats, on the other hand, always contain timestamps, and therefore modification to Matroska's timestamps do survive an extraction of a subtitle track to a subtitle file.

Really, you just have to disable the other tracks that you don't want to add there.

Exactly. Don't extract. Just… don't.

[von Suppé]

Does that makes things clearer?
Your explanation absolutely does.
Thanks for taking the time to do the reading on Dolby Vision.

[SeeMoreDigital]

What mkvmerge will NOT support anytime soon is reading dual-layer DV with the BL & the EL being in different tracks, no matter where they might come from...

Out of interest what needs to come first... A new dual-layer Dolby Vision compliant .mkv file parser or the muxer?

[Mosu]

Your explanation absolutely does.
Thanks for taking the time to do the reading on Dolby Vision.

I've also created FAQ page (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status) detailing the support status for Dolby Vision.

[Mosu]

Out of interest what needs to come first... A new dual-layer Dolby Vision compliant .mkv file parser or the muxer?

Well, I can certainly finish the muxer part without having a way to play them (for dual-layer with both layers in the same track, mind you! both layers in different tracks would require extending the Matroska specs with a couple of new elements & a hefty amount of changes to MKVToolNix). What needs to be done in MKVToolNix is:

mkvmerge will need to gain support for parsing single-layer DV from Annex B type bitstreams/MPEG transport streams. This basically means finishing the existing merge request (which looks pretty finished at the moment, I just have to test & merge the latest variant).
mkvmerge needs to parse the UNSPEC_63 NALUs for the parameter set NALUs. From those it will be able to create the hvcE configuration. That will not be that hard to do, actually; what I'm primarily lacking is a set of files to test with. I do have dual-layer MP4 files with UNSPEC_63 NALUs, but those do not have the parameter set NALUs in the bitstream; they're only present in the track headers' hvcE atom.
mkvextract must be able to convert the hvcE atom back into UNSPEC_63 parameter set NALUs and insert them at the right place. This is actually much more work than step 1, and I'm unclear about the syntax & semantics of two specific bytes within the UNSPEC_63 NALUs that I would have to recreate somehow.

So yeah, having dual-layer-both-layers-in-same-track sample files would definitely help.

[Mosu]

Heyo,

Summer is here, and so is MKVToolNix v58.0.0. Unlike the previous releases a lot more time has gone into it. The most noticeable change (to end users at least) is how the "default track" flag is handled, bringing it up to how the latest spec says the flag should be handled by players. Another prominent change is which MIME types are used for attached fonts on Windows. See the news below for details on both changes.

There were a couple of changes for packages, though none of them should actually require work on recent distros. Again, see the news below for details.

Last, but not least: get vaccinated if at all possible, y'all!

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 58.0.0 "Supper's Ready" 2021-06-13
New features and enhancements

mkvmerge, MKVToolNix GUI's multiplexer: the handling of the "default track" flag has been changed to match the recent changes to the Matroska specifications. The new semantics are that if it is set, it is supposed to signal to the player that this track is eligible for being played by default, potentially taking other factors such as user preferences regarding languages into account. This implies that more than one track of each type can have this flag set. For example, a Blu-ray disc with three audio tracks might have the main audio in both English and Japanese, whereas the third audio track contains the director's comments. In such a case the first two tracks should have the "default track" flag set, the third one shouldn't. Earlier "mkvmerge" was enforcing that only one track of each type could have the flag set. This restriction has been removed, both in "mkvmerge" and in the GUI's multiplexer. "mkvpropedit" and the GUI's header editor are unaffected as they've always allowed to set the flag on as many tracks as the user wanted.
mkvmerge: AVC/H.264 & HEVC/H.265 identification: added the stream's pixel dimensions (AVC only; were present for HEVC already) & default duration. Implements #3116 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3116).
mkvmerge, mkvextract: HEVC/H.265: added support for reading single-layer Dolby Vision from Annex B type bitstreams (elementary streams, MPEG transport streams). Patch by quietvoid. Implements #3113 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3113).
mkvinfo: the option "-X"/"--full-hexdump" now affects all binary elements, not just the frame data in "SimpleBlock" and "BlockGroup" elements.
MKVToolNix GUI: multiplexer: the "delay" and "sync" options can now be used for chapters in source files, too. Implements #3129 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3129).
MKVToolNix GUI: when moving list entries up & down with the optional buttons or the keyboard shortcuts (instead of using drag & drop), the GUI ensures that the top-most selected entry remains visible after the move. Implements #3123 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3123).
MKVToolNix GUI: added an option in the preference to use legacy MIME types for font attachments instead of the current standard ones (e.g. 'application/x-truetype-font' instead of 'font/sfnt' and 'font/ttf').

Bug fixes

build system: fixed filtering out optimization options when compiling the file "iso639_language_list.cpp" (before only numeric optimization levels were filtered out and only if it wasn't the last option in the list of flags). See #3105 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3105) for context.
build system: when libmagic was detected via "pkg-config", MKVToolNix was actually compiled without support for libmagic due to a preprocessor symbol not being defined.
mkvmerge: MP4 reader: fixed an issue with timestamps overflowing when the file's or the track's time scale is large. Fixes #3124 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3124).
mkvmerge, mkvextract: fixed key frame handling for "BlockGroup" elements with a forward reference but no backward references. Patches by Tom Yan.
mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: the programs will no longer omit writing mandatory elements set to their default value if other elements of the same type are present in the same master. This affects mostly the "chapter language" element which may occur multiple times within the same "chapter display" master. If it does occur multiple times and one of them is set to "English" (which is that element's default value), that element will now be written, too. Part of the fix of #3120 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3120).
mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: when parsing chapter files IETF & legacy language elements as well as legacy country elements will now be properly generated depending on which exist already, especially when there's more than one language and/or country element in a "chapter display" element. Part of the fix of #3120 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3120).
mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: fixed reading OGM-style chapter files with timestamps that don't have exactly three decimal places. Any number of decimal places between one and nine is now supported for nanosecond precision. Fixes #3121 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3121).
MKVToolNix GUI: chapter editor: added/fixed support for "chapter display" elements with multiple languages or countries. Part of the fix of #3120 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3120).

Build system changes

Qt 6: added support for building with Qt 6. "configure" will look for Qt 6 first and only continue looking for Qt 5 if Qt 6 isn't found or disabled via "--disable-qt6". Qt 6 detection works by first looking for the "qmake6" binary. Its location can be specified with the "--with-qmake6=…" option. All other Qt 6 related facts (such as compiler & linker flags or the position of the other required tools such as "lconvert", "moc", "rcc" and "uic") will be derived from the output generated by "qmake6". Note that at this point Qt 6 is not yet supported for the cross-compilation build to Windows, nor is a static Qt 6 build supported yet. Note that the command line options "--enable-static-qt", "--with-qt-pkg-config-modules" and "--without-qt-pkg-config" only apply to the Qt 5 and have no effect on Qt 6.
Qt 5: the options for specifying the position of the tools ("--with-moc=…", "--with-rcc=…" and "--with-uic=…") have been removed. Their position will now be derived from the output generated by "qmake".
"configure": completely disabling the GUI now requires passing both "--disable-qt6" and "--disable-qt" options.
Boost's multi-precision library is now required.
Boost v1.66 or newer is now required.

Other changes

The Windows build is now using an updated version of the "file"/"magic" library for MIME type detection of attachments. This affects fonts whose MIME types will now be the current standard MIME types (e.g. "font/sfnt" or "font/ttf" for TrueType fonts). As this might pose problematic with older players that only support the legacy MIME type (e.g. "application/x-truetype-font"), a new option was added in the GUI's preferences to use the legacy MIME types instead of the current standard ones. This is off by default. Builds for other operating systems have already been using newer versions of the "file"/"magic" library for a long time.



Have fun 😁

[Klaus1189]

Thanks for new version. Is it intended that v58.0.0 is not digitally signed? I have no problem with it but I recognzed it.

[Mosu]

Huh? Both the installers & the executables after installation are signed; I just re-checked (explorer → right-click on exe → properties → tab "Digital signatures") to make sure. Same for the exes in the 7z archives. So… what exactly are you talking about?

[Mosu]

Ugh, looks like the timestamp signature authority service is… somewhat broken? Dunno. I'll switch to a different one for the next release.

[Liisachan]

In my tests on Windows, GUI recognizes by default:
- .ttf as font/sfnt (technically correct) rather than font/ttf
- .otf as application/vnd.ms-opentype (still legacy?) rather than font/otf (or font/sfnt)
- .ttc as font/ttf (wrong?) rather than font/collection

For the standardized font mime types, one can check https://www.iana.org/assignments/media-types/media-types.xhtml#font

[Mosu]

Yeah, I've upgraded the "file" library used for MIME type detection, and it seems it isn't that good at that. Someone else already opened an issue for it. I plan to replace it by using Qt's MIME type detection which seems to work correctly with my (very) limited set of test files (both OTF & TTF fonts), but that requires quite a bit of work on the code in "configure", which is easily my least place to work in.

As stated in the NEWS file, there is an option in the preferences to use the MIME type that the Windows version of MKVToolNix had used for TrueType fonts (.ttf, not font collections) up until v57, application/x-truetype-font. You can enable that for the time being.

[odino]

Hi Moritz,
sorry to waste your time with this silly question but:
when I select "CTRL+D" (and probably other functions) the default destination file name changes from single slash to double slash. I know both are correct but is there actually a reason for this? I mean, either start the default with double slash or just leave it single all the time, right? lol
I also don't remember this happening before a few versions ago.

Greetings

[Mosu]

@odino I don't follow. For me nothing changes in the destination file name when I press Ctrl+D. Can you please be a bit more specific? What exactly is the destination file name set to before you press Ctrl+D, and what does it change to? And which operating system & which MKVToolNix version are you using?

[asarian]

I would love for compression "determine automatically" to be disabled by default, subsidiarily, an option to keep my choice to disable compression. It's frankly a bit of silly thing to have it enabled, in this day and age of 4K HDR10+ content. Stop marketing your software like any other cheap xvid bot. :)

[Asmodian]

It's frankly a bit of silly thing to have it enabled, in this day and age of 4K HDR10+ content.

I consider it a bit silly to not enable it in this day and age of massive computing power.

It is lossless compression and is basically universally supported. Why wouldn't you want it enabled?

[mood]

@Mosu after install MKVToolNix 58 rev 14

give me this error "share\misc\magic" could not be found in the installation folder.

[Mosu]

@Mosu after install MKVToolNix 58 rev 14

give me this error "share\misc\magic" could not be found in the installation folder.

This is a spurious error you can ignore. I've already fixed that yesterday locally, but I haven't pushed that commit to the repository yet. The program will work fine even with the warning shown as libmagic isn't used for MIME type detection anymore — that installation check is simply something I forgot to remove.

[Mosu]

I would love for compression "determine automatically" to be disabled by default

As said, this is lossless compression supported everywhere. On top of that mkvmerge only uses compression for subtitle tracks by default anyway, not for audio or video tracks.

That being said: Preferences → "Multiplexer" → "Default values" → "Disable additional lossless compression for all track types".

[asarian]

I consider it a bit silly to not enable it in this day and age of massive computing power.

It is lossless compression and is basically universally supported. Why wouldn't you want it enabled?

Because it takes an insane amount of sheer wasted time. The notion that mkvnix can compete with/outdo x265, compression-wise, is frankly, a bit delusional. But if mkvnix can significantly compress a HEVC stream, losslessly, beyond what x265 already could, and all in ca. 30 minutes, then I doff my cap at you. :) But I doubt it.

[asarian]

As said, this is lossless compression supported everywhere. On top of that mkvmerge only uses compression for subtitle tracks by default anyway, not for audio or video tracks.

That being said: Preferences → "Multiplexer" → "Default values" → "Disable additional lossless compression for all track types".


This good info to have. :goodpost:

[SeeMoreDigital]

It is lossless compression and is basically universally supported. Why wouldn't you want it enabled?
Indeed... It's 'hardware' media player friendly!

[nevcairiel]

Because it takes an insane amount of sheer wasted time. The notion that mkvnix can compete with/outdo x265, compression-wise, is frankly, a bit delusional. But if mkvnix can significantly compress a HEVC stream, losslessly, beyond what x265 already could, and all in ca. 30 minutes, then I doff my cap at you. :) But I doubt it.

Except it doesn't do any of that, all it compresses is subtitles. As Mosu already mentioned above your post.

It costs no measurable amount of time.

[asarian]

Except it doesn't do any of that, all it compresses is subtitles. As Mosu already mentioned above your post.

It costs no measurable amount of time.

Okay, thx guys. I see the source of my confusion now.

[Vicio]

Note: The latest release is v58.0.0.


Hi Mosu, greetings from Brazil.
First of all I would like to apologize if my text is not understandable, as I am using Google Translate to translate from Portuguese to English.

I am a great admirer and user of MKVToolNix and would like to thank you and everyone involved in the project for this amazing tool. I even have a channel where I post many videos about him to help people here in Brazil, I invite you to visit it.
Playlist MKVToolNix (https://www.youtube.com/playlist?list=PL9nYaAU_ht9zPSUBfOLY5hl8YuTjqGCOS)


But anyway, what I would like to report/ask you is that you re-evaluate the change that occurred in version 50.0.0 of MKVToolNix. This change has greatly harmed the productivity of users like me who make daily use of the software.

In versions prior to v50.0.0, it only took 2 clicks on the “Language” function to change the language information of the video, audio and subtitle tracks.
See the gif I made for better understanding:
https://i.imgur.com/H6zvqfx.gif


Remembering that this function is the one we use the most and in my opinion it should have quick access as it was in previous versions.
Functions like the ones below that we rarely use are like quick access.
https://i.imgur.com/A0jS4db.png


The "Language" function, which we use the most, was hidden, now we need to give 4 clicks to change the language of each track, making this process painful and tiring for users who make a lot of use of it, because every track we need to define the language will be 4 clicks to finish the task.
https://i.imgur.com/wN3zSF0.gif


Finally, I know that it is possible to rename the tracks with the tags of each language, like, pt, por, en, eng, etc... But this ends up being unproductive in the same way, as we will have to rename the tracks manually before import them into MKVToolNix. Now imagine in series that are several episodes?!

That was it Mosu, I hope that my feedback can be useful and noting that my message is not intended to criticize or offend, I am writing only to report the difficulties I have been having with this change and with the hope that you may be reassessing this situation.


Att.
Vício.

[Vicio]

Note: The latest release is v58.0.0.


Hi Mosu, greetings from Brazil.
First of all I would like to apologize if my text is not understandable, as I am using Google Translate to translate from Portuguese to English.

I am a great admirer and user of MKVToolNix and would like to thank you and everyone involved in the project for this amazing tool. I even have a channel where I post many videos about him to help people here in Brazil, I invite you to visit it.
Playlist MKVToolNix (https://www.youtube.com/playlist?list=PL9nYaAU_ht9zPSUBfOLY5hl8YuTjqGCOS)


But anyway, what I would like to report/ask you is that you re-evaluate the change that occurred in version 50.0.0 of MKVToolNix. This change has greatly harmed the productivity of users like me who make daily use of the software.

In versions prior to v50.0.0, it only took 2 clicks on the “Language” function to change the language information of the video, audio and subtitle tracks.
See the gif I made for better understanding:
https://i.imgur.com/H6zvqfx.gif


Remembering that this function is the one we use the most and in my opinion it should have quick access as it was in previous versions.
Functions like the ones below that we rarely use are like quick access.
https://i.imgur.com/A0jS4db.png


The "Language" function, which we use the most, was hidden, now we need to give 4 clicks to change the language of each track, making this process painful and tiring for users who make a lot of use of it, because every track we need to define the language will be 4 clicks to finish the task.
https://i.imgur.com/wN3zSF0.gif


Finally, I know that it is possible to rename the tracks with the tags of each language, like, pt, por, en, eng, etc... But this ends up being unproductive in the same way, as we will have to rename the tracks manually before import them into MKVToolNix. Now imagine in series that are several episodes?!
For now I am still using v49.0.0 due to this.

That was it Mosu, I hope that my feedback can be useful and noting that my message is not intended to criticize or offend, I am writing only to report the difficulties I have been having with this change and with the hope that you may be reassessing this situation.


Att.
Vício.

[Mosu]

This FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix#the-old-user-interface-is-not-coming-back) contains all I have to say on the topic.

[Vicio]

As I've said several times before, the old way of selecting languages will not come back.

I don't know the reason for this rude response, even because I wrote a cordial text.
But patience..., this decision is a huge step backwards, who knows with time your arrogance will wear out and you will be able to respond to people with more politeness.


This FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix#the-old-user-interface-is-not-coming-back) contains all I have to say on the topic.

I noticed that you edited your post, you must have realized it was stupid for no reason.
As I said, I don't speak the English language and that's why I don't follow gringo sites precisely because I didn't know that you had already spoken about the topic.
Anyway, I respect your decision even though I don't agree with it. Thank you now for this second most cordial response, kindness begets kindness.

[Mosu]

Please read the FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix) I've written on the topic. It contains a LOT of information and explanations on why the change was made, why it cannot be simply reverted, and why it isn't the catastrophe some people make it out to be.

[Vicio]

Please read the FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix) I've written on the topic. It contains a LOT of information and explanations on why the change was made, why it cannot be simply reverted, and why it isn't the catastrophe some people make it out to be.

Yes, I will read it calmly.
But as I said before, I'm not a hater, on the contrary, I'm the biggest promoter of your software here in Brazil.

Anyway thanks for the reply.

[Mosu]

I don't think you're a hater at all. Your request is absolutely reasonable. But that still doesn't mean that I will change the functionality back to what it was before for all the reasons I've laid out in said FAQ entry.

[Snowknight26]

Regarding taking 4 clicks to set the language, there a few workarounds.

mkvmerge doesn't properly show whether an element has focus. When you click the language name link (or the edit button to the right, which isn't visible in the above gifs), the Edit language window appears with the language dropdown focused. Therefore you can:

immediately type "en" on your keyboard for "English", "port" (or maybe "p", "po", or "por") for "Portuguese", etc.
use the scroll wheel (when hovering over the dropdown) to change languages
set the default language (Preferences -> Multiplexer -> Default values) to one you use most often, requiring 0 clicks in most cases
etc.

[Liisachan]

I can set e.g. 'eng' on GUI this way: Click the pen icon, hit [e], hit [enter], that's all. Quick enough.
Similarly for 'jpn': one click, two key strokes [j][enter].

[Vicio]

Regarding taking 4 clicks to set the language, there a few workarounds.

I'm aware of these options friend, I didn't think it was worth mentioning them because I don't think these alternatives are practical, among them and giving 4 clicks, 4 clicks end up being more viable.

Remembering that at no time I asked the developer to go back to the previous GUI, but I suggested that they rethink a way to shorten this long path to access the most used function of the software. Because for me it doesn't make any sense, functions like these in the image below, which we rarely use, have a quick access while the most used function became difficult to access.

https://i.imgur.com/O6ZO96j.jpg

https://i.imgur.com/pA8NPqM.gif



But anyway, any discussion here about it became irrelevant, since the developer was adamant about the topic, so I'm done with this subject here.

But thanks for trying to help.

[Liisachan]

Yeah, I've upgraded the "file" library used for MIME type detection, and it seems it isn't that good at that. Someone else already opened an issue for it. I plan to replace it by using Qt's MIME type detection which seems to work correctly with my (very) limited set of test files (both OTF & TTF fonts), but that requires quite a bit of work on the code in "configure", which is easily my least place to work in.

As stated in the NEWS file, there is an option in the preferences to use the MIME type that the Windows version of MKVToolNix had used for TrueType fonts (.ttf, not font collections) up until v57, application/x-truetype-font. You can enable that for the time being.
Mosu, thanks for taking time to change the library for this, stopping using libmagic. I'll test new builds, maybe this weekend.

The good news is, files written by v58 are likely to be okay: MPC-HC, MPC-BE, and LAV Filters all support exotic MIMEs like font/sfnt, or even application/font-sfnt, and load the attached fonts. We specifically asked each devs for that in 2019, if you remember. Those nice devs kindly added the support for almost every possible MIME type for fonts :)

That being said, I have an important request for the Matroska people. Could you include a note like this in the new specs, related to FileMimeType?

"Matroska was born more than 10 years before the font MIME types have been standardized. Initially the generic type application/octet-stream was used for font files, and then starting in 2004, application/x-truetype-font was used for TTF embedded for subtitle tracks (by a patch by Haali), and this private MIME type was the de facto standard for many years. For backward compatibility, a player that supports embedded fonts for subtitles SHOULD treat application/x-truetype-font as font/ttf, and application/vnd.ms-opentype as font/otf. Such a player also MAY check the extention stored in FileName, when it can't recognize the value in FileMimeType: case-insensitive .ttf, .otf, .ttc strongly suggest that the attached file is font/ttf, font/otf, font/collection, respectively."

[Mosu]

IBecause for me it doesn't make any sense, functions like these in the image below, which we rarely use, have a quick access while the most used function became difficult to access.

That observation is not correct. Those attributes that only have a limited set of options ("yes", "no" and maybe "default") can easily be expressed with a simple drop-down box. Languages, however, are incredibly complex in Matroska, and the aforementioned FAQ entry explains in great detail why they're complex — and why I cannot simply use drop-down boxes for them anymore. You just don't want to accept that there is much greater complexity to languages, but that complexity is there, you cannot magick it away.

[Vicio]

That observation is not correct. Those attributes that only have a limited set of options ("yes", "no" and maybe "default") can easily be expressed with a simple drop-down box. Languages, however, are incredibly complex in Matroska, and the aforementioned FAQ entry explains in great detail why they're complex — and why I cannot simply use drop-down boxes for them anymore. You just don't want to accept that there is much greater complexity to languages, but that complexity is there, you cannot magick it away.

Not quite! I carefully read that link you passed about the elements of "LanguageIETF" "Languages BCP 47", etc... That I understood very well. The point is, can you shorten this path?! Or keep the suspend box as it was before, with a link at the end of it that directs you to this new dialog??? That way there would be a merge of the previous function (drop-down box) with this new dialog box.

See the edit I made in PhotoShop for a better understanding of what I mean.

https://i.imgur.com/V1SjBVs.jpg

[Mosu]

I explain in the FAQ that I do not want to do something like that because it totally hides the tag's information that isn't the language (such as the country or the script). It suggests to the user that the additional information isn't there. This poses huge problems: the user will most likely be surprised to find out that there is more information in the tag and why they couldn't see it.

More importantly, what should happen when you change the language when additional information is present in the tag? For example, if the current language tag is "zh-Hani-CN" (Chinese in Han script in China) and you change the language drop down to "Japanese", would that now become "jp-Hani-CN"? That result wouldn't make much sense. Would it just become "jp"? That would ALWAYS destroy the additional information present in the tag.

None of those things are easy to solve with a drop-down box directly in the track properties, not without causing a lot of confusion all around.

I get that those issues are most likely completely irrelevant to you personally. But please keep in mind that your needs aren't the only needs I keep in mind when designing features. Please acknowledge that other people have different priorities, that satisfying everyone all the time simply isn't possible. I've done my best to curb the confusion, to limit the additional work required, while still providing a powerful interface — all in a package that I can actually support with the limited amount of time I have.

[Mosu]

Mosu, thanks for taking time to change the library for this, stopping using libmagic. I'll test new builds, maybe this weekend.

As always, the continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/58.0.0/) contain the changes. I've verified that the following cases work fine:

TrueType font files whose name ends with ".ttf" or no extension at all (for testing the content-based detection) yield "font/ttf".
OpenType font files whose name ends with ".otf" or no extension at all yield "font/otf".
TrueType font collection files whose name ends with ".ttc" yield "font/collection".

What doesn't work is a TrueType font collection whose file name doesn't end in ".ttc", though I really don't care about that case, to be honest.

That being said, I have an important request for the Matroska people. Could you include a note like this in the new specs, related to FileMimeType?

Good point. I've opened an issue (https://github.com/ietf-wg-cellar/matroska-specification/issues/518) for that over on the Matroska specification repo (https://github.com/ietf-wg-cellar/matroska-specification) so that we don't forget about it.

[Vicio]

I explain in the FAQ that I do not want to do something like that because it totally hides the tag's information that isn't the language (such as the country or the script). It suggests to the user that the additional information isn't there. This poses huge problems: the user will most likely be surprised to find out that there is more information in the tag and why they couldn't see it.
On this issue, I think this is underestimating user intelligence.

But please keep in mind that your needs aren't the only needs I keep in mind when designing features.
It's not just my needs, it's those of several other users too!!! As you said yourself in the FAQ, several other people have come to you disagreeing with your decision, this just goes to show that many others were also unhappy with these changes.

But that's okay Mosu, I'm not here to riot, as I said before, I respect your decision even though I don't agree with it, because I know you could get around this problem despite the complexity that has already been said.
Success with the project.

[imhh11]

At first, I hated the new way but now I'm used to it and I prefer it :)

1 click,
press letter f (for french),
enter

[Liisachan]

It's not just my needs, it's those of several other users too!!! As you said yourself in the FAQ, several other people have come to you disagreeing with your decision, this just goes to show that many others were also unhappy with these changes. On the other hand, more than one billion other people in the Chinese speaking area will be so happy when both muxing-side and player-side finally support zh-Hans and zh-Hant, auto-selecting the right subtitle track, and that recent change is an important milestone.

But I agree with you...

I know you could get around this problem despite the complexity that has already been said. ...In principle, it should be possible to make a more convenient GUI to select a language tag quickly. Maybe something like this?

http://faireal.net/aaa/mmg-language-menu.png

- Typical users can just use the "Simple" list.
- If you want to use a more complicated tag like zh-Hans or syc-Syrj, you can choose the "Advanced" radio button.
- There may be handy shortcuts to the recently used tags (the 3rd radio button).

However, there is not enough space for this in MKVToolnix GUI. All things considered, the current GUI for a language tag is well designed, compact and intuitive enough.

Also, you can add things like ".fre." ".dut." ".ita." in your input file names, and the GUI will automatically select the tag for you, zero clicks needed.

[Vicio]

On the other hand, more than one billion other people in the Chinese speaking area will be so happy when both muxing-side and player-side finally support zh-Hans and zh-Hant, auto-selecting the right subtitle track, and that recent change is an important milestone.
But I agree with you...
Hi Liisachan, how are you? Then...

The problem is not the addition of the new functions, but the way in which they were implemented, as they sacrificed the tool's usability. For those who use MKVToolNix sporadically, these changes will not be felt. The advanced user, who is the profile that makes the most use of the software, felt that the simple task of setting the language became a painful process.



...In principle, it should be possible to make a more convenient GUI to select a language tag quickly. Maybe something like this?

http://faireal.net/aaa/mmg-language-menu.png

- Typical users can just use the "Simple" list.
- If you want to use a more complicated tag like zh-Hans or syc-Syrj, you can choose the "Advanced" radio button.
- There may be handy shortcuts to the recently used tags (the 3rd radio button).
That's exactly what I suggested before. But the developer said he doesn't want to do that, as he claims users wouldn't realize there's a shortcut to advanced functions. I don't agree with this argument, because for me this is underestimating the intelligence of the users, those who use the software frequently know at least the basic functions.
Implementing something like me and now you suggested would merge the functions. That way anyone who wanted to make advanced adjustments to the language tags would be directed to the EDIT LANGUAGE window.
https://i.imgur.com/tgexzmN.jpg



Also, you can add things like ".fre." ".dut." ".ita." in your input file names, and the GUI will automatically select the tag for you, zero clicks needed.
This I already mentioned colleague, there in my first comment. Doing this on ALL audio and subtitle tracks is as unproductive as having to keep opening a secondary window to set the language.
Manually typing track by track to add the language tag is infeasible and unproductive.
But now it's just wait and hope that the developer finds a better solution for the language tags.

PS.
I apologize if any of my words sound aggressive, but as I said before I am using Google Translate to translate from Portuguese to English, so the translations may not reflect exactly what I am saying.
Hug.

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

[Liisachan]

I apologize if any of my words sound aggressive, but as I said before I am using Google Translate to translate from Portuguese to English, so the translations may not reflect exactly what I am saying. Then you do have good reasons to support pt-PT and pt-BR, don't you? Long, long ago, when Matroska was officially released, a few sample files were provided to demonstrate what this container can do. One of the sample clips was multi-subbed, including "Portuguese (Br.)" - back then, we only had a generic tag "por" for that track... :)

[Liisachan]

As for font mime types, the new beta (58.0.0.30 tested) is clearly more reasonable. There are other (non-font-related) subtle differences, of which none seems really important so far, though some kind of issues might occur in rare situations because there are so many changes.

[58.0.0] -> [58.0.0.30]
* = winner who guessed the registered type correctly

(libmagic rules)
vorbis.ogg = [audio/ogg]* -> [audio/x-vorbis+ogg]
theora.ogg = [video/ogg]* -> [video/x-theora+ogg]
.mp2 = [audio/mpeg]* -> [audio/mp2]

(libmagic sucks)
.m4a = [audio/x-m4a] -> [audio/mp4]*
.ac3 = [application/octet-stream] -> [audio/ac3]*
.rar = [application/x-rar] -> [application/vnd.rar]*

(the new library seems cleverer in some cases)
.mka = [video/x-matroska] -> [audio/x-matroska]
.ass = [text/plain] -> [text/x-ssa]
.wv = [application/octet-stream] -> [audio/x-wavpack]

(some of other differences)
.xml = [text/xml] -> [application/xml]
.log = [text/plain] -> [text/x-log]
.mtxcfg = [application/json] -> [text/plain]
.ffindex = [application/zlib] -> [application/octet-stream]

[Vicio]

Then you do have good reasons to support pt-PT and pt-BR, don't you?


As I said before:
The problem is not the addition of the new functions, but the way in which they were implemented, as they sacrificed the tool's usability.

[Mosu]

Thanks for the overview, Liisachan. I hadn't looked into it in detail as much.

(the new library seems cleverer in some cases)

Yeah, Qt can take both the content & the file name (= the extension) into account and will use the extension for resolving ambiguities. A lot of the differences you've noticed are down to using the extension, especially .mka = audio/…

Even though some of those changes are debatable, I actually agree with these, for example:

.mtxcfg = [application/json] -> [text/plain]
.ffindex = [application/zlib] -> [application/octet-stream]

There is a clear difference between a file's encoding and its semantics. What I mean by that is: just because a file has been compressed with the z compression library doesn't mean that any other application than ffmpeg can make use of the uncompressed contents. Same with .mtxcfg files; just because it's JSON doesn't mean any other application storing their settings in JSON can make sense of my GUI's settings. That's why such files need their own MIME type, and if there isn't a specialized one, a more generic MIME type makes more sense.

[Snowknight26]

Does mkvmerge remove filler data for HEVC streams like it does for H.264? Specifically nal_unit_type = 38.

[Mosu]

Yes, it does.

[Liisachan]

Finally, I know that it is possible to rename the tracks with the tags of each language, like, pt, por, en, eng, etc... But this ends up being unproductive in the same way, as we will have to rename the tracks manually before import them into MKVToolNix.

You don't have to do that one by one manually. Create a small batch file, e.g.
ren *.ac3 *.pt.ac3
ren *.srt *.pt.srt
...and save it as "pt.cmd". From now on, whenever needed, copy pt.cmd into your source folder, click it, and every .ac3 / .srt file in that folder becomes .pt.ac3 / pt.srt.

[elubron]

Has something changed between 53 and 57-58 with regards to appending, specifically --append-mode file and track? I've been using your program to split and append matroska files and have had no problems except when the files had subtitles which I fixed by adding the option --append-mode track. If I left it at default, the file would freeze video for 1-2 seconds (audio would still play) at the point where the 2 files were joined and then start playing normally. The append-mode track option would resolve this problem until I installed 57. I tried 58 as well, but have eventually gone back to using 53.

[Mosu]

No, the code dealing with appending tracks & files hasn't changed in a long time.

[Vicio]

You don't have to do that one by one manually. Create a small batch file, e.g.
ren *.ac3 *.pt.ac3
ren *.srt *.pt.srt
...and save it as "pt.cmd". From now on, whenever needed, copy pt.cmd into your source folder, click it, and every .ac3 / .srt file in that folder becomes .pt.ac3 / pt.srt.

Hi Liisachan. Grateful for the tip.

This will be a palliative measure that will help to get around this problem for now.
I'm even preparing a new video on my channel on this subject of the "LanguageIETF" element, in it I'll give people some tips, trying to alleviate this situation. Your tip will be in the video for sure.

Greetings from Brazil.

[odino]

@odino I don't follow. For me nothing changes in the destination file name when I press Ctrl+D. Can you please be a bit more specific? What exactly is the destination file name set to before you press Ctrl+D, and what does it change to? And which operating system & which MKVToolNix version are you using?

Sorry, Ctrl+T, see the changes in the attached pics but easy to reproduce.

Windows 64bit and v58.0.0

[Mosu]

Can you post the pictures somewhere else, please? It can take quite a bit for attachments to be approved here from time to time. You can easily upload them to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server). Thanks.

[Liisachan]

This will be a palliative measure that will help to get around this problem for now. You mean it's just a workaround and not good enough? You're free to keep using older versions of MKVToolNix, if you don't like newer GUI. You can get an older, portable version, and before starting the GUI for the first time, create mkvtoolnix-gui.ini that says:
[settings]
updates\checkForUpdates=false so that it might not update itself. Or you can simply use mkvmerge directly without using GUI at all, which is most flexible and convenient once you prepare your "template" batch file — you can directly edit whatever using a plain editor (no list-box, no click, "replace all" if needed), tweaking and re-tweaking, test-muxing again and again by just typing e.g. "ep10mux"...

[Mosu]

so that it might not update itself

Just a small clarification: MKVToolNix only checks whether or not there's an update available. It does NOT contain code to update itself.

[Vicio]

You mean it's just a workaround and not good enough?
Yes, palliative, because any other language that is also inside the folder will be renamed.
At the moment, I've opted for this alternative below, but it suffers from the same problem as the *.cmd script hint.
https://i.imgur.com/OpaUssB.gif


You're free to keep using older versions of MKVToolNix, if you don't like newer GUI.
Staying stagnant in older versions can be a momentary measure, but not in the long term, as new audio and video codecs are emerging, thus making older versions outdated, so at one time or another there will be a need to use the version more current.


Or you can simply use mkvmerge directly without using GUI at all, which is most flexible and convenient once you prepare your "template" batch file — you can directly edit whatever using a plain editor (no list-box, no click, "replace all" if needed), tweaking and re-tweaking, test-muxing again and again by just typing e.g. "ep10mux"...
We don't just merge series, there are also different videos. Me and, I'm sure other colleagues also create duals of MANY different files on a daily basis! And so I say again, the user who actually makes a lot of use of the software knows exactly the difficulties I'm reporting here for these changes. Now if a person uses the software once in life and once in death, these changes make little difference.

For batch blending of series I will leave a video of my own, where I show how to do this without the need for commands. Downloadable software is in the video description.

How to Merge Audio+Subtitles from Batch Series
https://youtu.be/XR5Ez9eSRQM
https://i.imgur.com/v6mcK4m.jpg

[Liisachan]

Yes, palliative, because any other language that is also inside the folder will be renamed.

As long as there is a pattern between the file names and languages, you can automate this in one way or another. For example, if *_1.ac3 is en, and *_2.ac3 is pt, then
ren *1.ac3 *1.pt.ac3
ren *2.ac3 *2.en.ac3

Your pattern might be more complicated; you might have to use something like Perl that generates your command line, or you might have to use ugly FOR in your batch file itself. Think this as a great opportunity to try new things. Leaning script-fu will save your time greatly in the long run — a blessing in disguise.

Another simple option. Though it depends, using a text editor and directly editing the command-line is often faster once you understand how it works, than manually clicking here and there. This might be a generation gap, though. We didn't have any GUI for Matroska until MMG came out. We started by typing "regsvr32 kaxdemux.dll" to just play a MKV file ^^;

PS (2021-06-25):
@Vicio
I mean, even if you can save 4 clicks or 40 clicks per track, muxing say 13 similar files (1-season episodes of the same series) using GUI is painfully tedious. Instead, you can prepare the command line for Episode 1 (here you can use GUI and copy-paste the command line), and then copy-edit it a little to make a 13-line batch file, "mux13eps.bat". While this batch file editing is usually easy enough (surely easier than doing the equivalent thing one by one on GUI), you could even automate that if you want to (for example, if there are 10 seasons x 13 files to mux, you may want to create a "meta-script" first which generates a big batch file automatically).

@Mosu
Thanks for clarification about updating check, and for fixing the year 2038 problem! :)

[Liisachan]

@Mosu
Though this is something technical and practically not yet important, robUx4 is thinking that, becuse say 2021-01-01T00:00:00Z is not exactly 20 years (counted in SI seconds) after 2001-01-01T00:00:00Z, the Date value for it should not be D = 86400*10^9*365.25*20 = 631152000000000000 = 0x08C2 4D66 6747 0000, but 5 leap seconds should be counted:
D + 5*10^9 = 631152005000000000 = 0x08C2 4D67 914C F200.

https://github.com/ietf-wg-cellar/ebml-specification/issues/411

Though this is ideal, it’s non-trivial to be leap-second-aware; the meaning of the Date value will become ambiguous (is the writer/parser leap-sec aware or not?). What do you think? Would you implement this in MkvToolNix?

If the standard becomes rigorous like that, 0x08C2 4D66 6747 0000 is no more 2021-01-01T00:00:00Z but 2020-12-31T23:59:55Z, the conversion between the value and a human-readable string being difficult or even impossible for the future value where we don't yet know how many more leap secs there will be.

[Mosu]

I seen but not read the discussion around leap seconds. For me it's really easy: we're storing the number of nanoseconds elapsed since 2001-01-01 00:00:00 UTC. This is basically the same as what in computer terms is called the "Epoch" or the "Unix Epoch", just in nanoseconds instead of seconds & a slightly different reference date. It is a very, very common way to store dates & timestamps.

This representation doesn't concern itself with leap seconds at all, nor does it concern itself with time zones. Both only come into play when converting between that number of nanoseconds and a different representation/system, e.g. year-month-day hour:minute:second. That conversion is definitely varying over time, sure, especially when you create a file with a date that is, at the point in time when you create the file, in the future. But that's simply how it is.

Other ways of expressing & storing date information has other problems, and most are very quirky edge cases. For example, if you decide to store a date as, let's say, six integers representing year, month, day, hours, minutes and seconds. You might think that his is fine. However, as soon as you introduce a leap second somewhere, how do you store it? You could store the value 60 for a second. Most software out there, however, will break somehow if you use 60 as a number of seconds (in the form of 2345-06-07 08:09:60). And if you want to do any sort of calculation with that type of storage (e.g. calculating the difference between two timestamps stored in this six-integers-format) you cannot simply convert those six integers to a number of seconds by multiplying & adding them all up, because for certain ranges there were 61 seconds in a minute and not just 60.

Aaaaand then there are things such as countries changing time zones. And some countries simply skipping over whole sections of their calendar. If you want to go down this rabbit hole some more, see Tom Scott's excellent & entertaining video (https://www.youtube.com/watch?v=-5wpm-gesOY) on the topic.

Or to put it differently: what we think of as a "year" is actually a timeframe with of varying length. Both leap seconds & leap years make sure of that. Your calculation "86400*10^9*365.25*20" is therefore fundamentally wrong as it assumes that all years are equally long. Which they aren't.

Storing the "Unix Epoch" value (or an equivalent) is an incredibly sane way to represent timestamps. You always have to take leap seconds, time zones into account anyway.

So that's what MKVToolNix does (via Qt or other libraries): it converts between that epoch & a components-based representation based on all conversion rules available at the time of the conversion (when the user uses the program). In that way it seems Steve & I are in agreement.

[Liisachan]

I agree with you that counting leap seconds would be ideal, but this is not yet a solved problem in real life. On the contrary, not counting leap seconds is still quite common, while only a few "good" systems are leap second-aware.

A Unix timestamp, for example, is usually the number of seconds that have elapsed since January 1, 1970, 00:00 UTC, not counting leap seconds. That's why one says 2^31−1 <=> 2038-01-19T03:14:07Z. Counting leap seconds, this conversation wouldn't be deterministic, and the Y2038 problem would occur about 30 seconds before 03:14:07.

The current version of MKVToolNix, too, converts e.g. 2038-01-19T03:14:07Z <=> 0x1039BFC8B3303600, not counting leap seconds (use Header Editor to set that Date, then open it with Info Tool, see the hex dump).

While counting leap seconds is definitely ideal, the real-life implementations are generally not so ideal yet. To avoid potential confusion, there could be a LeapSecondAware flag for Date; or a legacy Date & an optional LeapSecondAwareDate elements. New LeapSecondAwareDate could be even better if it were 16 bytes, instead of 8 bytes, to avoid the Y2293 problem of EBML, in case Matroska will be still popular in the 23rd century :D

[odino]

Can you post the pictures somewhere else, please? It can take quite a bit for attachments to be approved here from time to time. You can easily upload them to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server). Thanks.

Sorry, couldn't use your the fileserver, it never connects. Maybe because my connections are on private VPNs and your side blocks it. Anyhow, I posted it here:
https://ibb.co/vvPfJM9
https://ibb.co/rvhy4Hv

I have noticed this ONLY happens when the destination file name is x:\ and not if the destination filename has additional subfolders, e.g. x:\mkvstuff\ will not change to \\ when pressing CTRL+T

Steps for Windows on v58.0.0 64bit:
1. Add a random video file into the multiplexer
2. Set destination folder to c:\filename.mkv
3. Add a file title
4. press CTRL+T or use the menu shortcut
5. the destination folder will change to c:\\filename.mkv

Not a big deal, just odd behavior. This didn't happen a few versions ago because I would have noticed.

[Mosu]

Thanks, but I cannot reproduce it following your steps; for me the result after 4. is e.g. "C:\test title.mkv". Might be dependent on certain settings in the preferences.

[DMD]

Good morning
I have detected a strange problem, it is not of great importance but I want to understand if it is possible to solve with mkvtoolnix, avoiding re-encode the video.
Regarding the issue is that when I make the muxing of most HD or UHD movies in any aspect ratio from 1.33: 1 to 2.40: 1, in the section of the "Video Properties" the aspect ratio is always 16/9 or 1920x1080 or 3840x2160.
This assumed because the film was originally coded with the letterbox bands.
What I ask you can insert a tag that does don't modify the real aspect ratio but only the value of the aspect ratio.
I hope I was understandable.
It could be possible?
Thank you very much

MKVToolNix
https://i.postimg.cc/tRYv9t5g/Ridimensiona-di-Screenshot-001.png

Mediainfo
https://i.postimg.cc/g2N3w1cb/Screenshot-002.png

Aspect Ratio 2.39:1
https://i.postimg.cc/Twqd1vGr/Ridimensiona-di-Screenshot-003.png

[dvmoo]

Hi all, I am new to here, trying to search on forums (which one to use? doom9 or gitlab, reddit from MKVtoolnix's help menu?), but it seems there is no answer to the following points:

1) To cut/remove part of a mkv, currently I have to split it by timeframes, to 1st run, then the 2nd run will append (join) the spit parts without the cut part. Is there any way to do, instead of splitting, but joining part of mkv by timeframes, within 1 run/1 output file?
This is not only to save time, but it seems that on the 2nd run, mkvtoolnix does not recognize that the files have the similar properties to proceed a quick join losslessly (thing that I've seen on an Android app), so mkvtoolnix starts from frame 1 and takes time, as long as for normal run on the whole file, meaning double time.

2) Merge ERROR: it happened (sometimes) that after joining, the (joined) 2nd part (shorter) starts, then freezes or scratches images for a second or two, then continue fine. Playing the 2nd part alone, or duplicate it (for test) and joins these 2 parts, the resulting video is fluid, the freezing part was not part of the 2nd video. How to fix that? The way I used was just add the 1st part video, then context menu append the 2nd part.

3) From my understanding, but wish to be sure: MKVtoolnix does not decode/encode during process of add/remove audio/video/subtitle items, so MKVtoolnix is "lossless" (no modification) on audio/video tracks, is that correct?

4) When a mkv has DTS audio only, it can't be played on (my Samsung) TV. So the solution was to extract DTS, then EAC3To to get AC3, then merge back with MKVtoolnix. Is there anyway that we can set in mkvtoolnix to proceed all these steps within 1 queue? Would it be a suggestion to include in MKVtoolnix a cmd for mkvextract + EAC3to and wait for their completion before continueing?

Thanks for any help or suggestion.

[SeeMoreDigital]

Regarding the issue is that when I make the muxing of most HD or UHD movies in any aspect ratio from 1.33: 1 to 2.40: 1, in the section of the "Video Properties" the aspect ratio is always 16/9 or 1920x1080 or 3840x2160.
This assumed because the film was originally coded with the letterbox bands.

The 16:9 aspect ratio refers to 1920x1080 or 3840x2160 pixel frame size. Which includes the black bars above and below the 2.40:1 image.

The Blu-ray disc video encoding specification supports 4:3 and 16:9 pixel frame sizes. It does not support cropped images...

[Mosu]

Welcome to the forum. Both here and the sub-Reddit are fine for support/usage questions such as yours. Gitlab is solely for bug reports & feature requests.

Now on to your questions:

1. The "splitting by parts" mode does exactly that: you specify one or more parts to keep when remuxing. See the documentation (https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.description.split) for examples (look for "--split parts:").

2. Due to how frames are numbered in HEVC & AVC it's possible that you're running into a limitation of the lossless (see 3.) process at this point. Read more here (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2990#note_535215149). Not saying your issue is 100% the same, just that there are certain limitations you just have to live with. The only way to "fix" this is to re-encode the video.

3. MKVToolNix does not contain any codecs, that is correct. It cannot encode/decode video. Therefore the quality won't suffer one bit. The decoded images will be the same before & after muxing. That being said, MKVToolNix does modify the bitstream where necessary (e.g. in order to patch the aspect ratio, and it throws away filler NALUs). Therefore "no modification" is incorrect.

4. No, such a feature is outside the scope of MKVToolNix. You can easily script something around mkvextract, eact3to & mkvmerge that suits your needs as they're all command-line utilities and made for scripting.

[dvmoo]

@Mosu: Many thanks, it is so quick! All your answers help well with solutions, the parameters have more possibilities than I thought, it looks so complete then, I didn't use correctly. Thanks for the tips too :)

[Perenista]

When we try to copy a subtitle like this:

******
PGS, zlib, S_HDMV/PGS, Picture based subtitle format used on BDs/HD-DVDs
******

From one MKV to another, I am not sure if I have seen this happening, instances they became smaller in the destined file, compared to the original one (which had these subtitles inserted by MAKEMKV, after ripping the disc). Are they supposed to look the same when we do this between 1080p MKVs and also between UHD/4K and 1080p?

*******
dvmoo: avoid at all cost to split any MATROSKA file. I had to do a 2nd rip from many titles again because I discovered the total duration from these video files (and anything they contained) was permanently messed with (despite all of them not being out of sync) and there was also a case in which macroblocks or similar technical issues appeared in the resulting splitted parts (especially if we are talking about UHD rips), and the problem didn't go away when joining them into a single file. I even blamed the disc without realizing it was not meant to be splitted.

This isn't MKVToolnix's fault, either, it's a feature that has been explained here to be far from perfect, so it may work for a few, it may ruin others. I am not going to split anything ever again, because some of the contents I got rid of the original source and then when I tried to merge everything back and add new stuff into them I discovered their length changed. So I am now using WinRAR even if I deal with huge files.

[SeeMoreDigital]

So yeah, having dual-layer-both-layers-in-same-track sample files would definitely help.

If you're still interested, I can send you some (short duration) 2-layer Dolby Vision .m2ts contained samples backed-up from some 4K UHD discs...

[Mosu]

Sure, thanks, though I don't expect to be able to work on that any time soon as I don't have the specs for the hvcE HEVCDecoderConfigurationRecord which I'll have to recreate from the UNSPEC63 NALUs in the bitstream.

[Mosu]

Oh wait, that's the same record structure as the hvcC, right? And parsing the UNSPEC63 NALUs shouldn't be too hard as they seem to be regular NALUs wrapped in an additional short header. I totally spaced when I wrote that above… So parsing MPEG transport streams (or rather HEVC elementary streams) with both DV layers and generating the required configuration records shouldn't be that hard.

What's more of a problem is extracting dual-layer HEVC tracks to elementary streams as that potentially requires creating UNSPEC63-variants of the parameter set NALUs in the hvcE record, and for that I'd need to understand the aforementioned additional header that UNPSEC63 NALUs start with, which I don't just yet.

So yeah, please do upload sample files. I'd appreciate it. Thanks!

[Mosu]

Heyooo!

Summer's here, so let's stay inside & play with a new release of MKVToolNix: v59. There were several nice quality of life improvements to the GUI as well as the usual bug fixes.

Several things have changed for packagers, so many that I won't list them here. You can find them the NEWS below.

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 59.0.0 "Shining Star" 2021-07-10
New features and enhancements

mkvmerge: WebVTT parser: the parser now follows the specs' rules for parsing timestamps more closely by being more lenient: it allows arbitrary number of spaces & tabs at the start of the line & around the arrow; it allows any number of digits for the hours. Part of #3139 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3139).
MKVToolNix GUI: multiplexer: when adding a Blu-ray playlist without scanning for other playlists the GUI will now look for disc library information & let the user select which one to use if there's more than one entry. Implements #3143 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3143).
MKVToolNix GUI: multiplexer: added an option for sorting files & tracks by track types when adding them to multiplex settings. The order is: video first followed by audio, subtitles and other types. Files & tracks can still be reordered manually later. The option is enabled by default & can be found in the preferences → "Multiplexer" page → "Adding files" section. Implements #2366 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2366).
MKVToolNix GUI: multiplexer: added an option for recognizing file name sequences such as "movie.001.mp4", "movie.002.mp4", "movie.003.mp4" when adding multiple files at once. If a sequence is detected, the only first file will be added while the second and following file names will be appended to the first one. The option is enabled by default & can be found in the preferences → "Multiplexer" page → "Adding files" section. Implements #2866 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2866).
MKVToolNix GUI: multiplexer: added small colored boxes for each file & track in order to indicate from which file each track is read. The colors used can be configured in the preferences → "Multiplexer" page → "File & track colors" section.

Bug fixes

build system: fixed compilation with fmt v8. Fixes #3151 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3151).
mkvmerge: SRT subtitle reader: characters that aren't valid according to the assumed encoding of the file will now be replaced by the Unicode "Replacement Character" U+FFFD instead of keeping the invalid characters, potentially violating the Matroska specs.
mkvmerge: WebVTT parser: the parser now accepts timestamps with hours larger than 99. Part of #3139 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3139).
mkvextract: TTA extraction, only on Windows: fixed removing the temporary file created during extraction.
mkvmerge, mkvpropedit, MKVToolNix GUI's multiplexer & header editor: MIME type detection is now done using Qt instead of the "magic" library. The main impact is the MIME types of TrueType & OpenType fonts are now detected correctly. Fixes #3137 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3137).
mkvmerge, mkvinfo, MKVToolNix GUI's info tool: only on Windows: displaying dates before 1970-01-01 00:00:00 UTC or after 2038-01-19 03:14:08 UTC was broken. Note that the header editor was not affected. Fixes #3148 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3148).
MKVToolNix GUI: only on 64-bit Windows: under certain conditions, the 64-bit Windows binaries crashed when opening dialog windows. Even though the underlying bug hasn't been identified, the investigation showed that building it with newer versions than 10.2.0 of the mingw/gcc cross-compiler enabled the crashes, while binaries built with 10.2.0 were fine. This affected v57 and v58 which were built with gcc versions 10.3.0 and 11.1.0 respectively. For the time being I've switched back to building Windows binaries with gcc 10.2.0. Fixes #3132 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3132) & #3133 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3133).
MKVToolNix GUI: multiplexer: when adding files to the multiplexer by running the GUI's executable with file names as command line arguments, the source directory will be remembered as the "last open directory" again, causing subsequent uses of the "open file" dialog to start in the same directory.
MKVToolNix GUI: multiplexer: the "default track flag" column in the track list was missing its icons. Additionally it contained text even for things that aren't regular tracks and therefore do not actually have that flag (e.g. chapters or tags). Fixes #3144 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3144).
MKVToolNix GUI: multiplexer: the default for the dialog asking the user what to do with dragged & dropped files if they've never seen the dialog is back to adding the files to the current multiplex settings instead of "add as additional parts" which was an unintentional default.
MKVToolNix GUI: multiplexer: the "show command line" dialog will now always use backward slashes for the "Windows (cmd.exe)" mode and forward slashes for the "Linux/Unix shells" mode, regardless of the operating system it's currently running on. Fixes #3155 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3155).

Build system changes

The Qt library is now required for building all applications, even the command-line ones, as they use Qt's MIME type detection capabilities. In turn this means that you cannot disable the Qt usage anymore; either Qt5 or Qt 6 is required. You can still chose not to build MKVToolNix GUI, though. A new option has been added to "configure" for this purpose: "--disable-gui".
The "gmp" library is now required.
The "magic" library is not used anymore.
The "PCRE2" & "JPCRE2" libraries are not used anymore. The bundled version of "JPCRE2" was removed.
Boost's "rational" library is not used anymore.
"configure": the option "--enable-appimage" has been removed. The location of the relevant directories within an AppImage is now detected automatically.
The bundled "fmt" library was updated to v8.0.0.


Have fun 😁

[Liisachan]

1) GUI: Even if "Use legacy MIME types for font attachment" is checked, .ttc is treated as "font/collection" in v59 (not in v58).

2) Valid language variant tags may be refused, when its prefix is not "simple" as in:
de-CH-1996
en-GB-scotland
zh-Latn-CN-pinyin
ja-Latn-hepburn-heploc

Example:mkvmerge -o out.mka --language 0:sl-rozaj-biske resian.m4a
Error: [...] The variant 'biske' must only be used with one of the following prefixes: sl-rozaj. Notice mkvmerge is complaining that biske must be used with the prefix sl-rozaj, but that is exactly what the user is doing here.

[alex.brown111@hotmail.com]

Hi,

I have a smooth problem with some MKV created by ffmpeg but only if read with my blu ray panasonic, no issue with PC via VLC:

If I run a command like this:

ffmpeg.exe -vsync 1 -i "G:\Film da ottimizzare per blu ray\Deep Space 9 (ffmpeg ori)\Disk3\Star Trek Season 2- Disc 1_t05_ori.mkv" -y -c:v libsvt_hevc -preset 5 -qp 21 -pix_fmt yuv420p10le -profile:v 2 -map 0:0 -map 0:s -map 0:6 -disposition:a:0 +default+forced -map 0:1 -disposition:a:1 -default-forced -map 0:2 -disposition:a:2 -default-forced -c:a copy -c:s copy -metadata:s:v:0 Language="rom" -t 60 "Star Trek Season 2- Disc 1_t05_ori.mkv_60_sec_vsync.mkv"

I get this result:

General
Unique ID : 155001068370375428158814323990732767024 (0x749C1EB1AD94DEA9BF0DBD1D91EC7F30)
Complete name : G:\Film da ottimizzare per blu ray\Deep Space 9 (ffmpeg ori)\Disk3\Star Trek Season 2- Disc 1_t01.mkv
Format : Matroska
Format version : Version 4
File size : 2.03 GiB
Duration : 50 min 31 s
Overall bit rate mode : Variable
Overall bit rate : 5 749 kb/s
Movie name : Star Trek Season 2: Disc 1
Writing application : Lavf59.3.101
Writing library : Lavf59.3.101
ErrorDetectionType : Per level 1

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 50 min 31 s
Bit rate : 14.4 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.290
Stream size : 5.09 GiB
Writing library : Lavc59.1.102 libsvt_hevc
Language : rom
Default : Yes
Forced : No
Color range : Limited

Audio #1
ID : 5
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 50 min 31 s
Bit rate mode : Variable
Bit rate : 2 622 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 10.417 FPS (4608 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : -42 ms
Stream size : 947 MiB (46%)
Title : flac Surround 5.1
Writing library : Lavf59.3.101
Language : Italian
Default : Yes
Forced : Yes

Audio #2
ID : 6
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 50 min 31 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 32 bits
Compression mode : Lossy
Delay relative to video : -42 ms
Stream size : 69.4 MiB (3%)
Title : Stereo
Language : rom
Service kind : Complete Main
Default : No
Forced : No

Audio #3
ID : 7
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 50 min 31 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 32 bits
Compression mode : Lossy
Delay relative to video : -42 ms
Stream size : 69.4 MiB (3%)
Title : Stereo
Language : English
Service kind : Complete Main
Default : No
Forced : No



there is remarkable stuttering when I choose the flac track.

But if I run this line:

mkvmerge -o "Star Trek Season 2- Disc 1_t05_ok.mkv" "Star Trek Season 2- Disc 1_t05.mkv"

The stuttering is reduced to 90% on flac track and I get this result:

General
Unique ID : 218662047772936570314451312862733510369 (0xA480C74F192512B8CDAEEF935AB3A6E1)
Complete name : G:\Film da ottimizzare per blu ray\Deep Space 9 (ffmpeg ori)\Disk3\Star Trek Season 2- Disc 1_t01_ok.mkv
Format : Matroska
Format version : Version 4
File size : 2.01 GiB
Duration : 50 min 31 s
Overall bit rate mode : Variable
Overall bit rate : 5 686 kb/s
Movie name : Star Trek Season 2: Disc 1
Encoded date : UTC 2021-07-10 06:48:51
Writing application : mkvmerge v58.0.0 ('Supper's Ready') 64-bit
Writing library : libebml v1.4.2 + libmatroska v1.6.4 / Lavf59.3.101

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 50 min 31 s
Bit rate : 2 629 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.053
Stream size : 950 MiB (46%)
Writing library : Lavc59.1.102 libsvt_hevc
Language : rom
Default : Yes
Forced : No
Color range : Limited

Audio #1
ID : 5
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 50 min 31 s
Bit rate mode : Variable
Bit rate : 2 622 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 10.417 FPS (4608 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : -42 ms
Stream size : 947 MiB (46%)
Title : flac Surround 5.1
Writing library : Lavf59.3.101
Language : Italian
Default : Yes
Forced : Yes

Audio #2
ID : 6
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 50 min 31 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 32 bits
Compression mode : Lossy
Delay relative to video : -42 ms
Stream size : 69.4 MiB (3%)
Title : Stereo
Language : rom
Service kind : Complete Main
Default : No
Forced : No

Audio #3
ID : 7
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 50 min 31 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 32 bits
Compression mode : Lossy
Delay relative to video : -42 ms
Stream size : 69.4 MiB (3%)
Title : Stereo
Language : English
Service kind : Complete Main
Default : No
Forced : No





If I play any mkv file with my PC using VLC all files work perfectly without stuttering, but if I play a MKV file with my panasonic Blu ray player the video is not perfectly smooth like PC.

I have tested it using USB 3.0 port with SSD Samsung, but the result is the some with any other disk (apart the optical disk where the result is perfect)

I ask if there is workaround with mkvmerge to solve this problem. thank you !

[Mosu]

@Liisachan Thanks, I'll fix both.

[SeeMoreDigital]

Hi Mosu,

I've just finished uploading four (short duration) 2-layer Dolby Vision .m2ts contained sample files to your server...

EDIT: And the information I posted back in Jan 2020 (https://forum.doom9.org/showthread.php?p=1895241) is still relevant in your newer releases ;)

[Mosu]

1) GUI: Even if "Use legacy MIME types for font attachment" is checked, .ttc is treated as "font/collection" in v59 (not in v58).

2) Valid language variant tags may be refused, when its prefix is not "simple" as in:

Fixes for both have just been pushed.

[Liisachan]

@Mosu
Thanks, 1) 2) both fixed! But I found different minor issues.

3) Just because LANG has valid extensions/variants A & B, doesn't mean LANG-A-B is valid.
Ex1. "de-1901-1996" obviously doesn't make sense.
Ex2. "zh-cmn-yue" should be invalid, as "zh-cmn" (Mandarin) can't be further extended as Cantonese (yue).
Ex3. Common sense dictates that "hy-arevela-arevmda" doesn't make sense either, as Eastern Armenian & Western Armenian are mutually exclusive concepts ("sl-rozaj-biske" has a different structure, where "biske" is explicitly allowed as a sub-variant of "sl-rozaj").

4) The "Edit Language" dialog should open by Alt (or something) + L. Some users, complaining about the increased number of clicks, might be happy this way too (with Alt+T and arrow keys, 0-click editing would be possible). If this isn't easy, maybe change the label "&Language" to "Langauge" to reduce UI confusion. Imho having two different UIs with the identical functions (clickable text and the pen button) is already slightly confusing.

[Mosu]

3. That's entirely correct, but nothing I'm going to fix, I've decided. I don't aim to create a 100% correct implementation. For example, at the moment I don't support grandfathered entries. Nor do I support entries with outdated codes (e.g. several examples in RFC 5646 use the country code "CS" which stood for the European country of "Serbia & Montenegro" — a country that doesn't exist anymore as they split into "Serbia" (RS) and "Montenegro" (ME); now "CS" isn't part of ISO 3166 anymore, and MKVToolNix rejects tags using it as invalid). And my code doesn't enforce the preferred order within extended language & variant sub-tags. Etc.

I consider it good enough. It should definitely not reject valid tags (apart from the grandfathered entries mentioned above), but I don't care that much for the other part (rejecting all invalid ones), to be honest.

4. Hmmmmmmmmm well. That won't make anyone not complain, I'm afraid. If they don't like the extra dialog, they don't like it. At the moment you can use the sequence "Alt+K Tab Space" for opening the dialog already. That's pretty quick to hit; shortening it to just Alt+L would not save that much time.

I'll think about it.

Edit: fixed key binding for "track name"; it's Alt+K, not Alt+T

[Mosu]

4) The "Edit Language" dialog should open by Alt (or something) + L

GUI: mux: open language dialog when pressing track language label's shortcut (https://gitlab.com/mbunkus/mkvtoolnix/-/commit/3a9358ec09601adca371768c71d557495d8dc70d)

[Liisachan]

3) is okay for now, not really a practical problem. I was just wondering if you really assume "zh-mnp-nan" is valid here:
EXPECT_TRUE(mtx::bcp47::language_c::parse("zh-mnp-nan-Hant-CN").is_valid());

There are many 639-3 tags that can't be supported as legacy (639-2 based) Language values in Matroska, and not yet supported as LanguageIETF either. However, perhaps "cnr" should be supported since it's in ISO 639-2.

4) was something more basic. If UI says "Cop&y, Trac&k, &Language", users think Alt+Y, Alt+K, Alt+L should work; Alt+L did work in the past, so thanks for making it work again. (I too doubt this will make Vicio any happier, though.)

[Mosu]

4) was something more basic. If UI says "Cop&y, Trac&k, &Language", users think Alt+Y, Alt+K, Alt+L should work

Yeah I totally agree. I didn't remember that "Language" already has a keyboard shortcut — and it being present but not working is really not what I want.

I've just added similar shortcuts to almost all other places where language display widgets are used.

[Mosu]

I've reconsidered and "improved" (https://gitlab.com/mbunkus/mkvtoolnix/-/commit/a351d7629f86e61311261524395a31d783df8bef) (= fixed) the parser's validation of prefixes. Pretty much all examples you listed now test correctly, as do a lot of their variants for which I added a lot more test cases (e.g. "de-1901" and "de-1996" being valid, "de-1901-1996"). A side effect is that the order matters now, meaning "sl-rozaj-biske" is considered valid whereas "sl-biske-rozaj" isn't.

One thing I haven't changed (and don't think I ever will) is supporting legacy codes.

3) is okay for now, not really a practical problem. I was just wondering if you really assume "zh-mnp-nan" is valid here:
EXPECT_TRUE(mtx::bcp47::language_c::parse("zh-mnp-nan-Hant-CN").is_valid());

That was actually an example in RFC 4646 Appendix B in the "valid" section — which was a bit confusing, especially given that both extended language subtags ("mnp" and "nan") are known & valid, but their combination isn't, at least according to the current IANA language registry. I've changed that test to require failed validation.

However, perhaps "cnr" should be supported since it's in ISO 639-2.

My scripts generating the various lists only downloads certain data from the internet; other data is taken from Arch Linux's copy of ISO codes (which originates in Debian's work to turn those list into easily parseable JSON files). That copy doesn't include "cnr" yet; that's why it's missing from MKVToolNix. There's an open issue (https://salsa.debian.org/iso-codes-team/iso-codes/-/issues/29) for including "cnr" already, but judging from the open issues & merge requests the project looks not to be too active, unfortunately.

I'll look into downloading the lists directly from ISO's website directly (e.g. ISO 639-3 is available here (https://iso639-3.sil.org/code_tables/download_tables)) and parsing those.

Thanks for all the testing & the feedback!

[Liisachan]

A side effect is that the order matters now, meaning "sl-rozaj-biske" is considered valid whereas "sl-biske-rozaj" isn't.

That should be a correct behavior: biske is a member of sl-rozaj, but rozaj is not a member of "sl-biske" (which is invalid). Get a second opinion from [ https://validator.w3.org/#validate-by-input ]
<!DOCTYPE html><html lang="sl-rozaj-biske">
<head><title>test</title></head></html> validates, while <!DOCTYPE html><html lang="sl-biske-rozaj">
<head><title>test</title></head></html> gets an error.

One thing I haven't changed (and don't think I ever will) is supporting legacy codes. So that old Matroska files will always play fine, both by old and new players, even if future players may be reading LanguageIETF by default? I think that's a very good thing, and I hope the same thing will be true about the legacy font mime types too.

Let's say the audio track is Cantonese. Language=yue is impossible in the current Matroska specs, so we have Language=chi. The question is, can we have LanguageIETF=yue at the same time? Or should it be LanguageIETF=zh-yue even though being redundant and not the best practice? This may become an issue when players actually start reading LanguageIETF. Perhaps we're going to have to ask player-side devs to support both yue and zh-yue equally, just like standard and legacy font mime types.

That was actually an example in RFC 4646 Appendix B in the "valid" section — which was a bit confusing, especially given that both extended language subtags ("mnp" and "nan") are known & valid, but their combination isn't, at least according to the current IANA language registry.

It's your accidental typo :) RFC 4646 Appendix B says zh-min-nan (grandfathered but valid), not zh-mnp-nan (and neither zh-mnp nor zh-nan is valid). As LanguageIETF in Matroska, if we use zh-yue instead of yue, then we'll have to use zh-min-nan instead of nan, for the same reason. This point itself may be debatable, though.

EDIT: The last paragraph is wrong. Both zh-mnp and zh-nan are valid, and also zh-min-nan is technically valid too: "nan" (preferred) = "zh-nan" (synonym) = "zh-min-nan" (grandfathered), while "ms-min" = "min" ≠ "zh-min". Really confusing...

[Mosu]

That should be a correct behavior: biske is a member of sl-rozaj, but rozaj is not a member of "sl-biske" (which is invalid).

Yes. What I said wasn't exactly what I meant to say, which was "order matters & MKVToolNix now gets it right".

Let's say the audio track is Cantonese. Language=yue is impossible in the current Matroska specs, so we have Language=chi. The question is, can we have LanguageIETF=yue at the same time?

Yes, though mkvmerge only helps you so much in this regard. If you use e.g. "--language 1:yue", it will set LanguageIETF=yue but (Legacy)Language=und as yue doesn't have an associated 639-2 code. At the moment you cannot specify both independently of each other, and I have no plans to implement that capability either (mostly because it would be a real nightmare to implement in the GUI that isn't a huge confusion pile of poo).

If you need to support legacy players in such situations, you can use mkvpropedit after multiplexing. It will treat the property "language" similarly to mkvmerge, namely setting both LanguageIETF and (Legacy)Language, but it also knows the "language-ietf" property which will only set LanguageIETF. So:

"mkvpropedit v.mkv --edit track:2 --set language=chi" will set LanguageIETF=zh, (Legacy)Language=chi
"mkvpropedit v.mkv --edit track:2 --set language=chi --set language-ietf=yue" will set LanguageIETF=yue, (Legacy)Language=chi (Attention: order matters here; using them the other way around, "language" after "language-ietf", would mean that the value from "language" overrides the one from "language-ietf" as "language" sets both)

Using "--language 1:zh-yue" works, too. In that case mkvmerge will set LanguageIETF=zh-yue and (Legacy)Language=chi as chi is the 639-2 code associated with the 639-3 code zh.

So as to the question what best to do in order to be properly compatible, let's just say… it's complicated. My take: decide on either of the following:

Multiplex with language "zh-yue" if compatibility with older players is important and you want the simplest workflow
Use mkvpropedit with "--set language=chi --set language-ietf=yue" after muxing if compatibility with older players is important and you're OK slightly complicating your workflow[1]
Multiplex with language "yue" if compatibility isn't that important

[1] This can even be automated. The GUI supports running arbitrary programs after multiplexing. One could write a script (in whatever language) that uses mkvmerge to query the current track languages. For all tracks with a language of "yue" it runs mkvpropedit on the file & uses the aforementioned "--set language=chi --set language-ietf=yue" for those tracks. Then configure the GUI to run that script after mutliplexing & use "yue" as the track language going forward.

also zh-min-nan is technically valid too:

I disagree; the IANA registry only lists "zh" as a valid prefix for both extended language subtags "min" & "nan".

One thing be both definitely agree on:

Really confusing...

!!! 😁

[Liisachan]

The recent updates are impressive, but there seem to be some accidental regressions. A few basic tags are now refused: Latin (la; lat), Sign Languages (sgn), Artificial languages (art). Also, some minority tags, previously recognized, are now refused (lsg, rsi...).

I suggest you use https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry which is solid and more up-to-date than SIL's tables — also including recently added 3-letter codes (bic, bij, blg...) & script codes (Ougr, Pcun...).

I disagree; the IANA registry only lists "zh" as a valid prefix for both extended language subtags "min" & "nan".

You’re right, zh-min-nan is not a valid langtag. However, according to RFC4646, §2.1, a language tag is valid, not only when it is a valid langtag, but also when it is grandfathered. Actually, contrary to what you said, zh is not even listed as a valid prefix for min:
Type: extlang
Subtag: min
Prefix: ms But zh-min is grandfathered (i.e. an exception of the langtag rules):
Type: grandfathered
Tag: zh-min Similarly, zh-min-nan is grandfathered.

The current test version of MKVToolnix tends to refuse deprecated tags. Totally refusing deprecated tags, though, one can't use zh-yue: Type: redundant
Tag: zh-yue
Description: Cantonese
Added: 1999-12-18
Deprecated: 2009-07-29
Preferred-Value: yue

Legacy tags like zh-*** might be necessary as you explained. On the other hand, it would be ideal to keep things simple, refusing redundant/deprecated tags. If I could arbitrarily update the Matroska specs, I’d simply allow ISO 639-3 as the value of Language, e.g. Language=yue, Name=Cantonese. If a player selects a track by simple string comparison, it doesn’t need to know what yue means. A Cantonese-speaker can just type "yue" in the "preferred audio language" editbox, and everything would work. The current version of MPC-HC and MPC-BE can already do this (tested after changing 'und' to 'yue' by a binary editor), even showing nicely "Cantonese [yue]" in the audio menu.

I kind of understand why zh-yue (Deprecated, Redundant) is recommended over yue (standardized in 2009) in Matroska. But then, because of similar, practical reasons, shouldn't application/x-truetype-font be recommended over font/ttf? What's the point in using font/ttf, when both old and new players understand the legacy mime but not all players don't recognize font/ttf (standardized in 2017) yet? If anything, I'd make the "Use standard mime types for font attachments" checkbox as opt-in for those who really want to use them: enabling it doesn't really improve anything, except maybe the file size will become smaller by a few bytes, while confusing or upsetting a few end users (like those who are still using the last official version of MPC-HC). Imho the mime-type transition was slightly premature, with few advantages; it could have waited for a little longer, until most MPC-HC users switch to clsid2 builds or -BE. SourceForge, once a great site, is making things difficult, still recommending old MPC-HC (which doesn’t recognize font/ttf), along with the latest stable version of MPC-BE.

[Mosu]

The recent updates are impressive, but there seem to be some accidental regressions. A few basic tags are now refused: Latin (la; lat), Sign Languages (sgn), Artificial languages (art). Also, some minority tags, previously recognized, are now refused (lsg, rsi...).

Yeah, I excluded languages of type A (ancient = extinct since ancient times) & E (extinct in recent times). Latin falls into type A.

Artificial got lost 'cause I only process 639-3 at the moment and "art" is only part of 639-2 but not of 639-3. In fact, 639-3 doesn't contain language collections while 639-2 do, and I totally forgot about that fact.

I'll re-add processing 639-2 lists & disable filtering by type. That'll add… another 1.000 entries or so…

I suggest you use https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry which is solid and more up-to-date than SIL's tables

The LSR (language subtag registry) doesn't provide all the information I need, unfortunately. For example, it doesn't contain 639-3 alpha 3 codes if there is a 639-3 alpha 2 code. Search for "lat" and you'll see what I mean. You can find the entry for "la", of course, but no mention of "lat". Same for bibliographic vs. terminologoy 639-2 codes; it doesn't include those at all (see entry for German for which "de", "ger" and "deu" must be recognized, "de" used in LanguageIETF and "ger" in (LegacyLanguage) — but the LSR only lists "de", obviously).

I am using the registry for extended language sub-tags & variants, though.

However, according to RFC4646, §2.1, a language tag is valid, not only when it is a valid langtag, but also when it is grandfathered.

Ah, that would explain why it's listed in the "valid" section of Appendix B. As I said, MKVToolNix doesn't support grandfathered entries at the moment & no plans to change that.

Actually, contrary to what you said, zh is not even listed as a valid prefix for min:

Oh, you're right. I must have accidentally looked in the next line in iana_language_subtag_registry_list.cpp, which is "mnp" and which is valid for "zh". My bad.

On the other hand, it would be ideal to keep things simple, refusing redundant/deprecated tags.

I disagree. Neither is invalid. If they're accepted now, there's no reason to change that.

What's the point in using font/ttf, when both old and new players understand the legacy mime but not all players don't recognize font/ttf (standardized in 2017) yet?

Correctness & using standards where possible. As there's no way to know when "most MPC-HC users have switched", there's no use in waiting. Any timeframe is arbitrary.

With your arguments you could even refuse to ever add any type of new element (such as LanguageIETF) to Matroska ever again as there are always players out there refusing to play files that contain elements they don't know about, and we don't know when users have switched over from those players. It's a losing game.

For those who have problems with the MIME types, several options exist. It's up to the user to decide how much legacy support they want to offer.

[Liisachan]

A weird behavior, perhaps introduced somewhere between v52 and v56. When the language name for a 3-letter code (e.g. 'hmj') is exactly 2-letter (e.g. 'Ge'), and this 2-letter name is not identical to any valid language tag, then the 2-letter string is accepted as if it were a valid language tag.

Exmaple (note "ge" is not a valid language tag)
mkvmerge -o out.mka --language 0:ge in.ogg
mkvinfo out.mka
...
| + Language: und
| + Language (IETF BCP 47): hmj

For example, it doesn't contain 639-3 alpha 3 codes if there is a 639-3 alpha 2 code. Ah, that's right!

I disagree. Neither is invalid. If they're accepted now, there's no reason to change that.
I have nothing against zh-yue, etc. As a general statement, though, it would be ideal if this part is as simple as possible, the same language not having many, confusing synonyms.

I have nothing against font/ itself either, but the switch was a bit abrupt. I thought you agreed that the mime type transition wouldn't be a surprise attack, and that there would be some kind of advance warning. If I had known there were going to be MIME type changes, I could have tested pre-release versions and chances are, the MIME-related bugs in v58/59 wouldn't have existed. But v58 had been already released, so it's pointless to say this. The problems were fixed rather quickly, for which I'm thankful :)

With your arguments you could even refuse to ever add any type of new element (such as LanguageIETF) to Matroska ever again as there are always players out there refusing to play files that contain elements they don't know about, and we don't know when users have switched over from those players. It's a losing game. Well, as you know very well, the nature of EBML is such that it's freely extensible on the assumption that a parser will ignore elements that don't know or don't want to support. The font mime problem is different, in that an old parser does know the element FileMimeType, and we're changing the semantics of the value of this existing element. There has been an agreement that one must use "application/x-truetype-font" for an embedded font for subs. Haali/Gabest said, "use this, or else the font is not used" and typesetters were like "Okay, we'll use it". Other players also accepted the same protocol, and everything has been working fine for 10+ years. Breaking this agreement is much trickier than adding a totally new element (which can be harmlessly ignored).

Anyway, it was unfortunate that there didn't exist registered mime types for font files... it's no one's fault.

Because of this experience, it seems natural to ask this pre-emptively: maybe should we use "yue" instead of "zh-yue" from the beginning, so that the value of languageIETF will remain stable? Just wondering, not insisting anything. Perhaps whichever is fine, because hopefully a good player in the future will support both.

[Mosu]

A weird behavior, perhaps introduced somewhere between v52 and v56. When the language name for a 3-letter code (e.g. 'hmj') is exactly 2-letter (e.g. 'Ge')

Interesting case. Turns out, "Ge" is a valid _name_ of a language. This will only work with language names that are three letters long or shorter; otherwise the regular expression used to match against a BCP 47 tag structure won't match.

You can also use the language called "Gen" as an example; it works, and its code "gej" is written to the Matroska file.

I'll definitely fix this, most likely by removing the comparison to the name field as I don't think I ever intended that to work.

I have nothing against font/ itself either, but the switch was a bit abrupt. I thought you agreed that the mime type transition wouldn't be a surprise attack, and that there would be some kind of advance warning. If I had known there were going to be MIME type changes, I could have tested pre-release versions and chances are, the MIME-related bugs in v58/59 wouldn't have existed.

The problem with that is that I would have to had prior knowledge about how that went down. The thing is, MIME type detection depended on the "magic" library. For quite a while the Linux builds of MKVToolNix were using newer versions of the library (the ones that come with the respective distribution) whereas the Windows variant of the same MKVToolNix release were built with a rather ancient version of the same library. This meant that the same MKVToolNix version detected font MIME types differently without me realising this at all.

What drove me to update magic for the Windows build wasn't to make behavior the same across OSses, either. Instead, I primarily wanted to update in order to remove a ton of potential security issues in said library. magic deals with untrusted material from untrusted sources. I have a moral responsibility to keep it as up to date as possible.

Now why did I wait so long to update? That wasn't intentional either. I'm using the "MXE" project for cross-compiling from Linux to Windows. MXE functions a bit like a Linux distribution, just for providing huge set of build recipes that can compile everything from the compiler & the libraries & the programs on Linux to be run on Windows so that you can build your own program on top of that infrastructure. I'm relying on the MXE project keeping their build recipes up to date. For magic, unfortunately, that build recipe was quite stale, it turned out.

After updating the library I realized that it featured a change to font MIME types. When I compared that to Linux I noticed that on Linux the new font types had already been in use for quite a bit. So that seemed to be as good a time as any to change over officially as part of my releases had done so for a while.

If I had planned it all in advance, this would likely have gone down differently. It was more of an accident, though, and things were already broken.

The font mime problem is different, in that an old parser does know the element FileMimeType, and we're changing the semantics of the value of this existing element.

I get that, believe me, and like I said above, if it had been a planned change and all that.

Because of this experience, it seems natural to ask this pre-emptively: maybe should we use "yue" instead of "zh-yue" from the beginning, so that the value of languageIETF will remain stable?

Unlike font MIME types, there are valid, specced options for Chinese in BCP 47 today. Some of them just might be removed one day. When (or even if) that will be, I don't think anyone really knows.

I wrote earlier about the three options I see for users. I will not and cannot make a recommendation. I know what I'd do for my personal files, were I to speak Chinese, which I'm not, but personal libraries are just one of the many use cases, a lot of them with widely different requirements. So… yeah. 🤷

With BCP 47 I think players will have to do a lot of leg work for "proper" support for them, whatever "proper" means, exactly. In MKVToolNix I only need to consider creating (= letting the user input them), validating (either from user input or from existing data) and partially with displaying them.

For players, the "displaying them" part becomes that much more important, and there are so many things to consider, given that tags can become so large, and replacing the subtags with their corresponding names might yield huge huge-readable strings. On top of that players have to implement matching: letting the user chose their preferences, then matching those preferences to existing tags and deciding which to auto-select. I don't envy them that work, and I fear most players won't put too much work into it (if any at all; sticking to (Legacy)Language is probably appealing to a lot of developers).

BCP 47 is bloody huge. But just like Unicode, this isn't actually a technical problem, it's a human problem, as we were the ones to create all those languages and scripts and symbols. Basically we all have ourselves to blame for all the work we now must do 😁

[ctl-tx]

I have a request. Is it possible to make the "use legacy MIME types for font attachments" Preference apply to fonts attached in the Header Editor as well? Right now, I would have to manually enter the legacy MIME type into the MIME type box. It's a pain if there's more than a handful of fonts being attached.

[varekai]

@Mosu
First, read and watched on TV news about the disastrous flooding in Western Europe and hope you are safe.

Second, thanks for this one-of-a-kind software, really apprecitate it!
Win 10 + MKVToolNix v59.0.0

I've read the MKVToolNix FAQ but am uncertain if my method is supported?
I have several media files with video and audio and srt subtitles.
I would like to remove some audio tracks and subtitles and then multiplex to separate files to another HDD.
Thinking this will speed up the multiplex?
What I can't get to work is that the video files should be kept as is one by one and not joined to one big file.
Racking my brains trying to figure out the settings for batch and output to another HDD directory folder.
Think I read in FAQ that batch is not possible?
But... some time ago I think I got it to work... but I can't repeat that...

Best regards
varekai

[Mosu]

I have a request. Is it possible to make the "use legacy MIME types for font attachments" Preference apply to fonts attached in the Header Editor as well? Right now, I would have to manually enter the legacy MIME type into the MIME type box. It's a pain if there's more than a handful of fonts being attached.

I thought I had done that, but you're right, it doesn't work as intended at the moment. I'll look into it.

[Liisachan]

If Header Editor can do that, maybe the attachment MIME types should be automatically updated while MKV-to-MKV transmuxing, when the user opts out from using "font/".

Unlike font MIME types, there are valid, specced options for Chinese in BCP 47 today.

The truth is opposite in a way. On the one hand, the specs say both (1) using an x- value without registration and (2) registering a (non x-) value with IANA, are acceptable mechanisms for defining a new media subtype. For example "video/x-matroska" is acceptable (valid), though it can't be registered as-is. Similarly, "application/x-truetype-font" is valid, except it can't be registered as-is.

On the other hand, "zh-yue" is registered and explicitly marked as "obsoleted" since more than 10 years ago, with "Preferred-Value: yue". Although zh-yue is still valid, it's no more preferred.

The real bad legacy, though, may be "application/vnd.ms-opentype" for OTF. This one is not an x- type, nor registered. So technically it's really invalid (or are there some kind of exceptions for "vnd." ?).

[Mosu]

If Header Editor can do that, maybe the attachment MIME types should be automatically updated while MKV-to-MKV transmuxing, when the user opts out from using "font/".

The option only affects the MIME type of newly added attachments, not of existing attachments. I'm not a fan of auto-updating existing MIME types either. In addition it would be quite some work for mkvmerge as it doesn't support modifying existing attachments at all at the moment. All of that requires more time than I'm willing to invest.

[LeMoi]

Hello and thanks for the latest update.

- I don't really understand the new 'Default' track system. Before this update, there were automatically only one (the first) track that was marked as default, one video, one audio and one subtitle track, now, every track is marked as Default, is this normal ? I manually unselect the other tracks to keep only one of each type as default, do I need to or can I keep them all as Default?
- Since the latest version, the files are not added in the correct order if there's numbers in the first chars, even if they are selected in the right order in the 'Add window'
https://nsa40.casimages.com/img/2021/07/24//210724123643701334.jpg
Before this update, the file "10_..." was added after the file "9_...", I don't really understand why this the "10_..." file is added after the "4_...'

PS : in this example, "0_..." is video, "1_..." to "4_..." are audio files, other files are subtitles (idx/sub and SRT)

[Mosu]

- I don't really understand the new 'Default' track system. Before this update, there were automatically only one (the first) track that was marked as default, one video, one audio and one subtitle track, now, every track is marked as Default, is this normal ? I manually unselect the other tracks to keep only one of each type as default, do I need to or can I keep them all as Default?

The meaning of the "default track" flag has changed in the Matroska specs recently. The original meaning was "this track should be played by default". It turned out that this wasn't what most players implemented, nor what was actually useful. Therefore we (= the Matroska specs team) decided to change it to mean "this track is eligible to be played by default" with the expectation that other factors such as a track's language factor into this decision as well.

Here's the current wording from the spec notes (https://www.matroska.org/technical/notes.html#default-flag):

The “default track” flag is a hint for a Matroska Player indicating that a given track SHOULD be eligible to be automatically selected as the default track for a given language. If no tracks in a given language have the default track flag set, then all tracks in that language are eligible for automatic selection. This can be used to indicate that a track provides “regular service” suitable for users with default settings, as opposed to specialized services, such as commentary, hearing-impaired captions, or descriptive audio.

The Matroska Player MAY override the “default track” flag for any reason, including user preferences to prefer tracks providing accessibility services.

For example, if you have four audio tracks, with the first one containing director's comments in English, the other track being regular soundtracks in e.g. French, English and Japanese, the first track should NOT have "default track" set, the other three SHOULD have it set. That signals to a player that it should select one of the tracks 2, 3 or 4 by default, taking the user's language preferences into account.

MKVToolNix was changed to match the current specs.

If you're interested in the details, they're discussed here (https://github.com/ietf-wg-cellar/matroska-specification/issues/374) and here (https://github.com/ietf-wg-cellar/matroska-specification/pull/447).

- Since the latest version, the files are not added in the correct order if there's numbers in the first chars, even if they are selected in the right order in the 'Add window'

Hmm yeah, I'm now forcefully sorting the list alphabetically, which was necessary in order to implement feature request 2866 (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2866), and from the pure string comparison point of view 10_… sorts lower than 2_… as the numeric value of the '0' character is lower than the numeric value of the '_' character. This is a common problem with sorting strings with numbers on a computer if the sorting algorithm isn't specifically aware of their mixed nature. One simple-ish workaround is to prefix numbers lower than 10 with a 0, making them 01_…, 02_…, 10_… etc., which works as the characters representing numbers always sort how a human would say "correctly" when comparing them amongst themselves.

That being said: I do have such a numbers-aware sorting algorithm in MKVToolNix already and use it in other appropriate places. I'll simply switch to that one which should both fix your issue & keep feature request 2866 working.

[LeMoi]

Thanks for your answer about the 'default' flag, I got it.

One simple-ish workaround is to prefix numbers lower than 10 with a 0, making them 01_…, 02_…, 10_… etc., which works as the characters representing numbers always sort how a human would say "correctly" when comparing them amongst themselves.

That being said: I do have such a numbers-aware sorting algorithm in MKVToolNix already and use it in other appropriate places. I'll simply switch to that one which should both fix your issue & keep feature request 2866 working.

About the sorting algorithm, I know older versions of Windows needed the numbers to have same-digit numbers to be sorted correctly, but Windows 7 fixed that and most programs now handle that correctly. MKVToolnix used to do so, so that's why I was surprised to see this regression -to me.
I'll use two-digits numbers if there are more than 9 tracks until maybe there'll be a fix

[Mosu]

Well, it's not an OS-level thing (Windows x vs Windows y vs Linux), but a per-application thing. You probably mean Windows Explorer in WinXP vs its variant in Win7.

The thing is, for detecting sequentially-numbered files (one of the prerequisites) I need to process them in numerical order so that the file numbered N comes directly before N+1. There really is no guarantee for me, the application, that the file names handed over either via the operating system (via drag & drop), from an application-specific "open file" dialog or from the command line (think of Windows' "send to" feature) are sorted. Therefore MKVToolNix must do so. Earlier versions didn't have the aforementioned feature, therefore they didn't care about the order.

But like I said, should be easy to fix.

[Mosu]

First, read and watched on TV news about the disastrous flooding in Western Europe and hope you are safe.

Meh, totally overlooked your post. Thanks for your concern! Luckily for me I live well away from the affected areas and am not involved directly. I do have friends in the region, though, and yes, they're all luckily still alive. Many of them have lost their houses, though, some partially (basement & first floor completely flooded and uninhabitable), some have lost everything. It is kind of apocalyptic there.

What I can't get to work is that the video files should be kept as is one by one and not joined to one big file.

Sounds like you're adding all the files to a single mutliplex job. That won't work. Each multiplex job always creates one Matroska file, no matter how many files you add to it. If you want to create multiple Matroska files (one for each source file) you'll have to create one multiplex setting for each source file, too.

There are several avenues for automating such processes, including implementing something around the command-line tool mkvmerge or using third-party applications.

[Mosu]

I'll use two-digits numbers if there are more than 9 tracks until maybe there'll be a fix

I just saw in the source code that sorting is only done if the "recognize file sequences" feature is turned on in the preferences: "Multiplexer" → "Detect file name sequences…" Turning it off should help you, too.

[Mosu]

The latest continuous builds (https://mkvtoolnix.download/windows/continuous/) have the sorting issue… sorted 😊

[Perenista]

Why is it that MediaINFO says my video has a name but MKVToolnix doesn't show that name nowhere inside the file? I mean the track itself has been "named" but I am not seeing anywhere where this information is stored, so I can remove or edit...

EDIT: located in the HEADER editor. Is there a problem if we remove this element?

[Mosu]

The movie/segment title is purely option. It can be removed safely.

In the multiplexer the movie/segment title can be found on the output tab.

[LeMoi]

I just saw in the source code that sorting is only done if the "recognize file sequences" feature is turned on in the preferences: "Multiplexer" → "Detect file name sequences…" Turning it off should help you, too.

Unfortunately I like the 'Recognize file sequences' feature, so I don't really want to turn it off!

I tried the latest build, the problem looks to be solved, thanks for your reactivity :)

[Mosu]

You're quite welcome. Thanks for the report.

[Liisachan]

The option only affects the MIME type of newly added attachments, not of existing attachments. True, disregard that comment of mine. Not only the implementation would be non-trivial for you, this would also mean, for consisntency, that the mime types of existing attachments should be auto-updated in the reverse way too when MKV is transmuxed, and most users probably don't expect/want that.

(Users of v58 may want to fix the broken mime types due to libmagic, but they can do so by re-muxing instead of transmuxing.)

[varekai]

@Mosu
Thanks for your kind reply, much appreciated.
Good to hear all is well with you.
I can feel your concern for your friends, it is troubled times now.

You presented some new ideas to me and I will do some trial&error.
I'm not very good at using command-line but I'll figure it out... :D

Best regards
varekai

[Mosu]

Heya everyone.

Here's a new release of MKVToolNix: v60. It includes a substantial amount of improvements for BCP 47/RFC 5646 language tags. It also fixes a nasty bug in the HEVC code that could lead to a loss of some frames when appending HEVC tracks under certain circumstances.

Nothing's changed for package maintainers this time around.

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 60.0.0 "Are We Copies?" 2021-07-31
New features and enhancements

all: IETF BCP 47/RFC 5646 language tags: added support for language families from ISO 639-5 that aren't part of 639-2.
all: IETF BCP 47/RFC 5646 language tags: implemented support for Alpha 2 country codes of the "user-defined" category: "AA", "QM"–"QZ", "XA"–"XZ" and "ZZ".
all: IETF BCP 47/RFC 5646 language tags: updated the various lists of valid subtags from the official specs.
MKVToolNix GUI: multiplexer: pressing the keyboard shortcut for the track's "Language" label (Alt+L for English) will now open the language dialog.
MKVToolNix GUI: multiplexer: added an option in the preferences for turning off the colored boxes indicating which file each track belongs to.

Bug fixes

all: IETF BCP 47/RFC 5646 language tags: fixed validating extended language & variant subtags against their allowed prefixes (e.g. a valid tag with a country code as in "de-CH-1996" is recognized as valid while two generally known variants that aren't allowed together as in "de-1901-1996" is recognized as invalid).
all: IETF BCP 47/RFC 5646 language tags: when looking up a language for a two- or three-letter code, the programs will no longer compare that code with language names as that was unintended, ambiguous (e.g. the code "Ga" could be interpreted as the 639-2 alpha-2 code for "Irish" or as the name of the language called "Ga") and only worked with languages whose name was at most three letters long.
mkvmerge: HEVC/H.265: appending Matroska files with HEVC tracks might lead to the loss of the first couple of frames from each of the second and all following files. Fixes #3170 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3170).
mkvmerge, mkvextract: HEVC/H.265 parser: fixed the programs aborting when parsing VPS or SPS NALUs with invalid content due to unhandled exceptions. Fixes #3162 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3162).
MKVToolNix GUI: multiplexer: when the option "use legacy MIME types for font attachments" is enabled, the GUI will now use "application/x-truetype-font" for font collection files.
MKVToolNix GUI: multiplexer: fixed escaping the "mkvmerge" argument in the "Show command-line options" dialog for the "Windows (cmd.exe)" mode. Fixes #3164 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3164).
MKVToolNix GUI: multiplexer: when adding multiple files at once, the GUI will sort file names with numbers the way a human would expect it to. For example, "1.mp4", "9.aac", "10.srt", "11.srt" are now sorted exactly that order instead of "1.mp4", "10.srt", "11.srt", "9.aac".
MKVToolNix GUI: header editor: the header editor will now honor the "use legacy MIME types when adding font attachments" setting when adding new attachments.


Have fun 😎

[hubblec4]

Thanks a lot for all your work.

[VBB]

Thanks Mosu!

[Perenista]

I have a situation with the app...

- With a MKV open I am trying to add track #1 (MP3 audio) from an AVI. The AVI has 2 audio tracks.
- Then I have chosen all these options:

https://i.postimg.cc/Bnr3W5k2/X1.png

The problem is: MKVToolnix is saying "default: YES" for both audio tracks and telling me portuguese is their language.

I get it that MKVToolnix is saying PT for both. What shouldn't happen here is default: YES. It should be default: NO for the two.

This is after I edit the MKV before saving, so fixing the problem described:

https://i.postimg.cc/mrBdFtF0/XX2.png

Doing this to dozens of videos is going to be a waste of time....

If I am not mistaken what is missing here is a new option, which is only available for subtitles:

Disable "default track" flag for audio tracks

[Mosu]

You're not up to date what the "default track" flag means according to the current Matroska specification. That meaning has changed within the last year or so, and MKVToolNix was adjusted to match that new meaning. Please see this post (https://forum.doom9.org/showthread.php?p=1948368#post1948368) where I've written about it a few days ago. I also have a slightly more concise FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Default-and-forced-flags-and-default-yes-no-in-the-GUI#meaning-of-the-flags) on the topic.

[Mosu]

Anyone using MKVToolNix v60 should probably check the preferences → "Multiplexer" → "Process Priority"& set it to "lower" if it's on "lowest", v60's new default. Unfortunately "lowest" is substantially slower on Windows, even if nothing else is going on.

Unfortunately I forgot to mention that new default in the NEWS.md file for the v60 release. I've now changed the default to "lower" and included a note in NEWS.md.

This problem only affects users with a new installation/when no settings file exists.

[Liisachan]

Just curious: why not "Normal priority" by default? The OS, by default, automatically lowers the priority if the process is background anyway, plus today's CPUs are multicore and not so easily monopolized (muxing is not CPU-intensive).

Another thing that could have been in the news is: "MIME type handling for ttc fonts has been fixed".
Now one can create good MKVs again via GUI with font attachments (both compatible files and new-player-only files). Finally :)

@Perenista
In the new specs, things are more flexible and more than one audio (or subtitle) tracks can be Default=YES. Since it's flexible, we can manually set Default=YES/NO as we like, and (if desired) make it so that only one audio track and only one sub track have Default=YES - that's what I do anyway. For example, suppose you have two tracks with the identical subtitle text, one being more styled & CPU-intensive, the other being less so. You can mark whichever as Default=YES as you like, the other as Default=NO, assuming that the player will auto-select the Default=YES track when the file is played and the other track is manually selectable.

[Mosu]

Just curious: why not "Normal priority" by default? The OS, by default, automatically lowers the priority if the process is background anyway, plus today's CPUs are multicore and not so easily monopolized (muxing is not CPU-intensive).

It was on "normal" by default until v60. The thing here isn't CPU load, it's actually I/O load. The setting actually causes mkvmerge to lower both its CPU and its I/O priority.

The trigger was a report from a user complaining that mkvmerge using 350 MB/s of I/O bandwidth (fast SSDs, multiple mkvmerge processes running in parallel) was bringing their system to a standstill. A lower-than-normal I/O priority is totally appropriate here as it signals to the OS that what mkvmerge does isn't the most important thing (and it really isn't — interactive things such as web browsers, music/video players are always more important).

Sure, I simply could have told them to lower the priority themselves, but I'm a firm believer that in that while configurability is nice to have (and very important to a lot of people), having the default settings be appropriate for most users is even more important.

Another thing that could have been in the news is: "MIME type handling for ttc fonts has been fixed".

Not sure what you're missing. The following entry is present for v60:

* MKVToolNix GUI: multiplexer: when the option "use legacy MIME types for font attachments" is enabled, the GUI will now use `application/x-truetype-font` for font collection files.

[Liisachan]

It was on "normal" by default until v60. The thing here isn't CPU load, it's actually I/O load. The setting actually causes mkvmerge to lower both its CPU and its I/O priority. Ah, I see. That makes sense. And you're right, for some reason I didn't notice that ttc entry in the changelog (though I knew the issue itself had been fixed). Thanks again!

[quietvoid]

When adding multiple tracks with numbered naming like "XX 1", "XX 2", the tracks are automatically appended together with seemingly no way to separate them.
Is there an option to avoid this behaviour?

[Mosu]

Sure, in the preferences → "Multiplexer" → "Detect file name sequences"

[quietvoid]

Cool, thank you.

[markfilipak]

I've been searching for a solution for about 7 hours and have not found Joy.

How do I simply concat VOBs and remux them? The concat works like magic, but the subtitle streams are missing.

Thanks,
Mark.

FFPROBE h:\VIDEO_TS\VTS_04_1.VOB
Stream #0:0[0x1bf]: Data: dvd_nav_packet
Stream #0:1[0x1e0]: Video: mpeg2video (Main)...snip
Stream #0:2[0x20]: Subtitle: dvd_subtitle
Stream #0:3[0x21]: Subtitle: dvd_subtitle
Stream #0:4[0x22]: Subtitle: dvd_subtitle
Stream #0:5[0x23]: Subtitle: dvd_subtitle
Stream #0:6[0x24]: Subtitle: dvd_subtitle
Stream #0:7[0x25]: Subtitle: dvd_subtitle
Stream #0:8[0x26]: Subtitle: dvd_subtitle
Stream #0:9[0x27]: Subtitle: dvd_subtitle
Stream #0:10[0x28]: Subtitle: dvd_subtitle
Stream #0:11[0x29]: Subtitle: dvd_subtitle
Stream #0:12[0x2a]: Subtitle: dvd_subtitle
Stream #0:13[0x2b]: Subtitle: dvd_subtitle
Stream #0:14[0x2c]: Subtitle: dvd_subtitle
Stream #0:15[0x2d]: Subtitle: dvd_subtitle
Stream #0:16[0x80]: Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
Stream #0:17[0x81]: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Stream #0:18[0x82]: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Stream #0:19[0x83]: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Stream #0:20[0x84]: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s

MKVMERGE --output concat.mkv h:\VIDEO_TS\VTS_04_1.VOB

MKVINFO --summary concat.mkv
Track 1: video, codec ID: V_MPEG2, mkvmerge/mkvextract track ID: 0...snip
Track 2: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 1...snip
Track 3: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 2...snip
Track 4: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 3...snip
Track 5: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 4...snip
Track 6: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 5...snip

PS: 'FFMPEG -i "concat:h:\VIDEO_TS\VTS_04_1.VOB|..." -map 0 -codec copy -dn concat.mkv' takes forever or pukes on PTSs or both.

[Mosu]

MKVToolNix doesn't support reading subtitles directly from DVDs. You'll have to extract them with other software such as Subrip or Subtitle Edit. Then feed those extracted files to MKVToolNix.

[markfilipak]

MKVToolNix doesn't support reading subtitles directly from DVDs. You'll have to extract them with other software such as Subrip or Subtitle Edit. Then feed those extracted files to MKVToolNix.

Ah! Thanks, I think what I'll try next is this:
MKVMERGE --output AVTEMP.mkv VTS_xx_x.VOB
FFMPEG -i AVTEMP.mkv -map 0 -i "concat:VTS_xx_1.VOB|VTS_xx_2.VOB.." -map 1:s -codec copy TARGET.mkv
Hopefully, because I'm asking it to only mux the subtitles, FFMPEG will be smart enough to entirely bypass PTS-rounding issues and the infamous "Timestamps are unset in a packet for stream.." warning. But I suspect that FFMPEG is not that smart and I'll be back at square one.

Is there a way to do the muxing entirely in MKVMERGE via '--subtitle-tracks n,m,...' without messing with 'n,m...' at all? In other words, is there a way to tell MKVMERGE to mux in all subtitle tracks without indexing those tracks? Oh, wait, I'll bet that's why you included a special '-1' stream number (i.e. all streams). I'll try to figure out how to use it with '--sync' but exclude the video stream.

What I'm doing (in my notation):
23.9fps[24pps] --> 24fps[24pps] (via forcing PTSs in FFMPEG [note 1]) --> 60fps[60pps] (via vapoursynth.InterFrame [note 2]).
[note 1] Forcing PTSs does 2 things: 1, it corrects the running time so that the result is identical to what's seen in theaters (i.e. 24fps), and 2, it creates absolutely correct CFR PTSs that are montonically increasing and are purely integer (thereby avoiding rounding errors).
[note 2] Motion vector interpolation to 60fps[60pps] eliminates telecine judder on 60Hz TVs. I've already done this and it looks incredible. I'm trying to automate the process.

[Mosu]

mkvmerge muxes everything it understands & supports unless you tell it not to. Options such as "--subtitle-tracks" only ever limit the amount of tracks copied.

The shorted possible command, "mkvmerge -o out.mkv in.ext", copies everything supported from in.ext. No further options needed.

Ideally you'd go the other way around: first, extract subtitles with one of the programs I've mentioned above to either an SRT or to VobSubs (.idx + .sub). Then use mkvmerge to mux the VOBs with those freshly extracted subs, e.g. "mkvmerge -o total.mkv VTS_01_1.VOB extracted_subs.idx"

[markfilipak]

MKVToolNix doesn't support reading subtitles directly from DVDs. You'll have to extract them with other software such as Subrip or Subtitle Edit. Then feed those extracted files to MKVToolNix.

I saw this many months ago but forgot about it:
mkvmerge.html
2.7. Options that can be used for each input file
...Default: copy all subtitle tracks.

'MKVMERGE --output concat.mkv h:\VIDEO_TS\VTS_04_1.VOB' copied zero subtitle tracks.

...because it's a DVD, eh? ...Okay.

[markfilipak]

... e.g. "mkvmerge -o total.mkv VTS_01_1.VOB extracted_subs.idx"
Thanks so much. It's really good to see an entire command instead of bits and pieces of commands.

Will the resulting 'total.mkv' made that way always have the track order: video tracks, then audio tracks, then subtitles? The reason I ask is that such known track order would make my script slightly simpler and faster.

I didn't know I could just list the input files one after another like that. Handly!

Thanks, Mosu.

[Mosu]

I saw this many months ago but forgot about it:
mkvmerge.html
2.7. Options that can be used for each input file
...Default: copy all subtitle tracks.

'MKVMERGE --output concat.mkv h:\VIDEO_TS\VTS_04_1.VOB' copied zero subtitle tracks.

...because it's a DVD, eh? ...Okay.

Because that combination of format & source container simply isn't supported. I don't litter the documentation with caveats ("Only tracks that are actually supported given the combination of track type, codec & source container format and that are valid according to mkvmerge's internal metrics are considered." not once, but everywhere it talks about tracks) everywhere; all it would do is make it tiresome to read & easier to skip over content that's actually important.

Thanks so much. It's really good to see an entire command instead of bits and pieces of commands.

The man page's "Examples" section contains full commands as well.

Will the resulting 'total.mkv' made that way always have the track order: video tracks, then audio tracks, then subtitles?

No. The tracks will be in the order they're found in the file. Which order that is depends on the source container format & the actual content. For example, in AVIs the order is indeed video/audio/subtitles. In MP4, Matroska or MPEG transport streams, on the other hand, the order can be arbitrary. MP4 is among those that often has an audio track before a video track.

The order of the tracks created is the same order they're output in the identification mode (both JSON & plain modes).

The GUI has options for always sorting video/audio/subtitles, but the CLI app doesn't (intentionally so).

I didn't know I could just list the input files one after another like that. Handly!

You can always take a look at the command line the GUI generates for a given set of files & settings via "Multiplexer" → "Show command line". Note that the generated command line isn't guaranteed to be the shorted possible; the GUI sometimes includes redundant stuff (especially around track selection, e.g. adding "--subtitle-tracks 3,4" even if the source file contains exactly two subtitle tracks and therefore "--subtitle-tracks 3,4" could simply be left out and it'd have the same effect on muxing) because implementing a check if that option is actually needed takes more code, and more code requires more time for testing & leads to more chances for bugs.

[markfilipak]

[regarding subtitles from DVDs] Because that combination of format & source container simply isn't supported. I don't litter the documentation ...
That's totally understandable. I didn't mean to imply it wasn't. May I suggest a "Limitations" section in the html docs summarizing all such limitations in one place? I'll help write it if you like.
The man page's "Examples" section contains full commands as well.
Indeed. It's but one thing that makes your work outstanding. ;)
[regarding track order] No. The tracks will be in the order they're found in the file.
How about when there are multiple files? For example: 'MKVMERGE --output AV.mkv AVsource.mkv subs.mkv'. Would the subs always be the higher indexed tracks?
The GUI has options for always sorting video/audio/subtitles, but the CLI app doesn't (intentionally so).
Understood. That makes scripting a bit more complicated, but so be it.
You can always take a look at the command line the GUI generates for a given set of files & settings via "Multiplexer" → "Show command line".
Oh! That's very welcome. I wish every codesmith did that. Thanks!:cool::helpful:

[Mosu]

I'm sorry. I meant the track order when there are multiple files. For example: 'MKVMERGE --output AV.mkv AVsource.mkv subs.mkv'. Would the subs always be the higher indexed tracks?

The tracks are created in the order they are detected by mkvmerge. As files are processed left to right, this means that all tracks from AVsource.mkv would be created before the tracks from subs.mkv. There is no inter-file sorting going on here. Therefore where subtitle tracks end up depends on what the actual tracks in the files are. I'm guessing you're inferring that AVsource.mkv does not contain any subtitle track and subs.mkv contains nothing but subtitle tracks. In that case yes, the subtitle tracks would have the highest indexes.

However, if AVsource.mkv contains two subtitle tracks, a video track, an audio track and another subtitle track in that order, then it really doesn't matter what subs.mkv contains as the tracks in the output file would also be subtitle1, subtitle2, audio, subtitle3 and then whatever is in subs.mkv.

So in general you cannot make any assumption about track order based on track types.

The algorithm is completely deterministic, though. In pseudo code:

all_tracks = []

for file_name in file_names_in_command_line:
all_tracks.append(identify_tracks_in_file(file_name))

for track in all_tracks:
create_track_in_output_file(track)

No sorting, no grouping.

[markfilipak]

...
You are extraordinary.

[darksen]

One question, why with Microsoft Audio Codec Manager MKVToolNix shows it's codec ID 'A_MS/ACM' in the 'Codec' column when for codecs like 'AC-3' or 'DTS-HD MA' it shows the format or commercial name? In MediaInfo I see 'PCM' as the format for 'A_MS/ACM', is MediaInfo wrong here thus why MKVToolNix doesn't show 'PCM'?

Thanks.

[Mosu]

For most codecs there's a native way to store them inside Matroska. For those codec-specific identifiers (= CodecIDs) will be used, e.g. A_OPUS, V_AV1 or S_VOBSUB. All modern codecs (but also a lot of the old ones) have such a native way of storage and hence their own CodecID.

However, there's also a way to store audio or video (but not subtitle) data in Matroska in a way that simply borrows how data is stored in the venerable AVI and WAV containers. For those modes the generic CodecIDs V_MS/VFW/FOURCC (for video) or A_MS/ACM (for audio) are used. In these compatibility modes a certain part of the AVI/WAV container structure is simply stored in Matroska's CodecPrivate structure. Inside that data there is an identifier (for video a so-called FourCC = four characters code = four bytes whose ASCII representation is often times readable, e.g. "MPG2"; for audio a two-byte field with many well-known values) that tells the application what the actual codec is. The most well-known example of a codec that was pretty much only stored in that compatibility mode was MPEG-4 part 2, or as it is better known colloquially: DivX (or sometimes XviD).

This compatibility mode was introduced right at the start of Matroska's lifetime in order to ease adoption, and that kind of worked. Nowadays (as in… pretty much for at least the last ten years or so) there really isn't a good reason to use the compatibility mode. Sure, software developers might just be too lazy to implement native handling of the codecs & just use the compatibility mode.

MKVToolNix supports those compatibility modes and tries to convert them to native mode where possible (if not possible, the tracks will be copied as-is, meaning the output track will also use the compatibility mode).

The GUI itself simply lists a track's CodecID. It doesn't look deeper into that CodedPrivate structure for those other fields.

And the thing with PCM is: there are tons of different types of PCM, unfortunately, with a lot of different two-byte identifier values.

[darksen]

@Mosu Thanks for the detailed reply.

[Nejiro]

Hi everyone, I wanted to ask something about the dolby vision, I have several mkv files in which there are two video tracks, from the information with mediainfo one is HDR10 3840x2160 and the other 1920x1080 Dolby Vision, in this way, however, my player does not detects the dolby vision but only the HDR10, I wanted to know if with MkvToolNix there is the possibility of obtaining a single video track in which there is both the DV and the HDR10 to make my player reproduce the Dolby Vision files.
Thanks

[Mosu]

Hi everyone, I wanted to ask something about the dolby vision, I have several mkv files in which there are two video tracks, from the information with mediainfo one is HDR10 3840x2160 and the other 1920x1080 Dolby Vision, in this way, however, my player does not detects the dolby vision but only the HDR10

Dolby Vision can come in several forms: single-layer, dual-layer in a single track and dual-layer in two separate tracks. What you describe is the last case. At the moment MKVToolNix doesn't support such files. Maybe remuxing them & keeping the two tracks as they are works, I actually don't know — haven't tried it yet.

Support for those files is on my TODO list.

The support status and plans are summarized in this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status). It also links to the corresponding issues in my issue tracker.

As for other tools that might help: at the moment I only know about a pretty new project called dovi tool (https://github.com/quietvoid/dovi_tool), though it doesn't seem to support the dual-layer-in-separate tracks/files case yet. Again, haven't looked into it, but definitely a project worth watching and potentially adding to your Dolby Vision toolbox.

All that being said, other people here have much more experience with & knowledge Dolby Vision & the tooling around it. While I can answer your original question about MKVToolNix in particular, you should wait for others to chime in with solutions outside of MKVToolNix.

[quietvoid]

The simplest way is to use MakeMKV and remux the dual track file.
When doing so, it logs:
Hack: Found secondary video stream with RPU, assuming DV EL
Hack: Attaching DV data from second video track to first one and discarding second video track

And the output file is a single track.

However this doesn't guarantee the file will work on your devices, as only a few Android set top boxes support profile 7 dual layer in the MKV container :)

[SeeMoreDigital]

@Nejiro,

Out of interest... What's the make/model of your playback device?

[Nejiro]

It's a Zidoo Z9X...... https://www.zidoo.tv/Product/index/model/Z9X/target/VEMg6VRC2%2B9KKmVViAFMcQ%3D%3D.html

I am using MakeMKV as it was suggested to me and it works perfectly, the files are read by my player and played in dolby vision, I very much hope that this function is also implemented in MkvToolNix ...
Thank you

[SeeMoreDigital]

It's a Zidoo Z9X...... https://www.zidoo.tv/Product/index/model/Z9X/target/VEMg6VRC2%2B9KKmVViAFMcQ%3D%3D.html
Maybe some other Zidoo Z9X owner/users can help you, over on their dedicated help forums: http://forum.zidoo.tv/index.php

[Mosu]

Hi everyone, I wanted to ask something about the dolby vision, I have several mkv files in which there are two video tracks

While we're on the topic, can you please upload one or two of those files to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server)? I actually don't have sample Matroska files with dual-layer-in-two-tracks to work with for when I get around to implementing support for it.

Thanks!

[SeeMoreDigital]

While we're on the topic, can you please upload one or two of those files to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server)? I actually don't have sample Matroska files with dual-layer-in-two-tracks to work with for when I get around to implementing support for it.

Thanks!I'm sure I uploaded some .m2ts file samples (from Dolby Vision UHD discs) to your server a few weeks ago. Which MKVToolNix can mux just fine...

[Mosu]

I know. That's why I emphasized the "Matroska" part in my answer. I assume those were created by some other piece of software, and I want to be able to test as many potential sources as I can. I'm grateful for having the M2TS files, too, for the same reason.

[SeeMoreDigital]

I assume those were created by some other piece of software, and I want to be able to test as many potential sources as I can...
Good point... I wonder how many Matroska muxing software's are still out there.

Since the release of MakeMKV v1.15.3/4 its Matroska muxer automatically converts 2-track dual-layer Dolby Vision into single-track dual-layer .mkv contained encodes. I don't think they offer an option to keep both tracks now.

Cheers

[Nejiro]

With MakeMKV just load the mkv (which I had done with mkvtoolnix) which contains the two video tracks and automatically recognizes the DV, then I save and create a single video track which is recognized as dolby vision by my zidoo ..... . in case you have a player that is not compatible with dolby vision, it is reproduced as HDR ........
Is there hope that even with MkvToolNix you can do the same, that is create dolby vision compatible mkvs? I much prefer MkvToolNix to MakeMKV ....... I use MkvToolNix on Ubuntu 20.04 LTS
Thanks

[SeeMoreDigital]

Is there hope that even with MkvToolNix you can do the same, that is create dolby vision compatible mkvs? I much prefer MkvToolNix to MakeMKV ....... I use MkvToolNix on Ubuntu 20.04 LTS
ThanksBut surely you're using MakeMKV to create your Matroska 4K UHD back-ups in the first place!

[Mosu]

Is there hope that even with MkvToolNix you can do the same

There definitely is. That's why I asked you to upload (https://forum.doom9.org/showthread.php?p=1950215#post1950215) one or two of those MKVs with DV in two tracks to my file server earlier — so that I have more material to develop & test with.

[quietvoid]

I've uploaded a sample named "spears_and_munsil_drlow_dolby_vision_p7.mkv", which is dual layer profile 7.

Sourced from https://www.avsforum.com/threads/spears-munsil-uhd-hdr-benchmark-disc-discussion.3075780/page-43#post-59634582
Remuxed from mp4 with mkvmerge, then MakeMKV.

[Nejiro]

I don't know how to do it, they are very large files and my line only has 20mb at the output ...

[Nejiro]

Well, I see that someone sent it to you .....

[Mosu]

quietvoid: thanks, but that file only contains a single track. Those are supported just fine. What I need is a file with dual-layer Dolby Vision where each layer is stored in its own track.

Nejiro: I actually linked to the wrong post. Here's the link to the FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server) again. It contains an explanation that includes links to the software to use & screenshots how to configure them. It's really easy. Yes, they're huge, but that is no problem for me: just let the upload run as long as it takes, e.g. overnight. It would really help. Thanks.

[quietvoid]

Oh I thought you wanted dual layer (both single & dual track).
I guess the mp4 from Stacey Spears can just be remuxed to MKV as a source..

[ctl-tx]

I've run into a problem while cutting and joining mkvs with dolby trueHD audio tracks. I wanted to cut a video into 4 parts, then join the second and fourth parts together. But when I put the second part into the muxer, it couldn't see the TrueHD audio tracks, and the output had no audio tracks either. I put the segment (that the muxer couldn't see the audio tracks of) into the header editor, and that one could see the audio tracks just fine.

I thought it may have been because I threw out the AC-3 core of the TrueHD audio, so I went back to the raw video file, muxed it with the AC-3 tracks, then cut it again. This time, only the first of the two TrueHD tracks disappeared in the muxer.

I've got no idea how to get around this, so I'm posting here for help.

This is actually the second time I've encountered this problem. The first a few years ago. I can't remember exactly how I got through that time, only that it involved putting several unrelated mkvs together, and somehow the missing TrueHD track just reappeared. That's not an option this time.

Update: I changed the points in the video where I cut it and the TrueHD audio tracks in the segments now appear in the muxer. While this does solve my immediate problem, I needed to change the cut points anyway, I still hope the issue is looked into, the audio track shouldn't be unrecognized simply because it was cut at a different point.

[Mosu]

TrueHD is one of the very few audio codecs and the only modern one that I know of that uses two different frame types: major sync frames & normal ones. Decoding can only start from major sync frames. This is similar to video frames with key vs. non-key frames (or IDR vs. non-IDR frames).

Due to how mkvmerge works, it can only ever write to one file at the time. Splitting always uses the first video track in the output file to determine where to split. As soon as the split point is found, the current output file is closed & a new one is started.

For TrueHD this often means that splitting will occur before a regular TrueHD frame, not a major sync one, meaning that playing the second part a decoder cannot start decoding audio before the first major sync frame is found.

Splitting with more than one video track where both tracks have key frames in different positions exposes the same fundamental problem.

Handling situations such as these (different tracks with different restrictions where to splitting is allowed) differently, e.g. writing all remaining regular TrueHD frames to the previous output file, would require major rewrites of one of the most intricate parts of the applications. I do not have any plans to spend any time on this issue. It's a known limitation of mkvmerge not being a full-blown video editor.

Sorry.

[ctl-tx]

So, I suppose the only workaround is to change the cut points if this is encountered again. I'll just have to deal with that.

Could the two frame types be responsible for audio drops if you join two TrueHD tracks together? I saw that on my TrueHD joins, but I did those joins for ordered chapters and padded the join points in case of anomalies, such as these. They're just much more significant than I expected.

Edit: Wait, nevermind not being able to split and join due to different frame types. The muxer can't even see there's a track if it doesn't start on a major sync frame? Is it that hard to detect that the track starts with a non-normal frame and still show it on the muxer?

[Mosu]

mkvmerge probes the first few packets of a TrueHD track in order to determine its actual codec properties. If no major sync header is found within those first couple of packets, the track is considered to be bad. The number of packets probed (5) is indeed rather low, given that TrueHD uses a high number of very small frames (in one of my test files there are 120 frames between major sync frames). I'll increase that number considerably which should help with your situation.

[Mosu]

Hmm, at the moment I cannot reproduce the problem with mkvmerge not showing a split TrueHD track. Can you upload such a series of split files to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server), please? Thanks.

[ctl-tx]

Hmm, at the moment I cannot reproduce the problem with mkvmerge not showing a split TrueHD track. Can you upload such a series of split files to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server), please? Thanks.

The files have been uploaded. It's in the folder "from ctl-tx" These are the files I was working on when I posted. You can play the files and verify that they have audio. The audio tracks do not show up when you drop them in the muxer.

What about using what the Header Editor uses to identify tracks? As I said, these audio tracks did appear in it.

[Mosu]

Greetings, gentle fellow humans!

Oh wow, time is moving very strangely for me during this pandemic, sometimes slowing to a crawl, sometimes just going by very quickly. It's been four weeks since the last release already; so let's get the August one out just in time: v61.

This release is on the smaller side. Couple of improvements to the IETF BCP 47 language tag handling, couple other things. Nothing earth shattering, though.

For package maintainers there was a small change. See the NEWS below.

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 61.0.0 "So" 2021-08-30
New features and enhancements

all: IETF BCP 47/RFC 5646 language tags: implemented support for officially registered IANA language tag extensions.
mkvmerge: track selection: when using language tags for selecting which tracks to keep, mkvmerge will now use component-based language tag matching instead of comparing them verbatim. This means that only those components (language, region etc.) the user specified will be required to exist and be equal. For example, if a file contains three subtitle tracks with languages "es" (generic Spanish), "es-MX" (Spanish as spoken in Mexico) and "es-ES" (Spanish as spoken in Spain), the user can use "--stracks es" to match all three tracks or be more specific with e.g. "--stracks es-MX" which would only match one track. Similarly inverting the selection with e.g. "--stracks !es" would get rid of all three tracks, not just the one for the generic Spanish.
MKVToolNix GUI: multiplexer: deriving track languages from file names: the GUI can now detect full BCP 47/RFC 5646 language tags in file names. Part of the implementation of #3173 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3173).
MKVToolNix GUI: multiplexer: deriving track languages from file names: the default list of boundary characters now includes "-". Part of the implementation of #3173 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3173).
MKVToolNix GUI: multiplexer: the GUI now defaults to the "lower" process priority setting for new installations in order to leave more room for other applications, especially interactive ones. Up to and including v59 the default was the "normal" process priority. v60 changed that to "lowest", which turned out to be much slower on Windows for no real gain over "lower". The setting will be auto-corrected by the GUI if the settings file were saved last with a version between v60.0.0.0 & v60.0.0.17 & "lowest" & it is still set to "lowest".
HEVC dumper development tool: the tool has been renamed to "xvc_dump" and extended to be able to dump AVC/H.264 bitstreams, too. It now also detects the type of bitstream framing (ISO 14496-15 vs. ITU-T H.264/H.265 Annex B).

Bug fixes

all: IETF BCP 47/RFC 5646 language tags: fixed a corner case of wrongfully allowing scripts/variants not listed in any of the entries in the prefix list when the prefix list contains prefixes restricting scripts/variants and a prefix solely with the language at the same time (example: the variant "ekavsk" with its prefixes "sr", "sr-Cyrl" and "sr-Latn" where e.g. "sr-ekavsk" and "sr-Cyrl-ekavsk" should be allowed but not "sr-Bali-ekavsk").
mkvmerge: HEVC/H.265: the frame type of B frames was often wrongfully signalled as P frames instead, both with "BlockGroup" (missing second references) and "SimpleBlock" ("discardable" flag not set) elements.
mkvmerge: SSA/ASS packetizer: the frame numbers will now be re-calculated when appending SSA/ASS tracks so that frame numbers of appended tracks are always strictly higher than frame numbers of the track they're appended to.
mkvmerge, MKVToolNix GUI's chapter editor: BCP 47/RFC 5646 language tags: when BCP 47 language tags are used with a language code that isn't part of ISO 639-2, the programs will now write a legacy language element set to "und" ("undetermined") instead of not writing such an element at all or writing one with an invalid code. Fixes #3174 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3174).
mkvmerge, MKVToolNix GUI's chapter editor: BCP 47/RFC 5646 language tags: the programs will ensure that the legacy and IETF language elements written will be unique within the scope of the same "chapter display" element.
mkvinfo, MKVToolNix GUI's info tool: in summary mode the frame type was reported wrong for "BlockGroup" elements in which the "ReferenceBlock" elements were located behind the "Block" element.

Build system changes

all: "std::codecvt_utf8" is now used instead of Boost's "utf8_codecvt_facet". The bundled copy the latter in "lib/boost" has therefore been removed.


Have fun 😁

[VBB]

Thank you!

[Mosu]

The files have been uploaded. It's in the folder "from ctl-tx" These are the files I was working on when I posted.

Thanks. I actually fixed this a couple of days ago but forgot to post about it. You can try the latest continuous builds (https://mkvtoolnix.download/windows/continuous/).

[Selur]

Thanks. :)

[Etroxamin]

Hey, I need to to change video FPS (23.976 to 24), that's not a problem, but I saw a new flag for the "original framerate" appeared in MediaInfo.

I was wondering if that could cause problems for certain players/playback devices and found some posts that it actually can happen and the option "Fix bitstream timing info" can fix that. I read a bit more and saw "Fix bitstream timing info" was described as destructive option.

Now i am confused whats the best way to handle such a video framerate conversation.

The Film has been produced in 24 FPS, so discarding the original framerate information may not be "destructive" at all. However, when i check the "Fix bitstream timing info" MediaInfo still shows me the original framerate.

Is it possible to discard the original framerate information completely?
Are there any drawbacks using "Fix bitstream timing info"?

And maybe my understanding of frame timestamps isn't good enough, thought a framerate eg. 24 or 25 fps would be enough for a player to know how fast frames should be played. So, when I use "Fix bitstream timing info" and change the FPS back to 23.976 as it was originally, and use "Fix bitstream timing info" again, will the timestamps actually change to the orignal (100% accurate) or would these change to a slightly other value?

The video plays fine btw, no matter if i use "Fix bitstream timing info" or not, but before i do something "destructive" or end up with video wrongly interpreted by certain playback devices, it might be good to ask.

[Mosu]

However, when i check the "Fix bitstream timing info" MediaInfo still shows me the original framerate.

That option is only implemented for AVC/H.264, not for any other codec.

Is it possible to discard the original framerate information completely?

Speaking strictly from the AVC/HEVC specs POV: yes, as those sequence parameter set fields are optional. MKVToolNix doesn't contain functionality for that, though: either it leaves the SPS untouched (meaning the info might be present or not), or it forces the information to be present and what the user specified.

Are there any drawbacks using "Fix bitstream timing info"?

If you use wrong values, playback won't work as expected. Otherwise… not really, no.

So, when I use "Fix bitstream timing info" and change the FPS back to 23.976 as it was originally, and use "Fix bitstream timing info" again, will the timestamps actually change to the orignal (100% accurate) or would these change to a slightly other value?

That actually depends. First of all, what's stored in the SPS is not a floating point number but a pair of 32-bit unsigned integers which denominate the "number of frames per ticks" and "number of tickets per second", which, when divided, yields the number of fields-or-frames (depends…) per second. For several well-known & often used frame rates such as 23.976, mkvmerge will store the representation that is commonly used for that frame rate: 24000/1001. No, this isn't exactly 23.976, but that 23.976 number is actually a lie: movies were shot in 24000/1001 FPS, not in exactly 23.976, but us humans use the easy to remember number of 23.976 instead of… well anything, really. 24000/1001 is an irrational number, and you simply cannot express it exactly without reverting to a rational such as 24000/1001. So what MediaInfo reports as 23.976 is most likely stored as 24000/1001, even though that's not the same number.

Sooo… confused yet?

In pretty much all cases 24000/1001 are the numbers video files use when they contain "23.976 FPS" material. That being said, your original file just might contain some other similar but not quite the same value, e.g. 4294944000/179134957, and MediaInfo might round that to that well-known FPS of 23.976, too. Who knows? In this case the value mkvmerge would write would not actually be the value that was present in the file originally. And as we've just learned, that original value wouldn't be exactly 23.976 either.

That's the complex but somewhat accurate answer. The pragmatic answer is a short "sure, that works".

The video plays fine btw, no matter if i use "Fix bitstream timing info" or not

So why try to fix something that doesn't need fixing?

[Etroxamin]

"Fix bitstream timing info"

That option is only implemented for AVC/H.264, not for any other codec.


Ok, the video I use is HEVC, so turning this on doesn't change anything, I guess?


"Is it possible to discard the original framerate information completely?"

Speaking strictly from the AVC/HEVC specs POV: yes, as those sequence parameter set fields are optional. MKVToolNix doesn't contain functionality for that, though: either it leaves the SPS untouched (meaning the info might be present or not), or it forces the information to be present and what the user specified.


Well, is there a chance to see this option working for HEVC in the future, eventually? Btw, if it only works for AVC, it might be an idea to add the information (or else it can be confusing), i just googled a bit more, and someone in another forum had the problem that his muxed videos also had the "original framerate" information, he muxed a PAL DVD to play it at 23.976 frames and it caused problems for a playback device, while it was working on another device, another user suggested to use the "Fix bitstream timing info" but if it only works for AVC, then it makes not much sense of course.

And if MKVToolNix doesn't contain a functionality for removing the original framerate flag, while it can lead to complication with some devices, maybe it would be an idea to be able to force removing this information when FPS change is set. This information seems not of much use for a finished remux... (or not?) but can cause playback errors. It should be optional of course.


"Are there any drawbacks using "Fix bitstream timing info"?"

If you use wrong values, playback won't work as expected. Otherwise… not really, no.


Well, its just a switch to activate (no value to add), so you mean wrong values for the fps bar above? wouldn't a wrong value lead to plaback issues anyway, no matter if i tun the switch on?

Well, maybe the stored "original framerate" could be used to restore something if the original video isn't available anymore.




... so far the double framerate change, i thought something like that. But thanks a lot for that explanation or confirmation. Not that it is really important, I keep the source anyway, so won't ever need to do that, i was just curious :)


"The video plays fine btw, no matter if i use "Fix bitstream timing info" or not"

So why try to fix something that doesn't need fixing?


Well, as said above already, it can have playback issues with certain devices, which will use the "original framerate" instead the one correct one.

It would be great to have the "Fix bitstream timing info" switch for other videos than AVC of course, unless its causing problems of course, but well ...

Anyway, thanks a lot for your answer, at least I know that this switch doesn't work for my current "project". But as said its all fine, at least on PC, still - i'd like to find a way to remove the orignal framerate flag, but guess i then would need to find a way to "Fix bitstream timing info" as well, might be complicated and maybe not the right place to ask for here, but maybe it would be an idea to extend that function to other video types, may improve MKVToolNix and could help in certain situations.

And thanks a lot for MKVToolNix as a whole project btw, great piece of work.

[SeeMoreDigital]

... he muxed a PAL DVD to play it at 23.976 frames and it caused problems for a playback device...
720x576 PAL (and 720x480 NTSC) DVD's are all encoded using MPEG-2 video.

[Etroxamin]

720x576 PAL (and 720x480 NTSC) DVD's are all encoded using MPEG-2 video.

Yes, actually i just put this example on, as mpeg2 wont be effected by the "Fix bitstream timing info" as well. To visualize that without information that this switch is limited to AVC, it can be confusing in such cases.

However someone linked me to an example for ffmpeg:

ffmpeg -i input.mkv -c copy -bsf:v hevc_metadata=tick_rate=25:num_ticks_poc_diff_one=1 output.mkv

well in my case i need to do 24 of course, but seems to work. Even if i find these ffmpeg commands a bit confusing as well, at least for me, cause i never used ffmpeg before...

[von Suppé]

ffmpeg -i input.mkv -c copy -bsf:v hevc_metadata=tick_rate=25:num_ticks_poc_diff_one=1 output.mkv

A batchfile with that code for changing hevc framerate has been in my toolbox since the day I found out about it. Haven't still ran into a GUI with that option.

[markfilipak]

@Mosu, thank you for the update to an outstanding utility. May I cheerfully make some suggestions?

From VirusTotal analysis of mkvtoolnix-64-bit-61.0.0-setup.exe:
Detects "cmd" utilization to self-delete files in some critical Windows destinations.
SOC Prime Threat Detection Marketplace (https://sigma.socprime.com/#!/) - Ariel Millahuel
Context for the matching events
$CommandLine: 'C:\Windows\System32\cmd.exe /c C:\Windows\System32\ipconfig.exe /flushdns >C:\Windows\TEMP\ipconfig.out 2>&1'
$CommandLine: 'C:\Windows\System32\cmd.exe /c C:\Windows\System32\netsh.exe interface ip delete arpcache >C:\Windows\TEMP\ipconfig.out 2>&1'
$CommandLine: 'C:\Windows\system32\cmd.exe /c C:\Windows\system32\powercfg.exe /getactivescheme > C:\Windows\TEMP\PowerPlan.log'
$CommandLine: 'C:\Windows\system32\cmd.exe /c C:\Windows\system32\powercfg.exe /query 381b4222-f694-41f0-9685-ff5bb260df2e > C:\Windows\TEMP\HighPerformancePlan.log'

Regarding lines 1&2: What is mkvtoolnix-64-bit-61.0.0-setup.exe doing with the Internet? Whatever it is, don't do it. In my case, there's a practical reason: Windows is not connected to the Internet. I connect to the Internet solely through a Linux VM.
Regarding lines 3&4: Don't mess with the power scheme. Suggest settings but don't make them.

[Mosu]

MKVToolNix itself does not contain any of those actions it its source code. If you doubt that, get the source code (https://gitlab.com/mbunkus/mkvtoolnix/-/tree/main) and have a look for yourself.

My primary candidates are the NSIS installer & the Qt libraries, though neither the source of NSIS (https://sourceforge.net/projects/nsis/files/NSIS%202/2.46/nsis-2.46-src.tar.bz2/download) nor of Qt (https://github.com/qt/qtbase/tree/5.15.2) contains any mention of "powercfg.exe", "netsh.exe" or "ipconfig.exe".

I don't know where those calls come from. They certainly aren't done intentionally by myself. MKVToolNix only accesses the internet when the GUI's check for updates is run (automatically at most once a day, or if you select "Help" → "Check for updates" manually), and nothing at all is done with power configuration.

As a matter of fact, I decided to check on VirusTotal myself, first downloading mkvtoolnix-64-bit-61.0.0-setup.exe from the official download site, FossHub.com (https://www.fosshub.com/MKVToolNix.html), and then uploading it to VirusTotal. The result (https://www.virustotal.com/gui/file/f2ccd10c67f07369e13d9a75ab3a0b4f693d48f67f99a2224fa7c515186e7d2f) shows none of what you copy-pasted.

Looks like the problem is actually on your end.

You should compare the checksum of the exe with the official ones listed here (https://mkvtoolnix.download/downloads.html#windows).

[von Suppé]

Hi Mosu,

I'm still in the learning process about Dolby Vision. During which' use within both mkv and BD-ISO, I read this: https://github.com/justdan96/tsMuxer/issues/450#

As for remuxing a MakeMKV-created DV with your tool, I'm wondering what the deal is with adding these "Access Unit Delimiters" (which I understand are the first part of a specified form of NAL unit).
If I understand that thread correctly, MakeMKV would simply "forget" this and because of that, DoVi would not be triggered on a TV when remuxed as TS.

My question: Purely for the sake of a proper mkv with DoVi (not TS or BD), could the absence of these "AUDs" in a mkv pose any problem? And - as I'm a noob with this, this may sound stupid - if so, are/can these be (properly) rewritten by mkvtoolnix during a remux?
I hope you don't mind me asking.

[Mosu]

As far as I know access unit delimiters are purely optional, at least when stored in a container format that knows how to keep all NALUs that "belong" to a single frame in the same container-level block structure. Matroska is such a container, MP4 is one as well. In fact, mkvmerge discards AUDs during muxing and has always done so, not just for HEVC, but also for AVC.

MPEG transport streams on the other hand do not have such a notion of a block structure that contains several NALUs and which could therefore signal the start of a sequence of NALUs "belonging" to the same frame.

That being said, I don't understand why AUDs are necessary for DV playback even with MPEG transport streams. The HEVC specs are very clear on the order of NALUs, and from that order you can easily derive which slice NALUs certain DV NALUs belong to: the DV NALUs always follow the slice NALUs.

I'm completely confused by jcdr428 casually stating:

MakeMKV simply forgets to add the Access Unit Delimiters -which yusesope tool does correctly.

as if they were required for playback, especially for playback when inside Matroska or MP4. That doesn't compute.

If the standards do require them somehow somewhere, I'd be really interested in the details, whether I actually have to create them, and if so, under which circumstances.

[videoh]

Small, possibly irrelevant point about AUDs...

When developing DGDecNV I ran into an issue decoding AVC elementary streams:

We are starting to see streams that have successive IDR pictures with the same idr_pic_id (so far always = 0). This has been seen on commercial blurays. It can also be created by accident when concatenating streams, if the first ends with an IDR. As far as I can tell, CUVID silently discards the "extra" IDRs. I realize it's an illegal condition but I am wondering if it can be mitigated in CUVID, i.e., just accept the extra ones and bump the idr_pic_id internally to pretend the stream did it right. Your thoughts on this would be appreciated.

nVidia responded that it was a CUVID parser deficiency that may or may not be fixed and that a workaround is to inject an AUD before the new picture. So that is what DGDecNV does.

#ifdef IDR_PIC_ID_WORKAROUND
if (SystemStream_Flag == ELEMENTARY_STREAM && VideoStream_Flag == AVC)
{
// Workaround for successive IDRs with same idr_pic_id.
if (buf[2] == 1)
offset = 3;
else
offset = 4;

if ((buf[offset] & 0x1f) == 5 && (buf[offset+1] & 0x80))
{
aud[0] = aud[1] = 0;
aud[2] = 1;
aud[3] = 9;
aud[4] = 0xff;
decoder_decode_nalu(aud, 5, false);
}
}
#endif

So there is at least one case where it is beneficial not to strip AUDs. I leave it to you to judge the (ir)relevance of this.

AUDs are required by spec for transport streams.

If you strip the AUDs in MKV, then it will not be possible to later demux the AVC and place it in a transport stream.

Further data on transport streams (note the first bullet item):

Quoted from ISO/IEC 13818-1/2000/FDAM-3 (N5771):
"2.14 Carriage of ITU-T Rec. H.264 | ISO/IEC 14496-10 Video
The ITU-T Rec. H.264 | ISO/IEC 14496-10 coded data shall comply with the byte stream format defined in Annex B of ITU-T Rec. H.264 | ISO/IEC 14496-10, with the following constraints:
* Each AVC access unit shall contain an access_unit_delimiter NAL Unit.
* Each byte stream NAL Unit containing the access unit delimiter contains one zero_byte preceding the start_code_prefix_one_3bytes, as required by ITU-T Rec. H.264 | ISO/IEC 14496-10.
* Sequence and Picture Parameter Sets (SPS and PPS) shall be present within each AVC video stream carried in Transport and Program streams (Note that ITU-T Rec. H.264 | ISO/IEC 14496-10 allows the delivery of SPS and PPS by external means).
* To provide display specific information such as aspect_ratio, it is strongly recommended that the each AVC video stream carries VUI messages with sufficient information to ensure that the decoded AVC video stream can be displayed correctly by receivers."

[Mosu]

Thanks for the info.

I disagree with one thing you said, though:

If you strip the AUDs in MKV, then it will not be possible to later demux the AVC and place it in a transport stream.

Not necessarily. The application extracting from Matroska would be able to re-insert AUDs in such situations. mkvextract doesn't, at the moment.

I could disable the AUD removal, of course (though it isn't a trivial one-line change but rather more involved due to the parameter set normalization mkvmerge does). It would keep improve the situation a bit, for sure, but you can still end up with bad situations when splitting & appending, e.g. situations such as the one in my issue 2990 (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2990#note_535215149).

Also, if NVidia's decoder is able to insert AUDs as needed on the fly, any other program should be able to as well?

[videoh]

Not necessarily. The application extracting from Matroska would be able to re-insert AUDs in such situations. mkvextract doesn't, at the moment. Well sure, but the current status is that if you use mkvextract then there can be a problem.

Also, if NVidia's decoder is able to insert AUDs as needed on the fly, any other program should be able to as well? It's not the decoder, it's my app that feeds the decoder that inserts extra AUDs. But you are correct, any other app could do that. I don't know if others are aware of this workaround.

[Mosu]

What I find interesting is that ffmpeg's libavcodec doesn't seem to do anything with AUDs during decoding, if I read libavcodec/hevcdec.c correctly (function "decode_nal_unit", no other relevant mentions of HEVC_NAL_AUD); same for AVC.

Anyway, I think I'll change mkv* to keep AUDs for all MPEG …VC types.

[nevcairiel]

What I find interesting is that ffmpeg's libavcodec doesn't seem to do anything with AUDs during decoding, if I read libavcodec/hevcdec.c correctly (function "decode_nal_unit", no other relevant mentions of HEVC_NAL_AUD); same for AVC.

AUDs contain no data, they are merely a marker to help raw formats or "simple" containers to indicate frame starts. A decoder doesn't need them if it properly reads every other NAL anyway.

[videoh]

A decoder doesn't need them if it properly reads every other NAL anyway. I showed a case where that is not true.

[videoh]

I think I'll change mkv* to keep AUDs IMHO that is a great decision. Containers should not destroy any elementary stream data.

[nevcairiel]

I showed a case where that is not true.

There was a classification in that sentence for a reason - "if it properly reads every other NAL", clearly this is not true for NVIDIAs parser. But the post was about libavcodec, and why it doesn't use them at all.

[Mosu]

AUDs contain no data, they are merely a marker to help raw formats or "simple" containers to indicate frame starts. A decoder doesn't need them if it properly reads every other NAL anyway.

That has been my understanding as well, thanks for confirming it. I was really taken aback by the tsMuxer Github issue von Suppé linked to where the tsMuxer dev said that it was MakeMKV's fault that tsMuxer couldn't convert the stream into MPEG TS properly because MakeMKV didn't insert AUDs. Well, if AUDs aren't required for decoding, Matroska has no requirements for them but MPEG TS does, then it's simply not the responsibility of _Matroska_ muxers to insert AUDs. If anything it's tsMuxer's.

[nevcairiel]

Indeed. Preserving them is fine and good, they are only like 2 bytes + length code or something per frame, but you might as well have a MP4 as a source (which tolerates them but doesn't mandate them), or another MKV that has no AUDs, so there will still be many streams from the past and in the future that don't have them. Any software that requires them should make sure they are there itself.

[bruno321]

Is there a way to set the Matrix coefficients in mkvtoolnix? E.g. I have an mp4 that has not specified what they are, I want to remux it and set them to BT.709. Can I do that with mkvtoolnix?

[Mosu]

Yes, you can. mkvmerge has a track-specific parameter called "--colour-matrix-coefficients" for that. In the GUI it isn't directly exposed as an input field, but you can use the "additional options" input instead. Select the video track, scroll the "Properties" pane all the way down & enter the following verbatim in "Additional options":

--colour-matrix-coefficients <TID>:1

The GUI will automatically replace the "<TID>" part with the track's actual ID.

The value 1 corresponds to ITU-R BT.709. See the Matroska specs (https://www.matroska.org/technical/elements.html) for all possible values.

An alternative is to use the header editor. You'll find the field here: Video track … → Colour information → Video: color matrix coefficients.

[Liisachan]

24000/1001 is an irrational number, and you simply cannot express it exactly without reverting to a rational such as 24000/1001.

nitpick (?): you are confusing readers, by calling a rational number "irrational". I think what you're trying to say is, 24000/1001 can't be expressed as a finite decimal (in base 10).

[Mosu]

Yes, that was what I was going for before confusing things in my head.

[von Suppé]

Hi Mosu,

When first importing subtitles, and after that importing video into mkvtoolnix, the default output is muxed as a *.mks file. Is this supposed to be?
Muxing as .mkv requires manual setting of the extension.

[Liisachan]

Thanks Mosu. Not sure if this is by design, but several language codes are not recognized as valid: e.g. hbo (Ancient Hebrew), tmr (Jewish Babylonian Aramaic).

@von Suppé
On Windows, at least for me...
1) if I select ASS first and manually select the Destination file without specifying an extension, then .mks is auto-selected and it will be stuck as you pointed out.
2) If I select ASS first and manually select the Destination file with extension .mkv, then .mkv wil be used after that.
However--
3) If I select ASS first and just select a video (MP4/264/MKV/AVI) without selecting the Destination file at all, then .mkv is auto-selected.

So it seems that the most intuitive way would be: First select every source file, then select the Destination file; and the extension will be fine.

[von Suppé]

So it seems that the most intuitive way would be: First select every source file, then select the Destination file; and the extension will be fine.
Thanks, I understand.

[SeeMoreDigital]

After 18 years of owning the Terminator 2 Extreme DVD, I've finally been able to extract and decrypt the second (DVD-ROM) discs 1440x816 WMV3 video stream (and 6 channel wma pro audio stream).

Currently both streams a muxed within the .wmv container, but when I tried to re-mux the .wmv file into the .mkv container, MKVToolNix reported ".... is an unsupported container format (Windows Media (ASF/WMV))".

I suspect some trickery is required to mux such video streams into the .mkv container but is it possible or am I wasting my time (and everybody else's)?

I've already re-encoded the 6 channel wma pro audio to 6 channel Dolby Digital...


Cheers

[Mosu]

When first importing subtitles, and after that importing video into mkvtoolnix, the default output is muxed as a *.mks file. Is this supposed to be?

As soon as you manually modify/specify a destination file name, the GUI will no longer mess with it. All automatisms such as adjusting the extension or trying to make it unique are suspended at that point. Definitely intentional.

[Mosu]

Thanks Mosu. Not sure if this is by design, but several language codes are not recognized as valid: e.g. hbo (Ancient Hebrew), tmr (Jewish Babylonian Aramaic).

At the moment: intentional; I only keep types "Constructed", "Living" & "Special" from 639-3 right now. The two you've mentioned are "Historical" & "Extinct".

[Mosu]

So it seems that the most intuitive way would be: First select every source file, then select the Destination file; and the extension will be fine.

Either that, or start with the source file containing video (as having a video track present & selected will always force .mkv as the extension) before setting the destination file name.

[lvqcl]

I suspect some trickery is required to mux such video streams into the .mkv container but is it possible or am I wasting my time (and everybody else's)?

Use ffmpeg.

[Liisachan]

In theory, if the user just inputs the output "file name stem" without an extension, it's still the muxer's job to decide the extension of the output file, before writing it.

However, it's rather unnatural that the user first specifies the subtitle (or audio) source file, then selects the output file name, then selects the video source file. They may happen to do that in some situations, but normally, people decide the output file name after they select all the input files, not in the middle of selecting input files...

At the moment: intentional; I only keep types "Constructed", "Living" & "Special" from 639-3 right now. The two you've mentioned are "Historical" & "Extinct". So it's based on the 639-3 tables, nothing personal... This too is practically not a big problem at all, but things seem quite random, and potentially touchy, upsetting Semitic peoples; e.g.
- Samaritan Hebrew is still used religiously, but "smp" is refused.
- "Used only religiously" is not good enough? That's why Biblical Hebrew (hbo) is also refused? But Classical Syriac (syc), the Christian language of Peshitta, is accepted. On the other hand Jewish counterparts (tmr & jpa) are refused.
- Imperial Aramaic is a long-dead language, but "arc" is accepted too, not to mention lat & arc.

While you're not responsible for these tables, they may be a bit biased. For the record, 639-3 is maintained by SIL, a Christian organization, which may not be ideal to handle the International standards neutrally. (Not like there's anything we could do about that, though.)

[Sakura-chan]

Using a Sample (https://drive.google.com/open?id=17GvV7mOGPaLMaOmJuyZv7AfhRsdrBM-D) which has 6.1 DTS-HD audio
mediainfo.exe c:\Users\Selur\Desktop\Sample_7Ch-001.mkv
General
Unique ID : 305643535159227373137804081320895496115 (0xE5F0CDBD216A8CAF2B4160690D24BFB3)
Complete name : c:\Users\Selur\Desktop\Sample_7Ch-001.mkv
Format : Matroska
Format version : Version 4
File size : 102 MiB
Duration : 1 min 2 s
Overall bit rate mode : Variable
Overall bit rate : 13.7 Mb/s
Encoded date : UTC 2019-12-28 21:56:35
Writing application : mkvmerge v41.0.0.27 ('Smarra') 64-bit
Writing library : libebml v1.3.10 + libmatroska v1.5.2

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 2 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 2 frames
Format settings, GOP : M=1, N=10
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 min 2 s
Bit rate mode : Variable
Bit rate : 9 771 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.197
Stream size : 72.5 MiB (71%)
Default : Yes
Forced : No

Audio
ID : 2
Format : DTS ES XXCH XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 1 min 2 s
Bit rate mode : Variable
Bit rate : 3 917 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs LFE Cb
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Stream size : 29.1 MiB (29%)
Language : English
Default : Yes
Forced : No
I use:
ffmpeg -y -threads 8 -i "C:\Users\Selur\Desktop\Sample_7Ch-001.mkv" -map 0:1 -vn -sn -bsf:a dca_core -acodec copy -map_metadata -1 "E:\Temp\iId_1_aid_0_lang_en_09_28_20_8410_01.dts"
to extract the dts core and get:
mediainfo.exe "e:\Temp\iId_1_aid_0_lang_en_09_28_20_8410_01.dts"
General
Complete name : e:\Temp\iId_1_aid_0_lang_en_09_28_20_8410_01.dts
Format : DTS ES XXCH
Format/Info : Digital Theater Systems
Commercial name : DTS-ES Discrete
File size : 11.2 MiB
Duration : 1 min 2 s
Overall bit rate mode : Constant
Overall bit rate : 1 509 kb/s

Audio
Format : DTS ES XXCH
Format/Info : Digital Theater Systems
Commercial name : DTS-ES Discrete
Duration : 1 min 2 s
Bit rate mode : Constant
Bit rate : 1 509 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs Cb LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 11.2 MiB
so far so good. Notice the core is DTS-ES with 6.1 audio.
Muxing the audio using mkvmerge using:
mkvmerge --ui-language en -o "E:\Output\Sample_7Ch-001.mkv" --global-tags "E:\Temp\Sample_7Ch-001_09_28_20_8410__02.xml" --language 0:en --default-track 0:yes --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "E:\Temp\iId_1_aid_0_lang_en_09_28_20_8410_01.dts"
I get:
mediainfo.exe "e:\Output\Sample_7Ch-001.mkv"
General
Unique ID : 297622948022399407897597109173123386592 (0xDFE81843105E42451110FB9E70E98CE0)
Complete name : e:\Output\Sample_7Ch-001.mkv
Format : Matroska
Format version : Version 4
File size : 11.2 MiB
Duration : 1 min 2 s
Overall bit rate mode : Constant
Overall bit rate : 1 511 kb/s
Encoded date : UTC 2019-12-29 08:28:49
Writing application : mkvmerge v41.0.0 ('Smarra') 64-bit
Writing library : libebml v1.3.9 + libmatroska v1.5.2
Encoding Gui : Hybrid 2019.12.28.1

Audio
ID : 1
Format : DTS ES XXCH
Format/Info : Digital Theater Systems
Commercial name : DTS-ES Discrete
Codec ID : A_DTS
Duration : 1 min 2 s
Bit rate mode : Constant
Bit rate : 1 509 kb/s
Channel(s) : 6 channels
Channel(s)_Original : 7 channels
ChannelLayout_Original : C L R Ls Rs Cs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 11.2 MiB (100%)
Language : English
Default : Yes
Forced : No
-> Seems like mkvmerge flags the stream as 6 channel audio.


=> is this a bug or did I miss something?

---
Update:

using ffmpeg for muxing:
ffmpeg -y -r 0 -i "E:\Temp\iId_1_aid_0_lang_en_09_28_20_8410_01.dts" -acodec copy -metadata encoding_tool="Hybrid 2019.12.28.1" -r 0 "E:\Output\Sample_7Ch-001_new.mkv"
everything looks fine:
ediainfo.exe e:\Output\Sample_7Ch-001_new.mkv
General
Unique ID : 214078310457880531657066923291995838582 (0xA10DFB9C6A72D9428FC442879C209876)
Complete name : e:\Output\Sample_7Ch-001_new.mkv
Format : Matroska
Format version : Version 4
File size : 11.3 MiB
Duration : 1 min 2 s
Overall bit rate mode : Constant
Overall bit rate : 1 515 kb/s
Writing application : Hybrid 2019.12.28.1
Writing library : Lavf58.35.100
ErrorDetectionType : Per level 1

Audio
ID : 1
Format : DTS ES XXCH
Format/Info : Digital Theater Systems
Commercial name : DTS-ES Discrete
Codec ID : A_DTS
Duration : 1 min 2 s
Bit rate mode : Constant
Bit rate : 1 509 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs Cb LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 11.2 MiB (100%)
Default : Yes
Forced : No
-> so this is probably a bug / missing feature in mkvmerge.

Cu Selur
Just noticed the same. This seem to happen only with DTS-ES streams, which is very rarely used on BDs so it's understandable why no one cares. Only two discs out of thousands I have I found that have DTS-ES, the Master Audio variant.

Audio
ID : 2
Format : DTS ES XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 1 h 48 min
Bit rate mode : Variable
Bit rate : 3 966 kb/s
Channel(s) : 6 channels
Channel(s)_Original : 7 channels
ChannelLayout_Original : C L R Ls Rs LFE Cs
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Stream size : 3.01 GiB (14%)
Language : English
Default : Yes
Forced : No

https://en.wikipedia.org/wiki/DTS_(sound_system)#DTS-ES

Idk why a centre back channel is so important to actually go and invent all that crap, just settle on 5.1 or go the extra mile to 7.1. Anyway, given that the extra channel is "matrixed" in the two rear channels I understand the actual audio, the "real" channels, are just 6, the 5.1 that mkvmerge labels. mkvmerge should label the audio as 7 channels like ffmpeg does. Or maybe not, given the 7th channel does not matter in terms of the container, as it's not a "real" channel. The 7th channel is "made up" by an ES-aware decoder.

Btw, makemkv produces the same result as mkvmerge.

With DTS-X something similar happens.

Audio
ID : 2
Format : DTS XLL X
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 2 h 10 min
Bit rate mode : Variable
Bit rate : 6 228 kb/s
Channel(s) : 8 channels
Channel(s)_Original : Object Based
ChannelLayout_Original : Object Based
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Stream size : 5.66 GiB (16%)
Language : English
Default : Yes
Forced : No

Channels is labelled as 8. I understand DTS-X has an MA 7.1 stream as base, so that's where channels come from. Even when the actual X stream is object based (so the "original" labels).


Btw, I can't search for anything in GitLab and all the issues are blank. Weird. We'll have to look into it.

[Mosu]

Hey y’all,

not a lot’s been happening over the last couple of weeks wrt. to coding for me, but I thought I’d publish the bug fixes I’ve amassed since the last release. So here you go, a fresh v62.

For package maintainers there was a small change. See the NEWS below.

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 62.0.0 "Apollo" 2021-10-10
New features and enhancements

all: IETF BCP 47/TFC 5646 language tags: all ISO 639 languages are now available, even the ones that aren't of types "Constructed", "Living" or "Special".
mkvmerge, mkvpropedit: chapters: both programs will now write elements set to their default value, too (e.g. the legacy language element if it's set to "eng"). This is done to be more consistent with how MKVToolNix GUI writes chapters. Implements #3210 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3210).
MKVToolNix GUI: multiplexer: when adding new files as attachments the GUI checks if there are other attachments with the same name. If so, the GUI would ask whether to skip the affected files or add them anyway. There's now an option in the preferences to always skip such files, and it's enabled by default. Implements #3213 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3213).
MKVToolNix GUI: chapter editor: removed the support for explicitly setting the legacy country elements. Instead the legacy country elements are derived from the region parts of the IETF BCP 47 languages. Part of the implementation of #3193 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3193).

Bug fixes

mkvmerge: fixed a crash when splitting by chapters is enabled but there are no chapters at all. Part of the fix of #3198 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3198).
mkvmerge: the error message when trying to split by a chapter number that doesn't exist contained the wrong number of chapters that actually do exist. Part of the fix of #3198 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3198).
mkvmerge: AVC ES parser: fixed mkvmerge aborting due to uncaught exception when encountering bad SPS data. Part of the fix of #3176 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3176).
mkvmerge: AVC/H.264 parser: re-added the hack "--engage all_i_slices_are_key_frames" which was accidentally removed in release v61.
mkvmerge: AVI reader: fixed a crash trying to allocate too big of a memory chunk due to an integer overflows in check conditions. Part of the fix of #3176 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3176).
mkvmerge: HEVC ES parser: fixed another issue with frame type recognition. Certain frames were marked as B frames/discardable on the container level even though they could be reference pictures. Now only SLNR pictures (sub-layer non-reference) are marked that way. Fixes #3192 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3192).
mkvmerge: HEVC ES reader: improved file content detection for HEVC ES files with wrong file name extensions (e.g. ".mkv"), which fixes them being mis-detected as something else, e.g. DTS. Fixes #3201 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3201).
mkvmerge: HEVC ES parser: "end of sequence" NALUs are kept now, and no superfluous flushing will be done when one is found. This prevents splitting NALUs into two different Matroska blocks when they should really be part of a single one, also causing problems with erroneous timestamps. Mostly affects DoVi NALUs. Fixes #3202 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3202).
mkvmerge: Matroska reader, TrueHD: mkvmerge will now probe much more TrueHD frames trying to find the first sync frame. This fixes track detection in situations when a TrueHD doesn't start with a sync frame, e.g. when the source file's the result of splitting between sync frames.
mkvmerge, MKVToolNix GUI's chapter editor: IETF BCP 47/RFC 5646 language tags: when reading chapters from MPLS playlist files, the "ChapLanguageIETF" element will now be set to the configured default chapter language, not just the legacy "ChapterLanguage" element. Part of the fix of #3193 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3193).
mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: IETF BCP 47 elements will now always be created before writing chapters unless IETF BCP 47 elements are disabled. Part of the fix of #3193 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3193).
mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: when a chapter display element contains legacy language & country elements but no IETF BCP 47 elements and IETF BCP 47 elements aren't disabled, the IETF BCP 47 elements created will contain the region from the legacy element. Part of the fix of #3193 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3193).
mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: Legacy country elements are now created when IETF BCP 47 elements are present & contain a region code allowed in legacy country elements. Part of the fix of #3193 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3193).

Build system changes

The "tools" sub-directory is now always built. The corresponding "configure" option "--with-tools" has been removed. The "install" target still doesn't install them, though.


Have fun 😁

[rco133]

Hi.

Am I missing something, or how do I add Greek (ell) language.

In version 62 it seems to be totally gone. In version 60 there was Greek (grc, Ancient Greek) or something like that.

Maybe I am just missing something.

[rco133]

Hi.

Am I missing something, or how do I add Greek (ell) language.

In version 62 it seems to be totally gone. In version 60 there was Greek (grc, Ancient Greek) or something like that.

Maybe I am just missing something.

Never mind.

I was clearly missing something. I was just typing "Greek" in the language area, and expected it to find something. It didn't.

Now I tried to ebter "gre" in the free form input field, and it shows "Modern Greek". Sorry for the inconvenience.

[Nejiro]

Hello everyone, excuse me a question, if I have to merge two files and I have subtitles in the second track is there any way to do it? because being alone in the second file it cannot merge them with anything since in the first file the subtitles are not there ..... there is a way to merge the two files and put the subtitles only in the second track so that when I review the whole file the subtitles start with the right time, ie in the second track?
Thanks

[Mosu]

Depends on the subtitle format in question. For SRT-style subtitles (CodecID S_TEXT/UTF-8) and SSA/ASS (CodecID S_TEXT/SSA or …/ASS) it is possible by creating a temporary Matroska file consisting of the first file (the one without a subtitle track) and an empty text subtitle file. For SRT this is trivia; just create a text file, leave it empty and save it under "empty.srt". For SSA/ASS it gets a bit more complicated as SSA/ASS contains formatting blocks etc; the procedure is extracting the subtitles from the file you want to append, edit that extracted SSA/ASS file with a text editor & remove all lines starting with "Dialogue:". That way you'll have an SSA/ASS file with the same global header but without content.

MKVToolNix can then recognize empty SRT/SSA/ASS subtitle files & will create a subtitle track in the output file.

Step 2 is taking that temporary file & appending the file you wanted to append originally.

[hubblec4]

Depends on the subtitle format in question. For SRT-style subtitles (CodecID S_TEXT/UTF-8) and SSA/ASS (CodecID S_TEXT/SSA or …/ASS) it is possible by creating a temporary Matroska file consisting of the first file (the one without a subtitle track) and an empty text subtitle file. For SRT this is trivia; just create a text file, leave it empty and save it under "empty.srt". For SSA/ASS it gets a bit more complicated as SSA/ASS contains formatting blocks etc; the procedure is extracting the subtitles from the file you want to append, edit that extracted SSA/ASS file with a text editor & remove all lines starting with "Dialogue:". That way you'll have an SSA/ASS file with the same global header but without content.

MKVToolNix can then recognize empty SRT/SSA/ASS subtitle files & will create a subtitle track in the output file.

Step 2 is taking that temporary file & appending the file you wanted to append originally.

Yeah, and that works for all subtitle formats.
chapterEditor uses empty Blu-ray sups and VOB-subs(idx/sub) to help MTX to get a correct work flow.

[tormento]

I have a collection of old mkv videos that I would like to remux to latest matroska version.

I usually launch (on Windows)

for %%a in (*.mkv) do "D:\eseguibili\media\MKV Toolnix\mkvmerge.exe" -o "%%~na.mkv" "%%a"

but it doesn't keep the original date and time.

Is there a flag or can you suggest me a better batch to preserve date and time too?

[Mosu]

mkvmerge cannot preserve that field. If you need to preserve it, you'll have to retrieve it first with e.g. "mkvmerge -J source.mkv" and set it afterwards mit mkvpropedit.

[kuchikirukia]

Why do certain remuxes of interlaced 29.97 fps content come out showing up as 59.94, yet still manage to play properly as 29.97?

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 2 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 2 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 5 min 24 s
Bit rate mode : Variable
Bit rate : 32.9 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 59.940 (60000/1001) FPS
Original frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.265
Stream size : 1.24 GiB (96%)
Default : Yes
Forced : No

[tormento]

mkvmerge cannot preserve that field. If you need to preserve it, you'll have to retrieve it first with e.g. "mkvmerge -J source.mkv" and set it afterwards mit mkvpropedit.
I meant file date and time, not mkv properties. :)

[Mosu]

I meant file date and time, not mkv properties. :)

Nearly same answer; mkvmerge cannot preserve that; you'll have to query that before muxing & set it afterwards. On Linux this is pretty trivial as you can get a file modification time with the "stat" command, and changing it works via the "touch". Don't know how to do that on Windows, though you might get this to work with projects such as mingw (or maybe the Windows Subsystem for Linux).

[videoh]

Why do certain remuxes of interlaced 29.97 fps content come out showing up as 59.94, yet still manage to play properly as 29.97? Could be down to the difference between container and elementary stream metadata.

[kuchikirukia]

Could be down to the difference between container and elementary stream metadata.

The thing is that MPC-HC usually respects the container's flag on playback. If you mux a typical video at some arbitrary frame rate, MPC-HC will play it back at the container frame rate. But it doesn't play these remuxes at 59.94 fps even though it's apparently being passed as such: madVR is reporting it as 59.94.

Bluray m2ts: 29.970 (says source filter)
mkv: 59.940 (says source filter)

Plays both at 29.970

Specifically muxing it as 60000/1001p still plays back at 29.970, showing 59.940,
Forcing the mux to 30000/1001p plays back at half speed while saying 29.970 (says source filter).
Using i instead of p doesn't seem to make any difference.

[qyot27]

Nearly same answer; mkvmerge cannot preserve that; you'll have to query that before muxing & set it afterwards. On Linux this is pretty trivial as you can get a file modification time with the "stat" command, and changing it works via the "touch". Don't know how to do that on Windows, though you might get this to work with projects such as mingw (or maybe the Windows Subsystem for Linux).
WinTouch exists, which can set arbitrary creation, modified, and access dates. It's on CodeProject (the download sign up wall didn't exist when I downloaded it all those years ago), not sure if anyone has migrated the code to another host.

[Snowknight26]

Or just use PowerShell.


$file1 = Get-ChildItem file1.ext
$file2 = Get-ChildItem file2.ext
$file1.LastWriteTime = $file2.LastWriteTime

[Mosu]

Or just use PowerShell.

That looks very nice & useful! Thanks 😁

[tormento]

Or just use PowerShell.
Being a complete noob or PowerShell, can I kindly ask you a small script to just remux all the mkv that if finds, preserving timestamps?

[NanoBot]

Hi,

I meant file date and time, not mkv properties. :)

to set the file date and time back to the original values under Windows you may find this freeware program interesting:

https://www.funduc.com/fstouch.htm

[Snowknight26]

Being a complete noob or PowerShell, can I kindly ask you a small script to just remux all the mkv that if finds, preserving timestamps?

I guess this should work. Hope your filenames don't have an quotes because I didn't feel like handling those.


Get-ChildItem C:\Source\Path\ -Filter *.mkv | % {
$inputObject = $_
$outputPath = "C:\Output\Path\$($_.BaseName)$($_.Extension)"
& 'C:\Program Files\MKVToolNix\mkvmerge.exe' -o "$outputPath" "$($_.FullName)"
Get-ChildItem $outputPath | % { $_.LastWriteTime = $inputObject.LastWriteTime }
}

[oniiz86]

Is there anyway to have the legacy language element for English "eng" enabled by default for audio & subtitles like it is for foreign languages?

[Liisachan]

@Mosu thanks for the new version!

Is there anyway to have the legacy language element for English "eng" enabled by default for audio & subtitles like it is for foreign languages?
No "Language" element for the track means, by the specs, the default language, i.e. equivalent to "eng". Do you want to explicitly write "Language"="eng" anyway? If so, try something like this after muxing:

mkvpropedit.exe "your.mkv" --edit track:s1 --set language=eng

[oniiz86]

No "Language" element for the track means, by the specs, the default language, i.e. equivalent to "eng". Do you want to explicitly write "Language"="eng" anyway? If so, try something like this after muxing:

mkvpropedit.exe "your.mkv" --edit track:s1 --set language=eng

Yes I want to explicitly set to "eng" when I open the program, I noticed on my OPPO players the language is missing for English because I realised the old language element is not active like it is for foreign languages which have both "legacy" & BCP 47 elements always active, like Swedish for example has "swe" & "sv" whereas English only has the BCP 47 element active "en", I'm very sorry I'm quite the noob when it comes to utilising command lines, where do I place it so it runs everytime when muxing?

[Mosu]

Yes I want to explicitly set to "eng" when I open the program, I noticed on my OPPO players the language is missing for English

Most likely because your player doesn't support the Matroska specs correctly with respect to default values. The default value for the legacy language element is "eng", and therefore if the element isn't present in the file, that default value must be used.

Bug in your player. Nothing you can do about it on the MKVToolNix side.

[oniiz86]

Most likely because your player doesn't support the Matroska specs correctly with respect to default values. The default value for the legacy language element is "eng", and therefore if the element isn't present in the file, that default value must be used.

Bug in your player. Nothing you can do about it on the MKVToolNix side.

I don't believe so, it may be a change you had implemented over the years as mkvmerge v2.5.3 had the legacy language element enabled by default & my OPPO players recognise it correctly but chapter navigation had become corrupted so I remuxed with the latest build v62.0.0 & everything was fine except for the legacy language element "eng" not being active & had to manually enable the legacy language element "eng" for it to be recognised again.

Here is what mkvinfo reports for the really old mkvmerge build v2.5.3, the legacy language element for English is present "eng" as you can see, the latest build v62.0.0 does not have it present by default anymore but the foreign languages still have their legacy language elements active, obviously the old OPPO players do not recognise the newer IETF BCP 47 language elements & rely on the legacy language elements.

https://i.imgur.com/rPtOOid.png
https://i.imgur.com/ZksKHlE.png

[Mosu]

The thing is that the library used by MKVToolNix is a bit… finicky wrt. default values. I can turn on writing elements which are set to default values, but that also writes a lot of other elements that players aren't used to seeing at all. In the past there have been many players that have flat-out refused to play files containing such elements.

Implementing this one workaround (writing legacy language element if set to "eng") for one player would risk running into much more severe problems on other players. For something that _is_ a bug in the Oppo player. So… no.

And this has nothing (or very little) to do with BCP 47 language elements. It's a basic bug wrt. handling the legacy language element if it isn't present. In the Oppo player.

[oniiz86]

Ok, I understand, I didn't realise it would be so finicky if "eng" would remain active like all foreign languages in the most latest builds, I suppose OPPO never picked up on this bug across their player generations, it's not a massive issue but it's quite the laborious task to adjust for it in the header editor for every file, is there a batch file command to initiate across several files that could work like @Liisachan suggested, mkvpropedit.exe "your.mkv" --edit track:s1 --set language=eng

[Ian1182]

A Windows bat file similar to this

@echo off
for %%m in ("*.mkv") do (

"%ProgramFiles%\MKVToolNix\mkvpropedit" "%%~nm".mkv --edit track:s1 --set language=eng
"%ProgramFiles%\MKVToolNix\mkvpropedit" "%%~nm".mkv --edit track:a1 --set language=eng

)
exit /b

should work.
That sets the first audio and subtitle track to English of any MKV files in folder.

[oniiz86]

A Windows bat file similar to this

@echo off
for %%m in ("*.mkv") do (

"%ProgramFiles%\MKVToolNix\mkvpropedit" "%%~nm".mkv --edit track:s1 --set language=eng
"%ProgramFiles%\MKVToolNix\mkvpropedit" "%%~nm".mkv --edit track:a1 --set language=eng

)
exit /b

should work.
That sets the first audio and subtitle track to English of any MKV files in folder.

Thanks for that, I'm sorry I'm quite the noob when it comes to this, not so familiar with command lines, where do I place them exactly & will this sort of be a set and forget type of instructions?

[Ian1182]

I am assuming you are using a Windows PC.

Create a file called oniiz86.bat in a folder, contents of file as per my earlier response. Hopefully you are familar on the process to create a bat file, if not Google is your friend.

You then double click the bat file and it should set the audio & subtitle tracks for all the MKV files in that folder.

If you don't wish to update all files, the best approach would be to create a test folder, add the bat file to the test folder, copy over any MKV files you wish to update. Then run the bat file and copy back the updated files to your video folder.

Nope, its not set and forget as this is a manual process to add the audio/subtitle languages using a bat file.

Of course you can set the language to eng in the MKVTOOLNIX GUI and it should be honoured. I did a quick test and all was good. When no language was specified it was indeed left as undefined allowing the video player to decide on what to report.

[oniiz86]

I am assuming you are using a Windows PC.

Create a file called oniiz86.bat in a folder, contents of file as per my earlier response. Hopefully you are familar on the process to create a bat file, if not Google is your friend.

You then double click the bat file and it should set the audio & subtitle tracks for all the MKV files in that folder.

If you don't wish to update all files, the best approach would be to create a test folder, add the bat file to the test folder, copy over any MKV files you wish to update. Then run the bat file and copy back the updated files to your video folder.

Nope, its not set and forget as this is a manual process to add the audio/subtitle languages using a bat file.

Of course you can set the language to eng in the MKVTOOLNIX GUI and it should be honoured. I did a quick test and all was good. When no language was specified it was indeed left as undefined allowing the video player to decide on what to report.

Yes I am using Windows, this would be my first foray in creating a batch file, so hopefully I'll get the hang of it, I'm not sure what you mean by setting the language to "eng" as I couldn't find that setting anywhere unless you meant adjusting the header editor which is how I'm making such changes now?

[Ian1182]

How are you creating the MKV file in the first place. On the MKVToolNix GUI you have options to set the language for any of the tracks (video, audio, subtitles, etc).

The header editor is MKVPropEdit which is more of a command line tool hence the use of a windows bat file to issue the commands.

Which one are you using? If you are muxing the file from scratch using MKVToolNix it should be straightforward to set any of the attributes you need.

The header editor is useful for adding/deleting/modifying file characteristics on an existing MKV file.

[Liisachan]

You can also write "English" in the "Track name" edit-box, when creating your mkv using mkvroolnix-gui.exe. Many players show this text for the track. Maybe this solves your problem?

To use command line things, let's say you downloaded a standalone version of MKVToolnix, and unzipped the files in D:\mkvtoolnix (that is, a folder named "mkvtoolnix" in the root of your D: drive). For the simplicity, assume you put your source files in the same folder (D:\mkvtoolnix). I'll call them input.264, input.ogg, input.ass, but they can be anything.

1. Open the dos-box, by hitting [Win]+[R] and typing cmd [enter]
2. In the dos-box (a black window), type D: [enter] then type cd mkvtoolnix [enter]. It's good if the prompt says "D:\mkvtoolnix >" now.
3. Type this to create "your.mkv": mkvmerge --output "your.mkv" input.264 input.ogg input.ass [enter]
4. You'll see a few lines in your dos-box. Wait until it says "Progress: 100%". It's good, if you see no errors or warnings.
5. Now type this: mkvpropedit "your.mkv" --edit track:a1 --set language=eng --edit track:s1 --set language=eng [enter]
6. It's good, if it says "Done." without errors.

A batch file may be used when you don't want to do the same thing manually again and again. Create a small text file that has the same 2 lines you typed above:
mkvmerge --output "your.mkv" input.264 input.ogg input.ass
mkvpropedit "your.mkv" --edit track:a1 --set language=eng --edit track:s1 --set language=eng
and save it as, say, "do-it.bat" in D:\mkvtoolnix. Now you can just type do-it [enter] and the same thing will happen in one go.

In reality, you can replace any file name in the above example (e.g. input.264) with an actual file path (e.g. "D:\path to\some folder\your video.mp4"). Quotation marks " are necessary if the path contains space(s), optional otherwise. If you're not sure, ask mkvtoolnix-gui to generate a command line for you: use the GUI as you usually do, but instead of Start multiplexing, you can use the menu "Multiplexer | Show command line". Paste that into your do-it.bat.

The FOR loop and %% variables can be used to create a "meta-batch" file to run similar command lines in one go. You may want to try that once you're comfortable with normal command lines. However, in the above example, we're assuming that the track #1 is always English. If, for example, track #1 is Swedish and #2 is English, then the command line to use will be different, and if the track # for English is not fixed, things get difficult...

If you only need to edit a few MKV files once in a while, and you don't want to use command lines, well, this "side channel attack" (?) should work too: create your mkv using GUI normally, but set some totally unrelated language code, say Chinese, for tracks that are actually English. Then, open your fake-Chinese MKV with a binary editor, find "chi" & "zh" near CodecID, and overwrite them as "eng" & "en" respectively. The result should be a valid MKV file (unless the data is CRC-protected; mkvmerge doesn't write CRCs, so that's not a problem). People will say "Don't do this" and I wouldn't recommend this final method either, but it should work.

[oniiz86]

How are you creating the MKV file in the first place. On the MKVToolNix GUI you have options to set the language for any of the tracks (video, audio, subtitles, etc).

The header editor is MKVPropEdit which is more of a command line tool hence the use of a windows bat file to issue the commands.

Which one are you using? If you are muxing the file from scratch using MKVToolNix it should be straightforward to set any of the attributes you need.

The header editor is useful for adding/deleting/modifying file characteristics on an existing MKV file.

I'm sorry for confusing matters, I'm creating a file in the simplest way possible, selecting all the appropriate language tags, that is not the concern, the problem was that legacy language element "eng" is no longer enabled by default like all foreign languages but as I was told this is the correct behavior by design,

https://i.imgur.com/sixl6ZV.png?1

It was the Header Editor section I noticed this discrepancy between English & foreign languages with the legacy elements, you'll note that it is absent when I would've very much preferred for it to be active without manually enabling it,

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

This is how it is for foreign legacy language elements, enabled by default

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

[oniiz86]

You can also write "English" in the "Track name" edit-box, when creating your mkv using mkvroolnix-gui.exe. Many players show this text for the track. Maybe this solves your problem?

To use command line things, let's say you downloaded a standalone version of MKVToolnix, and unzipped the files in D:\mkvtoolnix (that is, a folder named "mkvtoolnix" in the root of your D: drive). For the simplicity, assume you put your source files in the same folder (D:\mkvtoolnix). I'll call them input.264, input.ogg, input.ass, but they can be anything.

1. Open the dos-box, by hitting [Win]+[R] and typing cmd [enter]
2. In the dos-box (a black window), type D: [enter] then type cd mkvtoolnix [enter]. It's good if the prompt says "D:\mkvtoolnix >" now.
3. Type this to create "your.mkv": mkvmerge --output "your.mkv" input.264 input.ogg input.ass [enter]
4. You'll see a few lines in your dos-box. Wait until it says "Progress: 100%". It's good, if you see no errors or warnings.
5. Now type this: mkvpropedit "your.mkv" --edit track:a1 --set language=eng --edit track:s1 --set language=eng [enter]
6. It's good, if it says "Done." without errors.

A batch file may be used when you don't want to do the same thing manually again and again. Create a small text file that has the same 2 lines you typed above:
mkvmerge --output "your.mkv" input.264 input.ogg input.ass
mkvpropedit "your.mkv" --edit track:a1 --set language=eng --edit track:s1 --set language=eng
and save it as, say, "do-it.bat" in D:\mkvtoolnix. Now you can just type do-it [enter] and the same thing will happen in one go.

In reality, you can replace any file name in the above example (e.g. input.264) with an actual file path (e.g. "D:\path to\some folder\your video.mp4"). Quotation marks " are necessary if the path contains space(s), optional otherwise. If you're not sure, ask mkvtoolnix-gui to generate a command line for you: use the GUI as you usually do, but instead of Start multiplexing, you can use the menu "Multiplexer | Show command line". Paste that into your do-it.bat.

The FOR loop and %% variables can be used to create a "meta-batch" file to run similar command lines in one go. You may want to try that once you're comfortable with normal command lines. However, in the above example, we're assuming that the track #1 is always English. If, for example, track #1 is Swedish and #2 is English, then the command line to use will be different, and if the track # for English is not fixed, things get difficult...

If you only need to edit a few MKV files once in a while, and you don't want to use command lines, well, this "side channel attack" (?) should work too: create your mkv using GUI normally, but set some totally unrelated language code, say Chinese, for tracks that are actually English. Then, open your fake-Chinese MKV with a binary editor, find "chi" & "zh" near CodecID, and overwrite them as "eng" & "en" respectively. The result should be a valid MKV file (unless the data is CRC-protected; mkvmerge doesn't write CRCs, so that's not a problem). People will say "Don't do this" and I wouldn't recommend this final method either, but it should work.

Thanks so very much for your assistance & @Ian1182, I'll see how I go & report back if it is a success!

[Ian1182]

Maybe I'm getting confused with the problem you are seeing.

If I add a audio or subtitle track using the MKVToolNix GUI and set a language, I see that in the resulting MKV file even if the language is English. However if I add a track and do not set any language (or set to "und") then the resulting MKV has no language attribute.

I see that as correct, if you don't set a language in the GUI it should be left as undefined (or blank) and allow the player to determine.

What I would see as incorrect would be for the GUI to set the language as undefined when the user explicitly specifies "eng". My experience is that the GUI does respect a user choice.

[Mosu]

Their problem is their player. It doesn't support the Matroska specs properly. When the legacy language element is set to English ("eng"), mkvmerge doesn't write it to the file. That is spec-compliant as the specs say that the element's default value is "eng", and any reader must use that value if the element isn't present.

Their player doesn't do that.

Therefore they want to have a way to force writing that element to the file. mkvmerge doesn't provide a way for that.

then the resulting MKV has no language attribute.

That is incorrect. In Matroska terms it isn't possible not to set a language. Semantically a language code is always in effect, whether or not the elment is present in the file doesn't matter.

[Ian1182]

@Mosu . Thanks for clearing that up.

[GAP]

What are the differences between the two versions of MKVToolnix?

[Mosu]

Which two versions are you talking about?

[Nejiro]

I am encountering with this latest version 62 on Ubuntu always errors when I load the index file of a bluray, example almost always tells me that file x cannot be joined to file y because they have different bitrate instead of the content if I go to see the m2ts file it's all on a file (type 0001.m2ts) and it has no different bitrate, in fact if I directly load the m2ts file it works, if I use the index file it always gives me this error, it didn't happen before ......

[Liisachan]

To clarify: 1) If you don't specify the language of a track, then it's set as "und" (Undefined). This does not mean that the Language element is NOT defined; actually it is explicitly defined as "und" (a bit confusing, kind of oxymoron :confused:).
2) If the Language value is indeed not defined (non-existing), then, by the Matroska Specks, the missing element is implicitly assumed to have the default value, which is "eng".
3) Technically, and even more confusing, both 1) and 2) are supposed to be ignored anyway whenever the LanguageIETF is defined for that track.

Perhaps a helpful thing to do is, to open a ticket if your player doesn't treat the non-existing Language element as "eng" - such Specs are admittedly confusing and in a way arbitrarily English-centric, but it's too late to change this now, and we're going to have to politely ask the player's devs to support this.

Adding --track-name is helpful for human users, in the menu etc. (e.g. --track-name "0:Français" for French subs); but it doesn't change the Language value.

@oniiz86: to answer your PM, you don't need to demux/remux the existing files. If you have your files to edit in C:\test, then you can create this test1.bat in the same folder:
SET PropEdit="X:\path to\mkvtoolnix\mkvpropedit.exe"

FOR %%f IN (*.mkv) DO %PropEdit% "%%f" --edit track:a1 --set language=eng --edit track:s1 --set language=eng


...assuming that the 1st Audio track and 1st Subtitle track are English. If for example, the audio in English is #2, change "a1" to "a2". The first line sets the path to mkvpropedit.exe. The FOR loop means, "FOR each file %%f DO this". In Dos-box, one can type:

cd /d C:\test
test1


Since the files will be rewritten in-place, you may want to save the original files first just in case something goes wrong. To automatically copy & save the original files as read-only, you can simply add something like this before the FOR loop in test1.bat:
mkdir BACKUP
copy /b *.mkv BACKUP\*.mkv
attrib +r BACKUP\*.mkv

[Nejiro]

Depends on the subtitle format in question. For SRT-style subtitles (CodecID S_TEXT/UTF-8) and SSA/ASS (CodecID S_TEXT/SSA or …/ASS) it is possible by creating a temporary Matroska file consisting of the first file (the one without a subtitle track) and an empty text subtitle file. For SRT this is trivia; just create a text file, leave it empty and save it under "empty.srt". For SSA/ASS it gets a bit more complicated as SSA/ASS contains formatting blocks etc; the procedure is extracting the subtitles from the file you want to append, edit that extracted SSA/ASS file with a text editor & remove all lines starting with "Dialogue:". That way you'll have an SSA/ASS file with the same global header but without content.

MKVToolNix can then recognize empty SRT/SSA/ASS subtitle files & will create a subtitle track in the output file.

Step 2 is taking that temporary file & appending the file you wanted to append originally.

Unfortunately I didn't quite understand what to do as none of my subtitles have that format, they are all in HDMV-PGS format, the only thing I managed to do is take the second track (the one where there are subtitles) save only the subtitles so that I get an .mks file which I then put in the first track so that when I add the track with the subtitles they only merge that then in the file obtained the subtitles start immediately and I would not want them to be there but in the second track I saw that there are and they also report with the times, so I have to keep the subtitles off and then activate them when needed .....

[tormento]

I'd like to save the AVS script that I used to encode the video along with the mkv, so I can see after some years, how I got that result.

Is there a comment section in MKV where you suggest to put such a small text? If readable thru MediaInfo it would be even better.

[Mosu]

Either use tags with a tag name you invent for the occasion (e.g. ENCODED_WITH_AVS_SCRIPT), or, simply attach it. The latter is preferable as there's more meta data stored with that method: you have to assign a MIME type to it, and you can keep your file name.

[Mosu]

so I have to keep the subtitles off and then activate them when needed .....

If you go the route you described, you can use the "delay" feature on the subtitle track in the first file when appending and use a ridiculous high negative value with it (its absolute value must be higher than the length of the first part). That way all entries from that first file (the ones you don't want to see) will end up with negative timestamps & will not actually be written to the output file.

Untested.

[Nejiro]

Yes thanks, it's a good idea, I'll try to see if it works ...... I put a value like 1,000,000 to be sure it goes beyond?

[Mosu]

Sure, or just 10000. The unit is "seconds"; meaning this is just below 3h.

[Nejiro]

One thing I wanted to ask, one of the functions that I use most to join two files is "hang files" so that they are placed one behind the other to obtain a single file, the function "add as additional parts" what is it for? 'did I ever understand ....
Thanks

[Mosu]

Not really. See this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Adding-files-vs.-Appending-files-vs.-adding-as-additional-parts) for details.

[Nejiro]

What is a lossless format that I can use instead of wav? Because several of my films have track in pcm / wav both in 2 channels and in 5.1, if I turn them into flac I would have a considerable space reduction without loss of quality but then unfortunately I can't merge two or three files as the program doesn't support it, I tried wavpack and it works but then it is not read to me by my Zidoo Z9X player, so I don't know what to use as a lossless format .....
Thanks

[SeeMoreDigital]

...if I turn them into flac I would have a considerable space reduction without loss of quality but then unfortunately I can't merge two or three files as the program doesn't support it... How about merging the (two or three) files which include PCM.wav audio first. Then extract the PCM.wav audio and re-encode it to Flac...

[Nejiro]

I have often done this but the times do not always coincide, if you merge multiple files and each audio file is contained in the same it is almost always fine, if after merging everything I extract the single pcm track and then transform it into flac many times the times do not coincide and unfortunately nothing can be done because it is fine for the first file and it starts to desynchronize after the second or third, so I can't even synchronize it with the delays etc .... I hope I have explained myself, sorry but I use a translator.

[Mosu]

What is a lossless format that I can use instead of wav? Because several of my films have track in pcm / wav both in 2 channels and in 5.1, if I turn them into flac I would have a considerable space reduction without loss of quality but then unfortunately I can't merge two or three files as the program doesn't support it

There are tons of lossless formats out there, and MKVToolNix supports quite a number of them. In no particular order:

Uncompressed PCM
FLAC
TTA (True Audio)
WavPack
ALAC (Apple Lossless Audio Codec)
DTS-HD MA (Master Audio)
TrueHD

As for FLAC: you can still append such tracks, and the result mostly works fine, if you enable the proper override. See this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Appending-&-splitting-FLAC-audio-tracks-not-supported) for details.

[Nejiro]

The problem is that many concert blurays have different tracks, for example, there is the main concert in dts-hd 96 and sometimes there are clips in dts-hd 48, I have no way to produce dts files (and not even true- hd) with no program then to merge the two files I extract the dts track and with audacity I transform it into pcm to put both at 48 or 96 so that I can merge them, often the files are even more than two and if I merge the single tracks the times coincide if after obtaining the single file I extract the pcm track and transform it into flac the times then do not coincide that's why I need to merge flac files but if it is not possible it does nothing ..... Alac is as big as PCM and audacity does not support it well, wavpack I can get it with ffmpeg or with native wavpack on ubuntu because audacity does not support it in output, in a nutshell it remains only the flac for me unfortunately ..... and the flac there is no way to join them.
Thanks

[Mosu]

and the flac there is no way to join them.

Again, you STILL CAN APPEND THEM. Read the FAQ entry!

[Nejiro]

But really now is there a way to merge the flacs? You give me great news because I have not even tried as I always got an error when I had to merge files with the flac inside, from which version is this functionality?
Thanks

[Mosu]

I… seem to completely fail to convey to you that you should read the FAQ entry I've linked, as the answer how to do that is written in said FAQ entry.

[Nejiro]

Sorry but maybe we don't understand each other, on the faq I find this section about flacs https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Appending-&-splitting-FLAC-audio-tracks-not-supported

[Nejiro]

I added the entry --engage append_and_split_flac in the gui on the options (I hope I put them in the right place) as written in the faq and I tried to merge two flacs but it gives an error, it says that these tracks are not supported, do not give an error immediately, try to join them but then from error .....

[Mosu]

Not supported!? Uh… is your MKVToolNix version compiled without FLAC support, maybe? Using Gentoo with use flags that prohibit FLAC?

Check in the GUI via "Help" → "System information". Near the bottom it'll list "Compiler and libraries". Does this section contain "FLAC"?

MKVToolNix has supported FLAC for… well over a decade. It's optional, though, and one can compile MKVToolNix support without it. By default it is enabled if libFLAC is detected in the "configure" stage.

And it would help if you posted the actual error message. Verbatim, please. Thanks.

[Nejiro]

Does this section contain "FLAC"?



https://i.postimg.cc/t1fVBJJg/Schermata-del-2021-10-26-00-52-25.png (https://postimg.cc/t1fVBJJg)

[Mosu]

Soooooooooo… can you upload the files somewhere?

And again, what is the exact error message? Please copy&paste it here, don't just paraphrase.

[Nejiro]

https://i.postimg.cc/F7jSvrf1/Schermata-del-2021-10-26-09-13-18.png (https://postimg.cc/F7jSvrf1)

https://i.postimg.cc/YGW9xRYj/Schermata-del-2021-10-26-09-15-22.png (https://postimg.cc/YGW9xRYj)

https://i.postimg.cc/kBF2ZTZb/Schermata-del-2021-10-26-09-14-32.png (https://postimg.cc/kBF2ZTZb)

[Mosu]

Which version of MKVToolNix is this?

[Liisachan]

The problem is that many concert blurays have different tracks, for example, there is the main concert in dts-hd 96 and sometimes there are clips in dts-hd 48
This may not be the problem here, but you can't probably append 96000.flac + 48000.flac.

Also, if your files happen to be like this...
0.mkv (track 0 = video, track 1 = flac)
1.mkv (track 0 = flac, track 1 = video)
... then -o out.mkv 0.mkv + 1.mkv probably doesn't work. You'll have to manually map the tracks to append, like --append-to 1:1:0:0,1:0:0:1

[Mosu]

You are definitely correct in that one cannot append two FLAC tracks that have different sampling frequencies, no matter which option one uses, Liisachan.

The other part of your answer doesn't apply in this case, though, as they're trying to append FLAC files, not Matroska files. You can see both source file names in the error message. Additionally, the "pre-parsing FLAC file…" messages only occur in the FLAC reader, not for FLAC in other containers.

On top of all that the last sentence of the error message is the one only output if mkvmerge doesn't support appending of these track types in general. Other reasons (sampling frequency, number of channels, codec type mismatch) have distinctly different error messages.

[Nejiro]

Which version of MKVToolNix is this?

It is the latest version 62.0.0 (Apollo) https://flathub.org/apps/details/org.bunkus.mkvtoolnix-gui

Obviously I have not tried to combine flacs with different samples, I know that you cannot do that with any file, they are always the same but that error has always been that and so by now I have given up on flac for my mkvs unfortunately .....

Unfortunately, however, as already said, apart from the wav that is not compressed I cannot find any lossless container that is supported by my Zidoo Z9X, I have also tried True-Audio (tta), Alac and wavpack which I get very well with ffmpeg but none of the three is supported

[Nejiro]

This may not be the problem here, but you can't probably append 96000.flac + 48000.flac.

Also, if your files happen to be like this...
0.mkv (track 0 = video, track 1 = flac)
1.mkv (track 0 = flac, track 1 = video)
... then -o out.mkv 0.mkv + 1.mkv probably doesn't work. You'll have to manually map the tracks to append, like --append-to 1:1:0:0,1:0:0:1


Sorry but I didn't understand anything :confused:

[Liisachan]

Sorry, I'm not sure what you're trying to do... Concatenating FLACs is trivial, and not related to Matroska.

On Windows, fb2k can do 1.flac + 2.flac + 3.flac + ... = concatenated.flac on the fly, without manually decoding them to WAV, and the result is perfect (bit-identical when decoded). Audacity can do a similar thing, and the result is at least sample-accurate and practically acceptable.

Like @SeeMoreDigital said, appending them as WAV is the easiest and safest; you can just append WAV files and (re-)encode (in which case, you could optionally try .wv insteald of .flac, since .flac may be inconvenient in Matroska). If the audio is already in Matroska, you can first mkvextract. MKVToolNix is surely not an audio editor, and you're making things difficult by using it to concatenate audio files... or is this something different, directly related to Matroska? I hope you can do what you want to, anyway :)

[SeeMoreDigital]

Personally speaking...

Until we have more detailed information about each one of the source files Nejiro is trying to merge together, any recommendations are pointless :scared:

[Nejiro]

Sorry, I'm not sure what you're trying to do... Concatenating FLACs is trivial, and not related to Matroska.

On Windows, fb2k can do 1.flac + 2.flac + 3.flac + ... = concatenated.flac on the fly, without manually decoding them to WAV, and the result is perfect (bit-identical when decoded). Audacity can do a similar thing, and the result is at least sample-accurate and practically acceptable.

Like @SeeMoreDigital said, appending them as WAV is the easiest and safest; you can just append WAV files and (re-)encode (in which case, you could optionally try .wv insteald of .flac, since .flac may be inconvenient in Matroska). If the audio is already in Matroska, you can first mkvextract. MKVToolNix is surely not an audio editor, and you're making things difficult by using it to concatenate audio files... or is this something different, directly related to Matroska? I hope you can do what you want to, anyway :)

Somehow I will try to get by but you didn't understand, I don't have to merge single flac files but mkv where in addition to the various dts-hd etc there are also pcm tracks, the problem is that if I have three mkv files with audio dts, pcm, dd etc. .... I join them and they are well synchronized, then I extract the single pcm track to transform it into flac and then put it back in the mkv you lose the audio video synchronism, that's why I was trying to merge mkv with already flac tracks inside .. ... unfortunately it is difficult to explain but I will somehow try to fix it, for me it is fun. I would have had no problem and I would not have written here if mkvmerge had merged mkv with flac tracks but somehow I will, I like it when the things get complicated and I enjoy it more :)

[mood]

How to disable opening a file automatically on startup of mkvtoolnix-gui???

[Asmodian]

How to enable opening a file automatically on startup of mkvtoolnix-gui?

Mine does not open anything on startup. :confused:

[Mosu]

How to disable opening a file automatically on startup of mkvtoolnix-gui???

It really doesn't add any file by default. Yes, it does create empty multiplex settings, but that's all.

Maybe you're starting the GUI through a shortcut or batch file that adds an additional file name in the call?

[Nejiro]

Sorry for the stupid question but I can't understand how to do it, I have mkvs with the attachment inside (for example the cover of the film in jpg), how do you do if you want to download that jpg or png file etc ... in a nutshell how do i get the attachment only?

[Mosu]

Open your Matroska file in MKVToolNix GUI's "header editor" tool. Its tree view contains all attachments that exist in the file. Right-click on any of those in the tree view & select the "save" option from the context menu.

[Nejiro]

If you go the route you described, you can use the "delay" feature on the subtitle track in the first file when appending and use a ridiculous high negative value with it (its absolute value must be higher than the length of the first part). That way all entries from that first file (the ones you don't want to see) will end up with negative timestamps & will not actually be written to the output file.

Untested.
I did this test but if I put 10000 or -10000 the subtitles of the first track start immediately, maybe there is a maximum value in which you can not go?
Thanks

[Selur]

Hi Mosi,
I think about splitting a clip using:
mkvmerge -v -o "Path to output" -A -S -B -T -M --no-chapters --no-global-tags --split 1s "PATH to input"
Problem is I would like to know the number of output files before writing the output files.

Question is: Is there a way to basically simulate the above without acctually having to write the output?
Or is there another way to know the number of files that would get created without having to do the actual splitting?

Cu Selur

[Mosu]

Not really, no. You can probably approximate it by running your whole source file through "mkvinfo -s", taking all the video key frames & then guess from their timestamps. Problem is, as soon as you have two key frames that are within 1s from each other mkvmerge will not split before the second one as "--split 1s" means "split after a duration of at least 1s has been written". You'll also have to take frame duration into account.

All of that will not be reliable.

[Selur]

okay, thanks for clearing that up.

[Master Yoda]

Something I have been curious about and that's the delay option. Already read a number of posts, just asking this to be clear for me.

From my understading when you add a - or + delay to a subtitle the program changes the timestamps, same as if I shifted the times back or forth in subtitle edit. With audio from what I have read, a negative delay the program removes frames from the beginning. I assume it isn't re-encoding, just cutting some frames off. What about a positive delay? Change the timestamp, add blank frames to the beginning or just add a flag to tell the player to start then audio later?

With the audio, does the program do the same with all formats? ie, FLAC, Master Audio, TrueHD, AAC, etc....

[Mosu]

Positive delays will only be added to the timestamps. No silent (that's what you probably mean by "blank") frames will be generated; for none of the supported codecs. There will simply be no audio content at the start for a certain amount of time.

Different players deal with that differently, some well (by only playing the video at regular speed until the first audio frame is encountered), others not so much (e.g. by playing audio immediately & having the video speed up until both are synchronized again).

[vanden]

Hello,

I have video and I don't understand how they are muxed..
Transformers Dark of the Moon (2011) MULTi VFF 2160p 10bit 4KLight DOLBY VISION BluRay AC3 5.1 x265-QTZ.mkv

Opened in MPC I have this:
https://i.ibb.co/3kFMXmP/MPCHC1.jpg
Last frames around 2h25min59sec, the sound is perfectly synchronized with the video.

The problem is when I open it with MeGUI/AviSynth script creator (L-SMASH Works) I have this:
https://i.ibb.co/jbRnK2y/MeGUI1.jpg
Last frames 2h27min43sec.771 (224649)!

I then demux the HEVC track and the audio track with gMKVExtractGUI.exe, mux that with mkvtoolnix-gui.exe
https://i.ibb.co/TtCHYpq/g-MKVExtract-GUI.jpg
https://i.ibb.co/8DtGpXm/mkvtoolnix-gui.jpg
Opened in MPC I have this:
https://i.ibb.co/WgwtCvg/MPCHC2.jpg
The sound is shifted and the Last frame is at 2h27min43sec!

How is this hevc track muxed !! ??

[tebasuna51]

I have video..
Transformers Dark of the Moon (2011) MULTi VFF 2160p 10bit 4KLight DOLBY VISION BluRay AC3 5.1 x265-QTZ.mkv...
Please read the forum rules:
6) No warez, cracks, serials or illegally obtained copyrighted content! Links to content of a questionable nature (e.g. anything you don't own and/or have downloaded), asking for, offering, or asking for help/helping to process such content in any way or form is not tolerated.

We can't help you.

[Mosu]

Heyo!

The last couple of months have been pretty quiet regarding MKVToolNix as I'm still struggling to find time, motivation & energy for after-hour coding in general and work on MKVToolNix in particular. There are several topics on my TODO list that are rather big & require lots of work, e.g. improving Dolby Vision support further or implementing support for VVC/H.266. I'm therefore glad that some users posted a couple of bug reports & feature requests that turned out to be small enough for me to fix & implement quickly: sometimes such small wins are desperately needed.

But that's probably more than you wanted to know. Anyway, here's a new release with a couple of small improvements.

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 63.0.0 "Everything" 2021-11-14
New features and enhancements

mkvmerge: AC-3 parser: E-AC-3 with BSID values > 10 and ≤ 15 are recognized now, too. Implements #3211 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3211).
mkvmerge: when using language codes for track selection (e.g. "-a und,en") all tracks that do not have a language property (due to their container not providing one, e.g. AVIs) will be treated as if they did have one set to "und" ("undetermined") as that is the language the track will have in the Matroska file anyway. Before this change it wasn't possible to match such tracks via language codes.
MKVToolNix GUI: only on Windows: when compiled with Qt ≥ 5.14 and &lt; 6 (which is the case for the officially provided binaries) fractional screen scaling will be enabled. This means that the GUI will be scaled appropriately if Windows is set to 125%, 150% or 175% instead of being too small or too large. Implements #3043 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3043).
MKVToolNix GUI: the spinner in the bottom right corner will now be hidden when no jobs are currently running. Implements #3225 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3225).
MKVToolNix GUI: header editor: a new column has been added to the tree view showing the status of the "track enabled" flag. The information is also shown on the track overview page on the right. Implements #3228 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3228).
MKVToolNix GUI: header editor: users can now reorder tracks by dragging & dropping. Implements #3227 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3227).

Bug fixes

mkvmerge: AVI reader: fixed reading AVI files that contain "vprp" video properties header chunks; reading aborted too early. Fixes #3209 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3209).


Have fun! ☺

[SeeMoreDigital]

Many thanks Mosu....

The 'screen scaling' appears to be working well on my Dell laptop ;)

[tebasuna51]

...
mkvmerge: AC-3 parser: E-AC-3 with BSID values > 10 and ≤ 15 are recognized now, too. Implements #3211 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3211)...

Thanks Mosu.

[VBB]

Thank you!

[Perenista]

What is going on, this new MKVTOOLNIX version isn't working anymore when I click Start multiplexing. Did it broke? Clicking does nothing.

EDIT: It's fixed now. I had to restart Windows 11. Oddly it wasn't doing anything before that.

Is it here or the program looks smaller? I am using a 4K monitor@30 Hz and 175% (display scale).

[SeeMoreDigital]

Is it here or the program looks smaller? I am using a 4K monitor@30 Hz and 175% (display scale).
Maybe the following quote is relevant: -

Version 63.0.0 "Everything" 2021-11-14
MKVToolNix GUI: only on Windows: when compiled with Qt ≥ 5.14 and &lt; 6 (which is the case for the officially provided binaries) fractional screen scaling will be enabled.
This means that the GUI will be scaled appropriately if Windows is set to 125%, 150% or 175% instead of being too small or too large. Implements #3043.

[Mosu]

Is it here or the program looks smaller? I am using a 4K monitor@30 Hz and 175% (display scale).

Yes, the new version enables Qt's support for fractional scaling. Before the update Qt would use a scaling factor of 1 for 100%/125% and 2 for 150%/175%. This is obviously rather bad as the GUI would be too small in 125% and too large for 150%/175%.

[Liisachan]

How to disable opening a file automatically on startup of mkvtoolnix-gui??? If you mean a popup, automatically opening and telling you about available new versions, you can disable it by the settings.

@Mosu
Thanks a lot for v63. Though that problem was only cosmetic, High-DPI is finally working fine, it seems :)

-Possible, minor usablity enhancements (if it's easy to implement):
a) GUI Muxer: When the "Edit Language" box is opened, e.g. when you hit Alt+L: (1) if you select "Free-form input" say by Alt+F, the editbox below should be auto-focused so you're ready to type whatever immediately; (2) if you select "Individually..." say by Alt+I, "Language" should be auto-focused similarly.
b) Info Tool (GUI): it would be quicker and more convenient if you can just double-click on the item in the Content list — instead of selecting it, right-clicking it, and then selecting "Show hex dump" — to get the same result (showing hex dump). Since it's only one item in the right-click menu and it's not like you can select menu items, IMHO right-clicking to get that mini-popup menu won't be necessary.
(This Info Tool is very nice and education, btw, for studying the the internal. Thanks!)

-A possible technical (not-so-practically-important) issue:
Some 3-letter lang codes accepted in v59 are no longer accepted in v60+ (including the latest version v63). For example bic, bij, blg; of which bic & bij have been deprecated and so it may be justifiable not to accept them; `blg` however is not deprecated according to https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
While such a minor lang tag is seldom if ever used anyway, there may be subtle, more generic issues behind this.


D:\Apps\mkvtoolnix59>mkvmerge -o out.mka --language 0:blg in.ogg
...
Multiplexing took 1 second.

D:\Apps\mkvtoolnix63>mkvmerge -o out.mka --language 0:blg in.ogg
...
Error: 'blg' is not a valid IETF BCP 47/RFC 5646 language tag in '--language 0:blg'.

[Mosu]

I'll look into implementing your two proposed changes. They both sound reasonable.

About blg: I don't generate the language list from the subtag registry as the information in it is rather incomplete. Instead I use the official sources for the 639-* codes where possible, and Wikipedia for 639-5. I don't care enough to extend this to handle codes that are only present in the subtag registry as well.

`blg` however is not deprecated according to https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

You must have misread, it is very much deprecated:

%%
Type: language
Subtag: blg
Description: Balau
Added: 2009-07-29
Deprecated: 2021-02-20
Preferred-Value: iba

[Liisachan]

You must have misread, it is very much deprecated:

%%
Type: language
Subtag: blg
Description: Balau
Added: 2009-07-29
Deprecated: 2021-02-20
Preferred-Value: iba

You're right. I was accidentally looking at `blq' (which is not deprecated) instead of `bld`. Everything seems cool after all. Thanks!

[Mosu]

BTW, after thinking some more about your info tool request I will not implement it after all. Double-clicking in a tree view is a standard action that expands or collapses the node, not just in MKVToolNix, but in a lot of GUIs in general. I don't want to have one special tree view that behaves subtly differently.

[Liisachan]

Okay. It was just a minor suggestion, nothing really important.

[ctl-tx]

I've run into a UI issue with the new version. The icons on the sidebar are now outsized and push out of their allotted space. It should be a scaling issue because I run my primary display at 200% scale. Can't see anything at 4K otherwise.
I'll note that moving the window to my secondary display (which is at 100% scale) and restarting it there doesn't resize the outsized icons.

[Mosu]

Yeah, others have opened an issue (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3229) for it, too. I'll look into it.

[Nejiro]

Heyo!

improving Dolby Vision support


Thank you so much for your work on this exceptional program ..... about the dolby vision I wanted to know if I have a uhd bluray with dolby vision track I get the single track in dolby vision as with MkeMKV or always two tracks in which the 1080 one concerns the dolby vision? Because when I have bluray uhd with dolby vision I am forced to use MakeMKV to get the track compatible with my player ..... I hope that soon everything can be done with your program that I like much more than MakeMKV.
Thanks

[Mosu]

At the moment mkvmerge only supports reading single-layer DV when reading from MPEG transport streams (that's what's used on Blu-rays). See the status page (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status) for more info.

Both dual-layer in a single track as well as dual-layer in two separate tracks are currently not supported when reading from MPEG transport streams. The former will be easier to implement in MKVToolNix and will likely be done at some point, but I cannot give you an ETA on the latter. As you're talking about "two tracks" this means you're talking about dual-layer DV in two separate tracks, the thing currently not supported and without an ETA.

You're going to have to continue using MakeMKV for such discs at the moment.

[ctl-tx]

Yeah, others have opened an issue (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3229) for it, too. I'll look into it.

Yes, mine looks like that too.

[SeeMoreDigital]

At the moment mkvmerge only supports reading single-layer DV when reading from MPEG transport streams (that's what's used on Blu-rays). See the status page (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status) for more info.

Both dual-layer in a single track as well as dual-layer in two separate tracks are currently not supported when reading from MPEG transport streams....Perhaps it's the term 'reading' I find confusing as I've experienced no problems dragging and dropping 2-track Dolby Vision.m2ts files (as used on 4K UHD Blu-ray discs) into mkvmerge and creating 2-track Dolby Vision.mkv muxes. Admittedly, such .mkv contained muxes can't be played correctly, but they can be muxed.

https://i.ibb.co/CPdSNvT/Capture.png

More-over, it's possible to drag and drop these 2-track Dolby Vision.mkv muxes into TSmuxer GUI and generate 'fully compliant' 2-track Dolby Vision.m2ts (AVCHD Folder-set) muxes, which play perfectly in my OPPO UDP-203 hardware media player.

[Mosu]

I see your point. For me as the developer it's basically the same thing as I'll have to change a lot both on the output and the input sides in order to support dual-layer in two tracks; that's why I… well… chose to mention the side that doesn't work as it would have to first, which is the input side (reading).

[Nejiro]

At the moment mkvmerge only supports reading single-layer DV when reading from MPEG transport streams (that's what's used on Blu-rays). See the status page (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status) for more info.

Both dual-layer in a single track as well as dual-layer in two separate tracks are currently not supported when reading from MPEG transport streams. The former will be easier to implement in MKVToolNix and will likely be done at some point, but I cannot give you an ETA on the latter. As you're talking about "two tracks" this means you're talking about dual-layer DV in two separate tracks, the thing currently not supported and without an ETA.

You're going to have to continue using MakeMKV for such discs at the moment.
I'll post you a mediainfo example of how they are before making the single file with MakeMKV, practically MakeMKV merges these two files and makes a single one in Dolby Vision ....
Thanks

MPEG-H HEVC Video 70360 kbps 2160p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 1000nits / HDR10 / BT.2020
MPEG-H HEVC Video 7538 kbps (9.68%) 1080p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 1000nits / Dolby Vision FEL / BT.2020

[Mosu]

I know what I would have to do. A couple of smaller details are still somewhat unclear (e.g. what's the semantics of the first two bytes of the UNSPEC62/63 NALUs). It's just that it's quite a huge amount of work that I'm currently not willing to tackle.

[quietvoid]

I'd also love to help but just don't have the time nor knowledge of the codebase to do it right, it's intimidating to me. :)

In case you want to note it down, 62 are simply prepended by 0x7C01, and 63 by 0x7E01. 63 is then followed by the regular HEVC NALUs.
I don't think there's anything else special about them.

[Mosu]

Are those fixed values without any further meaning? I know that what follows are regular NALUs, I just haven't found any documentation about the two prefix bytes yet (I don't have the official Dolby Vision specs).

[quietvoid]

Yea they are fixed.
0x7C01 is supported by the x265 documentation: https://x265.readthedocs.io/en/master/cli.html#cmdoption-dolby-vision-profile

It's also mentioned in the patent (but that's not a spec).
https://i.postimg.cc/qhT27S0M/Untitled.png (https://postimg.cc/qhT27S0M)

As for the enhancement layer NALUs, I don't think there's any spec for it though.
There's a mention in this comment: https://trac.ffmpeg.org/ticket/5688#comment:2

And a thorough explanation here: https://forum.makemkv.com/forum/viewtopic.php?style=11&p=85231&sid=d3ba6d6cc3ec73f7a5fe6a9ecb89c65c#p85231

[Mosu]

That's great information, thanks. Now all that remains is… the actual work ��

[Megalith]

...at what point did dragging .txt files into MKVToolNix's Multiplexer no longer automatically generate chapters? I just realized that all of my recent muxes are missing chapters. WTF.

EDIT: Okay, there's clearly a a bug. If you drag a bunch of files with a .txt file in it, the .txt file isn't automatically added to the chapters section. But it is if you drag it separately/individually.

[Mosu]

Please open an issue for it over on Gitlab. Otherwise chances are I'll forget about it again. Thanks.

[von Suppé]

Hi Mosu

I demuxed a mkv that holds BL+EL+RPU (like makemkv creates them). Comparing them with MediaInfo, I notice that for the source mkv it says in the video-part
"HDR format: Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible"
Where for the demuxed hevc stream it says
"HDR format: SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible"

Would the "Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU"-part be information that can't be held in the elementary stream? Of course the demuxed .hevc stream holds BL+EL+RPU.

[Mosu]

The elementary stream can hold that information just fine. mkvextract simply doesn't support it properly yet (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status).

[quietvoid]

MediaInfo is only parsing the container for Dolby Vision, so that's why.
It parses the HDR10+ SEI though.

[von Suppé]

Thank you both. So, am I right when I say that:

1 makemkv writes the DV info in the container metadata
2 when using a DV mkv as input, mkvmerge will keep this DV info during a remux

[Mosu]

Thank you both. So, am I right when I say that:

1 makemkv writes the DV info in the container metadata
2 when using a DV mkv as input, mkvmerge will keep this DV info during a remux

Yes to both. mkvmerge can handle single-layer & dual-layer-in-same-track DV just fine when reading them from Matroska or MP4 files. It can also handle single-layer from other containers, including MPEG TS/elementary streams. It cannot handle dual-layer-in-different-tracks correctly (with which I mean converting them to dual-layer-in-single-track as the most compatible way to store this wrt. player support) from any of the containers.

[leon]

Is this a Qt bug?

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

[Mosu]

Probably?

[GAP]

What is good setup to convert lossless avi to lossless mkv?

[VoodooFX]

What is good setup to convert lossless avi to lossless mkv?
Windows 7 is good enough. Then drag & drop that avi to the MKVToolNix window and press start.

[Dogway]

I have been using an old mkvtoolnix version (8.2.0 from 2015) since then first due to the header compression issue, I tried again 2 years ago and found that mkvextract was demuxing out .avc elementary streams instead of .h264. What's the situation today? I tested latest version and still demuxed .avc streams which MP4Box doesn't work with nor it is an standard, or is it? Any info is welcome.

[von Suppé]

I tested latest version and still demuxed .avc streams which MP4Box doesn't work with nor it is an standard, or is it?Can't you solve this by changing the extension?

[Dogway]

Not that I remember. The thing is I don't know how the .avc format came to be since it always was .h264 or .264. I guess this has implications in the elementary stream header.

[Mosu]

There is no technical difference between what's in .avc/.h264/.264. It's all the same elementary stream format. There is only one elementary stream format; this is the one: a stream of NALUs following the ISO/IEC 14496-10 Annex B byte stream format (same as the ITU-T Rec. H.264 Annex B byte stream format). Furthermore, mkvextract doesn't actually decide on the file name, nor on the extension; it's totally up to the user what to name it. You could use ".chunkybacon" as an extension, it would still be the same elementary stream format.

AVC is the ISO name. H.264 is the ITU-T name. Both standard bodies cooperated on the work for the codec; they just have different names for the very same format & standard.

[Snowknight26]

Mosu, I uploaded a sample TS file with an MPEG-2 stream that mkvtoolnix doesn't seem to detect. MPEG2Repair shows no corrupt frames/bytes on the original (sample shows one corrupt frame due to it being split from the original at 18M bytes), though ffprobe indicates that at least one frame has an invalid frame dimension of 0x0, yet proceeds to correctly detect all streams. I haven't analyzed the container further but I imagine mkvtoolnix doesn't detect the MPEG-2 stream due to invalid parameters. Are you able to determine the reason mkvtoolnix doesn't detect it? It's not really a huge problem since I can recreate the container with ffmpeg but was curious nevertheless.

[Mosu]

Sorry, but I don't really want to have to deal with MPEG-2 anymore. I'm not going to look into it.

[SEALBoy]

Looking for some help.

I am using MKVToolnix GUI to take MKV files and remove prior embedded subtitles & unnecessary audio tracks, and embedding a single external SRT for subtitles. When I do this, it generates a new MKV file. This process can take some time since it is writing several GBs to the HDD.

Does it HAVE to duplicate the video stream into a new MKV file? Is it not possible to simply remove the embedded subtitles and audio tracks and add in the SRT subtitles I want into the existing file without rewriting it into a new file? Can this be done using the GUI?

[Mosu]

It does have to do it this way, yes, as all frames of all tracks are interleaved by their timestamps. This means that all frames of video, audio & subtitle tracks that should be played at timestamp X are located closely together in the file. Conversely this means that the frames of a single track (no matter its type) are distributed all over the file. Taking out those frames isn't possible, and putting others into their place (or rather: where they should be located according to their timestamps) doesn't work either.

[SEALBoy]

It does have to do it this way, yes, as all frames of all tracks are interleaved by their timestamps. This means that all frames of video, audio & subtitle tracks that should be played at timestamp X are located closely together in the file. Conversely this means that the frames of a single track (no matter its type) are distributed all over the file. Taking out those frames isn't possible, and putting others into their place (or rather: where they should be located according to their timestamps) doesn't work either.

:thanks: :goodpost:

[GAP]

Are there any differences between the 32 bit and 64 bit versions that I should know about?
How do you append files with re encoding?

[von Suppé]

2. AFAIK MKVToolNix doesn't re-encode. You can append files in the input window by rightclick on your sourcefile --> Append files

[Liisachan]

1. Function-wise, probably no. A file written by a 32-bit version will play fine on a 64-bit OS and vice versa. Generally speaking, though, a 64-bit version should be slightly more efficient when muxing.

Incidentally, which version you used to create your MKV will be recorded in that MKV itself, and publicly visible if you share your file. In case you want to author it anonymously, a 64-bit version (much commoner) may be better for anti-fingerprinting.

You could also spoof MuxingApp / WritingApp strings too, hiding not only the "bit-ness" (32 or 64) but the Mkvmerge version, though perhaps doing something like this is stupid & pointless; e.g.

@REM Lying about WritingApp, setting a random string
mkvpropedit.exe muxed.mkv --edit info --set "writing-application=Lavf65.43.210"

Edit
PS: If you really want to change the writing-application string, you should also add --disable-track-statistics-tags option when muxing; otherwise, _STATISTICS_WRITING_APP will reveal the original writing app.

[Mosu]

You could also spoof MuxingApp / WritingApp strings too, hiding not only the "bit-ness" (32 or 64) but the Mkvmerge version, though perhaps doing something like this is stupid & pointless; e.g.

In rare cases this might actually lead to problems. When reading Matroska files mkvmerge uses the writing app/muxing app strings to enable workarounds for certain bugs in certain versions of software. Luckily this hasn't been needed for quite a while now, so the chances are next to none of this being triggered accidentally. I just wanted to mention it for completeness' sake.

[tormento]

I have a variable framerate mkv file. As AVS doesn't support vfr, my idea was to export timestamp from matroska, encode the video assuming a fixed fps and then reapply the timestamp code.

Is there a way to export timestamp from the original mkv and apply to the final one?

[filler56789]

Is there a way to export timestamp from the original mkv and apply to the final one?

With mkvextract:

Timestamp extraction:
The sixth mode finds the timestamps of all blocks for a track and outputs a timestamp v2 file with these timestamps.

Example:

mkvextract "a movie.mkv" timestamps_v2 1:timestamps_track1.txt

[tormento]

With mkvextract
And that would give me the capability to "transform" a constant framerate encoded (as I can't see alternatives) in a variable one?

[filler56789]

And that would give me the capability to "transform" a constant framerate encoded (as I can't see alternatives) in a variable one?

Yes. mkvmerge can use a timestamp file for converting CFR to VFR.

https://forum.videohelp.com/attachments/62521-1640300358/toolnixgui-timestamps.png

[vrpatilisl]

hello, everybody, new update is very good. i have sony alfa 6300 camera also have shot some home videos with that.I want to append video files and creat one longer video file but don't want to lose any quality. i attach both filesmedia info txt here can anybody expert please go through it and let me know what i am losing if any?
thanks

please find TXT files in attachment.
:thanks:

[Mosu]

Hey everyone.

Hope y'all are having a couple of stress-free days behind & ahead of you, whatever you might or might not celebrate. I still haven't had much energy to invest into coding, to be honest, but decided to do one last release in 2021 anyway, mostly fixing a couple of smaller issues — especially the wrong-sized icons on high DPI displays, which I've gotten so many bug reports about 😁

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 64.0.0 "Willows" 2021-12-27
New features and enhancements

MKVToolNix GUI: language dialog: when the user switches between the two edit modes, the mode's corresponding first control is automatically focussed.

Bug fixes

all: language lists: the entries for "Ancient Greek (to 1453)" and "Modern Greek (1453-)" have been renamed to "Greek (ancient, -1453)" and "Greek (modern, 1453-)" respectively in order to be easier to find.
mkvmerge: VobSub reader: files containing "id: --" lines to indicate that the track language isn't known were rejected by "mkvmerge". Now they're accepted, and "und" (undetermined) is used as the language. Fixes #3246 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3246).
MKVToolNix GUI: chapter editor: the "Save to Matroska or WebM file" function was using the wrong standard file dialog (the "open file" one instead of "save"), leading to confusing button names. Fixes #3242 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3242).
MKVToolNix GUI: high DPI scaling: fixed the icons in the tool selector having the wrong size for scaling factors other than 100% or 200%. Fixes #3229 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3229).

Build system changes

The bundled "fmt" library was updated to v8.0.1.
The bundled "nlohmann-json" library was updated to v3.9.1.
The bundled "pugixml" library was updated to v1.11 revision 6a76cac.
The bundled "utf8-cpp" library was updated to v3.2 revision b85efd6.


Have fun 😁

[filler56789]

Thanks :thanks: for the endless updates :D

[videoh]

Thank you for high DPI support!

[SeeMoreDigital]

Wonderful job ;)

[VBB]

Thank you Moritz, and a happy 2022!

[tormento]

Yes. mkvmerge can use a timestamp file for converting CFR to VFR.
Thanks!

And how can I convert an existing vfr MP4 into a MKV?

[filler56789]

And how can I convert an existing vfr MP4 into a MKV?

mp4fpsmod?

mp4fpsmod 0.26
(libmp4v2 trunk-r507)
usage: mp4fpsmod [options] FILE
-o <file> Specify MP4 output filename.
-i, --inplace Edit in-place instead of creating a new file.
-p, --print <file> Output current timecodes into timecode-v2 format.
-t, --tcfile <file> Edit timecodes with timecode-v2 file.
-x, --optimize Optimize timecode
-r, --fps <nframes:fps>
Edit timecodes with the spec.
You can specify -r more than two times, to produce
VFR movie.
"nframes" is number of frames, which "fps" is
aplied to.
0 as nframes means "rest of the movie"
"fps" is a rational or integer.
For example, 25 or 30000/1001.
-c, --compress-dts Enable DTS compression.
-d, --delay <n> Delay audio by n millisecond.
-T, --timescale <keep|n>
keep: Keep original timescale.
n: Set timescale of videotrack to n.

[tormento]

mp4fpsmod
Wow, thanks.

[Mosu]

And how can I convert an existing vfr MP4 into a MKV?

Simply remuxing it with MKVToolNix should suffice.

[SeeMoreDigital]

Indeed...

[vanden]

Hello,

How to remux in MKVToolNix AVC + MVC (264 + mvc) ?
Is it possible ?

[Emulgator]

BD3D2MK3D does that:
https://forum.doom9.org/showthread.php?t=177317

[Mosu]

How to remux in MKVToolNix AVC + MVC (264 + mvc) ?

MakeMKV can do it, too, but MKVToolNix can only do so partially. If MVC stuff is already inside Matroska (e.g. a Matroska file created by MakeMKV), MKVToolNix can deal with it just fine. However, MKVToolNix cannot handle it in other containers, including M2TS which is used on Blu-rays.

[vanden]

@ Mosu : OK
My problem comes from the fact that blurays with several .siff files have been remuxed by tsMuxeR (1 single .siff file): Perfectly readable with Stereoscopic Player.
Bluray with several .siffs made by MakMKV (1 single .mkv file) remade in bluray with tsMuxeR (1 single .siff file).

In both cases, it is impossible to open the iso by MakMKV (https://forum.makemkv.com/forum/viewtopic.php?f=22&t=20692&sid=87c210da59a57270848d6423cb2bc8d4) ....

Bluray lend

@ Emulgator
I don't know how to remux 1 .264 file and 1 .mvc file, or remux 1 .siff or 2 .m2ts with BD3D2MK3D

[GAP]

I was trying to merge some split videos with different sizes in MKVToolnix only to that I cannot do that. How do you merge videos of different sizes together in MKVToolnix? Or should I use something else?

[filler56789]

I was trying to merge some split videos with different sizes in MKVToolnix only to that I cannot do that. How do you merge videos of different sizes together in MKVToolnix? Or should I use something else?

Please define "merge videos of different SIZES". :confused:
IF you mean "concatenate videos of different RESOLUTIONS" (frame dimensions),
then you'll need a different container
(namely, a transport stream, AFAIK).

[GAP]

What do you suggest I use to convert the files to a transport stream?

[filler56789]

@GAP — ffmpeg, OR concatenating with the old "copy /b" on the elementary streams, first, and tsMuxer, secondly.
YMMV.

[Nico8583]

Hi,
Is there a way to remove "Original source medium" and "ID in the original source medium" from a MKV when muxing ? I would like to remux a BD to MKV and I don't need these infos.
Thanks !

Edit : I just tried --disable-track-statistics-tags but it removes also some other tags like bitrate, stream size, etc...

I also tried --no-track-tags but same result.

The only workaround I found is to use "mkvpropedit.exe 'MyMovie.mkv' --delete-track-statistics-tags" then "mkvpropedit.exe 'MyMovie.mkv' --add-track-statistics-tags" but it requires an additional step and time.

[varekai]

Question about batch 10 mkv video files using MKVToolNix for deleting some audio and subtitle files.
For the life of me I can't remeber how to do this?
I'm shure I've done this before... or not...
Now I only get 1 big file combined of all 10 mkv's.
Any input on this is highly appreciated.

PS/
I know of a fine little app named MKV Muxing Batch GUI x64.v2.1 that'll do the job perfectly but I would like to use MKVToolNix.

[sneaker_ger]

1. Preferences->Multiplexer: Under "Adding files .." select either to always ask the user or to create a new multiplex for each file.
2. Preferences->Multiplexer->Enabling Items: set "Only enable copying of tracks with specific languages by default" and choose what you want to keep.
3. Add all your files, check if tracks are disabled like you want to
4. Multiplexer(not in preferences)->Actions for all tabs->Start multiplexing (or add to job queue and start it there)

[Mosu]

Heyo!

Here it is, the first release of 2022. This time I've worked a bit on implementing a handful of feature requests/enhancements. Have fun with them!

Nothing's changed for package managers.

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 65.0.0 "Too Much" 2022-02-06
New features and enhancements

mkvmerge: the options "--default-track" and "--forced-track" have been renamed to "--default-track-flag" and "--forced-display-flag" respectively for improved consistency with other option names & the wording used in the GUI. However, the old names will be supported and recognized indefinitely. What will remain unchanged is the property names for those flags in mkvmerge's identification output. Existing third-party programs will continue working as they are.
mkvmerge: added a new option "--track-enabled-flag" to set or unset the "track enabled" track header flag.
mkvmerge: MP4 reader: "mkvmerge" will now evaluate the "flags" field of the track header atom ("tkhd") and set the track's "enabled" flag accordingly. Implements #3272 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3272).
MKVToolNix GUI: multiplexer: added support for the "track enabled" track header flag.
MKVToolNix GUI: multiplexer, header editor: added several menu entries & keyboard shortcuts for toggling various track flags of the currently selected tracks, e.g. "Ctrl+Alt+F, D" (that's "Ctrl" and "Alt" with "F" simultaneously followed by "D" without any other key pressed) for toggling the "default track" flag. Part of the implementation of #3253 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3253).
MKVToolNix GUI: multiplexer, header editor: added menu entries & keyboard shortcuts for setting the language of the currently selected tracks to one from a configurable list of languages. The shortcuts used are "Ctrl+Alt+A, 1" through "Ctrl+Alt+A, 0" for the first ten entries of that list (that's "Ctrl" and "Alt" with "A" simultaneously followed by a digit without any other key pressed). Part of the implementation of #3253 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3253).
MKVToolNix GUI: chapter editor: if the user enters commas in start or end timestamps they will automatically be changed to points as the decimal separator, allowing for easier copy & paste from other programs/sources. Implements #3273 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3273).
MKVToolNix: header editor: the selected track or attached file can now be moved up & down with the keyboard shortcuts "Ctrl+Up" & "Ctrl+Down" respectively. Part of the implementation of #3253 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3253).

Bug fixes

mkvmerge: Matroska reader: DVB subtitle tracks with a codec private data size of more than five bytes are accepted now, too. Fixes #3258 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3258).


Have fun 😁

[VBB]

Thank you!

[varekai]

1. Preferences->Multiplexer: Under "Adding files .." select either to always ask the user or to create a new multiplex for each file.
2. Preferences->Multiplexer->Enabling Items: set "Only enable copying of tracks with specific languages by default" and choose what you want to keep.
3. Add all your files, check if tracks are disabled like you want to
4. Multiplexer(not in preferences)->Actions for all tabs->Start multiplexing (or add to job queue and start it there)
Thanks for the update and thanks for the input, much appreciated!
I recognize that tab settings, I thought I could do it from here and not tab by tab:
https://i.imgur.com/fa8x9Xj.png

[-QfG-]

I don't understand the "Disable Track" switch... If i don't need a track i will erase them.

[hubblec4]

I don't understand the "Disable Track" switch... If i don't need a track i will erase them.

Yeah, that's a matter of Matroska playback support.

Matroska supports more then "simple" audio/video/sub tracks,
and a Chapter-Codec could use such flags....

[derf]

Starting with MKVToolNix v65.0.0, some files will not show all audio tracks in MPC-HC, only the default track. Reverting to MKVToolNix v64.0.0, all audio track show in MPC-HC. All audio tracks are detected correctly in VLC or Plex.

EDIT:
Remuxing from mkv to mkv doesn't work, I have to take the original m4v from Handbrake with v64 so the audio tracks from the mkv are detected in MPC-HC.

[Mosu]

One notable thing that changed is that mkvmerge now maps the "enabled" track header flag from MP4 file's "tkhd" atom to Matroska's "track enabled" flag. So maybe those tracks were disabled in the source MP4 files already. You can override those flags in the GUI, of course; that's one of the reason I added the "disabled track flag" combobox in the first place.

If that isn't it, report the issue to the MPC-HC bug tracker, please.

[rco133]

Hi.

In version 65 when wanting to set the language I can no longer just hit TAB to get from "Track name" to language selection.

I used to just press TAB and space to get into the language selection menu.

Now, when I hit TAB it just jumps to "Default track flag" and skips the Language selection.

That is a bit annoying, since I now have to use the mouse to get into the "Language" menu.

Am I doing something wrong, or has the behaviour been changed on purpose?

rco133

[Mosu]

That's already been fixed (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3274).

[Liisachan]

Starting with MKVToolNix v65.0.0, some files will not show all audio tracks in MPC-HC, only the default track. Reverting to MKVToolNix v64.0.0, all audio track show in MPC-HC. All audio tracks are detected correctly in VLC or Plex.

EDIT:
Remuxing from mkv to mkv doesn't work, I have to take the original m4v from Handbrake with v64 so the audio tracks from the mkv are detected in MPC-HC.

Perhaps the following is unrelated to your issue, but apparently similar problems are also happening due to LAV Filter-side issues. So, if someone has a problem where MPC-HC doesn't show all the audio tracks, various possibilities should be considered. The issue reported at https://forum.doom9.org/showthread.php?p=1963574#post1963574 on 2022-02-09 is:
If I have a *.MKV Video-File with a lot different audio-tracks the media player doesn't offer me to choose between all of them in the Audio Track selection
and clsid's comment is:
this issue is that one audio track isn't recognized by the splitter. He needs to go to the LAV Filters thread for help with that.

So, according to clsid, sometimes this kind of issue is not (directly) related to MKVToolNix nor to MPC-HC itself. I figured maybe I should share this info.

[nevcairiel]

One notable thing that changed is that mkvmerge now maps the "enabled" track header flag from MP4 file's "tkhd" atom to Matroska's "track enabled" flag. So maybe those tracks were disabled in the source MP4 files already. You can override those flags in the GUI, of course; that's one of the reason I added the "disabled track flag" combobox in the first place.

That seems to be the most likely case to me - thats really the only reason a MKV audio track would not be shown, if its set to Disabled.

Although I believe the MP4 "enabled" semantic is a bit different to the one in MKV, it seems to more closely correspond to MKV "default", and not intended to suppress tracks entirely, like MKV seems to specify the flag.

[Mosu]

Although I believe the MP4 "enabled" semantic is a bit different to the one in MKV, it seems to more closely correspond to MKV "default", and not intended to suppress tracks entirely, like MKV seems to specify the flag.

I am aware of this, or rather of ffmpeg mapping the flag to their "default track" equivalent. But then I took a look at ISO/IEC 14496-12:2015 and their verbiage is pretty unambiguous in 8.3.2.3:

Track_enabled: Indicates that the track is enabled. Flag value is 0x000001. A disabled track (the low bit is zero) is treated as if it were not present.

One might even argue that remuxing should simply skip such tracks, but I don't think this would be in the best interest of the user, and those flags are usually tailored towards the playback programs, not the remuxers/authoring programs.

[nevcairiel]

I see, that does look rather unambiguous, I didn't have the spec in front of me right now. I suppose people will need to take a bit more care in the future when remuxing.

[Nico8583]

Hi,
Does MKVToolNix support multi-angles Blu ray sources ? And how to proceed ?
Thanks !

[Mosu]

Not really, no.

[Nico8583]

Not really, no.
Thanks, is there a way to just show angles in mkvtoolnix ? Or is there a workaround to deal with angles before mkvtoolnix ? Thanks !

[hubblec4]

chapterEditor is extra designed for multi Angle/Edition support to help MTX to process such discs.

[Nico8583]

chapterEditor is extra designed for multi Angle/Edition support to help MTX to process such discs.
Thanks ! I don't need to keep all angles, just need to know if there is a multi angle and keep one of them. Is chapterEditor can do that ? And is it possible to do that and let mkvmerge do the MPLS to MKV muxing ? Thanks.

[hubblec4]

with cE you can preserve all Angles or only one, like you want.

All can be muxed directly in/with cE OR you can load all the settings to MTX. cE creates a settings file which can be load in MTX and then you have all settings in MTX.

[Nico8583]

Perfect, I'll try it ! Thanks

[Liisachan]

An odd (?) behavior of
mkvextract video.mkv timestamps_v2 0:timestamps.txt
Tested with several 24000/1001 fps videos. Let's say I have a video with only 5 frames. The folloing is expected (or not?):
# timestamp format v2
0
42
83
125
167
209
But mkvextract writes 208.708333 instead of 209. If it wants to be accurate, the number should be 208.541667, so the "708333" part doesn't make sense.

Similarly, if MKV is created with --timestamp-scale 100000, then mkvextract says:
0
41.7
83.4
125.1
166.8
208.508333
The last number seems odd (208.5 is expected, or not?).

The above is, however, a minor detail, perhaps almost harmless. The real problem that my friend and I are trying to solve is, sometimes mkvmerge makes the first frame non-0. For example:
# timestamp format v2
21
63
105
146 This may happen when the source is MP4, and I'm guessing that such an MP4 video file already has ~21ms offset for some reason (i.e. the first frame is ~21ms after the first audio sample), and mkvmerge is simply copying the timestamps from MP4... So this is probably not an MKV-side issue, but does anyone have any idea why such a strange MP4 file is written by ffmpeg (where the first frame is not 0:00.000)?

[Liisachan]

On Windows (at least), both 32- and 64-bit, mkvmerge rounds down the video frame timestamps with the fraction part ~0.54, like this:

Conditions:
- ntsc_film i.e. 24000/1001 fps CFR
- Frame# >= 31253, and ≡ 5 (mod 24)
- Input is .264 file (and not .mp4 file) written by x264.exe

First problem frame:
Frame 31253 (0:21:43.510 541 667) =
1303510.541667 ms
1303511 is expected
1303510 is used by mkvmerge.

The following mux-time option doesn't change this behavior:
--default-duration 0:24000/1001p --fix-bitstream-timing-information 0:1

Edit: This might be a problem of x264.exe ... because this does not happen when transmuxing from xvid.avi, but happens when reading x264.264. How can I check timestamps in .264 file?

Edit2: One thing I can reproduce consistently is, mkvmerge rounds down the fraction 0.5, for each "12 mod 24" frame.

Edit3: It seems that timestamps are as expected if input is video.mp4. Either the .264 write of x264 or the .264 parser of mkvmerge may be strange.

[Snowknight26]

There seems to be a bug in the track selection section of the Input pane in the multiplexer.

If you highlight a track/chapter/tag by clicking on the row corresponding to the item, while the item is highlighted, double clicking the checkbox causes the checkbox state to be changed 3 times. Once on the initial click, once on the 2nd click's mouse down, and a 3rd time on the click's mouse up.

Easy way to see it if you have multiple tracks:

Select the first track
Double click the left-most checkbox (the 'Copy this item' checkbox) of the 2nd track
The 2nd track's state correctly toggles twice (since you double clicked) but the first also track toggles once because it's highlighted

[Mosu]

Double clicks are handled the same way as pressing return; they act on all selected tracks. The checkboxes on the left are only visual indicators, not actual checkboxes. So whatever the current behavior is, it is going to stay that way.

[Snowknight26]

Double clicks are handled the same way as pressing return

They aren't though. The 2nd click of the double click causes the checkbox state to be toggled up to twice, once on mouse down, once on mouse up. Pressing enter only causes the checkbox state to be toggled once. Double clicking causes it to be toggled up to 3 times.

Video of reproduction steps, with a mouse intercept hook showing you exactly what state the mouse is in:
https://www.stfcc.org/misc/2022-02-23_07-57-09.mp4

Ran through several different scenarios, in this order:

Single clicking checkbox of a when no item is highlighted
Double clicking checkbox of a when no item is highlighted
Double clicking checkbox of the only item that's highlighted (did this twice)
Pressed up key to change highlighted item
Double clicking checkbox of a non-highlighted item (did this 3x)

[Mosu]

To be quite honest… I don't really care. I only register signal handlers for Qt's signals of "entry double cliked" and "return pressed" and do the same action in both cases. Everything else, including the management of which entry gets (de-)selected when or which click events are actually triggered, is handled by Qt, and I have no control over that.

[Snowknight26]

To be quite honest… I don't really care.

Likewise, so no hard feelings. ;) At least it's now documented for any pour soul that notices this quirk.

[shae]

In muxes where the audio is longer than video, splitting on video length doesn't seem to do anything.
A roundabout way, that sometimes works, is to append more video to the "real" video. But that doesn't always help.

Instead of all that, would it be possible to add a "cut to video stream length" option?

VVVV VVVV
aaaaaa -> aaaa

[Mosu]

Due to how many container types work, knowing which video packet is the last packet while it is processed is rather difficult to achieve and would require substantial buffering of content & for that substantial rewrites of the program. I won't spend time on that.

[hubblec4]

In muxes where the audio is longer than video, splitting on video length doesn't seem to do anything.
A roundabout way, that sometimes works, is to append more video to the "real" video. But that doesn't always help.

Instead of all that, would it be possible to add a "cut to video stream length" option?

VVVV VVVV
aaaaaa -> aaaa

Yeah, and that's the reason why you don't should cut and/or append mkv's.

[shae]

knowing which video packet is the last

Thanks for all the MKV tools!

Isn't it a matter of "no more video frames, stop here and truncate any pre-buffered audio"?

If not that, any way to get manual splitting to work when setting to split after frame == number_of_frames_in_video?

If not that, any way to get back the ability to append video to self (to pad length, which seems needed for splitting to work)?
Older versions allowed that, new ones seemingly disallow the same video file twice.

Yeah, and that's the reason why you don't should cut and/or append mkv's.
What do you mean?

The specific goal here is to truncate audio. I encountered it in some Bluray M2TS files.

[Mosu]

Isn't it a matter of "no more video frames, stop here and truncate any pre-buffered audio"?

Again, there's no way to know that there won't be any more video frames unless mkvmerge is completely done processing everything. This can mean that it would have to buffer gigabytes of other data in certain cases, potentially spanning reading multiple appended files and other structures, also affecting all other content generated in the meantime (e.g. chapters). Would that happen often? No. Would I have to implement all the code for that anyway? Yes, I would. There are no real shortcuts for me to take; it would take a huge amount of work.

If not that, any way to get manual splitting to work when setting to split after frame == number_of_frames_in_video?

Same problem; the program would have to know for certain that there will not be any more frames for that track coming. So no, no way.

If not that, any way to get back the ability to append video to self (to pad length, which seems needed for splitting to work)? Older versions allowed that, new ones seemingly disallow the same video file twice.

Not sure what you're referring to, but you can use the same file name as source files as often as you want. Yes, you can append it to itself by listing it twice (e.g. "mkvmerge -o out.mkv in.mp4 + in.mp4").

[Mosu]

On Windows (at least), both 32- and 64-bit, mkvmerge rounds down the video frame timestamps with the fraction part ~0.54, like this:

Liisachan, I'm not really replying to you not because I'm willfully ignoring you or because I've overlooked your posts, but because I simply don't want to deal with rounding issues. Those are some of the most excruciating issues to fix, and I simply lack the motivation & energy to tackle those. I postponed replying a bit, hoping I'd find the energy to look into it, but I just… haven't. I'm sorry.

[shae]

If not that, any way to get manual splitting to work when setting to split after frame == number_of_frames_in_video?

the program would have to know for certain that there will not be any more frames for that track coming. So no, no way.
There are currently options to split after frame or time. I did get split-after-frame to work at least once (which required the video to be append-padded). Under what circumstances is it supposed to work, and when is it supposed not to work?

Not sure what you're referring to, but you can use the same file name as source files as often as you want.
It was in the GUI. Will check again. I tried recently, but after the popup asking whether to append/start a new mux/etc., choosing "append" lead to no visible action; the file didn't appear as a child in the source list.

[ProWo]

I wrote a simple GUI for mkvalidator (for Windows only). It needs .net 4.8.
It works with any CPU.
You can download it here
https://files.videohelp.com/u/292773/mkvalidator-gui_120.7z
Enjoy

NB March 7, 2022 update to v1.2.0

[oniiz86]

I was wondering if anyone may know the technical reason why TrueHD & Dolby Digital Plus with Atmos causes intermittent subtle motion jerkiness when muxed with MKVToolNix on OPPO's BDP-10X players but when remuxed using @ProWo's superb "Clever FFmpeg-GUI" program there are no such motion issues, does it have to do with the LAV filters during the encoding process?

These same files with TrueHD & DDP/Atmos are fine when played on OPPO's UDP-20X players when muxed with MKVToolNix so obviously it is not the program, so it must be an unusual quirk of the earlier MediaTek MT8580 SoC in the BDP-10X players, first I thought it was a variable bit-rate issue with TrueHD but DDP/Atmos being constant bit-rate squashed that idea, what would the LAV filters be doing differently to what MKVToolNix is using?

[Klaus1189]

Upload two short sample output files on google drive or similar and we can compare them precisely.

[oniiz86]

@Klaus1189 This is the MKVToolNix sample https://ufile.io/qrd01dyt which for some strange reason has had its frame rate changed from 24000/1001 to 23976/1000, it is only a short 20 second clip but the motion jerkiness should be apparent at several points as it pans from left to right across the fence & also the kids running in the background tend to have some motion skipping too.

The sample https://ufile.io/r2u6z4ft made with ProWo's clever FFmpeg-GUI does not exhibit any motion jerkiness at all & has not had its frame rate changed, remains at 24000/1001.

The secondary lossy DD 5.1 track plays fine on both files, not sure why the TrueHD track is being problematic only when muxed with MKVToolNix.

Is it a case of the LAV filters are more forgiving in terms of the player's MTK SoC not strictly adhering to the Matroska spec vs MKVToolNix's libebml + libmatroska encoding process handles it more strictly to provide overall better spec compliant muxes?

Most owners should see the issue with the first sample if they have any of the following, OPPO's BDP-103/105(D), Cambridge Audio 752BD/CXU & Pioneer BDP-LX58/88 players.

[von Suppé]

This is the MKVToolNix sample https://ufile.io/qrd01dyt which for some strange reason has had its frame rate changed from 24000/1001 to 23976/1000.
I suspect this framerate change being introduced way earlier than when remuxing with MKVToolnix. Incorrect timecodes can be set during a flawed recode (the mkv's obviously are recodes) of 24000/1001 source. Where the exact 23.976 value is used as framerate instead of using the 24000/1001 fraction. As I understand ffmpeg always rewrites timecodes during mux, it could be the difference here.
If I'm right with this, MKVToolnix could be able to solve this for AVC by setting FPS to 24000/1001p and checking "Fix bitstream timing info" before muxing.

Additionally, I can imagine different playback results because of different players honouring container framerate or videostream framerate.

[oniiz86]

I suspect this framerate change being introduced way earlier than when remuxing with MKVToolnix. Incorrect timecodes can be set during a flawed recode (the mkv's obviously are recodes) of 24000/1001 source. Where the exact 23.976 value is used as framerate instead of using the 24000/1001 fraction. As I understand ffmpeg always rewrites timecodes during mux, it could be the difference here.
If I'm right with this, MKVToolnix could be able to solve this for AVC by setting FPS to 24000/1001p and checking "Fix bitstream timing info" before muxing.

Additionally, I can imagine different playback results because of different players honouring container framerate or videostream framerate.

The file is 24000/1001 but only when I used the splitting option "Parts by Timestamps" did it then change to 23976/1000, it mentions Original Frame Rate 24000/1001 & Frame Rate 23976/1000 according to MediaInfo but like I said when the sample was remuxed using @ProWo's Clever ffmpeg-GUI it shows correctly as 24000/1001.

I did try setting FPS to 24000/1001p & checking "Fix bitstream timing info" but it made no difference, I understand playback results will differ across different players but in this instance it seems to be MKVToolNix causing this difference with intermittent motion jerkiness on my OPPO BDP-105D that Clever ffmpeg-GUI does not.

[von Suppé]

I understand your post. For my own sanity I chopped several "real" 24/1001 mkv files to smithereens, all parts came out correctly showing 24/1001. I just can't imagine that MKVToolnix would introduce the exact 23.976 value out of nowhere.

I imported the "sample https://ufile.io/r2u6z4ft made with ProWo's clever FFmpeg-GUI" into MKVToolnix and did a clean full remux (no cutting). MediaInfo states on that result:

Frame rate: 23.976 (23976/1000) FPS
Original frame rate: 23.976 (24000/1001) FPS

Again, I don't think MKVToolnix grasps the 23976/1000 out of thin air. I'd still think there's something not 100% correct with the sourcefile you created these two samples with. BTW their elementary videostreams show bit-equal. Maybe flawed container metada is inherited?

I also demuxed the clever ffmpeg mkv into elementary streams, which I imported in MKVtoolnix for a clean remux. MediaInfo does not show 23976/1000 anywhere.
To me, this also would confirm that there's something in the source container that makes the difference.

[hubblec4]

Hi Mosu

Is there a way to force mkvmerge to write CRC32 elements?

[Mosu]

Neither of my tools currently supports CRC elements, mostly for actual technical issue with libebml. So the answer is no, unfortunately.

[hubblec4]

OK.
And no support means "only writing" or also reading?

In MkInfo tool I can see an entry called Adler-32, this has nothing to do with CRC32?

[Mosu]

Neither mkvmerge nor mkvpropedit can write them, and almost none of the tools can read them. mkvinfo has very, very limited support for displaying a CRC element's value without actually validating it, but as far as I remember there are situations in which libebml does some CRC handling internally without actually reporting the elements to the calling applications, meaning mkvinfo might not even show the element's presence.

Adler-32 checksums have nothing to do with CRC32 elements. Adler-32 checksums are calculated on the fly and are solely intended to be used for us humans to compare elements between different files (e.g. in order to be able to determine if CodecPrivate elements of two video tracks in different files are actually identical).

[oniiz86]

I understand your post. For my own sanity I chopped several "real" 24/1001 mkv files to smithereens, all parts came out correctly showing 24/1001. I just can't imagine that MKVToolnix would introduce the exact 23.976 value out of nowhere.

I imported the "sample https://ufile.io/r2u6z4ft made with ProWo's clever FFmpeg-GUI" into MKVToolnix and did a clean full remux (no cutting). MediaInfo states on that result:

Frame rate: 23.976 (23976/1000) FPS
Original frame rate: 23.976 (24000/1001) FPS

Again, I don't think MKVToolnix grasps the 23976/1000 out of thin air. I'd still think there's something not 100% correct with the sourcefile you created these two samples with. BTW their elementary videostreams show bit-equal. Maybe flawed container metada is inherited?

I also demuxed the clever ffmpeg mkv into elementary streams, which I imported in MKVtoolnix for a clean remux. MediaInfo does not show 23976/1000 anywhere.
To me, this also would confirm that there's something in the source container that makes the difference.

Do you think you know how the container may be causing this difference? It is very odd that the frame rate would change like that, I thought it may have been a certain audio track causing this issue because the split file has a duration of 23 secs but the duration should be 17 secs, I chose 00:16:23-00:16:40, I tried with other files that had TrueHD tracks & there was no altered frame rate from 24000/1001 to 23976/1000 & the split file was the exact duration, I just noticed the sample I've uploaded has different audio track lengths, the AC-3 track being slightly longer at 17ms, any reason why?

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 23 s 24 ms
Bit rate : 23.4 Mb/s
Width : 1 920 pixels
Height : 816 pixels
Display aspect ratio : 2.35:1
Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.624
Stream size : 64.3 MiB (86%)
Default : Yes
Forced : No

Audio #1
ID : 2
Format : MLP FBA
Format/Info : Meridian Lossless Packing FBA
Commercial name : Dolby TrueHD
Codec ID : A_TRUEHD
Duration : 23 s 23 ms
Bit rate mode : Variable
Bit rate : 3 154 kb/s
Maximum bit rate : 4 470 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 1 ms
Stream size : 8.66 MiB (12%)
Title : TrueHD 7.1
Language : English
Default : Yes
Forced : No

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 23 s 40 ms
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Delay relative to video : 12 ms
Stream size : 1.76 MiB (2%)
Title : AC-3 5.1
Language : English
Service kind : Complete Main
Default : No
Forced : No

[von Suppé]

First off, I think that files with wrong metadata can cause duration discrepancies, even without chopping them into smaller parts. Can't prove it though; my knowledge simply is too limited. Therefor I also don't know what metadata would be inherited to make MKVToolnix files framerate show up as 23976/1000.
To me it would seem unlikely that some corrupt audiotrack could affect video framerate. But, never say never.
Hopefully Mosu can tell us more about all this.

As to 23976/1000 framerate, I've always been suspicious. I wouldn't know what source would have this natively. As I mentioned earlier, very often the video turned out to be a recode where the exact value was set instead of using the 24000/1001 fraction. Where, eventhough MKVToolnix has the ability to "Fix bitstream timing info" for AVC, often the ultimate fix meant taking the video out of its container and change framerate of the ES.

[Liisachan]

Okay, more info to share with other users (Not a bug report). ffmpeg may have some issues too (we're still studying), but MKVToolNix is somewhat strange, in the following way.

Can anyone reproduce this strangeness?

1. Prepare a sample NTSC (24000/1001 fps) video with many frames (for me more than 31253 frames) as AVS, say, test.avs like this:


BlankClip(length=31800, width=640, height=4800, fps=24000, fps_denominator=1001, pixel_type="YV12")
KillAudio()


2. Encode it as MP4 (or MKV) with x264.


x264 --fps 24000/1001 -o x264-video.mkv "test.avs"


3. Mux it as MKV with mkvmerge. Timestamps in MKV are *GOOD* at this point:


mkvmerge -o mkvmerge.mkv "x264-video.mp4"
mkvextract "mkvmerge.mkv" timestamps_v2 0:good-timestamps.txt


4. Extract .264 and remux. Then, timestamps become bad:


mkvextract "mkvmerge.mkv" tracks 0:mkvextract.264
mkvmerge -o remuxed.mkv "mkvextract.264"
mkvextract "remuxed.mkv" timestamps_v2 0:bad-timestamps.txt


Bad how? For example Frame 31253 = 31253*1001*1000/24000 = 1303510.541666... ms (0:21:43.510541666) should be 1303511 if rounded, when the default timestamp format is used. Indeed good-timestamps.txt has 1303511; bad-timestamps.txt instead has 1303510, rounded down 0.54...; this fraction 0.54.. is always rounded DOWN in frame 5 mod 24 >= 31253. This is a bigger problem, causing subtitle-off-by-one-frame problems in some edge cases.

Solution for end-users: try not to let MKVToolNix do math about 24000/1001. Several other tools, e.g. AviSynth, x264 / Haali Matroska Writer b0, or even old AVI format, can handle a rational fps. MKVToolNix tends to break good timestamps, and once broken it's generally hard to fix them using MKVToolnix itself, except one can manually do --timestamps "0:good.txt" frame by frame. MKV is more flexible than CFR-only formats, at the cost that it can't handle CFR intrinsically, every MKV technically being VFR for MKV.

So, we can just use a tool that supports a rational FPS, and just let Mkvmerge COPY timestamps. Don't let it calculate them.

Solution for coders: when handling a rational number divide last. 31253*1001*1000/24000 instead of 31253*(1001/24000)*1000

PS: A smaller problem (not important) just fyi: a theoretical exact-0.5 ms fraction (every ntsc frame 12 mod 24 has it) is rounded DOWN if MkvToolNix does math. The tool doesn't support a rational fps by design. E.g. --default-duration 0:24000/1001p is approximated by integer, --default-duration 0:41708333ns, the tool unable to handle a rational number, not supporting round(rational) in this context. This is probably by design, not a bug. Rounding down 0.54... is still not good, counter-intuitive, nevertheless. A dirty workaround is, use
0:41708334ns i.e. 2/3 ns too large
instead of
0:41708333ns i.e. 1/3 ns too small

[oniiz86]

First off, I think that files with wrong metadata can cause duration discrepancies, even without chopping them into smaller parts. Can't prove it though; my knowledge simply is too limited. Therefor I also don't know what metadata would be inherited to make MKVToolnix files framerate show up as 23976/1000.
To me it would seem unlikely that some corrupt audiotrack could affect video framerate. But, never say never.
Hopefully Mosu can tell us more about all this.

As to 23976/1000 framerate, I've always been suspicious. I wouldn't know what source would have this natively. As I mentioned earlier, very often the video turned out to be a recode where the exact value was set instead of using the 24000/1001 fraction. Where, eventhough MKVToolnix has the ability to "Fix bitstream timing info" for AVC, often the ultimate fix meant taking the video out of its container and change framerate of the ES.

This file is explicitly set to 24000/1001, it's an odd one for sure why MKVToolNix is reporting it as 23976/1000 in split mode, the elementary AVC stream seems to be fine as clever ffmpeg-gui identifies it correctly, if the AVC stream were corrupted would it not matter which program was used to create the mux encode, what makes the LAV filters so special as to not cause any intermittent motion jerkiness on my OPPO player, what exactly is MKVToolNix's libebml + libmatroska doing differently during the encoding process to have an effect on the motion playback on certain MediaTek SoC players?

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 30 min
Width : 1 920 pixels
Height : 816 pixels
Display aspect ratio : 2.35:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 157 r2932 303c484
Encoding settings : cabac=1 / ref=5 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.10:0.00 / mixed_ref=1 / me_range=48 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=25 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=crf / mbtree=0 / crf=17.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.30 / pb_ratio=1.20 / aq=3:0.75
Default : Yes
Forced : No
FromStats_BitRate : 20275985
FromStats_Duration : 01:30:56.451000000
FromStats_FrameCount : 130824
FromStats_StreamSize : 13829365409

Audio #1
ID : 2
Format : MLP FBA
Format/Info : Meridian Lossless Packing FBA
Commercial name : Dolby TrueHD
Codec ID : A_TRUEHD
Duration : 1 h 30 min
Bit rate mode : Variable
Maximum bit rate : 4 470 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Title : TrueHD 7.1
Language : English
Default : Yes
Forced : No
FromStats_BitRate : 2967497
FromStats_Duration : 01:30:56.452000000
FromStats_FrameCount : 6547742
FromStats_StreamSize : 2024001148

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 1 h 30 min
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 416 MiB (3%)
Title : AC-3 5.1
Language : English
Service kind : Complete Main
Default : No
Forced : No
FromStats_BitRate : 640000
FromStats_Duration : 01:30:56.480000000
FromStats_FrameCount : 170515
FromStats_StreamSize : 436518400

[Liisachan]

A Matroska file does not work that way, not directly supporting any fixed frame rate at all. Instead, each frame has its timestamp (by default, the unit is 0.001 second = 1 millisecond aka 1 ms). A typical example is:

Frame 0 = time 0
Frame 1 = time 42 (fps between Frame 0 and 1 is 1000/42 = 23.809...)
Frame 2 = time 83 (fps between Frame 1 and 2 is 1000/41 = 24.390...)
Frame 3 = time 125 (fps between Frame 2 and 2 is 1000/42 = 23.809...) and so on.

There is also a per-track metadata called DefaultDuration, which might be 41708333 ns (41.708333 ms; ~23.976024168 fps), when an info tool can guess the source video is NTSC (24000/1001 fps) and may show an approximate value of it (e.g. 24 fps, 23.9760 fps, etc.); but it is only the default value. Since each frame has its own timestamp explicitly, this default value is basically irrelevant and unnecessary and generally not used, except maybe when calculating the end time of the very last frame.

This system may look confusing and (in specific cases) indeed it can be inconvenient, yet it is much more flexible this way, since one can use a variable frame rate (VFR) easily. That is how Matroska works. It is a feature - a design decision.

See also: https://matroska.org/technical/notes.html#timestampscale-rounding

@hubblec4
There are some tools that do write ebml CRCs (and there is a tool that can verify it), but like Mosu said, mkvmerge doesn't do that. To make sure the file is not corrupted after years, one can record the hash value of the file. An "insecure" hash like MD5 is enough for this purpose. If you're worried that an accidental writing error might occur when muxing, then you can simply mux twice with --deterministic and check the 2 files are bit-identical :)

[oniiz86]

A Matroska file does not work that way, not directly supporting any fixed frame rate at all. Instead, each frame has its timestamp (by default, the unit is 0.001 second = 1 millisecond aka 1 ms). A typical example is:

Frame 0 = time 0
Frame 1 = time 42 (fps between Frame 0 and 1 is 1000/42 = 23.809...)
Frame 2 = time 83 (fps between Frame 1 and 2 is 1000/41 = 24.390...)
Frame 3 = time 125 (fps between Frame 2 and 2 is 1000/42 = 23.809...) and so on.

There is also a per-track metadata called DefaultDuration, which might be 41708333 ns (41.708333 ms; ~23.976024168 fps), when an info tool can guess the source video is NTSC (24000/1001 fps) and may show an approximate value of it (e.g. 24 fps, 23.9760 fps, etc.); but it is only the default value. Since each frame has its own timestamp explicitly, this default value is basically irrelevant and unnecessary and generally not used, except maybe when calculating the end time of the very last frame.

This system may look confusing and (in specific cases) indeed it can be inconvenient, yet it is much more flexible this way, since one can use a variable frame rate (VFR) easily. That is how Matroska works. It is a feature - a design decision.

See also: https://matroska.org/technical/notes.html#timestampscale-rounding


@Liisachan Thanks for that, I noticed the DefaultDuration in the Header Editor section & it states 41708333 for 24000/1001 & I heard 41708375 is 23976/1000 but even files with 23976/1000 still have the DefaultDuration listed as 41708333 so not sure why the Header Editor does not reflect the small 42 ns difference, perhaps you may know why MKVToolNix's libebml + libmatroska is causing intermittent motion jerkiness where @ProWo's clever ffmpeg-gui program does not on my OPPO BDP-105D player, only TrueHD & E-AC3 JOC streams seem to be affected?

[shae]

Any idea what might make the GUI reject some or most Bluray MPLS files, even though they dump fine with bluray_dump and are also accepted by the Chapter Editor?

The rejected MPLS don't show up when opening the Bluray root (the window that shows the available playlists), nor are they accepted when dropped into the Multiplexer tab, where the GUI says (* = filename dropped):
The file '*.mpls' was not recognized as a supported format (exit code: 0).

[Liisachan]

@Liisachan Thanks for that, I noticed the DefaultDuration in the Header Editor section & it states 41708333 for 24000/1001 & I heard 41708375 is 23976/1000 but even files with 23976/1000 still have the DefaultDuration listed as 41708333 so not sure why the Header Editor does not reflect the small 42 ns difference Do you know the exact command line you're using via your GUI? If it has
--default-duration 0:24000/1001p
then, mkvmerge may set 41708333. While I have no idea why you're having problems with mkvmerge, by comparing the 2 command lines (one that works for you, and the other one that doesn't work well), perhaps you can guess what causes the difference for your specific player. This may be a player-side issue - MKV file written by mkvmerge is most probably well-formed.

(Mkvmerge is not as good at rounding as other muxers, but usually this does not cause any practical problems at all, since the frame timing written by mkvmerge is only off by less than 1 ms, and the frame timing is still off by up to 0.5 ms anyway even if rounding is done normally. If one insists 1 or 0.5 ms errors are too big, one can just use a smaller TimestampScale - mkvmerge can do that too.)

A few things you can try:
1) If you believe that DefaultDuration is problematic for your player, you can set that value as you like, this way:
mkvpropedit "your.mkv" --edit track:v1 --set default-duration=41708375

2) It is possible that ffmpeg automatically "corrects" the audio delay by shifting (delaying) video frame timestamps. To see this, try:
mkvextract "your.mkv" timestamps_v2 0:timestamps.txt

In timestamps.txt, you can see actual time stamps for each frame. If the first frame is not 0, some kind of issues might occur.

Like I said, DefaultDuration should be irrelevant (because each frame has its own timestamp), but some players might depend on this irrelevant number... I don't know. If you create an MKV file with --timestamps, where the first & second frames are 0 and 42 respectively, then
DefaultDuration 42000000 ns (42 ms; ~23.809523810 fps)
may be written, even if the video is essentially 24000/1001 fps, and this is not a problem - such an MKV file plays fine for me. Thus:

3) You can try other players, to see if the problem is in your MKV file itself, or it's your specific player...

[shae]

Is there a way to add custom commandline options in the GUI?

Looking to enable "deterministic".

[derf]

Perhaps the following is unrelated to your issue, but apparently similar problems are also happening due to LAV Filter-side issues. So, if someone has a problem where MPC-HC doesn't show all the audio tracks, various possibilities should be considered. The issue reported at https://forum.doom9.org/showthread.php?p=1963574#post1963574 on 2022-02-09 is:

and clsid's comment is:


So, according to clsid, sometimes this kind of issue is not (directly) related to MKVToolNix nor to MPC-HC itself. I figured maybe I should share this info.
It is the most likely scenario as, like I mentioned, the audio tracks are detected correctly with VLC and Plex.

Also, thanks for the link, I was stuck at MPC-HC 1.7.13 because there were no updates and the website said that development had ceased. Now I can update to 1.9.19! :D

[Liisachan]

@shae
You can go to the "Output" tab, and click the small button by the "Additional options" editbox.

@derf
MPC-BE is also being actively developed.
https://forum.doom9.org/showthread.php?t=165890

[shae]

"Output" tab, and click the small button by the "Additional options" editbox.Thanks.

[Mosu]

Heyo!

just keeping up with my usual release cadence & releasing MKVToolNix v66, a rather small release.

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 66.0.0 "Josie" 2022-03-13
New features and enhancements

mkvpropedit: added a new option "--chapter-charset" allowing the user to specify the character set to use when reading the following chapter file. Implements #3276 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3276).
MKVToolNix GUI: each language shortcut can now be associated with an optional track name that is set along with the language when the shortcut is used. This is an alternative to the feature requested in #3283 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3283).

Bug fixes

mkvmerge: Ogg/OGM reader: mkvmerge will no longer abort with an exception when it encounters Vorbis comments that contain data that isn't valid UTF-8. Fixes #3290 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3290).
MKVToolNix GUI: multiplexer: fixed several issues with the tab order of elements in the "properties" pane and the "output" tab. Also fixed the language display widgets (e.g. "track language" in the "properties" pane) never receiving tab focus. Fixes #3274 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3274).
MKVToolNix GUI: multiplexer: the chapter name template will now be passed to "mkvmerge" if a chapter file is selected on the "output" tab. Fixes #3295 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3295).


Have fun 😁

[VBB]

Thanks!

[Liisachan]

Thanks, Mosu!

As for that rounding weirdness... the original problem my friends and I were trying to fix was, most probably, related to how ffmpeg works (perhaps "by design"), and your tools are NOT responsible for that one. While investigating, I happened to notice the rounding error in mkvmerge too, but that is not the main problem at all. Technically there may be indeed a problem in mkvmerge like you suggested yourself, rounding down 0.5416... being clearly weird, but this part is practically harmless when muxing video; so, please, don't worry about it too much :)

We've already found a way to avoid the main problem (perhaps related to ffmpeg), and the (harmless) rounding error in mkvmerge could be easily avoided if one would like to. I guess a subtle rounding error might be bad for audiophiles in HA who want 1/44100 sample accurateness, but it's not a real problem for doom9 users at all.

Sorry if I annoyed you & thanks again!

[Mosu]

You never annoy me, Liisachan, and didn't with the recent venture into rounding issues either. Don't worry about it.

[Dogway]

I don't know if this is a limitation, but I tried to set a custom aspect ratio to a H.261 stream but the player (MPC-HC + LAV 0.76 + madVR) didn't recognize it.
I read that H.261 streams don't accept DAR flags but I thought this was done at container level? I'm using v66.0

[shae]

Is there a way to remap PTSes so that frame 0 is at 0:00.00?

[Liisachan]

One can always set (redefine) the timestamp of each frame explicitly:
https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.external_timestamp_files
Matroska is really flexible here.

[shae]

It's plain CFR, so I'm not looking to provide PTS files, but just set the times plainly, where frame 0 is at time 0.
The framerate could either be as set in the source container, or commandline.

[Liisachan]

@shae
MKV is so flexible that it's sometimes counter-intuitive and confusing: you may find it strange that MKV doesn't support "plain old CFR" in general.

@Mosu
1/ My friend is confused, and is complaining about this behavior: Even if "Use legacy MIME types for font attachments" is checked in GUI, it transmuxes the font files attached in existing MKV (without updating MIME types) to a newly written MKV, even without any warning.

2/ When transmuxing MKV to MKV: let's say "foo.ttf" is attached to source MKV - then if one tries to manually add "foo.ttf" (redundantly, so to speak, hoping "overriding" the existing attachment), GUI silently fails to add "foo.ttf" without any error/warning messages. This further confuses an inexperienced GUI user, as to how they can update the font mime type.

[Mosu]

@Mosu
1/ My friend is confused, and is complaining about this behavior: Even if "Use legacy MIME types for font attachments" is checked in GUI, it transmuxes the font files attached in existing MKV (without updating MIME types) to a newly written MKV, even without any warning.

That setting is a GUI-only setting that solely affects how MIME type auto-detection is done (= what the MIME type drop down will be set to when you add a new attachment to your multiplexer job). It has no affect on existing attachments as their MIME type will be kept as-is. Additionally the mkvmerge CLI doesn't have a function for altering the MIME type of existing attachments yet either; so I cannot simply extend the function to existing ones without some serious work.

2/ When transmuxing MKV to MKV: let's say "foo.ttf" is attached to source MKV - then if one tries to manually add "foo.ttf" (redundantly, so to speak, hoping "overriding" the existing attachment), GUI silently fails to add "foo.ttf" without any error/warning messages. This further confuses an inexperienced GUI user, as to how they can update the font mime type.

That might be a bug as a warning should be shown in that case if I remember correctly (but then again, it might not be as you can disable certain warnings in the preferences). I'll look into it.

[varekai]

@Mosu
This is very interesting! Not shure if doable but here goes:
How do I add a ClearSans.ttf to an existing mkv that will be used as subtitle when playing in a mediaplayer lik PotPlayer, MPC-HC or VLC?
I have tried but no subs show up in either player.

Really appreciate your dedicated work with MKVToolNix! :D

Thanks and best regards,
varekai

[Mosu]

Matroska the container format doesn't have provisions for signalling a player to use a certain font (or any other type of attachment). If and how fonts are used is up to the subtitle format in question. The best (only?) supported format using fonts is probably SSA/ASS, which will have to refer to the attached font's name.

[Mosu]

2/ When transmuxing MKV to MKV: let's say "foo.ttf" is attached to source MKV - then if one tries to manually add "foo.ttf" (redundantly, so to speak, hoping "overriding" the existing attachment), GUI silently fails to add "foo.ttf" without any error/warning messages. This further confuses an inexperienced GUI user, as to how they can update the font mime type.

Preferences → "Multiplexer" → "Always skip while attaching new files when attachment with same name exists"

Disable that option and the GUI'll ask you (or your friend) what to do in such a case.

[shae]

MKV is so flexible that it's sometimes counter-intuitive and confusing: you may find it strange that MKV doesn't support "plain old CFR" in general.

I don't mean I necessarily expect MKV to be PTS-less. But in term of muxing, it makes sense to have a simple option that effectively recreates or overrides, and does behind the scenes what's suitable for plain CFR. I assume that's what people use in 99% of the cases.

I don't know if such an option exists, but based on what you said, I guess it does not.

BTW, the source file with frame 0 not at 0 PTS was the result of cutting in Avidemux. I have no idea why it would create such a thing.

[Liisachan]

How do I add a ClearSans.ttf to an existing mkv that will be used as subtitle when playing in a mediaplayer lik PotPlayer, MPC-HC or VLC?
I have tried but no subs show up in either player. MPC-HC, MPC-BE should be able to do that playback-time, assuming that the font you want to use is installed and available by OS.

1) Open your MKV file like you watch it normally.
2) &Play -> Su&btitle Track -> &Styles
3) You can change font(s) etc.

Or, if it's not SSA/ASS, you can try: &View -> &Options -> Subtitles -> Default Style.

If you want to modify the MKV file itself so that new fonts may be used permanently, then you'll have to re-create your MKV files. Doing this is not difficult (at least for typesetters) but not trivial. That is, you don't need to re-encode but you need to re-mux it, after slightly editing your SSA/ASS. You can first demux ASS then open it with a text editor, and edit a line that looks like this:


[V4+ Styles]
...
Style: sampleStyle1,fontName,30,...


Change fontName. It's a font-family name (not a font-file name) supposed to be used for the lines with sampleStyle1. 30 is the font size. When done, remux your updated ASS file.
Like Mosu said, this process is not something directly related to MKVToolNix. Information about "suggested" font faces is in the source file (SSA/ASS), which mkvmerge will simply copy without doing anything special (e.g. it doesn't verify that the font is actually usable as an attachment). Enjoy subbing :)

[Liisachan]

But in term of muxing, it makes sense to have a simple option that effectively recreates or overrides, and does behind the scenes what's suitable for plain CFR.
True. One surely hopes `--default-duration 0:24000/1001p` would do that seemingly simple job.
Currently, if for some reason timestamps are messed up, then the easiest and foolproof way to fix & set frame timestamps exactly as you like seems to be using timestamps.txt explicitly. Otherwise, sometimes it's impossible to fix timestamps even with `--fix-bitstream-timing-information`.

[filler56789]

"The procedure entry point CreateEventA could not be located in the dynamic link library api-ms-win-core-synch-l1-2-0.dll."

source: mkvtoolnix-64-bit-66.0.0-revision-004-g068687405,
operating system = 64-bit Windows 7.

EDIT: mkvtoolnix-64-bit-64.0.0-revision-045-g5ab2bd424 is the last good one, apparently.

EDIT 2:

I don't support Windows 7 anymore.

okay :-/

EDIT 3:

From https://mkvtoolnix.download/doc/NEWS.md :

Version 59.0.0 "Shining Star" 2021-07-10

.......

## Build system changes

The Qt library is now required for building all applications,
even the command-line ones,
as they use Qt's MIME type detection capabilities.
In turn this means that you cannot disable the Qt usage anymore; either Qt5 or
Qt 6 is required.

Now I understand why the file "magic.mgc" suddenly is not required anymore.
Anyway, that was a very-bad idea && move,
at least for all the users of Windows 7, surely.

[varekai]

Matroska...
Thanks for the info, appreciate it!

[varekai]

MPC-HC, MPC-BE...
Thanks for info, appreciate it, will do some testing aka trial&error!

[filler56789]

"No multiplex job has been opened yet."

Is there a way to disable that, let's say, ``splash screen´´?

[Mosu]

"No multiplex job has been opened yet."

Is there a way to disable that, let's say, ``splash screen´´?

I don't understand. That's only shown when no settings are currently open, and the GUI actually starts with one open, therefore you'll only see that message if you actively close the last open settings. It's not a splash screen.

If you want something along the lines of "always open new, fresh settings when I close the last open one", then the answer is no.

[Mosu]

@Mosu
1/ My friend is confused, and is complaining about this behavior: Even if "Use legacy MIME types for font attachments" is checked in GUI, it transmuxes the font files attached in existing MKV (without updating MIME types) to a newly written MKV, even without any warning.

I've taken the time over the last two days to implement this: both mkvmerge & mkvpropedit now have a new option called "--enable-legacy-font-mime-types" which will cause the same MIME type mapping that was previously only used in the GUI to be applied to both newly added attachments as well as existing ones (read from Matroska or SSA/ASS files). The GUI adds the option automatically if there are any attachments to be dealt with.

[filler56789]

I don't understand. That's only shown when no settings are currently open, and the GUI actually starts with one open, therefore you'll only see that message if you actively close the last open settings. It's not a splash screen.

If you want something along the lines of "always open new, fresh settings when I close the last open one", then the answer is no.

Thanks for answering. The fact is, before upgrading to version 64, I was using version 45, and I had never seen that kind of message until today. :–|

[Mosu]

Thanks for answering. The fact is, before upgrading to version 64, I was using version 45, and I had never seen that kind of message until today. :–|

The message has been there right from the start, certainly in v45. You simply never closed the last open settings tab, it seems.

[Liisachan]

I've taken the time over the last two days to implement this: both mkvmerge & mkvpropedit now have a new option called "--enable-legacy-font-mime-types" which will cause the same MIME type mapping that was previously only used in the GUI to be applied to both newly added attachments as well as existing ones (read from Matroska or SSA/ASS files). The GUI adds the option automatically if there are any attachments to be dealt with. Thank you very much. By "from SSA/ASS", you mean it also reads that old uuencode (?) font data embedded in SSA/ASS itself?

I'm somehow lucky I can use 66.0 on my Windows 7, but I'm getting the same error described by filler56789 now, with 66.0.0.18. Because of this, I can't personally test it and perhaps I won't be able to comment much on newer versions from now on. Well, I have Linux that runs from a thumb drive, so I might test MKVToolNix there, though. My friend who complained will be surely happier nevertheless.

One potential problem is, some users can be sometimes idiots from your point of view. They may enable "Use legacy" just before hit "Start Multiplexing" thinking "Oh yeah, I'd like to use legacy Mime, so I'll check it before multiplexing." Not before selecting the attached files. :)

As for the other issue: The main problem is, "Always skip while attaching new files..." is enabled by default. So you can't really blame the user saying "This is happening because YOU enabled it" can you? I'd question this default.

The secondary problem is: Let's say I'm attaching "./video/debug.log" as Name "video-debug.log" and then also attaching "./audio/debug.log" as Name "audio-debug.log". There are no name-space collisions in the resulted MKV; the 2 source files are different, having different paths; & the first file is explicitly named as "video-debug.log". Even then, if warning is enabled, there will be a warning: "Name debug.log is already present". This may not be ideal, although not really a problem for me, as I don't use GUI too often.

Thanks for your work anyway. I'd like to re-emphasize that the font-mime mess is no one's fault. "Higher-ups" suddenly (re)defined the font mime types ~10 years after the de facto standard for MKV had been well established, supported by many players & tools. The breaking change occurred well above Matroska devs or Matroska users. Who'd have imagined that "editing the mime type of an attachment" will be such a daily job - be it updating to use font/ or be it 'downgrading' to application/x- to be old-player-friendly. :(

[Mosu]

Thank you very much. By "from SSA/ASS", you mean it also reads that old uuencode (?) font data embedded in SSA/ASS itself?

That, yeah.

One potential problem is, some users can be sometimes idiots from your point of view. They may enable "Use legacy" just before hit "Start Multiplexing" thinking "Oh yeah, I'd like to use legacy Mime, so I'll check it before multiplexing." Not before selecting the attached files. :)

Yeah well, I cannot prevent users from doing dumb things, and there's no such thing as a foolproof software 😁

As for the other issue: The main problem is, "Always skip while attaching new files..." is enabled by default. So you can't really blame the user saying "This is happening because YOU enabled it" can you? I'd question this default.

Huh… I don't remember why I made it enabled by default, to be honest. At the moment I agree that the default should be off, and I'll change it accordingly.

The secondary problem is: …

With the warning enabled you'll still be able to add any file, no matter how many naming collisions there are. That should suffice for those cases.

[Atak_Snajpera]

How to convert minimum_timestamp value to audio delay in ms?

"codec": "AAC",
"id": 1,
"properties": {
"audio_channels": 2,
"audio_sampling_frequency": 22050,
"codec_id": "A_AAC",
"codec_private_data": "139056e5a0",
"codec_private_length": 5,
"default_duration": 46439909,
"default_track": false,
"enabled_track": true,
"forced_track": false,
"language": "eng",
"language_ietf": "en",
"minimum_timestamp": 2234000000,
"number": 2,
"track_name": "HE-AAC 50-70",
"uid": 1982383230
},
"type": "audio"

[Mosu]

The minimum timestamp is in ns. And "audio delay" is basically the difference of the audio track's minimum timestamp & the video track's timestamp. Meaning:

audio delay in ms = (audio track's minimum timestamp - video track's minimum timestamp) / 1000000

[Atak_Snajpera]

The minimum timestamp is in ns. And "audio delay" is basically the difference of the audio track's minimum timestamp & the video track's timestamp. Meaning:

audio delay in ms = (audio track's minimum timestamp - video track's minimum timestamp) / 1000000

Ok. Thank you.

[tebasuna51]

Making test about a problem, detected by StainlessS with PCM multichannel stored like A_MS/ACM in mkv's generated by MakeMKV, I read mkv docs about that codec ID. Link to the problem.https://forum.doom9.org/showthread.php?p=1966364#post1966364
I read also the related post in this thread https://forum.doom9.org/showthread.php?p=1949976#post1949976
And the pending enhancement about ADPCM codec https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2757

In my test:

- mkvmerge ignore and mkvtoolnixGUI reject WAV files with: unsupported container format (RIFF WAVE wfortmatTag 0x000X)
Rejected:
wfortmatTag 0x0002 ADPCM MS 2 channels 4 bits
wfortmatTag 0x0006 ADPCM A-Law CCITT 2 channels 8 bits
wfortmatTag 0x0007 ADPCM U-Law CCITT 2 channels 8 bits
wfortmatTag 0x0011 ADPCM Intel 2 channels 4 bits
wfortmatTag 0x0031 GSM 6.10 Microsoft 1 channel
Accepted:
wfortmatTag 1 PCM INT like Codec ID A_PCM/INT/LIT
wfortmatTag 3 PCM Float IEEE like Codec ID A_PCM/FLOAT/IEEE

- ffmpeg can mux and demux in/from mkv's all of them using the Codec ID A_MS/ACM for wfortmatTag <> 1 or 3
mpchc (LAV filters) seems play without problems these mkv's.

- mkvextract
Error: Extraction of track ID 1 with the CodecID 'A_PCM/FLOAT/IEEE' is not supported.
Error: Extraction of track ID 1 with the CodecID 'A_MS/ACM' is not supported.

- when mkvmerge or ffmpeg mux a multichannel wav PCM INT with WAVE_FORMAT_EXTENSIBLE header always use Codec ID A_PCM/INT/LIT, and the ChannelMask is lost.
I only know MakeMKV and the old AVI-Mux GUI than create mkv's using CodecID 'A_MS/ACM' for multichannel wav's. Like must be to play correctly the file.
mpchc (LAV filters) seems play without problems these mkv's.

There are any problem to use 'A_MS/ACM' by mkvmerge/extract when is needed?
The 'fmt' subchunk of wav/w64 (http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html) files can be stored in Codec Private data when merge, and recovered when extract and all seems ok.

[Mosu]

The reason PCM data isn't well supported is that no one cares enough about it to put in the work. Will likely never improve substantially.

[filler56789]

Making test about a problem, detected by StainlessS with PCM multichannel stored like A_MS/ACM in mkv's generated by MakeMKV, I read mkv docs about that codec ID. Link to the problem.https://forum.doom9.org/showthread.php?p=1966364#post1966364
I read also the related post in this thread https://forum.doom9.org/showthread.php?p=1949976#post1949976
And the pending enhancement about ADPCM codec https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2757

In my test:

- mkvmerge ignore and mkvtoolnixGUI reject WAV files with: unsupported container format (RIFF WAVE wfortmatTag 0x000X)
Rejected:
wfortmatTag 0x0002 ADPCM MS 2 channels 4 bits
wfortmatTag 0x0006 ADPCM A-Law CCITT 2 channels 8 bits
wfortmatTag 0x0007 ADPCM U-Law CCITT 2 channels 8 bits
wfortmatTag 0x0011 ADPCM Intel 2 channels 4 bits
wfortmatTag 0x0031 GSM 6.10 Microsoft 1 channel
Accepted:
wfortmatTag 1 PCM INT like Codec ID A_PCM/INT/LIT
wfortmatTag 3 PCM Float IEEE like Codec ID A_PCM/FLOAT/IEEE

- ffmpeg can mux and demux in/from mkv's all of them using the Codec ID A_MS/ACM for wfortmatTag <> 1 or 3
mpchc (LAV filters) seems play without problems these mkv's.

- mkvextract
Error: Extraction of track ID 1 with the CodecID 'A_PCM/FLOAT/IEEE' is not supported.
Error: Extraction of track ID 1 with the CodecID 'A_MS/ACM' is not supported.

- when mkvmerge or ffmpeg mux a multichannel wav PCM INT with WAVE_FORMAT_EXTENSIBLE header always use Codec ID A_PCM/INT/LIT, and the ChannelMask is lost.
I only know MakeMKV and the old AVI-Mux GUI than create mkv's using CodecID 'A_MS/ACM' for multichannel wav's. Like must be to play correctly the file.
mpchc (LAV filters) seems play without problems these mkv's.

There are any problem to use 'A_MS/ACM' by mkvmerge/extract when is needed?
The 'fmt' subchunk of wav/w64 (http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html) files can be stored in Codec Private data when merge, and recovered when extract and all seems ok.

:goodpost: and :thanks:
Specially for mentioning the olde and goode AVI-Mux GUI.
Now I've finally found a way to put ATRAC3plus and ATRAC9 audio into the Matroska container. :) :sly:

The reason PCM data isn't well supported is that no one cares enough about it to put in the work.

It seems the actual problem is not "PCM data", but the lack of support for the WAVE_FORMAT_EXTENSIBLE feature in both mkvmerge and ffmpeg's Matroska muxer.

[filler56789]

source: https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2757

Let me rephrase, I'll look into outputting this type of audio as A_MS/ACM, but chances are your player doesn't support that one either.

For the notes, or FWIW....

LAV Filters have no problems with ATRAC3plus and ATRAC9 in both .MKV and .AVI,
whereas mpv plays correctly only the .AVI format.
Also, MPC-BE's internal filters (AVI splitter, Matroska splitter and the generic audio decoder) haven't been updated yet.

[Mosu]

No, the actual problem is that the Matroska format simply doesn't have native elements for the channel mapping & various codec IDs for various elements. WAVE_FORMAT_EXTENSIBLE is a foreign data structure we don't simply want to import into Matroska; we want to use native elements. Yes, there's the A_MS/ACM workaround, but I simply don't want to go down that road. I don't really want to do the specs work for the other parts either, mind you…

[filler56789]

No, the actual problem is that the Matroska format simply doesn't have native elements for the channel mapping & various codec IDs for various elements. WAVE_FORMAT_EXTENSIBLE is a foreign data structure we don't simply want to import into Matroska; we want to use native elements. Yes, there's the A_MS/ACM workaround, but I simply don't want to go down that road. I don't really want to do the specs work for the other parts either, mind you…

Well, that suxxx terribly :(

Yes, there's the A_MS/ACM workaround, but I simply don't want to go down that road.

However you (and/or other possible Matroska developers) saw no problem in forcing "V_MS/VfW" onto VC-1 and MPEG4-ASP...

[nevcairiel]

MPEG4-ASP...

You know, these are a thing right?

V_MPEG4/ISO/ASP
V_MPEG4/ISO/AP
V_MPEG4/ISO/SP

[Mosu]

Well, that suxxx terribly :(

And yet it doesn't seem to suck enough for you to do something about it by doing the specs work, does it? See, that's the thing with Open Source software. You could actually do something about it, but you chose not to, which is perfectly fine. But then again you don't get to complain that others make the same choice of not doing anything about it.

However you (and/or other possible Matroska developers) saw no problem in forcing "V_MS/VfW" onto VC-1 and MPEG4-ASP...

V_MS/VFW was done right at the start of Matroska development, back when we all (and myself most of all) know a whole lot less about coding in general, good container design in particular and good practices to round it all up. It was the easy way to achieve quick success, especially wrt. integration into existing players. I would most likely chose differently today.

[derf]

One notable thing that changed is that mkvmerge now maps the "enabled" track header flag from MP4 file's "tkhd" atom to Matroska's "track enabled" flag. So maybe those tracks were disabled in the source MP4 files already. You can override those flags in the GUI, of course; that's one of the reason I added the "disabled track flag" combobox in the first place.

If that isn't it, report the issue to the MPC-HC bug tracker, please.

I finally got around with v66 to taking the time to check what's happening. Effectively, the audio tracks were marked as disabled, but were still present. Changing the audio tracks to enabled corrects the issue. Now I'm looking in the options to check if all audio tracks can be set to enabled by default.

Thanks for the great software.

[filler56789]

OVERDUE/BELATED REPLY:

However you (and/or other possible Matroska developers) saw no problem in forcing "V_MS/VfW" onto VC-1 and MPEG4-ASP...

You know, these are a thing right?

V_MPEG4/ISO/ASP
V_MPEG4/ISO/AP
V_MPEG4/ISO/SP
That's 100% true for ffmpeg, but only 50% (or less) true for mkvmerge, because

1) mkvmerge doesn't use "V_MPEG4/ISO/*" for DivX /Xvid unless you call the "--engage native_mpeg4" option;
2) at least if you're using the mkvtoolnix GUI, "--engage native_mpeg4" only takes effect after you close and restart the application. :-/

-----
P.S.: end of discussion.

[filler56789]

Reporting a design-flaw...
When trying to remux an MKV which contains an ATRAC9 stream,
MKVtoolnix "thinks" it is Vorbis(!) audio :eek:
Evidently the GUI.exe should say "format unsupported" and act accordingly,
because when I pressed the "Start multiplexing" button, the application returned no warnings, no errors,
and no new file as well. :confused:

https://forum.videohelp.com/attachments/64062-1648657324/mkvtoolnix-FLAW.png

P.S.: For the notes, here is what MediaInfo detects:
Audio
ID : 2
Format : Atrac9
Format/Info : Adaptive Transform Acoustic Coding 9
Codec ID : A_MS/ACM / FFFE / 47E142D2-36BA-4D8D-88FC-61654F8C836C
Duration : 1 min 12 s
Bit rate : 120 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Compression mode : Lossy
Stream size : 1.04 MiB (5%)
Language : English
Default : Yes
Forced : No

Most people think the WAVE_FORMAT_EXTENSIBLE thing is for multichannel uncompressed audio only, but in fact it also can replace the use of a TwoCC with a GUID number.

[Mosu]

Thanks, but I don't really care and will not spend time on improving A_MS/ACM support.

[tebasuna51]

That's 100% true for ffmpeg, but only 50% (or less) true for mkvmerge, because...

@nevcairiel and filler56789

Maybe ffmpeg can solve that audio problem also: ffmpeg ticket (https://trac.ffmpeg.org/ticket/9703)

[Aleksoid1978]

Reporting a design-flaw...
When trying to remux an MKV which contains an ATRAC9 stream...

Can you upload mkv+ATRAC9 sample for me ?

[filler56789]

Can you upload mkv+ATRAC9 sample for me ?

Done. ↓ ↓

https://www.mediafire.com/file/veqcsrux9jwt6hh/GQ-ACSW-01-intro.mkv/file

[filler56789]

Thanks, but I don't really care and will not spend time on improving A_MS/ACM support.

You should have written "improving LACK OF a_ms/acm support". :D

I know, you're too busy even for writing appropriate error-handling code. ;)

[Mosu]

Heyo!

Here's a new release of MKVToolNix. Quite a lot of work has gone into this release, vastly improving the support for BCP 47 language tags. While a lot of you won't see much of a difference, the support has vastly improved for a lot of Asian languages, both adding new features such as canoncalization, as well as fixing bugs, e.g. not allowing certain variants with certain languages even though they do make total sense together.

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 67.0.0 "Under Stars" 2022-04-10
New features and enhancements

all: IETF BCP 47/RFC 5646 language tags: when deriving the legacy language element codes to use a language tag's ISO 639 code is also potentially interpreted as an & its prefix is used as the legacy language code. For example, "Yue Chinese" = "yue" is not part of ISO 639-2. However, there is an extlang subtag "yue" with a valid prefix of "zh" ("Chinese"), and for "Chinese" there is an ISO 639-2 language code: "chi". In this example the IETF language element would be set to "yue" and the corresponding legacy element to "chi". Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: grandfathered language tags are now supported. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: all deprecated subtags from the IANA language subtag registry are now supported. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: all lists of valid subtags have been updated from their respective authoritative sources. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: all in the IANA language subtag registry are now supported, even those marked as deprecated and of type 'grandfathered'. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: reduced the maximum number of extended language subtags that are present in a valid tag from 3 to 1 in compliance with RFC 5646 section 2.2.2. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: all language codes reserved for private/local use ("qaa"–"qtz") are now supported. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: Digital Cinema Naming Convention language codes that fall into the IETF BCP 47 range of "private use" tags ("qaa"–"qtz") are now replaced by their IETF BCP 47 equivalents during normalization (e.g. "QMS" → "cmn-Hans"). Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: added a new translation to Chinese Simplified (Singapore) by Dian Li.
mkvmerge, mkvpropedit: added a new command line option called "--enable-legacy-font-mime-types". With this option on the two programs will use the same legacy MIME types for fonts whenever new attachments are added (both programs), when reading existing attachments (only "mkvmerge") or when replacing existing ones (only "mkvpropedit").
mkvmerge, mkvpropedit: IETF BCP 47/RFC 5646 language tags: added a command line option "--normalize-language-ietf &lt;mode>" which turns on normalization of IETF BCP 47 language tags to either their canonical (mode "canonical") or extended language subtags form (mode "extlang") or turns it off (mode "off"). If the option isn't given, language tags will now be normalized to the canonical form. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: ISO 639-3 and 639-5 languages will now be used by default. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: the language editor dialog will now show warnings in several cases: when deprecated tags are used; when the tag's canonical and/or extlang forms differ from the user input. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: the language editor now has a button to replace the current tag with a normalized form (canonical or extlang) if those differ from the current tag. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: added an option in the preferences to always normalize all language tags to their canonical or extlang forms or to turn normalization off. Can also be enabled from the language editor dialog. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: the language dialog now shows a warning if a variant is used with a prefix that isn't in the variant's list of suitable prefixes. It'll also say if the corresponding canonical/extlang forms would have a suitable prefix. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: the language dialog now shows a warning if a script is used with a language for which it should be suppressed. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: multiplexer: the track property group boxes in the scrollable pane are now collapsible & expandable, saving their state over restarts of the GUI. This is in preparation of adding many more track properties in future releases, allowing the user to hide parts they don't use all that often.
MKVToolNix GUI: multiplexer: if the option "use legacy font MIME types" is enabled in the preferences, the new command line option "--enable-legacy-font-mime-types" will be passed to "mkvmerge" in order to have it remap the MIME types of existing attachments, too.

Bug fixes

all: IETF BCP 47/RFC 5646 language tags: variants aren't validated wrt. to prefixes anymore as BCP 47 doesn't actually pose restrictions on them, saying only that prefixes "are suitable sequences" for use with the variants. What is now verified, though, is that no variant is used multiple times within the same language tag. Part of the implementation/fix of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
build system & MKVToolNix GUI: fixed detecting the presence of & the compilation with the multimedia module of Qt version 6.2.0 and newer.
build system: fixed compilation on Unices other than Linux & macOS (e.g. FreeBSD). Fixes #3316 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3316).
MKVToolNix GUI: job queue: fixed compiling in the audio player code for the the "play audio" end-of-job action. Fixes #3303 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3303).
MKVToolNix GUI: multiplexer: recognizing added XML chapter, segment info or chapter files required the XML declaration & root node (e.g. "&lt;?xml…?> … &lt;Chapters>" for chapters) be located within the first 1 KB, which wasn't enough for files that contain a lot of comments at the start like the included "example-chapters-2.xml". The detection range was extended to 10 KB. Fixes #3302 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3302).

Build system changes

build system: the provided Windows binaries are now compiled with Qt 6. A drawback is that certain audio formats aren't supported anymore by Qt for the "end of job" sound notification playback, notably the Ogg file format & the Vorbis audio codec. MKVToolNix therefore now ships Opus-in-WebM files for the same purpose.
The bundled "fmt" library was updated to v8.1.1.
The bundled "nlohmann-json" library was updated to v3.10.5.
The bundled "pugixml" library was updated to v1.12.1.


Have fun 😁

[VBB]

Big thank you, as always!

[hubblec4]

Hi Mosu

When I start MTXgui, I get this error:
"Der Prozedureeinsprungspunkt 'CreateDXGIFactory2' wurde in der DLL 'dxgi.dll' nicht gefunden"

I guess it's the end of Win7 support?

[Mosu]

I haven't supported Windows 7 for quite a while now. If prior versions still ran on it, it was unintentional & lucky. It's likely that Qt 6 uses stuff that isn't available on Windows 7 as that was the only change between 66 & 67 that could affect OS-level compatibility.

[filler56789]

I guess it's the end of Win7 support?

Surely.
MKVtoolnix does not need to always use the "latest and greatest" :rolleyes: :rolleyes: :rolleyes: QT thing for the GUI.
And at least the command-line applications of the suite should not require QT at all.

The problem of course is to convince Mosu that he is wrong.

[lvqcl]

I'd say that the problem is to explain to some users that Mosu doesn't owe them anything.

[Snowknight26]

Looks like a bug caused by the transition to Qt 6 is the fact that the main MKVToolNix GUI window always opens on display 1, even if it was previously opened/closed on display 2 (assuming display 1 is to the left of display 2). Additionally, opening any context menus while the UI is on display 2 causes them to open on display 1.

Using a setup that consists of 2x 2560x1440 monitors (desktop resolution basically 5120x1440), when opening the GUI, it seems to always clamp the window position values to 2560x1440, even if the last location was was something like x=3000, y=700 (for the top-left pixel of the UI). Same with context menus.

Example screenshot:

After opening and dragging the GUI to monitor 2:
https://www.stfcc.org/pics/i/0f8986b0fae3e7db1aa10fa80be6c90a_th.png (https://www.stfcc.org/pics/i/0f8986b0fae3e7db1aa10fa80be6c90a.png)

After closing and reopening the GUI:
https://www.stfcc.org/pics/i/a1f7f6d4a754461af15df0aa50c68460_th.png (https://www.stfcc.org/pics/i/a1f7f6d4a754461af15df0aa50c68460.png)

After moving the GUI to monitor 2 and clicking the first menu. Notice the context menu on monitor 1:
https://www.stfcc.org/pics/i/0f8986b0fae3e7db1aa10fa80be6c90a_th.png (https://www.stfcc.org/pics/i/0f8986b0fae3e7db1aa10fa80be6c90a.png)

[clsid]

Possible solution to get rid of the CreateDXGIFactory2 dependency:
https://forum.qt.io/topic/78380/entry-point-not-found-the-procedure-entry-point-createdxgifactory2-could-not-be-located-in-the-dynamic-link-library-dxgi-dll

[Mosu]

Looks like a bug caused by the transition to Qt 6 is the fact that the main MKVToolNix GUI window always opens on display 1, even if it was previously opened/closed on display 2 (assuming display 1 is to the left of display 2). Additionally, opening any context menus while the UI is on display 2 causes them to open on display 1.

Yeah, I've already received a similar report via email, I'll likely create a Qt5-based pre-build soonish for everyone to use & will switch back to Qt5 for the next release(s). I do run a multi-monitor setup myself, but I was lucky in that the display the GUI runs well on is my main display — and I simply forgot to test the other one.

[Mosu]

Looks like a bug caused by the transition to Qt 6 is the fact that the main MKVToolNix GUI window always opens on display 1, even if it was previously opened/closed on display 2 (assuming display 1 is to the left of display 2). Additionally, opening any context menus while the UI is on display 2 causes them to open on display 1.

The latest continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/67.0.0/) are done with Qt 5 again. Please give them a try.

[Liisachan]

The latest continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/67.0.0/) are done with Qt 5 again. Please give them a try.

I can start 67.0.0.1 on Win7 !
Thanks for taking time for backward compatibilities.
Also, a lot of work related to lang tags seems impressive.

[Mosu]

I can start 67.0.0.1 on Win7 !
Thanks for taking time for backward compatibilities.
Also, a lot of work related to lang tags seems impressive.

Just to be perfectly clear: going back to Qt 5 has nothing to do with Windows 7. It's solely due to the multi-monitor issues. Once those have been solved in newer versions of Qt 6, I will go back to Qt 6. Windows 7 is not support, won't be supported, and MKVToolNix will cease to run on it.

[manolito]

Just asking for a clarification:

Which is the last MKVToolNix version which runs without issues under Win7 ? I'm not asking for official Win7 support, I just want to know which version is the last one without any known Win7 problems. I have no intention to upgrade Windows to a later version than Win7, so I just want to know which MKVToolnix version will become my last version.

The thing I already did for Win XP some years ago was combining an older GUI version with a newer main executable which worked for a couple of versions. Would it be possible to do the same thing for Win7 ?


Cheers
manolito

[StainlessS]

I just want to know which version is the last one without any known Win7 problems. I have no intention to upgrade Windows to a later version than Win7, so I just want to know which MKVToolnix version will become my last version.

+1 on that.

EDIT: thanks filler56789 :)

[Snowknight26]

The latest continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/67.0.0/) are done with Qt 5 again. Please give them a try.

That did the trick, thanks.

[filler56789]

Just asking for a clarification:

Which is the last MKVToolNix version which runs without issues under Win7 ?

Answer:


EDIT: mkvtoolnix-64-bit-64.0.0-revision-045-g5ab2bd424 is the last good one, apparently.

[filler56789]

I'd say that the problem is to explain to some users that Mosu doesn't owe them anything.

Evidently your point-of-view is absolutely non-technical and therefore not of much relevance.

[lvqcl]

Software development is not just a 'technical' thing. Often 'non-technical' issues matter much more than 'technical' ones.

[Liisachan]

@Mosu
Don't worry. Practically, that won't be a problem. I generally avoid the bleeding-edge (too new) versions anyway for actual encoding, after having experienced a lot of unexpected breaking changes, intentional or otherwise.

That said, testing new versions and creating sample test clips was fun in a way, arguably helpful for other users too, spotting potential issues if any. Maybe I can't personally do that actively anymore, but I'm sure you'll keep getting a lot of bug reports from many users... I hope there will be no hard feelings for anyone :)

Just asking for a clarification:

Which is the last MKVToolNix version which runs without issues under Win7 ? Although 66 seems to work for me, you don't necessarily need to use the last version that supports Win7. Unless you're doing something rather exceptional, any version (20, 30, 40, 50, etc.) works equally, essentially writing the bit-identical MKV files, if unessential meta-data is ignored.

For GUI-users in general (not only Win7 users), I'd recommend Version 57 or before (e.g. 56.1), if you ever use font attachments, are not too familiar with the subtlety of the font mime issues, and you'd like to support both old and new players. Starting from 58, GUI writes (without any warnings) an MKV file which older players don't understand - potentially a serious disadvantage (without any practical advantages). This happened due to a combination of unfortunate circumstances, not a bug but by design.

58+ too can optionally write an MKV file understandable by both old and new players, if you manually set the mime types. This compatibility mode is opt-in, disabled by default, though.

If you're creating an MKV file personally and you know you only use new players that support the new mime types, there won't be any problems at all either way. MPC-HC (clsid) and MPC-BE are good examples, where newer mime types are fully supported, but not the last version of "official" MPC-HC.
mpv seems fine too (at least for common cases).

VLC is not yet fully supporting the new mime types, but it has a fail-safe mechanism where the attachment file extension is checked when it doesn't understand the mime type (meaning, superficially it works in most cases, though the new mime types may not be fully supported explicitly). Btw, currently VLC (v3.0.0–v3.0.16) can't play MKV with Vorbis or Opus audio correctly, so don't use Vorbis in MKV if your target player is VLC!

PS
Even if you're fine with the newly standardized font mime types, Versions 58, 59 must be avoided. These are experimental versions, where new mime types were introduced, but are not yet stable one way or another. Version 60+ should work fine.

To make MKV files that both old and new players understand using v58+, you'll need to check "Use legacy MIME types for font attachment" in Preference | GUI | General Options. Enabling this option has no bad side effects; for backward compatibility, legacy mime types are written internally instead of the newly standardized ones, so this may not be your option if you're a "standard compliance" geek. The good news is, the Matroska specs now say a player should try to support both legacy and new font mime types, so basically these legacy types are guaranteed to work forever (so MKV written by v57 and before will always play okay too).

If not enabling this option: newer players are fine; older players before 2020 don't load the attached font files for subtitles. If the viewer is lucky, subtitles are still readable with some system default fonts, but they may be garbled if subtitles really require attached font files: e.g. if the language is not well supported by the system fonts. Without the intended fonts, also sign-subs may be shown in weird positions and fancy karaoke effects will be obviously broken.

While this situation is a nightmare for a SSA/ASS user/typesetter, if you don't use styled subtitles with font attachments at all, then these considerations are irrelevant for you.

Edit (2022-04-23)
As mentioned, VLC v3.0.0–v3.0.16 has vorbis/opus bugs; which was fixed in v3.0.17 (released around March, 2022). Changelog (NEWS) says:

Changes between 3.0.16 and 3.0.17:
----------------------------------
[...]
* Fix missing audio start of Opus audio in MKV/WebM

[manolito]

Thanks a lot Liisachan for this very useful information...

I was still using version 56.1 (32bit), now I switched to version 57 (also 32bit) without experiencing any problems. Looks like this will become my final MKVToolNix version...

Thanks again
Manolito

[hubblec4]

Possible solution to get rid of the CreateDXGIFactory2 dependency:
https://forum.qt.io/topic/78380/entry-point-not-found-the-procedure-entry-point-createdxgifactory2-could-not-be-located-in-the-dynamic-link-library-dxgi-dll

Is this a solution for Mosu or for the Win7 users?

For me it looks to complicate.

[Mosu]

That article is about compilation, so probably intended for me. But as stated earlier, I don't support Windows 7, therefore I won't spend time on such endeavors.

[hubblec4]

I can fully understand you, you won't support this "old" OS WIN7.
But on the other hand I can also understand the users (like me). WIN7 is the last Windows what I want to use.

Install a VM with Win10/11 is also not a solution, and change the OS to Linux is fine but there is no good Matroska player like MPC-HC/BE all other players are bad Matroska players.

And it seems that also for me, the last MTX version will be 66.

[Mosu]

That's totally your choice, and I don't really care what you do with your time & your devices (nor should I).

You (and everyone else insisting they'll never use anything else than Win7) won't stick with that choice forever anyway. One day you'll find yourself in the situation of needing or wanting a new computer, and you realize that your new hardware just doesn't work with Win7 anymore. Or your other favorite application besides MTX doesn't work with Win7 anymore, but you cannot justify not updating it anymore, e.g. because there's a new codec out there you want to use and it's only supported by that new version of the program that doesn't run on 7 anymoire. Or any other reason, really. Y'all can put it off, probably for quite a while, but y'all will have to upgrade or migrate to something else one day.

[hubblec4]

Yes I fully agree with that.
The time will be come, where is no way out to upgrade.

But I hope not in this decade :-)

[clsid]

It not only means dropping Windows 7, but also Windows 8.0, which together are about 15% of Windows users worldwide.

Fixing the current issue might take you an hour. Dealing with complaints much longer over time. But your choice. It is an unnecessary requirement for functionality in Qt that you don't use.

[Mosu]

You're actually wrong in your assumption. Always taking the easier route instead just in order to avoid having to deal with complaints would have led to MKVToolNix being abandoned ten years ago or even earlier. Complaints are always loud, people often hate & change and the ones that really hate it complain very loudly. You know what I really, really loath wrt. programming? Having to deal with legacy technology. This includes, but isn't limited to, having to cater to operating systems that even their main provider doesn't support anymore.

Back when I rewrote mmg to MKVToolNix GUI I mostly did it because I was completely demotivated to continue working with a) the old code base and even more so b) wxWidgets' extremely prickly design & idiosyncrasies. You probably remember how loudly and strongly people objected to the new GUI. Well, I could have just taken the easier route, but that one would have been to cede working on MKVToolNix (the whole project) altogether. That was my decision back then: "either I'm doing this not only to improve life for my users, but also for myself, or I'm walking away".

[hubblec4]

Hi Mosu

For me is all fine with your decisions and I will follow your way's.
There is no reason why you change your programming direction for a small amount of user's.

Keep on all your good and hard work. We all love it.

[Perenista]

For some reason the last MKVTOOLNIX version seems to disable partially dark mode from Windows 11 (last version, too). If you close and reopen the program it will work again.

Randomly it is disabling for no reason.

I took a screenshot from right now, showing this bug.

https://i.postimg.cc/PJkWJHGn/X1.jpg
https://i.postimg.cc/5yqwFr1Y/X2.jpg

And this is what we see if we close and reopen:

https://i.postimg.cc/wMSS77qT/SEMERRO1.jpg
https://i.postimg.cc/WpCR9fGL/SEMERRO2.jpg

Due to the nature of this problem I can't reproduce again. I don't know what is causing it. It wasn't like that in previous versions.

[clsid]

You're actually wrong in your assumption. Always taking the easier route instead just in order to avoid having to deal with complaints would have led to MKVToolNix being abandoned ten years ago or even earlier. Complaints are always loud, people often hate & change and the ones that really hate it complain very loudly. You know what I really, really loath wrt. programming? Having to deal with legacy technology. This includes, but isn't limited to, having to cater to operating systems that even their main provider doesn't support anymore.But this is not about using old or legacy code. It is a matter of excluding some parts of the Qt6 codebase. Parts that you probably aren't using (d3d12).

[Mosu]

But this is not about using old or legacy code. It is a matter of excluding some parts of the Qt6 codebase. Parts that you probably aren't using (d3d12).

If it's really as easy as adding -no-feature-d3d12 when building Qt 6, I may actually do that once the multi-display issues in Qt 6 have been ironed out.

[Mosu]

Looks like a bug caused by the transition to Qt 6 is the fact that the main MKVToolNix GUI window always opens on display 1, even if it was previously opened/closed on display 2 (assuming display 1 is to the left of display 2). Additionally, opening any context menus while the UI is on display 2 causes them to open on display 1.

Snowknight26, Qt 6.3.0 was just released. Can you please give this build (https://mkvtoolnix.download/windows/pre/64-bit/qt630-001/) a try wrt. to multi-display issues? It works fine on my multi-display Windows 11 system — but then again, so did release 67.0.0 (with Qt 6.2.4), meaning I currently don't have a system I can reproduce the multi-display issues on.

Thanks!

[Mosu]

But this is not about using old or legacy code. It is a matter of excluding some parts of the Qt6 codebase. Parts that you probably aren't using (d3d12).

And you're wrong about this, too:

Qt 6 doesn't support Windows 7 (https://doc.qt.io/qt-6/supported-platforms.html) anymore.
Qt 6's build system was completely rewritten. The configure tool doesn't exist anymore; therefore the "-no-feature-…" options don't apply. Looking for an equivalent "-DFEATURE_…" setting in the CMake files yields… nothing (e.g. "grep -r -i d3d12"). There simply isn't an option to disable Direct3D 12 anymore.

And that's the end of the amount of time I'm going to invest in Windows 7 support.

[Snowknight26]

Snowknight26, Qt 6.3.0 was just released. Can you please give this build (https://mkvtoolnix.download/windows/pre/64-bit/qt630-001/) a try wrt. to multi-display issues?

This build seems to have fixed all the multi-monitor issues I could find.

[Liisachan]

Windows 7 users:
To keep using Win7 is not the only options to avoid Win10. For example, you can use MKVToolnix GUI (and VLC) on Tails, just like you do on Win7. Tails is a Linux OS, designed for ordinary, privacy-oriented users. You can easily install this OS from Win7-64 into a USB stick (only taking 10 minutes, once you download the files). So I hope there will be no negative feelings for anyone... Win7 users can stop complaining and others can stop criticizing Win7, as Win7 & Tails can cleanly coexist.

In case someone is interested: To install MKVToolnix or anything personal on Tails, you'll need to unlock Persistent Storage and set up an admin password when starting Tails (which you can do easily in the login screen). Then, when it starts, open System Tools > Synaptic Package Manager, and search "mkv" to find "mkvtoolnix" and "mkvtoolnix-gui". Select them and click Apply, to install them (with dependencies).

They'll be installed in /usr/bin, so you can type this, in Terminal, to start GUI:
/usr/bin/mkvtoolnix-gui
Or to use mkvmerge:
/usr/bin/mkvmerge

The bad news is, the package installed this way (or via apt) is rather old (v31.0.0 as of writing this), though it does work. Hopefully one can get a newer version in the future.

Edit (2022-04-18): After installed, you can also start MkvtoolnixGUI via its icon under [Applications] (=something like "Start" button on Windows) -> Sound & Video. Terminal = something like "Dos box".

[Mosu]

This build seems to have fixed all the multi-monitor issues I could find.

Thanks for testing & the confirmation. I'll ask some of the other reporters for tests as well.

[jpsdr]

Sorry if it's a stupid question, but...

Is it :
a) All the files : mkvextract.exe, mkvinfo.exe, mkvmerge.exe, mkvpropedit and mkvtoolnix-gui.exe not Windows7 compatible.
b) Only mkvtoolnix-gui.exe.

If it's b), in that case, one possible solution, but not easy because it needs someone willing to do it, is "just" ;) to make another Windows7 compatible gui.
For example, there is gMKVExtactGUI made by GPower2. It works under Windows7, so finaly will the future mkvextract.exe version still be working under Windows7 ?
I don't exactly know (and so never used) what QT is, but the few i've understood (if i'm not wrong), it's just for GUI, so, only mkvtoolnix-gui is using it, so, if i'm still not wrong, the others programs should still work under Windows 7.
Correct me if i'm wrong somewhere.

Edit
Easier !!!!
If it's the case, you just have to overwrite mkvtoolnix-gui.exe of the new version with the latest working under Windows 7.
Crossing fingers... :D

[Mosu]

All programs use the Qt library. Qt 6 doesn't support Windows 7 officially. The only error I've seen so far references DirectX, though, and that one is GUI only, obviously, so the CLI tools might actually still run. If they do, it's accidental, not intentional.

[filler56789]

Sorry if it's a stupid question, but...

Is it :
a) All the files : mkvextract.exe, mkvinfo.exe, mkvmerge.exe, mkvpropedit and mkvtoolnix-gui.exe not Windows7 compatible.
b) Only mkvtoolnix-gui.exe.

Correct answer: a).

The exact error message complaining about a "procedure entry point not found" may vary, depending on how many updates your Windows 7 setup has (not) received.

Mosu thought it would be a good idea to replace the olde and goode file magic.mgc with a GUI-library which thinks ATRAC9 is Vorbis. :D
How good is that? :)

EDIT:
I wouldn't mind losing the GUI, but only the GUI, of the MKVtoolnix suite under Windows 7.
I wish there were alternative builds of MKVtoolnix (https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix-do-they-exist), but (so far) they don't exist :-/

[jpsdr]

Ok, so the last Windows 7 accidentaly working will probably be the 67.0.0.1, because for the next build, it will be using QT6.

[filler56789]

Ok, so the last Windows 7 accidentaly working will probably be the 67.0.0.1, because for the next build, it will be using QT6.

mkvtoolnix-64-bit-67.0.0-revision-027-gdedb7da46,
thus far.

[tebasuna51]

A difference between v67 and v66 is when you select Help -> System Information:

I'm using W10 v1607 and receive the message: "No problems were found with the installation.", but there are a new section not present in v66:
## Supported audio codecs

* AAC
* AC3
* ALAC
* EAC3
* FLAC
* MP3
* WMA

## Supported file formats

* AAC
* FLAC
* MP3
* MPEG4
* Matroska
* Mpeg4Audio
* QuickTime
* WMA
* WMV
* WebM

Is it a new limit about MkvToolNix support?
What about DTS, TrueHD, PCM, ...?

[filler56789]

A difference between v67 and v66 is when you select Help -> System Information:

I'm using W10 v1607 and receive the message: "No problems were found with the installation.", but there are a new section not present in v66:

## Supported audio codecs

* AAC
* AC3
* ALAC
* EAC3
* FLAC
* MP3
* WMA

## Supported file formats

* AAC
* FLAC
* MP3
* MPEG4
* Matroska
* Mpeg4Audio
* QuickTime
* WMA
* WMV
* WebM

Weird. :confused:

Using "version 67.0.0.27" under Windows 7 x64 and there is not a word about "supported codecs and formats". :confused:
# MKVToolNix

## General

* MKVToolNix GUI version: 67.0.0.27
* mkvmerge version: 67.0.0.27
* Installation type: portable
* Installation path: B:\COMMONAPPS\MKVTOOLNIX
* INI file location: B:\COMMONAPPS\MKVTOOLNIX\mkvtoolnix-gui.ini

## Installation problems

No problems were found with the installation.

# System

## Operating system
* Name: Windows
* Version: 6.1.7601
* Pretty name: Windows 7 Version 6.1 (Build 7601: SP 1)

## Screens

### Screen 0

* Device pixel ratio: 1
* Logical DPI: 96x96
* Physical DPI: 72.0355x72.0355
* Physical size: 677x381
* Virtual size: 1920x1080
* Geometry: 1920x1080@0x0

### Desktop scaling settings

* Scaling mode (`Win8DpiScaling`): not set
* Scaling override (`DesktopDPIOverride`): not set
* System-wide scale factor (`LogPixels`): not set

## Environment variables

* `LANG=en`
* `LANGUAGE=`
* `LC_ALL=`
* `LC_CTYPE=`
* `LC_MESSAGES=en`
* `MKVMERGE_DEBUG=`
* `MKVTOOLNIX_DEBUG=`
* `MTX_DEBUG=`
* `MTX_LOGGER=`
* `QT_AUTO_SCREEN_SCALE_FACTOR=`
* `QT_DEVICE_PIXEL_RATIO=`
* `QT_SCALE_FACTOR=`
* `QT_SCALE_FACTOR_ROUNDING_POLICY=`
* `QT_SCREEN_SCALE_FACTORS=`

# Qt

* Version: 5.15.3
* Build ABI: x86_64-little_endian-llp64

# Compiler and libraries

* Compiler: g++ 11.2.0
* Boost: 1.78.0
* cmark: 0.30.2
* dvdread: 6.1.2
* EBML: 1.4.2
* FLAC: 1.3.3
* fmt: 8.1.1
* Matroska: 1.6.4
* nlohmann-json: 3.10.5
* pugixml: 1.12.0
* Vorbis: Xiph.Org libVorbis 1.3.7
* zlib: 1.2.12

[Mosu]

That section is only present for versions compiled with Qt 6. It queries Qt 6 for the container formats & audio codec it (= the Qt library) supports. I did that due to v6 supporting different playback libraries than 5 on Windows (v5 goes through DirectShow for audio playback whereas v6 goes through WMF, and the latter doesn't supports neither Vorbis nor Ogg).

There are three things to know about this:

This only affects audio playback for the "run jobs" configuration in the preferences. It has no effect whatsoever on which formats mkvmerge supports for multiplexing.
Qt v5 simply doesn't support querying that information. That's why it hasn't been there before.
The list is somewhat incomplete and/or misleading. For example, Opus-in-WebM seems to work even if Opus isn't listed in the audio section.

I can see how having that list there is misleading, especially without all the other contextual information. I mostly wanted it to have there to make debugging easier (both for the user & for me — I often ask users to simply copy & paste & send me the system information content). I'll think about removing it again given its limited value, or adding a couple of lines explaining what it's used for.

[tebasuna51]

1. This only affects audio playback for the "run jobs" configuration in the preferences. It has no effect whatsoever on which formats mkvmerge supports for multiplexing

Good to know. Thanks.

[FranceBB]

Hi there,
I'm trying to mux a DolbyE track to mkv, it says "PCM" instead of "DolbyE".


If you want a DolbyE sample muxed in .wav and ready to be muxed in .mkv, take a look here (link expires in 7 days): https://we.tl/t-rIQuYtp4Mg


Anyway, this is what I'm trying to mux instead at work (which obviously I can't share):


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

I'm muxing the following video:



General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_1.m2v
Format : MPEG Video
Format version : Version 2
File size : 55.2 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 50.0 Mb/s

Video
Format : MPEG Video
Format version : Version 2
Format profile : 4:2:2@High
Format settings : BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=3, N=12
Format settings, picture structure : Frame
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 50.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.965
Time code of first frame : 06:14:59:13
GOP, Open/Closed : Closed
Stream size : 55.2 GiB (100%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709


with the following 4 audio tracks (DolbyE, DolbyE, PCM, PCM):

Track 1:

General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_2.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio #1
ID : 1
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 1 291 kb/s
Channel(s) : 6 channels
Channel layout : L C Ls X R LFE Rs X
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 1.42 GiB (56%)

Audio #2
ID : 2
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 505 kb/s
Channel(s) : 2 channels
Channel layout : X X X L X X X R
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 571 MiB (22%)



Track 2:


General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_3.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio #1
ID : 1
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 1 291 kb/s
Channel(s) : 6 channels
Channel layout : L C Ls X R LFE Rs X
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 1.42 GiB (56%)

Audio #2
ID : 2
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 505 kb/s
Channel(s) : 2 channels
Channel layout : X X X L X X X R
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 571 MiB (22%)




Track 3:


General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_4.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 2.54 GiB (100%)




Track 4:


General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_5.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 2.54 GiB (100%)





and it detects it as PCM instead:

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


Don't get me wrong, the file is muxed as is, but it would be nice to show the right codec there as DolbyE rather than PCM. :)

for more samples (very very short, few seconds) which do not expire, check this:

Sample1: Link (https://user-images.githubusercontent.com/18946343/140714877-ca9ab507-b8a1-4738-af1d-0bcc61bc99df.mov)

Sample2: Link (https://user-images.githubusercontent.com/18946343/140722392-a623950a-8248-4863-9ef8-0d70b6c86236.mov)

Sample3: Link (https://user-images.githubusercontent.com/18946343/140723130-8c0ba961-a98c-41c3-a293-d6494b3a18ee.mov)

[Mosu]

Dolby E is simply not supported.

[FranceBB]

Dolby E is simply not supported.

I see... Will it be supported in the future? :)

[Mosu]

Given that it's a format that is explicitly NOT wanted on the devices of end users: unlikely.

[filler56789]

..........
Don't get me wrong, the file is muxed as is, but it would be nice to show the right codec there as DolbyE rather than PCM. :)

+1.
Unsupported formats should be detected as unsupported formats,
not misdetected as supported formats. :sly:

Maybe I should test older versions of MKVtoolnix to see if the misdetection was already present in the goode and olde magic.mgc or if it was introduced by the almighty :rolleyes: Qt.

[tebasuna51]

Here I'm with Mosu, MkvToolNix works perfectly loading these wav files like PCM, if they are like the sample upload by FranceBB: Test_DolbyE.wav

The file have a correct wav header than say:

File: D:\Temp\Test_DolbyE.wav
Size: 2730401360 bytes
---------------------------------------------- Header Info
ChunkID .....: RIFF
RiffLength ..: 2730401352
Container ...: WAVE
SubchunkID ..: JUNK (Length: 28) [filled with 0's]
SubchunkID ..: fmt (Length: 16)
AudioFormat .: 1 (Integer)
NumChannels .: 2
SampleRate ..: 48000
ByteRate ....: 288000
BlockAlign ..: 6
BitsPerSample: 24
SubchunkID ..: data (Length: 2730401280)
Offset data .: 80
Duration ....: 9480.56 sec., (2h. 38m. 0.56s.)
------------------------------------------------- End Info

This is a perfect 2h. 38m. 0.56s. of noise PCM stereo, 24 bits, 48 KHz.

I don't know how MediaInfo can detect than this is Dolby E, but can't be stored with a fake INT wave header.

Wav is a container but if the data is not PCM INT the AudioFormat can't be 0x0001
For instance for:
Dolby AC2 Audioformat: 0x0030
Dolby AC3 SPDIF Audioformat: 0x0092
Maybe we need a new one for Dolby E

[manolito]

Which is the last MKVToolNix version which runs without issues under Win7 ? I'm not asking for official Win7 support, I just want to know which version is the last one without any known Win7 problems. I have no intention to upgrade Windows to a later version than Win7, so I just want to know which MKVToolnix version will become my last version.


FWIW I just updated the older archive with the last XP compatible version of MKVToolNix with the latest Win7 compatible version (32-bit only). The download link is here:

https://files.videohelp.com/u/172211/ToolNix_XP_Win7.zip


Cheers
manolito

[filler56789]

This is a perfect 2h. 38m. 0.56s. of noise PCM stereo, 24 bits, 48 KHz.

I don't know how MediaInfo can detect than this is Dolby E, but can't be stored with a fake INT wave header.

By analyzing/probing the stream itself, I guess...

Isn't DTS-in-WAV also read as "PCM noise" by the "unaware decoders"? :confused:

FWIW:

https://wiki.multimedia.cx/index.php/DTS

AND

https://wiki.multimedia.cx/index.php/Dolby_E

[FranceBB]

Isn't DTS-in-WAV also read as "PCM noise" by the "unaware decoders"? :confused:


Yep, it is. Unaware decoders will read it as noise 'cause they're gonna believe it's PCM and will try to decode it as is.

This is the official Dolby E Document: https://developer.dolby.com/globalassets/professional/dolby-e/dolby-e-high-level-frame-description.pdf

About Mediainfo detection, see here:

https://github.com/MediaArea/MediaInfoLib/blob/d5fb067e1539aa7a74c491e8262c81214f9c8bcb/Source/MediaInfo/Audio/File_DolbyE.h

https://github.com/MediaArea/MediaInfoLib/blob/7da9e111263496185627bbfb32e654842fb8cb9b/Source/MediaInfo/Audio/File_DolbyE.cpp

https://github.com/MediaArea/MediaInfoLib/blob/75adb6f8b3dc59f521344fe81055834047d88d3b/Source/MediaInfo/Audio/File_DolbyAudioMetadata.cpp

https://github.com/MediaArea/MediaInfoLib/blob/d5fb067e1539aa7a74c491e8262c81214f9c8bcb/Source/MediaInfo/MediaInfo_Events_Internal.h

About samples, I can share as many samples as you want. :)

[Mosu]

Just to make it clear: I won't be spending any time on Dolby E.

[FranceBB]

Just to make it clear: I won't be spending any time on Dolby E.

Would a donation change your mind? You know, just saying, hypothetically... :D

[Mosu]

No, it wouldn't.

[tebasuna51]

By analyzing/probing the stream itself, I guess...

Isn't DTS-in-WAV also read as "PCM noise" by the "unaware decoders"? :confused:

For what analyze the well defined data as PCM INT?

The dts-wav files have a unique use: cheat the CD burner to create a CD Audio than some (not all) players can send like dts multichannel streams by spdif to AVR's
Correct (not "unaware decoders") must play the dts-wav's files like noise.
It's easy extract the correct .dts file (with less size also) from a dtswav and use it to play correctly with standard players.

The correct way to store a DTS in wav container is use the AudioFormat 0x0008

This is the official Dolby E Document: https://developer.dolby.com/globalassets/professional/dolby-e/dolby-e-high-level-frame-description.pdf

Nothing about store Dolby E in WAV files.

About Mediainfo detection, see here:

I'm not interesed in what MediaInfo do, it is not a audio reference for nobody. MediaInfo show wrong data with many audio files.

If we use the WAV container must follow the M$ rules, and put an AudioFormat different.

I suggest use 0xDB0E or 0x0DBE (DolBy E, like 0xF1AC is used for FLAC) not in use in 1998 RFC 2361 (https://datatracker.ietf.org/doc/html/rfc2361), also not used in last mmreg.h (https://github.com/tpn/winsdk-10/blob/master/Include/10.0.14393.0/shared/mmreg.h) I know

[tormento]

@Mosu

Talking about audio formats, why does Dolby Digital Plus is still recognized as AC-3 and not EAC-3?

Moreover, unlike AC-3, it can have a core (or not) and ATMOS metadata, such as THD. They are two different beasts on their own.

[filler56789]

@Mosu

Talking about audio formats, why does Dolby Digital Plus is still recognized as AC-3 and not EAC-3?

Moreover, unlike AC-3, it can have a core (or not) and ATMOS metadata, such as THD. They are two different beasts on their own.

I have just tested the latest GUI with a .EAC3 elementary stream and it says:

"container = AC-3, codec = E-AC-3".

For me the distinction is good enough. :)

[jpsdr]

mkvtoolnix-32-bit-67.0.0-revision-033-g39529c226-setup so far so good... ;)

[manolito]

Thanks for the heads-up...

This version still supports Win7 (only tested the 32-bit version). Nice...

[Liisachan]

Maybe we should stop annoying Mosu directly or indirectly, who had made it clear, as early as 2019, that Win7 was no more actively supported.

If your main machine is Win7 64-bit, and you want to use MKVToolnix67+, you could try Tails.


You can keep using Win7, while booting to Tails only when necessary. It's not a VM but runs on its own, so it runs on Win7 box like forever (unlike Cygwin, which will eventually stop supporting Win7).
You can install Tails in 10 minutes, very easily, once you download a big image.
Both mkvmerge (CUI) and GUI run on Tails, which is a Debian-based OS.
Tails's file manager can read/write files on your Win7 box, so basically you don't need to migrate to Linux.
If you're avoiding Win10 for privacy concerns, Tails is exactly for you.
Tails is designed for ordinary people. It's easy to use. You don't need to be a geek. You don't need to manually compile anything yourself.
Except, as of writing this, you can't install the latest version of MKVToolnix on Tails via Package Manager by default. But you're happily using Win7, a 10-year-old OS! Why a sudden attachment to the newest version of mkvmerge, when the created MKV is essentially identical even if you use an older mkvmerge? If you're ok with a slightly old version of MKVToolnix, then you can have it on Tails by just a few clicks.


https://yosei.fi/aaa/mkvtoolnix67_on_tails_sm.jpg (https://yosei.fi/aaa/mkvtoolnix67_on_tails.png)

The screen shot shows MKVToolnix 67 (GUI & CUI on terminal) on Tails, running on my Win7-64 box. Notice the file manager's "Show other locations". Click it, and you can use your files on HD/SSD, although Tails itself runs from a USB stick. Tails' i/f is basically like Windows. Since it's Debian, your Windows tools don't run on it. But you can use the same audio/video/subtitle files on your HD, so you can basically use mkvmerge just like on Windows :)
This may be a practical option in case you want to use a newer version of mkvmerge (although personally, I usually don't use too new versions, except for testing purpose).

[StainlessS]

If your main machine is Win7 64-bit, and you want to use MKVToolnix67+, you could try Tails.

Just a word of warning,
Just searching for Tails in a browser, has been known to attract attention of FBI/NSA and other nefarious nasties. [EDIT: They dont like it if they cant spy on you]

A couple of quotes from Wikipedia [which could attract unwanted attention just by visiting, I do not include the link]
Laura Poitras, Glenn Greenwald, and Barton Gellman have each said that Tails was an important tool they used in their work with National Security Agency whistleblower Edward Snowden.
Security incidents

In 2014 Das Erste reported that the NSA's XKeyscore surveillance system sets threat definitions for people who search for Tails using a search engine or visit the Tails website. A comment in XKeyscore's source code calls Tails "a comsec [communications security] mechanism advocated by extremists on extremist forums".

In the same year, Der Spiegel published slides from an internal National Security Agency presentation dating to June 2012, in which the NSA deemed Tails on its own as a "major threat" to its mission and in conjunction with other privacy tools as "catastrophic".

EDIT: But I gotta try it one day.

[Liisachan]

Just a word of warning,
Just searching for Tails in a browser, has been known to attract attention of FBI/NSA and other nefarious nasties. [EDIT: They dont like it if they cant spy on you]

Obviously, you'll only use a privacy aware search engine, e.g. MetaGer, DDG, Searx, and use it via Tor, preferably via .onion. That's the whole point of Tails.

The privacy risk is 100 times bigger if you just use Google, or Windows 10. That's why you don't like to use Windows 10 in the first place, right?

[StainlessS]

Obviously, you'll only use a privacy aware search engine
Yep, but maybe some without any of those might try to search for Tails just to see what it is.

EDIT:
I might give MetaGer a try, looks ok. [although I'm not gonna bother with the Tor stuff], and I presume that DDG is DuckDuckGo.

[StainlessS]

Further to above,
Tails is just a more privacy secure version of Linux, I dont see any reason that some other version of Linux cannot be used instead,
and still retain access to Windows 7 partitions via MkvToolNix.
I have a separate Linux [Cinnamon Mint] install on external hard drive (also have Linux on SSD alongside Windows 10), via a USB 3.0 hard drive dock [rather than flash drive].
I use it [external Linux OS] for any emergency operating system fix, or whatever purposes.
Best to disable all internal drives in firmware [EDIT: INCLUDING boot NVMe SSD if you have one] before install [to ensure that you write Grub bootloader to your removable drive],
will ensure you can boot without any other drives at all. [even if internal drive bootloader is wiped]

I only use an old slow 60GB 2.5 inch drive in my dock for linux boot drive, so is probably slower than it could be, but probably faster
than a lot of Flash Drives. The hard drive dock I use, has been seen to write up to about 180MB/s, but not on the
linux 2.5" boot drive, on some other 3TB drive in the dock.

The HDD dock I use was purchased about 2 months ago, and I am delighted with it. Supports up to 2 x 16TB drives at once
[my external boot linux OS can boot from either of the 2 dock drive bays, GPT EFI install partition, I think], although I have only tried with 2x3TB drives [max size drives I have].
Drives tested include 3 x 3TB Hitatchi and 2 x 3TB Seagate NAS drives, also works just fine with WD drives
[a lot of docks have problems with Western Digital drives, 2 of my docks will not read any WD drives I've tested]

I have 4 HDD docks, but this is defo my favourite [SATA only, 2 others also have 3.5" and 2.5" IDE],
[B]FIDECO Aluminum Hard Drive Docking Station, USB 3.0 Docking Station for 2.5 and 3.5 inch SATA HDD or SSD, Support Offline Clone and 2x 16TB Hard Drives
https://www.amazon.co.uk/gp/product/B075TZJMWW/ref=ppx_yo_dt_b_asin_image_o09_s00?ie=UTF8&psc=1
The RED USB port alongside the two Blue ports is for Charge Only [eg charge your phone, or some kind of external power], it cannot be used
for eg Flash drive.

Also, I use 2.5" hard drives for a number of other boot tools, eg System Rescue Disk, and Macrium Reflect [OS Imager], and also FoxClone,
and other tools.
I tried install of Andoid on external drive but not a great deal of success so far, too much OS crashing.

[Liisachan]

1/ Re: --enable-legacy-font-mime-types
Finally tested the new "legacy font" option (v67.0.0). It works mostly, except when transmuxing MKV to MKV, "application/font-sfnt" written by mkvmerge v26 on Mac, is not fixed.

2/ A possible cosmetic issue. On GUI, when a job is done, the right progress bar goes to 100%. Maybe this should be reset to 0% when a new job is added, since the new job(s) are done 0% now. Especially, when you "Remove completed jobs" or "Remove all jobs", the progress bar should be cleared. Cosmetic, but potentially confusing.

@StainlessS
You're right. Tails is not really convenient for MKVToolnix, nor would I recommend it for a permanent platform for doing something video related. It's just that an ordinary user can try it out easily.

If (like myself) someone doesn't want to use Win10, then they should start looking for a third way, not just keeping using Win7. Otherwise they may be eventually forced to use Win10+, not having any other options... Yes, DDG is ddg.gg & Tails automatically uses Tor for every Internet connection, which may be good for privacy/anonymity but mostly irrelevant to using MKVToolnix locally :)

[filler56789]

If (like myself) someone doesn't want to use Win10, then they should start looking for a third way, not just keeping using Win7.

Ideally there should exist a fourth way. :)
Namely, someone :) who could build MKVtoolnix

1) either with Qt 5 "forever" OR
2) with Qt 6 or higher, but only for the GUI, nor for the CLI executables OR
3) without the GUI and without Qt at all.

As I said before, I surely am not the only user who wouldn't mind losing MKVtoolnix's GUI if the CLI .exes kept working under Windows 7. But it sucks that apparently there is nobody who has ever made "non-official" or alternative builds of MKVtoolnix.

[Mosu]

1/ Re: --enable-legacy-font-mime-types
Finally tested the new "legacy font" option (v67.0.0). It works mostly, except when transmuxing MKV to MKV, "application/font-sfnt" written by mkvmerge v26 on Mac, is not fixed.

I'll look into it.

2/ A possible cosmetic issue. On GUI, when a job is done, the right progress bar goes to 100%. Maybe this should be reset to 0%…

No, it should stay at 100%. I did have it reset to 0% way back when, and users complained that they were confused if anything had happened at all for faster jobs.

[Atak_Snajpera]

It really sucks that even CLI tools stopped working on win7. I guess I will have to stop updating mkvtoolnix in ripbot264...

Ps. I hope FFMPEG/x264/x265... builds won't go the same route in future!

[jpsdr]

That's it, here we are !
mkvtoolnix-32-bit-67.0.0-revision-052-g5d20c6052-setup is the last one working under Windows 7, at least about the GUI, i don't know about the CLI for the others versions.

[filler56789]

That's it, here we are !
mkvtoolnix-32-bit-67.0.0-revision-052-g5d20c6052-setup is the last one working under Windows 7, at least about the GUI, i don't know about the CLI for the others versions.

Version 67.0.0.53 is working here. :-/

Version 67.0.0.54 returns the well-known "procedure entry point not found in the blah-blah-blah.DLL".

[jpsdr]

Not for me the 53, error message, but i'll try under Win7 x64, for now i've just tried under Win7 x86.
After, try : install the last version, and replace the .exe GUI with the last working, maybe the cli will still work.

[hubblec4]

Version 67.0.0.53 is working here. :-/

Version 67.0.0.54 returns the well-known "procedure entry point not found in the blah-blah-blah.DLL".


For me works version 0.52. Version 0.53 don't work.

[jpsdr]

It's not just the GUI, even CLI are not working anymore. So it was expected, now it has hapened.

[filler56789]

For me works version 0.52. Version 0.53 don't work.

Probably because your Windows 7 is (much) more "up-to-date" than mine :-|
(only 25 updates since 2016 thus far)

EDIT:

67.0.0.60 is good again.

[hubblec4]

It really sucks that even CLI tools stopped working on win7. I guess I will have to stop updating mkvtoolnix in ripbot264...


Maybe you can create a patch like your Win7 install.

I have copied the "blah-blah-blah.DLL" from a Win10 to Win7 and there is no warning more, but MTX don't start. I guess other files have to be copied also.

[Dogway]

67.0.0.60 works here too for Win7 x64 SP1, updates up to early 2015. FYI no antivirus either and the PC hasn't exploded or anything :D
Looks like we are quite a few Win7 users around here. Has ffmpeg any drawbacks for MKV remux compared to toolnix?

[jpsdr]

I think we can stop counting the Win7 working versions here (61 is good also), i may have begun but i didn't thought there was so much continuous release, so it may create a lot of not realy usefull posts here.
Maybe create a MKVToolnix Windows 7 "The final countdow" dedicated thread... ;)

[von Suppé]

Hi Mosu,

quietvoid's dovi_tool now has the option to mux Dolby Vision's baselayer and enhacement layer together in one dual layer hevc stream. This resulting hevc stream can be imported and muxed with MKVToolnix as a singletrack, duallayer Dolby Vision mkv.

Contrary to when having remuxed a MakeMKV-created file (where I understand the videoinfo is written and copied in container-level metadata), MediaInfo shows no Dolby Vision properties on the videostream of the mkv.
Would it be possible to get MKVToolnix recognizing the properties of these kind of streams so that during muxing the right headers/metadata are written?

[Mosu]

Technically? Sure, but I'm not really interested in spending time on Dolby Vision at the moment. If you want me not to forget about it, please open an issue for it. Thanks.

[quietvoid]

Contrary to when having remuxed a MakeMKV-created file (where I understand the videoinfo is written and copied in container-level metadata), MediaInfo shows no Dolby Vision properties on the videostream of the mkv.

That doesn't sound right, mkvmerge should still add the metadata to the track.
It works for me when muxing the HEVC directly:

| + Block addition mapping
| + Block addition ID name: Dolby Vision configuration
| + Block addition ID type: 1685480259 (dvcC)
| + Block addition ID extra data: length 24, data: 0x01 0x00 0x0e 0x37 0x60 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00…

HDR format : Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible

There's just the extra HEVC decoder config block that's missing, as expected.

[Mosu]

Yeah, but that might not happen when remuxing from Matroska to Matroska, depending on… things. CodecPrivate exists already in that case and might not be recreated.

[von Suppé]

That doesn't sound right, mkvmerge should still add the metadata to the track.
It works for me when muxing the HEVC directly:
Do you use the mkvmerge.exe (CLI)? I'm working in the MKVToolnix GUI.

[quietvoid]

Do you use the mkvmerge.exe (CLI)? I'm working in the MKVToolnix GUI.

I use both, and they're supposed to both be calling mkvmerge AFAIK.
Can you clarify what your muxed source is? HEVC or Matroska?

[von Suppé]

I use both, and they're supposed to both be calling mkvmerge AFAIK.
Can you clarify what your muxed source is? HEVC or Matroska?
The BL_EL_RPU.hevc output stream directly from your dovi_tool after having muxed together BL and EL.
I'm using this code, no more:

dovi_tool mux --bl BL.hevc --el EL.hevc

[quietvoid]

The BL_EL_RPU.hevc output stream directly from your dovi_tool after having muxed together BL and EL.
I'm using this code, no more:

dovi_tool mux --bl BL.hevc --el EL.hevc

I can't reproduce your issue. MKVToolNix adds the Dolby Vision block for me.

[von Suppé]

Weird. Maybe you're using another version? I'm using MKVToolnix v67.0.0.63 on Win7 64 bit.

[quietvoid]

Shouldn't matter, mine is mkvtoolnix-gui v67.0.0 ('Under Stars') 64-bit.
You should make sure there are actually RPUs in the EL you're muxing.

If there are, then probably best to make an issue at MKVToolNix.

You can confirm this by using --debug dovi_configuration_record when muxing, which should dump the dovi_rpu_data_header and dovi_decoder_configuration_record.

[von Suppé]

You can confirm this by using
--debug dovi_configuration_record
when muxing...

Thank you. To be clear, I set this in "Miscellaneous box, additional options" yes?

[quietvoid]

Thank you. To be clear, I set this in "Miscellaneous box, additional options" yes?

Yea that works. It'll show up in the job output.

[von Suppé]

Didn't work. It gets weird though. I tried with version 62.0.0 and success... I'm now suspicious MKVToolnix not running 100% properly on Windows 7. Or better said, latest version on my Windows 7 pc. Mosu more than once mentioned that if it works on Windows 7, it's not by design. For now, I will continue to work with this version to import your tool's hevc.

When I have time (too busy now) I'll boot into Ubuntu and install latest MKVToolnix & try from there. Thanks for your help and my apologies for wasting some of your time, @quietvoid.

[Mosu]

FYI: there have been no changes at all to the h.264, h.265 or DoVi code in MKVToolNix between releases 66 & 67.

[von Suppé]

Ok. I must say I've been happily using till version 67.0.0.63 without any issues, until now with this specific dovitool's thing. I do harbour a healthy doubt now concerning my Windows 7 pc. The installation date is from a few years ago and a lot has been done with it since.
As said, when there's time to try things out in Ubuntu I'll also make effort to restore an image of a clean Win7 installation and see if that would make a difference.
Thanks.

[tormento]

Is it possible to "remove" a timecode from a file, created with a buggish software?

I mean, if I know that the frame rate is constant, how can I remove the variable frame rate flag and apply the correct constant one?

Edit: please something more elegant than demux to elementary streams and remux again :)

[Liisachan]

Is it possible to "remove" a timecode from a file, created with a buggish software?
No, every MKV file is technically VFR. Even a 25-fps, completely CFR Matroska (with a rational 40 ms/frame rate) has internal timecodes for each frame.

The good news is, you can always fix bad time stamps, simply by re-feeding a correct timecode file.

Also, mkvmerge has an option --fix-bitstream-timing-information, which, in ideal world, would fix time stamps. You may want to try it too see if it works for you. Although generally this option doesn't work too well and it's known that Mkvmerge itself may write less-than-ideal time stamps due to internal rounding errors, the resulted file might be practically acceptable, nevertheless.

Edit: please something more elegant than demux to elementary streams and remux again :) While remuxing is unavoidable, you'll only need to add a new timecode file, mostly painless. That's a sure-fire way. Also, in an ideal case, you'll just enable --fix-bitstream-timing-information (the result of this 2nd method may be practically good enough, if you're lucky).

[tormento]

While remuxing is unavoidable, you'll only need to add a new timecode file, mostly painless.
And what is a nice and clean way to create a new timecode file, once I know fps and length?

[Mosu]

Heyo!

Here's MKVToolNix v68 in which a lot of work has gone into replacing the icons in the GUI with scalable versions (SVG instead of PNG), improving support for odd scaling factors such as 125%.

A note to for package maintainers: due to the aforementioned change Qt's SVG library is now required.

A note for Raspberry Pi users: please migrate to using my Debian repository (https://mkvtoolnix.download/downloads.html#debian) instead of the Raspbian repository I used to host. The Debian binaries are now available for the armhf architecture, removing the need for a Raspbian-specific repository.

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 68.0.0 "The Curtain" 2022-05-22
New features and enhancements

mkvmerge: HDMV PGS subtitles: mkvmerge now tries to detect bogus timestamps (where the current timestamp is two hours or more after the previous timestamp) & correct them to something more sensible (1s after the previous timestamp). That way one bogus timestamp cannot cause the rest of the frames to not be interleaved properly with the other audio & video packets. Implemented for #3268 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3268).
mkvmerge: added colour information, colour mastering meta information & video projection information properties to the JSON identification format. The properties are reported for container types for which mkvmerge supports reading them (Matroska & MP4). The JSON identification format version number has been bumped to v15.
MKVToolNix GUI: multiplexer: added controls for all the video colour information & the video projection information.

Bug fixes

mkvmerge: SRT reader: entries with a duration of 0 or less will now be skipped. Fixes #3332 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3332).
mkvpropedit, MKVToolNix GUI's chapter & header editors: fixed an invalid memory access when trying to update existing Matroska files whose EBML Head element had a "size" field length of eight bytes, and where rewriting said element would shrink the element by one byte. Files created by gstreamer fit the first part whereas the second depends on the changes requested by the user. Part of the fix of #3325 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3325).
mkvpropedit, MKVToolNix GUI's chapter & header editors: fixed the programs not handling having to remove EBML void elements at the end of the file correctly and consequently aborting. Part of the fix of #3325 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3325).
MKVToolNix GUI: the GUI now uses almost all SVG icons, allowing proper scaling even for scaling factors such as 125%. Fixes #3335 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3335).
MKVToolNix GUI: when compiled with Qt 5 the character set of INI files is forced to UTF-8 in order to fix reading INI files written by a version compiled with Qt 6. Fixes #3346 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3346).

Build system changes

Qt's SVG library is now required.


Have fun 😁

[manolito]

Looks like latest version works under Win7 again?

[VBB]

Thank you Moritz. Looks great!

[ntropy]

Using v68.0.0 64-bit to append _t15.mkv and _t16.mkv together found on this page (https://archive.org/download/doctor-who-jon-pertwee-disc-1-terror-of-the-autons-t-01/Disc%201/).


But there's a video freeze during playback of the resulting mkv in MPC-HC 1.9.19 on Win10 and in Kodi 19.0 on Nvidia Shield. Are they just bad .mkv's and not appendable? It looks like they are from a blu-ray of a seamless branching title offering an episode with and without 2020 VFX added to a 1971 program. So shouldn't mkv's from a seamless blu-ray be appended seamlessly?

[73ChargerFan]

Seeking / timing problems

I've got an m2ts file extracted with AnyDVD, 24.000 fps avc, dts-ma, that when remuxed won't seek properly. I'm using v68.0.0 & MPC-HC 1.9.21.2.

The source file, when played in MPC-HC, works fine and I can seek back and forth without problems. But seeking the mkv file often scrambles the video, glitches, pauses, and can take 3-6 seconds to recover.

I've tried remuxing directly from the m2ts file, using both MKVToolnix & eac3to, and also from the "00021 - 2 - h264, 1080p24.h264" extracted with eac3to. Each time I get the same result. I have no experience with the ffmpeg muxer so I didn't try it.

I've tried combinations of setting FPS to be 24p, enabling "fix bitstream timing info", and all the Indexing options. Audio is ignored and not copied for now.

The m2ts plays fine. Is it the remux process, or do you think its an unrecoverable glitch caused by AnyDVD?

Any ideas on how to correct the timing / seeking? This isn't the first time I've encountered this, and I'd really like to learn something new and fix it without re-encoding.

Thanks! And Thank You Mosu!

P.S. I re-encoded a 5 minute sample with HandBrake, and there's no image corruption and I can seek fine, so I think it can correctly read the video stream.

[tormento]

I am dealing with an anime box where unfortunately all the episodes are part of the same m2ts and there are chapters only to know when the parts start.

I have split the episodes by main chapters and the keyframes are not exactly where they should. The problem anyway is not the video, but the audio tracks that present different delays.

To batch the muxing of the encoded tracks, I would usually launch something like:

for /R %%a in (*.mkv) do D:\Eseguibili\Media\MKVToolNix\mkvmerge.exe --output ^"g:\Out\%%~na.mkv^" --no-chapters --language 0:ja ^"^(^" ^"%%~na.mkv^" ^"^)^" --sync 0:7 --language 0:it ^"^(^" ^"%%~na [ita] DELAY 7ms.eac3^" ^"^)^" --sub-charset 0:UTF-8 --language 0:it --track-name 0:F --forced-display-flag 0:yes ^"^(^" ^"%%~na [ita] F.ass^" ^"^)^" --sync 0:7 --language 0:ja ^"^(^" ^"%%~na [jpn] DELAY 7ms.eac3^" ^"^)^" --sub-charset 0:UTF-8 --language 0:it ^"^(^" ^"%%~na [ita].ass^" ^"^)^" --attachment-name ^"Trebuchet MS.ttf^" --attachment-mime-type font/ttf --attach-file ^"F:\Raw\— ttf\Trebuchet MS.ttf^" --attachment-name ^"Trebuchet MS italic.ttf^" --attachment-mime-type font/ttf --attach-file ^"F:\Raw\— ttf\Trebuchet MS italic.ttf^" --chapter-language it --chapters ^"%%~na chapters.txt^" --track-order 0:0,1:0,2:0,3:0,4:0

but I can't find a way to make it aware to change the delay based on audio file and change the audio file name itself to follow the different delays.

Is there someone who is smart enough to find a proper solution?

Mosu, could you create a "wildcard" or some way to batch mux a video file with the corresponding tracks, according to some syntax, as I did?

01.mkv is the video
01 [language] delay XX ms.ec3 are the DD+ audio tracks
01 [language].sup are the subs
01 chapters.txt is the OGM chapter file

It is something typical when dealing with bd boxes, a solution would be useful to everybody.

EDIT: I created the BAT file

for /R %%a in (*.mkv) do D:\Eseguibili\Media\MKVToolNix\mkvmerge.exe --output ^"g:\Out\%%~na.mkv^" --no-chapters --title ^"^" --language 0:ja ^"^(^" ^"%%~na.mkv^" ^"^)^" --sync 0:%1 --language 0:it ^"^(^" ^"%%~na [ita] DELAY %1ms.ec3^" ^"^)^" --sub-charset 0:UTF-8 --language 0:it --track-name 0:F --forced-display-flag 0:yes ^"^(^" ^"%%~na [ita] F.sup^" ^"^)^" --sync 0:%1 --language 0:ja ^"^(^" ^"%%~na [jpn] DELAY %1ms.ec3^" ^"^)^" --sub-charset 0:UTF-8 --language 0:it ^"^(^" ^"%%~na [ita].sup^" ^"^)^" --attachment-name ^"Trebuchet MS.ttf^" --attachment-mime-type font/ttf --attach-file ^"F:\Raw\— ttf\Trebuchet MS.ttf^" --attachment-name ^"Trebuchet MS italic.ttf^" --attachment-mime-type font/ttf --attach-file ^"F:\Raw\— ttf\Trebuchet MS italic.ttf^" --chapter-language it --chapters ^"%%~na chapters.txt^" --track-order 0:0,1:0,2:0,3:0,4:0

and I call it with "test.bat xx" where xx is the delay but I won't consider it a universal and elegant solution.

[hubblec4]

How important is it for you to split physical the episodes?


I would prefer ordered-linked-chapters-mkv's per episode if you want to have separated episode-files. This is a virtual cut method and with the correct player it always works.

[tormento]

How important is it for you to split physical the episodes?
It's easier to manage.
I would prefer ordered-linked-chapters-mkv's per episode
I do not understand what you mean.

[hubblec4]

You can play each episode separate without splitting the big.mkv(all episodes).

Create an mkv for each episode with chapters only, yes only the chapters are needed for this feature.

The simplest way is to uses only one chapter.
For episode one:
Start time 0s - end time 20min (or how ever the end time of episode one is)

Set a SegmentUID: this is the SegmentUID from the big.mkv. In cE and in ChapterEditor by MTX you can load the mkv and the UID is extracted automatically.
This UID is used for all other chapters too.

Save the chapters to the usual xml-format, then load this chapter file to a blank MTX muxing tab -> output and mux the mks to the folder with the big.mkv.

Play the mks file with MPC-HC and only episode one is used.

You can now create all the other episode.mks files, change the start and end time frame exactly.

[FranceBB]

I found a bug in v68.0.0
This is a pcm_s24le file muxed in .mxf


General
Complete name : \\Avisynth Server 3\Masterfiles\hitch_sdr_sky_italy\IMF10544357_HITCH_2D_D_UHD_LB240_XVYCC_2398_TXT_ITA_ITA_DS.mxf
Format : MXF
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 2.03 GiB
Duration : 2 h 6 min
Overall bit rate : 2 304 kb/s
Package name : Material Package / File Package: SMPTE 382M clip wrapping of wave audio
Encoded date : 2022-05-03 22:45:04.940
Writing application : Rohde and Schwarz Clipster 6.9.1.0.1
Writing library : Windows 8 (64-bit) 2.38.0.20411.1

Audio
ID : 2
Format : PCM
Format settings : Little
Format settings, wrapping mode : Clip (BWF)
Codec ID : 0D01030102060200
Duration : 2 h 6 min
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Channel layout : Lt Rt
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 2.03 GiB (100%)
Title : FP Sound track
Language : Italian
Locked : Yes
MCA Title : MCA Title
MCA Title Version : MCA Title Version
MCA Audio Content Kind : MCA Audio Content Kind
MCA Audio Element Kind : MCA Audio Element Kind

Other #1
ID : 1-Material
Type : Time code
Format : MXF TC
Frame rate : 24.000 FPS
Time code of first frame : 00:59:30:00
Time code of last frame : 03:05:44:21
Time code settings : Material Package
Time code, striped : Yes
Title : Timecode track

Other #2
ID : 1-Source
Type : Time code
Format : MXF TC
Frame rate : 24.000 FPS
Time code of first frame : 00:59:30:00
Time code of last frame : 03:05:44:21
Time code settings : Source Package
Time code, striped : Yes
Title : Timecode track



When I drag and drop it in MKVToolnix however it gets displayed as H.264 for some reason:

https://i.imgur.com/0AIZVgI.png

and the remuxed file is completely wrong:

General
Unique ID : 79386411615199042806034007473513494999 (0x3BB9444876D722A7164F3ED7BC92F9D7)
Complete name : \\Avisynth Server 3\Masterfiles\test.mkv
Format : Matroska
Format version : Version 4
File size : 2.23 GiB
Duration : 50 min 24 s
Overall bit rate : 6 321 kb/s
Encoded date : UTC 2022-06-27 09:38:10
Writing application : mkvmerge v68.0.0 ('The Curtain') 64-bit
Writing library : libebml v1.4.2 + libmatroska v1.6.4

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Codec ID : V_MPEG4/ISO/AVC
Duration : 50 min 24 s
Bit rate : 6 321 kb/s
Width : 16 pixels
Height : 16 pixels
Display aspect ratio : 1.000
Frame rate mode : Variable
Frame rate : 0.247 FPS
Bits/(Pixel*Frame) : 99965.969
Stream size : 2.23 GiB (100%)
Default : Yes
Forced : No


however trimming and muxing it with FFMpeg first in mkv and then re-muxing it in mkv with MKVToolnix works:

General
Unique ID : 339212212735179089857451465021233800334 (0xFF31E55334695FF13DF67BBBE98BA48E)
Complete name : \\Avisynth Server 3\Masterfiles\trim.mka
Format : Matroska
Format version : Version 4
File size : 287 KiB
Duration : 1 s 0 ms
Overall bit rate mode : Constant
Overall bit rate : 2 353 kb/s
Encoded date : UTC 2022-06-27 09:47:45
Writing application : mkvmerge v68.0.0 ('The Curtain') 64-bit
Writing library : libebml v1.4.2 + libmatroska v1.6.4

Audio
ID : 1
Format : PCM
Format settings : Little / Signed
Codec ID : A_PCM/INT/LIT
Duration : 1 s 0 ms
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 24 bits
Stream size : 281 KiB (98%)
Language : Italian
Default : No
Forced : No
FILE_PACKAGE_NAME : File Package: SMPTE 382M clip wrapping of wave audio
FILE_PACKAGE_UMID : 0x060A2B340101010501010F201300000038723ACE89734FC680B85F2D7B78FA25
TRACK_NAME : MP sound track



Trimmed sample file (1s): Link (https://trac.ffmpeg.org/attachment/ticket/9818/trim_1.mxf)

[Mosu]

MXF is not a supported container format. Unfortunately mis-detection of not supported content as H.264 or H.265 is rather common as those elementary streams only have a very loosely defined structure. Not going to get fixed.

[tormento]

Is there a way to "edit" the m2ts list that MKVToolnix takes into account when importing a mpls file?

I'd like to avoid to import the final (long) credit m2ts from a BD.

@Mosu

For future implementation: please add "split after m2ts" (such as split after chapters) and m2ts selection from mpls import.

[Mosu]

There isn't, and it's very unlikely I'll implement such functionality.

[Mosu]

Well hello, everyone!

Long time no release, for various reasons, including having had caught Covid. Luckily it was rather mild. But still; I'd rather not have gotten it at all.

Anyway. Here's a small release, couple of fixes, couple of features. Nothing overly revolutionary. Nevertheless, enjoy!

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 69.0.0 "Day And Age" 2022-07-09
Important notes

all: the spelling of "colour" was changed to "color" throughout all programs to match the use of American English spelling in MKVToolNix. This not only affects documentation and user interface controls, but also program options for mkvmerge & mkvpropedit. Both programs will continue to accept the British English spelling of their respective options indefinitely. One breaking change is that the property names in mkvmerge's JSON identification mode have also been changed to American English spelling. As those properties have only been introduced in release v68, this seems like a small enough window to make such a change.

New features and enhancements

MKVToolNix GUI: the number of recently used entries (e.g. destination directories) remembered by the GUI can now be configured in the preferences. Implements #3362 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3362).
MKVToolNix GUI: multiplexer: when adding files the track properties regarding color information & color mastering meta information will be parsed & set in the corresponding GUI controls. Implements #3359 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3359).
MKVToolNix GUI: job queue: the job queue can now be sorted by clicking on the column headers. Part of the implementation of #3365 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3365).
MKVToolNix GUI: job queue: when loading jobs from the queue directory that weren't previously known to the program those jobs will be sorted by their "date added" timestamp instead of using the order the operating system returns them in. Part of the implementation of #3365 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3365).

Bug fixes

build system: fixed compilation with fmt v9. Fixes #3366 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3366).
mkvmerge: HEVC ES parser: the parser will now parse at least the first full access unit before reporting that it has found all the required headers. Otherwise parsing might stop in the middle of the access unit due to the source reader not providing more data in the first call, leading to the parser not finding the "unspec62" and "unspec63" NALUs required for Dolby Vision. Fixes #3363 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3363).
MKVToolNix GUI: preferences: the default actions added to the "execute programs" section on new installations now default to use WebM file names instead of Ogg, matching the format of the included audio files.

Build system changes

The bundled "fmt" library was updated to v9.0.0.


Have fun 😁

[VBB]

Thanks!

[gpower2]

Thanks for another release @Mosu!

I wish you a quick recovery! :)

[rco133]

Hi.

Again it is probably me who is doing something wrong.

Updated from v67 I think.

When adding a track pressing space to get into language setting, I am using to just pressing "da" for example for "danish".

With 69, even if I enter "dan" it chooses "dan (daf)", which I have no idea what even is,

I have to enter "dani" before it chooses "danish".

Is there any way to get the old behaviour back?

rco133

[Mosu]

You can change the preferences to auto-focus the free-form language input. There you can use a simple "da" as that's the ISO 639 code for Danish.

[v0lt]

Mosu
I didn't see any information about end of support for Windows 7 and Windows 8.1 in version 69.0.0 in NEWS.md (https://mkvtoolnix.download/doc/NEWS.md). Although the download page says about support for Windows 10 and newer (https://mkvtoolnix.download/downloads.html#windows). Please add this information to NEWS.md.

My observations:
68.0.0 - installs and runs on Windows 7.
69.0.0 - installs but does not run on Windows 7.

[Mosu]

Windows < 10 hasn't been supported for years now. It isn't news.

[lvqcl]

Although the download page says about support for Windows 10 and newer (https://mkvtoolnix.download/downloads.html#windows)

The download page has a link to https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Officially-supported-operating-systems-and-versions:
Supported are all client versions of Windows (meaning Intel architecture) that Microsoft offers general support for.
This means that MKVToolNix stopped supporting Windows 7 a long time ago.

[filler56789]

69.0.0 - installs but does not run on Windows 7.
OUCH! *woman facepalming emoji*

Yeah, the installer shouldn't even run IF "Windows.version < 10".
But that's ""an irrelevant :rolleyes: detail"" for the ""geniuses"" who devilop the QT GUI. ;)

[FranceBB]

Thanks for the update, it works just fine on Fedora 36 x64.
I'm glad you had a swift recovery from COVID, it's never nice when you get it. I caught it in the middle of December 2021 even though I had 2 doses of Oxford Astra Zeneca + the Pfizer Booster, so... I know. :(

Anyway I'm glad you're feeling better and thanks for the new release! :)

[v0lt]

Windows < 10 hasn't been supported for years now. It isn't news.
It is possible that support was discontinued earlier (which did not prevent mkvtoolnix-gui.exe from working on these systems). But in which version this happened cannot be found in NEWS.txt and other text documents.

OUCH! *woman facepalming emoji*
...
I don't understand why you are so confused by the results of my test installs and application runs. This is just information for other users.

[Mosu]

I never mention in NEWS when I drop support for an operating system. 'cause that's not actually news about the code itself. It's just an operational decision.

Furthermore, I don't actually test whether a change breaks the programs from running on unsupported operating systems. That's part of the "unsupported" package — not receiving this kind of verification.

[tormento]

Furthermore
What happened to mkvtoolnix.download/windows/continuous/64-bit/69.0.0? I see it empty.

[Mosu]

A delete command gone awry. Will be populated with future builds, of course.

[tormento]

A delete command gone awry. Will be populated with future builds, of course.
Thanks :)

[filler56789]

I don't understand why you are so confused by the results of my test installs and application runs. This is just information for other users.

I was a programmer ""some time between 1973 and 1985"" :) ,
therefore it's difficult for me NOT to be annoyed by the post-modern programming "features" ;)

[tormento]

@Mosu

Since last version, I see many

--max-luminance 3:0 --min-luminance 3:0 --projection-pose-yaw 3:0 --projection-pose-pitch 3:0 --projection-pose-roll 3:0

in CLI command generated by GUI.

As I use it as reference to create batch files, could you please make them optional when of no use?

[Mosu]

That can definitely be improved, yeah. I'll look into it.

[Mosu]

Aaaand it's fixed.

[Selur]

How to properly signal 30000/1001 fps interlaced with mkvmerge v69.0.0 ('Day And Age') 64-bit?
Using '--default-duration "0:29.97i"':
mkvmerge --ui-language en -o "E:\Output\2022-07-17@08_45_40_5310__03.mkv" --global-tags "E:\Output\mkvtags_2022-07-17@08_45_40_5310__03.xml" -d 0 --default-track 0:yes --language 0:en --default-duration "0:29.97i" --aspect-ratio-factor 0:0.889 --chapter-charset UTF-8 --chapters "E:\Output\2022-07-17@08_45_40_5310__04.chp" --compression -1:none --forced-track 0:yes --field-order 0:6 --no-audio --no-subtitles "E:\Output\clip1_2022-07-17@08_45_40_5310_02.m2v" --track-name 0:"Japonês" --language 0:ja --default-track 0:yes --sync 0:6 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "E:\Output\iId_1_aid_0_lang_ja_DELAY_6ms_2022-07-17@08_45_40_5310_01.ac3"
and using '--default-duration "0:30000/1001i"':
mkvmerge --ui-language en -o "E:\Output\2022-07-17@08_45_40_5310__03.mkv" --global-tags "E:\Output\mkvtags_2022-07-17@08_45_40_5310__03.xml" -d 0 --default-track 0:yes --language 0:en --default-duration "0:30000/1001i" --aspect-ratio-factor 0:0.889 --chapter-charset UTF-8 --chapters "E:\Output\2022-07-17@08_45_40_5310__04.chp" --compression -1:none --forced-track 0:yes --field-order 0:6 --no-audio --no-subtitles "E:\Output\clip1_2022-07-17@08_45_40_5310_02.m2v" --track-name 0:"Japonês" --language 0:ja --default-track 0:yes --sync 0:6 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "E:\Output\iId_1_aid_0_lang_ja_DELAY_6ms_2022-07-17@08_45_40_5310_01.ac3"
both result in

Frame rate : 29.970 (29970/1000) FPS <- container
Original frame rate : 29.970 (30000/1001) FPS <- stream


Cu Selur

[Selur]

Okay, "0:30000/1001i", does seem to work as intended unless I use m2v video.
(For AVC content I need to use "0:60000/1001i" to get 29.970 (30000/1001) fps.)

[jpsdr]

@Mosu

There might be one more option. There seems to be modified QT6 version for Win7 here:
https://forum.qt.io/topic/133002/qt-creator-6-0-1-and-qt-6-2-2-running-on-windows-7
I've been already able to run another QT6 based software using that (Calibre 6.1 - https://calibre-ebook.com/download).
There you need to use as well VxKex to run it - https://github.com/vxiiduu/VxKex
But MKVToolnix seems to have QT embedded in main exe, so it is not possible just easily replace those binary files like for Calibre.

Do you think you can take a look at this ?

[Mosu]

Why would I? I don't support Windows 7.

[manolito]

--EDIT--
Issue solver. Please see here
https://forum.doom9.org/showthread.php?p=1973494#post1973494

Please bear with me, after my stroke last year I am quite ignornt with my computer. But I try to come back a little one step after the other...

My current problem is with some clips in the .TS format from the internet (I cannot post them here since they are quite explicit). The clips are VFR, and they play well in my players. I want to repack them to MKV or MP4 to be able to add chapters (also my XTreamer box is not too happy with .TS files), but after the conversion with MKVToolNix or MkvToMP4 audio will be out of sync.

I do not want to reencode the clips, I just want to repack them to a different container plus adding chapters. This must be possible because after fooling around a little bit using different software, I found that the very old YAMB 2.0 can do this without any problems.

It would be nice if I could somehow convince MKVToolNix to do the same, but so far I failed to find a way to do this.

Maybe I should mention that only a few .TS files exhibit these problems, and these sources do have a lot of (very bad) edits. But somehow YAMB is able to do it, and it does it without reencoding.


Cheers
manolito

[jpsdr]

Question about building mkvtoolnix target windows.
I've successfully build a 32 bits version.
Then, i wanted to build a 64 bits version, so i changed ARCHITECTURE to 64 in setup_cross_compilation_env.sh and re-run it. It took a LOOOOONG time, meaning that all the dependencies were build for 64 bits.
Unfortunately, it failled during the link, saying that a lot of lib/module are not compatible.
My guess: files from previous build where not cleaned and not overwritten, compiler probably thought it wasn't needed to rebuild them, resulting in linker trying to link 32 bits build with 64 bits build.
Do i need to do some cleanup between the both run of setup_cross_compilation_env.sh/rake ? In that case, what is the command for doing the clean up ?
Thanks.

[Mosu]

I cannot really help you with general problems compiling the MXE project. It's not my project; I only use it.

What I can tell you:

you can easily clean up the folder simply by deleting the whole "usr" sub-folder. It's where all the built stuff is installed.
you can have both 32 and 64-bit packages in a single MXE installation by setting "MXE_TARGETS" to "x86_64-w64-mingw32.static i686-w64-mingw32.static" in the "$MXE/settings.mk" file. It's just my setup_cross_compilation_env.sh script that doesn't support it. That script is targeted at users who want to do a one-time build, or who only need one architecture on a regular basis.

Clean up for a MKVToolNix source-tree is simply running "drake clean" followed by a new call to "configure".

[jpsdr]

In my setup, "drake" is not know, but i run "rake clean", and re-rerun setup_cross_compilation_env.sh, and as the libraries mxe where allready built, it was very fast, i then re-run "rake", and it finished ok.
:thanks:

[Mosu]

The MKVToolNix source tree comes with drake bundled. drake is much better at handling concurrent builds, making much better use of multi-core systems. You can run it from the MKVToolNix source tree root with "./drake" if you don't have it installed globally.

That being said, drake is definitely not a requirement. rake will do just fine, albeit slower.

setup_cross_compilation_env.sh is designed to be run multiple times without removing anything between runs, so yeah, you can certainly re-run it after changing ARCHITECTURE. One thing to note, though, is the script will always fetch the latest variant of my customized MXE repository. If that happens, it's quite possible you'll have to completely remove the $MXE/usr sub-directory and recompile both the 32 & the 64 bit toolchains.

[manolito]

--EDIT--
Issue solver. Please see here
https://forum.doom9.org/showthread.php?p=1973494#post1973494


Short follow-up to this post:
https://forum.doom9.org/showthread.php?p=1972539#post1972539

To show the issue I cut out a short section of one of the affected .TS sources which is only mildly erotic. You can download it here:
https://files.videohelp.com/u/172211/Test.zip

I included the MediaInfo results for the files. Maybe someone has an idea why only the old YAMB can handle such sources...

Cheers
manolito

[jpsdr]

@Mosu
Just out of curiosity, because size don't realy matter, any idea why my .exe files are at almost twice bigger than yours ?

[Mosu]

You probably didn't strip them.

[filler56789]

@Mosu
Just out of curiosity, because size don't realy matter, any idea why my .exe files are at almost twice bigger than yours ?

But size DOES matter. Keep in mind that not everybody has tons of RAM and tons of disk space to waste only because most programmers of today are careless noob-like 🤬s.
:D

P.S.: besides stripping the executables, you might also apply UPX onto them. However I don't know if the Qt stuff of MKVtoolnix will like that... FWIW, the ORIGINAL ancient .exe(s) of tsMuxeR were upx-ed, but after being un-upx-ed, it /they doesn't /don't work anymore. :confused:

[jpsdr]

You probably didn't strip them.
....
How do you do that ? Is it something to add in the setup_cross_compilation_env.sh script ?
Or is it a parameter to add when doing the rake command ?

[mastrboy]

But size DOES matter. Keep in mind that not everybody has tons of RAM and tons of disk space to waste only because most programmers of today are careless noob-like 🤬s.
:D

P.S.: besides stripping the executables, you might also apply UPX onto them. However I don't know if the Qt stuff of MKVtoolnix will like that... FWIW, the ORIGINAL ancient .exe(s) of tsMuxeR were upx-ed, but after being un-upx-ed, it /they doesn't /don't work anymore. :confused:

You are more likely to get flagged by antivirus software when using tools like UPX and mpress though, likely as a lot of malicious software use the same tools unfortunately.
Thankfully Microsoft is pretty fast at fixing false-positives for Defender after submitting files to them, usually within a few days. (https://www.microsoft.com/en-us/wdsi/filesubmission)

[jpsdr]

There is commits in MKVToolnix for MSYS2 issues.
It means it's probably possible to build MKVToolnix using MSYS2...:eek:

But i'm unable to find tutorial about it.

[Mosu]

It's not supported officially, and I don't know how to do it. Another person did the work of getting it to compile & provided merge requests that I merged. That's all.

[von Suppé]

Hi Mosu,

At the Dolby Vision support status page, I wonder why there is no "Supported check" under mkvextract for single track dual layer. Extracting hevc from STDL seems ok.

[Mosu]

Mostly because it doesn't do anything with the data stored in the various "addition" blocks (the stuff that corresponds to the CodecPrivate of the base laye, the dvcC/dvvC atoms). For regular, non-DV HEVC it's quite common that the parameter set NALUs are only stored once at the start, and mkvextract tries its best to normalize them so they're present before each and every key frame.

It could do something similar with the Dolby Vision NALUs, but it doesn't yet (as that is simply not implemented).

So yeah, for well-formed tracks you only take out and remux somewhere else as-is, the current code should work fine. The edge cases probably won't, though.

[Mosu]

Heyo!

A new small release is ready, mostly fixing two annoying bugs in the GUI's handling of color parameters that unfortunately slipped in in v69.

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 70.0.0 "Caught A Lite Sneeze" 2022-08-14
New features and enhancements

MKVToolNix GUI: the user can now control where the job queue files & the preferences INI file are stored via environment variables. If set, the variable "MKVTOOLNIX_GUI_STATE_DIR" can point to a directory where the GUI stores both the job queue sub-directory and the preferences INI file. If you only want to relocate the preferences INI file, you can store the desired file name for the INI file in "MKVTOOLNIX_GUI_CONFIG_FILE". Implements #3382 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3382).
MKVToolNix GUI: when adding directories via drag & drop/copy & paste the GUI will now offer the user the option to create one multiplex settings tab per directory & adding all files from that directory to the corresponding, newly created tab. Implements #3371 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3371).

Bug fixes

mkvmerge: AV1 OBU parser: fixed identifying files that only contain single frame. Fixes #3380 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3380).
MKVToolNix GUI: multiplexer: when reading color parameters from identified files that are floating point numbers (minimum/maximum luminance, projection pitch/roll/yaw) the numbers will be formatted in floating-point notation instead of scientific notation as mkvmerge only supports the former. Fixes #3368 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3368).
MKVToolNix GUI: multiplexer: color parameters that are floating point numbers (minimum/maximum luminance, projection pitch/roll/yaw) will only be set to a value during identification if the identification actually contains the property, and not to 0 anymore if it doesn't.

Build system changes

Several merge requests where accepted that improve compilation on MSYS2 on Windows. Note that this build type isn't supported.


Have fun 😁

[Kuler087]

thank you !

[lvqcl]

I wonder why A/V detection is 3/15 on Windows portable and 0/15 on Windows installer. Also some antiviruses don't like hevcc_dump.exe.

[Mosu]

New EXEs that have never been seen in the wild are often the target of false positives.

I create both the 7z and the installer from the same set of compiled EXEs. I compile on Linux. There's no Windows involved in the build process at all.

So… yeah.

[jpsdr]

A build question.
When you're building for Linux (we will forget targeting Windows for now).
Will --enable-static-qt build QT (or something similar) ? If not, what will it do ?
Is --enable-static-qt mandatory for --enable-static ?
Or for --enable-static you just need to have installed the proper allready build QT package ?

[Mosu]

If you want to use a statically-linked Qt, you'll have to use "--enable-static-qt".

"--enable-static" compiles all programs as static binaries, requiring all libraries to exist as static libraries. This isn't supported. The option is only present because one user provided a merge request for it. I don't use it, I don't test it, I don't support it.

[jpsdr]

Ok, thanks.
When you're building for Linux, what are the required QT packages for --enable-static-qt ?

[Mosu]

I only use static Qt libraries for the Windows builds, via the MXE project.

[jpsdr]

I'm not talking about the Windows build via MXE.
As i've specified, when you build for Linux, what are the required QT package for --enable-static-qt ?

[Mosu]

I'm not building with static Qt libraries on Linux. That's what I meant above. I only build with static Qt libraries when I build for Windows. For that I only use MXE.

[jpsdr]

Ah... Ok...
Sorry, i didn't understood, thanks for these informations.

[manolito]

https://forum.doom9.org/showthread.php?p=1972708#post1972708

Sorry for bringing this up again, but I think I found the issue now...

It turned out that the source files are borked, but playing the original .TS files in any player did not reveal the problem. Only after converting the source to .MKV usind MKVToolNix the audio sync was broken.

dmMediaConverter to the rescue. It reported THIS in its log:

[mpegts @ 076b04c0] Non-monotonous DTS in output stream 0:1; previous: 16190735, current: 16189009; changing to 16190736. This may result in incorrect timestamps in the output file.

The solution was to just repack the source with dmMediaConverter (everything in DirectStreamCopy mode) to another .TS file and then use this repacked source file as the input for MKVToolNix. All audio sync errors are gone...


Cheers
manolito

[jpsdr]

@Mosu
Assuming i want to build a Linux release, the same way you do, but from a clean fresh mkvtoolnix repo cloning.

My guess is that i have to do the following, am i correct ?


./autogen.sh (is there parameters here ?)
./configure (what parameters are you using ?)
rake (is there parameters here ?)

[Mosu]

Highly depends on which distro I build for, if I build for development, if I try to test certain features.

For releases I build from source tarballs, not git repo checkouts, meaning that you don't have to run "autogen.sh" (that builds the "configure" script, but the source tarball already includes "configure"). "autogen.sh" doesn't need parameters.

In general I only add those parameters to "configure" that are required for it to find the required libraries if they're stored in locations "configure" doesn't search in. Ideally I don't add any parameter to "configure".

"rake" doesn't need any parameters either.

[jpsdr]

Ok, thanks.

[Perenista]

I used MKVToolnix to put a subtitle (SRT) inside a m2ts file, and noticed that as MKV the filesize decreased from 65.1 to 61.9 GB.

By comparing both MediaINFO details from them, can this reduction be explained?

m2ts (original file):

https://pastebin.com/VuBWVUn8

MKV:

https://pastebin.com/r1VSWpXu

Is the MKV still "lossless" after I used MKVtoolnix? I only added the SRT.

EDIT: I just found this explanation (https://forum.videohelp.com/threads/359137-MKVToolNix-Complete-m2ts-to-mkv-reduces-file-size-why):

Is that it?

The CONTAINER OVERHEAD of a transport stream is much greater than the container overhead of other formats (MPG, AVI, MKV, MP4). In this way, when you remux from (m2)ts to Matroska, you will ALWAYS get a very-noticeable filesize reduction.

[Mosu]

Yes. The MPEG (2) transport stream container has one of the highest overhead of all the usual containers. It's really noticeable.

Another possible part of the explanation are filler NALUs. Video streams might contain so-called "filler NALUs" that don't contain any data and are only present to keep the effective bitrate above a certain threshold. As those NALUs are completely superfluous wrt. decoding, they're dropped by MKVToolNix.

[hubblec4]

Hi Mosu

Short question. mkvmerge writes always 8 bytes for the Segment DataSizeLength?

[Mosu]

It doesn, in order to facilitate modifying the files in-place later with tools such as mkvpropedit, but also because the total file size is unknown until the whole file's been written (and therefore the needed segment size is unknown until that point as well).

Other tools work differently.

[oniiz86]

Is there any reason as to why the "By Parts Based On Timestamps" splitting feature is imprecise? If the timestamp is 01:16:30-01:17:00 the file's duration is 38 seconds instead of 30.

[Mosu]

Spliting only ever works right before key frames, both at the start & at the end.

[Moonbase]

I recently switched from Linux Mint 20.3 (Ubuntu 20.04-based) to Linux Mint 21 (Ubuntu 22.04-based). MKVToolNix from your PPA worked fine in Mint 20.3, but with Mint 21 I keep getting:


mkvtoolnix-gui: symbol lookup error: /lib/x86_64-linux-gnu/libQt6Multimedia.so.6: undefined symbol: eglCreateImage


Synaptic tells me version 70.0.0-0~ubuntu2204bunkus01 of both mkvtoolnix and mkvtoolnix-gui are installed, and my deb line in /etc/apt/sources.list.d/mkvtoolnix.download.list is


deb https://mkvtoolnix.download/ubuntu/ jammy main


Any ideas on how to make it work again? Or how I could help to diagnose the problem?

[Mosu]

I don't provide packages for Mint. Certain Mint releases are compatible with certain Ubuntu releases. It seems that Mint 21 is not compatible with any current Ubuntu release anymore, making using Ubuntu packages with Mint impossible.

[Moonbase]

Hm, ok. So I’ll have to live with the AppImage for now. Thanks for providing that!

[darksen]

I want to ask something, I've been having this problem: https://forum.videohelp.com/threads/404564-Video-looks-corrupted-in-players-but-extracted-frames-look-OK, as you can read there, Blu-rays ripped with MakeMKV output video files with glitches but using your program output a glitch-free video file. From the moment I posted my last comment there to now I have done nothing, haven't re-ripped, checked, nothing, which is why only now that I'm making this comment. The thing is I've started to check the video files and blu-rays and at least in the Gods of the Arena blu-ray there is at least one video file (00101.mt2s) that has a glitch but when I demuxed the file with MKVToolNix (or chapterEditor which uses mkvmerge) the resulting video file is glitch-free, so:

Does MKVToolNix modifies the video tracks in any way? I mean, do you apply some kind of fix?
Asking because besides the output file being glitch-free the video tracks have different sizes/hashes. I can provide the original files if needed.

[SeeMoreDigital]

I want to ask something, I've been having this problem: https://forum.videohelp.com/threads/404564-Video-looks-corrupted-in-players-but-extracted-frames-look-OK, as you can read there, Blu-rays ripped with MakeMKV output video files with glitches but using your program output a glitch-free video file....LOL... I've been telling people (over on the AVS and AVForums) to de-mux and re-mux their MakeMKV back-ups using gMKVExtractGUI and MKVtoolNix-GUI for years ;)

The method works particularly well with seamless branched Blu-ray disc sources...

[Mosu]

It doesn't have any specific capabilities related to fixing issues. All it does is parsing the video frames, calculating their timestamps & then packaging them in Matroska. This process might alter the timestamps compared to the source container format, but it should not alter the encoded video frames (it might change the parameter set NALUs e.g. for timestamps & aspect ratio if certain options are enabled).

What it does is dropping superfluous filler NALUs. That can account for significant file system reduction.

[darksen]

Thanks, in any case I think I'll keep demuxing with MKVToolNix, the only problem I've got so far has been with 3D media and some Disney blu-rays. Does MKVToolNix not support demuxing 3D media? For example in the same Gods of the Arena blu-ray, there is an special feature that is in 3D but the program demuxes it as normal video.

from MakeMKV output:


Video
ID : 1
ID in the original source medium : 4113 (0x1011)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Stereo High@L4.1 / High@L4.1
MultiView_Count : 2
MultiView_Layout : Both Eyes laced in one block (left eye first)
Format settings : CABAC / 2 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 2 frames
Format settings, GOP : M=1, N=10
Codec ID : V_MPEG4/ISO/AVC
Duration : 5 min 35 s
Bit rate mode : Variable
Bit rate : 37.9 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.763
Stream size : 1.48 GiB (99%)
Language : English
Default : No
Forced : No
Original source medium : Blu-ray



from MKVToolNix output:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 2 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 2 frames
Format settings, GOP : M=1, N=10
Codec ID : V_MPEG4/ISO/AVC
Duration : 5 min 35 s
Bit rate mode : Variable
Bit rate : 25.1 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.505
Stream size : 1 004 MiB (99%)
Language : English
Default : Yes
Forced : No

[oniiz86]

LOL... I've been telling people (over on the AVS and AVForums) to de-mux and re-mux their MakeMKV back-ups using gMKVExtractGUI and MKVtoolNix-GUI for years ;)

The method works particularly well with seamless branched Blu-ray disc sources...

Yeah if only MediaTek-based SoC players, well specifically the BDP-10x series of players could effectively playback TrueHD with or without Atmos consistently & reliably without any audio dropouts within the MKV container & this is with the secondary Dolby Digital track always present & the first thing played upon power on, you are always guaranteed at least one audio dropout but you seemingly confirmed many years ago on your BDP-103 using an old version of MKVToolNix v7.1.0 that it played back TrueHD without any audio glitches, I wonder if the latest MKVToolNix versions are problematic with the old BDP-10x series of players?
A few days ago I used the latest version of MKVmergeGUI (v7.1.0) to re-mux Star Trek - Into Darkness (which has 7.1 TrueHD audio) and Batman - The Dark Knight (which has 5.1 TrueHD audio) and both now play okay without audio glitches.

[Mosu]

Thanks, in any case I think I'll keep demuxing with MKVToolNix, the only problem I've got so far has been with 3D media and some Disney blu-rays. Does MKVToolNix not support demuxing 3D media?

Only partially: you can safely remux a 3D version if it's already inside Matroska, but it cannot read that stuff from Blu-rays correctly. For those discs use MakeMKV.

[darksen]

Understood, thanks.

Something strange is happening on my end. Whenever the app hangs no matter how tiny the time it hangs is the GUI turns white, then if it hangs again it turns black but the text in the track listing is still black so it's impossible to read anything there, I have to close and reopen the app for it to have the dark theme again. Curious that it seems no one has reported this yet, maybe is happening to me only?

Also, is it normal that the app hangs when "Ok" is clicked in the settings window? Say I open the settings and change something or nothing -doesn't matter- then press Ok the app hangs for some seconds, it has always been like this or at least it's been like this for quite some time (years I think).

[Mosu]

Also, is it normal that the app hangs when "Ok" is clicked in the settings window? Say I open the settings and change something or nothing -doesn't matter- then press Ok the app hangs for some seconds, it has always been like this or at least it's been like this for quite some time (years I think).

Yeah, it has to re-initialize a LOT of the GUI components when you hit enter — and that process is rather slow. I'm aware of it, but all that time is spent inside the Qt library, and I honestly don't know how to speed it up (something like… suspend all UI size recalculation until all things have changed or something like that).

[gpower2]

Yeah, it has to re-initialize a LOT of the GUI components when you hit enter — and that process is rather slow. I'm aware of it, but all that time is spent inside the Qt library, and I honestly don't know how to speed it up (something like… suspend all UI size recalculation until all things have changed or something like that).

In good old WinForms, there is a SuspendLayout() method to prevent any draw operations for such cases.

From a quick googling, it seems that Qt offers a similar functionality in "setUpdatesEnabled(false)". https://www.qtcentre.org/threads/2634-How-to-temporarily-stop-draw-updates

If that is indeed the issue, it sounds like an easy fix, although I have not seen the UI code of MkvToolnix and never worked with Qt so I could be tremendously wrong :D

[Mosu]

I'm aware of that function, though until today I hadn't tried wrapping the whole "update UI after preferences changed" process in it. I now have, and it makes no difference. Some quick profiling shows that two functions are responsible for roughly 90% of the time:

updating all the internal representations for languages, scripts, regions etc. depending on the settings for "often-used selections"
setting up the color scheme & font

At the moment both are always called after the preferences dialog is closed successfully. I can easily limit that to only when those settings have actually changed. I already do that for the translations.

[darksen]

I'm trying to demux the War of the Damned blu-ray and I'm choosing the playlists without recaps but I'm getting this in the log:

--- Errors emitted by job 'Multiplexing to file "00101.mkv" in directory "M:\SpartacusS3-d1"' started on 2022-09-19 03:03:58 -05:00 ---
The file no. 0 ('Q:\BDMV\STREAM\00126.m2ts') does not contain a track with the ID 6, or that track is not to be copied. Therefore no track can be appended to it. The argument for '--append-to' was invalid.

MKVToolNix is supposed to append a 1s clip at the start, is this fixable?

It seems to me that these guys instead of splitting the recap and the actual episode have put them together into one single file so the player has to play first a black clip and then skip a portion of the video, I'm guessing the point to where it skips is not in a keyframe so that's why it needs the clip. Just in case I've uploaded the playlist to your ftp.

clip mediainfo: https://pastebin.mozilla.org/PFBnMnt0
episode mediainfo: https://pastebin.mozilla.org/Wh1O0TZ2

[Mosu]

Also, is it normal that the app hangs when "Ok" is clicked in the settings window? Say I open the settings and change something or nothing -doesn't matter- then press Ok the app hangs for some seconds, it has always been like this or at least it's been like this for quite some time (years I think).

You can give the latest continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/70.0.0/) a try. They should be faster wrt. closing the preferences dialog.

[Mosu]

I'm trying to demux the War of the Damned blu-ray and I'm choosing the playlists without recaps but I'm getting this in the log:

At the moment MKVToolNix only supports MPLS playlists that reference files which all have the same number & types of tracks. Sorry.

[darksen]

At the moment MKVToolNix only supports MPLS playlists that reference files which all have the same number & types of tracks. Sorry.

No problem, I can live with the recaps.

You can give the latest continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/70.0.0/) a try. They should be faster wrt. closing the preferences dialog.

Tested it and now it doesn't hang when clicking OK after changing or not any setting, thank you!

[hubblec4]

I'm trying to demux the War of the Damned blu-ray and I'm choosing the playlists without recaps but I'm getting this in the log:

MKVToolNix is supposed to append a 1s clip at the start, is this fixable?

It seems to me that these guys instead of splitting the recap and the actual episode have put them together into one single file so the player has to play first a black clip and then skip a portion of the video, I'm guessing the point to where it skips is not in a keyframe so that's why it needs the clip. Just in case I've uploaded the playlist to your ftp.


When the mpls file uses different m2ts files you can solve this problem with chapterEditor.
cE can ignore the first m2ts file.

[Mosu]

Tested it and now it doesn't hang when clicking OK after changing or not any setting, thank you!

It'll still hang for some time if you change any of the following options:

the list of often used languages/regions/character sets
the UI's language
"disable dark mode"

I haven't found a way to speed up any of those things; "setUpdatesEnabled(false)" doesn't make a difference at all. But the common case of not changing any of those options should indeed result in much faster application of settings. Therefore I do consider this a win.

[jpsdr]

A little question, out of curiosity.
When you mux video + audio and set a value in the shift (ms) field for the audio.
Is the shift done during the mux, resulting in a resync muxed file, or is it just an information to be provided to the player, and it's up to the player to apply/do the audio shift ?

Can the value be negative ?

[Mosu]

Sync settings (both the additive part & the multiplicator) are used during muxing & simply applied to all frame timestamps. Think "new_timestamp = sync_factor * old_timestamp + sync_additive", just with some more variables. The factor will be applied before the addition.

Players have nothing to do here. And as those values are directly included in timestamp calculation, there's no way to derive them from a file they've been applied on.

The additive part of the sync setting can be negative. However, as timestamps in Matroska files cannot be negative, this means that all frames whose timestamps end up negative after said calculation will be dropped during muxing.

[Mosu]

I recently switched from Linux Mint 20.3 (Ubuntu 20.04-based) to Linux Mint 21 (Ubuntu 22.04-based). MKVToolNix from your PPA worked fine in Mint 20.3, but with Mint 21 I keep getting:

FYI: a couple of days ago I decided to offer packages for Linux Mint (https://mkvtoolnix.download/downloads.html#linuxmint), starting with v21.

[hubblec4]

FYI: a couple of days ago I decided to offer packages for Linux Mint (https://mkvtoolnix.download/downloads.html#linuxmint), starting with v21.

Very very good decision. TOP!

[Moonbase]

FYI: a couple of days ago I decided to offer packages for Linux Mint (https://mkvtoolnix.download/downloads.html#linuxmint), starting with v21.

Gee, thanks! I’m sure this will be appreciated by many. I’ll give it a try soon and switch back to your PPA (after finishing my current work using the AppImage).

[Mosu]

Note that due to how packages are named, you may have to uninstall both the "mkvtoolnix" and the "mkvtoolnix-gui" packages if you had them installed from the Ubuntu repositories before installing them from the Linux Mint repository. Or wait for the next release; that'll fix it, too.

[Moonbase]

Note that due to how packages are named, you may have to uninstall both the "mkvtoolnix" and the "mkvtoolnix-gui" packages if you had them installed from the Ubuntu repositories before installing them from the Linux Mint repository. Or wait for the next release; that'll fix it, too.

You going to use "jammy" instead of "vanessa" for the PPA/deb line? Might be a good move, thanks!

[Mosu]

You going to use "jammy" instead of "vanessa" for the PPA/deb line? Might be a good move, thanks!

No. Why would I? The Linux Mint release isn't called Jammy. And even their own repository doesn't use "jammy", it uses "vanessa".

[Moonbase]

Yep, that’s true. Just thought you might make a version that runs on both Ubuntu 22.04 and Linux Mint 21 (and thus use "jammy", like other tools do). My bad.

Btw, kudos for doing so much just perfectly right with MKVToolNix(GUI)! I just ripped my "The Hobbit: An Unexpected Journey" 3D BluRays (main movie = 2 BluRays) and was about to concatenate part 1 & 2 using ffmpeg when I realized I could as well try MKVToolNix’ "append" function. And it actually even recalculated the Part 2 chapter timings correctly (a horrible job doing that manually using the XML extracts) and did a perfect append! Wow. I only had to change the part 2 chapter names, of course.

62 GB movies, here we come! I’ll need a bigger NAS real soon now… :cool:

[Mosu]

Yep, that’s true. Just thought you might make a version that runs on both Ubuntu 22.04 and Linux Mint 21 (and thus use "jammy", like other tools do). My bad.

That had been my modus operandi for the past years. However, there have been reports that the package for Ubuntu 22.04 doesn't actually work on Linux Mint 21. That prompted me to build a "real" package for Linux Mint 21, which mainly means building it on Linux Mint 21, not on any version of Ubuntu. Hence separate repositories & separate names.

[Moonbase]

Thanks for clarifying—and for the extra work supporting Mint! Much appreciated.

[darksen]

One request, could you please add a variable that returns the path of the first track's file? I would have asked the path of the video track but there could be cases where no video track would be used.
I was trying to create an action to execute a python script to copy the creation date of the source file to the destination file but there is no variable to get the path of the source file in order to get it's time.

Also, I'm correct at assuming that the actions are executed from first at the left to last at the right?
Additional question, does "<MTX_DESTINATION_FILE_DIRECTORY>" returns the path or only the directory name? Sorry, I haven't found anything about this in the documentation.

Thanks.

[Mosu]

One request, could you please add a variable that returns the path of the first track's file?

That's what MTX_SOURCE_FILE_NAMES is for. It expands to all source file names. Just integrate that into your command-line parsing in your Python script. Each entry is the fully-qualified file name, including drive letter, directory etc.

Also, I'm correct at assuming that the actions are executed from first at the left to last at the right?

Yes.

Additional question, does "<MTX_DESTINATION_FILE_DIRECTORY>" returns the path or only the directory name?

All variables that contain any type of file or directory name or path are always fully qualified, including drive letter & parent directories.

Example:

MTX_CURRENT_TIME=2022-09-26T12:45:16
MTX_DESTINATION_FILE_DIRECTORY=/home/mosu/prog/video/data
MTX_DESTINATION_FILE_NAME=/home/mosu/prog/video/data/v (42).mkv
MTX_INSTALLATION_DIRECTORY=/home/mosu/prog/video/mkvtoolnix/src/mkvtoolnix-gui
MTX_JOB_DESCRIPTION=Multiplexe in Datei »v (42).mkv« im Verzeichnis »/home/mosu/prog/video/data«
MTX_JOB_END_TIME=2022-09-26T12:45:16
MTX_JOB_EXIT_CODE=0
MTX_JOB_START_TIME=2022-09-26T12:45:16
MTX_JOB_TYPE=multiplexer
MTX_OUTPUT_FILE_DIRECTORY=/home/mosu/prog/video/data
MTX_OUTPUT_FILE_NAME=/home/mosu/prog/video/data/v (42).mkv
MTX_SOURCE_FILE_NAMES=(
/home/mosu/prog/video/data/v.avi
)


(This is from Linux version as I don't have a running Windows here at the moment, but for Windows the names will contain the drive letter)

That being said, I can totally understand your confusion as the verbiage in the popup that adds variables is less than clear. I'll fix that soon.

[Moonbase]

@Mosu: Is there currently any known problem remuxing MPEG transport streams? I’m just about to remux an old TV recording (Lucky Luke, 2.3 GB ts file with wrong extension ".mpg") into MKV and it already takes 1½ hours, currently at 55%… While other multi-GB formats on this same machine remux in seconds, or minutes at most.

[Mosu]

Dunno. Might be you're running into a bug. Might be some other cause.

[Moonbase]

Well, I’ll sit this one out and have a look at the results. I’ll also try some other M2TS files, just to check. Maybe the old recording is just somehow defective.

EDIT: FYI, there must be something highly inefficient going on—runtime of the video is 1h 18min and it took 2h 55min 20s just to remux:


--- Output of job 'Multiplexing to file "Lucky Luke - Auf in den Wilden Westen (2007).mkv" in directory "/home/matthias/Filme"' started on 2022-09-27 10:34:46 +02:00 ---
mkvmerge v70.0.0 ('Caught A Lite Sneeze') 64-bit
'/home/matthias/Filme/Lucky Luke - Auf in den Wilden Westen (2007).mpg': Using the demultiplexer for the format 'MPEG transport stream'.
'/home/matthias/Filme/Lucky Luke - Auf in den Wilden Westen (2007).mpg' track 0: Using the output module for the format 'MPEG-1/2 video'.
'/home/matthias/Filme/Lucky Luke - Auf in den Wilden Westen (2007).mpg' track 1: Using the output module for the format 'MPEG-1/2 Audio Layer II/III'.
The file '/home/matthias/Filme/Lucky Luke - Auf in den Wilden Westen (2007).mkv' has been opened for writing.
The cue entries (the index) are being written...
Multiplexing took 175 minutes 20 seconds.


ffmpeg -hide_banner -i Lucky\ Luke\ -\ Auf\ in\ den\ Wilden\ Westen\ \(2007\).mpg tells me:


[mpegts @ 0x564b608d1080] DTS 15370 < 18970 out of order
Input #0, mpegts, from 'Lucky Luke - Auf in den Wilden Westen (2007).mpg':
Duration: 01:18:49.69, start: 0.040000, bitrate: 3922 kb/s
Program 1
Metadata:
service_name : Service01
service_provider: FFmpeg
Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, progressive), 720x576 [SAR 64:45 DAR 16:9], 9500 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Side data:
cpb: bitrate max/min/avg: 9500000/0/0 buffer size: 1835008 vbv_delay: N/A
Stream #0:1[0x101]: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s
At least one output file must be specified


The resulting MKV file contains kind of "timelapse video" (~12min 14s) plus the original audio stream (1h 18min 49s). Here’s its MediaInfo output:


General
Unique ID : 287748801639657602076692450631621382226 (0xD87A6742341BA125365AB8CD01399052)
Complete name : /home/matthias/Filme/Lucky Luke - Auf in den Wilden Westen (2007).mkv
Format : Matroska
Format version : Version 4
File size : 2.08 GiB
Duration : 1 h 18 min
Overall bit rate mode : Variable
Overall bit rate : 3 782 kb/s
Movie name : Lucky Luke - Auf in den Wilden Westen (2007)
Encoded date : UTC 2022-09-27 08:34:46
Writing application : mkvmerge v70.0.0 ('Caught A Lite Sneeze') 64-bit
Writing library : libebml v1.4.2 + libmatroska v1.6.4

Video
ID : 1
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings : CustomMatrix / BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : Variable
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 12 min 13 s
Bit rate mode : Variable
Bit rate : 23.1 Mb/s
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 161.286 FPS
Original frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.346
Time code of first frame : 00:00:00:01
Time code source : Group of pictures header
GOP, Open/Closed : Open
Stream size : 1.98 GiB (95%)
Default : Yes
Forced : No

Audio
ID : 2
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Format settings : Joint stereo / Intensity Stereo + MS Stereo
Codec ID : A_MPEG/L2
Codec ID/Hint : MP2
Duration : 1 h 18 min
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Frame rate : 41.667 FPS (1152 SPF)
Compression mode : Lossy
Delay relative to video : -11 ms
Stream size : 108 MiB (5%)
Language : German
Default : Yes
Forced : No


Further investigation shows that time stamps are bad in the file, so probably no further action required with MKVToolNix. I just leave this here for others as a warning—I strongly suspect this was caused by using a bad "cutting w/o re-encoding" tool to cut out the advertisements from the TV broadcast.

[Stereodude]

Is there a way to assign a PGS subtitle (.sup from Blu-ray) to a 3D plane in a .mkv container?

[Mosu]

No, there isn't.

[darksen]

That being said, I can totally understand your confusion as the verbiage in the popup that adds variables is less than clear. I'll fix that soon.

Thank you! Much clearer now in the latest build.
Btw there is a typo in MTX_DESTINATION_FILE_DIRECTORY.

[Mosu]

Gnarf. Thanks for the catch. Fixed.

[darksen]

No problem.

I have tried the action and it is working well but I have another question, it seems that the actions aren't executed after the previous action finishes, instead they are just executed sequentially no matter if the previous action still hasn't finished, is this correct?

I'm asking because I tried executing the action to copy the dates and also enabled the built-in action to delete the source files and if both actions are enabled the dates aren't copied, I'm guessing because the source file is deleted before the script is able to fetch it's timestamp.

[Mosu]

The "run program" action runs the program in the background, meaning the GUI doesn't wait for the program to finish. If you have a "delete source file(s)" action configured as well, it'll likely be executed before the program you've also configured has had a chance to do its work.

If you want to delete the source files as well, include it in the program you're running.

[Mosu]

Hey everyone!

MKVToolNix v71 is out, bringing some more maintenance, but fixes, partial support for the latest Matroska elements. Partial in the sense that the GUI's chapter editor still needs to be updated for the new elements used for naming/titling editions (similar to how atoms can already be named). This will come in the next release.

A couple of notes for package maintainers: the latest releases of libEBML (v1.4.4) & libMatroska (v1.7.1) are required. They're also bundled, as usual. Those two releases were made on the same day as this MKVToolNix release: 2022-10-08. They should restore ABI compatibility with libEBML v1.4.2 & libMatroska v1.6.3 respectively, which we accidentally broke with last week's releases (the bad ones: libEBML v1.4.3 & libMatroska v1.7.0).

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 binaries as well as the Linux AppImage are available already. The macOS binaries & 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 71.0.0 "Altitude" 2022-10-08
New features and enhancements

mkvmerge, MKVToolNix GUI's multiplexer: added support for the Emphasis audio track header element via the "--audio-emphasis" option. It is also read from Matroska files.
mkvmerge: the options "--list-stereo-modes" and "--list-audio-emphasis" have been added to list all support numerical & textual values for the "--stereo-mode" & "--audio-emphasis" options.
mkvpropedit, MKVToolNix GUI's header editor: added support for the Emphasis audio track header element via the "emphasis" property.
MKVToolNix GUI: multiplexer: when the track properties are configured to be displayed in a tab widget below the files & tracks in the "Input" tab, the "Color information" tab will be laid out in two columns. This reduces the minimum height the whole tab widget requires. Implements #3401 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3401).
MKVToolNix GUI: greatly sped up closing the preferences dialog by only re-running certain initialization functions when their corresponding settings have changed. Also fixes issues such as #3406 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3406).
mkvinfo, MKVToolNix GUI's info tool: added support for the following new elements from Matroska v5: Emphasis audio track header element; Chapter Skip Type; Edition Display; Edition String; Edition Language IETF.
mkvmerge, mkvpropedit: added support for the following new chapter elements from Matroska v5: Chapter Skip Type; Edition Display; Edition String; Edition Language IETF. The GUI's chapter editor will receive support for them in the next release.

Bug fixes

mkvmerge: Ogg/OGM reader: mkvmerge will now correctly skip tracks of unsupported types as well as tracks for which all track header pages haven't been found. Fixes #3394 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3394).

Build system changes

libEBML 1.4.4 & libMatroska 1.7.1 are now required.
The bundled libEBML & libMatroska libraries were updated to v1.4.4 & v1.7.1 respectively.
The bundled "fmt" library was updated to v9.1.0.
The bundled "nlohmann-json" library was updated to v3.11.2.


Have fun 😁

[hubblec4]

Hi Mosu

I see the "matroskachapters.dtd" is not up to date. The new elements are not present.
What are names you will use for the new elements?

Is mkvmerge ready to read this new elements from a chapter.xml file?

[Mosu]

Yikes, totally forgot about that file. Thanks for the heads-up. I'll update it for the next release.

Yes, XML files can already contain the elements. All CLI tools can handle them already. It's just the GUI's chapter editor that isn't up to date yet — I simply didn't want to hold the release up anymore.

The example file "examples/example-chapters-1.xml" also contains all the new elements & shows their names. They are:


<EditionDisplay>
<EditionString>Example movie</EditionString>
<EditionLanguageIETF>en</EditionLanguageIETF>
</EditionDisplay>
<ChapterAtom>
<ChapterTimeStart>00:00:00.000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Intro</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterSkipType>1</ChapterSkipType>
</ChapterAtom>

[hubblec4]

Many thanks for this infos.

[Mosu]

DTD is updated (https://gitlab.com/mbunkus/mkvtoolnix/-/blob/main/examples/matroskachapters.dtd). I also took the opportunity to fix a couple of issues all the DTDs & ensure that all example XML files actually validate against them.

[hubblec4]

OK.

Is "EditionManaged" a new name for "EditionFlagOrdered"?

[Mosu]

Uh, no, that's a very, very old name. When you look at the "git blame" output for the file, you might notice that line is from 2004. It's since been renamed to EditionFlagOrdered, but it looks like I never got around to replacing it in the DTD, too. I'll fix it in a moment.

[hubblec4]

:-)

Mmh maybe a next issue.
"ChapterLanguage" uses a "+" for the occurrence, but this element can be omitted.
Would it be better to use the "*" (Asterisk) sign?

[WSC4]

I need some information on the old abandoned MKVToolNix thread that dates back to December 2017 please?

https://forum.doom9.org/showthread.php?p=1828168#post1828168

It is post #4992 and was posted by forum member manolito, and he posted this link there:

https://files.videohelp.com/u/172211/ToolNix_XP.zip

Error - File has been deleted.

I hope he sees this and can let me know if it can be upload again please?

[manolito]

The link address has changed after I added Win7 to the supported versions. Use this one:
https://files.videohelp.com/u/172211/ToolNix_XP_Win7.zip

(VideoHelp does not allow posters to edit their older posts after a certain time, so there is no way for me to update this old post)

Cheers
manolito

[Mosu]

Heyo.

I've just released a new minor update, v71.1. It solely fixes the "configure" script not having the correct requirements wrt. to libEBML & libMatroska. It also fixes several issues in the XML DTDs, but those aren't actually used in MKVToolNix itself. Functionality wise v71.1 is the same as v71.0. If you aren't a Linux package maintainer, feel free to skip this release.

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 71.1.0 "Fortitude" 2022-10-09
Bug fixes

Chapters DTD: added the new edition & chapter elements from Matroska v5.
Chapters DTD: fixed EditionUID being mandatory. mkvmerge can auto-generate it if it's missing from the XML file.
Chapters DTD: fixed the "example-chapters-1.xml" not validating against the DTD.
Chapters DTD: corrected the old name "EditionManaged" to "EditionFlagOrdered".
Chapters DTD: fixed "ChapLanguageIETF" missing its element declaration & "ChapterLanguage" being required.
XML DTDs: fixed elements representing binary data not allowing the "format" attribute.

Build system changes

bug fix: configure accidentally tested for libEBML ≥ 2.0.0 & libMatroska ≥ 2.0.0, even though the actual requirements are 1.4.4 & 1.7.1 respectively.


Have fun 😁

[hubblec4]

Hi Mosu

MTX supports now Matroska v5 elements: is this the official start for Matroska v5?

[Mosu]

v4 is the one that's currently going through the IETF standardization process. All elements we're adding now will be v5. These elements are the first v5 elements that have been specified. If you want to take that as to be an "official start", feel free, though there really isn't anything more behind this as "not part of the initial IETF standard".

[WSC4]

The link address has changed after I added Win7 to the supported versions. https://files.videohelp.com/u/172211...ix_XP_Win7.zip

Hi there manolito. Very pleased to see you are back posting again. I was told about your ill health last February in the Optimal encoding with FFmpeg for DVD thread and was very sorry to read about it. Sincerely hope you are fit and well now and have made a full recovery.

I need some information about MKVToolNix for Windows XP and Windows 7 please. Those operating systems have not been supported here for 3 years. Would it be more convenient if I post my question in the "MKVToolnix Windows 7 "The final Countdown" thread than here?

[manolito]

I need some information about MKVToolNix for Windows XP and Windows 7 please. Those operating systems have not been supported here for 3 years. Would it be more convenient if I post my question in the "MKVToolnix Windows 7 "The final Countdown" thread than here?

Hi WSC4 and thanks for the kind words. In my case there is no way to hope for a full recovery. The brain cells are too specialized to be replaced by new cells once they have died. Nothing you can do about it, I used to be pretty smart for 68 years, and now I will stay pretty dumb for the rest of my life. No reason to become grumpy...

To discuss MKVToolNix for WinXP and Win7 it would be good to move this to the other forum thread you mentioned. I am quite sure that Mosu is not amused to see this discussion in his main thread... :rolleyes:


Cheers
manolito

[WSC4]

OK. Shall do. See you over there. https://forum.doom9.org/showthread.php?p=1968296#post1968296

[archiel]

EAC3 issue - Resolved see edit below

Initially noted this running a batch conversion in RipBot64, but the issue seems to go the mkvtools. If I run MediaInfo against the source file the Audio has one length, however after extraction the length has changed.

from source
ID : 2
Format : E-AC-3
Format/Info : Enhanced AC-3
Commercial name : Dolby Digital Plus
Codec ID : A_EAC3
Duration : 46 min 16 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 32 bits
Compression mode : Lossy
Stream size : 63.6 MiB (4%)
Language : English
Service kind : Complete Main

After extraction (via mkvtoolnix GUI or mkvextract)
Audio
Format : E-AC-3
Format/Info : Enhanced AC-3
Commercial name : Dolby Digital Plus
Duration : 46 min 34 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 64.0 MiB (100%)
Service kind : Complete Main

Is this a known issue / is anyone else seeing this?

I am running Win11 Pro 22H2

Edit: The audio was fine, but the video was reporting the wrong frame rate, which resulted in an incorrect duration. At a guess the whole file had been cropped, but not on a key frame, so the first block had a different frame rate - the file showed as 24.131 instead of 23.976, the rate for the rest of the file.

[Emulgator]

How do these files compare (decoded) in a DAW (Audacity or what you prefer) ?

[archiel]

Problem resolved - see my edit to the original post.

[tebasuna51]

Don't trust always in all data than MediaInfo show, because it don't read the full streams and assume some info.
When show the container seems assume a duration (and size = Duration x Bitrate) wrong for the eac3 track, the correct is the info about the extracted track.
Also it lie when show:
Bit depth : 32 bits
A lossy encode don't have Bitdepth

[Moonbase]

Splitting after timestamp/frame—how exactly is it done?

Until now, I was usually fortunate when needing to split a long file. For "time stamp after", I used the last, say P frame before an I frame, and MKVToolNix GUI seems to perfectly include the last P frame (at my given timestamp) in the first file, and start the second file with the next frame, i.e., the I frame.

What would happen if I had a file with long GOPs and needed to cut somewhere else (i.e., not at an I frame)? Would MKVToolNix "blindly" cut at the given position, or somehow search to the next/previous I-frame and cut there, in order not to mess up the start of the next file?

[Moonbase]

Don't trust always in all data than MediaInfo show, […]

This may actually be important. I recently ran MediaInfo across a few 3D MKV files, looking for the "3d-plane" tags MakeMKV puts there for some 3D subtitles. They suddenly seemed all gone!

Somehow, MediaInfo couldn’t "see" them (although being in the files) across a network mount (ftp:// via Nemo on Linux). So beware, MediaInfo might show odd data on network mounted files (with ftp: being an especially bad case, and nfs: seemingly the best, because one can wildly seek around within the file, which ftp: cannot support).

[Mosu]

mkvmerge only ever splits before I frames, no matter which splitting mode you use. If you need to split within a GOP, you must use different tools that can re-encode the frames in that GOP as needed.

[Moonbase]

Thanks for the confirmation. Good to know it’s not a "dumb" splitter, possibly corrupting split files.

If I specify an arbitrary timestamp, will it search forward or backward to find the next I-frame for splitting? Or will it use the nearest I-frame?

[Mosu]

Always forward if it isn't on a keyframe at that point. Some modes seem to split on key frames, some on the next one; though I don't remember the details & why this is the case, to be quite honest. Probably something like off-by-ones or > vs >=

[hubblec4]

Would it be much amount of work to offer a "where mkvmerge splits list"?

Like "mkvmerge an.mkv --testsplit 00:01:00.000"
mkvmerge outputs then the timestamp of the real split.

[Mosu]

Not in a test mode, no. It has to process all the frames in order to determine how the timestamps actually pan out & where to split. Sure, I could add the information about which timestamps it has used for splitting, but that way you still would have to read the whole file. It would still take a lot of time depending on the source material.

[hubblec4]

Sure, I could add the information about which timestamps it has used for splitting
Mmmh indeed such an info would be nice. i have create a ticket (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3421).


but that way you still would have to read the whole file. It would still take a lot of time depending on the source material.
Ok, but Mkvmerge doesn't have to write any new MKV. files, which is probably the most of the time, or am I wrong?

[Mosu]

Writing & reading takes a similar amount of time, maybe 40/60%.

[darksen]

I have added a mpls to MKVToolNix but it doesn't add the audio track, if I open said playlist file with mediainfo it does shows an audio track. The thing is, the mpls links two files, the first file has a duration of a few seconds and doesn't have any audio, the second one does have an audio track. Can this be fixed? I've uploaded the mpls, I can share the files if needed.

[Mosu]

No, not with MKVToolNix. It requires all tracks to be present in the first M2TS referenced from an MPLS playlist.

To put it differently: when you tell it to add an MPLS file, it'll parse it & take a lot of its metadata (such as the chapter information, track languages, cover image if you're using the GUI). It'll also parse the list of M2TS & the start & end timestamps for each of those.

The next step is track identification — and for this it acts as if you had added the first M2TS file referenced in the MPLS & appended all the other ones. And what you need to realize is that mkvmerge will only create tracks in the destination file for each track in all the source files that have been added, but not for the appended files.

On top of all that for most track types having them referenced in an M2TS's PAT/PMT is not enough; instead mkvmerge will actively look for the first couple of frames for those tracks in order to extract certain information that isn't present in the PAT/PMT (e.g. sampling frequency, channel count, image dimensions etc.).

[darksen]

Thank you for the detailed response, you made it pretty clear. I'll have to do this manually which should be easy.

[Mosu]

Heyo!

here's MKVToolNix release v72. It fixes quite a lot of bugs, several one of them in the component driving the in-place file modification in mkvpropedit & the GUI's chapter & header editors. Therefore I urge everyone to update.

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 72.0.0 "Minuano (Six-eight)" 2022-11-13
New features and enhancements

mkvmerge: AV1 parser: the variable-width OBU size field will be re-written with minimal length if it's encoded longer than necessary.
mkvmerge: when splitting is active the program will output the timestamps actually used for making the decision when to split. If GUI mode is active, a specially formatted line "#GUI#splitting_before_timestamp &lt;timestamp>" is output as well. Lines prefixed with"#GUI#" are suitable for machine parsing, won't be translated and are guaranteed not to change in format. Implements #3421 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3421).
MKVToolNix GUI: multiplexer: when dragging & dropping directories to the "attachments" tab, the files contained in those directories will be attached. Implements #3410 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3410).
MKVToolNix GUI: info tool: added information about the file (directory, size, modification timestamp) at the top of each tab. Implements #3407 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3407).

Bug fixes

mkvmerge: AV1 parser: fixed the parser completely aborting when parsing the OBU size field fails due to there not being enough data to parse. Instead the parser will remember the last known-good position & restart from there after more data is available. Fixes #3431 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3431).
mkvmerge: HDMV PGS subtitles: reverted the change that implemented a heuristic for detecting bogus timestamps & attempting to fix them. This was done to fix #3268 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3268). Unfortunately this affected valid subtitle files with intentional huge gaps in timestamps, e.g. forced subtitle tracks. The heuristic has simply been removed, fixing #3392 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3392).
mkvmerge: Matroska reader: fixed reading files with EBML Void elements before the Matroska Segment element.
mkvmerge: fixed reversed attachment selection: "--attachments !4" would not copy any attachment instead of all attachments but the one with ID 4. Fixes #3427 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3427).
mkvextract: IETF BCP 47/RFC 5646 language tags: mkvextract will now use & prefer IETF BCP 47 track language elements if they're present. Only affects the VobSub & USF subtitle extraction.
mkvpropedit, MKVToolNix GUI's chapter & header editors: updated the list of deprecated Matroska elements. The applications will no longer try to write those elements, even if they're found in the file to be modified. The programs will no longer abort with error messages such as "assertion "false" failed". Fixes #3416 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3416).
mkvpropedit, MKVToolNix GUI's chapter & header editors: when the Matroska version numbers stored in the EBML Head element are updated, the updated EBML Head element might be smaller than the existing one. In that case the programs used to shrink the EBML Head & write a small EBML Void element between the updated EBML Head & the following element, usually a Matroska Segment element. This isn't widely supported by programs including MKVToolNix itself, causing them to declare such files as invalid. The programs will now create the EBML Void element inside the EBML Head element, making them a level 1 element instead of a level 0 element. Fixes #3355 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3355).
mkvpropedit, MKVToolNix GUI's chapter & header editors: often the programs have to relocate the Master elements in which the modifications were done. In that case the Seek Head elements must also be updated to reflect to the Master elements' new positions. If a file contained a Seek Head element at the start already and if that Seek Head was too small to contain the updated positions, the programs would end up in an endless loop trying to write data to the end, creating ever-growing files. This is now handled properly by voiding this too-small Seek Head & finding a proper space for a new one instead. Fixes #3338 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3338).
MKVToolNix GUI: header editor: fixed pixelated icons on higher display scaling values. Fixes #3420 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3420).


Have fun 😁

[quietvoid]

Hi Mosu, thanks for this release.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:
It appears clicking the NEWS link now always downloads the file, instead of opening in the browser.
Maybe something has changed in the site's setup?

I've tried on both Firefox and Google Chrome.

[Mosu]

It appears clicking the NEWS link now always downloads the file, instead of opening in the browser.

Oh… right, that's due to a related config change. I'll fix it. Thanks.

Edit: fixed

[AYColumbia]

@Mosu,
Thanks much for the continued releases of this invaluable tool. :)

[FranceBB]

Thank you for the new release, as always. :)

[Peter_A]

Often, I copy & paste the MKVToolNix output (from "Job Output") into a text/log file (on a Windows machine). The output has always maintained the line breaks when pasted in the past, but it is not doing that with v72.0.0. When I paste now, all of the lines are concatenated into a single line. I thought that maybe either the CR or LF was dropped, but I tried saving as text files with UNIX (LF) and MAC (CR) line terminators, as well, and experienced the same (output all in single line).

Was this an intentional change in v72.0.0? I didn't see anything in the release notes, but perhaps I overlooked something.

[Mosu]

I definitely didn't change anything there, and most certainly this isn't intentional. I can reproduce it on my end. My guess is that this is due to Qt which was updated to v6.4.0 with MKVToolNix v72.

I suggest you don't copy-paste, but instead use the "Save output" function from the "More actions" button.

Edit: looks like QTBUG-107004 (https://bugreports.qt.io/browse/QTBUG-107004).

[manolito]

@ Peter_A

Or you can use an alternative build compiled using Qt5.7 from here:
https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix/page3#post2672418

Cheers
manolito

[Peter_A]

I suggest you don't copy-paste, but instead use the "Save output" function from the "More actions" button.

Edit: looks like QTBUG-107004 (https://bugreports.qt.io/browse/QTBUG-107004).

Thanks, but that doesn't even totally work as I'd expect. If I mux and then clear the output, it removes the output from the window. If I mux again, the new output shows in the window, but if I then save the output (as you suggest), the file contains the output from both muxes. It seems to keep everything since the program was last closed. Why does it not just save what's currently in the window (what I'd assume would be the desired behavior)?

[Mosu]

OK, this is a bit complicated.

The one "job output" tab that's always visible does indeed collect the logs of all jobs. The output isn't just saved from the "output" text field to a file as there are three text fields: "output", "warnings", "errors". What's saved is the internal representation of the output as it is produced by mkvmerge — meaning warnings & error messages are interleaved with regular output, preserving the order in which the messages arrive.

That being said, clearing the output on the "job output" tab should also clear its internal representation, which it doesn't seem to do — hence you seeing the output of all jobs in the saved file. I'll look into that.

As yet another workaround you can go to the "job queue" tool & right-click on the job whose output you want to save. Select "View output" from the context menu. This will open a separate tab in the "job output" tool, and from there you can save it.

[Moonbase]

Thanks for continuous upgrades! I actually had some cases where the GUI Header Editor messed up the header slightly in v70. Nothing that couldn’t be fixed by doing a fresh remux, though. Will check if this is better now with v72.

[Kairys]

Hi! Is it possible to use your program to create a Blu-Ray Remux with the addition of your own audio track? There are folders (BDMV, CERTIFICATE) extracted using the MakeMKV program. What to do next? Could you give a brief instruction? Thanks

[Megalith]

How feasible is this via scripting?

1. Scan all MKVs and remove all audio tracks with the words "audio commentary"
2. Retain file accessed/modified dates

And would this require re-muxing?

[Mosu]

Not that hard at all with proper scripting languages (can even be done with bash, but it's a bit harder).

Removing whole tracks always requires full remuxes.

[hubblec4]

Hi! Is it possible to use your program to create a Blu-Ray Remux with the addition of your own audio track? There are folders (BDMV, CERTIFICATE) extracted using the MakeMKV program. What to do next? Could you give a brief instruction? Thanks

Hi Kairys
and welcome to Doom9.

Simple drag&drop the index.bdmv file into a Muxing-Tab in MKVToolNix(MTX).

MTX scans this file and presents a selection form with all the content of this disc (except: Angles of titles).

[Megalith]

Question about Dialnorm:

Whether Dialnorm is modified/retained is strictly decided in the muxing stage, correct? Regardless of how an audio track (e.g., TrueHD) was extracted, the only way that the Dialnorm settings could have been modified is if I toggled "remove dialog normalization gain" under the audio properties section of MKVToolNix, correct?

(For the longest time, I had assumed that eac3to determined this during the extraction phase, but apparently I have been wrong...)

[hubblec4]

You are correct. And yes, eac3to removes the Dialnorm by default.

[Mosu]

Question about Dialnorm:

Whether Dialnorm is modified/retained is strictly decided in the muxing stage, correct?

Removing it requires modification of each and every AC-3 packet. In the case of MKVToolNix it's therefore only possible to remove it during muxing, meaning you're correct.

Note that "removing dialnorm" is technically impossible. It's only possible to set the value used for dialog normalization to its minimum or maximum value, but you cannot remove it. However, mkvmerge uses established verbiage in order not to confuse users further that might know that functionality from tools such as eac3to.

[beto]

Thank you for the tool. Is there a way to use it to extract streams and attachments from a MKV file using a GUI? I do not know if a GUI is provided in the bundle for this purpose. The GUI provided shows me only a multiplexer and not a demultiplexer.

Thanks.

[NanoBot]

Are you looking for a program like this:

https://forum.doom9.org/showthread.php?t=170249

[beto]

Yes. That will do the trick. Thanks a lot.

[Perenista]

The 1st file was saved as AVI. DVDRip, but with the wrong AR (1.90). I wanted to use MKVToolnix and save as MKV. Specifying the 16:9 AR (1.78).

It worked. But the audio is now out of sync.

Why?

AVI:

https://pastebin.com/bza6Gx2f

MKV:

https://pastebin.com/fGUvYjAp

Important: before using MKVToolnix I appended at the very end of CD-1 (AVI) the 2nd file (CD-2), resulting in a single AVI, saving with the option "direct stream copy" using VirtualDubMOD. I used to split into 2 CDs in the past, and joined both files that way.

If I play that single AVI it's OK and the audio isn't out of sync. MKVToolnix, however, causes that issue.

[Mosu]

I suggest you try it without appending the AVIs first. There are two possible ways:

Simply use MKVToolNix GUI/mkvmerge to append the AVIs to a single Matroska file in a single go. Add the first AVI to the GUI's multiplexer, append the second one, go.
Another possibility is to mux each AVI to a separate Matroska file first, and then append those two Matroska files to a combined, long Matroska file.

The background is that the AVI container simply doesn't provide timestamps for audio data. Therefore appending AVIs to other AVIs requires hackery, and it's quite possible that mkvmerge simply doesn't support some types of those tricks.

[Perenista]

Oh-oh... I got this while trying to put the CD1.avi into MKV...

********
This audio track contains 146944 bytes of invalid data which were skipped before timestamp 00:36:42.352000000. The audio/video synchronization may have been lost.
********

I just checked the original AVI and indeed after 36m42s there's an abrupt cut in the video/audio, which seems to remove a portion of the content. Oddly this abrupt cut turns into the image freezing only for the MKV, for 1-2 seconds, then resumes from that. After that moment, the audio is out of sync in the CD1.mkv.

For example, at 46 minutes...

But here's something funny: this CD1.avi (affected with this issue) is not out of sync anywhere. I checked and it's OK into 46 minutes. I predict it will also remain unaffected if I append with CD2.avi using VDM.

MKVToolnix will not handle with the AVI due to this internal error, in other words the fact there is an error in there derails the whole thing as a result.

I am going to discard these old AVIs and create a new one from the disc...

[Mosu]

Hey y'all!

Even though not much has happened with MKVToolNix over the last six or seven weeks, I've decided to finalize the first release of the year, v73. Nothing overly amazing in it.

One note for macOS users that isn't stated in the NEWS below: this release's DMG was built with FLAC support again. Sorry for the confusing in the previous version; that was due to build system setup SNAFUs on my end.

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 73.0.0 "25 or 6 to 4" 2023-01-02
New features and enhancements

mkvmerge: greatly enhanced the speed of Base64 decoding which is used used e.g. when reading pictures embedded in Ogg or FLAC files or for binary data inside XML chapter & tag files. Even small blocks of data could take unreasonably long.
mkvmerge: added support for reading HEVC/H.265 video from FLV containers. Implements #3466 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3466).

Bug fixes

mkvmerge: splitting: fixed a typo in the string output in GUI mode regarding the timestamps before which splitting was done. See #3421 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3421).
MKVToolNix GUI: job output: after having run multiple jobs the "Clear output" functionality only reset the visible parts. However, using the "save output" function would also save the output generated before the user used "clear output". Now only the output after the last use of "clear output" is saved. Fixes #3438 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3438).
build system: when probing for the FLAC library the Ogg libraries will be linked with the compiled test program as well. This fixes detection if the "pkg-config" settings for FLAC don't list Ogg & the linker doesn't find the library automatically (e.g. for my macOS builds). Fixes #3439 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3439).


Have fun 😁

[VBB]

Thank you Moritz, and Happy New Year!

[filler56789]

Thanks for liking The Chicago Transit Authority. :)

[Mosu]

Chicago (with and without the suffix) has been a favorite of mine for more than 30 years now, and I still love their music to pieces today.

[outhud9]

Hi,

I've been having trouble getting MKVToolnix GUI to open on Linux Mint for a while now. Same issue on both LM21 and 21.1. I upgraded from LM20.3 a few months ago, but can't tell for certain if this is when the problem started. It had been working fine for years.

I've tried the version from the default repos (v65 I think?) and also 71 and now 73 today. I've tried with the mkvtoolnix Ubuntu repo, the Linux Mint repo and also with the AppImage. I used apt remove --purge mkvtoolnix* between different install attempts.

Same issue on all of them, the GUI doesn't open.

From a terminal --help and --version give the expected outputs, but running mkvtoolnix-gui alone doesn't open the GUI window.

After running mkvtoolnix-gui, I see this is from ps aux for about 10-15 seconds:

me@me-desktop:~$ ps aux | grep MKV
me 28416 1.4 0.0 388296 31708 pts/0 Sl+ 11:17 0:00 /tmp/.mount_MKVTooQcX2CD/usr/bin/mkvtoolnix-gui
me 28419 4.6 0.0 12572 2528 ? Ssl 11:17 0:00 ./MKVToolNix_GUI-73.0.0-x86_64.AppImage

and then both of these end, and I'm returned to a terminal prompt.

Anything I can try to debug this? Thanks!

[Ripman]

Hi Moritz. HNY. Thanks for the years of quality sw.

Sometimes we get subtitles that are formatted as closed captions - basically, subtitles that are fixed width. You can extract CC's as srt subtitles with CCExtractor_win_portable_v0.94, as an example.

So I got one CC srt file recently, and I wanted to add it to an MKV. These fixed width subtitles are always the same length per line - for the attached, it seems like 32 and 39. The non- white space text can start in any column. Even if your player centers subtitle text, the fixed width ensures that whatever "positioning" was used in the CC is also maintained.

So I muxed the fixed width srt into an mkv, and it gave strange results. I extracted the muxed srt, and it looks like white space is being chomped, but not for every line. It seems like all trailing white space is chomped, but not all leading white space is chomped. Ideally, unless the standard says otherwise, the subtitle text should not be changed at all - no chomping.

I have attached the original fixed width srt, and the srt extracted from the mkv I muxed.

Any insights on this one, M? Best.....

[Klaus1189]

Upload to Google drive or similar

[Ripman]

Upload to Google drive or similar

Regarding the fixed width srt finding I posted above, here is a link to all relevant files.

https://www.dropbox.com/sh/ke6mpcllswk99q0/AAB-tvtuKOR2zqL2-5dGgVbLa?dl=0

Win 10. Mkvtoolnix mkvmerge mkvextract v73.0.0.

The extracted srt file that is chomped - it displays that way on a TV or Vic when playing.

[Mosu]

I'm not sure if always keeping all whitespace is really the right thing to do. I'm definitely willing of making the behavior configurable, though. Please open an issue over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/) for it. Otherwise chances are I'll forget about it again. Thanks.

[Ripman]

I agree on the white space issue. None of the subtitle processing tools even give an option to preserve white space - Subtitle Edit, aegissub, SubSync, etc.

Either way, thanks as usual. I’ll put something over at git.

[Ripman]

I agree on the white space issue. None of the subtitle processing tools even give an option to preserve white space - Subtitle Edit, aegissub, SubSync, etc.

Either way, thanks as usual. I’ll put something over at git.

I created issue 3470 over at gitlab. Here is the link.

https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3470

Thanks everyone.

ADDED: I will say that editing these fixed width files can be tricky because of the aforementioned lack of support in some of the popular subtitle processing tools. So, in this particular case, the fixed width CCs are what comes from the video container - it's the source. I then re-created the srt without white space, which is in the dbox folder. I used SubSync to align these subtitle timecodes more closely. I then used a custom perl script I had to transfer the updated timecodes to the fixed width srt, which is also in the dbox folder. The UTF-8 srt files that come from CCExtractor_win_portable_v0.94 do not contain a BOM, so I had to manually insert those 3 bytes => used UltraEdit in hex mode.

[tormento]

Would be possible to give a directory for the files to attach?

It could be useful for many (who said fonts?) and positively useful for me :)

[Mosu]

Since v72 you can drag & drop directories onto the "attachments" tab and the GUI will attach all files in that directory.

[tormento]

Since v72 you can drag & drop directories onto the "attachments" tab and the GUI will attach all files in that directory.
I want to do it with command line, as it's a batch.

[Mosu]

You'll have to set up the command line with all the file names from that folder yourself; mkvmerge cannot help you with it.

[Ripman]

Thanks for that update. I tested 73.0.0.11 from the continuous builds with the new option that was added and the fixed width srt from the dbox link above. The srt file gets muxed in without any issues or changes.

Unfortunately- the idea of fixed width srt text files is not workable based on my simple tests. Vlc doesnÂ’t use fixed spacing for text subtitles, so the fixed width formatting doesnÂ’t work there. On my pioneer BDP-80 Elite, it doesnÂ’t even show the first subtitle - the unit freezes. The unit works fine with leading spaces on either subtitle lines 2 or 3.

So nothing useful here but at least the spaces are trimmed by default now. The thanks again btw.

[tormento]

You'll have to set up the command line with all the file names from that folder yourself; mkvmerge cannot help you with it.
In spare time, please, add the capability to use directory name too to include the files. It would help (at least me) to make scripts much readable and faster to paste in terminal.

[Ripman]

Thanks for that update. I tested 73.0.0.11 from the continuous builds with the new option that was added and the fixed width srt from the dbox link above. The srt file gets muxed in without any issues or changes.

Unfortunately- the idea of fixed width srt text files is not workable based on my simple tests. Vlc doesnÂ’t use fixed spacing for text subtitles, so the fixed width formatting doesnÂ’t work there. On my pioneer BDP-80 Elite, it doesnÂ’t even show the first subtitle - the unit freezes. The unit works fine with leading spaces on either subtitle lines 2 or 3.

So nothing useful here but at least the spaces are trimmed by default now. The thanks again btw.

I may have spoken too soon - apologies for that.

Using mkvmerge/mkvextract/gui 73.0.0.11 on Win10.

It would seem that using the new "whitespace" option is doing something a little different to the input srt file. Attached: 1. An srt that I muxed into an mkv; and 2. What gets extracted from the muxed mkv using mkvextract from the command line.

It would seem there is one extra crlf being inserted between subtitle entries when using the "whitespace" option. Interestingly, I put a double-space in sub #684 of the input file and it seems to be maintained - so that's good. The one extra crlf may be the source of freezing units I mentioned in previous posts on the topic, but that remains to be seen. I've tested SRTs when NOT using the new "whitespace" option, and everything seems to go in and come out as expected.

You should be able to take the input SRT in the attached, mux it into any mkv you have using the new "whitespace" option, and then extract the SRT to get the output SRT in the attached. Easy breezy. Thanks Moritz.

[Mosu]

Shoudl be fixed now.

[Ripman]

Shoudl be fixed now.

All good with 73.0.0.18. I inserted a fixed width srt file into an mkv. I extracted the srt with mkvextract and diff it with the original - everything matches and is fine.

No player freezes either. So that’s good.

I still don’t think these types of things work too well bc it requires the display to output fixed width characters, which most don’t. I suppose playing with various fonts on the playing device or sw could help.

Btw - I came across this while looking at some old DVDs that I’d replaced with BDs. Seems some old mpeg2 tracks have CCs embedded. Some examples I’ve come across:
- The Sting 2DVD special edition
- The Parallax view
- The Sheena Easton video on the Bond BD - For your eyes only
- Men of respect - early 90s DVD

THANKS AGAIN M. THE SW IS REALLY GREAT.

[r0lZ]

Hi Mosu.
A user of BD3D2MK3D has this error with mkvmerge: CreateEventA not found in library api-ms-win-core-synch-l1-2-0.dll. I suppose it's because he uses an unsupported version of Windows. Car you confirm? Or is it an outdated library?
Original thread at VideoHelp here (https://forum.videohelp.com/threads/395498-BD3D2MK3D-Convert-3D-BDs-or-MKV-to-3D-SBS-TAB-or-FS-MKV-Support-thread/page13#post2680579).

[lvqcl]

I suppose it's because he uses an unsupported version of Windows.

https://forum.doom9.org/showthread.php?p=1971554#post1971554 and several posts below it.

[Mosu]

Hi Mosu.
A user of BD3D2MK3D has this error with mkvmerge: CreateEventA not found in library api-ms-win-core-synch-l1-2-0.dll. I suppose it's because he uses an unsupported version of Windows. Car you confirm? Or is it an outdated library?
Original thread at VideoHelp here (https://forum.videohelp.com/threads/395498-BD3D2MK3D-Convert-3D-BDs-or-MKV-to-3D-SBS-TAB-or-FS-MKV-Support-thread/page13#post2680579).

Sounds like they're running Windows version not supported by MKVToolNix, e.g. 7.

[r0lZ]

Yes. I have just received confirmation that Win7 is his OS.
Thanks.

[kedautinh12]

Yes. I have just received confirmation that Win7 is his OS.
Thanks.

Win7 can use this ver
https://forum.doom9.org/showthread.php?t=184092&page=4

[r0lZ]

Indeed. Thanks.

[Mosu]

Hey y'all!

MKVToolNix v74 is out. This is another one in a longer line of small-ish bug fix releases. Nothing too earth shattering. Anyway, have fun with it.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.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 74.0.0 "You Oughta Know" 2023-02-12
New features and enhancements

mkvmerge: SRT handling: added a hack called "--engage keep_whitespaces_in_text_subtitles" which disables stripping whitespaces from the start & end of each line of SRT entries during muxing. Part of the implementation of #3470 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3470).

Bug fixes

all: Windows: UNC paths of type "\\?\C:\…" are supported again by switching back to Boost's file system library instead of using C++17's file system library. Fixes #3058 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3058).
mkvmerge: AVC/H.264 & HEVC/H.265 packetizers: when appending tracks the pixel dimensions will be checked & muxing will be aborted if they don't match. Fixes #3480 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3480).
mkvmerge: file type detection: file types that can be detected unambiguously by their content (e.g. Matroska, MP4, WAV…) will now preferred in the detection order over file types based on their extension. Prevents certain cases of mis-detection, e.g. DTS in WAV but with a file name extension of ".dts" being detected as the wrong type of DTS. Fixes #3462 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3462).
mkvmerge: SRT handling: whitespaces will now be stripped from the start & the end of each line of each entry, not just from the end of the last line. Part of the fix of #3470 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3470).
mkvextract: SRT extraction: whitespaces will not be stripped from the start & end of the whole entry anymore. Part of the fix of #3470 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3470).
MKVToolNix GUI: multiplexer: when adding multiple files that include certain file types (chapters, segment info and tag files) and when the choice where to add them is "all files to a single new tab", these certain file types will now be added in the newly added tab as well instead of the current tab that had already been open. Fixes #3469 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3469).
build system: fixed compatibility with Ruby 3.2.0 by using "FileTest.exist?" instead of "File.exists?", "Dir.exists?" & "FileTest.exists?" which were removed in that release.

Build system changes

MKVToolNix is now using & requiring Boost's "file system" and "system" libraries again instead of C++17's file system library. This is due to gcc's library not supporting UNC paths of types "\\?\C:\dir\file.ext".


Have fun 😁

[Ripman]

Hi M. Thanks for the new v74 release.

Sometimes I use the gui to generate an options file. I noticed that sometimes the gui will put the —display-dimensions option with a width X height argument in the options file.

I never use the —display-dimensions from the command line. Is the option required? What happens if not used?

I did read the man page but didn’t see anything explicit about the questions I asked. Just wondering. I’m thinking if the option is not present, mkvmerge uses what it sees in the video stream.

Thanks again. Best…..

[Mosu]

In general mkvmerge will always set the display dimensions on the output file. If they're provided via a CLI option, then those will be used. Otherwise, if they're provided by the source container (Matroska), those values will be used. Otherwise, the pixel dimensions will be used. Therefore you only need to set the parameters if they're different from the ones derived by the scheme outlined earlier. The goal for mkvmerge is to preserve as much information as possible verbatim by default.

That being said, the GUI has slightly different use case & different goal. One of its purpose is to make the user more aware of settings that are set somewhere in the source file. In the case of e.g. the movie's title that title is therefore shown in the appropriate line edit. The same goes for the display dimensions: if the source container provides display dimensions, those values are shown in the track's display width & height line edits — so that the user can easily see that they're set & what they're set to. Last, the GUI doesn't try to reduce the command line to the smallest possible CLI. It simply gives all the options for which some control is set in the GUI. Therefore sometimes those options are redundant.

For example, if you add a Matroska file with a video track whose pixel dimensions and display dimensions are both 1000x600. In such a case you wouldn't need to specify "--display-dimensions 0:1000x600" as that would be mkvmerge's default to use anyway. The GUI doesn't care, though; it doesn't try to recreate all of mkvmerge's internal decision making & adds "--display-dimensions 0:1000x600" anyway.

[NVF]

First, thanks so much for the tool.

I've gotten time stamp error warnings in the past (.srt overlaps if I understood them correctly) but no longer. Any help understanding and/or fixing this issue would be appreciated.

Thanks.

[Mosu]

Heyo!

Time for another release. Again nothing major, just some bug fixing & adding a simple converter from timed-text to Matroska's simple format (SRT-like).

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads (https://mkvtoolnix.download/downloads.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 75.0.0 "Goliath" 2023-03-26
New features and enhancements

mkvmerge: MP4 reader: mkvmerge will now read Timed Text (FourCC "tx3g") subtitle tracks & convert them on the fly to Matroska's simple text subtitle format ("S_TEXT/UTF8"; text only, no styles). Implements #2208 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2208), #2242 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2242), #2613 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2613), #3000 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3000), #3243 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3243), #3418 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3418) and possibly others.

Bug fixes

all: switched back to using "boost::filesystem" functions for creating directories instead of the ones introduced to work around bugs in "std::filesystem". The latter didn't work correctly with UNC paths after the switch to "boost::filesystem::path" in v74. Fixes #3483 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3483).
mkvmerge: VobSub reader: mkvmerge will now probe the ".idx" file during VobSub identification even if the ".sub" file is passed as the source. Avoids mis-detection of the ".sub" as MPEG program streams. Fixes #3489 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3489).
MKVToolNix GUI: the GUI could abort with an exception on startup while looking for the "mkvmerge" or "mediainfo" executables due to inaccessible folders. Fixes #3481 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3481).
MKVToolNix GUI: preferences: when opening the preferences the first time the UI might pre-select the first entry in the list of interface languages if the operating system's language is not available for MKVToolNix. This might also happen on Linux if e.g. "en_GB" is set, even though "en_US" is available. Now English ("en_US") will be selected instead. Fixes #3486 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3486).
MKVToolNix GUI: multiplexer: when adding files the GUI has special handling for chapter/tags/segment info files. This is done by comparing their content to certain patterns. This recognition could wrongfully be triggered if any such file was embedded in another file verbatim, e.g. with a chapter XML file attachment in a Matroska file. When trying to add that Matroska file, the GUI would treat it as a chapter file instead of a regular one. This content-based detection was fixed. Fixes #3487 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3487).

Other changes

mkvpropedit, GUI's header editor: removed support for the deprecated "minimum cache" & "maximum cache" track header elements.


Have fun ��

[NanoBot]

Thx for the new version.
I would like to mention that the link for the windows versions points to fosshub where only the outdated version 73.0 is available. The newest windows version is available here: https://mkvtoolnix.download/downloads.html#windows

:thanks:

[Mosu]

Oooooh right, I forgot to update my boilerplate macro. Thanks.

[Perenista]

https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3194

"Disable default track flag for audio tracks"

Where is that option?

[Mosu]

There is no such option.

[ctl-tx]

If you're taking suggestions, can the "Tracks, chapters and tags" window have a "en/disable selected items" option on the right click menu, just like in the "Attachments from source files" window? I'd like to be able to select and disable ten items there at once instead of one at a time.

[Mosu]

All actions taken in the "properties" pane apply to all selected tracks. Meaning there are two ways to achieve what you want to do already. After having selected a couple of tracks, you can

switch the "copy this item" drop-down box to "no" or
hit the return key, assuming your focus is still on the tracks view.

As I don't really like all that much duplicated stuff, I will not add a third option to that list.

The difference with the other view is that the other view doesn't have a properties pane in which there is such an option already.

[ctl-tx]

That's good enough for me! Thanks for the tip!

[AYColumbia]

I was encoding some old DVDs at 720x480. After running the merge command below, the AR is translating to 1280x960 instead of 720x540. Ideas? I'm having to use the property editor (CLI) to fix it for now. The elementary stream is 720x480.

"D:\MKVToolNix\mkvmerge.exe" --ui-language en --output ".\output\video.mkv"
--no-audio --no-video --title "video.mkv [nocues]" "(" "K:\DVD Source\video.mkv" ")"
--default-duration 0:24000/1001fps --aspect-ratio 0:4/3
--language 0:und "(" "video.hevc" ")"
--language 0:eng --no-chapters "(" "video.ac3" ")"
--track-order 0:0,1:0 --engage no_cue_duration --engage no_cue_relative_position

Thanks.

[UPDATE] Getting more strange results. The command below specifies specific dimensions so the display numers are correct in the resulting MKV but the pixel dimensions are 720x960 instead of 720x480.
"E:\MultiMediaTools\MKVToolNix\mkvmerge.exe" --ui-language en --output ".\output\video.mkv"
--no-audio --no-video --title "video [nocues]" "(" "K:\DVD Source\video.mkv" ")"
--default-duration 0:24000/1001fps --display-dimensions 0:720x540
--language 0:und "(" "video.hevc" ")"
--language 0:eng --no-chapters "(" "video.ac3" ")"
--track-order 0:0,1:0 --engage no_cue_duration --engage no_cue_relative_position

Here's the mediainfo output for the main+video to help. Maybe I'm missing something. Thanks a lot.
General
Unique ID : 9682556509059931718141687288042861920 (0x748CAE4AE737FE43B9CCF22F653B560)
Complete name : E:\media\work\video.mkv
Format : Matroska
Format version : Version 4
File size : 144 MiB
Duration : 25 min 32 s
Overall bit rate : 787 kb/s
Movie name : video [nocues]
Encoded date : UTC 2023-04-23 13:09:48
Writing application : mkvmerge v75.0.0 ('Goliath') 64-bit
Writing library : libebml v1.4.4 + libmatroska v1.7.1

Video
ID : 2
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L3.1@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 25 min 32 s
Bit rate : 593 kb/s
Width : 720 pixels
Height : 960 pixels <- pixel height in MKV
Original height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.036
Stream size : 108 MiB (75%)
Writing library : x265 3.5+37+12-4e46995bc:[Windows][MSVC 1931][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr /
no-ssim / log-level=2 / input-csp=1 / input-res=720x480 / interlace=1 / total-frames=36755 /
level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers /
annexb / no-aud / no-eob / no-eos / no-hrd / info / hash=0 / no-temporal-layers / open-gop /
min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=3 / b-adapt=0 / b-pyramid / bframe-bias=0 /
rc-lookahead=5 / lookahead-slices=0 / scenecut=69 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh /
ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 /
limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / no-signhide / no-tskip / nr-intra=0 /
nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=0 / no-limit-modes /
me=0 / subme=0 / merange=57 / temporal-mvp / no-frame-dup / no-hme / no-weightp / no-weightb /
no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=2 / selective-sao=0 / early-skip /
rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 /
psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 /
qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=10000 / vbv-bufsize=10000 / vbv-init=0.9 /
min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 /
aq-mode=1 / aq-strength=0.00 / aq-bias-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 /
no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=6 /
transfer=6 / colormatrix=6 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 /
log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps /
no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion /
no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 /
analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 /
refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 /
copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field /
qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 /
decoder-max-rate=0 / no-vbv-live-multi-pass
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.601 NTSC
Transfer characteristics : BT.601
Matrix coefficients : BT.601

[AYColumbia]

Bueller, Bueller, anyone, anyone... ;)

[nevcairiel]

Interlaced HEVC is practically unsupported in the entire open-source video world. Would strongly advise to not use it.

[AYColumbia]

Interlaced HEVC is practically unsupported in the entire open-source video world. Would strongly advise to not use it.
The input is interlaced but the output is NOT. I only add the --interlace switch because the x265 docs state that it indicates the input is interlaced.

I'm just trying to figure out why the resolution is winding up as it is.

[nevcairiel]

If the input is interlaced, then the output is interlaced. If you want it otherwise, deinterlace it first. --interlace indicates the input is interlaced, quite right, but it also tasks x265 to encode it as interlaced.
If you set --interlace with x265, it expects you to feed it individual fields, which you likely did not do, so it got frames, thinking those are fields (which would be half the height), hence your output is double the height.

[AYColumbia]

If the input is interlaced, then the output is interlaced. If you want it otherwise, deinterlace it first. --interlace indicates the input is interlaced, quite right, but it also tasks x265 to encode it as interlaced.
If you set --interlace with x265, it expects you to feed it individual fields, which you likely did not do, so it got frames, thinking those are fields (which would be half the height), hence your output is double the height.
Oof, yikes. I didn't realize that based on the full help and how it's worded. I also made and incorrect assumption that MediaInfo would show it as interlaced which it does NOT. I really appreciate you responding and clarifying. I'll have to reencode one more time. Thanks again. :)

[Perenista]

I put 938906 ms in delay for MKVToolnix for a MP3 track (to be in sync with a MKV more than 15 minutes later) and the app returned an error. Why? Is there a limit?

[Mosu]

There's no limit. Just guessing, as you didn't post the actual error message: you entered "938906 ms", but that option simply doesn't take a unit suffix. It only expects a number, and that number is interpreted as milliseconds.

[Mosu]

Heyo!

here's yet another release, v76.0. This is a slightly bigger one in terms of the number of fixed bugs & implemented improvements. Due to the change wrt. the handling of BlockAddition elements (which is required for HDR content for WebM, VP9, AV1`) I strongly recommend users to upgrade.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.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 76.0 "Celebration" 2023-04-30
Important notes

mkvmerge: removed the option "--blockadd". Removing block additional data is not possible anymore, as it is often required for proper decoding. Part of the implementation of #3511 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3511).

New features and enhancements

mkvmerge: JSON file identification: added a child element called "num_index_entries" to the "properties" track element containing the number of index entries found for a track. Currently only implemented for Matroska files where it contains the number of cue points. See #3510 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3510).
mkvmerge: the maximum block addition ID track header value is now calculated automatically from both the existing mappings & the actually used block additions in the block groups. Part of the implementation of #3511 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3511).
mkvmerge: Matroska reader: when reading WebM files that use block additions with ID 4 (HDR for VP9) an appropriate block addition mapping will be created automatically. Part of the implementation of #3511 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3511).
mkvmerge: MP4 reader: the title/movie name meta data (content of the "udta.meta.ilst.©nam" atom) will now be copied over as the segment title track header attribute. Part of the implementation of #3475 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3475).
mkvmerge: MP4 reader: the comment & encoder meta data (content of the "udta.meta.ilst.©cmt" & "….©too" atoms) will now be copied over as global tags "COMMENT" & "ENCODER" respectively. Part of the implementation of #3475 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3475).
mkvmerge, MKVToolNix GUI's multiplexer: added an option to stop processing after the primary video track ends called "--stop-after-video-ends". This discards any remaining packets of other tracks. Part of the implementation #3506 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3506).
MKVToolNix GUI: only on Windows: the GUI now uses Qt's "Fusion" style instead of the deprecated "Windows Vista" style. The advantage is that as of Qt 6.5 the "Fusion" style properly supports Windows 10's & 11's dark application mode. The Windows binaries are now built with said Qt version. Therefore the option to disable the dark mode has been removed. Fixes #3264 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3264) and likely others.
MKVToolNix GUI: multiplexer: automatically setting the destination file name: added an option in the preferences for using the first source file's directory name instead of its file name as the basis for the destination file name. Implements #3512 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3512).
MKVToolNix GUI: multiplexer: double-clicking on certain columns in the "tracks" view will now toggle them directly (columns "Default track" & "Forced track") or activate the corresponding control (columns "Language", "Name" & "Delay"). Double-clicks on other columns will do what they've done before, too: toggling the "Copy item" state. Implements #3513 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3513) & others.
MKVToolNix GUI: the dialog for editing language tags is now created only the first time the user wants to edit a language tag & cached afterwards instead of creating a new instance each time. This makes subsequent uses instant.

Bug fixes

mkvmerge: mkvmerge will now only try to probe for VobSubs if the name of the file to identify ends in either ".idx" or ".sub", preventing mis-identification of other file types if VobSubs with the same base name exist in the same directory. Fixes #3508 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3508).
mkvmerge: AC-3: mkvmerge will now skip certain types of garbage data (16 bytes starting with 0x01 0x10) that can occur before each sync frame, fixing the file not being identified as AC-3. Fixes #3484 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3484).
mkvmerge: Matroska reader: when reading files that use block additions with IDs other than 1 (e.g. 4 for HDR for VP9) the IDs will now be kept & written to the output file. Before no ID would be written, effectively using 1 as that's the default value for the corresponding element. Part of the implementation of #3511 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3511).
mkvmerge: mkvmerge will no longer write block addition mappings or the max block addition ID track header elements when creating a WebM file as those elements aren't supported there. Part of the implementation of #3511 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3511).
mkvpropedit: fixed replacing chapters & tags in files that don't contain tracks. Fixes #3498 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3498).


Have fun 😁

[hubblec4]

Many thanks for your work, Mosu!!

[AYColumbia]

Many thanks for your work, Mosu!!
My sentiment exactly. Thanks Mosu! 😊

[Kuler087]

love the new features. thanks! :)

[Perenista]

About my previous comment: that's odd, it wasn't working before... Now it is.

After the update, I noticed another issue:

Using: Windows 11, 64-bit...

Looks like this new MKVTOOLNIX is broken in terms of visuals, dark mode... it was OK before, now it looks like this:

https://i.postimg.cc/1XTjhDdB/MMM.jpg

That blue font for the english track was not what I saw before... same for the grey background...

Also, when we check the box "disable dark mode" it does not stay ticked... even after we restart the app. I am using some sort of dark mode config here...

EDIT: Yep, confirmed to be broken. Restarted Windows, nothing changed. Some sort of regression happened with the visuals of this app. I'll try to get an older version and install in another folder, to show how it looked like.

Oh, OK, just checked your changelog... what exactly was fixed?

Just installed 75.0.0 and it's OK:

https://i.postimg.cc/sDdqVCD4/CORRECT.jpg

https://i.gifer.com/origin/51/51d8642b88d1f052bcda12f2b86ebb0a_w200.gif

How can we fix this?

[Mosu]

Meh. Unfortunate I didn't notice this before the release. There are two separate issues: the link being too dark and the fact that the "disable dark mode" checkbox is still shown on Windows 11 as you cannot turn it off anymore there. I'll address both soon.

You cannot really do anything about it on your end. Either live with it or downgrade.

[Mosu]

Turns out this is a bug in Qt 6.5.0 which hardcodes that dark blue for the dark mode. I've filed an issue for it (https://bugreports.qt.io/browse/QTBUG-113305).

Until that's fixed I've also implemented a workaround in MKVToolNix. You can use the latest continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/76.0/) which contain the fix.

[Selur]

I got a problem with setting the SAR for av1 content.
Using:
mkvmerge --ui-language en -o "G:\Output\2023-05-02@05_31_22_6810__06.mkv" --global-tags "J:\tmp\mkvtags_2023-05-02@05_31_22_6810__06.xml" -d 0 --default-track 0:yes --default-duration "0:50/1fps" --aspect-ratio-factor 0:16/15 --no-chapters --compression -1:none --forced-track 0:yes --field-order 0:0 --no-audio --no-subtitles "J:\tmp\Naruto DVD Folge 4_15 sec_new_1_2023-05-02@05_31_22_6810_03.av1"
MediaInfo reports:
Video
Count : 381
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
ID : 1
ID : 1
Unique ID : 7344196294740375732
Format : AV1
Format : AV1
Format/Info : AOMedia Video 1
Format/Url : http://aomedia.org/
Commercial name : AV1
Format profile : Main@L3.1
Codec ID : V_AV1
Codec ID/Url : http://aomedia.org/
Duration : 15280.000000
Duration : 15 s 280 ms
Duration : 15 s 280 ms
Duration : 15 s 280 ms
Duration : 00:00:15.280
Duration : 00:00:15:14
Duration : 00:00:15.280 (00:00:15:14)
Bit rate : 3263008
Bit rate : 3 263 kb/s
Width : 720
Width : 720 pixels
Height : 576
Height : 576 pixels
Sampled_Width : 720
Sampled_Height : 576
Pixel aspect ratio : 1.000
Display aspect ratio : 1.250
Display aspect ratio : 5:4
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 50.000
Frame rate : 50.000 FPS
FrameRate_Num : 50
FrameRate_Den : 1
Frame count : 764
Color space : YUV
Chroma subsampling : 4:2:0
Chroma subsampling : 4:2:0
Bit depth : 10
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.157
Delay : 0
Delay : 00:00:00.000
Delay : 00:00:00:00
Delay : 00:00:00.000 (00:00:00:00)
Delay, origin : Container
Delay, origin : Container
Stream size : 6232346
Stream size : 5.94 MiB (100%)
Stream size : 6 MiB
Stream size : 5.9 MiB
Stream size : 5.94 MiB
Stream size : 5.944 MiB
Stream size : 5.94 MiB (100%)
Proportion of this stream : 0.99822
Default : Yes
Default : Yes
Forced : Yes
Forced : Yes
colour_description_present : Yes
colour_description_present_Source : Stream
Color range : Limited
colour_range_Source : Stream
colour_primaries_Source : Stream
transfer_characteristics_Source : Stream
Matrix coefficients : BT.470 System B/G
matrix_coefficients_Source : Stream

When using ffmpeg:
ffmpeg -y -r 50/1 -i "J:\tmp\Naruto DVD Folge 4_15 sec_new_1_2023-05-02@05_35_15_9110_03.av1" -vcodec copy -metadata encoding_tool="Hybrid 2023.05.01.1" -map 0:0 -aspect 20:15 -r 50/1 "G:\Output\Naruto DVD Folge 4_15 sec_new.mkv"
MediaInfo properly reports:
Video
Count : 381
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
ID : 1
ID : 1
Unique ID : 15569613067555342625
Format : AV1
Format : AV1
Format/Info : AOMedia Video 1
Format/Url : http://aomedia.org/
Commercial name : AV1
Format profile : Main@L3.1
Codec ID : V_AV1
Codec ID/Url : http://aomedia.org/
Duration : 30560.000000
Duration : 30 s 560 ms
Duration : 30 s 560 ms
Duration : 30 s 560 ms
Duration : 00:00:30.560
Duration : 00:00:30:14
Duration : 00:00:30.560 (00:00:30:14)
Bit rate : 1600545
Bit rate : 1 601 kb/s
Width : 720
Width : 720 pixels
Height : 576
Height : 576 pixels
Sampled_Width : 720
Sampled_Height : 576
Pixel aspect ratio : 1.067
Display aspect ratio : 1.333
Display aspect ratio : 4:3
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 25.000
Frame rate : 25.000 FPS
FrameRate_Num : 25
FrameRate_Den : 1
Frame count : 764
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Chroma subsampling : 4:2:0
Bit depth : 10
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.154
Delay : 0
Delay : 00:00:00.000
Delay : 00:00:00:00
Delay : 00:00:00.000 (00:00:00:00)
Delay, origin : Container
Delay, origin : Container
Stream size : 6114084
Stream size : 5.83 MiB (98%)
Stream size : 6 MiB
Stream size : 5.8 MiB
Stream size : 5.83 MiB
Stream size : 5.831 MiB
Stream size : 5.83 MiB (98%)
Proportion of this stream : 0.98010
Default : No
Default : No
Forced : No
Forced : No
colour_description_present : Yes
colour_description_present_Source : Container / Stream
Color range : Limited
colour_range_Source : Container / Stream
colour_primaries_Source : Stream
transfer_characteristics_Source : Stream
Matrix coefficients : BT.470 System B/G
matrix_coefficients_Source : Container / Stream


=> seems like "--aspect-ratio-factor 0:16/15" got ignored.

Cu Selur

[Mosu]

@Selur: thanks, that looks like a bug in the AV1 packetizer. Other packetizers such as the AVC & HEVC ones do honor the aspect ratio given, whereas the AV1 simply ignores it. I have an idea why that is & will look into it.

[Mosu]

Are there any macOS users here that'd like to help me test something? A user over on Reddit asked for file association for the MKVToolNix app. I've implement such in the latest pre-DMG (https://mkvtoolnix.download/macos/pre/). However, I've run into the problem that after installing the application (via dragging & dropping the application to the Applications folder, _not_ the DMG) & running "killall Finder" MKVToolNix is now the default application for its types, taking precedence over thinks such as QuickTime or VLC. This is obviously not what I want; I only want it to be the primary for *.mtxcfg & an alternate for all the others (meaning it should show up in "Open with" but not be the application opened when double-cliking on a file or selecting "Open" from the context menu).

The documentation I've found says that I have to adjust the rank, which I've done for all file types with:

<key>LSHandlerRank</key>
<string>Alternate</string>

(and "Owner" solely for "mtxcfg"), but that doesn't seem to help on my machine.

Luckily things return to normal as soon as you uninstall the application.

I'd like some feedback if possible: does this happen for others, too? Any insight into why?

For those who want to take a look at the Info.plist: see here it is (https://gitlab.com/mbunkus/mkvtoolnix/-/blob/main/packaging/macos/Info.plist).

Thanks!

[Mosu]

I got a problem with setting the SAR for av1 content.

Should be fixed in the latest continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/76.0/).

[jpsdr]

Hi.
Out of curiosity, is there somewhere an option to get back the previous visual interface ? I don't like this "Fusion"... :(

[Mosu]

No, there isn't. The reason is simple: the older style (called "windowsvista" by Qt) doesn't support dark themes properly.

[jpsdr]

Too bad... :(
Ok, thanks.

[Sakura-chan]

So MKVToolNix will be forever stuck in dark mode with no way to change it back? A shame really. The interface looks horrible in dark mode to me. And having to switch the whole system for one external program doesn't make sense. I like dark mode on Windows itself but I want programs in light mode. For me things I stay little time in or are mostly in the background are good in dark mode, like windows settings, explorer. Programs I spent quite some time with are better in light mode.

All programs with dark modes that I've encountered have a switch, like MKVToolNix did until 75.0.0. Usually a "default", meaning follow system scheme, and a light and dark options, or other colour schemes if the program has them. It's like the most basic of options. Never an issue until today.

Why Fusion doesn't allow for a switch between modes I don't understand. Time to keep and cherish 75.0.0 indefinitely then. I do mostly BD remuxing which has a limited selection of settings/codecs already very mature so I'm not really too bothered. But talk about silly regressions.

[Mosu]

So MKVToolNix will be forever stuck in dark mode with no way to change it back?

No. Please read the corresponding FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dark-mode-issues) for the current state of things.

[Ripman]

Thank you - as usual - for the new version, M. Best…..

[Mosu]

Hey! 😁

It's nearly summer & the weather's nice where I live. So why not do another MKVToolNix release today? 😁 This release mostly fixes the messy situation with the dark application mode on Windows among a lot of other things. Additionally mkvmerge will now sort tracks by their type by default!

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.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 77.0 "Elemental" 2023-06-04
New features and enhancements

mkvmerge: tracks in the destination file will now be sorted by their type automatically unless the track order is specified with the "--track-order" option. The order is as follows: video tracks first followed by audio & subtitle tracks with other rarely used types of tracks last. Tracks of the same type will be sorted in the same order as their source files occur in the command-line arguments. Note that this doesn't affect file identification. Implements #3545 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3545).
MKVToolNix GUI: multiplexer: the default list colors used for distinguishing source files does not include the darkest tier anymore (the ones where one or two components are set to the value 0x3f) as they're hard to distinguish from each other. Only affects new installations, or when the user presses the "reset to default colors" button. Implements #3533 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3533).
MKVToolNix GUI: multiplexer: the GUI will now check the state of the 'track enabled' flag of all video, audio & subtitle tracks when starting to multiplex or adding a job to the job queue. If there's no track with its flag turned on for a type, the GUI will turn on the flag for the first track of the type. This behavior can be turned off in the preferences. Implements #3535 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3535).
MKVToolNix GUI: header editor: the columns in the tracks/attachments view and the values on the "track type" page will now be updated each time a corresponding property is changed (e.g. when a track's name is changed) instead of showing what's in the file on disk. Implements #3554 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3554).
MKVToolNix GUI: macOS: when you install the application from the DMG it'll register itself as an alternate handler for its supported file types. This allows the use of the "Open with" context menu action in Finder.
MKVToolNix GUI: Windows: a new settings in the preferences lets the user chose whether to use the light or the dark color palette, or to follow the system settings. Part of the fix for #3528 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3528).

Bug fixes

Fixed compilation with fmt v10.0.0.
mkvmerge: fixed several instances of wrong format strings for "fmt::format" used in debug messages. Fixes #3548 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3548).
mkvmerge: AV1 packetizer: the packetizer did not honor the aspect ratio (factor) given on the command-line via the "--aspect-ratio" or "--aspect-ratio-factor" options.
mkvmerge: JSON identification: cropping parameters are reported again even if some of the four values are not present in the file or set to 0. Fixes #3534 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3534).
mkvmerge: Windows: when writing to a network share connected via SMB1 "mkvmerge" was aborting with a error about "create_directory() failed" with existing directories. This was due to a bug in recent versions of the Boost.Filesystem library. The Windows version of MKVToolNix will be built with Boost 1.82.0 from now on which includes the fix. Fixes #3547 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3547).
MKVToolNix GUI: the defunct "disable the dark mode" checkbox was removed from the preferences.
MKVToolNix GUI: language dialog: under certain conditions the controls for the individual components remained disabled when the dialog is opened even though editing of individual components is selected. Part of the fix of #3532 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3532).
MKVToolNix GUI: language dialog: the controls for the individual components weren't re-initialized properly after opening the dialog for the second & all following times, potentially leaving previously selected/entered entries intact, primarily when editing multiple tracks at once. Part of the fix of #3532 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3532).
MKVToolNix GUI: header editor: using the actions from the "modify selected track" context menu only worked if the user right-clicked on the first column in the view. They now work for clicks on any of the columns. See also #3554 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3554).
MKVToolNix GUI: header editor: some of the actions toggling specific flags from the "modify selected track" did not work correctly if the flag wasn't currently present in the file, especially if the underlying value has a default value in the Matroska specs.
MKVToolNix GUI: Windows: the GUI will now always use its own implementation of light & dark palettes instead of relying on Qt. This circumvents two issues with the palette support in Qt 6.5.0: 1. if Windows 11's dark application mode is active, links were displayed in a hard-to-read dark blue. 2. for unknown reasons the the dark palette was not chosen on some Windows 11 installations even though Windows 11's color mode was set to "dark". This is a workaround for #3528 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3528).

Build system changes

The bundled "fmt" library was updated to v10.0.0.
MKVToolNix GUI now uses an external Qt resource file instead of compiling it into the executable. The resource file has reached a size at which the C++ compiler exhausts available virtual memory on some 32-bit architectures. On Windows & macOS the GUI will look for the file in "&lt;folder_with_executables>/data/qt_resources.rcc", and in the directory set with "configure"'s "--datadir" parameter on other systems (which usually means "/usr/share/mkvtoolnix"). The "install" build system commands installs it into that folder.


Have fun 😁

[-QfG-]

Bug in v0.77 (x64 / x86)

If i using the "Header Editor" load a file and then i choose "Segment Information - Title" and set "Add Element" now to Yes/No the Tool crashes. This feature works fine in v0.76.

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

EDIT Not only the function "Title" is corrupt, all functions under Segment Informations corrupted.

[Mosu]

Already fixed. See this issue (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3556).

[-QfG-]

Thanks, works fine now with r011 :)

[Kairys]

How to make a Blu Ray Remux? Tell me the procedure for creating a Bluray remux with Dolby Vision 7 from a BDMV container.
I use programs: MakeMKV, MKVToolNix. Do I need to make mkvextract gMKVExtractGUI after MakeMKV or just add MKV to MKVToolNix?

[Mosu]

First use MakeMKV as that'll preserve DV properly when reading from Blu-rays (MKVToolNix doesn't support reading DV from MPEG transport streams yet, nor from HEVC elementary streams). Then remux the MKV created with MakeMKV with MKVToolNix. No need for extraction. In fact extraction of DV & remuxing the extracted streams will be result in non-compliant Matroska files for the moment as, again, MKVToolNix doesn't support readint DV from MPEG TS & HEVC elementary streams.

[Kairys]

Is it better to add soundtracks in AC3 format or is it possible to add MKA (Matroska Audio)?

[Mosu]

There's no codec called "Matroska Audio". "Matroska Audio" can only mean a Matroska container that only contains audio (no video, no subtitles), but the audio codec can be anything (AAC, AC-3, DTS, Opus…).

[hello_hello]

I have a couple of suggestions/requests regarding the MKVToolNix GUI. How hard they'd be to implement, I have no idea.

One of the things I seem to do most when remuxing is to set or change a delay for a stream and also change a stream's name/description. I had to do this for quite a few files today and having to constantly switch tabs makes the process harder, so it made me wonder how hard it'd be to add a Custom tab to the GUI. The idea being the Custom tab could be configured by the user to contain the most used items from any of the other tabs, saving a lot of tab switching.

Another idea would be to make the columns themselves more useful, so appropriate items could be changed "in-place", rather than just passively display what's been entered under a tab. I'm referring to the section of the GUI in the screenshot below. An example would be changing the delay by clicking on the area where -21 is displayed and entering a new value, or by clicking under the default track column to automatically change the default status. That sort of thing.

Cheers.

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

PS I still think having a copy of the "Abort Job" button on the multiplexer window would be a good idea. 99% of the time when I need to abort a job it's right after I've started it running from the multiplexer widow only to realize I need to change something, so it'd be handy to be able to stop the job from the same window too.

[Mosu]

Thanks for your suggestions. However, I won't implement them. They're all require a lot of effort to implement correctly, and I'm not keen on doing any of the work. Additionally I consider having an "Abort job" button on the multiplexer to be very bad design as there's no guarantee that the job that'll be aborted has anything to do at all with the current multiplex settings.

[hello_hello]

Thanks for your suggestions. However, I won't implement them. They're all require a lot of effort to implement correctly, and I'm not keen on doing any of the work.

No problem. I suspected as much.

Additionally I consider having an "Abort job" button on the multiplexer to be very bad design as there's no guarantee that the job that'll be aborted has anything to do at all with the current multiplex settings.

I'm an idiot, so for a running job I want to abort, I invariably switch to the Job Queue tab before remembering the Abort button's under the Job Output tab, and by the time I've switched tabs again the job's often finished or almost finished running, so these days I usually just add the modified job to the queue and let it over-write the first output file. :)

What about a situation like that where a second job is added to the queue with the same name as a running job or a job already in the queue? You have to click through a warning about over-writing the first job to show that's you're intention, so would it make sense for any existing job with the same name to be aborted automatically if it's running or prevented from running if it hasn't started, given it'll be over-written anyway? The warning dialogue could possibly have an extra button, one to add the new job to the queue without killing any existing job as it currently works, and another to also stop/abort any existing job with the same output file name, or something like that....

[Selur]

Using mkvmerge v77:
mkvmerge --ui-language en -o "G:\Output\2023-06-15@16_46_50_3010__03.mkv" --global-tags "G:\Output\mkvtags_2023-06-15@16_46_50_3010__03.xml" -d 0 --default-track 0:yes --default-duration "0:50/1fps" --aspect-ratio-factor 0:1150/1053 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --field-order 0:0 --no-audio --no-subtitles "G:\Output\2023-06-15@16_47_01_0110_02.264"
and
MP4Box -par 1=1150:1053 -add "G:\Output\2023-06-15@16_47_01_0110_02.264"#video:fps=50:name="":lang="" -brand avc1 -itags tool="Hybrid 2023.06.15.1" -tmp "G:\Output" -new "G:\Output\2023-06-15@16_47_01_0110__03.mp4"
both tell the muxer that the PAR should be 1150:1053.

For the mkv 'mediainfo --full' reports:
Width : 692
Width : 692 pixels
Height : 568
Height : 568 pixels
Stored_Width : 704
Stored_Height : 576
Sampled_Width : 692
Sampled_Height : 568
Pixel aspect ratio : 1.331
Original pixel aspect ratio : 1.092
Display aspect ratio : 1.621
Display aspect ratio : 16:10
Original display aspect ratio : 1.331
Original display aspect ratio : 4:3
for the mp4 'mediainfo --full' reports:
Width : 692
Width : 692 pixels
Height : 568
Height : 568 pixels
Stored_Width : 704
Stored_Height : 576
Sampled_Width : 692
Sampled_Height : 568
Pixel aspect ratio : 1.092
Display aspect ratio : 1.329
Display aspect ratio : 4:3
Original display aspect ratio : 1.331
Original display aspect ratio : 4:3

Using ffmpeg as muxer:
ffmpeg -y -r 50/1 -i "J:\tmp\2023-06-15@17_04_11_3410__04.mkv" -vcodec copy -metadata encoding_tool="Hybrid 2023.06.15.1" -map 0:0 -bsf:v h264_mp4toannexb -aspect 1.3305378330 -r 50/1 "G:\Output\par_1150_1053_ffmpeg.mkv" (using DAR instead of PAR since ffmpeg only handles DAR)
I get:
Width : 692
Width : 692 pixels
Height : 568
Height : 568 pixels
Stored_Width : 704
Stored_Height : 576
Sampled_Width : 692
Sampled_Height : 568
Pixel aspect ratio : 1.092
Display aspect ratio : 1.331
Display aspect ratio : 4:3

Using AV-1 and:
mkvmerge --ui-language en -o "G:\Output\2023-06-15@17_09_18_2810_02.mkv" --global-tags "J:\tmp\mkvtags_2023-06-15@17_07_47_7110__04.xml" -d 0 --default-track 0:yes --default-duration "0:50/1fps" --aspect-ratio-factor 0:1150/1053 --no-chapters --compression -1:none --forced-track 0:yes --field-order 0:0 --no-audio --no-subtitles "J:\tmp\av1_mkvmerge_1_2023-06-15@17_07_47_7110_02.265"
Width : 692
Width : 692 pixels
Height : 568
Height : 568 pixels
Stored_Width : 704
Stored_Height : 576
Sampled_Width : 692
Sampled_Height : 568
Pixel aspect ratio : 1.331
Original pixel aspect ratio : 1.092
Display aspect ratio : 1.621
Display aspect ratio : 16:10
Original display aspect ratio : 1.331
Original display aspect ratio : 4:3
vs MP4Box and:
MP4Box -par 1=1150:1053 -add "J:\tmp\av1_1_2023-06-15@17_09_18_2810_02.265"#video:fps=50:name="":lang="" -brand hvc1 -itags tool="Hybrid 2023.06.15.1" -tmp "J:\tmp" -new "G:\Output\2023-06-15@17_09_18_2810__04.mp4"
mediainfo reports:
Width : 692
Width : 692 pixels
Height : 568
Height : 568 pixels
Stored_Width : 704
Stored_Height : 576
Sampled_Width : 692
Sampled_Height : 568
Pixel aspect ratio : 1.092
Display aspect ratio : 1.329
Display aspect ratio : 4:3
Original display aspect ratio : 1.331
Original display aspect ratio : 4:3
with ffmpeg I get the same as with MP4Box.


=> Did something change on how to tell mkvmerge so set a specific par, is something broken?

Cu Selur

[Mosu]

What about a situation like that where a second job is added to the queue with the same name as a running job or a job already in the queue?

Sure, one could add yet even more functionality and special-cases for those types of user errors, but I just don't want to.

[Mosu]

Did something change on how to tell mkvmerge so set a specific par, is something broken?

I don't think so. Did you try earlier versions? How do they behave compared to v77?

[Selur]

I only tested the last two versions (same behaviour), will test more over the weekend.

[Mosu]

If you find one that behaves differently & the next one doesn't, that'd help me a great deal. I really cannot think of the last time I changed aspect ratio handling.

[hello_hello]

Sure, one could add yet even more functionality and special-cases for those types of user errors, but I just don't want to.

Fair enough, but to me it'd just be an extension of checking a file with the same name doesn't already exist on the disk, except instead of a file being over-written, the job in the queue is replaced.

[Mosu]

I'm not against the functionality per se. If you want to implement it & provide patches/a MR for it, I'd be more than happy to merge them.

[Selur]

@mosu: can't reproduce this anymore, will report back in case it pops up again and I can.

[Mosu]

Heyo!

MKVToolNix v78 is out with tons of bug fixes, especially for those crashes in the GUI's header editor & for the GUI hanging when adding files via drag & drop. Both have crept in in version 77. Fortunately they were only annoying but didn't affect existing files.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.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 78.0 "Running" 2023-07-02
New features and enhancements

MKVToolNix GUI: header editor: for files that only contain legacy track language elements but no IETF language elements the header editor will now derive the IETF language elements from the legacy elements. See #3557 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3557).
AppImage: the AppImage is now built on AlmaLinux 8 with Qt 6.5.1. This means that the minimum glibc version this AppImage is compatible with has also been bumped, to v2.28. The oldest Debian coming with this version is Debian 10 "Buster"; for Ubuntu it's 18.10 "Cosmic Cuttlefish".
Windows installer: the installer will now remove the file "data\portable-app" if it's present in the installation directory as its presence would signal to the app to run in portable mode, requiring write access to its base directory. This fixes some installation issues that could occur when a user extracted a portable app archive into a folder like "C:\Program Files\MKVToolNix". Also added an installation check for the same issue. See #3558 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3558).

Bug fixes

all: Linux: if initializing the locale system based on the system's settings fails, e.g. if environment variables such as "LC_ALL" have been set to "fr_FR.UTF-8" but the locale for "fr_FR.UTF-8" hasn't been built, MKVToolNix will try to fall back to "en_US.UTF-8" first & "C.UTF-8" second. If neither of the three succeeds, an error message will be shown, and the program will abort. This fixes the programs not catching an exception from the "boost::filesystem" library which doesn't cope with mis-configured locale systems well. Workaround for #3574 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3574).
mkvmerge: sorting tracks by type did not work properly when some tracks weren't copied. Part of the fix of #3567 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3567).
mkvmerge: track numbers in the destination file were assigned out-of-order when the track order in the source files differs from the one in the destination file. Now they're assigned sequentially in the order the tracks appear in the destination file again. Part of the fix of #3567 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3567).
MKVToolNix GUI: under certain circumstances the GUI would try to display error messages from a secondary thread, which isn't allowed in Qt, causing to program to either hang or outright crash. Part of the fix of #3556 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3556) & #3561 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3561).
MKVToolNix GUI: the GUI will check for several potential installation issues wrt. to having write access to certain directories (system's temporary directory, MKVToolNix's file identification cache directory and others) & display proper error messages if not. Part of the fix of #3556 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3556) & #3561 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3561).
MKVToolNix GUI: header editor: fixed the application crashing whenever you change a property below the "segment information" node. This bug was introduced in v77. Fixes #3556 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3556).
MKVToolNix GUI: header editor: when reading files that only contain legacy track language elements but no IETF track language elements, the header editor was showing all tracks as having "English" as the language. This bug was introduced in v77. Fixes #3557 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3557).
MKVToolNix GUI: header editor: when a legacy track language element contains a country code (e.g. "fr-CA"), the header editor was wrongfully using "und" = "undetermined" as the language for that element. Now it'll use the language from the language/country pair, which would be "fr" in the earlier example. Part of the fix of #3557 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3557).
MKVToolNix GUI: header editor: the keyboard shortcuts from the "modify selected track" sub-menu didn't work right after opening a file. They only started working after opening the "header editor" menu. Fixes #3573 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3573).
AppImage: fixed the GUI resources (e.g. icons) not being found.
AppImage: the Qt plugins required for using compose key/dead keys are now included. Fixes #3577 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3577).

Build system changes

The compilation database ("compile_commands.json") is now always built. The variable "BUILD_COMPILATION_DATABASE" is not evaluated anymore.


Have fun 😁

[varekai]

Thanks! Much appreciated!

[Perenista]

I am not sure if this was already questioned here:

If we need to handle multiple MKVs, MKVToolnix while capable of adding mutiple tasks, which happen after the former has already finished, cannot open multiple instances of the program. This is only possible if we install an old version somewhere.

Is this the developer's choice, or something else prevents this idea from working?

I'll explain: sometimes I have to deal with, say, more than 10 different files extracted from the discs, bonus features. So I may have to do the same procedure with all of them, at the same time. I could easily do the 1st, then close in the same MKVToolnix instance, and open the 2nd. But it would also help if I could open 2 windows of that program at the same time.

One example:

VirtualDub2. If I need to check how 2 files are different in the same scene/frame, I need to open 2 instances of that program:

If I click in the icon from my taskbar, it will not do it. Only 1. But if I do it again from the shortcut in my desktop, 2, 3 or more are now active:

https://i.postimg.cc/09sYQBPR/WINDOWS.jpg

The same cannot be said of MKVToolnix, which locks me into 1 instance.

[Mosu]

You can have multiple multiplex jobs open in MKVToolNix GUI at the same time. That's the big difference to the old mkvmergeGUI which didn't have that capability. There's no need for a second instance as you can work on multiple jobs simultaneouslyin the same instance.

[Perenista]

Multiple jobs, yes. Once the 1st ends, the other will start. But how can I open multiple tabs inside MKVToolnix and edit two files at the same time?

[Mosu]

"Multiplexer" menu → "New", or Ctrl+N.

[Mosu]

Heyo!

With up to 31°C outside, it's a good idea to stay inside & do the likely last release of the summer for MKVToolNix, v79.0. Not a lot's happened, but there's support for AV1 with Dolby Vision. Yay!

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.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 79.0 "Funeral Pyres" 2023-08-20
New features and enhancements

mkvmerge: AV1: added support for reading Dolby Vision from AV1 IVF & OBU streams. Patches by Quietvoid.
mkvmerge: MPEG TS reader: added support for colors in teletext subtitles. Patch by Angela Schmid.
MKVToolNix GUI: multiplexer: when adding files the GUI can automatically enable the "forced display" flag for subtitle tracks if the file name contains the word "forced" delimited by certain characters (configurable). This feature is turned on by default. Implements #3586 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3586).
MKVToolNix GUI: multiplexer: added the option "--stop-after-video-ends" to the dialog for additional command line options. Implements #3594 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3594).
MKVToolNix GUI: multiplexer: when adding Blu-ray playlists the dialog allowing the user to select the playlist to add will now show audio & video track properties as well (pixel dimensions for video; sampling frequency, channels for audio). Implements #3597 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3597).
MKVToolNix GUI: header editor: in order to reduce confusion with users non that versed in Matroska elements, the naming of the two "language" track properties has been changed: the old element is now titled "Language (obsolete)" & the current, IETF BCP 47 based one is simply called "Language".
MKVToolNix GUI: preferences: you can now use the "delete" key to remove entries from simple list widgets for strings (e.g. the list of recently used destination directories).

Bug fixes

mkvmerge: DTS reader: if a DTS stream doesn't start with a DTS core but a sub-stream element (EXSS), the reader will now look for a core. If found, it'll start processing from there instead of from the start. This fixes the timestamp calculation if the sampling frequency in the core & in the extensions are different. Fixes #3602 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3602).
MKVToolNix GUI: multiplexer: the "emphasis" and "stereoscopy" combo-boxes now have a much smaller minimum width, allowing to make the whole "properties" pane much smaller again. Fixes #3581 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3581).
MKVToolNix GUI: macOS: when you install the application from the DMG it'll no longer register itself as an alternate handler for its supported file types. It seems like this overrode existing associations, forcing people to change them manually to whatever they wanted them to be. Additionally this forced the associated file to always be shown with an MKVToolNix icon. The GUI's own ".mtxcfg" files will still be registered. Fixes #3588 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3588).


Have fun! 😁

[varekai]

Many thanks for the update, much appreciated! :)

[tebasuna51]

Thanks Mosu, you are lucky with 31º here we go over 40º

[Mosu]

Yeah I definitely am lucky to have been born where I have been, no doubt about it. Hope y'all can stay hydrated & safe.

[Kairys]

Does the GPU play a role in ripping?
I am curious as does the GPU play a role in ripping? Would spec'ing a higher end GPU card result in better ripping performance?

[Mosu]

For MKVToolNix the GPU doesn't make a difference as it isn't a video encoder. MKVToolNix solely works at the container level. It's speed is limited by I/O speed, RAM speed, and its architecture.

[Selur]

Okay, how to set the PAR to 1:1 on a source?
With v76 using:
mkvmerge --ui-language en -o "G:\Output\2023-08-25@13_36_38_4410__06.mkv" --global-tags "J:\tmp\mkvtags_2023-08-25@13_36_38_4410__06.xml" -d 0 --default-track 0:yes --default-duration "0:24000/1001fps" --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --field-order 0:0 --no-audio --no-subtitles "J:\tmp\2023-08-25@13_36_38_4410_03.264"
worked fine. (tried x264 and 265 encoded content)
mkvtoolnix-64-bit-76.0-revision-055-g212d04d4e and later set the DAR of the source as PAR.

okay, it's not just PAR 1:1, I tried:
mkvmerge --ui-language en -o "G:\Output\2023-08-25@14_13_41_3610__04.mkv" --global-tags "G:\Output\mkvtags_2023-08-25@14_13_41_3610__04.xml" -d 0 --default-track 0:yes --default-duration "0:25/1fps" --aspect-ratio-factor 0:16/11 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --field-order 0:0 --no-audio --no-subtitles "G:\Output\2023-08-25@14_13_41_3610_03.264" --language 0:aid --default-track 0:yes --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "G:\Output\iId_2_aid_1_2023-08-25@14_13_41_3610_01.mp3" --track-order 0:0,1:1 (also set
--track-order ...')
I uploaded the raw streams and the output to my googleDrive (https://drive.google.com/file/d/1_3tuQwrx0Q-k4h8Tm1m9BCxnBu-B8Ysq/view?usp=drive_link) for you to easily reproduce this.

=> is this a bug, or does setting the PAR work in another way than before, and I missed the change?

PAR seems to be fine if I use '--track-order 0:1,1:2' (offsetting the output numbers by on) => is '--track-order ...' needed for PAR to work?
(Only for x264, x265 encodes this works, for av1 the PAR is broken in this case.)

Cu Selur

[DMD]

Good morning.
Sorry for the stupid question, I don't know if it has been asked already.
I would need to launch multiple instances, is it not possible to do that?
Thank you

[varekai]

Good morning.
Sorry for the stupid question, I don't know if it has been asked already.
I would need to launch multiple instances, is it not possible to do that?
Thank youYes you can start 2, I havn't done that before and don't know if it will work with files added.
Start one as admin and one without and 2 instances will load.

[Mosu]

Good morning.
Sorry for the stupid question, I don't know if it has been asked already.
I would need to launch multiple instances, is it not possible to do that?
Thank you

No, you cannot. You also don't need to as you can easily open several multiplex settings at the same time within that single instance. Working on multiple things simultaneously is very much possible.

BTW: this has been asked & answered (https://forum.doom9.org/showthread.php?p=1990675#post1990675) not even three weeks ago here.

[Mosu]

Okay, how to set the PAR to 1:1 on a source?

This looks a bit buggy. Can you please file an issue over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/)? Thanks.

[DMD]

No, you cannot. You also don't need to as you can easily open several multiplex settings at the same time within that single instance. Working on multiple things simultaneously is very much possible.

BTW: this has been asked & answered (https://forum.doom9.org/showthread.php?p=1990675#post1990675) not even three weeks ago here.
Thank you very much
I had not read the discussion.

[Mosu]

Okay, how to set the PAR to 1:1 on a source?

No need to open an issue anymore. The problem should be fixed by this commit (https://gitlab.com/mbunkus/mkvtoolnix/-/commit/aa2588bb1447826d71391da408cd6b5020128b26). Please read the explanation in the commit's message for details on what actually happend.

[Selur]

Thanks, afk. today, will look at it tomorrow evening and report back.

[Selur]

Okay, I did some tests:
av1:
mkvmerge --ui-language en -o "G:\Output\2023-09-03@18_46_32_6310__02.mkv" --global-tags "J:\tmp\mkvtags_2023-09-03@18_46_32_6310__02.xml" -d 0 --default-track 0:yes --default-duration "0:25/1fps" --aspect-ratio-factor 0:16/11 --no-chapters --compression -1:none --forced-track 0:yes --field-order 0:0 --no-audio --no-subtitles "J:\tmp\av1_1_2023-09-03@18_46_32_6310_01.av1" --track-order 0:1
x264:
mkvmerge --ui-language en -o "G:\Output\2023-09-03@18_46_46_6310__02.mkv" --global-tags "J:\tmp\mkvtags_2023-09-03@18_46_46_6310__02.xml" -d 0 --default-track 0:yes --default-duration "0:25/1fps" --aspect-ratio-factor 0:16/11 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --field-order 0:0 --no-audio --no-subtitles "J:\tmp\2023-09-03@18_46_46_6310_01.264" --track-order 0:1
x265:
mkvmerge --ui-language en -o "G:\Output\2023-09-03@18_46_54_1610__02.mkv" --global-tags "J:\tmp\mkvtags_2023-09-03@18_46_54_1610__02.xml" -d 0 --default-track 0:yes --default-duration "0:25/1fps" --aspect-ratio-factor 0:16/11 --no-chapters --compression -1:none --forced-track 0:yes --field-order 0:0 --no-audio --no-subtitles "J:\tmp\2023-09-03@18_46_54_1610_01.265" --track-order 0:1
Conclusion is: Now x264 and x265 works, but av1 is broken.
I tried av1 files created with QSVEncC, NVEncC, aomenc, svt-av1, to be sure it's not related to av1 from one encoder.
And the funny thing is the av1 streams from av1-svt, rave1 and aomenc are handled correctly, the others are not.
Uploaded the muxed files to GoogleDrive (https://drive.google.com/drive/folders/1oz4h0J5W3l6kRe9mqMtnVciOcloM6ySz?usp=drive_link).

Cu Selur

[Boulder]

Running mkvalidator on one file muxed by mkvmerge 79.0, I get an error "ERR0B1: Block at 1439158911 track #2 is not a keyframe". Didn't try reinstalling the previous version yet, but is this something to submit an issue about?

[Mosu]

Running mkvalidator on one file muxed by mkvmerge 79.0, I get an error "ERR0B1: Block at 1439158911 track #2 is not a keyframe". Didn't try reinstalling the previous version yet, but is this something to submit an issue about?

No. That's wrongly labeled as an error by mkvalidator. In my personal opinion this shouldn't even be a warning. It's not a violation of the specs, it's not even a severe issue wrt. performance. Would it be ideal to have each cluster start with a key frame for each track? Sure. Is it always possible? Definitely not.

[Ripman]

Hey M. Hope you had a nice summer. About 34 today in NYC.

=> Is “Video Display Unit” (VDU) set based on the values for “Video Display Width” (VDW) and “Video Display Height” (VDH) passed with the --display-dimensions option? Or maybe based on whether the --aspect-ratio option or the --aspect-ratio-factor option was used.

(I’m assuming --aspect-ratio can be passed as 16x9, 4x3, 1.85, 2.40, etc., but I’m not sure what values can be passed for --aspect-ratio-factor.)

The reason I ask is because I have a widescreen mpeg2 video, that, after being cropped and encoded to mpeg4, shows a VDW of 11418 and a VDH of 6237 via the MKVToolNix header editor. This will give the proper aspect ratio of (almost) 1.85, but I think these “big” values can cause problems with TVs and other HW because the equipment isn’t expecting numbers that big. The cropped video is 718 wide and 462 high, and with a PAR of 32/27 gives the same aspect ratio as the big numbers above.

(Do these big values 11418 x 6237 seem normal - do they make sense?)

Here is a post where I describe the details with links to work files, etc. Go to the 2 most recent posts at the bottom - August 24.

https://forum.handbrake.fr/viewtopic.php?t=43016

Any insights are very much appreciated. I’m trying to figure out if this is an equipment/HW limitation, an encoding bug, or a lack of understanding on my part. The reason I asked about the options is for the case where it is an equipment/HW limitation or an encoding bug and some repairs would need to be done on older encodes - I’ve already developed a Perl script that uses mkvinfo and mkvmerge and updates the VDW and VDH values based on the “Video Pixel Width” and “Video Pixel Height” from the mkv header. I want know how to handle VDU. Thanks and best…..

[tormento]

I have found this (https://github.com/gnoling/UnlinkMKV) utility.

Is it possible to do the same with "standard" MKVToolnix package?

[Ripman]

I have found this (https://github.com/gnoling/UnlinkMKV) utility.

Is it possible to do the same with "standard" MKVToolnix package?

Yes. MKNToolNix is a more comprehensive tool with excellent stability and accessible expertise. That’s the gui version. There are also command line utilities in the bundle so that all operations can be ‘batched’ - mkvinfo mkvmerge mkvextract.

Read the man pages. They are very detailed.

[tormento]

Sorry if it's been already asked but I have searched and not found.

When importing a BD episodic playlist, sometimes there are opening and ending sections for every episode in the middle of the episode itself, before the epilogue or after the prologue.

Besides having the "Before chapters", it would be nice to have a syntax such as "4-5+10-11, 12-13+18-19" or something like that to tell the program to use from chapters 4 to 11 but chapters 5 and 11 and from chapters 12 to 19 but chapters 13 and 19.

I could do it splitting by hand, encoding and joining by hand but I should deal later with chapters, subtitles, etc.

[hubblec4]

cE has such an option to split and join the parts you have mentioned automatically.
BD2mkv -> Split-section
OK, there you can only enter time stamps, not chapter numbers.

[tormento]

cE has such an option to split and join the parts you have mentioned automatically. BD2mkv -> Split-section
OK, there you can only enter time stamps, not chapter numbers.
Thanks for the info and the feature.

Unfortunately, manually inserting time stamps would be a PITA for large BD collections.

[TheEqualizer]

mp4fpsmod?

-d, --delay <n> Delay audio by n millisecond.



Is it possible to select a specific audio track to apply the delay (we are talking about when there are several audio tracks in the video), I tried the -map parameter, swears that I don't understand, I can't find a solution.

[tormento]

I am trying to split a mpls by frames, using 'After frame/field numbers' and in 'Frames/fiels:' I am feeding the values:

951,44243,79459,85791,121017,124634,127241,129940,162576,166176,172438.175137,204104,207714,209988,212687,245555,251865,287078,290673,292920,295619,328600

The resulting error is:

Invalid frame for '--split' in '--split frames

The resulting CLI is:

mkvmerge.exe --ui-language en --output ^"N:\Raw\26-00017.mkv^" --language 0:en --language 1:it --language 2:ja --language 3:it ^"^(^" ^"N:\Naruto_BD26\BDMV\PLAYLIST\00017.mpls^" ^"^)^" --split frames:2698,37951,44243,79459,85791,121017,124634,127241,129940,162576,166176,172438.175137,204104,207714,209988,212687,245555,251865,287078,290673,292920,295619,328600 --chapter-language und --generate-chapters-name-template ^"Capitolo ^<NUM:2^>^" --track-order 0:0,0:1,0:2,0:3

What am I doing wrong?

[Mosu]

frames: expects a single number, which is taken to mean "split after every n frames".

Try "by parts by frames" or whatever it's called in the GUI; the CLI equivalent: "--split parts-frames:a,b,c,d,…"

[Boulder]

I've been trying to teach the AI to create a simple chunked encoding tool. The basic stuff works fine, but it stumbles upon joining the resulting webm files. Is there a way to feed a simple list of files to concatenate with mkvmerge? I'd rather not use ffmpeg as it seems to cause some issues like repeating frames. The input list would be like:

F:\Temp\Captures\encodes\lotr_fotr\chunks\encoded_chunk_0.webm
F:\Temp\Captures\encodes\lotr_fotr\chunks\encoded_chunk_1.webm

etc. The number indexing is not a problem, that can be adjusted.

[Mosu]

With a shell that expands shell wildcards (e.g. bash, zsh), sure: mkvmerge -o out.webm [ encoded_chunk*.webm ]

[tormento]

With a shell that expands shell wildcards (e.g. bash, zsh), sure: mkvmerge -o out.webm [ encoded_chunk*.webm ]
Your download repository is giving me bad gateway error.

Anyone else?

[Mosu]

Thanks for the heads-up. I've restarted the offending daemon.

[Magister Irrylio]

Will A_MS/ACM support ever be added to mkvextract? I can get around it by just putting it into an mka with mkvtoolnix and then converting that to FLAC with ffmpeg, but it's inconvenient compared to just extracting every track, especially when working with multiple files. Don't really see why mkvextract can't simply extract it.

[Mosu]

I'm not interested in implementing it.

[Mosu]

Heyo!

Time for another release. I'm still in a bit of a coding slump (or rather: preoccupied with all the amazing games that have come out this year); therefore this release is really, really small. I'll likely do one more bug fix release this year that'll be around this size as well. But let's see how things shake out.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.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 80.0 "Roundabout" 2023-10-29
New features and enhancements

MKVToolNix GUI: if the system's locale uses one of the Han scripts, the GUI will force Arabic numerals to be used in spin boxes. This prevents Suzhou numerals from being used which seems to be the default on Windows systems sold in China. Implements #3624 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3624).

Bug fixes

build system: fixed detection of Qt6 if "clang" is used for compilation on Linux. In that case Qt's "qmake" added a "gcc"-specific option that "clang" doesn't understand, "-mno-direct-extern-access". "configure" will now pass the parameter "-spec linux-clang" to "qmake" so that it uses the correct compiler flags.
build system: fixed the use of "mktemp" to be more portable to e.g. macOS. Fixes #3608 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3608).
mkvmerge: if a video aspect ratio was given with "--aspect-ratio-factor", the code would apply a second factor based on the pixel resolution, resulting in much too large values for the "DisplayWidth" element. For example, with a pixel resolution of 720x520 & an aspect ratio factor of 1/1 the result should be 720x520, but instead it was 900x520. Up until release 76.0 this has only happened when a track order was given (which unfortunately includes all invocations with MKVToolNix GUI as it always includes the track order). Starting with release 77.0 this has always happened due to the automatic sorting of tracks implicitly creating a track order, even if none was given.


Have fun 😁

[varekai]

Thanks, much appreciated!! :)

[Perenista]

Is there a way to disable the warning about saving files with only the video track?

[Mosu]

Yes, in the preferences → "Multiplexer" → "Warn about missing audio tracks".

[Grimsdyke]

I tried to merge a few files lately using the wonderful chapter feature in MKVtoolNix !!
However there were already some warnings given -> merging was done but video got distorted right at the first warning point. Sound was fine.

I tried all things that I could think of but unfortunately the only way I found was merging in FFmpeg -> conversion to m4V -> adding chapters then with Drax.
So I was wondering. Is there the possibility to "out source" merging towards ffmpeg in MKVtoolNix in such situations ?

[Emulgator]

You would just have to do the outsourcing yourself (i.e. reencode) and I would suggest this in any such case.
A muxer can only mux, maybe check for compliancy and reject things that can not be merged.
Any task beyond that will be job of the person tasking the various softwares, me too ;-)

[oniiz86]

I have an audio delay discrepancy when splitting the file with "By parts based on timestamps", the file's "Delay relative to video" is 2s 2ms (2002ms) & was wondering if it is normal behaviour for the delay variance depending on where a split is made?

The file in its entirety below,

Audio
ID : 2
Format : DTS ES XCh XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 1 h 44 min
Bit rate mode : Variable
Bit rate : 4 738 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs LFE Cb
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 2 s 2 ms
Stream size : 3.44 GiB (25%)
Title : DTS-HD MA 6.1
Language : English
Default : Yes
Forced : No

A 3min sample has a 7ms delay

Audio
ID : 2
Format : DTS ES XCh XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 3 min 0 s
Bit rate mode : Variable
Bit rate : 5 599 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs LFE Cb
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 7 ms
Stream size : 120 MiB (24%)
Title : DTS-HD MA 6.1
Language : English
Default : Yes
Forced : No

A 4min 55s sample has a 1ms delay

Audio
ID : 2
Format : DTS ES XCh XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 4 min 55 s
Bit rate mode : Variable
Bit rate : 4 846 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs LFE Cb
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 1 ms
Stream size : 171 MiB (24%)
Title : DTS-HD MA 6.1
Language : English
Default : Yes
Forced : No

[tormento]

I have an audio delay discrepancy when splitting the file with "By parts based on timestamps", the file's "Delay relative to video" is 2s 2ms (2002ms) & was wondering if it is normal behaviour for the delay variance depending on where a split is made?

Does the track have video too? If positive, AFAIK you can split video only at I-Frames.

[oniiz86]

Does the track have video too? If positive, AFAIK you can split video only at I-Frames.

Sorry, yes it does, the film is X-Men: The Last Stand, is a delay of 2s 2ms (2002ms) fairly significant, I can't detect any audible delay, I was just curious why it varied so much depending on where the timestamps are split when making a short sample, here is the video stream below,

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 44 min
Bit rate : 13.7 Mb/s
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.373
Stream size : 10.00 GiB (74%)
Writing library : x264 core 155 r2901 7d0ff22
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=48 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=25 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Audio
ID : 2
Format : DTS ES XCh XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 1 h 44 min
Bit rate mode : Variable
Bit rate : 4 738 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs LFE Cb
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 2 s 2 ms
Stream size : 3.44 GiB (25%)
Title : DTS-HD MA 6.1
Language : English
Default : Yes
Forced : No

[Mosu]

I have an audio delay discrepancy when splitting the file with "By parts based on timestamps", the file's "Delay relative to video" is 2s 2ms (2002ms) & was wondering if it is normal behaviour for the delay variance depending on where a split is made?

Yes, this is normal.

The "delay of video relative to audio" is simply the difference of the timestamps of the first video & first audio packets. At the start of the file it's relatively normal to have audio start quite a bit later than the video, in your example more than 2s later.

However, there's absolutely no reason to assume that there's a gap in the audio somewhere in the middle. Therefore when you split the second & all following files will have both audio & video content very near the start of the file, and therefore a much, much smaller difference between the timestamps of the first audio & video packets.

Furthermore, audio & video packets almost always have a different duration. For videos typical values include 40ms (for a 25 FPS video) or 41,708333ms (for a 23.976 FPS video). Typical values for audio on the other hand include 21,333ms for AAC @ 48.000 Hz and similar values.

Let's assume your video is 25 FPS with the aforementioned AAC @ 48.000 Hz audio track, and you have a key frame at the 30th frame, which means at 30 * 40ms = 1200ms. For audio the closest packet that plays at 1200ms starts at 21.333ms * floor(1200ms / 21.333ms) = 21.333ms * 56 = 1194.648ms. However, mkvmerge only includes packets in the new file that start at or after the splitpoint, meaning that audio frame will not be written into the new file. Instead, the next one will be, which starts at 21.333ms * ceiling(1200ms / 21.333ms) = 21.333ms * 57 = 1215,981. The difference between the timestamps of this first audio frame & the video frame where we split is obviously 15.981ms, and that's the value you'll see for this particular split as the delay between audio & video.

You can then make similar calculations for a different split point. Let's assume you have one at 76 frames = 76 * 40ms = 3040ms. The first audio frame that'll end up in the new file is located at 21.333ms * ceiling(3040ms / 21.333ms) = 21.333ms * 143 = 3050.619ms. The difference for this case is 10.6619ms, which is different than the previous example.

[tormento]

I have a strange issue.

I have created a mkv from DVD with MakeMKV (but I don't think that is the cause).

If I try to split by chapters AND I keep only the video — removing audio, subs and chapters entries from Tracks, chapters and tags — MKVToolNix GUI doesn't split the mkv and gives me the full lenght file.

Is it a bug or by design?

[Mosu]

If you opt not to copy chapters from the source, then it cannot split by chapters. The reason is that the split decisions are made way later than the decision whether or not to read chapters from a file.

[tormento]

If you opt not to copy chapters from the source, then it cannot split by chapters. The reason is that the split decisions are made way later than the decision whether or not to read chapters from a file.


I understand. [emoji4]

That’s a pity as if I want to cut a video but to have no chapters in it, I’d have to remix twice. [emoji20]

[hello_hello]

I've noticed that MKVToolNix sometimes applies a delay to the video stream when splitting MKVs. That is, after splitting, a split section might have a video delay, sometimes of a few seconds. Fortunately this doesn't seem to alter the A/V sync. If the first split section begins at the start of the source MKV, it never has an additional delay applied to the video. Only sections from the first split point sometimes have a video delay.

I often use MKVToolNix to split MKVs after I've encoded a video. I do this by also encoding the sections I want to remove (separately), appending them to the sections I'm keeping, then split on the appropriate frames while remuxing. Doing so ensures the video has a keyframe at the split points, and of course it splits any audio and subtitle streams to match so they don't need to be split separately. Once again though, the split MKV sometimes has a substantial video delay, although the A/V sync is okay.

There's a link to a 6kB zip file below containing two small sample MKVs. Neither MKV contains a stream other than (blank) video and neither has a video delay. The first MKV contains 140 frames of AVC video.
If I open "Test A.mkv" from the zip file and append "Test B.mkv", then remux while telling MKVToolnixGUI to split the output after frame 140, logically the output MKVs should be the same as the input MKVs, but in this case the second output MKV has a video delay of 600ms, and I'm just trying to understand why.

Test.zip (https://files.videohelp.com/u/210984/Test.zip)

Cheers.

[Perenista]

Is there a way to actually add a new subtitle to a MKV, but that new track have the "default" disabled by default?

If I am not mistaken, if we enable this option, it also disables the "default" for the others which are already DEFAULTED.

Example: my file has:

1) A video track = DEFAULT track option enabled (english)
2) An audio track = DEFAULT track option enabled (english)
3) A subtitle track = DEFAULT track option enabled (english)

If I add a 4th track:

4) A subtitle track = in another language, like ITALIAN;

I don't want the 4th to have the "DEFAULT" flag enabled; instead, I want it DISABLED.

A 4th or any other additional tracks. All new stuff with this flag turned OFF.

I often use MKVToolNix to split MKVs after I've encoded a video.I stopped splitting any file with MKVToolnix a long time ago, because that always broke the resulting MKV. It had A/V sync issues, and I was unable to revert the damage. Only a few were not affected, it was totally random. I used to do this because I had more than 1 Google Drive acc, with 15 GB each, and some MKVs were big.

I should never have tried this, since it introduces problems I never saw again, once I stopped with this practice. Now I always let the file with its original size, and if needed, use WinRAR to split the thing. Trust me, if you never noticed, it was pure luck, this is always bound to happen, and it doesn't matter if you try to append the splitted parts later. This is similar to destroying a vase, trying to glue the broken pieces, then arguing nothing changed.

[Mosu]

Heyo!

Here's MKVToolNix v81, the latest & greatest etc. etc. A lot of work went into improving & finishing the support for Dolby Vision. Apart from that there are several usability improvements & bug fixes, as usual.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows 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.

Please note that I don't have macOS binaries yet, and due to issues with my build machine I cannot give an ETA for them either.

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

Version 81.0 "Milliontown" 2023-12-02
New features and enhancements

mkvmerge: MPEG transport stream reader: HEVC/H.265: added support for reading single-layer Dolby Vision from Annex B type bitstream read from MPEG transport streams. Partially implements #3113 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3113).
mkvmerge: MPEG transport stream reader, HEVC/H.265 elementary stream reader: added support for reading dual-layer Dolby Vision with both the base & enhancement layers in the same track from Annex B type bitstreams in MPEG transport files & elementary stream files. Implements #3126 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3126).
mkvmerge: MPEG transport stream reader: HEVC/H.265: implemented combining dual-layer Dolby Vision with base & enhancement layers in different tracks. Implements #3127 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3127).
MKVToolNix GUI: multiplexer: added a new option in the preferences for always enabling 'forced' subtitle tracks. A subtitle track is considered to be 'forced' if: the corresponding property is set in the source file; the track's name contains the word 'forced' (in English); deriving the 'forced display' flag from file names is active & the file name matches the corresponding pattern. The option is disabled by default. Implements #3627 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3627).
MKVToolNix GUI: multiplexer: the functionality for detecting file name sequences when adding files can now recognize the patterns used by GoPro's cameras for chaptered video files. Implements #3633 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3633).
xyzvc_dump: the end position of the current NALU will be output in non-portable format as well.
xyzvc_dump: HEVC: the tool will now also output the inner NALU type of Dolby Vision NALUs ("unspec62" and "unspec63").

Bug fixes

mkvmerge: when the user requests processing be stopped after the video ends "mkvmerge" will now take appending files into account properly. It won't stop processing unconditionally after the first file ends anymore. Fixes #3618 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3618).
mkvmerge: AV1 handling in readers: the readers will now provide the pixel dimensions to the AV1 packetizer as early as possible, just like for other video packetizers. That way the pixel dimensions are available for calculating the display dimensions when command-line options such as "--aspect-ratio" & "--aspect-ratio-factor" are used. Before the change the calculation was done based on initial pixel dimension values of 0x0, resulting in display dimensions of 0x0, too. Fixes #3611 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3611).
mkvmerge: HEVC/H.265 packetizer: when reading & appending HEVC/H.265 from Matroska, MP4/MOV or FLV files the first frame of all the appended files was sometimes dropped, resulting in broken video at the point where video is appended. Fixes #3479 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3479).
mkvmerge: MPEG transport stream reader: when reading MPEG transport streams from Blu-rays the four-byte long "TP_extra_header" structure in front of the transport packets are now skipped properly. Before the fix a stray byte with value of "0x47" inside that "TP_extra_header" structure could have thrown off the detection of where the transport packets start, leading to mkvmerge dropping a few audio and/or video frames at the start of the file. Fixes #3632 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3632).
mkvextract: AAC extractor: when an invalid program config element in the GA-specific config element is encountered, the program config element will be disregarded, which avoids mkvextract aborting with an exception. Fixes #3606 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3606).
xyzvc_dump: fixed the tool aborting with an exception when the last NALU in an Annex B type file was shorter than four bytes.

Other changes

AVC & HEVC dumper development tool: the tool has been renamed from "xvc_dump" to "xyzvc_dump" as "xvc" is an abbreviation for an existing video codec (Extreme Video Coding), and the tool has nothing to do with that codec.


Have fun! 😁

[Emulgator]

Nice, many thanks !

[markfilipak]

Hi All. I'm running Win7-64bit. What's the 'last' Win7 release of mkvtoolnix?

I know where the vintage packages are but I can't find any release info, so I don't know which to download. I've been running v.61 but I've encountered an mkvextract bug in v.61 when there's 'extra' dots in the file name (e.g., c:\my..video.mkv). The bug makes scripting too difficult. Thanks -- Mark.

[manolito]

Win7 compatible builds are here:

https://forum.doom9.org/showthread.php?t=184092

At the very end of this thread you can find the current versions which are built to work under Win7.


Cheers
manolito

[Snowknight26]

Did m2ts parsing break in v81?

Tried to remux several Blu-rays and each time v81 silently aborts when the output file has been opened for writing.

v81:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\test.mkv^" --no-audio --no-subtitles --no-chapters --language 0:und ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\PLAYLIST\00001.mpls^" ^"^)^"
mkvmerge v81.0 ('Milliontown') 64-bit
Scanning 2 files in 1 playlist.
Done scanning playlists.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'Z:\temp\test.mkv' has been opened for writing.


v80 (stopped with Ctrl+C):

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\test.mkv^" --no-audio --no-subtitles --no-chapters --language 0:und ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\PLAYLIST\00001.mpls^" ^"^)^"
mkvmerge v80.0 ('Roundabout') 64-bit
Scanning 2 files in 1 playlist.
Done scanning playlists.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'Z:\temp\test.mkv' has been opened for writing.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Extracted the aspect ratio information from the video bitstream and set the display dimensions to 1920/1080.
^Cogress: 3%

[Mosu]

Oh? It shouldn't have, and none of my test cases have failed. That being said, the changes for Dolby Vision did modify the transport stream code quite a bit. It's quite possible something broke that shouldn't have.

Can you provide some more information? I just gave it a try; remuxing the "Solo — A Star Wars Story" Blu-ray via the GUI worked just fine (playlist 00800.mpls).

[Snowknight26]

Ah ok, now I'm getting somewhere. It looks like v81 fails to write anything to the output file if the input is either a Blu-ray playlist or m2ts (and possibly others, but haven't tested) that contains a PCM track and you specifically don't include the PCM track in the output.

v81, M2TS with 2 streams, H.264 and PCM, with PCM unchecked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --no-audio --language 0:und ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts^" ^"^)^"
mkvmerge v81.0 ('Milliontown') 64-bit
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'Z:\temp\temp.mkv' has been opened for writing.


v81, M2TS with 2 streams, H.264 and PCM, with PCM checked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --language 0:und --language 1:ja ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts^" ^"^)^" --track-order 0:0,0:1
mkvmerge v81.0 ('Milliontown') 64-bit
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 1: Using the output module for the format 'PCM'.
The file 'Z:\temp\temp.mkv' has been opened for writing.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 0: Extracted the aspect ratio information from the video bitstream and set the display dimensions to 1920/1080.
^Cogress: 4%

v81, different M2TS with 2 streams, H.264 and PCM, with PCM unchecked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --no-audio --language 0:und ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts^" ^"^)^"
mkvmerge v81.0 ('Milliontown') 64-bit
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'Z:\temp\temp.mkv' has been opened for writing.


v81, different M2TS with 2 streams, H.264 and PCM, with PCM checked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --language 0:und --language 1:ja ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts^" ^"^)^" --track-order 0:0,0:1
mkvmerge v81.0 ('Milliontown') 64-bit
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 1: Using the output module for the format 'PCM'.
The file 'Z:\temp\temp.mkv' has been opened for writing.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Extracted the aspect ratio information from the video bitstream and set the display dimensions to 1920/1080.
^Cogress: 4%


v81, playlist with multiple streams (H.264, PCM, DTS-HD MA, chapters), with PCM unchecked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --audio-tracks 2,3,4 --language 0:und --language 2:ja --language 3:ja --language 4:ja ^"^(^" ^"Z:\temp\FFXIV_FATU\BDMV\PLAYLIST\00003.mpls^" ^"^)^" --chapter-language und --generate-chapters-name-template ^"Chapter ^<NUM:2^>^" --track-order 0:0,0:2,0:3,0:4
mkvmerge v81.0 ('Milliontown') 64-bit
Scanning 8 files in 1 playlist.
Done scanning playlists.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 4: Using the output module for the format 'DTS'.
The file 'Z:\temp\temp.mkv' has been opened for writing.


v81, playlist with multiple streams (H.264, PCM, DTS-HD MA, chapters), with PCM checked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --language 0:und --language 1:ja --language 2:ja --language 3:ja --language 4:ja ^"^(^" ^"Z:\temp\FFXIV_FATU\BDMV\PLAYLIST\00003.mpls^" ^"^)^" --chapter-language und --generate-chapters-name-template ^"Chapter ^<NUM:2^>^" --track-order 0:0,0:1,0:2,0:3,0:4
mkvmerge v81.0 ('Milliontown') 64-bit
Scanning 8 files in 1 playlist.
Done scanning playlists.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 4: Using the output module for the format 'DTS'.
The file 'Z:\temp\temp.mkv' has been opened for writing.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 0: Extracted the aspect ratio information from the video bitstream and set the display dimensions to 1920/1080.
Appending track 0 from file no. 1 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts') to track 0 from file no. 0 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts').
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 0: Extracted the aspect ratio information from the video bitstream and set the display dimensions to 1920/1080.
Appending track 2 from file no. 1 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts') to track 2 from file no. 0 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts').
Appending track 3 from file no. 1 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts') to track 3 from file no. 0 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts').
Appending track 4 from file no. 1 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts') to track 4 from file no. 0 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts').
Appending track 1 from file no. 1 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts') to track 1 from file no. 0 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts').
^Cogress: 7%

[hello_hello]

I stopped splitting any file with MKVToolnix a long time ago, because that always broke the resulting MKV. It had A/V sync issues, and I was unable to revert the damage. Only a few were not affected, it was totally random. I used to do this because I had more than 1 Google Drive acc, with 15 GB each, and some MKVs were big.

Well I can't say I've ever had problems splitting files, and I've done it hundreds of times over the years. The only "issue" has been MKVToolNix applying a video delay to a split section. The delay can be removed by applying an appropriate negative delay to each stream, making the video delay zero. I've never experienced A/V sync problems as a result, but I was curious as to why there's a video delay in the first place, especially in the case of the samples I uploaded, where the video is the only stream....

[markfilipak]

Win7 compatible builds are here:

https://forum.doom9.org/showthread.php?t=184092

At the very end of this thread you can find the current versions which are built to work under Win7.
Thank you, Manolito. I was able to upgrade to v.81. The mkvextract bug is still there.

Script:
set NAME=STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris
set M2TS=h:\BDMV\STREAM\00004.m2ts
set TARGETPATH=g:\Movies I'm working on\STAR TREK, TNG
ffmpeg -i "%M2TS%" -map 0:s:0 -s 1920x1080 -c:s dvdsub -f matroska "%TARGETPATH%\%NAME%.mkv"
"C:\Program Files\MKVToolNix\mkvextract" "%TARGETPATH%\%NAME%.mkv" tracks 0:"%TARGETPATH%\%NAME%"

Result:
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..idx
Should be:
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris.idx

Result:
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..sub
Should be:
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris.sub

--Mark.

[Mosu]

Ah ok, now I'm getting somewhere. It looks like v81 fails to write anything to the output file if the input is either a Blu-ray playlist or m2ts (and possibly others, but haven't tested) that contains a PCM track and you specifically don't include the PCM track in the output.

Interesting. Please open an issue over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/) for it. Thanks.

[Mosu]

Thank you, Manolito. I was able to upgrade to v.81. The mkvextract bug is still there.

This is not a bug. You're effectively calling mkvextract with like this (replacing the variables with copy-pasted content):

"C:\Program Files\MKVToolNix\mkvextract" "g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris.mkv" tracks 0:"g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris"

Note that there's neither ".idx" nor ".sub" at the end. However, mkvextract has to create those two files. It assumes that the user always specifies a file extension for the output file name. It then replaces the extension with .idx for the first file & with .sub for the second file.

The extension is simply the part starting with the last . in the name. Therefore the result is pretty self-explanatory.

If it didn't replace the extension but only appended .idx & .sub, most users would simply end up with "filename.idx.idx" and "filename.idx.sub", which would be assinine.

No, mkvextract cannot read your mind. Therefore it makes the sensible assumption that the user always specifies a file extension.

Just add ".idx" to the end; it should work fine, e.g.

"C:\Program Files\MKVToolNix\mkvextract" "%TARGETPATH%\%NAME%.mkv" tracks 0:"%TARGETPATH%\%NAME%.idx"

[j7n]

Can you say which input formats currently have automatic audio delay compensation implemented? I want to avoid compensating twice.

[Mosu]

For each source file mkvmerge will normalize the timestamps so that the lowest timestamp of that file starts at 0. The relative timestamps will remain intact (e.g. if audio starts at 120ms, video starts at 40ms, then mkvmerge will subtract 40ms from all timestamps from that one file so that audio starts at 80ms, video at 0ms). Meaning that if you take a file containing more than one track & mux it the audio, video & subtitles from that one file should always stay in sync.

There's nothing in mkvmerge to synchronize audio & video from different files apart from the aforementioned normalization to starting at 0ms for each individual file.

On top of that mechanism the GUI can scan file names & recognize a delay mentioned in the file name & apply it via mkvmerge's "--sync" option. mkvmerge itself doesn't have something similar (for good reason).

In other words: manually specifying --sync… should ideally only be needed if you combine tracks from different source files as there's no way for mkvmerge to automagically sync them up.

[markfilipak]

This is not a bug.
Yes, I see that now. But it is illogical.
Note that there's neither ".idx" nor ".sub" at the end. However, mkvextract has to create those two files.
That's why it's illogical.

The template I used was from another site. It appeared from it that only the /path/name was supplied -- no extension (file type). That made sense because mkvextract makes 2 files: IDX & SUB, and calling it with only one extension is illogical.

Your explanation works, thank you, but it doesn't explain why
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris
became
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987.
The extension is simply the part starting with the last . in the name. Therefore the result is pretty self-explanatory.
But why would mkvextract remove the 'extension'. That's illogical. I have plenty of files with names like 'mkvextract.exe.txt'.
If it didn't replace the extension but only appended .idx & .sub, most users would simply end up with "filename.idx.idx" and "filename.idx.sub", which would be assinine.
I disagree. It would be logical and it would be immediately apparent to everyone what happened, and they would supply just /path/name. In my case, I was running a script and when the 'extensions' were removed, there was a collision because the only parts that differed were the 'extensions'. What would be logical is to specify just /path/name like I did.

It's a small deal and I've 'fixed' my code, so don't trouble yourself.
Just add ".idx" to the end; it should work fine, e.g.
Thank you. I am doing that now. But it's still illogical. :-)

[Mosu]

But why would mkvextract remove the 'extension'.

Because most people who use mkvextract do actually specify an extensions such as .idx or .sub when they try to extract VobSub subtitles — as they have to specify extensions for all other file types, too. Therefore mkvextract assumes that people do that and replaces the existing extension for each of the two files.

Don't make the mistake of assuming that what you find logical or illogical is universal. Most people work differently than you do (same goes for anyone, really; most people work differently than I do, for example). I had tried not to replace extensions in the past, which lead to a lot of confused users. The current way of replacing extensions only lead to one complaint (yours) over the last ten years or so. This is my experience, and that's why mkvextract behaves this way.

[j7n]

I read some time ago (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/715) that in MP4 files the tag ITunSMPB was taken into account and converted into a delay in addition to one specified by --sync. What I want to know is which (if any) other elementary stream formats have received similar treatment since that issue was resolved. I'm not asking for any changes, just to clarify the current situation.

[-QfG-]

Is there a way to actually add a new subtitle to a MKV, but that new track have the "default" disabled by default?

If I am not mistaken, if we enable this option, it also disables the "default" for the others which are already DEFAULTED.


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

Simply set this switch. I hope in future of the same options for audio, too.

[Mosu]

I read some time ago (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/715) that in MP4 files the tag ITunSMPB was taken into account and converted into a delay in addition to one specified by --sync. What I want to know is which (if any) other elementary stream formats have received similar treatment since that issue was resolved. I'm not asking for any changes, just to clarify the current situation.

There are no other formats that I know of that have similar information on top of the already existing timestamps in the file format.

[hello_hello]

There's a link to a 6kB zip file below containing two small sample MKVs. Neither MKV contains a stream other than (blank) video and neither has a video delay. The first MKV contains 140 frames of AVC video.
If I open "Test A.mkv" from the zip file and append "Test B.mkv", then remux while telling MKVToolnixGUI to split the output after frame 140, logically the output MKVs should be the same as the input MKVs, but in this case the second output MKV has a video delay of 600ms, and I'm just trying to understand why.

Test.zip (https://files.videohelp.com/u/210984/Test.zip)

Cheers.

Mosu, any chance of an answer to this one? I'm curious....

Cheers.

[Mosu]

I've written in depth about how mkvmerge's splitting & appending works and am not in the mood to write all that up once again. Sorry. Just be aware that splitting+appending is not a lossless process, for various reasons. You can play around with "--append-mode file" vs "--append-mode track", if you want.

[hello_hello]

I don't know if it's expected, but when I append Test B.mkv to Test A.mkv (from the zip file I linked to) using "add as additional parts", the output is only Test A.mkv and there's no error or warning message.

I played around with "--append-mode file" and "--append-mode track". Neither changes the result.
It doesn't matter which --append-mode I use, after appending, the video timecodes from the output files are the same. There's no "gap" in the timecodes where they were appended.
After appending Test B.mkv to Test A.mkv, regardless of the --append-mode specified, if I then split the output MKV after frame 140, the second part has no video delay.

If I append them while also splitting after frame 140 in a single operation though (as I often do to split the audio and subtitles to match), it doesn't matter which --append-mode I use, the second part has a video delay of 600ms.

So unfortunately playing around with --append-mode didn't explain why appending and splitting in a single operation sometimes creates a video delay for the second part (even when there's no other streams), whereas appending and splitting in two steps doesn't.

[hello_hello]

There are no other formats that I know of that have similar information on top of the already existing timestamps in the file format.

MP3, Ogg and Opus (can) support gapless playback. Foobar2000 always knows the exact duration and number of samples compared to the original lossless file. Obviously it's not the case for AC3 though. Is gapless playback the same thing?

https://en.wikipedia.org/wiki/Gapless_playback

Opus doesn't support a 44.1k sample rate, hence the extra samples, but the duration is correct.

https://imgur.com/EYEyCQn.png

[Mosu]

I don't know if it's expected, but when I append Test B.mkv to Test A.mkv (from the zip file I linked to) using "add as additional parts", the output is only Test A.mkv and there's no error or warning message.

Read this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Adding-files-vs.-Appending-files-vs.-adding-as-additional-parts) for understanding what "add as additional part" is for.

[Mosu]

MP3, Ogg and Opus (can) support gapless playback.

Ogg is a container format, not a codec, unlike MP3 & Opus. Ogg doesn't really have any kind of controls for gaps or no gaps. All it has is a value called "granulepos" for each Ogg page whose interpretation depends on the codec used in the track you're looking at (it's generally described as "the absolute position of this packet in the original uncompressed data stream", but how that's calculated depends on the codec — for some it's simply multiplied by the sampling frequency, for others some bits are a number of frames since the last key frame, for others it's just a fraction of seconds, etc.). With this definition it is possible to precisely locate the end of a stream (and therefore ensure the next stream starts right afterwards). The drawback of only recording the end of the frame is that there's no way to properly encode gaps in such a stream, or offsets at the beginning, without deeply inspecting each frame and maybe eben enocding them. Additionally having different time bases is impossible for most codecs.

For Opus you're correct, in as that it has a pre-roll/pre-skip header fields for specifying the exact start & discard padding packet fields for specifying non-full last frames, thereby specifying the exact end. It's a very good format, not just for that but for its compression properties, too, of course. mkvmerge supports all of these fields for Opus.

All that being said, MP4 with iTunes tags is different insofar as there's the container format that already contains precise timestamps, then there's potential codec-inherent values and THEN there's the iTunes tags-based delay on top of those two. These are three layers of timestamp adjustments, and that's not how Ogg, Mp3 or Opus work. Ogg+Opus are two layers, MP3 in an elementary stream is just one level etc. That tags-based level is… interesting, and that's what I meant with "I don't know if there's any other similar mechanism".

[j7n]

MP3 [..] (can) support gapless playback. Foobar2000 always knows the exact duration and number of samples compared to the original lossless file. Obviously it's not the case for AC3 though. Is gapless playback the same thing?In MP3 the duration of delay and padding are saved in a silent frame, and cut off on playback. Compensating for the delay in a movie is easier than implementing gapless playback because films start and end with silence. Only the starting point needs be offset, and any extra silence at the end doesn't matter. All lossy codecs have a short fade-in, typically around 256 samples. I think Ogg codecs handle it internally.

Should latency compensation be added for other formats, may I suggest it is made opt-in, or an information about the correction is output to the muxing log. The audio stream might already be in perfect sync because X samples were deleted from the start, it was made using the --no-delay parameter in Qaac, or the audio was extracted from another container where sync was corrected using unknown means.

[markfilipak]

...I had tried not to replace extensions in the past, which lead to a lot of confused users. The current way of replacing extensions only lead to one complaint (yours) over the last ten years or so. This is my experience, and that's why mkvextract behaves this way.
That's fine. I can manage. You-da-man!

I got another problem that really is a problem. Rather than repeat it here, I'll link to it:
https://forum.doom9.org/showthread.php?p=1995140#post1995140

What do you think? Do you have a fix?

Best Regards,
Mark.

[Mosu]

VobSubs have their duration stored within the packets themselves. That's why the .idx doesn't actually need a duration; it's implicit from the bitstream. There's no bug here.

[markfilipak]

VobSubs have their duration stored within the packets themselves.
Thank you, Mosu!

What are the odds that mkvextract is getting the durations found inside the '.sub' file, wrong?

Is there a way to check on mkvextract's work? I'd be able and willing to parse the '.sub' if I knew the struct.

The '.srt's that SubtitleEdit makes are definitely wrong sometimes. SubtitleEdit could be getting the 'end' timestamp calculations wrong of course, and I'm checking at that end. Sometimes the '.srt' that SubtitleEdit makes shows 00:00:00.000 as the 1st 'start' timestamp!

Sometimes the '.idx' that mkvextract makes shows 00:00:00.000 as the 1st 'start' timestamp!

With Best Regards,
Mark.

[Mosu]

What are the odds that mkvextract is getting the durations found inside the '.sub' file, wrong?

Unlikely.

Is there a way to check on mkvextract's work? I'd be able and willing to parse the '.sub' if I knew the struct.

Look up "spu DVD" and similar on Google; you'll find some reverse-engineered information about its structure. The official documentation is MPEG's DVD books; I doubt they're freely available.

Sometimes the '.idx' that mkvextract makes shows 00:00:00.000 as the 1st 'start' timestamp!

That's not inherently wrong. The start timestamp is simply taken from the Matroska packet's timestamp of the subtitle frame.

[markfilipak]

About 00:00:00.000 time stamp: The start timestamp is simply taken from the Matroska packet's timestamp of the subtitle frame.
Aw, really? It's always been wrong. I've not seen it myself, but I think some authors make an initial, blank sub so that subs are on from the git-go. I'm not referring to that. I use mkvextract to make IDXs and SUBs. I feed those to SubtitleEdit. The IDXs with 00:00:00.000 are always bad, and actually, all the times in them are screwed up.
In the 176-episode, 'STAR TREK, TNG' BD box, I found short runs of consecutive episodes in which mkvextract made bad (00:00:00.000) IDXs. I suspect some BD authoring tools produce PGC subs that are flawed, and some authors used them for the series of consecutive episodes that they authored. I could clip some source samples if you're interested.

[markfilipak]

I don't mean to 'pile on', but I have another issue:

This is a show-stopper. The actors in this play:
mkvtoolnix0.mkv (1:32:49.817)
mkvtoolnix1.mkv (1:15:04.461)
mkvtoolnix01.mkv (2:47:54.278) concatenation

This is the 1st of 3 concats to put together a 5 hour video.
(Note: I've left out the drive:\path\ parts for clarity.)

(Note: I'm using redirection: 2>output.txt, to capture 'showinfo' outputs...)

The 1st segment, mkvtoolnix0.mkv, ends on a P-frame -- look:

ffmpeg -i mkvtoolnix0.mkv -map 0 -vf showinfo -c:v rawvideo -sn -an -f null foo.mkv 2>output.txt
:
[Parsed_showinfo_0 @ 0000000003a77dc0] n:133538 pts:5569648 pts_time:5569.65 duration: 41 duration_time:0.041 ... iskey:0 type:P

That should be frame 133538: (3600+32*60+49.648)*24/1.001,... and it is.

mkvtoolnix1.mkv starts on an I-frame -- look:

ffmpeg -i mkvtoolnix1.mkv -map 0 -vf showinfo -c:v rawvideo -sn -an -f null foo.mkv 2>output.txt
[Parsed_showinfo_0 @ 00000000005ffe80] n: 0 pts: 0 pts_time:0 duration: 41 duration_time:0.041 ... iskey:1 type:I
:

Now comes the trouble. I used MKVToolNix to concatenate the two video segments.
I expect that frames 133538-cum-0 will become frames 133538-cum-133539 of course.
Here's the result:

ffmpeg -i mkvtoolnix01.mkv -map 0 -vf showinfo -c:v rawvideo -sn -an -f null foo.mkv 2>output.txt
:
[Parsed_showinfo_0 @ 0000000003a57dc0] n:133538 pts:5571483 pts_time:5571.48 duration: 41 duration_time:0.041 ... iskey:0 type:B <== this is not a P-frame
[Parsed_showinfo_0 @ 0000000003a57dc0] n:133539 pts:5571525 pts_time:5571.53 duration: 41 duration_time:0.041 ... iskey:0 type:B <== this is not an I-frame
:

Where did the P-cum-I-frame combo go?
In fact, there are no P-cum-I-frame combos in mkvtoolnix01.mkv

MKVToolNix doesn't transcode, so frames don't get resexed, so... what's going on?

MPV stepping through the transition:
1:32:49.481
1:32:49.522 <== MPV step (+41 ms)
1:32:49.564 <== MPV step (+42 ms)
1:32:49.606 <== MPV step (+42 ms) - 1/2 second of run with sound on this step
1:32:49.608 <== MPV step - 'time' almost stops
1:32:49.647 <== MPV step (is 1:32:49.606 + 41 ms)
1:32:49.608 <== MPV step - 'time' goes backwards on this step
1:32:51.649 <== MPV step (+2 sec jump) - 1 second of run with sound on this step
1:32:49.689 <== MPV step (-2 sec jump)
1:32:51.691 <== MPV step (+2 sec jump) - 1 second of run with sound on this step
1:32:49.731 <== MPV step (-2 sec jump)
1:32:51.733 <== MPV step (+2 sec jump) - 1 second of run with sound on this step
1:32:51.774 <== MPV step (+41 ms)
1:32:51.816 <== MPV step (+42 ms)
1:32:51.858 <== MPV step (+42 ms)
The 0:02.336 sequence above actually takes about 5 seconds of wall clock during which there are 3 'flashes' of non-black frames.
Audio and subtitles wind up still in sync.

Two issues:
1 - Disappearing P-cum-I-frame combo even though only muxing (sounds impossible to me).
2 - PTSs going forwards and backwards.

The question is not, 'How do I fix it?' The question is, 'How do I avoid it?' ...Please.
(I tried very hard to avoid problems and I planned the trimming as sensibly as I could.)

Regards,
Mark.

Aha! PS: I was reading my post and got a brainwave: Has the timing changed its basic timing of +41 ms/frame through the transition? Answer: No!
1:32:51.774 - 1:32:49.564 = 2.21 s.; (2.21 s)/(41 ms/frame) = 54 frames.
So, there should be 54 frames in the transition.

But 5 seconds in real-time, wall clock time tells me there's actually around 100 frames. So I could conceivably delete the offending frames. I'd have to delete them by frame numbers, not sexagesimal times. I don't know how to do that.

[markfilipak]

It looks to me that exactly 2 seconds are being skipped and that the 'tail' of mkvtoolnix0.mkv and the 'head' of mkvtoolnix1.mkv are overlapped causing 3 sets of back-forward jumps. It's hard to know for sure due to MKV's millisecond rounding granuarity.

:
1:32:49.608
1:32:49.647
1:32:49.608 - - - - - - jump back- - - - - fix: remove this
- - - - - - 1:32:51.649 jump forward - - - fix: move to end
1:32:49.689 - - - - - - jump back
- - - - - - 1:32:51.691 jump forward - - - fix: move to end
1:32:49.731 - - - - - - jump back
- - - - - - 1:32:51.733 jump forward - - - fix: move to end
- - - - - - 1:32:51.774
- - - - - - :

- - - 1:32:49.772 - - - jump over (skip) - fix: insert 48 black frames
- - - 1:32:49.813 - - - jump over (skip)
- - - 1:32:49.854 - - - jump over (skip)
- - - 1:32:49.895 - - - jump over (skip)
- - - 1:32:49.936 - - - jump over (skip)
- - - 1:32:49.977 - - - jump over (skip)
- - - 1:32:50.018 - - - jump over (skip)
- - - 1:32:50.059 - - - jump over (skip)
- - - 1:32:50.100 - - - jump over (skip)
- - - 1:32:50.141 - - - jump over (skip)
- - - 1:32:50.182 - - - jump over (skip)
- - - 1:32:50.223 - - - jump over (skip)
- - - 1:32:50.264 - - - jump over (skip)
- - - 1:32:50.305 - - - jump over (skip)
- - - 1:32:50.346 - - - jump over (skip)
- - - 1:32:50.387 - - - jump over (skip)
- - - 1:32:50.428 - - - jump over (skip)
- - - 1:32:50.469 - - - jump over (skip)
- - - 1:32:50.510 - - - jump over (skip)
- - - 1:32:50.551 - - - jump over (skip)
- - - 1:32:50.592 - - - jump over (skip)
- - - 1:32:50.633 - - - jump over (skip)
- - - 1:32:50.674 - - - jump over (skip)
- - - 1:32:50.715 - - - jump over (skip)
- - - 1:32:50.756 - - - jump over (skip)
- - - 1:32:50.797 - - - jump over (skip)
- - - 1:32:50.738 - - - jump over (skip)
- - - 1:32:50.779 - - - jump over (skip)
- - - 1:32:50.820 - - - jump over (skip)
- - - 1:32:50.861 - - - jump over (skip)
- - - 1:32:50.902 - - - jump over (skip)
- - - 1:32:50.943 - - - jump over (skip)
- - - 1:32:50.984 - - - jump over (skip)
- - - 1:32:51.025 - - - jump over (skip)
- - - 1:32:51.066 - - - jump over (skip)
- - - 1:32:51.107 - - - jump over (skip)
- - - 1:32:51.148 - - - jump over (skip)
- - - 1:32:51.189 - - - jump over (skip)
- - - 1:32:51.230 - - - jump over (skip)
- - - 1:32:51.271 - - - jump over (skip)
- - - 1:32:51.312 - - - jump over (skip)
- - - 1:32:51.353 - - - jump over (skip)
- - - 1:32:51.394 - - - jump over (skip)
- - - 1:32:51.435 - - - jump over (skip)
- - - 1:32:51.476 - - - jump over (skip)
- - - 1:32:51.517 - - - jump over (skip)
- - - 1:32:51.558 - - - jump over (skip)
- - - 1:32:51.599 - - - jump over (skip)

[Emulgator]

.mkv was not made for editing after all.
I would choose a different approach.

[Ripman]

Hey M. Hope you had a nice summer. About 34 today in NYC.

The reason I ask is because I have a widescreen mpeg2 video, that, after being cropped and encoded to mpeg4, shows a VDW of 11418 and a VDH of 6237 via the MKVToolNix header editor. This will give the proper aspect ratio of (almost) 1.85, but I think these “big” values can cause problems with TVs and other HW because the equipment isn’t expecting numbers that big. The cropped video is 718 wide and 462 high, and with a PAR of 32/27 gives the same aspect ratio as the big numbers above.

(Do these big values 11418 x 6237 seem normal - do they make sense?)

Thanks and best…..

Hi M. Merry and thanks for v81.

From the sept 6 post quoted above…. Any ideas or insights on the VDH VDW values I’m seeing from encoding. Really appreciate. Best and happy…..

[Mosu]

The idea behind the two elements "Display Width" & "Display Height" is to signal the intended/optimal resolution at which to show the final video. A lot of players don't use them that way, though, and only use their ratio, but not the actual dimensions. For those players your huge values should be fine. Players that do follow the intended use, though, will likely show a huge window initially, which is likely not what you want.

[Ripman]

Thanks as usual very much.

I posted about this maybe 2-3 years ago here after dead-ending on the encoder forum.

2 questions:

1. Should I report it as a bug to the encoder devs?

2. IÂ’ll use a script to update the VDW / VDH based on the cropped dimensions - mkvinfo + mkvmerge. You see any issues with this approach?

Merry and happy, M. Best….

[markfilipak]

Regarding https://forum.doom9.org/showthread.php?p=1995186#post1995186 & https://forum.doom9.org/showthread.php?p=1995197#post1995197, I'm redoing all my work, so disregard those posts for the moment.

But I want to comment on something that may be significant:
For the video I trimmed (both ends) using MKVToolNix, the run time shown by MPV is
1194:33:59.458.
For the same video I just trimmed using ffmpeg, the run time shown by MPV is
1:32:51.432.

The requested trim points slightly differ because I found slightly better I-frames for the ffmpeg trim, but still...

What do you make of 1194:33:59.458?

The reason I say this may be significant is that the MKVToolNix subtitle stream is what's 1194:33:59.458, not the video or audio streams. And it's the MKVToolNix subtitle stream that later shows bogus out-times. In fact, once a subtitle is displayed, it's not removed until the next subtitle is displayed, even minutes later.

The ffmpeg subtitle stream works properly.

MKVToolNix has a subtitle timing problem somewhere.

I will pursue this if anyone shows interest -- e.g., has this happened to you? -- otherwise, I'll drop it and stop taking up doom9 space.

Oh, the version is MKVToolNix GUI version: 81.0

[mood]

dark mode on windows 11 and MKVToolNix GUI 81 flash white on startup, I use lastest version 81.0.51, is it possible to fix this??

Edited...

[Mosu]

dark mode on windows 11 and MKVToolNix GUI 81 flash white on startup, I use lastest version 81.0.51, is it possible to fix this??

Not from my end, no. This is up to Qt.

[Mosu]

What do you make of 1194:33:59.458?

I would need access to the source file that was fed into MKVToolNix in order for it to generate such a high timestamp. Without it I really cannot say anything useful.

[73ChargerFan]

Donation Time!
Thank you for your hard work this year. You're the best.

[markfilipak]

I would need access to the source file that was fed into MKVToolNix in order for it to generate such a high timestamp. Without it I really cannot say anything useful.
Of course. The file is many gigabytes.
...May I ask: Are you using the ffmpeg libraries? The reason I ask is that I've found some significant errors that may impact your stuff. I'm pursuing the issue on ffmpeg-user.

Aside: What I found are not obscure or 'corner' cases.

-- Mark.

[Mosu]

Of course. The file is many gigabytes.
...May I ask: Are you using the ffmpeg libraries?

No, I don't.

[RivDoVi]

Hi there :)!

Firstly, i'd like to wish you all a Happy New Year and all the best for 2024 :D

Now, i just updated mkvmerge from v80 to 81 (i only received the update notification yesterday, for an unknown reason) and almost made a heart attack reading that in the changelog :

mkvmerge: MPEG transport stream reader: when reading MPEG transport streams from Blu-rays the four-byte long "TP_extra_header" structure in front of the transport packets are now skipped properly. Before the fix a stray byte with value of "0x47" inside that "TP_extra_header" structure could have thrown off the detection of where the transport packets start, leading to mkvmerge dropping a few audio and/or video frames at the start of the file. Fixes #3632.

Is that issue as important as it sounds ?
I've been doing a lot of personal remuxes recently, more than a hundred with v80.
The idea of having to redo all of them to ensure they are proper would be a bit heartbreaking judging by the amount of time all these remuxes required in the first place :eek:

Does this issue occured with AVC streams ?
I mainly use EAC3to to demux audio then use the playlist .mpls in mkvmerge for video/subs/chapters. For extras & bonuses i simply drop the M2TS in mkvmerge.

If a remux is affected by the issue, shouldn't it be obvious to spot like completely out of sync audio & video ?
Any way to spot problematic remuxes easily ?

I'd be happy to receive an answer, i'm a bit panicking right now :).

Also, thanks a lot for the wonderful work on MKVmerge, been using it for years. :o

[Mosu]

Is that issue as important as it sounds ?

I guess this depends on how you do things & how important 100% correctness is for you. Some helpful (?) facts:

This type of problem only occurred sometimes, not for every stream, as the "arrival_time_stamp" that makes up most of the four bytes must have that special byte in them in order to trigger the issue.
It could only happen for MPEG transport streams that were used on Blu-rays, not for ones used for DVB broadcasting, for example.
It doesn't happen if you re-mux a file that another Matroska muxer produced, e.g. if you have a file produced by MakeMKV, then re-muxing that one with mkvmerge would not make it worse.
The number of frames skipped was always rather small (if it happened, usually the first group of pictures, meaning less than one second of content).

Does this issue occured with AVC streams ?

The problem occurred regardless of codecs, so yes.

If a remux is affected by the issue, shouldn't it be obvious to spot like completely out of sync audio & video ?

No, as the content dropped included both the audio & video. In other words, the first few frames of all content are missing, but the relation between audio & video timestamps was unaffected. If a movie starts with a black screen, as most on Blu-rays do, it's very, very likely you won't notice a thing.

Any way to spot problematic remuxes easily ?

No. Personally I would just randomly check ten or so movies done prior to v81 for A/V sync issues. If they seem to play fine, if the start of the movie doesn't show any issues, then I'd simply accept that things are the way they are.

[RivDoVi]

The number of frames skipped was always rather small (if it happened, usually the first group of pictures, meaning less than one second of content).[/list]

In other words, the first few frames of all content are missing, but the relation between audio & video timestamps was unaffected.

No. Personally I would just randomly check ten or so movies done prior to v81 for A/V sync issues. If they seem to play fine, if the start of the movie doesn't show any issues, then I'd simply accept that things are the way they are.

What about if you extracted the audio stream from the m2ts with another software (eac3to in my case) then used mkvmerge for the mpls while adding the eac3to processed audio ? I suppose in that case it should drop the frames for the video but would result in an out of sync audio because audio frames were not dropped by eac3to am i right ?

The dropped video frames by mkvmerge would mean the processed mkv video stream would logically start at the next i-frame which is quite enough to spot audio sync issue if my assumption above is right as it would lead to 400/500ms delay at the very least.

Also, just to be able to clearly have an idea if my ideas are correct, would you be able to kindly share here or via PM some disc titles that were problematic ?
I may have some of them, i suppose a practical example would be the best illustration :o

Kind Regards to you and thanks for your answer !

[Mosu]

What about if you extracted the audio stream from the m2ts with another software (eac3to in my case) then used mkvmerge for the mpls while adding the eac3to processed audio ? I suppose in that case it should drop the frames for the video but would result in an out of sync audio because audio frames were not dropped by eac3to am i right ?

That sounds about right, yes. You would likely be able to see a significant effect in the A/V sync if you're running into this issue.

That being said, exporting audio separately also means that mkvmerge doesn't have access to the audio/video delay information (meaning if they don't start at the same time in the M2TS). You'll have to tell mkvmerge the actual offset anyway. This is totally independent of the bug we're talking about; this is always the case if you separate audio & video & mux them from different source files.

Also, just to be able to clearly have an idea if my ideas are correct, would you be able to kindly share here or via PM some disc titles that were problematic ?

I only have what the reporting user uploaded for issue 3632 (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3632) (there's additional information in that report as well). The one short sample file I have is from a Japanese anime whose name I don't know. I actually don't know of any particular Blu-ray that's affected by the issue. Sorry.

[RivDoVi]

That sounds about right, yes. You would likely be able to see a significant effect in the A/V sync if you're running into this issue.
That being said, exporting audio separately also means that mkvmerge doesn't have access to the audio/video delay information (meaning if they don't start at the same time in the M2TS). You'll have to tell mkvmerge the actual offset anyway. This is totally independent of the bug we're talking about; this is always the case if you separate audio & video & mux them from different source files.

Yes of course.
Eac3to recognizes these delays and corrects them straight into the generated audio file. That is why it's widely used for audio processing/demuxing before using mkvmerge for remuxing as the latter adds delay information as tag which is less preferable for a clean result. This also prevents problem on playlists with multiple m2ts (referred to as "seamless branching).
Eac3to/DGDemux are the main audio demuxing programs used by the communities.

I reviewed 40 of my personal remuxes without encountering a problem for now ; i suppose this 0x47 timecode is pretty rare because normally the problem should be quite obvious with the eac3to/mkvmerge combo in the end since eac3to would not cut audio frames leading to desync, as implied on my previous post.

Lots of thanks for your kind and quick answers :thanks:

[Mosu]

Heya everyone!

Happy new year! Good time for a new release, I guess. This one with lots of bug fixes & enhancements. One important change is that Qt 5 is not supported anymore. The program now requires Qt 6.2 or newer for compilation.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.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 82.0 "I'm The President" 2024-01-02
New features and enhancements

mkvmerge: Matroska reader: the "video alpha mode" track header property will be copied to the output file if present. Part of the implementation of #3643 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3643).
mkvmerge: Matroska reader: the "video alpha mode" track header property will be reported in JSON identification mode as the track property "alpha_mode". Part of the implementation of #3643 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3643).
mkvmerge: Matroska reader: the file's timestamp scaling factor will be reported in JSON identification mode as the container property "timestamp_scale".
mkvmerge: MPEG transport stream reader: teletext subtitles intended for hearing impaired people (type 0x05) are now marked as such via the appropriate flag in the track headers.
mkvmerge: file identification: the JSON identification output schema version has been bumped to 19.
mkvmerge: added a new hack "always_write_block_add_ids" that can be used as a workaround for players that don't support the handling of missing "Block Addition ID" sub-elements of "Block More" elements in block additions properly. These are used for e.g. alpha channel data in VP9 with a "Block Addition ID" value of 1, which is also its default value. Workaround for the player issues listed in #3643 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3643).
mkvinfo: added support for the "video alpha mode" track header element. Part of the implementation of #3643 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3643).
mkvpropedit, MKVToolNix GUI's header editor: added support for the "video alpha mode" track header property. In "mkvpropedit" it's called "alpha-mode". Part of the implementation of #3643 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3643).
MKVToolNix GUI: multiplexer: when adding files the GUI can automatically enable the "hearing impaired" flag for audio and subtitle tracks if the file name contains the word "cc" or "sdh" delimited by certain characters (configurable). This feature is turned on by default. Implements #3648 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3648).
MKVToolNix GUI: multiplexer: when scanning for Blu-ray playlists the GUI will now ignore playlists that are likely meant for menus. Currently the GUI considers this to be the case when a playlist contains the same item at least five times. This behavior can be turned off in the preferences. Implements #3658 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3658).

Bug fixes

mkvmerge: MPEG transport stream reader: fixed a crash introduced in v81 that occurred when there was at least one PCM track that wasn't copied from the transport stream file. Fixes #3645 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3645).
mkvmerge: when reading data from Matroska files damaged in a specific way, mkvmerge ended up trying to write various types of elements that aren't allowed to be written (so-called "EbmlDummy" elements as well as elements that don't have a value set) to the output file, which caused the underlying "libebml" library to abort. These types of broken elements are now filtered out.

Build system changes

Qt 5 is no longer supported. Qt 6 is now required for building MKVToolNix. This implies that the options to "configure" revolving around configuring Qt 5 or choosing between the two have been removed (e.g. "--disable-qt6").
Qt 6 detection: if detection fails, error messages from "qmake" can now be found in "config.log". See #3649 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3649).
Qt 6 detection: "configure" will only consider Qt 6.2.0 or newer, not 6.0.x or 6.1.y anymore, due to the lack of support for the multimedia module.
Qt 6 detection: "configure" will now fail to detect Qt 6 if the 'multimedia' module is not found by "qmake" (e.g. due to development packages not being installed). See #3649 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3649).
The bundled "fmt" library was updated to v10.1.1.


Have fun 😁

[tormento]

I'd like to move from TCC prompt (and batches) to PowerShell but I am really just at the beginning.

A typical TCC batch would be:

for %%a in (*.mkv) D:\Eseguibili\Media\MKVToolNix\mkvmerge.exe --output ^"M:\Out\%%~na.mkv^" --language 0:ja ^"%%~na.mkv^" --language 0:it ^"%%~na [ita].ec3^" --language 0:it --track-name ^"0:Cartelli PGS Dynit^" --forced-display-flag 0:yes ^"%%~na [ita] F.sup^" --language 0:ja --default-track-flag 0:no ^"%%~na [jpn].ec3^" --language 0:it --track-name ^"0:Completi PGS Dynit^" --default-track-flag 0:no ^"%%~na [ita].sup^" --chapter-language ja --chapters ^"%%~na.txt^" --track-order 0:0,1:0,2:0,3:0,4:0

but I really can't find a way to translate in PowerShell one.

Can someone with more experience help me?

[Mosu]

Also, just to be able to clearly have an idea if my ideas are correct, would you be able to kindly share here or via PM some disc titles that were problematic ?

The person filing the bugs answered the following when I asked them about the affected discs:

I personally have these:
RWBY vol.4 disc 2 00017.m2ts
Shokei Shoujo no Virgin Road Vol.1 00015.m2ts
I don't have these so I don't know what edition, but have been told they also had this problem. Since i asked to check for 47 byte at the start.
Kino no Tabi 2017 00010.m2ts
Karekano
Shoujo Kakumei Utena
Shakugan no Shana
Inuyasha: (BOX1 JPN)

[tormento]

I will try a second time ;)

Please consider to accept a directory as source for attachments in mkvtoolnixgui and mkvmerge command line.

[Mosu]

Please consider to accept a directory as source for attachments in mkvtoolnixgui and mkvmerge command line.

No, sorry, mostly because it would conflict with how the other "--attachment-…" options work.

[tormento]

No, sorry, mostly because it would conflict with how the other "--attachment-…" options work.
And creating a new --dirattachment switch? That wouldn't break compatibility at all.

[Mosu]

Not interested.

[Nico8583]

Hi, is there a way to treat multi angle playlist from a Blu ray ? Thanks.

[hubblec4]

With chapterEditor you can "feed" MTX with the correct m2ts order.

[Nico8583]

With chapterEditor you can "feed" MTX with the correct m2ts order.
Thank you, I'll look at it

[Nico8583]

Hi, another question.
Is it possible to not combine BL and EL streams when muxing to MKV ? I can't find an option.
Same question for Dolby TrueHD, is it possible to let TrueHD and AC3 combined in the same stream ?
Thank you.

[Mosu]

No, it's not. DV storage in Matroska is the same as DV in MP4: both layers in the same track.

Additionally in Matroska you can only have one codec per track, meaning TrueHD & AC-3 will always be separate tracks.

Matroska is not meant to be an intermediate format for later remuxing into MPEG transport streams. If you need that, don't use Matroska.

[jpsdr]

I've made several tries without succes for now, so i'm asking how to do...
I have a video file (1) at 24fps, another (2) at 23.976 fps. Both are "the same", meaning for exemple the frame number 12987 is exactly the same for both videos.
I want to mux the audio of (2) with the video of (1).
I tried the "streaching" method on video track of (1), with 23.976/24 parameter. But the mediainfo still provided 24.000fps information (when it should be 23.976). Stoped here, didn't think to check if video/audio where in sync.
So, i add the "Set fps default" to 24000/1001 on video track of (1). Mediainfo still provided 24.000fps information, and audio and video where out of sync.

Question : what's the difference between "streaching" and "Set fps default" ? Are they doing the same thing, just changing the duration of a frame ?

I discovered the "Correct binary data on temporal flux" checkbox (don't know if it's proper translation).

So, if i want to : change the fps of the video (1) to 23.976, have it properly detected by mediainfo, and finaly have my video and audio in sync, how should i mux ?

EDIT:
I've been able to have everything in sync, but whatever i do, check or not "Correct binary data on temporal flux", the fps reported by mediainfo is 24.000... :(
(Right click on the video inside MPC-HC and "MediaInfo" informations).

[tormento]

(Right click on the video inside MPC-HC and "MediaInfo" informations).
Try to use real MediaInfo (https://mediaarea.net/it/MediaInfo/Download).

[tebasuna51]

With the full MediaInfo you can see the diferences between check or not that checkbox:

Original MkvT-FPS +Fix bitstream
---------- ---------- --------------
Frame rate mode :
Frame rate (1): 24.000 FPS 24000/1001 24000/1001
Original frame rate (2): - the same 24.000 - the same
Standard :

(1) Frame rate stored in container (preferred at play time with standard players)
(2) Frame rate stored in video stream (ignored at play time but preserved if track is extracted)

Maybe MediaInfo is not clear but the MkvToolNix help yes.

Now you can mux the audio (2) to video (1) and play in sync

[jpsdr]

So... is it better or not to check the "Fix bitstream"... (I don't know why i have the feeling the answer will be "It depends..." ;))
What will give me the file with the less risk of wrong play with several different players ?

Finaly, after understanding (took me a little while) tebasuna51 answer :thanks:, it seems in my case it would be better to check it...

BTW, i thought i have the "Mediainfo" panel with MPC-HC when right click because i have installed Mediainfo, so i thought it uses the "real" Mediainfo.
Never checked if the panel is avaible on a system without Mediainfo. If i remember, i'll check when there is a new release and so install a new version.

[jpsdr]

Here the relevant informations from MediaInfo 24.01.1, opening the files with the "real" MediaInfo program.

Film_24_000

General
Format : Matroska
Format version : Version 4
Duration : 1 h 44 min
Frame rate : 24.000 FPS
Writing library : libebml v1.4.4 + libmatroska v1.7.1

Video
ID : 1
Format : HEVC
Duration : 1 h 44 min
Frame rate mode : Constant
Frame rate : 24.000 FPS


Film_23_976

General
Format : Matroska
Format version : Version 4
Duration : 1 h 44 min
Frame rate : 23.976 FPS
Writing library : libebml v1.4.5 + libmatroska v1.7.1

Video
ID : 1
Format : HEVC
Duration : 1 h 44 min
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS


I mux doing the following :
Audio is from Film_23_976 untouched, video is from Film_24_000 with FPS set to 24000/1001 + "Fix bitstream" checked.

Result is :

General
Format : Matroska
Format version : Version 4
Duration : 1 h 44 min
Frame rate : 24.000 FPS
Writing library : libebml v1.4.5 + libmatroska v1.7.1

Video
ID : 1
Format : HEVC
Duration : 1 h 44 min
Frame rate mode : Constant
Frame rate : 24.000 FPS

It plays fine in sync with MPC-HC, but... Is it realy what it should be...:confused: