Create, modify and inspect Matroska (MKV) files for Windows PC

MKVToolNix 80.0.0 (32-bit)

October, 30th 2023 - 24.98 MB - Open Source

Free Download

Security Status

Latest Version

MKVToolNix 83.0.0 (32-bit)
Operating System

Windows 7 / Windows 8 / Windows 10
User Rating

Click to vote
Author / Product

Moritz Bunkus / External Link
Filename

mkvtoolnix-32-bit-80.0-setup.exe
MD5 Checksum

4197b82f5b16ebff0f7cf0e4d152acd4

Sometimes latest versions of the software can cause issues when installed on older devices or devices running an older version of the operating system. Software makers usually fix these issues but it can take them some time. What you can do in the meantime is to download and install an older version of MKVToolNix 80.0.0 (32-bit).

For those interested in downloading the most recent release of MKVToolNix (32-bit) or reading our review, simply click here.

All old versions distributed on our website are completely virus-free and available for download at no cost.

We would love to hear from you

If you have any questions or ideas that you want to share with us - head over to our Contact page and let us know. We value your feedback!

Download MKVToolNix 80.0.0 (32-bit)

MKVToolNix 80.0.0 (32-bit) Screenshots

The images below have been resized. Click on them to view the screenshots in full size.

What's new in this version:

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.

Fixed:
- 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
- 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 720x520 & an aspect ratio factor of 1/1 the result should be 720x520, but instead it was 900x520. 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.