MKVToolNix v80.0 released


Time for another release. I’m still in a bit of a coding slump (or rather: preoccupied with all the amazing games that have come out this year); therefore this release is really, really small. I’ll likely do one more bug fix release this year that’ll be around this size as well. But let’s see how things shake out.

You can download the source code or one of the binaries. 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 since the previous release:

New features and enhancements

  • MKVToolNix GUI: if the system’s locale uses one of the Han scripts, the GUI will force Arabic numerals to be used in spin boxes. This prevents Suzhou numerals from being used which seems to be the default on Windows systems sold in China. Implements #3624.

Bug fixes

  • build system: fixed detection of Qt6 if clang is used for compilation on Linux. In that case Qt’s qmake added a gcc-specific option that clang doesn’t understand, -mno-direct-extern-access. configure will now pass the parameter -spec linux-clang to qmake so that it uses the correct compiler flags.
  • build system: fixed the use of mktemp to be more portable to e.g. macOS. Fixes #3608.
  • mkvmerge: if a video aspect ratio was given with --aspect-ratio-factor, the code would apply a second factor based on the pixel resolution, resulting in much too large values for the DisplayWidth element. For example, with a pixel resolution of 720×520 & an aspect ratio factor of 1/1 the result should be 720×520, but instead it was 900×520. Up until release 76.0 this has only happened when a track order was given (which unfortunately includes all invocations with MKVToolNix GUI as it always includes the track order). Starting with release 77.0 this has always happened due to the automatic sorting of tracks implicitly creating a track order, even if none was given.

Have fun 😁

2 thoughts on “MKVToolNix v80.0 released

  1. Hellboy.

    “mkvmerge: if a video aspect ratio was given with –aspect-ratio-factor, the code would apply a second factor based on the pixel resolution” “which unfortunately includes all invocations with MKVToolNix GUI”

    I always use the GUI. that mean that all the video files that were created using the GUI contain a bad aspect-ratio?

    1. mosu Post author

      No. Only if you manually specified an aspect ratio _factor_ in the GUI. The part about “all invocations of MKVToolNix GUI” only refers to the fact that the GUI will always specify a track order.

      Or to put it differently: the issue only happens when both options `–aspect-ratio-factor` and `–track-order` were specified at the same time. The GUI always specified `–track-order`, but only specifies `–aspect-ratio-factor` if you enter a factor manually.

Comments are closed.