MKVToolNix v87.0 released

[Masutin]

When adding chapters with mkvpropedit is it possible to set the language 'und'? Similar to muxing with '--chapter-language und' with mkvmerge to produce a menu with '::Chapter Title' in the file properties. If nothing is specified, mkvpropedit produces entries with :en:Title. Removing 'en' might strip unnecessary bytes.

[Mosu]

No. mkvpropedit takes chapters as they are, only adds missing IETF language elements (unless turned off) & other mandatory elements.

[Mosu]

Heyo 💝

MKVToolNix v86.0 is out. There were several bug fixes, most notably around the handling of timestamp files. That was code I hadn't touched for… a decade, maybe. Quite the trip. A couple of enhancements were also made; see below.

Here are the usual links: the MKVToolNix home page, the downloads section and the source code.

The Windows packages and macOS disk image as well as the Linux AppImage are available already. The other Linux packages are still being built and will be available over the course of the next couple of hours.

Here are the NEWS since the previous release:

Version 86.0 "Winter" 2024-07-13
New features and enhancements

• mkvmerge: Matroska reader: track statistics tags are included in the JSON identification output just like other tags had already been included: as part of the track properties, prefixed with "tag_". Implements #3714.
• mkvmerge: MPEG TS reader: mkvmerge will now detect teletext subtitle tracks even if they're not listed in the PMT as long as it can find teletext pages flagged as subtitles in the header within the probed ranged of the file. Implements #3650.
• MKVToolNix GUI: multiplexer: the default mode for escaping the arguments in the "Show command line" dialog can now be set in the preferences. Partially implements #3709.
• MKVToolNix GUI: multiplexer: the "Show command line" dialog now includes the command lines for all currently open multiplex settings, switchable with a combo box. Partially implements #3709.
• MKVToolNix GUI: multiplexer: some users add the option "--regenerate-track-uids" to the "additional options", even though "--regenerate-track-uids" is a file-specific option, and you can only use global options in the "additional options". However, the GUI currently doesn't have an option for specifying additional file-specific options. The GUI now detects the use of this option in the "additional options" & adds it for each of the source files instead. Implements #3707.
• MKVToolNix GUI: multiplexer: the option "--regenerate-track-uids" has been added to the "additional command line options" dialog. See #3703.
• translations: added a Norwegian Bokmål translation of the man pages by Roger Knutsen (see "AUTHORS").

Bug fixes

• mkvmerge: when using timestamp files for subtitle tracks, mkvmerge will no longer set a default duration for the track. Partially fixes #3711.
• mkvmerge: when using timestamp files for subtitle tracks, mkvmerge will no longer queue frames longer than necessary, which resulted in the frames sometimes being written much later than they should have been according to their timestamps. Partially fixes #3711.
• mkvmerge: when using timestamp files for subtitle tracks, mkvmerge will now write the packets' duration properly. Partially fixes #3711.
• MKVToolNix GUI: job queue: the shortcut from the "Job queue" menu are now enabled correctly whenever the number of jobs in the queue changes (e.g. by adding new jobs). Fixes #3720.

Have fun 😁

[Masutin]

mkvpropedit. Apparently using '--normalize-language-ietf off' or '--disable-language-ietf' won't affect the language identifier in the chapters.

[hubblec4]

Hi Mosu

Many thanks for the new version of MKVToolNix.

I have a question about the timestamp files. In the description is a hint that the count of the timestamp entries must be not smaller as frames there are.
Equal timestamps entries as frames is of course the best.
But what is when there are more timestamp entries in a timestamp file as frames to mux? Is this a problem for mkvmerge?

[AngelGraves13]

BUG:

Version 86.0 crashes (closes) if you try to move items in the queue by dragging them.

[Mosu]

Originally Posted by AngelGraves13

BUG:

Version 86.0 crashes (closes) if you try to move items in the queue by dragging them.

Please open an issue for this over on Gitlab. Otherwise chances are I'll forget about it again. Thanks.

[Mosu]

Originally Posted by Masutin

mkvpropedit. Apparently using '--normalize-language-ietf off' or '--disable-language-ietf' won't affect the language identifier in the chapters.

Whether or not IETF BCP47 support is on only matters to parts that you tell mkvpropedit to modify. For example, if you use mkvpropedit to only set the track name then existing chapters aren't modified and are therefore not affected by the option. The other way around is true as well: if you only use mkvpropedit to replace chapters, then only the chapter language elements will be affected by the option, but not the track or tag language elements.

I just verified that the option very much works as expected when replacing or adding chapters with mkvpropedit.

BTW: '--normalize-language-ietf off' is not a valid option at all.

[Mosu]

Originally Posted by hubblec4

Hi Mosu

Many thanks for the new version of MKVToolNix.

I have a question about the timestamp files. In the description is a hint that the count of the timestamp entries must be not smaller as frames there are.
Equal timestamps entries as frames is of course the best.
But what is when there are more timestamp entries in a timestamp file as frames to mux? Is this a problem for mkvmerge?

Having more timestamps isn't a problem. The only difference between the two situations (exactly as many timestamps as frames & more timestamps than frames) is how the last frame's duration is calculated: if there are more frames, the last frame's duration is the difference between the last frame's timestamp & the following timestamp, whereas in the situation of "exactly as many timestamps as frames" the last frame's duration is derived from other means (in case of timestampts v2: the most often occurring duration).

With fixed FPS content there should be no difference at all.

[hubblec4]

Originally Posted by Mosu

Having more timestamps isn't a problem. The only difference between the two situations
....
With fixed FPS content there should be no difference at all.

Very interesting and good to know. Thanks for this hint.

[hubblec4]

Hi Mosu

I have some questions about TrueHD Audio.

Here is a picture from the MKVInfo tool.


1. Why is there no DefaultDuration element?
The FPS is well defined for 48khz with a value of 1 / 1200.

2. Why is each frame stored in it's own SimpleBlock except the first two frames?
This produces a lot overhead.

[Mosu]

TrueHD is one of the few audio formats that actually have something similar to I/P video frames in that it has "sync" frames that are decodable on their own & non-sync frames with a much shorter header that rely on the presence of the previous sync header for decoding. The number of non-sync frames vs sync frames is much, much higher than P video frames to I video frames — in one example file I have there are 38 sync frames and 4802 non-sync frames (!).

In the past I have actually tried placing one sync frame & all following non-sync frames into the same Matroska frame, but that broke playback on pretty much everything I had access to at that time.

Default duration doesn't make much sense if it's below 1ms, which it is for TrueHD.

[hubblec4]

Originally Posted by Mosu

TrueHD is one of the few audio formats that actually have something similar to I/P video frames in that it has "sync" frames that are decodable on their own & non-sync frames with a much shorter header that rely on the presence of the previous sync header for decoding. The number of non-sync frames vs sync frames is much, much higher than P video frames to I video frames — in one example file I have there are 38 sync frames and 4802 non-sync frames (!).

OK. Good to know.

Originally Posted by Mosu

In the past I have actually tried placing one sync frame & all following non-sync frames into the same Matroska frame, but that broke playback on pretty much everything I had access to at that time.

Interesting. For muxing I had used the -1 value for the TimestampScale, but with the default value (or omit the TimestampScale element) there are identical timestamps for some frames (00:00:00.003000000), and it is not clear to me which frame are used at this timestamp.
For better timestamps the -1 magic value should be always used?

Originally Posted by Mosu

Default duration doesn't make much sense if it's below 1ms, which it is for TrueHD.

Yes, I can understand this, but for the duration calculation of a stream Matroska say: use the timestamp from the last(display order) frame and add the frame duration.
When no DefaultDuration element is there I have to find out the frame duration by my self?

[nevcairiel]

TrueHD audio frames are typically 0.8333.. milliseconds long. Thats why you run into troubles with the default timestamp scale which is just in milliseconds and cannot represent even a single TrueHD frame accurately. Eventually you need two frames with the same timestamp to make up the difference.
The same reason applies why an accurate DefaultDuration is not necessarily possible or useful. Unfortunately Matroska does not offer fractional timestamp scales to solve this (plus its only one timestamp scale that needs to apply for video and audio equally).

[Masutin]

Thanks for your reply! In mkvpropedit when only adding chapters with -c, or replacing, if it's different, entries are marked as English by default. mkvinfo shows this as:
Chapter language: eng
Chapter language (IETF BCP 47): en
Can I a) delete or b) avoid adding this language identifier?
I used options with IETF from the manual. You mention '--disable-language-ietf' working as expected. Indeed '--normalize-language-ietf off' is invalid. The manual says "Enables normalizing all IETF BCP 47 language tags to either their canonical form with mode 'canonical', to their extended language subtags form with mode 'extlang' or turns it off with mode 'off'. By default normalization to the canonical form is applied."
If these two options do not apply here, please never mind.

[hubblec4]

Yeah, I'm absolute at you.
Missing fractional elements is an EBML issue and we have a discussion there but the founder is not really interested in.

The good is the TimestampScale element can be used to get micro-second timestamp accuracy, but also this is not enough to get perfect timestamps.

@Mosu
Is there a chance to change this in the Matroska specs, to get better timestamps?

[Mosu]

Not really. After long and exhausting discussions the issue remains that any kind of improved timestamps would either increase the overhead quite a bit (and be hacky, basically having a second layer of timestamps in addition to the existing, known ones) or use completely different block group elements. The latter type of files would not be backwards compatible at all.

I don't think it's realistic to expect this to change anymore.

[Masutin]

Dear Mosu, my last message about mkvpropedit was for you. It's about removing or not adding entries that in mkvinfo appear as:
Chapter language: eng
Chapter language (IETF BCP 47): en
This may be a trifle but still may have a solution.

[OAKside]

May I ask why MKVToolNix adds audio tags (like Writing library) to General, not under Audio?

Notes: I'm not exactly sure when this behavior started, but it was many versions ago. Similar tags for videos are placed under Video section.

Reproduce: Encode AAC audio. It will contain tags under Writing library (like qaac 2.82, CoreAudioToolbox 7.10.9.0, AAC-LC Encoder, TVBR q73, Quality 96). Add this audio and a video to MKV container (using MKVToolNix 85.0). View media info (using MediaInfo 24.06): The mentioned audio tags will end up in General, not Audio.

[Mosu]

There are no sections for information in Matroska such as "General" or "Audio". How information is presented is up to the application presenting it, in this case; MediaInfo.

Certain pieces of information are stored at the bitstream level within a track. Additionally there can be free-form tags associated with a track (instead of with the whole file in general). My guess is that MediaInfo groups both this bitstream-level information & the track-associate tags in a section called "Audio" if it's from the bitstream of an audio track and similarly for video tracks. That's expected behavior.

Tags can also not be associated with a track, in which case they're supposed to apply to the whole file.

I have no idea how MediaInfo decides to show those types of tags.

One thing that I can think of is converting tags from MP4 to Matroska. In MP4 tags are not associated with a track; they're global. mkvmerge converts a limited number of MP4 tags into global Matroska tags, among them the movie title, the free-form comment field & the encoder.