MKVToolNix v99.0 released

[Liisachan]

Yeah, sure, I could ask that question. But I don't care all that much for one simple reason: the update check transmits & reveals less information about the user than what they reveal when visiting the MKVToolNix web site with a regular browser as Qt's network library only transmits a very limited set of headers. Here's the full request:

GET /latest-release.xml.gz HTTP/1.1
Host: mkvtoolnix.download
Connection: Keep-Alive
Accept-Encoding: gzip, deflate
Accept-Language: en-US,*
User-Agent: Mozilla/5.0

The same request will be made for "/releases.xml" for populating the list of changes.

Update check itself is not a big problem for me. You can easily turn it off, except for the very first time.

What I don't really like is, when the GUI shows info about new version(s), a link to youtube is shown in such a way that the user may think it's a link to the release note. If you click such a link, youtube.com is called, then indirectly gstatic.com, accounts.google.com, etc. While one might argue this trick-to-click is okay because mkvtoolnix.download itself is affiliated with Google anyway, I think the link should honestly say "Search this on youtube" if it's a link to youtube.

Related to the DPI problem (cosmetic): v40 on Win7; it seems that the "Disable scaling for high DPI displays" option doesn't change anything when the GUI is closed and restarted: tested three 3 dpi values (113; 120; 138).

PS Win7 users should be aware that just because you don't use Win10 doesn't make you "safe."

[Mosu]

What I don't really like is, when the GUI shows info about new version(s), a link to youtube is shown in such a way that the user may think it's a link to the release note.

Ah, I see. Before you only talked about the update check. So even if this is moving the goalposts a bit, I think this problem can be easily fixed by changing the layout of the headings, e.g. to something like this:

MKVToolNix news & changes (view full list online (https://mkvtoolnix.download/doc/NEWS.md))

Version 40.0.0 "Old Town Road + Pony" (listen on YouTube (https://www.youtube.com/results?search_query=Pomplamoose+Old+Town+Road+Pony))

That better?

[Liisachan]

@Mosu
For me, the root of the problems is that random applications try to connect to remote addresses when the user does not ask/allow them to do so. Such a behavior might have been frowned upon 10 or 20 years ago. Today people seem okay with that. MKVToolnix GUI is just one of many such “today” tools. The solution is obvious (a firewall set up to block/intercept every connection by default). The update check of this GUI does not cause any real problem, easy to disable, and perhaps many people today love automatic checking. So I'm not requesting any changes about this. I block its connection and don't use that dialog box, so its links are not my problem.

What I'm unhappy about is not your GUI, but this trend in general. Even free software (e.g. firefox) doesn't necessarily respect your privacy anymore. Free/nonfree and privacy-oriented/Google-like, are two different dimensions.

Anyway, I'd like to report something different. In /doc/en/mkvmerge.html

1) 12. Attachments: in the example, TTF is attached with --attachment-mime-type application/octet-stream (!!) Yes, I remember I used this MIME in early days. I really hope that the Matroska specs will have a footnote, clarifying which MIME types should be supported as an embedded font.

2) --aac-is-sbr is explained as “needed if a) the source file is an AAC file (not for a Matroska(tm) file) and”... this "not for" is a bit confusing. Perhaps you mean "not from", "not stored in" or something like that?

[DMD]

Good morning
I need to create MKV files with multichannel audio, with audio files in RF64 (https://en.wikipedia.org/wiki/RF64) format, is there no way to make this format compatible with MKVToolnix?
Thanks

[Mosu]

Good morning
I need to create MKV files with multichannel audio, with audio files in RF64 (https://en.wikipedia.org/wiki/RF64) format, is there no way to make this format compatible with MKVToolnix?
Thanks

I've just enhanced mkvmerge's WAV reader to be able to handle RF64 files, too. Please give the latest pre-build from here (https://mkvtoolnix.download/windows/pre/64-bit/) a try. If it doesn't work for you, I'll need a sample file for which mkvmerge fails.

[SeeMoreDigital]

Good morning
I need to create MKV files with multichannel audio, with audio files in RF64 (https://en.wikipedia.org/wiki/RF64) format, is there no way to make this format compatible with MKVToolnix?
ThanksThis is interesting...

Why RF64 and what playback device are you intending using?

[Sharc]

.mp4 files have a 'rotation' parameter which ensures that portrait filmed clips (for example from mobile phones) are played back in portrait orientation on TV etc.
When remuxing such files to .mkv the orientation flag seems to get lost and the portrait clip is shown in landscape orientation (90° flipped). Is there an option for keeping the rotation flag in .mkv, or would I have to resize and re-encode the source before remuxing it to .mkv?

[hubblec4]

There is an element called ProjectionPoseRoll, but this element is nowadays not supported.
You can use Matroska Tags (3 players support it) with a SimpleTag -> TagName = ROTATE; TagString = 90 or 180 or 270
and in the Targets element you add a TrackUID element with the UID of the video track.

You could try chapterEditor.

[Sharc]

Thanks, will try. But as you write it seems not to be widely supported by players.

[Mosu]

Hey,

here's one last release before the end of the year, and it's a bit bigger than the previous ones. Have a look at the news below for details.

Nothing's changed for package maintainers.

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

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

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

Version 41.0.0 "Smarra" 2019-12-06

New features and enhancements


mkvmerge: Matroska reader: Vorbis tracks: stream comments (aka Vorbis comments) will be converted to Matroska attachments (for cover arts) and Matroska track tags (for other comments). Additionally the stream comments will be removed from Vorbis headers.
mkvmerge: MP4 reader: added support for reading Opus audio from MP4 files. Part of the implementation of #2673 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2673).
mkvmerge: MP4 reader: added support for reading VP9 video from MP4 files. Part of the implementation of #2673 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2673).
mkvmerge: Ogg reader: Vorbis, Opus & VP8 streams: stream comments (aka Vorbis comments) will be converted to Matroska attachments (for cover arts) and Matroska track tags (for other comments). Additionally the stream comments will be removed from Vorbis headers.
mkvmerge: WAV reader: added support for reading RF64 files.
MKVToolNix GUI: multiplexer: the list of predefined track names is now split up into three lists, one for each track type (audio, video & subtitles). Part of the implementation of #2654 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2654).
MKVToolNix GUI: multiplexer: when trying to add thumbnails for a Blu-ray the GUI will determine the thumbnail's pixel size from the thumbnail files if the XML file doesn't contain that information. This works for JPEG and PNG files. Implements #2674 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2674).
MKVToolNix GUI: general: line edits & combo boxes will now have a "clear text" button appear whenever they're not empty. Part of the implementation of #2654 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2654).
MKVToolNix GUI: update check: the dialog showing the latest news & version information states explicitly where the links take the user (the MKVToolNix "NEWS.md" file and YouTube respectively).


Bug fixes


mkvmerge: Matroska reader: mkvmerge did not copy the codec's private data when reading WavPack from Matroska files. Fixes #2685 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2685).
mkvmerge: MPLS handling: re-added caching when using MPLS playlists as input files. Fixes #2666 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2666).
mkvmerge: MPEG TS reader: when reading an MPLS playlist, the calculation of the minimum timestamp to use for shifting all output timestamps to zero was wrong. It was wrongfully considering timestamps from packets it would not copy due to the MPLS's timestamp restrictions. This could lead to the first timestamps in the output file being quite large, e.g. more than a couple of minutes, causing sync problems when multiplexing together with other files. Fixes #2670 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2670).
MKVToolNix GUI: multiplexer: the automatic switch between aspect ratio & display width/height wasn't reflected in the configuration generated for "mkvmerge". The user had to change between the two settings manually. Fixes #2660 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2660).
MKVToolNix GUI: multiplexer: the progress dialog shown when scanning a Blu-ray wasn't closed properly in certain situations. Fixes #2678 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2678).
MKVToolNix GUI: general: the configured font was not applied to a lot of controls (e.g. the file & track lists or the menu entries) on application startup. Instead the user had to open & close the preferences in order for the font to be applied to all controls. Fixes #2671 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2671).


Have fun :)

[redbtn]

Thank you Mosu! Great work!
And thanks for vorbis comments, you didn't forget.

[Overdrive80]

Would be possible for next versions, let sustitute files from GUI?? For example, at select file and right button of mouse, option for replacing file. This would let keep options of configuration for that track.

Thanks.

[redbtn]

What does it mean? Every time after muxing > demuxing *.avc file this 127 bytes adds.
I'm asking because if I remember correctly, earlier versions doesn't change *.avc.

https://t37.pixhost.to/thumbs/59/129423178_fs-2019-12-08-05-53-15_cr.png (https://pixhost.to/show/59/129423178_fs-2019-12-08-05-53-15_cr.png)

https://t37.pixhost.to/thumbs/59/129423179_fs-2019-12-08-05-56-08_cr.png (https://pixhost.to/show/59/129423179_fs-2019-12-08-05-56-08_cr.png)

[Dulus_No]

@redbtn
Seems to be relevant: https://forum.doom9.org/showthread.php?p=1869782#post1869782

[redbtn]

@redbtn
Seems to be relevant: https://forum.doom9.org/showthread.php?p=1869782#post1869782
Thank you. It seems it's normal behavior, so there is no problem then.

[Liisachan]

MKVToolNix GUI: update check: the dialog showing the latest news & version information states explicitly where the links take the user (the MKVToolNix "NEWS.md" file and YouTube respectively).


Thanks for taking your precious time, making this more transparent, and I'm sorry I annoyed you and made this thread awkward because of my comments about something that might look paranoid. I have nothing against many users who love YouTube, but a few users do avoid YouTube, as seen in a comment to a DEF CON 2019 talk video “YouTube version (for those who can tolerate surveillance capitalism) (https://blog.torproject.org/next-chapter-anti-censorship)”. One might misunderstand you if you keep using perceived trick-to-click to a commercial site run by a company paying you, so I thought it might be your problem.

If possible, I'd like to have a --deterministic option, where the output MKV files with the same command line are always bit-identical, if things like DateUTC/SegmentUID/TrackUIDs/_STATISTICS_WRITING_DATE_UTC are manually set identical (or --disable-track-statistics-tags is used for the stats). A deterministic output would have a few obvious advantages; you can easily see the output is ok (no accidental hw error occurs while muxing), by just running the same command line twice on different machines, and check if the two outputs are identical. If this is technically difficult, though, please ignore this suggestion. Thanks again.

[mkver]

Such a thing already exists: --engage no_variable_data

[Liisachan]

Such a thing already exists: --engage no_variable_data

Thank you very much. That hack seems very useful for testing.

[Mosu]

Would be possible for next versions, let sustitute files from GUI?? For example, at select file and right button of mouse, option for replacing file. This would let keep options of configuration for that track.

No, sorry. Way too much work, especially with getting things right for files which don't exactly match the replaced file's structure.

[Mosu]

Thanks for taking your precious time, making this more transparent, and I'm sorry I annoyed you and made this thread awkward because of my comments about something that might look paranoid.

Please don't worry about it. I'm not annoyed; everything's fine. In fact I had never considered what users might expect when clicking on the version code name (back when the code name was linked to Youtube) — and that there was no way for the user to actually see where the link pointed to without clicking on it.

If possible, I'd like to have a --deterministic option, where the output MKV files with the same command line are always bit-identical, if things like DateUTC/SegmentUID/TrackUIDs/_STATISTICS_WRITING_DATE_UTC are manually set identical (or --disable-track-statistics-tags is used for the stats).

That's something I might indeed implement, with a couple of caveats. As mkver said there is the option "--engage no_variable_data" which does lead to bit-identical files — however, that's only supposed to be used for testing purposes (e.g. I use it in MKVToolNix' test suite). The intentional drawback of that option is that all UIDs start at 1 counting up and that certain strings (e.g. "muxing application" and "writing application") are replaced by the ugly string "no_variable_data".

One caveat is that I would only guarantee that the same version of mkvmerge would produce the same files — meaning I wouldn't guarantee that mkvmerge 40 and 50 create the same files. This shouldn't be a problem for your use case.

The other caveat is that I would likely make the user have to provide a seed for the random number generator with the option (seed = a number the user choses which will then be used for starting the random number generator; the RNG would then produce the same sequence if the same seed number was given).

Why would I want that? Well, because UIDs do matter to mkvmerge. For example, when reading chapters from different files chapters with the same UID are considered to be the same chapter; they're merged by mkvmerge into a single entry. If all random number generation always started with the same name, chances are way too high that all chapters end up with the same UID over and over again. This is the case with "--engage no_variable_data", obviously.

Sure, the user might always use the same seed number, but then again it's not my fault anymore :)

As I'm busy at the moment: please open an issue over on Gitlab for this idea so that it won't get lost. Thanks.

[Liisachan]

The other caveat is that I would likely make the user have to provide a seed for the random number generator with the option (seed = a number the user choses which will then be used for starting the random number generator; the RNG would then produce the same sequence if the same seed number was given). Sounds a good idea to me. Since humans are bad at coming up with a random seed, it might be convenient if it accepts an arbitrary string, which is hashed internally. I'll explain this when I open an issue (not an issue, just a request though).

Why would I want that? Well, because UIDs do matter to mkvmerge. The current version of Header Editor lets me edit TrackUID, but it doesn't update Tag/Targets/TrackUID, so I'll get orphaned tags. Is this by design?

As I'm busy at the moment: please open an issue over on Gitlab for this idea so that it won't get lost. Thanks. I'm going to do that this weekend. Thanks again :)

[Mosu]

Sounds a good idea to me. Since humans are bad at coming up with a random seed, it might be convenient if it accepts an arbitrary string, which is hashed internally. I'll explain this when I open an issue (not an issue, just a request though).

Easy enough to do; I can simply calculate an Adler 32-bit checksum over the argument and use the result as the seed.

The current version of Header Editor lets me edit TrackUID, but it doesn't update Tag/Targets/TrackUID, so I'll get orphaned tags. Is this by design?

Hmm, I never considered that. Not sure what I'd call that (bug or intentional behavior). Both mkvpropedit & the header editor were meant to be low-level tools for the user to _quickly set fields to any value they want with the caveat that they must know what they're doing. Other fields face similar issues with changes: segment UID, next/previous segment UID might break file linking; changes to the default duration will change the interpretation of timestamps of laced frames; changing the track number will break all existing blocks.

I think changing the UIDs inside tags & chapters would be good, but the other things I listed won't be fixed.

Please open an issue for this, too. Thanks.

[Megalith]

Is it possible to sync MKVToolNix jobs between different PCs (W10)?

[rco133]

Hi.

I am not even sure that this is related to MKVToolnix, but I don't know where else to ask.

I have a x265 video file, a DTS HD-MA audio file and an AC3 audio file that I want to mux together to one MKV file.

When I do it the following happens.

Order of added files:

video
DTS
AC3

Result is that when AC3 audio is selected the video speeds up, and the audio also speeds up. My guess is double speed.

video
AC3
DTS

Result is that when DTS audio is selected the video slows down and the audio also slows down. My guess is half speed.

No video, just audio
DTS
AC3

Result is DTS normal speed and AC3 is double speed.

The two audio files played seperatly both play at normal speed. But when combined with MKVToolnix, only the first one plays normal, and the second one is either double or half speed.

DTS track is a 2 channel HD-MA track and the AC3 track is a 2 channel 192 kb/s track.

I am sure that it is probably something with the audio files, since I have done this in MKVToolnix many times without any problems.

I am using Win10 and have tried most recent and several older MKVToolnix versions. All yield the same result.

Anyone have an idea on how to trouble shoot this, and maybe pinpoint what is actually going wrong?

Thanks in advance.

rco133

[rco133]

Hi.

I am not even sure that this is related to MKVToolnix, but I don't know where else to ask.

I have a x265 video file, a DTS HD-MA audio file and an AC3 audio file that I want to mux together to one MKV file.

When I do it the following happens.

Order of added files:

video
DTS
AC3

Result is that when AC3 audio is selected the video speeds up, and the audio also speeds up. My guess is double speed.

video
AC3
DTS

Result is that when DTS audio is selected the video slows down and the audio also slows down. My guess is half speed.

No video, just audio
DTS
AC3

Result is DTS normal speed and AC3 is double speed.

The two audio files played seperatly both play at normal speed. But when combined with MKVToolnix, only the first one plays normal, and the second one is either double or half speed.

DTS track is a 2 channel HD-MA track and the AC3 track is a 2 channel 192 kb/s track.

I am sure that it is probably something with the audio files, since I have done this in MKVToolnix many times without any problems.

I am using Win10 and have tried most recent and several older MKVToolnix versions. All yield the same result.

Anyone have an idea on how to trouble shoot this, and maybe pinpoint what is actually going wrong?

Thanks in advance.

rco133

I may have found the issue. The DTS HD-MA file is 96 kHz sample rate while the AC3 file is 48 kHz sample rate. At least I think that may be the issue.

rco133

[filler56789]

I may have found the issue. The DTS HD-MA file is 96 kHz sample rate while the AC3 file is 48 kHz sample rate. At least I think that may be the issue.

rco133

My not-so-humble opinion: the problem is not in MKVmerge, the problem is not in the audio files themselves, the problem is in the software /firmware you used for playing that Matroska file.

Would you mind naming it?

[rco133]

My not-so-humble opinion: the problem is not in MKVmerge, the problem is not in the audio files themselves, the problem is in the software /firmware you used for playing that Matroska file.

Would you mind naming it?

Sure. As I said to start with I suspected it might not be a MKVToolnix issue.

Since my last post I have tried several software players.

MPC-HC 1.8.8 is my default player, and the one I first detected the issue on. Looks like it doesn't like two audio tracks to have different sample rates.

VLC, for some reason I was not able to get it to show the video. But the file played, and I could change audio tracks without the pitch of either of them changing.

SMPlayer plays the MKV file just fine, and I can change between the two audio tracks without problems.

MPC-HC relies on LAV filter I belive. No idea if this is an MPC-HC or LAV filter issue.

Looks like MKVToolnix has absolutely nothing to do with the issue at hand.

rco133

[Aleksoid1978]

Sure. As I said to start with I suspected it might not be a MKVToolnix issue.

Since my last post I have tried several software players.

MPC-HC 1.8.8 is my default player, and the one I first detected the issue on. Looks like it doesn't like two audio tracks to have different sample rates.

VLC, for some reason I was not able to get it to show the video. But the file played, and I could change audio tracks without the pitch of either of them changing.

SMPlayer plays the MKV file just fine, and I can change between the two audio tracks without problems.

MPC-HC relies on LAV filter I belive. No idea if this is an MPC-HC or LAV filter issue.

Looks like MKVToolnix has absolutely nothing to do with the issue at hand.

rco133

Can you upload problem file ?

[Mosu]

Is it possible to sync MKVToolNix jobs between different PCs (W10)?

If by "sync" you mean "copy", sure, with limitations. Each job file has a unique ID and can be dropped into the job queue directory (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Location-of-settings,-job-queue,-cache-folder) of another MKVToolNix installation without overwriting anything. When MKVToolNix GUI starts it scans all files in the job queue directory and reads all it finds — meaning you don't have to do anything else to make the GUI pick up your copied file.

The limitation is that the source files must exist in the same paths on the other installation, of course.

[Liisachan]

@Mosu
Thanks very much for implementing (https://gitlab.com/mbunkus/mkvtoolnix/commit/b519eadbd0a66666ca6414f8372a94da4d5f693a) the deterministic option (#2698 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2698)). This may be a very cool feature :)

That is, when a few people are creating MKV files as a team, this option may be very convenient to automatically detect it when something goes wrong. Conceptually, a quality-checker can simply demux the MKV created by a teammate and remux it with the same command-line (with the same seed), to see they get an identical file.

Also, when you're creating a mission-critical MKV file, you may want to mux it twice to see the results are bit-identical. This is like something an audiophile might do, when ripping a CD not in DB (ripping it more than once to make sure every bit is ok).

Note. If I understand correctly, what is guaranteed by this option is bit-identicalness with respect to a fixed seed. Two deterministically written MKV files with different seeds, s1, s2, are generally not only non-identical, but also might be different in size. This might happen for example when only one UID in s1-MKV is different in size compared to the corresponding UID in s2-MKV, e.g. one happens to be small and fits in 7 bytes while the other requires 8 bytes. In this example, MKV with s1 is always smaller by 1 byte than MKV with s2 (*). But s1-MKV is always identical no matter how many times you mux it, and s2-MKV is always identical too.

(*) If this is a problem for some reason, one can simply try a different seed such that each UID will have a “typical” byte size.

:thanks:

[GCRaistlin]

Muxing a file to Matroska and then demuxing it back (for example wav>mka>wav) doesn't give us the identical copy of the source file (I believe the header gets changed). Thus, it's hard to compare tracks demuxed from BDMV and tracks demuxed from Matroska: we need to mux tracks demuxed from BDMV to Matroska, then demux it and only then compare. Can anything be done about that?

[Selur]

Using a Sample (https://drive.google.com/open?id=17GvV7mOGPaLMaOmJuyZv7AfhRsdrBM-D) which has 6.1 DTS-HD audio
mediainfo.exe c:\Users\Selur\Desktop\Sample_7Ch-001.mkv
General
Unique ID : 305643535159227373137804081320895496115 (0xE5F0CDBD216A8CAF2B4160690D24BFB3)
Complete name : c:\Users\Selur\Desktop\Sample_7Ch-001.mkv
Format : Matroska
Format version : Version 4
File size : 102 MiB
Duration : 1 min 2 s
Overall bit rate mode : Variable
Overall bit rate : 13.7 Mb/s
Encoded date : UTC 2019-12-28 21:56:35
Writing application : mkvmerge v41.0.0.27 ('Smarra') 64-bit
Writing library : libebml v1.3.10 + libmatroska v1.5.2

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 2 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 2 frames
Format settings, GOP : M=1, N=10
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 min 2 s
Bit rate mode : Variable
Bit rate : 9 771 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.197
Stream size : 72.5 MiB (71%)
Default : Yes
Forced : No

Audio
ID : 2
Format : DTS ES XXCH XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 1 min 2 s
Bit rate mode : Variable
Bit rate : 3 917 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs LFE Cb
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Stream size : 29.1 MiB (29%)
Language : English
Default : Yes
Forced : No
I use:
ffmpeg -y -threads 8 -i "C:\Users\Selur\Desktop\Sample_7Ch-001.mkv" -map 0:1 -vn -sn -bsf:a dca_core -acodec copy -map_metadata -1 "E:\Temp\iId_1_aid_0_lang_en_09_28_20_8410_01.dts"
to extract the dts core and get:
mediainfo.exe "e:\Temp\iId_1_aid_0_lang_en_09_28_20_8410_01.dts"
General
Complete name : e:\Temp\iId_1_aid_0_lang_en_09_28_20_8410_01.dts
Format : DTS ES XXCH
Format/Info : Digital Theater Systems
Commercial name : DTS-ES Discrete
File size : 11.2 MiB
Duration : 1 min 2 s
Overall bit rate mode : Constant
Overall bit rate : 1 509 kb/s

Audio
Format : DTS ES XXCH
Format/Info : Digital Theater Systems
Commercial name : DTS-ES Discrete
Duration : 1 min 2 s
Bit rate mode : Constant
Bit rate : 1 509 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs Cb LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 11.2 MiB
so far so good. Notice the core is DTS-ES with 6.1 audio.
Muxing the audio using mkvmerge using:
mkvmerge --ui-language en -o "E:\Output\Sample_7Ch-001.mkv" --global-tags "E:\Temp\Sample_7Ch-001_09_28_20_8410__02.xml" --language 0:en --default-track 0:yes --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "E:\Temp\iId_1_aid_0_lang_en_09_28_20_8410_01.dts"
I get:
mediainfo.exe "e:\Output\Sample_7Ch-001.mkv"
General
Unique ID : 297622948022399407897597109173123386592 (0xDFE81843105E42451110FB9E70E98CE0)
Complete name : e:\Output\Sample_7Ch-001.mkv
Format : Matroska
Format version : Version 4
File size : 11.2 MiB
Duration : 1 min 2 s
Overall bit rate mode : Constant
Overall bit rate : 1 511 kb/s
Encoded date : UTC 2019-12-29 08:28:49
Writing application : mkvmerge v41.0.0 ('Smarra') 64-bit
Writing library : libebml v1.3.9 + libmatroska v1.5.2
Encoding Gui : Hybrid 2019.12.28.1

Audio
ID : 1
Format : DTS ES XXCH
Format/Info : Digital Theater Systems
Commercial name : DTS-ES Discrete
Codec ID : A_DTS
Duration : 1 min 2 s
Bit rate mode : Constant
Bit rate : 1 509 kb/s
Channel(s) : 6 channels
Channel(s)_Original : 7 channels
ChannelLayout_Original : C L R Ls Rs Cs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 11.2 MiB (100%)
Language : English
Default : Yes
Forced : No
-> Seems like mkvmerge flags the stream as 6 channel audio.


=> is this a bug or did I miss something?

---
Update:

using ffmpeg for muxing:
ffmpeg -y -r 0 -i "E:\Temp\iId_1_aid_0_lang_en_09_28_20_8410_01.dts" -acodec copy -metadata encoding_tool="Hybrid 2019.12.28.1" -r 0 "E:\Output\Sample_7Ch-001_new.mkv"
everything looks fine:
ediainfo.exe e:\Output\Sample_7Ch-001_new.mkv
General
Unique ID : 214078310457880531657066923291995838582 (0xA10DFB9C6A72D9428FC442879C209876)
Complete name : e:\Output\Sample_7Ch-001_new.mkv
Format : Matroska
Format version : Version 4
File size : 11.3 MiB
Duration : 1 min 2 s
Overall bit rate mode : Constant
Overall bit rate : 1 515 kb/s
Writing application : Hybrid 2019.12.28.1
Writing library : Lavf58.35.100
ErrorDetectionType : Per level 1

Audio
ID : 1
Format : DTS ES XXCH
Format/Info : Digital Theater Systems
Commercial name : DTS-ES Discrete
Codec ID : A_DTS
Duration : 1 min 2 s
Bit rate mode : Constant
Bit rate : 1 509 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs Cb LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 11.2 MiB (100%)
Default : Yes
Forced : No
-> so this is probably a bug / missing feature in mkvmerge.

Cu Selur

[Mosu]

Conceptually, a quality-checker can simply demux the MKV created by a teammate and remux it with the same command-line (with the same seed), to see they get an identical file.

Technically those cicumstances don't fall under the conditions I've laid out in the documentation, namely that the source files used to create the Matroska file aren't byte-identical. mkvmerge can and will modify the bitstream for certain codecs, and that process isn't reversed by mkvextract (and technically that process cannot be reversed as there's no way to determine which modifications were actually done). Example: h.264, prefixing key frames with SPS/PPS NALUs or modifying the SPS wrt. to timing or aspect ratio information.

Or to put it differently: given the following processing pipeline:

source_file1 → mkvmerge → Matroska_file1 → mkvextract → intermediate_file1 → mkvmerge → Matroska_file2

the bitstreams in Matroska_file1 and Matroska_file2 may very well be different, and therefore Matroska_file1 & Matroska_file2 may very well be different even if the same options & the same seed are used.

Note. If I understand correctly, what is guaranteed by this option is bit-identicalness with respect to a fixed seed. Two deterministically written MKV files with different seeds, s1, s2, are generally not only non-identical, but also might be different in size. This might happen for example when only one UID in s1-MKV is different in size compared to the corresponding UID in s2-MKV, e.g. one happens to be small and fits in 7 bytes while the other requires 8 bytes. In this example, MKV with s1 is always smaller by 1 byte than MKV with s2 (*). But s1-MKV is always identical no matter how many times you mux it, and s2-MKV is always identical too.

That is absolutely correct.

[Mosu]

Muxing a file to Matroska and then demuxing it back (for example wav>mka>wav) doesn't give us the identical copy of the source file (I believe the header gets changed). Thus, it's hard to compare tracks demuxed from BDMV and tracks demuxed from Matroska: we need to mux tracks demuxed from BDMV to Matroska, then demux it and only then compare. Can anything be done about that?

No. As I just wrote to Liisachan: certain modifications are done by mkvmerge to bitstreams of certain codecs (and they have to be in order to produce spec-compliant Matroska files) that cannot be reversed by mkvextract.

[Forteen88]

I just wanted to say that when I used MKVToolNix v41.0.0 to remux (and then encode the *.mka file to AAC) commentary audio from my Blu-ray ("Scream (1996)"), then the sync was not correct with the video, but when I used eac3to to demux (and then encode to AAC) that same commentary audio from the Blu-ray, it worked great.
When demuxing with eac3to, it had lots of these warnings: "[v01] Video has a gap of 1 frames at playtime 0:01:25. <WARNING>" with different playtimes.

[Liisachan]

@Mosu
Thanks for clarification.

@GCRaistlin
Yeah, the first idea was only “conceptually.” To actually do that, some kind of preparation may be necessary...

Happy new year everyone :) 2020 - the 18th year of Matroska (first released in 2003)

[Selur]

@Mosu: Any insight into the DTS-ES handling issue I posted about?

[Liisachan]

2 random observations:
1) a while ago, it was asked why muxing via GUI is faster:

In both cases, it's exactly the same command running, but it's much faster from the gui.

This may or may not be related, but it is documented that (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/About-track-UIDs,-track-numbers-and-track-IDs): “When you add a file to GUI, it runs mkvmerge --identification-format json --identify added-file.ext and parses the output.” So input files are once read already before actual muxing. If, on the other hand, you mux via a command line, it's a cold start. Intuitively this could make differences.

2) Unrelated to 1): I noticed on my Win7 that sometimes a temp file %TEMP%\MKVToolNix-GUI-MuxJob-*.json is not deleted after the job is done. Though I can't reproduce this, I found several such old .json files there. They are not harmless, but I figured I'd report them just in case. Thanks.

[mkver]

2) Unrelated to 1): I noticed on my Win7 that sometimes a temp file %TEMP%\MKVToolNix-GUI-MuxJob-*.json is not deleted after the job is done. Though I can't reproduce this, I found several such old .json files there. They are not harmless, but I figured I'd report them just in case. Thanks.
This has already been reported (as issue 2499 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2499)) and fixed.

[Liisachan]

This has already been reported (as issue 2499 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2499)) and fixed.

Can you reproduce this with a newer version (mkvtoolnix41 tested)?
1) Start GUI, mux something.
2) first json in %TEMP% created
3) Mux something else.
4) second json in %TEMP% -> first json is still memory mapped; not “freed” [potentially a problem if you mux a lot of files?]
5) Don't explicitly close GUI, and shut down Windows. -> json is not deleted [no cleanup on exit, if not explicitly closed?]

[Mosu]

@Mosu: Any insight into the DTS-ES handling issue I posted about?

No, I haven't really looked into it, and I don't plan to at the moment. You can open an issue over on GitLab if it's important to you that I do take a look.

[Selur]

You can open an issue over on GitLab if it's important to you that I do take a look.
Will do, thanks.

[Mosu]

2 random observations:
1) a while ago, it was asked why muxing via GUI is faster:

This may or may not be related, but it is documented that (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/About-track-UIDs,-track-numbers-and-track-IDs): “When you add a file to GUI, it runs mkvmerge --identification-format json --identify added-file.ext and parses the output.” So input files are once read already before actual muxing. If, on the other hand, you mux via a command line, it's a cold start. Intuitively this could make differences.

The identification process only reads the first couple of MB of a file (how much depends on its type). This shouldn't make a difference wrt. overall muxing speed.

2) Unrelated to 1): I noticed on my Win7 that sometimes a temp file %TEMP%\MKVToolNix-GUI-MuxJob-*.json is not deleted after the job is done. Though I can't reproduce this, I found several such old .json files there. They are not harmless, but I figured I'd report them just in case. Thanks.

It's possible this happens when the GUI crashes — but maybe it's something else. Not sure I care enough to spend time on this as the files are created in %TEMP% on purpose, meaning it's totally fine for the user to delete them whenever they seem fit (e.g. via the drive cleanup feature).

[Mosu]

Hey everyone,

I sincerely hope y'all have had a good start into the new year and are sufficiently recovered from whatever you've done over the last couple of days. I've been busy fixing up release v42 of MKVToolNix. Yeah, I'm that boring :)

In this release a lot of source code changed under the hood as I replaced two external libraries (Boost's "optional" and "regex" libraries) with ones from the C++ Standard Library. I tested extensively, but it's quite possible there are bugs lurking due to those changes. If you find one, please file a bug on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/) as usual. Thanks!

Apart from that there were many, many changes; see below for the list.

Dear package maintainers: apart from the aforementioned library changes (Boost's "optional" and "regex" are no longer used, they've been replaced with "std::optional" and "std::regex") four new translations of man pages have been added. The required compiler versions haven't changed, though: gcc ≥ 7 and clang ≥ 4 should work fine. Please adjust your packaging instructions accordingly.

And now for the usual boilerplate:

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 42.0.0 "Overtime" 2020-01-02
New features and enhancements

mkvmerge: added an option for creating byte-identical files: "--deterministic &lt;seed>". Part of the implementation of #2698 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2698).
mkvmerge: Matroska reader: mkvmerge will remove the "icpf" atom headers if they're present in frames read from Matroska files. Implements #2692 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2692).
mkvmerge: MP4 reader: ALAC tracks: the number of channels, sampling frequency and bit depth are now taken from the bitstream in order to fix bogus values on the container level. Implements #2714 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2714).
mkvpropedit: when changing track UIDs the referring elements in existing chapters & tags will be updated automatically, too. Part of the implementation of #2700 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2700).
mkvinfo: when the option "-p"/"--hex-positions" is used, element positions will be output regardless of the verbosity level. Part of the implementation of #2713 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2713).
mkvinfo: added the option "-P"/"--positions" for showing the position of each element in decimal regardless of the verbosity level used. Part of the implementation of #2713 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2713).
mkvinfo: added the option "-o"/"--continue" for continuing processing when the first cluster is encountered regardless of the verbosity level used. Part of the implementation of #2713 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2713).
mkvinfo: added the option "-a"/"--all" for outputting all sub-elements (even cues & seek head entries) and not stopping at the first cluster regardless of the verbosity level used. Part of the implementation of #2713 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2713).
MKVToolNix GUI: multiplexer: added an option in the preferences for disabling adding cover images from Blu-ray discs. Implements #2693 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2693).
MKVToolNix GUI: multiplexer: added mkvmerge's new "--deterministic" option in the "additional command-line options" dialog. Part of the implementation of #2698 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2698).
MKVToolNix GUI: header editor:: when changing track UIDs the referring elements in existing chapters & tags will be updated automatically, too. Part of the implementation of #2700 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2700).

Bug fixes

mkvmerge: HEVC ES parser: fixed a bug in the slice parser calculating the size of a field which in turn could have led to the slice's type being read wrong. Patch by Torsten Hauska. Fixes #2710 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2710).
mkvmerge: Matroska reader: fixed a segmentation fault when trying to read a file that uses header removal compression but no removed bytes are present in the track headers. Fixes #2687 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2687).
mkvmerge: MPEG elementary stream parser: fixed an invalid memory access and use of uninitialized memory that could happen under certain circumstances. Fixes #2690 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2690).
mkvmerge: RealMedia reader: fixed a division by zero when all audio timestamps were zero. Fixes #2689 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2689).
mkvmerge: RealMedia reader: fixed an invalid memory access in the video frame assembly code triggered by invalid data in the file. Fixes #2691 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2691).

Build system changes

"std:: optional" (C++17 feature) is now used instead of "boost:: optional".
"std::regex" is now used instead of "boost::regex".

Other changes

New man page translations into French, Italian, Russian and Chinese Traditional have been added.

Have fun :)

[GCRaistlin]

certain modifications are done by mkvmerge to bitstreams of certain codecs (and they have to be in order to produce spec-compliant Matroska files) that cannot be reversed by mkvextract.

Is there a way to get the identical tracks by demuxing containers that were built from identical tracks at all? The goal is to find out if a container was built from an undamaged source - by comparing tracks demuxed from it (a BDRemux downloaded from a torrent tracker) to tracks demuxed from another container (an original BD downloaded from another torrent tracker).

[Mosu]

Is there a way to get the identical tracks by demuxing containers that were built from identical tracks at all? The goal is to find out if a container was built from an undamaged source - by comparing tracks demuxed from it (a BDRemux downloaded from a torrent tracker) to tracks demuxed from another container (an original BD downloaded from another torrent tracker).

In general: no. It is possible for certain codes under certain conditions. AVC/h.264 and HEVC/h.265 do not fall under those conditions, unfortunately.

[King Mustard]

For years, I have been using mkvmerge GUI v7.9.0 to remove contents from an MKV file (such as audio or subtitle tracks), or change simple things like language or the default track flag.

Despite my comfort with v7.9.0, I want to try upgrading to v42.0.0, as I'm sure sticking with v7.9.0 will eventually cause me issues.

From what I can see, mkvmerge GUI has dissolved in favor of the larger MKVToolNix GUI. Is that correct?

I have attached two screenshots:

eb_mkvmerge-1.png - An example file in mkvmerge GUI v7.9.0
eb_mkvmerge-2.png - The same file in MKVToolNix GUI v42.0.0As an example, I'd remove tracks in mkvmerge GUI v7.9.0 by unticking them in the 'Tracks, chapters and tags' section before choosing a destination file (at the bottom) and choosing Start muxing.

Could someone help explain how I would accomplish the same thing in MKVToolNix GUI v42?

[mkver]

Screenshots on this forum take a really long time to get approved. You'd better use a real image hoster. But actually removing tracks works just the same in the current version as in the older version: You untick them in the "Tracks, chapters and tags" list. It's the lower of the two lists in the multiplexer; the upper is for source files. The "Start muxing" button has been renamed to "Start multiplexing".

[MrVideo]

Jumping in late to the potential loss of Win7 support.

While saying that if you don't like the loss of Win7 support and move to Mac, or Linux/ As pointed out that won't be realistic for EU country businesses and government agencies. Even here in the states, business and governments dictate what the OS/hardware will be used by employees.

The problem, even for personal users, is that Adobe products do not run under Linux. I have a Linux server from which I do all my browsing and file downloading/uploading. If I want to use Photoshop, Illustrator, etc., I have to use M$. Like many others, Win10 is not in the cards. I'll be dead before that OS lands on any of my computers.

Yes, depending on what a business, or government agency, does, there will be Macs provided to those specialized users. Otherwise, general users will have a M$ computer with Adobe products installed.

As a side note, I have cygwin installed on my Win7 systems. I do a lot of Zshell scripting to automate a lot of what I do, including running mkvmerge.

For many of us around the world, Win7 is here to stay.

End of my 2 cents.

[Asmodian]

For many of us around the world, Win7 is here to stay.

This is simply one of the many things you will need to keep old versions of. ;)