MKVToolnix Windows 7 "The final Countdown"

[jpsdr]

Hi.

I'm creating this thread to avoid poluting the Mosu thread with more posts.

We can talk here about which versions are working.

Also we know that a not working version at one time doesn't mean it's final, it just happenend.

Nevertheless, the reality is that the true final deadline is comming, and it's very near !

But, in the meantime...

The last i've tested working is 61.

New non officials QT5 builds
You can check here (https://github.com/jpsdr/MKVToolnix-QT5-Windows-7/releases/) for builds, not sure how often there will be.

[Liisachan]

Yeah, let's talk freely here without annoying Mosu :)

First off, I was surprised to know there are so many die-hard Win7 users, as I was thinking I was one of only few weirdos who're still using Win7.
Why are you guys avoiding Win10? Privacy concerns, or some kind of compatibility problems? If it's privacy, do you think Linux (migrating to it or using it side by side) is a realistically good option?

Also, don't just use the "lastest" MKVToolnix blindly... Generally, too new versions tend to be less reliable than tried and tested older versions, especially, experimental "continuous" builds. If you do font attachments, I'd suggest Version 57 or before to avoid the font-mime-type mess.

While MKVToolnix is a respectable project, it's not a secret that its GUI is not known for the most intuitive UI. Matroska is sometimes too powerful, too complicated, thus tools tend to become complicated & confusing.
Given that the rigorous rounding is important for Matroska (which doesn't support ntsc 24000/1001 fps explicitly),
https://matroska.org/technical/notes.html#timestampscale-rounding
the current rounding errors of mkvmerge is less than ideal, although there are workarounds. The fundamental problem here may be that MKVToolnix is practically a one-person project, not developed by a team.

But it's FLOSS, so if someone starts alt. builds (like MPC-HC & MPC-BE), things might become convenient for everyone, more flexible, and perhaps less stressful for Mosu too.

That being said, the problem here is not only about MKVToolnix. Many tools have stopped supporting Win7 already (esp. 32-bit), and more and more tools will stop supporting Win7 sooner or later... So I think Win7 users should start looking for a different option too just in case, which may mean Linux. "MKVToolnix for Win7" would be useful for the time being, though.

For many practical purposes, older versions of mkvmerge are perfectly fine. Essentially they write bit-identical MKV files as written by the newest version. So don't worry too much :)

EDIT
additional link
https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix-do-they-exist

[Dogway]

It's a Doom9 thing (the amount of Win7 users), we are a bunch of die hard fans.
Personally I like the OS to be fully under my control, and be sleek and functional.
Things like Cortana, Windows Defender, Candy Crush, Telemetry, "Apps", unavoidable updates... are not things I want on a working environment.

Another bad thing is the lack of DWM, I read you can't disable it so you can't go into FSE anymore.
More:
You have to disable "Control Flow Guard" for extra performance (if you run NVidia Cards).
You also need to "Empty Standby Memory" regularly while gaming (maybe with a task scheduler).
I also read that there are issues with the winsxs folder, maybe due to the amount of updates but it grows very large soon.
Finally the UI is a mess, not only metro is a disaster in itself but it's half metro half classic UI mixed.

I was happy to change to Win11 as it fixes some of the Win10 problems, but then they came with the hardware requirements.

Linux... nvidia driver incompatibilities and no or very bad color management system. Enough to not look any further.

I will install Win10 regardless in a few months, at least until I buy a new PC probably around 2025.

I'm curious to know aside of a GUI what MKVToolnix has better MKV features/support than ffmpeg. To know if it's worth changing, or if ffmpeg has important issues to care about.

[filler56789]

Version 67.0.0.63 is O.K.

[filler56789]

Last_Good one = 67.0.0.76.

[von Suppé]

Last_Good one = 67.0.0.76.
:thanks:

[Liisachan]

It's a Doom9 thing (the amount of Win7 users), we are a bunch of die hard fans.
Personally I like the OS to be fully under my control, and be sleek and functional.
Yeah, you want to own your OS. You don't want your OS to own you. Forced updates would be a real downer. While you're talking about freedom, convenience, practicality, I'd use "privacy" as the keyword, but I guess we're basically saying the same thing here. I'm so ready to migrate to Linux, except I'm kind of "trapped" - some tools that run on Windows are important in my current tool chain, even though I don't need Windows itself. Maybe I could use Win10 locally so that there are no privacy concerns?

I'm curious to know aside of a GUI what MKVToolnix has better MKV features/support than ffmpeg. To know if it's worth changing, or if ffmpeg has important issues to care about.
I'm not 100% sure, but in some cases, I think ffmpeg may delay video frame time stamps to offset the audio delay, which could mess up subtitle timing (esp. karaoke).
[Edit: I say "mess up" as a typesetter, but practically, normal people can't see the difference, even if karaoke color change for one letter is off by 41 ms.]

On the other hand, some MKV writer (ffmpeg too?) can write ebml CRCs, which MKVToolnix can't. Most MKV writers (e.g. Haali's) except MKVToolnix do not have weird rounding errors, where timestamps are not rounded correctly. MKVToolnix also does automatic update checking by default, without asking, without any privacy policy (but almost every tool does that today). So, frankly, it has a few, slightly unsatisfactory elements for me. The GUI i/f is not very intuitive, tbh.

That said, MKVToolnix has a ton of nice things. For example, the --deterministic option can be very handy for debugging in some situations. Info Tool - Element Viewer (hex dump) is extremely convenient when you're studying the inside of an MKV file. And its language code (LanguageIETF) support is nearly perfect, truly admirable. In reality, probably only a few, if any, users need/use complicated language codes, though.

For something basic, like just muxing x264 and aac, perhaps other muxers are as good as mkvmerge is. But all in all, I believe MKVToolnix is the most powerful tool to handle MKV.

[filler56789]

67.0.0.87.

[filler56789]

Looks like latest version works under Win7 again?

Yes :)

mkvtoolnix-64-bit-68.0.0-revision-001-g6a55c58d2

[ssjkakaroto]

First off, I was surprised to know there are so many die-hard Win7 users, as I was thinking I was one of only few weirdos who're still using Win7.
Why are you guys avoiding Win10? Privacy concerns, or some kind of compatibility problems? If it's privacy, do you think Linux (migrating to it or using it side by side) is a realistically good option?
The mentality of change for the sake of change is plaguing the whole IT world. When I bought my PC Windows 7 was fully supported, so it works perfectly with my hardware.
Security is a non-issue if you know how to get ESU updates (https://docs.microsoft.com/en-us/troubleshoot/windows-client/windows-7-eos-faq/windows-7-extended-security-updates-faq).
Besides some programs that are forcing Windows 10 down our throats, I see no reason to upgrade from a perfectly stable system.

[filler56789]

mkvmerge v68.0.0.36.

[manolito]

Thanks for the Heads-Up...

Mosu just released Version 69.0.0 of MKVToolMix, and this version no longer works under Win7. So the version you posted seems to be the final Win7 compatible version. I did a quick test (32-bit only), and it seems to work fine.

So I updated my ToolNix Repository for ancient versions (for WinXP and Win7, 32-bit only), the link is here:
https://forum.doom9.org/showpost.php?p=1967747&postcount=1585


Cheers
manolito

[hubblec4]

@filler56789

Do you know if this fix is included in the last working version?
mkvmerge: HEVC ES parser: the parser will now parse at least the first full access unit before reporting that it has found all the required headers. Otherwise parsing might stop in the middle of the access unit due to the source reader not providing more data in the first call, leading to the parser not finding the "unspec62" and "unspec63" NALUs required for Dolby Vision. Fixes #3363 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3363).

[filler56789]

@filler56789

Do you know if this fix is included in the last working version?

I cannot check that because 1) I don't split MKV files and 2) I have never played /created /used HEVC streams containing Dolby-Vision, but my answer is:

VERY-UNLIKELY, because...

Moritz Bunkus @mbunkus added: fixed-in-version 69.0.0 — 1 day ago

source: https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3363

[lvqcl]

Mosu just released Version 69.0.0 of MKVToolMix, and this version no longer works under Win7.

It seems that it won't work on Win8/8.1 too.

[Video Dude]

@filler56789
Do you know if this fix is included in the last working version?

The last working Win7 version is mkvtoolnix-64-bit-68.0.0-revision-036-g37903f25c

Look at the g37903f25c and find the corresponding commit on gitlab, which is 37903f25

https://gitlab.com/mbunkus/mkvtoolnix/-/commit/37903f25cf7ea2d0ddd381d8506fc0c2a30f5d2f


So yes, it appears that fix is included. In fact, it was the very last commit for Win7.

[hubblec4]

Thanks Video Dude for this info.

[filler56789]

The last working Win7 version is mkvtoolnix-64-bit-68.0.0-revision-036-g37903f25c

Look at the g37903f25c and find the corresponding commit on gitlab, which is 37903f25

https://gitlab.com/mbunkus/mkvtoolnix/-/commit/37903f25cf7ea2d0ddd381d8506fc0c2a30f5d2f


So yes, it appears that fix is included. In fact, it was the very last commit for Win7.

Thanks for correcting me. *THUMBS UP*

Too bad no one can trust Mosu anymore. :(

:sly:

[filler56789]

SOURCE: https://www.videohelp.com/software/MKVToolNix

Please, can you share those files ?

If you have the following 69.0.007 versions bearing the below SHA-1, they will work with Windows 7/8 and respective server version:
B5D5E22968F947558BFB100EF06D37A1FB3BC7C4 mkvtoolnix-32-bit-69.0.0-revision-007-ga64005aa6-setup.exe
5F8BB12A7C9FA214E4B63BCFC4EF020E27186A4F mkvtoolnix-32-bit-69.0.0-revision-007-ga64005aa6.7z
254911C993E8685AE514A8B7FD789C200EA6E3C4 mkvtoolnix-64-bit-69.0.0-revision-007-ga64005aa6-setup.exe
86B4EEDFA42A60D74FECBE76FA55BF44A53D400A mkvtoolnix-64-bit-69.0.0-revision-007-ga64005aa6.7z

[jpsdr]

Thanks for the tips.

[jpsdr]

Tested mkvtoolnix-32-bit-69.0.0-revision-007-ga64005aa6-setup.exe under Windows 7 x86, not working for me.

[hubblec4]

for me also not.

[filler56789]

FWIW, and again:

from the #usercomments section for MKVtoolnix @ Videohelp dot com:

If you have the following 69.0.007 versions bearing the below SHA-1, they will work with Windows 7/8 and respective server version:

B5D5E22968F947558BFB100EF06D37A1FB3BC7C4 mkvtoolnix-32-bit-69.0.0-revision-007-ga64005aa6-setup.exe
5F8BB12A7C9FA214E4B63BCFC4EF020E27186A4F mkvtoolnix-32-bit-69.0.0-revision-007-ga64005aa6.7z
254911C993E8685AE514A8B7FD789C200EA6E3C4 mkvtoolnix-64-bit-69.0.0-revision-007-ga64005aa6-setup.exe
86B4EEDFA42A60D74FECBE76FA55BF44A53D400A mkvtoolnix-64-bit-69.0.0-revision-007-ga64005aa6.7z

BUT the greater surprise is this one :scared:

There might be one more option. There seems to be modified QT6 version for Win7 here:
https://forum.qt.io/topic/133002/qt-creator-6-0-1-and-qt-6-2-2-running-on-windows-7
I've been already able to run another QT6 based software using that (Calibre 6.1 - https://calibre-ebook.com/download).
There you need to use as well VxKex to run it - https://github.com/vxiiduu/VxKex
But MKVToolnix seems to have QT embedded in main exe, so it is not possible just easily replace those binary files like for Calibre.

[jpsdr]

Intersesting. Maybe someone who know how to build MKVToolnix can test make a build using this QT version instead of standard.

[filler56789]

Intersesting. Maybe someone who know how to build MKVToolnix can test make a build using this QT version instead of standard.

For the users of Windows 7 and 8.1, the ``ideal´´ solution would be

1) revert the change which made the CLI-executables depend on Qt
(I.O.W., make them use the file magic.mgc again)

+

2) replace the Qt-based GUI with one written in Java, or in a dot-net language, or in C++.

[filler56789]

OOOPS, now finally there exists a non-official build of MKVtoolnix for Windows 7 and 8.1 :eek: :scared:

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix-do-they-exist#post2663774

[jpsdr]

According this thread, the minimal requirement build for mkvtoolnix is QT 5.9.0, so, for now, you "just" ;) have to build mkvtoolnix with this QT version, no need for tweaked QT version, just normal 5.9.0.
I, out of curiosity take a look of how to build mkvtoolnix... argh... it seems even more painfull than building x264...

Edit
Maybe finaly it's not so painfull, but still failling building... :(

[filler56789]

I, out of curiosity take a look of how to build mkvtoolnix... argh... it seems even more painfull than building x264...

INFINITELY more annoying than building x264, granted.
Principally because of the bloated Qt slowware.
When I managed to compile tsMuxeR, it was easy to get rid of the GUI part, which is the one that requires Qt. But MKVtoolnix is much more complex than tsMuxeR :–/

[manolito]

Now there is a 32-bit version which works nicely under Win7 . Have a look here:

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix-do-they-exist#post2663838

Cheers
manolito

[Video Dude]

If we could fork MKVToolNix to GitHub and then create an Actions script to automatically compile it.

I found this about Qt5:

https://github.com/marketplace/actions/install-qt


There should also be ways to include mxe/rake in the Actions script.

Future updates could be cherry picked to commit. Most non-gui commits would not break Win7 support.

[jpsdr]

Building MKVToolnix with QT5 under Linux

While the minimum requirement described in the MKVToolnix home page stays QT 5.9.0, it will probably be able to build a Windows 7 version.
For now, i've not been able to build under Windows with MSYS2, the mxe package may just not be compatible with... :(
But one thing is sure: You can't build from a 32 bits Windows with a 32 bits version of MSYS2.

I'll describe what i've done, so some the paramaters/values i've used are specific to my configuration, adapt if you change things.

I've created an MKVToolnix directory in my $HOME directory.
Then, clone GIT the followings:

git clone https://gitlab.com/mbunkus/mxe $HOME/MKVToolnix/mxe
git clone https://gitlab.com/mbunkus/mkvtoolnix.git $HOME/MKVToolnix/mkvtoolnix


Now, edit the setup_cross_compilation_env.sh file in the mkvtoolnix/packaging/windows directory.
Change eventualy the ARCHITECTURE if you want to build for 32 or 64 bits.
For my setup, i've changed:
INSTALL_DIR=${INSTALL_DIR:-$HOME/MKVToolnix/mxe}

Now change the following line:
MKVTOOLNIX_DEPENDENCIES+=qt6 qt6-qtmultimedia
with:
MKVTOOLNIX_DEPENDENCIES+=qt5 qtmultimedia

Now... In the mxe/docs directory, open the index.html file in your brower, and check the necessary installed tools according your Linux version.

I was under Ubuntu 20.04, i'll now switch to install instructions specific to it.
I had to install the following:

apt-get install \
autoconf \
automake \
autopoint \
bash \
bison \
bzip2 \
flex \
g++ \
g++-multilib \
gettext \
git \
gperf \
intltool \
libc6-dev-i386 \
libgdk-pixbuf2.0-dev \
libltdl-dev \
libssl-dev \
libtool-bin \
libxml-parser-perl \
lzip \
make \
openssl \
p7zip-full \
patch \
perl \
python3 \
python3-mako \
ruby \
sed \
unzip \
wget \
xz-utils

That was for mxe. I've struggle a little to figure out what was missing to finalise.
I may have installed too much things, so, the following is my guess of what may just be necessary:
apt-get install python-is-python3 libogg-dev libvorbis-dev docbook-xsl xsltproc
You can try with just this. If it fails, add the following:
apt-get install vorbis-tools qt5-default build-essential qtcreator
On my system, both lines are installed, but as i said, i may have installed things not necessary.

Now, from within the mkvtoolnix directory, run the script:
./packaging/windows/setup_cross_compilation_env.sh
The building library part will take a LOOOT of time, without any message log displayed, so, don't panic if script seems "frozen", it's not ! But, once it's done, when you re-run the script, it will not take a lot of time.

Now... If everything went fine, it will say it and display a message with also 3 commands to execute, with rake at the last.
Copy/paste (and so execute) the 3 commands in your console.
The last, rake, will build mkvtoolnix.
You have to search within the src directory (and sub-directories) to find all the .exe.
I've been able to build a 32 bits version of 69.0.0.39, tested Ok (at leat the GUI starts) on a Windows 7 x86.

Edit
If you want to build both 32 bits and 64 bits versions, once a build is finished, you have to run "rake clean", and after changing ARCHITECTURE in setup_cross_compilation_env.sh, re-run it, don't add the PATH (it's allready done if you're still in the same console), just "hash -r" and "rake".

And then, after, you have to strip the files.

Edit 2
Collect them together in a location for stripping them all at once.
32-bit executables require the 32-bit strip.exe, 64-bit executables require the 64-bit strip.exe.

32-bit build:
Code:

{mxe}/usr/bin/i686-w64-mingw32.static-strip *.exe


64-bit build:
Code:

{mxe}/usr/bin/x86_64-w64-mingw32.static-strip *.exe

[jpsdr]

Build under Windows with MSYS2 is not looking good...
After solving some issues, i've been able to begin the toolchain build, but after a very long time (at least 1h if not 2h), it failed with:

configure: error: Oops, mp_limb_t doesn't seem to work

After a little search, it seems to be a MSYS2 issue, for now there is unfortunately a big chance this being a fatal blow...:(

[filler56789]

I have not read everything yet, BUT maybe there exists a workaround :–/

.............
The configure step fails with "error: Oops, mp_limb_t doesn't seem to work" apparently because it calls configure using an absolute path, not relative.

https://githubmemory.com/repo/wbhart/mpir/issues/189

[jpsdr]

Unfortunately, this is advanced Makefile/script, i'm totaly lost and have no idea of what to do (if it's even possible to do something).

[jpsdr]

Anyway, i have 69.0.0.39 Windows 7 working (at least, GUI start, didn't test further yet) version build under Linux, but i don't know where to put it. Any suggestion ? Create a Github ?

[hubblec4]

GitLab

[filler56789]

BOTH GitHub and GitLab. :)
Just to be on the safe side. :)
Hopefully someone will change the source-code and find a way to get rid of Qt :devil: entirely 😇.

[filler56789]

Anyway, i have 69.0.0.39 Windows 7 working (at least, GUI start, didn't test further yet) version build under Linux, but i don't know where to put it. Any suggestion ? Create a Github ?

You might have already shared the archive in that Videohelp thread that I opened some weeks ago.

[jpsdr]

Hopefully someone will change the source-code and find a way to get rid of Qt :devil: entirely ��.

This is, i think a LOOOT harder than just try to build it with a QT5 version, while the minimum is still QT5.
I'll think later eventualy for at least a github.

[jpsdr]

Check first post, and forget GitLab, i stopped trying to understand how it works before i wanted to kill someone... :angry:

[hubblec4]

Thank you. It works.

[filler56789]

Check first post, and forget GitLab, i stopped trying to understand how it works before i wanted to kill someone... :angry:

Many :thanks: for the alternative build. :goodpost:

=> mkvmerge
mkvmerge v69.0.0.39 ('Day And Age') 64-bit
Error: no destination file name was given.

mkvmerge -o out [global options] [options1] <file1> [@option-file.json] …

suggestion: please give better names to the releases...
we already have a ton of «vc_redist*.exes» :D in the world. :)

[jpsdr]

... I don't understand what you mean.
I just build, Mosu chooses the name of the releases.

[filler56789]

... I don't understand what you mean.
I just build, Mosu chooses the name of the releases.

I meant the filenames of the archives...
"MKVtoolnix.7z" is very UN-informative,
different from "mkvtoolnix-69.0.0-revision-039-gcea3d558a.7z",
for example.

[jpsdr]

Ah... Ok... I'll try to remember for the next time, and don't stop just after zip my directory.

[manolito]

Thanks jpsdr for your build... :D

For Doom9 users who do not regularly check VideoHelp I post the link to your build here:
https://github.com/jpsdr/MKVToolnix-QT5-Windows-7/releases/

I just tested it (32-bit only) under Win7, and it works flawlessly. Highly recommended :)

//EDIT//
I also updated the link to my legacy MKVToolMix versions here
https://forum.doom9.org/showthread.php?p=1967747#post1967747
to include this latest Win7-32bit version. Enjoy...


Cheers
manolito

[jpsdr]

Will not have access to a Linux PC for several weeks, so, unless someone else make a build using the method i've described, no new build for a while.
Also, MSYS2 build is in progress, but for now, only be able to get "dynamic" builds ( the .exe ask for a lot of DLLs :( ), not success on static builds yet.

[filler56789]

Thanks a lot for your hard work, jpsdr.

I myself MIGHT (try to) compile MKVtoolnix and share more old-Windows-compatible builds, but first I would have to ``clean´´ my HDDs and this would take some more weeks or months :–|

[filler56789]

Version 70 has been released. :cool:

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix-do-they-exist?p=2665052&viewfull=1#post2665052

[filler56789]

Version 71 built by user autodidact :thanks: @ VideoHelp-dot-com.

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix?p=2669522#post2669522