MKVToolNix v24.0.0 released

[Mosu]

And the inputs for tag/chapter/timecode/segmentinfo files. Etc. Basically everywhere which is not a file dialog.

[Megalith]

Where is the option to ignore the AC3 core track from being included from a TrueHD track?

EDIT: Nevermind, I'm an idiot. Obviously you can just uncheck the AC3 stream in the Input options...

[ndjamena]

MakeMKV is complaining bitterly about any VC-1 track that has been remux using MKVMerge, so far the only difference I can see using MKVInfo is that the first frame in the MKVMerge file is 33 bytes longer for some reason. The file was originally created by MakeMKV then remuxed by MKVMerge, so is this added 33 bytes expected?

http://www.makemkv.com/forum2/viewtopic.php?f=8&t=9039

[Mosu]

Hey,

I've released MKVToolNix v7.9.0.

First of all a note to all Windows users: I've renamed the downloads slightly. They're now named e.g. mkvtoolnix-32bit-7.9.0-setup.exe etc. The difference is that 64bit builds use …-64bit-… instead of …-amd64-… and that the 32bit builds include their architecture (-32bit-) in their name for the first time. This was done in order to reduce the confusion sown by the term »amd64« which denotes the processor architecture but not the manufacturer. Many people weren't aware of that differentiation.

As for the changes in this release: A couple of important bugs have been fixed, e.g. a very old bug in handling MPEG-1/2 video preventing the detection of such tracks; if --sync was used at the same time as --default-duration then --sync was ignored; mkvinfo's exit codes were wrong (this may trip up frontends using mkvinfo!); handling of E-AC3 in MPEG transport stream in certain situations etc. See below for all the details.

Since the previous release a serious amount of work has gone into the new GUI, MKVToolNix GUI. It has reached a state in which I consider it fit for wider use. I've therefore removed the preview warning and included it in all the packages that I provide (both Windows and Linux).

If everything goes according to plan then the next release, 8.0.0, will see the old GUI (mmg, mkvmerge GUI) be marked as being deprecated – meaning there will be a popup message warning you about this fact when you start mmg. Two releases later, with 8.2.0, the old GUI will finally be removed among with all support for the wxWidgets toolkit.

Of course all of this depends on the number and seriousness of bugs found in the new GUI ;) Therefore these plans are not set in stone.

Changes for package maintainers: configure will now detect the presence of the Qt libraries version 5.2.0 or later by default and use them if they're found. This means that at the moment both GUIs (mmg and MKVToolNix GUI) will be built unless you tell configure otherwise. There are several switches that deal with the various toolkits:

--disable-gui – don't build any GUI support, neither wxWidgets nor Qt based (same as for the previous releases)
--disable-wxwidgets – don't build wxWidgets-based GUIs (mkvinfo's wxWidgets frontend, mmg)
--disable-qt – don't build Qt-based GUIs (mkvinfo's Qt frontend, MKVToolNix GUI)
--without-mkvtoolnix-gui – build mkvinfo's Qt-based frontend but not MKVToolNix GUI

The two different frontends for mkvinfo are mutually exclusive with the Qt-based version taking precedence over the wxWidgets-based version.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-05-10 Moritz Bunkus <moritz@bunkus.org>
* Released v7.9.0.
* build system: configure will now check for Qt by default. If at least v5.2.0 is found then the Qt versions of mkvinfo's GUI and the new mkvtoolnix-gui will be enabled. You can affect this detection with the options --disable-gui (turns off all GUIs; works the same as before), --disable-qt (will compile the wxWidgets GUI for mkvinfo and mmg) and --without-mkvtoolnix-gui (will compile the Qt version of mkvinfo's GUI but no mkvtoolnix-gui).

2015-05-07 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: mkvinfo would exit with the wrong return code (0 instead of 2) if a non-existing file name had been given. Fixes #1182 (https://github.com/mbunkus/mkvtoolnix/issues/1182).

2015-05-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Two more characters are now escaped in the container and track properties output in verbose identification mode: [ is replaced with \b and ] with \B. This is needed for reliable parsing by other programs, e.g. GUIs.

2015-05-04 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: added context menu entries for tracks: »select all«, »enable all« and »disable all«.

2015-05-02 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: implemented aborting the currently running job.

2015-04-28 Moritz Bunkus <moritz@bunkus.org>
* all: fix compilation on Mac OS in common/command_line.cpp due to boost::range::filtered requiring a copyable functor. Fixes #1175 (https://github.com/mbunkus/mkvtoolnix/issues/1175).
* all: fix compilation on Mac OS in common/version.cpp due to wrong usage of std::stringstream and ostream operators. Fixes #1176 (https://github.com/mbunkus/mkvtoolnix/issues/1176).

2015-04-27 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: implemented the »additional command line options« dialog.

2015-04-25 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature in the chapter editor: added features »set the language/country of the selected chapter and its sub-chapters«.

2015-04-24 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: fixed compilation with Boost 1.58.0. Fixes #1172 (https://github.com/mbunkus/mkvtoolnix/issues/1172).
* mkvmerge: bug fix: Fixed a segmentation fault during cleanup after Ctrl+C was pressed. Fixes #1173 (https://github.com/mbunkus/mkvtoolnix/issues/1173).

2015-04-23 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature in the chapter editor: added features »clamping time stamps of sub-chapters to their parent's time stamps«, »expanding time stamps of chapters to encompass their sub-chapters' time stamps« and »shifting start and end time stamps by an offset«.

2015-04-22 Moritz Bunkus <moritz@bunkus.org>
* all: permanently removed the build times tamp from the version information and the corresponding configure option.

2015-04-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: the main window's size, position and state (maximized/minimized) is saved on exit and restored on startup.
* MKVToolNix GUI: new feature: the GUI is now fully translatable. The German translation has been completed for the GUI, too.

2015-04-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed --sync not doing anything if --default-duration is used for the same track, too.

2015-04-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed aborting file identification with an error message about »aac_error_protection_specific_config« that happened for some files. Fixes #1166 (https://github.com/mbunkus/mkvtoolnix/issues/1166).

2015-04-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: implemented changing the interface language.

2015-04-13 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: implemented often used subtitle character sets.
* MKVToolNix GUI: enhancement: implemented setting a user configurable subtitle character set by default.
* MKVToolNix GUI: enhancement: implemented the automatic removal of jobs configurable by the user.
* mkvmerge: bug fix: fixed specifying track properties like language or name for AC3 cores embedded in TrueHD tracks when they're read from raw thd+ac3 files. Fixes #1158 (https://github.com/mbunkus/mkvtoolnix/issues/1158).
* mkvmerge: enhancement for MPEG program stream handling: mkvmerge will only look for additional files automatically if the source file begins with »VTS_…« and just if it ends in a number. E.g. when reading »video_1.mpg« another file called »video_2.mpg« will no longer be read automatically. Implements #1164 (https://github.com/mbunkus/mkvtoolnix/issues/1164).

2015-04-12 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: display country names in addition to country codes.
* MKVToolNix GUI: enhancement: implemented often used languages and country codes.
* MKVToolNix GUI: chapter editor enhancement: implemented defaults for the language and country settings for newly created chapter names.
* MKVToolNix GUI: merge tool enhancement: added controls for mkvmerge's »reduce audio to its core« and »force NALU size length« features.
* MKVToolNix GUI: new feature: implemented the »Preferences« dialog (not all of the functionality the options refer to has been implemented yet, though).

2015-04-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG-1/2 parser: fixed a long-standing issue that prevented mkvmerge from recognizing certain MPEG-1/2 video tracks and files if the frame's sequence numbers didn't follow a certain expected pattern. Fixes #1162 (https://github.com/mbunkus/mkvtoolnix/issues/1162) and probably others like #1145 (https://github.com/mbunkus/mkvtoolnix/issues/1145) or #1099 (https://github.com/mbunkus/mkvtoolnix/issues/1099).
* MKVToolNix GUI: merge tool enhancement: Implemented adding and append files and adding files as additional parts via drag & drop from external applications.
* MKVToolNix GUI: merge tool bug fix: fixed the column headers on the »attachments« tab.

2015-04-10 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: implemented opening files via drag & drop from external applications.
* MKVToolNix GUI: enhancement: The portable Windows version will store its settings in a file in the same folder instead of the registry.
* MKVToolNix GUI: enhancement: Qt's »Windows Vista« style is now used on Windows instead of the old, Windows 98-like »Windows« style.
* MKVToolNix GUI: merge tool enhancement: The merge tool has been re-written to be tabbed like the header and chapter editors allowing for multiple merge job settings to be open at the same time.

2015-04-08 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: implemented re-ordering chapters and editions with drag & drop.

2015-04-06 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: implemented the chapter editor.

2015-04-04 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: implemented adding attachments via drag & drop from external applications.
* MKVToolNix GUI: new feature: implemented the header editor.

2015-04-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Implemented proper type output during identification for DTS-ES (extended surround) tracks. Implements #1157 (https://github.com/mbunkus/mkvtoolnix/issues/1157).

2015-03-31 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: implemented the online update check.

2015-03-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The calculation of the width and height of h.265/HEVC video tracks did not take the conformance window (cropping) into account. Fixes #1152 (https://github.com/mbunkus/mkvtoolnix/issues/1152).
* mkvmerge: bug fix: Fixed the value of the DocTypeVersion header field if any of the Matroska elements CodecDelay, DiscardPadding or SeekPreRoll is used. This is the case for Opus tracks.
* mkvmerge: bug fix: Fixed the handling of E-AC3 tracks in M2TS files if the AC3 core and the extension are stored in separate packets.
* mkvmerge: new feature: Implemented support for the DTS-HD container format.

2015-03-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Implemented support for core-less DTS streams consisting solely of XLL extension sub-streams.
* mkvmerge: new feature: track selection can be done by language codes as well. Affects the options --audio-tracks, --button-tracks, --subtitle-tracks and --video-tracks. Works only for containers that actually provide a language tag. Implements #1108 (https://github.com/mbunkus/mkvtoolnix/issues/1108).
* source code: bug fix: Accidental uses of the »long double« type have been converted to normal »double«s. This fixes compilation on platforms which don't support the »long double« type in combination with Boost::Math. Fixes #1150 (https://github.com/mbunkus/mkvtoolnix/issues/1150).

Have fun.

[Keiyakusha]

Hey guys. I just tried new MMG GUI and have a few questions. All of these might not be implemented yet, I'm totally fine with that, but I'm still curious.
1) In "Tracks, chapters, tags and attachments" form, how do I re-arrange stream positions?
2) How do I terminate muxing mid-way?
3) How do I disable statistics? (Such as NUMBER_OF_FRAMES, NUMBER_OF_BYTES, _STATISTICS_WRITING_APP etc.)

[Overdrive80]

Any tool for converting mmg option file to new version (mtxcfg)??

[sneaker_ger]

1) In "Tracks, chapters, tags and attachments" form, how do I re-arrange stream positions?
2) How do I terminate muxing mid-way?
3) How do I disable statistics? (Such as NUMBER_OF_FRAMES, NUMBER_OF_BYTES, _STATISTICS_WRITING_APP etc.)
1. Drag&Drop
3. Output options, Additional options (bottom right corner), check --disable-track-statistics

[Zenitram]

3) How do I disable statistics? (Such as NUMBER_OF_FRAMES, NUMBER_OF_BYTES, _STATISTICS_WRITING_APP etc.)

Please don't, such statistics are useful for people who get your file (and they use so little place in the file).

[Sparktank]

Thanks for the hefty update, Mosu!

[Keiyakusha]

1. Drag&Drop
Ouch... should have tried this myself... >__<

3. Output options, Additional options (bottom right corner), check --disable-track-statistics
Yep, this is it, totally missed it. Thanks!

Please don't, such statistics are useful for people who get your file (and they use so little place in the file).

Currently is looks like this (see at the bottom of this post). Only NUMBER_OF_FRAMES provides information that is not already available and still I don't find it useful. In case number of frames matters, most likely I am going to edit the content and have other means to know this information. Thus I consider all of this statistics to be completely useless.

Format : Matroska
Format version : Version 4 / Version 2
File size : 221 MiB
Duration : 8mn 47s
Overall bit rate : 3 506 Kbps
Encoded date : UTC 2015-05-10 15:20:02
Writing application : mkvmerge v7.9.0 ('Birds') 64bit
Writing library : libebml v1.3.1 + libmatroska v1.4.2
DURATION : 00:08:47.744000000
NUMBER_OF_FRAMES : 24738
NUMBER_OF_BYTES : 6590628
_STATISTICS_WRITING_APP : mkvmerge v7.9.0 ('Birds') 64bit
_STATISTICS_WRITING_DATE_UTC : 2015-05-10 15:20:02
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

[Mosu]

Hey guys. I just tried new MMG GUI and have a few questions. All of these might not be implemented yet, I'm totally fine with that, but I'm still curious.
1) In "Tracks, chapters, tags and attachments" form, how do I re-arrange stream positions?
2) How do I terminate muxing mid-way?
3) How do I disable statistics? (Such as NUMBER_OF_FRAMES, NUMBER_OF_BYTES, _STATISTICS_WRITING_APP etc.)

Questions are more than welcome.

Via drag & drop: select a track, drag to new position. Same applies for files & re-ordering them. You can also select multiple tracks & drag and drop them, but only if they're all on the same level (e.g. you cannot drag & drop a non-appended and an appended track at the same time). You can also not change the level (you cannot convert an appended track to not-appended and vice versa).
Select the »Job output« tool and hit the »Cancel« button.
Select the »merge« tool. Go to the »Output« tab. On the lower right you'll find »Additional options«. Here you can either add »--disable-track-statistics-tags« manually or click the button to the right of the input. That'll show a popup where you can select such options. It's the equivalent of the old GUI's »add additional command line options« menu entry.

[Mosu]

Any tool for converting mmg option file to new version (mtxcfg)??

No, and none will be coming. It's too much work, and I have a lot of things still left to implement that I consider of higher priority. Sorry.

[Mosu]

Currently is looks like this (see at the bottom of this post). Only NUMBER_OF_FRAMES provides information that is not already available and still I don't find it useful. In case number of frames matters, most likely I am going to edit the content and have other means to know this information. Thus I consider all of this statistics to be completely useless.

Note that BPS is also one of those tags. MediaInfo doesn't list it as »BPS«, but I guess that the value from »BPS« is displayed as »Overall bit rate«.

Note further that the track's duration (»Duration«) is yet another of those pieces of information that won't be available if you disable the statistics. The track's duration is also different from the file's duration.

I'm not trying to start a discussion about the (lack of) usefulness of those tags, but the facts are that without those tags there's no way to determine:

the amount of bytes in a track,
the amount of blocks ( = frames/fields) in a track,
a track's duration (Matroska only stores a duration for the whole segment and that may differ a lot from each track's duration, especially if you have overlong subtitles),
due to the points above: the track's effective bit rate

Before the tags were introduced MediaInfo used to guesstimate both a track's duration and its effective bit rate. That heuristic was often off and the source for much confusion.

[ndjamena]

You're not supposed to be able to see the Track Statistic tags, it's just MKVMerge/MMG/MediaInfo weren't designed to handle them properly and currently it's a mess. Duration and Number of Bytes are only already available if you either have only a single track in the file or (for Number of Bytes) have only a single Variable bitrate stream (even then if the duration of just one of the tracks is significantly less than the file duration all of MediaInfos current output is worthless).

There's also a BPS tag that you're not seeing because MediaInfo has been programed to hide it, which is what it should be doing to all of them but Zenitram hasn't gotten around to writing the necessary code yet.

The Tag handling should have been fixed long ago, but no one has had the time thus far. Things will get better and your current files without the tags will become outdated.

[Zenitram]

Zenitram hasn't gotten around to writing the necessary code yet.

And I apologize for that. It will be past soon.

[Keiyakusha]

You're not supposed to be able to see the Track Statistic tags, it's just MKVMerge/MMG/MediaInfo weren't designed to handle them properly and currently it's a mess.
Yes, mediainfo output might be not perfect, but my point was that the information in these statistics fields is redundant. Changing mediainfo output may improve the overall mediainfo experience but it won't make the statistics information itself any more useful. (Also personally I don't want statistics to be hidden in mediainfo, or at least indication that they are present in a file)
I think without statistics mediainfo is doing great job displaying all truly relevant information.

Still, even knowing this, and the stuff that Mosu mentioned in the post above, I don't want this information to be present in my files. And if someone receives files from me, he is not supposed to do anything with them anyway (except playback of course)

[ndjamena]

And I apologize for that. It will be past soon.

FFMPEG needs to updated too, and MKVMerge. Be sure to remove everything in the _STATISTICS_TAGS tag and not just the individual tags for forward compatibility.

FFMPEG lists each tag twice, which is annoying and can only compound the general distaste for the tags.

MKVMerge lists them twice as well, once in the "Track Info" and once in the "Track Tags" list. That should change. Actually, according to the specs "TargetTypeValue" (50/60/70) and TargetType (EPISODE/MOVIE) aren't mandatory and really shouldn't be used for the Statistic Tags. I don't know if it does already or not but MKVMerge should probably verify the tags before outputting them and ignore them if they don't pass, and NOT output the security tags (tags starting with "_").

The whole thing needs to be cleaned up before people should be expected to accept them.

-edit- Oh, "TargetTypeValue" has a "default" of "50" (although looking at Tag "defaults" is dangerous business), but target type can be left out completely (and I do object to have MOVIE tags in my TV EPISODES.)

[ndjamena]

Yes, mediainfo output might be not perfect, but my point was that the information in these statistics fields is redundant. Changing mediainfo output may improve the overall mediainfo experience but it won't make the statistics information itself any more useful. (Also personally I don't want statistics to be hidden in mediainfo, or at least indication that they are present in a file)
I think without statistics mediainfo is doing great job displaying all truly relevant information.

Still, even knowing this, and the stuff that Mosu mentioned in the post above, I don't want this information to be present in my files. And if someone receives files from me, he is not supposed to do anything with them anyway (except playback of course)

If you came into this sometime in the future, when the Stat tags were fully mature and hidden, would you care if they were there or not or are you just making arguments based on prejudices caused by the current situation?

[Keiyakusha]

If you came into this sometime in the future, when the Stat tags were fully mature and hidden, would you care if they were there or not or are you just making arguments based on prejudices caused by the current situation?
I would care, assuming I did some research during which I figured out that they exist and what they are for. I think this is similar to x264's SEI information which some people prefer to remove (or use a modified build that doesn't creates it to begin with)

[ndjamena]

Right, I figured out why I thought "TargetTypeValue" could be left out.

This is from a FFMPEG Track tag extracted using MKVExtract:

<Targets>
<TrackUID>1</TrackUID>
</Targets>


I don't know what that means, and since it's the Matroska tagging system I'd rather not know.

But unless I'm missing something in the specs "TargetType" should be able to be left out completely.

[hello_hello]

Thanks for the new version, but........

When trying to run both mmg.exe and mkvtoolnix-gui.exe on XP (downloading mkvtoolnix-32bit-7.9.0.7z) I get the following error:

Entry Point Not Found
The procedure entry point RegGetValueA could not be located in dynamic link library ADVAPI32.dll

[Mosu]

Windows versions prior to Windows Vista are not supported anymore (and haven't been for a couple of releases now).

[filler56789]

Windows versions prior to Windows Vista are not supported anymore (and haven't been for a couple of releases now).

That's a shame indeed. A Matroska multiplexer should have nothing to do with the pesky Windows Registry, to begin with :)

[hello_hello]

Windows versions prior to Windows Vista are not supported anymore (and haven't been for a couple of releases now).

That's odd, as I've been using MKVMergeGUI on XP. Is that mentioned in the changelog somewhere? I can't find it.

mmg.exe from (portable) versions 7.8.0, 7.7.0 and 7.6.0 all run happily on XP. Was it decided to deliberately prevent MKVMergeGUI from running on it?

The timing seems a shame, considering the final version of the new GUI isn't far away. It would have been nice to have the first "non-beta" version working on XP before XP support was dropped.

What about mkvmerge.exe? Programs such as MeGUI use it for muxing. Should I be preventing MeGUI from updating it to version 7.9.0 so I won't find MeGUI suddenly incapable of MKV muxing?

Thanks.

Edit: I tested the last part and no, MeGUI can't mux MKVs if I update MKVMerge to 7.9.0. It seems the maintainer of MeGUI might be unaware of the lack of XP support as MeGUI updated MKVMerge to 7.8.0 when it was released, but fortunately that version does work on XP so no harm there so far.

[Mosu]

Over a year ago I've said a couple of times that I would not spend time on Windows XP support anymore. Windows XP isn't supported by Microsoft anymore either, so why should I? It's insecure, it will stay that way, and I have to set limits to what I can and do support.

I haven't done anything actively in order to prevent things from running on Windows XP. They simply turned out not to anymore, as it seems. Not supporting Windows XP simply means that I will not hunt down the reason for this.

There's a cost to such backwards compatibility. To some it may seem small, but finding the reason why e.g. mkvmerge suddenly doesn't run there anymore? Far from trivial. Maybe even impossible for me if it's due to Qt.

I usually don't mention dropping support for certain operating system versions in the ChangeLog unless there's a conscious decision involved like e.g. requiring function XYZ that's only available in OS version 29 and later. In this case no such decision was made; hence no ChangeLog entry.

[hello_hello]

That's a shame indeed. A Matroska multiplexer should have nothing to do with the pesky Windows Registry, to begin with :)

I'll confess of all the programs to drop XP support, I'd have thought a muxing program would be right at the end of the list still working when almost no other current software does, especially as Win2000 was still supported up to about a year and a half ago, but what do I know..... I don't write software. :(

[filler56789]

That's odd, as I've been using MKVMergeGUI on XP. Is that mentioned in the changelog somewhere? I can't find it.

From the build 726's changelog:

2015-04-10 Moritz Bunkus <moritz@bunkus.org>

* MKVToolNix GUI: enhancement: Qt's »Windows Vista« style is now used on Windows instead of the old, Windows 98-like style.

[Mosu]

I'm pretty sure that that change isn't responsible. Qt draws its own controls and can make them look like anything. You can select the Vista style on Linux, the Windows 95 style on Vista or the Linux style on Windows 8.

[filler56789]

Apologies for the bad guess.
Anyway, so it's time to finally move house to my Windows 7 (yuck) machine...

[hello_hello]

Over a year ago I've said a couple of times that I would not spend time on Windows XP support anymore. Windows XP isn't supported by Microsoft anymore either, so why should I?

There's the "new GUI is just around the corner" reason for continuing XP support until the first stable version is released. That'd at least allow XP users to run one version of the new GUI for the rest of eternity.
Honestly, I get some of the reasons for not supporting XP, but when it comes to Microsoft not supporting it I have no idea what one has to do with the other, given more people still use XP than Vista and Windows 8 and Windows 8.1 combined (according to Wikipedia and the breakdown of computers connected to the internet, although I suspect there's an even larger number of PCs still running XP that aren't used for browsing). I think that should carry more weight than Microsoft's fiscal policy, but I don't write software..... ;)

(I've run XP without a software firewall, without an antivirus program, without an anti-anything program for years without getting infected, just me, Firefox, XP and a router, so I honestly don't get the "insecure" argument either, but that's a whole other debate....... :))

I just see it as a bit of a pity no software writers seem to take a stand a say "well that new version of Windows is a piece of %^#$ and I won't support it", instead helping to force people to upgrade their non piece of %^$% Windows version instead, but as I said, what do I know? I don't write software...... :)

I usually don't mention dropping support for certain operating system versions in the ChangeLog unless there's a conscious decision involved

Now I'm aware of that I'll assume any new version of mkvtoolnix will fail to work without warning unless I'm running the latest version of Windows and upgrade it far more cautiously in the future. ;)

Thanks.

PS. I'm not trying to appear ungrateful, or demanding (hence all the smileys), and it's your time to spend as you so choose, and mkvtoolnix is very, very, very much appreciated as I use it pretty much daily (one of the reasons no support for XP is disappointing for me as even when I build a new Win7 PC in the near future the old PCs will still continue to run XP), but I'm just offering a "user" perspective...... as someone who doesn't write software it's the only one I've got. ;) :)

[Chetwood]

Can anyone point me to the proper QT 'library' to install to get the new GUI? I've installed 5.4.1 and am stil getting the old one on Win 8.1. Thx.

If you came into this sometime in the future, when the Stat tags were fully mature and hidden, would you care if they were there or not or are you just making arguments based on prejudices caused by the current situation?
I don't have any use for stats either and since I'm not sure how they may affect playback on standalones, I've turned them off just as I have done with the cue tags.

And I apologize for that. It will be past soon.
While you're at it would you mind and reconsider outputting reports with ALT+E to the same dir as the file the report is written on? It still makes no sense to have this written to the program dir of all places. Thx.

[Mosu]

Can anyone point me to the proper QT 'library' to install to get the new GUI? I've installed 5.4.1 and am stil getting the old one on Win 8.1. Thx.

You don't have to install Qt yourself. All you have to do is execute mkvtoolnix-gui.exe instead of mmg.exe (start menu entry »MKVToolNix GUI«).

[burfadel]

There's the "new GUI is just around the corner" reason for continuing XP support until the first stable version is released. That'd at least allow XP users to run one version of the new GUI for the rest of eternity.
Honestly, I get some of the reasons for not supporting XP, but when it comes to Microsoft not supporting it I have no idea what one has to do with the other, given more people still use XP than Vista and Windows 8 and Windows 8.1 combined (according to Wikipedia and the breakdown of computers connected to the internet, although I suspect there's an even larger number of PCs still running XP that aren't used for browsing). I think that should carry more weight than Microsoft's fiscal policy, but I don't write software..... ;)

(I've run XP without a software firewall, without an antivirus program, without an anti-anything program for years without getting infected, just me, Firefox, XP and a router, so I honestly don't get the "insecure" argument either, but that's a whole other debate....... :))

I just see it as a bit of a pity no software writers seem to take a stand a say "well that new version of Windows is a piece of %^#$ and I won't support it", instead helping to force people to upgrade their non piece of %^$% Windows version instead, but as I said, what do I know? I don't write software...... :)



Now I'm aware of that I'll assume any new version of mkvtoolnix will fail to work without warning unless I'm running the latest version of Windows and upgrade it far more cautiously in the future. ;)

Thanks.

PS. I'm not trying to appear ungrateful, or demanding (hence all the smileys), and it's your time to spend as you so choose, and mkvtoolnix is very, very, very much appreciated as I use it pretty much daily (one of the reasons no support for XP is disappointing for me as even when I build a new Win7 PC in the near future the old PCs will still continue to run XP), but I'm just offering a "user" perspective...... as someone who doesn't write software it's the only one I've got. ;) :)

Why should Microsoft continue supporting an OS from 2001? It seems counter-intuitive insisting on having the latest MKV tools if you are still running at ancient OS (it is ancient).

Microsoft is going to a continuous support model starting with Windows 10. So, if you don't want to be left out, upgrade to Windows 10 when it comes out :). It might not be called Windows 10 in 6 years, but you will have an upgrade path from base Windows 10.

Continuous support of XP is just an encouragement for people to stick with XP, and is a waste of money and resources.

Also, how do you know you don't have any malicious software on your computer if you don't have any means of knowing it is there?

[nevcairiel]

Honestly, I get some of the reasons for not supporting XP, but when it comes to Microsoft not supporting it I have no idea what one has to do with the other, given more people still use XP than Vista and Windows 8 and Windows 8.1 combined (according to Wikipedia and the breakdown of computers connected to the internet, although I suspect there's an even larger number of PCs still running XP that aren't used for browsing).

Those stats are mostly tainted by companies who got stuck because they use some equally ancient software. Its unfortunate, but we do not have stats on "personal" PCs alone.

On the topic at hand, especially when developing a new UI, trying to support XP gets rather annoying fast, as there are a whole bunch of new things you can use if you don't, so I wouldn't expect especially new software to support XP at all anymore. Who would want to spend extra time on that?
(PS: its not limited to UI either, there is a long list of things that got improved in the win32 API in later versions of windows, from UI, to threading, to file access)

Personally for myself, I'll drop XP support the moment it can save me a couple hours time or a few headaches to do so. If i were to write something new, I would never even bother to try to support it at all.

[foxyshadis]

Supporting XP also means having an XP system, and even if it's a VM it can still be a pain to trot it out to re-run your testing and debugging on it every build. If you care about such things and don't have a Win7 Pro/Enterprise, that might also mean licensing costs. XP users have to realize that they're the burden now, and they can't just argue for support, it's become pony up cash or watch software pass you by. It's almost as ridiculous as IanB sticking to VC6 until just a couple of years ago.

Mosu most likely has better stats on his userbase than anyone else, anyway, no matter what the wide world looks like. I guess it's time to make a big red banner on the update post that XP is reported to not work.

[stax76]

one of the reasons no support for XP is disappointing for me as even when I build a new Win7 PC

Are you seriously saying you want to upgrade from the old WinXP to the new WinXP (Win7 == new WinXP)? Here in Germany Win7 still costs minimum 60€, the real retail Version (no Dell crap that is often pirated I believe) is still above 100€ I believe. Win10 on the other hand is free for Windows Insiders and for the first year and as long as you don't have to reinstall you can use it for free for ten years or more. Some might think the first year is free like the first heroin is free and it might be true that after the first year it will be as expensive as MS office is now but it's still likely possible to run it the next ten years for free.

[Mosu]

Folks please. This is not a thread about a general discussion between the pros and cons of various Windows versions. A couple of points have been made. Please let's leave it at that and return to the thread's intended topic: MKVToolNix.

Thanks.

[sneaker_ger]

So, what exactly caused the XP incompatibility? Some library update or just a simple compiler switch? Esp. if it's the latter it could be useful for people looking into building their own XP-compatible binaries.

(Disclaimer: I don't use anything older than Win 7)

[Mosu]

I don't know. Figuring that out is part of the cost of that »support for Windows XP« thingy.

[ndjamena]

New chapter editor... Can it auto-select the first name in the list when a chapter is highlighted? This is painful.

(or the first one the first time and the closest to the currently selected the next time... or whatever, just not this.)

[Mosu]

Actually I did it that way at first, but that totally destroyed keyboard navigation in the tree. The latter is a complaint that has been raised against the old GUI as well; therefore I decided not to auto-set the focus.

[ndjamena]

Not set the focus to the chapter name field, I mean automatically select a chapter name from the list, rather than having the Name/Language/Country greyed out (nothing selected).

[Mosu]

Ah, sorry. I misunderstood. I'll do something about that, but not right now (let's say within two releases).

[ndjamena]

OK then, I can't use it like this, so I'll switch back to MMG for now.

-edit- cool, keyboard navigation works now!

[qyot27]

So, what exactly caused the XP incompatibility? Some library update or just a simple compiler switch? Esp. if it's the latter it could be useful for people looking into building their own XP-compatible binaries.

(Disclaimer: I don't use anything older than Win 7)

I don't know. Figuring that out is part of the cost of that »support for Windows XP« thingy.

Since it's what the error message complains about, it's more than likely the use of RegGetValueA (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868%28v=vs.85%29.aspx) in src/common/fs_sys_helpers/windows.cpp @ line 146. That function is Vista+ (or seemingly 2k3+).

Supporting XP in that instance would mean using a different registry querying function. RegQueryValueEx, as the answers on SO point to, but I doubt the actual parameters taken by RegQueryValueEx vs. RegGetValue are the same, so it'd require special-casing to support both (or simply an option to disable registry support at configure time so it doesn't build that part at all - which might make some degree of sense for portable builds, regardless of any OS version squabbling).


I haven't tried doing this in several years, but Wine could be used to patch over XP itself to avert this (http://wiki.winehq.org/WineOnWindows). Wine can run 7.9.0 seemingly without problems*, since it implements support for higher versions of the Windows program APIs (if the OS itself was stable enough, it'd probably work swimmingly in ReactOS as it has a symbiotic relationship with Wine for program support while currently targeting NT kernel version 5.2). You just have to cross-compile Wine's DLLs under MinGW-w64 so that it routes the calls into win32. It could probably also be done under MSys2 or Cygwin.

*obviously, I'd normally just use the native build instead if I'm logged in under Ubuntu, but not everyone wants to switch their XP machines to Linux.

I had to resort to doing this in 2011 for a game that kept crashing using the Microsoft DirectX runtime. After I got Wine's d3dx9_43.dll built I dropped it into the game's directory, and everything was peachy. Since Windows prioritizes DLLs in a program's home directory, it'll use those before it tries the ones from the system. So if a cross-compiled copy of Wine's ADVAPI32.dll were in there, it'd more than likely work as-is without specific XP support. Provided that ADVAPI32.dll itself doesn't require more of the Wine DLL ecosystem.


EDIT: after testing a cross-compiled Wine (1.7.42-137-g6d323d8), that trick won't work atm. Windows is either smart enough to not load *those* particular .dlls from the application directory, or we're going to need a much more complete WineOnWindows environment (read: wine.exe itself, which the limited cross-compiling support in Wine can't do yet) to be able to do anything regarding that. But really, going to that much trouble generally isn't worth it when you can run an up-to-date version of [insert Linux distro name here] on the same machine and use the native build of MKVToolNix just fine. For ancient setups like mine, that's pretty much the only thing you can do short of just staying back at 7.8.0. The jury's still out on ReactOS since right now I don't have access to the VM I normally use, but ROS is still not anywhere close to stable for daily use.

[filler56789]

Since it's what the error message complains about, it's more than likely the use of RegGetValueA (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868%28v=vs.85%29.aspx) in src/common/fs_sys_helpers/windows.cpp @ line 146. That function is Vista+ (or seemingly 2k3+).

Already available in "Windows XP Professional x64 Edition", according to that same page (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868%28v=vs.85%29.aspx).

[Mosu]

Not set the focus to the chapter name field, I mean automatically select a chapter name from the list, rather than having the Name/Language/Country greyed out (nothing selected).

I've implemented something along these lines in pre-build 729 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/). Is this what you had in mind?

[hello_hello]

Folks please. This is not a thread about a general discussion between the pros and cons of various Windows versions. A couple of points have been made. Please let's leave it at that and return to the thread's intended topic: MKVToolNix.

Just a post to answer some questions asked of me then I'll leave it at that.

Why should Microsoft continue supporting an OS from 2001? It seems counter-intuitive insisting on having the latest MKV tools if you are still running at ancient OS (it is ancient).

I never said they should. I simply said I don't see any direct relationship between the version of Windows software should run on and whether that version is still supported by Microsoft. The "old OS" argument breaks down for me when you compare it to a "number of users" argument which at the moment still includes something like 15% of PC users, while supporting OSs with a combined market share of something like 3%. If you could show me stats along the lines of "98% of people downloading converting/muxing software run Win7 or newer", then that'd possibly be a different story.

I'm not insisting on anything, but I'd like a warning if a new version won't run on a particular flavour of Windows so I know not to upgrade, find it won't run, post in the mkvtoolnix forum about the problem thinking I'm contributing to bug fixing in a small way, only to be told to &%$ off and upgrade Windows. :)

Also, how do you know you don't have any malicious software on your computer if you don't have any means of knowing it is there?

Once every year or so I install antivirus software and run a full scan. Just to see what it'll find. Then I restore the previous year's Windows and programs image, update everything and make a new image. I've been doing that for years and the scans have never found anything worse than a few naughty cookies.

Are you seriously saying you want to upgrade from the old WinXP to the new WinXP (Win7 == new WinXP)?

Maybe I'd be happy if Win XP had been like Windows 10. Free to use and perpetually upgrade, or however it'll work. ;)
I'll possibly upgrade to Win7 initially because I have a legit copy that was given to me that's never been used and there's no XP drivers for the MB I want. I've not looked closely at Win10 yet.

[qyot27]

Already available in "Windows XP Professional x64 Edition", according to that same page (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868%28v=vs.85%29.aspx).
64-bit XP Pro is not the same OS as 32-bit XP. The 64-bit edition is derived from 2k3 (so I did technically include it in that 2k3+ addendum). Most XP users aren't using the 64-bit edition, though.

[Chetwood]

All you have to do is execute mkvtoolnix-gui.exe instead of mmg.exe (start menu entry »MKVToolNix GUI«).
Thanks. Being a windows user I skipped over any and all mentions of the command-line as usual ;)

I also think, XP is over, also because M$ offered Win 8 licenses for only 30 € for a while.