MKVToolNix v100.0 released [Archive]

Mosu

12th July 2018, 20:21

Note: The latest release is v101.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

12th July 2018, 20:38

Nice one Mosu :)

Rollinnn

14th July 2018, 22:41

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"?>

<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

19th July 2018, 21:18

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

19th July 2018, 22:05

Perenista

19th July 2018, 22:16

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

21st July 2018, 20:16

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

21st July 2018, 20:18

Perenista

22nd July 2018, 17:14

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

Mosu

22nd July 2018, 19:09

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

26th July 2018, 02:09

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

26th July 2018, 03:08

Your problem is described in #6 here:

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

Just like the good ol' days. ;)

manolito

26th July 2018, 03:43

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

26th July 2018, 07:26

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

Mosu

26th July 2018, 08:09

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

26th July 2018, 19:43

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

26th July 2018, 19:58

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

The latter.

Snowknight26

30th July 2018, 17:08

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

4th August 2018, 21:50

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

4th August 2018, 21:59

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

4th August 2018, 21:59

Is the RHEL repo URL wrong?

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

Selur

4th August 2018, 22:00

Okay. Thanks for clearing that up. :)

Cu Selur

Snowknight26

4th August 2018, 22:13

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

4th August 2018, 22:28

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

6th August 2018, 15:46

Confirmed working on RHEL 7, thanks!

73ChargerFan

11th August 2018, 18:43

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

11th August 2018, 19:18

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

11th August 2018, 21:16

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

11th August 2018, 22:27

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

hubblec4

14th August 2018, 02:44

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

14th August 2018, 16:44

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

14th August 2018, 17:04

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

14th August 2018, 17:06

hubblec4

14th August 2018, 18:01

@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

14th August 2018, 18:12

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

14th August 2018, 19:02

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

14th August 2018, 21:25

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

15th August 2018, 03:59

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

15th August 2018, 11:11

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

17th August 2018, 21:21

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

18th August 2018, 01:47

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

18th August 2018, 08:16

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

18th August 2018, 12:51

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

18th August 2018, 13:05

I won't add anything in that direction.

hubblec4

19th August 2018, 13:51

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

19th August 2018, 15:09

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

hubblec4

19th August 2018, 16:05

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

Megalith

22nd August 2018, 14:47

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

22nd August 2018, 17:36

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

26th August 2018, 13:21

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 :)

Klaus1189

26th August 2018, 15:31

v26.0.0 is singed by "LINET Services GmbH"

Mosu

26th August 2018, 15:45

That is correct, as explained on the MKVToolNix home page (https://mkvtoolnix.download/authenticity.html#windows). LINET Services is my own company (https://www.linet-services.de/impressum/). It was easier to get a code signing certificate for an organization than for an individual.

73ChargerFan

26th August 2018, 21:47

Ouch.. twice in two hours the v26.0.0 GUI crashed but mkvmerge keeps running in the background.

It happened when I was interacting with the Multiplexer tab, but that's all I know. Restarting the GUI works (Which Is Really Cool) - it shows me the job that's running, and the jobs I'd queued before the gui crashed keep starting like nothing happened.

I'll reinstall and restart my system, maybe all the in place upgrades have finally caught up with me.

EDIT:
Turns out now I have two instances of mkvmerge running.

Mosu

26th August 2018, 21:53

Well, you'll have to figure out which steps make the GUI crash exactly. I cannot act on "it happens sometimes somehow".

73ChargerFan

26th August 2018, 22:05

I'm spending all day doing this, and will try to maybe pay closer attention some of the time. Thanks.

anddi

27th August 2018, 23:59

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

Yes. Wow. I came back here because I had just noticed that deleting every tag fixes thumbnails on Win10, but after seeing your reply I tried mkvpropedit with just "--delete-track-statistics-tags" option and that alone fixed my thumbnails on Windows 10. I don't use any software for thumbnails whatsoever.

mkver

28th August 2018, 07:40

Yes. Wow. I came back here because I had just noticed that deleting every tag fixes thumbnails on Win10, but after seeing your reply I tried mkvpropedit with just "--delete-track-statistics-tags" option and that alone fixed my thumbnails on Windows 10. I don't use any software for thumbnails whatsoever.
Then I believe that the change introduced because of this issue (https://gitlab.com/mbunkus/mkvtoolnix/issues/2202) is behind this. Someone tell Microsoft that TagDefault has a default value.

Boulder

31st August 2018, 17:04

Well, you'll have to figure out which steps make the GUI crash exactly. I cannot act on "it happens sometimes somehow".

I've experienced it as well. This is what Win10 Event viewer shows in the log:

Faulting application name: mkvtoolnix-gui.exe, version: 26.0.0.0, time stamp: 0x00000000
Faulting module name: mkvtoolnix-gui.exe, version: 26.0.0.0, time stamp: 0x00000000
Exception code: 0x40000015
Fault offset: 0x000000000141fcab
Faulting process id: 0x4778
Faulting application start time: 0x01d44126ac2dcb52
Faulting application path: C:\Program Files (x86)\MKVtoolnix\mkvtoolnix-gui.exe
Faulting module path: C:\Program Files (x86)\MKVtoolnix\mkvtoolnix-gui.exe
Report Id: 217c1904-3556-4978-afe9-d91c1dcf07af
Faulting package full name:
Faulting package-relative application ID:

I've been transferring my encode archives from DVDs to portable HDDs. Some of the old archives are MKV split into parts, and I use MKVToolnix GUI to rejoin them to mux them as a single file on the HDD. So basically I drag-and-drop stuff, use Append, select file and mux.

What I have noticed that after some muxes, my OS turns quite sluggish and restarting MKVToolnix GUI will fix that. If I don't restart, after several rounds of rejoining and muxing files, the GUI crashes by simply vanishing and then it leaves its mark in the Event viewer log. I've had it happen twice, and both times it happened when I dragged a file in the source panel.

If you can come up with a debug build, I might be able to trace the problem for you. I may still have some split files to join :)

Mosu

31st August 2018, 18:34

Thanks. Doesn't help me that much, though.

What you've described sounds like a severe memory leak; the system thrashing would be swapping activity. The crash might then be due to all free memory being exhausted.

I've tried to reproduce this by appending various file types for several minutes now. Memory usage will rise while mux jobs are open, but that's to be expected, and it's not that huge usage either. With ten open settings with ~4 files each, memory usage rises from ~40 MB at start to ~68 MB.

There does seem to be some kind of leak that I can detect as memory usage doesn't drop back to ~40 MB when I close all settings, remove all jobs from the queue & clear the job log.

With those numbers, you'd need hundreds of open mux jobs in order to exhaust even those systems that don't have a lot of memory.

So far this doesn't help me much.

What you could do is have task manager open while you mux and watch the GUI's memory usage. If you notice severe increases due to certain files, I'd highly appreciate it if you uploaded them to my file server (https://gitlab.com/mbunkus/mkvtoolnix/wikis/FTP-server) along with a description of how exactly you set up the job.

A debug build wouldn't help in this case. I'm convinced that the crash isn't the problem; it's just a symptom of the bug that leads to the system becoming sluggish (like I said, likely a memory leak). Debug builds don't help with memory leaks.

Boulder

1st September 2018, 15:57

I just experienced the crash again. There were no signs in the task manager view, normal memory consumption all the time even though the sluggishness started almost immediately after the first job was done. It definitely seems memory related because the sluggishness seems to be more apparent if I have an encoding task running, which means that around 50% of total memory is reserved by vspipe and x265. But like I said, there's nothing visible pointing to a memory leak because there is plenty of memory available right up until the crash.

Mosu

1st September 2018, 16:13

How much memory is mkvmerge.exe (not mkvtoolnix-gui.exe) consuming in that case? Note that mkvmerge's memory will jump right when it starts, and it will continue to grow slowly due to in-memory indexes getting bigger (those indexes can only be written all at once when the file's done).

Can you watch your I/O load, too? Is mkvtoolnix-gui.exe causing a lot of I/O activity while the system is sluggish? You can use Windows' "Resource Monitor" tool for that.

Boulder

1st September 2018, 16:38

The crash occurs directly in the GUI, for me it happens when I drag and drop a source file in the panel. I've not had a crash while a mux operation has been in progress. I watched a 10 GB mux progress and mkvmerge took around 50-70 MB most of the time, peak working set was about 100 MB. I'll try to see how many muxes it will take for the crash to happen as the sluggishness already appears after the first two or three.

Mkvtoolnix-gui.exe has no activity outside normal usage in Resource Monitor, it seems to be behaving well.

Mosu

1st September 2018, 16:46

Can you reproduce the crash with the same file? If not, try removing the "cache" folder (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Location-of-settings,-job-queue,-cache-folder) between tries.

Mosu

1st September 2018, 16:47

When you drag & drop & the GUI crashes, is a job still running at that point?

Boulder

1st September 2018, 17:09

Can you reproduce the crash with the same file? If not, try removing the "cache" folder (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Location-of-settings,-job-queue,-cache-folder) between tries.

I'll try.. I probably need to run a mux operation instead of just goofing around with the GUI if this is memory related.

When you drag & drop & the GUI crashes, is a job still running at that point?No, I always wait for the mux job to finish before I start preparing a new one. This is basically because I usually get one part from a DVD and all the rest from an HDD.

Mosu

1st September 2018, 17:28

BTW, here (https://mkvtoolnix.download/windows/debug/32-bit/) is a build with debug symbols. Don't know how much use those might be to you — I compile on Linux with the mingw cross-compiler. I don't know if its type of debugging info is usable on Windows.

Boulder

1st September 2018, 17:32

I was able to reproduce it with the same file(s). I already had finished four different muxes and then did the same mux job four times just like each of them was a new one. After those, I added the same source files normally and added the job into the queue. Removed all source files to readd them once again and the GUI vanished. I could tell that I'm close to success (sic) because the HDD started making swapping like noise.

I'll install the debug build, let's see if we can find something there. It seems to be 32-bit but probably no difference in that sense compared to the 64-bit build that I use (the x86 path is due to an ancient installation).

Mosu

1st September 2018, 17:40

Well yeah, I figured from your x86 path that you were using a 32-bit build, hence… :)

Boulder

1st September 2018, 17:46

Well, it crashed after adding the same files over and over again and adding the job in the queue :) Where can I get the dump file? I couldn't find it in the program directory.

Mosu

1st September 2018, 18:22

No idea, I don't program under Windows.

But I do have an idea where this might come from. I'll try to rewrite the corresponding code section later tonight.

XinHong

2nd September 2018, 07:24

Hello Mosu,

There is something strange with v26 of MKVToolNix GUI:
- Start MKVToolNix GUI
- Drag & drop a file
- Perform a mux (not mandatory to perform something)
- Right click in the "Source Files" and choose "Remove All Files"
- Close MKVToolNix
- The following message appears :
"The file "< No destination file >" has been modified. Do you really want to close ? All changes will be lost"

I don't remember I had this message in v25, and, as all files in the source list have been removed, I think this message should not appear

Mosu

2nd September 2018, 09:49

The settings consist not only of the stuff on the "input" tab, but also of all the controls on the "output" and "attachments" tab. If their settings deviate from the last saved state (or the "new settings" state if it has never been saved or added to the job queue), then the GUI will ask for confirmation.

Mosu

2nd September 2018, 11:15

Well, it crashed after adding the same files over and over again and adding the job in the queue :)

I've created a new debug build (https://mkvtoolnix.download/windows/debug/64-bit/), this time not with debugging symbols, but with a lot of validity checks on the internal structures containing job information. If an inconsistency is found, an error message is shown. Please give this build a try, and if such a message pops up, please provide the error it shows (you can select & copy the message shown in that dialog, BTW).

BTW: I highly appreciate your work on this. As I cannot reproduce the crashes (yet), I have to rely on other people's work.

mkver

2nd September 2018, 12:20

Where can I get the dump file? I couldn't find it in the program directory.
It's in C:\Users\<Account_Name>\AppData\Local\CrashDumps. But can one even analyze them with the GNU tools?

PS: Have you already tried to find out when exactly the problems started to arise by using these builds? (https://mkvtoolnix.download/windows/continuous/64-bit/25.0.0/) I can't reproduce the crashes and therefore can't do it.

Boulder

2nd September 2018, 13:02

I've created a new debug build (https://mkvtoolnix.download/windows/debug/64-bit/), this time not with debugging symbols, but with a lot of validity checks on the internal structures containing job information. If an inconsistency is found, an error message is shown. Please give this build a try, and if such a message pops up, please provide the error it shows (you can select & copy the message shown in that dialog, BTW).

BTW: I highly appreciate your work on this. As I cannot reproduce the crashes (yet), I have to rely on other people's work.

No problems regarding testing :) This was a random accident that I happened to start working so heavily on video clips, I usually mux a couple of files at a time. In my daily work, I often need to rely on information from others to reproduce problems so I know how frustrating it can sometimes be to try things.

Now I got the crash with the mux job running. No error messages whatsoever, the OS just turned very sluggish while I was browsing the internet and I knew that it would not take long for something to happen.

I uploaded two most recent dumps if they are of any use. The older one is from yesterday's debug build, the other one is the crash I just had.

https://drive.google.com/open?id=17KJ5ZgwUP26_65WVr2YBocphfn5LKlJ3

mkver, thanks, I think I'll start digging a bit deeper with those builds.

Mosu

2nd September 2018, 14:00

OK, so the problem is completely unrelated to that particular part of the program. It was one of the few areas of the GUI that I actually changed between v25 and v26. So we'll have to look at other changes.

There's one particular change between 25 and 26 that affects job/config handling. I've reverted that change and created a new debug build (https://mkvtoolnix.download/windows/debug/64-bit/) without said change.

Mosu

2nd September 2018, 14:16

BTW, the crash dumps don't help me — yet. I'm currently learning a lot about different debug info formats, how to do postmortem and/or just-in-time crash debugs for mingw applications etc. I'll look at bit further into those methods before providing new binaries to test with.

In case anyone is interested: "MinGW and Postmortem Debugging" (http://blog.morlad.at/blah/mingw_postmortem), "Dr. MinGW — Postmortem debugging tools for MinGW" (https://github.com/jrfonseca/drmingw)

Mosu

2nd September 2018, 17:22

Alright, here (https://mkvtoolnix.download/windows/debug/64-bit/mkvtoolnix-64-bit-26.0.0-revision-016-g78d7708b3.7z) is another debug build. This one links against the Dr. MinGW library. When it crashes, it should write a file called "mkvtoolnix-gui.RPT" in the same file the exe is is (hence me only providing the portable archive — writing to "C:\Program Files…" is normally not possible). This file should contain a stack trace. Please send me that file/upload it somewhere. Thanks.

Boulder

2nd September 2018, 17:49

Boulder

2nd September 2018, 18:26

I was able to reproduce the crash by torturing the GUI but no RPT file appeared in the program folder :( I'll install rev 014 and see how it goes..

Mosu

2nd September 2018, 18:46

014 isn't linked against that library and wouldn't create such a report anyway.

If there is no report, the crash doesn't happen under the control of the program.

I honestly don't know what else to try here.

Boulder

2nd September 2018, 18:52

But wasn't 014 the one in which you reverted a change that could be associated with this issue? Currently I have tried only adding files as a source and added jobs to queue and it has worked smoothly and doesn't cause any OS sluggishness. The next step will be muxing and then torturing the GUI.

Mosu

2nd September 2018, 19:21

In 016 the change is still reverted, just with the Dr. MinGW library linked & invoked. So if 016 still crashes, that aforementioned change isn't the culprit.

Boulder

2nd September 2018, 19:28

dade49

5th September 2018, 02:23

Hello Mosu, I have a DTS-HD MA 5.1 track (24 bit) with dialnorm on both the master and the embedded core track. I am using the MkvToolNix GUI to build an mkv from the source and using the option to remove dialog normalization from the track. The resulting file has the dialnorm removed from the core track, but it remains on the master track. Is there a way to remove it from both? Is this an issue that you're aware of? I'm happy to provide a sample if you need it. Thank you for all of your hard work.

Mosu

8th September 2018, 12:14

Hello Mosu, I have a DTS-HD MA 5.1 track (24 bit) with dialnorm on both the master and the embedded core track.

I'm not aware of such a problem. Please open a new issue (https://gitlab.com/mbunkus/mkvtoolnix/issues/) for it and upload a sample file.

Mosu

8th September 2018, 12:16

Ah, okay. I think I'll try v25 then, and work my way up from there with those intermediate builds towards v26. Of course, I could find this in v25 as well because it's been quite a long time since I did this kind of work.

One thing i did change between releases 25 and 26 was that I updated all of the libraries used by MKVToolNix, specially Qt from 5.10.1 to 5.11.1. Here (https://mkvtoolnix.download/windows/debug/64-bit/mkvtoolnix-64-bit-26.0.0-revision-016-g78d7708b3-01788.7z) is a new build of the same code base (016-g78d7708b3) as before, but compiled against the older set of libraries, the one v25 was compiled against. Please give this build a try, too. Thanks.

Boulder

8th September 2018, 14:56

One thing i did change between releases 25 and 26 was that I updated all of the libraries used by MKVToolNix, specially Qt from 5.10.1 to 5.11.1. Here (https://mkvtoolnix.download/windows/debug/64-bit/mkvtoolnix-64-bit-26.0.0-revision-016-g78d7708b3-01788.7z) is a new build of the same code base (016-g78d7708b3) as before, but compiled against the older set of libraries, the one v25 was compiled against. Please give this build a try, too. Thanks.
Thank you, I've been slowly resuming the work today. I'll try to make it crash over the weekend :)

9th September 2018, 20:03

Is it possible to set >99 chapters using "simple chapter format", or it only possible with XML based chapter format?

Mosu

9th September 2018, 20:16

I haven't actually tried it, but the code uses regular expressions for matching the lines, and the number part is a simple "\d+" — meaning "one or more digits". Meaning "CHAPTER01" should work, as should "CHAPTER1", "CHAPTER0001" or "CHAPTER12345".

hubblec4

9th September 2018, 20:53

The OGM specs allows 1000 chapters indexed from 000 up to 999.
But Mosu's Chapter Editor and my chapterEditor supports more chapters.

Mosu

11th September 2018, 18:30

Thank you, I've been slowly resuming the work today. I'll try to make it crash over the weekend :)

The problem has been fixed. A crucial piece of information was contributed over on GitLab (https://gitlab.com/mbunkus/mkvtoolnix/issues/2372): it doesn't depend on the files; simply switched between the tools suffices. With that I was able to reproduce it, track it to a font resource memory leak introduced after v25, and fix it. A new, fixed build is available here (https://mkvtoolnix.download/windows/pre/64-bit/).

Boulder

11th September 2018, 18:47

Congratulations :) This was a tough one, fortunately others were able to contribute as well.

Megalith

14th September 2018, 01:22

mkver

14th September 2018, 01:38

Maybe this is related to the above issue (which has been fixed), but I have run into a couple of instances in which MKVToolNix GUI will disappear in the middle of a job, as if the program was closed. Task Manager will show that the program is still running, however.
1. Just to be sure: You are running the new, patched version, not the 26.0 release version?
2. What exactly does Task Manager show? Is it mkvmerge.exe running or is it mkvtoolnix-gui.exe? If you started a job from the GUI, then you should have a mkvmerge.exe process and a mkvtoolnix-gui.exe process running at the same time. mkvmerge.exe ends automatically after the completion of the job, so if the GUI crashes during a job you should still have a MKVToolNix related process running (namely mkvmerge.exe), but it shouldn't be mkvtoolnix-gui.exe.

If the answer to 1. is yes and if it's really mkvtoolnix-gui.exe that is running after the GUI crashed, you should open a ticket on gitlab.

Megalith

21st September 2018, 01:39

I tried the patched version and have not run into the issue so far, so I assume all is good now.

Selur

22nd September 2018, 09:13

Using:
rav1e: 0.1.0
mkvmerge: v26.0.0
ffmpeg: version N-91949-g6304268e39
I aimed do the following:
a. convert input to av1, by decoding to yuv420p using ffmpeg, piping to and encoding with rav1e
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p -vsync 0 -f yuv4mpegpipe - | rav1e --tune Psychovisual - -o "E:\Output\test.ivf"
.ivf output plays fine in latest MPC-HC so I assume the file is okay
b. remuxing to mkv using mkvmerge:
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:\Output\test.ivf"
but that creates 0 byte file and outputs:
mkvmerge v26.0.0 ('In The Game') 64-bit
'E:\Output\test.ivf': Using the demultiplexer for the format 'IVF (AV1, VP8, VP9)'.
'E:\Output\test.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
Still got 1.3 TB free on that drive.

To be sure this isn't a rav1e problem I also used aomenc for encoding, but got the same error.
(Same problem with: mkvtoolnix-64-bit-26.0.0-revision-021-g39f37fa93-01789)

-> Since the av1 support is still experimental, is there any progress there? (or did I mess up somewhere with the muxing call?)

Cu Selur

Ps.: uploaded the test.ivf to my GoogleDrive (https://drive.google.com/open?id=0B_WxUS1XGCPAUTlILW54VThMTFU).

Mosu

22nd September 2018, 09:45

mkvmerge's AV1 support isn't usable yet. Neither does it conform to the finalized AV1 bitstream spec, nor had the AV1-in-Matroska specs been finalized when I last worked on that code (which was several weeks ago).

Selur

22nd September 2018, 19:34

Okay, thanks for the info. Hoped there would have been some progress,.. :)

Mosu

26th September 2018, 20:02

I've just released MKVToolNix v27.0.0. This release is smallish but important due to two bug fixes. The first is an annoying crash easily triggered on Windows simply by using the program for a while. The second is indubitably more important: mkvmerge was corrupting E-AC-3 frames when the "dialog normalization gain removal" functionality was used.

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 27.0.0 "Metropolis" 2018-09-26

## New features and enhancements

* mkvmerge: chapters: the timestamps of chapters read from containers or from chapter files can be adjusted (multiplication and addition) with the new `--chapter-sync` option or using the special track ID `-2` for the existing `--sync` option. Part of the implementation of #2358 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2358).
* MKVToolNix GUI: multiplexer: adjusted & added controls for mkvmerge's new feature of being able to adjust chapter timestamps. Part of the implementation of #2358 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2358).
* MKVToolNix GUI: multiplexer: the GUI can now ask for confirmation when the user is about to create a file that won't contain audio tracks. It does this by default if at least one source file contains an audio track. Implements #2380 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2380).

## Bug fixes

* mkvmerge: AC-3: dialog normalization gain removal was corrupting E-AC-3 frames irreversibly by writing checksums in places where they didn't belong. Additionally only the first E-AC-3 frame in a Matroska was processed but not additional dependent frames in the same block. Fixes #2386 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2386).
* MKVToolNix GUI: fixed a leak of Windows font resources leading to a general slowdown and subsequent crash. Fixes #2372 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2372).

Have fun :)

hubblec4

26th September 2018, 20:42

Many thanks for the fast fix for "dialog normalization gain removal".

hubblec4

27th September 2018, 15:32

Hi Mosu

I have some question about attachments. When I use MTX-GUI and add an attach file the MIME-Type is set automatically.
But when I create an mtxcfg can I scan/identify the attach file and mkvmerge tells me the MIME-Type?
When the MIME-Type is not set in an mtxcfg file, set mkvmerge this value automatically?

hubble

Mosu

27th September 2018, 15:56

But when I create an mtxcfg can I scan/identify the attach file and mkvmerge tells me the MIME-Type?
When the MIME-Type is not set in an mtxcfg file, set mkvmerge this value automatically?

There's no such functionality. However, you shouldn't need it that functionality as mkvmerge does indeed derive the MIME type automatically if it isn't set. The GUI allows for the MIME type to be empty, too, even though the drop-down box doesn't contain an empty entry. You can, however, simply remove the MIME type's name manually.

hubblec4

27th September 2018, 18:12

However, you shouldn't need it that functionality as mkvmerge does indeed derive the MIME type automatically if it isn't set.

That sounds great, thanks for your explanation.

hubblec4

27th September 2018, 18:21

I have a new PC and now the mtxcfg file have one line only. What was the way I have to go, so that mtxcfg file is human friendly readable?

Mosu

27th September 2018, 18:31

The environment variable "MTX_JSON_FORMAT" has to be set to "indented".

hubblec4

27th September 2018, 18:53

Thanks. After restart MTX it works.

hubblec4

28th September 2018, 16:23

After restart MTX it works.

That was not correct, I have to restart my PC. Why is this option so "complicated" to set up? Is there no way to have an option inside MTX?

Mosu

28th September 2018, 16:46

Regular users simply don't need this. It's meant solely for developers.

gpower2

29th September 2018, 09:21

The environment variable "MTX_JSON_FORMAT" has to be set to "indented".

That was not correct, I have to restart my PC. Why is this option so "complicated" to set up? Is there no way to have an option inside MTX?

You could set this option inside your code so that you won't have to change it manually.
In .NET you can use "Environment.GetEnvironmentVariable" and "Environment.SetEnvironmentVariable" in order to manipulate environment variables, I am pretty sure you could find the equivalents for the language you use. ;)

hubblec4

29th September 2018, 12:55

You could set this option inside your code so that you won't have to change it manually.
Thanks for this info, but I don't need it inside my code.
I don't use MTX-GUI since my chapterEditor is ready, but to see if my mtxcfg file is correctly created, I need the MTX-GUI to check this.

In .NET you can use "Environment.GetEnvironmentVariable" and "Environment.SetEnvironmentVariable" in order to manipulate environment variables, ....
Lazarus can also work with the "System Environments" but I don't like to set options in the system directly (like Windows registry).
chapterEditor stays portable and will never touch system entries, all settings can be stored in files.

@Mosu
What is with Linux and mtxcfg file, I think there is no environment variable which I can setup up, or?

Mosu

29th September 2018, 13:01

What is with Linux and mtxcfg file, I think there is no environment variable which I can setup up, or?

Huh? Of course you can set environment variables in Linux. Where exactly depends on the shell & desktop environment the user uses.

hubblec4

29th September 2018, 15:16

A suggestion. MTX uses an ini file, could you add there an option for this task?
Init is 0 for disabled human friendly readable and 1 for enabled.
A developer can change this setting easy and fast, and most important you don't have to restart the system.

lvqcl

29th September 2018, 15:28

and most important you don't have to restart the system.
Open command line window, set the environment variable, and start mkvtoolnix-gui.exe from that window. This should do the trick.

Mosu

29th September 2018, 15:58

I really don't see a reason to do anything in this regard. Setting an environment variable is trivial; logging out & back in again suffices; you usually only have to do it once per installation. And that's for the very few people who actually need that feature.

tkwou

29th September 2018, 20:32

Hi I've had to do OS re-install with Windows 2008 Server R2. I re-installed Mkvtoolsnix but now Mkvtoolsnix-gui.exe refuses to open. Mkvtoolsnix-gui ran fine before the OS re-install. Mkvmerge continues to work as my Ripbot264 still runs fine. I'm sure there must be a .dll dependency problem. I'm either missing or have the wrong versions of the necessary .dll's. Does it require a specific VC runtime version?

Mosu

29th September 2018, 20:37

It requires the Windows Media Foundation libraries to be installed. See this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/wikis/DLLs-not-found).

tkwou

29th September 2018, 22:35

mkver

29th September 2018, 22:41

Sounds like your Windows installation is corrupt. Run "sfc /scannow" in an elevated command prompt.

tkwou

29th September 2018, 23:27

I've already done that and it's passed verification.

Selur

2nd October 2018, 15:45

Seeing that some sides as elecard (https://www.elecard.com/videos) offer webm, I wonder is the webm spec for including av1 finished?

Mosu

2nd October 2018, 15:58

Kind of, yeah. Steve Lhommes pull request was merged to the Matroska specs a few weeks ago.

hubblec4

2nd October 2018, 16:23

Hi Mosu

I have some questions about two track flags: Default and Forced. (subtitle tracks)

If a Forced flag is set to true then a Player must use this track and have to ignore the Default track, right?
And I guess only one track should have that Forced flag set to true? If more Forced flags set to true, the first track wins?

Mosu

2nd October 2018, 17:21

Citing the specs for "forced":

Set if that track MUST be active during playback. There can be many forced track for a kind (audio, video or subs), the player SHOULD select the one which language matches the user preference or the default forced track. Overlay MAY happen between a forced and non-forced track of the same kind. (1 bit)

This means:

Multiple subtitle tracks can be played at the same time. In fact, the Matroska specs do not stipulate anything about the number of tracks of a type that can be active at the same time.
Forced tracks are not supposed to replace non-forced ones.
Multiple subtitle tracks can have the "forced" flag set. Think of Lord of the Rings when Elvish is spoken. You would likely have one forced subtitle track for each language Elvish is translated into. It's up to the player to select from all of those, most likely based on the track's language and the user's preferences regarding languages.

sneaker_ger

2nd October 2018, 19:30

Also note few (none?) players stick 100% to the specs in that regard.

magsoud

2nd October 2018, 23:44

Hi Mosu
Please Create mkvextract-gui.exe
https://pasteboard.co/HGEkYJ9.png

foxyshadis

3rd October 2018, 03:35

Thanks, I have Media Foundations installed with media streaming role installed. I'm getting "the program can't start because api-ms-win-core-libraryloader-l1-2-0.dll is missing from your computer. Try reinstalling the program to fix this problem"

I did some research, and it looks like these errors happen when your paths somehow point you to the wrong bitness of files, ie, 32-bit when you're using 64-bit software or vice versa.

sneaker_ger

3rd October 2018, 10:14

Hi Mosu
Please Create mkvextract-gui.exe
https://pasteboard.co/HGEkYJ9.png
See:
https://gitlab.com/mbunkus/mkvtoolnix/issues/1026

gMKVExtractGUI (https://forum.doom9.org/showthread.php?t=170249)
MKVcleaver (https://forum.doom9.org/showthread.php?t=152108)

Mosu

3rd October 2018, 10:21

Please Create mkvextract-gui.exe

I might, one day; there's even a feature request (https://gitlab.com/mbunkus/mkvtoolnix/issues/1026) open for it. But it really has no priority for me as there are several third-party alternatives available. sneaker_ger has linked to a couple already.

tkwou

9th October 2018, 18:27

I did some research, and it looks like these errors happen when your paths somehow point you to the wrong bitness of files, ie, 32-bit when you're using 64-bit software or vice versa.

Thanks foxyshadis. I considered that so I tried running "Dependency Walker". It's not showing any 32-bit 64-bit .dll mismatches when I open the mkvtoolnix-gui.exe.

Mosu

11th October 2018, 16:16

AV1 support in MKVToolNix is ready for testing. The input, output and parser code has been adjusted to the finalized AV1 bitstream spec as well as the codec mappings for AV1 in Matroska/WebM and MP4.

mkvmerge can read AV1 from Matroska/WebM, MP4, IVF files and raw OBU streams.
mkvmerge can write AV1 in both Matroska and WebM modes.
mkvextract can extract AV1 to IVF files.
The GUI knows about all of that.
The "--engage enable_av1" option was removed as support isn't experimental anymore.

Note that you need very new or even unreleased players in order to play back AV1 in Matroska/WebM (no matter if they were created by mkvmerge or by aomenc). I've successfully played content with:

VLC nightly 3.0.5-20181011-0535 (https://nightlies.videolan.org/build/win64/)
MPC-HC 1.8.3 (https://github.com/clsid2/mpc-hc/releases)

Test files were created with aomenc revision 7cae98f4e from 2018-10-03. MP4 test files were obtained from Youtube.

The latest continuous builds (Windows (https://mkvtoolnix.download/windows/continuous/), Linux (https://mkvtoolnix.download/appimage/continuous/)) contain the changes.

I appreciate testing, but reports, test files and any other kind of feedback. Thanks!

v0lt

14th October 2018, 10:43

The MKVToolNix incorrectly limits the size when splitting. I asked 4480M, but got 4486 MB.

Mosu

14th October 2018, 10:46

No, it doesn't. Read this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Splitting-imprecise), please.

Anakunda

18th October 2018, 09:57

Hi, is there an option for mkvmerge, that discards in final mux all chaptering info from source files?
That means one file, one chapter.

sneaker_ger

18th October 2018, 09:59

--no-chapters (https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.description.no_chapters) (needs to be applied for every input file that has chapters)

Anakunda

19th October 2018, 11:22

--no-chapters (https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.description.no_chapters) (needs to be applied for every input file that has chapters)

Tried that but some files still appear as two or more tracks so they do contain some internal indexing, tho mediainfo shows only one chapter.

mkver

19th October 2018, 12:05

Mosu

20th October 2018, 16:59

Hey,

here is MKVToolNix v28.0.0: the first release to support AV1 in its finalized form. mkvmerge can read it from Matroska/WebM, MP4, IVF container files and from raw OBU streams. mkvextract will extract it to IVF files. Apart from that a couple of bugs were fixed and usabitliy enhancements made.

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 28.0.0 "Voice In My Head" 2018-10-20

## New features and enhancements

* mkvmerge: AV1 parser: updated the code for the finalized AV1 bitstream specification. Part of the implementation of #2261 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2261).
* mkvmerge: AV1 packetizer: updated the code for the finalized AV1-in-Matroska & WebM mapping specification. Part of the implementation of #2261 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2261).
* mkvmerge: AV1 support: the `--engage enable_av1` option has been removed again. Part of the implementation of #2261 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2261).
* mkvmerge: MP4 reader: added support for AV1. Part of the implementation of #2261 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2261).
* mkvmerge: DTS: implemented dialog normalization gain removal for extension substreams. Implements #2377 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2377).
* mkvmerge, mkvextract: simple text subtitles: added a workaround for simple text subtitle tracks that don't contain a duration. Implements #2397 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2397).
* mkvextract: added support for extracting AV1 to IVF. Part of the implementation of #2261 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2261).
* mkvextract: IVF extractor (AV1, VP8, VP9): precise values will be used for the frame rate numerator & denominator header fields for certain well-known values of the track's default duration.
* mkvmerge: VP9: mkvmerge will now create codec private data according to the VP9 codec mapping described in the WebM specifications. Implements #2379 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2379).
* MKVToolNix GUI: automatic scaling for high DPI displays is activated if the GUI is compiled with Qt ≥ 5.6.0. Fixes #1996 (https://gitlab.com/mbunkus/mkvtoolnix/issues/1996) and #2383 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2383).
* MKVToolNix GUI: added a menu item ("Help" → "System information") for displaying information about the system MKVToolNix is running on in order to make debugging easier.
* MKVToolNix GUI: multiplexer, header editor: the user can enter a list of predefined track names in the preferences. She can later select from them in "track name" combo box. Implements #2230 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2230).

## Bug fixes

* mkvmerge: JSON identification: fixed a bug when removing invalid UTF-8 data from strings before they're output as JSON. Fixes #2398 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2398).
* mkvmerge: MP4/QuickTime reader: fixed handling of PCM audio with FourCC `in24`. Fixes #2391 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2391).
* mkvmerge: MPEG transport stream reader, teletext subtitles: the decision whether or not to keep frames around in order to potentially merge them with the following frame is made sooner. That avoids problems if there are large gaps between teletext subtitle frames which could lead to frames being interleaved too late. Fixes #2393 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2393).
* mkvextract: IVF extractor (AV1, VP8, VP8): the frame rate header fields weren't clamped to 16 bits properly causing wrong frame rates to be written in certain situations.
* mkvpropedit, MKVToolNix GUI's header editor: fixed file corruption when a one-byte space must be covered with a new EBML void element but all surrounding elements have a "size length" field that's eight bytes long already. Fixes #2406 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2406).

Have fun :)

sneaker_ger

20th October 2018, 17:05

Thx. Is AV1 as "simple" as VP9 or can we except as many bugs as with AVC and HEVC?

Mosu

20th October 2018, 17:17

AV1 is much, much simpler to handle (from the container POV) than AVC & HEVC. Doesn't mean there are or won't be any bugs.

Selur

20th October 2018, 17:22

Nice thanks for the release! :)

Cu Selur

Sparktank

21st October 2018, 07:09

Thanks for the update! Saw it on videohelp today.

Anakunda

21st October 2018, 11:01

It's completely normal to have more than one track and it has nothing to do with chapters. If mediainfo shows only one chapter, is it possible that you let MKVToolNix generate one chapter per appended file on the output tab (which generates one chapter even if no file has been appended)?

Yeah there's just one chapter

+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ Maximum EBML ID length: 4
|+ Maximum EBML size length: 8
|+ Document type: matroska
|+ Document type version: 4
|+ Document type read version: 2
+ Segment: size 107467001
|+ Seek head (subentries will be skipped)
|+ EBML void: size 4012
|+ Segment information
| + Timestamp scale: 10415
| + Multiplexing application: libebml v1.3.6 + libmatroska v1.4.9
| + Writing application: mkvmerge v28.0.0 ('Voice In My Head') 64-bit
| + Duration: 00:03:06.531243975
| + Date: Sun Oct 21 09:52:20 2018 UTC
| + Segment UID: 0x0b 0xda 0x42 0x28 0xa1 0xa6 0xd2 0x36 0x8a 0xb9 0x87 0x10 0x7b 0x5d 0x32 0x5e
|+ Tracks
| + Track
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 8584554008224039298
| + Track type: audio
| + Codec ID: A_PCM/INT/LIT
| + Default duration: 00:00:00.031250000 (32.000 frames/fields per second for a video track)
| + Language: und
| + Audio track
| + Sampling frequency: 96000
| + Channels: 2
| + Bit depth: 24
|+ EBML void: size 1060
|+ Chapters
| + Edition entry
| + Edition flag hidden: 0
| + Edition flag default: 0
| + Edition UID: 6837861688061832105
| + Chapter atom
| + Chapter UID: 2623445988119765238
| + Chapter time start: 00:00:00.000000000
| + Chapter flag hidden: 0
| + Chapter flag enabled: 1
| + Chapter display
| + Chapter string: 00:00:00.000
| + Chapter language: eng
| + Chapter atom
| + Chapter UID: 2179528021987700301
| + Chapter time start: 00:00:00.000746760
| + Chapter flag hidden: 0
| + Chapter flag enabled: 1
| + Chapter display
| + Chapter string: 00:03:18.907
| + Chapter language: eng
|+ EBML void: size 800
|+ Cluster

General
Unique ID : 15754770526983769576157346589482758750 (0xBDA4228A1A6D2368AB987107B5D325E)
Complete name : stereo-002.mka
Format : Matroska
Format version : Version 4
File size : 102 MiB
Duration : 3 min 6 s
Overall bit rate mode : Constant
Overall bit rate : 4 609 kb/s
Encoded date : UTC 2018-10-21 09:52:20
Writing application : mkvmerge v28.0.0 ('Voice In My Head') 64-bit
Writing library : libebml v1.3.6 + libmatroska v1.4.9

Audio
ID : 1
Format : PCM
Format settings : Little / Signed
Codec ID : A_PCM/INT/LIT
Duration : 3 min 6 s
Bit rate mode : Constant
Bit rate : 4 608 kb/s
Channel(s) : 2 channels
Sampling rate : 96.0 kHz
Frame rate : 32.000 FPS (3000 SPF)
Bit depth : 24 bits
Stream size : 102 MiB (100%)
Default : Yes
Forced : No

Menu
00:00:00.000 : en:00:00:00.000 / en:00:03:18.907

But in foobar I get
stereo-002 (72 samples)
stereo-002 (17906928 samples)

Is that a something kinda pregap?
How do I force mkvmerge to load the file in media player as one continuous track?

mkver

21st October 2018, 13:30

1. There are two chapters:

| + Chapter atom
| + Chapter UID: 2623445988119765238
| + Chapter time start: 00:00:00.000000000
| + Chapter flag hidden: 0
| + Chapter flag enabled: 1
| + Chapter display
| + Chapter string: 00:00:00.000
| + Chapter language: eng
| + Chapter atom
| + Chapter UID: 2179528021987700301
| + Chapter time start: 00:00:00.000746760
| + Chapter flag hidden: 0
| + Chapter flag enabled: 1
| + Chapter display
| + Chapter string: 00:03:18.907
| + Chapter language: eng

The last chapter begins at 746760ns (~71,68896 samples at 96kHz). The title of the chapter and the naming of the file suggests that this track corresponds to the second track of an album and that this track started at 3:18.907.
2. I don't know whether this a pregap or not. Actually, nobody could know given the information you provided. One could only guess. And judging by the sample rate it comes from some source other than an audio CD and I have no experience with such a format; in particular I don't know whether there is pregap is usual in these circles.
3. Could you describe in way more detail what your input files were and what your mkvmerge command was (you can go to multiplexer->show command line) and what you did expect and what happened instead? (I think I can already guess the answer to the last two questions, but not the other ones.)
4. a) mkvmerge cannot "force" any player to do anything.
b) Actually, having chapters doesn't mean that the file is discontinuous. A gap would mean that the file is discontinuous, but there is no reason to assume that there is a gap.
c) I don't know why foobar produces a gap between the two chapters. I thought that being an audio player, it is specifically designed for gapless playback so that even when different items of a playlist exist in separate files, they are played without gaps.

v0lt

21st October 2018, 14:11

No, it doesn't. Read this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Splitting-imprecise), please.
I understand why this is happening. MKVToolNix enlarges the file until the next keyframe appears.
But when I split a file by size, I want the file to be no more than the specified size. I would like the MKVToolNix should discard an incomplete group of frames.

Is it possible to do this file splitting mode?

Ex0rcist

21st October 2018, 14:15

Is there any mkv extractor which is capable of applying audio delay when extracting audio/video files?

Anakunda

21st October 2018, 14:18

@mkver: I don't say there's a gap, but indexing that makes a pregap. There's really one chapter but two atoms, call it microchapters, which foobar recognizes and splits to more virtual tracks. The more is weird where mkvmerge took the 72 samples microindexing, when the original chapters file was

CHAPTER01=00:00:00.000
CHAPTER01NAME=
CHAPTER02=00:03:18.907
CHAPTER02NAME=
CHAPTER03=00:06:25.427
CHAPTER03NAME=
CHAPTER04=00:10:17.116
CHAPTER04NAME=
CHAPTER05=00:14:05.803
CHAPTER05NAME=
CHAPTER06=00:16:24.609
CHAPTER06NAME=
CHAPTER07=00:18:57.094
CHAPTER07NAME=
CHAPTER08=00:23:33.412
CHAPTER08NAME=
CHAPTER09=00:27:11.547
CHAPTER09NAME=
CHAPTER10=00:30:01.174
CHAPTER10NAME=
CHAPTER11=00:36:00.533
CHAPTER11NAME=
CHAPTER12=00:39:47.218
CHAPTER12NAME=
CHAPTER13=00:44:49.312
CHAPTER13NAME=
CHAPTER14=00:48:18.312
CHAPTER14NAME=
CHAPTER15=00:51:15.781
CHAPTER15NAME=
CHAPTER16=00:58:06.358
CHAPTER16NAME=

Note there are no pregaps just true tracks boundings

mkver

21st October 2018, 15:38

This doesn't answer my questions: What input files did you give mkvmerge? What were your settings?
But it did give me a clue where the 72 samples came from: In Matroska, PCM data is not put in one gigantic block of data like in wav. Instead, it is put in smaller blocks and these blocks are interleaved according to their timestamps ("interleave" means that you put blocks with similar timestamp (even from different tracks) near to one another so that one could use a PCM track as an audio track for a video and play the file without having to constantly seek to the place where the audio is stored and back to the place where the video is stored). As the Mediainfo above says, there are 3000 samples per Matroska block. 3:18.907 at 96kHz are 19.095.072 samples or 6365 of these blocks of 3000 samples with a remainder of 72 samples. With normal tracks, one can't simply split inside a block -- they are like atoms for Matroska and mkvmerge (ok, there are exceptions: mkvmerge allows to strip DTS extensions away). One either has to keep a block in an output file or one doesn't keep said block in an output file when splitting (hypothetically one could use DiscardPadding, but that's not used...). But with PCM data, one could be more precise and split sample accurately, but apparently the tool you used for splitting (I guess it is mkvmerge, but you still haven't told me what you were actually doing!) didn't do it and simply splitted after 6365 blocks with 3000 samples each. The second chapter position (at 72 samples) corresponds to the start of the second track, the first chapter is just leftover from the last track.

The first block of PCM data to be kept has a precise timestamp of 3:18.90625. mkmverge allows up to 1 ms of deviation when determining which blocks to keep. As 3:18.90625 is less than 1ms away from 3:18.907, this block is kept.

Anakunda

21st October 2018, 15:43

Input files - chapters file and audio track (WAV)

--output stereo.mka stereo.w64 --split chapters:all --chapters chapters.txt --no-chapters

I still am sure PCM data can be cut accurately and not by blocks or rounded to frames like CDA.

sneaker_ger

21st October 2018, 15:50

JFYI: Input options belong before the respective input file, i.e.
--output stereo.mka --no-chapters stereo.w64 --split chapters:all --chapters chapters.txt
(I guess it doesn't matter here as w64 shouldn't have chapters.)

Anakunda

21st October 2018, 15:56

This reorder doesn't make any difference. I think there should be used something stronger than --no-chapters which suppresses any atomization.

mkver

21st October 2018, 16:10

Yes, it can. But this would involve writing code specifically for it and mkvmerge doesn't seem to have this code.
The --no-chapters option is actually an input file option, not an output file option, i.e. it discards chapters already in your input file, but leaves chapters that you explicitly add during the muxing process (e.g. by using a chapters file) alone. In this case this means that any chapters in your w64 file (there aren't any and I don't believe that w64 is able to contain chapters anyway) would be discarded.
I'll open an issue for the real problem (that PCM is not split sample-accurately, but only block-accurately), but I don't think that he will fix this. After all, this just affects PCM.

hubblec4

22nd October 2018, 10:53

Hi Mosu

I want replace an attachment with mkvpropedit.

"mkvpropedit.exe" "S01E00 - Hauptmenü.mkv" --replace-attachment name:"Matroska Medium Menu Config.mmmcfg"

I get always this error message

>"mkvpropedit.exe" "S01E00 - Hauptmenü.mkv" --replace-attachment name:"Matroska Medium Menu Config.mmmcfg"
Error: Invalid selector in '--replace-attachment name:Matroska Medium Menu Config.mmmcfg'.

What I'm doing wrong?
When I use the ID to replace an attachment, this works.

"mkvpropedit.exe" "S01E00 - Hauptmenü.mkv" --replace-attachment 1:"Matroska Medium Menu Config.mmmcfg"

Mosu

22nd October 2018, 11:03

The `--replace-attachment` option requires a selector and the name of the file to use instead. Both are separated by a colon.

In the case of `1:Matroska…` the selector is the 1 and the `Matroska…` is the file name. So far, so good.

When you type `name:Matroska…` the selector itself is just `name` and the new file name is `Matroska…`. However, `name` on its own is not a valid selector: it requires a colon and the name of the existing file to replace, meaning the full option would actually contain two colons:

--replace-attachment "name:old name:new file name"

hubblec4

22nd October 2018, 11:41

Thanks for this info, and maybe you should add this example to your mkvpropedit page (selectors (https://mkvtoolnix.download/doc/mkvpropedit.html#mkvpropedit.edit_selectors)).

hubblec4

22nd October 2018, 12:07

And for the MIME-type you have to use also 2 colons?

--replace-attachment "mime-type:mime-type-name:new file name"

Mosu

22nd October 2018, 12:20

Thanks for this info, and maybe you should add this example to your mkvpropedit page (selectors (https://mkvtoolnix.download/doc/mkvpropedit.html#mkvpropedit.edit_selectors)).

There is just such an example in the Examples (https://mkvtoolnix.download/doc/mkvpropedit.html#mkvpropedit.examples) section.

And for the MIME-type you have to use also 2 colons?

Yes.

hubblec4

22nd October 2018, 16:44

Hi Mosu

I have some trouble with mkvpropedit.exe. I would add Tags,Chapters and Attachments in one go to a very small mkv file.
All works fine when no chapters,tags and attachments are present in the mkv file. But when I repeat the same cmd the Tags are not present but there is a seek entry with a position value which is greater as the entire file.
When I change the size of tags and chapters(add tags and chapters) and use again the same cmd, then no chapters and no tags in the mkv file.

Here is a sample (https://forum.videohelp.com/attachments/47003-1540222580/mkvpropedit.7z) with two mkvpropedit.bat files. (maybe you have to change the path for mkvpropedit)

EDIT:
It seems mkvpropedit is OK, but the InfoTool in the GUI shows it not correct

mkver

22nd October 2018, 20:11

The relocation of level 1 elements to the end (if there is not enough space in front of the video clusters) is nothing new and I'm surprised that you didn't know about it. But now you seem to do. But I can't see what's supposed to be wrong with the InfoTool in the GUI. You should open an issue if you think that there is something wrong. (If you're believe that the discrepancy between the offsets in the file and the offsets in the seekheads are a bug: No, they aren't. The seekhead contains the offset relative to the first byte in a particular segment (i.e. the first byte after the length field of the segment). The same is used for the cues.)

Mosu

22nd October 2018, 20:49

mkver has already explained most of what's relevant. The only thing missing is an explanation why the command-line mkvinfo doesn't show elements at the end of the file by default: there's a FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Understanding-mkvinfo's-output) dedicated to it.

mkver

22nd October 2018, 21:02

EDIT:
It seems mkvpropedit is OK, but the InfoTool in the GUI shows it not correct
As you see, he actually said that the InfoTool in the GUI has a bug.
Btw: Why does mkvpropedit write two SeekHeads? Why doesn't it write one SeekHead with pointers to the relevant level 1-elements (which may very well be at the end of the file)? If there is enough space for a complete SeekHead at the beginning, there is no reason for a second SeekHead at all.
(I am speaking of normal situations, not situations where one wants to have the clusters referenced in the SeekHead, too.)

Mosu

22nd October 2018, 21:31

As you see, he actually said that the InfoTool in the GUI has a bug.

I've used the batch files provided by hubblec4, and both resulting files (batch 1 (https://mkvtoolnix.download/misc/hubblec4_mkvpropedit_1.mkv), batch 2 (https://mkvtoolnix.download/misc/hubblec4_mkvpropedit_2.mkv)) look just fine in both mkvinfo and the GUI's info tool. I don't know what he thinks the bug is.

Btw: Why does mkvpropedit write two SeekHeads?

Because at the point in time it needs to add an element to the seek head there isn't enough room to write the whole seek head at the front of the file. mkvpropedit does NOT try to optimize all the elements before the first cluster — instead it only tries to (re-)write the element it needs to update and maybe the meta seek. It will merge two or more consecutive EBML void elements if they're present or if they result from mkvpropedit's own action, but it won't move elements around in order to free up space. For example, if you have MetaSeek — Void — Tracks — Void — Chapters, it won't move the Tracks up or down in order to merge those two Voids.

Additionally, mkvpropedit doesn't batch changes. Meaning that if mkvpropedit will need to rewrite Tracks, Chapters and Attachments, it will first rewrite Tracks and fix up the MetaSeek for the newly written Tracks, then rewrite Chapters and fix up MetaSeek for the newly written Chapters etc. What usually happens is:

Layout could be something like MetaSeek — SegmentInfo — Tracks — Void — Clusters — Cues.
Let's assume you want to add chapters that fit into that Void and add a movie title (updating SegmentInfo); in that order. mkvpropedit will first write the Chapters there and shrink the void resulting in MetaSeek — SegmentInfo — Tracks — Chapters — Void — Clusters — Cues.
Now the newly added Chapters will have to be added to the Cues. As there's no place behind the existing MetaSeek, it will create a new MetaSeek entry at the end, move all level 1 references to the second MetaSeek and reduce the first MetaSeek to simply point to the second MetaSeek. There'll be new space behind the first MetaSeek. The result is: MetaSeek1 —Void — SegmentInfo — Tracks — Chapters —Void — Clusters — Cues — MetaSeek2.
Adding the title to SegmentInfo makes it larger. Let's assume the title is so long that adding the space from the Void before the SegmentInfo won't be enough; meaning SegmentInfo will be located to the back as well. Result: MetaSeek1 —Void — Tracks — Chapters —Void — Clusters — Cues — MetaSeek2 — SegmentInfo.
The reference to SegmentInfo is in MetaSeek2 before step 4. It has to be updated, but as the file position is now much larger, it won't fit into MetaSeek2 anymore. mkvpropedit will remove the reference from MetaSeek2 and include it in MetaSeek1 as there's more than enough space behind MetaSeek1 now. However, mkvpropedit will NOT simply move the whole of MetaSeek2 anywhere, even if the Void after MetaSeek1 would be big enough now to fit MetaSeek1+MetaSeek2 into; MetaSeek2 is here to stay (until you remux with mkvmerge). The final result is: MetaSeek1 —Void — Tracks — Chapters —Void — Clusters — Cues — MetaSeek2 — SegmentInfo.

If you want optimal layout, use mkvmerge.

hubblec4

22nd October 2018, 21:59

I've used the batch files provided by hubblec4, and both resulting files (batch 1 (https://mkvtoolnix.download/misc/hubblec4_mkvpropedit_1.mkv), batch 2 (https://mkvtoolnix.download/misc/hubblec4_mkvpropedit_2.mkv)) look just fine in both mkvinfo and the GUI's info tool. I don't know what he thinks the bug is.

Yes both files looks good in mkvinfo tool.

Here is a pic from mkvinfo tool for my Hauptmenü.mkv
https://forum.videohelp.com/attachments/47005-1540241468/mkvinfo-tool.PNG

You see there is no Level1 element Tags or Chapters.

Mosu, have you used batch file 1 twice and then batch file 2?

I do the following:
run batch 1 -> load mkv in mkvinfo looks fine
run batch 1 again -> load mkv in mkvinfo missing Tags element
run batch 2 -> load mkv in mkvinfo look at the picture.

Mosu

22nd October 2018, 22:10

Ah, no, I didn't run the first step twice. Yeah, that's a bug. Please file an issue over on Gitlab, but don't expect too timely a fix.

hubblec4

22nd October 2018, 22:30

Is this a bug in mkvinfo or mkvpropedit?

Mosu

22nd October 2018, 22:37

mkvpropedit

hubblec4

22nd October 2018, 23:28

Ah, no, I didn't run the first step twice. Yeah, that's a bug. Please file an issue over on Gitlab, but don't expect too timely a fix.

I have opened an issue (https://gitlab.com/mbunkus/mkvtoolnix/issues/2413) on Gitlab

I hope you can find quickly the bug, because it breaks a new feature for chapterEditor.

Occurs this issue because tags and chapters AND attachments at the same time are written?

mkver

23rd October 2018, 00:00

mkvpropedit
No, it's a bug in the mkvinfo GUI embedded in MKVToolNix GUI. The old (external) mkvinfo doesn't have this bug (click on pic to see it bigger):
https://i.imgur.com/y26XbtUl.png (https://i.imgur.com/y26XbtU.png)
It probably stops after finding the first void after the cluster or so.

Mosu

23rd October 2018, 15:18

No, it's a bug in the mkvinfo GUI embedded in MKVToolNix GUI.
It probably stops after finding the first void after the cluster or so.

Both of those are spot on. The issue's been fixed.

detroit1

23rd October 2018, 16:41

I am trying to use mkvtoolnix to join several 4K files

I notice it gives errors often and will not join the files

Most have the same profile mp4 with the same audio, some may not have any audio

I have a feeling it is the audio that is making it fail

What can I do to join the files without any problem

sneaker_ger

23rd October 2018, 17:13

I have a feeling it is the audio that is making it fail
The error messages should show you exactly which tracks they refer to. "Feeling" is no good.

detroit1

23rd October 2018, 17:48

Yes I looked at the log and my first file was 4096 and all others were 3840 so I converted the first file to 3840 and then did it again

no errors but early on the audio from the next file is playing in file before so it did not do it correctly

I am trying again now after deleting one of the files out

Mosu

23rd October 2018, 20:36

Hey,

due to an unfortunate bug in the AV1 sequence header parser in release 28.0.0, here's a small bug fix update: MKVToolNix v28.1.0.

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 28.1.0 "Morning Child" 2018-10-23

## Bug fixes

* mkvmerge: AV1 parser: fixed an error in the sequence header parser if neither the `reduced_still_picture_header` nor the `frame_id_numbers_present_flag` is set. Part of the fix for #2410 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2410).
* mkvmerge: AV1 parser: when creating the `av1C` structure for the Codec Private element the sequence header OBU wasn't copied completely: its common data (type field & OBU size among others) was missing. Part of the fix for #2410 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2410).
* mkvmerge: Matroska reader, AV1: mkvmerge will try to re-create the `av1C` data stored in Codec Private when reading AV1 from Matroska or WebM files created by mkvmerge v28.0.0. Part of the fix for #2410 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2410).
* MKVToolNix GUI: info tool: the tool will no longer stop scanning elements when an EBML Void element is found after the first Cluster element. Fixes #2413 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2413).

Have fun :)

Mosu

25th October 2018, 22:29

Hey,

unfortunately I have to release a third time within a week: this time due to a use-after-free bug in all programs that make up the MKVToolNix package. This type of vulnerability allows arbitrary code execution using specially crafted Matroska files. It was introduced in v5.5.0 and affects all following releases up to and including the latest one, v28.1.0. Hence today's bug fix release.

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 binaries as well as the Linux AppImage are available already. The maxOS binaries and 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 28.2.0 "The Awakening" 2018-10-25

## Bug fixes

* mkvmerge, mkvinfo, mkvextract, mkvpropedit, MKVToolNix GUI's info tool & chapter editor: fixed a case of memory being accessed after it had been freed earlier. This can be triggered by specially crafted Matroska files and lead to arbitrary code execution. The vulnerability was reported as Cisco TALOS 2018-0694 on 2018-10-25.

Have fun :)

Selur

28th October 2018, 06:57

Small question how to get the 'default' and 'forced' track info using 'mkvmerge --identify' ?
"I:\Hybrid\64bit\mkvmerge.exe" --identify "C:\Users\Selur\Desktop\Test.mkv"
returns:
File 'C:\Users\Selur\Desktop\Test.mkv': container: Matroska
Track ID 0: video (MPEG-4p10/AVC/h.264)
Track ID 1: audio (AAC)
Track ID 2: subtitles (SubStationAlpha)
Attachment ID 1: type 'application/x-truetype-font', size 221328 bytes, file name 'OpenSans-Semibold.ttf'
adding '--engage keep_track_statistics_tags', I get:
File 'C:\Users\Selur\Desktop\Test.mkv': container: Matroska
Track ID 0: video (MPEG-4p10/AVC/h.264)
Track ID 1: audio (AAC)
Track ID 2: subtitles (SubStationAlpha)
Attachment ID 1: type 'application/x-truetype-font', size 221328 bytes, file name 'OpenSans-Semibold.ttf'
Tags for track ID 0: 7 entries
Tags for track ID 1: 7 entries
Tags for track ID 2: 7 entries

Mediainfo returns:
Default : Yes
Forced : No
for each of the tracks.

In older versions I got something like (different file):
Track ID 1: video (V_MS/VFW/FOURCC, DIVX) [language:und display_dimensions:640x480 default_track:1 forced_track:0]
Track ID 2: audio (A_AAC) [language:und default_track:1 forced_track:0]
Track ID 3: subtitles (S_TEXT/UTF8) [language:chi default_track:1 forced_track:1
(seems like I totally missed that this output changed :))

Okay, forget that question, using '-F json' helps.

Cu Selur

Mosu

28th October 2018, 13:18

Yeah, the verbose identification format was removed in January. Use the JSON format for anything above the most basic track list.

mkver

28th October 2018, 15:01

@mosu: Your signature is outdated.

Ex0rcist

28th October 2018, 17:14

Repeating my question.

Is there any mkv extractor which is capable of applying audio delay when extracting audio/video files?

Mosu

28th October 2018, 17:18

mkvextract itself has no functionality for that. I don't know if any of the various GUIs out there does.

mkver

28th October 2018, 19:46

eac3to tries to do that, but if you don't want to reencode, then the precision with which you can do that is limited by the length of the audio packets of the format that you are extracting.

LeMoi

29th October 2018, 23:30

If I have a 3hr file and want to cut some part of it to have a 2hr one, AFAIK, I have to:
- open original_file.mkv
- cut with timecodes, for example I want to keep the parts 00:00:00.000-01:00:00.000,02:00:00.000-03:00:00.000
- then I have two 1hr files, original_file-001.mkv and original_file-002.mkv
- open the first one in the GUI, and append the second one, then mux and I'll have the 2hr original_file-001.mkv+original_file-002.mkv=target_file.mkv

Is there a way to skip the intermediate part1 and part2 files, and mux directly from original_file.mkv to target_file.mkv?
The app would read and mux the first hour, stop muxing and keep reading until the second hour, then restart to mux, in order to have only one final target file?
I know this is a feature request, AFAIK MKVToolnix GUI doesn't allow to do so, would it be possible to add this option in the future?

Thanks in advance!

hubblec4

30th October 2018, 01:12

Yes there is a way, insert a "+" in front of the second timestamp pair.

00:00:00.000-01:00:00.000,+02:00:00.000-03:00:00.000

mkver

30th October 2018, 01:18

Use "00:00:00.000-01:00:00.000,+02:00:00.000-03:00:00.000". (That's by the way included in both the ballon help in the GUI (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/po/fr.po#L6014) as well as in the documentation (https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.description.split). Where did you get the idea that it isn't possible from?)

mood

31st October 2018, 18:54

@Mosu

on windows 7 pro 32bit the mkvtoolnix-32-bit-28.2.0-revision-006 and revision-008 "mkvtoolnix-gui.exe" crash on startup

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

revision-005 works fine

mkver

31st October 2018, 20:34

@mood: This has just been fixed and the new continuous build is up (https://mkvtoolnix.download/windows/continuous/32-bit/28.2.0/).

mood

31st October 2018, 23:28

@mood: This has just been fixed and the new continuous build is up (https://mkvtoolnix.download/windows/continuous/32-bit/28.2.0/).

oh, oki, thanks...

when I made the post the lastest build it was revision-008

mkver

1st November 2018, 01:31

I know. Inspired by your post I made a bug report (https://gitlab.com/mbunkus/mkvtoolnix/issues/2424) on GitLab (that's the proper place for MKVToolNix bug reports) and mosu fixed it quickly.

LeMoi

1st November 2018, 13:35

Yes there is a way, insert a "+" in front of the second timestamp pair.

00:00:00.000-01:00:00.000,+02:00:00.000-03:00:00.000

Thanks for the tip!

zaemon

3rd November 2018, 14:03

Hello.

madshi has been working for some time now to improve HDR tone mapping in madVR. The relevant thread can be found on AVS forums. As of now, madVR is able to parse HDR files in order to measure nits content of files (thus producing an HDR measurement file). Me and others encountered problems with remuxes done with MKVToolNix, where the same remuxes done with MakeMKV were fine (MKVToolNix remuxes yielded incomplete HDR measurement files with seamless branched movies). madshi reported that the problematic remuxes done with MKVToolNix had weird timestamp.

At this point I'm switching to MakeMKV for all my future remuxes and will redo problematic remuxes (hopefully only seamless branched titles). I just wanted to make some people here aware of the "problem", maybe someone could investigate it further and fix whatever needs to be fixed (not saying something's wrong with MKVToolNix per se).

I'm willing to provide more information if someone requests it.

In a non related topic, my experience with MKVToolNix is that the tool is way slower than MakeMKV for the same task. MakeMKV is 2-3x faster for remuxing purpose. Does anyone noticed this?

Thanks.

zaemon

hubblec4

3rd November 2018, 19:20

MKVToolNIX(MTX) has indeed a small issue while muxing seamless branching discs.
https://gitlab.com/mbunkus/mkvtoolnix/issues/2051
A workaround is to process the audio streams with eac3to.
MTX is able to preserve multi edition seamless branching discs with the help of chapterEditor, Makemkv can't do this.

mkver

3rd November 2018, 20:56

@zaemon:
1. mkvmerge compresses the subtitles with zlib (to save some space), MakeMKV doesn't. This might make a bit of difference, but I don't think it could explain what you experienced.
2. What version of mkvmerge were you using to remux the files? Version 18.0 greatly improved the speed of remuxing H.264 and H.265 from unframed sources (everything except mp4 and mkv). And version 25.0 was the first (release) version that had a bug affecting seamless branching Blurays (https://gitlab.com/mbunkus/mkvtoolnix/issues/2321) fixed. I will test if newer versions of mkvmerge are still slower.
3. There might of course still be a bug in mkvmerge. And for this the right place is actually on GitLab (https://gitlab.com/mbunkus/mkvtoolnix/issues?scope=all&utf8=%E2%9C%93&state=all), not here in this thread. If you still have this bug with a recent version of mkvmerge (Here (https://mkvtoolnix.download/windows/continuous/) are the latest continuous builds of MKVToolNix. The very latest of it contains a new option should the GUI look bad because of High DPI stuff. (High DPI awareness has been enabled since version 28.0 and some users reported problems -- this does of course not affect the cli tools in any way.)) What you can do then: You can upload the output of mkvinfo -v -v -r <output.log> <Input.mkv>, where <Input.mkv> is once the file created by a recent version of mkvmerge and once the file created by MakeMKV. Upload it somewhere (normally, I'd say that you should upload it to the server (https://gitlab.com/mbunkus/mkvtoolnix/wikis/FTP-server) of the MKVToolNix author, but I want to look at it myself, so please upload it to somewhere where I can get it (you may of course also upload it to his ftp-server, too)). And if you want mosu to be able to take a look at it, you should upload the whole, unencrypted disc to his ftp-server.

PS: It would have been nice if you had directly linked to the avsforum thread (https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-129.html). Although I have to say that it really doesn't contain more relevant information than "Madshi said the timestamps are weird".

zaemon

4th November 2018, 00:06

Thanks to both of you. First I'll try the eac3to method. I think it will be useful to know out of the three methods which one works. Now again, I had no problem with MKVToolNix prior to doing measurement with madVR: no warning, no error, no playback issue. I wouldn't consider it a bug at this point. But it's a fact that MKVToolNix's seamless branched remuxes are not compatible with the current dev version of madVR regarding HDR measurement files.

As for speeds, this does not really concern me but I was just curious to know why there was so much difference with MakeMKV.

mkver

4th November 2018, 00:17

And which version of mkvmerge did you use?

hubblec4

20th November 2018, 03:32

Hi Mosu

I have opened a thread (https://forum.doom9.org/showthread.php?t=175889): And the WebM file (https://github.com/brenopolanski/html5-video-webvtt-example/blob/master/MIB2.webm) in this project (https://github.com/brenopolanski/html5-video-webvtt-example) could not be recognized by mkvmerge. Also the .vtt file (https://github.com/brenopolanski/html5-video-webvtt-example/blob/master/MIB2-subtitles-pt-BR.vtt) on this github project could not be loaded into MTX-GUI.
Could you have a look?

Mosu

20th November 2018, 14:28

Both the WebM file and the VTT file can be read & muxed by mkvmerge 28.2.0 just fine here. The resulting file plays fine in VLC; subtitles are shown.

Did you right-click & "save as" perhaps? That way you might end up with HTML code being downloaded, not the actual files.

hubblec4

20th November 2018, 16:32

Wow, thanks Mosu you are right, I saved it with a rigth-click.
I had never thought that this is the issue.

Mosu

1st December 2018, 13:10

Hey,

it's time for MKVToolNix v29.0.0 which fixes a couple of bugs and adds one or two new features.

There were two important changes for package managers regarding library dependencies. Please see the NEWS below for details.

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 29.0.0 "Like It Or Not" 2018-12-01

## Important notes

* The string formatting library used was switched from `boost::format` to [`fmt`](http://fmtlib.net/). See the section "Build system changes" for details.

## New features and enhancements

* MKVToolNix GUI: added an option in the preferences for disabling automatic scaling for high DPI displays. Implements #2415 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2415).
* MKVToolNix GUI: the GUI will now prevent the system from going to sleep while the job queue is running. This feature is implemented for macOS, Windows and Linux/Unix systems where the `org.freedesktop.login1.Manager` D-Bus interface is available. Implements #2411 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2411).

## Bug fixes

* mkvmerge: chapter generation: the start timestamps of chapters generated in intervals was wrong for files whose smallest video timestamp was bigger than 0. Fixes #2432 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2432).
* mkvmerge: MP4 reader: fixed handling of atoms whose size exceeds the parent atom's size. Fixes #2431 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2431).
* mkvmerge, MKVToolNix GUI's chapter editor: the chapter name template will now also be used when reading Ogg-style chapter files with empty chapter names. Fixes #2441 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2441).
* mkvextract: AAC: mkvextract will now write the program config element (PCE) before the first AAC raw data packet if the PCE is present in the `AudioSpecificConfig` structure in the `Codec Private` Matroska element. The PCE carries vital information about the number of channels and is required in certain cases. Fixes #2205 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2205) and #2433 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2433).
* mkvpropedit, MKVToolNix GUI's header editor: in situations when a one-byte space must be covered by a new EBML void element the following element must be moved up instead. If that moved element is a cluster, the corresponding cue entries will now be updated to reflect the cluster's new position. Fixes #2408 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2408).
* MKVToolNix GUI: Windows: the application manifest is now included properly so that Windows actually recognizes it. See #2415 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2415).

## Build system changes

* Qt's D-Bus implementation is now required for building on systems other than macOS and Windows,
* The `boost::format` library is not used anymore.
* The [`fmt` library](http://fmtlib.net/) is now required. Versions 3 and newer are supported. As not all Linux distributions include packages for the library, its release 5.2.1 comes bundled with MKVToolNix. The `configure` script will check for a system version of the library and use it if present and recent enough. Otherwise it will fall back to the bundled version and link that statically.

Have fun :)

kuchikirukia

16th December 2018, 02:53

I have some UI suggestions that might improve the usability of the GUI.
I've noticed the GUI is really big. I find myself moving it around the screen a lot to get behind it to get to Explorer to pick files to throw in it. The main snag with making the window smaller seems to be that you lose sight of the mux button and have to scroll down to find it. As soon as you collapse smaller than 678 pix high you start to lose those buttons.
If it's at all possible to move the buttons to the status bar it would fix this problem.

Here's the current smallest without getting any scroll bars:

https://i.postimg.cc/m2JhfTrS/default.png

Proposed change:

https://i.postimg.cc/y6r8c70z/changes.png

Buttons are moved to status bar.

Add Source Files label gets reduced to Add Files
Start Multiplexing label gets reduced to Start Mux
Add to Job Queue label gets reducted to Add to Queue
(so now the buttons can be a little smaller)

Jobs to Execute reduced to just Jobs
Automatic shortened to Auto
Warnings shortened to warn

This gives room for the buttons in the same space as the current default.

That would allow us to resize it vertically to this and still be perfectly usable:

https://i.postimg.cc/pTrpMrKq/small-with-jobs.png

And if it's at all possible to have the status bar UI collapse onto the "Jobs to execute" bar when resized horizontally, it could further be resized down to this:

https://i.postimg.cc/wTg39w51/small-change.png

The Jobs bar is nice but not exactly vital to the basic use, so collapsing down on it would lose almost nothing.

(Also, Save buttons would be nice on the chapter editor)

mkver

16th December 2018, 08:19

I find myself moving it around the screen a lot to get behind it to get to Explorer to pick files to throw in it.
My solution for this is to include MKVToolNix in the "Open with" list of the file types that are processed with MKVToolNix.

Mosu

16th December 2018, 11:20

I have some UI suggestions that might improve the usability of the GUI.

Thanks for the suggestions. I won't implement any of them as they aren't going in a direction I want to take the GUI in. I simply don't support such low resolutions.

manolito

16th December 2018, 11:51

I simply don't support such low resolutions.

I hope you don't mind if I call this attitiude "ARROGANT". Not everyone is in the situation to be able to afford a state of the art computer, graphics card and monitor like you.

kuchikirukia

16th December 2018, 13:01

Thanks for the suggestions. I won't implement any of them as they aren't going in a direction I want to take the GUI in. I simply don't support such low resolutions.

Resolution doesn't really do anything since nearly everybody scales their UI up to make it visible. My phone is 1080p and its screen is completely full from top to bottom with 20 icons. My desktop, on the other hand, can fit 50 icons on the taskbar and still have 1920x1050 area left over. It's screen size that gives real estate and most people aren't running something like this:

https://i.postimg.cc/13HydrnD/mjcqjfZ.jpg

The GUI would fit nicely in around 5% of that screen. But for the majority of us it takes up a third of our screens.

Perenista

16th December 2018, 17:09

What is going on?

First this https://forum.doom9.org/showpost.php?p=1860220&postcount=370

Now this, with the MKVExtractGUI2.exe:

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

Mosu

16th December 2018, 17:23

MKVExtractGUI2.exe is not part of MKVToolNix. It's a third-party application.

Mosu

16th December 2018, 19:08

I hope you don't mind if I call this attitiude "ARROGANT".

I very much mind. It isn't arrogant, it is necessary and normal. Every software developer out there places certain restrictions on what they support in their software, be it operating systems & their versions, the hardware (virtual or physical) its run on, or even the time of day it is run. It's simple logistics: every development team out there has a limited set of resources, both regarding money (in order to buy all the different equipment they have to support) and time (implementing stuff & hunting bugs takes a lot of time). Both of those resources are finite; hence decisions are made with respect to what a useful subset of all the requirements are that they can support with their current level of resources so that the most number of people benefit from it. It's always a trade-off.

MKVToolNix is basically a one-person project regarding coding — me. My time is very finite, and I have to chose carefully where to spend my time. And I've been spending my time on this fine piece of software that I offer you completely free of charge, free of any type of commitment, and I've been doing that for more than 15 years now. I've been gifting you countless hours of my time, no small amount of my wit, and you even get the whole source code to do with as you please.

And still you have the gall to call me arrogant when I decline to spend more of my free time on this piece of software, for which I'm not compensated, which I couldn't make a living off even if I wanted to, which solely benefits persons other than myself? Really? Statements such as yours are _the_ reason I and other open source software developers & maintainers often burn out.

All of this over an enhancement request? Really? It wasn't that the software didn't work form them; no, they simply didn't want to spend heir time scrolling in order to push buttons. But you expect me to spend my time improving your life. Don't get me wrong, it's 100% fine to ask about such a feature. That isn't arrogant. But not accepting me declining to do something for you for free? That is.

Apart from all of that: I wasn't kidding when I said that the suggestions lead in a direction I didn't want to take the GUI in. For example, I don't like using abbreviations all over the place. Abbreviations that may be obvious to you often aren't to other users. Placing buttons in the task bar is something I honestly haven't ever seen any program do — as a first-time user I would be very confused about them; even more so as those buttons only apply to the multiplexer tool whereas the whole status bar applies to all tools.

I simply don't consider those suggestions to be good, I don't consider them to be significantly helpful to a significant number of people, and I consider them to be detrimental or confusing to others. Not a good combination.

LeMoi

16th December 2018, 19:19

Thanks for the suggestions. I won't implement any of them as they aren't going in a direction I want to take the GUI in. I simply don't support such low resolutions.
Thanks :)

lvqcl

16th December 2018, 20:52

This reminds me of some discussions such as this (https://www.phoronix.com/forums/forum/software/distributions/974049-manjaro-linux-to-drop-32-bit-support) and this (https://www.reddit.com/r/linux/comments/4omfud/why_are_distros_starting_to_drop_x86_support/).
To quote a reddit user frome that thread:
Wow reading the comments there are a lot of people who feel entitled to someone else's time and work.

@Mosu: just disregard them.

Placing buttons in the task bar is something I honestly haven't ever seen any program do — as a first-time user I would be very confused about them; even more so as those buttons only apply to the multiplexer tool whereas the whole status bar applies to all tools.
+1.

manolito

16th December 2018, 21:05

I very much mind. It isn't arrogant, it is necessary and normal.

Sorry, I did not intend to insult you. All your points about providing free software are valid, and I am very grateful for software like MKVToolNix. And of course it is your baby, you are free to take it into any direction you want.

To make my view clear, I am a strong believer in sustainabilty, I believe that repairing hardware is better than throwing it into the trash bin. I believe that noone needs a new smartphone every year, and the same is true for computers and TVs and cars and whatever...

So remarks like "I simply will not support such low resolutions" or "I will not support such ancient OS like Win XP" do offend me. Apple was the company who introduced this attitude a long time ago, and this is the reason why I do not own any Apple products. Will your next move be to drop 32-bit support?

The problem with MKVToolNix is that over the years it has become a de-facto standard for dealing with MKV files. A lot of other software relies on it, and this "monopoly" is well earned (some MKV related things can be done with FFmpeg, but it is no match to MKVToolNix). But I believe that such a monopoly brings some obligations, even for free software.

So I do thank you very much for providing such a great tool like MKVToolNix, but I still wish that you would consider supporting users with older hardware or Operating Systems.

Cheers
manolito

kuchikirukia

16th December 2018, 21:12

Could we get an options page for changing keybinds? Resizing hiding the buttons wouldn't matter if I could just bind "mux" to mouse3 instead of CTRL-R.

Mosu

16th December 2018, 21:14

Could we get an options page for changing keybinds? Resizing hiding the buttons wouldn't matter if I could just bind "mux" to mouse3 instead of CTRL-R.

I have no intentions of implementing configurable key bindings. I would accept patches that implement this (= I'm not against such functionality, I just won't spend time on it myself).

Dulus_No

17th December 2018, 03:52

mkver

17th December 2018, 05:12

Same here on Win 7 x64. I only noticed it after reading your post. Using the continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/28.2.0) it seems that the commits from November 4th are to be blamed (or maybe it is an update to the other components that happened at the same time): g4fc889a6f (https://mkvtoolnix.download/windows/continuous/64-bit/28.2.0/mkvtoolnix-64-bit-28.2.0-revision-009-g4fc889a6f.7z) works well, ge8342d4d9 (https://mkvtoolnix.download/windows/continuous/64-bit/28.2.0/mkvtoolnix-64-bit-28.2.0-revision-020-ge8342d4d9.7z) does not. Disabling High DPI scaling seems to not affect this.

Mosu

17th December 2018, 09:53

I regularly update all the libraries I use for building MKVToolNix at the start of the month. The result is probably due to a newer version of one of the libraries involved in font rendering (Qt, freetype, pango, harfbuzz…). It's something you'll have to live with for the time being.

Edit: MKVToolNix doesn't mess with font settings apart from the most basic information. All it does is set the font's family name and its point size. The rest is up to the aforementioned libraries.

varekai

17th December 2018, 09:57

@kuchikirukia
It's screen size that gives real estate and most people aren't running something like this:

That picture is so cool, it's a keeper! Thansk! :D

nautilus7

18th December 2018, 02:17

Kerning with windows 10 is ok.

Anakunda

18th December 2018, 12:27

The --no-chapters option is actually an input file option, not an output file option, i.e. it discards chapters already in your input file, but leaves chapters that you explicitly add during the muxing process (e.g. by using a chapters file) alone. In this case this means that any chapters in your w64 file (there aren't any and I don't believe that w64 is able to contain chapters anyway) would be discarded.
I'll open an issue for the real problem (that PCM is not split sample-accurately, but only block-accurately), but I don't think that he will fix this. After all, this just affects PCM.

I'm only curious if the issue was already fixed in latest version. No mention in change logs. Are the dev at least aware of the oddness?

Mosu

18th December 2018, 12:56

I am aware of it, but I'm not willing to spend time on it.

hello_hello

18th December 2018, 18:33

I have some UI suggestions that might improve the usability of the GUI.

The SendTo folder should be your best friend. If you use a program regularly, there should be a shortcut for it in the SendTo folder (especially if there's no other Explorer menus). Mostly, have have to create them yourself though. I'm on XP, but my SendTo folder is almost a mini start menu (it contains sub-folders for less up/down scrolling, so many of the shortcuts can't be seen in the screenshot below).

https://i.postimg.cc/jSnhsTPT/XP-Send-To.gif

And.... there's much better file management programs than Explorer, and some are free. The "Lite" version is free.:)
https://www.zabkat.com/alldown.htm

Selur

21st December 2018, 05:43

Hi!
Got a file created with VideoReDo which contains S_DVBSUB subtitles.
Trying to extract the subtitles using:
"I:\Hybrid\64bit\mkvextract.exe" tracks "C:\Users\Selur\Desktop\Beispiel_DVB_SUBS.mkv" 3:"E:\Output\Beispiel_id_3_lang_de"
I get:
Error: Extraction of track ID 3 with the CodecID 'S_DVBSUB' is not supported.
Is there a trick to extractin/handling those subtitles? Or is this a missing feature? (only saw support for S_DVBSUB in mkvmerge mentioned in the changelog)

Cu Selur

mkver

21st December 2018, 07:04

There is no defined "raw" format for DVB subtitles; only the packetization inside transport streams (as PES packets) and inside Matroska is defined. Therefore you can't really extract these subtitles, because there is no format to extract them to. (One could of course create such a format. One could e.g. declare the stream of PES packets to be the raw format, similar to vobsubs. But the difference to vobsubs is that the latter is an established format, whereas the former would be a new creation by MKVToolNix. And why create such a format? It makes no sense. If you want to keep only the DVB subtitles inside a Matroska file, simply remux the file with only the DVB subtitles selected.)

Selur

21st December 2018, 15:49

Didn't know there is no defined raw format for those subtitles.
-> I will convert them to dvd subs (idx/sub). Thanks!

kuchikirukia

25th December 2018, 16:36

I've been running into an issue:

If you split a mkv at say 1:00, but there's an .ASS subtitle line running from 0:59 to 1:10, MKVToolNix will keep the entire length of the subtitle line, which makes the length of the first part 1:10 even though your audio and video were cut at 1:00. If you try to append the split segments together again the video will not append seamlessly. There'll be a gap and the time on players will jump ahead when they hit the gap.

Is there a way to hard cut the subtitle line at 1:00 or just ignore it so this doesn't happen?

sneaker_ger

25th December 2018, 17:00

No. Only way is to disable subtitles (and cut them externally with a different tool).

JackBauer

27th December 2018, 22:29

I just discovered this tool and I'm in love :)

Unfortunately though I can't figure out how to make the tool, by default, not select non-english audio and subs for when I multiplex.

Under Preferences: Multiplexer: Encoding items, I've selected the "only enable copying of tracks..." but when I load a mkv, all the other languages are still checked in the "copy item" column.

So I'm guessing I'm misunderstanding that configuration setting.

Some mkv's have a ton of subtitles, so I'm just trying to make it easier to strip some of them out rather than clicking on 20 lines. I figure there has to be a way, I'm just not getting it?

TIA :)

Mosu

27th December 2018, 22:42

In the preferences, select the "Multiplexer" → "Enabling items" pane. There:

Under "Enable copying of items by their type", make sure "audio", "video" and "subtitles" are actually selected (as this setting takes precedence over the language-specific setting insofar as deselecting e.g. "audio" here means audio tracks will never by selected, no matter their language and the enable-by-language settings).
Under "Enable copying of items by their language":
enable "only enable copying…"
for "always enable copying…" select "video" but neither "audio" nor "subtitles" and
select "English (eng)" in the language list.

JackBauer

27th December 2018, 23:15

In the preferences...

That did it.... Thank you very much!

Mosu

27th December 2018, 23:29

You're quite welcome.

algorithm_colon

30th December 2018, 13:03

There's been some noise recently about this (https://github.com/DolbyLaboratories/dlb_mp4base) tool from Dolby which can create Dolby Vision mp4 files. I was able to create a profile 7 file from a UHD disc backup which played succesfully with DV on an LG TV.
I was wondering if there's anything in the code that might provide some clues for getting Dolby Vision into mkv - after remuxing the mp4 with mkvtoolnix all of the dolby vision information is lost.

SeeMoreDigital

30th December 2018, 13:20

... I was able to create a profile 7 file from a UHD disc backup which played succesfully with DV on an LG TV.
..Are you able to upload a sample .mp4?

algorithm_colon

30th December 2018, 14:24

Here's (https://1drv.ms/u/s!Ag6hm31FMiVwjr8xOGQOZZARcUphkA) a 1 minute sample

SeeMoreDigital

30th December 2018, 17:15

Here's (https://1drv.ms/u/s!Ag6hm31FMiVwjr8xOGQOZZARcUphkA) a 1 minute sampleNice one,

I can confirm that your Dolby Vision .mp4 contained sample does indeed work with my LG television and my OPPO UDP-203 :)

MediaInfo detects the dedicated 'DVHE' meta-data as a separate video stream, which MKVmerge currently doesn't know what to do with. But this is a good start.

Perhaps you should also make jdobbs, the author of BD Rebuilder aware of information as he's intending to create an .m2ts muxer. Here's a link to his most recent post in his 'BD Rebuilder Beta' topic: https://forum.doom9.org/showthread.php?p=1861438#post1861438

UPDATE: I've just managed to add an LC-AAC audio track to your .mp4 sample using 'My MP4Box GUI' (with a new build of MP4Box)...

Cheers

gonca

30th December 2018, 23:05

Here is a link to a small discussion on this
https://www.makemkv.com/forum/viewtopic.php?f=12&t=18602

J-Wo

31st December 2018, 17:55

Running v29 x64 on an i5-8400 with 16Gb ram and Windows 10 Pro. When multiplexing a 30Gb 4K movie, I noticed in the task manager that my memory seems to max out at 50% (e.g. 8Gb/16Gb). Just wondering if this is the expected behavior and/or limitation of MKVMerge?

Thanks!

mkver

1st January 2019, 10:58

Normally, mkvmerge takes way less memory; there are basically two possibilities why this could happen:
a) Your file might contain only few frames that are detected as keyframes by mkvmerge so that mkvmerge has to buffer a lot of material before it can write it again. If so, then your source material might simply not contain a lot of keyframes; or they aren't detected by mkvmerge. The latter case would be a bug.
b) There is a memory leak going on. This would also be a bug.
If you want to help, you should upload the source file (not the remuxed file) to the server described here (https://gitlab.com/mbunkus/mkvtoolnix/wikis/FTP-server) and open an issue here (https://gitlab.com/mbunkus/mkvtoolnix/issues).

algorithm_colon

2nd January 2019, 08:18

Nice one,

I can confirm that your Dolby Vision .mp4 contained sample does indeed work with my LG television and my OPPO UDP-203 :)

MediaInfo detects the dedicated 'DVHE' meta-data as a separate video stream, which MKVmerge currently doesn't know what to do with. But this is a good start.

Perhaps you should also make jdobbs, the author of BD Rebuilder aware of information as he's intending to create an .m2ts muxer. Here's a link to his most recent post in his 'BD Rebuilder Beta' topic: https://forum.doom9.org/showthread.php?p=1861438#post1861438

UPDATE: I've just managed to add an LC-AAC audio track to your .mp4 sample using 'My MP4Box GUI' (with a new build of MP4Box)...

Cheers

The dolby tool can do audio as well, but of course mp4 won't hold truehd, hence my interest to see if this could work with mkv

Wakaku

3rd January 2019, 14:50

Happy New Year everyone, and thank you for such a superb Matroska software, MKVToolNix. I just want to ask if there's a way, without loading any file, to immediately start MKVToolNix GUI to a desired main tab instead of the default Multiplexer tab. Like if I want it to start at Header Editor tab immediately. Perhaps a command line option which could be put into a shortcut or batch file. For example if I could create different shortcuts (or shorcuts to batch files) yet pointing to the same mkvtoolnix-gui.exe.

Mosu

3rd January 2019, 15:17

Wakaku

4th January 2019, 09:46

Not without opening a file in the wanted too, no. The existing options can be found here (https://mkvtoolnix.download/doc/mkvtoolnix-gui.html), but they only have an effect if a file name is given after them, too.

OK thanks. Also thank you and everyone for considering Matroska rotation during playback. A really convenient and powerful container ability. :)

Mosu

4th January 2019, 14:31

Hey,

2019 is here along with the first release of MKVToolNix for the year, v30.0.0. It's on the smaller side wrt. the number of user-visible changes. It does contain a couple of usability enhancements for the GUI, though, that folks will hopefully appreciate.

Nothing has changed for package managers since v29.0.0.

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 30.0.0 "Interstellar" 2019-01-04

## New features and enhancements

* mkvextract: WAV extractor: mkvextract will now write W64 files instead of WAV files if the file name extension is `.w64` or if the final file size is bigger than 4 GB, the file size limit for WAV files. Implements #2458 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2458).
* MKVToolNix GUI: multiplexer: a new button was added next to the "destination file" controls. Clicking it shows a menu with the ten most recently used output directories. Selecting one of them will change the destination file to the selected directory keeping the file name. Implements #2468 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2468).
* MKVToolNix GUI: multiplexer (preferences): the ten most recently used values for the "relative output directory" and "fixed output directory" settings are now saved. The corresponding settings have been changed into combo boxes allowing quick access to those recent values.
* MKVToolNix GUI: multiplexer (preferences): the predefined split sizes and durations can now be customized in the preferences.
* MKVToolNix GUI: chapter editor: added an option in the "Chapter editor" menu for appending chapters from an existing file to the currently open editor tab. Part of the implementation of #2439 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2439).
* MKVToolNix GUI: chapter editor: added an action in the context menu for copying the selected entry and all of its children to another open editor tab. Part of the implementation of #2439 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2439).

## Bug fixes

* mkvmerge: all files opened for writing will now be flushed once before they're closed. This ensures the operating system actually writes all cached data to disk preventing data loss in certain situations such as power outages or buggy drivers in combination with suspending the computer. Fixes #2469 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2469).
* mkvmerge: AAC: under certain conditions 8 channel audio files were taken for 7 channel ones.
* MKVToolNix GUI: multiplexer: removing a file added as an "additional part" will no longer cause a crash. Fixes #2461 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2461).
* source code: fixed compilation with Boost 1.69.0 after API-breaking change to the `boost::tribool` class. Fixes #2460 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2460).

Have fun :)

manolito

4th January 2019, 16:34

Starting with this version 30.0.0 the old hack from this post:
https://forum.doom9.org/showthread.php?p=1813131#post1813131
to make the software work under Win XP is now history. The very latest version which works under XP after replacing the GUI with the old v. 10 GUI is v29.0.0. You can still download it here:

https://files.videohelp.com/u/172211/ToolNix_XP.zip

Cheers
manolito

/EDIT/
The archive was updated to also include the last Win7 compatible version (32-bit only)

filler56789

4th January 2019, 21:22

## New features and enhancements

* mkvextract: WAV extractor: mkvextract will now write W64 files instead of WAV files if the file name extension is `.w64` or if the final file size is bigger than 4 GB, the file size limit for WAV files. Implements #2458.

.
.
.

## Bug fixes

* mkvmerge: all files opened for writing will now be flushed once before they're closed. This ensures the operating system actually writes all cached data to disk preventing data loss in certain situations such as power outages or buggy drivers in combination with suspending the computer. Fixes #2469.

:goodpost: && :thanks:

mood

5th January 2019, 00:32

@Mosu

version 30 has a serious bug

Version 30 has a major bug that will delete your files! Unbelievable! If you use the chapter editor function and add New Edition Before or New Edition After and then add a subchapter, click save and watch your file size shrink to around 1-7 kb! Excellent(!)

I see this comment on videohelp (https://www.videohelp.com/software/MKVToolNix) site, I tested and it's true, reduced a file from 700 MB to 561 bytes

Mosu

5th January 2019, 00:36

Thanks for bringing it to my attention. I'll look into it tomorrow.

hubblec4

5th January 2019, 02:09

I have used a 7,5mb file only and there is no issue. (Win7-64 MTX-64bit)

hubblec4

5th January 2019, 03:40

Nice gif :-)

I believe you, but maybe it helps Mosu to identify to issue faster when he knows with small files seems to work.
I had added editions before and after and insert a chapter to this edition. Then I used the save item from the main menu and also try the "save in...." item but the files size don't changed.

Mosu

5th January 2019, 15:01

I can reproduce the problem if the file was created by Handbrake. I cannot reproduce such a problem with files created by MakeMKV, ffmpeg or mkvmerge. I haven't investigated yet what the difference is with Handbrake's files. If you want to be kept up to date, follow the issue I've opened (https://gitlab.com/mbunkus/mkvtoolnix/issues/2476).

As a workaround you can remux with mkvmerge before editing chapters.

Mosu

5th January 2019, 15:56

I've just committed a fix for the regression (v29 was ok; the problem was introduced during the implementation of appending chapters to open tabs for v30). I'll likely release v30.1.0 later today or tomorrow.

Mosu

5th January 2019, 17:30

Like I've stated above, the problem's already been fixed. The determining factor wasn't Handbrake vs. mkvmerge, but whether the source file contained chapters or not.

Mosu

5th January 2019, 17:39

Hey,

due to an unfortunate bug in v30.0.0 that caused the GUI's chapter editor to truncate Matroska/WebM files to a few KB, I have to release v30.1.0 today. This release also implements a workaround for dragging & dropping not working on macOS with Qt 5.12 (due to a bug in Qt).

Nothing has changed for package managers since v29.0.0.

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 30.1.0 "Forever And More" 2019-01-05

## Bug fixes

* build system: fixed building on non-UTF-8 locales. Fixes #2474 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2474).
* MKVToolNix GUI: multiplexer: implemented a workaround for drag & drop not working on macOS with Qt 5.12 due to a bug in Qt 5.12. Fixes #2472 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2472).
* MKVToolNix GUI: chapter editor: when opening a Matroska/WebM file that doesn't contain chapters and later saving chapters back to them, the editor was truncating the file down to a couple of KB in size. This was a regression introduced with the implementation of #2439 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2439) in v30.0.0 Fixes #2476 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2476).

Have fun :)

mood

5th January 2019, 17:40

Like I've stated above, the problem's already been fixed. The determining factor wasn't Handbrake vs. mkvmerge, but whether the source file contained chapters or not.

oki...

I tested with 30 rev 006 and work now without the bug

:thanks::thanks:

Edit....

You were faster to post than I was :)

Overdrive80

5th January 2019, 20:39

Hi Mosu, I uploaded video (at your FTP server) with issue in GUI when spanish language is set. With this problem is imposible to use the options of program. Regards.

Mosu

5th January 2019, 20:56

Well, your translations of some of the strings are too long. Try to make them shorter. Qt cannot wrap labels for checkboxes etc; therefore the minimum width of the right panel is however long the longest text shown in a single line.

Mosu

5th January 2019, 21:09

Overdrive80

5th January 2019, 21:16

BTW, your screen resolution is extremely low. As I've stated in other places, I don't support extremely low resolutions simply because I don't have the time to support every possible hardware out there. With Spanish as the language and the default font size of 9 points, the preferences dialog fits nicely into 975x535 pixels (including the title bar), which I consider to be good enough.

As with anything Open Source, if someone who cares about really low resolution wants to take this type of problem on and improve it: sure, knock yourself out! I'd welcome patches.

My resolution screen is 1920x1080, and video is cropped to dont show my desktop.

EDIT: If I can not see it, is really difficult to shorten the captions because horizontal scroll bar dont work properly.

I uploaded other video in HD.

EDIT2: If the size of the preferences window is enlarged, could not it be compensated?

Mosu

5th January 2019, 21:36

Uhm, if your desktop is larger than the window you've shown in the video, then just make the whole preferences window bigger.

Overdrive80

5th January 2019, 21:41

Uhm, if your desktop is larger than the window you've shown in the video, then just make the whole preferences window bigger.

Ups, I dont notice that I could resize preferences window. :stupid:

Solved, although the resizing of that window could be automated according to the length of the content?

Thanks.

EDIT: The translations are what they are, it is not my fault that my language uses more characters to express something that is shorter in English.

mood

10th January 2019, 00:52

@Mosu

Review on videohelp (https://www.videohelp.com/software/MKVToolNix) site

MKVToolNix 30.1.0 is still truncating some of the files i try to remux.
A 88 MB file became a 6MB file, after remuxing.

Use version 30.1.0 with caution!

73ChargerFan

10th January 2019, 06:22

mkver

10th January 2019, 12:38

@Mosu

Review on videohelp (https://www.videohelp.com/software/MKVToolNix) site
Is there a way to contact TuNK and ask him about more details? Was he really remuxing or did he just use the chapter/header editor? Can he provide sample files together with a description of what he did?

And would it be possible for the description on videohelp to also include that bug reports should be posted on the project's issue tracker (https://gitlab.com/mbunkus/mkvtoolnix/issues) where they are actually taken care of?

sneaker_ger

10th January 2019, 12:48

Unfortunately, he has disabled PMs on Videohelp.

Mosu

10th January 2019, 13:26

Resizing the GUI window seems weird. Minimum window size is 1152 x 715 - shorter than that and I lose the buttons and file entry box at the bottom.

Is there a minimum height for the mutliplexer/input/properties element? It won't shrink to less than 50% the height of the desktop.

The minimum height is calculated automatically from the minimum height of all the control on all the panels in all the tools. As soon as you shrink it below that height, the controls will stay at their height and scroll bars will be shown. Meaning no, you do not lose the buttons, but you may have to scroll in order to find them.

Back in the day the GUI did not allow shrinking below the minimum size. Users requested that I do allow that, and the scrollable panes were the compromise that enabled the change.

LouieChuckyMerry

15th January 2019, 15:24

First, many thanks to Mosu for MKVToolNix :thanks: . After stalling as long as possible, I've finally gotten around to upgrading from version 8.3.0 (I know, I know) and, wow, the new GUI is really, really functional after getting the hang of it. I've one question, though: Is there any way to set the field "Output/File title:" to always populate as blank (no text)? I can't find a setting for this; perhaps there's a command line I could set? Thanks for any help.

Mosu

15th January 2019, 15:32

Thanks for the praise.

The title is affected by the following two options in the preferences: "Multiplexer" → "Default values" → "Automatically set the file title from source files" and "Automatically clear the file title when the last file is removed".

LouieChuckyMerry

15th January 2019, 16:13

Thanks for the praise.

You're welcome, it's very well deserved.

The title is affected by the following two options in the preferences: "Multiplexer" → "Default values" → "Automatically set the file title from source files" and "Automatically clear the file title when the last file is removed".

Ahhh, I was misinterpreting the above emphasized text. Thank you for the clarification; unticking that option is exactly what I needed :) .

LouieChuckyMerry

16th January 2019, 13:51

OK, seems I've a second question: Is there any way to set the field "Input/Properties:/Track name:" to always populate as blank (no text) for each track?

Mosu

16th January 2019, 13:59

No. The track name will be set if and only if the source file contains a track name. This is done so you can actually remove an existing track name by blanking the prefilled name.

LouieChuckyMerry

16th January 2019, 14:42

Damn, I though MKVToolNix could do everything ;-) . Thanks for the answer, Mosu, be well.

Mosu

16th January 2019, 14:55

If you don't like track names at all, you could set up a script to run after each job has completed (see preferences) that uses mkvmerge & mkvpropedit in order to remove any existing track names in the output file just created. MKVToolNix does provide all the mechanisms for automating nearly anything you would want to do, but you'll have to invest a bit of your time to tailor it to your specific needs.

LouieChuckyMerry

16th January 2019, 15:28

If you don't like track names at all, you could set up a script to run after each job has completed (see preferences) that uses mkvmerge & mkvpropedit in order to remove any existing track names in the output file just created.

OK, it's seems that is does do everything ;) . It's only sometimes that I want to clear the track names; is it possible to run the script manually? Ahhh, I'll check the Help file...

Mosu

16th January 2019, 15:45

LouieChuckyMerry

16th January 2019, 16:15

You can define actions to run after job completion. Each action can be configured to be run automatically or on demand only. However, you'll have to activate the action to run while the job is running — currently there's no way to run an action on a job that has already completed (at least not from the GUI).

When I have a job queue that's a season (or several seasons) of a TV show, the only thing I (sometimes, not always) want to do is clear the video and-or audio track names ("Input/Track name:"). I don't quite understand what you meant by the above emphasized text. Sorry I'm a bit slow; I'm still in therapy from trying to learn AviSynth five years ago...

Mosu

16th January 2019, 16:23

LouieChuckyMerry

16th January 2019, 16:56

In the "job output" tool there's a button called "When finished…" with which you can tell the GUI to execute a pre-configured action after the currently running job (or the whole queue) has finished. Using that button is what I meant.

What you cannot do, at the moment, is go to the "job queue" tool and execute a pre-configured action from there, e.g. for a completed job.

Thanks for the clarification, now I understand.

For your use case I'd simply write a script that iterates over all files in a certain folder, uses "mkvmerge --identification-format json --identify currentfile.mkv" in order to query track IDs and properties and then calls "mkvpropedit currentfile.mkv --edit track:… --delete name --edit track:… --delete name…" for all tracks that do have names set. That's assuming all of your files for a specific season (or show) end up in the same folder, but no other files are present in said folder.

I've gone to "Preferences/Jobs & jobs queue/Executing actions/+ Add action", selected "Execute a program" and named it "ClearTrackName(s). My destination folder is "C:\Users\...\Desktop\MKVTempNix". I understand how a command line works, in its most basic sense, but not how to use it. That is, I can copy and paste your above text but don't understand how-where to place the folder path or how to call "mkvpropedit". I tried:

C:\Users\...\Desktop\MKVTempNix\mkvmerge --identification-format json --identify currentfile.mkv mkvpropedit currentfile.mkv --edit track:… --delete name --edit track:… --delete name…

but received a "Program execution failed" message.

Mosu

16th January 2019, 17:00

What you're trying to do cannot be expressed as a simple one-liner. You'll have to write a full script to do what I said. Here's (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Batch-muxing-with-the-GUI#more-advanced-processing) an example of a Ruby script doing something else you can use as a basis to get started.

LouieChuckyMerry

16th January 2019, 17:04

Ooh boy, I'm going to have to double my therapy sessions (or up my Bitburger intake). I'll spend some time trying to figure this out, Mosu, thank you so much for your time :) .

Mosu

16th January 2019, 17:55

You're quite welcome.

Flash_Git

25th January 2019, 20:11

Since the release of 30.0.0 (including the latest) fonts have looked terrible on macOS (Mojave).

http://www.framecompare.com/image-compare/screenshotcomparison/YDDPNNNX

Mosu

25th January 2019, 20:23

Yeah, that's a known problem with Qt 5.12.0 on macOS. Qt 5.12 has other issues, too, but it does solve the very real issue of 5.11 not being usable at all on Mojave in dark mode. Meaning I'll stick with 5.12. I'll definitely update Qt as soon as new versions come out.

Your options are, obviously:

Stay with a version before v30.
Stay with a version after v30 and live with the bad font rendering.
Compile MKVToolNix v30.1.0 yourself against Qt 5.11.x (MKVToolNix is fully compatible with earlier Qt releases down to 5.3 or so).

hubblec4

25th January 2019, 20:59

On my Windows7 with font Segoe UI, many labels have spaces in the names, this come from QT5.12?

Mosu

25th January 2019, 21:46

No, the Windows builds are still using 5.11.x. It was another updated library that's causing this.

mariner

26th January 2019, 09:11

Here's (https://1drv.ms/u/s!Ag6hm31FMiVwjr8xOGQOZZARcUphkA) a 1 minute sample

Thank you, algorithm_colon.

leon

28th January 2019, 01:52

Is it possible to make mkvmerge completely abort muxing in case of a warning?

Mosu

28th January 2019, 18:39

Is it possible to make mkvmerge completely abort muxing in case of a warning?

No. At the moment there's no option for that. I might add one, though. Please file a feature request over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/). Otherwise chances are I might forget about it again. Thanks.

leon

31st January 2019, 11:26

No. At the moment there's no option for that. I might add one, though. Please file a feature request over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/). Otherwise chances are I might forget about it again. Thanks.

Somebody's already done it(Thanks): https://gitlab.com/mbunkus/mkvtoolnix/issues/2493
Thanks for considering this.

mkver

1st February 2019, 20:02

Something's wrong with kerning on v29.0.0: http://www.framecompare.com/image-compare/screenshotcomparison/W67WNNNX
OS is Windows 8 x64, font is Segoe UI.
System information: https://pastebin.com/h4e0RECr
The kerning problem is gone since the first continuous build after 30.1 (https://gitlab.com/mbunkus/mkvtoolnix/commit/8cde39725e19267325ac7e0933fe214cf788786a). Incidentally, this commit is about qt, but updating the qt requirement alone can't fix this; there was an update of qt (or some other stuff that has something to do with font rendering) at the same time, wasn't there?

Mosu

1st February 2019, 20:31

Yep, I did update my MXE build environment on 2019-01-06, and the first continuous build after after 30.1.0 (not the one for 30.1.0, though) seems to have been done with the updated environment. MXE did update the HarfBuzz (https://www.freedesktop.org/wiki/Software/HarfBuzz/) library, among other things, within the timeframe.

Incidentally, this commit is about qt

That commit only updated the documentation & the check in "configure". The change that actually triggered higher Qt requirements went in before release 30.0.0 already. That commit is completely unrelated to the issue at hand.

tormento

3rd February 2019, 07:49

@Mosu I dunno if it's related to your suite or the specific app, anyway, could you please get a look at that (https://forum.doom9.org/showthread.php?p=1863191#post1863191)?

Mosu

3rd February 2019, 12:39

@Mosu I dunno if it's related to your suite or the specific app, anyway, could you please get a look at that (https://forum.doom9.org/showthread.php?p=1863191#post1863191)?

That's definitely due to what that application does. I cannot help you with it.

Mosu

9th February 2019, 12:31

Hey,

I've just released MKVToolNix v31.0.0 which fixes a couple of issues, especially drag & drop support in combination with Qt 5.12 and newer. Note that the addition of flushing cached data on closing files introduced in v30 has been reverted due to detrimental behavior; an additional command line option has been added to make mkvmerge flush its buffers for those who need it.

Nothing has changed for package managers since v30.1.0.

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 31.0.0 "Dolores In A Shoestand" 2019-02-09

## New features and enhancements

* all programs: added a new option `--abort-on-warnings` that will cause the program to abort after it has emitted the first warning, similar to how it aborts after the first error. Implements #2493 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2493).
* mkvmerge, mkvextract: when closing files that were opened for writing, cached data will not be flushed to storage automatically anymore. This reverts the workaround implemented for #2469 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2469). A new option was added to both programs (`--flush-on-close`) that re-enables flushing for people who are affected by data loss such as described in #2469 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2469).
The reason is that automatic flushing causes long delays in processing queues when the output by mkvmerge/mkvextract isn't the final product but just an intermediate result to be processed further.
Implements #2480 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2480).
* MKVToolNix GUI: multiplexer: the dialog previewing different character sets for text subtitles will now keep the position of the displayed text when switching between character sets. Implements #2489 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2489).

## Bug fixes

* mkvmerge: AVI reader: using DV type 1 AVIs will now result in an unsupported file type being reported (as the underlying AVI library doesn't support them) instead of crashing mkvmerge. Fixes #2491 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2491).
* mkvmerge: HEVC: the height of interlaced streams will now be set correctly to the height of the full frame instead of the height of a single interlaced field. Fixes #2446 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2446).
* mkvmerge: MP4 reader: edit lists consisting solely of elements that mkvmerge doesn't support (such as dwells) are simply ignored. Before no data was read for such tracks at all. Fixes #2487 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2487).
* mkvmerge: text subtitles: entries with an explicit duration of 0ms will now be handled correctly: the 0ms duration will be stored in Matroska instead of the difference between the current and the following entry. Fixes #2490 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2490).
* MKVToolNix GUI: multiplexer, chapter editor: fixed drag & drop handling with Qt 5.12.0 and newer. Fixes #2472 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2472).
* MKVToolNix GUI: multiplexer: the GUI did not clean up temporary files created when running `mkvmerge`. Fixes #2499 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2499).

## Build system changes

* Qt 5.4.0 or newer has required (up from 5.3.0) since version 30.0.0; I just forgot to include this entry.

Have fun :)

mkver

9th February 2019, 21:20

Note that the addition of flushing cached data on closing files introduced in v30 has been reverted to do detrimental behavior;
Interesting. I didn't now you had such a destructive nature. :devil:
(You wanted to write "due to", didn't you?)

Mosu

9th February 2019, 21:27

LOOOOOOL I did indeed :D "due to" is obviously the intended wording :)

sneaker_ger

9th February 2019, 21:38

I've just released MKVToolNix v31.0.0
* MKVToolNix GUI: multiplexer: the dialog previewing different character sets for text subtitles will now keep the position of the displayed text when switching between character sets. Implements #2489.
Thank you.

mkver

9th February 2019, 21:58

LOOOOOOL I did indeed :D "due to" is obviously the intended wording :)
It happens to me all the time, too. See for example my recent PR for mkvalidator (https://github.com/Matroska-Org/foundation-source/pull/39): Despite rereading it repeatedly I let an unused variable slip through and had to reword the commit message.

Danette

10th February 2019, 16:47

sneaker_ger

11th February 2019, 16:45

Danette

11th February 2019, 19:06

That is already the default behavior. Are you sure your source files actually have chapters as defined in the Matroska spec and not just e.g. Segment Titles?

Upload sample files and your complete command if necessary.

@Mosu:
Maybe it would make sense to add a <SEGMENT_TITLE> variable to --generate-chapters-name-template

Thanks for the reply. I'll upload a sample as the next step, if you still think it necessary. However, here is what the XML file contains:

<?xml version="1.0"?>

<Chapters>
<EditionEntry>
<EditionUID>17724414706209801463</EditionUID>
<ChapterAtom>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterUID>16958226351709810015</ChapterUID>
<ChapterDisplay>
<ChapterString>Chapter Name Test</ChapterString>
<ChapterLanguage>und</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
</EditionEntry>
</Chapters>

Note that the chapter name is entitled: "Chapter Name Test".

Mosu

11th February 2019, 19:32

I am merging various mkv files. Each file has a chapter name. When I add/append the files, the output does have the various chapter times correctly placed, but the chapter names disappear. Is there some way to merge these files and retain the chapter names within each file so I don’t have to manually re-enter the name for each one?

Sounds a bit like all the chapters in the source files have the same chapter UIDs. Can you extract chapters from each of the file and upload them to my server, please?

Danette

11th February 2019, 22:34

Sounds a bit like all the chapters in the source files have the same chapter UIDs. Can you extract chapters from each of the file and upload them to my server, please?

You are right: many of the xml files have the same ChapterUID (all made with the MKVtoolnix chapter editor). The only difference is in the ChapterString, which contains the chapter name. I could upload them, but that is what you would see.

As I see it, being able to specify the ChapterString in the name template would fix it. I suppose that @sneaker_ger was suggesting.

leon

16th February 2019, 18:02

* all programs: added a new option `--abort-on-warnings` that will cause the program to abort after it has emitted the first warning, similar to how it aborts after the first error. Implements #2493.

That was fast. Thank you.

Megalith

23rd February 2019, 01:49

Is there an ETA on when the auto-sorting option (e.g., automatically move video files to the top of list) will be added to MKVToolNix?

Mosu

23rd February 2019, 14:43

No. Whenever I have free time and feel motivated to tackle it. Thing is, it isn't a trivial change.

wonkey_monkey

23rd February 2019, 20:31

A warning, as people still seem to be posting directly to threads and may not be aware:

It appears that the forum may have been hacked. There is a suspicious "test" announcement, apparently from tebasuna51 (but probably not), parts of the forum are not working, and there appear to be some malicious javascript files.

I'm not speaking in any official capacity here, but I would recommend, at the very least, NOT entering your password anywhere on Doom9 for the time being.

Please refer to this post: https://forum.doom9.org/showthread.php?goto=newpost&t=176128

LeMoi

26th February 2019, 19:52

Sometimes I make a mistake when I encode a video and I forget to crop, I just realize after I mux.
So I do a reencode of the video with the proper crop settings, I remove the muxing job from the queue and re-edit it in MKVToolNix GUI, but it doesn't reload the properties of the files, and if I just remux the files, the ratio of the muxed file is wrong... (ie old 16/9 instead of new 2.35). I have to remove the video track from the list and re-add it to get the new properties.
Is it possible that, when I edit a job and remove it from the queue, MKVToolNix GUI re-checks the properties of the files? while keeping the settings like delay, track name, etc.?

Mosu

26th February 2019, 20:23

Is it possible that, when I edit a job and remove it from the queue, MKVToolNix GUI re-checks the properties of the files? while keeping the settings like delay, track name, etc.?

No, that's not possible at the moment, and it would require quite a lot of work to implement. Not something I'm willing to spend time on.

LeMoi

27th February 2019, 08:49

OK, no problem, you're the programer, I thought it would be easier to reload the files, I'll wait until you change your mind :)

Wakaku

8th March 2019, 06:33

Thank you for implementing "emoji" support. No more "black diamonds with white question marks". All areas seems covered (eg. input of/output to emoji filenames, Header editor tags, retaining XML tags, covers). Thus such metadata can now be preserved. Output MKV is playable without problems in MPC-HC, MPC-BE, PotPlayer, KMPlayer, VLC. :)

Mosu

12th March 2019, 23:05

Hey,

Here's MKVToolNix v32.0.0, a really small bug fix release, the most important probably being the handling of Unicode code points > U+ffff (e.g. Emojis). For that to work a bug-fixed libEBML is also needed, which is why libEBML v1.3.7 is now required. It was released earlier today.

Other than that nothing has changed for package managers since v31.0.0.

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 32.0.0 "Astral Progressions" 2019-03-12

## New features and enhancements

* mkvinfo: when sizes are output the size of the element's data portion is output in addition to the element's total size.
* MKVToolNix GUI: info tool: the element's data portion is shown as an extra column.
* MKVToolNix GUI: multiplexer: added column "Delay" to the track list containing the additional delay to apply during multiplexing. Implements #2506 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2506).

## Bug fixes

* all: fixed handling of Unicode code points > U+FFFF. Fixes #2516 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2516).
* mkvmerge: Windows: mkvmerge was crashing with an exception when trying to identify certain files that can be used on Blu-rays (such as MPEG transport streams of MPLS play list files) and when the file name was given as a UNC path (e.g. `\\servername\sharename\path\to\file.m2ts`). The GUI emitted errors such as "the JSON output could not be parsed" in that case. Fixes #2507 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2507).
* MKVToolNix GUI: the portable mode wasn't detected correctly when the current working directory the GUI was started from wasn't the directory the GUI's executable file was located it. Examples for when this is the case are Windows' "send to" or "open with" functions. Fixes #2501 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2501).
* MKVToolNix GUI: multiplexer: using button to change the current destination directory to one of the recently used ones did not update the file name according to the "make file name unique" setting. Part of the fix of #2519 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2519).
* MKVToolNix GUI: multiplexer: the function "set destination file name from selected file's name" will now only change the destination file's name but not its path. Part of the fix of #2519 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2519).

## Build system changes

* libEBML v1.3.7 and libMatroska 1.5.0 are now required as they fix their handling of Unicode code points > U+FFFF (see #2516 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2516)).

Have fun :)

hubblec4

12th March 2019, 23:40

Thanks a lot.

robena

20th March 2019, 21:13

Hi,

I'm tying to use mkvmerge in command line mode, inside some scripts I wrote to automatize remuxing MKV files originating from Blu-rays.

I'm working with an overclocked 6 core cpu on Windows 7, and on a RAID system that can read and write at around 500 Mbs.

When I use MKVtoolnixG, Processhacker shows that remuxing runs at about 180MB/s, which is much faster than the drive speed, and remuxing a 60GB file is pretty fast.

If I display the command line, and cut and paste it into a DOS windows, and run it manually, I get barely 25MB/s, and muxing if much much slower.

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

Why, and how can I get back the full speed from the command line?

Mosu

20th March 2019, 21:24

… remuxing runs at about 180MB/s, which is much faster than the drive speed …

I'm pretty sure you're experiencing the nice effects of caching. If you really want to make speed comparisons, you'll have to re-run the same test multiple times in sequence and discard the first run (e.g. in the GUI add the same job three times and then let the whole queue run to finish; only take the time of the second & third run).

The most important thing is to flush all the caches to disk after completing one test and before moving on to the next. Otherwise the OS will still be busy writing data from the first test to disk while you're already running the second test. That will severely skew the results in favor of the first test, obviously.

In fact, real testing should look ideally look something like this:

Flush all cached data to disk
Run the test and…
Flush all cached data to disk directly afterwards

I cannot tell you how to do 1, but mkvmerge itself can do steps 2 and 3 if you add the command line option "--flush-on-close". In that case the time mkvmerge reports will be the real duration of one round of multiplexing. Of course you must add that option both in the GUI as well as on the command line; both tests must use identical options.

Again, the test is worthless if 1. (flushing before muxing) isn't done.

In the end using the GUI and using mkvmerge directly cannot produce different results as the GUI does nothing more than starting mkvmerge with the command-line parameters you can see via "Multiplexer" → "Show command line". There's no secret option, no additional setup the GUI does.

Benchmarking is real hard.

robena

20th March 2019, 22:53

In the end using the GUI and using mkvmerge directly cannot produce different results as the GUI does nothing more than starting mkvmerge with the command-line parameters you can see via "Multiplexer" → "Show command line". There's no secret option, no additional setup the GUI does.

Benchmarking is real hard.

That's a very logical answer, but unfortunately it's not a caching problem.

Muxing with the GUI is always at least 5 times faster, whether I start it first or second.

I did multiple tests like:

1) command line
2) GUI
3) command line
4) GUI

and the result are consistent every time, the GUI is much faster.

Besides, these are UHD very large 60GB files, so memory caching would be filled up very fast.

When I copy a 60GB file from my RAID to a SSD, I see first (sometimes) 1.5Gbs speed, but after a few gigabits, the caching ends and it goes down to the real disk speed.

With the GUI, the whole 60GB run at the same fast speed from beginning to end.

With the command line cust & pasted, the whole 60GB run at the same very slow speed, even if I run it after the GUI run. I just redid the GUI first, command line second second test, and the command line was easily 5 times slower.

Edit: I used the sysinternals "sync -r" command to flush all the drives before each run, same results.

Here is the command line:

"C:/Program Files/MKVToolNix\mkvmerge.exe" --ui-language en --output ^"B:\prob\test3\Lord of War UHD ^(1^).mkv^" --no-subtitles --language 0:eng --track-name ^"0:MPEG-H HEVC Video / 71269 kbps / 2160p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 10 bits / HDR10 / BT.2020^" --default-track 0:yes --language 1:eng --track-name ^"1:Dolby TrueHD/Atmos Audio / 7.1 / 48 kHz / 4750 kbps / 24-bit^" --default-track 1:yes --language 2:eng --track-name 2:AC3 ^"^(^" ^"B:\prob\test3\Lord of War UHD.mkv^" ^"^)^" --language 0:und ^"^(^" ^"B:\prob\test3\Lord of War UHD.sup^" ^"^)^" --language 0:und ^"^(^" ^"B:\prob\test3\Lord of War UHD-grey.sup^" ^"^)^" --title ^"Lord of War ^(2005^)^" --flush-on-close --track-order 0:0,0:1,0:2,1:0,2:0

I am at a complete loss to explain that.

Mosu

20th March 2019, 23:23

robena

20th March 2019, 23:39

Are you writing to the same file in each iteration? If so you're likely incurring a lot of time from simply deleting the existing huge output file. That's a rather slow operation on NTFS.

I can reproduce your results somewhat, but not if each call to mkvmerge writes to a different file that doesn't exist yet.

So… add "remove output file, flush all of Windows' caching (e.g. by rebooting)" to your list of things to do before each run.

Like I said, proper benchmarking is hard.

I did both, either writing the same file after deleting, or letting the GUI increasing the (N) number.

You probably did not see my edit while writing your answer, I found out how to flush all the drives without rebooting with the sync command.

Also, aside these specific tests, I made scores of command line remuxes that were all always extremely slow, and every time I try the GUI, it's 5 time faster. At first I though I was writing poorly my scripts (which I did with the doc, not by looking at the command line in thr GUI), and rewrote them to have the exact same syntax as the GUI. It did not help, and I think that the use of the sync command and of different file names rules out caching.
I also tried to read on one drive and write on another, with exactly the same difference in speed. My RAID is very good at parallel accesses (unlike regular hard drives), I barely notice a difference when using the 2 drives strategy.

Anyway, thanks for spending time on that subject.

robena

20th March 2019, 23:56

Another thing: this seems to happen only with UHD HEVC video files.
I did not notice my scripts being slow with 50GB regular HD AVC files. Even weirder!

robena

22nd March 2019, 07:54

So, nobody has an idea why this is happening, and how to correct it?

Dulus_No

23rd March 2019, 19:20

Hi!
I've encountered a strange behavior of SPS/PPS duplication when merging and extracting an avc stream.
Used commands:
mkvmerge -o ldaQLGOoJW0_1.mkv ldaQLGOoJW0.avc
mkvextract ldaQLGOoJW0_1.mkv tracks 0:ldaQLGOoJW0_1.avc
mkvmerge -o ldaQLGOoJW0_2.mkv ldaQLGOoJW0_1.avc
mkvextract ldaQLGOoJW0_2.mkv tracks 0:ldaQLGOoJW0_2.avc
mkvmerge -o ldaQLGOoJW0_3.mkv ldaQLGOoJW0_2.avc
mkvextract ldaQLGOoJW0_3.mkv tracks 0:ldaQLGOoJW0_3.avc
H.264 analysis: https://imgur.com/a/rPWNZdm
7z archive with source and result files: https://mega.nz/#!J1hASKpA!VLINH3Ie2vigG5f_8XT6pUCS_NYlA8q9fbA3xiOBZGI

Mosu

23rd March 2019, 19:29

Yeah, my tools are definitely not trying to deduplicate SPS & PPS (or VPS for HEVC). Instead, they try to achieve best playback compatibility (including seeking to arbitrary places) while not complicating the code too much.

Mosu

23rd March 2019, 19:37

So, nobody has an idea why this is happening, and how to correct it?

One last idea: when starting mkvmerge manually, do you perchance start it with a lower process priority (e.g. because the process you start it from, such as cmd.exe, is already running with a lower process priority)? Or do you start the GUI (and therefore mkvmerge-started-from-the-GUI) with a higher one? See Windows 10's task manager's "detail" page, right-click on the column header & enable the "base priority" column.

Perenista

23rd March 2019, 21:14

robena

23rd March 2019, 21:19

One last idea: when starting mkvmerge manually, do you perchance start it with a lower process priority (e.g. because the process you start it from, such as cmd.exe, is already running with a lower process priority)? Or do you start the GUI (and therefore mkvmerge-started-from-the-GUI) with a higher one? See Windows 10's task manager's "detail" page, right-click on the column header & enable the "base priority" column.
Thanks, I already tried that. I also verified the processor affinity.

I start it 2 ways: normally using a REXX interpreter that I wrote (my scripting language of choice, having worked with an IBM mainframe in the 80s) which does a direct CreateProcess() call without using the Windows cmd.exe. My interpreter has a routine allowing to set the priority, and it changes nothing. I integrated the calls into the shell, so I just have to right click on a file and choose the aspect ratio to create sup files with the command line version of tsmuxer correctly placed at the bottom of the video, and remux then automatically. I get details from the processed files with (again) the command line version of mediainfo. It's a one click process, and why I want to use the command line. Without a script to handle every thing, the GUI would be much easier, but very far from a one click process.

And in case it was my interpreter the culprit, by cutting and pasting the command line as is from the GUI into a DOS window, and checking the priority of the mkvmerge process running with the task manager.

So, still a headscratcher. :)

mkver

24th March 2019, 11:52

It's odd. I tried to add a dubbing to a Matroska video and told MKVToolnix to add + 7000 ms as delay, to sync said dubbing audio (AC3) with the video. This time didn't work. However when I open MPC-HC (and both files at the same time) and add 7000 ms manually the audio matches. Now it seems 7000 ms is too much because the audio is still 0.5 second or 1 second out of sync.

(I know the best way to do this is adding these +7 seconds in the dubbing audio and then adding to the MKV without any delay option enabled in MKVToolnix. The problem is that I might have to do this with subtitle streams, too, so it would be a hassle if this didn't work in all cases.

Maybe this time didn't work because 7 seconds is too much?
Is your audio an AC3 elementary stream (that doesn't have explicit timestamps, so that its first audio frame gets a timestamp of zero by default) or a Matroska file (or another container)? If so, what is the lowest timestamp of said audio file? And what about the timestamps of the other file (only the first few timestamps are of interest here)? See my answers here (https://gitlab.com/mbunkus/mkvtoolnix/issues/2174) for a possible reason why this is happening.

robena

28th March 2019, 16:08

mkver

28th March 2019, 16:28

What about the actual CPU time used by the underlying mkvmerge process for each task? Does it make a difference when started from the GUI?

Perenista

29th March 2019, 03:47

Is your audio an AC3 elementary stream (that doesn't have explicit timestamps, so that its first audio frame gets a timestamp of zero by default) or a Matroska file (or another container)? If so, what is the lowest timestamp of said audio file? And what about the timestamps of the other file (only the first few timestamps are of interest here)? See my answers here (https://gitlab.com/mbunkus/mkvtoolnix/issues/2174) for a possible reason why this is happening.I did more tests and 19 others (and different ones) were perfectly fine. There were times I even added 7000 or more than 8000 ms in terms of delay.

The file number 20 was the one with this issue. However I managed to figure out the correct delay to insert: 6350 ms. I checked at the beginning and after 58 minutes and now it's 100% OK. Not sure what went wrong before.

The audio stream I was trying to correct the sync (to be added in my Matroska video) is AC3:

Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
File size : 352 MiB
Duration : 1 h 49 min
Overall bit rate mode : Constant
Overall bit rate : 448 kb/s

Audio
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Duration : 1 h 49 min
Bit rate mode : Constant
Bit rate : 448 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 44.1 kHz
Frame rate : 28.711 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 352 MiB (100%)
Service kind : Complete Main

Info about the MKV:
https://pastebin.com/U4beAwL1

mkver

29th March 2019, 05:32

1. This is actually not all the data I wanted, because it doesn't tell me anything about the first few timestamps of Matroska file. Use mkvinfo -s -r <output log> <Matroska file> for this; only the first few (say, the first second) of timestamps is of interest here.
2. And you used the elementary stream during determining the offset? Not the stream remuxed into Matroska or so? (Seeking in elementary streams that don't provide timestamps is a PIA, so it is often not instantaneous.)

dREV

29th March 2019, 10:25

Hello, not sure if this has been brought up or not. I wanted to bring an issue that I wanted to clarify or just ignore. I made a post on mkvtoolnix page a few months ago asking about this but was told to come here instead to ask my question. Not sure if I should also post this on HEVC's thread as well?

I use an older version of mkvmerge (prefer simple gui then the new one) and also tried the latest portable of version 32.0.0 "Astral Progressions" 64 bit and both still got the same results.

My issue is concerning HEVC's implementation of the code when viewed in Media Info. It's "total-frames=". As I cut frames with Avisynth then append them together to fix problematic scenes, however, when muxing I would receive these messages only on HEVC.

#version 8.3 "Over the Horizon" 64 bit version

mkvmerge finished with a return code of 1. There were warnings, or the process was terminated

Warning: The track number 0 from the file 'C:\Users\Public\# 000\4003, 4146) #banding\# 000 4003, 4146) #banding.mkv' can probably not be appended correctly to the track number 0 from the file 'C:\Users\Public\#000\0, 4002) #Combined\# 000 0, 4002) #Combined.mkv': The codec's private data does not match (lengths: 2277 and 2278). Please make sure that the resulting file plays correctly the whole time. The author of this program will probably not give support for playback issues with the resulting file.

# version 32.0.0

--- Warnings emitted by job 'Multiplexing to file "# 000 - done.mkv" in directory "C:\Users\Public"' started on 2019-03-29 02:14:27 ---The track number 0 from the file 'C:\Users\Public\# 000\4003, 4146) #banding\# 000 4003, 4146) #banding.mkv' can probably not be appended correctly to the track number 0 from the file 'C:\Users\Public\# 000\0, 4002) #Combined\# 000 0, 4002) #Combined.mkv': The codec's private data does not match (lengths: 2277 and 2278). Please make sure that the resulting file plays correctly the whole time. The author of this program will probably not give support for playback issues with the resulting file.

I understand there's no support for the older mkvtoolnix version but as I wrote it's carrying on in the latest. If I try to mess with the total frame line via command line's in MeGUI for HEVC it'll stop working.

When appending then muxing them together regardless of how many frames there are in total now it'll only go by the first mkv cut (ex: frames 0, 4003) and will display that under media info ignoring the appended frames added.

# HEVC x265 3.0_Au+14-c7e5878bdd31

Encoding settings : cpuid=1111039 / frame-threads=3 / numa-pools=12 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=3 / input-res=1440x1080 / interlace=0 / total-frames=4003

So my question is, should I just ignore this as thus far there's been no issues during playback. Is this even an issue or not? It's kinda odd that it's able to recalculate the "Bits/(Pixel*Frame)" for the complete frame count of the video (at least I believe it's so) likewise with H264 but not do the same with HEVC's "total-frames=". There's no issues when doing these cuts/appends on H264 since it doesn't exist there.

Hopefully devs know what I am talking about concerning this and clue me in. :confused:

sneaker_ger

29th March 2019, 11:12

manolito

29th March 2019, 15:04

sneaker_ger

29th March 2019, 17:33

"sky", "oil". 2 words that are not identical but both have length of 3 letters. ;)

mkver

29th March 2019, 18:45

You can use e.g. ffmpeg's trace_headers bitstream filter to see what is in the relevant parameter sets: ffmpeg -i <Inputfile> -c copy -bsf:v trace_headers -t <appropriately short time like 0.1> -report -f null -

robena

29th March 2019, 21:02

What about the actual CPU time used by the underlying mkvmerge process for each task? Does it make a difference when started from the GUI?

No, it's pretty low in both cases, below 20%. None of the 6 cores goes over 50%.

mkver

29th March 2019, 21:41

dREV

30th March 2019, 05:17

You can ignore this in this case as long as the rest of the x265 settings are identical. It's not an issue. The "encoding settings" line you see in MediaInfo is x265's custom "SEI". It's only for information, not part of any standard. Mkvmerge will never alter it in any way. The bitrate on the other hand is taken from Matroska statistic tags (when present) which are in fact updated when appending.

When appending mkvmerge compares the header data of both tracks. When they are not identical it displays a "warning" that there might be a problem. It doesn't actually check whether or not the files are compatible in any meaningful way.

OK. :thanks: Should I post this in HEVC thread to let them know about this? Seems like an oversight for those who cut frames.

This is my experience,too, using H.264 streams.

I often add 5 seconds of blank video with silent audio to the beginning and the end of my converted MKV files, and as long as I create the "Silence" file with exactly the same settings as the movie then MKVMerge has no complaints.

But recently I noticed that after replacing x264.exe with a newer build I do get these warnings about the codec's private data not matching. The weird thing is that the lengths are identical so I really do not see any mismatch.

The combined file plays perfectly, but just to be on the safe side I reencoded the "Silence" file using the newer x264 build, and the warnings disappeared.

I too use .h264 streams and don't receive that. At least with version 8.3 64 bit. I don't get those when appending files together either in .h264 streams or mkv. Even when I've accidentally muxed in the wrong frames it gave me no warning about that. So that's odd you are receiving that. Have you by accident changed the x264 settings from one set of frames to the next? I've accidentally done that and would receive that message as well and as sneaker_ger wrote seems to be so. The x264 I'm using is x264 core 152 r2851kMod ba24899. http://komisar.gin.by/.

I think I tried updating to the newer ones but I think MeGUI couldn't use it since I'm using an old version (ver 2525) in order to still use .h264 streams via DGI as lsmash takes a bit longer to index.

sneaker_ger

30th March 2019, 07:40

OK. :thanks: Should I post this in HEVC thread to let them know about this? Seems like an oversight for those who cut frames.
Let who know? It's not a bug.

robena

30th March 2019, 09:24

I actually meant the accumulated CPU time, i.e. for the whole remuxing, not at a single instant in time. If the average CPU utilization is the same in both cases, but the CLI version uses it longer, then that would be really strange.
Well, I not sure how to measure it precisely, but since the CLI lasts 6 times more with about the same average, the accumulated should be higher.
If you know a tool to measure the accumulated time of a process, I'll make the measurement.
Anyway, I have decided to replace my DAS by another NAS, more powerful with a 20Gbs aggregated Ethernet link, so the problem will be soon moot I hope.

hello_hello

30th March 2019, 11:17

This is my experience,too, using H.264 streams.

I often add 5 seconds of blank video with silent audio to the beginning and the end of my converted MKV files, and as long as I create the "Silence" file with exactly the same settings as the movie then MKVMerge has no complaints.

But recently I noticed that after replacing x264.exe with a newer build I do get these warnings about the codec's private data not matching. The weird thing is that the lengths are identical so I really do not see any mismatch.

The combined file plays perfectly, but just to be on the safe side I reencoded the "Silence" file using the newer x264 build, and the warnings disappeared.

I always include --stitchable in the x264 command line. I never know when I'm going to need to split off a bit off an encode and re-do it to fix a problem and/or do some appending.

For reasons I don't understand, when x264 is writing directly to MKV, or you're appending MKV's, the warning is more likely to occur.
I've never understood why sometimes I can extract the raw h264 streams from each MKV to be appended (after MKVToolNix produced the codec private data warning), append the raw streams, and if the encoder settings were identical sometimes that'll make the codec private data warning go away, even if --stitchable wasn't used.

I'm happy to learn why... should anyone would care to explain.

Cheers.

PS. I'm using x264 core 155 r2901 7d0ff22 (with 32 bit MeGUI), as last time I tried to upgrade it, the newer x264 wouldn't run on XP. Is that still the case with the latest version?

sneaker_ger

30th March 2019, 12:36

Mkvmerge displays a warning if "CodecPrivate" element of 2 (or more) mkv files you wish to append aren't identical. "CodecPrivate" is an element of a Matroska container (https://matroska.org/technical/specs/index.html#CodecPrivate). So if you append 2 raw H.264 streams there is no "CodecPrivate". So there is no warning. The underlying problem remains the same, though.

Note that x264cli behaves a bit different depending on how you output:
to .mkv: H.264 headers (SPS/PPS) only at beginning of file
to .264: SPS/PPS at every keyframe
The latter can mitigate problems when appending files with different headers because the decoder can always access the correct PPS/SPS.

Note that not using --stitchable doesn't necessarily make files incompatible. But I think it is indeed a good idea to activate in case you want to make editing later.

manolito

30th March 2019, 12:48

PS. I'm using x264 core 155 r2901 7d0ff22 (with 32 bit MeGUI), as last time I tried to upgrade it, the newer x264 wouldn't run on XP. Is that still the case with the latest version?

The behavior I was talking about happened with LigH's latest build r2969 under Win7-64. My XP computer does not really handle HD sources. The latest x264 version which runs under XP and does not need SSE2 is 0.148.2579.0 from 2015.

I never used the --stitchable parameter in x264 because at the time when I created this "Silence" clip I used the same x264 build which was used for the movie conversion. The warning started to appear after I updated x264 to a newer build. For the movie conversion the parameters were absolutely identical. So I believe that every new build probably creates different "private data" even when identical parameters are used.

Maybe mkvmerge should be a little less strict when it issues this warning...

Cheers
manolito

dREV

30th March 2019, 14:01

Let who know? It's not a bug.

To the HEVC developers.

I also did a test by doing two different frames. Cutting one with (0, 1) and the other with (2, 900) and the info showed total frames= 899 so I wanted to know what the documentation means by https://x265.readthedocs.io/en/latest/cli.html

If --total-frames is 1, then a stillpicture variant will be signaled, but this parameter is not always set by applications, particularly not when the CLI uses stdin streaming or when libx265 is used by third-party applications.

So wanted to let them know for those who cut frames and append and see if it wasn't an oversight.

The behavior I was talking about happened with LigH's latest build r2969 under Win7-64. My XP computer does not really handle HD sources. The latest x264 version which runs under XP and does not need SSE2 is 0.148.2579.0 from 2015.

Didn't know you use XP. I'm on Windows 7 so I see why I am not expiriencing the same issue as you're going through.

mkver

30th March 2019, 14:03

Well, I not sure how to measure it precisely, but since the CLI lasts 6 times more with about the same average, the accumulated should be higher.
If you know a tool to measure the accumulated time of a process, I'll make the measurement.
Anyway, I have decided to replace my DAS by another NAS, more powerful with a 20Gbs aggregated Ethernet link, so the problem will be soon moot I hope.
The easiest way to measure this is by using the Taskmanager: Make it show the CPU Time of your processes and take a look at the value of this counter right before the process ends.
(This is not a perfect benchmark: If a process takes (say) 10 % of a core's CPU time, then after 10s the CPU time will be 1s higher -- regardless of whether your CPU is currently running at its maximum/default frequency or not.)

filler56789

30th March 2019, 15:23

PS. I'm using x264 core 155 r2901 7d0ff22 (with 32 bit MeGUI), as last time I tried to upgrade it, the newer x264 wouldn't run on XP. Is that still the case with the latest version?

When you try to run x264.exe on its own, i.e., "outside of" MeGUI,
what is the error message(s) that Windows XP returns? :confused:

robena

30th March 2019, 21:02

The easiest way to measure this is by using the Taskmanager: Make it show the CPU Time of your processes and take a look at the value of this counter right before the process ends.
(This is not a perfect benchmark: If a process takes (say) 10 % of a core's CPU time, then after 10s the CPU time will be 1s higher -- regardless of whether your CPU is currently running at its maximum/default frequency or not.)

I used something more precise, the command:

typeperf "\Process(mkvmerge)\% Processor Time" -si 10 -o mkvmerge.txt

For the command line, directly cut pasted form the GUI, I got a file that looks like:

"(PDH-CSV 4.0) (Romance Standard Time)(-60)","\\NT\Process(mkvmerge)\% Processor Time"
"03/30/2019 19:58:15.817"," "
"03/30/2019 19:58:25.822","96.552356850679971"
"03/30/2019 19:58:35.824","96.859476872593547"
"03/30/2019 19:58:45.826","98.107263033370458"
"03/30/2019 19:58:55.828","97.327396077620293"
.....
"03/30/2019 20:28:15.975","97.483370443431511"
"03/30/2019 20:28:25.977","98.107263033370458"
"03/30/2019 20:28:35.978","98.112168754568174"
"03/30/2019 20:28:45.981"," "
"03/30/2019 20:28:55.983"," "

The sum of all not NULL times was: 16144.6679175611
Elapsed time was 19:58:25 -> 20:28:45, 32m20s

Then, I ran the GUI, after a "sync" command and got:

"(PDH-CSV 4.0) (Romance Standard Time)(-60)","\\NT\Process(mkvmerge)\% Processor Time"
"03/30/2019 20:51:55.756"," "
"03/30/2019 20:52:05.760","35.717906573357453"
"03/30/2019 20:52:15.762","31.818571794606637"
"03/30/2019 20:52:25.774","28.514617588198405"
.....
"03/30/2019 20:57:25.883","34.470119444157191"
"03/30/2019 20:57:35.885","37.121667093707742"
"03/30/2019 20:57:45.888"," "

Total CPU time was: 1017.40205400394
Elapsed time was 20:52:05 -> 20:57:45, 5m40s

As you can see, both the elapsed time and the CPU usage are way lower from the GUI.

hello_hello

30th March 2019, 21:33

The behavior I was talking about happened with LigH's latest build r2969 under Win7-64. My XP computer does not really handle HD sources. The latest x264 version which runs under XP and does not need SSE2 is 0.148.2579.0 from 2015.

I never used the --stitchable parameter in x264 because at the time when I created this "Silence" clip I used the same x264 build which was used for the movie conversion. The warning started to appear after I updated x264 to a newer build. For the movie conversion the parameters were absolutely identical. So I believe that every new build probably creates different "private data" even when identical parameters are used.

I assume the timeline went something like this:

1: x264 doesn't optimize global stream headers
2: x264 does optimise global stream headers
3: Users complain about not being able to append encoded video
4: --stitchable added to prevent x264 from optimising global stream headers
5: Fewer users complain about not being able to append encoded video

--stitchable became a thing in 2013 (https://github.com/yixia/x264/commit/8c8b46f1fbcf1c4b684afff9160d074077909965), so if you created the original silence clip before then, it'd make sense. If not, I don't know.........

I've definitely had problems appending encoded video in the past, even when the same x264 build was used and the same settings. Although --stitchable has always prevented the warning when appending constant frame rate encodes. For variable frame rate encodes it's still a little hit and miss. That could be because x264 is writing directly to MKV (for reasons I don't understand) as if MKVToolNix has warned about the codec's private data when appending VFR video in MKVs, extracting the raw streams and appending those instead has always worked.

An SSE2 requirement isn't an issue for me, but if x264 could find that missing entry point in kernel32.dl and obsess over bcrypt.dll a little less, I wouldn't complain. That started sometime after build 2091.

Cheers.

sneaker_ger

30th March 2019, 22:29

You already asked about fps in the past. It changed headers.
https://forum.doom9.org/showthread.php?p=1822942

filler56789

31st March 2019, 01:26

An SSE2 requirement isn't an issue for me, but if x264 could find that missing entry point in kernel32.dll and obsess over bcrypt.dll a little less, I wouldn't complain. That started sometime after build 2091.

Just my wild guess... the problem is not the recent revisions of x264, it's whether the .EXE uses win32thread or not. If you compile x264 without win32thread, then it should run normally on Windows XP
(or at least I think so).
I don't have a XP machine anymore, so I cannot test my hypothesis...

hello_hello

31st March 2019, 03:15

Sorry filler56789,
I missed your earlier post.

I can't remember if Windows offered an error message as such, but the first hurdle was x264 not being able to find bcrypt.dll. I downloaded it just to see what'd happen, then the next hurdle was a procedure entry point in kernel32.dll, so I gave up. That's much the same as the latest ffmpeg compiled without XP support (and MKVToolNixGUI after version 10), and while I don't know what win32thread is just yet, I suspect you're on the right track.

Cheers.

hello_hello

31st March 2019, 03:18

You already asked about fps in the past. It changed headers.
https://forum.doom9.org/showthread.php?p=1822942

I completely forgot about that.

Thanks.

lvqcl

31st March 2019, 10:12

I can't remember if Windows offered an error message as such, but the first hurdle was x264 not being able to find bcrypt.dll. I downloaded it just to see what'd happen, then the next hurdle was a procedure entry point in kernel32.dll, so I gave up. That's much the same as the latest ffmpeg compiled without XP support (and MKVToolNixGUI after version 10), and while I don't know what win32thread is just yet, I suspect you're on the right track.

From x264 configure file:
External library support:
--disable-avs disable avisynth support
--disable-swscale disable swscale support
--disable-lavf disable libavformat support
--disable-ffms disable ffmpegsource support
--disable-gpac disable gpac support
--disable-lsmash disable lsmash support

So, it looks like x264 is linked with some ffmpeg libraries by default. r2901 contains string "FFmpeg version git-2018-01-18-81c09ce34d", while r2935 contains "FFmpeg version git-2018-09-23-77c673920b".
Apparently, newer x264 -> newer ffmpeg -> no WinXP support.

(sorry for offtopic)

Mosu

12th April 2019, 18:02

Hey,

another month, time for another release of MKVToolNix: v33.0.0. This is still a rather quiet time for MKVToolNix; hence this is another small bug fix release.

There've been no changes regarding packaging since the previous release.

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 33.0.0 "A Little Bit of Madness" 2019-04-12

## Bug fixes

* mkvinfo: when using the `--size` option, mkvinfo will now report the correctly if an element has an unknown size. Part of the fix of #2530 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2530).
* MKVToolNix GUI: info tool: clusters with an unknown size will now be read and displayed correctly. Part of the fix of #2530 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2530).
* MKVToolNix GUI: multiplexer: Windows: trying to open Blu-ray index or playlist files failed when the path to the files contained symbolic links (e.g. when mounting a drive in a sub-folder via Windows' disk management utility). Fixes #2522 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2522).
* MKVToolNix GUI: multiplexer: if a destination file names ends with a number in parenthesis (e.g. a year such as "(2017)"), that number will not be stripped anymore during the process of ensuring the destination file name is unique. Only those suffixes added automatically in prior attempts to make the file name unique will be removed. Fixes #2521 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2521).
* MKVToolNix GUI: multiplexer: Windows: the GUI will let the user change the drive letter part of the destination file name freely again and only verify its validity right before starting to mux/adding to the job queue. Before it tried to force that into something valid, often resulting in unintentional paths (such as "C:\users\…\DC\files\…"). Fixes #2527 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2527).

Have fun :)

stax76

12th April 2019, 20:24

Thanks for the release. Minor cosmetic request for you or anybody else that posts markdown: BB code instead of MD code would be easier to read. It could be converted with a script that reads MD from the clipboard and copies BB back and for convenience the script could be started with a launcher like Alfred or Wox or via command line.

before: https://forum.doom9.org/showpost.php?p=1870861&postcount=88

after: https://forum.doom9.org/showpost.php?p=1870995&postcount=90

node script: https://pastebin.com/ru5xe4EE

Mosu

15th April 2019, 08:53

Hey,

well, I buggered up the handling of UNC paths on Windows in release 33.0.0. So… sorry? :) Here's a fix for that. As this is just an emergency hot fix release I'll include the news for v33.0.0, too.

There've been no changes regarding packaging since the previous release.

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 33.1.0 "Primrose" 2019-04-15
Bug fixes

MKVToolNix GUI: multiplexer: Windows: using UNC paths (e.g. "\\server\Videos") when the option "automatically set the destination file name" was set in the preferences, the GUI would create a destination file name with forward slashes (e.g. "//server/Videos/outputfile.mkv"), a syntax not supported by "mkvmerge". Fixes #2533 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2533) & #2534 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2534).
build system: the programs were accidentally built without stack protection ("-fstack-protector-strong") on recent versions of gcc and clang.

Version 33.0.0 "A Little Bit of Madness" 2019-04-12
Bug fixes

mkvinfo: when using the "--size" option, mkvinfo will now report the correctly if an element has an unknown size. Part of the fix of #2530 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2530).
MKVToolNix GUI: info tool: clusters with an unknown size will now be read and displayed correctly. Part of the fix of #2530 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2530).
MKVToolNix GUI: multiplexer: Windows: trying to open Blu-ray index or playlist files failed when the path to the files contained symbolic links (e.g. when mounting a drive in a sub-folder via Windows' disk management utility). Fixes #2522 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2522).
MKVToolNix GUI: multiplexer: if a destination file names ends with a number in parenthesis (e.g. a year such as "(2017)"), that number will not be stripped anymore during the process of ensuring the destination file name is unique. Only those suffixes added automatically in prior attempts to make the file name unique will be removed. Fixes #2521 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2521).
MKVToolNix GUI: multiplexer: Windows: the GUI will let the user change the drive letter part of the destination file name freely again and only verify its validity right before starting to mux/adding to the job queue. Before it tried to force that into something valid, often resulting in unintentional paths (such as "C:\users\…\DC\files\…"). Fixes #2527 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2527).

Have fun :)

Mosu

15th April 2019, 09:32

Thanks for the release. Minor cosmetic request…

Well, the script as-is didn't work too well for me, but with a couple of changes (handle more headline tags, revert HTML escaping of " and &, removal of code tags, manually joining lines in order to avoid line breaks) it works well enough, I guess.

chros

15th April 2019, 12:40

raymondjpg

23rd April 2019, 04:43

I am trying, unsuccessfully, to standardise order of tracks in output files generated by MKVToolNix so video comes first, then audio, then subtitles.

When I add --track-order 0:0,0:1 (by my understanding video first, then audio) as Default additional command line options in Multiplexer default values preferences, I get an error when muxing '--track-order' may only be given once.

I can find only one instance of --track-order in mkvtoolnix-gui.ini, and nowhere else in MKVToolNix preferences to set track order, so I am at a loss to know how to achieve standardisation of track order in output files.

Can anyone set me on the right path?

sneaker_ger

23rd April 2019, 09:23

When I add --track-order 0:0,0:1 (by my understanding video first, then audio)
That's not what it means. It means track 0:0 (track with TrackID 0 of first input file) is used first, then track 0:1 (track with TrackID 1 of first input file) second. --track-order doesn't have any arguments to differentiate between video/audio/subtitles.

I can find only one instance of --track-order in mkvtoolnix-gui.ini, and nowhere else in MKVToolNix preferences to set track order, so I am at a loss to know how to achieve standardisation of track order in output files.

Can anyone set me on the right path?
It's not possible to automatically make the GUI set 1. video 2. audio 3. subtitles. The GUI will always insert its own --track-order which cannot be disabled.

raymondjpg

23rd April 2019, 11:01

That's not what it means. It means track 0:0 (track with TrackID 0 of first input file) is used first, then track 0:1 (track with TrackID 1 of first input file) second. --track-order doesn't have any arguments to differentiate between video/audio/subtitles.

It's not possible to automatically make the GUI set 1. video 2. audio 3. subtitles. The GUI will always insert its own --track-order which cannot be disabled.

Thanks for the clarification. I was curious as to why the version of mkvmerge.exe bundled with MeGUI always managed to generate an mkv with the 'correct' track order of Video Audio and then Subtitles, whereas the current version of MKVToolNix GUI 33.1.0 is generating mkvs with track order of Audio Video then Subtitles.

I know track order in output files can be changed around manually.

sneaker_ger

23rd April 2019, 12:40

You can set the track order manually. It's just that MeGUI and MKVToolNixGUI use mkvmerge in different ways. The way MKVToolNixGUI works it's not possible to automate what you want.

Klaus1189

25th April 2019, 16:53

Is it possible to cut out a scene from a a videofile (key frame accurate is enough for that), but the two other parts (before and after the cut) should be one file again, without the need of more than one step.
I could cut on two points and then merge the two other parts together, but is there a one step possibility for that?

mkver

25th April 2019, 17:13

If you do not want to keep the middle part, then it is possible: If you use a + in front of a range, then this range will be appended to the preceding range that was outputted.

hubblec4

25th April 2019, 18:46

You have to use split option "By parts based on timestamps".

kuchikirukia

26th April 2019, 08:59

I've uploaded a PAL DVD .VOB to your FTP that exhibits some weird behavior. The weirdness I'm seeing when trying to frame serve this is probably due to bugs in LSMASH and FFMS2, but I've just never seen LSMASH behave this way.

Muxing this VOB to mkv with mkvtoolnix ends up with a weird mediainfo that claims variable frame rate and 47.867 FPS. From the mkv, LWLibavVideoSource will frame serve 54099 frames with a seemingly random duplicate frame pattern, while it shows 28255 frames with no dupes when used on the VOB.
FFMS2 locks up on both the mkv and VOB, and shows 54099 frames from the mkv and 28254 from the VOB.
DGDecode shows 28255 frames on the VOB or demuxed mpeg from the mkv.

There's no problem playing either the mkv or VOB in MPC-HC.

hubblec4

26th April 2019, 11:41

Hi Mosu

It seems the SegmentInfo.dtd is not correct, but mkvmerge handles the structure correctly.

SegmentFamily ist marked with a "?" (no or one times) but it can added multiple times, the asterisk sign (SegmentFamily*) should be used.
And the ChapterTranslateEditionUID has no extra sign but it should also have the asterisk sign (ChapterTranslateEditionUID*).

Some question about the Info elements:
Mkvmerge can use all Info elements which are available in the info.XML.
Mkvpropedit can edit all this elements too? And additionally I can edit some more elements like the Info Title.?

And then there are some elements which can't be edited, this values are written while mkvmerge mux the mkv file.
- Duration
- DateUTC
- MuxingApp
- WritingApp

The TimestampScale element can be set before I mux an mkv. Is this only possible with a command line switch?

Best regards
hubble

Liisachan

26th April 2019, 14:34

Hi, Mosu.

I have an Ogg Vorbis file, 15188168 bytes, 1448.447 sec (69525456 samples in 48000 Hz), that is 83887 bps (~84 kbps).

When I mux it into MKV using mkvmerge v33.1.0, a SimpleTag with TagName BPS is automatically written for the corresponding audio track, and its value is 82787 (~83 kbps), which I can't change even if I use a tags.xml file with:
<Simple><Name>BPS</Name><String>83887</String></Simple>

Am I correct to assume that this behavior is by design, and the BPS auto-written by mkvmerge is correctly based on some kind of "packet size" in MKV and so slightly smaller than the BPS of the "raw" Ogg Vorbis file?

Sorry if this has been already asked and answered. I did some search and read your changelog entry dated on 2014-05-20, which states:
mkvmerge: new feature: mkvmerge will write track-specific tags with statistics (»BPS« for the average number of bits per second

By which I'm guessing that an auto-written BPS is for a track in MKV, and not for the actual audio data, but I'd like to confirm this. TYIA.

mkver

26th April 2019, 16:15

@Liisachan: The statistics are for the actual data contained in the track in MKV. They do not consider MKV container overhead; and they also do not consider the overhead of the Ogg container (which is usually higher than Matroska overhead). Your other number (for the ogg vorbis file) probably has the ogg container overhead included in its calculation.

@kuchikirukia: First: mkvmerge's code for MPEG-2 is old, buggy and unsupported. So even if there were a bug in mkvmerge, it wouldn't get fixed. That being said, I don't have a reason to think that there is buggy behaviour by mkvmerge here.
Here is some background: A coded picture in MPEG-2 can either be a coded field or a coded frame (and frames needn't be progressive).* Matroska contains blocks and mkvmerge puts each picture in one block. What MediaInfo reports as FPS is in reality the block count per second.
So here are the numbers for your sample: Your sample contains 28255 frame-equivalents (i.e. two coded fields are counted as one frame here). 2*28255-54099 = 2411 of these are coded frames, while 28255-2411 = 25844 are encoded as coded fields (so there are 51688 coded fields). So the block-rate is 54099 / (2411 + 25844) * 25 = 47.8667.
It seems that your tools output two frames for each pair of two coded fields when the container is Matroska. I remember such bugs from H.264. You can report these bugs, of course (but they are not new), but in the meantime you should simply use another container if you work with the said tools.

*: Furthermore, these pictures can contain flags that say that they should be output more than once; the most common application is for coded frames to be output as three fields (i.e. one field output twice). That way one can encode progressive material as 24/1.001p on a DVD and output it as 60/1.001i for compability with legacy CRT (and modern equipment designed for progressive material can get the actual progressive video). This is used on NTSC DVDs, but not for PAL DVDs and therefore you can ignore it.

Liisachan

26th April 2019, 18:11

@mkver
Thanks! That makes sense. In the past I could manually write a BPS tag via an xml file, and back then I simply wrote file_size_in_bits / duration_in_sec as BPS value -- which is also the bitrate reported by oggenc (the ogg container overhead being included, like you said). As such, the definition of BPS value is now incompatible with that of my old MKV files, and I was a bit confused when I noticed that I can no longer explicitly write a BPS tag via xml. Still, if this is by design, I'm fine with that. A 1 kbp/s difference is not a big deal, and most players/tools probably don't read BPS tags anyway :)

Edit 2019-09-30
In the specs https://matroska.org/technical/specs/tagging/index.html#BitsPS it is clearly stated that BPS is only the data in the Blocks, and excludes headers and any container overhead.

EDIT2 2019-11-25
If needed, however, you can write a BPS tag freely as you like, by using --disable-track-statistics-tags
For example, you might want to make its value 85000 or 85272.4 or whatever, instead of 85272.

Perenista

8th May 2019, 02:05

Why can't I add .sub (MicroDVD) subtitles to a Matroska? I added an AVI and was going to add the subtitle, now I have to convert to SRT first

videoh

8th May 2019, 04:19

Matroska supports S_VOBSUB subtitles. These are typically named as ".sub" files when demuxed. See here for details and limitations.

https://matroska.org/technical/specs/subtitles/images.html

I don't know anything about MicroDVD.

`Orum

10th May 2019, 09:47

I've been working on transcoding some streams in some of my mkv files, and in doing so, I've discovered that several audio streams have a delay compared to the video. This by itself isn't surprising, but what is shocking is that I can't see anywhere this delay is indicated in mkvinfo. Even adding the original file into mkvmerge's GUI shows no delay on these tracks, when there definitely is one; sync is lost without it, and MediaInfo shows a "Delay relative to video" with a positive value for certain audio tracks.

I messed around with -v and -t to mkvinfo, but if either is used, I am inundated with output, and I'm not sure if any of it even shows the delay. How does MediaInfo get this value, and is there some CLI program that will show it to me? I've got literally hundreds of these files, and using a GUI application to look at each one is impractical.

sneaker_ger

10th May 2019, 11:01

Read: MKVToolNix FAQ: Delay not shown in the GUI (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Delay-not-shown-in-the-GUI)

mkvmerge -J "file.mkv"
Shows "minimum_timestamp" (in nanoseconds) for each track. "minimum_timestamp" of audio minus "minimum_timestamp" of video = "delay relative to video" of the audio track as MediaInfo shows it.

You can also see it in the Info tool:
https://i.imgur.com/iceeAcw.png
(Here it's 123ms-20ms=103ms audio "delay relative to video".

Of course there's the question of whether or not your workflow is good. If you always work under the assumption that video starts at 0ms and that video and audio tracks are constant framerate it may fail if those aren't true (Matroska supports variable framerates). I also see people needlessly demux e.g. audio tracks instead of just reading them from the mkv file directly when remuxing. When transcoding tracks I would get rid of delays anyways (fill with silence/blackness or remove).

`Orum

10th May 2019, 18:13

So, if I understand correctly, in the mkvinfo -v output, the lines I'm looking for are the first instance of:
Simple block: key, track number X
for each track. Then if I subtract the value for the each track's initial keys from one another, I can compute the relative delay between the tracks, right? It's a bit tedious but nothing perl can't handle.

I don't see much point in adding silence though, other than to simplify future transcoding. Since that won't happen, I'm not going to worry about it.

Edit: Hrm, I'm not sure what VFR has to do with this though. All the timestamps are in seconds, so why would the audio delay in any way relate to the frame rate?

Edit2: Seems subtitle tracks either lack the "Simple block: key..." line in the output, or it's optional. Anyway, I have the script working to parse the offsets correctly and can now adjust the delay in muxing accordingly. Thanks!

sneaker_ger

10th May 2019, 22:06

Edit: Hrm, I'm not sure what VFR has to do with this though. All the timestamps are in seconds, so why would the audio delay in any way relate to the frame rate?
I'm saying you might be working under wrong assumptions. E.g. that your Matroska files are CFR (except for the delay and some jitter) while that isn't necessarily true. And that the structure is only SimpleBlocks. So now you spent work on implementing delay detection which will probably fail in certain cases. While software like mkvmerge, ffmpeg or eac3to can read from mkv directly without having to implement this.
Maybe in your case it's sufficient or even makes sense. I don't know enough about your workflow or sources. Just my 2 cents ..

`Orum

11th May 2019, 08:55

I'm only transcoding audio, but if I were to do video, I'd check if it's VFR and if so, export & reimport the timecode. All tracks that are not transcoded are taken directly from the original mkv in mkvmerge, which I believe maintains everything in the original (such as timecode) without being explicitly told to do so, though I'd have to check with some VFR footage to verify this.

As for delay, it sounds like it can be done without SimpleBlocks? If so, what do I have to look for?

While software like mkvmerge, ffmpeg or eac3to can read from mkv directly without having to implement this.
Is directly reading the binary data the only way to calculate delay with perfect accuracy? If so that seems more like a deficiency in mkvinfo (where it's already awkward to view delay) than anything.

Edit: I did notice that one can simply export the timecode for each stream via mkvextract, and look at the first value in the timecode to determine offset as well. Is this more reliable to determine the delay?

sneaker_ger

11th May 2019, 09:03

I'm only transcoding audio, but if I were to do video, I'd check if it's VFR
Audio can be variable, too. (gaps) In that case the raw stream + the info about initial delay is not enough to reconstruct the timings. Information is lost.

For audio I would usually use ffmpeg or eac3to (+maybe some external encoder like qaac) which can read directly from mkv and "fix" the delay and any gaps while at it. So I don't see any need to parse mkvinfo at all. (Again: I don't know your reasons/workflow. Maybe you need different software or have other reasons.)

As for delay, it sounds like it can be done without SimpleBlocks? If so, what do I have to look for?
I'm saying not all mkv are SimpleBlock.

Is directly reading the binary data the only way to calculate delay with perfect accuracy? If so that seems more like a deficiency in mkvinfo (where it's already awkward to view delay) than anything.
No, mkvinfo has the same info as other software.

Perenista

11th May 2019, 19:17

`Orum

11th May 2019, 19:32

Audio can be variable, too. (gaps) In that case the raw stream + the info about initial delay is not enough to reconstruct the timings. Information is lost.
While I've never actually seen this, I assume the timecode can be extracted, and reapplied--unless one transcodes the audio, which I assume can change whatever "frame" size was used in the original and then things might fail to align.

In any case, as I've never seen this (and only seen silence added at the beginning/end), I'm not going to worry about it. In those edge cases, transcoding should probably be done with eac3to as you mention, at least initially.

I'm saying not all mkv are SimpleBlock.
I'll have to do more research into mkv to understand what other methods can be used, but at so far all of mine appear to be able to get the relative delay between video and audio by parsing it.

My player will automatically switch to the subtitle I created, even if it's already using another one.
So you want to automatically switch subtitle tracks when the audio track is switched? As far as I'm aware, that's not possible, at least within the mkv file itself. It might be possible with some playback software, but you might need some weird way to try and determine which sub track to use for which audio stream.

hubblec4

11th May 2019, 19:47

Is there a way to do this inside MKVToolnix? If the answer is yes, how?

- Let's say I have an audio track (and we will say this is track #2) that in certain scenes needs the subtitles to be enabled in the Matroska. You know, scenes spoken in another language, that sort of thing.

I already created a subtitle for these parts, and added to the Matroska. Obviously the subtitle file has only text for THESE SCENES. The rest of the movie is not covered by it.

What I want to find out is if:

a) I select the audio track #2;

Then

b) My player will automatically switch to the subtitle I created, even if it's already using another one.

That way when a) is selected b) will follow, meaning the player will automatically refer a) to b) while I am using Media Player Classic.

Meaning even if I select a different subtitle the fact I selected a) will switch the current subtitle selected to... b)

This is a task of Matroska Chapters with the ChapterTrack element which is not supported by all the players I know.
Or you can use TRACKSETEX, but you need Haali Splitter. It works perfect with MPC-HC.

I work currently on a Github project Matroska-Playback (https://github.com/hubblec4/Matroska-Playback) (early state) and here some info about TRACKSETEX (https://github.com/hubblec4/Matroska-Playback/blob/master/src/TRACKSETEX.md) and ChapterTrack (https://github.com/hubblec4/Matroska-Playback/blob/master/src/ChapterTrack.md) element.

filler56789

12th May 2019, 05:11

nevcairiel

12th May 2019, 08:59

Audio with gaps is generally just considered "broken", since it'll easily result in an audible glitch, or result in running out of sync with the video if the player assumes that audio should not have gaps.

Mosu

16th May 2019, 15:07

@Mosu, is there any plan for this? I'm just interested, thanks!

At the moment I don't have concrete plans for working on Dolby Vision. I acknowledge that HDR technologies are important, and I will most likely spend time on those topics in the future, just not soon.

Mosu

16th May 2019, 15:09

I've uploaded a PAL DVD .VOB to your FTP that exhibits some weird behavior.

I don't support MPEG-2 video & VOBs anymore. I would accept patches fixing problems, but I won't spend time on them myself.

Mosu

16th May 2019, 15:22

By which I'm guessing that an auto-written BPS is for a track in MKV, and not for the actual audio data, but I'd like to confirm this. TYIA.

mkvmerge uses a generic algorithm for calculating a track's BPS: it takes the maximum sum of a packet's timestamp and its duration, subtracts from that the minimum timestamp of all packets, and uses that as the track's duration. Then it divides the number of bytes written as frame payload for that track and divides it by that duration.

That algorithm works in mkvmerge's core; it's codec-agnostic and only works on packet timestamps/durations and not on actual number of samples (because it doesn't have access to that type of information).

Mosu

16th May 2019, 15:33

It seems the SegmentInfo.dtd is not correct, but mkvmerge handles the structure correctly.

It's quite possible that the DTDs aren't correct (anymore). DTDs are an outdated and unflexible technology. XML Schemas would have been better, but I never bothered to implement them. As no one asks for them either, it seems people don't need them after all.

Some question about the Info elements:
Mkvmerge can use all Info elements which are available in the info.XML.

mkvmerge only supports the four elements listed here (m_debug_to_tag_name_map) (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/common/xml/ebml_segmentinfo_converter.cpp#L36). It explicitly forbids the elements listed here (m_invalid_elements_map) (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/common/xml/ebml_segmentinfo_converter.cpp#L41).

Mkvpropedit can edit all this elements too? And additionally I can edit some more elements like the Info Title.?

You can ask mkvpropedit which elements it supports by running "mkvpropedit -l":

Elements in the category 'Segment information' ('--edit info'):
title | US | Title: The title for the whole movie.
date | DT | Date: The date the file was created.
segment-filename | US | Segment filename: The file name for this segment.
prev-filename | US | Previous filename: An escaped filename corresponding to the previous segment.
next-filename | US | Next filename: An escaped filename corresponding to the next segment.
segment-uid | X | Segment unique ID: A randomly generated unique ID to identify the current segment between many others (128 bits).
prev-uid | X | Previous segment's unique ID: A unique ID to identify the previous chained segment (128 bits).
next-uid | X | Next segment's unique ID: A unique ID to identify the next chained segment (128 bits).
muxing-application | US | Multiplexing application: The name of the application or library used for multiplexing the file.
writing-application | US | Writing application: The name of the application or library used for writing the file.

And then there are some elements which can't be edited, this values are written while mkvmerge mux the mkv file.
- Duration
- DateUTC
- MuxingApp
- WritingApp

Except for the duration those elements can be set with mkvpropedit, but not with mkvmerge.

The TimestampScale element can be set before I mux an mkv. Is this only possible with a command line switch?

That's the only way. You cannot change with mkvpropedit.

chros

16th May 2019, 17:17

At the moment I don't have concrete plans for working on Dolby Vision. I acknowledge that HDR technologies are important, and I will most likely spend time on those topics in the future, just not soon.
No worries and thanks for all your work!

hubblec4

16th May 2019, 19:56

Many thanks Mosu for the info.

Mosu

18th May 2019, 13:18

Hey,

here's the May release of MKVToolNix, v34.0.0. It's a tiny update with just three bugs fixed (and several translations updated).

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 34.0.0 "Sight and Seen" 2019-05-18
Bug fixes

mkvmerge: all subtitle frames are now treated as key frames in order to fix wrong data in source files. Fixes #2541 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2541).
mkvmerge: AV1: fixed frame timestamp calculation when reading bitstreams that lack timing information from IVF files. Fixes #2553 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2553).
mkvmerge: Matroska reader: fixed an infinite loop that could happen with large video frames and applied timestamp files due to too much data being buffered at the wrong time. Fixes #2550 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2550).

Have fun :)

Perenista

6th June 2019, 14:56

I think I found a bug in the last MKVToolnix. I specifically told it to split into 15100 MB parts a 70 GB file (14.7 GB parts to be uploaded to Google Drive), with Dolby Atmos and other tracks. And it did. The problem is that part 5 is missing the Atmos track, while all others (DD 5.1 for example) are there. I tried appending parts 1, 2, 3 and 4 and was able to, but when I reached part 5 I noticed this error.

I don't remember telling MKVToolnix to remove the Atmos track from part 5. And I couldn't have done anything wrong since I splitted into 5 parts. Another thing I did was adding audio tracks/subtitles that weren't there, but I did this to the huge 70 GB file, before the splitting.

Note: part 5 has 9.43 GB.

********

EDIT: Wait, wait, wait, I think I see what's wrong!

The Atmos track is indeed inside the part 5. However it's not showing when I open with MKVToolnix:

MEDIAINFO from part 5.mkv:
https://pastebin.com/0N9vW8r4

What happens when part 5 is opened:

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

Part 1-4 file, 59 GB:

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

Indeed it's a bug. That's why MKVToolnix says "formats don't match" and refuse to append the 59 GB file with the 9 GB one.

Somehow the Atmos information was messed in this splitting. But it's MKVToolnix's fault, not mine.

MEDIAINFO from the 59 GB file (parts 1-4 that I appended):

https://pastebin.com/eCnJU3h6

******

P.S. I did the same procedure in another movie and I appended the 5 parts minutes ago. In this #2 example the movie also has the Atmos track, and the scenario is very similar. Everything went OK, and I was able to append all parts into a big 70 GB file. Very odd.

What went wrong with this other movie?

**********
Update: spoke too soon. I am getting the same error with a third movie.

Here's the log:

--- Errors emitted by job 'Multiplexing to file "SINGLE FILE, PARTS 1+2+3.mkv" in directory "C:\Users\XXXXX\Desktop\XXXXXXXXX"' started on 2019-06-06 11:35:46 ---
The track number 2 from the file 'C:\Users\XXXXXXXXX\Desktop\XXXXXXX/MOVIE- UHD-4K-2160p-Blu-ray-Lossless - 5-5.mkv' cannot be appended to the track number 1 from the file 'C:\Users\XXXXXXXXXX\Desktop\XXXXXXXXXXXXX\MOVIE - UHD-4K-2160p-Blu-ray-Lossless - 4-5.mkv'. The formats do not match.

What is wrong with movie #3?

- Splitted into 5 parts.

- Parts 1, 2 and 3 can be easily appended. Let's call this file: SINGLE FILE, PARTS 1+2+3.mkv

- When I try to append SINGLE FILE, PARTS 1+2+3.mkv into PART 4.MKV this is what I am getting now:

THE FORMATS DO NOT MATCH

But how? Part 4 was generated from the huge 70 GB one!

And Part 5 of this third movie is also failing to display the Atmos track in MKVToolnix. For this reason it's saying: "cannot be appended to the track number 1"

Because the file SINGLE FILE, PARTS 1+2+3.mkv expects that PART 5.mkv has the Atmos track as TRACK NUMBER 1.

Since it's only seeing the DD 5.1 instead it will not append.

However the Atmos track is still there.

Another MediaINFO, part 5 from this third movie:

https://pastebin.com/MbiVj8Hk

Like the 2nd movie this one also had new tracks added to it. A dubbed one, and 2 new subtitles.

My theory is that by adding a foreign track I messed with the splitting. Perhaps I should have saved everything first, and only after I should have splitted?

mariush

6th June 2019, 15:57

Perenista

6th June 2019, 16:11

Not saying it's not a bug but...

Any particular reason you're not just using 7zip or some other compression software to create a multi volume archive with NO compression (or super fast compression) and volume sizes the amount you want?
You can set each volume to something like 990 MB or 2950 MB or 4950 MB, allowing you to upload 15/5/3 segments totalling 14750-14850 MB

In addition to that, you also have the benefit of encrypting the contents of the archives even if they're packed with no compression..I am uploading 15 GB parts to free Google Drive accounts (this is the limit). It's 4K content. They can be streamed or downloaded later and appended, to make a single file with whatever original size it was.

So it would make no sense to use WinRAR here, since I want the MKV to be streamed.

What I did was to convert the original disc into Matroska, then I added new tracks (one dubbing and 2 or 3 new subtitles). However I didn't save the 70 GB file again after adding those tracks. I simply added them for the upcoming task. But before hitting "Start multiplexing" I configured MKVToolnix to save into 15100 MB parts.

That's why the 70 GB file was saved into 5 others.

The issue I discovered here is that part 4 is saying "format don't match" and part 5 is missing the Atmos track while opening it in MKVToolnix.

Turns out that I will be able to append parts 1, 2 and 3, but part 4 (and 5) are impossible to be appended into this third movie.

For the 2nd movie the error is in part 5. Parts 1, 2, 3 and 4 were appended successfully.

The bug consists of:

- While part 5 has the Atmos track inside the file, MKVToolnix is ignoring it exists, after opening.

- Part 4 from this 3rd movie is somehow messed and for an unknown reason can't be appended to parts 1-2-3.

*******

Also: I installed a new SSD recently (2 days ago), and after that I formated and installed Windows 10-64 bit. Also checked the drive's health. So this isn't in any way some sort of system corruption.

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

Update:

Part 4 was appended now to the 1-3 file from the 3rd movie.

So the only bug that remains is the hidden Dolby Atmos track from part 5. The bug affected two movies by now, yet strangely leave one out of it.

hubblec4

6th June 2019, 17:48

I ask me often when users learn that cutting with MKVToolNix is a bad idea. It works in most cases of course, BUT Matroska has some limitations for cutting and so you run from time to time in a split issue for some files. And this is not a bug of mkvmerge.

Perenista

6th June 2019, 17:55

Here's a more thorough explanation of what I did. Disregard all my previous posts and read this one to avoid any confusion.

- The movie has the Dolby Atmos track, and MAKEMKV says DD 5.1 for the secondary track of it. MAKEMKV also lists a 3rd track (separated from the Atmos) which is also Dolby Digital 5.1. I always assumed both are 100% identical, yet I always leave two tracks named as DD 5.1. Since I want a MKV lossless version from the disc I proceed this way.

Then there's a 2.0 track which is the audio commentary.

The movie also has 1 subtitle, english closed captions. Plus chapters.

It's Ultra-HD Blu-ray (4K).

*******

What I did, in the 1st place:

1) Saved the UHD into a single MKV. Final size is more or less 70 GB. With all tracks mentioned before.

2) Opened this MKV with MKVToolnix.

3) I also had additional tracks for this movie, saved elsewhere:

a) Portuguese dubbing.
b) English subtitles (not CC)
c) Portuguese subtitles

4) Added a, b and C) to 2), the 70 GB file.

5) MKVToolnix is still open. I added a, b and c, yet I haven't saved the 70 GB file again, which would end up having +- 71 GB.

6) I instruct MKVToolnix to split into 15100 MB parts, with a, b and c. It ends saving into 5 splitted parts.

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

So this is it.

Now why am I calling a bug?

Because when we open part 5 in MKVToolnix the Atmos track is missing. But it's there inside the file! Only MKVToolnix is not seeing.

I am able to append parts 1, 2, 3 and 4 together again. Not part 5.

This is what happens when we try to... append part 5 into parts 1+2+3+4:

>>>>>>>>>>>>>>>>>>>>>>> The track number 4 from the file PART 5.MKV cannot be appended to the track number 3 from the file PARTS 1+2+3+4.MKV. The number of channels of the two audio tracks is different: 2 and 6

In the above test I didn't select the Atmos track. So in theory it should work, right? Since parts 1+2+3+4 have the same tracks as part 5.

If I select the Atmos track in the file PARTS 1+2+3+4.mkv this is the end result:

>>>>>>>>>>>>>>>> The track number 2 from the file PART 5.MKV cannot be appended to the track number 1 from the file PARTS 1+2+3+4.mkv. The formats do not match.

*********

Now what might happen if I not only remove the Atmos track from PARTS 1+2+3+4.mkv, also the two DD 5.1 tracks? And do the same with PART 5.mkv?

Answer: it will now be possible to append part 5!

Another test:

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

Try to select only one DD 5.1 track.

Result?

Fail. The same "The number of channels of the two audio tracks is different: 2 and 6" error.

Final test:

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

Result: Success! I am now able to append part 5.

So this means the fact two different tracks have the same name.... MKVToolnix is causing all these problems? And also hiding the Atmos track in part 5?

I ask me often when users learn that cutting with MKVToolNix is a bad idea. It works in most cases of course, BUT Matroska has some limitations for cutting and so you run from time to time in a split issue for some files. And this is not a bug of mkvmerge.I consider a bug when I have been doing this splitting and appending for years and this is the first time EVER I encounter such problem. And I discovered all of sudden! No idea why this is happening yet.

I did everything correct, yet this bug appeared in TWO MOVIES. It's not an isolated case.

What is odd is that it didn't happen for a 3rd movie I was doing the same stuff, however in this case the tracks have different names. I believe the fact two different tracks had the same name (DD 5.1) completely messed MKVToolnix.

I only split files due to Google Drive's limited 15 GB space for free accounts. If was up to me I would never do that.

P.S. MAKEMKV before I converted the 4K to MKV:

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

Perenista

9th June 2019, 19:31

I fixed all the issues mentioned by creating a single 70 GB file with all the changes, and only after finishing all my editions I splitted the file into 151000 MB parts. Then I tried appending again, and it worked for ALL MOVIES.

What happened here was that I tried to do two things AT THE SAME TIME: a) add new contents to a file, and b) split the original file + a) which had not even been added. That's why mkvToolnix was incapable of appending it again, somehow things got messed after this task.

Mental note: do all the changes to the MKV and only after them split the whole thing. I tried to save some time, not knowing this would break the final results if in the future I wanted to append it into a single big file. I hope I didn't mess any of the previous MKVs, created in the past.

sneaker_ger

9th June 2019, 19:35

The question is whether you accidentilly made a user mistake. Or if you had found a bug. It would be nice if such a bug could be documented and fixed even if you now have a workaround.

qyot27

10th June 2019, 04:07

Considering the history of MakeMKV's Matroska output sometimes being funky, it wouldn't surprise me if it had to do with mkvmerge having to fix the original mux in the first place. Eliminate that X factor entirely; use MakeMKV's Backup mode and then give mkvmerge the index.bdmv and do all the stream manipulation from there. That would confirm whether this really was a bug in mkvmerge or not.

Mosu

22nd June 2019, 11:56

Time for release v35.0.0 of MKVToolNix. Again, it only includes a small number of enhancements and bug fixes; nothing major.

There've been no changes regarding packaging since the previous release.

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 35.0.0 "All The Love In The World" 2019-06-22
New features and enhancements

mkvmerge: JSON identification: the "codec name" track property will be output as "codec_name". The JSON schema has been bumped to v12 for this change.
MKVToolNix GUI: job queue: added a new type of action to execute after job completion: deleting source files for of multiplexer jobs. As this is a destructive operation, the action is disabled by default. Implements #869 (https://gitlab.com/mbunkus/mkvtoolnix/issues/869) and #2570 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2570).

Bug fixes

mkvmerge: the "codec name" track property wasn't copied from Matroska files. Fixes #2566 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2566).
MKVToolNix GUI: multiplexer: Windows: clearing the destination file name will reset the tab name to "<No destination file>" again. Fixes #2571 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2571).
MKVToolNix GUI: multiplexer: the file types were not re-translated if the UI language was changed. Fixes #2572 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2572).

Have fun :)

hubblec4

23rd June 2019, 00:33

Hi Mosu
The old "codec name" track property (now codec_name) was "codec" only?

sneaker_ger

23rd June 2019, 08:32

CodecName is the most useless element anyways. I don't see the purpose as CodecIDs are already human-readable and unambiguous.

Wakaku

23rd June 2019, 16:22

Hello, it's been quite a while, I just need a little help. After muxing/remuxing with v35.0, tag portions which contain ChapterUIDs are lost. There are no Warnings or Errors, all smooth, both left and right message boxes are blank after muxing/remuxing.

These two ways end up with the same results:

Remuxing an existing MKV with such an exisiting tag.
Muxing an MKV plus an external XML tag.

Here are my sample tags. The tags are intended for 3 WWE videos downloaded from Youtube, but concatenated with FFmpeg to create a single MKV. Thus the related metadata, covers, and chapters for each video (eg. URL's, titles, etc) in the single MKV.

Original XML tag (https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxkcDc5bGFrYXN8Z3g6MThhNDA5NzExODAwYzUxZA)
After remuxing with v35.0 (https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxkcDc5bGFrYXN8Z3g6M2U0MTgyOTRhNDlhZTcxYw)

Is there any new option or setting to use to achieve the old/previous behavior? Thanks in advance.

Klaus1189

14th July 2019, 12:06

I am using 35.0.0 and want to correct a wrong tagged/encoded file, the 21,9 GB one from https://svs.gsfc.nasa.gov/13057
To get it played properly with MPC-BE and LAV Filters (MPC-BE with internal Filters is fine with this file) I need to set Default duration/FPS" to 60000/1001p and also "Fix bitstream timing info", otherwise MediaInfo will report original Framerate as 25 as it was and also LAV Filters with see and still use this.

But if I have set it to 60000/1001p the original FPS will be reported as 60.000p in MediaInfo. Is that a bug in MediaInfo or an issue in MKVToolNix?

sneaker_ger

15th July 2019, 15:47

Probably a MediaInfo limitation. It has trouble detecting the exact fps with especially with short probe sizes because Matroska timestamps don't map 60/1.001 fps 100% exactly (jitter).

nogames

17th July 2019, 18:04

Mosu

19th July 2019, 16:28

Sounds like… well… something, maybe bad compiler optimizations? I don't know… Please give the latest continuous build (https://mkvtoolnix.download/windows/continuous/64-bit/35.0.0/) a try. They're built with newer compiler versions.

Not that I think that'll really do anything, mind you…

As I don't have access to a single Ryzen system, I don't think there's really anything I can do at the moment, especially given that older Ryzen seems to have run the binaries just fine according to you.

Mosu

19th July 2019, 16:30

The old "codec name" track property (now codec_name) was "codec" only?

No. "codec" wasn't changed at all. The property "codec_name" was added containing the value of the "CodecName" track header attribute if present.

nogames

29th July 2019, 17:53

Sounds like… well… something, maybe bad compiler optimizations? I don't know… Please give the latest continuous build (https://mkvtoolnix.download/windows/continuous/64-bit/35.0.0/) a try. They're built with newer compiler versions.

Downloaded the 64-bit version of the continuous build. And no errors. It runs. I'll report back again when this version goes final.

DragonQ

29th July 2019, 19:33

MKVToolNix GUI v35.0.0/64bit keeps crashing when adding a file to GUI. It does not matter if it is via drag-drop or Add file option.

I just upgraded my system to Ryzen 7 3700X. It's a fresh install of Windows 10 Pro 64-bit (version 1903). I came from a Ryzen 7 1800X (but not version 1903 but the previous version) which did not have this problem.

The 32bit version of MKVToolNix GUI v35.0.0 works! I have tried all 64 bit versions from v30.0.0 and on and they all crash when I add a file.

Note: No difference in behaviour between Installed and Portable versions
I have a similar issue. I also have a Ryzen 7 3700X, a fresh install of Windows 10 1903, and the 64-bit version of MKVToolnix GUI. I can add files and make changes, but as soon as I hit "Start multiplexing", the app crashes and disappears. I then cannot restart the app at all (it presumably insta-crashes since I never see the window). The only way to get the app to relaunch is to empty the "AppData\Local\bunkus.org\mkvtoolnix-gui\jobQueue" directory.

The only workaround I've found is to import files, choose my settings, then do "Show command line" and run it manually in the command line.

Snowknight26

31st July 2019, 03:34

Yep, just noticed the same thing, Ryzen 5 3600. Start multiplexing crashed the program and it won't start again. It was working fine up until I chose the destination file using the button instead of typing the name in manually.

Mosu

1st August 2019, 08:20

chros

1st August 2019, 10:03

The new Ryzens are known to contain several bugs, e.g. with their RDRAND instruction.
That's interesting, thanks. Did AMD become the new Intel?! :devil:

DragonQ

3rd August 2019, 15:19

The new Ryzens are known to contain several bugs, e.g. with their RDRAND instruction. This is not a bug in MKVToolNix, and AMD has released new BIOSes that're supposed to fix some of those bugs to for the motherboard manufacturers. Another user who reported the issue over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/2589) also reported that their motherboard manufacturer's just released a BIOS update. After having applied the update MKVToolNix started to work fine (https://gitlab.com/mbunkus/mkvtoolnix/issues/2589#note_198551877) for them.
Which bugs are "known" other than the RDRAND bug? Does MKVToolnix actually use RDRAND?

Either way, I tried the latest dev release and it seems to work now. Not sure if it's because of the new version or a new BIOS but at least it works now. :)

huhn

3rd August 2019, 19:07

there are quit some issues they even pulled bios versions thanks to bugs in the AGESA. boards are shipped with alpha version bios this is as rushed as possible...

if you want a stable system zen 2 shouldn't be an option for now.

MrVideo

8th August 2019, 10:11

I tried looking thru the change logs and a search here, but didn't find anything. At what version did Windows support change to Win7, and later? Thanks.

lvqcl

8th August 2019, 10:58

and a search here
There is also an old thread: http://forum.doom9.org/showthread.php?t=155732

I tried looking thru the change logs and a search here, but didn't find anything. At what version did Windows support change to Win7, and later? Thanks.

You mean officially? I suspect that the answer is here - https://gitlab.com/mbunkus/mkvtoolnix/wikis/Officially-supported-operating-systems-and-versions

Supported are all client versions of Windows (meaning Intel architecture) that Microsoft supports. This means Windows 7 or newer, 32-bit and 64-bit architectures. On the server side Windows Server 2012 and newer are supported.
(emphasis mine)

At least, version 11 was the first that dropped support for WinXP.

PS: http://forum.doom9.org/showthread.php?p=1806381#post1806381

sneaker_ger

8th August 2019, 12:44

Yeah, officially. The sounds made the GUI not work on XP for good. CLI may still work. As should Vista.
# Version 11.0.0 "Alive" 2017-04-22

## New features and enhancements

* MKVToolNix GUI: implemented several built-in actions that can be executed
either on special events or once via the "watch jobs" tool. These are:
playing an audio file (implemented for all operating systems)

## Build system changes

* Qt's multimedia component is required for compilation of the GUIs since
version 11.0.0.
https://mkvtoolnix.download/doc/NEWS.md

MrVideo

8th August 2019, 13:33

You mean officially? I suspect that the answer is here - https://gitlab.com/mbunkus/mkvtoolnix/wikis/Officially-supported-operating-systems-and-versions
I saw that. It doesn't say when.
At least, version 11 was the first that dropped support for WinXP.
I've got V24 32bit running on an XP system. I've never used the GUI. I do all my mkvmerge stuff via the CLI within Zshell scripts under cygwin. That said, I do not use that system for recoding and merging of the video and audio streams anymore. But, I do use mkvmerge a lot. I guess I'll just keep upgrading until I find a version whereby it no longer works and go back to the previous version.

I had to rebuild another XP system that I was using for compiling and loaded XP-64 on it. I ran either 31 or 33 on it. Hardware issues required a new mobo so I upgraded it to Win7 as well. I had already built another Win7 box for compiling and have basically turned off the other Win7 box. At least I haven't turned it back on after AC power issues. :eek:
PS: http://forum.doom9.org/showthread.php?p=1806381#post1806381
Personally I do not like the "ding"ing that goes on when programs finish, or if there are errors. I find it annoying. The error dialog popups are good enough for me.

Thanks for the responses. It has been helpful.

manolito

9th August 2019, 04:37

The last CLI version which works under WinXP is v.29. If you need the GUI you have to replace some components of the package with older versions.

FWIW here is a package which does this...
https://files.videohelp.com/u/172211/ToolNix_XP.zip

/EDIT/
The archive was updated to also include the last Win7 compatible version (32-bit only)

MrVideo

9th August 2019, 09:06

The last CLI version which works under WinXP is v.29.
Thanks for the info. That'll save me a lot of trial and error.
If you need the GUI you have to replace some components of the package with older versions.
Thanks. But like I wrote, I do not use the GUI and have never used the GUI.

Mosu

10th August 2019, 15:58

Here's another small summery bug fix release for MKVToolNix, v36.0.0. Nothing major's changed; just a couple of fixes here & there.

There've been no changes regarding packaging since the previous release.

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 36.0.0 "Is That Jazz?" 2019-08-10
New features and enhancements

mkvmerge: mkvmerge now allows appending AV1, VP8, VP9, H.264/AVC and H.265/HEVC tracks whose pixel dimensions differ. Implements #2582 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2582).

Bug fixes

source code: fixed building with Boost 1.71.0. Fixes #2599 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2599).
all: fixed the spelling of the H.264 & H.265 codec names.
mkvmerge: Blu-ray MPLS handling: mkvmerge will now find corresponding M2TS files even if the "clip_codec_identifier" playlist item field is not set to "M2TS" in the MPLS file. Fixes #2601 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2601).
mkvmerge: fixed handling of text files that use both DOS-style and Unix-style line endings resulting in problems such as text subtitle files not being parsed correctly. Fixes #2594 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2594).

Have fun :)

Mosu

10th August 2019, 16:07

Which bugs are "known" other than the RDRAND bug? Does MKVToolnix actually use RDRAND?

MKVToolNix itself does not contain any assembly instructions, nor does it contain any CPU-specific or CPU-vendor-specific code. It is, of course, more than possible that at least some of the libraries used by MKVToolNix do use those instructions, especially given that MKVToolNix does communicate via HTTPS, meaning there are a lot of security-related code paths.

I don't know specifics about buggy instructions other than RDRAND, but there are tons of reports out there of bugs such as software crashing (see e.g. Destiny 2 crashing (https://hothardware.com/news/amd-ryzen-3000-zen-2-destiny-2-bungie-crash)), Windows blue-screening during boots and several board vendors releasing BIOS updates several times a week. All of that paints a picture of a rather immature hardware platform. Not really surprising, really, as AMD's hardware seems to include much more radical changes & new features than the glacial enhancements Intel seems to produce these days. I'd simply give the hardware platform some more time to mature, or be aware of the usual risks for early adopters.

Mosu

10th August 2019, 16:13

I tried looking thru the change logs and a search here, but didn't find anything. At what version did Windows support change to Win7, and later? Thanks.

While we're on the topic: yes, my official policy is that I only support those Windows versions that Microsoft supports for the general population (= unpaid support). So yes, this means that Windows 7 itself will soon not match this criteria anymore as its unpaid, extended support will end on January 14, 2020.

This doesn't mean that MKVToolNix will stop running on Windows 7 on that day, nor does it mean that I'll go out of my way to make MKVToolNix require newer Windows versions to run. In fact, it's quite possible MKVToolNix will continue running on Windows 7 for much longer than it used to run on XP after its end of support. But I do reserve the right to refuse to debug issues occurring on Windows 7 unless the user can show the problem happens on other supported platforms, too.

Queue the outrage in 3… 2… 1…

Mosu

10th August 2019, 16:15

I saw that. It doesn't say when.

That's because I don't implement intentionally that cause MKVToolNix not to run on older versions anymore. "Not supported" doesn't necessarily mean "doesn't run anymore". I just don't pay attention to unsupported OS anymore regarding my choice of things such as library versions, features used, compiler flags used etc. I often don't even realize there's a problem running on older OS until users complain.

MrVideo

10th August 2019, 18:28

That's because I don't implement intentionally that cause MKVToolNix not to run on older versions anymore.
I don't mean to imply that you do anything intentionally to not make it work.

Mosu

10th August 2019, 18:47

I don't mean to imply that you do anything intentionally to not make it work.

I hadn't understood you that way, don't worry. I just wanted to make clear that I'm not intentionally trying to piss people off :)

MrVideo

11th August 2019, 02:20

I just wanted to make clear that I'm not intentionally trying to piss people off :)
The only one that I get pissed off at is Adobe. For example, with the latest Premiere, one must run a certain edition of Win10, or later.

I expect software to eventually stop working, so I just use the last one that still works. In the case of Premiere, I just do not use it, instead using another party's software that still works under Win7-64.

kuchikirukia

12th August 2019, 07:30

Did I misclick some setting to screw up the automatic file name logic? It used to always increase in level when muxing -- i.e. xxx.mkv would mux to xxx (1).mkv which would then mux to xxx (1) (1).mkv. Now mine is all screwed up. xxx (1).mkv will mux to xxx (2).mkv, but xxx.mkv will also mux to xxx (2) if (1) is present so you can't tell what the source was anymore. I've even seen it go down a level after cleaning up some intermediate files and muxing again.

I can't tell what the latest generation top-level mux is anymore since it can be mixed in with lower level ones. How do I get the other way back?

sneaker_ger

12th August 2019, 08:36

There were some changes in the last versions. Which can be quite confusing. Especially since the file name can change the moment you click "Start muxing".

https://i.imgur.com/OezTpKn.gif

Mosu

19th August 2019, 12:13

kuchikirukia

20th August 2019, 03:48

Oh, that's a nice GIF showing off a bug in the logic. It happens when the number to add, "(3)", is already present at the end of the original base name. In that case too much is removed (from "m (3) (3)" down to "m" instead of "m (3)") before the GUI checks for existing files. I'll see to it that it gets fixed.

Does it need to remove anything? I liked the way it worked before. You had definite tiers of muxes and could trace the children back to the parent. Having movie.mkv and movie (1).mkv now both mux to movie (2).mkv means you can't tell by looking at movie (2).mkv where it came from. You could tell before because only movie.mkv would mux to movie (2).mkv while movie (1).mkv would mux to movie (1) (1).mkv.

I don't mind that I have files that end up looking like zszs (1)-002 (1) (1)-001 (8) (2)-001 (5).mkv. I can follow that.

Asmodian

22nd August 2019, 01:42

I have to agree with kuchikirukia, even if it isn't as slick. :o

Mosu

23rd August 2019, 18:52

Having movie.mkv and movie (1).mkv now both mux to movie (2).mkv means you can't tell by looking at movie (2).mkv where it came from.

Assuming "movie.mkv" and "movie (1).mkv" exists in the destination folder, the current, fixed algorithm will chose "movie (2).mkv" for "movie.mkv" and "movie (1) (1).mkv" for "movie (1).mkv". That "movie (2).mkv" was chosen for "movie (1).mkv" was the bug I was referring to.

kuchikirukia

24th August 2019, 00:16

Cool. Thanks for the fix!

Mosu

24th August 2019, 09:54

Due to two nasty bugs in v36 I'm releasing v37 sooner than anticipated. This release fixes both of the bugs; see below for details.

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 37.0.0 "Leave It" 2019-08-24
New features and enhancements

MKVToolNix GUI: the list of often used languages now contains those from Wikipedia's "List of languages by native speakers" by default. Also by default only those languages will be shown in the language drop-down boxes.

Bug fixes

MKVToolNix GUI: multiplexer: fixed a bug in the "make destination file names unique" logic that caused an existing number-in-parenthesis at the end of the file base name to be removed in certain situations (e.g. when the first added file was named "m (3).mkv" and both "m (3) (1).mkv" and "m (3) (2).mkv" existed already, the GUI was suddenly use "m.mkv" instead of "m (3) (3).mkv").
MKVToolNix GUI: on Windows the GUI is built with a slightly older version of the Qt library again (5.12.4). The Qt version used in release v36.0.0, v5.13.0, lead to crashes when doing certain things such as selecting multiple tracks in the multiplexer. Fixes #2605 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2605) and #26008 (https://gitlab.com/mbunkus/mkvtoolnix/issues/26008).

Have fun :)

filler56789

24th August 2019, 10:11

^ :thanks:

Masutin

26th August 2019, 09:01

WithFOR %%A IN (*.mp4) DO mkvmerge -o "%%~nA.mkv" ^
--default-duration 0:23.976fps "%%A"I change the frame rate to constant and have had a problem with only one file where mkvmerge v.10 processes 200% and the tracks merge onto themselves, the duration doubles.

sneaker_ger

26th August 2019, 11:18

mkvmerge v10 is not supported. We are currently at version 37.0.0. First test the latest mkvmerge version. If v37 shows the same problem show us the samples (at least MediaInfo) of input and output and the full mkvmerge log. But I suspect it is not a bug. Maybe Track with ID 0 is not 23.976 fps or maybe not even a video track. And I don't even know what "tracks merge onto themselves" means.

mkver

26th August 2019, 13:23

Some mp4 files use edit lists to loop the content (and some tools seem to add such edit lists even when they shouldn't). This could be such a file. Newer versions of mkvmerge contain a heuristic to detect such bogus edit lists, so this might be fixed already. As sneaker_ger said: Ancient versions are not supported.

Masutin

26th August 2019, 19:27

No support for older verions on Doom9 at all? 10 must be the last one for XP, I can't try a new one now. But once I've brought this up, I clarify, only the video (23.976!) is doubled (looped, 'merged onto itself'), the audio is of normal duration. The file is from mp4creator, it must add this 'edit list'. Any idea of fixing it? Nothing unusual in the log or MediaInfo report (Advanced, too).
-o "Witness (1985).mkv" --default-duration 0:23.976fps "Witness (1985).mp4"
mkvmerge v10.0.0 ('To Drown In You') 32bit
'Witness (1985).mp4': Using the demultiplexer for the format 'QuickTime/MP4'.
'Witness (1985).mp4' track 0: Using the output module for the format 'AVC/h.264'.
'Witness (1985).mp4' track 1: Using the output module for the format 'AAC'.
The file 'Witness (1985).mkv' has been opened for writing.
'Witness (1985).mp4' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1280/720.
Progress: 100% (the intermediate was 200%)
The cue entries (the index) are being written…
Multiplexing took 4 minutes 56 seconds.

Format : MPEG-4
Formatprofile : Base Media / Version 2
Codec Id : mp42 (mp42/isom)
File size : 564 MB
Duration (ms) : 1h 52mn
Overall bit rate mode : Variable
Overall bit rate : 703 Kbps
Encoded date : UTC 2011-09-06 21:04:43
Tagged date : UTC 2011-09-06 21:05:35
Writing application : mp4creator 1.6.1d
===================== Video =====================
Id : 1
Format : AVC
Format info : Advanced Video Codec
Formatprofile : High@L4.1
Formatsettings, CABAC : Yes
Formatsettings, ReFrames : 8 frames
Codec Id : avc1
Codec info : Advanced Video Coding
Duration (ms) : 1h 52mn
Bit rate : 664 Kbps
Width : 1 280 pixels
Height : 720 pixels
Original height : 716 pixels
Display aspect ratio : 16:9
Original display aspect rat : 16:9
Frame rate mode : Variable
Frame rate : 23.976 (23976/1000) fps
Minimum frame rate : 23.974 fps
Maximum frame rate : 23.981 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.030
Stream size : 533 MB (94%)
===================== Audio =====================
Id : 2
Format : AAC
Format info : Advanced Audio Codec
Formatprofile : HE-AAC / LC
Codec Id : 40
Duration (ms) : 1h 52mn
Bit rate mode : Variable
Bit rate : 35.0 Kbps
Maximum bit rate : 55.0 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz / 24.0 KHz
Frame rate : 23.438 fps (1024 spf)
Compression mode : Lossy
Stream size : 28.1 MB (5%)
Language : English

sneaker_ger

26th August 2019, 22:20

Yes, it seems mkver is right. Maybe you could use something like --split parts:-01:51:59.

Does v 37.0.0 really not support XP at all or is this just the GUI? Maybe mkvmerge (CLI) works?

manolito

26th August 2019, 22:40

Does v 37.0.0 really not support XP at all or is this just the GUI? Maybe mkvmerge (CLI) works?

No, it is not just the GUI. The last CLI version which works under WinXP is v29.0.0

sneaker_ger

26th August 2019, 22:57

In v29 the problem mentioned by mkver should already be fixed.

KaraokeAmerica

27th August 2019, 12:54

I just installed this on a Pi4 running Raspbian. It runs, but the version is 31.

Is that the best it gets for the Pi platform?

Yes, I understand that a Pi is not a quad-Xeon. I just like to play......;)

Masutin

27th August 2019, 15:50

mkvmerge 29 works on XP and fixes the problem! I was informed that mkvtoolnix 10 was the last to work on XP and never thought it worth inquiring if it applied to CLI. DE über alles!

manolito

27th August 2019, 17:40

Maybe my workaround package from this link is for you:
https://forum.doom9.org/showthread.php?p=1881431#post1881431

Maybe you can even help me to make it more "universal", that means working under more local Windows versions.

When you mix an older MKVToolnix GUI with newer CLI versions, Toolnix will pop up a warning. My package clicks aways this warning, but for this to work it needs a substring which is part of the warning window title. I started with "Problem" as the substring to look for, but I later changed it to "robl" because the "P" can be lowercase or uppercase depending on the language, and the "e" character is different in French (it has an accent grave).

You did not say where you come from, can you test it and tell me what the window title of this warning message is for you?

Cheers
manolito

Mosu

29th August 2019, 16:20

I just installed this on a Pi4 running Raspbian. It runs, but the version is 31.

Is that the best it gets for the Pi platform?

There's no limit to ARM that I know of. However, I don't provide packages for the ARM architecture as I don't use it myself. Therefore all you get is the package provided by Raspbian (= Debian) itself, and that's v31 for "buster" (https://packages.debian.org/buster/mkvtoolnix).

Feel free to compile the package yourself (https://mkvtoolnix.download/source.html#debian_ubuntu_package). I cannot tell you if a Pi4 has enough resources for that, though.

ChaosKing

29th August 2019, 17:46

There's no limit to ARM that I know of. However, I don't provide packages for the ARM architecture as I don't use it myself. Therefore all you get is the package provided by Raspbian (= Debian) itself, and that's v31 for "buster" (https://packages.debian.org/buster/mkvtoolnix).

Feel free to compile the package yourself (https://mkvtoolnix.download/source.html#debian_ubuntu_package). I cannot tell you if a Pi4 has enough resources for that, though.

I think flatpak has also arm support. They have at least the newest version on their page. https://flathub.org/apps/details/org.bunkus.mkvtoolnix-gui

https://flatpak.org/setup/Raspbian/

Mosu

29th August 2019, 21:15

Oh right, the Flatpak! I totally forgot about that. Thanks for thinking of it.

Inviska

3rd September 2019, 23:11

Would it be okay to bundle the MKVToolNix command line tools in my Inviska MKV Extract AppImage?

It seems more people are using the MKVToolNix Snap and AppImage, which Inviska MKV Extract won't work with. After being contacted a few times asking how to get it working, I started to think it would be better to include the MKVToolNix command line tools in my AppImage, but I didn't know if this would be okay with you.

Would you have any problems with me bundling the MKVToolNix command line tools in my AppImage?

Edit: I just released a new version with the MKVToolNix command-land tools bundled in the AppImage. If this is a problem I can delete it and do another release without the tools included.

rmlazzari

5th September 2019, 21:01

Hello, first I apologize if this is not the right place to post beginner questions. If not, please indicate the right place.

But if my question can be answered in this topic, here it goes:

For many years I have been using MKVToolNix-gui under Windows. I also used a gui to extract .MKV files. The interface for extract, if I'm not mistaken, was not installed. I just copied .DLL and .EXE files to the same folder where MKVToolNix-gui had installed itself and created a link to .EXE on the desktop. Even so, I never clicked on the extract. I directly clicked on the .MKV file and from the context menu chose to open it with the extract.

But now I'm using Linux Mint.

I am new to Linux although I worked from 1978 until a few years ago as a COBOL mainframe computer programmer (IBM / 370, 4341 etc.). That is, all my knowledge today is obsolete, maybe useless, but maybe I can recognize a command line, for example.

Well, using the Linux Mint Application Manager (19.2), I found MKVToolNix-gui, installed it and it is working fine. But I don't know how to update it or how to install the gui for MKVExtract (or something).

I read the page at "https://mkvtoolnix.download/downloads.html#ubuntu", copied and pasted the following lines into Terminal:

1 - wget -q -O - https://mkvtoolnix.download/gpg-pub-moritzbunkus.txt | sudo apt-key add -

2 - /etc/apt/sources.list.d/mkvtoolnix.download.list

3 - deb https://mkvtoolnix.download/ubuntu/ bionic main

4 - deb-src https://mkvtoolnix.download/ubuntu/ bionic main

Only the first line worked but the others... I have the impression that "wget" is a command, that the second line is a file but I don't know what the third and fourth line are.

Anyway, to avoid bothering you, I would like you to help me upgrade MKVToolNix-gui (installed version is 19 but the program asks me to upgrade to 37) and install gMKVExtract (I think it was This is the program but I may be wrong).

As I said before, I apologize for the difficulty and although I want to know at least the basics of Linux, in this message, if you can help me just install and update the MKV programs I would be very grateful.

qyot27

6th September 2019, 01:07

rmlazzari

7th September 2019, 23:09

On Ubuntu (presumably any Debian variant, but I dunno for sure), after running the wget piping command, do
sudo add-apt-repository "deb https://mkvtoolnix.download/ubuntu/ bionic main"
(or swap 'bionic' for the corresponding one Mint should be using, or just the latest one in general - if that version of Mint was based on Ubuntu 19.04, use 'disco')

Which will perform the requisite steps to add that to the sources and update the lists. This avoids having to make the user muddle around in config files.

Thank you. I've applied your suggestion and it seem to work fine. Well... whit some issues, if you want I can copy here the messages. But when I call MKVToolNix-gui, it shows the updated version ("Leave It", 37).

And a last question: I'd like to do what I did under Windows: right-click in the .MKV file then the option to open it with gMKVExtract Gui. I did that way because in the first time I try to open a .MKV file, I choose the .EXE in a folder. Now I don't know neither where or which file I have to point to open with an extract gui.

Mosu

10th September 2019, 17:53

Would it be okay to bundle the MKVToolNix command line tools in my Inviska MKV Extract AppImage?

In general: when you want to include someone else's work in your own package or when you have any question about the licensing of a specific piece of software, you should really contact the authors themselves, in MKVToolNix' case: me. My email address is readily available. Posting on a forum, not waiting for a response and just going ahead without understanding the licensing implications is not the polite thing to do.

That being said: MKVToolNix is licensed under the GPLv2. This allows you to do a lot of things wit the software, including re-distributing it either on its own or as part of a larger package. The website ChooseALicense.com (https://choosealicense.com/licenses/gpl-2.0/) contains a nice & concise list of things you may do & things you must do. Here's the list of things you must do and my additional information about it:

Disclose source — if anyone asks you, in whatever way, for the source code of the version of MKVToolNix you distribute, you must make that source code available. If you do not modify MKVToolNix, it suffices to link to the official MKVToolNix download locations. However, if you do make modifications to MKVToolNix, you must make those modifications available in source code form, too.
License and copyright notice — you must include the license and the copyright notice for MKVToolNix in your package. In general you can simply include the files "COPYING" and "README.md" from MKVToolNix in your package; just rename them to make it clear that they apply to the MKVToolNix portion of your package, not to your whole package (e.g. "COPYING.MKVToolNix" and "README.MKVToolNix.md", or place all of MKVToolNix' components in a single sub-directory called "MKVToolNix" and leave the original file names unmodified). Note that your package's own documentation (README file or whatever) should (must?) include a note that your package contains another piece of software, MKVToolNix, and where to find its license & copyright information (point to the "COPYING" and "README.md" files you've included).
Same license — this only applies if you made any modification to MKVToolNix. If you do, those changes must be licensed under the GPLv2, too. Note that this does NOT apply to any other application that's part of your package — you could easly bundle an application licensed under BSD-2-clause with another application covered under a proprietary licensed together with MKVToolNix in your package! "Same license" really only applies to any changes made directly to the copy of MKVToolNix you distribute.
State changes — again, this only applies if you made changes to MKVToolNix. If you did, you must document those changes (e.g. by including a diff file in your package containing the changes made, or by pointing to a git repository that contains each of your changes as commits).

Basically it's really easy, especially if you only distribute an unmodified copy of MKVToolNix. In that case include the license & README & point to them in your package's own documentation as described in point 2, and you'll be good to go.

Mosu

10th September 2019, 18:01

Only the first line worked but the others... I have the impression that "wget" is a command, that the second line is a file but I don't know what the third and fourth line are.

Welcome to Linux :) I suggest you read up on a couple of newbie guides. There are a ton of them out there, and they can really benefit new users.

Now: you're correct that "wget" is a command. It's used to download files from the internet. In this case, the whole command downloads a file from my web server with "wget" and feeds the file directly to a second command, "apt-key". What's downloaded is the GPG key that's used to cryptographically sign the locations where you will later download MKVToolNix from. That GPG key is fed to "apt-key", which installs that key as a trusted key for this type of operation (downloading & installing software from locations that are signed with that key).

The second line is indeed the name of a file which you must create. Lines three & four are the content you should place in said file. That file will configure the location where to download MKVToolNix from. That location is the one that's signed with the GPG key downloaded in step 1.

What qtyo27 posted is an alternative to creating that file manually. It runs another command, "add-apt-repository", which will create that file for you if it doesn't exist already and add the location information to it. It's slightly easier to use, but not available everywhere, which is why I'm not mentioning it on my web site.

And a last question: I'd like to do what I did under Windows: right-click in the .MKV file then the option to open it with gMKVExtract Gui.

That's something that has nothing to do with MKVToolNix. In fact, it has everything to do with the desktop environment you're using (on Linux there are tons of different desktop environments out there, unlike Windows where there's basically only one: Window's own). You should ask such a question on one of Linux Mint's forums. You'll likely have much better luck getting an answer there than here (e.g. I cannot answer your question as (1) I don't know which desktop environment Linux Mint uses by default as there are two or three possibilities and (2) even if I did, I only know how to do it in KDE/Plasma, and that's definitely not what Linux Mint is using).

Inviska

11th September 2019, 02:42

In general: when you want to include someone else's work in your own package or when you have any question about the licensing of a specific piece of software, you should really contact the authors themselves, in MKVToolNix' case: me. My email address is readily available. Posting on a forum, not waiting for a response and just going ahead without understanding the licensing implications is not the polite thing to do.

Sorry about that. A bug was reported with PureHD tracks and I was enthusiastic to release the new version with a fix, but I should have waited for your reply or emailed you. Sorry.

I've uploaded a new version of the AppImage with MKVToolNix removed.

Thanks a lot for the information about my obligations under the GPLv2 licence. For now I won't bundle MKVToolNix and will see how things progress. If Snaps and FlatPaks start to take off more I might have to include it, in which case I'll follow your instructions so it's done properly.

Again, sorry for uploading the other version without waiting for your response.

Mosu

11th September 2019, 17:04

No problem; I'm not mad or something :)

ripster

13th September 2019, 08:21

I am putting together a new PC build that will also be used for working with mkvtoolnix. Is there a benefit to using an Intel processor with more cores/threads in that machine with regard to processing times with mkvtoolnix?

I would get a k-processor with at least 4 cores anyhow but there is also the option to go up to 6 or 8 cores and the question whether it makes much of a difference to go for a processor with hyperthreading - seems that hyperthreading increases temperature substantially and due to that it limits maximum stable overclock.

mkver

13th September 2019, 09:33

mkvmerge is single-threaded and usually not CPU-bound, so hyperthreading doesn't really matter. The only thing against AMD that I can think of are recent bugs that resulted in crashes, but they seem to have been fixed already and when you buy a new one, you should already get the fix (see here (https://gitlab.com/mbunkus/mkvtoolnix/issues/2589)).

ripster

14th September 2019, 10:11

Thanks, what do you mean by not CPU-bound? I take it that single core speed should still play a role but I could use either an AMD or Intel platform?

mkver

14th September 2019, 16:46

It is usually bound by the speed of your HDD/SSD and RAM. After all, a lot of the stuff mkvmerge does is "copy data from here to there".

stax76

17th September 2019, 06:10

Does mkvextract support long paths on Win 10? First test showed it doesn't, might as well be an issue in staxrip though.

Selur

23rd September 2019, 17:14

I had written some code which could detect the stretching that worked with some old mkvinfo version, but since I used it last a bunch of stuff must have changed with the output of mkvinfo, so that code doesn't work any more.
So before I start to try to figure out what that code really indented to do and how it would need to be adjusted I wonder:

Is there an 'easy' way to detect whether an mkv contains a, by mkvtoolnix, strechted stream and by how much the stream was stretched (so that one can take the stretch into account when remuxing/reencoding such a file into another container)?

Cu Selur

sneaker_ger

23rd September 2019, 18:09

There is no one field you can just read. For video tracks you could look into the bitstream (e.g. AVC or HEVC time_scale and num_units_in_ticks). For audio tracks you could see whether the frames overlap or have gaps i.e. if [number of frames]*[duration of one single frame] matches the duration in the container. If you are lucky maybe by reading the DefaultDuration and comparing it to the frame size (if frame sizes for the given codec are constant, and if DefaultDuration is set in the first place). Without track statistic tags this potentially involves a lot of parsing. For subtitles it may be impossible (maybe one can find a pattern in the roundings?).

Are you sure your app was able to do such things?

Selur

23rd September 2019, 19:33

There is no one field you can just read.
a bunch of fields would have been nice too ;)

Are you sure your app was able to do such things?
Yup, but what it does/did is:
a. get the mkvinfo output
b. for each stream (only audio&video) collect it's raw length and the length in the container
c. compare raw and container size

Cu Selur

sneaker_ger

23rd September 2019, 20:43

But mkvinfo does not provide "raw length"?

Selur

23rd September 2019, 21:06

At least not that I'm aware of, from what I know you have to calculate it yourself by parsing the blocks. :)
I hoped there might be some additional (and 'new') data somewhere providing the info, since parsing the whole output is a pain for large files with xy streams. ;)

Cu Selur

Selur

24th September 2019, 09:09

For video stream detecting the stretch is easy you could compare the 'Codec's private data: size' and the 'Default duration' for the stream. My guess is this is how MediaInfo reports container vs. stream fps.
Sadly for audio streams (even if the frame size should be constant), you only sometimes have a 'Default duration' info and I haven't seen any 'Codec's private data: size' so far. :/
-> @Mosu: would it be possible to simply keep a single entry per stream which shows how much a streams duration was stretched in case this happens? Or is there some easy way to calculate stretch value?

sneaker_ger

24th September 2019, 09:28

A codec's private data doesn't change when stretched.

Liisachan

30th September 2019, 07:05

Hi! I'd appreciate any input from anyone.

Currently, when attached via GUI on Windows, a TTF file seems to get --attachment-mime-type application/x-truetype-font by default (*), an OTF gets --attachment-mime-type application/vnd.ms-opentype. On the other hand, RFC 8081 in Feb 2017 (https://tools.ietf.org/html/rfc8081) defined the official Media Types for them, font/ttf and font/otf, respectively, and there is also font/sfnt. My friend who muxes on Mac actually gets "application/font-sfnt" then "font/sfnt" by default for TTF, saying mkvmerge (on Mac) probably updated how it does things. Hence this ongoing debate among our group:
Opinion 1: We should now use the standardized media types (e.g. font/ttf), instead of non-standard wild types such as "application/x-font-ttf".
Opinion 2: We shouldn't. That will confuse many players, and the fonts won't be loaded/used properly.

In the long run, maybe we should start using "font/ttf" sooner or later, but if there is some kind of guideline that says that for maximum interoperability/compatibility one SHOULD keep using "application/x-truetype-font" for TTF in Matroska, perhaps that makes sense too.

@Mosu Do you (or Matroska devs) have any specs/opinions/plans about this matter?

(*) Very early versions of mkvmerge may have used "application/octet-stream", if I check old MKV files muxed in 2003-2004.

filler56789

30th September 2019, 08:32

Jamaika

30th September 2019, 09:30

From my point of view, I don't care what type we use. I was more interested in the possibility of adding ttf to subtitle and then playing. Under the condition that the recipient likes to watch with subtitles. If the ttf size was over 4MB, the movie didn't play on my computer. So what are we discussing?

Liisachan

30th September 2019, 11:19

Thanks for the comments.

Ouch! :eek:
Fonts never ever should have been defined as "application/something", to begin with.

Well, Matroska was born around 2003; the official Media Type "application/font-sfnt" was only defined in 2013 (and became obsolete in 2017 when "font/ttf" was defined), thus there was no "correct" choice in the first place between 2003-2013, except maybe generic "application/octet-stream" if anything. It's not like someone did something not-very-smart. Simply there was no "correct" answer at all.

@Jamaika You can use font subsetting so that only the glyphs used in your script will be supported. Say, you have a CJK font (4 MiB) supporting 40,000 glyphs, but you actually use 2,000 glyphs, then your compacted font will be like 0.2 MiB, which you can attach to your MKV instead of the huge original font file.

If we use "font/ttf" now, potentially many existing players won't load the attached TTF files. One example of such players is the last official version of MPC-HC from 2017, perhaps still used by a few people. We geeks can just use a newer (unofficial) MPC-HC for example, but that's something like using ECMAScript 2017 in an webpage simply because "our" nightly builds support it, ignoring normal users with regular browsers who want to enjoy the same page (but will experience problems).

Jamaika

30th September 2019, 11:31

Thanks for the comments.
@Jamaika You can use font subsetting so that only the glyphs used in your script will be supported. Say, you have a CJK font (4 MiB) supporting 40,000 glyphs, but you actually use 2,000 glyphs, then your compacted font will be like 0.2 MiB, which you can attach to your MKV instead of the huge original font file.

I don't know how to do it. I haven't seen users do this. There was to be a new version of libass v5.0 with new font tab options. Nothing that I know of. I think the topic has died and it's certainly not Matroska's problem. Anyway, the problem of enabling new features is associated with potential piracy than improving the video world.

About ttf: I read convert everything to otf. There are converters. How many votes so many ideas.

filler56789

30th September 2019, 16:53

Well, Matroska was born around 2003; the official Media Type "application/font-sfnt" was only defined in 2013 (and became obsolete in 2017 when "font/ttf" was defined), thus there was no "correct" choice in the first place between 2003-2013, except maybe generic "application/octet-stream" if anything. It's not like someone did something not-very-smart. Simply there was no "correct" options at all.

Well, I didn't say and I didn't mean that the Matroska developers are the ones to blame in this case. I stopped playing around with Web "development" (read: programming) ages ago, when nearly-nobody used font-embedding in HTML pages... and I was too ignorant and lazy to perceive that the "application/something" mime types were not a very-logical thing.

And yes, someone did something that was not-smart-at-all. Namely, the ones who decided that "application/sth" should be the umbrella label for anything that they were too lazy to classify properly... For example, they should have chosen archive/zip, archive/rar, document/pdf, document/msword, document/msexcel, mmedia/mp4, etc, instead of application/zip, application/rar, application/pdf and so on.

Liisachan

30th September 2019, 23:15

Let me clarify the context of my original question:

1. A media player that supports softsubbed MKV won't load the attached font files if it doesn't recognize them as fonts. Then styled subs will be broken (shown with some system default fonts), unless the attached fonts are already installed. This is bad!
2. Many programs (splitter, demuxer, etc.) seem to recognize an attached file as a font by checking its MIME type. So, in principle, you want to use an attachment-mime-type that makes every tool happy. But if "application/x-truetype-font" is going to be obsolete soon, we may want to discard backward compatibility.

Thus the original question: what should I type after --attachment-mime-type when attaching a TTF: "font/sfnt" as seen on Mac, "font/ttf" as in RFC, or actually "application/x-truetype-font" after all?

@Jamaika Subsetting is supported by Windows OS itself (https://docs.microsoft.com/en-us/windows/win32/api/fontsub/nf-fontsub-createfontpackage). It's widely used when embedding fonts in general, and there is no license problem unless subsetting is forbidden in fsType in the 'OS/2' table of that font. Since this is off-topic, you can start a new thread and/or PM me if interested.

@filler56789 To use new top-level types ("archive", "document", etc.), you MUST (https://tools.ietf.org/html/rfc6838#section-4.2.7) first define them via RFC, which would be probably time-consuming. But I see your point - e.g. "application/vnd.ms-opentype" looks a bit ugly (why ms- when it's supposed to be an open standard).

arrgh

4th October 2019, 18:18

hi
after some significant time, I wanted to check what the timeline might be for the muxing of MVC mkv-files...
here was the last reference to this...:
https://forum.doom9.org/showpost.php?p=1832794&postcount=5078

as can be seen here 3D is still of interest to many people, as also the tsmuxer open source project shows:
https://forum.doom9.org/showthread.php?p=1879321#post1879321

for a Fantasy / SciFi enthusiast 3D is still a topic, even when some people frown on it as on Micro-Plastic...:)

Mosu

6th October 2019, 13:02

Thus the original question: what should I type after --attachment-mime-type when attaching a TTF: "font/sfnt" as seen on Mac, "font/ttf" as in RFC, or actually "application/x-truetype-font" after all?

mkvmerge doesn't detect MIME types itself. It uses the widely used "libmagic" from the "file" project. Waaaay back when "libmagic" used to return "application/…" for fonts. Then one day they switched to "font/…". That was sometime in 2011, and it didn't go down well with users (see bug 682 (https://gitlab.com/mbunkus/mkvtoolnix/issues/682)[1]) as their programs weren't ready for "font/…". Therefore I implemented a workaround in mkvmerge in v5.2.0 which manually mapped "font/…" back to "application/…".

However, that was quite a long time ago. I don't think there's a definitive answer at the moment, though, as I'm not aware of any research/comparison of application wrt. them supporting "font/…". We would all benefit from a comprehensive test of all known implementations that support fonts in Matroska; try using both MIME types and create a mapping which implementation support which MIME type.

My gut feeling would be that there are still implementations out there that don't support "font/…", but I don't have any evidence for it.

Edit: Depending on the result I would definitely change MKVToolNix' default back to "font/…"; maybe make it configurable in the GUI for those who'd need backwards compatibility.

[1] Even though GitLab shows that the bug was "opened 4 years ago", that's only the date when I migrated the bug tracker to GitHub (!); the original dates couldn't be kept during that migration. The original bug was filed in 2011.

Mosu

6th October 2019, 14:16

Looks like it's time for MKVToolNix v38, which continues the bug-fixing tradition of previous releases.

There's one minor change wrt. packaging: Boost's Operators header library is now required.

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 38.0.0 "The Silent Type" 2019-10-06

New features and enhancements

mkvextract: chapters, tags & cue sheets will now be written to standard output if no file name is given, same as if "-" is given as the file name.
MKVToolNix GUI: job queue: added a new setting in the preferences' "job queue & job status" section that, when enabled, will cause the GUI to remove all output files created by jobs that are either aborted by the user or that end in an error. Implements #2614 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2614).

Bug fixes

all programs: macOS: fixed file access if the file name (including all path components) contains any Unicode character where NFC (Normalization Form Canonical Composed) and NFD (Normalization Form Canonical Decomposed) differ, e.g. German Umlauts. Fixes #2620 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2620).
mkvmerge: when splitting by chapters the user can now split by chapters coming from one of the appended files, too. Fixes #2625 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2625).
mkvmerge: AAC reader: fixed reading codec parameters (channels, sample rate) if a file starts with garbage that includes valid-but-bogus AAC headers. Fixes #2622 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2622).
MKVToolNix GUI: Hebrew was added to the list of often-used languages so that it can be selected by default again. Fixes #2610 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2610).
MKVToolNix GUI: when updating the GUI's settings from v37.0.0 or older, the GUI checks if the list of often-used languages equals the built-in list from v36.0.0. If it does, it will be updated to the built-in list changed in v37.0.0. Fixes #2611 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2611).

Build system changes

Boost's Operators header library is now required.

Have fun :)

Liisachan

7th October 2019, 06:34

Mosu: thank you very much for your detailed answer/clarification!
We would all benefit from a comprehensive test of all known implementations that support fonts in Matroska; try using both MIME types and create a mapping which implementation support which MIME type.

Not a comprehensive test, but a few key facts: Do players support an embedded TTF with the FileMimeType "font/" on Windows?

The latest version of MPC-BE (v1.5.3 @ 2019-04-01): NO
The latest (final) official version of MPC-HC (v1.7.13): NO
The latest unofficial version of MPC-HC (clsid2 builds): YES
zoomplayer: NO (according to my friend)

Those players marked NO do support an embedded TTF with the FileMimeType "application/x-truetype-font". So your gut feeling seems correct (e.g. MPC-BE from April 2019 does not support "font/"). I'd say it's still too early to migrate to "font/".

As a side note, it seems that when you mux a file on Mac, "font/sfnt" is used by default for TTF and "application/vnd.ms-opentype" for OTF; which is less than ideal even if one prefers "font/". RFC says, Use of "font/sfnt" is likely to be rare in practice. I.e. if you do use "font/", "font/ttf" should be used for TTF, not "font/sfnt"; and "font/otf" should be used for OTF, not "application/vnd.ms-opentype".

Aleksoid1978

7th October 2019, 07:26

Mosu: thank you very much for your detailed answer/clarification!

Not a comprehensive test, but a few key facts: Do players support an embedded TTF with the FileMimeType "font/" on Windows?

The latest version of MPC-BE (v1.5.3 @ 2019-04-01): NO
The latest (final) official version of MPC-HC (v1.7.13): NO
The latest unofficial version of MPC-HC (clsid2 builds): YES
zoomplayer: NO (according to my friend)

Those players marked NO do support an embedded TTF with the FileMimeType "application/x-truetype-font". So your gut feeling seems correct (e.g. MPC-BE from April 2019 does not support "font/"). I'd say it's still too early to migrate to "font/".

As a side note, it seems that when you mux a file on Mac, "font/sfnt" is used by default for TTF and "application/vnd.ms-opentype" for OTF; which is less than ideal even if one prefers "font/". RFC says, Use of "font/sfnt" is likely to be rare in practice. I.e. if you do use "font/", "font/ttf" should be used for TTF, not "font/sfnt"; and "font/otf" should be used for OTF, not "application/vnd.ms-opentype".

Upload short samples with "font/" mime type - i check and add support in MPC-BE.

nevcairiel

7th October 2019, 08:11

Not a comprehensive test, but a few key facts: Do players support an embedded TTF with the FileMimeType "font/" on Windows?

The latest version of MPC-BE (v1.5.3 @ 2019-04-01): NO
The latest (final) official version of MPC-HC (v1.7.13): NO
The latest unofficial version of MPC-HC (clsid2 builds): YES
zoomplayer: NO (according to my friend)

To be fair, MPC-HC does not actually support these mimetypes, it just has a fallback to look at the file extension of the attachment if its an unrecognized mimetype, and then accept .ttf and .otf files.
I have, however, added support just now for future versions. Software like ZoomPlayer that also uses LAV Filters should automatically inherit this support once its updated accordingly.

Mosu

7th October 2019, 09:10

Thanks!

Not a comprehensive test, but a few key facts: Do players support an embedded TTF with the FileMimeType "font/" on Windows?

The latest version of MPC-BE (v1.5.3 @ 2019-04-01): NO
The latest (final) official version of MPC-HC (v1.7.13): NO
The latest unofficial version of MPC-HC (clsid2 builds): YES
zoomplayer: NO (according to my friend)

Yikes, that's bad — but not entirely unexpected. This is the usual situation in which there is a solution that is "good enough" and where nothing much will change without a lot of (outside) pressure. In this case such pressure might be all applications creating Matroska files only using "font/…". However, that won't fly with users who'll rightfully complain that their newly created files don't work as expected.

Catch 22, once more.

Great to hear that both Aleksoid1978 and nevcairiel will add support for "font/…".

Liisachan

7th October 2019, 09:50

Upload short samples with "font/" mime type - i check and add support in MPC-BE.

fonts_embedded.mkv (http://faireal.net/image/public_domain/fonts_embedded.mkv) (268 KiB, 10 sec), testing four different FileMimeType values:
Test1 font/ttf
Test2 font/sfnt
Test3 application/font-sfnt
Test4 font/otf

Ideally, something like this is shown:
http://faireal.net/image/public_domain/fonts_embedded.jpg
Above = hardsubbed
Below = softsubbed <-- check this
(PNG (http://faireal.net/image/public_domain/fonts_embedded.png))

Aleksoid1978

7th October 2019, 11:12

fonts_embedded.mkv (http://faireal.net/image/public_domain/fonts_embedded.mkv) (268 KiB, 10 sec), testing four different FileMimeType values:
Test1 font/ttf
Test2 font/sfnt
Test3 application/font-sfnt
Test4 font/otf

Ideally, something like this is shown:
http://faireal.net/image/public_domain/fonts_embedded.jpg
Above = hardsubbed
Below = softsubbed <-- check this
(PNG (http://faireal.net/image/public_domain/fonts_embedded.png))

:)
It is interesting - who and why come up with different names for the same types.
What diff font/sfnt & application/font-sfnt ??

P.S. Do you have spec for new font/ mime types ?

Liisachan

7th October 2019, 12:19

:)
It is interesting - who and why come up with different names for the same types.
What diff font/sfnt & application/font-sfnt ??

P.S. Do you have spec for new font/ mime types ?

to the best of my knowledge:
font/ttf & font/otf = the current standard Media Type (https://www.iana.org/assignments/media-types/media-types.xhtml)s for TTF & OTF respectively, defined in 2017 as RFC 8081 (https://tools.ietf.org/html/rfc8081), assigned and listed (https://www.iana.org/assignments/media-types/media-types.xhtml#font) by the IANA
font/sfnt (https://tools.ietf.org/html/rfc8081#section-4.4.1) = abstract type that includes both font/ttf and font/otf
application/font-sfnt (https://www.iana.org/assignments/media-types/application/font-sfnt) = ex-standard (2013-2017), still valid (https://www.iana.org/assignments/media-types/media-types.xhtml#application) as a deprecated alias of font/sfnt

qyot27

7th October 2019, 12:45

fonts_embedded.mkv (http://faireal.net/image/public_domain/fonts_embedded.mkv) (268 KiB, 10 sec), testing four different FileMimeType values:
Test1 font/ttf
Test2 font/sfnt
Test3 application/font-sfnt
Test4 font/otf

Ideally, something like this is shown:
http://faireal.net/image/public_domain/fonts_embedded.jpg
Above = hardsubbed
Below = softsubbed <-- check this
(PNG (http://faireal.net/image/public_domain/fonts_embedded.png))

mpv passes all four tests, and it even warns the user about the old MIME type:
[sub/ass] Loading font attachment 'homework smart.TTF' with MIME type application/font-sfnt. Assuming this is a broken Matroska file, which was muxed without setting a correct font MIME type.

Liisachan

8th October 2019, 13:26

Since Mosu suggested a comprehensive test about "font/", I'm posting another test clip: fonts_embedded2.mkv (http://faireal.net/image/public_domain/fonts_embedded2.mkv) (329 KiB, 10 sec)
This one is like the first sample, except the three other subtypes will be tested:
Test5 = TTC attached as "font/collection" <-- mkvtoolnix-gui uses "application/x-truetype-font"
Test6 = WOFF attached as "font/woff"
Test7 = WOFF2 attached as "font/woff2"
Test8 = TTF files with extension .xtf are attached with 3 different FileMimeType values (mkvtoolnix-gui uses "application/x-truetype-font").
Test5 is practically important for a few users (esp. in CJK where TTC fonts are common). Test6/7 are only for completeness, not practical atm. Test8 is something different.

The letters in the upper area are hardsubbed. Ideally, softsubs in the lower area should look similar to the hardsubs, like this:
http://faireal.net/image/public_domain/fonts_embedded2.jpg (http://faireal.net/image/public_domain/fonts_embedded2.png)

mkvmerge doesn't detect MIME types itself. It uses the widely used "libmagic" from the "file" project. Waaaay back when "libmagic" used to return "application/…" for fonts. Then one day they switched to "font/…". That was sometime in 2011, and it didn't go down well with users (see bug 682 (https://gitlab.com/mbunkus/mkvtoolnix/issues/682)[1]) as their programs weren't ready for "font/…". Therefore I implemented a workaround in mkvmerge in v5.2.0 which manually mapped "font/…" back to "application/…".

As RFC 8081 pointed out, media types such as "font/ttf" had been non-existent until they were defined in 2017. If someone had started using it in 2011 in a widely used library, what they did was rather questionable, given that technically no one is allowed to use an arbitrary top-level media type, while anyone is allwed to use a subtype x-something privately. Besides, not "font/" but "application/font-sfnt" became the official media type for TTF/OTF in 2013.
It's only after 2017 that one may officially use "font/" when attaching a font file. So I think that this is a relatively new problem, not directly related to what you did in 2011. As for what you did in 2011, it was a correct move imho - refusing then-illegal media types in favor of legal (though unregisterable) x- subtypes.

@qyot27
While mpv seems to be a fantastic player, that warning message is a bit strange. Does it show a similar warning about "application/x-truetype-font"? As a fact, "application/font-sfnt" was the only standard Media Type for TTF/OTF before 2017 and it's still officially valid, so one could argue it's more correct than "application/x-truetype-font". Was mpv from 2016 happy about "application/font-sfnt" while unhappy about "font/ttf"? If so, in a way I'd respect such a rigorous player, though maybe it'd be more elegant to handle older files transparently, esp. when the file in question is technically not broken.

qyot27

8th October 2019, 15:40

@qyot27
While mpv seems to be a fantastic player, that warning message is a bit strange. Does it show a similar warning about "application/x-truetype-font"? As a fact, "application/font-sfnt" was the only standard Media Type for TTF/OTF before 2017 and it's still officially valid, so one could argue it's more correct than "application/x-truetype-font". Was mpv from 2016 happy about "application/font-sfnt" while unhappy about "font/ttf"? If so, in a way I'd respect such a rigorous player, though maybe it'd be more elegant to handle older files transparently, esp. when the file in question is technically not broken.

The relevant commit in mpv is f3d2f4c6c2a (from 2017-12-12), which added the font/ top level type to follow RFC8081. The list of font mimetypes it accepts in the subtitle demuxer is (currently, sub/sd_ass.c @ lines 85-92):
"application/x-truetype-font",
"application/vnd.ms-opentype",
"application/x-font-ttf",
"application/x-font", // probably incorrect
"font/collection",
"font/otf",
"font/sfnt",
"font/ttf",
And if it doesn't see the font as one of those, it throws that warning shown before. I'm not sure why it doesn't have "application/font-sfnt" in the list, as there's no indication that it was removed, but because mpv detects fonts based on file extension as well (sub/sd_ass.c @ line 96), Test 3 in the original file worked despite the warning, but the application/font-sfnt .xtf in Test 8 did not. The file extension detection may have simply masked the issue, so there was never any reason to explicitly include application/font-sfnt...maybe?

Liisachan

9th October 2019, 13:54

LAV Filters now explicitly support the 3 important now-standard Media Types and 1 standard alias (related code changes (https://git.1f0.de/gitweb?p=ffmpeg.git;a=commitdiff;h=8066ee422778255341277dd50d83ceb5b1f6a4b2)); the binary (https://files.1f0.de/lavf/nightly/) (v0.74.1-26) was tested with MPC and a few MPC-based players (by disabling their internal source filter for Matroska), 100% passing Tests 1-4 and 8 (one-upping mpv in Test 8 ;)). In the LAV Filters thread, I requested the addition of the "font/collection" support.

In retrospect, it would have been convenient if the Matroska specs had, under each AttachedFile, something like "AttachmentType", the value of which could have been 0 (default: unspecified), 1 (cover art), 2 (back cover art), 3 (embedded font), etc. Then, players could simply load everything as font iff AttachmentType=3, and it could reliably show the cover art in MKA even if a lot of images are attached.

Mosu

9th October 2019, 17:52

Thank you very much for all the investigative work, Liisachan!

MrVideo

11th October 2019, 21:30

I found a minor grammatical error in mkvmerge, as seen in the MKVToolnix GUI error output listing:
However, no headers where found for that track number.
The word "where" describes a physical location. The correct word is: were

Liisachan

12th October 2019, 07:03

@qyot27
Perhaps it simply shows that application/font-sfnt (https://www.iana.org/assignments/media-types/application/font-sfnt) was unsuccessful (*). Failure to support it is not a big problem as this type is so rarely used, and it's indirectly supported anyway if the extension is .ttf or .otf (I think). It's impressive that mpv's FileMimeType support was near perfect already 2 years ago.

@Mosu
Real thanks should go to Aleksoid1978 and Nevcairiel :) If ToolNix suddenly starts using the new font types, there may be a lot of confusion. I suggest there be a transitional period, like until the end of 2020 (or whenever you see fit); mkvmerge can output some kind of notices. E.g. if font/ttf is used too early, it could say, "this is a standard type name, but old players may not recognize it", and if application/x-truetype-font is used too late, it could say "you might want to use the newly standardized type names".

(*) meaning, the media type application/font-sfnt, though officially registered, was never commonly used. Most developers, servers, clients, end-users didn't start using it — perhaps they didn't/don't even know it exists — to the point that the same media type had to be re-defined using a more intuitive name, font/sfnt. CSS3 @font-face was still a Working Draft when application/font-woff & application/font-sfnt were registered in early 2013; maybe only a few, experimental and standard-aware parties (like Firefox devs?) were interested in them back then. One may remember that MSIE hadn't recognized application/xhtml+xml for many years even after XHTML 1.1 was standardized.

EDIT:
Now MPC-BE (r4808+) fully supports the 5 mime types: font/sfnt, /ttf, /otf, /collection & application/font-sfnt, passing Tests 1–5 & 8 100%. LAV is also already near-perfect (except font/collection), passing Tests 1–4 & 8 100%.

EDIT2 (2019-10-14):
Now LAV Filters fully support the 5 mime types!!

saracas

14th October 2019, 23:49

I cannot for the life of me figure out how to batch edit 300 MKVs using the same steps... I go into MKVtoolnix and copy the command line after setting one up one episode and I get this:

"C:/Program Files/MKVToolNix\mkvmerge.exe" --ui-language en --output ^"W:\SHOWNAME\Season 01\Show.Name.S01E01.DVD ^(1^).mkv^" --audio-tracks 1 --language 0:eng --track-name ^"0:MPEG-2 / 480p / 23.976 fps^" --language 1:jpn --track-name ^"1:Japanese / AC-3 / 2.0 / 448 kbps^" --default-track 1:yes --language 2:eng --track-name 2:English --default-track 2:yes --forced-track 2:yes ^"^(^" ^"W:\SHOWNAME\Season 01\Show.Name.S01E01.DVD.mkv^" ^"^)^" --track-order 0:0,0:1,0:2

How do I make the two directories in there specify all files in those folders? Basically all I am doing is removing english track and setting first subtitle track to forced for all these files.

Liisachan

15th October 2019, 00:47

you can try something like this example
test.bat
---
FOR %%f IN (*.mkv) DO (mkvmerge -o "new\%%f" --no-attachments "%%f")
---

EDIT (FIX)
I forgot to quote the last %%f, which doesn't work if a file name has a space, "%%f" should work in such a case too. The example above will transmux every MKV file in the current folder and write new files in the sub-folder "new". --no-attachments is just an example, where attachments will be dropped in newly created MKVs. One can replace this part with what they actually want to do.

Liisachan

18th October 2019, 01:09

[GUI] Error status from the previous session persists until explicitly acknowledged, even when no errors occur in the current session. Maybe by design, but could be confusing as follows:

Tested: MKVToolNix v38 on Win7 32-bit

Steps to repro:
1. Start mkvtoolnix-gui.exe, select a source file (e.g. some.avi)
2. Rename "some.avi" to "renamed.avi" behind the back of the GUI
3. On GUI: Start muxing -> the status bar shows [X] 1 error (as the source file is not found)
4. Just close mkvtoolnix-gui, restart it later -> Still [X] 1 error is shown
5. Select "renamed.avi" and mux it into "renamed.mkv" -> Now successful. but...

Expected result:
In most tools (especially command line ones), even if an error occurred in the previous session and an error message was shown, that error will be automatically forgotten if one restarts the tool and do something new. If old errors are remembered, the corresponding old error messages should be shown too, to explain what errors it is talking about.

What happened instead:
GUI still shows [X] 1 error. Job Output inconsistently says "No errors yet".

Mosu

18th October 2019, 08:30

In most tools (especially command line ones), even if an error occurred in the previous session and an error message was shown, that error will be automatically forgotten if one restarts the tool and do something new. If old errors are remembered, the corresponding old error messages should be shown too, to explain what errors it is talking about.

And that is the case for MKVToolNix, too. What you failed to realize is that the status bar indicators refer to the jobs known to MKVToolNix, not to what the "job output" tool shows. As soon as that job containing the error is removed, the status bar indicator will go back to 0 errors. In the same spirit, you can right-click on the job & select "View output". A new tab will be opened in the "job output" tool, and that tab will include the error.

On top of all that, the always-visible tab in the "job output" tool is labeled "current job". Of course there aren't any errors in it when you've just opened the GUI as there hasn't been a "current job" yet.

Mosu

18th October 2019, 08:36

I found a minor grammatical error in mkvmerge, as seen in the MKVToolnix GUI error output listing:

Thanks, I'll fix it.

Mosu

18th October 2019, 08:40

I suggest there be a transitional period, like until the end of 2020 (or whenever you see fit); mkvmerge can output some kind of notices. E.g. if font/ttf is used too early, it could say, "this is a standard type name, but old players may not recognize it", and if application/x-truetype-font is used too late, it could say "you might want to use the newly standardized type names".

I'm hesitant to add a real warning for such things as it would punish those who use the new types on purpose (punish in the sense that none of their jobs using the new font types would be succeeding anymore, and they'd always have to check if it was only due to the font warning or to something actually important). This means I'd have to make the warning configurable, and that's always a lot of work. A note would be fine, of course. Then again, a simple note would probably never be read by most GUI users.

End of 2020 sounds reasonable; maybe even a bit longer.

stax76

18th October 2019, 09:07

This means I'd have to make the warning configurable, and that's always a lot of work.

For the GUI aspect there are some ways to reduce the work, run time generated GUI is some work but easier to deal with than older UI toolkits (never worked with QT), generic GUI based on a grid is easier, most effective is just a INI conf file, I've used it this week for my new MediaInfo GUI and it was totally easy to do.

https://postimg.cc/TLkPDKsX

Mosu

18th October 2019, 13:40

The problem isn't adding yet another checkbox to the Qt UI. It's the amount of things to do for each such configurable thing:

Add checkbox in preferences dialog (trivial, it's one line in the corresponding .ui file)
Determine keyboard shortcut that isn't used by any other visible control for English & German
Save that setting in the configuration
Add a corresponding command line option to mkvmerge
Add help output for the new command line option
Add documentation in mkvmerge's man page
Implement both the warning as well as having it turned off in mkvmerge
Implement test cases for all three cases (other MIME type, bad MIME type with warning at defaults, bad MIME type with warning turned off)
Update the program & man page translations
Translate all the new content into German
Add a NEWS entry

Nothing about this is hard. It's just tedious & takes time. Nothing about what you've said would reduce the amount of work I'd have to do.

Liisachan

18th October 2019, 21:08

@Mosu
My point is, if MKVToolNix started using "font/" suddenly, there could be a lot of confusion. If you have a plan to migrate to the new types, I suggest you advertise in advance that there will be compatibility-breaking changes, so that subbers can make informed decisions. Warning from mkvmerge (CUI, not GUI) is one of the possible things you could do, but if it's not easy, that's fine. There are other things we could do, such as simply posting a short explanation in subtitle-related forums or making a user-friendly font-attachment FAQ page.

Maybe some subbers don't want to migrate to the new types. Technically, RFCs explicitly guarantee that one can freely use private x-tokens such as application/x-truetype-font as long as both parties (in this case muxer and player) agree on it. As such, it will be perfectly fine and standard-compliant (perhaps even recommended) to keep using x- MIME types privately inside Matroska (note: SSA/ASS itself is a private format, not officially standardized). In fact, when font-embedding was first implemented by Haali (as a patch to Gabest's splitter), it was announced in doom9 (https://forum.doom9.org/showthread.php?threadid=72086) that one MUST use application/x-truetype-font.
On the other hand, since Matroska is an open-spec format, where FileMimeType is defined as the MIME type, one may (and perhaps now should) use the registered MIME types. The catch is, doing so will generate MKVs that older players don't understand. In the worst case, subtitles will be unreadable at all. Sometimes the problem will be only stylistic (wrong font faces), though I imagine young typesetters will be upset when that happens (old typesetters know that font-embedding is optional to begin with, e.g. disabled by default in Haali Splitter until like 2007).

Yet another concern is, unless clearly documented (ideally as a footnote to FileMimeType in the official specs on Matroska.org), some of the legacy types might be forgotten quickly and new-generation players in the future won't play old MKVs right. There are actually as many as 10 different MIME Types that may be used for attached fonts. Implementers generally don't know this undocumented, confusing situation. For example, LAV Filters were fixed in v0.74 saying "Fonts embedded in MKVs without a proper mimetype were not being imported" - where it is assumed that the legacy types are the proper mime types. As another example, application/font-sfnt is registered but was/is poorly supported (even by mpv).
End users (including myself) are even more clueless. I only noticed this problem recently, though the top-level type "font" was registered in 2017. Imho, it could be helpful if mkvmerge warns when "problematic" MIME types are specified. But like you said, some of the "problematic" types are actually "good" (officially registered) ones, and there is no fool-safe solution to this dilemma. That said, there are a few end-users who happened to use new types such as application/font-sfnt simply because their tool chains had been updated that way, even though they wouldn't have used such poorly-supported types if warned about them.

I'd say, a warning like "font/ttf may cause problems. This is not an error. It's fine if you know what you're doing" wouldn't be "punishment". Seeing that, 1% of the users would be cool, like "yeah, I know why this warning is shown. This is a difficult problem and I see mkvmerge is trying to be helpful" and 99% of the users would be like "did I do something wrong? I'll have to check about this" - both would be good. In the second case, ideally they will do some search and will be like "I now understand the problem. I tested several players. I'll use font/ttf" - or they'll be like "I now understand the problem. I'll keep using x-types". Both options sound fine to me. Let them make an informed decision about their own files :)

As for the error status of GUI, it's ok if it's by design. I just wanted to point out that it could be confusing when one uses GUI as a one-time front end, and not as a batch-job front end.

~~PS~~
About the status bar message on GUI, I'd think two minor text changes might be helpful.
1) In the main manu: "Job queue" -> "Job queue/log"
2) In the context menu: "Show job queue" -> "Show job queue/log"

Unfamiliar with this GUI, one may assume the queue is empty in the example I described above (the same status bar says "Jobs to execute = 0, 0, 0", certainly looking like the queue is empty). This may be just me, but intuitively, one has no reason to look into the "Job queue" when an error is reported. But if the context menu item says "Show job queue/log" when "error(s)" is right-clicked, it'll be immediately clear where to look.

mood

20th October 2019, 20:58

In the last continuous build 38.0.0-revision-028, how can I disable the dark theme?? the new GUI is mess up, I'm using windows 7 x86

with same configuration settings, the dark theme GUI size change turn it a mess up

38.0.0-revision-028

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

38.0.0-revision-019

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

kuchikirukia

21st October 2019, 14:22

Sort of an odd request, but when setting mkvtoolnix to split by chapters, would it be possible to have a period as a valid separator along with the comma? Since I use the numpad to enter chapter numbers, it would make it far easier to enter 2.3.5.6 than reach all the way over for the comma. (I generally sit at an angle to my desk with the keyboard almost out of reach when I don't have it in my lap for typing, and just making a stab for the comma will usually end up with me hitting "m" or ".")

Any of /*-+ would also work. i.e. 2+3+5+6

filler56789

21st October 2019, 16:13

I agree with mood, the "dark theme" thing suxxx.
At least there should be an option to turn it off.

Mosu

21st October 2019, 20:09

In the last continuous build 38.0.0-revision-028, how can I disable the dark theme?? the new GUI is mess up, I'm using windows 7 x86

Oops, the dark theme was only supposed to be enabled if Windows' own color mode is set to dark. This check was buggy; it even enabled dark mode on Windows versions that don't actually support a color mode setting (anything before Windows 10 1809). I've just fixed that check. New continuous builds will be available in a couple of hours.

Mosu

21st October 2019, 20:10

Sort of an odd request, but when setting mkvtoolnix to split by chapters, would it be possible to have a period as a valid separator along with the comma?

I'm not going to add something like that, sorry. It would be confusing (why only there? Why that particular character? why is "," not enough, it works everywhere else?), and it would be a one-person-feature, something I'm really not keen to add.

Mosu

21st October 2019, 20:12

@Mosu
My point is, if MKVToolNix started using "font/" suddenly, there could be a lot of confusion.

That's definitely a good point. Announcing such a change in advance is indeed a good idea, something I've done in the past with other changes as well (e.g. the deprecation & later removal of options such as the verbose identification mode). It isn't something I'm willing to work on right now, though I'll probably revisit the topic early next year.

filler56789

22nd October 2019, 00:14

Oops, the dark theme was only supposed to be enabled if Windows' own color mode is set to dark. This check was buggy; it even enabled dark mode on Windows versions that don't actually support a color mode setting (anything before Windows 10 1809). I've just fixed that check. New continuous builds will be available in a couple of hours.

Just tested v38-029 and confirmed that now it works as expected :)

:thanks:

mood

22nd October 2019, 00:27

Liisachan

24th October 2019, 04:37

That's definitely a good point. Announcing such a change in advance is indeed a good idea, something I've done in the past with other changes as well (e.g. the deprecation & later removal of options such as the verbose identification mode). It isn't something I'm willing to work on right now, though I'll probably revisit the topic early next year.
Thanks for taking this seriously & sorry about the fuss. It's nothing urgent, really. What I'm worrying about is, what's happening like 10 years later. The offical FAQ (https://matroska.org/technical/guides/faq/index.html#q7) says: "Q: Will my .mkv files be compatible with future Matroska software if i will use current tools to mux my files? A: The files being created now are spec compliant." That sort of things.
It would be reassuring if in the future, there is a little footnote to FileMimeType in the specs, saying e.g. "For historical reasons please treat (a list of MIMEs) as 'font/sfnt'."

Also, I still think it would be more intuitive if the menu item "Show job queue" is renamed to "Show job queue/log" when "Error(s)" on the statusbar is right-clicked.

Another thing I always find counter-intutive about GUI is this. If you open a source file e.g. vorbis.ogg, and just try to close the GUI, it says...

Close modified file
-------------------
The file "vorbis.mka" has been modified. Do you really want to close?
[Close file] [Cancel]

From the user's point of view, "vorbis.mka" doesn't even exist, and it's not clear what the GUI "has modified" or what it wants to "close". If you [Close file], not the "modified file" but the GUI itself will close. I find this a bit illogical. I think what it wants to say is something like this:

Unsaved project
------------------
Unsaved changes to a job to write "vorbis.mka". Exit anyway?
[Yes] [Cancel]

This happens to me, e.g. when I use the GUI to generate a prototype command line, copy it to the clipboard, and quickly close the GUI without muxing.

Finally, I've noticed that MKVToolNix automatically imports a cover art in several cases, e.g. from FLAC, but not from MP4 (moov.udta.meta).

Perhaps none of the above are important (at least nothing is urgent). Perhaps some of them are known limitations or by design. Reporting them anyway just in case. Feel free to ignore them :) and thanks again for your hard work :D

Mosu

3rd November 2019, 12:16

Also, I still think it would be more intuitive if the menu item "Show job queue" is renamed to "Show job queue/log" when "Error(s)" on the statusbar is right-clicked.

I've just changed that to "Show job queue & access job logs".

From the user's point of view, "vorbis.mka" doesn't even exist, and it's not clear what the GUI "has modified" or what it wants to "close". If you [Close file], not the "modified file" but the GUI itself will close. I find this a bit illogical. I think what it wants to say is something like this:

I partially agree. I've changed the wording to make it clear that the program is asking about changed multiplex settings that would create a certain file.

I disagree about changing the wording to "exiting" the program. The thing is that the question applies both when you quit the program & when you close the current tab. In fact, quitting the program will first close all open tabs, and that's when the question is asked. It is asked for all tabs that have been modified (in the multiplexer, chapter editor & header editor). So labeling the button with "exit program" would be somewhat strange if one of the following tabs was modified, too; the question would again be asked for that tab, and the program would not have been quit yet. I'll leave the wording for the button as "close …".

Finally, I've noticed that MKVToolNix automatically imports a cover art in several cases, e.g. from FLAC, but not from MP4 (moov.udta.meta).

Yeah, it's not been on my radar yet. I'll look into implementing support for it.

Edit: gosh I wish Doom9 still had working email notifications…

Liisachan

4th November 2019, 14:49

I disagree about changing the wording to "exiting" the program. The thing is that the question applies both when you quit the program & when you close the current tab. In fact, quitting the program will first close all open tabs, and that's when the question is asked. It is asked for all tabs that have been modified (in the multiplexer, chapter editor & header editor). So labeling the button with "exit program" would be somewhat strange if one of the following tabs was modified, too; the question would again be asked for that tab, and the program would not have been quit yet. I'll leave the wording for the button as "close …".
Okay, that makes sense. I'm guessing everything looks cool in the original language (German), and changing text even a bit is actually a lot of work, since it'll have to be re-translated to many user-interface languages. Please don't overthink about my random observations... Take it easy & thanks again :)

Mosu

4th November 2019, 23:48

Good evening everyone. Here's a nice fresh release of MKVToolNix for y'all: v39.

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 39.0.0 "In The Waiting Line" 2019-11-04
New features and enhancements

mkvmerge: Blu-ray: when reading an MPLS playlist mkvmerge will look up and use chapter names from the Blu-ray's "track/chapter names" meta data if it exists. Part of the implementation of 2486.
mkvmerge: MP4 reader: if present, cover art images (the "meta.udta.ilist.covr" atom) will be converted into attachments.
MKVToolNix GUI: multiplexer: when adding a playlist from a Blu-ray disc, the disc library meta data will be parsed, and the biggest thumbnail, if present, will be added as a new attachment with name "cover.jpg" (extension depends on thumbnail's extension). Implements #2644 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2644).
MKVToolNix GUI: multiplexer: when adding a playlist from a Blu-ray disc, the title from the disc library meta data will be set as the new file title if the disc library meta data contains one & no title has been set yet.
MKVToolNix GUI: multiplexer: the automatically generated destination file name will now be based on the file title if one is set at that point. This works in conjunction with the title being said from the Blu-ray disc library meta data.
MKVToolNix GUI: chapter editor: when reading chapters from an MPLS playlist the GUI will look up and use chapter names from the Blu-ray's "track/chapter names" meta data if it exists. Part of the implementation of 2486.
MKVToolNix GUI: Windows: added a dark mode that's enabled when Windows 10's dark mode is turned on.
translations: added a Bulgarian translation of the programs & the man pages by Симеон Цветков (see "AUTHORS").

Bug fixes

mkvmerge: attachments without a file name won't be ignored anymore. Part of the fix of #2642 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2642).
MKVToolNix GUI: header editor: attachments with an empty name element will be shown as "<unnamed>" as originally intended. Part of the fix of #2642 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2642).
Linux AppImage: the AppImage will no longer change directories before running the desired executable allow the use of relative file names. Fixes #2632 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2632).

Build system changes

MKVToolNix now requires a C++ compiler that supports the following features of the C++17 standard: ""[[maybe_unused]]" attribute", "nested namespace definition", "structured bindings". For the GNU Compiler Collection (gcc) this means v7 or newer; for clang it means v4 or newer.
Boost 1.60.0 or newer is now required.

Have fun :)

hubblec4

5th November 2019, 14:05

Thank you for your work all the time.

DMD

5th November 2019, 14:29

I congratulate the developers of the 39.00 release, the dark blue graphic appearance is very welcome and restful.
Thanks :thanks:

Liisachan

5th November 2019, 21:24

@Mosu
Thanks a lot! Tested MP4 cover art support: it works fine, even supporting 2 or more cover arts flawlessly. Very cool :) Also, thanks for text tweaking.
Really appreciated.

Just so you know (not your problem!): While testing, I noticed that foobar2000 (tested v1.5 beta20) writes cover art(s), under certain conditions, in a non-standard position of MP4 (moov.udta.tags.cvrx). I think you can ignore such wild cover art(s). Compared with older version, fb2k is now trying to use moov.udta.meta more, but it still uses moov.udta.tags at least sometimes.

EDIT
changelog typos?
"meta.udta" -> "udta.meta"
"ilist" -> "ilst"

Mosu

6th November 2019, 15:53

Thanks a lot! Tested MP4 cover art support: it works fine, even supporting 2 or more cover arts flawlessly. Very cool :)

Good to hear. The only files I had available for testing were ones with a single cover art picture each; therefore I couldn't test that.

changelog typos?
"meta.udta" -> "udta.meta"
"ilist" -> "ilst"

Yeah, typos. I'll fix them. Thanks.

Liisachan

7th November 2019, 13:27

Good to hear. The only files I had available for testing were ones with a single cover art picture each; therefore I couldn't test that.

Thanks :) but small bad news: MPC-like players (including the latest MPC-BE) and LAV recognize a cover art in BMP too, iff the atom flag is 0x1b (undocumented value?).

I don't think there are many MP4s with BMP cover arts, but such images are somehow widely supported anyway (MPC, LAV, foobar2000). Currently MKVToolNix treats such a BMP as cover.jpg (image/jpeg) when it's actually BMP, which is obviously not good.

Maybe the right thing to do is, treat a cover as jpeg if 0x0d, as a png if 0x0e, otherwise just ignore a cover image as unrecognizable. Of course you could support non-standard (?) BMP covers if you'd like to... or you can just ignore this problem as such a file is perhaps actually rare.

Here's a sample clip (http://faireal.net/image/2019/3covers.mp4) - no video, silent audio + 3 cover arts in PNG/JPG and BMP. When e.g. MPC-HC (clsid2) plays this clip, it even shows the BMP image like a static video, as it's the 1st cover art.

EDIT
1. It seems that mp4 parsers tend to ignore this atom flag, and instead read the first 4 bytes of the image data to see if it's JPEG or PNG.
2. FYI: foobar2000 (audio player for Windows) also accepts BMP and GIF (not only JPEG and PNG) in its "Import picture file" dialog box. As such, an MP4 file written by foobar2000 is generally broken (not standard-compliant) in more than one aspect.

redbtn

8th November 2019, 02:57

tormento

8th November 2019, 11:27

Is it possible to have the light theme back? I find the dark theme too dark.

Mosu

8th November 2019, 16:35

Thanks :) but small bad news: MPC-like players (including the latest MPC-BE) and LAV recognize a cover art in BMP too, iff the atom flag is 0x1b (undocumented value?).

Thanks, I'll add BMP handling & skipping cover art with unsupported type fields (instead of treating them as JPEG).

Mosu

8th November 2019, 16:36

Is it possible to have the light theme back? I find the dark theme too dark.

See here (https://gitlab.com/mbunkus/mkvtoolnix/issues/2646).

Mosu

8th November 2019, 16:43

Something weird happens. When I mux 7.1 channel opus file into MKV, it seems like some metadata is lost.
It doesn't have Channel layout anymore (mediainfo shows only L channel, I think WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X6 is lost) and information about encoder, maybe something else.

I don't know how channel layout is stored off the top of my head. I'll have to investigate. Please upload one such Opus file (from before muxing it!) to my file server (https://gitlab.com/mbunkus/mkvtoolnix/wikis/FTP-server) or somewhere else I can get to. Thanks.

And after demuxing opus from MKV, files are not the same. They looks very different in hex editor. Is it normal? I'm asking because any other formats like flac, dts, ac3 etc exactly the same after mux>demux.

That is normal as Opus is extracted into the Ogg container format (same as Vorbis, but unlike the other formats you've listed which do not require a container around them). That process is lossy, e.g. the stream's serial number is chosen randomly during extraction.

redbtn

8th November 2019, 17:18

I don't know how channel layout is stored off the top of my head. I'll have to investigate. Please upload one such Opus file (from before muxing it!) to my file server (https://gitlab.com/mbunkus/mkvtoolnix/wikis/FTP-server) or somewhere else I can get to. Thanks.
Done. File named "opus-512.opus"

Original

Channel(s)_Original : 8
Channel(s)_Original : 8 channels
Channel positions : Front: L C R, Side: L R, Back: L R, LFE
ChannelPositions_Original : Front: L C R, Side: L R, Rear: L R, LFE
Channel positions : 3/2/2.1
ChannelPositions_Original : 3/2/3 ( i dont know why, cuz original flac before convert to opus was 3/2/2.1 )
Channel layout : L R C LFE Lb Rb Ls Rs

After muxing

Channel(s) : 8
Channel(s) : 8 channels
Channel positions : Front: L C R, Side: L R, Rear: L R, LFE
Channel positions : 3/2/3
Channel layout : L

Mosu

8th November 2019, 17:40

Ah right; the source file stores information such as the the encoder used or the channel layout in Vorbis comment packets (what other containers call "tags"). mkvmerge doesn't support converting Vorbis comments to Matroska tags and back at the moment. I might work on that some day. If you want me to, please open an issue over on GitLab (https://gitlab.com/mbunkus/mkvtoolnix/issues/); otherwise chances are I'll forget about it again.

redbtn

8th November 2019, 17:47

Mosu

8th November 2019, 17:55

That I cannot answer.

john33

9th November 2019, 10:36

Abs62

9th November 2019, 11:06

When I set .mkv file as source, v39.0.0 GUI make destination filename from "Title" field instead of source filename as in previous versions. How to return old behaviour?

Mosu

9th November 2019, 11:37

When I set .mkv file as source, v39.0.0 GUI make destination filename from "Title" field instead of source filename as in previous versions. How to return old behaviour?

See this issue (https://gitlab.com/mbunkus/mkvtoolnix/issues/2648).

Mosu

9th November 2019, 11:38

The channel mapping info is contained in the opus header and, by default, is the same as for vorbis files. It would be reasonable to expect any self-respecting decoder/player to map the output correctly but clearly there are no guarantees. ;)

Yeah. Even when I'll implement converting Vorbis comments to Matroska tags, I will likely not keep any tags regarding channel mapping for Opus files as the format itself specifies the channel mapping.

Mosu

9th November 2019, 14:09

Hey y'all,

there's been quite a lot of feedback on the changes in v39, and due to it I decided to make two of the new features configurable: the dark mode for Windows & deriving the file name from the file title. Combine that with an easy-to-trigger regression in the MP4 handling in v39, and I've decided to get a new release out sooner rather than later. So here it is, v40.0.0 is out.

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 40.0.0 "Old Town Road + Pony" 2019-11-09
New features and enhancements

mkvmerge: MP4 reader: added support for BMP covert art images.
MKVToolNix GUI: multiplexer: added an option to disable deriving the destination file name from the file title. Implements #2648 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2648).
MKVToolNix GUI: multiplexer: the content of the "stereoscopy" combo box has been simplified making the box's minimum width much smaller, allowing the user to resize the GUI's whole window to a much smaller width.
MKVToolNix GUI: multiplexer: whenever the user changes the "aspect ratio" or "display dimensions" controls, the corresponding radio button will be activated automatically. Implements #2651 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2651).
MKVToolNix GUI: Windows: added a setting in the preferences to disable the GUI's dark color mode even if Windows's app color mode is set to dark. Implements #2646 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2646).
MKVToolNix GUI: Windows: replaced the dark mode introduced in v39 with another dark mode that's less wasteful with space between widgets.

Bug fixes

mkvmerge: MP4 reader: mkvmerge was reading eight bytes too many for cover art images. This could cause file identification to fail when the cover art was located at the end of the MP4 file. Even if it succeeded, this meant too much data present in the attachment. Fixes #2650 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2650).
mkvmerge: MP4 reader: covert art images with unknown image types will be skipped instead of treated as JPEG images.

Build system changes

Qt 5.9.0 or newer is now required for building MKVToolNix GUI.

Have fun :)

sneaker_ger

9th November 2019, 15:14

Something weird happens. When I mux 7.1 channel opus file into MKV, it seems like some metadata is lost.
It doesn't have Channel layout anymore (mediainfo shows only L channel, I think WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X6 is lost) and information about encoder, maybe something else.
I get this even when encoding from 7.1 wav to 7.1 opus via OpusEnc directly (no MKVToolNix involved). Are we certain it is an MKVToolNix and not e.g. a MediaInfo issue?

General
Complete name : source.wav
Format : Wave
File size : 3.66 MiB
Duration : 5 s 0 ms
Overall bit rate mode : Constant
Overall bit rate : 6 144 kb/s
Writing application : Lavf58.33.100

Audio
Format : PCM
Format settings : Little / Signed
Codec ID : 00000001-0000-0010-8000-00AA00389B71
Duration : 5 s 0 ms
Bit rate mode : Constant
Bit rate : 6 144 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Lb Rb Ls Rs
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 3.66 MiB (100%)

General
Complete name : encode.opus
Format : Ogg
File size : 76.2 KiB
Duration : 5 s 7 ms
Overall bit rate : 125 kb/s
Writing application : opusenc from opus-tools 0.2-3-gf5f571b

Audio
ID : 10181 (0x27C5)
Format : Opus
Duration : 5 s 7 ms
Channel(s) : 8 channels
Channel layout : L
Sampling rate : 48.0 kHz
Compression mode : Lossy
Writing library : libopus 1.3-26-ge85ed772, libopusenc 0.2.1-2-g9cb17c6

https://www.sendspace.com/file/3x7564

redbtn

9th November 2019, 16:12

It's not MediaInfo issue cuz I can see (in hex editor) WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X6 in source opus file and I can't see it in file after mux>demux. But since opus has only one Channel Layout for 7.1, I think it's not a big problem for decoder. But, I'll open an issue later, maybe it will be possible to save this information in MKV down the road.
Ps: I downloaded your wav file, and it was made by ffmpeg. FFmpeg doesn't save WAVEFORMATEXTENSIBLE_CHANNEL_MASK at all. You can check it, make flac (or another format) from source like TrueHD in eac3to and in ffmpeg and compare.

Mosu

9th November 2019, 16:40

There's no use for a channel configuration indication if the format's specification explicitly says what the channel configuration for a given number of channels must be. All it does is confuse users (and developers).

redbtn

9th November 2019, 19:23

I was worried about the differences in the opus files before and after mux>demux. But I investigated it deeper and I found differences in headers of every frame, all other information the same. And if I convert these files to flac they are identical. So, all works perfectly. I take my hat off to Mosu

Liisachan

11th November 2019, 00:39

Thanks Mosu. I can verify the mp4 cover art 8-byte bug in 39 and fix in 40 (also BMP cover art support).

Something cosmetic - the GUI is no more fully DPI-aware on Windows (at least on Win7) starting from around version 25, when the default window size is initially calculated. The [Start multiplexing] button etc. are not visible when GUI opens the first time, if the DPI is higher than 96.
The image below shows the GUI versions 20 (left) and 40, on Windows 7, when 120 dpi is used.

http://faireal.net/image/2019/mmg120dpi.jpg (http://faireal.net/image/2019/mmg120dpi.png)
Click to enlarge

EDIT
Verified: Jpeg/Png/BMP image in MP4 -> imported to MKV attachments bit-identically
Verified: Unrecognizable artwork in MP4 -> ignored ok
(FYI) MPC/LAV recognize Jpeg/PNG even if their flags are wrong/unrecognizable (not sure how this actually helps, but kind of impressive)
Question: Is libmpagic reliable? The registered media type of BMP seems to be image/bmp (https://www.iana.org/assignments/media-types/media-types.xhtml#image), but the GUI automatically uses image/x-ms-bmp. This lib used strange font mime types in the past too. MPC shows a BMP cover art in MP4 correctly as "image/bmp".

SeeMoreDigital

11th November 2019, 10:38

Something cosmetic - the GUI is no more fully DPI-aware on Windows (at least on Win7) starting from around version 25, when the default window size is initially calculated. The [Start multiplexing] button etc. are not visible when GUI opens the first time, if the DPI is higher than 96.
The image below shows the GUI versions 20 (left) and 40, on Windows 7, when 120 dpi is used.

I can confirm much the same behaviour with Windows 10. I've been meaning to mention it :o

Atak_Snajpera

14th November 2019, 16:10

I've just noticed that mkvtoolnix-gui.exe can't be compressed by upx without --force switch. This is first time I had to use that option on executable. I wonder what is so unusual in that executable?
https://i.postimg.cc/fLTS7nKD/Capture.png

filler56789

14th November 2019, 18:54

I've just noticed that mkvtoolnix-gui.exe can't be compressed by upx without --force switch. This is first time I had to use that option on executable.
https://i.postimg.cc/fLTS7nKD/Capture.png

I confirm that, it's been happening since various revisions ago... I never reported it though because I thought it was not an actual issue...

I wonder what is so unusual in that executable?

Good question :confused:

Mosu

14th November 2019, 23:01

Something cosmetic - the GUI is no more fully DPI-aware on Windows (at least on Win7) starting from around version 25, when the default window size is initially calculated.

Ugh, I hate high DPI shit. It's really, really hard getting good information how one is supposed to make all of it work correctly, including the user-defined UI scaling thingy in Windows, _and_ how to make it all work in a cross-platform way.

I will likely have to look into it again sometime in the future, but it's really one of my least favorite areas to work on. So don't expect any miracles.

On top of that note that I won't spend time on Windows 7 specific issues anymore as Windows 7 nears even the end of its extended support period (2020-01-14). No, this doesn't mean the GUI will magically stop working on W7 on that date. Yes, I did read that a Windows 10 user complained about the same thing one post after yours, and I will look into the high DPI issue, but I will only do so on W10, and if a fix works on W10 but not on W7, then it'll likely stay unfixed for W7.

Question: Is libmpagic reliable? The registered media type of BMP seems to be image/bmp (https://www.iana.org/assignments/media-types/media-types.xhtml#image), but the GUI automatically uses image/x-ms-bmp.

I… honestly don't know. The "file" project (where libmagic comes from) is _the_ default content type recognition library on all Open Source systems; it's used in thousands of commercial/proprietary products, too. Maybe it's a backwards-compatibility thing?

Regarding MIME types for attachments from MP4 files: I don't use libmagic for them, actually, I simply use ones depending on the numeric object type present in the MP4 file. As "file --mime-type somefile.bmp" said "image/x-ms-bmp", that's what I hardcoded. I'll change it to "image/bmp".

Mosu

14th November 2019, 23:08

manolito

15th November 2019, 01:36

On top of that note that I won't spend time on Windows 7 specific issues anymore as Windows 7 nears even the end of its extended support period (2020-01-14). No, this doesn't mean the GUI will magically stop working on W7 on that date. Yes, I did read that a Windows 10 user complained about the same thing one post after yours, and I will look into the high DPI issue, but I will only do so on W10, and if a fix works on W10 but not on W7, then it'll likely stay unfixed for W7.

I think that it is a shame that developers like you show so little regard to the privacy concerns of so many users and government authorities (German conference of "Datenschutzbeauftragte"). Here is a link from Heise which is only a few days old:
https://www.heise.de/newsticker/meldung/Datenschutzkonferenz-Hohe-Huerden-fuer-den-Einsatz-von-Windows-10-4584678.html

For me Win10 is evil, I will never use it, and I am not the only one. It may make life a little easier for devs, but this is not enough to justify your decision to ignore Win7 compatibility in the near future.

Cheers
manolito

Liisachan

15th November 2019, 02:09

Ugh, I hate high DPI shit. It's really, really hard getting good information how one is supposed to make all of it work correctly, including the user-defined UI scaling thingy in Windows, _and_ how to make it all work in a cross-platform way.

I don't know how difficult it would be to make it cross-platform. If it were just for Windows, things would be rather trivial; e.g. when you create a logical font, you can multiply the font size by 96.0 / GetDeviceCaps( hDC, LOGPIXELSY ) and round the result to int, after that, functions like GetTextExtentPoint32 return the correct width and height of the text area in pixels, so you can place static text / GUI parts accordingly.

On top of that note that I won't spend time on Windows 7 specific issues anymore as Windows 7 nears even the end of its extended support period (2020-01-14). No, this doesn't mean the GUI will magically stop working on W7 on that date. Yes, I did read that a Windows 10 user complained about the same thing one post after yours, and I will look into the high DPI issue, but I will only do so on W10, and if a fix works on W10 but not on W7, then it'll likely stay unfixed for W7.

Fine with me :)
Many Windows programs don't work so well for me anyway. I have the taskbar thing at the top of my desktop, not at the bottom; a stupid program (including some tool created by Microsoft itself) always places its main window at y=0 of the desktop (below the task bar), so I can't even use its menu with mouse unless I move the window to a lower position using keyboard only. Compared with this, the problem of MKVToolNix GUI is very minor (I can just resize the main window a bit with mouse, and then that window size will be automatically used the next time).

That said, I think many people use larger and “dense” monitors these days, and higher-dpi settings are used more and more frequently. Although the problem is cosmetic and nothing urgent, I don't think it's W7-specific.

As for MIME types, since Matroska is a multimedia container where the MIME types are sometimes critically important, imho it would be safer if you manually hard-code some important MIME types (like you did for fonts). Even if libmagic is the de facto standard in the world, Matroska has its own internal (de facto) standard for historical reasons, widely supported in the multimedia world. This is mostly about font MIME types, and I know I'm paranoid; as a typesetter, the recent font mime-type related problem (fonts not loaded) was a bit traumatic, though the MIME type of BMP itself is not very important. Thanks again! :)

EDIT:
One can get the height of Windows GUI part this way:
Caption : GetSystemMetrics( SM_CYCAPTION )
Border : GetSystemMetrics( SM_CYSIZEFRAME )
Menu : GetSystemMetrics( SM_CYMENU ) or via GetMenuBarInfo (there may be a 1-pixel difference)
Statusbar : empirically (height of Caption) - 2, more reliably via GetWindowRect with hwndStatusbar

But like you said, the "theme" thing may confuse things even more...

Liisachan

15th November 2019, 02:27

For me Win10 is evil, I will never use it, and I am not the only one. It may make life a little easier for devs, but this is not enough to justify your decision to ignore Win7 compatibility in the near future.

I feel the pretty much the same way about Win10 itself, but the problem here is just cosmetic. We know we're going to have a lot of problems soon. You're going to protect yourself, not depending on security patches by Windows Update (actually I disabled Windows Update itself many years ago, in the services.msc level). While it would be great if many devs try to keep supporting Win7 in the future, maybe that won't happen so we're going to have to deal with minor conveniences by ourselves. The way I see it #1 problem of Win10 is forced updates (you don't own your windows; Windows own you... like in Soviet Russia). From what I gathered, the privacy issues of Win10 can be fixed relatively easily (there are many tools for that too). Anyway, let's be strong. You're not alone.

stax76

15th November 2019, 07:53

I think traditional QT isn't High DPI independent like QT Quick or WPF.

Mosu

15th November 2019, 18:10

I think that it is a shame that developers like you show so little regard…

This is the same discussion when I dropped support for XP. And I'm just as unsympathetic to your arguments. No one is forcing you to do anything, least of all using Windows 10. Looks like I have to re-iterate a couple of points about Open Source software in general and MKVToolNix in particular:

This is Open Source software. You get the source code. You can do anything you want with it. Don't like that XYZ doesn't work on Windows 7? Well, you get all the source to fix problems yourself or get someone else to fix them for you.
Just because I'm offering a program doesn't mean I'm under any obligation to make it suit your particular use case.
You don't even have to keep using Windows. MKVToolNix is a cross-platform product, and I've been offering (and will continue to) binaries for various Linux distributions as well as macOS. Switching from W7 doesn't mean you must switch to W10.
The best way to protect your privacy is not staying with an unsupported, proprietary operating system, but switching to an updated, free one instead. Like Linux. Or one of the BSDs. If privacy were really that important to you, you'd chose that route. But I'd wager you won't, which only means that privacy is either just a pretext for not liking Windows 10, or you're just angry that I don't value your personal level of privacy concerns the same as you.
You get something for free here. I don't owe you anything, and I'm 100% free to chose what I spend my time on.

ChaosKing

15th November 2019, 18:41

I think traditional QT isn't High DPI independent like QT Quick or WPF.

It seems high dpi scaling is also supports for legacy apps

Qt 5.6 supports cross-platform high-DPI scaling for legacy applications, similar to the scaling done natively in macOS. This allows applications written for low DPI screens to run unchanged on high DPI devices. This feature is opt-in, and can be enabled using the following environment variables:
QT_AUTO_SCREEN_SCALE_FACTOR
QT_SCALE_FACTOR
QT_SCREEN_SCALE_FACTORS
Source https://doc.qt.io/qt-5/highdpi.html

By default, Qt applications are set to Per-Monitor DPI Aware on Windows 8.1 or System-DPI Aware on older Windows versions.
Maybe this is why it is not scaling on win7?

stax76

15th November 2019, 19:00

The best way to protect your privacy is not staying with an unsupported, proprietary operating system, but switching to an updated, free one instead. Like Linux. Or one of the BSDs. If privacy were really that important to you, you'd chose that route. But I'd wager you won't, which only means that privacy is either just a pretext for not liking Windows 10, or you're just angry that I don't value your personal level of privacy concerns the same as you.

The way I see it is Linux technically is not on par with Windows, example one is no browser supports hw acceleration making YouTube unusable for people with 4K/UHD display. I can use mpv to watch YourTube but very often I want to use Chrome.

Second example is PowerShell which I as .NET programmer consider far superior to bash, everything .NET including PowerShell runs fine on Linux but there is still an ideology problem on Linux against Microsoft even though MS nowadays does much for Open Source, much more than Apple I believe and also even Torvalds made a statement that this kind of thinking does not help. If I remember correctly than you left github the time around when it was acquired by Microsoft.

manolito

15th November 2019, 19:56

This is the same discussion when I dropped support for XP.

Yeah, history repeating itself... :devil:

But there is one big difference this time. This time you are pushing your users towards using an Operating System (I am talking about Win10, IMO not many users consider Win8 or 8.1 as a viable alternative) which neither corporate users nor government agencies or other public organizations can legally use in Germany. And probably not in the whole European Union because the privacy laws come from the EU.

Did you even read the Heise artikel I linked to?
https://www.heise.de/newsticker/meldung/Datenschutzkonferenz-Hohe-Huerden-fuer-den-Einsatz-von-Windows-10-4584678.html

One of the key statements of this article:
Verschiedene Untersuchungen zeigten, dass es aktuell nicht möglich sei, die Übertragung insbesondere von Telemetrie-Daten "durch Konfiguration von Windows10 vollständig zu unterbinden.

Several research showed that it is actually impossible to completely disable the transfer especially of telemetry data by configuring Win10.

Since you have your own company you should be familiar with the DSGVO. This law makes it illegal for anyone whose business involves working with personal data of others to transfer such personal data to a third party without explicit consent of the persons who give their personal data to a European company. And transferring such data into a country like the US where no comparable privacy laws exist is completely forbidden.

And Win10 does just this.

Mosu

15th November 2019, 20:36

Again, I'm _not_ pushing you to use Windows 10. I would if I only offered a Windows 10 version of MKVToolNix. But I don't. I actually offer it for quite a range of operating systems.

And my philosophy is really easy: if the vendor doesn't support it anymore, I don't either. Unsupported software & unpatched machines are quite a problem on the internet (not just Windows, mind you, pretty much all IoT devices fall under this category as to wide swaths of home routers/modems).

So don't try playing the "W10 bad, W7 good" card; I completely reject that premise as it's a very selective view on a rather complex matter.

Mosu

15th November 2019, 20:47

It seems high dpi scaling is also supports for legacy apps

I'm well aware of Qt's documentation regarding high DPI settings. MKVToolNix is using the settings there (Qt::AA_EnableHighDpiScaling). However, that leads to interesting results, especially with the 125% scaling mode in Windows.

In general it works more or less.

What I haven't turned on yet is using proper high-density pixmaps for icons, mostly because I haven't figured out how to make the tool selector's icons behave properly (size calculation, drawing high-density pixmaps properly so they're scaled accordingly).

Certainly not impossible but rather time-consuming.

And the only high DPI monitor I have is connected to my Windows machine. That's all fine, but it makes testing with Linux hard & with macOS (this is just a VM) impossible. Hence me not liking having to work on this particular feature :)

Liisachan

15th November 2019, 23:52

@Mosu
Speaking of privacy... In MKVToolNix GUI, the "Check online for available updates" option is enabled by default. There are many such tools today, but good old tools tend to ask, "Do you want to automatically check updates...?" before phoning home for the first time. Yes, the right thing for me to do would be compiling my own version the way I like. I know that.

@manolito
Don't worry too much.
(1) Mosu explicitly said: “No, this doesn't mean the GUI will magically stop working on W7 on that date.” It's not like W7 support will be intentionally terminated.
(2) We're free to keep using an old OS; similarly we're free to keep using an old version of MKVToolNix forever. Not using the latest version too soon (i.e. using the same old version for a while) is actually a good idea for most (including Win10) users, so you can avoid accidental regressions and tacit compatibility-breaking changes, and make sure you have your MKV files consistent.
(3) Even if GUI becomes incompatible in the future, it's probably easy (if not trivial) to maintain Win7 compatible fork privately, as long as mkvmerge runs on Win7.

The best way to protect your privacy is not staying with an unsupported, proprietary operating system, but switching to an updated, free one instead. Like Linux. Or one of the BSDs. If privacy were really that important to you, you'd chose that route. But I'd wager you won't, which only means that privacy is either just a pretext for not liking Windows 10, or you're just angry that I don't value your personal level of privacy concerns the same as you. Don't bet on it :) I've been thinking that this might be a great opportunity (blessing in disguise) for me to finally migrate to Linux. I don't even like Win7 itself. My friend told me that the easiest way to migrate to Linux is Win10 + WSL. So I might actually get Win10 to learn how to use Linux (kind of ironic).

X : potential security/privacy risks by keeping using Win7
Y : immediate privacy issues and daily annoyance by using Win10
Many somehow assume X > Y. While X > Y might be true for naive users (e.g. if you use Google on Win7, you're already in a worse world than Win10), if you're careful, my gut feeling is X < Y at least for the time being. Sorry OT.

Mosu

18th November 2019, 20:38

Liisachan

21st November 2019, 13:46

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

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

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

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

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

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

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

Mosu

23rd November 2019, 19:16

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

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

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

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

That better?

Liisachan

26th November 2019, 00:58

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

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

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

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

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

DMD

27th November 2019, 17:19

Mosu

2nd December 2019, 22:40

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

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

SeeMoreDigital

2nd December 2019, 23:01

Sharc

4th December 2019, 12:58

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

hubblec4

4th December 2019, 16:21

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

You could try chapterEditor.

Sharc

4th December 2019, 22:21

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

Mosu

6th December 2019, 19:38

Hey,

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

Nothing's changed for package maintainers.

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

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

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

Version 41.0.0 "Smarra" 2019-12-06

New features and enhancements

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

Bug fixes

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

Have fun :)

redbtn

6th December 2019, 22:49

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

Overdrive80

7th December 2019, 23:35

redbtn

8th December 2019, 02:03

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

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

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

Dulus_No

8th December 2019, 06:36

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

redbtn

8th December 2019, 10:57

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

Liisachan

9th December 2019, 16:48

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

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

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

mkver

9th December 2019, 18:25

Such a thing already exists: --engage no_variable_data

Liisachan

10th December 2019, 15:58

Such a thing already exists: --engage no_variable_data

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

Mosu

10th December 2019, 19:03

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

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

Mosu

10th December 2019, 19:13

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

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

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

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

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

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

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

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

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

Liisachan

13th December 2019, 02:50

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

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

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

Mosu

13th December 2019, 11:39

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

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

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

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

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

Please open an issue for this, too. Thanks.

Megalith

21st December 2019, 21:05

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

rco133

26th December 2019, 10:43

Hi.

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

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

When I do it the following happens.

Order of added files:

video
DTS
AC3

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

video
AC3
DTS

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

No video, just audio
DTS
AC3

Result is DTS normal speed and AC3 is double speed.

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

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

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

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

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

Thanks in advance.

rco133

rco133

26th December 2019, 11:18

filler56789

26th December 2019, 14:16

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

rco133

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

Would you mind naming it?

rco133

26th December 2019, 19:11

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

Would you mind naming it?

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

Since my last post I have tried several software players.

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

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

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

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

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

rco133

Aleksoid1978

27th December 2019, 01:33

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

Since my last post I have tried several software players.

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

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

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

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

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

rco133

Can you upload problem file ?

Mosu

28th December 2019, 13:49

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

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

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

Liisachan

28th December 2019, 22:56

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

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

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

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

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

:thanks:

GCRaistlin

29th December 2019, 00:54

Selur

29th December 2019, 09:47

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

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

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

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

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

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

---
Update:

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

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

Cu Selur

Mosu

29th December 2019, 14:09

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

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

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

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

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

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

That is absolutely correct.

Mosu

29th December 2019, 14:11

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

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

Forteen88

29th December 2019, 17:31

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

Liisachan

31st December 2019, 03:57

@Mosu
Thanks for clarification.

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

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

Selur

31st December 2019, 13:06

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

Liisachan

2nd January 2020, 00:38

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

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

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

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

mkver

2nd January 2020, 04:24

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

Liisachan

2nd January 2020, 07:07

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

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

Mosu

2nd January 2020, 12:56

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

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

Selur

2nd January 2020, 13:19

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

Mosu

2nd January 2020, 13:34

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

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

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

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

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

Mosu

2nd January 2020, 14:53

Hey everyone,

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

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

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

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

And now for the usual boilerplate:

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

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

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

Version 42.0.0 "Overtime" 2020-01-02
New features and enhancements

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

Bug fixes

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

Build system changes

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

Other changes

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

Have fun :)

GCRaistlin

4th January 2020, 16:27

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

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

Mosu

4th January 2020, 19:10

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

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

King Mustard

5th January 2020, 16:37

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

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

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

I have attached two screenshots:

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

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

mkver

5th January 2020, 18:03

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

MrVideo

8th January 2020, 07:38

Jumping in late to the potential loss of Win7 support.

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

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

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

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

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

End of my 2 cents.

Asmodian

9th January 2020, 07:12

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

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

SeeMoreDigital

9th January 2020, 18:04

Hi Mosu,

I don't know if anybody else has mentioned it but I'm happy to confirm that if you have an .mkv file that contains an HEVC video stream (stream #1) and a Dolby Vision stream (stream #2) that was created using the newest version of your Matroska muxer, if you drag and drop your .mkv file into the new 'open-source' build of TSmuxer GUI the new .m2ts file contains a perfectly viable Dolby Vision stream, which works perfectly.

So what-ever you've done, you've done a great job :D

Many, many thanks

Mosu

9th January 2020, 22:54

Interesting — as I actually haven't really changed anything in the HEVC code for quite a while apart from this one bug fix (https://gitlab.com/mbunkus/mkvtoolnix/commit/8d27558d9bf84b59b33b7efc0cb5313f15691984).

But I'll take it! :D

SeeMoreDigital

9th January 2020, 23:32

Yep it's great news...

MKVmerge mux: -

General
Unique ID : 42601498193025875308533413168111364906 (0x200CC006DA67D85C7D4829D2B5FB2B2A)
Complete name : D:\Re-mux tests [short duration]\Paramount Logo in Dolby Vision [With AC3 only].mkv
Format : Matroska
Format version : Version 4
File size : 111 MiB
Duration : 16 s 736 ms
Overall bit rate : 55.5 Mb/s
Encoded date : UTC 2020-01-09 22:20:19
Writing application : mkvmerge v42.0.0 ('Overtime') 64-bit
Writing library : libebml v1.3.10 + libmatroska v1.5.2

Video #1
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 16 s 725 ms
Bit rate : 49.4 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.248
Stream size : 98.4 MiB (89%)
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 143 cd/m2
Maximum Frame-Average Light Level : 41 cd/m2

Video #2
ID : 2
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 16 s 725 ms
Bit rate : 5 570 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.112
Stream size : 11.1 MiB (10%)
Default : No
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2

Audio
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 16 s 736 ms
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 1.28 MiB (1%)
Service kind : Complete Main
Default : No
Forced : No

TSmuxer GUI Re-mux 'Open Source' version: -

General
ID : 1 (0x1)
Complete name : D:\Re-mux tests [short duration]\Paramount Logo in Dolby Vision [TSmuxer re-mux]\AVCHD\BDMV\STREAM\00000.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 116 MiB
Duration : 16 s 714 ms
Overall bit rate mode : Variable
Overall bit rate : 58.2 Mb/s
Maximum Overall bit rate : 35.5 Mb/s

Video #1
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : 36
Duration : 16 s 599 ms
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 143 cd/m2
Maximum Frame-Average Light Level : 41 cd/m2

Video #2
ID : 4117 (0x1015)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : 36
Duration : 16 s 599 ms
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 16 s 736 ms
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 1.28 MiB (1%)
Service kind : Complete Main

If I have the time next week I'll re-mux a long duration movie (probably 2001: A Space Odyssey) to make sure everything remains in-sync and report back.

Cheers

Boulder

12th January 2020, 13:12

I have extracted chapters from an existing mkv file using InviskaMKVExtract. The extracted files work fine (drag and drop) in MKVToolNix GUI v41.0.0, but v42.0.0 doesn't accept them.

I pasted a sample chapter file here: https://pastebin.com/HHw12Z5X

filler56789

12th January 2020, 13:36

Overdue update...

Originally Posted by Atak_Snajpera

I've just noticed that mkvtoolnix-gui.exe can't be compressed by upx without --force switch. This is first time I had to use that option on executable. I wonder what is so unusual in that executable?

I really have no idea. I've never used upx, I definitely don't purposefully do anything to make upx's life harder.

Very-probably it's QT's fault --- the same problem happens with the GUI of tsMuxeR.

mkver

12th January 2020, 16:20

73ChargerFan

12th January 2020, 21:00

I used "split after specific timestamps" for the first time today. It rocks! A movie has 2min 27sec of music with no video at the beginning. I split it into two, and not only was that flawless, but it corrected the chapter marks also! Cool!

Mosu

14th January 2020, 21:25

Very-probably it's QT's fault

Well, that's a matter of perspective. As the original EXE is working perfectly fine while a program designed to mess around with a perfectly-fine-working EXE fails to produce another perfectly-fine working EXE, I'd argue that it's the messing-around program (UPX) that's at fault.

Mosu

26th January 2020, 15:38

Hey y'all,

let's do a second release in January, fixing a couple of annoyances that crept in lately. Just a smaller maintenance release; nothing earth shattering. But see for yourself down below.

Nothing's changed for package managers.

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 43.0.0 "The Quartermaster" 2020-01-26
New features and enhancements

MKVToolNix GUI: using one of the command line options "--info", "--edit-headers" or "--edit-chapters" will make the GUI select the corresponding tool on startup even if no further file name is given. Implements #2723 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2723).
MKVToolNix GUI: multiplexer: added a setting in the preferences for changing the location of the MediaInfo executable for when the user accidentally selected the wrong one.

Bug fixes

mkvmerge: AVC/h.264 parser: the order of the NALUs before each key frame was sometimes wrong: mkvmerge wrote SPS & PPS after SEI NALUs. Now SPS & PPS NALUs are always written before the other NALUs. Patch by Torsten Hauska. Part of the implementation of #2709 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2709) and part of the fix of #2250 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2250).
mkvmerge: AVC/h.264 parser: when additional SPS or PPS NALUs (with IDs that haven't been seen so far) are found mid-stream, mkvmerge will prepend all following key frames with all current valid SPS & PPS NALUs (just like when SPS & PPS NALUs are overwritten mid-stream). Part of the fix of #2250 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2250).
mkvmerge: MPEG TS reader: fixed detection of MPEG-1/2 video tracks consisting of very few frames. Fixes #2732 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2732).
mkvmerge: Ogg Opus reader: fixed the handling of Ogg Opus streams that contain a just one Ogg page ("mkvmerge" aborted with an exception). Fixes #2722 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2722).
MKVToolNix GUI: multiplexer: dragging & dropping XML files with chapters or tags to the GUI's window was broken in v42. Instead of adding the file names to the appropriate input boxes the GUI was running mkvmerge for file identification purposes which then failed. Fixes #2718 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2718).

Have fun :)

redbtn

27th January 2020, 12:41

Nice work Mosu! Thank you for release.

chros

27th January 2020, 12:49

If I have the time next week I'll re-mux a long duration movie (probably 2001: A Space Odyssey) to make sure everything remains in-sync and report back.
So, did it work well?

SeeMoreDigital

27th January 2020, 16:42

So, did it work well?As a matter of fact.... Yes it did. Perfectly :)

Bozotheclown

29th January 2020, 12:54

Hello,

Small suggestions:
job_output screenshot

17172

Status line:
- if "Completed OK" - in green color
- if "Failed" - red color

It would help to quick check if job is finished successfully or not.

Also working indicator (on bottom right) even after job has finished is in frozen state. I think it should disappear after job is done.

zeropc

29th January 2020, 20:42

Why was MKVToolNix support for macOS High Sierra and below dropped?

Mosu

30th January 2020, 14:19

Also working indicator (on bottom right) even after job has finished is in frozen state. I think it should disappear after job is done.

If a job wasn't successful, the "errors" indicator in the status bar would blink red and show a number > 0.

Mosu

30th January 2020, 14:20

Why was MKVToolNix support for macOS High Sierra and below dropped?

Because MKVToolNix now uses C++ features that Apple only supports on macOS 10.14 (Mojave) or newer.

zeropc

31st January 2020, 13:30

Because MKVToolNix now uses C++ features that Apple only supports on macOS 10.14 (Mojave) or newer.

I see. Thanks for the info :)

saracas

5th February 2020, 23:08

I have three questions:

- How does one make the remux (destination file) the exact same name as the original (source file), and also automatically delete source file when finished?

- How can I set the default track flag to YES by default? "Determine automatically" sets it to no even though it's the only sub track with foreign language audio.

- I am using a webui version of MKVToolNix which doesn't support drag and drop, when I add multiple files via Add Sources button it adds them all under the same job. If I drag and drop on Windows, I can add them as seperate jobs. How do I add multiple files as seperate jobs without drag and drop?

Thanks

leon

11th February 2020, 18:39

Mosu can you please look into this?

https://www.reddit.com/r/mkvtoolnix/comments/ev6olo/seems_like_theres_visual_bug_with_v43/

manolito

11th February 2020, 19:46

+1, I have the same thing on 2 machines. Can get a little irritating...

markfilipak

15th February 2020, 04:58

varekai

17th February 2020, 10:44

Howdy,

What subtitle & chapter tools do you recommend? I want to extract subtitles to SUP or SUB (not SRT). I'm not familiar with chapter tools, so I don't have any file-type suggestions. The subs & chaps will be imported to MKVToolNix GUI.

Thanks,
Mark.
I+want+to+extract+subtitles+to+SUP+or+SUB (https://www.google.com/search?ei=Yl5KXpToHsT3qwGrv6HYAw&q=I%2Bwant%2Bto%2Bextract%2Bsubtitles%2Bto%2BSUP%2Bor%2BSUB&oq=I%2Bwant%2Bto%2Bextract%2Bsubtitles%2Bto%2BSUP%2Bor%2BSUB&gs_l=psy-ab.3...10693.42408..43875...0.4..0.164.1043.15j1......0....1..gws-wiz.......0i71.sliVTmS_3kk&ved=0ahUKEwiUocq1pNjnAhXE-yoKHatfCDsQ4dUDCAs&uact=5)

chapter+tools+videohelp (https://www.google.com/search?ei=eV9KXq-fEqiMrwTs4oHABg&q=chapter%2Btools%2Bvideohelp&oq=chapter%2Btools%2Bvideohelp&gs_l=psy-ab.3...11709.14939..15933...0.0..0.77.608.10......0....1..gws-wiz.QB888IrYl9Y&ved=0ahUKEwjvv8K6pdjnAhUoxosKHWxxAGgQ4dUDCAs&uact=5)

Mosu

18th February 2020, 10:06

Mosu can you please look into this?

https://www.reddit.com/r/mkvtoolnix/comments/ev6olo/seems_like_theres_visual_bug_with_v43/

Nothing I can do about that short of downgrading Qt, which I'm not going to do as that would make other problems resurface. Please be patient; it'll likely get fixed someday in Qt and I update Qt regularly.

leon

18th February 2020, 11:21

Mosu

18th February 2020, 20:05

Mind you it uses Qt 5.14, don't remember what MKVToolnix v43 used.

You can check which Qt version MKVToolNix was built with via the "Help" → "System information" menu entry. For MKVToolNix v43 on Windows this was Qt 5.14.1.

Should I report that to Qt devs or they are already aware of the problem?

I wasn't able to find anything in their bug tracker with a quick search.

Note that this particular problem doesn't happen on all Windows installations (it doesn't on my Windows 10, my Windows Server 2016 and Server 2019 installations). Neither did anyone open a bug report for it.

If it only happens on Windows 7, you might have to prepare for the problem not to be fixed anymore.

manolito

20th February 2020, 01:08

If it only happens on Windows 7, you might have to prepare for the problem not to be fixed anymore.

This would be a stupid move by the Qt devs since Win7 still is the #2 of the most frequently used Operating Systems today...

FWIW mkvmerge-gui.exe version 42.0.0 runs nicely with mkvtoolnix 43.0.0. Use a "clicker" tool like ClickOFF to get rid of the warning popup.

Thunderbolt8

28th February 2020, 23:40

I have a small feature request for the GUI: Would it be possible to add a toggle reverse select button for the different streams/codecs in the "tracks, chapters and tags" window? Some source files contain a lot more subtitle streams compared to the usual two single audio and video streams you want to keep for muxing. In this case being able to deselect everything via pressing one button and simply reselect the few streams you want to keep would be way faster and more convenient than having to deselect ten or more subtitle streams all manually.

would be great if this could be implemented.

Mosu

5th March 2020, 15:17

Assuming tracks are grouped by type, which they often are:

Click on the top-most subtitle track
Press & hold Shift & click on the bottom-most subtitle track
Press return

That'll toggle "mux this" for all subtitle tracks. Really not that hard & doesn't really warrant yet another small function.

giantslirpy711

8th March 2020, 15:56

EDIT: MOSU, could you possibly help me figure this out.
I've hunted for an answer everywhere. The issue is not isolated to one file or type of files within mkv. I'm not saying it's a bug. I honestly have no idea what it is or how to fix it, but I have tried.

--------------------
I was attempting to see just how effective split by frame and timecodes was in doing any simple video editing thinking, sure why edit the video, to remove commerciqls or unwanted office content etc, just segment the MKV pull out the chunks you don't want.

Segmenting by filesize works great for years. Segment by frame seems to work fine as well but to be honest, editing by timecodes is giving me problems.

Here was my practice file. I attempted to make a cliff notes version of episode one. 50 min content edited down to 10min.

X:/Downloads/APPS/mkvtoolnix_all/mkvtoolnix-64-bit-41.0.0/mkvtoolnix\mkvmerge.exe --ui-language en --output ^"C:\MOVIES\REMUX2\Magicians.S04E01.mkv^" --language 0:jpn --default-track 0:yes --display-dimensions 0:1920x1080 --compression 0:none --language 1:eng --default-track 1:yes --compression 1:none --sub-charset 2:UTF-8 --language 2:eng --track-name 2:SDH --compression 2:none ^"^(^" ^"E:\MOVIES\Season.04\Magicians.S04E01.mkv^" ^"^)^" --clusters-in-meta-seek --generate-chapters interval:00:05:00 --track-order 0:0,0:1,0:2 --split ^"parts:00:00:00-00:01:35,+00:02:03-00:02:10,+00:02:24-00:02:30,+00:02:45-00:02:59,+00:03:20-00:03:46,+00:04:50-00:05:00,+00:06:23-00:06:32,+00:07:51-00:08:09,+00:10:30-00:11:58,+00:17:17-00:18:28,+00:19:40-00:20:11,+00:26:43-00:27:06,+00:28:07-00:28:37,+00:37:45-00:38:20,+00:39:35-00:40:07,+00:42:10-00:44:28^"

Ran fine no errors but file was a mess.

—The audio was out of sync within first 30 seconds and was 2 min out of sync by end of 10 minute mkv.
—there were strange spots where the picture would stutter at the transition Point rather than a clean slice.. It appeared to be showing a portion of the end of previous segment and the beginning of next segment at same time.

—I bumped timecodes to 10000000
—I changed the cluster size to 100 thinking maybe smaller clusters could be sliced up easier.

The final product was still SEVERELY out of sync audio with video.

Any comments on why this happens and what to do to avoid it would be appreciated.

I've chopped up videos into 250MB chunks for x264 x265 test runs, ALL SEGMENTS perform perfectly.

No idea why do timecodes segments fall apart
Any suggestions?

Mosu

8th March 2020, 19:56

Well hello everyon!

The last couple of weeks have been pretty slow wrt. MKVToolNix development (usually due to everything else being really hectic). Nevertheless I think it's time for a small maintenance
release.

Nothing's changed for package managers.

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 44.0.0 "Domino" 2020-03-08
New features and enhancements

MKVToolNix GUI: header editor: the attachments can now be reordered via drag & drop. Implements #2753 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2753).

Bug fixes

mkvmerge: Matroska reader: when encountering certain errors in the track headers such as the codec ID not being present mkvmerge will simply skip those tracks instead of exiting with an error. Fixes #2737 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2737).
MKVToolNix GUI: multiplexer: the "ask before overwriting" functionality did not look for the correct file names when splitting was active. Fixes #2741 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2741).

Have fun :)

hubblec4

8th March 2020, 20:36

Thank you very much for all your work in all this time.

markfilipak

13th March 2020, 05:29

Thank you for MKVToolNix.

From searches I see clues that there's a log file. I can't find a log file, or a way to configure MKVToolNix to make a log file.

When attempting to move audio channels in a particular, existing MKV, the process quits at 78% with "Failed". I want to know what provoked the failure.

Thanks,
Mark.

markfilipak

13th March 2020, 05:56

I+want+to+extract+subtitles+to+SUP+or+SUB (https://www.google.com/search?ei=Yl5KXpToHsT3qwGrv6HYAw&q=I%2Bwant%2Bto%2Bextract%2Bsubtitles%2Bto%2BSUP%2Bor%2BSUB&oq=I%2Bwant%2Bto%2Bextract%2Bsubtitles%2Bto%2BSUP%2Bor%2BSUB&gs_l=psy-ab.3...10693.42408..43875...0.4..0.164.1043.15j1......0....1..gws-wiz.......0i71.sliVTmS_3kk&ved=0ahUKEwiUocq1pNjnAhXE-yoKHatfCDsQ4dUDCAs&uact=5)

chapter+tools+videohelp (https://www.google.com/search?ei=eV9KXq-fEqiMrwTs4oHABg&q=chapter%2Btools%2Bvideohelp&oq=chapter%2Btools%2Bvideohelp&gs_l=psy-ab.3...11709.14939..15933...0.0..0.77.608.10......0....1..gws-wiz.QB888IrYl9Y&ved=0ahUKEwjvv8K6pdjnAhUoxosKHWxxAGgQ4dUDCAs&uact=5)

Thanks. What do you use?

Regards,
Mark.

varekai

13th March 2020, 09:57

Thanks. What do you use?
Regards,
Mark.
What I use for video subtitle projects.

tsMuxer
SubTitle Edit
Notepad++
MKVToolNix
MKVCleaver
gMKVExtract
easySUP

Regards,
varekai

Mosu

13th March 2020, 10:17

From searches I see clues that there's a log file. I can't find a log file, or a way to configure MKVToolNix to make a log file.

When muxing you can find the output in the "job output" tool.

For past jobs you can find the logs in the "job queue" tool: right-click on the job in question and select "view output". That'll open another tab in the "job output" tool containing the messages generated by that job.

markfilipak

14th March 2020, 12:30

When muxing you can find the output in the "job output" tool.

For past jobs you can find the logs in the "job queue" tool: right-click on the job in question and select "view output". That'll open another tab in the "job output" tool containing the messages generated by that job.
All they ever say is "Completed OK" or "Failed". I made a Failed (78%) remux the other day when I attempted to move an audio stream # in an MKV that I'd made the day before. I had no idea why it failed, just that it "Failed".

markfilipak

14th March 2020, 12:35

Ah! I never knew I could right-click on the job in question (there's no indication). Here's the output:

mkvmerge v41.0.0 ('Smarra') 64-bit
'xxxxx.mkv': Using the demultiplexer for the format 'Matroska'.
'xxxxx.mkv' track 0: Using the output module for the format 'MPEG-1/2 video'.
'xxxxx.mkv' track 1: Using the output module for the format 'AC-3'.
'xxxxx.mkv' track 2: Using the output module for the format 'AC-3'.
The file 'OUT.mkv' has been opened for writing.

As you can see, there's no indication why the remux "Failed".

tormento

14th March 2020, 16:36

I have a bunch of old AVI file I'd like to convert to MKV but file date is important to remember when they were shot.

Is there a way or a future feature to keep file time and data untouched? Any workaround?

Let me elaborate: image files have EXIF, where you can store date and time. There are a lot or programs that allows you to manipulate EXIF, file name, file date and whatsoever.

If we could store time and date into mkv container (perhaps even for every stream) from/to file name or file date it would be great.

SeeMoreDigital

14th March 2020, 19:51

I have a bunch of old AVI file I'd like to convert to MKV but file date is important to remember when they were shot.Out of interest.... What formats are the video and audio streams?

tormento

14th March 2020, 20:15

out of interest.... What formats are the video and audio streams?

xvid+mp3/ac3+srt

markfilipak

15th March 2020, 14:20

The source IFO has 10 PGCs (program chains).
Beginning with the 9th program, audio leads the video -- programs 1 to 8 were okay.
By tedious trial-&-error, I worked out that the audio needed to be delayed by 4400ms.
I may encounter something like this in the future.
I wonder whether there's a better way than my work flow.

Work flow:
Step 1: I used MKVToolNix to repackage the VOB as an MKV.
Step 2: I viewed the MKV via the MPV player and saw the audio leading towards the end of the MKV.
Step 3: I reran MKVToolNix and added an audio delay.
Step 4: I viewed the MKV again.
I repeated Steps 3 & 4, adjusting the audio delay until it was right.
Each time, I had to fast forward to the 9th program to see the result.
Between each step, I reran HandBrake to extract the 9th program (based on start/stop times) to verify that, indeed, I was getting what I wanted.
(I realize now that rerunning HandBrake in each loop was probably unnecessary and that I could have extracted the 9th program just once, at the end.)

Is there a better way to determine the needed audio delay than by trial-&-error?
Note that MKVToolNix's "Fix bitstream timing info" check box was unavailable (grayed out).

varekai, I haven't tried all your suggested tools (though I already have and use most of them).

Warm Regards,
Mark.

Mosu

15th March 2020, 14:58

I have a bunch of old AVI file I'd like to convert to MKV but file date is important to remember when they were shot.

Write a small shell script that first determines the modification timestamp of the source file, then muxes them and lastly changes the modification timestamp of the muxed file to the value remembered earlier. For example (this is with bash on Linux, but other OS will surely have similar tools available):

mtime=$(/usr/bin/stat --format=%Y src.avi)
mkvmerge -o out.mkv src.avi src.mp3
touch -d @$mtime out.mkv

Alternatively create a tag file with the tags you want to use.

Alternatively set the segment header's "date" field with mkvpropedit after muxing.

Mosu

15th March 2020, 15:01

Ah! I never knew I could right-click on the job in question (there's no indication).

How many programs that make use of context menus have you seen that give explicit hints that there's a context menu available? Serious question. I cannot think of a single one and would like to see how those programs do it.

As you can see, there's no indication why the remux "Failed".

There's a separate box for error messages; the don't show up in the regular output box. What does that error box show?

Mosu

15th March 2020, 15:03

EDIT: MOSU, could you possibly help me figure this out.

When I have something to say I usually respond. Therefore: when I don't respond I don't have anything productive to say or don't want to spend time on it.

SeeMoreDigital

15th March 2020, 15:05

xvid+mp3/ac3+srtIf your XviD video streams contain b-frames encoded with 'packed bit-stream' I recommend you remove it first - unless MKVToolNix is able to do this now.

Cheers

tormento

15th March 2020, 15:15

If your XviD video streams contain b-frames encoded with 'packed bit-stream' I recommend you remove it first - unless MKVToolNix is able to do this now.

Cheers

Thanks for your precious hint.

markfilipak

15th March 2020, 16:52

Thanks for replying.
How many programs that make use of context menus have you seen that give explicit hints that there's a context menu available? Serious question. I cannot think of a single one and would like to see how those programs do it.
They indicate it by distinctive text color, or distinctive text background color, or a box, or an underline (like a web page link), or -- least desired -- switching to a finger mouse cursor (like a web page mouse-over on a link). Providing some sort of distinction saves the user having to 'click around' all over the application and it saves the user (me) missing some important info.
There's a separate box for error messages; the don't show up in the regular output box. What does that error box show?
I assume you mean the '[X] # errors' thingy in the status panel at the bottom of the application... Right now it says '[X] 0 errors'. I'm pretty sure I clicked it when the failure occurred -- I always do that when an error's indicated. It was my inability either to find an explanation or to find the thing that provides an explanation that prompted me to ask.

Mosu

16th March 2020, 13:58

Thanks for replying.

They indicate it by distinctive text color, or distinctive text background color, or a box, or an underline (like a web page link),

All of those methods are only appropriate for cases where context-sensitive content is interspersed in non-conext-sensitive content, such as hyperlinks in otherwise regular text. This isn't the case with MKVToolNix as there all list boxes/tree views have context menus, similar to well-known desktop applications such as Word, Excel or even web browser (where everything actually has a context menu, not just links!). MKVToolNix is a program in the tradition of desktop applications, not a smartphone/tablet app where different rules apply.

I assume you mean the '[X] # errors' thingy in the status panel at the bottom of the application...

No, that isn't what I meant.

Click on the "job output" tool on the left. You'll see a tab with three big text boxes labeled "normal output" (the top one), "warnings" (bottom left) and "errors" (bottom right). Whenever an error occurs, the bottom right box should contain something.

markfilipak

16th March 2020, 20:10

Your application is wonderful, but its odd UI and the lack of a log limits usability.
All of those methods are only appropriate for cases where context-sensitive content is interspersed in non-conext-sensitive content, such as hyperlinks in otherwise regular text. This isn't the case with MKVToolNix as there all list boxes/tree views have context menus, similar to well-known desktop applications such as Word, Excel or even web browser (where everything actually has a context menu, not just links!). MKVToolNix is a program in the tradition of desktop applications, not a smartphone/tablet app where different rules apply.
I won't push the issue because you're obviously proud of the UI and it's not a big issue to me. But I will say that in 45 years of computer use, I've never seen an app as you describe (aside from MKVToolNix, apparently). The apps that make me happiest are the ones that are 'transparently' easy to use. Let me give you an example: Total Commander; even after 15 years of constant use, I never cease to marvel at its utility and simplicity.

I'm fairly new to MKVToolNix, but I'm pretty happy with it. Inclusion of integrated subtitle & chapter tools (involving some processing of IFO files for DVD, and MPLS files for BD (I think)) would be a very welcome addition.
No, that isn't what I meant.

Click on the "job output" tool on the left. You'll see a tab with three big text boxes labeled "normal output" (the top one), "warnings" (bottom left) and "errors" (bottom right). Whenever an error occurs, the bottom right box should contain something.
That's not a log. May I share some firsthand experience? I have no idea why, 11 days ago, an MKV to MKV remux failed at 78%. The failure occurred when I changed the audio stream #s by one place. It wasn't until a couple of days later that I discovered that the source actually had 10 PGCs and that PGCs 9 & 10 had audio that was 4400ms late -- I assume the PTS was in error for the VOB holding those PGCs. I wanted to see whether that was the reason why MKVToolNix failed, but by that time, it was too late to investigate it because MKVToolNix doesn't keep a log.

After I make a MKV using your tool, I use timings from IfoEdit analysis of the IFO to determine the PGCs and then chop the MKV into part-wise MKVs using HandBrake. I'm not really happy with that because HandBrake can't remux and I'm not keen on transcoding. If MKVToolNix allowed me to chop up a source based on the running times shown by IfoEdit, I'd be very happy to do the whole job with MKVToolNix.

Regarding the 4400ms audio error, in that case, I remuxed from VOB to MKV using MKVToolNix, then cut the video apart to make 10 MKVs with HandBrake (with acursed transcoding), and finally, for the 9th & 10th MKVs, moved the audio by 4400ms via MKVToolNix. I'd prefer to cut HandBrake out of the process.

markfilipak

17th March 2020, 03:35

@Mosu

I owe you an apology. Opening 'Job queue' (not 'Job output', as you said) and right-clicking the 'Description' of the failed remux and selecting 'View output' opens a panel (tab) that has an 'Errors' section. That section says, "Could not write to the destination file: 112 (There is not enough space on the disk.)". So there is a log of sorts ...certainly sufficient to figure out what went wrong (at least, in this case).

I complement you for some good documention.

May I ask a question? A chap on the ffmpeg-user list said he uses the MKVToolNix "generate timestamps" option. Is that an undocumented feature? Or was the chap in error?

Warm Regards,
Mark.

Mosu

17th March 2020, 19:28

@Mosu

I owe you an apology. Opening 'Job queue' (not 'Job output', as you said)…

Actually I did say that you can right-click on a job in the "job queue" tool & then view its output in the "job output" tool; see this post (https://forum.doom9.org/showthread.php?p=1903626#post1903626). But that's fine, often enough I don't read instructions carefully enough myself. So… apology accepted, of course.

May I ask a question? A chap on the ffmpeg-user list said he uses the MKVToolNix "generate timestamps" option. Is that an undocumented feature? Or was the chap in error?

I'm actually not quite sure which particular feature that person is talking about. Normally mkvmerge will re-use existing timestamps for the container a track is read from.

A couple of possibilities:

The "--default-duration" option is the most likely candidate in my opinion. You specify how long each frame or field (depending on how the video was encoded: interlaced or progressive) should be displayed, and mkvmerge will calculate the timestamps from it. mkvmerge will also set the track's "default duration" header field accordingly. With this option mkvmerge does indeed "generate timestamps" from your specification.
With the "--timestamps" option you can specify a file which contains the timestamps for all the frames of a track. mkvmerge will use those timestamps instead of the ones from the source container. There are several file formats for that particular "timestamps file". The option is meant to be used by other tools, not really by humans. With this option mkvmerge does not "generate timestamps" itself, it just uses timestamps someone or something else has generated for mkvmerge.
Maybe the person wasn't talking about timestamps after all but about chapters? mkvmerge can generate chapters based on timestamps, e.g. one chapte every X seconds.

markfilipak

18th March 2020, 05:05

Actually I did say that you can right-click on a job in the "job queue" tool & then view its output in the "job output" tool; see this post (https://forum.doom9.org/showthread.php?p=1903626#post1903626). But that's fine, often enough I don't read instructions carefully enough myself. So… apology accepted, of course.
May I suggest?
"Current Job Output" ...after a job runs
"Current Job Queue" ...before a job runs
"Job History" ...previous job outputs

I like your style, Mosu.

markfilipak

18th March 2020, 05:20

I'm actually not quite sure which particular feature that person is talking about. Normally mkvmerge will re-use existing timestamps for the container a track is read from.

A couple of possibilities:

The "--default-duration" option is the most likely candidate in my opinion. You specify how long each frame or field (depending on how the video was encoded: interlaced or progressive) should be displayed, and mkvmerge will calculate the timestamps from it. mkvmerge will also set the track's "default duration" header field accordingly. With this option mkvmerge does indeed "generate timestamps" from your specification.
With the "--timestamps" option you can specify a file which contains the timestamps for all the frames of a track. mkvmerge will use those timestamps instead of the ones from the source container. There are several file formats for that particular "timestamps file". The option is meant to be used by other tools, not really by humans. With this option mkvmerge does not "generate timestamps" itself, it just uses timestamps someone or something else has generated for mkvmerge.
Maybe the person wasn't talking about timestamps after all but about chapters? mkvmerge can generate chapters based on timestamps, e.g. one chapte every X seconds.
Thank you. Yes, I was familiar with all these options. Below is the mailing list thread for your information and perspective. As you see from my query (at the end of the thread), I thought that MKVToolNix might provide a clue regarding the 4400ms audio lead. The early-audio was present only for PGCs 9 & 10 and the only thing I can think of was that the PTS was wrong.

On 03/15/2020 09:41 AM, Mark Filipak wrote:
> On 03/15/2020 09:02 AM, Crazy Red Elephant via ffmpeg-user wrote:
>>> Are they actually disruptive, or could you just keep the original
>>> stream as is, knowing 1 out of 120 frames or something will be
>>> dropped when playing back?
>>
>> To me, yes. I know some other users also reported something about
>> playback issues numerous times but the stream provider doesn't seem to
>> care.
>>
>> I think I mentioned before that remuxing the video with MKVToolNix and
>> the "generate timestamps" option checked...
>
> Can you help me find the "generate timestamps" option? I can't find it.
> I'd like to see what it does with a VOB that has 8 PGCs that are okay,
> but the 9th & 10th PGCs have audio in advance of video by about 4400ms.
>
> Regards,
> Mark.

markfilipak

18th March 2020, 11:39

I discovered (the hard way) that MKVToolNix doesn't handle things well if the input and output are the same file name.
It would be nice if overwriting were possible.

Mosu

18th March 2020, 13:02

I discovered (the hard way) that MKVToolNix doesn't handle things well if the input and output are the same file name.
It would be nice if overwriting were possible.

Overwriting a file you're reading from is definitely not supported and never will be. mkvmerge should abort with an error message if this is attempted.

The are several reasons, e.g. there's a distinct possibility that data to be written is generated faster than data is read from the source file; in that case data that hasn't been read yet would be overwritten by the output data. Not a good idea.

Liisachan

18th March 2020, 20:37

Hi, I'd like to report a possible issue of the GUI.

The default destination file name, auto-generated by GUI, may cause errors or unexpected behaviors, at least on my Windows machine, in some situations related to a slash (possibly also a colon?) in the --title.

Example 1
You have "La Rose - Partie 2.264" and want to make "La Rose - Partie 2.mkv". You want to give it a title "La Rose / Partie 2". A command line like this will work fine:
mkvmerge -o "La Rose - Partie 2.mkv" "La Rose - Partie 2.264" "La Rose - Partie 2.ogg" --title "La Rose / Partie 2"
On GUI, when you select source files like above, "La Rose - Partie 2.mkv" is automatically set as the destination, which seems fine. You can type "La Rose / Partie 2" in the "File title" editbox, which seems fine too. But then, when you're happy with the default destination shown and click "Start multiplexing", you got an error like this:
Errors emitted by job 'Multiplexing to file " Partie 2.mkv" in directory "X:\path\La Rose "' started on 2020-03-18 18:26:13 ---
The file 'X:\path\La Rose \ Partie 2.mkv' could not be opened for writing: open file error.

The problem seems to have two aspects:
1) GUI design: Before and when you click Start, the "Destination file" editbox is saying "X:\path\La Rose - Partie 2.mkv". GUI suddenly changes its mind after you click Start, even though you do want to create "X:\path\La Rose - Partie 2.mkv". If the default destination changes, the editbox showing it should be updated accordingly before the user clicks "Start multiplexing" (e.g. when the "File title" editbox is updated and loses the focus).
2) Technically it's possible to create a file "X:\path\La Rose \ Partie 2.mkv" on Windows (though this is probably not what the user wants to do), but the tools fail to do that: it seems that they can't handle a folder name with a trailing space in this case.

Example 2
Suppose the --title should be "Take a 50/50 Chance!" GUI works fine with this title, but if the destination file name is auto-generated, then a sub-folder "Take a 50" is created, in which a file "50 Chance!.mkv" is written. Obviously this is not what the user wants. Like Example 1, the user doesn't know this will happen until after they click the "Start multiplexing" button.

Mosu

18th March 2020, 23:22

Nice catch, thanks. I'll have to replace all characters Windows doesn't allow in file names before copying the title to the file name.

markfilipak

19th March 2020, 06:56

Nice catch, thanks. I'll have to replace all characters Windows doesn't allow in file names before copying the title to the file name.
As an alternative, you could %-hex the offending characters. For example, "Take a 50/50 Chance!" would become "Take a 50%2F50 Chance!". Or you could simply replace any offending characters with hyphen of course.

Mosu

19th March 2020, 12:41

Replacing consecutive invalid characters with a single hyphen is what I was thinking about. I don't like % encoding for normal folks as they don't really understand what's happening and what that's supposed to mean.

tormento

19th March 2020, 13:23

For example (this is with bash on Linux, but other OS will surely have similar tools available)
Ask me anything about hardware but I am a noob about programming software.
Alternatively create a tag file with the tags you want to use.
Months ago I asked you to set language from filename convention and at the beginning you were reluctant. After some silent months, you coded it and it's really useful.

I think it would be useful for a lot of people to have the stream file date and time saved in the mkv container, so being resilient to cuts and other manipulations.

Mosu

19th March 2020, 16:20

Ask me anything about hardware but I am a noob about programming software.

I'm sure you weren't born with your knowledge about hardware. So how did you acquire it? You invested time to learn about it.

Same with automating/scripting stuff. If you want to be efficient, use automation; if you don't know how, invest the time & learn.

If you aren't willing to invest the time, then I can only understand that to mean that the topic isn't that important to you.

tormento

19th March 2020, 17:53

I'm sure you weren't born with your knowledge about hardware. So how did you acquire it? You invested time to learn about it.
I appreciate your wise reply. I can read you are proud of the lines you crossed.

In this spirit, I gave you a comment to improve your great product: my hint was about a feature many could find useful.

Liisachan

20th March 2020, 08:51

Nice catch, thanks. I'll have to replace all characters Windows doesn't allow in file names before copying the title to the file name.

The problem may not be just that some characters are illegal in the Windows file system. In my tests, GUI doesn't allow you to create foo.mkv from foo.264 at all, when the File title is non-empty and not "foo", even if you explicitly type "foo.mkv" in the File destination editbox. In other words, on GUI, when --title is specified, you can't select a Destination that happens to be identical to the initial default Destination.

Example:
- When you create a new job on GUI and add a source file "D:\CD Image.flac", the Destination file "D:\CD Image.mka" is auto-selected. Type something in the File title editbox; the Destination file remains the same. In this state, you'd think "CD Image.mka" will be created when "Start multiplexing" is clicked...
http://faireal.net/image/2020/cd_image_mka.png

- What will actually happen is different (already reported).

- Not only that, even if you manually type or select the Destination "D:\CD Image.mka" (suppose you do want to use that file name) after you type something in File title, GUI ignores it and still tries to create a Matroska file named after the File title. This behavior seems case-sensitive: GUI allows you to write e.g. "D:\CD Image.Mka" (capital M) from "D:\CD Image.flac" with an arbitrary --title.

Mosu

20th March 2020, 15:54

The GUI tries to determine whether the user has changed the destination file name manually and remembers the name it set automatically. If the current name is different than the automatically determined one, the GUI will stop auto-generating the file name. Sure, there might still be bugs in that process (because it's a shitty guesswork).

Nevertheless, the title issues should be fixed. The latest continuous builds (https://mkvtoolnix.download/windows/continuous/) contain the fixes.

Liisachan

21st March 2020, 01:58

Thanks! Tested 44.0.0.14 and it's working fine :)

As for the second problem, I've found an easy workaround for Windows. If you want to do e.g. mkvmerge -o "D:\path to\foo.mkv" "D:\path to\foo.264" --title bar using GUI and doesn't want to get bar.mkv, you can just change one character - lowercase the drive letter - in the Destination editbox: "d:\path to\foo.mkv" instead of "D:\path to\foo.mkv".

Of course, one can also use Multiplexer | Show command line, and just paste it to cmd.exe or make a batch file (which is most convenient for me).

One cosmetic observation: the command line generated by GUI for cmd.exe uses forward slashes to write a path to the folder where mkvmerge.exe exists. E.g. if you have mkvmerge.exe & mkvtoolnix-gui.exe in
D:\folder\mkvtoolnix
then, a command line generated by GUI looks like:
D:/folder/mkvtoolnix\mkvmerge.exe --ui-language en --output ...
This seems harmless, though, as cmd.exe now accepts a forward slash as if it were a backslash.

Mosu

21st March 2020, 19:26

Thanks! Tested 44.0.0.14 and it's working fine :)

Great! Thanks for the confirmation.

As for the second problem, I've found an easy workaround for Windows. If you want to do e.g. mkvmerge -o "D:\path to\foo.mkv" "D:\path to\foo.264" --title bar using GUI and doesn't want to get bar.mkv, you can just change one character - lowercase the drive letter - in the Destination editbox: "d:\path to\foo.mkv" instead of "D:\path to\foo.mkv".

Yeah, that's definitely a useful workaround.

One cosmetic observation: the command line generated by GUI for cmd.exe uses forward slashes to write a path to the folder where mkvmerge.exe exists.

Nice, you found one last place where I forgot to use the "show platform-dependent slashes" function. I'll fix that. Yes, it is completely cosmetic as Windows supports both backward and forward slashes as path separators (both in cmd.exe and all of its "open a file" functions).

tormento

28th March 2020, 09:34

I am encoding lot of material with local dialects and I can't find them in ISO 639-2. I saw they are present in ISO 639-3, could you please add it as optional in the next nightly or major release?

nevcairiel

28th March 2020, 09:45

I am encoding lot of material with local dialects and I can't find them in ISO 639-2. I saw they are present in ISO 639-3, could you please add it as optional in the next nightly or major release?

Strictly speaking, the Matroska specification says that codes should be ISO 639-2, if you use others you are likely to confuse reading applications

https://www.matroska.org/technical/specs/index.html#languages

tormento

28th March 2020, 09:56

Strictly speaking, the Matroska specification says that codes should be ISO 639-2, if you use others you are likely to confuse reading applications
Uh, I see.

Anyway, I don't remember where, I saw that current revision of specification is v3 and v4 is work in progress. Perhaps it refers to something else.

Mosu

28th March 2020, 17:37

The current Matroska specs contain new elements (https://github.com/cellar-wg/matroska-specification/blob/master/ebml_matroska.xml#L348) for specifying languages following the IETF BCP 47 specification (see here (https://tools.ietf.org/html/bcp47) for the full spec and here (https://en.wikipedia.org/wiki/IETF_language_tag) for Wikipedia's summary). That spec is pretty much complete and can express any type of language/territory relationship.

Unfortunately no tool supports those elements yet, and yes, that includes MKVToolNix — because handling those specs is rather complex. Just like real life.

So no, I will never add support for ISO 639-3 as I cannot simply use arbitrary values that aren't part of the spec — and the spec already includes a superior mechanism in IETF BCP 47 language elements. I plan on supporting them one day, but please don't ask me for an ETA.

Liisachan

28th March 2020, 18:56

Nice, you found one last place where I forgot to use the "show platform-dependent slashes" function. I'll fix that. Yes, it is completely cosmetic as Windows supports both backward and forward slashes as path separators (both in cmd.exe and all of its "open a file" functions).

Still, it's Windows after all; backslashes are safer. For example, if you have mkvmerge in a folder "cd" something like this could happen.
R:\>cd\mkvmerge.exe --version
mkvmerge v44.0.0 ('Domino') 32-bit

R:\>cd/mkvmerge.exe --version
The system cannot find the path specified.

Also, though irrelevant to the current version of mkvmerge, XP is less tolerant of foward slashes.
C:\>mkvtoolnix\mkvmerge.exe --version
mkvmerge v20.0.0 ('I Am The Sun') 32-bit

C:\>mkvtoolnix/mkvmerge.exe --version
'mkvtoolnix' is not recognized as an internal or external command,
operable program or batch file.

I am encoding lot of material with local dialects and I can't find them in ISO 639-2. I saw they are present in ISO 639-3, could you please add it as optional in the next nightly or major release?

If the language name is uncoded in ISO 639-2, perhaps something like this is the best one could do currently:
mkvmerge -o foo.mkv foo.264 --language 0:mis --track-name 0:"Venetian [vec]" foo.ogg

mis = “Uncoded languages” is not supported by GUI, not in the Available list, but mkvmerge does accept it. MPC shows whatever you type as track-name e.g. "Venetian".

It would be ideal if not only ISO 639-3 but the language subtag registry were supported so that e.g. simplified Chinese vs. traditional Chinese subs, or Mandarin vs. Cantonese dubs could be consistently tagged and auto-selected by players. Although the Matroska specs says one can (at least) use suffixes like -cn, -tw, -hk, they are not supported in reality; even if supported, they are not necessarily convenient (e.g. when talking about writing systems, not about countries).

Note: even if the language code is not in the GUI listbox by default, mkvmerge accepts any language codes in mkvmerge --list-languages > lang.txt.
*Example 1:
mkvmerge -o foo.mkv foo.264 --language 0:nap foo.ogg
MPC-HC & MPC-BE both show "Napolitan" for this track.

*Example2:
mkvmerge -o foo.mkv foo.264 --language 0:nap foo.ogg --language 0:mul --track-name 0:"Japanese karaoke with English translation" foo.ass
For this subtitle track, MPC-BE shows "Multilingual, Japanese karaoke with English translation".

tormento

28th March 2020, 19:29

The current Matroska specs contain new elements

Well, thanks! You were really wise. Any ETA will be welcome, when any.

Mosu

29th March 2020, 08:58

mis = “Uncoded languages” is not supported by GUI, not in the Available list, but mkvmerge does accept it.

This is incorrect. "Uncoded languages" is very much available in the GUI.

In fact both the GUI and mkvmerge use the same list of languages for displaying/checking their validity. All entries that mkvmerge accepts are available in the GUI (preferences → "GUI" → "Often used selections" → "Languages").

Liisachan

29th March 2020, 16:51

@Mosu: you're right. Sorry, was looking for "mis" under M, not U. That's why I couldn't find it.

stax76

29th March 2020, 19:38

@Mosu

Re-muxing a video that has a FLAC audio track and using split mode by parts don't seem to work, maybe you can take a look or maybe somebody else can verify it.

G: Matroska, 28.9 MiB, 2 min 49 s, 1 430 kb/s

V: HEVC, Main 10@L3.1@Main, 1280x720, 23.976 FPS, 2 088 kb/s

A: German, FLAC, 1 291 kb/s, 2ch, 44.1 kHz

General

CompleteName : C:\Users\frank\Desktop\aaa.mkv
Format/String : Matroska
Format_Version : Version 4
FileSize/String : 28.9 MiB
Duration/String : 2 min 49 s
OverallBitRate_Mode/String : Variable
OverallBitRate/String : 1 430 kb/s
Encoded_Date : UTC 2020-03-29 18:20:06
Encoded_Application/String : mkvmerge v44.0.0 ('Domino') 64-bit
Encoded_Library/String : libebml v1.3.10 + libmatroska v1.5.2

Video

ID/String : 1
Format/String : HEVC
Format/Info : High Efficiency Video Coding
Format_Profile : Main 10@L3.1@Main
CodecID : V_MPEGH/ISO/HEVC
Duration/String : 11 s 220 ms
BitRate/String : 2 088 kb/s
Width/String : 1 280 pixels
Height/String : 720 pixels
DisplayAspectRatio/String : 16:9
FrameRate_Mode/String : Constant
FrameRate/String : 23.976 (23976/1000) FPS
FrameRate_Original/String : 23.976 (24000/1001) FPS
ColorSpace : YUV
ChromaSubsampling/String : 4:2:0
BitDepth/String : 10 bits
Bits-(Pixel*Frame) : 0.095
StreamSize/String : 2.79 MiB (10%)
Encoded_Library/String : x265 3.3+10-g08d895bb6:[Windows][GCC 9.3.0][64 bit] 10bit
Encoded_Library_Settings : removed, was too long
Default/String : Yes
Forced/String : No
colour_range : Limited
colour_primaries : BT.709
transfer_characteristics : BT.709
matrix_coefficients : BT.709

Audio

ID/String : 2
Format/String : FLAC
Format/Info : Free Lossless Audio Codec
CodecID : A_FLAC
Duration/String : 2 min 49 s
BitRate_Mode/String : Variable
BitRate/String : 1 291 kb/s
Channel(s)/String : 2 channels
ChannelLayout : L R
SamplingRate/String : 44.1 kHz
FrameRate/String : 9.571 FPS (4608 SPF)
BitDepth/String : 24 bits
Compression_Mode/String : Lossless
StreamSize/String : 26.1 MiB (90%)
Encoded_Library/String : Lavf58.38.101
Language/String : German
Default/String : No
Forced/String : No

FLAC file was created with ffmpeg:

D:\Projekte\VB\staxrip\bin\Apps\Encoders\ffmpeg\ffmpeg.exe -i "D:\Samples\aaa_temp\aaa ID1.m4a" -af volume=1.7dB -y -hide_banner -ac 2 "D:\Samples\aaa_temp\aaa ID1.flac"

edit:

Happens also with FLAC created with eac3to.

sneaker_ger

29th March 2020, 20:43

I cannot reproduce. Does splitting work as expected if you disable the video track?

stax76

29th March 2020, 21:37

Thanks for testing, and if you demux the result with mkvextract, has the flac file the correct length in mpv?

I cannot reproduce. Does splitting work as expected if you disable the video track?

Yes

Mosu

29th March 2020, 21:44

Splitting & appending FLAC isn't supported by mkvmerge due to the very unfortunate way FLAC is stored in Matroska. And yes, I was the one who invented how it is stored. I obviously didn't grasp that what I was doing was problematic.

stax76

29th March 2020, 22:49

Thanks, next staxrip build has a verification and a suggestion which settings can be used instead.

sneaker_ger

30th March 2020, 07:22

Thanks for testing, and if you demux the result with mkvextract, has the flac file the correct length in mpv?
No. (Of course) Mosu is right and while it seemingly works if I play the FLAC file with mpv or MPC-HC the displayed duration is the one from before the splitting (even though the actual data from the cut-out parts is missing). :o He wrote some more info about it some time ago: https://gitlab.com/mbunkus/mkvtoolnix/-/issues/953

So re-encoding is the proper way to deal with this.

Chris

30th March 2020, 09:15

I guessed the problem is Qt after updating another software which uses Qt, it now shows similar problems, however the difference is that it doesn't appear to be hanging like MKVToolnix but seems to open menus slowly. Mind you it uses Qt 5.14, don't remember what MKVToolnix v43 used. Should I report that to Qt devs or they are already aware of the problem?

I can confirm this bug with Qt 5.14.1. The same problem have Qbittorrent 4.2.2 with identical qt version.

You can check which Qt version MKVToolNix was built with via the "Help" → "System information" menu entry. For MKVToolNix v43 on Windows this was Qt 5.14.1.

I wasn't able to find anything in their bug tracker with a quick search.

Note that this particular problem doesn't happen on all Windows installations (it doesn't on my Windows 10, my Windows Server 2016 and Server 2019 installations). Neither did anyone open a bug report for it.

If it only happens on Windows 7, you might have to prepare for the problem not to be fixed anymore.

My OS is Windows 10 1909 64bit. Thanks for this great software Mosu! :)

Qbittorrent post:
https://github.com/qbittorrent/qBittorrent/issues/12316

Mosu

30th March 2020, 17:36

I've just modified mkvmerge to abort with appropriate error messages if the user attempts to append or split FLAC audio tracks. Additionally I've converted the text from issue 953 sneaker_ger has linked to into an official entry in my FAQ.

stax76

31st March 2020, 07:57

Thanks Mosu

Stereodude

1st April 2020, 13:15

Is there a way to make a MVC (3D Blu-ray) mux with MKVToolNix directly from the mounted .ISO of the decrypted Blu-ray? I know for regular 2D blu-rays you can just drag in the .pls. Doing that on a 3D blu-ray gives you a 2D mux.

arrgh

1st April 2020, 21:32

... a way to make a MVC (3D Blu-ray) mux with MKVToolNix directly...

I second this request.:thanks:

Mosu

2nd April 2020, 08:36

Stereodude

2nd April 2020, 12:56

It might happen one day, but I've never really been motivated to work on that functionality.
So the MKV container can handle MVC video (from a 3D blu-ray), and MKVToolNix can correctly handle/process/manipulate/export a MKV that already contains a MVC video stream (from a 3D blu-ray), but it has no ability to mux it from the demuxed streams or a blu-ray source? What's different about having it already in a .mkv vs. demuxed elementary streams? :confused:

Mosu

2nd April 2020, 21:44

Data already present in Matroska can simply be kept as-is. Data read from other container formats has to be parsed and converted into structures suitable for storage in Matroska.

Ripman

3rd April 2020, 17:08

Hi all. Long time. Still very excellent sw. I pay attention, just haven't needed to ask anything - even with the option changes and such.

Thanks again for mkvtoolnix.

Mosu

4th April 2020, 15:11

Hello dear people,

I sincerely hope you're all healthy or at least on the way there. I'm fine, and having some more time on my hands I was able to get more done wrt. MKVToolNix. So this release is a bit bigger than the previous ones.

Nothing's changed for package managers.

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 45.0.0 "Heaven in Pennies" 2020-04-04
New features and enhancements

mkvmerge: mkvmerge has never supported appending & splitting FLAC audio tracks. mkvmerge will now emit error messages when the user attempts either instead of continuing and creating invalid FLAC tracks.
MKVToolNix GUI: added an option in the preferences to turn on eliding text on tab headers. If enabled, tab names will be shortened so that all tab headers fit into the window's width. Implements #2768 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2768).
MKVToolNix GUI: added an option in the preferences to disable all tooltips.
MKVToolNix GUI: Windows: debug output sent via Qt's to Windows' debugging facility will use a more verbose message format including the application name, making it easier to filter for in SysInternal's "Debug View" utility.
MKVToolNix GUI: multiplexer: if the file identification fails due to a JSON parser error, the output generated by "mkvmerge" will be output via Qt's debugging facility (viewable with SysInternal's "Debug View" utility on Windows; on other systems it's output on "STDERR") allowing insight into what's gone wrong.
MKVToolNix GUI: multiplexer: if an error occurs during file identification, the name of the processed file will be mentioned in the error message.
MKVToolNix GUI: multiplexer: if an error occurs during identification of multiple files, the GUI will ask the user whether to continue or abort the identification process. Implements #2778 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2778).
MKVToolNix GUI: job queue: added an option in the preferences for removing completed jobs when exiting the program depending on their status. Implements #2769 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2769).

Bug fixes

mkvmerge: H.265/HEVC packetizer: fixed changing the NALU size length, it was using the wrong offset into the "hevcC" structure.
mkvmerge: MP4 reader: fixed calculating the duration of video tracks that only contain a single frame. Fixes #2747 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2747).
mkvmerge: MP4 reader: if there's no frame offset table ("ctts" atom) present for H.265/HEVC video tracks, mkvmerge will determine the timestamp order itself instead of relying on the timestamps in the MP4 being in the presentation order required by Matroska. Fixes #2777 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2777).
mkvpropedit: Windows: mkvpropedit wasn't caching when reading the file to modify, slowing down operations such as adding track statistics tags considerably. Fixes #2761 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2761).
MKVToolNix GUI: multiplexer: when using the title as part of the destination file name (both automatically as well as using the "copy title to destination file name" function) all characters that aren't valid in a file name are replaced by hyphens.
MKVToolNix GUI: multiplexer: the "copy title to destination file name" function was broken when the "make file name unique" option in the preferences was disabled. In that case the file base name was removed regardless of what the title was set to at the time.
MKVToolNix GUI: multiplexer: when using the "show command line" menu option on Windows the path to the "mkvmerge" executable was shown with forward slashes instead of backslashes. This is a purely cosmetic fix as Windows supports both forward and backward slashes.
MKVToolNix GUI: multiplexer: when adding Blu-ray playlists the GUI used to only look for the English version of the disc library information (title & cover images). Now the GUI will present all disc library entries in the "select playlist to add" dialog & let the user chose which one to use (if any). Fixes #2765 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2765).
MKVToolNix GUI: multiplexer, info tool: fixed the "warn before overwriting" check wrt. jobs creating the same file. Fixes #2758 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2758).

So try to have some fun, especially in these trying times.

filler56789

4th April 2020, 21:36

^ Thanks :thanks:

ryrynz

4th April 2020, 21:48

Solid release. Good one.

6th April 2020, 11:12

Is it possible to log actual start and finish timecodes for all parts from "--split parts:" output?

as a temporarily solution I am using "--split timecodes:" instead of "--split parts:", this way I can calculate times manually

Selur

11th April 2020, 07:26

Small question:
I noticed that mkv has rotaion options:

--projection-type TID:method
Sets the video projection method used. Valid values are 0 (rectangular projection), 1 (equirectangular projection), 2 (cubemap projection) and 3 (mesh projection).
--projection-private TID:data
Sets private data that only applies to a specific projection. Data must be given as hex numbers with or without the "0x" prefix, with or without spaces.
--projection-pose-yaw TID:float
Specifies a yaw rotation to the projection.
--projection-pose-pitch TID:float
Specifies a pitch rotation to the projection.
--projection-pose-roll TID:float
Specifies a roll rotation to the projection.

see: https://mkvtoolnix.download/doc/mkvmerge.html

-> Do VLC, MPC-HC and other players support these? (they would be useful when reencoding mp4 files which were recorded by a mobile with a mp4 rotation flag)

Cu Selur

Ps.: Okay, did a small test using:
mkvmerge --ui-language en -o "E:\Output\source with rotation flag.mkv" --global-tags "E:\Temp\source with rotation flag_08_56_54_1010__06.xml" -d 0 --default-track 0:yes --projection-type 0:0 --projection-pose-roll 0:90 --track-name 0:"VideoHandle" --language 0:en --default-duration 0:2984100/100000fps --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles --timecodes 0:"E:\Temp\timecodeV2_08_56_54_1010.tc" "E:\Temp\08_56_54_1010_03.264" and the output at least with MPC-HC wasn't rotated.

leon

14th April 2020, 05:51

@Mosu

https://bugreports.qt.io/browse/QTBUG-82701

What's the current version of Qt used in the latest version of MKVToolNix?

Mosu

14th April 2020, 18:28

You can check the Qt version your particular copy was built against via "Help" → "System information".

Mosu

14th April 2020, 18:29

Is it possible to log actual start and finish timecodes for all parts from "--split parts:" output?

There's no functionality that outputs those timestamps.

leon

14th April 2020, 20:14

You can check the Qt version your particular copy was built against via "Help" → "System information".

I know that, but I'm not using the "latest version" because of the bug.

Mosu

14th April 2020, 22:41

v45 is built with Qt 5.14.2, which is the latest release available.

ryrynz

14th April 2020, 22:45

I know that, but I'm not using the "latest version" because of the bug.If you look at the link you posted you can see the issue was closed with the release of 5.14.2. If you're going to reference something at least understand it...

leon

15th April 2020, 08:10

@Mosu
OK, thanks. So you'll update to the next version of Qt as soon as it's available, right?

If you look at the link you posted you can see the issue was closed with the release of 5.14.2.

I don't know how that's relevant to the version of Qt used in MKVToolNix, but whatever.

ryrynz

15th April 2020, 08:12

@Mosu

OK, thanks. So you'll update to the next version of Qt as soon as it's available, right?

Mosu just said it uses the latest.. There nothing to fix...
It's relevant if you paid attention to a) what I said
b) the link you provided and lastly c) what Mosu said!

leon

15th April 2020, 08:22

You certainly don't know what you're talking about. I suggest you read the previous posts (2 pages before this). I perfectly understand what Mosu says, thank you.

Mosu

15th April 2020, 19:06

Actually, the bug says that it was too late for 5.14.2 and that it was fixed in 5.14.3. 5.14.3 hasn't been released yet.

I usually update my mingw cross-compilation environment once a month, normally within the first weekend of the month. You can guesstimate from that information which MKVToolNix release will use 5.14.3 once that'll have been released.

mkver

16th April 2020, 00:45

Mosu

16th April 2020, 17:54

No, nothing new on that front. I haven't thought about the topic at all the past couple of months, to be honest. It doesn't have a high priority for me.

AYColumbia

19th April 2020, 19:59

stax76

19th April 2020, 20:06

Post command line, output and media info (https://github.com/stax76/MediaInfo.NET).

https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.exit_codes

Mosu

20th April 2020, 15:10

Hi Mosu,
I noticed that mkvmerge.exe does NOT exit with an error code when it fails that would set the errorlevel used in batch files. Would you please consider returning an exit code other than 0 on any failure please just so I know the process failed? For now, I just work around it by checking if my output file exists. Thank you.

mkvmerge should always exit with 2 in case of errors and 1 in case of warnings. As stax76 said, please post the command line used as well as the full output generated by mkvmerge.

Perenista

21st April 2020, 21:19

Is there a way to force MKVToolnix to stop saving a modified file this way?

Let's say original MKV is MOSU.mkv

I change a few things and save a new copy. MKVToolnix says it will save as MOSU (1).mkv

Actually I don't want that. I want it to replace MOSU.mkv and the new file to have that same original name.

If not possible during saving, deleting the original MOSU.mkv file after the completion and saving as I said above.

*****
Also, is there a way to force the file (using MKVToolnix) to select a certain subtitle track if a certain audio track is also selected? Important: not the other way around, so selecting the subtitle first would not change to the desired audio track. Or this is always manually chosen by the user, during playback?

Mosu

22nd April 2020, 08:53

Is there a way to force MKVToolnix to stop saving a modified file this way?

In the preferences disable the checkbox that says to make the destination file name unique.

Also, is there a way to force the file (using MKVToolnix) to select a certain subtitle track if a certain audio track is also selected?

No.

22nd April 2020, 17:52

@Mosu
Would you please help me understand how to decode CodecPrivate data field (codec_private_data) reported by mkvmerge (I'm comparing it to the headers traced by ffmpeg and there seems to be some extra chunks of information that ffmpeg headers don't have)? A more detailed description of the issue is in this post (https://forum.doom9.org/showthread.php?t=181316)
Thank you!

Mosu

23rd April 2020, 18:48

I cannot help you with your original goal (encoding something so that the codec private data matches). The content of CodecPrivate for H.265/HEVC uses the same structure is the same as the hvcC atom in corresponding MP4 files. Its structure is described in the usual ISO/IEC documents.

Stereodude

25th April 2020, 20:39

Using the "Remove dialog normalization gain" option on an E-AC-3 audio track that contains Atmos during muxing results in an audio stream that is no longer decoded as Atmos, just DD+.

MediaInfo reports basically the same information for the audio stream before and after, but my Denon doesn't see the after version as Atmos. The volume offset is gone though.

before:Audio
ID : 2
Format : E-AC-3 JOC
Format/Info : Enhanced AC-3 with Joint Object Coding
Commercial name : Dolby Digital Plus with Dolby Atmos
Codec ID : A_EAC3
Duration : 1 h 57 min
Bit rate mode : Constant
Bit rate : 768 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 645 MiB (14%)
Language : English
Service kind : Complete Main
Default : Yes
Forced : No
Complexity index : 16
Number of dynamic objects : 15
Bed channel count : 1 channel
Bed channel configuration : LFE
Duration_Source : General_Duration
After:ID : 2
Format : E-AC-3 JOC
Format/Info : Enhanced AC-3 with Joint Object Coding
Commercial name : Dolby Digital Plus with Dolby Atmos
Codec ID : A_EAC3
Duration : 1 h 57 min
Bit rate mode : Constant
Bit rate : 768 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 645 MiB (14%)
Language : English
Service kind : Complete Main
Default : Yes
Forced : No
Complexity index : 16
Number of dynamic objects : 15
Bed channel count : 1 channel
Bed channel configuration : LFE

hubblec4

26th April 2020, 12:22

Hi Sterodude

Could you open an issue on GitLab (https://gitlab.com/mbunkus/mkvtoolnix/issues?scope=all&utf8=%E2%9C%93&state=opened) with a sample file please?
If you have no GitLab acc I can do it for you if you provide a sample of your Dolby Atmos file.

Mosu

26th April 2020, 12:43

You can open an issue on GitLab, that would probably be best, but this isn't something I'm going to work on any time soon if ever. Just FYI.

Perenista

26th April 2020, 15:58

What is the difference between "Determining automatically" and YES for DEFAULT TRACK FLAG?

Example: let's say I have a movie with 2 audio tracks: english and portuguese.

I always want this file to use as default track the english. Note this is not FORCED, it is my preferred track, to be played whenever I open this file (except, of course, if we instruct Media Player Classic to ignore this and select other language instead).

>>>>>>>>>>>>>>>>>
OK, I can configure YES for english and NO for portuguese, while editing the MKV.

This is what I mean:

https://i.imgur.com/0SXIL69.png https://i.imgur.com/Fw67Qny.png https://i.imgur.com/IEdSxhc.png

But if I come back later and want to edit some other stuff in this MKV, I always find it like this:

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

Didn't I say NO to that setting after editing? Why MKVToolnix keeps changing to "determine automatically" whenever it opens again? (and this happens with subtitles, too)

sneaker_ger

26th April 2020, 16:45

https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Default-and-forced-flags-and-default-yes-no-in-the-GUI

markfilipak

29th April 2020, 14:00

Hey Mosu, I hope you're well.

I have a problem. I have a soft telecined movie. There are 6 VOBs. I need to concatenate them. I have tried these 3 command lines:

#1: "C:\Program Files\MKVToolNix\mkvmerge.exe" -o "OUT.VOB" H:\VIDEO_TS\VTS_01_1.VOB
#2: "C:\Program Files\MKVToolNix\mkvmerge.exe" --default-duration 0:24000/1001fps -o "OUT.VOB" H:\VIDEO_TS\VTS_01_1.VOB
#3: "C:\Program Files\MKVToolNix\mkvmerge.exe" --default-duration 0:30000/1001fps -o "OUT.VOB" H:\VIDEO_TS\VTS_01_1.VOB

In every case, each OUT.VOB appears combed when played back -- actually, they look like they were combed but then slightly filtered [Note].

[Note} mkvmerge is pretty quick, too quick to be transcoding (though OUT.VOB looks transcoded).

It's important that OUT.VOB be simply concatenated because I'm following the concatenation with ffmpeg, 24-to-60fps trancoding via 55-telecine and to do that I need clean 24 FPS.

Is there a mkvmerge command line that will solely concatenate the source VOBs without changing them?

Regards,
Mark Filipak.

More Info:
I use MPV to check the video at each step. MPV, Shift-I displays
FPS: xx.xxx (specified) xx.xxx (estimated)
where estimated is calculated on-the-fly from the PTSs of the preceeding 10 frames.

Source VOB: FPS: 29.970 (specified) 23.976 (estimated)

OUT.VOB #1: FPS: 59.940 (specified) 23.976 (estimated)
OUT.VOB #2: FPS: 23.976 (specified) 23.976 (estimated)
OUT.VOB #3: FPS: 29.970 (specified) 29.970 (estimated)

ffmpeg input VOB needs to be: FPS: 29.970 (specified) 23.976 (estimated)

videoh

29th April 2020, 14:08

Use copy /b in a cmd window. You don't need mkvmerge for this.

copy /b a.vob + b.vob + c.vob combined.vob

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/copy

markfilipak

29th April 2020, 14:27

Use copy /b in a cmd window. You don't need mkvmerge for this.

copy /b a.vob + b.vob + c.vob combined.vob

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/copy

The result has PTS errors and the ffmpeg transcode malfunctions.

Mosu

29th April 2020, 19:27

mkvmerge can only create Matroska files, not MPEG program streams (that's what VOBs are).

videoh

29th April 2020, 20:41

The result has PTS errors and the ffmpeg transcode malfunctions. Then you didn't do it right. :p

Maybe try knitting? Or miniature golf?

markfilipak

29th April 2020, 21:10

mkvmerge can only create Matroska files, not MPEG program streams (that's what VOBs are).

An MKV is fine. Actually, MKV is preferred. I'm sorry if I implied otherwise.

Do you have any guidance regarding the combing? I don't understand how combing can happen if mkvmerge is solely performing remuxing, but then, I don't understand a lot of things. ;-)

PS: I checked things and ...you know what? I did name the files '.VOB'. But you know what? I could have named them '.EXE'. It doesn't matter to MKV. It plays anything that it finds contains a video stream.

markfilipak

29th April 2020, 21:28

Then you didn't do it right. :p
You don't understand. ffmpeg has a bug that mishandles gaps in PTSs and/or DTSs that aren't monotonic. 'copy /b' doesn't fix that, of course. mkvmerge (and HandBrake, too) do fix the problem somehow. Remuxing seems to work magic sometimes. Unfortunately, mkvmerge appears to create a different problem: Combing. The combing is what I seek to avoid. I would use HandBrake, but HandBrake insists on transcoding and I don't want transcoding.

I hope it's clear now.

Maybe try knitting? Or miniature golf?
What? Do you want me to play with myself?

Mosu

29th April 2020, 22:17

Do you have any guidance regarding the combing? I don't understand how combing can happen if mkvmerge is solely performing remuxing, but then, I don't understand a lot of things. ;-)

I don't support MPEG program stream/MPEG elementary stream handling in mkvmerge anymore. That code was contributed by someone else who hasn't been around for more than a decade now, and I have no interest in fixing issues in that code.

As I've never dealt with telecined content I cannot give you any advice whatsoever.

PS: I checked things and ...you know what? I did name the files '.VOB'. But you know what? I could have named them '.EXE'. It doesn't matter to MKV. It plays anything that it finds contains a video stream.

mkvmerge generally determines the file type by the content. There are certain cases where it uses the file's extensions in situations where content-based detection is ambiguous (e.g. not detecting an MPEG transport stream with H.264 inside as an H.264 elementary stream if the file's extension is ".ts" or ".m2ts").

videoh

29th April 2020, 22:41

I hope it's clear now. Nah. You asked how to just concatenate VOB files and I told you. You wrote:

It's important that OUT.VOB be simply concatenated

I never claimed it would fix any ffmpeg problems. Best bet for you is to post a sample source stream(s) and tell us how to duplicate your issue. Don't make all kinds of assumptions and then start blaming people if they don't necessarily accept them.

What? Do you want me to play with myself? Divine energy will flow through you, if you allow it.

markfilipak

30th April 2020, 07:57

I never claimed it would fix any ffmpeg problems.
There is no blame to assign, my friend. There is no blame at all.

What I have is VOBs that provoke time stamp mishandling by ffmpeg. I have found that remuxing via mkvmerge fixes those problems and that ffmpeg then transcodes the remuxed videos correctly. So, of course, I want to use mkvmerge as a preprocessor in scripts.

The fix should logically be limited to fixing the time stamps in elemental streams, but mkvmerge's output appears to be more than remuxed, it appears to be transcoded because the frames are no longer pristine, they're combed. I don't know what to make of that and I don't have the tools that would reveal what's actually happening in raw frames.

So, I come here to find out becasue you folks are informed. If I'm making assumptions, I appologize. It's because I'm somewhat ignorant. If you have any suggestions, I'd be very grateful.

Stay safe, stay healthy,
Mark.

videoh

30th April 2020, 09:06

If you have any suggestions, I'd be very grateful. As I said, best bet for you is to post a sample source stream(s) and tell us exactly how to duplicate your issue. We don't have magic wands or clairvoyance.

mkvmerge is not transcoding.

sneaker_ger

30th April 2020, 09:13

As you say mkvmerge is not re-encoding. If it was combed after using mkvmerge then if was also combed before. Probably your player activated de-interlacing/IVTC for the VOB file without you knowing thus appearing as if it was progressive. After remuxing to mkv your player isn't detecting this anymore.

videoh

30th April 2020, 11:06

Quite right, sneaker_ger. A small sample cut from the VOB would allow us to verify that. OP should cut a section that comes out combed in the MKV. Set range in DGIndex and then Save Project and Demux Video. Post a link to the resulting M2V file.

AYColumbia

30th April 2020, 15:12

Post command line, output and media info (https://github.com/stax76/MediaInfo.NET).

https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.exit_codes

mkvmerge should always exit with 2 in case of errors and 1 in case of warnings. As stax76 said, please post the command line used as well as the full output generated by mkvmerge.
Thanks I'll provide that info the next time it happens. I had not saved the prior info and I should have provided it. My bad.

Mosu

1st May 2020, 10:20

Hey everyone!

It's May. It's time. Time for another MKVToolNix release.

In v45 I accidentally introduced two bugs that users stumbled across almost immediately, and I nearly released a bug fix release only a few days after the v45 release, but ultimately decided against it. Therefore I suggest you upgrade to v46 now, especially if you're dealing with H.265/HEVC video in MP4 files.

Nothing's changed for package managers.

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 46.0.0 "No Deeper Escape" 2020-05-01
New features and enhancements

mkvmerge: when splitting, the placeholder "%c" can be used in the destination file name. It'll be replaced by the name of the first chapter in the file. Implements #2791 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2791).
mkvmerge: when reading MPLS playlists mkvmerge will include a tag named "SOURCE_ID" in the track's statistics tags that conveys the fact that the source was a Blu-ray and what the track's ID was in the source container. When reading Matroska file existing "SOURCE_ID" tags will be kept. The format used is the same format MakeMKV uses. Implements #2774 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2774).
mkvmerge: for audio-only files mkvmerge will now write a cue entry every 500ms instead of every 2s.
MKVToolNix GUI: job actions: split up the option "execute when the job finishes successfully or with warnings" into two separate options: "…when finishes successfully" and "…when exits with warnings". Implements #2798 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2798).

Bug fixes

mkvmerge: Matroska reader: when regenerating UIDs for chapters mkvmerge will now fix referencing tag chapter UID targets to have the same values. Fixes #2804 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2804).
mkvmerge: MP4 reader: fixed a crash that could potentially happen while trying to identify H.265/HEVC tracks.
mkvmerge: MP4 reader: when reading H.265/HEVC tracks without a frame offset table ("ctts" atom) present, mkvmerge did not parse the "hevcC" structure correctly in certain cases, causing no video frames to be output at all or the output not being playable. This fixes #2782 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2782), a bug introduced in v45.
mkvmerge: MPLS handling/MPEG TS reader: timestamp restrictions as given in an MPLS file were only honored for the first play item, not for subsequent play items. For those play items the whole referenced file was always copied. Part of the fix of #2789 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2789).
mkvmerge: MPLS handling/MPEG TS reader: under certain circumstances mkvmerge copied one frame too many before switching to the next play item. Part of the fix of #2789 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2789).
mkvmerge: for audio-only files cues will only be created for I frames (important for e.g. TrueHD where decoding can only start on a sync frame). Fixes #2790 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2790).
MKVToolNix GUI: fixed a crash that happened when closing the preferences after having closed at least one multiplexer tab. Fixes #2785 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2785).
MKVToolNix GUI: macOS: changed the default of the "elide tab header labels" feature introduced in v45 from "no" to "yes" to mirror how versions before v45 behaved on macOS.

Have fun!

MrVideo

1st May 2020, 23:01

Tbut mkvmerge's output appears to be more than remuxed, it appears to be transcoded because the frames are no longer pristine, they're combed.
I'm jumping in here a little late, so excuse me this has been discussed with you in previous posts. But, do you understand what a combed video frame is?

As noted, MKVmerge does not do any recoding/transcoding, it only copies source material.

A combed video frame is a result of two different fields in a 480i, 576i or 1080i video file. This can be because the video was shot with a 480i/576i/1080i video camera, or a 23.976 progressive video source was telecined to 29.97, where two video frames, out of five, can have combed video frames.

For a true video source, you have to live with the combing, or recode using a deinterlacing function, which combines the two fields into a single progressive frame. That ultimately results in a loss of time space. By this I mean if the two fields have rapid motion, that motion appears to move at a pace of 59.94 images a second. But, when you deinterlace, the time is now has a motion of 29.97 images a second, or time/space is now 1/2 of what it originally was. I personally prefer to keep the full motion intact. The process of deinterlacing can also reduce the vertical resolution.

If the 29.97 interlaced video is a result of the telecine process to convert 23.976 source material to 29.97, the IVTC (inverse telecine) process can restore the interlaced 29.97 video back to 23.976 progressive video, removing the combing effect.

If you already knew all this... then NEVERMIND!

markfilipak

3rd May 2020, 02:00

I'm jumping in here a little late, so excuse me this has been discussed with you in previous posts. But, do you understand what a combed video frame is?!

"progressive video source [that] was telecined"
A combed frame from telecine mixes 2 half-pictures that are separated in time by 1/24 second, and as you cited, a 23-telecine has 2 of them in every 5 frames (40%), and they are back-to-back: the 3rd & 4th frames.

"shot with a 480i/576i/1080i video camera"
Each combed frame in that case results in fields separated in time by 1/60 second -- less than half the combing -- but every frame is combed (100%).

Both are awful.

As for my project, the only thing I can figure is that I must have somhow grabbed a hard telecined video to use for testing. That seems a year ago, though it was just yesterday or the day before, and I've since used many test videos and discarded some. I've progressed past that. I'm still using mkvmerge and in fact am using it for 2 of the 4 processing steps, but I'm using it in a slightly different way. In other words, I got no problems with mkvmerge. Not any more.

MrVideo

3rd May 2020, 12:26

""shot with a 480i/576i/1080i video camera"
Each combed frame in that case results in fields separated in time by 1/60 second -- less than half the combing -- but every frame is combed (100%).
Yes and no. If the two fields have an imperceptible time difference, it will appear as though the frame was a progressive frame. There will be no combing effect visible.

Just think, before digital TV came along, no one really complained about interlaced video, no matter the source. We've become spoiled.

darksen

4th May 2020, 04:57

Is there any way to make MKVToolNix use a separate path to create the files and then move the finished files to the destination? I mean, a temp working folder?
This to prevent fragmentation as much as possible as it is impossible for MKVToolNix to pre-allocate the space beforehand.

Also, what does --engage-cow do?

MKVToolNix GUI: job actions: split up the option "execute when the job finishes successfully or with warnings" into two separate options: "…when finishes successfully" and "…when exits with warnings". Implements #2798.

Thank you! I was going to request this.

Mosu

4th May 2020, 08:18

Is there any way to make MKVToolNix use a separate path to create the files and then move the finished files to the destination? I mean, a temp working folder?

Nope. No plans for it either.

Also, what does --engage-cow do?

It's "--engage cow", and just give it a try and you'll see.

Selur

4th May 2020, 18:05

Seeing that with exhale (https://gitlab.com/ecodis/exhale/) there's a xHE-AAC encoder out there I was wondering if there are plans to support xHE-AAC in mkvtoolnix?

Mosu

5th May 2020, 09:59

There are no plans so far. I don't know what work (if any) would be required.

Nejiro

5th May 2020, 13:17

Greetings to all, I am new to this forum and I apologize if I use a translator, I use MKVToolNix on Ubuntu 20.04 lts, I have some 1: 1 bluray in which I removed the various languages that I do not need by transforming the m2ts file into mkv, all it works well but I noticed with mediainfo that the bitrate of the video on the mkv file is lower than the m2ts, so I lose quality on the mkv file compared to the m2ts? Or does mkv remove things that are not needed without me losing quality?
Thanks

videoh

5th May 2020, 13:38

Overhead for an M2TS is higher than for MKV. The actual video is not affected in any way.

Nejiro

5th May 2020, 14:17

Perfect, thank you very much for your reply, so with an mkv file you won't lose anything, that's what I wanted to hear ......

Nejiro

5th May 2020, 15:32

videoh

5th May 2020, 15:46

One possibility:

https://forum.videohelp.com/threads/384585-Matroska-text-file-attachment

MKV gurus here may know more about it.

And, oh, welcome to the forum!

hubblec4

5th May 2020, 17:36

Excuse me another question, when I create mkv files with Handbrake I have the possibility to insert in appropriate spaces plot of the film, director, year etc ... with MKVToolNix is it possible to do it? I can't find where to insert this data .....
Thanks

Such things could be preserved with Matroska Tags.
MKVToolNix has no Tags editor you could try chapterEditor for this task.

Nejiro

5th May 2020, 18:54

I imagined there wasn't a tag editor like on Handbrake, creating an html file I wouldn't know how ...
Thanks

Nejiro

6th May 2020, 11:38

Excuse me another question, I have an mkv file in which an audio track starts about 5 seconds behind the video, how can I synchronize them? I select the audio track and in the audio delay field I enter 5,000? I don't know how it should be inserted exactly the value 5000 or 5.000? If instead it is the opposite and that is that the audio is in advance I have to put the minus sign in front, that is -5000?
Thanks

Mosu

6th May 2020, 13:05

The "delay/sync" functionality simply adds the number of milliseconds given in the box to all timestamps. So if audio is 5s behind your video you have to subtract 5s, which means: add "-5000" ms. So you enter "-5000".

Liisachan

6th May 2020, 21:11

insert in appropriate spaces plot of the film, director, year etc ... with MKVToolNix is it possible to do it? Like others say, it's easy once you know how to tag MKV files. At first, you may feel XML files are difficult, but once you create your "template", you can just reuse the same file again and again, with just editing the tag values.

There is, however, one subtle, tricky aspect...
MPC and MPC-HC parse DESCRIPTION and show it as Description in Information (Ctrl+3).
MPC-BE parses the last COMMENT and shows it as Description.
Because of this, if you'd like to get a consistent result (for both HC and BE), set the last COMMENT identical to the global DESCRIPTION tag (as a workaround). If you only use a global tag file, this simply means COMMENT and DESCRIPTION have the same value in it. If you use par-track tag file(s) too, the COMMENT of the last tag file matters: e.g. if you have not only global.xml but also video.xml, audio.xml, and sub.xml and the track order is video audio sub, then COMMENT in sub.xml matters.

If you don't mind such minor detail (HC/BE compatibility) you can safely ignore this :) It's just a (weird) workaround for specific players, not at all required in the matroska specs.

markfilipak

17th May 2020, 21:42

I'm not sure what MKV supports and I doubt that what I want can be done, but perhaps someone less ignorant than me will pitch in.

What I want, and what a BD player does, is pair audio & subtitles in particular ways.

A particular BD movie has English dialog & French dubs. It has infrequent German dialog during scenes set in Berlin. If English dialog is selected (default), then German-to-English translation subs are automatic. If French dubs, then German-to-French translation subs are automatic.

Streams:
1 English audio
2 French dub
3 English subs
4 French subs
5 German-to-English translation subs for scenes in Berlin
6 German-to-French translation subs for scenes in Berlin

Playback of BD disc (e.g., PowerDVD):
1 (+5 automatic) -- part-time translations only
2 (+6 automatic) -- part-time translations only
1 (+5 automatic) + 3 -- full-time English subs & translations
2 (+6 automatic) + 4 -- full-time French subs & translations

Playback of MKV remux (e.g., MPV):
1 -- no subs, no translations
2 -- no subs, no translations
1 + 3 -- English subs but no translations
2 + 4 -- French subs but no translations
1 + 5 -- translations but no English subs
2 + 6 -- translations but no French subs

Is there any way to pair 1 & 5 and 2 & 6 (as though forced subs) so that an MKV remux duplicates the behavior of a BD disc player?
1 (+5 automatic) + 3 -- full-time English subs & translations
2 (+6 automatic) + 4 -- full-time French subs & translations

Thanks,
Mark.

sneaker_ger

18th May 2020, 20:21

The MKV specs don't offer the possibility to bind any specific audio track to a specific subtitle track (or vice versa). I vaguely remember something about a possibility using editions though I think players didn't support it anyways so ...

(Back in the day "Haali's Splitter" offered support for non-spec "TRACKSETEX" to offer such pairings but I don't know if there is any player support outside of the deprecated Haali Splitter.)

odino

18th May 2020, 20:22

Is there a way to delete a language from the ISO list? Church Slavic bla bla bla is so long the right-hand panel in the multiplexer is stretched unnecessarily. I will never ever use it among a few others I could trim.

stax76

18th May 2020, 21:14

Dotnet just calls this Church Slavic. Maybe somebody finds the staxrip approach interesting:

https://postimg.cc/XXzpvxdX

markfilipak

18th May 2020, 21:28

The MKV specs don't offer the possibility to bind any specific audio track to a specific subtitle track (or vice versa).

Thanks for the info. -- Mark.

PS: I found the MKV specification, but github is a show stopper. I searched for MKV editors, but turned up only video editors.

Is there an IFOEdit-style editor for MKV that will at least allow me to see into an MKV and see/copy metadata?

odino

19th May 2020, 06:07

Dotnet just calls this Church Slavic. Maybe somebody finds the staxrip approach interesting:

https://postimg.cc/XXzpvxdX

Yeah, so I'm sure it can be configured somehow.

Mosu

19th May 2020, 08:31

foxyshadis

19th May 2020, 09:26

Thanks for the info. -- Mark.

PS: I found the MKV specification, but github is a show stopper. I searched for MKV editors, but turned up only video editors.

Is there an IFOEdit-style editor for MKV that will at least allow me to see into an MKV and see/copy metadata?

The GUI's info tool and header editor give you access to pretty much all of that.

odino

19th May 2020, 11:02

Preferences → GUI → Often used selections

That only works if I select the tickbox to "only include often used in list" but that defeats the point of an often used list.

Mosu

19th May 2020, 12:41

That only works if I select the tickbox to "only include often used in list" but that defeats the point of an often used list.

Not really, it just allows you to use the selections in two different modes, depending on what you prefer: either the full list with certain entries located at the top or only those entries you tend to use over and over. Most people I talk to prefer the latter.

Don't get hung up on the name.

odino

19th May 2020, 18:35

Alright thanks, I'll use it that way.

kuchikirukia

20th May 2020, 01:57

I just tried to do a weird workflow which had a bugged result:

I have a Blu-ray with 3 episodes in 3 M2TS files. I wanted chapters in them but the Blu-ray playlist for them combines the episodes together, so I threw the playlist into mkvtoolnix and then split it at the episode chapter marks to get 3 MKVs with BD video and PCM audio with chapters.
Here's the oddity: When trying to mux in AAC audio and subtitle tracks from a previous encode, it ends up delaying the video and original audio of the split mkvs. Ep 1 will mux fine, but on eps 2 and 3 the black lead-in will play for ~1 second longer than simply the BD video + PCM alone, the Info Tool will show an additional 1 second of playtime, and the AAC and subs will be out of sync with the BD video and PCM, even though if you throw both audio tracks in Audacity it shows them to be in perfect sync.

If you mux the AAC audio and subs into the original M2TS' there's no issue.

E: it seems to be setting an audio delay relative to video of -1.3 seconds. That's weird because doesn't mkvtoolnix usually cut AAC with a negative delay?

Perenista

21st May 2020, 18:28

I noticed what appears to be an issue with MKVToolnix, or with what I have in mind...

I have an ISO (DVD) from a TV recording. When I use MPC-HC to open the DVD, the disc is able to play the 2 parts together. When I use MAKEMKV it generates 2 Matroskas. That's OK, but when I append the 2nd file to the 1st, there is an audio bug that is never seen (heard) in these individual files. So this must be a) MKVToolnix's doing, or b) a bug inherent to this idea of appending. Important: I noticed with other disc that is totally different, so this isn't an isolated case, it's valid for ALL appendings we ever do.

Let's see if I can explain this...

We will assume each video has 2 minutes. Appending would make a single 4 minute MKV file, right?

The problem is that the 4 minute file mutes the audio for a second after the point in which they are joined together.

Like this:

>>>>>> 4 minute file when analyzed further:

2 minutes 2 minutes
====== =/====

/ = the muting.

/ would be at 2:02 or 2:03.

Then at 2:04 the video and audio continue just fine.

But (and here's the catch) if we open file2.mkv and play it... we never notice the / I just mentioned above.

Here's proof of what happened. Instead of just posting a written explanation, I have actually recorded the bug happening

First, I want to show how I am putting these files together:

https://i.imgur.com/1QQDF2s.png

Second, download this file from Google Drive and play in your PC:

-LINK REMOVED-, problem solved

PROOF.mpg;

Pay attention of what happens in the following moments:

- 0:00 until 20 seconds - file1.mkv is played.
- 20 seconds until 47: file2.mkv is played

- Starting at 50 seconds I play this "4 minute" file, which is file1.mkv and file2.mkv appended.

1 minute and 7 seconds: exactly the moment in which the / (bug) can be noticed: the audio is briefly muted. This would be in a 4 minute file the moment 2:02 or 2:03, approximately.

Note that file2.mkv at 30 seconds onwards don't show anything wrong. This is how it should have been in the 4 minute file.

In theory the appending of file1.mkv and file2.mkv should generate a 4 minute file spotless. Why is that not happening?

MEDIAINFO from file1.mkv:

https://pastebin.com/1BgabbRa

kuchikirukia

21st May 2020, 19:52

Cut out 20 seconds at the end of mkv1, 20 seconds out of the beginning of mkv2, and upload both along with a merged 40 second copy. That will give mosu something to look at.

Also you can probably get around this issue by appending the audio and video tracks separately and them muxing them together.

sneaker_ger

21st May 2020, 20:37

Mkvmerge has 2 different --append-mode settings. It's common for the default setting to create audio or video gaps. You can read in the docs about them:
https://mkvtoolnix.download/doc/mkvmerge.html

MEDIAINFO from file1.mkv:

https://pastebin.com/1BgabbRa
It says video is 48m39s, audio is 48m38s. If you use the default append mode a 1 second audio gap is expected. (Feature, not bug.)

Perenista

21st May 2020, 21:54

Mkvmerge has 2 different --append-mode settings. It's common for the default setting to create audio or video gaps. You can read in the docs about them:
https://mkvtoolnix.download/doc/mkvmerge.html

It says video is 48m39s, audio is 48m38s. If you use the default append mode a 1 second audio gap is expected. (Feature, not bug.)But how do I tell MKVToolnix to use TRACK mode instead? I am using the GUI. Should I only use command lines for that?

Yeah, this is a case of a DVD (VOB...) splitted into 2 different MKVs by MAKEMKV, so when appending them I need to use TRACK instead of "FILE" (see below), otherwise this problem will happen.

These splitted MKVs are 2 parts of a single content, not two independent recordings from the same DVD that I wanted to put together, yet were always apart from each other.

The only reason MAKEMKV created 2 MAKEMKVs is because the DVD was created with 2 options: WATCH ALL (which in the end just put them together) and watch 1st half of the match and 2nd half (it's a broadcast from a sports event).

--append-mode mode
*********
Determines how timestamps are calculated when appending files. The parameter mode can have two values: 'file' which is also the default and 'track'.

When mkvmerge appends a track (called 'track2_1' from now on) from a second file (called 'file2') to a track (called 'track1_1') from the first file (called 'file1') then it has to offset all timestamps for 'track2_1' by an amount. For 'file' mode this amount is the highest timestamp encountered in 'file1' even if that timestamp was from a different track than 'track1_1'. In track mode the offset is the highest timestamp of 'track1_1'.

Unfortunately mkvmerge cannot detect which mode to use reliably. Therefore it defaults to 'file' mode. 'file' mode usually works better for files that have been created independently of each other; e.g. when appending AVI or MP4 files. 'track' mode may work better for sources that are essentially just parts of one big file, e.g. for VOB and EVO files.
*********

kuchikirukia

22nd May 2020, 00:10

Also you can probably get around this issue by appending the audio and video tracks separately and them muxing them together.

^^^^^

Perenista

22nd May 2020, 02:15

^^^^^It worked! I read your message and was reluctant to try. Now I figured out how it's done:

I had to do the following:

1) gMKVExtractGUI: extract the video and chapter tracks from file1.mkv. Repeat procedure for file2.mkv.

2) MKVToolnix: create a MKV with extracted tracks from file 1. Repeat for tracks from file2.

2.1) Merge the two resulting MKVs (append option).

3) gMKVExtractGUI: extract the audio track from file1.mkv. Repeat procedure for file2.mkv.

4) MKVToolnix: create a MKA with extracted tracks from file 1. Repeat for tracks from file2.

4.1) Merge the two resulting MKAs (append option).

5) Insert the MKA inside the MKV and save as a new MKV.

A little more work, but it fixed the problem. What I am not sure is how can we tell exactly if appending will cause this issue... I only noticed after checking, otherwise it would be still there.

********
Unfortunately mkvmerge cannot detect which mode to use reliably. Therefore it defaults to 'file' mode. 'file' mode usually works better for files that have been created independently of each other; e.g. when appending AVI or MP4 files. 'track' mode may work better for sources that are essentially just parts of one big file, e.g. for VOB and EVO files.
********

In this case it was easy to spot the error because:

a) It's a DVD, so VOB files;

b) It's a sports event, a match with 1st and 2nd half, and when we open the DVD it offers us the option to play all together or select one of the two.

Another case in which I saw this problem was a TV show episode that is probably viewed as a single one (with 44 instead of 22 minutes) during DVD playback, but it's actually splitted into two when MAKEMKV is extracting.

When I tried appending the MKVs the same thing happened, so I let them separated.

I never stopped to read mkvmerge's documentation, this is very interesting.

kuchikirukia

22nd May 2020, 02:27

Uh, alternately you could've just put file1 and 2 into mkvtoolnix set to append, selected only the video track and hit merge, then deselected the video track and selected the audio track and hit merge, then muxed the resulting mkv and mka files together.

You just always need to check your joins. There's no way to automatically tell which way is the right way to append. Subtitles especially will wreck things if you're splitting and appending since the lines don't get cut on split (it only splits between subtitle lines). So your audio and video will get cut on the keyframe, the subtitle line will extend further, and so when you try to append, everything in the next file will get pushed back to the end of the subtitle line.

sneaker_ger

22nd May 2020, 06:57

JFYI:
https://i.imgur.com/xmtFNhh.png

(Whether or not to use track append mode on these files is a different question. I would have expected a sync issue if the two files weren't originally from the same VOB.)

kuchikirukia

22nd May 2020, 18:29

Yeah, he probably needs to cut the last 1 second of file1 to get the dangling track back in line.

Masutin

27th May 2020, 22:40

What do you use to find key frames? In mkvmerge 29 (XP), times according to PotPlayer may result in one KF too early or late.

Mosu

30th May 2020, 13:58

Well hello, gentle people.

Surprisingly it's still May, even though it feels much longer since… well everything, really. Anyway, roughly four weeks since the previous release means it's a good time for another MKVToolNix release.

v47 contains a couple of new enhancements and few bug fixes. However, under the hood big chunks of the source code was changed in an ongoing effort of switching from using Boost libraries to the C++ standard library. For end users this replacement doesn't mean much — apart from the usual danger of accidentally introducing bugs. Hopefully not too many.

For package maintainers the situation is different. There were several changes, not only due to this migration. Please read the news below carefully. Thanks.

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 47.0.0 "Black Flag" 2020-05-30
New features and enhancements

mkvmerge: chapters: mkvmerge can now read chapters from DVDs if the user specifies the path to a DVD folder structure via the "--chapters …" parameter. By default chapters from the first title will be imported. This can be changed by append ":<title number>" to the file/directory name in the "--chapters …" argument, e.g. "--chapters /srv/dvds/BigBuckBunny/VIDEO_TS:3" This feature requires mkvmerge to have been built with the "libdvdread" library. Part of the implementation of #2808 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2808).
mkvmerge: added "--engage append_and_split_flac" that enables mkvmerge to append and split FLAC tracks, restoring pre-v45 behavior. The resulting tracks will be broken: the official FLAC tools will not be able to decode them and seeking will not work as expected.
MKVToolNix GUI: multiplexer: added support for mkvmerge's new support for reading chapters from DVDs if both have been built with the "libdvdread" library. Part of the implementation of #2808 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2808).
MKVToolNix GUI: multiplexer: when deriving languages from file names the GUI will now look for simplified language names instead of the full ones (e.g. instead of looking for "Greek, Modern (1453-)" it would simply look for "Greek").
MKVToolNix GUI: multiplexer: the options in the "additional command-line options" dialog are now sorted alphabetically. Additionally the "--append-mode" option has been added as one of the only missing global options.
MKVToolNix GUI: chapter editor: the chapter editor can now read chapters from DVDs if MKVToolNix has been build with the "libdvdread" library. Part of the implementation of #2808 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2808).
MKVToolNix GUI: header editor: added an option in the preferences for displaying all date & time values in UTC instead of the local time zone. Implements #2814 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2814).

Bug fixes
all: fixed a crash when using the "MTX_LOGGER=file" syntax for logging debug messages without specifying a file name to log to. It will now log to a file called "mkvtoolnix-debug.log" in the system's default temporary directory, as initially intended.

Build system changes
The "libdvdread" (https://www.videolan.org/developers/libdvdnav.html) library will be used if found via "pkg-config". If it is found, support for reading chapters from DVDs will be enabled in "mkvmerge" and the MKVToolNix GUI. Part of the implementation of #2808 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2808).
Boost's Date/Time, Lexical Cast, Range, Range Adaptors, Tri-Bool, Variant libraries are not used anymore.
MKVToolNix now requires a C++ compiler & standard library that support the following features of the C++17 standard: ""std::variant"", ""std::gcd"". For the GNU Compiler Collection (gcc) this means v7 or newer; for clang it means v4 or newer — the same versions required by earlier MKVToolNix versions.
MKVToolNix now requires version 6.1.0 of fmtlib or later for the "fmt::to_string" function and bugfixes to the formatting of floating point numbers. If a system-wide version is installed that's older, the bundled copy will be used.
The bundled version of fmtlib has been updated to release 6.2.1.

Have fun :)

hubblec4

30th May 2020, 14:48

Hi Mosu

Maybe there is a bug for IFO support.
I have opened a ticket (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2830).
Can someone confirm this?

Mosu

30th May 2020, 17:44

The thing is: I'm using libdvdread for reading DVDs. That library has the same problem a lot of other Unix-originating libraries have: they use the "open()" or "fopen()" function which only takes a char* as the file name argument, or to put it differently: they don't support reading from file names/paths that contain non-ASCII (non-ANSI, but due to how mkvmerge works internall, non-7bit-ASCII effectively) characters on Windows (on Linux/macOS that's not a concern as those functions take UTF-8 encoded char* strings there).

Bummer. But something I did know about when I made the decision to use libdvdread. Classical tradeoff between the amount of time I was willing to invest into this feature (it already took several hours to implement) and the importance of the feature (DVD? nowadays? Pleeease… and there are other tools that can get you the same information).

hubblec4

30th May 2020, 20:31

All fine, and I know you have more important things to do.

Liisachan

30th May 2020, 20:49

@Mosu
Thanks again for your passionate work :)
It's unfortunate that FLAC support is limited; one doesn't have this problem if WavPack is used instead?
[Btw I don't think you need to bad-mouth (?) DVD just because it's not the newest format; there are some hidden gems - old shows - only available as DVDs, and in some cases BD versions may even look worse when the show was originally created as SD but forcefully up-scaled to HD w/o careful remastering...]

@hubblec4
On Windows, Unicode (non "ANSI") file names often have ascii file names too, as seen by dir /x. Which may help in some cases, transparently recognized as the alias of the Unicode file name. E.g. Avisynth can read Unicode file names if you use such short (ascii) names.

@Masutin
Not sure if this will help you with your specific problem, but if you just open a file (e.g. MKV) with VirtualDub2, Keyframes are shows as scuh (Shift + arrow keys). You could also do ffmsindex.exe -f -k "path\to\your file.mkv" to quickly get the keyframe list.

stax76

30th May 2020, 21:23

Since Windows 10 the code page can be changed to UTF8, most but not all apps work well with it.

On Windows, Unicode (non "ANSI") file names often have ascii file names too, as seen by dir /x.

Does anybody know an API or command to get this name?

Liisachan

30th May 2020, 22:01

GetShortPathName

stax76

30th May 2020, 22:23

Thanks, I hope it will be useful.

lvqcl

30th May 2020, 22:43

stax76

30th May 2020, 23:53

According to this page (https://superuser.com/questions/1505174/how-comes-that-short-filenames-8-3-are-created-in-one-partition-and-not-in-ano), "Since Windows 8 and Windows Server 2012 newly formatted volumes will have 8.3 name generation disabled by default." So GetShortPathName() is not a reliable workaround.

Here in the terminal short paths work, apparently using UTF8 as code page is better anyway because only then Emoji show in the terminal.

https://i.postimg.cc/0NJtDNg2/Untitled.png

Mosu

31st May 2020, 11:17

I'm aware of GetShortPathName(), and I do have experimental code that re-tries with the short path name if opening with the regular one fails. The problem is: it doesn't actual solve the problem. It's not even a good workaround. It's a workaround that works _sometimes_ under _specific circumstances_. For example: It doesn't work if the file system doesn't store short path names. It doesn't work on network drives.

Sooooo… no.

Mosu

1st June 2020, 09:49

It's unfortunate that FLAC support is limited; one doesn't have this problem if WavPack is used instead?

Nope. Neither do the other supported, lossless formats: ALAC & TrueAudio. Neither of the three formats has the same type of unfortunate design decisions that FLAC does.

Note that support for files created by WavPack5 is currently slightly broken. Just within the last couple of hours a PR was opened to fix those issues, though, and the next MKVToolNix release will handle them correctly.

Liisachan

1st June 2020, 21:25

Neither of the three formats has the same type of unfortunate design decisions that FLAC does. Is the design of FLAC somehow strange? Hypothetically, what if one uses flac --ogg to write it as .oga? The current version of MKVToolNix doesn't support it, but it's an Ogg so MKVToolNix could read it alright in theory and handle it right? If so, maybe you could store FLAC as ogg, or would that simply confuse splitters/players and the resulted MKV wouldn't play even if one could create it?

As for GetShortPathName(), like you know very well, the resulted string is char* encoded in a Window-specific "ANSI" code page, after WideCharToMultiByte(CP_ACP); so even if short paths are enabled, they do not play nicely with a pure ASCII library not written specifically for Windows. For one thing, if the code page is Asian, the char string may contain the same byte as a backslash as the 2nd byte of a multi-byte character.

But unlike others say, using the short path name for a Unicode file name is often a usable workaround *IF* you're using a legacy non-Unicode program written for Windows; e.g. AVISource() in .avs can open Unicode.avi this way [though of course FFVideoSource(utf8=true) may be more elegant].

sneaker_ger

1st June 2020, 21:32

If so, maybe you could store FLAC as ogg
Since when does mkvmerge output anything other than mkv? ;)

See:
https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Appending-&-splitting-FLAC-audio-tracks-not-supported#technical-background

Mosu

1st June 2020, 21:47

Is the design of FLAC somehow strange?

The FLAC file headers (which are stored in Matroska's CodecPrivate) contain a checksum _of the decoded data_. In order to add or remove _encoded_ data to/from the track, the checksum would have to be re-calculated & updated. That would require actually decoding the whole encoded audio stream. No other format I know of uses a checksum of the decoded data because even validating the checksum would require a costly decoding process.

Sure, lots of formats have checksums, but those are checksums of the encoded data and the header data, and most of those checksums only cover single frames instead of _the whole stream_. Those single-frame checksums over encoded data are _fine_.

Here we run into the next problem: the API of libFLAC which is completely incompatible to how mkvmerge works (and other similar programs such as ffmpeg which has its own FLAC encoder & decoder). Meaning there's no easy way to decode FLAC blocks safe for linking to & requiring ffmpeg (which I'm not willing to do) or writing my own FLAC decoder (which I'm even less willing to do).

All of this is independent of where FLAC is stored (raw, in Ogg, in Matroska…).

Liisachan

1st June 2020, 22:57

Thanks for clear explanation. While it's understandable that audiophiles may want to store the checksum of the decoded (i.e. original) data, the situation seems surely inconvenient for Matroska.

@sneaker_ger
I trust you know that, by "store FLAC as ogg" I vaguely meant "store FLAC in the same way Vorbis.ogg is stored in Matroska". But you're right: .ogg is just a container, and FLAC in flac and FLAC in ogg are the same thing for Matroska. It was a stupid question :)

Technically, you have to scan the whole file(s) to re-calculate checksums and checkSumAdjustment when you edit a TTF file or split a TTC into TTF files too. But in this case, of course you don't have to decode any compressed data.

foxyshadis

7th June 2020, 21:01

The FLAC file headers (which are stored in Matroska's CodecPrivate) contain a checksum _of the decoded data_. In order to add or remove _encoded_ data to/from the track, the checksum would have to be re-calculated & updated. That would require actually decoding the whole encoded audio stream. No other format I know of uses a checksum of the decoded data because even validating the checksum would require a costly decoding process.

Sure, lots of formats have checksums, but those are checksums of the encoded data and the header data, and most of those checksums only cover single frames instead of _the whole stream_. Those single-frame checksums over encoded data are _fine_.

Here we run into the next problem: the API of libFLAC which is completely incompatible to how mkvmerge works (and other similar programs such as ffmpeg which has its own FLAC encoder & decoder). Meaning there's no easy way to decode FLAC blocks safe for linking to & requiring ffmpeg (which I'm not willing to do) or writing my own FLAC decoder (which I'm even less willing to do).

All of this is independent of where FLAC is stored (raw, in Ogg, in Matroska…).

Does anything actually care? FFMpeg generates it, but it also just skips over that value completely while decoding. Never even tries to store it, let alone validate it. flac has this:
FLAC__bool do_md5_checking; /* initially gets protected_->md5_checking but is turned off after a seek or if the metadata has a zero MD5 */
and the decoder does compare against a block of all-zeros to see if it's set. Seems like that would be a perfectly valid thing to set. Of course it's not in the spec, but that's good ol' FLAC.

lvqcl

8th June 2020, 22:07

Flac encoder creates a file with zero checksum if it writes to stdout:

> flac test.wav -o - > test.flac

...or if MD5 calculation is disabled during encoding (undocumented option --no-md5-sum):

> flac --no-md5-sum test.wav

In both cases metaflac shows:

> metaflac --show-md5sum test.flac
00000000000000000000000000000000

It's also possible to change MD5 checksum of an existing flac file with the (another undocumented) option --set-md5sum:

> metaflac --set-md5sum 00000000000000000000000000000000 test.flac

In any case, there's no problems with decoding etc. of such files.

tormento

10th June 2020, 09:57

Would it be possible to introduce batch muxing?

Let's say I have some streams thus named:

01 My movie.mkv (or whatever video format)
01 My movie [ita].ac3 (or whatever audio format)
01 My movie [ita] Forced.srt (or whatever sub format)
01 My movie [eng].ac3 (or whatever audio format)
01 My movie [eng].srt (or whatever sub format)
01 My movie [ita].srt (or whatever sub format)
01 My movie.txt (or whatever chapter format)

Picture that I set the "template" thru that streams and I want to repeat the same thing for "My movie 02" thru "My movie 10".

I have tried to use a "for" command but the string starts to get out of control soon, setting languages, order, forced etc.

Would it be possible to create a batch system for that, changing the number only of the streams?

That would be terrific for muxing entire episode seasons.

Mosu

10th June 2020, 11:05

My stance on batch muxing (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Batch-muxing-with-the-GUI) hasn't changed.

Note that there are third-party applications (https://mkvtoolnix.download/links.html) that implement some type of batch muxing.

tormento

10th June 2020, 13:28

Note that there are third-party applications (https://mkvtoolnix.download/links.html) that implement some type of batch muxing.
Will try them or fight with command line. :p

stax76

10th June 2020, 13:47

For batch muxing in staxrip you would:

-Disable indexing by installing LAV Filter and set source filter to DSS2.
-Select Copy/Mux video encoding profile.
-Select Copy/Mux audio profile.

tormento

11th June 2020, 10:38

For batch muxing in staxrip you would
Thank, will try.

My yesterday attempt (and success) was the following command line:
for %%a in (*.mkv) do "D:\Eseguibili\Media\MKV Toolnix\mkvmerge.exe" --output ^"F:\Out\%%~na.mkv^" --audio-tracks 3 --language 0:jpn --track-name 0: --default-track 0:yes --compression 0:none --language 3:jpn --track-name 3: --compression 3:none --language 4:ita --track-name 4:F --default-track 4:yes --compression 4:none --language 5:ita --track-name 5: --compression 5:none ^"^(^" ^"%%a^" ^"^)^" --language 0:ita --compression 0:none ^"^(^" ^"%%~na.mp4^" ^"^)^" --track-order 0:0,1:0,0:4,0:3,0:5
Funny, uh? :D

Boulder

11th June 2020, 11:06

My method for batch muxing of entire seasons is to 1) name all the files so that they can be easily muxed as episodes, 2) create a project in MKVToolNix GUI out of the files for the first episode, 3) copy the actual commandline, 4) edit it in Notepad++ by replacing "episodefilename" with %~nf and run the whole mess in a command prompt window with for %f in (*.hevc) do "..."

tormento

11th June 2020, 11:22

@Mosu

Would be possible to have an abort job in the Multiplexer window too, without having to switch to Job output one?

That plus a switch in preferences to remove or not the muxed file if a job is aborted.

tormento

11th June 2020, 11:24

My method for batch muxing of entire seasons is
Sometimes I have replace audio and subs from external sources. There is where real fun starts. :p

Perenista

11th June 2020, 17:31

Hey, what happened with appending this kind of MKV?

2-3.mkv' cannot be appended to the track number 1 from the file '1-3.mkv'. Appending tracks of this type is not supported.

It's funny, I remember having splitted these with MKVToolnix before... Now I can't merge them?

MEDIAINFO from file1.mkv:

https://pastebin.com/3bwkggYY

Should I get an older MKVToolnix version for that? If so, which one?

Note: The whole thing was splitted into 3 files. I tried appending file 1.mkv to file2.mkv and file3.mkv.

P.S. This was indeed splitted with help from MKVToolnix, in May 26, 2018 (v23.0.0). I can confirm that, because file 1 continues in file 2 and I did the splitting because I store them in Google Drive, and part1 has almost 15 GB, which is the max Google Drive space allowed. I need to use append for all 3 to further proceed with another splitting. File1 has 6 hours and file 2 another 6 hours I believe, and I need to do a splitting after 8 hours.

(((((((((((()))))))))

Wait a minute! I got the 23.0.0 version * and this appending is working!!!!!!!!!!!!

* From here:
https://mkvtoolnix.download/windows/releases/23.0.0/

What is going on?

Proof it's working:

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

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

*******
RESULTED FILE:

Appending worked in 23.0.0!

https://pastebin.com/YX3KAWCh

So why was this feature removed? I had to install this older version in another folder, just to merge the 3 parts again.

And there are no anomalies in this 35 GB file with all 3 combined.

>>>>>>>>>
Another problem: Splitting is also being denied in this newer version. Again I had to resort to 23.0.0 to do this.

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

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

sneaker_ger

11th June 2020, 22:30

Read:
https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Appending-&-splitting-FLAC-audio-tracks-not-supported

Perenista

11th June 2020, 23:11

Read:
https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Appending-&-splitting-FLAC-audio-tracks-not-supportedI have noticed after writing this post that my 2 uploads somehow have stuttering issues not solved after hours. They are both online at Youtube, but I am already checking the whole thing again just to confirm if this is only Youtube's doing or if they became this way after I combined them:

The 1st video has almost 12 hours (Youtube limits to 12 hours or 128 GB). This I believe has 60-70 GB:
LINK REMOVED. A NEW ONE IS BEING SENT RIGHT NOW, AND I ALREADY CONFIRMED IT'S OK. THIS ISSUE WAS FIXED BY FOLLOWING THESE TIPS (https://forum.doom9.org/showthread.php?t=170249&page=12)

The 2nd video has 3 hours and more or less 22 GB:
LINK REMOVED. A NEW ONE IS BEING SENT RIGHT NOW, AND I ALREADY CONFIRMED IT'S OK. THIS ISSUE WAS FIXED BY FOLLOWING THESE TIPS (https://forum.doom9.org/showthread.php?t=170249&page=12)

*****************
(Update: problem solved, I changed the audio to W64 and now the newer MKVtoolnix versions handle it just fine. Youtube is also showing the full video without issues: https://www.youtube.com/watch?v=I-hAea-eYz8 - no more stuttering, probably caused by the old audio track). For the moment I gave up the idea of reencoding the video (in H.265 it would still be as much as good as it is now), which would in my calculations be reduced to 50% of its current size, because it would take too much time in my 2014 PC.
*****************

I recorded this content (Metal Gear Solid PS1 game) using an old software many will know... called FRAPS (which is crap and for years no one uses anymore).

Unfortunately I didn't use OBS at the time so the files end up being very big and reencoding the whole thing isn't something I am willing to do at this point (if it's done then the resulted file would have to be 98% similar in terms of PQ). But in this case I suspected before you posted this had nothing to do with the video, since in the past I remember having a similar problem:

https://forum.doom9.org/showthread.php?p=1786481#post1786481

In this case the total filesize is 95 GB and almost 15 hours. I had to split into 15 GB parts because that's the Google Drive free account max disk space, I use multiple accounts for backup. That's why I splitted back then. When I wanted to watch the whole thing I just had to append.

Mosu

12th June 2020, 18:43

Would be possible to have an abort job in the Multiplexer window too, without having to switch to Job output one?

I don't want any controls working on the current job in the multiplexer window as it's completely intransparent which job they would actually work on. There might be something else entirely muxing currently, that has nothing to do with what's shown in the multiplexer tool at that moment.

That plus a switch in preferences to remove or not the muxed file if a job is aborted.

You mean the incomplete output file(s)? Hmm… that I would consider. Please open a feature request for it over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/-/issues); makes it harder to forget about it again :) Thanks.

Liisachan

12th June 2020, 19:44

@foxyshadis
@lvqcl
Thanks for the great info. I tried --no-md5-sum and it works perfectly (though a WARNING is shown when encoding). If the correct MD5s are desired, I guess one can still append/split FLAC.mkv by
1 demuxing FLAC
2 decoding it to WAV (*)
3 remuxing it with the original MKV while disabling FLAC track(s)
4 MKVToolNix can append/split this
5 replace the audio in the resulted file(s) with FLAC, by demuxing WAV, compressing, and remuxing.
(*) or transcode it to WavPack so Step 5 will be unnecessary

@Mosu
Something very minor, not practicaly important: When the "second" is not integer in DateUTC, Header Editor's behavior is slightly inconsistent, e.g. the same time 01:23:45.9 may be shown as 01:23:45 or 01:23:46 depending on the year:
Original Date 2000-12-31 01:23:45.9 -> Header Editor shows 01:23:46
Original Date 2001-12-31 01:23:45.9 -> Header Editor shows 01:23:45
Header Editor doesn't refuse to write a "bad" Date not expressible as EBML, when it is specified by the user.
New Date 2293-04-11 23:47:16 -> Header Editor writes x = 0x7FFFFFFFCD0D2800 correctly.
New Date 2293-04-11 23:47:17 -> Header Editor overflows: 0x8000000008A7F200 = x + 10^9 is written (=1708-09-22 00:12:43.290448384). If Matroska lives long, eventually the year 2293 problem will occur...

Nejiro

16th June 2020, 18:47

When I use the program I sometimes get error or warning messages but when I click to go and see them it doesn't show me anywhere, where can I find them?
Thanks

Boulder

16th June 2020, 18:49

Sometimes I have replace audio and subs from external sources. There is where real fun starts. :p

You just have to follow the proper naming scheme to make your batch muxing work :) Bulk Rename Utility is something I also use quite a lot with mkvmerge related things.

Mosu

16th June 2020, 20:20

When I use the program I sometimes get error or warning messages but when I click to go and see them it doesn't show me anywhere, where can I find them?

The "job output" tool (last icon in the job selector on the left) contains the output of the currently running job. It's split into three panes: the regular output on the top, the warnings on the bottom left and errors on the bottom right.

For past jobs you can go to the "job queue" tool, right-click on the job that contains warnings/errors and select "view output" from the context menu. This will open a new tab in the "job output" tool and switch to that new tab. That tab will only contain the output/warnings/errors generated by that one job.

Nejiro

16th June 2020, 22:03

Thank you so much

tormento

17th June 2020, 10:58

I have tried to mux some HEVC video to Matroska and I've found the orientation is lost, i.e. a vertical video on mobile becomes horizontal.

Is there any manual setting we can use to set back the original rotation or any tweak you can introduce?

Thanks.

hubblec4

17th June 2020, 11:57

Is there any manual setting we can use to set back the original rotation or any tweak you can introduce?

You can/must use a Tag to rotate the movie. The official ProjectionPoseRoll element is not supported in the players today.

tormento

17th June 2020, 14:28

You can/must use a Tag to rotate the movie. The official ProjectionPoseRoll element is not supported in the players today.
Which tag allows me to do it? Where can I set it in MKV GUI?

I have looked at HEVC file with MediaInfo and there is a Video TAG, such as

Rotation : 90°

Isn't possible to have MKV GUI to automatically recognize Rotation and set the correct tag?

Perenista

17th June 2020, 18:38

Using the delay for audio tracks usually works everywhere? Sometimes I introduce a negative delay for some audio tracks. Other times I put a positive one, also for subtitles. I know we can edit both cases and avoid using the delay field from MKVToolnix, but I think this will imply a reencode at least for audio.

What I find odd is that I once uploaded a video excerpt to Vimeo and the delay was ignored. The same video sent to Dailymotion worked as intended. And for both services I uploaded the same file.

sneaker_ger

17th June 2020, 19:31

Using the delay for audio tracks usually works everywhere?
Most often it works. But not always (as you found out). If you want to be sure you have to take the extra steps to pre-pend silence outside MKVToolNix. (Negative audio delays usually work because mkvmerge does delete audio frames, then).

Other times I put a positive one, also for subtitles.
Subtitle delays should always work, at least with text subtitles.

I know we can edit both cases and avoid using the delay field from MKVToolnix, but I think this will imply a reencode at least for audio.
Depends on the format and software you are using. Softwares like eac3to and delaycut may delay audio without re-encoding. If that doesn't work ffmpeg may be able to encode some silence which you can manually prepend in mkvmerge.

hubblec4

17th June 2020, 22:34

Which tag allows me to do it? Where can I set it in MKV GUI?

I have looked at HEVC file with MediaInfo and there is a Video TAG, such as

Rotation : 90°

Isn't possible to have MKV GUI to automatically recognize Rotation and set the correct tag?

MKVToolNix has no Tags editor and the ROTATE Tag is not an official one.
You can use my chapterEditor -> MatroskaTools->Tags
In a SimpleTag set
TagName = ROTATE
TagString = 90 or -90
TargetUID = the type is TagTrackUID and the UID is the video track UID

vertigo220

20th June 2020, 16:05

Not sure if this is a bug or if I'm just not understanding how it's supposed to work, but I have some audio files and some video files, the latter consisting of a single frame each. I'm trying to combine them into a file where each image displays for the duration of one of the audio files. I tried changing the duration/FPS, but since they're different lengths, that didn't work. I tried stretching them, but if I stretch them by the proper amount (which took a fair amount of trial and error to figure out), they show for the proper durations, but the file is twice as long as it's supposed to be. In this case, if the first audio file is e.g. 90s long, and therefore the first chapter in the final file should also be 90s, the chapter is actually 180s long and when it reaches 90s it jumps to the next chapter. But if I click in the timeline between 90s and 180s, it just "plays" all the way to chapter 2. If I cut the stretch factors in half, the total and chapter lengths are correct, but the images only display half as long as they're supposed to, so the image for chapter two in the above example would display at 45s.

Any ideas either on how to do this or whether this is actually a bug? It seems like one to me, but apparently I have to know for sure before reporting it as such.

sneaker_ger

20th June 2020, 17:26

Hard to answer without having a sample file at hand. Video timings are usually(*) not related to chapters. You could try to manually set the timings for the video via timestamp (v2) files. https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.external_timestamp_files
(To check your output file let mkvextract create a timestamp v2 file for your video track or look into mkvinfo.)
If it still does not work I would say it is a problem of your player.

(*) if we ignore ordered chapters

jlw_4049

23rd June 2020, 21:16

I was wondering if there was anyway to allow the extraction of the DTS CORE from DTS-HD files via the mkvextract CLI?

sneaker_ger

24th June 2020, 17:22

Mosu

27th June 2020, 20:15

Hey everyone,

summer's upon us, and surely we're all itching to stay at home some more, aren't we? Well, despair not, at least you can update your MKVToolNix version to the latest & shiniest there ever was.

This release features massive improvements to the handling of Blu-ray playlists (MPLS files) & corresponding MPEG transport streams (M2TS files), both bug fixes and real enhancements. See the news below for details.

Important news for package managers are the new reuquirements for libEBML/libMatroska & the main development branch having been renamed in my source code repo. Again, see the news for details.

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 48.0.0 "Sick Of Losing Soulmates" 2020-06-27
New features and enhancements

mkvmerge: AC-3: file identification will report AC-3 tracks encoded in Dolby Surround EX as codec "AC-3 Dolby Surround EX". Implements #2740 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2740).
MKVToolNix GUI: multiplexer: on new installations the GUI will now recognize all known ISO 639-2 language codes in file names by default instead of only the top 100 of languages by native speakers.
MKVToolNix GUI: multiplexer: on new installations the list of "often used languages" will by default only contain certain agnostic ones ("multiple languages", "no linguistic content", "reserved for local use", "uncoded languages"), "English" and the default user interface language. The "list of spoken languages by native speaks" isn't used anymore. Also implements #2716 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2716).
MKVToolNix GUI: header editor: added an option to remove all attachments to the tree context menu. Implements #2835 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2835).
MKVToolNix GUI: while the GUI is running it will remember the last page that was selected when the preferences dialog is closed. Upon re-opening the preferences that page will be selected by default. Implements #2852 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2852).

Bug fixes

mkvmerge: fixed a segmentation fault when exiting prematurely due to write errors such as the destination having run out of space. Fixes #2843 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2843).
mkvmerge: DTS: fixed wrong channel count for DTS tracks with XCh extensions. Fixes #2715 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2715).
mkvmerge: MPEG TS reader: fixed detecting h.264/AVC and h.265/HEVC tracks that consist of only a single frame. Part of the fix of #2849 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2849).
mkvmerge: MPEG TS reader: fixed handling of unbounded PES sizes for tracks that consist of only a single PES packet. Part of the fix of #2849 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2849).
mkvmerge: MPEG TS reader: PGS subtitle tracks are now exempt from the "detect bogus subtitle timestamps" heuristic which could lead to some PGS subtitles not being timestamped correctly. Symptoms were that they were shown at the wrong time or that they were shown indefinitely. Fixes #2736 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2736) and partially fixes #2824 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2824).
mkvmerge: MPEG TS reader: when reading MPLS playlists the start timestamps of a play items were handled wrong: all the timestamps of packets read were compared to that start timestamp, dropping those packets whose timestamps were smaller than the play item's start timestamp. The correct behavior is to accept all packets as soon as the first one with a timestamp equal to or larger than the play item's start timestamp is encountered. This could result in PGS subtitle entries located right at the start of the play item being garbled/lost as they consist of multiple PES packets for which some timestamps are often slightly smaller. Part of the fix of #2824 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2824).
mkvmerge: MPEG TS reader: when reading MPLS playlists mkvmerge will no longer read the whole M2TS files they reference, processing only the packets lying inside the timestamp range given by the playlists's play item's start & end timestamps. Instead mkvmerge will use the index information present in corresponding clip information (CLPI) files in order to seek to the nearest file position of the play item's start timestamp. Additionally mkvmerge will simply stop processing a file once the end timestamp is seen. This change greatly speeds up processing files from which only small portions must be read. Part of the fix of #2824 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2824).
mkvmerge: WavPack: fixed support for files created by v5 of the program. Checksums, DSD audio data and non-standard sampling rates are handled correctly. Patch by David Bryant.
MKVToolNix GUI: multiplexer: fixed the cursor being positioned wrong after entering or pasting characters that aren't allowed in file names into the "destination file" control. Fixes #2855 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2855).

Build system changes

libEBML v1.4.0 and libMatroska v1.6.0 are now required.

Other changes

The source code repository's main development branch was renamed to "main".

Have fun :)

jlw_4049

27th June 2020, 22:56

Not directly, only via mkvmerge --reduce-to-core followed by mkvextract. Is ffmpeg an option for you? I think it should allow doing it in one operation (via -c copy and the "dca_core" bitstream filter).

Thank you sneaker! I was asking for the ability to extract/reduce to core when creating a GUI.

andiandi

29th June 2020, 20:54

I wondered if the cut was GOP accurate ?

Because on specific videos, it's impossible to know, AFAIK, if it's open gop or not.

Selur

5th July 2020, 19:53

How to properly mux 29.97 fps interlaced avc content with mkvmerge?

My source is interlaced AVC (duration: 00:00:41.542) and using:
mkvmerge --ui-language en -o "E:\Output\avc - interlaced_new_new.mkv" --global-tags "E:\Output\avc - interlaced_new_new_2020-07-05@20_21_37_3510__03.xml" -d 0 --default-track 0:yes XXXXXXX--fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "E:\Output\avc - interlaced_new_new_2020-07-05@20_21_37_3510_02.264" --default-track 0:yes --sync 0:-67 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "E:\Output\iId_1_aid_4352_DELAY_-67ms_2020-07-05@20_21_37_3510_01.ac3"
as a base (and replacing the XXXXXXX):

I get:
when using:
--default-duration 0:30000/1001i --fix-bitstream-timing-information 0

Frame rate mode : VFR
Frame rate mode : Variable
Frame rate : 29.970
Frame rate : 29.970 (30000/1001) FPS
FrameRate_Num : 30000
FrameRate_Den : 1001
Original frame rate : 14.985
Original frame rate : 14.985 (15000/1001) FPS
FrameRate_Original_Num : 15000
FrameRate_Original_Den : 1001
Duration : 00:01:23.083

when using:
--default-duration 0:60000/1001i --fix-bitstream-timing-information 0
Frame rate mode : VFR
Frame rate mode : Variable
Frame rate : 59.940
Frame rate : 59.940 (59940/1000) FPS
FrameRate_Num : 59940
FrameRate_Den : 1000
Original frame rate : 29.970
Original frame rate : 29.970 (30000/1001) FPS
FrameRate_Original_Num : 30000
FrameRate_Original_Den : 1001
Duration : 00:00:41.542

when using:
--default-duration 0:30000/1001fps --fix-bitstream-timing-information 0
Frame rate mode : VFR
Frame rate mode : Variable
Frame rate : 59.940
Frame rate : 59.940 (59940/1000) FPS
FrameRate_Num : 59940
FrameRate_Den : 1000
Original frame rate : 29.970
Original frame rate : 29.970 (30000/1001) FPS
FrameRate_Original_Num : 30000
FrameRate_Original_Den : 1001
Duration : 00:00:41.542

when using:
--default-duration 0:60000/1001fps --fix-bitstream-timing-information 0
Frame rate mode : VFR
Frame rate mode : Variable
Frame rate : 119.884
Frame rate : 119.884 FPS
Original frame rate : 60.000
Original frame rate : 60.000 FPS
Duration : 00:00:20.770

when using:
--default-duration 0:30000/1001fps
Frame rate mode : Variable
Frame rate : 59.940
Frame rate : 59.940 (59940/1000) FPS
FrameRate_Num : 59940
FrameRate_Den : 1000
Original frame rate : 29.970
Original frame rate : 29.970 (30000/1001) FPS
FrameRate_Original_Num : 30000
FrameRate_Original_Den : 1001
Duration : 00:00:41.542

when using:
--default-duration 0:30000/1001i
Frame rate mode : Constant
Frame rate : 29.970
Frame rate : 29.970 (30000/1001) FPS
FrameRate_Num : 30000
FrameRate_Den : 1001
Duration : 00:01:23.083

when using:
--default-duration 0:60000/1001fps
Frame rate mode : Variable
Frame rate : 119.884
Frame rate : 119.884 FPS
Original frame rate : 29.970
Original frame rate : 29.970 (30000/1001) FPS
FrameRate_Original_Num : 30000
FrameRate_Original_Den : 1001
Duration : 41 s 501 ms

when using:
--default-duration 0:60000/1001i
Frame rate mode : Variable
Frame rate : 59.940
Frame rate : 59.940 (59940/1000) FPS
FrameRate_Num : 59940
FrameRate_Den : 1000
Original frame rate : 29.970
Original frame rate : 29.970 (30000/1001) FPS
FrameRate_Original_Num : 30000
FrameRate_Original_Den : 1001
Duration : 00:00:41.542

So none of the above seem to totally correct, what I was aiming for was:
Frame rate mode : Constant
Frame rate : 29.970
Frame rate : 29.970 (30000/1001) FPS
FrameRate_Num : 30000
FrameRate_Den : 1001
Duration : 00:00:41.542

What am I missing? How to do it correctly?

Cu Selur

Mosu

6th July 2020, 11:23

"--default-duration 0:30000/1001i" should be the correct one. Yes, for interlaced content the track's "default duration" must be half the duration compared to progressive content (meaning other tools might show that as double the frame rate). Remember, Matroska doesn't have a header field for a progressive frame rate; it only has a field that tells the default duration of a single Matroska frame — whatever that "Matroska frame" might contain. For interlaced video content it's a single field, and a single field is shown half as long as a full progressive frame, obviously.

Selur

6th July 2020, 16:10

Confused,...when using "--default-duration 0:30000/1001i" I get:
Frame rate mode : Constant
Frame rate : 29.970
Frame rate : 29.970 (30000/1001) FPS
FrameRate_Num : 30000
FrameRate_Den : 1001
Duration : 00:01:23.083
which doubles the playback time and any play I used plays the video at half the speed.
Shouldn't it be "--default-duration 0:60000/1001i" then?

Selur

6th July 2020, 19:02

Also got another issue, using 'mkvmerge v48.0.0.16 ('Fortress Around Your Heart') 64-bit' (same happens with 48.0.0.0)
and
mkvmerge --ui-language en -o "C:\Users\Selur\Desktop\In The Dark.track.mkv" -d 0 --default-track 0:yes --default-duration 0:50/1i --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "C:\Users\Selur\Desktop\In The Dark.track.264"
the output seems to be only the header without any content. :/
console output doesn't show any errors.
mkvmerge v48.0.0.16 ('Fortress Around Your Heart') 64-bit
'C:\Users\Selur\Desktop\In The Dark.track.264': Using the demultiplexer for the format 'AVC/H.264'.
'C:\Users\Selur\Desktop\In The Dark.track.264' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'C:\Users\Selur\Desktop\In The Dark.track.mkv' has been opened for writing.
Progress: 100%
Uploaded the source .264 file to my GoogleDrive (https://drive.google.com/file/d/1O9w0cYcYer_CRLxrrGZP0Co3Vsoo7DvO/view?usp=sharing) (176MB)
(using --default-duration 0:25fps instead of --default-duration 0:50/1i doesn't change the output,...)

Cu Selur

Ps.: I suspect the source file is somehow broken, the raw stream plays fine in mpc-hc, but neither mkvmerge nor ffmpeg can remux it into a container,... :/

arrgh

6th July 2020, 23:29

if I demux with mkvextract.exe an 3D-MKV, created with MakeMKV, I get an "AVC" file of about the correct size (you might be aware of DGDemux which can demux from the BluRay the h264 and the mvc streams into separate files; the combined file sizes are in the fitting size range of the avc);

but it doesn't seem to be possible to remux this "avc" file with mkvmerge back to a working mvc-mkv (even with a manually set Stereoscopy-Tag);

on the other hand MediaInfo recognizes this avc file as “multiview”…
and a remux with the video taken directly out of the "original" mkv (without prior demuxig) does work...

what additional setting do I need to do? Or is there a bug in mkvextract, so that certain details of the video stream are lost?
Thanks

Mosu

7th July 2020, 13:33

mkvmerge doesn't support reading MVC from anything but other Matroska files yet. See this issue for general support for 3D Blu-rays (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/1106) and this other issue for MVC data in raw h.264 elementary streams (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2709) for details.

arrgh

7th July 2020, 21:27

"yet" has a good sound to it...
I don't know whether the problem is on the "extract" or the "merge" side, but is it difficult to solve it? will it be solved?
I have seen in the second thread that you mention some changing standards... is there a risk that what did work up to now (reading MVC from MKV) might stop working in future?

Mosu

7th July 2020, 22:34

I'm not particularly interested in spending time on 3D stuff, haven't been for years. So that "yet" is definitely not a sign of things becoming supported soon, if ever.

The problem is on the merge side, not the extraction.

To the best of my knowledge the changes to the standard won't affect playback of existing files.

arrgh

7th July 2020, 22:45

...
The problem is on the merge side, not the extraction.
...

so, it seems to be very difficult to "emulate" the mkv-container environment on a primary stream containing all relevant data of the mkv in a way that that the remux would work?

the background of this is: even if the interlacing of the h264 and the mvc into a unified video steam would be done by a third party, mkvmerge would not support the muxing into a mkv file?

Mosu

8th July 2020, 08:57

"Problem" was the wrong word. "Difficult" isn't the right word either. I simply haven't implemented the functionality yet. It would most likely not be "difficult", just time consuming. That mkvmerge doesn't "support" it is simply due to that the time to implement it hasn't been spent yet.

Please don't try to read anything more into my statement than "I'm not motivated to spend time on this feature".

mkver

8th July 2020, 11:50

Selur

9th July 2020, 17:53

Thanks a lot didn't even know that opiton existed. :)

Cu Selur

arrgh

9th July 2020, 21:09

...
To the best of my knowledge the changes to the standard won't affect playback of existing files.

I was not refering only to playback but also to remuxing of mkv from existing mvc-mkv

Mosu

9th July 2020, 21:23

I was not refering only to playback but also to remuxing of mkv from existing mvc-mkv

If I ever decide to implement support for MVC in mkvmerge, it will include being able to read files written before the aforementioned change to the specs.

arrgh

10th July 2020, 18:06

If I ever decide to implement support for MVC in mkvmerge, it will include being able to read files written before the aforementioned change to the specs.

good!

meanwhile there is a tool available, which is part of the DGDemux package, which can interlace the primary h264 stream and the mvc stream into a unified h264 multiview stream;
I was able to mux with tsmuxer a working ISO with such a file.

I would therefore like to ask you to implement the muxing of such interlaced streams into a mkv. I could provide samples...

Thanks

ssjkakaroto

20th July 2020, 05:03

Hi mosu, I'm having a small issue with mkvtoolnixgui v48, which didn't happen with v47.

In a dual-monitor setup, if mkvtoolnixgui is on the secondary monitor and you click on the arrow of "Add job to queue", the menu will appear on the primary monitor.
You can see it here:
v48: https://imgur.com/a/EClTVGV
v47: https://imgur.com/a/TzZXeJL

OS is Windows 7 x64.

Thanks

Mosu

20th July 2020, 13:12

I don't support Windows 7 anymore.

ssjkakaroto

21st July 2020, 02:49

Sure, except it also happens on Windows 10 (Pro x64 version 1909): https://imgur.com/a/ZIjTgTy

Mosu

21st July 2020, 15:25

I see. That's a bug in Qt, then. Nothing I can do about it.

Perenista

27th July 2020, 23:20

I've been putting AVI files into MKV using MKVtoolnix and nothing wrong happened... until now. Audio is out of sync.

I checked the original AVI and there is no issue with it. So putting in MKV changed that. What is wrong here?

This is the MEDIAINFO from the AVI:

https://pastebin.com/gDiDdWEG

And from the MKV with this error:

https://pastebin.com/TbRDzeKb

EDIT: I checked the log for errors and found this:

'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 3344 bytes of invalid data which were skipped before timestamp 00:16:34.664000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 1214 bytes of invalid data which were skipped before timestamp 00:16:38.296000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 63 bytes of invalid data which were skipped before timestamp 00:16:38.322000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 405 bytes of invalid data which were skipped before timestamp 00:16:38.348000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 122 bytes of invalid data which were skipped before timestamp 00:16:38.426000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 1358 bytes of invalid data which were skipped before timestamp 00:16:38.452000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 1254 bytes of invalid data which were skipped before timestamp 00:16:38.557000000. The audio/video synchronization may have been lost.

Invalid data? I can play the original AVI without any issues. At 16:34 and 16:38 the image freezes for less than a second, so there must be some flaw in the file itself, I mean a failure like a broadcast transmission breaking and the image gets fuzzy *. Even so the whole thing continues and I confirmed it's only MKVToolnix that is rejecting this error when I put the content in MKV.

* https://i.imgur.com/hU9C3pe.jpg

I'll try extracting the MP3 with VirtualDubMOD and then adding to see if things change.

>>>>>
Update: it didn't work. I tried creating a MKV with the video stream (and the new subtitle I added) only. OK, no errors in the log. But when I added the MP3 extracted from the AVI they were there again.

That means the problem is not with the video, it's with the audio.

Even so, the question remains:

- Why MKVToolnix can't create a MKV with this error, and without losing sync?
- If it can, how do I enable that option?

Any suggestions to fix this? Despite the fact the original AVI file doesn't need fixing since it can be watched synchronized.

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

Update: just checked another file and when this problem happens the MKV created by MKVToolnix simply skips the defective part, making the audio jump. That's what makes the audio becoming out of sync. If I let the content in the original AVI this doesn't happen.

Unfortunately this is how MKVToolnix works, when it should leave the file as it is. So I am forced to watch the file in AVI, otherwise I will break it even more.

Correction: I checked two more files that had the same issue and they didn't lose sync, but in one of them the audio jumped (it cuts abruptly to the next second corrected) as I said before. They probably didn't lose sync because for them the flaw was seen quicker than the other ones that were way more corrupted.

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

This situation is pretty much what happens when we play a vinyl (LP) and there's skipping.

LPs sound great when in good condition. Records can suffer from all sorts of deterioration, much of it causing unwanted skipping or audio distortion. Some of these problems can be remedied, while others, are permanent. One of the main problems of older records are that they skip, or have lots of crackling and popping when playing. This is a common problem when attempting to convert records to CD or MP3 files.

What MKVToolnix does is to make us notice the problem even further.

What I wanted: that MKVtoolnix displayed the AVI just like it is displayed before putting the same AVI into a MKV container.

In other words, that MKVToolnix ignored the error completely and didn't change anything.

I can only assume this is impossible in the AVI --------- > MKV conversion.

Mosu

2nd August 2020, 15:04

Hey y'all,

this is more or less a small bugfix release of MKVToolNix. One rather important new feature is support for the new Matroska elements introduced for storing additional codec-initialization data needed for techniques such as MVC (3D video) or Dolby Vision metadata. mkvmerge cannot produce them itself yet, but it will keep the data that's present, e.g. when reading files created by MakeMKV.

Important news for package managers is that libMatroska v1.6.1 is now required (that one was released earlier today). As usual MKVToolNix bundles that version as a fallback.

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 49.0.0 "Sick Of Losing Soulmates" 2020-08-02
New features and enhancements

mkvmerge: added support for copying the new track header elements "BlockAddIDName", "BlockAddIDType", "BlockAddIDValue" and "BlockAddIDExtraData" from Matroska files if they exist. Part of the implementation of #2887 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2887).
mkvinfo: added support for the new track header elements "BlockAdditionMapping", "BlockAddIDName", "BlockAddIDType", "BlockAddIDValue" and "BlockAddIDExtraData". Part of the implementation of #2887 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2887).
MKVToolNix GUI: multiplexer: the list of recent directories can now be edited in the preferences → "Multiplexer" → "Destination file name". Implements #2861 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2861).
MKVToolNix GUI: preferences: the values in the various "predefined values" lists can now be re-ordered freely by dragging & dropping.

Bug fixes
mkvmerge: Matroska reader: when reading tracks (e.g. a subtitle track) from Matroska files with their "default track" flag set to "yes", and when overwriting those via the command line to "no", "mkvmerge" would not promote additional tracks of the same type from other files (e.g. another subtitle track from an SRT file). Fixes #2863 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2863).
mkvmerge: SRT reader: empty lines inside entries were doubled. Fixes #2888 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2888).
mkvmerge: subtitles: when calculating the rounded duration of each entry the error from rounding the corresponding timestamp will be taken into account. Fixes #2890 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2890).
mkvextract: SSA/ASS extraction: mkvextract is no longer inserting empty lines before the "Dialogue:" lines. Fixes #2876 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2876).
mkvextract: USF subtitles: start & end timestamps were too high by a factor of 1.000.000. Fixes #2875 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2875).
MKVToolNix: info tool: when saving to a text file the checkbox "Save as default for saving output to text files" did nothing. Fixes #2869 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2869).
MKVToolNix: info tool: when saving to a text file in "all elements in a tree-like structure" mode, the GUI always stopped at the first cluster regardless of the setting of the "verbosity" option.
MKVToolNix GUI: preferences: when tooltips were disabled the dialogs for adding new entries to the various "predefined values" lists were missing their texts.
Windows installer: the images are shown again. Fixes #2868 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2868).
configure: fixed detection of QtDBus. Fixes #2886 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2886).

Build system changes
libMatroska v1.6.1 is now required. The bundled version has been updated to that version.

Have fun :)

quietvoid

2nd August 2020, 17:41

One rather important new feature is support for the new Matroska elements introduced for storing additional codec-initialization data needed for techniques such as MVC (3D video) or Dolby Vision metadata. mkvmerge cannot produce them itself yet, but it will keep the data that's present, e.g. when reading files created by MakeMKV.

Thanks for the new release :)

I was playing with test samples and the headers seem to be kept just fine (mkvinfo says so at least).

I was wondering if there were plans to be able to edit these (block addition mapping, and all) with mkvpropedit (or the GUI), as they don't seem to be in the current list.
It's possible that is what you refer to for mkvmerge cannot produce them itself yet,

Mosu

2nd August 2020, 21:48

No plans for making those fields editable with mkvpropedit/the header editor. The reason is that they're codec-specific data. I don't make CodecPrivate available for editing either.

quietvoid

2nd August 2020, 22:51

Okay, thanks for the info.

ssjkakaroto

3rd August 2020, 05:59

Hey Mosu, can you tell me exactly what changed between v47.0.0 and v48.0.0/v49.0.0 regarding to Qt so I can try to open a bug report about the dual-monitor issue over the Qt bug tracker?

Mosu

3rd August 2020, 12:15

Hey Mosu, can you tell me exactly what changed between v47.0.0 and v48.0.0/v49.0.0 regarding to Qt so I can try to open a bug report about the dual-monitor issue over the Qt bug tracker?

v47 was built with Qt 5.14.2, v48 with Qt 5.15.0. Apart from that no changes wrt. to monitor or menu or display handling were made on my end.

Selur

9th August 2020, 11:03

Small question about chroma sub sampling signaling.
From https://mkvtoolnix.download/doc/mkvmerge.html I gathered that for:

4:2:0 one should use 1,1
4:2:1 one should use 1,0

-> What should be used for '4:4:4' and 4:2:2' ?

nevcairiel

9th August 2020, 22:02

The wording of that option sure is bizarre, but either way, for 4:4:4 its clearly 0,0 since nothing is being removed. And 4:2:2 has full vertical resolution, so it should be 1,0.

I have never seen a MKV that uses that information though, when raw video is contained in MKV its usually with a FourCC to identify it or similar means, and encoded video carries that information in its bitstream.

Mosu

9th August 2020, 22:03

I actually don't know. Those options & the accompanying documentation was contributed by someone else.

ssjkakaroto

10th August 2020, 00:00

v47 was built with Qt 5.14.2, v48 with Qt 5.15.0. Apart from that no changes wrt. to monitor or menu or display handling were made on my end.
Hi Mosu, the bug with the popup menu will be fixed in Qt 5.15.1 (https://bugreports.qt.io/browse/QTBUG-84462)

Mosu

10th August 2020, 17:53

That's great, thanks! I usually update my build environment once a month and should pick up 5.15.1 quickly after its release.

chros

12th August 2020, 09:39

No plans for making those fields editable with mkvpropedit/the header editor. The reason is that they're codec-specific data. I don't make CodecPrivate available for editing either.

Hi Mosu! Thanks for your continous work on mkvtoolnix.
Do you know any util to do this? I'm asking because of this (https://forum.doom9.org/showthread.php?t=181702). (Although I don't even know whether it's possible without reencoding.)

Mosu

13th August 2020, 16:50

I strongly doubt that you can convert HDR formats without re-encoding.

SeeMoreDigital

13th August 2020, 17:44

Hi Mosu! Thanks for your continous work on mkvtoolnix.
Do you know any util to do this? I'm asking because of this (https://forum.doom9.org/showthread.php?t=181702). (Although I don't even know whether it's possible without reencoding.)There's no need to convert HDR10+ to HDR10... As HDR10+ (and Dolby Vision) HEVC encodes already include mandatory HDR10 meta-data as a fall-back!

https://en.wikipedia.org/wiki/HDR10%2B

chros

19th August 2020, 10:15

Thanks, but for whatever reason the Oppo deal with HDR10+ in a different way. @butterw2 just wrote how to flag (https://forum.doom9.org/showthread.php?p=1921283#post1921283) these differently using ffmpeg. That's what I need for experimenting. I'll continue with this in this thread (https://forum.doom9.org/showthread.php?t=181702).

Mosu

6th September 2020, 14:53

Hello everyhone,

another month, another MKVToolNix release. This one includes quite a high number of commits under the hood due to the prominent new feature I've implemented: support for the new IETF BCP 47 language elements. Finally you can express things such as "Portuguese as spoken in Brazil" or "Serbian in Cyrillic script as spoken in Serbia".

Apart from that there are the usual enhancements & bug fixes.

Important news for package managers is that the PCRE2 library is now required (only its UTF-8 variant).

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 50.0.0 "Awakenings" 2020-09-06
New feature: IETF BCP 47 language tags

I've written up a nice FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix) about the switch to using IETF BCP 47 language tags, how they interact with legacy language elements, how the programs actually behave and how to disable their use if necessary.
mkvmerge: IETF BCP 47/RFC 5646 language tags: mkvmerge will now accept full BCP 47 language tags for all options taking a language. mkvmerge will always write "LanguageIETF" track header elements. If the language tag contains a valid ISO 639-2 language code it will also set the legacy "Language" track header element to the included ISO 639-2 code. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvmerge: IETF BCP 47/RFC 5646 language tags: if present the "LanguageIETF" track header element will be reported as the "language_ietf" property in JSON identification mode. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvmerge: IETF BCP 47/RFC 5646 language tags in chapters: mkvmerge will now write "ChapLanguageIETF" elements when creating chapter atoms, either when reading the simple chapter format or when generating chapters due to the "--generate-chapters" command line option. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvmerge: IETF BCP 47/RFC 5646 language tags in tags: mkvmerge will now write "TagLanguageIETF" elements when creating "simple tag" elements, either when reading tag XML files or when generating them. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvmerge: IETF BCP 47/RFC 5646 language tags: added an option "--disable-language-ietf" that causes mkvmerge to only write the legacy language elements.
mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: IETF BCP 47/RFC 5646 language tags in chapters: when reading XML chapter files the programs will now add "ChapLanguageIETF" elements for atoms that don't contain them. The values are derived from existing "ChapterLanguage" elements. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvpropedit: IETF BCP 47/RFC 5646 language tags: setting/deleting the track language now acts on both the old language element as well as the "LanguageIETF" track header element. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvpropedit: IETF BCP 47/RFC 5646 language tags: added an option "--disable-language-ietf" that causes mkvpropedit to apply changes to the "language" track header property only to the legacy language track header element.
mkvinfo: IETF BCP 47/RFC 5646 language tags: added support for the "LanguageIETF" track header element. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
MKVToolNix GUI: multiplexer: added full support for IETF BCP 47/RFC 5646 language tags for both track and chapter languages. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
MKVToolNix GUI: chapter: added full support for IETF BCP 47/RFC 5646 language tags for chapter languages. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
MKVToolNix GUI: header editor: added full support for IETF BCP 47/RFC 5646 language tags for track header languages. The header editor allows editing of the legacy language elements and the IETF BCP 47 language elements independent of each other. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).

Other new features and enhancements

mkvmerge: the chapter generation mode "when-appending" now also works with the splitting modes "parts:" & "parts-frames:" when using the "…,+…" syntax for appending other sections of the source file to the same destination file. Implements #2898 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2898).
MKVToolNix GUI: multiplexer: the file selection dialogs now include the extension ".dtsma" for DTS files. Implements #2901 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2901).
mkvmerge: MP4 reader: sped up parsing MP4 DASH files with a lot of segments ("trun" atoms) quite a bit. Part of the fix of #2900 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2900).
The PCRE2 regular expression library is now used instead of "std::regex" for big performance improvements in all places where regular expressions are used for parsing big chunks of text, e.g. in the subtitle parsers. Part of the fix of #2899 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2899).
all programs: Windows: all programs now support long file names on Windows 10 release 1604 if they're turned on in the registry. Implements #2916 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2916).

Bug fixes

MKVToolNix GUI: preferences: under certain conditions changing the selected entry in the page tree on the left did not cause the page shown on the right to be updated. Fixes #2895 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2895).
mkvmerge: splitting text by a fixed string (e.g. ",") is now done by using "std::string.find()" instead of using a regular-expression-based text splitting function, greatly improving its performance. Part of the fix of #2899 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2899).
mkvmerge: mkvmerge will now read-buffer file I/O when probing text file formats which increases its speed significantly on Windows. Part of the fix of #2899 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2899).
mkvmerge: MP4 reader: fixed handling of "tkhd" atoms of version 1. Fixes #2900 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2900).

Build system changes

The PCRE2 library (the 8-bit variant) is now required.

AYColumbia

7th September 2020, 01:22

Thank you Mosu.

Masutin

18th September 2020, 23:15

1) Can the progress percentage appear in the CLI window title?
2) While lists of MKV files, as contents of storage media, appear in televisions, players, file managers or other interfaces, will attached images show as covers? They didn't in my case but I didn't try newer systems. Is the tag "Cover:Yes" required?

Mosu

19th September 2020, 07:10

1) Can the progress percentage appear in the CLI window title?

No, and I have no intention of implementing something like that.

2) While lists of MKV files, as contents of storage media, appear in televisions, players, file managers or other interfaces, will attached images show as covers? They didn't in my case but I didn't try newer systems. Is the tag "Cover:Yes" required?

From Matroska's side there is no official mechanism to mark attached pictures as cover images. Convention is to name them "cover.[ext]". If and how they're used is up to the software reading the files.

Snowknight26

20th September 2020, 17:20

Just from a usability standpoint, it's no longer possible to select a track in the multiplexer input panel, click language, then quickly type 'eng' (or whatever you choose) for to select the language you want. Instead, you have to click the very small edit button which has a much smaller click area than the input field that used to show in there instead.

What's more interesting is, if you double click on the label next to the edit button, the "Extended subtags" dropdown receives focus and opens, making it even more inconvenient to try to change the language component (you have to close the dropdown, Shift+Tab to go to language, type in the letters, then press enter).

These changes add unnecessary user actions.

Instead, might I suggest keeping the language dropdown visible on the main multiplexer panel (while still having the edit button), allowing one to quickly change languages while still having the option of defining a more specific language tags through the edit button?

Mosu

20th September 2020, 19:21

Instead, you have to click the very small edit button

That's incorrect. You can also click on the text itself. Nearly the whole row reacts to a single click by opening the dialog.

What's more interesting is, if you double click on the label next to the edit button, the "Extended subtags" dropdown receives focus and opens

This is likely due to what I wrote above: the first click of your double-click opens the dialog, and therefore the second click actually ends up in the dialog, not the main window. Easy solution: don't double-click.

Please also note that you can change which parts of the dialog are selected by default in the preferences. If you prefer to use the keyboard, maybe switch the preferences over to having the free-form input selected by default. That way all you have to do is click on the panel, type "en" and press enter.

If you don't double-click, the focus will be on the "language" drop-down initially if the preferences are set to "components", otherwise on the free-form input — meaning you can just start typing right after the dialog's been opened.

Instead, might I suggest keeping the language dropdown visible on the main multiplexer panel

A strong "nope" as that would make for a very confusing user interface if other parts than just the ISO 639 language code being set. And it would make the required validation quite a lot harder to implement (and in case of failures frustrating to users).

And just to preempt a potential followup question: no, I won't make this whole thing configurable via the preferences (so that you could opt back to the old drop-down box without all the other additional controls, without the dialog). That would mean TONS of more code to maintain, more combinations to test extensively, a lot more edge cases and an even more confusing UI for users in case of there being more than the ISO 639 language being set.

The old drop-down isn't coming back.

I'm definitely up to improving the support & UI! Your proposal isn't really an improvement, though, as it comes with a lot of drawbacks.

Mosu

20th September 2020, 20:14

Addon: I've tried hard to design a system that, while offering much more power, requires a minimum of additional clicks. I'm very much aware users don't like having to click more. From a design perspective I had to balance the following requirements:

The user should be able to use the full feature-set that BCP 47 language tags offer.
For users not familiar with BCP 47: the language tag should be easy to construct with a lot of help from the program.
Users intimately familiar with BCP 47 should be able to quickly input a valid BCP 47 language tag without having to hunt through multiple combo boxes.
The displayed language tag should be human-readable (e.g. "English" instead of "en").
The displayed language tag should still offer the full information about all of its components.
The new controls should ideally fit into the same space the existing controls were occupying, if at all possible without making the dialog any wider.
After swapping out the old for the new controls the interface should not be much more confusing than it was before.
The number of mouse clicks required for the most-often executed operation (changing solely the language code) should ideally not increase, or if it has to increase, as little a possible.
The new controls should be usable solely with the keyboard.
The user interface should not accept invalid language tags.

Of course several of those requirements conflict with each other.

Why am I writing this? To underline that I _have_ taken those concerns into consideration. I'm not just willfully making users' lives harder.

Snowknight26

22nd September 2020, 03:06

This is likely due to what I wrote above: the first click of your double-click opens the dialog, and therefore the second click actually ends up in the dialog, not the main window. Easy solution: don't double-click.

You're right. It just so happened that when clicking once, the Edit language window appeared such that the 'Extended subtags' dropdown was exactly where the mouse cursor was, so naturally a 2nd click would focus on it instead.

That was simply a false assumption on my part.

And just to preempt a potential followup question

Well surprise surprise, I didn't have follow-up questions. :p I suppose my only complaint is that from a UI/UX perspective, it's not normal for a text label to be an actionable element (meaning clicking it does something).

Minor bug though:

Open MKVToolNix GUI
Click Add source files
Select a file with chapters
Click on the chapters in the "Tracks, chapters and tags" panel
Click "<Do not change>" next to Language in the Properties panel
Change any parts of the language
The new language option is reflected in the Properties panel
Click on a different track in the "Tracks, chapters and tags" panel
Click on the chapters in the "Tracks, chapters and tags" panel
Language settings are not preserved (naturally, since you shouldn't be able to change the language for chapters?)

Mosu

22nd September 2020, 08:55

I suppose my only complaint is that from a UI/UX perspective, it's not normal for a text label to be an actionable element (meaning clicking it does something).

That's true, of course. That's why it isn't the only way to open the dialog & why the edit button is present, consistent with edit buttons in several other locations in MKVToolNix GUI. That the text label accepts a click, too, is purely for convenience & ease of use.

Maybe I'll change the visuals somehow to signal interactivity (similar to URIs are underlined & displayed in a different color).

Click on the chapters in the "Tracks, chapters and tags" panel
Click "<Do not change>" next to Language in the Properties panel

Ooooh, right. That shouldn't happen. From mkvmerge's perspective you cannot change the language of chapters & tags; therefore the GUI shouldn't allow you to change the language for those entries. It didn't before v50, and the edit button in v50 is disabled correctly, but the click on the text is still accepted. I'll fix that. Thanks.

SeeMoreDigital

22nd September 2020, 09:48

With regard to adding chapters...

Is there any particular reason why the supported 'chapter file' types can't be dragged and dropped into the GUI's main window, instead of always having to visit the 'Output tab'?

Mosu

22nd September 2020, 16:52

Is there any particular reason why the supported 'chapter file' types can't be dragged and dropped into the GUI's main window, instead of always having to visit the 'Output tab'?

Huh? You _can_ drag & drop chapter files onto the "input" tab. The GUI will recognize dropped chapter files & automatically insert their file name in the corresponding control in the output tab. It'll even show a helpful popup message explaining what it just did & why it did it.

If you don't see that popup, you've opted not to see it again earlier (there's a checkbox in the popup for that).

The reason chapter files aren't treated the same way other source files is that mkvmerge simply doesn't handle them the same way. I might change that someday, but it'd be quite a bit of work for, honestly, not even that much of a increase in convenience, never mind that it wouldn't actually enhance or extend existing features.

SeeMoreDigital

22nd September 2020, 18:00

If you don't see that popup, you've opted not to see it again earlier (there's a checkbox in the popup for that)...How odd then!!!

A few days ago I used gMKVExtract GUI v2.5.2.0 to demux some chapters as an 'chapters.ogm.txt' file. And when I tried dropping them into MKVToolNix GUI I received this message: -

https://i.ibb.co/C75qw8L/Chapters.png

...And the chapters did not appear :eek:

Edit: I think I know what's happened now. The 'chapters.ogm.txt' file has been loaded and it appears under the 'Output' (Chapters) tab. But they don't appear within this box as being loaded: -

https://i.ibb.co/2kxqyXh/Box.png

Mosu

22nd September 2020, 18:27

Edit: I think I know what's happened now. The 'chapters.ogm.txt' file has been loaded and it appears under the 'Output' (Chapters) tab. But they don't appear within this box as being loaded:

Chapters appear in that box only if they're part of one of the source files (e.g. inside Matroska or MP4 files or MPLS playlists) in the upper box. As I said earlier, pure chapter files are not regular source files, though, and don't appear there.

I know, somewhat confusing, due to design decisions in the early days, not trivial to change, might be changed one day, but don't hold your breath :)

SeeMoreDigital

22nd September 2020, 18:40

I know, somewhat confusing, due to design decisions in the early days, not trivial to change, might be changed one day, but don't hold your breath :)Yeah, it is somewhat confusing. But at least I now know that they are in there ;)

EDIT: It's rather incredible that you first released your application way back on the 30 April 2003 and continue to regularly issues updates...

hubblec4

25th September 2020, 11:44

Hi Mosu

I want mux an mkv from a BD, and when I set the "--disable-language-ietf" flag there is no language for the video track.
Audio and subtitle tracks have the "normal" 3-letter-language code.

Mosu

27th September 2020, 16:41

there is no language for the video track.

Where exactly do you mean?

SeeMoreDigital

27th September 2020, 19:53

there is no language for the video track.
Out of interest... What's the purpose of assigning a language to a video track?

Mosu

27th September 2020, 21:23

Out of interest... What's the purpose of assigning a language to a video track?

The problem is with the Matroska specs in this particular case: the old Language element is both mandatory and has a default value of "eng". The effect is that there's no way NOT to assign a language to a track: if no language element is found, a reader must use the default value "eng" instead. Yes, that's one of the two design decisions we would definitely change if we redesigned the container.

From a semantic point of view it isn't that much of a problem as there's the code "zxx" = "No linguistic content; Not applicable" that can be used to signal that the video track does indeed not have any linguistic content.

VBB

28th September 2020, 01:41

What about "und" (undetermined)? That seems to work just fine when assigned to a video track, and it doesn't show as anything in MediaInfo.

Mosu

28th September 2020, 08:04

Semantically speaking "und" means that there is linguistic content, you just don't know which language it actually is. How players treat "undetermined" is not up to Matroska/MKVToolNix, and I bet it isn't uniform across players either.

hubblec4

28th September 2020, 12:00

Where exactly do you mean?

I forgot that no language element is written if the language is "eng".

hubblec4

28th September 2020, 12:39

Out of interest... What's the purpose of assigning a language to a video track?

This is maybe not important, but a video from an USA production looks different to Chinese production.

I have some movies where the original is produced in Sweden and Hollywood had make a remake of this movie.
There are a lot of scenes where signs in Sweden language -> newspaper articles or shop advertisement and others.

SeeMoreDigital

28th September 2020, 18:37

This is maybe not important, but a video from an USA production looks different to Chinese production.Hmmm...

But surely such sources would not arrive to you muxed within the Matroska container. They would be identified in a different way!

Do transport container and mp4 muxers offer a video language option?

Mosu

28th September 2020, 20:21

Do transport container and mp4 muxers offer a video language option?

MP4 does provide a language for all tracks in the "mdhd" atom, no matter the track's type.

MPEG transport streams do not have a language field in general. Certain track/codec types do have a language coded somewhere in their codec-specific initialization data, e.g. teletext or the generic subtitle PMT descriptors. However, MPEG transport streams as used on Blu-rays are always accompanied by clip information files ("CLIPINF/*.clpi"). Those files do contain a language field for all tracks, no matter their type, but for video tracks it's often empty.

NanoBot

29th September 2020, 00:20

Out of interest... What's the purpose of assigning a language to a video track?

I use the language tag of the video track to indicate the language of the opening credits, end credits and hardcoded subtitles.

Another possibility: Think of Star Wars, there the language tag could be used to indicate the language of the intro.

netmask

29th September 2020, 06:54

I don't support Windows 7 anymore.
Which is the latest version tat does support Windows 7 64bit Professional?

jpsdr

29th September 2020, 17:46

For me, the last (50.0.0) works on Windows 7 x64. By this, i think he means that he will not investigate any issue if you're under Windows 7. If it works, good for you, otherwise, too bad... :(

netmask

29th September 2020, 21:38

Thanks..

Mosu

4th October 2020, 12:51

Hello everyoone,

I've just pushed out MKVToolNix v51. As expected the new IETF BCP 47 language tag functionality introduced in v50 had a couple of bugs, which I've fixed in v51. Apart from that I've also started fuzzying mkvmerge, which turned up several issues that have also been fixed. Fuzzying will continue in the future and I fully expect a lot more bugs to be unearthed by it.

Important news for package managers is that `configure` can now detect and use a system-wide installed copy of the JPCRE2 header library. If it isn't found, the bundled version will be used (just like in v50).

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 51.0.0 "I Wish" 2020-10-04
New features and enhancements

mkvmerge, mkvpropedit, MKVToolNix GUI: IETF BCP 47 language tags: added missing support for UN M.49 regions for which there are no corresponding ISO 3166 alpha codes. This enables language tags such as "es-419" = Spanish in Latin America and the Caribbean. Implements #2919 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2919).
MKVToolNix GUI: IETF BCP 47 language tags: the text in the widget displaying the current language & the corresponding edit button is now displayed like a link (depending on the theme: different color & underlined), making it clearer that not just the edit button can be clicked but the text, too.

Bug fixes

mkvmerge: AV1 parser: fixed mkvmerge crashing after uncaught exceptions due to certain data conditions. Found by fuzzying.
mkvmerge: AV1 packetizer: the duration of frames wasn't set properly. When appending AV1 IVF or OBU files this meant that the last frame of the Nth file and the first frame of file N+1 had the same timestamp. Fixes #2937 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2937).
mkvmerge: DTS reader: fixed handling of buffers with an odd length when byte-swapped DTS is detected so that mkvmerge doesn't abort with a failed assertion. Found by fuzzying.
mkvmerge: h.264/AVC and h.265/HEVC elementary stream readers: mkvmerge will no longer claim to recognize data that looks like AVC or HEVC but with invalid video width/height values as that lead to failed assertions in libEBML later. Found by fuzzying.
mkvmerge: h.265/HEVC parser: fixed mkvmerge aborting after uncaught exceptions due to certain data constellations found by fuzzying.
mkvmerge: IVF reader: fixed mkvmerge crashing with a "division by zero" error due to certain data conditions. Found by fuzzying.
mkvmerge: fixed mkvmerge aborting with a "division by zero" error due to the timestamp scaling factor being 0 after handling certain data constellations found by fuzzying.
mkvmerge: track statistics: fixed a "division by zero" error when the content's shorter than 1ms. Found by fuzzying.
mkvmerge, mkvinfo, mkvextract, mkvpropedit: Matroska access class: fixed an invalid memory access under certain data conditions. Found by fuzzying.
MKVToolNix GIU: IETF BCP 47/RFC 5646 language tags: the GUI will no longer open the language dialog when clicking on a disabled language display widget.
MKVToolNix GUI: IETF BCP 47 language tags: the "variants" combo-boxes were not populated even when the language tag was valid and contained at a variant. Fixes #2923 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2923).
MKVToolNix GUI: IETF BCP 47 language tags: when no language is selected, at least one of the other components (extended subtags, region, or variants) has something selected and "private use" is not empty, the GUI would claim this to be a valid tag, which it isn't. Fixes #2924 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2924).
MKVToolNix GUI: multiplexer: when the tracks/chapters/tags selection changes from "at least one entry selected" to "no entry selected", the input controls will be reset to their default state and not just disabled. Fixes #2927 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2927).

Build system changes

"configure" now checks for the presence of the a system-wide installed copy of the JPCRE2 C++ wrapper library for the PCRE2 library and uses that if it's new enough (at least v10.32.1). If not, the bundled version will be used as a fallback. Implements #2929 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2929).

Have fun!

VBB

4th October 2020, 18:51

Thanks Mosu! I use your software almost every day. Shout out to Braunschweig from a former Frankfurter :D

LeMoi

14th October 2020, 10:38

Thanks for the latest updates.
Is there a way to have the possibility to choose between the old and the new language selector ? The old way (scrolling menu) was way more practical, it needed less clics, I can understand that it doesn't bother some people (maybe some asked for it ?!), but it's more complicated than it was... maybe we could choose between something like "easy mode" and "complete mode".

Mosu

14th October 2020, 11:18

Please see this FAQ section (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix#the-old-user-interface-is-not-coming-back) where I answer your question.

hubblec4

14th October 2020, 11:54

When 1000 user says this new language system is not good to use, I guess you are more willing to change/bring back the old language system.
For me personal is the IETF language a pain and not easy to use in MTX.

Mosu

14th October 2020, 13:07

At the moment I actually have more positive feedback (people that are glad they can finally be more precise wrt. to languages) than negative on the change.

LeMoi

15th October 2020, 23:38

I understand that, even if I disagree (the list was pretty complete, and the 3-char code was more precise, and it needed one click less ^^), that's why I wondered if there a way to have the choice between the new and the old method

Mosu

16th October 2020, 08:34

the list was pretty complete

Well, you couldn't differentiate between things such as "Portuguese as spoken in Brazil" vs. "Portuguese as spoken in Portugal" (which is quite different), nor could you mark subtitles with "Serbian in Latin" vs "Serbian in Cyrillic" with the old system. It was far from complete. Sure, it seems to have been enough for you and your use case, but you and your use case aren't everyone else's.

and the 3-char code was more precise

This part of your sentence I don't understand at all. BCP 47 language tags use the same ISO 639 language codes the old system used. The only difference is that the old Matroska system only used the three-letter codes whereas BCP 47 says that the two-letter code should be used if there is one available for a given country, and if not to use the three-letter code. There's nothing being more or less precise about this; the ISO 639 code list contains three-letter codes for all countries and two-letter codes for a lot (but not all) others.

As a matter of fact: the old Matroska system only supported languages from the ISO 639-2 standard. However, there have been extensions of that list with ISO 639-3 and 639-5, which the old Matroska standard did not support. BCP 47 does support those (MKVToolNix doesn't yet, though I'm going to implement them soonish).

Atak_Snajpera

23rd October 2020, 16:02

What am I doing wrong here?
https://i.postimg.cc/sfJxVFf0/Untitled-1.png

sneaker_ger

23rd October 2020, 18:52

Try
mkvmerge "@options.json"

Atak_Snajpera

24th October 2020, 11:42

Still the same error. Is there anybody who uses json configuration file with success? BTW. Yes my file is detected by notepad++ as ANSI as UTF-8. The same problem in v51 as well.

sneaker_ger

24th October 2020, 12:09

Is there anybody who uses json configuration file with success?
Yes. Working fine with mkvmerge v51 as long as I don't forget the "@".

Atak_Snajpera

24th October 2020, 12:30

Could you show me some screenshots? Obviously I must be doing something...

sneaker_ger

24th October 2020, 12:42

:confused:
https://i.imgur.com/cIFBYb7.png

Atak_Snajpera

24th October 2020, 13:09

:confused:
https://i.imgur.com/cIFBYb7.png

Does it also work if you run that command from .cmd/.bat file?

https://i.postimg.cc/635P8JMJ/Untitled-1.png

By the way. Is there any logical reason why the method of loading option file is "over engineered/unusual". Why not something simpler like
mkvmerge --options "MyOptions.txt"
or even better
mkvmerge "MyOptions.txt"

Why do we have to use that @ symbol?

sneaker_ger

24th October 2020, 13:20

Move the "@" to the front of the absolute path.

Atak_Snajpera

24th October 2020, 13:24

Move the "@" to the front of the absolute path.

Thanks! That works! Jesus...

Mosu

24th October 2020, 19:06

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

24th October 2020, 20:00

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

25th October 2020, 11:08

@ 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

25th October 2020, 11:30

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

25th October 2020, 12:04

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

25th October 2020, 12:45

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

9th November 2020, 16:13

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

9th November 2020, 17:41

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

9th November 2020, 17:44

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

9th November 2020, 18:00

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

9th November 2020, 18:23

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

12th November 2020, 13:08

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

12th November 2020, 13:50

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

12th November 2020, 14:27

DragonQ

12th November 2020, 15:46

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

12th November 2020, 18:08

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

13th November 2020, 12:03

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

13th November 2020, 12:49

olli66

13th November 2020, 13:25

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

14th November 2020, 12:20

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

15th November 2020, 06:03

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

16th November 2020, 19:30

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

16th November 2020, 19:35

--ui-language en

mariner

19th November 2020, 11:04

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

6th December 2020, 18:40

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

6th December 2020, 18:42

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

6th December 2020, 18:45

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

6th December 2020, 20:15

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

7th December 2020, 04:55

quietvoid

7th December 2020, 14:30

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

22nd December 2020, 21:24

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

23rd December 2020, 12:33

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

23rd December 2020, 13:01

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

27th December 2020, 19:42

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

3rd January 2021, 19:12

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

Mosu

4th January 2021, 23:08

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

5th January 2021, 01:23

Thank you again for all your work.

VBB

5th January 2021, 02:20

Thanks as always!

DragonQ

5th January 2021, 13:13

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

5th January 2021, 15:43

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

6th January 2021, 12:59

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

6th January 2021, 13:44

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

6th January 2021, 14:27

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

6th January 2021, 16:05

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

6th January 2021, 16:32

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

6th January 2021, 16:47

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

6th January 2021, 16:57

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

6th January 2021, 19:47

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

stax76

6th January 2021, 20:02

@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

24th January 2021, 14:52

Mosu

24th January 2021, 19:49

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.

In the GUI's preferences you can configure it to use a default languages for tracks that don't have such a property, or even for those whose language property is "und": "Preferences" → "Multiplexer" → "Default values" → "Default track languages to set". You can configure it per track type (mostly for handling video tracks differently than audio & subtitle tracks). This setting is evaluated whenever you add new files to multiplex settings.

If you want to modify existing files, you can look into scripting mkvpropedit to change the properties of existing tracks. This automation example (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Automation-examples#example-2-remove-default-track-flag-from-all-subtitle-tracks) does something very similar and can serve as a basis for your own script.

If scripting isn't your thing, there's also JMkvpropedit (https://github.com/BrunoReX/jmkvpropedit), though I've never used it myself and cannot attest to its suitability to your problem.

Mosu

30th January 2021, 16:42

Heydiho,

trying to keep up my usual schedule in 2021 of about four to five weeks between releases. This time it's even a bit less than four weeks. Several bug fixes and small enhancements were made.

There have been no changes for package maintainers.

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

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

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

Version 53.0.0 "Fool's Gold" 2021-01-30
New features and enhancements

mkvmerge: AVI reader: added support for reading the video aspect ratio from the video properties header ("vprp" chunk) if present and setting the display dimensions accordingly. Implements #2993 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2993).
mkvmerge: MP4 reader: for h.264/AVC tracks that don't have an "AVCConfigurationBox" ("avcC" atom) in their sample description ("stsd") atom or whose "avcC" atom contains no content "mkvmerge" will now re-derive the "AVCConfigurationBox" from the bitstream. Implements #2995 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2995).
mkvextract: mkvextract will now check if any of the destination file names is the same as the source file name and abort with an error if that's the case. Implements #3001 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3001).
MKVToolNix GUI: when querying the user for a file name for saving things (e.g. multiplexer settings or an attachment in the header editor), the automatically suggested file name will now be based on the situation-specific file names (e.g. the destination file name for multiplexer settings or the attachment's name when saving an attachment in the header editor) instead of the directory's name. Implements #3012 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3012).
MKVToolNix GUI: multiplexer: when deriving track languages from file names the GUI will now select the right-most match instead of the left-most one. For example, "La.vie.en.rose.(fr).srt" will now be detected as French (fr) instead of English (en). Implements #3013 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3013).
MKVToolNix GUI: preferences: the items in the "pre-defined …" lists can now be renamed by double-clicking with the mouse or pressing the F2 key.
Windows installer: the "bluray_dump" command-line utility will be installed into the "tools" sub-directory. "bluray_dump" can read & dump certain file types used on Blu-rays: ".mpls" playlists, ".clpi" clip information databases, ".bdmv" index files, "bdmt_….xml" disc library databases and "tnmt_….xml" track & chapter name databases.

Bug fixes

mkvmerge: stretching chapter timestamps with "--chapter-sync" now works correctly with floating point values including fractions of floating point numbers (e.g. "12.3/45.67"). The tooltips in the GUI have been adjusted accordingly. Fixes #3002 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3002).
mkvmerge: MPEG 1/2 video handling: the "default duration" header field was often half the value it actually should be, resulting in all video frames having an explicit block duration with the correct value. This has been fixed with a patch by Tom Yan.
mkvmerge: MPEG 1/2 video handling: the data stored in "Codec private" and "Codec state" doesn't contain extensions other than sequence & sequence display extensions anymore. Fix by Tom Yan.
mkvmerge: tag handling: when remuxing a Matroska file with the "--no-track-tags", existing "SOURCE_ID" track tags are now skipped, too.
MKVToolNix GUI: multiplexer: the drop-down boxes with pre-defined track names now follow the order set in the preferences instead of sorting the entries alphabetically. Fixes #2999 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2999).

Have fun :)

hubblec4

30th January 2021, 23:11

Hi Mosu

Bug fixes

mkvmerge: MPEG 1/2 video handling: the "default duration" header field was often half the value it actually should be, resulting in all video frames having an explicit block duration with the correct value. This has been fixed with a patch by Tom Yan.

What a lucky coincidence. I got yesterday the Star Trek Voyager DVD's and had muxed the episodes from DVD 1.

With the new MTX version, I can confirm for the video frames is no longer a BlockGroup used.

I was always wondering why the "default duration" header field shows the half and in the BlockGroup shows the block duration the correct value.

Bug fixes

mkvmerge: MPEG 1/2 video handling: the data stored in "Codec private" and "Codec state" doesn't contain extensions other than sequence & sequence display extensions anymore. Fix by Tom Yan.

In the mkv's muxed with MTX 52 there are "Codec state" elements which now not anymore present.
This data was really superfluous?

Mosu

30th January 2021, 23:23

In the mkv's muxed with MTX 52 there are "Codec state" elements which now not anymore present.
This data was really superfluous?

Yes. A "codec state" says that the initialization data from that state element is to be used instead of "codec private" from the point where the state element occurs in the file.

All the change does is removing the very first state element if and only if its content is the same as the private element. Semantically nothing changes by leaving out that particular state element.

hubblec4

30th January 2021, 23:43

Fine. I'm glad to have this improvement now.
The file size is round about 700kb smaller. For 178 episodes it is more than 100mb.

stax76

4th February 2021, 17:36

staxrip always re-muxes mkvextract extracted AAC files to M4A using MP4Box, but is this necessary or do the AAC files contain all important metadata?

There is currently a discussion here:

https://github.com/staxrip/staxrip/issues/489

Mosu

4th February 2021, 22:25

ADTS AAC files only include as much information as necessary for decoding. Extracting to it loses quite a lot of meta data, of course, such as the timestamps or user-supplied data such as track names, tagging, chapter information. Most of those could be stored in MP4, but they don't survive the .mkv → .aac step.

Or to put it differently: the .aac → .mp4 step cannot invent metadata that isn't present in the .aac already.

So no, .mkv → .aac → .mp4 doesn't make much sense. One exception would be to feed the .mp4 to programs that don't support ADTS AAC files.

If you want to keep more metadata intact, you'll have to use other applications that support reading Matroska and writing MP4 files. An obvious one is ffmpeg, another choice might be the gstreamer framework (no idea if that offers more than what libavformet does, though).

Edited to add: mkvextract doesn't support extraction of 7.1 AAC to ADTS AAC files at the moment due to a more or less easily fixed but. Other channel configurations (7.0, 8.0 and more than 8 channels in general) aren't suported at all. The reason is that things get somewhat dicey with ADTS AAC files and the higher channel counts; the stream will have to contain a program_config_element to signal the higher channel count. mkvextract cannot generate said program_config_element at the moment.

pson80

5th February 2021, 03:55

I'm trying to figure out how to use the 'Directory relative to first source file's directory'-setting but can't find any info about it other than this post (https://forum.doom9.org/showthread.php?p=1861871#post1861871) that just says it now remembers your setting and there's nothing in the FAQ or documentation either. Maybe it's so obvious for the most you of that it isn't needed :D

Maybe it isn't even possible to do what I want to do anyway.
I would like to set the output directory to Y:\CurrentJobName (remote server) if the input is located locally in D:\Incoming\CurrentJobName. Is that doable or am I stuck to changing it manually every time?

Mosu

5th February 2021, 09:42

That scheme isn't supported by MKVToolNix GUI. What "parent directory" means is: same drive, one directory up. For example, if the first file is located in "D:\Some\Where", the destination file name will be set to "D:\Some".

Nejiro

9th February 2021, 08:56

Hello everyone, I am using version 53.0.0 on Ubuntu 20.04 lts and I cannot merge two files, I get the error that a file cannot be merged with itself, this is the first time this happens to me and I don't know how Obviously they are two compatible files and it is an operation that I have done many times, I load the first file then with the function "append to an existing source file" I put the second file, only I get this error ... .... I hope someone can help me.
Thank you

Mosu

9th February 2021, 12:13

This happens mostly when the appended files has more tracks than the file it's being appended to. In that case the GUI cannot really find a good place where to place the superfluous tracks, and it ends up laying them out in way that the superfluous tracks would be appended to the last non-superfluous track of the appended file.

You'll have to deactivate those appended tracks for which there's no corresponding track in the file they're appended to.

Example: Let's assume your first file contains one video, one audio track, and that your second file (the one you're trying to append to) contains one video, one audio and one subtitle track. In such a setup the GUI will set up things this way by default:

the video track from file 2 will be appended to the video track from file 1
the audio track from file 2 will be appended to the audio track from file 1
the subtitle track from file 2 has no corresponding track in file 1, but it must be placed _somewhere_; in this case it'll likely be appended to the audio track from file 1, to which the audio track from file 2 is already appended

In that case you'd have to deactivate the subtile track from file 2.

Nejiro

9th February 2021, 12:40

I apologize but it was my mistake, the two files did not have the same audio tracks, I fixed and now everything is fine.
Thank you

odino

12th February 2021, 04:39

Hi Moritz,
I have a question on stretching chapters. I have subtitles and chapters from an old mkv file @ 23.976 and the new on is 24fps. I can stretch the subs to perfectly match by stretching it by 0.999 but if I do the same for the chapters they all end up as 0s. I had first extracted it as XML and added it via "Chapter file". Additionally: is there any reason one cannot delay the chapters directly from the properties tab rather than extracting it, re-adding it and then adding a delay in the Chapters section?

It would also be helpful if you could give some examples of the stretching in the wiki you wrote about avoiding to stretch audio? E.g. 23.976fps->24fps, 25fps -> 23.975 and so on. https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Stretch-or-shrink-audio-tracks
I tried to look everywhere for help on this but didn't find any examples.

Lastly, your contact page is still linking to the old forum post: https://mkvtoolnix.download/community.html

Thank you.

Mosu

12th February 2021, 14:35

mkvmerge treats chapters completely differently than regular tracks. This means that all calculating operations on chapters are pretty hacky and not tested well.

Use the chapter editor, open the chapters, right-click on the top-most item, select "Additional modifications" from the popup menu, enable "Multiply start and end timestamps…". Calculate 23.976/24 and enter the result in the dialog.

I'm not keen on giving a lot of examples. It's better to understand what you're doing/what you're calculating, 'cause then you don't have to look for the exact example matching your current use case, but you can calculate it yourself. If your original video track plays at x FPS, and your new one at y FPS, then the factor to use is always x/y. If you're going from 23.976 FPS to 24 FPS you play _more_ frames per second meaning same number of frames will result in a _shorter_ video meaning the resulting factor for adjusting other tracks to the new rate must be < 1. That's your check to see if you swapped the two values.

I'll fix the link. Thanks.

Mosu

12th February 2021, 14:38

Addendum: which MKVToolNix version are you trying the chapter sync with? 'cause there was a pretty important fix in v53 for --chapter-sync.

I also just tried the following:

mkvmerge -o out.mkv --chapter-sync 0,0.999 in.mkv

with v53 and the resulting chapter timestamps in out.mkv are just; they're exactly the original timestamps * 0.999.

Perenista

14th February 2021, 03:48

*******
PnS Rotate Y- flips horizontally
*******

I noticed a video I have here needs me to apply this MPC-HC feature, which also doesn't seem to work with madVR, only Enhanced Video Renderer. Alt + num 6 will do the trick.

I was wondering if it's possible to apply this without reencode, and using MKVToolnix. The file is a Matroska.

Or perhaps a lossless change as suggested here:
https://stackoverflow.com/questions/25031557/rotate-mp4-videos-without-re-encoding

However this one only applies to MP4.

Barabba

17th February 2021, 17:11

Hi, I?ve some mp4 produced by an Hikvision DVR that I want to join.. they are without timestamps, as the the recorder don't care do well pack the mp4 before close it, so it's up to the software solve this problem. Avidemux doesn't accept these files, so I try to join to mkv but the result isn't so good, half of the video is "masked/corrupted" and it appears only when people are passing by it. I attach 2 files here, maybe they can be helpful to solve the problem, if possibile.Thanks
https://drive.google.com/file/d/1WIwtbO7VYG_7SoXzzY6AfM6Vylxzos23/view?usp=sharing

PS: if you may suggest me a way to correct the problem, maybe a command line with ffmpeg, I'll be glad to try. Thank you!
PS2: I've the latest version 53

EDIT: I can solve the error in files using this command: ffmpeg -err_detect ignore_err -i 1.mp4 -c copy output.mp4
I suppose you use ffmpeg too to manage and merge mp4 files, may you please introduce che chance to apply a ffmpeg command to any input file boefore processing? It would be great to have a batch/gui interface to do that.. thanks

stax76

19th February 2021, 10:47

I think there is a Unicode issue:

mkvextract .\unicode-🙂.mkv tracks 1:.\unicode-🙂.aac

Error: Unknown mode '.\unicode-🙂.aac'.

Mosu

19th February 2021, 21:27

I think there is a Unicode issue:

Thanks, that should be fixed now.

stax76

20th February 2021, 20:57

Thanks! :thanks:

Mosu

26th February 2021, 20:23

Heya,

again I'm releasing a bit early, not even four weeks after the previous one. This release, however, does pack quite a bit more of a punch than the previous ones, both in terms of enhancements and bug fixes. On top of that one of the libraries used (libEBML) has just been released fixing several heap overflow bugs, and I didn't want to wait too long to get those fixes into a new MKVToolNix release.

There have been several changes concerning package maintainers. Please refer to the NEWS below for details.

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 54.0.0 "F Maj Pixie" 2021-02-26
New features and enhancements

mkvmerge: added support for using ISO 639-3 language codes in IETF BF47 language tags. Part of the implementation of #3007 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3007).
mkvmerge: AC-3 parser: added support for byte-swapped AC-3 data. Implements #3022 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3022).
mkvmerge: Matroska reader: for audio tracks that have the bit depth track header set mkvmerge will now keep that header even for codecs that don't require it for decoding. Implements #3009 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3009).
mkvmerge: MPEG transport stream reader, PCM audio tracks: mkvmerge will now re-order the channels for 5.1, 7.0 and 7.1 channel tracks from the Blu-ray layout to the WAVEFORMATEXTENSIBLE layout expected in Matroska. Patch by Tom Yan. Implements #2988 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2988).
mkvmerge, mkvinfo, mkvpropedit, MKVToolNix GUI: added support for the following new track header elements: "hearing impaired" flag, "visual impaired" flag, "text descriptions" flag, "original" flag, "commentary" flag. Implements #3011 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3011).
MKVToolNix GUI: added support for using ISO 639-3 language codes in IETF BF47 language tags. As there are several thousand of them, they're deactivated by default and must be activated in the preferences ("GUI" → "Often used selections" → "Languages"). Part of the implementation of #3007 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3007).
MKVToolNix GUI: multiplexer: when adding Blu-rays the user can select multiple playlists to add simultaneously in the "select playlist to add" dialog. Implements #2961 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2961).
MKVToolNix GUI: multiplexer: the file name extensions "eb3" and "ec3" were added for Dolby Digital Plus & "mpl" for Dolby TrueHD in the file dialogs. Part of the implementation of #3027 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3027).
MKVToolNix GUI: multiplexer: when adding multiple files the dialog asking the user what to do with them has gained a new checkbox. If enabled, all files containing at least one video track will always be placed in newly created multiplex setting. Implements #2966 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2966).
MKVToolNix GUI: multiplexer: added a menu entry in the "Multiplexer" for adding all files that are currently in the clipboard. Implements #3006 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3006).

Bug fixes

all: Windows: fixed compatibility with gettext 0.21 and newer on mingw.
all: Windows: fixed several of the programs having problems with certain Unicode characters (primarily emojis) in file names (e.g. mkvextract wrongfully complaining about an "invalid mode" or the GUI not being able to find parts of Blu-ray file structures).
mkvextract: AAC: fixed wrong channel mask field in the ADTS headers for 7.1 channel layouts. Fix by Tom Yan. Fixes #2636 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2636).
mkvextract: h.265/HEVC extraction: if the first frame starts with the parameter sets (SPS, PPS & VPS), the ones from CodecPrivate aren't written and the ones from the first frame are kept. Fixes #3031 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3031).
mkvmerge: fixed the calculation of chapter timestamps read from NTSC DVDs. Fix by Tom Yan.
MKVToolNix GUI: IETF BCP 47 language widget: the language combo box will now always contain the language code the user enters in the free-form field, even if it isn't in the list of often-used languages the user configured in the preferences.
MKVToolNix GUI: multiplexer: when browsing for the destination file name the default directory is now chosen according to the preferences regarding how the destination file name should be formed. For example, if the policy is set to "fixed output directory" then that output directory will be the one initially set when the directory selection dialog is opened. Fixes #3021 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3021).
MKVToolNix GUI: multiplexer: fixed the removal of appended source files if the "delete source files" end-of-job action is enabled. Fixes #3029 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3029).
MKVToolNix GUI: chapter editor: when importing chapters from DVDs the IETF BCP 47 language elements will be set, too, not just the legacy language elements.

Build system changes

libEBML v1.4.2 and libMatroska v1.6.3 are now required. The optional, bundled copies of both libraries have been updated to those versions. This bump in requirements fixes several heap overflow bugs in libEBML.
MKVToolNix is now using the C++17 library feature "file system library" instead of Boost's "file system" and "system" libraries. For the GNU Compiler Collection (gcc) libstdc++ this means v8 or newer is required; for clang's libc++ it means v7 or newer. For macOS this means that provided disk image will only run on 10.15 "Catalina" or newer.

Have fun :)

manolito

26th February 2021, 21:36

Thanks for the new version... :D

I found one small issue (using the 32-bit portable version under Win7-64):
After overinstalling over the previous version keeping the old INI file the program always hangs when trying to open a file via right-click in the source window. Drag and Drop with Explorer works.

What fixed it was deleting the old INI file and reentering my settings. Must be some inconsistency with the INI entries between the old and the new version. No big deal...

Mosu

26th February 2021, 21:40

Too bad you removed the file. I would surely have liked to take a look at the issue, but without… Well.

manolito

26th February 2021, 22:24

Just repeated the installation on another ThinkPad with almost identical setup. No problems with this one, and I believe it has something to do with the font size setting.

The laptop which had no issues uses a font size of 100%. The other one which had the issues has a higher resolution screen and uses a font size of 125% (my eyes getting a little old). And this bigger font size made the difference.

//EDIT//
Oh damn, I mixed it all up...
The laptop which had the issue also uses a display setting of 100%. What I did to improve readability was to reduce the screen resolution from the native 1600x900 to a smaller resolution of 1360x768. This usually does not cause problems, but the Qt library might behave differently.

//EDIT2//
If you still want to look at my previous INI file, I do have Rollback RX installed so I can easily retrieve the old INI file and upload it. Let me know...

Mosu

26th February 2021, 23:04

Yeah, I don't support such low resolutions. The GUI has certain minimum required sizes that depend on the active language (as labels, combo box contents etc. have different lengths in different languages). There will be weird interactions if the automatically stored/remembered frame positions & sizes don't fit into the screen anymore and similar things. Nothing I want to spend time on.

manolito

28th February 2021, 01:37

Still a little bit weird...

The laptop which has no problems has a screen resolution of 1280x800. The other one which showed the problem has a resolution of 1360x768. This is in the same ballpark for me, and both resolutions are certainly HD resolutions.

So I don't really understand why one of these screen resolutions works and the other does not... :confused:
Well, at least it does work after deleting the INI file, so no real problem...

ryrynz

28th February 2021, 06:37

Still a little bit weird...

Attempt recovery of the ini imo.

DavidRyan

1st March 2021, 17:24

Hi - Thanks for the continued development of this very useful tool.

Wanted to add that I have the same issue as reported above with v54.0. I usually open sources via the 'Add source files' button but doing that in this version results in the application hanging and having to be killed. Folders/sources don't appear, it just hangs. This is on a laptop with a 1920*1080 display with text/apps display set to 125% if that matters, saw it mentioned above.

I can still use mkvtoolnix by dragging and dropping sources. And I guess a clean install may resolve the issue if that worked for others. But before I do that if you want me to send in the configuration settings file let me know.

kuchikirukia

2nd March 2021, 02:46

I used to be able to cut off audio/sub tracks that ran longer than the video with the split function. This no longer works.

>have 22:09 video
>audio and sub tracks are 23:40 because they have an ending I cut from the video
>set to split after 22:09
>Doesn't split.

Mosu

2nd March 2021, 12:31

Wanted to add that I have the same issue as reported above with v54.0. I usually open sources via the 'Add source files' button but doing that in this version results in the application hanging and having to be killed.

Can you please do two things:

Upload your settings file (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Location-of-settings,-job-queue,-cache-folder) to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server). Include your user name in the file name (or create a directory with your name) so I can associate it with you.
Get the latest continuous build (https://mkvtoolnix.download/windows/continuous/64-bit/54.0.0/) and give that one a try. I've fixed several issues over the last couple of days that may very well be the cause of what you observed. Try this without deleting the settings file first.

Thanks.

Mosu

2nd March 2021, 12:34

I used to be able to cut off audio/sub tracks that ran longer than the video with the split function. This no longer works.

Nothing has changed wrt. splitting for a long time now. If it worked before for you, that was certainly by accident, or the situation was subtly different with the files.

DavidRyan

2nd March 2021, 13:54

Can you please do two things:

Upload your settings file (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Location-of-settings,-job-queue,-cache-folder) to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server). Include your user name in the file name (or create a directory with your name) so I can associate it with you.
Get the latest continuous build (https://mkvtoolnix.download/windows/continuous/64-bit/54.0.0/) and give that one a try. I've fixed several issues over the last couple of days that may very well be the cause of what you observed. Try this without deleting the settings file first.

Thanks.

OK, I've:
- Uploaded settings file to your server, folder named "DavidRyan"
- Tried the latest continuous build and sources open fine from the button now. Tried a couple of times (as wasn't sure if it worked once last time and then failed or failed from the time I used the build) and all seems good so far.

Thanks.

Mosu

2nd March 2021, 16:20

Great. Thanks for the feedback.

Atlantis

3rd March 2021, 00:06

Language is not recognized. When adding movie.English.srt for example, it doesn't recognize English. It worked with the previous versions.

Atlantis

3rd March 2021, 01:07

What has happened to this software. It's been 2 hours I'm unable to add a subtitle with MKVToolNix recognizing the language. Tried almost everything .English.srt .en.srt .eng.srt in () and other stuff. It does not recognize.

ryrynz

3rd March 2021, 01:13

What has happened to this software.

Revert to an earlier version until it's fixed or someone can help.

Windows (https://mkvtoolnix.download/windows/releases/)
macOS (https://mkvtoolnix.download/macos/)

Atlantis

3rd March 2021, 01:15

So everyone has this problem too or is it just me?

Update: I just went to 53 and it is working. The problem is with 54. It was driving me crazy.

videoh

3rd March 2021, 02:45

What has happened to this software. Be patient and let Mosu do the needful. Improvements very often come with temporary regressions. IMHO, it's a fair price to pay for improved functionality and new features.

Mosu

3rd March 2021, 10:12

I can reproduce it with default settings & will look into it. As a workaround:

Open the preferences, go to "Multiplexer" → "Deriving track languages"
Under "Recognized languages" remove all languages from the "selected" list
Under "Recognized languages" re-add those languages you want recognized back to the "selected" list

The default is to recognize all languages. That doesn't seem to work anymore (v54 added tons of new language codes).

Mosu

3rd March 2021, 12:14

Technical details why it isn't working out-of-the-box with v54. The problem is a combination of two separate issues.

v54 added ISO 639-3 language codes. That list is loooong: 7.143 entries. Those codes should be deactivated by default in order not to overwhelm users. The user has to enable them in the "Often used selections" part of the GUI's preferences.

Unfortunately the "deriving track languages" selection always includes all 639-3 codes, no matter what the checkbox in the "often used selections" is set to. This is the first issue.

For deriving the track languages the GUI creates a regular expression (regex) of all the possible matches; usually both the two- and three-letter-codes and their English names (so that it'll recognize "fr", "fre" and "French" for… well… French, obviously).

Now, if all 7.143 languages are enabled (which they are by default) the resulting regex is a bit bigger than 100 KB. While there are regex engines that can handle such large regexes, the one used by the Qt project (the well-known "pcre" = Perl-compatible regex library) can't, or at least not without recompiling it — its limit is at 65.535 bytes (yeah, they use two-byte numbers for string offsets).

And that's issue two.

The first issue is easy enough to fix. The second, however, is a problem as I have to redesign how the GUI derives languages. I definitely cannot use a regex of all enabled languages; it'll have to be something else.

Luckily there's an easy workaround: deactivate most languages in the "deriving track languages" preferences and only enable those you actually want to use.