MKVToolNix v99.0 released

[Mosu]

Note: The latest release is v99.0.

Hello everyone,

July's release of MKVToolNix is here: v25.0.0. After two smaller ones, this one packs quite a number of bug fixes and enhancements, including fixing a regression in the GUI's header editor preventing elements from being removed that was introduced in v24.0.0. Sorry about that.

AV1 support hasn't changed. While the bitstream format's been finalized in the meantime, the mapping to Matroska & WebM hasn't. It's currently being discussed on the CELLAR mailing list.

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 of the course of the next couple of hours.

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

# Version 25.0.0 "Prog Noir" 2018-07-12

## New features and enhancements

* mkvmerge: SRT/ASS/SSA text subtitles: for files for which no encoding has been specified, mkvmerge will try UTF-8 first before falling back to the system's default encoding. Part of the implementation of #2246 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2246).
* mkvmerge: SRT/ASS/SSA/WebVTT text subtitles: a warning is now emitted if invalid 8-bit characters are encountered outside valid multi-byte UTF-8 sequences. Part of the implementation of #2246 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2246).
* mkvmerge: Matroska & MPEG transport stream readers: the encoding of text subtitles read from Matroska files can now be changed with the `--sub-charset` parameter.
* Linux: starting with release 25 an AppImage will be provided which should run on any Linux distribution released around the time of CentOS 7/Ubuntu 14.04 or later.
* macOS: translations: updated the `build.sh` script to build `libiconv` and a complete `gettext`. Together with an additional fix to how translation files are located, MKVToolNix can now use all interface languages on macOS, too. Fixes #2110 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2110), #2307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2307), #2323 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2323).

## Bug fixes

* mkvmerge: AVC/h.264: fixed file identification failing for certain elementary streams due to internal buffers not being cleared properly. Fixes #2325 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2325).
* mkvmerge: HEVC/h.265: fixed file identification failing for certain elementary streams due to internal buffers not being cleared properly. This is the HEVC analog to what was fixed for AVC in #2325 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2325).
* mkvmerge: MLP code: fixed various issues preventing MLP from being parsed correctly. Fixes #2326 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2326).
* mkvmerge: TrueHD/MLP packetizer; dialog volume normalization removal isn't attempted if the track is an MLP track as the operation is only supported for TrueHD, not MLP.
* mkvmerge: MPEG TS reader: when reading MPLS mkvmerge will now compare the MPLS's start and end timestamps against the transport stream's PTS instead of its DTS. Otherwise the first key frame of a video track might be dropped if it isn't the first in presentation order. Fixes #2321 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2321).
* mkvmerge: JSON identification: mkvmerge will ensure that all strings passed to the JSON output modules are valid UTF-8 encoded strings by replacing invalid bytes with placeholder characters. This avoids the JSON library throwing an exception and mkvmerge aborting on such data. Fixes #2327 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2327).
* mkvmerge: audio packetizers: mkvmerge will now keep discard padding values if they're present for packets read from Matroska files. Fixes #2296 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2296).
* mkvmerge: Ogg Opus reader: packet timestamps aren't calculated by summing up the duration of all packets starting with timestamp 0 anymore. Instead the algorithm is based on the Ogg page's granule position and which packet number is currently timestamped (special handling for the first and last packets in the stream).
* This fixes the first timestamp if the first Ogg packet's granule position is larger than the number of samples in the first packet (= if the first sample's timestamp is bigger than 0). mkvmerge will keep those offsets now and inserts "discard padding" only where it's actually needed. * It also improves handling of invalid files where the first Ogg packet's granule position is smaller than the number of samples in the first packet (= the first sample's timestamp is smaller than 0). mkvmerge will now shift all timestamps up to 0 in such a case instead of inserting "discard padding" elements all over the place. * mkvmerge will no longer insert "discard padding" elements if the difference between a) the calculated number of samples in the packet according to the granule position and b) the actual number of samples as calculated from the bitstream is one sample or less and if the packet isn't the last one in the stream. This circumvents certain rounding errors. * The timestamp of the first packet after a gap in the middle of the stream is now calculated based on the Ogg page the packet belongs to, and not based on the timestamps before the gap.
Fixes #2280 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2280).
* mkvmerge: complete rewrite of the progress handling. It's now based upon the total size of all source files and the current position within them instead of the number of frames/blocks to be processed. This simplifies calculation when appending files and fixes rare cases of when progress report was obvious wrong (e.g. stuck at 0% right until the end). Fixes #2150 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2150) and #2330 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2330).
* MKVToolNix GUI: header editor: non-mandatory elements couldn't be removed anymore due to a regression while fixing #2320 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2320). They can now be removed again. Fixes #2322 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2322).

Have fun :)

[SeeMoreDigital]

Nice one Mosu :)

[Rollinnn]

I took 9 wav files (pcm 96 kHz/16 bits), all exacly one second (96000 samples) long, merged them to mka using MKVToolnix 25.0.0 with creating chapters for each appended file.
It seems obvious that each chapter should be exactly 1 second long and second chapter should start exactly at 1 second, third chapter should start exactly at 2 second and so on.
But using Info tool in MKVToolnix or MKVCleaver i can see that chapters time is slightly off.
So question: is this normal? If not, then what can be reason of this?
Here are chapters as extracted by MKVCleaver:
<?xml version="1.0"?>
<!-- <!DOCTYPE Chapters SYSTEM "matroskachapters.dtd"> -->
<Chapters>
<EditionEntry>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>0</EditionFlagDefault>
<EditionUID>6106875923387060889</EditionUID>
<ChapterAtom>
<ChapterUID>7385917724078987421</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 01</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>12105901406932053652</ChapterUID>
<ChapterTimeStart>00:00:00.999996225</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 02</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>4640490012402631944</ChapterUID>
<ChapterTimeStart>00:00:02.000002865</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 03</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>143719244427371845</ChapterUID>
<ChapterTimeStart>00:00:02.999999090</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 04</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>11556711324240879944</ChapterUID>
<ChapterTimeStart>00:00:03.999995315</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 05</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>6789293790652085347</ChapterUID>
<ChapterTimeStart>00:00:05.000001955</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 06</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>815895495329946186</ChapterUID>
<ChapterTimeStart>00:00:05.999998180</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 07</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>13740887356558005711</ChapterUID>
<ChapterTimeStart>00:00:07.000004820</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 08</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>7577353493033748017</ChapterUID>
<ChapterTimeStart>00:00:08.000001045</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 09</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
</EditionEntry>
</Chapters>

[Perenista]

I have a little problem with MKVToolnix: I used nPlayer to copy the 4K recorded video from my iPAD PRO 10.5 to another folder, so it was converted from MOV to MP4.

These are the details from the MP4 (now saved in my PC):

https://pastebin.com/GWRkfxyD

And as you can see the file is playing fine.

https://imgur.com/a/PRKWy0P

Now watch what happens when I add the MP4 to MKVToolnix and save as MKV:

https://imgur.com/a/uWTiCx5

Why? And how to avoid this?

It seems the iPAD is sending a command (embedded inside the MP4, of course) to MKVToolnix, to turn the image upside down. The funny thing is that everywhere I play this content it is not upside down. When added to MKVToolnix it changes to this.

Edit: now I spotted this in the file properties:

Rotation: 180°

What the hell?

[sneaker_ger]

The video has been recorded upside-down but a flag in the MP4 container tells players to rotate the video by 180° upon display (so that display is corrected). When mkvtoolnix remuxes the mp4 file this flag is lost because such a flag doesn't exist for mkv. Nothing you can do except re-encode the video or stick to mp4. (There are SEI messages for orientation in H.264 that mkvtoolnix would keep but I don't know a software to change them nor if any player supports them.)

[Perenista]

The video has been recorded upside-down but a flag in the MP4 container tells players to rotate the video by 180° upon display (so that display is corrected). When mkvtoolnix remuxes the mp4 file this flag is lost because such a flag doesn't exist for mkv. Nothing you can do except re-encode the video or stick to mp4.Yamb is also failing to do the same, so sticking with MP4 and doing any lossless change is not an option.

If this was an AVI I could easily open VirtualDUB and use directstream copy to save without reencode.

I need to edit this MP4 in this way:

- I recorded with the iPAD, however I used a tape recorder which then saved the ambient audio as a MP3. (this is way better than the audio recorded from the iPAD)

What I need to do:

1) Remove the audio stream from the MP4 recorded by the iPAD.

2) Add the MP3 from the tape recorder, which is now synchronized.

I did this:

- Extracted the video as RAW (Yamb option). I did this with the MP4 taken from the iPAD. Resulting file: IMG_1513_track1.h264

Then I used Yamb to join the video and audio streams.

Again upside down. Why Apple continues to do this sort of c.rap to force users into reencodes is beyond me.

In a 2013/14 PC it takes several hours to reencode in 4K quality, using Sony Vegas. And the final result, even if it's good, it's not as good as the original MP4 file (and there was a reduction from 6.82 to 3.63 GB).

I'll see if there's something that can be done... It makes no sense to say this was recorded upside down since I only used landscape mode and while I was looking at the iPAD camera the image was not upside down. :mad:

*****
Edit: I did it! Problem solved! There was no need to reencode. :D

https://stackoverflow.com/questions/25031557/rotate-mp4-videos-without-re-encoding

This is what should be done:

Look at that part...

True lossless rotation of MP4:

open mp4 with hex editor and search for vide to find the metadata of the video track
some rows above (for my files mostly 9, sometimes 12) you should see trak...\tkhd
in between there should be an @ sign (HEX 40)
in the two rows before it the rotation matrix is stored

(...)

[LeMoi]

Hello there,
when I am in the main multiplexing window, is there a keyboard shortcut to add the tracks, or do I need to right click in the blank part and then select 'Add files' ?

[Mosu]

You can generally see available shortcuts on controls by pressing and holding Alt. In case of the English variant, you'll then see that the "Add source files" button has an accelerator on the A, meaning you can press Alt+A to activate it.

[Perenista]

Why isn't possible to open MKVToolnix twice to edit files? I can only do it once at a time.

[Mosu]

That's intentional so that things such as adding files to a running instance via the command line (or drag & drop onto the program icon or via Windows "send to" functionality) works.

You can easily work on multiple things at the same time in that single instance, though: just open new tabs in the tool you need. Note that the job queue is run asynchronously, meaning you can continue using the tools (multiplexer, info too, chapter editor, header editor) while jobs are being executed.

[mood]

the build "mkvtoolnix-32-bit-25.0.0-revision-008-ga86e6cece" is broken

it can't open mkv file, nothing happen, no error message, nothing, all buttons stay disable

I have to kill the task for close mkvtoolnix.

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

[videoh]

Your problem is described in #6 here:

https://forum.doom9.org/forum-rules.htm

Just like the good ol' days. ;)

[manolito]

And instead of chastizing posters you should adhere to what a former moderator had to say about such things:
https://forum.doom9.org/showthread.php?p=1432768#post1432768

[mood]

I have change the name of file. I just post the bug not promote piracy

[Mosu]

Thanks for the heads-up. It actually does work, it just accidentally reads the whole file during identification which can take quite a long time. I've fixed it.

[LeMoi]

You can generally see available shortcuts on controls by pressing and holding Alt. In case of the English variant, you'll then see that the "Add source files" button has an accelerator on the A, meaning you can press Alt+A to activate it.

Thanks for the tip, but indeed it's reserved for the english version. With the French translation, Alt-A opens the Help Menu ('Aide'), even if the A of "Add source files" ('Ajouter des fichiers source') is underlined, so there's not keyboard shortcut... But that made me notice the "Add Source files" button, since until now I used to right-click in the main window, I have to admit that I never saw this button in the bottom of the window :D

PS: is there a button in the attachment tab, or do I need to use the right click?

[Mosu]

PS: is there a button in the attachment tab, or do I need to use the right click?

The latter.

[Snowknight26]

Is the RHEL repo URL wrong?

Adding the repo and then trying to update produces:

failure: repodata/repomd.xml from bunkus-org: [Errno 256] No more mirrors to try.
https://mkvtoolnix.download/centos/7Server/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found


Shouldn't https://mkvtoolnix.download/centos/7Server/x86_64/repodata/repomd.xml be https://mkvtoolnix.download/centos/7/x86_64/repodata/repomd.xml? (basically, remove "Server")

Edit: Looks like CentOS and RHEL use different $releasever variables: https://github.com/alanfranz/docker-rpm-builder/issues/15 & https://stackoverflow.com/questions/35978202/which-yum-variable-can-give-6-or-7-as-output

[Selur]

How experimental is av1 support atm. ?
Using:
ffmpeg -y -loglevel fatal -threads 8 -i "D:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv422p -vsync 0 -f yuv4mpegpipe - | aomenc --passes=1 --pass=1 --end-usage=cq --cq-level=18 --target-bitrate=15000 --profile=1 --cpu-used=6 --min-q=0 --max-q=63 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tune-content=default --tile-columns=2 --tile-rows=1 --min-gf-interval=0 --max-gf-interval=0 --threads=2 --width=640 --height=352 --i422 --input-bit-depth=8 --bit-depth=8 -o "E:\Temp\22_34_07_3710_01.ivf" -
to create an av1 file and then trying to multiplex it using:
mkvmerge --ui-language en -o "E:\Output\test.mkv" -d 0 --default-track 0:yes --default-duration 0:25/1fps --aspect-ratio-factor 0:1/1 --engage enable_av1 --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "E:\Temp\22_34_07_3710_01.ivf"
I get a 0byte output file and:
mkvmerge v25.0.0 ('Prog Noir') 64-bit
'E:\Temp\22_34_07_3710_01.ivf': Using the demultiplexer for the format 'IVF (AV1, VP8, VP9)'.
'E:\Temp\22_34_07_3710_01.ivf' track 0: Using the output module for the format 'AV1'.
The file 'E:\Output\test.mkv' has been opened for writing.
Error: An exception occurred when writing the destination file. The drive may be full. Exception details: end of file error; No error

(while there are still 2TB free on the hdd)

Cu Selur

Ps.: uploaded the ivf file to: https://drive.google.com/open?id=0B_WxUS1XGCPAUTlILW54VThMTFU

[Mosu]

How experimental is av1 support atm. ?

It's completely unusable. Treat the code as if it didn't exist.

Longer explanation: The specs for AV1-in-Matroska and AV1-in-WebM haven't been finalized yet. They will definitely look differently than what mkvmerge produces. mkvmerge's OBU parser is also based on an older bitstream format and cannot process 1.0 bitstreams. Currently work on the specification for AV1-in-Matroska/WebM is ongoing on the CELLAR list (https://mailarchive.ietf.org/arch/msg/cellar/oAxbYWJcZx4t5XvuIUp8AW8F8EQ) (and other threads about "AV1 seeking" & "AV1 init" on the same ML).

[Mosu]

Is the RHEL repo URL wrong?

As I don't have an RHEL installation, I only support CentOS directly.

[Selur]

Okay. Thanks for clearing that up. :)

Cu Selur

[Snowknight26]

As I don't have an RHEL installation, I only support CentOS directly.

Would you be able to make a symlink for 7 -> 7Server so that those with RHEL installations can use the RPM without having to fiddle with things manually? Or maybe clarify on the site's download page that RHEL isn't really supported?

[Mosu]

Would you be able to make a symlink for 7 -> 7Server so that those with RHEL installations can use the RPM without having to fiddle with things manually?

Sure. Done (both "7Server" and "7server", just to be safe). Give it a try, please.

[Snowknight26]

Confirmed working on RHEL 7, thanks!

[73ChargerFan]

Still lovin' the new GUI, but if I may request one not small feature:
A button for "new multiplexor job"

Last night I remuxed over 50 files, all using the mouse only. New job, though, requires a different brain activity (find menu, find item (on top), press it, repeat). Having a button would mostly eliminate my use of a keyboard altogether. I've got hundreds more to go. Maybe a button on the left, "New Job", beneath "Multiplexer", or right click on the job title tab?

Just thought I'd chime in... Thanks again for your hard work.

[Mosu]

I won't add any more buttons. More buttons only make things more confusing requiring more of that brain activity you're talking about.

You can easily leave the left hand on your keyboard and press Ctrl+N each time you want to create a new job.

[73ChargerFan]

Yes, but I my HTPC doesn't have one close by.

How about in the window menu, to the right of Help. A space 1/2" wide then a menu item "New Job" that doesn't open a sub-menu, but instead opens a new multiplexor job. A fakey button.

Just a thought :D

[Mosu]

No, I'm really, really not interested in adding a lot of buttons, let alone one for this particular function.

[hubblec4]

Hi Mosu

I have a question about the TimeStampScale.
This value is important for the length of bytes (you told me the scale factor is used to reduce bytes for storing). Default value is 1000000 and means ms-accuracy, but this makes issues with audio's and maybe also for cutting.

Can I set the TimeStampScale value to 1000000000 and now I have micro sec accuracy? How much bigger will be the resulting mkv?

[mkver]

You haven't understand this value at all: If this value is x, then the timestamps of the ordinary times (not the ones which are explicitly in ns like DefaultDuration or the DiscardPadding ones) are given by <Value encoded in File>*TimeStampScale ns; with the default value of 1000000 for TimeStampScale TimeStampScale ns = ms; with 1000000000 1000000000 ns = s. You would have s accurarcy which is useless.
If you want μs you would have to use a TimeStampScale value of 1000. Given that the relative timestamp inside (Simple)Blocks is a signed int16 you could only fit 65.536 μs of data in one Cluster; if the muxer tries to only use nonnegative relative timestamp values, it is half that value. mkvmerge does that. You would essentially have more than one cluster per video frame for ordinary framerates. The overhead will be huge.
Supplying mkvmerge with --timestamp-scale -1 will make it use such a low value that it is sample accurate even when a video track is present. This will likely still increase overhead, but not so much.
With hindsight, I believe that basing everything around ns precision was wrong. 1/9 ns would have been a better value (because then all common durations (including NTSC durations and lengths of audio samples for ordinary samplerates) would be an integral multiple of this base); or probably a file-dependent (actually segment-dependent) rational value.

[Mosu]

Yeah, even us Matroska developers agree that the choice of how to timestamp frames wasn't a good one, but one that will most likely never change as too much stuff out there wouldn't be able to handle anything else.

In order to put things into perspective: each cluster element contains at least the cluster timestamp. As a generalization you could say that at µs resolution you'd end up with roughly twelve bytes of overhead per 32ms of content. For a two hour movie you'd end up with ~ 2h * 60m/h * 60s/m * 1000ms/s * 12bytes/cluster / 32ms/cluster / 1024bytes/KB / 1024KB/MB = 2.5MB of additional overhead. Due to B frames and them being out of order, the actual overhead will often be higher (I just ran a test with a 2h movie where the additional overhead was more like 4.2MB while total file size was 1.6GB). Personally I wouldn't call either of those numbers a "huge overhead". My days of trying to fit movies on single CDs are long gone, luckily.

[anddi]

Hello! This is a very minor thing but it's bugging me. On Windows 10 when I have .mkv file with a preview thumbnail and I remux it with MKVToolNix, the preview thumbnail is lost. It's not a cover art, just a preview of the video. Is there a setting to enable it somehow?

[hubblec4]

@mkver
Yes, the value for TimeStampScale should be 1000 (not 1000000000), sorry my fault.
A vale of -1 is an automatic for mkvmerge? good to know.

@Mosu
Thanks for your test.
Have you used a "-1" value for TimeStampScale in your test? And if so, which TimeStampScale was set by mkvmerge?

For me is accuracy more important then save disk space. And Mosu's test shows that 4.2mb more overhead is almost nothing in relation to the file size.

[hubblec4]

Hello! This is a very minor thing but it's bugging me. On Windows 10 when I have .mkv file with a preview thumbnail and I remux it with MKVToolNix, the preview thumbnail is lost. It's not a cover art, just a preview of the video. Is there a setting to enable it somehow?

I can remember me that someone asked the same... maybe on GitLab.
EDIT:
https://gitlab.com/mbunkus/mkvtoolnix/issues/2334

That is a Win10 issue.

[anddi]

I can remember me that someone asked the same... maybe on GitLab.
EDIT:
https://gitlab.com/mbunkus/mkvtoolnix/issues/2334

That is a Win10 issue.

Thank you! This is exactly what I was looking for. And tbh I'm not that surprised it's a Win10 issue.. :D

[mkver]

Have you used a "-1" value for TimeStampScale in your test? And if so, which TimeStampScale was set by mkvmerge?

For 48kHz content (the most common sample rate for audio accompanying movies) the TimestampScale is 20832; 20833 would be enough for sample accuracy.

For me is accuracy more important then save disk space. And Mosu's test shows that 4.2mb more overhead is almost nothing in relation to the file size.
There might be an unpleasant surprise waiting for you, namely the way mkvmerge assignes timestamps from input files. It simply trusts them and this might sound good, but it has some side-effects. By "trusts them" I mean that the timestamp of the i. frame (frame[i] - 0 based array) in a lace is set equal to Timestamp((Simple)Block) + sum the durations of all the frame[j] with j<i. This calculation is done in ns precision. Whereas the durations are fine (the error that is introduced by using ns is usually negligible; there is only one scenario in which the durations are bad: if a track is not supported (if it is supported, then the durations are directly taken from the bitstream level) and if there is no default duration for the track), the Timestamp of the (Simple)Block is not. They are after all already rounded, for a TimestampScale of 1000000 they are rounded to ms.
Here is mkvinfo's output for a file with TimestampScale 1000000 containing a DTS soundtrack (packet duration 32/3 ms):

| + Simple block: key, track number 1, 8 frame(s), timestamp 00:00:00.000000000
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Simple block: key, track number 1, 8 frame(s), timestamp 00:00:00.085000000
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024

If one remuxes this file with the automatically choosen TimestampScale amounting to sample precision, one gets this:

|+ Cluster
| + Cluster timestamp: 00:00:00.000000000
| + Simple block: key, track number 1, 8 frame(s), timestamp 00:00:00.000000000
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Simple block: key, track number 1, 8 frame(s), timestamp 00:00:00.084994560
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024
| + Frame with size 1024

8*32/3ms = 85 1/3ms, i.e. the first lace ends at about 85 1/3 ms, but the timestamp of the second lace is very near to 85ms and not to 85 1/3ms as the timestamp is derived as above and then converted to the new TimestampScale of 20832. This is actually worse than it was before: Earlier the "incorrect" value of 85ms could be blamed upon the timestamp resolution, but this time it isn't. Put another way: With 1ms precision it could be disregarded that there is actually an 1/3ms overlap between the first two laces; now this is no longer true. The file is claming to be more precise than it actually is.

There are other ways to run into this issue: Remux a file without changing the TimestampScale, but with changing the lacing (can be done by either disabling-lacing or by changing the clustering (e.g. use a different video track that has keyframes at different points)) and you get something like this (for disable-lacing and still 1ms precision, remuxed from the first file above):

| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.000000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.011000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.021000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.032000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.043000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.053000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.064000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.075000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.085000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.096000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.106000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.117000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.128000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.138000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.149000000
| + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.160000000
| + Frame with size 1024

The frame with timestamp 106ms should actually have a timestamp of 106 2/3ms which should be rounded to 107ms.

A strategy to solve this problem would go like this: For the first (first/next/last etc. always refers to output order (established from the timestamps directly read from the file)) (Simple)Block of a track the timestamp in the file is trusted. Then the end timestamp of said (Simple)Block is calculated (if possible; if not, one has to trust the timestamps anyway). The next timestamp read is then compared to the end timestamp of the last one. If they agree within the bounds of the precision possible by the input file, then it is presumed that there is no gap between these two frames and instead of the timestamp of the second block the end timestamp of the first block is used. If not, then the timestamp taken from the input file is directly used. This logic is similar to the one used to prevent shifting gaps due to lacing (https://gitlab.com/mbunkus/mkvtoolnix/commit/366a362e08751cc01c43f515348452de66c7c620).

If someone wants several blocks to overlap (like the 1/3ms above), then this algorithm would obviously destroy this and "correct" the file. But apart from this case (that seems to be totally unlikely) I can't think of a scenario where it would make matters worse.

[ryrynz]

Hey Mosu, any chance of prompting to change output file name automatically when only one video source file exists when swapping in/out files for new jobs?

[sneaker_ger]

Isn't that already the default? If not, look into preferences for the setting. If there is none describe in more detail what exactly you are doing, what you are expecting and what is happening instead.

[Klaus1189]

Thank you! This is exactly what I was looking for. And tbh I'm not that surprised it's a Win10 issue.. :D


Does that help?
https://forum.videohelp.com/threads/389849-Remuxing-with-MKVToolNix-removes-videos-thumbnails-and-file-properties#post2526077

[hubblec4]

Hi Mosu

This time I have a question about chapters :-)

I want split an mkv with the split option "By Parts based on timestamps" and insert new external chapters (SimpleChapters).
Here a very short options file:

[
"--output",
"F:\\Output.mkv",
"--no-chapters",
"--no-global-tags",
"(",
"F:\\Input.mkv",
")",
"--split",
"parts:00:00:00.000000000-00:01:05.586000000,+00:01:42.299000000-00:02:40.571000000",
"--chapters",
"F:\\chapters.xml"
]


The chapters file:

CHAPTER01=00:00:00.000
CHAPTER01NAME=Kapitel 1
CHAPTER02=00:00:20.000
CHAPTER02NAME=Kapitel 2
CHAPTER03=00:00:40.000
CHAPTER03NAME=Kapitel 3
CHAPTER04=00:01:00.000
CHAPTER04NAME=Kapitel 4
CHAPTER05=00:01:20.000
CHAPTER05NAME=Kapitel 5
CHAPTER06=00:01:40.000
CHAPTER06NAME=Kapitel 6
CHAPTER07=00:02:00.000
CHAPTER07NAME=Kapitel 7


The issue is, mkvmerge recalculate the external chapter time stamps after first split-pair.

Chapters from Output.mkv:

CHAPTER01=00:00:00.000
CHAPTER01NAME=Kapitel 1
CHAPTER02=00:00:20.000
CHAPTER02NAME=Kapitel 2
CHAPTER03=00:00:40.000
CHAPTER03NAME=Kapitel 3
CHAPTER04=00:01:00.000
CHAPTER04NAME=Kapitel 4
CHAPTER05=00:01:05.666
CHAPTER05NAME=Kapitel 6
CHAPTER06=00:01:23.367
CHAPTER06NAME=Kapitel 7


Last both chapter times are now wrong.

OK, wrong is not right. I think when mkvmerge make such a split case without external chapters and keep existing chapters than it is important to shift the time stamps.
But I want the chapter times from the external chapters.

Is there something that I missed or could you change this so that when external chapters are used then all chapter times stay untouched?

[Mosu]

mkvmerge assumes that all content belongs together, no matter whether or not splitting is used. It therefore assumes that the chapter timestamps will have to be shifted if the output timestamps are shifted.

There's no option to change this, and I don't plan on adding one.

[hubblec4]

...
There's no option to change this, ....

An option is not absolutely necessary, an automatic would be better.

When I append files (I know appending is not splitting) with chapters, all chapter times will be shifted, but when I use an external chapters.xml file, there is no recalculate for the chapter times.

I guess it would be very easy to do the same for splitting.

If external chapters are present then mkvmerge must not assumes that all content belongs together and you can skip the recalculate function.

[Mosu]

I won't add anything in that direction.

[hubblec4]

Hi Mosu

I have a question about Tags and the pre-switch "all:" and "global:".

propedit My.mkv --tags all:tags.xml
propedit My.mkv --tags global:tags.xml


I had changed in my chapterEditor from all: to global: and it seams that all work, but it breaks the Matroska Tags editor.
What are the differences of this switches?

[Mosu]

With "all", all tags are replaced. With "global", only those tags that do not target a track (via "Targets" → "TrackUID") are replaced.

[hubblec4]

Ah ok, global: is depend of Targets->TrackUID. Good to know.

[Megalith]

Would it be difficult to add an option for auto-sorting source files? Ideally, the order should be video, audio, and then subtitles, but the video file is always last when I drag them into MKVToolNix due to the naming convention my de-muxer uses.

[Mosu]

Auto-sorting wouldn't be too hard. Please open a feature request over on [Gitlab](https://gitlab.com/mbunkus/mkvtoolnix/issues/) for that so I won't forget about it.

[Mosu]

Hey,

time for another release of MKVToolNix, v26.0.0. It's on the smaller side regarding the number of changes.

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 of the course of the next couple of hours.

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

# Version 26.0.0 "In The Game" 2018-08-26

## New features and enhancements

* mkvmerge: chapter generation: if the name template given by `--generate-chapters-name-template` is empty, no names (`ChapterDisplay` master elements with `ChapterString`/`ChapterLanguage` children) will be generated for the chapter atoms. Part of the implementation of #2275 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2275).
* mkvmerge: chapters: chapter names generated from MPLS files will now use the name template if one is set via `--generate-chapters-name-template`. Part of the implementation of #2275 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2275).
* mkvmerge: mkvmerge will no longer abort with an error message if no audio, video and subtitle tracks should be multiplexed. This allows copying of chapters from non-chapter source files (e.g. Matroska or MP4 files).
* MKVToolNix GUI: the font size in the tool selector on the left will scale with the font size the user selects in the preferences.
* MKVToolNix GUI: the GUI will no longer automatically resize the columns in tree and list views to match the content size. Instead it remembers and restores the widths set by the user. Implements #2353 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2353).
* MKVToolNix GUI: multiplexer: the chapter name template will now be set automatically to the name template in the preferences' "chapter editor" section. Additionally the option `--generate-chapters-name-template …` will be passed to mkvmerge in situations when mkvmerge will generate chapters (either because automatic generation is enabled or if chapters are generated for MPLS playlists). Part of the implementation of #2275 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2275).
* MKVToolNix GUI: chapter editor: if the chapter name template is empty, chapters will be generated without names. Part of the implementation of #2275 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2275).
* MKVToolNix GUI: chapter editor: added an option to remove all chapter names to the "additional modifications" dialog. Part of the implementation of #2275 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2275).

## Bug fixes

* mkvmerge: Matroska reader: fixed wrong timestamps when appending Matroska files where the second Matroska file's first timestamp is bigger than 0. Fixes #2345 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2345).
* mkvmerge: MP4 reader: fixed division by zero errors during file identification if the timescale is 0 in the `MVHD` atom.
* mkvmerge: Windows Television DVR files are now recognized as an unsupported file type. This prevents mis-detection as MPEG-2 with an accompanying flood of error messages. Fixes #2347 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2347).
* MKVToolNix GUI: info tool: under certain circumstances "cues" were shown at the wrong level (inside the previous master element instead of on level 1). Fixes #2361 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2361).
* MKVToolNix GUI: job queue: fixed invalid memory handling and consequent crashes when using the "edit in corresponding tool & remove from job queue" option if one of the files in that job contained attached files. Fixes #2368 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2368).

## Build system changes

* An AppStream metadata file will be installed in `$prefix/share/metainfo`.

Have fun :)