MKVToolNix v83.0 released

[Mosu]

Originally Posted by Atak_Snajpera

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 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
2. Here Strings
3. Arrays
4. Hash Tables

In mpv(.net):

--include=<conf file>

[Mosu]

Originally Posted by stax76

It's not listed under special characters 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.

Originally Posted by stax76

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.

Originally Posted by Atak_Snajpera

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]

Originally Posted by Atak_Snajpera

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:



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]

Originally Posted by Perenista

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]

Originally Posted by sneaker_ger

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:



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/viewto...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/...e)#post2592742

[Aleksoid1978]

Originally Posted by 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.

MPC-BE(with internal filters) support.

[DragonQ]

Originally Posted by Aleksoid1978

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!

Originally Posted by butterw2

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

https://forum.videohelp.com/threads/...e)#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 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]

Originally Posted by 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.

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

Originally Posted by filler56789

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]

Originally Posted by olli66

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