MKVToolNix v99.0 released [Archive] - Page 8

Mosu

15th April 2019, 08:53

Hey,

well, I buggered up the handling of UNC paths on Windows in release 33.0.0. So… sorry? :) Here's a fix for that. As this is just an emergency hot fix release I'll include the news for v33.0.0, too.

There've been no changes regarding packaging since the previous 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 33.1.0 "Primrose" 2019-04-15
Bug fixes

MKVToolNix GUI: multiplexer: Windows: using UNC paths (e.g. "\\server\Videos") when the option "automatically set the destination file name" was set in the preferences, the GUI would create a destination file name with forward slashes (e.g. "//server/Videos/outputfile.mkv"), a syntax not supported by "mkvmerge". Fixes #2533 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2533) & #2534 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2534).
build system: the programs were accidentally built without stack protection ("-fstack-protector-strong") on recent versions of gcc and clang.

Version 33.0.0 "A Little Bit of Madness" 2019-04-12
Bug fixes

mkvinfo: when using the "--size" option, mkvinfo will now report the correctly if an element has an unknown size. Part of the fix of #2530 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2530).
MKVToolNix GUI: info tool: clusters with an unknown size will now be read and displayed correctly. Part of the fix of #2530 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2530).
MKVToolNix GUI: multiplexer: Windows: trying to open Blu-ray index or playlist files failed when the path to the files contained symbolic links (e.g. when mounting a drive in a sub-folder via Windows' disk management utility). Fixes #2522 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2522).
MKVToolNix GUI: multiplexer: if a destination file names ends with a number in parenthesis (e.g. a year such as "(2017)"), that number will not be stripped anymore during the process of ensuring the destination file name is unique. Only those suffixes added automatically in prior attempts to make the file name unique will be removed. Fixes #2521 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2521).
MKVToolNix GUI: multiplexer: Windows: the GUI will let the user change the drive letter part of the destination file name freely again and only verify its validity right before starting to mux/adding to the job queue. Before it tried to force that into something valid, often resulting in unintentional paths (such as "C:\users\…\DC\files\…"). Fixes #2527 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2527).

Have fun :)

Mosu

15th April 2019, 09:32

Thanks for the release. Minor cosmetic request…

Well, the script as-is didn't work too well for me, but with a couple of changes (handle more headline tags, revert HTML escaping of " and &, removal of code tags, manually joining lines in order to avoid line breaks) it works well enough, I guess.

chros

15th April 2019, 12:40

There's been some noise recently about this (https://github.com/DolbyLaboratories/dlb_mp4base) tool from Dolby which can create Dolby Vision mp4 files. I was able to create a profile 7 file from a UHD disc backup which played succesfully with DV on an LG TV.
I was wondering if there's anything in the code that might provide some clues for getting Dolby Vision into mkv - after remuxing the mp4 with mkvtoolnix all of the dolby vision information is lost.
@Mosu, is there any plan for this? I'm just interested, thanks!

raymondjpg

23rd April 2019, 04:43

I am trying, unsuccessfully, to standardise order of tracks in output files generated by MKVToolNix so video comes first, then audio, then subtitles.

When I add --track-order 0:0,0:1 (by my understanding video first, then audio) as Default additional command line options in Multiplexer default values preferences, I get an error when muxing '--track-order' may only be given once.

I can find only one instance of --track-order in mkvtoolnix-gui.ini, and nowhere else in MKVToolNix preferences to set track order, so I am at a loss to know how to achieve standardisation of track order in output files.

Can anyone set me on the right path?

sneaker_ger

23rd April 2019, 09:23

When I add --track-order 0:0,0:1 (by my understanding video first, then audio)
That's not what it means. It means track 0:0 (track with TrackID 0 of first input file) is used first, then track 0:1 (track with TrackID 1 of first input file) second. --track-order doesn't have any arguments to differentiate between video/audio/subtitles.

I can find only one instance of --track-order in mkvtoolnix-gui.ini, and nowhere else in MKVToolNix preferences to set track order, so I am at a loss to know how to achieve standardisation of track order in output files.

Can anyone set me on the right path?
It's not possible to automatically make the GUI set 1. video 2. audio 3. subtitles. The GUI will always insert its own --track-order which cannot be disabled.

raymondjpg

23rd April 2019, 11:01

That's not what it means. It means track 0:0 (track with TrackID 0 of first input file) is used first, then track 0:1 (track with TrackID 1 of first input file) second. --track-order doesn't have any arguments to differentiate between video/audio/subtitles.

It's not possible to automatically make the GUI set 1. video 2. audio 3. subtitles. The GUI will always insert its own --track-order which cannot be disabled.

Thanks for the clarification. I was curious as to why the version of mkvmerge.exe bundled with MeGUI always managed to generate an mkv with the 'correct' track order of Video Audio and then Subtitles, whereas the current version of MKVToolNix GUI 33.1.0 is generating mkvs with track order of Audio Video then Subtitles.

I know track order in output files can be changed around manually.

sneaker_ger

23rd April 2019, 12:40

You can set the track order manually. It's just that MeGUI and MKVToolNixGUI use mkvmerge in different ways. The way MKVToolNixGUI works it's not possible to automate what you want.

Klaus1189

25th April 2019, 16:53

Is it possible to cut out a scene from a a videofile (key frame accurate is enough for that), but the two other parts (before and after the cut) should be one file again, without the need of more than one step.
I could cut on two points and then merge the two other parts together, but is there a one step possibility for that?

mkver

25th April 2019, 17:13

If you do not want to keep the middle part, then it is possible: If you use a + in front of a range, then this range will be appended to the preceding range that was outputted.

hubblec4

25th April 2019, 18:46

You have to use split option "By parts based on timestamps".

kuchikirukia

26th April 2019, 08:59

I've uploaded a PAL DVD .VOB to your FTP that exhibits some weird behavior. The weirdness I'm seeing when trying to frame serve this is probably due to bugs in LSMASH and FFMS2, but I've just never seen LSMASH behave this way.

Muxing this VOB to mkv with mkvtoolnix ends up with a weird mediainfo that claims variable frame rate and 47.867 FPS. From the mkv, LWLibavVideoSource will frame serve 54099 frames with a seemingly random duplicate frame pattern, while it shows 28255 frames with no dupes when used on the VOB.
FFMS2 locks up on both the mkv and VOB, and shows 54099 frames from the mkv and 28254 from the VOB.
DGDecode shows 28255 frames on the VOB or demuxed mpeg from the mkv.

There's no problem playing either the mkv or VOB in MPC-HC.

hubblec4

26th April 2019, 11:41

Hi Mosu

It seems the SegmentInfo.dtd is not correct, but mkvmerge handles the structure correctly.

SegmentFamily ist marked with a "?" (no or one times) but it can added multiple times, the asterisk sign (SegmentFamily*) should be used.
And the ChapterTranslateEditionUID has no extra sign but it should also have the asterisk sign (ChapterTranslateEditionUID*).

Some question about the Info elements:
Mkvmerge can use all Info elements which are available in the info.XML.
Mkvpropedit can edit all this elements too? And additionally I can edit some more elements like the Info Title.?

And then there are some elements which can't be edited, this values are written while mkvmerge mux the mkv file.
- Duration
- DateUTC
- MuxingApp
- WritingApp

The TimestampScale element can be set before I mux an mkv. Is this only possible with a command line switch?

Best regards
hubble

Liisachan

26th April 2019, 14:34

Hi, Mosu.

I have an Ogg Vorbis file, 15188168 bytes, 1448.447 sec (69525456 samples in 48000 Hz), that is 83887 bps (~84 kbps).

When I mux it into MKV using mkvmerge v33.1.0, a SimpleTag with TagName BPS is automatically written for the corresponding audio track, and its value is 82787 (~83 kbps), which I can't change even if I use a tags.xml file with:
<Simple><Name>BPS</Name><String>83887</String></Simple>

Am I correct to assume that this behavior is by design, and the BPS auto-written by mkvmerge is correctly based on some kind of "packet size" in MKV and so slightly smaller than the BPS of the "raw" Ogg Vorbis file?

Sorry if this has been already asked and answered. I did some search and read your changelog entry dated on 2014-05-20, which states:
mkvmerge: new feature: mkvmerge will write track-specific tags with statistics (»BPS« for the average number of bits per second

By which I'm guessing that an auto-written BPS is for a track in MKV, and not for the actual audio data, but I'd like to confirm this. TYIA.

mkver

26th April 2019, 16:15

@Liisachan: The statistics are for the actual data contained in the track in MKV. They do not consider MKV container overhead; and they also do not consider the overhead of the Ogg container (which is usually higher than Matroska overhead). Your other number (for the ogg vorbis file) probably has the ogg container overhead included in its calculation.

@kuchikirukia: First: mkvmerge's code for MPEG-2 is old, buggy and unsupported. So even if there were a bug in mkvmerge, it wouldn't get fixed. That being said, I don't have a reason to think that there is buggy behaviour by mkvmerge here.
Here is some background: A coded picture in MPEG-2 can either be a coded field or a coded frame (and frames needn't be progressive).* Matroska contains blocks and mkvmerge puts each picture in one block. What MediaInfo reports as FPS is in reality the block count per second.
So here are the numbers for your sample: Your sample contains 28255 frame-equivalents (i.e. two coded fields are counted as one frame here). 2*28255-54099 = 2411 of these are coded frames, while 28255-2411 = 25844 are encoded as coded fields (so there are 51688 coded fields). So the block-rate is 54099 / (2411 + 25844) * 25 = 47.8667.
It seems that your tools output two frames for each pair of two coded fields when the container is Matroska. I remember such bugs from H.264. You can report these bugs, of course (but they are not new), but in the meantime you should simply use another container if you work with the said tools.

*: Furthermore, these pictures can contain flags that say that they should be output more than once; the most common application is for coded frames to be output as three fields (i.e. one field output twice). That way one can encode progressive material as 24/1.001p on a DVD and output it as 60/1.001i for compability with legacy CRT (and modern equipment designed for progressive material can get the actual progressive video). This is used on NTSC DVDs, but not for PAL DVDs and therefore you can ignore it.

Liisachan

26th April 2019, 18:11

@mkver
Thanks! That makes sense. In the past I could manually write a BPS tag via an xml file, and back then I simply wrote file_size_in_bits / duration_in_sec as BPS value -- which is also the bitrate reported by oggenc (the ogg container overhead being included, like you said). As such, the definition of BPS value is now incompatible with that of my old MKV files, and I was a bit confused when I noticed that I can no longer explicitly write a BPS tag via xml. Still, if this is by design, I'm fine with that. A 1 kbp/s difference is not a big deal, and most players/tools probably don't read BPS tags anyway :)

Edit 2019-09-30
In the specs https://matroska.org/technical/specs/tagging/index.html#BitsPS it is clearly stated that BPS is only the data in the Blocks, and excludes headers and any container overhead.

EDIT2 2019-11-25
If needed, however, you can write a BPS tag freely as you like, by using --disable-track-statistics-tags
For example, you might want to make its value 85000 or 85272.4 or whatever, instead of 85272.

Perenista

8th May 2019, 02:05

Why can't I add .sub (MicroDVD) subtitles to a Matroska? I added an AVI and was going to add the subtitle, now I have to convert to SRT first

videoh

8th May 2019, 04:19

Matroska supports S_VOBSUB subtitles. These are typically named as ".sub" files when demuxed. See here for details and limitations.

https://matroska.org/technical/specs/subtitles/images.html

I don't know anything about MicroDVD.

`Orum

10th May 2019, 09:47

I've been working on transcoding some streams in some of my mkv files, and in doing so, I've discovered that several audio streams have a delay compared to the video. This by itself isn't surprising, but what is shocking is that I can't see anywhere this delay is indicated in mkvinfo. Even adding the original file into mkvmerge's GUI shows no delay on these tracks, when there definitely is one; sync is lost without it, and MediaInfo shows a "Delay relative to video" with a positive value for certain audio tracks.

I messed around with -v and -t to mkvinfo, but if either is used, I am inundated with output, and I'm not sure if any of it even shows the delay. How does MediaInfo get this value, and is there some CLI program that will show it to me? I've got literally hundreds of these files, and using a GUI application to look at each one is impractical.

sneaker_ger

10th May 2019, 11:01

Read: MKVToolNix FAQ: Delay not shown in the GUI (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Delay-not-shown-in-the-GUI)

mkvmerge -J "file.mkv"
Shows "minimum_timestamp" (in nanoseconds) for each track. "minimum_timestamp" of audio minus "minimum_timestamp" of video = "delay relative to video" of the audio track as MediaInfo shows it.

You can also see it in the Info tool:
https://i.imgur.com/iceeAcw.png
(Here it's 123ms-20ms=103ms audio "delay relative to video".

Of course there's the question of whether or not your workflow is good. If you always work under the assumption that video starts at 0ms and that video and audio tracks are constant framerate it may fail if those aren't true (Matroska supports variable framerates). I also see people needlessly demux e.g. audio tracks instead of just reading them from the mkv file directly when remuxing. When transcoding tracks I would get rid of delays anyways (fill with silence/blackness or remove).

`Orum

10th May 2019, 18:13

So, if I understand correctly, in the mkvinfo -v output, the lines I'm looking for are the first instance of:
Simple block: key, track number X
for each track. Then if I subtract the value for the each track's initial keys from one another, I can compute the relative delay between the tracks, right? It's a bit tedious but nothing perl can't handle.

I don't see much point in adding silence though, other than to simplify future transcoding. Since that won't happen, I'm not going to worry about it.

Edit: Hrm, I'm not sure what VFR has to do with this though. All the timestamps are in seconds, so why would the audio delay in any way relate to the frame rate?

Edit2: Seems subtitle tracks either lack the "Simple block: key..." line in the output, or it's optional. Anyway, I have the script working to parse the offsets correctly and can now adjust the delay in muxing accordingly. Thanks!

sneaker_ger

10th May 2019, 22:06

Edit: Hrm, I'm not sure what VFR has to do with this though. All the timestamps are in seconds, so why would the audio delay in any way relate to the frame rate?
I'm saying you might be working under wrong assumptions. E.g. that your Matroska files are CFR (except for the delay and some jitter) while that isn't necessarily true. And that the structure is only SimpleBlocks. So now you spent work on implementing delay detection which will probably fail in certain cases. While software like mkvmerge, ffmpeg or eac3to can read from mkv directly without having to implement this.
Maybe in your case it's sufficient or even makes sense. I don't know enough about your workflow or sources. Just my 2 cents ..

`Orum

11th May 2019, 08:55

I'm only transcoding audio, but if I were to do video, I'd check if it's VFR and if so, export & reimport the timecode. All tracks that are not transcoded are taken directly from the original mkv in mkvmerge, which I believe maintains everything in the original (such as timecode) without being explicitly told to do so, though I'd have to check with some VFR footage to verify this.

As for delay, it sounds like it can be done without SimpleBlocks? If so, what do I have to look for?

While software like mkvmerge, ffmpeg or eac3to can read from mkv directly without having to implement this.
Is directly reading the binary data the only way to calculate delay with perfect accuracy? If so that seems more like a deficiency in mkvinfo (where it's already awkward to view delay) than anything.

Edit: I did notice that one can simply export the timecode for each stream via mkvextract, and look at the first value in the timecode to determine offset as well. Is this more reliable to determine the delay?

sneaker_ger

11th May 2019, 09:03

I'm only transcoding audio, but if I were to do video, I'd check if it's VFR
Audio can be variable, too. (gaps) In that case the raw stream + the info about initial delay is not enough to reconstruct the timings. Information is lost.

For audio I would usually use ffmpeg or eac3to (+maybe some external encoder like qaac) which can read directly from mkv and "fix" the delay and any gaps while at it. So I don't see any need to parse mkvinfo at all. (Again: I don't know your reasons/workflow. Maybe you need different software or have other reasons.)

As for delay, it sounds like it can be done without SimpleBlocks? If so, what do I have to look for?
I'm saying not all mkv are SimpleBlock.

Is directly reading the binary data the only way to calculate delay with perfect accuracy? If so that seems more like a deficiency in mkvinfo (where it's already awkward to view delay) than anything.
No, mkvinfo has the same info as other software.

Perenista

11th May 2019, 19:17

`Orum

11th May 2019, 19:32

Audio can be variable, too. (gaps) In that case the raw stream + the info about initial delay is not enough to reconstruct the timings. Information is lost.
While I've never actually seen this, I assume the timecode can be extracted, and reapplied--unless one transcodes the audio, which I assume can change whatever "frame" size was used in the original and then things might fail to align.

In any case, as I've never seen this (and only seen silence added at the beginning/end), I'm not going to worry about it. In those edge cases, transcoding should probably be done with eac3to as you mention, at least initially.

I'm saying not all mkv are SimpleBlock.
I'll have to do more research into mkv to understand what other methods can be used, but at so far all of mine appear to be able to get the relative delay between video and audio by parsing it.

My player will automatically switch to the subtitle I created, even if it's already using another one.
So you want to automatically switch subtitle tracks when the audio track is switched? As far as I'm aware, that's not possible, at least within the mkv file itself. It might be possible with some playback software, but you might need some weird way to try and determine which sub track to use for which audio stream.

hubblec4

11th May 2019, 19:47

Is there a way to do this inside MKVToolnix? If the answer is yes, how?

- Let's say I have an audio track (and we will say this is track #2) that in certain scenes needs the subtitles to be enabled in the Matroska. You know, scenes spoken in another language, that sort of thing.

I already created a subtitle for these parts, and added to the Matroska. Obviously the subtitle file has only text for THESE SCENES. The rest of the movie is not covered by it.

What I want to find out is if:

a) I select the audio track #2;

Then

b) My player will automatically switch to the subtitle I created, even if it's already using another one.

That way when a) is selected b) will follow, meaning the player will automatically refer a) to b) while I am using Media Player Classic.

Meaning even if I select a different subtitle the fact I selected a) will switch the current subtitle selected to... b)

This is a task of Matroska Chapters with the ChapterTrack element which is not supported by all the players I know.
Or you can use TRACKSETEX, but you need Haali Splitter. It works perfect with MPC-HC.

I work currently on a Github project Matroska-Playback (https://github.com/hubblec4/Matroska-Playback) (early state) and here some info about TRACKSETEX (https://github.com/hubblec4/Matroska-Playback/blob/master/src/TRACKSETEX.md) and ChapterTrack (https://github.com/hubblec4/Matroska-Playback/blob/master/src/ChapterTrack.md) element.

filler56789

12th May 2019, 05:11

nevcairiel

12th May 2019, 08:59

Audio with gaps is generally just considered "broken", since it'll easily result in an audible glitch, or result in running out of sync with the video if the player assumes that audio should not have gaps.

Mosu

16th May 2019, 15:07

@Mosu, is there any plan for this? I'm just interested, thanks!

At the moment I don't have concrete plans for working on Dolby Vision. I acknowledge that HDR technologies are important, and I will most likely spend time on those topics in the future, just not soon.

Mosu

16th May 2019, 15:09

I've uploaded a PAL DVD .VOB to your FTP that exhibits some weird behavior.

I don't support MPEG-2 video & VOBs anymore. I would accept patches fixing problems, but I won't spend time on them myself.

Mosu

16th May 2019, 15:22

By which I'm guessing that an auto-written BPS is for a track in MKV, and not for the actual audio data, but I'd like to confirm this. TYIA.

mkvmerge uses a generic algorithm for calculating a track's BPS: it takes the maximum sum of a packet's timestamp and its duration, subtracts from that the minimum timestamp of all packets, and uses that as the track's duration. Then it divides the number of bytes written as frame payload for that track and divides it by that duration.

That algorithm works in mkvmerge's core; it's codec-agnostic and only works on packet timestamps/durations and not on actual number of samples (because it doesn't have access to that type of information).

Mosu

16th May 2019, 15:33

It seems the SegmentInfo.dtd is not correct, but mkvmerge handles the structure correctly.

It's quite possible that the DTDs aren't correct (anymore). DTDs are an outdated and unflexible technology. XML Schemas would have been better, but I never bothered to implement them. As no one asks for them either, it seems people don't need them after all.

Some question about the Info elements:
Mkvmerge can use all Info elements which are available in the info.XML.

mkvmerge only supports the four elements listed here (m_debug_to_tag_name_map) (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/common/xml/ebml_segmentinfo_converter.cpp#L36). It explicitly forbids the elements listed here (m_invalid_elements_map) (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/common/xml/ebml_segmentinfo_converter.cpp#L41).

Mkvpropedit can edit all this elements too? And additionally I can edit some more elements like the Info Title.?

You can ask mkvpropedit which elements it supports by running "mkvpropedit -l":

Elements in the category 'Segment information' ('--edit info'):
title | US | Title: The title for the whole movie.
date | DT | Date: The date the file was created.
segment-filename | US | Segment filename: The file name for this segment.
prev-filename | US | Previous filename: An escaped filename corresponding to the previous segment.
next-filename | US | Next filename: An escaped filename corresponding to the next segment.
segment-uid | X | Segment unique ID: A randomly generated unique ID to identify the current segment between many others (128 bits).
prev-uid | X | Previous segment's unique ID: A unique ID to identify the previous chained segment (128 bits).
next-uid | X | Next segment's unique ID: A unique ID to identify the next chained segment (128 bits).
muxing-application | US | Multiplexing application: The name of the application or library used for multiplexing the file.
writing-application | US | Writing application: The name of the application or library used for writing the file.

And then there are some elements which can't be edited, this values are written while mkvmerge mux the mkv file.
- Duration
- DateUTC
- MuxingApp
- WritingApp

Except for the duration those elements can be set with mkvpropedit, but not with mkvmerge.

The TimestampScale element can be set before I mux an mkv. Is this only possible with a command line switch?

That's the only way. You cannot change with mkvpropedit.

chros

16th May 2019, 17:17

At the moment I don't have concrete plans for working on Dolby Vision. I acknowledge that HDR technologies are important, and I will most likely spend time on those topics in the future, just not soon.
No worries and thanks for all your work!

hubblec4

16th May 2019, 19:56

Many thanks Mosu for the info.

Mosu

18th May 2019, 13:18

Hey,

here's the May release of MKVToolNix, v34.0.0. It's a tiny update with just three bugs fixed (and several translations updated).

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 34.0.0 "Sight and Seen" 2019-05-18
Bug fixes

mkvmerge: all subtitle frames are now treated as key frames in order to fix wrong data in source files. Fixes #2541 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2541).
mkvmerge: AV1: fixed frame timestamp calculation when reading bitstreams that lack timing information from IVF files. Fixes #2553 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2553).
mkvmerge: Matroska reader: fixed an infinite loop that could happen with large video frames and applied timestamp files due to too much data being buffered at the wrong time. Fixes #2550 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2550).

Have fun :)

Perenista

6th June 2019, 14:56

I think I found a bug in the last MKVToolnix. I specifically told it to split into 15100 MB parts a 70 GB file (14.7 GB parts to be uploaded to Google Drive), with Dolby Atmos and other tracks. And it did. The problem is that part 5 is missing the Atmos track, while all others (DD 5.1 for example) are there. I tried appending parts 1, 2, 3 and 4 and was able to, but when I reached part 5 I noticed this error.

I don't remember telling MKVToolnix to remove the Atmos track from part 5. And I couldn't have done anything wrong since I splitted into 5 parts. Another thing I did was adding audio tracks/subtitles that weren't there, but I did this to the huge 70 GB file, before the splitting.

Note: part 5 has 9.43 GB.

********

EDIT: Wait, wait, wait, I think I see what's wrong!

The Atmos track is indeed inside the part 5. However it's not showing when I open with MKVToolnix:

MEDIAINFO from part 5.mkv:
https://pastebin.com/0N9vW8r4

What happens when part 5 is opened:

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

Part 1-4 file, 59 GB:

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

Indeed it's a bug. That's why MKVToolnix says "formats don't match" and refuse to append the 59 GB file with the 9 GB one.

Somehow the Atmos information was messed in this splitting. But it's MKVToolnix's fault, not mine.

MEDIAINFO from the 59 GB file (parts 1-4 that I appended):

https://pastebin.com/eCnJU3h6

******

P.S. I did the same procedure in another movie and I appended the 5 parts minutes ago. In this #2 example the movie also has the Atmos track, and the scenario is very similar. Everything went OK, and I was able to append all parts into a big 70 GB file. Very odd.

What went wrong with this other movie?

**********
Update: spoke too soon. I am getting the same error with a third movie.

Here's the log:

--- Errors emitted by job 'Multiplexing to file "SINGLE FILE, PARTS 1+2+3.mkv" in directory "C:\Users\XXXXX\Desktop\XXXXXXXXX"' started on 2019-06-06 11:35:46 ---
The track number 2 from the file 'C:\Users\XXXXXXXXX\Desktop\XXXXXXX/MOVIE- UHD-4K-2160p-Blu-ray-Lossless - 5-5.mkv' cannot be appended to the track number 1 from the file 'C:\Users\XXXXXXXXXX\Desktop\XXXXXXXXXXXXX\MOVIE - UHD-4K-2160p-Blu-ray-Lossless - 4-5.mkv'. The formats do not match.

What is wrong with movie #3?

- Splitted into 5 parts.

- Parts 1, 2 and 3 can be easily appended. Let's call this file: SINGLE FILE, PARTS 1+2+3.mkv

- When I try to append SINGLE FILE, PARTS 1+2+3.mkv into PART 4.MKV this is what I am getting now:

THE FORMATS DO NOT MATCH

But how? Part 4 was generated from the huge 70 GB one!

And Part 5 of this third movie is also failing to display the Atmos track in MKVToolnix. For this reason it's saying: "cannot be appended to the track number 1"

Because the file SINGLE FILE, PARTS 1+2+3.mkv expects that PART 5.mkv has the Atmos track as TRACK NUMBER 1.

Since it's only seeing the DD 5.1 instead it will not append.

However the Atmos track is still there.

Another MediaINFO, part 5 from this third movie:

https://pastebin.com/MbiVj8Hk

Like the 2nd movie this one also had new tracks added to it. A dubbed one, and 2 new subtitles.

My theory is that by adding a foreign track I messed with the splitting. Perhaps I should have saved everything first, and only after I should have splitted?

mariush

6th June 2019, 15:57

Perenista

6th June 2019, 16:11

Not saying it's not a bug but...

Any particular reason you're not just using 7zip or some other compression software to create a multi volume archive with NO compression (or super fast compression) and volume sizes the amount you want?
You can set each volume to something like 990 MB or 2950 MB or 4950 MB, allowing you to upload 15/5/3 segments totalling 14750-14850 MB

In addition to that, you also have the benefit of encrypting the contents of the archives even if they're packed with no compression..I am uploading 15 GB parts to free Google Drive accounts (this is the limit). It's 4K content. They can be streamed or downloaded later and appended, to make a single file with whatever original size it was.

So it would make no sense to use WinRAR here, since I want the MKV to be streamed.

What I did was to convert the original disc into Matroska, then I added new tracks (one dubbing and 2 or 3 new subtitles). However I didn't save the 70 GB file again after adding those tracks. I simply added them for the upcoming task. But before hitting "Start multiplexing" I configured MKVToolnix to save into 15100 MB parts.

That's why the 70 GB file was saved into 5 others.

The issue I discovered here is that part 4 is saying "format don't match" and part 5 is missing the Atmos track while opening it in MKVToolnix.

Turns out that I will be able to append parts 1, 2 and 3, but part 4 (and 5) are impossible to be appended into this third movie.

For the 2nd movie the error is in part 5. Parts 1, 2, 3 and 4 were appended successfully.

The bug consists of:

- While part 5 has the Atmos track inside the file, MKVToolnix is ignoring it exists, after opening.

- Part 4 from this 3rd movie is somehow messed and for an unknown reason can't be appended to parts 1-2-3.

*******

Also: I installed a new SSD recently (2 days ago), and after that I formated and installed Windows 10-64 bit. Also checked the drive's health. So this isn't in any way some sort of system corruption.

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

Update:

Part 4 was appended now to the 1-3 file from the 3rd movie.

So the only bug that remains is the hidden Dolby Atmos track from part 5. The bug affected two movies by now, yet strangely leave one out of it.

hubblec4

6th June 2019, 17:48

I ask me often when users learn that cutting with MKVToolNix is a bad idea. It works in most cases of course, BUT Matroska has some limitations for cutting and so you run from time to time in a split issue for some files. And this is not a bug of mkvmerge.

Perenista

6th June 2019, 17:55

Here's a more thorough explanation of what I did. Disregard all my previous posts and read this one to avoid any confusion.

- The movie has the Dolby Atmos track, and MAKEMKV says DD 5.1 for the secondary track of it. MAKEMKV also lists a 3rd track (separated from the Atmos) which is also Dolby Digital 5.1. I always assumed both are 100% identical, yet I always leave two tracks named as DD 5.1. Since I want a MKV lossless version from the disc I proceed this way.

Then there's a 2.0 track which is the audio commentary.

The movie also has 1 subtitle, english closed captions. Plus chapters.

It's Ultra-HD Blu-ray (4K).

*******

What I did, in the 1st place:

1) Saved the UHD into a single MKV. Final size is more or less 70 GB. With all tracks mentioned before.

2) Opened this MKV with MKVToolnix.

3) I also had additional tracks for this movie, saved elsewhere:

a) Portuguese dubbing.
b) English subtitles (not CC)
c) Portuguese subtitles

4) Added a, b and C) to 2), the 70 GB file.

5) MKVToolnix is still open. I added a, b and c, yet I haven't saved the 70 GB file again, which would end up having +- 71 GB.

6) I instruct MKVToolnix to split into 15100 MB parts, with a, b and c. It ends saving into 5 splitted parts.

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

So this is it.

Now why am I calling a bug?

Because when we open part 5 in MKVToolnix the Atmos track is missing. But it's there inside the file! Only MKVToolnix is not seeing.

I am able to append parts 1, 2, 3 and 4 together again. Not part 5.

This is what happens when we try to... append part 5 into parts 1+2+3+4:

>>>>>>>>>>>>>>>>>>>>>>> The track number 4 from the file PART 5.MKV cannot be appended to the track number 3 from the file PARTS 1+2+3+4.MKV. The number of channels of the two audio tracks is different: 2 and 6

In the above test I didn't select the Atmos track. So in theory it should work, right? Since parts 1+2+3+4 have the same tracks as part 5.

If I select the Atmos track in the file PARTS 1+2+3+4.mkv this is the end result:

>>>>>>>>>>>>>>>> The track number 2 from the file PART 5.MKV cannot be appended to the track number 1 from the file PARTS 1+2+3+4.mkv. The formats do not match.

*********

Now what might happen if I not only remove the Atmos track from PARTS 1+2+3+4.mkv, also the two DD 5.1 tracks? And do the same with PART 5.mkv?

Answer: it will now be possible to append part 5!

Another test:

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

Try to select only one DD 5.1 track.

Result?

Fail. The same "The number of channels of the two audio tracks is different: 2 and 6" error.

Final test:

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

Result: Success! I am now able to append part 5.

So this means the fact two different tracks have the same name.... MKVToolnix is causing all these problems? And also hiding the Atmos track in part 5?

I ask me often when users learn that cutting with MKVToolNix is a bad idea. It works in most cases of course, BUT Matroska has some limitations for cutting and so you run from time to time in a split issue for some files. And this is not a bug of mkvmerge.I consider a bug when I have been doing this splitting and appending for years and this is the first time EVER I encounter such problem. And I discovered all of sudden! No idea why this is happening yet.

I did everything correct, yet this bug appeared in TWO MOVIES. It's not an isolated case.

What is odd is that it didn't happen for a 3rd movie I was doing the same stuff, however in this case the tracks have different names. I believe the fact two different tracks had the same name (DD 5.1) completely messed MKVToolnix.

I only split files due to Google Drive's limited 15 GB space for free accounts. If was up to me I would never do that.

P.S. MAKEMKV before I converted the 4K to MKV:

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

Perenista

9th June 2019, 19:31

I fixed all the issues mentioned by creating a single 70 GB file with all the changes, and only after finishing all my editions I splitted the file into 151000 MB parts. Then I tried appending again, and it worked for ALL MOVIES.

What happened here was that I tried to do two things AT THE SAME TIME: a) add new contents to a file, and b) split the original file + a) which had not even been added. That's why mkvToolnix was incapable of appending it again, somehow things got messed after this task.

Mental note: do all the changes to the MKV and only after them split the whole thing. I tried to save some time, not knowing this would break the final results if in the future I wanted to append it into a single big file. I hope I didn't mess any of the previous MKVs, created in the past.

sneaker_ger

9th June 2019, 19:35

The question is whether you accidentilly made a user mistake. Or if you had found a bug. It would be nice if such a bug could be documented and fixed even if you now have a workaround.

qyot27

10th June 2019, 04:07

Considering the history of MakeMKV's Matroska output sometimes being funky, it wouldn't surprise me if it had to do with mkvmerge having to fix the original mux in the first place. Eliminate that X factor entirely; use MakeMKV's Backup mode and then give mkvmerge the index.bdmv and do all the stream manipulation from there. That would confirm whether this really was a bug in mkvmerge or not.

Mosu

22nd June 2019, 11:56

Time for release v35.0.0 of MKVToolNix. Again, it only includes a small number of enhancements and bug fixes; nothing major.

There've been no changes regarding packaging since the previous 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 35.0.0 "All The Love In The World" 2019-06-22
New features and enhancements

mkvmerge: JSON identification: the "codec name" track property will be output as "codec_name". The JSON schema has been bumped to v12 for this change.
MKVToolNix GUI: job queue: added a new type of action to execute after job completion: deleting source files for of multiplexer jobs. As this is a destructive operation, the action is disabled by default. Implements #869 (https://gitlab.com/mbunkus/mkvtoolnix/issues/869) and #2570 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2570).

Bug fixes

mkvmerge: the "codec name" track property wasn't copied from Matroska files. Fixes #2566 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2566).
MKVToolNix GUI: multiplexer: Windows: clearing the destination file name will reset the tab name to "<No destination file>" again. Fixes #2571 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2571).
MKVToolNix GUI: multiplexer: the file types were not re-translated if the UI language was changed. Fixes #2572 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2572).

Have fun :)

hubblec4

23rd June 2019, 00:33

Hi Mosu
The old "codec name" track property (now codec_name) was "codec" only?

sneaker_ger

23rd June 2019, 08:32

CodecName is the most useless element anyways. I don't see the purpose as CodecIDs are already human-readable and unambiguous.

Wakaku

23rd June 2019, 16:22

Hello, it's been quite a while, I just need a little help. After muxing/remuxing with v35.0, tag portions which contain ChapterUIDs are lost. There are no Warnings or Errors, all smooth, both left and right message boxes are blank after muxing/remuxing.

These two ways end up with the same results:

Remuxing an existing MKV with such an exisiting tag.
Muxing an MKV plus an external XML tag.

Here are my sample tags. The tags are intended for 3 WWE videos downloaded from Youtube, but concatenated with FFmpeg to create a single MKV. Thus the related metadata, covers, and chapters for each video (eg. URL's, titles, etc) in the single MKV.

Original XML tag (https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxkcDc5bGFrYXN8Z3g6MThhNDA5NzExODAwYzUxZA)
After remuxing with v35.0 (https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxkcDc5bGFrYXN8Z3g6M2U0MTgyOTRhNDlhZTcxYw)

Is there any new option or setting to use to achieve the old/previous behavior? Thanks in advance.