MKVToolNix v24.0.0 released

[shinchiro]

How could I make mkvmerge show attachment's name in japanese or chinese when using -i option?

[Mosu]

My guess is that you're referring to the fact that the output of Unicode characters on Windows' cmd.exe is buggy. That's handled (and fixed) in ticket 971. You have two options:

1. Download and use the new build mentioned in that ticket.
2. Redirect mkvmerge's output to a text file with the following two options:

   --redirect-output output.txt --output-charset UTF-8

Option 2 has the advantage of working with versions going back years.

[cihub]

I'm not sure whether this question have been asked previously, but how do you leave info about "Bits/(Pixel*Frame)" in Matroska after remuxing (MKVToolNix 6.5.0, 6.7.0)? When I mux H.264 from x264 and add AAC-HE, it gets stripped, but when I mux only video, or AC3, it stays there.

[Mosu]

You cannot. There's no header information for this.

What you see is MediaInfo estimating the bitrate based on the track size. However, MediaInfo can only do that if there's only a single track inside that file because in Matroska there's no header info about the track size either.

Therefore: Only one track -> MediaInfo uses the file size as an approximation for the track size -> MediaInfo calculates estimated bitrate based on the file's duration and the file's size.

[cihub]

Thank you for explanation, Mosu.

[shinchiro]

Originally Posted by Mosu

My guess is that you're referring to the fact that the output of Unicode characters on Windows' cmd.exe is buggy. That's handled (and fixed) in ticket 971. You have two options:

1. Download and use the new build mentioned in that ticket.
2. Redirect mkvmerge's output to a text file with the following two options:

   --redirect-output output.txt --output-charset UTF-8

Option 2 has the advantage of working with versions going back years.

Thanks, Mosu. That's great. Tried with option 1 but it look like the japanese character turn to '???' so I used option 2 and it worked

[Sakura-chan]

Hi

Is there some sort of compression in Matroska for MPEG2 streams?

I've seen this happen with certain discs. The story goes like this. I have a DVD, 6.37 GB in size. I use MakeMKV on the main feature, the resulting MKV is 5.18 GB. It has an MPEG2 and an AC3 track. Then, because I want to add English subs, I remux that MKV and the subs with mkvtoolnix v6.6.0. But now the resulting MKV is only 3.93 GB.

What is going on? The bitrate of the movie is decreased, but everything is there. mkvmerge doesn't re-encode anything. I guess there must be some compression going on. But how can it be so strong to cut 1.25 GB of the MPEG2 track? Is there some kind of "garbage" or useless data in the frames of the MPEG2 stream?

Why MakeMKV's resulting file has a "logical" filesize given the source and mkvmerge remux is a lot smaller?

Extracting the MPEG2 tracks from both big and small MKVs results in .mpg files with sizes according to the original MKVs. So the stream doesn't go back to the original size. mkvmerge simple discards something in the mux.


This doesn't happen always. Or probably I haven't noticed before because I didn't stop to check the sizes of the MKVs. For now I've seen this with 3 PAL DVDs (French editions of Hideo Gosha's films). I made MKVs of other DVDs and didn't observe this drastic size reduction, just a little as always when making MKVs from DVDs.

Here's the info of the video tracks of both MKVs.

Original:

Video #1
ID : 1
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : No
Format settings, Matrix : Custom
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 1h 32mn
Bit rate mode : Variable
Bit rate : 7 703 Kbps
Maximum bit rate : 8 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.743
Time code of first frame : 10:00:00:00
Time code source : Group of pictures header
Stream size : 4.96 GiB (96%)
Language : English
Default : No
Forced : No


Remuxed:

Video #1
ID : 1
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : No
Format settings, Matrix : Custom
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 1h 32mn
Bit rate mode : Variable
Bit rate : 5 808 Kbps
Maximum bit rate : 8 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.560
Time code of first frame : 10:00:00:00
Time code source : Group of pictures header
Stream size : 3.74 GiB (95%)
Default : Yes
Forced : No


All in all, another great reason to store/backup movies in MKV, that's a nice (and lossless) file size cut :P

[Mangix]

I believe avi files are broken with mmg 64-bit under windows. I switched to the 32-bit version and could remux an avi file without running into error code 3.

[Mosu]

Originally Posted by shinchiro

Thanks, Mosu. That's great. Tried with option 1 but it look like the japanese character turn to '???' so I used option 2 and it worked

Then your Windows version lacks support for Asian languages, or your cmd.exe uses a font that lacks those characters.

[Mosu]

Originally Posted by Mangix

I believe avi files are broken with mmg 64-bit under windows. I switched to the 32-bit version and could remux an avi file without running into error code 3.

Known and fixed. See https://trac.bunkus.org/wiki/Troubleshooting.

[Mosu]

Originally Posted by Sakura-chan

Hi

Is there some sort of compression in Matroska for MPEG2 streams?

No. What you're most likely seeing is mkvmerge removing filler data. Various MPEG-based formats require certain storage (on a DVD) to have a minimum bitrate. Filler data is therefore inserted in order to achieve that minimum. This filler data is not required for decoding, it is complete garbage from the point of view of the decoding process. A decoder skips that data.

mkvmerge simply removes it. A Matroska file does not have a minimum bitrate.

Note that the actual video bitrate is unaffected by this removal. The video bitrate is the number of bits the actual encoded pictures use. That filler data only affects the whole stream's bitrate, which is highly misleading. If you have a video stream at 2Mbit/s then the quality will not be improved one iota by packaging it as a stream with a stream bitrate of 4Mbit/s.

[hello_hello]

I'm not sure when it happened.... I think I skipped a version or two and went from 6.4 to 6.7..... but I just wanted to say thanks. MKVMergeGUI no longer opens at a snail's pace running on my quad core PC. It used to take at least twice as long to open as it did running on my dual core. Now it opens nice and quickly regardless of the CPU. Sometimes, it's the little things.....

Thanks! (32 bit version, XP)

[Nexin]

Mosu using MKVmerge recently for splitting and audio image with added cue sheet.

MKVmerge
drop audio file - Mux to mka file - Remove audio file
Drop new muxed mka file - add cue file to it - close MKVmerge (To remove all cue file info, as there is no remove all here. Would be nice to have the option to do this with need to restart MKVmerge.)
Open MKVmerge - drop newer mka file and select Global then Splitting Mode

This is where I become stuck what to add for Split Parts By Timecodes which I guess will be the most exact way to split perfectly on INDEX 00:03:54 (now chapters). I have tried many ways yet unable to get it to split.

I have a suggestion wouldit be possible for MKVmerge to parse an mka file on load so automatically knows each chapter (from the now embedded cue file in mka). So when using Splitting and other MKVmerge features we see instead a list and able to select what chapters we like to be split and output.

I did get MKVmerge to work but it fails for what I needed as I though it would from the splitting name. I used the following..
Split Before Chapters
All
# [# of tracks to split]

As can guess the track splits weren't perfectly correct and erased those split files.

If you can see a way to make MKVmerge better to automatically parse each file or highlighted file on Input screen (after you implement this do tell if we need to highlight file in the upper or lower panel on Input for file to auto chapter parse)


Also the MKVmerge gui doesn't keep its screen position on restart. This is even with GUI maximise window set. With each new MKVmerge start the GUI has moved nearly all off the monitor screen
(1 gfx screen and 1 hardware monitor setup using xp3)

[hello_hello]

Originally Posted by Nexin

MKVmerge
drop audio file - Mux to mka file - Remove audio file
Drop new muxed mka file - add cue file to it - close MKVmerge (To remove all cue file info, as there is no remove all here. Would be nice to have the option to do this with need to restart MKVmerge.)
Open MKVmerge - drop newer mka file and select Global then Splitting Mode

The File/New menu doesn't open a new file or a new instance of MKVMergeGUI as I'd originally assumed it would. It clears everything.
At one stage I requested a "New" button be added to the bottom of the window. Maybe replacing the "copy to clipboard" button, which I suspect would be a likely winner if ever entered into a "least often used GUI button" competition. Or maybe that's just me. A "manage jobs" button next to "add jobs" button might be handy too.

Originally Posted by Nexin

I did get MKVmerge to work but it fails for what I needed as I though it would from the splitting name. I used the following..
Split Before Chapters
All
# [# of tracks to split]

As can guess the track splits weren't perfectly correct and erased those split files.

I've not split files by chapters before so after reading your post I gave it a spin after muxing a multitrack flac file into an MKA, then again using multitrack MP3. Each time I included the corresponding cue file.
After muxing, opening the muxed file and splitting before chapter (all), the output files all contained a single chapter with a timecode of 00:00:00.000, so for me MKVMergeGUI split exactly at each chapter.
I'm using version 6.7.0 and XP.

[hello_hello]

MKVMergeGUI has an option to automatically use any audio delay included in the file's name if the delay amount follows the word "delay". For those who aren't aware it can do so, an example file name would be (as extracted by DGIndex):
"Audio T81 2_0ch 224Kbps DELAY 32ms"

Feature request:
When audio is extracted from an MKV using MKVCleaver, it looks something like this (it doesn't write the delay value):
Audio_Track01(EN).mp3
MKVExtractGUI does it like this (no audio delay written either)
Audio_track2_eng.mp3
MeGUI extracts the audio this way:
audio - [0] English 16ms
Although after requesting it be changed, Zather informed me the next MeGUI version would write the file names in a more MKVMergeGUI friendly manner.
audio - [0] English Delay 16ms

Given most programs write the language name (or two letter code) to the extracted audio, would it be possible for a future version of MKVMergeGUI to automatically apply the specified language when adding tracks? The same way it automatically applies the correct delay? MeGUI's muxers understand the format MeGUI uses for languages in file names and automatically applies them, so I'd assume it's not impossible. MKVMergeGUI already does so when opening MKVs if the streams within have a specified language and/or delay.

If the developers of the above software (and MKVMergeGUI) would care to get together one day, have a few drinks, tell a few jokes at the expense of other software developers, then settle down to the task of deciding on a common naming format each program will use when extracting, I'll buy the first couple of rounds.

[Mosu]

Originally Posted by Nexin

Mosu using MKVmerge recently for splitting and audio image with added cue sheet.

This works as intended, just like hello_hello has written. Keep in mind that mkvmerge can only split before I frames, not at arbitrary positions (even though you can enter arbitrary timestamps). See the documentation.

To remove all cue file info, as there is no remove all here. Would be nice to have the option to do this with need to restart MKVmerge.

Use »File« -> »New«, that's what the function is there for: to start over as if you had re-started mmg. The »Remove all« button is intentionally different and keeps the content of a lot of controls in order to facilitate muxing several sets of files, e.g. several episodes of a series where you keep certain central things, one after each other.

I have a suggestion…

I'm in the middle of re-writing the GUI with a different toolkit (Qt instead of wxWidgets). Therefore the old GUI has reached its end of life; I won't spend any more time on it. I also don't accept feature requests for the new GUI yet.

[Mosu]

Originally Posted by hello_hello

Given most programs write the language name (or two letter code) to the extracted audio…

No, and not for the reason that I'm currently re-writing the GUI. Read this FAQ entry I've written about this very topic.

[hello_hello]

Originally Posted by Mosu

No, and not for the reason that I'm currently re-writing the GUI. Read this FAQ entry I've written about this very topic.

That's disappointing..... and to be honest I'm not sure any of the reasons listed would necessarily be show stoppers. If I may....

If I wanted to detect full language names (e.g. "English") then how should Johnny English.srt or, even worse, The French Connection.srt be handled?
If I wanted to detect full language names it would be restricted to their English representations. But what if the file name contains a localized language name? In the following example the language would be "English" again, but the whole file name is in French: Le fabuleux destin d'Amélie Poulain (Anglais).srt
So we're back to short ISO-689 codes. Even if I only try to detect them at word boundaries there's a huge problem as some of those three-letter codes are actual words in certain languages. Let's take Le juge est une femme.srt Here est is the language code for Estonian.

MeGUI's muxers have used the language written to extracted streams for as long as I can remember. I tested it by changing the file name to a language like this:

Audio - [0] English 16ms
French - [0] English 16ms

Disappointingly it used English the first time and French the second, so it's not particularly clever. I'd be willing to bet the number of complaints regarding this behaviour in the MeGUI threads would be somewhere in the vicinity of none. Having said that.....

The word "Delay" preceding the delay value in the file name has been the secret handshake for applying a delay for as long as I can remember, yet file names can also contain numbers. Surely a similar secret handshake could be used for applying language names? A two/three letter code following, or surrounded by, characters which aren't likely to be otherwise combined in the same way?

Audio -[[En]]- Delay 16ms

I'd imagine you'd need set the standard.... be the one who decides on on the appropriate secret handshakes for MKVMerge, while the developers of encoder GUIs and extraction utilities etc would need to make their programs MKVMergeGUI friendly. If there's ever going to be a standard for this sort of thing, it's got to start somewhere.

Originally Posted by Mosu

Another problem occurs with files that can contain multiple tracks. Let's take Life of Brian (FRE).mkv as an example. What if there's one audio track and one subtitle track in that file? Which of those would FRE refer to?

Neither. Mostly, it's after extracting streams from their original containers it'd be handy to have languages and audio delays written to file names and automatically applied. Doing the same at the container level doesn't seem as important to me.
While I hadn't envisaged it, if a container contains more than one track, any language written to the file name would probably be best ignored. It's ignored currently so nothing would change there. If a container contains more than one stream, I'd expect the language specified for the streams to be applied as it currently is.
Maybe if a container only contains a single stream the language in the file name could be applied, but if the stream itself has a set language I'd probably expect it to take precedence. Or maybe in such a situation they could both be ignored... Whatever happens, the user would get used to the way it works.

Originally Posted by Mosu

The next problem is that detecting the language code is one thing. Making the user aware that mmg has tried to detect such a code is another matter entirely. If the language drop-down box is simply set accordingly then the user will only realize this if he clicks on all added tracks in turn. But he has to do that because it's such a frail mechanism that he has to verify the results.

When streams or files are opened by MKVMergeGUI for muxing, each stream is listed in the tracks section. Changing the text color of a stream which has been subjected to an automatic application of settings.... as long as the user is given some sort of "hey, something happened and you might want to check it warning".....
Mind you when currently opening an existing MKV I'd imagine most people know the individual tracks need to be checked unless they're confident they were set correctly in the first place.... sometimes you just need to check.
Even if the "general track options" area contained a single "default" button which for the selected track would automatically apply a particular language, default and forced track setting according to the users preference, it would probably reduce the need for clicking, scrolling and selecting by a considerable amount.

Anyway.... thanks for all the hard work on MKVToolNix. It's appreciated!

[Mosu]

You may, but you won't change my mind, and I can live perfectly fine with your disappointment. I'm also pretty sure that the amount of time such a feature would have saved you doesn't even equal the time you've spent writing this post.

[Nexin]

Originally Posted by Nexin

Mosu using MKVmerge recently for splitting and audio image with added cue sheet.

Originally Posted by Mosu

This works as intended, just like hello_hello has written. Keep in mind that mkvmerge can only split before I frames, not at arbitrary positions (even though you can enter arbitrary timestamps). See the documentation.

Working with audio only with MKVmerge ATM.
No I frames unless audio also has I frames ?

Can MKVmerge split exact on cue sheet (chapter) Index marks or not ? If not will the new GUI be able to do so ?

Currently MKVmerge GUI Splitting feature has many options. I thought the 'Split by parts based on Timecodes' would be an exact precise split of the cue file Index points (chapters). Use of MKVmerge is for demux only with no audio file conversion. To demux and split precisely only at exact Index points using the embedded cue index (chapters).

Originally Posted by Nexin

To remove all cue file info, as there is no remove all here. Would be nice to have the option to do this with need to restart MKVmerge.

Originally Posted by Mosu

Use »File« -> »New«, that's what the function is there for: to start over as if you had re-started mmg. The »Remove all« button is intentionally different and keeps the content of a lot of controls in order to facilitate muxing several sets of files, e.g. several episodes of a series where you keep certain central things, one after each other.

Thanks the File-New option works as needed, I was looking for a GUI button to do the same.

Originally Posted by Nexin

I have a suggestion…

Originally Posted by Mosu

I'm in the middle of re-writing the GUI with a different toolkit (Qt instead of wxWidgets). Therefore the old GUI has reached its end of life; I won't spend any more time on it. I also don't accept feature requests for the new GUI yet.

Good news I didn't know you were working on a new GUI.

Will also the new GUI allow drag and drop for cue files. Current MKVmerge complains with 'File Identification Failed' when try to.

Looking forward to the new MKVmerge GUI features and options