MKVToolNix v99.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.