MKVToolNix v99.0 released

[Mosu]

Why do we have to use that @ symbol?

I know you're venting, and I get why. Nevertheless, let me take that opportunity to write a bit about command-line design.

Why do we have to use "--help" instead of "-?"? Why do we have to use "--sync" instead of "-sync"? Why do we have to put file-specific options in front of the file they apply to instead of after them?

Because there isn't a Single Right Way to design command line options. There are a lot of different schemes out there, and have been over the years. I do try to be somewhat consistent, I do try to follow existing conventions where that makes sense (e.g. "--help" is the standard for GNU tools and tools for Linux/Unix in general instead of "-?" which is more at home in the Windows world). But often enough there is no precedent for what I'm implementing. So I invent stuff.

As for a precedent I couldn't really find one. On Linux/Unix we usually don't have a problem with command-line options as the Unix shells have always had a high length limit (usually 32 KB). On top of that Linux/Unix shells don't have that character set dichotomy that Windows has with its ANSI & OEM character sets & that cmd.exe was basically a piece of shit you couldn't rely on, especially when trying to deal with Unicode file names & Unicode text input & output. Therefore Linux/Unix tools didn't really need & didn't really have options for reading additional command-line options from a file. If you wanted to put those into a file, you did that and used syntax such as "program `cat file-with-options.txt`". However, the backticks `…` are interpreted by the shell before the program is executed, meaning that the shell's limit of 32 KB applied. cmd.exe didn't have such a thing such as backticks.

Nowadays cmd.exe is… better. Somewhat.

Anyway, the point was that there wasn't a established, commonly-used precedence for such an option I could follow. I did think about using something like "--options" instead of "@", but "--options" would have been way to general for my taste. I though about "--command-line-options", but that's rather long. So I thought about other ways to signal what to do with the file, and I already had my own precedence of prefixing file names with "+" for signalling that the file should be appended. @ has the nice property of not being a special character in shells (bash, zsh, cmd.exe etc.) and doesn't have to be escaped unlike other candidates such as ` * ! < { [ Back in the day I also favored having short option names over longer but explicitly named ones, an stance I've changed opinions on since (see below).

Next time you cannot get something to work may I kindly suggest you ask a bit earlier before getting all worked up about something that isn't all that important in the grand scheme of things? We are happy to help.

Addendum: here are a couple of things I might design differently if I ever reworked the whole command line interface, in no particular order:

Options would not be file-specific anymore. Instead they would always take a file ID and, if appropriate, a track id. That way they would be position-independent. This is one of the things that's still confusing users to this day.
I would use JSON instead of XML (chapter & tag files). Back when I designed that stuff, JSON hadn't been invented yet; neither had YAML. Nowadays JSON is ubiquitous, and there are very good libraries available for all languages, making the choice easy. (An aside: I prefer YAML to JSON for the simple reason that you cannot have comments in JSON files, but you can in YAML. Unfortunately working with YAML is much more error-prone due to it using whitespace as structure and interpreting a lot of bare words such as "yes" as special data types instead of strings. What makes YAML totally unsuitable for MKVToolNix, though, is the language support. There are way fewer YAML libraries out there, mostly due to YAML not only being a data serialization format, but an object serialization format — making it much more complicated and much more dangerous to implement fully, especially for languages without introspection support such as C++. End of long aside.)
I would use full-fledged option names instead of single-character file name prefixes, e.g. "--append filename.ext" instead of "+filename.ext", and yes, "--command-line-options filename.ext" instead of "@filename.ext". Would make the whole experience much more regular, easier to understand and easier to implement — especially given that some of those special chars such as ( ) have to be escaped in a lot of shells.
I would follow GNU-style long option names more closely. This means that you would have single-dash short options followed by a space followed by an argument ("-s 1:150ms") or long, double-dash options followed by either an equals or a space followed by an argument ("--sync=1:150ms" or "--sync 1:150ms"). My tools mostly follow this, but they don't support the variant with the equals. In the Linux/Unix world having long option names with equals is very common, though, and MKVToolNix would have fit in better.
At the moment command-line applications that follow a command-suite model are very popular, e.g. "docker container rm abc47110815" and "docker image pull ubuntu/focal". They follow the pattern "application-name [--optional-global-options] topic [--optional-topic-specific-options] [optional-topic-arguments]". I would probably merge all four existing command line apps (mkvmerge, mkvinfo, mkvextract, mkvpropedit) in a single command-suite style application called… "mkvtoolnix" or "mtx" or so, and expose the functionality of each of the four original tools as topics, e.g. "mtx merge -o out.mkv in.mp4" and "mtx info file.mkv". This wouldn't have that much of an advantage for end users, though; it's more a matter of style or taste. I would imagine that it would lead to a more consistent interface between those four tools, though, solely by forcing me to always think about the command-line interfaces of all applications when dealing with one part of it. So it might have a positive impact on after all.
I would be more consistent with naming options and making clearer what they apply to (e.g. using "--audio-tracks" instead of "--atracks" even though the latter is shorter).
I would treat chapter files like regular source files. The net effect would be that I wouldn't need all those chapter-specific command-line options (e.g. users could simply use "--sync" on a chapter source file instead of "--chapter-sync"). Again, that would make the interface more regular & easier to use (more regular = fewer exceptions/edge cases = less to remember for the end user = easier to use). Actually, this is kind of on my TODO list as it would be possible to retrofit this functionality while keeping the existing options (--chapters, --chapter-charset, --chapter-sync…) for backwards compatibility.
File & track would be consistent, both within the same tool (e.g. all track IDs for all file types would always start at 0, no matter the source container) as well as between tools (e.g. mkvpropedit would certainly not start numbering tracks at 1 whereas mkvmerge & mkvextract start at 0). That's one point I regret the most as it's caused so much confusion for users.

The power of hindsight… It sure would have been nice to have all that insight before I started work on the project, all those nearly 18 years ago.

[Atak_Snajpera]

Yes, I was frustrated that I was unable to understand how this was supposed to work. Personally I have never seen other command line tool using similar way of loading configuration file. --command-line-options looks logical. I don't care if IT is not ultra short. If you plan to merge all tools use mkvtoolnix name instead of meaningles mtx which will be burrowed in search results.

[stax76]

@ has the nice property of not being a special character in shells (bash, zsh, cmd.exe etc.) and doesn't have to be escaped unlike other candidates such as ` * ! < { [ Back in the day I also favored having short option names over longer but explicitly named ones, an stance I've changed opinions on since (see below).

It's not listed under special characters (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_special_characters?view=powershell-7) but there are several language features that use the At (@) character.

Following does not give output due to splatting:


Desktop> Write-Host @aaa

Desktop>


1. Splatting (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_splatting?view=powershell-7)
2. Here Strings (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_quoting_rules?view=powershell-7#here-strings)
3. Arrays (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_arrays?view=powershell-7)
4. Hash Tables (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_hash_tables?view=powershell-7)

In mpv(.net):

--include=<conf file>

[Mosu]

It's not listed under special characters (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_special_characters?view=powershell-7) but there are several language features that use the At (@) character.

Sure, but mkvmerge's use of the @ character actually predates PowerShell (which debuted in 2006). I was talking about when I introduced the feature. Not sure when exactly I introduced the feature, but I found a git commit message from 2005 when I moved the parser function for it to a different file.

In mpv(.net):

--include=<conf file>

That adds another _configuration file_ to parse, not a set of command line options. Not the same thing. Options for parsing additional config files are common for tools that work with config files a lot. And even for those the option names have never been standardized, e.g. "--include" like you wrote for mpv, "--load" for Emacs, "-u" for vim etc. etc.

If you plan to merge all tools…

I don't. That was more of an observation of how things might look if MKVToolNix didn't exist and I was just starting implementing it.

[stax76]

That adds another _configuration file_ to parse, not a set of command line options. Not the same thing. Options for parsing additional config files are common for tools that work with config files a lot. And even for those the option names have never been standardized, e.g. "--include" like you wrote for mpv, "--load" for Emacs, "-u" for vim etc. etc.

It's kind of the same thing because mpv uses a property system, the conf and CLI parser just use the property system, most mpv command line options are just properties.


Using the border property on the command line:

--border=yes
--border=no
--no-border
--border


In the conf file:

border = no


Maybe there are many tools that work like this, I know only mpv however.

[hubblec4]

Is there anybody who uses json configuration file with success? BTW.

Yes, my chapterEditor use JSON options files for muxing mkv's.
Also hSplit and DiscShare uses such a command-line parameter to load params from external files.
I like the "@" prefix.

[Perenista]

I think I spotted a bug in MKVToolnix. It has to do with splitting and appending. Using last version, of course, and also last Codecguide.com version from the codec pack.

Well, I have a huge file here, and I told MKVtoolnix to split into 5 parts total (never mentioned a number, I put unlimited parts and 15200 MB for each part, to fit a free Google Drive account).

Of course later we could use "append" and join all 5 parts.

*********
First of all, this is the data (MEDIAINFO) from the original file. As you can see it's huge, and has multiple subtitles and audio tracks.

https://pastebin.com/0QWZ6hHM

******
If I open this file with MPC-HC (total lenght: 1 hour and 56 minutes) and go to...

(Before mentioning that, I must say that MPC-HC is using madVR (my monitor is old, W2452V), and in filters this is what it says here:

https://i.postimg.cc/NfNSsSCx/XX.png

I opted to use ffdshow audio... in MPC because it allows me to increase the volume (I use 5 db +), while LAV doesn't.

Back to what I was going to say:

If I open the original HUGE file (look into pastebin) with MPC-HC (total lenght: 1 hour and 56 minutes) and go to... 1 hour, 9 minutes and 30 seconds... everything plays fine, selecting the 1st audio track, I named "Dolby Atmos".

However (and this is where I spotted a problem) the splitted files...

When I open file number 4 of 5, it starts playing the moment mentioned above, from 1 hour and 9 minutes.

*****
FILE 4 of 5
*****

At 1 second the audio (track: Dolby Atmos) plays, but interrupts and resumes for a very brief moment, I would say 250 ms more or less, however you can hear clearly (no question about this) that there is a dropout (the technical term for this), because it's as if at this very brief moment the audio was interrupted and then resumed at the same time.

This video shows exactly what happened with this file (part 4 of 5, splitted by MKVToolnix):

https://www.youtube.com/watch?v=lbgz2vVxHow

Audio drop out can occur at any time during the playback of a file and can be as short as a frame and up to multiple seconds or minutes. The result is either the back ground music is only heard or the audio goes completely silent while the video is still progressing without issue.

Of course I tried playing all other audio tracks to see if (still in MPC) this would happen.

Track 2 is named as Dolby Digital 5.1. Track 3 as DTS-HD MA 5.1, track 4 as DTS 5.1.

None of them showed audio dropout. Only this DOLBY ATMOS.

Again: this has not happened in the original HUGE file, before the splitting.

*****
Then, not satisfied, I tried playing this part 4 of 5 in another player: VLC.

This is what is reaaaaaaaaaaaaally odd: VLC while playing the track Dolby Atmos HAS NO AUDIO DROPOUT!!!!!!!!!!

And opening the original HUGE file everything fine at 1 hour and 9 minutes.

*********
So, I had another idea: why not block ffdshow audio processor from MPC... and try with LAV instead?

What was the result?

No change! Audio dropout still there in file 4 of 5!!!!!!!!!!!!

Meaning only MPC had a problem with this.

********

OK, so how do I know this is MKVToolnix's fault?

Another great idea: why not... open file "3 of 5" (splitted from the original HUGE) in MKVToolnix... and append with part 4?

That way we have files 3 + 4 (of all 5 parts), and we can go directly to the scene with this drppout, however without this dropout happening 1 second after the file starts.

FILES 3 + 4 appended = 29 GB (original file has 73 GB).

The moment the scene with the issue starts in 3+4 is after 22 minutes and 55 seconds.

*********
What happened there? And please note this is using LAV, not ffdshow audio processor:

1) At 23m01s the video FROZE. That's right: THE IMAGE JUST FROZE!!!!!!!!!!!!! Audio was still playing. After 4 seconds the video resumed.

2) At 23m02s the audio was MUTED. This was not a dropout: video frozen, no audio. Only at 23m06s the audio could be heard again.

3) And that's not all! Even though audio resumed at 23m06s, we had a dropout at this precise moment and at 23m07s the audio resumed, and from now on no more problems.

If I select any other audio track, such as #2 DD 5.1, #3 DTS-HD MA... it will have the same issue. The only difference is that I believe there will be no audio dropout, however at 23m07s when the audio resumes, we can hear right before, and this is veeeeeeery brief, a harsh sound that is heard when a radio transmission had been interrupted badly and is now being reestablished.

******
More tests: turning ffdshow audio processor ON again in MPC.

No change. And I believe 2 audio dropouts during these seconds, 23m02 and 23m07s.

What about VLC? (note: same result with ALL tracks)

At 23m 0 seconds: video frozen, audio muted. 23m04s video resumed. 23m05s audio resumed. I don't think I heard a dropout, only a technical sound of the audio signal being restablished from a dropout.

*******
Bottom line and to sum everything up:

- Original file is fine;
- After splitting into 5 parts, part 4 of 5 had audio dropout after 1 second of playback;
- After appending parts 3 and 4, not only the audio dropout remained there, we now had 4 seconds of lost content, video frozen and audio muted.

What is going on here?

I never had a similar issue with MKVToolnix. And I have been appending and splitting files FOR YEARS.

As you can see this can't be the Dolby Atmos fault, because the video freezing at this scene indicates a problem splitting and appending only in this moment of the movie.

If you play the original HUGE file and there is nothing wrong with it, then what's the explanation?

P.S. This is MEDIAINFO for part 4 of 5:

https://pastebin.com/JKQG7YFG

And this is MEDIAINFO for parts 3 + 4 appended:

https://pastebin.com/41BY7NK3

[hubblec4]

I believe the issue is "splitting and appending".

I had used it also for a long time, and mostly it works but for some mkv's not and in such a case I decided me not to split the file. (preserve entire content)

After splitting you have at the end of the split files often audio data with bigger timestamps as the video.
I'm sure each split file plays fine.
But when you append the files this will produce gaps for the video.

I suggest you use a binary file splitter like hSplit.
Only with this you have after splitting and joining a bit identical file and therefor no playing issues.

[Perenista]

OK, I think I figured out what went wrong here. And if that's the case then this isn't MKVToolnix's fault, it's just that MKVToolnix makes the problem evident, when there's something fishy going on.

- While playing the original disc everything looks fine in both MPC and VLC.
- After using MAKEMKV to convert into Matroska, we have this huge file, that has 73 GB.

- I said this HUGE file had no problems. But that isn't true, sadly. However while playing in MPC and VLC you don't notice if you are not looking with more attention. After this scene (no freezing or audio dropout where I said) a few seconds later there's a very quick audio dropout in MPC, and not in VLC.

But (and this is where things get interesting) VLC compensates for the late audio dropout by not letting the movie run smoothly and SKIPPING FRAMES!

In other words, the video accelerates in less than a second to the next frame to not let me notice the audio dropout in VLC (yet I could spot after looking carefully!), and this doesn't happen in MPC.

What everything I said indicates?

- That the original disc was defective in this area from the movie, after 1 hour....
- Perhaps it only affected this specific scene;
- Or (another possibility) this is MAKEMKV's fault. When MAKEMKV tried to save the disc as MKV, maybe it did something wrong.

Maybe AV synchronization issues due to a bad disc (scratched...) or a problem created by the distributor while handling the DISC, which warrants a RECALL.

There's just one thing: that huge file (MKV) had already been handled by MKVToolnix, since I inserted additional tracks in it. So this was not the original file MAKEMKV had created.

Meaning this could still be MKVTOOLNIX's fault. I am not seeing how because no errors were reported by it.

To figure out the answers once and for all, this is what I am going to do:

- Delete everything already created and go back to the original disc.
- Use MAKEMKV again to create another file.
- Inspect this file and if everything is OK, then use MKVTOOLNIX to edit again.

I'll post the results later, and this is the only way to be sure the disc was indeed defective, I don't believe my SSD drive is and a bad block affected this part of the file.

This is very bad because it is a silent issue that someone may never notice until it inspects the file.

Of course it would be expected from us users to not look into 100% of the files/contents we edit in all these softwares, right after. Even worse is the fact in the original disc everything looks fine, no dropout or skipped frames.

[sneaker_ger]

So, I had another idea: why not block ffdshow audio processor from MPC... and try with LAV instead?

What was the result?

No change! Audio dropout still there in file 4 of 5!!!!!!!!!!!!
Are you using software decoding or bitstreaming for the audio?

[Perenista]

Are you using software decoding or bitstreaming for the audio?MAKEMKV with the original UHD/4K disc. When you run MAKEMKV you save as MKV and before that you only see this:

https://i.postimg.cc/J0pF2MrD/XXAs.png

Unfortunately this is either a MAKEMKV bug or a defective disc.

This is now 100% confirmed, because when I opened the disc again, and saved, I saw this warning:

https://i.postimg.cc/wMXPcLPV/XXA.png

When I looked into this thread: https://www.makemkv.com/forum/viewtopic.php?t=21079

People were saying this was an innocuous warning. It turns out it isn't!

And this content HAS Dolby Atmos, too. So this is not a coincidence.

Either the media is defective (and I have no reason to believe that) or MAKEMKV is not handling these discs properly. Either way, this was NOT caused by MKVTOOLNIX. Splitting and appending had no bearing in what happened. I'll now check my options and report this to them, too.

P.S. I said in the MakeMKV thread this is a bug from MakeMKV + the fact we are including the Dolby Atmos track. Once we leave the Atmos track out, nothing happens:
https://www.makemkv.com/forum/viewtopic.php?p=99292#p99292

It took me the entire day to figure that out. I'll leave this track outside my file until they fix this bug.

[DragonQ]

Does anyone know of a media player that actually supports MKV's cropping flags? I can set the flags using MKVToolNix GUI and MediaInfo shows the cropped dimensions correctly, but every single player I've tried ignores the flags: Kodi, MPC-HC, VLC. :(

[butterw2]

h264/hevc bitstream crop modification with ffmpeg works ok in most software players (tested in mp4).

https://forum.videohelp.com/threads/398507-Top10-Commands-for-Lossless-Video-manipulation-using-ffmpeg-(Guide)#post2592742

[Aleksoid1978]

Does anyone know of a media player that actually supports MKV's cropping flags? I can set the flags using MKVToolNix GUI and MediaInfo shows the cropped dimensions correctly, but every single player I've tried ignores the flags: Kodi, MPC-HC, VLC. :(

MPC-BE(with internal filters) support.

[DragonQ]

MPC-BE(with internal filters) support.
So it does. Shame it doesn't support madVR out of the box, but I guess that's proof that it does work when properly implemented. It's rather annoying that most players haven't implemented it yet despite some rather old feature tickets being open!

h264/hevc bitstream crop modification with ffmpeg works ok in most software players (tested in mp4).

https://forum.videohelp.com/threads/398507-Top10-Commands-for-Lossless-Video-manipulation-using-ffmpeg-(Guide)#post2592742
This looks promising. Unfortunately, it doesn't seem to work for me. I'm trying to crop a 4:3 1920x1080 video to 1440x1080 and have confirmed that the exact centre 1440 columns contain video data and the rest are black. The following should work:

ffmpeg -i "original.mkv" -codec copy -bsf:v h264_metadata=crop_left=240:crop_right=240 -aspect 1440:1080 "test.mkv"

However, for some reason when I play the resulting video, there's about 48 pixels of black on the left side and 48 pixels of video missing from the right side, as if the crop isn't happening in the centre as it should. This happens when playing the test file in MPC-HC with EVR or madVR, and MPC-BE. Also, madVR thinks "100% zoom" is now 1488x1166 for some reason.

I also tried extracting the h264 stream and running that through ffmpeg, then remuxing to MKV. Same issue. I also tried outputting to .mp4...same issue. Tried using both ffmpeg 4.2.4 & 4.3.1. Maybe it's because the video is interlaced? I've uploaded a 10s sample here (https://dragonq.uk/files/original_10s.mkv) in case anyone else wants to try. :)

EDIT: Never mind, it works fine but only when cropping in multiples of 64. The closest crop I can get is:

ffmpeg -i "original.mkv" -codec copy -bsf:v h264_metadata=crop_left=192:crop_right=192 -aspect 1536:1080 "test.mkv"
And with ITU601 aspect ratio correction:
ffmpeg -i "original.mkv" -codec copy -bsf:v h264_metadata=crop_left=192:crop_right=192 -aspect 1575:1080 "test.mkv"

These play correctly in MPC-HC + madVR but not in Kodi on Windows or on my CoreELEC box, sadly. In both cases, Kodi squishes the video far too much. It looks like it might be applying the aspect ratio before the crop, rather than afterwards.

[butterw2]

I'll have to revisit this.

The cropping part is well supported I think, the issue is that it can mess up the AR when played. I don't know if there is a solution.

Landscape top and bottom mod-8 crops may be better supported.

[olli66]

Hi you fine people. I have a muxing problem. I downloaded a video from the web which has lossy audio. I used a sound editor to make a new audio stream (source is from a lossless 24bit 96khz recording) which is absolutely in sync with the original audio file which I demuxed. I then remuxed the video and the new audio but the sync is way off. I synced many of concerts and replaced plenty of audio streams but this time the procedure is not working. I am encountering the same problem with two concerts. What could be the issue? It is the first time I try this approach. Usually I use Adobe Encore to make a blu-ray but now the videos are 4k and I decided to go for a file version and not alter the video source.

[filler56789]

Hi you fine people. I have a muxing problem. I downloaded a video from the web which has lossy audio. I used a sound editor to make a new audio stream (source is from a lossless 24bit 96khz recording) which is absolutely in sync with the original audio file which I demuxed. I then remuxed the video and the new audio but the sync is way off. I synced many of concerts and replaced plenty of audio streams but this time the procedure is not working. I am encountering the same problem with two concerts. What could be the issue? It is the first time I try this approach. Usually I use Adobe Encore to make a blu-ray but now the videos are 4k and I decided to go for a file version and not alter the video source.

Without details it will be difficult to give a good answer...
or even a good guess :-/
The sync problem might be caused by the video streams and not by the new audios...
MediaInfo reports and/or sample files would help.

[olli66]

thanks! how I can I make a sample? the files are huge.
when I put the demuxed video on a adobe premiere timeline along with the new audio stream I created, it is perfectly in sync, just not when I mux it with mkvmerge or tsmuxer...

Without details it will be difficult to give a good answer...
or even a good guess :-/
The sync problem might be caused by the video streams and not by the new audios...
MediaInfo reports and/or sample files would help.

[tebasuna51]

...I downloaded a video from the web...
The rule 6 of this forum
6) No warez, cracks, serials or illegally obtained copyrighted content! Links to content of a questionable nature (e.g. anything you don't own and/or have downloaded), asking for, offering, or asking for help/helping to process such content in any way or form is not tolerated.

prevent us to help you with this question. Please read the rules.

[olli66]

Well, I thought since I bought and owned both music videos and the one has lossy sound but high res audio and the other one is only 1080p but has lossless audio I have the right to do with these files as I please and "exchange" the audio streams. So, OK, I will not even upload a sample´

The rule 6 of this forum


prevent us to help you with this question. Please read the rules.

[Perenista]

I was asked in the MAKEMKV forum to do this command to investigate the issues with my MKV files:

mkvinfo -C optionA.mkv > optionA.txt

The problem is that the TXT files created are using MY LANGUAGE (portuguese). How do I change this to english?

[sneaker_ger]

--ui-language en

[mariner]

DV support
Greetings.
Can anyone kindly advise if DV streams (single layer profile 5 and 8) is supported by mkv?
When muxed into mkv, mediainfo did not report any DV related info.
Or is it a mediainfo issue?
Many thanks and best regards,

[Thunderbolt8]

is there a way to reset default settings? I somehow messed up the order of tabs in the tracks, chapters and tags window and would like to reset this.

[Mosu]

is there a way to reset default settings? I somehow messed up the order of tabs in the tracks, chapters and tags window and would like to reset this.

Just delete the mkvtoolnix-gui.ini settings file (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Location-of-settings,-job-queue,-cache-folder) while the GUI isn't running.

[Thunderbolt8]

thanks :)
just the question why did you actually call the folder in appdata bunkus.org and not mkvtoolnix? because I intuitively looked for the latter one and couldnt find anything ;)

[Mosu]

That's how Qt names folders when using the QSettings class: after the application's organization name (https://doc.qt.io/qt-5/qcoreapplication.html#organizationName-prop). And back when I started I considered myself to be the organization as the only developer…

[mariner]

DV support
Greetings.
Can anyone kindly advise if DV streams (single layer profile 5 and 8) is supported by mkv?
When muxed into mkv, mediainfo did not report any DV related info.
Or is it a mediainfo issue?
Many thanks and best regards,

Is this resolved in the new release?

[quietvoid]

Most things Dolby Vision are tracked in this issue: https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2784
So, no it is not.
Currently you would have to remux using MakeMKV.

[Perenista]

Since MKVTOOLNIX is not accepting splitting FLACs or appending them, I was forced to download an old version for that, because I still had a bunch of files with FLACs in both situations, a few that were splitted already and some I need to split again, after further edits using MKVTOOLNIX.

So if I wanted to keep the audio track in lossless (original source is FLAC) but in another audio coding format, what should I do?

I mean, once I append the files again (EDIT: did that a few minutes ago) I am going to extract the FLACs and convert them into another format that recent MKVTOOLNIX versions accept.

But the only requirement is to not lose any quality, so it must be other audio format that is also lossless, and one that is not recognized by 1% of devices.

Any ideas? And what would be the best software for this task?

Note: MKVTOOLNIX changed its policy on splitting FLACs for these reasons:
https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Appending-&-splitting-FLAC-audio-tracks-not-supported

I realize that, but my problem is that I can't simply ditch my files, and for some I had to append/join their multiple parts. That's because they were splitted into 15 GB pieces to fit free Google Drive accounts.

[mkver]

The good thing about lossless codecs is that reencoding does not incur a degradation in quality. So you can decode the audio, append the raw (PCM) audio and reencode the parts that you need (to FLAC) and add it to the other (already properly splitted) tracks.
Of course, you can also just keep the raw audio; it just takes more space. WavPack would be yet another option, but it is not as widely supported as FLAC.

[Mosu]

MKVToolNix supports the following lossless formats (in alphabetical order): ALAC (Apple Lossless Audio Codec), DTS-HD MA (DTS-HD Master Audio), FLAC (Free Lossless Audio Codec), uncompressed PCM, Dolby TrueHD, TTA (True Audio) and WavPack. Of those only FLAC poses problems wrt. appending & splitting. Of those the most widely supported formats are probably DTS-HD MA & TrueHD, especially TrueHD, as that is a requirement for Blu-ray support.

BTW, the FAQ entry you linked to also mentions how to disable those checks with v47 or newer so that you don't have to use an older version.

[Perenista]

I commented about this bug from MAKEMKV a while ago and this is better explained in these threads:

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

https://makemkv.com/forum/viewtopic.php?f=8&t=21079

Without reading both threads you are not going to understand what's going on with UHD rips and MAKEMKV (which I am going to comment below).

Well, here's the thing. In my last post from the 1st thread (see above) I said it's MKVTOOLNIX in fact the software that is evidencing the bug.

What do I mean by that? I meant that MKVTOOLNIX doesn't have a problem (neither is creating one), only making them clear to us as if the defect was there, hidden in total darkness and MKVTOOLNIX was turning on the light.

When the file is not splitted into these 15 GB parts, I am not seeing audio dropouts which for some odd reason always appear in file/part 4 at the first seconds of it.

>>>>>>>>>>>>>>>>>>>>>>

It happened with BTTF part 1 (1985 movie) from Universal, and today I saw it happening for a very brief moment with Karate Kid (1984), both these UHD/4K discs, both only happening with the Atmos track, and they are from different distributors (KK is from Sony).

>>>>>>>>>>>>>>>>

Even if MAKEMKV is very likely messing with the Atmos tracks, I can't stop thinking (when I create all these splitted parts) if MKVTOOLNIX isn't doing something else, too. Failing to do the job properly.

<<<<<<<<<<<<<<<<<<<<

Because it's very, veeeeeeeeeeeery strange that you can only notice audio dropout once the movie is splitted into multiple 15 GB MKV parts.

What matters if I split something or not? Splitted is no different from reconstructed, appending all parts together. Both processes are lossless. The splitted files are not something else entirely.


>>>>>>>>>>
So what we see when the file has 64 GB should be no different... from when it is divided into 15 GB parts.

Unless you are going to tell me SPLITTING damages Atmos tracks and should never be done.

>>>>>>>>>>>>>

If that's the case, then MKVTOOLNIX needs to treat Atmos tracks the same way as it is now with FLACs.

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

Mosu: could you tell me if there's something unique to Atmos tracks that make them break when splitting?

And causing these audio dropouts for the first seconds of file/part 4?

If I switch to the DD 5.1 derived from the Atmos the audio dropout will not be there, in this part 4.


>>>>>>>>>>>>
So far this problem (which is not a small one) has not been fixed by MAKEMKV developers. Until this is fixed I can't rely on the rips I create from my discs anymore. It would take me ages to inspect all these files and their audio streams. Besides, there are some people saying sometimes the A/V SYNC ISSUE warning means nothing.

[2-perf]

MKV muxed with PCM 1.0 Mono file using MKVToolNix v51.0.0 won't load in eac3to.

[Mosu]

After three months of not being motivated to spend a significant amount of time on coding outside of work, I finally found some of that motivation again. The result is release v52.0.0 of MKVToolNix. It contains a couple of enhancements to the GUI and one bug fix in libEBML that's security-sensitive.

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 52.0.0 "Secret For The Mad" 2021-01-04
New features and enhancements

MKVToolNix GUI: job queue: the maximum number of jobs to run concurrently can now be increased in the preferences. The default remains at 1. Implements #2984 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2984).
MKVToolNix GUI: the GUI will now add a context-specific default extension to file names selected for saving on platforms that don't add one itself (e.g. GNOME). For example, when saving multiplexer settings the extension ".mtxcfg" will be added. Implements #2983 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2983).
MKVToolNix GUI: added an option to the preferences for the window to stay on top of other windows. Implements #2967 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2967).

Bug fixes

mkvextract: h.265/HEVC extraction: the code for skipping extraction of prefix SEI NALUs in the first frame was skipping two bytes too few, resulting in broken processing of all following bytes. Patch by Mike Chen.
libEBML: the optional, bundled version of libEBML was updated to v1.4.1.

Build system changes

libEBML v1.4.1 is now required due to a bug in libEBML that caused pointers to just-freed memory being returned to the caller under certain invalid data constellations, causing use-after-free errors in all of MKVToolNix's programs. Fixes #2989 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2989).


Have fun :)

[hubblec4]

Thank you again for all your work.

[VBB]

Thanks as always!

[DragonQ]

I have extracted some 2ch PCM tracks from a few MKVs I have and encoded them into DTS-HD MA tracks using DTS Encoder Suite. Does anyone know if it's still necessary to apply a -21ms delay to these DTS-HD MA tracks when remuxing? I can find people mentioning this in various forums but not that recently and just wanted to check if it's something mkvmerge would do automatically these days. Thanks.

[Mosu]

mkvmerge does not add arbitrary delays based on codec types. All it does is reusing existing timestamps of source containers if those source containers provide them. Raw DTS files (elementary streams? whatever those might be called) do not; therefore for DTS tracks read from raw DTS files the timestamps will always start at 0.

[bruno321]

I've an mkv with the following mediainfo:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 9 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 9 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 15 min
Bit rate : 1 457 kb/s
Width : 696 pixels
Height : 532 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.157
Stream size : 783 MiB (92%)
Writing library : x264 core 161 r3018 db0d417
Encoding settings : cabac=1 / ref=9 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=11 / psy=1 / psy_rd=1.00:0.03 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=150 / rc=crf / mbtree=0 / crf=17.7 / qcomp=0.65 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=62500 / vbv_bufsize=78125 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / pb_ratio=1.30 / aq=2:1.00
Default : Yes
Forced : No

I used mkvtoolnix's "split after specific timestamps", which got me two files. The first part has a similar mediainfo. The second, however, has this:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 9 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 9 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 14 min
Bit rate : 1 461 kb/s
Width : 696 pixels
Height : 532 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.158
Stream size : 780 MiB (92%)
Default : Yes
Forced : No

Notably, the Writing library and the Encoding settings are gone. Why is that? Is this expected behavior, or a bug I should report somewhere?

[hubblec4]

Splitting and appending mkv files, are features which currently not work 100%.
If you do that then you have to life with issues.

[sneaker_ger]

It's not really a problem. The custom SEI x264 writes with settings is in the beginning of the stream so it ends up in the first part only. That SEI is totally optional and not needed.

[bruno321]

I don't know what SEI means, but I can say that I'd appreciate it if those lines made it to every one of the split pieces.

[stax76]

Why is that? Is this expected behavior, or a bug I should report somewhere?

It's probably a missing feature and not a bug.

[bruno321]

Thanks, stax. I wrote about it and it got swiftly closed, the developer doesn't intend to work on such a feature. https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2994

[Boulder]

Using mkvalidator on files with a Dolby Atmos track takes a very long time to finish. Is this something that cannot be helped? I also noticed that the process uses quite a lot of memory if the file is big, like almost 4GB for a 15GB Matroska file.

[Mosu]

mkvalidator is not part of MKVToolNix, nor am I its author. Therefore I cannot say anything about it.

[stax76]

@bruno321

It can be achieved via simple script however:

1. Read tag data, very easy with Get-MediaInfo (https://github.com/stax76/Get-MediaInfo) for instance
2. Create tag file
3. Re-mux

[Perenista]

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