gMKVExtractGUI

[gpower2]

New version 1.7.0 is out, fixing the issue with the mkvinfo gui popup with the new MKVToolNix version v9.0.0, and adding an option for not showing the success popup messagebox.

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v1.7.0/gMKVExtractGUI.v1.7.0.7z/download

Changelog:

Add support for the new --no-gui parameter of mkvinfo for MKVToolNix v9.0.0 and newer, without breaking compatibility with older MKVToolnix versions
Add option to not show the success popup messagebox
Add setting for showing or not the success popup messagebox


It's not just that it's a pop-up (as a matter of fact, I get two pop-ups), it adds a huge delay to opening a file with gMKVExtractGUI. I have to wait a while for the first mkvinfo to do its work, then I close it, another mkvinfo window pop ups which then takes a while analysing my file...

This is an issue because of a change in MKVToolNix's v9.0.0 default behavior for mkvinfo. It's fixed in new version (v1.7.0) ;)

Second this, needing to close a popup every time is becoming a bit irritating. It is a common GUI design guideline that informational messages should go into a status bar in an unobtrusive way. Only errors should invoke a modal dialog box to specifically attract user's attention to the fact that his intent was not accomplished and he must take some further actions.

I couldn't disagree more with this. In fact I get really frustrated when applications use this design, since most of the time I don't sit in front of the application's status bar, waiting for it to get to 100%, but I do other stuff, expecting a signal from the app that the process is finished.
However, since it wasn't difficult to implement, I added an option for changing the default behavior in the new version (v1.7.0), so I am waiting for feedback! :p


Enjoy people! :D

[alfixdvd]

Thanks for the update.

[Telion]

@gpower2

Big thanks for adding that option!

Can you please consider making another small UX enhancement and add a big "Close" button rightward of "Abort" one? Then after a job is done it would be convenient to move the mouse just a little from the previously pressed "Extract" button to exit the app without going all the way up to that small "X" or resorting to keyboard.

And maybe it would be also worth to allow a user to immediately paste a full filename into the "Input file" field and press Enter to load it without the need to open the "Browse..." dialog first.

[Wildfire]

Thanks for the update, all is okay again! :)

[Solon8]

I couldn't disagree more with this. In fact I get really frustrated when applications use this design, since most of the time I don't sit in front of the application's status bar, waiting for it to get to 100%, but I do other stuff, expecting a signal from the app that the process is finished.
However, since it wasn't difficult to implement, I added an option for changing the default behavior in the new version (v1.7.0), so I am waiting for feedback! :p

Thank you for implementing this.

My only suggestion, but I'm not sure everyone agrees, would be to keep the sound signal. I was just lazy to click the popup, but I didn't mind the sound to tell me processing was over.

[TheShadowRunner]

Great app, just wished I could reduce its height/width by quite a margin (current hardcoded minimum is too big imho).

[Mosu]

@gpower2: Why are you invoking mkvinfo in the first place? mkvinfo is NOT designed to be the source of information for other programs. There are several reasons: for example it only reports elements that are actually present (e.g. mkvinfo might not show a "language" element for a track which means that the track's language is actually "eng"), nor does it show elements located after the first cluster by default (e.g. it won't show tags if they're located at the end) – unless you make its output verbose in which case it outputs everything from the file which takes a long time.

mkvmerge's identification output is actually what you should use instead, especially since I've implemented JSON output for it (mkvmerge --identification-format json --identify yourfile.mkv). Its output IS designed to be parsed by other applications, it will handle absent elements with default values properly (e.g. it will show "eng" as a track's language if the track does not actually contain a "language" element), and it will show all elements (tags, chapters, attachments…) no matter where they're located. In less time than mkvinfo's verbose output would.

On top of that I'm very careful not to change mkvmerge's behavior regarding the identification output. Such a change like mkvinfo's regarding the GUI wouldn't have affected gMKVExtractGUI if it had used mkvmerge instead.

So… what are you using mkvinfo for that mkvmerge doesn't give you? I'm really curious if there's something missing in mkvmerge's output that I could add for you.

[gpower2]

@Mosu
I just replied in the GitHub issue! I guess great minds think alike! :p
gMKVExtractGUI uses mkvinfo's output in order to determine the relative delay between video and audio tracks. This information cannot be determined from mkvmerge's output. I also use mkvinfo's output to get the CodecPrivate value for each track segment.

To be honest, until recently, I hadn't noticed that you meticulously added the version information in the executables, so I wasn't sure I could robustly detect the version of MKVToolNix that the user uses. However, now that I know that, I can be more flexible about which options to use and when, so if you could add these extra information in mkvmerge's output, that would be perfect! :)

Thanks for showing interest in a MKVToolNix's "byproduct"!

[Mosu]

Thanks for the feedback. CodecPrivate is already included in mkvmerge's identification output, but the relative delay isn't.

That one's a bit tricky to implement, too. In general I don't want identification to be quick (it's already taking a long time due to all the different file types it supports). Scanning the file for the minimum timecode for each track is time consuming, and I definitely don't want to do it for each and every file as most people wouldn't need that information. I could introduce some kind of flags that enable deeper inspection of the file.

How do you handle e.g. subtitle tracks at the moment? Their first timestamp could be almost anywhere within the file.

[gpower2]

Well, I guess when I was asked to include CodecPrivate, mkvmerge didn't output it, or I was lazy enough not to check for it! :p

As for the relative delay, it was indeed quite tricky to quickly determine it. I only try to find the relative delay for video and audio tracks, and not subtitle tracks, since this information isn't really useful to anyone.
In order to find it, I execute mkvinfo with --check-mode option, parsing its output line by line, trying to match this regex:
"track number {0}, \d frame\(s\), timecode (\d+\.\d+)s"
I then check if the delay (first timecode) is for a video track or for an audio track, assuming that there is only one video track for the file.
After I find the delays for all the tracks, I kill mkvinfo process, in
order to not waste time, and calculate the relative delay for the audio tracks.
Most of the times, video tracks have 0 delay, so the audio tracks' relative delay is the same as their first timecode. If video track has a delay greater than 0, then audio tracks' relative delay is calculated as track's delay minus the video track's delay.

I know it's way hacky, but it was the fastest and only way to get this information. If you have a better way of determining this, I'm all ears! :)

PS.
This procedure is executed immediately after getting mkvmerge's identify output, so I already have a list of the tracks and their types, in order to get the info I want from mkvinfo's output and then kill it immediately.

[Mosu]

Well, I guess when I was asked to include CodecPrivate, mkvmerge didn't output it, or I was lazy enough not to check for it! :p

It was first included in version… uhm…

In the JSON output it looks like this:

"codec_private_data": "014d4033ffe10017674d40339a7405016d808800000303e80000bb5478c19501000468ee3c80",
"codec_private_length": 38,

The data itself is a hexdump. For tracks that don't have a CodecPrivate element these two elements aren't output.

As for the relative delay…

I'm current implementing the following mechanism:

mkvmerge will always try to find the minimum timestamp for each track. It will process at most five seconds of data before giving up. If a timestamp is found for a track then it will be reported as "minimum_timestamp" (a number in nanoseconds) in the identification output. If no timestamp was found within the probing window (e.g. for subtitles that only start later) the element won't be present. The probing process will be aborteed as soon as five seconds of content have been observed (as stated above) or as soon as a timestamp has been found for every track, whichever happens first.

The timestamp reported will not necessarily be the first one for a track. For example, a video track may start with a B frame with a higher timestamp than the I frame coming shortly after it. mkvmerge will really report the minimum of what it finds.

Would that be useful to you? If so I can provide new pre-builds for testing soon.

[stax76]

Note from another mkvtoolnix GUI programmer :) : In StaxRip I had a huge messy function growing over the years parsing mkvinfo output, 1-2 years ago I rewrote it using MediaInfo for audio and video replacing the messy function with clean OOP and added a demuxing GUI for mkv and mp4. For chapters and attachments I still use the old mkvinfo output parsing.

[Mosu]

Note that I make no guarantees whatsoever that the track IDs mkvmerge requires will match the ones that MediaInfo outputs. I only guarantee that the IDs that mkvmerge's identification outputs are the ones you need to use with mkvmerge and mkvextract. Only mkvmerge knows which tracks it supports; MediaInfo can only guess and may get it wrong. It usually doesn't, but that's no guarantee. You've been warned.

[stax76]

For a GUI that supports all kinds of formats and tools MediaInfo is a blessing, anything else in this situation would be a mess. One thing tricky I noticed and worked around is that MediaInfo works with 'TrueHD/AC3' as single stream ID and mkvmerge splits it into two. I just hope my code works and if it don't, hope that people report issues and fixes won't introduce new issues.

[gpower2]

It was first included in version… uhm…

In the JSON output it looks like this:

"codec_private_data": "014d4033ffe10017674d40339a7405016d808800000303e80000bb5478c19501000468ee3c80",
"codec_private_length": 38,

The data itself is a hexdump. For tracks that don't have a CodecPrivate element these two elements aren't output.

Actually the CodecPrivate that I use from mkvinfo is like this: "length 45 (h.264 profile: High @L4.1)".
I don't actually need the codec_private_data...

I'm current implementing the following mechanism:

mkvmerge will always try to find the minimum timestamp for each track. It will process at most five seconds of data before giving up. If a timestamp is found for a track then it will be reported as "minimum_timestamp" (a number in nanoseconds) in the identification output. If no timestamp was found within the probing window (e.g. for subtitles that only start later) the element won't be present. The probing process will be aborteed as soon as five seconds of content have been observed (as stated above) or as soon as a timestamp has been found for every track, whichever happens first.

The timestamp reported will not necessarily be the first one for a track. For example, a video track may start with a B frame with a higher timestamp than the I frame coming shortly after it. mkvmerge will really report the minimum of what it finds.

Would that be useful to you? If so I can provide new pre-builds for testing soon.

That actually sounds... perfect! :)
Perhaps you could only do this for video and audio tracks, since I can't think of a case where other track types would benefit from such information.
From my experience, it shouldn't take too long.
Actually, the procedure that I described you is almost instant, and it executes both mkvmerge and mkvinfo!

Thanks for your continuous support! :)

Note from another mkvtoolnix GUI programmer : In StaxRip I had a huge messy function growing over the years parsing mkvinfo output, 1-2 years ago I rewrote it using MediaInfo for audio and video replacing the messy function with clean OOP and added a demuxing GUI for mkv and mp4. For chapters and attachments I still use the old mkvinfo output parsing.

gMKVExtractGUI is supposed to be a complimentary application to MKVToolNix, with it and .NET framework as the only dependencies. Using MediaInfo would break this and also make it a lot more difficult to maintain, having to keep track of both MKVToolNix and MediaInfo versions.
I understand your decision for StaxRip, but it has a totally different purpose from gMKVExtractGUI. ;)

[Mosu]

I've just uploaded new pre-builds (https://mkvtoolnix.download/windows/pre/) that contain the change for "minimum_timestamp". I've decided on a 10 second search window which should pretty much always catch all audio and video tracks. Build numbers 01175 and higher contain the functionality.

Actually the CodecPrivate that I use from mkvinfo is like this: "length 45 (h.264 profile: High @L4.1)".

I see. That's probably not something I will make mkvmerge output.

[gpower2]

Thanks for the new pre-builds! :)
I will test it and come back with feedback ASAP!

[Mosu]

About the CodecPrivate thingy. mkvinfo outputs profile information for two codecs: AVC/h.265 and HEVC/h.265. Those can be easily gathered yourself by parsing the "codec_private" attributes mkvmerge outputs. Here's how.

AVC/h.264: trivial. Connvert the first four pair of hex numbers to four bytes. Then you get the following variables:

// bytes[0] is always 1 and can be ignored.
profile_idc = bytes[1];
profile_compat = bytes[2];
level_idc = bytes[3];

Then you can determine the profile and level strings like mkvinfo does (https://github.com/mbunkus/mkvtoolnix/blob/master/src/info/mkvinfo.cpp#L331).

For HEVC/h.265 is a bit more complicated, but not by much. Convert the codec private hex numbers to bytes. Then you'll need some specific bits. I'll write some pseudo code; see here for the code (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/hevc.cpp#L414) mkvinfo uses:

// Start reading at the start of the codec private bytes.
skip 8 bits (version number)
skip 2 bits (profile space)
skip 1 bit (tier flag)
profile_idc = read 5 bits
skip 32 bits (profile compatibility flags)
skip 1 bit (progressive source flag)
skip 1 bit (interlace source flag)
skip 1 bit (nonpacked constraint flag)
skip 1 bit (frame only constraint flag)
skip 44 bits (reserved)
level_idc = read 8 bits

And here's (https://github.com/mbunkus/mkvtoolnix/blob/master/src/info/mkvinfo.cpp#L350) how those numbers translate into the profile strings.

That way you don't even need to execute mkvinfo.

[gpower2]

That's amazing! :)
I didn't know that mkvinfo just parsed the codec private data and then presented it in a user friendly way!

It seems to me that now mkvmerge provides me with all the necessary information!

I will give it a try first thing in the morning! ;)

Thanks again Mosu!

[gpower2]

After testing pre build 01176, I have to say that the minimum timestamp works as expected! :)

However, I forgot that I also used mkvinfo to get some general info about the file:

Writing Application: mkvmerge v6.8.0 ('Theme for Great Cities') 64bit built on Mar 2 2014 21:34:26
Muxing Application: libebml v1.3.0 + libmatroska v1.4.1
Duration: 5979.008s (01:39:39.008)
Date: Sat Apr 12 17:44:19 2014 UTC

Is there any chance those information could also be added to the output of mkvmerge?

Thanks again! :D

PS.

Actually, I checked again and mkvmerge already provides most of the information, except the Date field, so if you could add it, that would be all I need! :)

[Mosu]

I've actually just added "writing_application" and "muxing_application" to the "container" section yesterday. They should both be available in the pre-builds. The "duration" has been present in the "container" section for a long time already. "date" isn't available yet, but I'll add it, again in the "container" section, albeit with a different format: I'll use ISO 8601 (https://en.wikipedia.org/wiki/ISO_8601).

[Mosu]

Pre-builds 01177 & higher (https://mkvtoolnix.download/windows/pre/) contain the two new fields "date_utc" and "date_local".

[hello_hello]

Enhancement request: Could you use a label at the bottom of the window, to signal that the demuxing was successful (instead of the popupbox) and use the popupbox for errors?

I can't find a valid reason to change the default behavior. What use case do you have in mind?

That sounds like something I may have complained about. ;)

I don't think the popup box was the problem for me as such, more that it creates an additional taskbar button if the GUI isn't in the foreground when the extraction finishes, but it doesn't when it is. I've returned to gMKVextract numerous times by clicking on it's taskbar button to find it's unresponsive until the penny drops and I hunt down the popup window. Could the original taskbar button be used to proclaim a job has completed successfully?
Would it also be possible to apply the "no popup" option to the job manager? With the job manager running it increases the taskbar button count to three.

I'm still using gMKVExtractGUI running on XP, if it makes any difference.

Thanks.

[gpower2]

I've actually just added "writing_application" and "muxing_application" to the "container" section yesterday. They should both be available in the pre-builds. The "duration" has been present in the "container" section for a long time already. "date" isn't available yet, but I'll add it, again in the "container" section, albeit with a different format: I'll use ISO 8601 (https://en.wikipedia.org/wiki/ISO_8601).
...
Pre-builds 01177 & higher (https://mkvtoolnix.download/windows/pre/) contain the two new fields "date_utc" and "date_local".

I've finished testing with the newest pre-build and now gMKVExtractGUI gets all the information it needs from mkvmerge! :)
I've also added gradual fallbacks, in order to be compatible with older versions. ;)
New version will be fully compatible with versions v4.x and newer!

Thanks again Mosu for your continuous hard work! :thanks:

Can you please consider making another small UX enhancement and add a big "Close" button rightward of "Abort" one? Then after a job is done it would be convenient to move the mouse just a little from the previously pressed "Extract" button to exit the app without going all the way up to that small "X" or resorting to keyboard.

And maybe it would be also worth to allow a user to immediately paste a full filename into the "Input file" field and press Enter to load it without the need to open the "Browse..." dialog first.

I think that the main form has already too many buttons, so adding another one that doesn't actually add a new functionality is a "no go" at the moment, sorry...
As for the input text box, I have thought of that myself, but it would require adding yet another button and a lot of event handling complexity, so I decided to not go that way.
You can still drag and drop files on the text box or the check box list. ;)

My only suggestion, but I'm not sure everyone agrees, would be to keep the sound signal. I was just lazy to click the popup, but I didn't mind the sound to tell me processing was over.

Indeed I was thinking about that myself, so I added it! :)

That sounds like something I may have complained about. ;)

I don't think the popup box was the problem for me as such, more that it creates an additional taskbar button if the GUI isn't in the foreground when the extraction finishes, but it doesn't when it is. I've returned to gMKVextract numerous times by clicking on it's taskbar button to find it's unresponsive until the penny drops and I hunt down the popup window. Could the original taskbar button be used to proclaim a job has completed successfully?
Would it also be possible to apply the "no popup" option to the job manager? With the job manager running it increases the taskbar button count to three.

I'm still using gMKVExtractGUI running on XP, if it makes any difference.

Thanks.

I added the "popup" checkbox in the Job Manager form and a new setting for it.
However I won't change the form's title since it will become really messy really quickly. In Windows Vista and newer, gMKVExtractGUI uses the new taskbar features that show the current task's progress.
Please update to a newer version of Windows since Windows XP is already more than 15 years old and I'm not sure Mosu or myself will continue to support it.

Great app, just wished I could reduce its height/width by quite a margin (current hardcoded minimum is too big imho).

I reduced the minimum size of the main form to 600x400 from 640x600. I believe that should cover it! ;)

[TheShadowRunner]

I reduced the minimum size of the main form to 600x400 from 640x600. I believe that should cover it! ;)
Thanks for this, but from 640x600 to 600x400 isn't quite enough, please allow 430x400 ? It's really the width that's an issue.

[gpower2]

Well, I changed the minimum size to 400x400 now, but I have to warn you that the layout of the "Actions" panel will be broken and I can't do much about it. ;)

Next version will probably come along with the new version of MKVToolNix.

[TheShadowRunner]

Well, I changed the minimum size to 400x400 now, but I have to warn you that the layout of the "Actions" panel will be broken and I can't do much about it. ;)
No worries whatsoever, thank you.

Next version will probably come along with the new version of MKVToolNix.
oh, I hope it'll still work alongside the good'ol mkvtoolnix v8.3.0..

[gpower2]

oh, I hope it'll still work alongside the good'ol mkvtoolnix v8.3.0..

Oh, it will! Next version will be compatible with all MKVToolNix versions from v4.x to v9.x+ ! :)

I've tested the code against more than a 100 video files with more than 10 different versions of MKVToolNix, and managed to find some pretty nasty bugs and also added a lot of gradual fallbacks, in order to get the file information. ;)

However, I strongly advise against using older versions, since Mosu was kind enough to provide us with all the necessary information with mknvmerge's output, so next MKVToolNix and gMKVExtractGUI will be blazing fast! :)

[gpower2]

New version 1.8.0 is out and it has a lot of changes underneath! Thanks to Mosu, with MKVToolNix v9.1.0, gMKVExtractGUI is faster than ever in identifying all the necessary info from matroska files!
Extended tests with lots of different files also helped in solving some bugs and making the indentification progress more robust.
Finally, small UI fixes were made, either reported by you or found by me in my tests.

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v1.8.0/gMKVExtractGUI.v1.8.0.7z/download

Changelog:

Change minimum size in main form
Play Windows Asterisk sound when success popup does not show
Make mkvinfo's output parsing more robust
Add parsing of mkvmerge's new output data (thanks Mosu!!!)
Add as many fallback mechanisms as possible, in order to maintain compatibility with older versions
Clear input file textBox in main form, when MKVToolNix path is changed
Clear status and progress bar in main form, when an error has occured during extraction and no popup was selected
Add new setting for showing popup message in success in job manager
Fix some UI issues in Job Manager form
Add a workaround for buggy output from mkvmerge in older versions (v4.0)
Changed the main form's minimum size to 400x400
Added horizontal scroll bar to mkv track list
Add job counter in the text of the jobs groupbox
Make Jobs Grid Columns Autofill


Enjoy people! :D

[djcj]

I had some problems with case sensitivity when I tried to build the latest version from source on Linux. The pre-built version doesn't run at all because of that.

Here's a patch that fixed it for me:
--- a/gMKVExtractGUI.sln
+++ b/gMKVExtractGUI.sln
@@ -5,7 +5,7 @@
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "gMKVExtractGUI", "gMKVExtractGUI\gMKVExtractGUI.csproj", "{20EBEFF3-C838-4239-A236-EC055BF51398}"
EndProject
-Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "gMKVToolNix", "gMKVToolnix\gMKVToolNix.csproj", "{82FC8FA8-50C0-44FA-8801-80050C0ED89F}"
+Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "gMKVToolNix", "gMKVToolnix\gMKVToolnix.csproj", "{82FC8FA8-50C0-44FA-8801-80050C0ED89F}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
--- a/gMKVExtractGUI/gMKVExtractGUI.csproj
+++ b/gMKVExtractGUI/gMKVExtractGUI.csproj
@@ -122,7 +122,7 @@
</Compile>
</ItemGroup>
<ItemGroup>
- <ProjectReference Include="..\gMKVToolnix\gMKVToolNix.csproj">
+ <ProjectReference Include="..\gMKVToolnix\gMKVToolnix.csproj">
<Project>{82fc8fa8-50c0-44fa-8801-80050c0ed89f}</Project>
<Name>gMKVToolNix</Name>
</ProjectReference>
--- a/gMKVExtractGUI/Program.cs
+++ b/gMKVExtractGUI/Program.cs
@@ -28,9 +28,9 @@
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
- if (!File.Exists(Path.Combine(Application.StartupPath, "gMKVToolnix.dll")))
+ if (!File.Exists(Path.Combine(Application.StartupPath, "gMKVToolNix.dll")))
{
- MessageBox.Show("The gMKVToolnix.dll was not found! Please download and reinstall gMKVExtractGUI!", "An error has occured!", MessageBoxButtons.OK, MessageBoxIcon.Error);
+ MessageBox.Show("The gMKVToolNix.dll was not found! Please download and reinstall gMKVExtractGUI!", "An error has occured!", MessageBoxButtons.OK, MessageBoxIcon.Error);
}
else
{


edit:

It still works on Linux btw. but it can't read files with special chars like Ø, ä, é or ß in their filenames. I haven't checked if this is also the case on Windows.

[djcj]

Checked it on Windows 10. There I have no problems with special chars.

[gpower2]

So sorry for the late reply!
I totally forgot that Linux likes its file system case sensitivity! :p
Working with Visual Studio and Windows makes you lazy sometimes!

Could you try latest revision (r113+) and see if it fixes your problems?

I also changed the locale in Linux from "C" to "en_US.UTF-8", in order to hopefully support special characters in filenames, so please check this also!

Thanks for all your support and feedback! :D

[Mosu]

Please note that you cannot rely on en_US.UTF-8 being available on Linux (you can't even rely on the file names being encoded in UTF-8; someone with an ancient system might still use e.g. ISO-8859-15 with a locale of de_DE@euro…). It is available on a lot of machines, yes, and UTF-8 is the de facto standard nowadays, yes, but neither is true for all machines. I've run into this with MKVToolNix myself.

The only sensible thing you can do (and what the usual applications actually do) is to retrieve the locale settings from the environment. The standard C library call for this is 'setlocale(LC_CTYPE, "");' which causes glibc to look at the environment variables LC_ALL, LC_CTYPE and LANG and to use the first one set. I know C# is not C or C++, but there should be something similar available.

[gpower2]

Hmm, I was sure I would run into troubles with this approach, but I hoped for the best!

The thing is, that I want to enforce mkvtoolnix to output its messages in english and not use the translations.
When I set LC_ALL, LANG and LC_MESSAGES to "C", it worked out just fine, but as djcj reported, it stopped accepting filenames with non standard characters.
Which environment should I change, in order to enforce english output in mkvtoolnix, without changing the current system locale?

[Mosu]

Hey,

The thing is, that I want to enforce mkvtoolnix to output its messages in english and not use the translations.

That, at least, is trivial. Just add --ui-language en_US (no .utf-8 suffix) to any of the program's command line.

When I set LC_ALL, LANG and LC_MESSAGES to "C"…

Yeah, messing with those is messy ;) Just don't do it at all and only add the aforementioned arguments.

And if you're trying to achieve something with my tools that you don't immediately know how just ask ;) I could have saved you the trouble ;)

[gpower2]

Hey,
That, at least, is trivial. Just add --ui-language en_US (no .utf-8 suffix) to any of the program's command line.


Oh, I wish that was the case...
This was what I used to do, until djcj reported that it didn't work. After reading mkvextract's manual (https://mkvtoolnix.download/doc/mkvextract.html) I noticed that you specifically say:
It is preferable to use the environment variables LANG, LC_MESSAGES and LC_ALL though.

After changing these environment variables, the output messages were finally in English. You can see the conversation after this post: http://forum.doom9.org/showthread.php?p=1740289#post1740289

Perhaps I should use 'en' for Windows and 'en_us' for Linux?

Yeah, messing with those is messy ;) Just don't do it at all and only add the aforementioned arguments.

And if you're trying to achieve something with my tools that you don't immediately know how just ask ;) I could have saved you the trouble ;)

Thanks for your continuous support! :)

[Mosu]

Oh, I wish that was the case...

It is the case. The values to use simply depend on the operating system in question. On Linux/Unix you'll have to use en_US and on Windows it's en or English (both should work). My tools use the same conventions for locale names as the operating system they're running on. They don't try to map Linux-specific locales (en_US) to Windows-specific ones (en) and vice versa.

I've just verified on both Linux and Windows that what I've written above is correct and works. On a German Windows using --ui-language en works (as does --ui-language English); on a Linux with LC_ALL=de_DE.UTF-8 using --ui-language en_US works.

This was what I used to do, until djcj reported that it didn't work. After reading mkvextract's manual (https://mkvtoolnix.download/doc/mkvextract.html) I noticed that you specifically say:

That's outdated. I should really change that…

[gpower2]

It is the case. The values to use simply depend on the operating system in question. On Linux/Unix you'll have to use en_US and on Windows it's en or English (both should work). My tools use the same conventions for locale names as the operating system they're running on. They don't try to map Linux-specific locales (en_US) to Windows-specific ones (en) and vice versa.

I've just verified on both Linux and Windows that what I've written above is correct and works. On a German Windows using --ui-language en works (as does --ui-language English); on a Linux with LC_ALL=de_DE.UTF-8 using --ui-language en_US works.

That's actually great news! It's a much simpler solution and I already commited it to trunk!
Thanks again! :)

@djcj
You should try r115+!

[hello_hello]

Please update to a newer version of Windows since Windows XP is already more than 15 years old and I'm not sure Mosu or myself will continue to support it.

MKVToolNix hasn't run on XP since version 7.8.0, so that's what I'm using. gMKVExtractGUI 1.8.0 seems to be working fine. There's probably little chance I'll ever upgrade XP on this PC. Maybe when I've played around with it more I'll switch to Linux, but other than that it'll be XP till it dies.
The PC's old. The next one will run Win7 until I'm hopefully comfortable switching to Linux and dumping Windows completely.

[sneaker_ger]

MKVToolNix hasn't run on XP since version 7.8.0, so that's what I'm using
XP compatibility of Mvktoolnix has been restored later.

[gpower2]

MKVToolNix hasn't run on XP since version 7.8.0, so that's what I'm using. gMKVExtractGUI 1.8.0 seems to be working fine. There's probably little chance I'll ever upgrade XP on this PC. Maybe when I've played around with it more I'll switch to Linux, but other than that it'll be XP till it dies.
The PC's old. The next one will run Win7 until I'm hopefully comfortable switching to Linux and dumping Windows completely.

XP compatibility of Mvktoolnix has been restored later.

I think that v8.8 works on XP, but I am not so sure if that's the case with newer versions. ;)

Thanks to djcj valuable feedback, and Mosu's support, gMKVExtractGUI works on Linux too, so you wouldn't have to stop using it! ;)

[hello_hello]

Thanks for the info. I stopped paying attention to MKVToolNix after it stopped working on XP, so I had no idea that had changed again. I just gave MKVToolNix 9.1.0 a spin and it seems fine. Aside from the way it displays directories. ie "E:/video.mkv" rather than "E:\video.mkv". Is that an XP thing or is it normal?

Cheers.

[hubblec4]

... Aside from the way it displays directories. ie "E:/video.mkv" rather than "E:\video.mkv". Is that an XP thing or is it normal?

Cheers.

Thats normal.

[bin_ch]

Well, I changed the minimum size to 400x400 now, but I have to warn you that the layout of the "Actions" panel will be broken and I can't do much about it. ;)


With this change, all new gMKVExtractGUI users will see a broken UI upon start. That's not making a good first impression IMO.
Users requiring such a small size shouldn't be the majority after all. Most users have to enlarge the window size which they probably don't need to previously.
Is it possible to make the initial size for the first run bigger than the minimum? I think it will create better user experience with this approach.

[bin_ch]

A small bug:

If job mode is enabled, as soon as 'Add job' is pressed, the status text in the main window immediately shows 'Extraction completed!'

This bug was introduced in 1.7.0

[gpower2]

Thanks for the feedback bin_ch! Both bugs are fixed in trunk! ;)

[magsoud]

Add this:
1) Start main form's Auto fit Size!
2) Saved Setting! (last Window Size and ticked in Action item,...)

[alfixdvd]

Since release 9.1.0 of mkvtoolnix I have trouble with almost mkv files.

I start gmkvextractgui, I browse and choose an mkv file and nothing happens. Panel is empty of information and gmkvextractgu hangs, mkvinfo don't retrieve any information.

With version 9.0.1 of mkvtoolnix all's fine

[Wildfire]

Since release 9.1.0 of mkvtoolnix I have trouble with almost mkv files.

I start gmkvextractgui, I browse and choose an mkv file and nothing happens. Panel is empty of information and gmkvextractgu hangs, mkvinfo don't retrieve any information.

With version 9.0.1 of mkvtoolnix all's fine

No problems here - it must be a system-specific issue.

[alfixdvd]

No problems here - it must be a system-specific issue.

I don't think. MKVcleaver works fine with both versions of mkvtoolnix.