gMKVExtractGUI

[gpower2]

As a personal bet, I developed a small GUI utility to use mkvinfo and mkvextract cli tools from MKVToolnix pack, in order to extract tracks, chapters and CUE sheets from mkv files.

Though there are already other GUI utilities, I found them rather slow (original MkvExtract GUI), or inefficient (MkvExtractGUI-2 does not extract attachment tracks correctly).

So, gMKVExtractGUI was born, written in pure C# .NET v2 (.NET v4 since v1.9.0) and it works!

Current version is v2.15.0 and you can always find the latest executable file here:

https://github.com/Gpower2/gMKVExtractGUI/releases (https://github.com/Gpower2/gMKVExtractGUI/releases)

Other download locations:
https://www.videohelp.com/software/gMKVExtractGUI
http://www.softpedia.com/get/Multimedia/Video/Other-VIDEO-Tools/gMKVExtractGUI.shtml

Note: After version v2.9.0, I switched from SourceForge (https://sourceforge.net/projects/gmkvextractgui/) to Github (https://github.com/Gpower2/gMKVExtractGUI), and all new versions will be released there henceforth.

Buy me a beer :) (https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YZZQZYL2Y6UNG)

From v1.6.4 Linux is fully supported through MONO framework.
For use with MKVToolNix v9.0.0 and later, v1.7.0 or newer is required.
From MKVToolNix v9.6.0 and later, the JSON output from mkvmerge is used, so Newtonsoft.Json.dll is required (bundled).
From v1.9.0 .NET Framework v4 is required.
Batch support is supported from v2.0.0.
Dark mode is supported from v2.8.0.
Localization is supported from v2.13.0.

Key features:

Use almost 100% of mkvextract functionality (supports extraction of tracks, attachments, chapters in XML, OGM and CUE, timecodes, tags and CUE sheet)
Use mkvinfo to analyse mkv elements really really fast
Automatically detects MKVToolnix installation directory from registry
It doesn't require the executable to be placed inside MKVToolnix directory, but it still checks for it if registry search fails
Uses file extensions for tracks according to CODEC_ID as defined in official mkvextract documentation
Uses separate thread for invoking mkvextract in order to have a responsive GUI
It incorporates a job mode for batch extracting (new in v1.6)
Supports Linux through MONO (new in v1.6.4)
Supports all MKVToolnix versions from v4.x and newer
Supports batch extraction of multiple files (new in v2.0.0)
Supports custom output filename patterns (new in v2.5.0)
Supports adding sub-directories in the custom output filename patterns (new in v2.7.0)
Supports dark mode (new in v2.8.0)


Changelog:

v2.15.0

feat: Add Hungarian language file by @JohnFowler58 in #52
fix(dpi): Fix issues with dpi scaling and responsive layout. Fix the DPI change when switching screens in real time. by @Gpower2 in #56


v2.14.0

chore(localization): refine Simplified Chinese translations by @ambitiuswisdom in #46

fix: Add guard to ApplyResponsiveLayout for early resize safety. Fixes #51
fix: Fix translation grid cell commit logic in order to avoid overwriting the whole translation text per key stroke. Fixes #45
fix: Fix HighDPI mode for Windows by querying during start up and selecting the best mode available for the current Windows version. Fixes #36


v2.13.0

feat: Add localization feature (#39)

perf: Use typed synchronous extraction delegates in gMKVJob and gMKVExtract
perf: Remove DoEvents from SetTableLayoutMainStatus methods in main Form
perf: Replace task polling with continuation-based TPL in main Form.
perf: Replace thread polling with event-driven extraction completion
perf: Send async events for updating the progress and status fields in the forms.

fix(dark): Fix scrollbars in dark mode for RichTextBox.
fix(dark): Fix buttons light mode theming when switching from dark to light mode during runtime.
fix(dark): Fix status strip in dark mode for Mono runtime

fix: Fix gform DPI autoscaling and force initial DPI scaling on Mono in gForm.InitDPI. References issues #36 #41 (#42)

chore: Sanitize all files with the same line endings (CRLF) and encoding (UTF-8 without BOM) for consistency
chore: Fix public API of gMKVToolnix sevices


v2.12.0

doc: Update the user manual with the new Advanced Options.
fix: The Defaults button in Options form now resets the new Advanced Options too.
feat: Add support for raw and fullraw track extraction modes. This closes #22 (#33)
feat: Add option to disable BOM for text files (v96.0+) #31 (#32)
fix: Fix key overrides of custom TextBox controls for Ctrl+A and Ctrl+C
fix: Changed txtLog to gRichTextBox and removed unused code
feat: Add a Select button that displays the Context Menu as another entry point for it. #27 (#30)
fix: fix MkvToolnixPath detection when Settings path is empty (#29) Thanks @lapluis


v2.11.1

fix: Fix issue with Job manager when adding tracks that don't have CodecPrivate data, like PGS subs. thanks arestarh


v2.11.0

feat: Add tooltips and an option to disable/enable them. Closes #21 (#24)
feat: Support checking/unchecking all Forced tracks per track type.
feat: Add support for the Forced track property. Closes #20
feat: Add option for overwriting existing files when extracting. This closes #18 (#19)
feat(tags): Add output filename options for tags. Closes #12
feat: Changed the output file extension for the OGM chapter type from "ogm.txt" to "txt" in the `gMKVToolNix.MkvExtract` namespace. Closes #4

fix(linux): Fix some more possible Linux issues with P/Invoke
fix(linux): correctly fix gRichTextBox issue in Linux
fix(linux): Fix some issues in Linux by excluding paths with P/Invoke.

docs: Enhance README and add docs folder with a basic User Manual

tests: Introduce Unit Tests and refactor part of the code for testability and performance (#11)

perf: Improve context menu creation
perf: Core refactor
Huge refactor of parsing state, practically making parsing stateless
Refactored the process output handling, by using List instead of StringBuilder to avoid splitting into individual line strings afterwards
Removed file existence checks for batch requests to minimize the IO operations
Various code optimizations in string operations
Various code formatting improvements
Refactor gMKVMerge, option handling and codec private data logic (#15)
Refactor gMKVInfo, fix typos and improve parsing (#14)
Refactor gMKVExtract and related components (#13)


v2.10.0

fix(ui): Show "Extraction completed!" message in the segment info text box instead of the label status, to avoid visual clatter (thanks @dclxvplusone)
feat(chapters): Add new PBF chapter type. It automatically transforms the default XML chapter type to the PBF chapter type. Comes with no guarantees, since documentation is basically non-existent
Reorganize and refactor various parts of the code. Switch to using Newtonsoft.Json via Nuget and update to latest version


v2.9.1

fix(init): Revamped the init sequence for detecting the MKVToolnix path and added a new button to manually trigger the auto detect sequence.
fix(logs): Fix various logs in FrmMain2 and gMKVHelper.


v2.9.0

fix(progress): Update the task bar progress bar value based on the total progress and not on the individual job progress
fix(code): Switch to unboxed types and minor optimizations.
fix(gForm): Add the form handle in the remaining message boxes in gForm
feat(dark): Implement Dark Mode in a new way with a bit of help from AI (thanks Jules!)
fix(files): Fix file structure
Create README.md


v2.8.1

fix(dark): Possible fix of a bug with ComboBox in dark mode (thanks vertigo220!)


v2.8.0

Add support for Dark Mode


v2.7.0

Add explicit support for AV1 video codec
Add support for appending input files via drag and drop (thanks vertigo220!)
Make the success dialog popup appear as top most form across desktop (thanks vertigo220!)
Fix the Abort buttons state before the success dialog pop up appears (thanks vertigo220!)
Add new placeholder for directory separator in Options (thanks Liquid, oniiz86!)
Add new Status Strip in Options form in order to make resize easier
Add min size in the Options form to avoid minimizing it to size 1,1


v2.6.4

Minor code optimizations
Add final Trim when generating the output filename (thanks tormento!)


v2.6.3

Fix calculating delays from mkvinfo. (Thanks kedautinh12!)


v2.6.2

Fix attachment filename for all cases. (Thanks mastrboy!)
Improve track selection when filter value is an empty string
Optimize algo to avoid unnecessary comparisons


v2.6.1

Replace invalid file characters with underscore character ('_') from output filename


v2.6.0

Add support for new element "Language IETF"
Minor code optimizations/modernization


v2.5.2

Fix issue in checking for an existing job when adding a new job


v2.5.1

Fix finding delays with newer mkvinfo versions
Optimize finding delays with mkvinfo by searching only for tracks that couldn't find delays with mkvmerge


v2.5.0

Ask the user to create the output directory if it doesn't exist
Various improvements on Form Controls
Added new "Options" form to support custom output filename patterns
Check if a file with the same filename already exists before extracting and add a counter to the output filename to avoid overwritting the original file


v2.4.2

Stop trying to find delays in matroska files that don't contain any video tracks


v2.4.1

Fix attachment extraction


v2.4.0

Enclose language in [] characters in the output filename for tracks, in order for MKVToolNix GUI to be able to derive it
Quote output filename in chapters, tags and cuesheet when using the new MKVToolNix cli
Fix the necessary input fields check when extracting tags and cuesheet
Refactor output filename calculation


v2.3.0

Add new setting for default output directory
Switch to "timestamps_v2" instead of "timecodes_v2" for MKVToolNix v17+
Add support for the new mkvextract syntax for MKVToolNix v17+
Add a new commandline argument --mkvtoolnix="..." to specify a manual path for MKVToolNix


v2.2.0

Change the output directory behavior
Add custom DPI scaling code and enable it on all forms
Add new manifest Property "dpiAwareness" for newest Windows Versions (Windows 10 v1607+)
Added new Audio Codec_ID A_EAC3 and A_MLP
Added some missing video and subtitle codec_id
Remove unnecessary separator in context menu
Increase the width of the percentage labels in Main form
Decrease the height of the buttons in Log Form


v2.1.0

Fix Linux issues
Fix adding files from command line
Add support for passing directories from command line
Make right click to change selection in the TreeView


v2.0.0

New form that supports batch extracting!
Fix bug when removing multiple jobs from Job Manager
Add the filename in the track progress report label in the Job Manager
Add new properties in the gMKVSegmentInfo class


v1.9.2:

Add more Log messages
Add more functionality to the Log Form
Fix some cases where settings were getting overriden during start up (thanks Bal65, RyFeR26!)
Switch to using --gui-mode for mkvextract versions v9.7.0 and newer, while keeping existing functionality for backwards compatibility
Hopefully solve all remaining issues with locale on Linux (thanks djcj!)


v1.9.1

Implement new method to read standard output character by character (fixes Linux parsing)
Replace hard-coded newline characters with Environment.NewLine
Improve parsing of mkvinfo output
Add exceptions to the log
Change version identification in Linux
Add more sanity checks
Fix copy-paste bugs in Settings
Add more log messages in Settings
Simplify version checking for Linux and OSX for mkvinfo and mkvmerge
Fix small cosmetic bug for Linux in main Form
Add LICENSE.md for NewtonSoft
Add log for detecting versions
When on Linux, check for mkvmerge in /usr/bin first


v1.9.0

Switch to .NET v4
Add new JSON parser for reading the JSON identification info from mkvmerge (Based on NewtonSoft JSON.NET, Newtonsoft.Json.dll)
Fix issues with Linux case sensitivity (hopefully!) (thanks djcj!)
Fix locale issues with Linux (hopefully!) (thanks djcj and Mosu!)
Make application dpi aware (thanks stax76!)
Fix initial size when there is no ini file (thanks bin_ch!)
Fix bug when in job mode and popup checkbox is unchecked and adding a job results in status label showing "Extraction completed!" (thanks bin_ch!)
Switch to using SaveFileDialog and OpenFileDialog instead of FolderBrowserDialog (thanks arestarh!)
Fix rare case where Track properties in mkvmerge verbose identification occupy more than one line
Change namespace from gMKVToolnix to gMKVToolNix


v1.8.0

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


Older changelog here (https://forum.doom9.org/showthread.php?p=2011596#post2011596)

Hope you enjoy this little utility and feedback is always appreciated! :)

[wanezhiling]

can't remember settings.

[wanezhiling]

http://i.imgur.com/RzYZUtG.png

I tested all my mkv files, empty in the list.:confused::confused:

[gpower2]

What version of MkvToolnix do you use?
Did you get any error message when you selected the video file?

[wanezhiling]

offical 6.7.0 installer
No error, just empty.

[gpower2]

It seems that mkvinfo didn't spit out anything about the file.
It is really strange since I made most of my tests with 6.7.0 and didn't have any problems.

Did you extract both exe and dll files?
I'll build a version with debug information and upload it in the afternoon to check this, thanks for your feedback! :)

[wanezhiling]

Did you extract both exe and dll files?
Of course.

[Taurus]

Same here as in wanezhiling post ->empty list

Edit: Tried it on Win XP 32bit and on Win7 64bit -> the same.

[gpower2]

I just tested it again and I didn't have any problems here:

http://i.imgur.com/Cd4UeF7.gif?1

I'll upload the new version as soon as I can to see what's happening with you guys...

[sneaker_ger]

Could it be a problem with non-English versions of Windows? May want to look into --command-line-charset and/or --output-charset then.

[gpower2]

Perhaps the --ui-language could be the solution, I am working on adding a log form in order to see the true output of the operations.
Won't be long now.

@sneaker_ger
Did you try it yourself? Did you run into any problems?

[sneaker_ger]

Ah, yes, I forgot the --ui-language option. Yes, I tested it on a non-English Windows with the same symptoms as the other reporters.

Also: does it only check file extension? Then .mka, .mks, .mk3d and .webm are missing. (Though I don't think file extensions are a good way to check.)

[gpower2]

New version v1.2 is out, hoping to solve the problems you all had.
In case the problems persist, you can view the log and paste it here in order to examine the root cause of the problems.

Have it a try and thanks again for all the feedback! :)

[mastrboy]

Are you going to add batch (multiple files) support, similar to MKVCleaver?

[gpower2]

I'm surely considering it, I just haven't figured out yet how to implement the workflow of the batch. I'm thinking more of a job manager thingy, but it would be some time before it gets out...

[wanezhiling]

Funny, it only works with mkvtoolnix 6.7.0, an error occurs with old versions, 6.6.0 eg

http://i1.tietuku.com/a67df41fee3a927e.jpg

:scared:

[gpower2]

Probably some option is incompatible with older versions, I'll check it and come back with a fix (hopefully).

At least it works with 6.7.0 now, right?

@mastrboy
Any thoughts on the batch processing mode? It would be nice to have some feedback from users first. :)

[[ReX]]

You should probably use mkvmerge with "--identify-for-mmg" instead of mkvinfo.

Here's a scenario where mkvinfo fails:
1) Take a MKV file (file.mkv) with attachments (fonts, for instance)
2) Check if the output of mkvinfo shows attachments (yes)
3) Add a font attachment to it using mkvpropedit
mkvpropedit "file.mkv" --attachment-name "arial.ttf" --attachment-mime-type "application/x-truetype-font" --add-attachment "C:\Windows\Fonts\arial.ttf"
4) Check if the output of mkvinfo shows attachments (no)

[gpower2]

Hmm, I never thought of checking mkvmerge for command line parameters to identify mkv properties!
Still, isn't that a limitation/bug on mkvinfo's side? Shouldn't we open a ticket to MkvToolnix's bug tracker?

Anyways, I will check that option too, maybe I'll put a setting to select which road you want to take. Thanks [ReX]!

[rsotome]

Hmmm, so far, so good, really nice extraction program. :)

A batch option would be very useful, but I understand you'll need time to implement something like that.

Something that would really be very useful would be the ability to extract the video track straight into an mkv container, instead of the raw video, is that possible?

[gpower2]

Well, mkvextract does not support remuxing the tracks to matroska container, but with the help of mkvmerge, I believe something like that could be possible.

It sounds like a nice feature, so I'll do my research and I'll come back to you for my findings. Thanks for the feedback! :)

[[ReX]]

Hmm, I never thought of checking mkvmerge for command line parameters to identify mkv properties!
Still, isn't that a limitation/bug on mkvinfo's side? Shouldn't we open a ticket to MkvToolnix's bug tracker?

Anyways, I will check that option too, maybe I'll put a setting to select which road you want to take. Thanks [ReX]!

That's actually the right way to do it, it's what mmg does (hence the name of the command line argument).
It's not actually a bug, there's a FAQ entry (https://trac.bunkus.org/wiki/FAQ%3AUnderstandingMkvinfosOutput) for the mkvinfo behavior.

[gpower2]

Wow, you were right on the spot [ReX]!
Thanks for clarifying this, I'll make the change as soon as I can find some free time!

[aMvEL]

Nice program, gpower2. I've been using mkvextractgui-2 the last years and this seems to be more robust.

I was wondering if you would concider implementing the ability to open mkv files with gmkvextractgui, like right click mkv-file and open with.
As of now it just opens the program but doesn't load the mkv-file like mkvextractgui-2 (and mkvcleaver for that matter), does.

[STaRGaZeR]

Thanks for the program! I noticed 3 problems with it so far:

- Old versions of mkvtoolnix don't seem to work. 5.0.1 for example, complaining about more than one input file.
- The progress bar stays at 0% all the time, at least when extracting only one subtitle track for a given mkv file.
- The log seems to be in the system's locale, not in english.

Everything else working as expected :)

[lansing]

I think you need to include a ini file to remember all the settings. I'm using portable version of mkvtoolnix and every time I run the program I need to point to the folder again.

[Dark Eiri]

Loving your app! May I suggest the extension filter on the open file dialog to include .mkv, .mka and .webm simultaneously instead of separatedly?

[gpower2]

Thank you all for your kind words and support!
I finally found some time to implement most of the changes you guys requested, but Sourceforge is having some problems with file uploading, so I don't know when v1.3 will be officially out...
Hopefully sometime today!

In any case, I will update the first post and this one, so just be a little more patient! :)

[gpower2]

Sourceforge finally fixed their issues and new version is up!
First post is updated, so you can now grab the new version!

I am waiting for your feedback! :)

[lansing]

with 1.3, I'm getting an error "the process cannot access the ini because it is being used by another process" in program startup.

[aMvEL]

Thank you for opening for CLI, gpower2!
This has now completely replaced mkvextractgui-2 for me :)

[gpower2]

with 1.3, I'm getting an error "the process cannot access the ini because it is being used by another process" in program startup.

It is quite weird for you to get such a message. Perhaps some antivirus issue or maybe folder permissions?

[lansing]

It is quite weird for you to get such a message. Perhaps some antivirus issue or maybe folder permissions?

I have moved the folder to desktop but still got the same dummy error. But I was still able to delete that ini file while the program was running.

And some other bugs I found, before I created the ini path by pointing to the mkvtoolnix folder, when I run the program and hit extract tags or extract cue or the extract tracks button, it will return a "xx extracted successfully" message

[gpower2]

I have moved the folder to desktop but still got the same dummy error. But I was still able to delete that ini file while the program was running.

The program doesn't try to do anything complicated, it just checks for the existence of the ini file, opens it, reads it and closes it.
I honestly can't do much without further information...

And some other bugs I found, before I created the ini path by pointing to the mkvtoolnix folder, when I run the program and hit extract tags or extract cue or the extract tracks button, it will return a "xx extracted successfully" message

That's me being lazy and omitting basic checks... :oops:
I must add them for the next version!

Thanks again for all your feedback!

[gpower2]

with 1.3, I'm getting an error "the process cannot access the ini because it is being used by another process" in program startup.

Could you please check if this build solves the issue for you?
http://tools.animeclipse.com/gmkvextractgui/gMKVExtractGUI.v1.3.b.7z

[lansing]

Could you please check if this build solves the issue for you?
http://tools.animeclipse.com/gmkvextractgui/gMKVExtractGUI.v1.3.b.7z

yes it's fixed.

Another bug I found, after dragging a random file to the input field, an error message pop up like it suppose to, but after I click ok to confirm it, the file was still in the input field.

[gpower2]

I just uploaded v1.3.1!
It is mostly a bug fix version, you can find detailed changelog in the post.

@lansing
I believe most, if not all, of the bugs you reported have been fixed in this version. Thanks for your feedback so far!

@rsotome
I reconsidered adding a re-muxing option, and I think that it is meaningless, since MkvMerge GUI does exactly what you ask. ;)

Hopefully when v1.4 comes, it will include the batch feature that most of you requested. Thank you all for your support! :D

[lansing]

Thanks for the fixes.

Another bug I found, the output directory field right now can take in whatever thing I dragged into it.

And I think the mkvtoolnix directory field shouldn't be in the main window gui, because it's not part of the common tasks with the program and we're setting it only once.

[hello_hello]

And I think the mkvtoolnix directory field shouldn't be in the main window gui, because it's not part of the common tasks with the program and we're setting it only once.

Agreed. I've only played around with gMKVExtractGUI and already I've changed the output location using the mkvtoolnix location field by mistake.
I don't know if it's been mentioned, but a default output directory might be nice, rather than it changing for every opened file.

I've not played with gMKVExtractGUI for long and not read through this thread, but I'm curious, can gMKVExtractGUI do anything MKVCleaver can't? Not that the existence of MKVCleaver should stop the development of any new extraction programs, but especially given it can batch extract, it's set a fairly high standard in terms of usability.

[gpower2]

Another bug I found, the output directory field right now can take in whatever thing I dragged into it.
Agreed. I've only played around with gMKVExtractGUI and already I've changed the output location using the mkvtoolnix location field by mistake.

Hmm, you are right, I never bothered to check it properly...

And I think the mkvtoolnix directory field shouldn't be in the main window gui, because it's not part of the common tasks with the program and we're setting it only once.

Well, I guess that's just a matter of opinion. I wanted to have all the options visible and accessible at one place, so that the user doesn't need to search for hidden options or menus.
I guess that may seem odd for more advanced users, but I believe from personal experience, that less experienced users prefer those kind of GUIs.

I don't know if it's been mentioned, but a default output directory might be nice, rather than it changing for every opened file.

That's indeed a valid request! I will look into it!

I've not played with gMKVExtractGUI for long and not read through this thread, but I'm curious, can gMKVExtractGUI do anything MKVCleaver can't? Not that the existence of MKVCleaver should stop the development of any new extraction programs, but especially given it can batch extract, it's set a fairly high standard in terms of usability.

I wrote this program to be as simple as possible in terms of use. I always found MKVCleaver GUI to be a little awkward and preferred to use MKVExtractGUI, but since it had its flows, gMKVExtractGUI was born.

[johnsonlam]

Hi,

Thanks gpower2 for your great GUI!

[hello_hello]

Well, I guess that's just a matter of opinion. I wanted to have all the options visible and accessible at one place, so that the user doesn't need to search for hidden options or menus.
I guess that may seem odd for more advanced users, but I believe from personal experience, that less experienced users prefer those kind of GUIs.

IMO, there's a "best of both worlds" compromise there.
You could, if you desired, have no option in the GUI itself to set the location of MKVToolNix, but the first time the Extract button is selected, a popup window could allow the user to show gMKVExtractGUI where to find it.
In a more subtle location there could be an option to set the location of MKVToolNix for more advanced users to play with, allowing them to switch MKVToolnix versions if need be, although personally I think most advanced users could simply edit the ini file to change the location of MKVToolNix after it's been automatically set the first time. Assuming of course, that's where gMKVExtractGUI stores the location.

A little "not quite a bug". If the MKVToolNix location area is set to somewhere other than the location of the MKVTooNix folder, when you try to open an MKV an error message regarding not being able to find the specified file pops up.

If the current system for selecting the MKVToolNix location can't be changed, could the default behaviour of the Browse button be changed so selecting it has no effect until you actually browse to a new location? Those Browse buttons all look alike and I've hit the bottom Browse button accidentally a couple of times and then had to browse to the MKVToolNix location all over again. It'd be nice just to be able to think "oops" and close the browse window without anything having changed.

Speaking of which. The lowest area for entering a location in a GUI must be the output location. That's not my idea. That's the law. ;)
I think it's also why I've accidentally clicked on the wrong Browse button a couple of times.

An Abort button would be very handy. I'm an idiot. I sometimes start extracting the wrong stream before I realise I'm extracting the wrong stream.

I've added this one to my MKVCleaver wish list and with any luck the next version will incorporate it, but when extracting audio streams, if the audio stream has a delay relative to the video, could said delay be written to the file name? Like DGIndex does. Well exactly as DGIndex does. If the file name ends with the word "delay" followed by a delay value, MKVMergeGUI will automatically apply it when muxing, as will MeGUI's muxers. Currently the only way to ensure extracted audio is remuxed using the correct delay is to manually check for one using MediaInfo.
The latest version of MeGUI now writes any delay values to the file name of extracted audio streams in an MKVMergeGUI friendly manner. Zathor is quite an obliging fellow. ;)

Speaking of which, MeGUI writes the language of extracted tracks to the file name in a way it's muxers understand in order to automatically apply the particular language. When I'm given a jewelled hat and declared ruler of the world, which does seem to be taking longer than I'd initially expected, all extraction and muxing programs would have to follow the same rules for writing languages to extracted files and automatically applying them when muxing. Mosu isn't at all interested in that, for reasons I don't understand, but if MKVCleaver, gMKVExtractGUI, and MeGUI all used the same convention.... I guess I'm dreaming....

Is there a good reason for extracting chapters with an OGM extension rather than TXT? MKVMergeGUI is happy with either and Notepad already opens text files. ;)
And could gMKVExtractGUI remember the setting for the type of chapters to extract? As I said, I'm an idiot, so to extract ogm chapters I have to do it without remembering to change the setting, then again after changing it.

Thanks for a nice little program!

[gpower2]

First of all... wow! I never expected such a detailed post!
So I'll try to address all of your issues:

IMO, there's a "best of both worlds" compromise there.
You could, if you desired, have no option in the GUI itself to set the location of MKVToolNix, but the first time the Extract button is selected, a popup window could allow the user to show gMKVExtractGUI where to find it.
In a more subtle location there could be an option to set the location of MKVToolNix for more advanced users to play with, allowing them to switch MKVToolnix versions if need be, although personally I think most advanced users could simply edit the ini file to change the location of MKVToolNix after it's been automatically set the first time. Assuming of course, that's where gMKVExtractGUI stores the location.
...
If the current system for selecting the MKVToolNix location can't be changed, could the default behaviour of the Browse button be changed so selecting it has no effect until you actually browse to a new location? Those Browse buttons all look alike and I've hit the bottom Browse button accidentally a couple of times and then had to browse to the MKVToolNix location all over again. It'd be nice just to be able to think "oops" and close the browse window without anything having changed.

I really tried to avoid popup and other "hidden" forms from showing up out of the blue. That's why I insist on leaving MKVToolnix location in the main form. Perhaps I will add a question when the user tries to alter the location, when it's already set, so that it will not get accidentally changed. I may also have forgotten to check for whether the user has pressed OK or Cancel, I'll also look into it.

A little "not quite a bug". If the MKVToolNix location area is set to somewhere other than the location of the MKVTooNix folder, when you try to open an MKV an error message regarding not being able to find the specified file pops up.

I believe this is the expected behavior, but I'll see to change the message into something more useful.

An Abort button would be very handy. I'm an idiot. I sometimes start extracting the wrong stream before I realise I'm extracting the wrong stream.

I totally agree with you, it was already planned for the next version. ;)

I've added this one to my MKCleaver wish list and with any luck the next version will incorporate it, but when extracting audio streams, if the audio stream has a delay relative to the video, could said delay be written to the file name? Like DGIndex does. Well exactly as DGIndex does. If the file name ends with the word "delay" followed by a delay value, MKVMergeGUI will automatically apply it when muxing, as will MeGUI's muxers. Currently the only way to ensure extracted audio is remuxed using the correct delay is to manually check for one using MediaInfo.
The latest version of MeGUI now writes any delay values to the file name of extracted audio streams in an MKVMergeGUI friendly manner. Zathor is quite an obliging fellow. ;)

This is the expected behavior, since Matroska does not keep the delays in the audio tracks. Mkvmerge simply rewrites the timestamps on the audio track and drops the delay. More on that here:
https://trac.bunkus.org/wiki/FAQ%3ADelayNotShownInMmg.

Speaking of which, MeGUI writes the language of extracted tracks to the file name in a way it's muxers understand in order to automatically apply the particular language. When I'm given a jewelled hat and declared ruler of the world, which does seem to be taking longer than I'd initially expected, all extraction and muxing programs would have to follow the same rules for writing languages to extracted files and automatically applying them when muxing. Mosu isn't at all interested in that, for reasons I don't understand, but if MKVCleaver, gMKVExtractGUI, and MeGUI all used the same convention.... I guess I'm dreaming....

I'll check it, it won't be difficult to simply change the output filename. ;)

Is there a good reason for extracting chapters with an OGM extension rather than TXT? MKVMergeGUI is happy with either and Notepad already opens text files. ;)
And could gMKVExtractGUI remember the setting for the type of chapters to extract? As I said, I'm an idiot, so to extract ogm chapters I have to do it without remembering to change the setting, then again after changing it.

Will do, and will do. ;)

[hello_hello]

First of all... wow! I never expected such a detailed post!

I do tend to ramble on a bit sometimes.... :)

I really tried to avoid popup and other "hidden" forms from showing up out of the blue. That's why I insist on leaving MKVToolnix location in the main form. Perhaps I will add a question when the user tries to alter the location, when it's already set, so that it will not get accidentally changed. I may also have forgotten to check for whether the user has pressed OK or Cancel, I'll also look into it.

I can think of a few programs which pop up to ask for the location of a particular utility and to me it seems to work pretty well. Foobar2000 for instance. The first time you use one of it's converter presets, such as converting to MP3, a window pops up asking where the LAME encoder resides. You navigate to the location once and never have to think about it again.

I checked and I was wrong. Sorry. If you select Cancel in the browse window the MKVToolNix location remains unchanged. I must have hit okay instead without thinking. However....
On my PC when you do select the Browse button, the browse window defaults to the desktop location. If instead it defaulted to the "already specified" location for MKVToolNix (for example "C:\Program Files\MKVToolnix") you could dismiss the browse window using either okay or cancel and nothing would change. ;)

This is the expected behavior, since Matroska does not keep the delays in the audio tracks. Mkvmerge simply rewrites the timestamps on the audio track and drops the delay. More on that here:
https://trac.bunkus.org/wiki/FAQ%3ADelayNotShownInMmg.

But extracted streams, once they're extracted, no longer have timestamps. In order to remux the extracted audio using the original timestamps you need to specify the appropriate audio delay when muxing. Either that or the timestamps should always be extracted along with the audio and used when remuxing it. From the page you linked to:

"Let's take an AC3 track for example. Those often have packets with a duration of 32ms. Now if you offset that by -40ms mkvmerge subtracts those 40ms from all timestamps. The very first two timestamps would then be at -40ms and -8ms; however, Matroska doesn't allow negative timestamps. Therefore the first two packets will be dropped. The new first packet is the old third packet at the new timestamp 24ms (old timestamp 64ms, subtract delay 40ms = 24ms). MediaInfo would then report a positive offset of 24ms."

So that's all good. You now have a file with a positive audio delay of 24ms, in human terminology, but what if you later extract the audio from that particular MKV, re-encode it (or whatever) and then remux it? For it to be muxed the same way as the original, a 24ms delay needs to be applied. Currently the only way to determine if a delay is needed is to check the original MKV using MediaInfo.
How MeGUI determines the delay when extracting I'm not sure. It may work it out from the timestamps or it may use the delay reported by MediaInfo.

It's pretty much the same logic behind DGIndex writing audio delays to the file names of extracted audio. When muxing it into an MKV/MP4/AVI, the way the muxing program handles the audio doesn't really matter, the correct audio delay still needs to be specified.

[gpower2]

So, the new version is out (1.4) and I am really excited about this one! It's the version with the most changes since the first one, so I am also anxious about feedback from you!

I hope I managed to satisfy most of your requests, one that I specifically didn't implement was writing the language of the extracted tracks in a specific way, so that MeGUI muxers can automatically parse it. MeGUI actually expects the full language name, something that really doesn't make any sense, since most programs recognize and accept the language short code (eng, jpn, etc...). I would have to convert all short codes back to the language's full name, not that it is so difficult and I might have the code from another project of mine, but it just seems plain stupid! :p

The biggest change is the new Extraction Mode selector, which came along with the new timecodes mode where you can now extract timecodes from the matroska files. The second one is the detection of the delay in audio tracks via timecodes. I hope I didn't mess it up...

So, lots of things to check out, waiting for your feedback! ^_^

[hello_hello]

I'll confess I don't quite get it. The first time you run the program a windows pops up with a message along the lines of "I can't find MKVToolNix and the world is about to end", but a window popping up after the program is opened enquiring where to find MKVToolNix is a bad idea...... I guess we'll never agree on that one. :)

For some reason when I replaced the old files with the new versions and ran the program, it didn't pick up the location of MKVToolNix from the existing ini file. No big deal really. I just thought I'd mention it in case you wanted to change that in future versions.

An MKV extraction program which writes the audio delay to the name of the audio stream? Hallelujah and praise the lord! Well praise gpower2 for implementing it and I'll take a little for suggesting it. ;) So far it seems to be working correctly (writing the correct delay value).

For some reason the Abort button doesn't seem to be where it ought to be. It's kind of "slid up" a bit, ie not in line with the AbortAll button. Maybe that's just when running on XP?

I thought the language written to extracted streams might be asking a bit much and yes I agree MeGUI should use the two/three letter language code. I might point Zathor to this thread to see if he has an opinion on the subject. My discussion with Mosu re language codes and MKVMergeGUI made me want to forget the whole idea, but if all programs used the same system it'd be wonderful. I don't know whether Zathor would want to be making huge changes to MeGUI in that department though as he'd need to change both the extracting and muxing behaviour.

I haven't had a chance to play with the new version much but I will later and report back if I discover any oddness. Thank you very much again!

[gpower2]

I'll confess I don't quite get it. The first time you run the program a windows pops up with a message along the lines of "I can't find MKVToolNix and the world is about to end", but a window popping up after the program is opened enquiring where to find MKVToolNix is a bad idea...... I guess we'll never agree on that one. :)

The program has only 2 prerequisites, .NET framework and MKVToolnix. It can't do anything if those prerequisites aren't installed, so I think it is quite "honest" from the program to check for them at start up. ;)

For some reason when I replaced the old files with the new versions and ran the program, it didn't pick up the location of MKVToolNix from the existing ini file. No big deal really. I just thought I'd mention it in case you wanted to change that in future versions.

That was unavoidable, since I changed the ini file format... Hopefully that won't happen again (at least, not soon :p)

For some reason the Abort button doesn't seem to be where it ought to be. It's kind of "slid up" a bit, ie not in line with the AbortAll button. Maybe that's just when running on XP?

I never really tested it in XP, so it may indeed seem a bit out of place there. Care to post a screenshot?

[hello_hello]

The program has only 2 prerequisites, .NET framework and MKVToolnix. It can't do anything if those prerequisites aren't installed, so I think it is quite "honest" from the program to check for them at start up. ;)

Fair enough. Check at startup, check when you first try to extract.... either way if it asked for the location of MKVToolNix while it's checking it'd make the location area for MKVToolNix obsolete. ;)

I never really tested it in XP, so it may indeed seem a bit out of place there. Care to post a screenshot?

http://s1.postimg.org/5jnl9sebz/Clipboard01.gif

[gpower2]

Fair enough. Check at startup, check when you first try to extract.... either way if it asked for the location of MKVToolNix while it's checking it'd make the location area for MKVToolNix obsolete. ;)

The thing is that MKVToolnix is required even for analyzing the contents of the file, so basically, the program is utterly useless when MKVToolnix is not there!

http://s1.postimg.org/5jnl9sebz/Clipboard01.gif

Wow, that is definitely not the way it is supposed to look! Hopefully I found the cruft behind it (evil Visual Studio Designer!), so I'm guessing you won't have that problem with the next version. ;)

[hello_hello]

The thing is that MKVToolnix is required even for analyzing the contents of the file, so basically, the program is utterly useless when MKVToolnix is not there!

Ahh..... so that's why instead of having a window pop up asking you where to find MKVToolNix you have one popping up stating the program can't find it, and why rather than having a button which says "Set MKVToolNix", there's a location area for MKVToolNix in the GUI which in theory you'll only ever set once and then it'd serve no purpose. :)

[hello_hello]

A couple more thoughts....

The way it appears to work when extracting audio streams, as best as I can tell, is selecting "tracks" as the extraction option and selecting "tracks and timecodes" do exactly the same thing, only when "tracks" is selected the timecodes are deleted after they're extracted. Maybe it's something to do with determining any audio delay, but when extracting audio from large MKV files it slows the process down quite a bit. I have two RAID-0 volumes in this PC and I usually try to put the source file on one while extracting to the other in order to make the process less time consuming (one reason I prefer to use a default output location) so when the extraction process appeared to be taking longer than it should have I had a look to see if I could work out why. I hadn't noticed the timecodes were also being extracted until then.

Also, the "lock" setting for the output location doesn't seem to survive a restart of the GUI which makes it far less useful, given the output location still needs to be set every time the program is used.

Cheers.

[sneaker_ger]

It's probably quicker to read the first timecode through mkvinfo. Don't know how easy that is, though.

[gpower2]

Ahh..... so that's why instead of having a window pop up asking you where to find MKVToolNix you have one popping up stating the program can't find it, and why rather than having a button which says "Set MKVToolNix", there's a location area for MKVToolNix in the GUI which in theory you'll only ever set once and then it'd serve no purpose. :)

You forget the scenario when a user wants to try different portable versions of MKVToolnix to test a specific input file... ;)

The way it appears to work when extracting audio streams, as best as I can tell, is selecting "tracks" as the extraction option and selecting "tracks and timecodes" do exactly the same thing, only when "tracks" is selected the timecodes are deleted after they're extracted. Maybe it's something to do with determining any audio delay, but when extracting audio from large MKV files it slows the process down quite a bit. I have two RAID-0 volumes in this PC and I usually try to put the source file on one while extracting to the other in order to make the process less time consuming (one reason I prefer to use a default output location) so when the extraction process appeared to be taking longer than it should have I had a look to see if I could work out why. I hadn't noticed the timecodes were also being extracted until then.

I will try to find another way, but I don't feel confident about that, since I've already tried a lot of different approaches for this. Unfortunately, the only way to determine the delay of a track, is via the timecodes and I couldn't find a way to get the timecodes of a track without extracting them whole...

Also, the "lock" setting for the output location doesn't seem to survive a restart of the GUI which makes it far less useful, given the output location still needs to be set every time the program is used.

I will add them in the settings then. I never had to extract tracks from different locations to the same output location, so I haven't thought of this thoroughly.

It's probably quicker to read the first timecode through mkvinfo. Don't know how easy that is, though.

I don't know if mkvinfo dumps the timecodes, and if it does, it does it in the verbose mode, which is quite slow, so the performance could be the same or even worse. However, it is another thing I could check out, thanks for the tip! :)

[sneaker_ger]

At least in the GUI navigating to the first timecode is fast. Not sure if the same can be done via the CLI. Maybe ask Mosu.

[hello_hello]

You forget the scenario when a user wants to try different portable versions of MKVToolnix to test a specific input file... ;)

I guess you're referring to more advanced users who'd have no problem changing the location using a button on the bottom of the GUI or by manually editing the ini file, or even by temporarily renaming the folder where gMKVExtractGUI expects to find MKVToolNix in order to be prompted for it's location when gMKVExtractGUI is next used. ;)

[hello_hello]

I've been using gMKVExtractGUI a little more today and I need to report, it's killing me in the speed department. I timed the extraction process to make sure I wasn't imagining it. Until I did I hadn't realised gMKVExtractGUI extracts each stream one at a time. Any reason for that?

With a 5GB MKV on one RAID-0 volume while extracting to another, I extracted the DTS audio stream and two subtitle streams. Each one took a little under 70 seconds, so the total extraction time (including the audio timecodes) was 4 minutes 35 seconds.

MKVCleaver, on the other hand, extracted all three streams in 1 minute, 5 seconds. If I ran a single hard drive like most/many people the process using gMKVExtractGUI would be somewhat painful. For whatever reason it seems MKVCleaver doesn't extract the timecodes at the same time it extracts the streams, but if you do ask it to extract timecodes, it extracts them all together. In my test if I'd extracted timecodes that would have doubled MKVCleaver's extraction time, although it's not something I do often anyway.

Cheers.

[sneaker_ger]

I doubt mkvcleaver extracts timecodes and bitstreams at the same time, mkvextract simply cannot do it.

[hello_hello]

I doubt mkvcleaver extracts timecodes and bitstreams at the same time, mkvextract simply cannot do it.

For whatever reason it seems MKVCleaver doesn't extract the timecodes at the same time it extracts the streams, but if you do ask it to extract timecodes, it extracts them all together.

I meant when extracting multiple steams and timecodes it extracts all the streams together, then it extracts all the timecodes together.

[gpower2]

I'll have to redesign the core concept of the program, since at this time it executes mkvextract for each track separately.

I can't say how long it will take me since I'm kind of preoccupied with my job at the moment.

It is good to have feedback from heavy usage scenarios, thanks again! :)

[hello_hello]

I'm not sure if you're still planning on a new version, but if you are.....

I found a small issue/bug when extracting audio from MKVs, in relation to the delay value written to the file name. MeGUI has the same shortcoming, so I've also reported it as an MeGUI bug.

MKVs can't have streams with negative delays, but if the video has a positive delay, it's effectively a negative audio delay. That type of delay doesn't happen much, but it's possible. eac3to handles it as a negative audio delay when extracting audio and fixes it, and MediaInfo reports a positive video delay as a negative audio delay, but MeGUI/gMKVExtractGUI assume the audio delay is zero. Technically correct, but for practical purposes, not so much....

Cheers.

[gpower2]

Unfortunately I didn't have the necessary free time to complete the new core redesign, in order to optimize multiple track extraction, but it will be done. ;)

As for the audio delay, I guess I'll have to subtract video delay from audio delay or something like that.

[gpower2]

After quite some time, I managed to find the time needed to do a major redesign and refactoring of the core code, in order to make gMKVExtractGUI as efficient as it can get. I now think that it is ready, after a lot of testing and head banging on the wall, so here it is:

http://sourceforge.net/projects/gmkvextractgui/files/v1.5/gMKVExtractGUI.v1.5.7z/download (http://sourceforge.net/projects/gmkvextractgui/files/v1.5/gMKVExtractGUI.v1.5.7z/download)

Changelog:

Hopefully fix Abort button from being drawn out of line in some OS (Windows XP ?)
Fix some visual issues
Added Output Directory and Lock Output Directory to the Settings
Replace escape characters in mkvmerge
Changed extraction mode to support grouping of similar tasks into one process call
Added support of finding the delays in video and audio tracks
Now extracted audio tracks have the relative to the video delay
Add an extra check when selecting timecodes extraction mode
Made a few more performance improvements


Enjoy people! :D

[TurboPascal7]

Hi, thanks for your app.

I have three feature requests:
1. Increase the area where you can drag-n-drop the input file (the whole app window or at least the streams area). Right now you need to drop it directly on the input file textbox which is quite small.
2. Add "select all" button. Maybe I just didn't find it, but extracting some 30 streams from an mkv right now is extremely painful.
3. A "batch" button, just like that in mkvextractgui2.

Thanks.

[Xebika]

I agree with batch button.

[gpower2]

A small update with new version v1.5.1:

http://sourceforge.net/projects/gmkvextractgui/files/v1.5.1/gMKVExtractGUI.v1.5.1.7z/download

Changelog

Increase the drag and drop area for the input file to the group box of input file info
Add a context menu for easy selection of tracks


The batch button of MkvExtractGUI-2 is not one of the features that I will add, since I am designing a true batch mode, or rather a job management mode. But this will be in the v2.x series of the app and I can't make any promises about the release date.

[hello_hello]

Thanks for the update! I've only had a quick play, but so far so good...... and the Abort button is now where it should be (XP).

Cheers.

[gpower2]

Thanks for the update! I've only had a quick play, but so far so good...... and the Abort button is now where it should be (XP).

Cheers.

I am waiting for your feedback, especially about the performance issues you had with your RAID configuration, and about the audio delay. I think that everything should work as it should with the latest version. ;)

Thanks for all the support so far! :)

[gpower2]

Quick update:
Just tested gMkvExtractGUI with mkvtoolnix v7.0 and it works just fine. ;)

[TurboPascal7]

Thanks. I like the way you implemented the track selection menu, works a lot better than a simple button.

[hello_hello]

I am waiting for your feedback, especially about the performance issues you had with your RAID configuration, and about the audio delay. I think that everything should work as it should with the latest version. ;)

Thanks for all the support so far! :)

I still haven't had an extensive play but so far I've found nothing to nitpick over. ;)

Speed seems the same as MKVCleaver when extracting multiple tracks, and I do like the way gMKVExtractGUI displays additional track information (name, language, delay etc). So far I can't fault the audio delays it's writing.

I'll look forward to what seeing what you do with batch extracting.

PS gMKVExtractGUI seems to be working fine with MKVToolNix v7.0 here.

[huokok]

Hi, gp2
A few questions I'd like to ask and a few feedback.

After a mkv file loaded, I got those two warnings in log. What is the meaning? (I'm not a technical people at all)
Warning: Could not initialize the iconv library for the conversion from UFT-8 to UFT-8. Some strings will not be converted to UTF-8 and the resulting Matroska file might not comply with the Matroska specs (error: 22, Invalid argument).
Warning: Could not initialize the iconv library for the conversion from UFT-8 to UFT-8. Some strings cannot be converted from UTF-8 and might be displayed incorrectly (error: 22, Invalid argument).

After extraction, I found the video extension is .avc instead of .h264, which is different from GUI2. Apparently, mp4box doesn't like this, by their standard:p
Unknown input file type
Error importing D:\test\test_track1_eng.avc: Corrupted Data in file/stream


http://i.imgur.com/v5YYf6Z.jpg

Why there are empty square brackets? And is there any difference in 2 delay brackets?
For the duration, it shows the same as in mkvinfo. What concerns me is that duration is the audio duration, which is slightly longer than video track, so I'm assuming the duration is the longest track? Well, it seems to be the issue of mkvinfo.

Thank you, I like the interface of this GUI.:D
:thanks:

[gpower2]

First of all sorry my delayed reply...

Hi, gp2
After a mkv file loaded, I got those two warnings in log. What is the meaning? (I'm not a technical people at all)
These messages are the result of explicitly setting the output charset to utf-8 while executing mkvinfo and mkvmerge.
It shouldn't matter to anyone, but I use them because of some localization problems the first versions had. Better safe than sorry, right?

After extraction, I found the video extension is .avc instead of .h264, which is different from GUI2. Apparently, mp4box doesn't like this, by their standard:p
I tried to follow the standards for output file extensions as defined here (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvextract.html) and here (http://matroska.org/technical/specs/codecid/index.html).
In my tests .avc behaved better than .h264, but I guess each tool has its own preferences.

http://i.imgur.com/v5YYf6Z.jpg

Why there are empty square brackets? And is there any difference in 2 delay brackets?
For the duration, it shows the same as in mkvinfo. What concerns me is that duration is the audio duration, which is slightly longer than video track, so I'm assuming the duration is the longest track? Well, it seems to be the issue of mkvinfo.
The brackets for mkv tracks show the following information:
TrackID
TrackType
CodecID
TrackName
Language
ExtraInfo (resolution for video tracks, sample rate and channels for audio tracks)
Delay
EffectiveDelay
If any of these properties is not defined in the mkv file, then it will be empty.
The "Delay" field is the actual track delay as defined in the mkv header.
The "EffectiveDelay" is the actual delay that players use while playing the file. It is actually different only for the audio tracks, in cases that there is a delay defined for the video track. This is the value that is used for generating the output file name when extracting the track.

Thank you, I like the interface of this GUI.:D
:thanks:
Thanks for your support! :D

[gpower2]

New version (v1.5.2) is out. It fixes an issue with the Attachment file names, since newer MKVToolnix versions added the uid tag.

You can download it here: http://sourceforge.net/projects/gmkvextractgui/files/v1.5.2/gMKVExtractGUI.v1.5.2.7z/download

Change log:
Fix parsing for Attachment Filenames for newer mkvmerge versions (ignore uid tag)
Added tooltip information about the track list
Added functionality to remember window position

[hello_hello]

Thanks for the new version but.....

I went back to 1.5.1 pretty quick. I found the new pop-up tooltip to be fairly annoying, plus sometimes it'd pop up and cover tracks so I couldn't read them properly (depending where the cursor was at the time).

[LouieChuckyMerry]

Hi gpower2, I figured I'd come bother you here and leave you in peace at SourceForge, ha ha. And thanks for the new version :) . I'm not sure if it's technically a bug, but I wanted to let you know that the remembering of window position fails if either the top-side or the left-side of the gMKVExtractGUI window is even the slightest bit past the edge of the screen; the bottom-side and right-side of the window have no issue with passing the edge of the screen. I'm running Windows 7 64 bit. Also, the window size isn't remembered. I'm not sure if this was part of the update, but it would be a nice feature ;) . I've not noticed anything else but I've also not used your fine program much since the update. I only noticed the window position issue because I like to keep my Mkv extractor in the upper-left corner of my screen (MKVMerge in the upper-right) and the first thing I did upon opening the program was drag it up and left then resize it. I'll check it out some more soon, thanks again.

[gpower2]

Thanks for the feedback guyz!
I guess the tooltip was too much, I'll either remove it completely, or find another way to show the help.

As for the windows position and size, I didn't test it for negative coordinates, and I didn't incorporate the window's size in the settings.

Will fix and release a new version soon. ;)

Thanks again! :D

[gpower2]

New version (v1.5.3) is out, nothing too big, just fixing the remembering of window's initial position and size and removing the help tooltip.

Changelog:

Fixed setting the window's initial position to negative coordinates
Added the window's size to settings
Removed the help tooltip

[hello_hello]

Can I contribute by providing a link? ;)

gMKVExtractGUI.v1.5.3.7z (http://sourceforge.net/projects/gmkvextractgui/files/v1.5.3/gMKVExtractGUI.v1.5.3.7z/download)

Thanks for the new version.

[LouieChuckyMerry]

Awesome!. I opened the new version and it defaulted to the upper-left corner of my screen. I then resized the window, then closed it and reopened it (several times, just to be sure). And it's right where I left it. Thank you, I think that MKVMerge has a new best friend ;) . Now, if you can sort out a functional batch mode (each input file can have independent tracks selected for extraction) then I might have to name my first child gpower2...

[wanezhiling]

http://i.imgur.com/TqXBeFx.png
The processing bar always displays 0% when extracting tracks.

[bin_ch]

The processing bar always displays 0% when extracting tracks.
Works fine here.
Your mkvextract might be running with a language/translation other than English. (Chinese, I assume?)

gMKVExtractGUI forces mkvmerge and mkvinfo to use English, but apparently no such treatment for mkvextract.

For now you can do something like deleting/renaming the locale folder in your mkvtoolnix installation as a workaround.

[gpower2]

@wanezhiling
I need a little more information in order to help you, like the version of MKVToolnix you're using, if the mkv track gets actually extracted and if you are using a non default locale like bin_ch suggested.

[wanezhiling]

http://i.imgur.com/zL49n4F.png

Everything is fine, except the processing bar..

[gpower2]

Well, that's because extraction completes so quickly in your case, that mkvextract doesn't have the time to print the progress percentage.

There's really nothing I can do about that...

Think of it as a feature rather than a bug! :p

[STaRGaZeR]

- The progress bar stays at 0% all the time, at least when extracting only one subtitle track for a given mkv file.

I wrote this some pages ago :D

Back then I only tested with subtitle tracks, but long video steams don't print any progress here either, always at 0%. However, even if it finishes so fast that here is no time to update the bar, at least it should show 100% at the end.

[wanezhiling]

@gpower2

No, that's not correct.
I test some hugh files (need long extracting time), always 0% as well.

[gpower2]

Well, in that case I'll send you a debugging version in order to thoroughly look into this... Stay tuned...

[bin_ch]

wanezhiling, you haven't yet answer whether your mkvextract is running with non-English language.
Your screenshot clearly shows that you are on Chinese Windows, so your mkvextract will very likely be in Chinese, too. Try running it in command prompt and watch the output. The language setting in mkvmergeGUI works for MMG only, the command line tools will run in your system language if there's a matching translation, unless you force --ui-language.

And I guess your issue is the same, STaRGaZeR, since your Windows doesn't seem to be English either.

As far as I can see, currently gMKVExtractGUI doesn't force mkvextract English, and can't catch the progess info if the mkvextract output doesn't contain the word 'Progress'.
Try the suggestion above in #81 to make the translation unavailable. If that works, then that's where the problem is, just wait for an updated version, which I guess will come soon ;)

[wanezhiling]

bin_ch, sorry I missed your post in #81...
You are right, the progress bar works fine after deleting the locale folder.:thanks:

[gpower2]

I noticed that I forgot to enforce the ui language while executing mkvextract, so 1.5.4 will be out soon with this bug fix.

Thank you all for your feedback! :)

[STaRGaZeR]

bin_ch, yeah, my Windows is not in English. In my first post I even noticed that the log, which is probably just pasted from mkvextract output, wasn't in English either. It seems that the proper solution is just to pass the language parameter to mkvextract and everything will be fine :)

[Mildragon]

When I extract a font from an .mkv (attachment), I can't open or install it. For example, the application extracts: cfsmeb_.ttf [uid , which has not a known extension. What do I have to do?

[gpower2]

@Mildragon
If that's the case, then you should rename your file to "cfsmeb_.ttf".
I thought I fixed those cases, are you sure you're using the latest version (1.5.3)?

[gpower2]

New version is out, fixing the ui-language option for mkvextract and ensuring that progress will always be 100% when showing the successful completion message.

Link: http://sourceforge.net/projects/gmkvextractgui/files/v1.5.4/gMKVExtractGUI.v1.5.4.7z/download

Thanks again for all your feedback! :)

[STaRGaZeR]

Working fine now :)

Thanks!

[Mildragon]

OK problem solved. I was using an old version.... Thanks for the reply.

[gpower2]

A new version is out, adding some UI goodies and an audio extension fix for TrueHD tracks (thanks Giwyy!).

https://sourceforge.net/projects/gmkvextractgui/files/latest/download?source=files

Thank you all for your support! :D

[bin_ch]

Thanks for the new version.

But I noticed with 1.5.5, if there's another window (could be from other programs, or the log window of gMKVExtractGUI itself, or even the context menu of the track list) that overlays on top of the main GUI, when I switch back, there's a good chance that part of the overlay window would have some residual image on the main GUI.
Not sure if it's just me, doesn't happen on versions prior to 1.5.5

[gpower2]

On my effort to reduce the mad flickering of the checked list control, I may have broken it a bit...
Is it so annoying for me to release a new version, or can you bear with it for the time being?

[bin_ch]

I'm fine with it, just wanted to report it. That's only a slight flaw in the GUI anyway, doesn't affect functionality.

[netmask]

I have an odd problem, no matter how big or small I resize the gMKVExtract window the description next to the action buttons overlap almost making them unreadable.

[gpower2]

Could you please post the version you are using, as well as the OS version?

Also, please upload the screenshot to an image hosting site and paste the link here, thank you!

[bin_ch]

Hi gp2, regarding to the GUI issue, I guess r56 on SF is supposed to fix the issue, but if my build attempt succeeds, the problem is still there.
And I'm sorry that I should have mentioned that I am on Windows 7 with classic theme. In my tests, there's no such problem in the typical Win 7 aero theme (before or after r56). Win XP (classic theme and default Lunar theme) is also affected.
Hope the info helps.

[netmask]

Could you please post the version you are using, as well as the OS version?

Also, please upload the screenshot to an image hosting site and paste the link here, thank you!


The image is here http://i.imgur.com/r9zE2uH.jpg


The version of gMKV is the latest and my operating system is Windows 7 Ultimate 32 bit
I've had this problem for quite sometime with all the updates of gMKV and all the Windows updates
Thanks

[gpower2]

Hi gp2, regarding to the GUI issue, I guess r56 on SF is supposed to fix the issue, but if my build attempt succeeds, the problem is still there.
And I'm sorry that I should have mentioned that I am on Windows 7 with classic theme. In my tests, there's no such problem in the typical Win 7 aero theme (before or after r56). Win XP (classic theme and default Lunar theme) is also affected.
Hope the info helps.

Since you can compile from the source, perhaps you could do me a favor and check r60? There should be no issues anymore...

@netmask
The larger font scheme you are using is messing with the control sizes and location. I switched to DPI AutoScaleMode, but I don't know if it will fix your problem, since it seems it's a known .NET issue (http://stackoverflow.com/a/3043006)
I'll try to reposition the controls in order to prevent this from happening, in case the DPI AutoScale mode doesn't work.

[netmask]

The larger font scheme you are using is messing with the control sizes and location.

One of the "joys" of being 77 :) I am assured by my doctor I will be able to throw away my glasses next year when my cataracts come off....

[bin_ch]

r60 is still no good.

Here's a screenshot, after opening and resizing the log window:
http://oi59.tinypic.com/25p04ly.jpg


update:
The problem is partially fixed. With 1.5.5, the track list part is also affected.

r56 and r60 are similar, only the file info part is affected.

[gpower2]

Oh, I see. I didn't understand that you were also experiencing issues with the info text. I did make some changes with it, but it performed really smooth in Window 8.1.
I guess I'll change back that control too and try to find a more robust solution for the flickering. Thanks a lot for testing and feedback! :)

[gpower2]

New version is out (v1.6) and I'm so excited about it! :D
It introduces a new job mode and a new Job Manager form, basically this is how I imagined a batch mode should work.

I'm really looking forward to hearing (actually reading) your feedback and your suggestions about it! :)

http://sourceforge.net/projects/gmkvextractgui/files/v1.6/gMKVExtractGUI.v1.6.0.7z/download

[netmask]

Looking good, no overlap of description now. Will do some extraction tests later today.... many thanks

[bin_ch]

Thanks for the effort. The GUI issue is fixed.
The new job manage system is a great addition to the program.

[bin_ch]

Regarding to the batch mode, do you have plans to implement a feature that can open multiple files at once? (Or batch add jobs to the queue)
That would be useful when people want to extract something from a series of files with similar track combination.

[gpower2]

Regarding to the batch mode, do you have plans to implement a feature that can open multiple files at once? (Or batch add jobs to the queue)
That would be useful when people want to extract something from a series of files with similar track combination.

The thing about opening multiple files at once is how to group the similar tracks. There are many criteria for track similarity apart from the obvious (type), like track language, track comments, track ID, etc.
So in order to keep the GUI simple, I bypassed the idea. However, I haven't fully abandoned it, I just can't seem to find a nice formula for it.
Any ideas on the subject would be extremely useful!

[kongfl888]

Hi gpower2,
:thanks:

I found two bug (maybe)

1st.
First open the log, then open a *.mkv file, and finally open log again. You will see nothing in the log form(unless you click the 'Refresh' button).

2nd.
When you load a job from files , you can not add jobs to the manager anymore.

Talk about my idea.(I don't have an account of sourceforge.net. ISP limited. So maybe it looks messy...)

For the first one , I think it does better after adding an activated event.

private void frmLog_Activated(object sender, EventArgs e)
{
try
{
txtLog.Text = MKVLogger.LogText;
txtLog.Focus();
txtLog.Select(txtLog.Text.Length ,0);
txtLog.ScrollToCaret();
}
catch (Exception ex)
{
Debug.WriteLine(ex);
}
}


And the second,

//frmJobManager.cs line 381
//grdJobs.DataSource = new BindingList<gMKVJobInfo>(jobList);
grdJobs.DataSource = _JobList = new BindingList<MKVJobInfo>(jobList);
grdJobs.Refresh();


Or you have other ideas...

Anyway, this gMKVExtractGUI is very helpful and I very like it. :thanks:very much!

Best Regards.

[gpower2]

Thanks for your feedback kongfl888!
I will see to them as soon as I can! ;)

[hello_hello]

The thing about opening multiple files at once is how to group the similar tracks. There are many criteria for track similarity apart from the obvious (type), like track language, track comments, track ID, etc.
So in order to keep the GUI simple, I bypassed the idea. However, I haven't fully abandoned it, I just can't seem to find a nice formula for it.
Any ideas on the subject would be extremely useful!

Why do tracks need to be grouped?
Files and their tracks could be listed individually and the desired track to be extracted from each selected, then batch extracted without needing to add individual jobs to a queue first.

MKVCleaver also has another method for batch extracting tracks where you can simply select "audio track 1" etc in the right pane. One area where that could probably be improved is after selecting a track in batch mode every file could have it's "audio track 1" selected, but the user could check the individual files and deselect a track and/or select a different one if desired.

I'll confess I find not being able to open multiple files simultaneously a bit inconvenient at times. Quite often I'll highlight a bunch of them in Windows Explorer, right click and SendTo MKVCleaver. Being able to do the same with gMKVExtractGUI would be nice. Currently it's one file at a time from the SendTo menu.

Anyway, thanks for the new version!

[AMZMA]

is there any way to check all/uncheck all track, etc?

[gpower2]

Why do tracks need to be grouped?
Files and their tracks could be listed individually and the desired track to be extracted from each selected, then batch extracted without needing to add individual jobs to a queue first.

This is what gMKVExtractGUI currently does with the job manager. You open a video file, select the specific tracks for extraction and add the job. I can't imagine of an intuitive interface that opens and analyses all the files at once. As I said before, I am open to all suggestions.

MKVCleaver also has another method for batch extracting tracks where you can simply select "audio track 1" etc in the right pane. One area where that could probably be improved is after selecting a track in batch mode every file could have it's "audio track 1" selected, but the user could check the individual files and deselect a track and/or select a different one if desired

MKVCleaver tries to match the tracks of all the video files selected and does that grouping I was talking about. There are usually two different ways to implement batch processing, one being batch processing individual jobs, and the other to do exactly the same procedure many times. It is obvious that I implemented the first one.

is there any way to check all/uncheck all track, etc?

Yes, you can right click on the track list and you will see a context menu with many selection options. ;)

[hello_hello]

This is what gMKVExtractGUI currently does with the job manager. You open a video file, select the specific tracks for extraction and add the job. I can't imagine of an intuitive interface that opens and analyses all the files at once. As I said before, I am open to all suggestions.

I don't understand why you couldn't list all the open files in a single pane and each file in the list would have a sub-list of it's tracks, much the same way MKVCleaver does it.

MKVCleaver tries to match the tracks of all the video files selected and does that grouping I was talking about. There are usually two different ways to implement batch processing, one being batch processing individual jobs, and the other to do exactly the same procedure many times. It is obvious that I implemented the first one.

I'll confess I don't understand that. I'd interpret "batch processing individual jobs" as adding jobs to a queue individually, then running the job queue, much as gMKVExtractGUI does now. I'd have thought "doing exactly the same procedure many times" would be the definition of not batch processing.

Anyway.... my idea would be to have a pane which lists multiple files, and under each file would be a list of it's tracks. There'd be a way to select "video" or "audio 1" or "subtitle track 1" etc which would automatically check the appropriate track for each file. If you select "audio 1" for example, the first audio track for each file is checked, but before starting the batch extraction job there'd be the opportunity to change the selection manually. For file number three I might want to de-select audio 1 and select audio 2 instead. That sort of thing.

[AMZMA]

Yes, you can right click on the track list and you will see a context menu with many selection options. ;)

hohohohoho
never realize that before :thanks:

[dade49]

I've been looking for an easy way to read MKV metadata in my own C# app. Most of the libraries are compiled in C++ (libebml, libmatroska) and aren't easily usable for me. While the source code for mkvtoolnix is available, I cannot compile it in Visual Studio and am a Windows developer. I started trying to parse mkvinfo's output and was looking for a C# library to use. Your gMKVToolnix.dll gives me exactly what I need and I can now parse all my mkv's and read the metadata I need. Thank you very much for your hard work, as it has saved me lots of time doing it myself. :)

[dade49]

For those interested, create a new C# console app (or another C# app), add a reference to the DLL and then use the following:
using gMKVToolnix;

gMKVInfo mkvInfo = new gMKVInfo(gMKVHelper.GetMKVToolnixPathViaRegistry());
List<gMKVSegment> mkvSegments = mkvInfo.GetMKVSegments(@"C:\Path\file.mkv");
gMKVSegmentInfo mkvHeader = (gMKVSegmentInfo)mkvSegments[0];
string app = mkvHeader.WritingApplication;
string mux = mkvHeader.MuxingApplication;
string length = mkvHeader.Duration;
string date = mkvHeader.Date;
Thanks again!

[gpower2]

That's exactly why I separated the GUI from the Core element of the application, though I didn't expect to see it get used so soon by another fellow developer!
Thanks for your support and if you need anything, don't hesitate to ask! ;)

[dade49]

That's exactly why I separated the GUI from the Core element of the application, though I didn't expect to see it get used so soon by another fellow developer!
My usage is pretty simple. I have hundreds of MKV's, all compiled by me over the past several years. I needed an easy way to determine which ones I've compressed with Handbrake and which ones I merged with mkvmerge. I was comparing file size, but that's not accurate enough depending on the length of each file. I've been looking for an easy way to parse WritingApplication from each file. While invoking mkvinfo hundreds of times via your app isn't the most efficient method, it does seem to be the easiest. Your app is the first I've seen written in C#. Again; thank you. If I can contribute down the road, please let me know. I may be able to help with the requests for batching. I think people don't want to specify options for each file, IE: extract all PGS subtitles from all MKV's in this folder.

[dade49]

Thanks for your support and if you need anything, don't hesitate to ask! ;)
Any chance you would consider adding the CodecPrivate property from a Video track? I'm interested in parsing the h.264 profile details if they are defined. Thanks :)

[gpower2]

That would be a Media Info thingy, which I don't use.
gMkvExtractGUI is based solely and exclusively on MKVToolnix tools. So unfortunately I can't help you with that... :(

[dade49]

Well, mkvinfo (from MKVToolnix) shows this data for me:
CodecPrivate, length 96 (h.264 profile: High @L4.1)
This is a nice to have. If you're not interested I understand.

[gpower2]

You're right, I forgot about that property, since I switched to using mkvmerge's output for track information and not mkvinfo's.
I added the property to gMKVTrack class, parsed it from mkvinfo's output, and merged it with mkvmerge's information.

To make all this more developer friendly, I moved the post processing from the main form, to gMKVHelper class in the new public static function GetMergedMkvSegmentList, so now you just need to call this function and the returned list will contain the merged information from both mkvmerge and mkvinfo. ;)

You can get the source from SourceForge, since I won't be releasing a new version at this time.

P.S.
I noticed you use only the mkvinfo's output, which is not always correct, as stated here: http://forum.doom9.org/showthread.php?p=1669904#post1669904
I suggest you use the new function from gMKVHelper, and make a little loop to take the gMKVSegmentInfo segment, or use LINQ if you don't have .NET framework version limitations ;)

[dade49]

I suggest you use the new function from gMKVHelper, and make a little loop to take the gMKVSegmentInfo segment
I just got back to looking at this. I was able to pull the source and compile. Using this new method solves everything. Thanks for your support. I am a fan. :)

[Overdrive80]

Hi power2, using last version of gmkvextractgui and mkvmerge I get "55 (-400)_track2_spa_DELAY 16ms" if extract audio from matroska file with delay know (-400). IMHO, the filename should be "55 (-400)_spa_DELAY -400ms". Is one problem known?

Thanks.

EDIT: After test, mkvmerge trim frames of audio. Ignore my msg.

[wanezhiling]

I got an error with the file (https://www.sendspace.com/file/kxh667).

http://i2.tietuku.com/bc321de5ec434633.png

[alfixdvd]

I got an error with the file (https://www.sendspace.com/file/kxh667).

http://i2.tietuku.com/bc321de5ec434633.png

I updated to Mkvtoolnix 7.6.0 and I get the same error with a mkv file when I tray to open a mkv file to extract a subtitle.

MKVExtractGUI2 works fine with 7.6.0

Perhaps the trouble is in gMKVToolnix.dll?

[dade49]

As others have reported, it appears that the new version of mkvtoolnix 7.6.0 breaks the current version of gMKVExtractGUI 1.6.0.0. If you revert to mkvtooknix 7.5.0, this utility still works. You can still download the previous version of mkvtooknix in 64 bit (https://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-amd64-7.5.0-setup.exe) or 32 bit (https://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-7.5.0-setup.exe) while we wait for a fix from gpower2. :)

[gpower2]

I haven't downloaded mkvtoolix 7.6 in order to test gmkvextractgui, however, after quickly browsing the changelog, it appears that Mosu changed the exit code, so it naturally breaks gmkvextractgui.

A quick fix will be released tomorrow!

Thanks for your feedback everyone! :)

[gpower2]

gMKVExtractGUI 1.6.1 is out in the wild!

Mostly a bug fix release, now fully compatible with MkvToolnix 7.6.

Changelog:


Changed Log Form to refresh the log text when Activated and not when Shown (thanks kongfl888!)
Fix adding Jobs to the Job Manager after loading jobs from XML (thanks kongfl888)
Added CodecPrivate property to gMKVTrack class (thanks dade49)
Removed PostProcessing of segment lists to gMKVHelper class
Changed ExitCode check, in order to avoid error messages when only warnings are present in the output
Remove UTF-8 parameter from mkvinfo

[Nebudchanezzer]

gMKVExtractGUI 1.6.1 is out in the wild!

Mostly a bug fix release, now fully compatible with MkvToolnix 7.6.

Changelog:


Changed Log Form to refresh the log text when Activated and not when Shown (thanks kongfl888!)
Fix adding Jobs to the Job Manager after loading jobs from XML (thanks kongfl888)
Added CodecPrivate property to gMKVTrack class (thanks dade49)
Removed PostProcessing of segment lists to gMKVHelper class
Changed ExitCode check, in order to avoid error messages when only warnings are present in the output
Remove UTF-8 parameter from mkvinfo


Seems to be something wrong with the download, only get a "READ.ME"....

[gpower2]

That's just SourceForge being stubborn...
Latest file is once again the correct one, thanks for the feedback!

[bin_ch]

These messages are the result of explicitly setting the output charset to utf-8 while executing mkvinfo and mkvmerge.
It shouldn't matter to anyone, but I use them because of some localization problems the first versions had. Better safe than sorry, right?


Now that the corresponding code is commented out in the latest version, so it doesn't really matter, but just FYI, the code was triggering warnings because you mis-spelled UTF-8 as UFT-8, otherwise it should be fine.

[gpower2]

Thanks bin_ch, I will check it out!

I believe new version is working, right?

[STaRGaZeR]

Hi gpower2,

just found an annoying bug which should be easy to fix. If you minimize the main window and then close the program via right click - close on the taskbar, the following gets written in the settings ini file:

Initial Window Position X:-32000
Initial Window Position Y:-32000

When you open the program again, the main window is out of the monitor and cannot be accessed. Solution is to remove those lines from the ini, causing the program to reappear again at (0, 0).

The rest is working nicely, I'm using this extensively now :)

[gpower2]

Thanks for the feedback STaRGaZeR! :)
Fixed in latest trunk revision (r73)! ;)

[LeXXuz]

Thank you so much for this GUI! :thanks:

I wish I stumbled upon this earlier. Until today I used MKVextractGUI-2 which was a pain, especially with delayed audio tracks. :(

Right now I came across a mkv file with two audio tracks with a delay of about +8040ms.

Upon extraction the timecode files are correct (first frame timecode is 8040 as it should), however the tracklist in the GUI shows a delay of -2417483648, which looks like a buffer over/underflow in your code.

Edit: Tested this with a couple of files right now and they all show this vast delay. I use the latest mkvtoolnix build. Maybe you want to check in on this. :)

[gpower2]

Hi LeXXuz and thanks for the feedback!
I did test again with a lot of different delays and files, but I couldn't reproduce the overflow bug that you mention.

From your screenshot I noticed that the files you use are muxed with an ancient version of mkvtoolnix (v2.9.8) so perhaps that might be relevant.
Could you upload a sample file that triggers this behavior in order for me to check it?

[gpower2]

It's time for a new version, so gMKVExtractGUI 1.6.2 is out in the wild!

Mostly a bug fix release, addressing issues reported by users here and there.

Changelog:


Fix the wrong setting of the initial form position in the ini file when the form is minimized
Fix typo bug (UFT-8 instead of UTF-8) (thanks bin_ch!)
Add WindowState setting
Make Form remember the last window state
Add a fallback mechanism, in order to use the UserAppData folder for storing the app settings when the current user doesn't have read/write permissions to the app path


And remember, feedback is always welcome! :)

[bin_ch]

Thank you for the new version. It works perfectly.

Just FYI, mkvtoolnix author implemented a new mkvextract mode for cue extraction in Febuary:
mkvextract: implement cue extraction (https://github.com/mbunkus/mkvtoolnix/commit/fcb139a519151418cb9028f2ebbd80fa58f8c631)
mkvextract docs: document cue extraction (https://github.com/mbunkus/mkvtoolnix/commit/39d7f186030848a1681b70f7272889749e538ebb)
The feature doesn't seem to be very useful for ordinary users, but for the completeness of your GUI, you might want to have a look at it.

[gpower2]

Thanks for the info bin_ch, I will add it to the new version! :)

[STaRGaZeR]

Thanks for the new build :)

[alfixdvd]

With new version 8.4.0 Mkvtoolnix, gMKVExtractGUI 1.6.2 on start launch a error: The folder does not contain MkvToolnix.

best regards

[gpower2]

Just released v1.6.3 which is compatible with MkvToolnix v8.4 while keeping compatibility with previous versions. :)

Thanks for the feedback as always!

[alfixdvd]

Just released v1.6.3 which is compatible with MkvToolnix v8.4 while keeping compatibility with previous versions. :)

Thanks for the feedback as always!

Thanks, now works fine.

[djcj]

So far I've been using mkv-extractor-qt on Ubuntu, but I prefer to use the same programs on Windows and Linux so I gave it a try.
I can build and run the tool. And when I create symbolic links to the MKVToolnix programs it doesn't complain about not finding them:
djcj: Debug $ ln -s /usr/bin/mkvmerge mkvmerge.exe
djcj: Debug $ ln -s /usr/bin/mkvextract mkvextract.exe
djcj: Debug $ ln -s /usr/bin/mkvinfo mkvinfo.exe
djcj: Debug $ mono gMKVExtractGUI.exe

But when I open an mkv file it shows me an error:
http://fs2.directupload.net/images/150922/temp/w539pox6.png (http://fs2.directupload.net/images/150922/w539pox6.png)

[gpower2]

Hi djcj,

the truth is I haven't actually tried building on Linux, and the code is hardwires to work with windowsm even the parser of the executable's output (line endings, etc).

So the code is not tested to work on Linux out of the box. I could work with you to try and make it work on Linux too, if you could provide me with the Log output of the application, in order to check the executable's output.

Thanks for the feedback!

[djcj]

Depending on how I set the environment language before I start the program I either get no information (like on the screenshot) or it says "Error: There is no translation available for 'en'."

[gpower2]

If you press the Log button (on the bottom left corner of the application) you will get information about the output. Could you paste it here?

[djcj]

Here's the log from after selecting an input file:
[2015-09-23][23:53:40] Error: There is no translation available for 'en'.
That's the whole log. It looks like it doesn't even read any information from the input file.
Tested on SVN snapshot (r80).

[gpower2]

It seems that the mkvtoolnix you use does not have the english resources(???) and gMkvExtractGUI depends on the english output to do the parsing.

Could you try with the other environment setup that got you the first message and check the log?

[djcj]

Changing the language code in the source files from "en" to "en_US" and setting the environment variables in the shell to English seemed to do the trick. Well, at least I get more useful information from the log. And it pops up a message saying "No mkv segments were provided!".
Here's the full log: http://pasted.co/a843e8fb

[gpower2]

That's weird, when running "mkvextract --ui-language list", I get the output:

Available translations:
en (English)
ca (Catalan)
cs (Czech)
de (German)
es (Spanish)
eu (Basque)
fr (French)
it (Italian)
ja (Japanese)
lt (Lithuanian)
nl (Dutch)
pl (Polish)
pt_BR (Brazilian Portuguese)
pt (Portuguese)
ru (Russian)
sr (Serbian)
sv (Swedish)
tr (Turkish)
uk (Ukrainian)
zh_CN (Chinese Simplified)
zh_TW (Chinese Traditional)

I guess if you run the same command, you will get a different output, could you check it to be sure?

As for the "No mkv segments were provided!", that simply means that the parser couldn't identify any mkv segments in the output, although the log you posted seems to be normal.

I'll check it and post the results here.

Thanks for your efforts! :)

EDIT:
I realized I used "\r\n" to do the line splitting instead of Environment.NewLine, so in Linux it was definitely broken.
Fixed in r81, so you could check it out.

[djcj]

Now it works!
However, I need to run the tool with "LANGUAGE=C mono gMKVExtractGUI.exe" and I need to apply this patch:
--- a/gMKVToolnix/gMKVExtract.cs
+++ b/gMKVToolnix/gMKVExtract.cs
@@ -498,7 +498,7 @@
{
ProcessStartInfo myProcessInfo = new ProcessStartInfo();
myProcessInfo.FileName = _MKVExtractFilename;
- myProcessInfo.Arguments = String.Format("--ui-language en {0}", argParameters);
+ myProcessInfo.Arguments = String.Format("--ui-language en_US {0}", argParameters);
myProcessInfo.UseShellExecute = false;
myProcessInfo.RedirectStandardOutput = true;
myProcessInfo.StandardOutputEncoding = Encoding.UTF8;
--- a/gMKVToolnix/gMKVInfo.cs
+++ b/gMKVToolnix/gMKVInfo.cs
@@ -171,7 +171,7 @@
{
// add the default options for running mkvinfo
List<OptionValue> optionList = new List<OptionValue>();
- optionList.Add(new OptionValue(MkvInfoOptions.ui_language, "en"));
+ optionList.Add(new OptionValue(MkvInfoOptions.ui_language, "en_US"));
//optionList.Add(new OptionValue(MkvInfoOptions.command_line_charset, "\"UFT-8\""));
//optionList.Add(new OptionValue(MkvInfoOptions.output_charset, "\"UFT-8\""));
// check for extra options provided from the caller
--- a/gMKVToolnix/gMKVMerge.cs
+++ b/gMKVToolnix/gMKVMerge.cs
@@ -83,7 +83,7 @@
using (Process myProcess = new Process())
{
List<OptionValue> optionList = new List<OptionValue>();
- optionList.Add(new OptionValue(MkvMergeOptions.ui_language, "en"));
+ optionList.Add(new OptionValue(MkvMergeOptions.ui_language, "en_US"));
//optionList.Add(new OptionValue(MkvMergeOptions.command_line_charset, "\"UTF-8\""));
//optionList.Add(new OptionValue(MkvMergeOptions.output_charset, "\"UTF-8\""));
optionList.Add(new OptionValue(MkvMergeOptions.identify_verbose, String.Empty));


Maybe you can let gMKVExtract check whether it has to set "en", "en_US" or something else by checking the output of "--ui-language list".
Here's the list I get:
en_US (English)
ca_ES (Catalan)
cs_CZ (Czech)
de_DE (German)
es_ES (Spanish)
eu_ES (Basque)
fr_FR (French)
it_IT (Italian)
ja_JP (Japanese)
lt_LT (Lithuanian)
nl_NL (Dutch)
pl_PL (Polish)
pt_BR (Brazilian Portuguese)
pt_PT (Portuguese)
ru_RU (Russian)
sr_RS (Serbian Cyrillic)
sr_RS@latin (Serbian Latin)
sv_SE (Swedish)
tr_TR (Turkish)
uk_UA (Ukrainian)
zh_CN (Chinese Simplified)
zh_TW (Chinese Traditional)

Another minor issue is that the progress bar stays at 0% during the extraction phase and jumps directly to 100% after finishing.


EDIT:

Is it possible to add a command line option to tell gMKVExtractGUI.exe that it should use a specific .ini file from another directory? That would make it easier to run it from a system directory and saving the config file in the user directory.
And the source code license according to the project page is public domain, right?

[gpower2]

That's really good news! I expected it would take more changes to make it run on Linux!

As for the issues:

However, I need to run the tool with "LANGUAGE=C mono gMKVExtractGUI.exe"

I'd expect that the "LANGUAGE=C" should not be needed, since the app executes all the cli commands with the "ui-language" parameter in order to be sure that the output is always english. Could you give it a try?

I need to apply this patch:
- myProcessInfo.Arguments = String.Format("--ui-language en {0}", argParameters);
+ myProcessInfo.Arguments = String.Format("--ui-language en_US {0}", argParameters);

Since on Windows the "en" seems to work for everyone, I could just change it on the fly by using the new IsLinux flag.

Another minor issue is that the progress bar stays at 0% during the extraction phase and jumps directly to 100% after finishing.

That could mean that the parser couldn't parse the progress percentage from the output, or that mono can't update the UI asychronously.
Could you post the Log to see what the output writes?

Is it possible to add a command line option to tell gMKVExtractGUI.exe that it should use a specific .ini file from another directory? That would make it easier to run it from a system directory and saving the config file in the user directory.

In r77, I had made a fallback mechanism in order to write to UserAppData when the current user does not have write permissions to the current folder. To be honest I don't know how this will work on Linux.
I could try to incorporate a cli argument like -i or --ini in order to custom load an ini file.

And the source code license according to the project page is public domain, right?

That's exactly right! :)
You can use it however you like!

Thanks again for all your feedback!

[djcj]

I'd expect that the "LANGUAGE=C" should not be needed, since the app executes all the cli commands with the "ui-language" parameter in order to be sure that the output is always english. Could you give it a try?
Somehow the output of the log is in German for me (my default environment language) and the app pops up that "No mkv segments found" message again. Maybe the environment variables have a higher priority and they're kind of overwriting the cli commands? Here's the log if you need it: http://pasted.co/468748b5


That could mean that the parser couldn't parse the progress percentage from the output, or that mono can't update the UI asychronously.
Could you post the Log to see what the output writes?
http://pasted.co/b58a2ad1


In r77, I had made a fallback mechanism in order to write to UserAppData when the current user does not have write permissions to the current folder. To be honest I don't know how this will work on Linux.
Great. It actually works. I've put it into a system directory and then it writes the config into /home/djcj/.config/Gpower2/gMKVExtractGUI/1.6.3.0/gMKVExtractGUI.ini

[gpower2]

Somehow the output of the log is in German for me (my default environment language) and the app pops up that "No mkv segments found" message again. Maybe the environment variables have a higher priority and they're kind of overwriting the cli commands? Here's the log if you need it: http://pasted.co/468748b5

I guess I have to ask Mosu about that one...

Originally Posted by gpower2
That could mean that the parser couldn't parse the progress percentage from the output, or that mono can't update the UI asychronously.
Could you post the Log to see what the output writes?
http://pasted.co/b58a2ad1

The output log is as expected. I checked the relevant code again and everything seems to be bug free, so I'm guessing it's a mono issue.

Great. It actually works. I've put it into a system directory and then it writes the config into /home/djcj/.config/Gpower2/gMKVExtractGUI/1.6.3.0/gMKVExtractGUI.ini

I guess that covers your request, right? I still might implement the cli argument, since it's actually a cool idea!

Thanks again! :)

[gpower2]

After reading the mkvmerge manual more carefully I noticed this:

--ui-language code
Forces the translations for the language code to be used (e.g. 'de_DE' for the German translations). It is preferable to use the environment variables LANG, LC_MESSAGES and LC_ALL though. Entering 'list' as the code will cause mkvmerge(1) to output a list of available translations.

That's why you have to set the LANGUAGE environment variable beforehand!

So, I changed the code a bit, to set the needed environment variables to "C" locale when on Linux and not to use the "--ui-language" cli option.
The environment variables values should only affect the current process, so you won't have to worry about messing with your locale settings.

Could you check r82 without patching it and without adding LANGUAGE=C before running it?

[magsoud]

Please Add Checkbox "Use Source Dir for Output"

[gpower2]

By default the output dir is the same with the source dir, unless you check the "Lock output" checkbox.

So your request is already fulfilled! :)

[Thunderbolt8]

the program keeps crashing for me after updating mkvtoolnix to 8.5.0. does anyone else have this problem?

[gpower2]

At what phase does the app crash?
It crashes immediately on start up?
Or when you open a file?

EDIT:
It appears that the 8.5.0 installer deletes all files in "C:\Program Files\MKVToolnix" except the ones with "exe" extension.
So if you had put the gMKVExtractGUI files in this directory, you will find that the file "gMKVToolnix.dll" is missing.
In that case you should re-download gMKVExtractGUI and put all the files in the MKVToolnix directory again.

[Thunderbolt8]

thanks, it works again.

[kypec]

Your tool does great job but there is one cosmetic annoyance that you could fix easily I hope:
Individual and total jobs percentage labels should be moved one row further down so as to align with their progress bars accordingly - see screenshot:
http://i65.tinypic.com/309q1si.jpg
:thanks:

[gpower2]

I will fix it in the new version! ;)

Thanks for the feedback! :D

[magsoud]

two suggestion for MKVExtractGUI:
1) When the application is extracting, Show warning for click on Close!
2) Show "Success Extraction" in Main Window!

[gpower2]

New version 1.6.4 is out, mostly containing fixes reported from users here, but the most exciting thing about this version, is that it's the first to fully support Linux, thanks to feedback from djcj!

Download link:
http://sourceforge.net/projects/gmkvextractgui/files/v1.6.4/gMKVExtractGUI.v.1.6.4.7z/download

Changelog:

Add support for Linux (thanks djcj)
Add a start up check to ensure that gMKVToolnix.dll is present in the same directory as gMKVExtractGUI.exe
Fix progress labels position in JobManager form (thanks kypec)
Add check on closing in order to ensure that an extraction process does not get interrupted unintentionally (thanks magsood)
Fix Job Manager form Minimum Size
Add context menu to Job Manager Form in order to easily reset job states


Enjoy! :)

[johnsonlam]

Hi,

The download binary name is gMKVExtractGUI 1.6.4.7, in fact it's 1.6.4.0.
When I drag a MKV made with mkvtoolnix-64bit-8.6.1 it complain "Input string was not in a correct format".

Thanks.

[gpower2]

Hi,

The download binary name is gMKVExtractGUI 1.6.4.7, in fact it's 1.6.4.0.
When I drag a MKV made with mkvtoolnix-64bit-8.6.1 it complain "Input string was not in a correct format".

Thanks.

Hi, the download binary is 1.6.4 but it's file extension is 7z, so perhaps you thought that the version is 1.6.4.7 while it's indeed 1.6.4.

Using MkvToolNix 8.6.1 works for me so you have to provide more details with your problem. First step would be to paste the results from the Log window.

[johnsonlam]

Hi, the download binary is 1.6.4 but it's file extension is 7z, so perhaps you thought that the version is 1.6.4.7 while it's indeed 1.6.4.

Using MkvToolNix 8.6.1 works for me so you have to provide more details with your problem. First step would be to paste the results from the Log window.

Sorry! I'm too hurry to report the problem.
Attached was the log and the actual message dialog.

Thanks.

Rgds,
Johnson.

[isidroco]

Hi, I'm trying to make CDs from some MKVs, and it would be VERY useful to be able to convert XML to CUE format. I need this:

PERFORMER "Electric Light Orchestra"
TITLE "Hyde Park"
FILE "Hyde Park.wav" WAVE
TRACK 01 AUDIO
TITLE "01 - All Over The World"
PERFORMER "Electric Light Orchestra"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "02 - Evil Woman"
PERFORMER "Electric Light Orchestra"
INDEX 01 04:29:10
...

instead of this:

<?xml version="1.0"?>
<!-- <!DOCTYPE Chapters SYSTEM "matroskachapters.dtd"> -->
<Chapters>
<EditionEntry>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>1</EditionFlagDefault>
<EditionUID>16840779534454836898</EditionUID>
<ChapterAtom>
<ChapterUID>11141243726119184491</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:04:29.135533333</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>01 - All Over The World</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>11775360033362589863</ChapterUID>
<ChapterTimeStart>00:04:29.135533333</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:09:09.882666666</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>02 - Evil Woman</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
.....

[hubblec4]

Hi, I'm trying to make CDs from some MKVs, and it would be VERY useful to be able to convert XML to CUE format.


Such a feature was requested for my chapterEditor and its on the ToDo list.
The person are used this tool(chap2cue (http://www.fr-an.de/soft/01/)) at the moment.

[gpower2]

Sorry! I'm too hurry to report the problem.
Attached was the log and the actual message dialog.

So sorry for the late response, unfortunately I thoroughly checked the source code and couldn't find where this error might be.
Could you upload me a piece of the video that throws the error in order to properly debug it?

Hi, I'm trying to make CDs from some MKVs, and it would be VERY useful to be able to convert XML to CUE format. I need this:

PERFORMER "Electric Light Orchestra"
TITLE "Hyde Park"
FILE "Hyde Park.wav" WAVE
TRACK 01 AUDIO
TITLE "01 - All Over The World"
PERFORMER "Electric Light Orchestra"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "02 - Evil Woman"
PERFORMER "Electric Light Orchestra"
INDEX 01 04:29:10
...

instead of this:

<?xml version="1.0"?>
<!-- <!DOCTYPE Chapters SYSTEM "matroskachapters.dtd"> -->
<Chapters>
<EditionEntry>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>1</EditionFlagDefault>
<EditionUID>16840779534454836898</EditionUID>
<ChapterAtom>
<ChapterUID>11141243726119184491</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:04:29.135533333</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>01 - All Over The World</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>11775360033362589863</ChapterUID>
<ChapterTimeStart>00:04:29.135533333</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:09:09.882666666</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>02 - Evil Woman</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
.....

What you are asking is a converter from XML chapters to CUE format. Since the XML chapters does not contain all the information needed for the CUE file, the converter should demand from the user to enter the rest of the information. As you can see, all this is not in the scope of extracting tracks from matroska files, so I will not implement such a feature.
You could use another utility like hubblec4's chapterEditor. ;)

[bin_ch]

So sorry for the late response, unfortunately I thoroughly checked the source code and couldn't find where this error might be.
Could you upload me a piece of the video that throws the error in order to properly debug it?

Just a wild guess.
Don't know whether you have already noticed, the log johnsonlam provided contains some question marks (track_name for the subtitle tracks, and file name for attachment id 6), which indicates a very possible text encoding issue.
MKVToolNix used to write BOM for UTF-* encoded text files, but version 8.6.0 of MKVToolNix included a change to not write BOM anymore. The change has been reverted in 8.7.0.
Considering johnsonlam was using an affected version (8.6.1), would it be possible that the problem is caused by that change?
I suggest johnsonlam giving 8.7.0+ a try, to see if the problem still exists.

[isidroco]

What you are asking is a converter from XML chapters to CUE format. Since the XML chapters does not contain all the information needed for the CUE file, the converter should demand from the user to enter the rest of the information. As you can see, all this is not in the scope of extracting tracks from matroska files, so I will not implement such a feature.
You could use another utility like hubblec4's chapterEditor. ;)

The only info it may not have is title/performer which can be omited if absent (title could be filename). Basically, INDEX 01 is the position of each <ChapterTimeEnd> with decimals translated to frames. And track TITLE is <ChapterString> (which can be set to a generic "Track nn" if absent). Resulting text file can be edited later if one wants more data in it, but it is a huge improvement to be able to have a CUEsheet of extracted WAV.

[rock]

I get error "Input string was not in a correct format"
file: http://a.pomf.cat/fersvc.mkv (got from mpv issue tracker)
I use gMKVExtractGUI v1.6.4, MKVToolNix 8.5.0 64-bit, on Windows 8.1
I can open it and extract with latest MkvExtractGUI-2

regards :)

[gpower2]

Thank you very much for the feedback! :)

I found the bug, it happens when the mkv file has only one chapter entry!

I will shortly release a bug fix version! ;)

Thanks again

P.S.
It looks like it's the same bug that johnsonlam had reported.

[gpower2]

New version 1.6.5 is out, fixing a notorious bug that affected all files that contained only 1 chapter entry! It also incorporates new "cues" extraction mode for more advanced users of mkvtoolnix, and also a new chapter type, CUE, that automatically converts XML chapters to CUE sheet format.

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v1.6.5/gMKVExtractGUI.v1.6.5.7z/download

Changelog:

Fix parsing the number of chapter entries in case there is only one chapter entry (thanks johnsonlam, rock)
Change gMKVToolnix to gMKVToolNix
Add new extraction mode "cues" (thanks bin_ch)
Add new Chapter Type "CUE" which transforms XML chapters to Cue Sheet (thanks isidroco)


Enjoy! :)

[bin_ch]

Thanks for the new version.

One bug report concerning Cue Sheet output:
The INDEX are wrong for chapter entries whose ChapterTimeStart exceed one hour, for example, 01:05:00.0000 should be 65:00:00, but gets written as 05:00:00

[gpower2]

One bug report concerning Cue Sheet output:
The INDEX are wrong for chapter entries whose ChapterTimeStart exceed one hour, for example, 01:05:00.0000 should be 65:00:00, but gets written as 05:00:00

Thanks for the feedback bin_ch! :)
Indeed I forgot to add the hours from the chapter to the minutes of the cue sheet format. I'll fix it in the new version. ;)

I'd also like to ask you if you checked the new cues extraction mode.

Thanks again!

[bin_ch]

Oh yeah, forgot to mention that. Tried the cues extraction and it's working great. Thank for implementing it.

[gpower2]

New version 1.6.6 is out, fixing a bug in the CUE Sheet format chapters, and also incorporating support for older versions of MKVToolNix (v4.x).

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v1.6.6/gMKVExtractGUI.v1.6.6.7z/download

Changelog:

Fix minutes in Cue Sheet Chapter Format (thanks bin_ch)
Add support for older mkvtoolnix versions (v4.x)


Enjoy! :)

[hubblec4]

Hi gpower2

For what these two entries are used?
REM GENRE ""
REM DATE ""

GENRE and DATE are not listed in the specs (http://digitalx.org/cue-sheet/syntax/).

[gpower2]

Hi gpower2

For what these two entries are used?
REM GENRE ""
REM DATE ""

GENRE and DATE are not listed in the specs (http://digitalx.org/cue-sheet/syntax/).

According to digitalx.org, "REM" is a recognized command and according to the wikipedia sample here:
https://en.wikipedia.org/wiki/Cue_sheet_(computing)#Examples
Genre and Date are commonly used comments in cue sheet for CD's.

That's why I included them, in order to make it easier for the user who edits the file afterwards. ;)

[hubblec4]

Thanks for this info. I will implement it too.

[wanezhiling]

dvb sub in mkv is not suuported?
sample: https://www.sendspace.com/file/0s21qa

[gpower2]

It seems that mkvextract does not like CODEC_ID S_DVBSUB...

It's a question that should be asked in the MKVToolNix thread here: http://forum.doom9.org/showthread.php?t=155732 , since gMKVExtractGUI is just a GUI for mkvextract and doesn't contain the actual demuxing code. ;)

[TalasNetrag]

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?

[gpower2]

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?

[Solon8]

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?

I actually had the same thought yesterday. The only reason would be to gain some (very little) time, users are lazy. There's just no need for a popup when it's successful.

[wanezhiling]

http://i.imgur.com/1VhyyNH.png
Something is wrong with today's MKVToolNix v9.0.0 (http://forum.doom9.org/showpost.php?p=1762105&postcount=4022)...

[gpower2]

It appears that this change:
A change a lot of users of Windows and Mac OS will hopefully welcome is that mkvinfo launches with its GUI by default now unless the option "--no-gui" is given. Users of these two OSes often start mkvinfo by clicking on the executable instead of using start menu entries making adding the parameter "--gui" somewhat difficult. The behavior for other OSes has not been changed.

invokes MkvInfo executable with the GUI and not the cli.

I'll upload a new version fixing the problem ASAP.

Thanks for the instant feedback! :)

[Telion]

The only reason would be to gain some (very little) time, users are lazy. There's just no need for a popup when it's successful.
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.

[Wildfire]

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.

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...

Well, I'll just wait for the updated gMKVExtractGUI to see if that fixes it.

[alfixdvd]

http://i.imgur.com/1VhyyNH.png
Something is wrong with today's MKVToolNix v9.0.0 (http://forum.doom9.org/showpost.php?p=1762105&postcount=4022)...

In MKVExtractGui-2 occurs the same.

[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.

[bin_ch]

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 for me, too.

Are you using Non-English Windows?
If so, you might want to give the pre builds (https://mkvtoolnix.download/windows/pre/) of MKVToolNix a try.

[Wildfire]

No problems for me, too.

Are you using Non-English Windows?
If so, you might want to give the pre builds (https://mkvtoolnix.download/windows/pre/) of MKVToolNix a try.

My Windows is non-English too (Dutch, to be precise). No problems here.

[alfixdvd]

I will use MKVcleaver because it works fine with both versions of mkvtoolnix

[bin_ch]

I will use MKVcleaver because it works fine with both versions of mkvtoolnix
So have you tried the pre-builds?

I was suggesting the pre-builds of mkvtoolnix because version 9.1.0 introduced a bug in the output of mkvmerge identification, which gMKVExtractGUI relies on to get file info.
The bug has been fixed in pre-builds 01201 and higher.

If it's still no good with the pre-builds, then you might have indeed found a bug in gMKVExtractGUI.
In that case, you'll need to provide more detailed information for the author to investigate, for example, manually execute mkvmerge.exe --ui-language en --identify-verbose file.mkv and post the output.

[alfixdvd]

So have you tried the pre-builds?

I was suggesting the pre-builds of mkvtoolnix because version 9.1.0 introduced a bug in the output of mkvmerge identification, which gMKVExtractGUI relies on to get file info.
The bug has been fixed in pre-builds 01201 and higher.

If it's still no good with the pre-builds, then you might have indeed found a bug in gMKVExtractGUI.
In that case, you'll need to provide more detailed information for the author to investigate, for example, manually execute mkvmerge.exe --ui-language en --identify-verbose file.mkv and post the output.

I installed 9.1.0 final over 9.0.1 final without de-install, and now works fine.

I don't understand what happens.

If I have another issue I will try : mkvmerge.exe --ui-language en --identify-verbose file.mkv to try to identfy the problem.

thanks

[gpower2]

Sorry for the delayed response alfixdvd...

In gMKVExtractGUI v1.8 & MKVToolNix 9.1.0 the identification process relies solely on mkvmerge.exe and not on mkvinfo.exe like it used to.
Perhaps something happened with your installation with MKVToolNix and that caused the problems you were having. ;)

As the other users suggested, if you happen to run again into problems with gMKVExtractGUI, you could try to run the command "mkvmerge.exe --ui-language en --identify-verbose file.mkv" manually, and post the output here. ;)

Thanks for your feedback! :)

[hello_hello]

I installed 9.1.0 final over 9.0.1 final without de-install, and now works fine.

I don't understand what happens.

I generally download the portable MKVToolNix and unzip it to an appropriately named folder, after renaming the old MKVToolNix folder to something like "MKVToolNix_old". If you copy the ini file from the old MKVToolNix folder to the new one it'll retain the previous settings.

That way it's fairly easy to change the version of MKVToolNix gMKVExtractGUI is using, without having to uninstall/install it.

[Perenista]

I am having this problem here:
Extraction of track ID 1 with the CodecID 'A_MS/ACM' is not supported.

Tried to do this:
http://i.imgur.com/KNjSAzp.png

[gpower2]

You are posting a screenshot of another application (MKVExtractGUI2) and not of gMKVExtractGUI, so I can't help you.

[Perenista]

You are posting a screenshot of another application (MKVExtractGUI2) and not of gMKVExtractGUI, so I can't help you.This error I reported is happening with this app, gMKVExtractGUI. Here's the screenshot from gMKVExtractGUI:

http://i.imgur.com/kvSdFlT.png

And only affects this PCM 5.1 track:

http://i.imgur.com/Tb6pB1z.png

In case you are wondering, this is not the only app that isn't capable of extracting this PCM 5.1 track.

As I reported on Doom9, these can't do the same, too:

- MKVCleaver (http://forum.doom9.org/showpost.php?p=1786484&postcount=434)
- MKVExtractGUI (see previous post)

So, that means this track is stuck inside my MKV (extracted from a Blu-ray - it's lossless).

[Mosu]

mkvextract, the tool all of those GUIs are actually using, does not support that particular CodecID type. Therefore none of those GUIs can extract that track. I don't have any plans for adding support for it either. Sorry.

[Perenista]

OK, I am using this app for the job:
http://taudioconverter.sourceforge.net/
https://hydrogenaud.io/index.php/topic,104311.0.html
http://forum.blu-ray.com/showthread.php?t=209091

It's extracting in the method "COPY AUDIO", as a WAV (and saving in a folder called LOSSLESS-AUDIO), so I am assuming it is not really reencoding anything. I have only seen a bunch of movies/old Blu-rays using a PCM track.

P.S. The track wasted 4.79 GB in WAV (the movie has 2h28m52s).

[djcj]

There are still some case-sensitivity issues left when I try to build revision 116 on Linux:
--- a/gMKVExtractGUI/gMKVExtractGUI.csproj
+++ b/gMKVExtractGUI/gMKVExtractGUI.csproj
@@ -126,7 +126,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.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

[gpower2]

Thanks for your feedback, sorry for the delay...

I believe the issue should be fixed in r118. ;)

[gpower2]

New version 1.9.0 is out and it has some important changes. First of all, gMKVExtractGUI from now on will require .NET Framework v4 instead of v2. The main reason for this change was that newer Windows versions (8.1+) come with .NET v4 prebundled, while you have to download .NET v3.5 separately. Since .NET v4 is the last version that is supported by WinXP, I hope that there won't be any compatibility issues. Also, gMKVExtractGUI from now on will use the JSON output from mkvmerge and not the verbose text, so a JSON parser was required and Newtonsoft.Json.dll now comes bundled. In order to keep backwards compatibility, the JSON output will be used only for MKVToolNix version v9.6.0 and newer. Another change, that is untested since I don't have the required setup, is that now the app is DPI aware, so if anyone has the necessary setup, I would really appreciate the feedback!

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v1.9.0/gMKVExtractGUI.v1.9.0.7z/download

Changelog:

Switch to .NET v4
Add new JSON parser for reading the JSON identification info from mkvmerge (Based on NewtonSoft JSON.NET, Newtonsoft.Json.dll)
Fix issues with Linux case sensitivity (hopefully!) (thanks djcj!)
Fix locale issues with Linux (hopefully!) (thanks djcj and Mosu!)
Make application dpi aware (thanks stax76!)
Fix initial size when there is no ini file (thanks bin_ch!)
Fix bug when in job mode and popup checkbox is unchecked and adding a job results in status label showing "Extraction completed!" (thanks bin_ch!)
Switch to using SaveFileDialog and OpenFileDialog instead of FolderBrowserDialog (thanks arestarh!)
Fix rare case where Track properties in mkvmerge verbose identification occupy more than one line
Change namespace from gMKVToolnix to gMKVToolNix


Enjoy people! :D

[amayra]

DPI aware ?????
i think we're gonna have a problem here sir
https://s28.postimg.org/kfh571r4t/screenshot_15.png

[gpower2]

Hmm, it seems that the initial minimum size is not enough in those HighDPI environments.
You can however resize the windows and it will be automatically saved and remembered next time you run it. ;)

Thanks for your feedback! :D

PS.
However, it does look a lot crisper now, doesn't it? :)

[hello_hello]

New version 1.9.0 is out and it has some important changes. First of all, gMKVExtractGUI from now on will require .NET Framework v4 instead of v2. The main reason for this change was that newer Windows versions (8.1+) come with .NET v4 prebundled, while you have to download .NET v3.5 separately. Since .NET v4 is the last version that is supported by WinXP, I hope that there won't be any compatibility issues.

Just thought I'd let you know gMKVEtractGUI seems fine with MKVToolNix 9.6.0 on XP so far.

Thanks.

[gpower2]

@hello_hello
That is excellent! :) Thanks for the feedback! ;)

@djcj
Could you check r126 to see if it works as expected? I think I finally solved all of Linux issues, both at build time and runtime.

[DVD Maniac]

Installs fine but when I click Extract I get this error.

Windows 10 Prof
gMKVExtract v 1.9.0.7

[gpower2]

@DVD Maniac

Hi there and happy new year! :)
Your attachment got approved today and I was surprised to see that the title bar of the form in gMKVExtractGUI does not have the version! It should be "gMKVExtractGUI v1.9.0.0 -- By Gpower2" and not just "gMKVExtractGUI". Are you sure you are using the latest version from SourceForge site?
In any case, could you press the Log button and paste the contents here?

[djcj]

@djcj
Could you check r126 to see if it works as expected? I think I finally solved all of Linux issues, both at build time and runtime.
I could check how it works on Linux, sure.

By the way you should probably include Newtonsoft.Json's license text or a link to its Github site in your Libs folder.
Now that I think about it, the icon may be GPL, since it's based on MKVToolNix's icon.


Update:

So far it's working, but only if I build the binaries from source with Mono. If I use your pre-compiled version I get this "No mkv segments were provided" error. There is also a little layout issue as seen on the screenshot. The progress bar still doesn't work, by the way.

[Bal65]

Windows 7 Pro
gMKVextract v1.9.0
MKVtoolNix v9.9.0

gMKVextract doesn't remember screen width & height between sessions.

If I look in gMKVExtractGUI.ini "after" it's been closed, the values match whatever screen size I set using the mouse to stretch it out, but next time it starts it always reverts to 640x600 and overwrites the previous values "immediately" upon startup.

Note, if I start it maximized, it remembers that setting.

Also, if I set a specific Output Directory and click the "lock" option, while it writes the directory value into gMKVExtractGUI.ini, it doesn't actually use it when restarted (i.e. the Output Directory box is empty and the lock option is unchecked.)

[gpower2]

New version 1.9.1 is out and it is more of a bug fix release, especially for Linux. Hopefully now the compiled binaries should work out of the box on Linux (tested them on Ubuntu).
@Bal65 I believe the settings should have no problem now, however if you're still having problems, please check the Log form for the detected settings path and post the results here. Thanks for the feedback! :)

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v1.9.1/gMKVExtractGUI.v1.9.1.7z/download

Changelog:

Implement new method to read standard output character by character (fixes Linux parsing)
Replace hard-coded newline characters with Environment.NewLine
Improve parsing of mkvinfo output
Add exceptions to the log
Change version identification in Linux
Add more sanity checks
Fix copy-paste bugs in Settings
Add more log messages in Settings
Simplify version checking for Linux and OSX for mkvinfo and mkvmerge
Fix small cosmetic bug for Linux in main Form
Add LICENSE.md for NewtonSoft
Add log for detecting versions
When on Linux, check for mkvmerge in /usr/bin first


Enjoy people! :D

[djcj]

The progress is displayed correctly if I set my environment variable LANGUAGE to C or en_US.UTF-8, otherwise it stays at 0% until it's finished. It looks like --ui-language doesn't do the thing.

--- gMKVExtractGUI/Program.cs
+++ gMKVExtractGUI/Program.cs
@@ -37,13 +37,13 @@
{
// If on Linux, set the enironmnet variables for locale to C (default locale)
// Actually set to en_US.UTF-8 locale in order to support UTF-8 filenames in Linux
- //// After clearing things with Mosu, this is not necessary anymore, since --ui-language is more than enough!
- //if (IsOnLinux)
- //{
- // Environment.SetEnvironmentVariable("LC_ALL", "en_US.UTF-8", EnvironmentVariableTarget.Process);
- // Environment.SetEnvironmentVariable("LANG", "en_US.UTF-8", EnvironmentVariableTarget.Process);
- // Environment.SetEnvironmentVariable("LC_MESSAGES", "en_US.UTF-8", EnvironmentVariableTarget.Process);
- //}
+ if (IsOnLinux)
+ {
+ Environment.SetEnvironmentVariable("LC_ALL", "en_US.UTF-8", EnvironmentVariableTarget.Process);
+ Environment.SetEnvironmentVariable("LANG", "en_US.UTF-8", EnvironmentVariableTarget.Process);
+ Environment.SetEnvironmentVariable("LC_MESSAGES", "en_US.UTF-8", EnvironmentVariableTarget.Process);
+ Environment.SetEnvironmentVariable("LANGUAGE", "en_US.UTF-8", EnvironmentVariableTarget.Process);
+ }
Application.Run(new frmMain());
}
}

[gpower2]

That's quite troubling...
I guess my box plays nicely because I already have en_US locale.
Could you post the log of both cases in order to further troubleshoot the issue?

Thanks for all your feedback! :)

[djcj]

I've attached 2 logs. By default my language is set to de_DE.UTF-8.

[Bal65]

Nope, still having the same problem.

The Detected settings path in the log is always the "same" directory containing the 3 main program files (i.e. if they're in C:\Temp\gMKVextract, that's the path detected and where the initial gMKVExtractGUI.ini gets created.)

Just so we're clear about what's happening...

One the very first run, gMKVExtractGUI.exe creates a new gMKVExtractGUI.ini with a set of default settings.

The values in that new gMKVExtractGUI.ini change whenever I resize the GUI window and/or set the various paths (FYI, the values change "dynamical" as I resize the GUI or input paths.)
Those values remain whatever they are when I exit the program.

However, when I restart gMKVExtractGUI.exe, even if I simple shut it down and restart it, it always overwrites the existing gMKVExtractGUI.ini thus reverting back to its default settings.

It's like gMKVExtractGUI.exe isn't detecting there's an existing gMKVExtractGUI.ini so it always creates a new one?!?!

[Bal65]

Nope, still having the same problem.

The Detected settings path in the log is always the "same" directory containing the 3 main program files (i.e. if they're in C:\Temp\gMKVextract, that's the path detected and where the initial gMKVExtractGUI.ini gets created.)

Just so we're clear about what's happening...

One the very first run, gMKVExtractGUI.exe creates a new gMKVExtractGUI.ini with a set of default settings.

The values in that new gMKVExtractGUI.ini change whenever I resize the GUI window and/or set the various paths (FYI, the values change "dynamical" as I resize the GUI or input paths.)
Those values remain whatever they are when I exit the program.

However, when I restart gMKVExtractGUI.exe, even if I simple shut it down and restart it, it always overwrites the existing gMKVExtractGUI.ini thus reverting back to its default settings.

It's like gMKVExtractGUI.exe isn't detecting there's an existing gMKVExtractGUI.ini so it always creates a new one?!?!

[Bal65]

@Bal65 I believe the settings should have no problem now, however if you're still having problems, please check the Log form for the detected settings path and post the results here. Thanks for the feedback! :)
Still not remembering the settings.

Detected settings path in the log "always" matches whatever directory the main program is located in.

FYI, the values in the ini file do change as I resize the window or if I type something into the Output Directory field and those settings remain "what they were" after I close the program. The problem happens the next time I start it up.

Everything in the ini file reverts back to the initial settings just as if the main program is either not detecting the ini already exists or it's resetting the values to their defaults prior to actually reading them.

[RyFeR26]

Still not remembering the settings.

Detected settings path in the log "always" matches whatever directory the main program is located in.

FYI, the values in the ini file do change as I resize the window or if I type something into the Output Directory field and those settings remain "what they were" after I close the program. The problem happens the next time I start it up.

Everything in the ini file reverts back to the initial settings just as if the main program is either not detecting the ini already exists or it's resetting the values to their defaults prior to actually reading them.

I have exactly the same issue (latest version (1.9.1) on Win10 x64). ini is created, values change when i change the size of the window and check the ini file after closing the app but when starting it's like the ini values are not read and all is set to default again (also in the ini).

Could this be investigated? If more info / testing is needed just let me know.

[gpower2]

@RyFeR26, @Bal65
Could you check the log for this test build?
https://sourceforge.net/projects/gmkvextractgui/files/Debug/%5BTest%5D%5B20170403%5DgMKVExtractGUI.v1.9.1.7z/download

@djcj
Unfortunately the attachments are still pending approval from the boarad. Could you paste the log to pastebin?

[RyFeR26]

[QUOTE=gpower2;1802687]@RyFeR26, @Bal65
Could you check the log for this test build?
https://sourceforge.net/projects/gmkvextractgui/files/Debug/%5BTest%5D%5B20170403%5DgMKVExtractGUI.v1.9.1.7z/download

Downloaded the test version and replaced the files. Started the app, all set to default, changed window size, etc, closed app, restarted app, again set to default.

Copy of log-file and the ini file after resizing and closing the app attached.

If you need more info let me know, thanks for looking into this.

[Bal65]

@RyFeR26, @Bal65
Could you check the log for this test build?
Just as before, when I exit the program, the ini file contains the new settings but, once I restart it, they revert back to the defaults.

Here's the log from your new test version and it shows it is in fact saving the settings before it reads them!

[2017-04-10][12:36:30] Detected settings path: C:\Temp\[Test][20170403]gMKVExtractGUI.v1.9.1
[2017-04-10][12:36:30] Changing WindowState
[2017-04-10][12:36:30] Saving settings...
[2017-04-10][12:36:30] Begin loading settings...
[2017-04-10][12:36:30] Finished loading settings!
[2017-04-10][12:36:30] Begin setting form size and position from settings...
[2017-04-10][12:36:30] Finished setting form size and position from settings!
[2017-04-10][12:36:30] Begin setting chapter type, output directory and job mode from settings...
[2017-04-10][12:36:30] Finished setting chapter type, output directory and job mode from settings!
[2017-04-10][12:36:30] Checking registry for mkvmerge...
[2017-04-10][12:36:30] Changing MkvToolnixPath
[2017-04-10][12:36:30] Saving settings...

The problem appears to be caused by the Changing WindowsState detection which is forcing it to update the settings before it actually reads them. Suggest you update the code so it reads and applies the existing ini settings before making any changes to them.

[Bal65]

@RyFeR26, @Bal65
Could you check the log for this test build?
As before, the settings are changed when I exit the program but get reset to their defaults once I restart it.

Here's the log for this version.

Detected settings path: C:\Temp\gMKVExtractGUI.v1.9.1
Changing WindowState
Saving settings...
Begin loading settings...
Finished loading settings!
Begin setting form size and position from settings...
Finished setting form size and position from settings!
Begin setting chapter type, output directory and job mode from settings...
Finished setting chapter type, output directory and job mode from settings!
Checking registry for mkvmerge...
Changing MkvToolnixPath
Saving settings...

As you can see, it clearly indicates the program is saving the settings before it actually reads them which is what's causing the problem.

[RyFeR26]

As before, the settings are changed when I exit the program but get reset to their defaults once I restart it.

Here's the log for this version.

Detected settings path: C:\Temp\gMKVExtractGUI.v1.9.1
Changing WindowState
Saving settings...
Begin loading settings...
Finished loading settings!
Begin setting form size and position from settings...
Finished setting form size and position from settings!
Begin setting chapter type, output directory and job mode from settings...
Finished setting chapter type, output directory and job mode from settings!
Checking registry for mkvmerge...
Changing MkvToolnixPath
Saving settings...

As you can see, it clearly indicates the program is saving the settings before it actually reads them which is what's causing the problem.

Hmmm, my post with the log file and ini file did not seem to be added properly (not seeing it anyway).

Same issue with the tets-version as Bal65 has commented on. INI file holds the correct data after closing the app, i see the same entries in the log when opening the app again, it says it's loading settings and that it's finished but all is back to default.

[RyFeR26]

Previous 2 posts did not make it to the forum somehow...

Exactly the same behavior as Bal65 describes, incl the Saving settings before the Loading settings.

[gpower2]

I think I found the cause of this behaviour, could you please check out this test version: https://sourceforge.net/projects/gmkvextractgui/files/Debug/%5BTest%5D%5B20170415%5DgMKVExtractGUI.v1.9.1.7z/download

Thanks for all your feedback! :)

[Bal65]

This one keeps the settings between uses http://home.earthlink.net/~al-east/pix/smiles/icon_thumbsup.gif

Log file...

Detected settings path: C:\Temp\gMKVExtractGUI.v1.9.1
Begin loading settings...
Finished loading settings!
Begin setting form size and position from settings...
Finished setting form size and position from settings!
Begin setting chapter type, output directory and job mode from settings...
Finished setting chapter type, output directory and job mode from settings!
Checking registry for mkvmerge...
Changing MkvToolnixPath
Saving settings...

[gpower2]

That's excellent news! Those changes will land with the new version. ;)
Till then, you can safely use the Test version, since it doesn't include any experimental changes and it is safe for daily use.

[Bal65]

Thanks!

[RyFeR26]

That's excellent news! Those changes will land with the new version. ;)
Till then, you can safely use the Test version, since it doesn't include any experimental changes and it is safe for daily use.

Hi, I also confirm it works perfectly now on my config:D

Thanks for fixing it!

[gpower2]

New version 1.9.2 is out and it is yet again another bug fix release. The settings issues are fixed, as well as the remaining locale issues on Linux.

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v1.9.2/gMKVExtractGUI.v1.9.2.7z/download

Changelog:

Add more Log messages
Add more functionality to the Log Form
Fix some cases where settings were getting overriden during start up (thanks Bal65, RyFeR26!)
Switch to using --gui-mode for mkvextract versions v9.7.0 and newer, while keeping existing functionality for backwards compatibility
Hopefully solve all remaining issues with locale on Linux (thanks djcj!)


Enjoy people! :D

[gpower2]

After almost 4 years since the first version of gMKVExtractGUI, I finally managed to rework the UI and the necessary core code to support batch extracting!
v2.0.0 incorporates a new form, that is based on the old one in order to retain familiarity and not to mess with the existing user's workflow. You can now add multiple files and the recognized tracks will appear in a tree. Multiple selection of tracks can be done either manually, or via the context menu which is automatically created according to the file tracks.
The "Job Mode" check box is now replaced by the button "Add Job", so the user can more easily add jobs or run instantly the extraction process.
There are also a lot of changes that I can't possibly document here, so I guess I urge you to discover them! :p

So without further ado, the download link:

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.0.0/gMKVExtractGUI.v2.0.0.7z/download

Changelog:

New form that supports batch extracting!
Fix bug when removing multiple jobs from Job Manager
Add the filename in the track progress report label in the Job Manager
Add new properties in the gMKVSegmentInfo class


Hope you enjoy this people! :D

[SeeMoreDigital]

Hi gpower2,

Sadly I'm receiving a 'page 404' error :(

[Wildfire]

Hi gpower2,

Sadly I'm receiving a 'page 404' error :(

SourceForge seems to be down at the moment. As their Twitter account states, "SourceForge is experiencing issues. We are investigating."

[gpower2]

Talk about bad timing... :(
Entire SourceForge page is down, so naturally the download links don't work at the moment.

You can download v2.0.0 from Videohelp's mirror, at least until SourceForge is back up:
https://www.videohelp.com/download/gMKVExtractGUI.v2.0.0.7z

EDIT:
You can also download v2.0.0 from SoftPedia:
http://www.softpedia.com/get/Multimedia/Video/Other-VIDEO-Tools/gMKVExtractGUI.shtml

[djcj]

On Linux I'm getting a "user32.dll" warning with v2.0.0 when I open a matroska file:

[2017-09-26][16:29:19] System.DllNotFoundException: user32.dll
at (wrapper managed-to-native) gMKVToolNix.gTreeView:SendMessage (intptr,int,intptr,gMKVToolNix.gTreeView/TVITEM&)
at gMKVToolNix.gTreeView.SetIsCheckBoxVisible (System.Windows.Forms.TreeNode node, Boolean value) <0x4216a890 + 0x00193> in <filename unknown>:0
at (wrapper remoting-invoke-with-check) gMKVToolNix.gTreeView:SetIsCheckBoxVisible (System.Windows.Forms.TreeNode,bool)
at gMKVToolNix.Forms.frmMain2.<AddFileNodes>b__14_4 (System.Windows.Forms.TreeNode n) <0x4216a7a0 + 0x0002b> in <filename unknown>:0
at System.Collections.Generic.List`1[T].ForEach (System.Action`1 action) <0x4216a6b0 + 0x0007f> in <filename unknown>:0
at gMKVToolNix.Forms.frmMain2.AddFileNodes (System.String argMKVToolNixPath, System.Collections.Generic.List`1 argFiles, Boolean argAppend) <0x4212e630 + 0x005db> in <filename unknown>:0
at gMKVToolNix.Forms.frmMain2.addInputFileToolStripMenuItem_Click (System.Object sender, System.EventArgs e) <0x4206b0d0 + 0x0010b> in <filename unknown>:0


Mapping user32.dll in the mono config to any Linux library like this


<dllmap dll="user32.dll" target="libc.so.6" os="!windows"/>


gives me a "SendMessage" warning:


[2017-09-26][16:33:21] System.EntryPointNotFoundException: SendMessage
at (wrapper managed-to-native) gMKVToolNix.gTreeView:SendMessage (intptr,int,intptr,gMKVToolNix.gTreeView/TVITEM&)
at gMKVToolNix.gTreeView.SetIsCheckBoxVisible (System.Windows.Forms.TreeNode node, Boolean value) <0x4127bb50 + 0x00193> in <filename unknown>:0
at (wrapper remoting-invoke-with-check) gMKVToolNix.gTreeView:SetIsCheckBoxVisible (System.Windows.Forms.TreeNode,bool)
at gMKVToolNix.Forms.frmMain2.<AddFileNodes>b__14_4 (System.Windows.Forms.TreeNode n) <0x4127ba60 + 0x0002b> in <filename unknown>:0
at System.Collections.Generic.List`1[T].ForEach (System.Action`1 action) <0x4127b970 + 0x0007f> in <filename unknown>:0
at gMKVToolNix.Forms.frmMain2.AddFileNodes (System.String argMKVToolNixPath, System.Collections.Generic.List`1 argFiles, Boolean argAppend) <0x4123fdc0 + 0x005db> in <filename unknown>:0
at gMKVToolNix.Forms.frmMain2.addInputFileToolStripMenuItem_Click (System.Object sender, System.EventArgs e) <0x41176f50 + 0x0010b> in <filename unknown>:0


Everything is still working. I can check or uncheck a track, but clicking on the line next to the track's checkbox makes the program crash.

[gpower2]

I was afraid of that, but my VirtualBox stopped working and I didn't take the time to check it on Linux... :o

It's just some work arounds for bugs of the TreeView control in .NET, I'll just disable them for Linux OS.

Thanks for the feedback! :)

[gpower2]

@djcj
Since SourceForge appears to be seriously broken, you can appy this patch in order to solve the Linux problems:

Index: gMKVExtractGUI/Controls/gTreeView.cs
===================================================================
--- gMKVExtractGUI/Controls/gTreeView.cs (revision 149)
+++ gMKVExtractGUI/Controls/gTreeView.cs (working copy)
@@ -150,6 +150,11 @@
throw new ArgumentNullException("node");
if (node.TreeView == null)
throw new InvalidOperationException("The node does not belong to a tree.");
+
+ // If we are on Linux, we can't use P/Invoke to user32.dll
+ // So this function can't do anything
+ if (gMKVHelper.IsOnLinux) { return; }
+
var tvi = new TVITEM
{
hItem = node.Handle,
@@ -173,6 +178,11 @@
throw new ArgumentNullException("node");
if (node.TreeView == null)
throw new InvalidOperationException("The node does not belong to a tree.");
+
+ // If we are on Linux, we can't use P/Invoke to user32.dll
+ // So if the node's check box visibility has the same value as the node's TreeView CheckBoxes property
+ if (gMKVHelper.IsOnLinux) { return node.TreeView.CheckBoxes; }
+
var tvi = new TVITEM
{
hItem = node.Handle,

[djcj]

Do you have a copy of the full source code? I've only downloaded the binary.

edit:

Maybe you should use something like if (!gMKVHelper.IsOnWindows) in case someone is using this on another OS that is not Windows or Linux.

[gpower2]

SourceForge is back online, so I commited the change to trunk and also released v2.0.0b with the aforementioned fix.

https://sourceforge.net/projects/gmkvextractgui/files/v2.0.0/gMKVExtractGUI.v2.0.0b.7z/download

Hope this solves the problems on Linux!

PS.
In mono, the only reported OSes are Windows, Linux and Mac. Since no one has stepped up to test it on Mac and I don't have access to a Mac, gMKVExtractGUI officially supports Windows and Linux! :)

[djcj]

Thanks, now it doesn't crash.

[hello_hello]

gpower2,
Thanks for the new version.

However.... gMKVExtractGUI v2.0 and 2.0b seem to be broken in respect to the Windows Explorer Right Click/SendTo menu. It results in a popup message saying an error has occurred (at least on XP). After closing the error message, gMKVExtractGUI opens but without opening the files.

Right clicking on a stream in the list of files/streams doesn't actually select it. As an example, if you open two MKVs and the first MKV is highlighted in the list of files, right clicking on the second MKV and selecting "remove selected input file" removes the first file and not the second, because the second wasn't selected by right clicking on it.

When right clicking to check or uncheck tracks, the track count seems counter-intuitive to me. If you have five MKVs open with an audio stream each and check them all, the right click menu shows (5/5) next to "check audio tracks" but (0/5) next to "uncheck audio tracks". To me it'd make more sense if the both displayed the number of currently checked tracks rather than what's checked in one instance and what's unchecked in the other.... because I'm easily confused.

I'm not sure if it's by design or not, but dragging and dropping files is a "one chance" proposition. You can right click to "add files", then right click again to add some more, whereas dragging and dropping replaces the current files rather than adding more to the list.

While it's nice having a right click menu to select all tracks of a certain type etc, I think it'd be handy to have buttons for each type of track on the main GUI somewhere so all video or all audio streams etc could be selected with a single click.

Thanks again.

[SeeMoreDigital]

gpower2,
Thanks for the new version.

However.... gMKVExtractGUI v2.0 and 2.0b seem to be broken in respect to the Windows Explorer Right Click/SendTo menu. It results in a popup message saying an error has occurred (at least on XP). After closing the error message, gMKVExtractGUI opens but without opening the files.

I can confirm the same behaviour with Windows 10 64-bit. Here's the error message: -

http://i66.tinypic.com/32zsx8o.png


Cheers

[gpower2]

Thanks, now it doesn't crash.
Thanks for the confirmation! :)

However.... gMKVExtractGUI v2.0 and 2.0b seem to be broken in respect to the Windows Explorer Right Click/SendTo menu. It results in a popup message saying an error has occurred (at least on XP). After closing the error message, gMKVExtractGUI opens but without opening the files.
I can confirm the same behaviour with Windows 10 64-bit. Here's the error message: -
http://i66.tinypic.com/32zsx8o.png
Cheers
Definetely a bug, I will fix it first thing! ;)

Right clicking on a stream in the list of files/streams doesn't actually select it. As an example, if you open two MKVs and the first MKV is highlighted in the list of files, right clicking on the second MKV and selecting "remove selected input file" removes the first file and not the second, because the second wasn't selected by right clicking on it.
Ah, you can't believe the quirks the TreeView control has in .NET...
I'll try to make right click to change the selected node like the left click.

When right clicking to check or uncheck tracks, the track count seems counter-intuitive to me. If you have five MKVs open with an audio stream each and check them all, the right click menu shows (5/5) next to "check audio tracks" but (0/5) next to "uncheck audio tracks". To me it'd make more sense if the both displayed the number of currently checked tracks rather than what's checked in one instance and what's unchecked in the other.... because I'm easily confused.
Why repeat the same information? I think this is more a matter of getting used to the information shown. ;)

I'm not sure if it's by design or not, but dragging and dropping files is a "one chance" proposition. You can right click to "add files", then right click again to add some more, whereas dragging and dropping replaces the current files rather than adding more to the list.
I was torn about that. At first I made drag and drop to append files, but after I added the "Add Input File(s)..." option in the context menu, I thought that it was better to just clear and add files on drag and drop.
I guess I could a question to the user, asking what she/he wants to do.

While it's nice having a right click menu to select all tracks of a certain type etc, I think it'd be handy to have buttons for each type of track on the main GUI somewhere so all video or all audio streams etc could be selected with a single click.
That's definetely a no-no for me! :p
I think that the UI is already cluttered enough and adding more buttons to it would be too much.

[hello_hello]

For the record, I didn't post details of the error message because on XP, there aren't any.
Where it says "Error setting TreeNode state" in SeeMoreDigital's screenshot it simply says "One or more errors occurred" on XP.

Why repeat the same information? I think this is more a matter of getting used to the information shown. ;)

It's currently repeating the same information anyway, only doing it in a different way.
If the "check tracks" menu says two out of five tracks are checked, it's the same as three out of five tracks being unchecked, which is what the "uncheck tracks" menu would say.

Maybe it's just my brain, but it's determined "Uncheck all tracks (3/5)" must mean there's currently three tracks checked, not two, because having the same information displayed in a different way is counter-intuitive to me.

I was torn about that. At first I made drag and drop to append files, but after I added the "Add Input File(s)..." option in the context menu, I thought that it was better to just clear and add files on drag and drop.
I guess I could a question to the user, asking what she/he wants to do.

That seems like a perfect opportunity for a user preference.
As a user though, I think it'd be better if drag and drop appended files, because if you don't want them appended it's easy enough to clear the list of files first.

That's definetely a no-no for me! :p
I think that the UI is already cluttered enough and adding more buttons to it would be too much.

I agree. I've always thought the "MKVToolNix Directory" area at the top was a waste of space. ;)
If it's about usability though, the number of times I'd click on a button to select all the audio streams compared to the number of times I'd change the location of MKVToolNix would easily be in the vicinity of 100,000:1.

Anyway, thanks for the hard work. It's appreciated.

[gpower2]

New version 2.1.0 is out and it fixes some bugs that came along the v2.0.0.

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.1.0/gMKVExtractGUI.v2.1.0.7z/download

Changelog:


Fix Linux issues
Fix adding files from command line
Add support for passing directories from command line
Make right click to change selection in the TreeView


Enjoy people! :D

[ismail0100]

Thank u I am using this and very good :)

[djcj]

This may be a little pedantic but can you put a license/unlicense/readme file to your source tree or add a header to your source files to make it more clear that your project is released into the Public Domain?

[gpower2]

Thank u I am using this and very good :)
Happy to hear that! :)

This may be a little pedantic but can you put a license/unlicense/readme file to your source tree or add a header to your source files to make it more clear that your project is released into the Public Domain?
Could you point me to an example file?

[dissory]

Thanks for the great program!

Using the latest version, I noticed choosing the folder to extract to doesn't work. Even if you choose a different folder it always extracts to the source folder.

[gpower2]

Yes, the output folder is a bit tricky at this time. You have to check the "Lock" option when you don't want to extract to the source folder.

[Telion]

It's worth to just rename the "Lock" checkbox to "Use source folder" and reverse its meaning, so that the greyed out path box would indeed mean it's not relevant while the checkbox is on. The current way is non-intuitive and non-standard for a regular windows UI control.

[gpower2]

It's worth to just rename the "Lock" checkbox to "Use source folder" and reverse its meaning, so that the greyed out path box would indeed mean it's not relevant while the checkbox is on. The current way is non-intuitive and non-standard for a regular windows UI control.

That's actually a great idea! I was still hanging on the previous design but something just didn't seem right...
I'll see to it ASAP!

[hello_hello]

gpower2,

Is there something peculiar about eac3 I don't understand?
gMKVExtractGUI extracts it with an mka extension. Shouldn't it have an eac3 extension?

I noticed MKVCleaver extracts it with an "undefined" extension, which seems like a bit of a co-incidence in that both programs appear to be getting it wrong, but I thought I'd ask about it here first. MeGUI uses MKVExtract to extract it as eac3.

Thanks.

[gpower2]

gpower2,

Is there something peculiar about eac3 I don't understand?
gMKVExtractGUI extracts it with an mka extension. Shouldn't it have an eac3 extension?

I noticed MKVCleaver extracts it with an "undefined" extension, which seems like a bit of a co-incidence in that both programs appear to be getting it wrong, but I thought I'd ask about it here first. MeGUI uses MKVExtract to extract it as eac3.

Thanks.

After checking the code which decides the output file's extension, I realized that I don't have a Codec_ID for EAC3. If you post the CODEC_ID reported I could add another case for eac3. ;)

Thanks for the feedback! :)

[Mosu]

Note the following:

The Matroska CodecID for AC-3 is A_AC3, for E-AC-3 it's A_EAC3.
mkvmerge up to and including v16 identified both types as "AC-3/E-AC-3".
mkvmerge after v16 now identifies AC-3 as "AC-3" and E-AC-3 as "E-AC-3".

[Mosu]

Hey,

FYI. I've just pushed a major change in how mkvextract's command line interface works. In short: you can now use all modes (tracks, timestamps, cues, tags, chapters…) at the same time, but the order of the arguments had to be changed.

Here's the corresponding entry from NEWS.md:

* mkvextract' command line interface has been changed to allow extraction of
multiple items at the same time. The first argument must now be the source
file's name. All following arguments either set the mode (e.g. `tracks`) or
specify what to extract in the currently active mode.

Those items that were written to the standard output (chapters, tags and cue
sheets) are now always written to files instead. Therefore the respective
modes require an output file name.

For example, extracting two tracks, the chapters and the tags can be done
with the following command:

`mkvextract input.mkv tracks 0:video.h265 1:audio.aac chapters chapters.xml tags tags.xml`

The old interface (specifying the mode first and the source file name
second) remains working and supported. However, it is now deprecated and
will be removed at the end of 2018.

This should make life easier for GUIs as they don't have to run mkvextrat multiple times anymore.

As stated in the NEWS entry the old interface is still available and should still work (if it doesn't, please drop me a line; that would be unintentional but not surprising given how invasive those changes were). However, the old interface will be removed, even though only at the end of 2018, therefore changing the GUIs is probably a must.

If you want to give it a spin right now, you can use the latest pre-builds for Windows (https://mkvtoolnix.download/windows/pre/).

[gpower2]

Thanks for the heads up Mosu!
I'll definitely look into it first thing!

[Mosu]

Great! And you're welcome.

I expect there to be bugs in the new mode. Writing a CLI parser isn't that hard, but changing an existing one to something else so that both modes work leads to quite a lot of corner cases. Bug reports are more than welcome!

[RyFeR26]

Hi,

It seems the "Add" and "Extract" buttons in the lower right corner both do the same (extract selected tracks). Shouldn't the "Add" button open the file dialog to add files?

At this moment it's only possible to add files while right-clicking the "Input files" area and select 'Add input file(s)".

Am i missing something or should this behavior be corrected?

I'm using the latest version (2.1.0).

[djcj]

Is it possible to set (force) the mkvtoolnix directory through command line? Something like "gMKVExtractGUI.exe --mkvtoolnix=/home/user/custom/bin". Right now it seems to default to "/usr/bin" even if I put another directory with the command line tools in front of my PATH.

[gpower2]

Hi,

It seems the "Add" and "Extract" buttons in the lower right corner both do the same (extract selected tracks). Shouldn't the "Add" button open the file dialog to add files?

At this moment it's only possible to add files while right-clicking the "Input files" area and select 'Add input file(s)".

The button you are referring to is for adding Jobs, not files. gMKVExtractGUI features a job manager, where you can add extracting Jobs and run them at a later time. You can see the job manager form at any time by clicking on the "Jobs..." button.
Since dragging and dropping now supports folders and sub folders, I think that adding files manually is not so intuitive, though I left the option from the context menu.

Is it possible to set (force) the mkvtoolnix directory through command line? Something like "gMKVExtractGUI.exe --mkvtoolnix=/home/user/custom/bin". Right now it seems to default to "/usr/bin" even if I put another directory with the command line tools in front of my PATH.

That is definitely something I could check. However you can still change the MKVToolNix path by either browsing to the path, or dragging and dropping it on the field. ;)

[gpower2]

Happy new year everyone! :)

It's time for a new version (v2.2.0)!
With this version, HighDPI environments are fully supported thanks to the feedback and vigorous testing from Six!

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.2.0/gMKVExtractGUI.v2.2.0.7z/download

Changelog:


Change the output directory behavior
Add custom DPI scaling code and enable it on all forms
Add new manifest Property "dpiAwareness" for newest Windows Versions (Windows 10 v1607+)
Added new Audio Codec_ID A_EAC3 and A_MLP
Added some missing video and subtitle codec_id
Remove unnecessary separator in context menu
Increase the width of the percentage labels in Main form
Decrease the height of the buttons in Log Form


As always, enjoy people! :D

[hello_hello]

Thanks for the new version. Still working fine on XP! :)

A request regarding the new output directory behaviour.....

Could gMKVExtractGUI always remember a specified (default) output directory independently of the "use source" option?
Or to put it another way, could the "use source" checkbox simply toggle between a specified directory and the source directory? Currently it can work that way, as long as you check "use source" after adding input files and uncheck it again before removing input files, or before closing the GUI, and as long as you don't click on any input files while "use source" is checked. If you follow those rules, you can check "use source" and gMKVExtractGUI will extract to the source directory, then when you uncheck "use source" it goes back to using the "default" directory (the one you previously specified).

Anyway... I think it'd be more fun if gMKVExtractGUI always remembered a specified (default) directory and the "use source" checkbox simply toggled between that directory and the source directory (without causing gMKVExtractGUI to forget the specified directory).

Thanks again.

[Telion]

^ Second this.

[Usopputo]

how do I install it in linux porfis or pass me the linux version

[gpower2]

If you have Mono installed, then you can simply execute the executable found in the 7z file!
Nothing else is needed! ;)

[gpower2]

Is it possible to set (force) the mkvtoolnix directory through command line? Something like "gMKVExtractGUI.exe --mkvtoolnix=/home/user/custom/bin". Right now it seems to default to "/usr/bin" even if I put another directory with the command line tools in front of my PATH.

I finally got to this request and I just commited this new functionality with r165. I think I tested enough, however a second set of eyes is always better! :)

Thanks for the new version. Still working fine on XP! :)

A request regarding the new output directory behaviour.....

Could gMKVExtractGUI always remember a specified (default) output directory independently of the "use source" option?
Or to put it another way, could the "use source" checkbox simply toggle between a specified directory and the source directory? Currently it can work that way, as long as you check "use source" after adding input files and uncheck it again before removing input files, or before closing the GUI, and as long as you don't click on any input files while "use source" is checked. If you follow those rules, you can check "use source" and gMKVExtractGUI will extract to the source directory, then when you uncheck "use source" it goes back to using the "default" directory (the one you previously specified).

Anyway... I think it'd be more fun if gMKVExtractGUI always remembered a specified (default) directory and the "use source" checkbox simply toggled between that directory and the source directory (without causing gMKVExtractGUI to forget the specified directory).

Thanks again.

^ Second this.

I added this functionality with a small context menu on the output directory. It will be available with the next version, or you could build it yourself from trunk if you want to try it! ;)

[Perenista]

https://i.imgur.com/kr7sVxA.png

I have a problem with this app from MKVToolnix:

https://i.imgur.com/R3adHjS.png

When I try to extract the PCM from the Matroska (which has these specs) :
https://pastebin.com/Whz1QiTy

The resulting PCM has only:

2h31m if I open using MPC-HC. But MediaINFO says something quite different:

https://pastebin.com/z6kpZQ8J (correct info: over 14 hours)

Then I tried opening this huge PCM in this program:
http://download.cnet.com/TAudioConverter-64-bit/3000-2141_4-75924909.html

I told it to convert to MP3 160 Kbps, 48 kHz.

The MP3 file now it's reduced to 173 MB. And if I open in MPC-HC it has 2h31m, too. MediaINFO says the following about this MP3:

https://pastebin.com/AtHa6z76 (2h31m)

Any thoughts?

https://i.imgur.com/YULHWZQ.png

Clearly this is a bug only affecting huge PCM audio tracks with many hours....

P.S. VLC, WinAMP and PowerDVD also inform 2h31m for the PCM.

In other words the audio track is stuck in that Matroska video, which has 95 GB. I need to get it out and convert it to MP3.

[gpower2]

You should make this post in the MKVToolNix thread here:
https://forum.doom9.org/showthread.php?t=155732

This is the thread for the gMKVExtractGUI application, which only uses the mkvextract.exe as is from the MKVToolNix tools.

You should also always use the latest versions of both MKVToolNix and gMKVExtractGUI, in case you stumbled on a bug that is already solved. ;)

[mkver]

You can't put more than 4 GB of PCM data in a wav container (because the size field uses a 32 bit unsigned integer). This restriction can be overcome by using the w64 container. You can use ffmpeg to extract the audio data from the Matroska file to w64; or you can use ffmpeg to directly encode the audio to something else or to pipe to another encoder.
But there is something that is strange: Actually 2h31m at 1536 kb/s amounts to way less than 2 GB. How big is the file if you use ffmpeg for the extraction?
[Edit]: Now I see! Your extracted file has the correct filesize, but an unsuitable container: It's size field in the header is only correct modulo 2^32, i.e. according to the header the size is only 1.63GB which gives the length that the players show to you. But this length is wrong. I already told you what you can do about it.

[Mosu]

mkvextract cannot write wave64 files at the moment. There's currently no way to extract such a track correctly with mkvextract.

[Perenista]

https://i.imgur.com/1uKYZNm.png

I tried using ffmpeg, and failed. Unless this is not the correct command:
https://forum.doom9.org/showpost.php?p=1833343&postcount=5082

See more here: https://imgur.com/a/i5qY6

The W64 file has only 350 MB, and 1 hour later is still showing the same image. So no luck there.

I tried ffmpeg - i E:\XX.mkv D:\file.w64

[tormento]

@gpower2

May I ask you to

- add bitrate for audio tracks, at least ac3
- give a minimal configuration for filename output: I don't care about track name at the beginning, I would prefer to add numer of channels in audio, for example

[djcj]

@gpower2: the --mkvtoolnix is working. Maybe you can also add a --help command so it's easier to figure that out. By the way can you upload a new release with that change?

[gpower2]

@gpower2

May I ask you to

- add bitrate for audio tracks, at least ac3
- give a minimal configuration for filename output: I don't care about track name at the beginning, I would prefer to add numer of channels in audio, for example

@tormento
I don't understand what you're asking when you say to "add bitrate for audio tracks", please clarify with an example. ;)
I could add a template string for output filename generation, but it's not as simple as it seems, so no promises!

@gpower2: the --mkvtoolnix is working. Maybe you can also add a --help command so it's easier to figure that out. By the way can you upload a new release with that change?

Glad to know that it works! I was planning to implement the new command line arguments changes in mkvtoolnix before releasing a new version, probably during the summer.
I hope that's ok for you! As always, thanks for your valuable feedback! :)

[djcj]

Since there doesn't seem to be a GUI for Linux available that doesn't require "special" runtimes like mono or python, I took the time and wrote something in C++ using FLTK (so the binary only needs standard X11 libraries).
https://github.com/darealshinji/mkvextract-gui

I just wanted to let Linux users know about it. By the way, the program doesn't have a real name, "mkvextract-gui" is more of a description or project name.

[gpower2]

Hi people! Long time no see! :p

It's time for a new version (v2.3.0)!
With this version, the new mkvextract syntax introduced in MKVToolNix v17 is officially supported, just in time before the old one is deprecated!

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.3.0/gMKVExtractGUI.v2.3.0.7z/download

Changelog:


Add new setting for default output directory
Switch to "timestamps_v2" instead of "timecodes_v2" for MKVToolNix v17+
Add support for the new mkvextract syntax for MKVToolNix v17+
Add a new commandline argument --mkvtoolnix="..." to specify a manual path for MKVToolNix


As always, enjoy people! :D

[mood]

gpower2, 2.3.0 language track detect on file name not work, example: now its [eng], not _eng_

the _eng_ not detect by mkvtoolnix 27 only [eng]

example 1: music_track1_chi_DELAY 30ms.aac not detect language

example 2: music_track1_[chi]_DELAY 30ms.aac language is detected

[Mosu]

the _eng_ not detect by mkvtoolnix 27 only [eng]

You can change the regular expression MKVToolNix uses for recognizing track languages in the file name in MKVToolNix GUI's preferences. The following should recognize _xxx_, too:

[[({.+=#_-](<ISO_639_1_CODES>|<ISO_639_2_CODES>|<LANGUAGE_NAMES>)[])}.+=#_-]

[gpower2]

gpower2, 2.3.0 language track detect on file name not work, example: now its [eng], not _eng_

the _eng_ not detect by mkvtoolnix 27 only [eng]

example 1: music_track1_chi_DELAY 30ms.aac not detect language

example 2: music_track1_[chi]_DELAY 30ms.aac language is detected

It's not a recent change in gMKVExtractGUI, I guess that it never really worked in MKVToolNix and no one ever bothered to report it! :P

It's an easy and quick fix, I'll have it ready for the next version. ;)

Thanks for the feedback! :)

[gaak]

Version 2.3.0 doesn't appear to produce .ogm.txt files. You get the success message but no file.

[manolito]

Cannot reproduce your issue here.
Maybe your MKV has problems. What happens after you import your MKV into the current version of MKVToolNix and remux it?

Cheers
manolito

[gaak]

It was an MKV produced with Handbrake 1.1.2. gMKVExtractGUI version 2.2.0 worked. I guess I'll stay with 2.2.0 because most of my work requires the use of Handbrake and I don't want to go through having to remux everytime. Thanks for your help.

[manolito]

Tried to reproduce the issue with an MKV created by Handbrake 1.1.2, but I couldn't... :devil:

gMKVExtractGUI 2.3.0 created OGG chapters just fine, maybe you should upload an MKV which shows the problem...

[x3inspire]

Hi im using gMKVExtractGUI, currently the sub output is like this:
SubName S01E01_track3_und

Where can i setting to make the output only display SubName S01E01 without "_track3_und" or subtitle output same as video name?

Thanks.

[gaak]

Tried to reproduce the issue with an MKV created by Handbrake 1.1.2, but I couldn't... :devil:

gMKVExtractGUI 2.3.0 created OGG chapters just fine, maybe you should upload an MKV which shows the problem...

I found it. It's not putting it in the source directory that I have checked or selected, it's putting it in "C:\gMKVExtractGUI\Files" under where the execs are. What size am I limited to for the upload?

[manolito]

What size am I limited to for the upload?

You should not use forum attachments as it can take ages until they get approved. Use a file hoster like SendSpace instead...

[x3inspire]

Hi im using gMKVExtractGUI, currently the sub output is like this:
SubName S01E01_track3_und

Where can i setting to make the output only display SubName S01E01 without "_track3_und" or subtitle output same as video name?

Thanks.

Hi, any answer please?

[videoh]

Hi, any answer please? Settings are described in the documentation. You can check the documentation to see if your requirement is supported.

[manolito]

I found it. It's not putting it in the source directory that I have checked or selected, it's putting it in "C:\gMKVExtractGUI\Files" under where the execs are.

I can reproduce the issue. It only happens if the target folder has some special characters like spaces in its name. Looks like gpower2 forgot to enclose the target folder with double quotes...

By videoh:
Settings are described in the documentation. You can check the documentation to see if your requirement is supported.

Looks like this software comes without any documentation... :p
Not every software developer is as thorough as you are when it comes to writing proper documentation... :D


Cheers
manolito

[x3inspire]

Settings are described in the documentation. You can check the documentation to see if your requirement is supported.

https://i.imgur.com/GKF6fXj.png

Where is the setting? The output still display include "_track3_eng"

[hello_hello]

Where is the setting? The output still display include "_track3_eng"

It's better that it does, otherwise if you extracted multiple subtitles from the same MKV, they'd have the same name.

MKVCleaver lets you modify the extracted file names, but if you don't use settings that allow each extracted stream to have a unique name, the first stream of a particular type will probably be over-written when the next one is extracted, if they're extracted together.

https://i.postimg.cc/Hsf6x3h5/MKVCleaver.gif

[hello_hello]

gpower2, 2.3.0 language track detect on file name not work, example: now its [eng], not _eng_

the _eng_ not detect by mkvtoolnix 27 only [eng]

example 1: music_track1_chi_DELAY 30ms.aac not detect language

example 2: music_track1_[chi]_DELAY 30ms.aac language is detected

Back when suggesting MKVToolNix apply languages codes (https://forum.doom9.org/showthread.php?p=1666629#post1666629) was evidence of a mental condition, I thought it'd be a nice idea for everyone to get together and decide on a format for writing and reading language names/codes. Zathor kindly modified MeGUI so it'd write delays MKVToolNix could understand, and I think he added an ability pick up 3 letter language codes when muxing raw streams, and the author of MKVCleaver made the extracted file names configurable, but it's still a bit messy.

There's not exactly hundreds of freeware programs for extracting/muxing MKVs, so I would've thought it'd be easy to settle on a format that everyone understands, and supporting others would be at the discretion of the software author. I still think some sort of standard for writing language names/codes would be a good thing.

[gpower2]

Wow guys, haven't had this many comments in years!
Sorry for not answering earlier, but real life is quite busy for me.

Version 2.3.0 doesn't appear to produce .ogm.txt files. You get the success message but no file.
I found it. It's not putting it in the source directory that I have checked or selected, it's putting it in "C:\gMKVExtractGUI\Files" under where the execs are. What size am I limited to for the upload?
I can reproduce the issue. It only happens if the target folder has some special characters like spaces in its name. Looks like gpower2 forgot to enclose the target folder with double quotes...

I'll look into this matter as soon as possible. It's definitely not the file's fault...


Looks like this software comes without any documentation... :p
Not every software developer is as thorough as you are when it comes to writing proper documentation... :D


Cheers
manolito

I don't think that this software requires any kind of documentation, it's just a GUI for a CLI tool...

Hi im using gMKVExtractGUI, currently the sub output is like this:
SubName S01E01_track3_und

Where can i setting to make the output only display SubName S01E01 without "_track3_und" or subtitle output same as video name?

Thanks.

It's a feature that is not supported and that is the reason that you can't find any relevant option for it.
It may or may not be supported in future versions...

Back when suggesting MKVToolNix apply languages codes (https://forum.doom9.org/showthread.php?p=1666629#post1666629) was evidence of a mental condition, I thought it'd be a nice idea for everyone to get together and decide on a format for writing and reading language names/codes. Zathor kindly modified MeGUI so it'd write delays MKVToolNix could understand, and I think he added an ability pick up 3 letter language codes when muxing raw streams, and the author of MKVCleaver made the extracted file names configurable, but it's still a bit messy.

There's not exactly hundreds of freeware programs for extracting/muxing MKVs, so I would've thought it'd be easy to settle on a format that everyone understands, and supporting others would be at the discretion of the software author. I still think some sort of standard for writing language names/codes would be a good thing.

This issue is already resolved in trunk, since the problem was the "[]" characters and not the language code itself. ;)

[videoh]

Looks like this software comes without any documentation... :p My bad. :scared:

BTW, I have decoded my first frame from an MKV in DGIndex. Lots more work to do though.

[manolito]

BTW, I have decoded my first frame from an MKV in DGIndex. Lots more work to do though.

:thanks:

[Intervencion]

Also having the chapters' issue with files with spaces.
Thanks for your work:thanks:

[gpower2]

Hi people! I just release a new version (v2.4.0) to address the issues introduced with v2.3.0.

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.4.0/gMKVExtractGUI.v2.4.0.7z/download

Changelog:


Enclose language in [] characters in the output filename for tracks, in order for MKVToolNix GUI to be able to derive it
Quote output filename in chapters, tags and cuesheet when using the new MKVToolNix cli
Fix the necessary input fields check when extracting tags and cuesheet
Refactor output filename calculation


As always, enjoy people! :D

[manolito]

Working nicely, thanks... :thanks:

[Intervencion]

Same :thanks: Working at 100%

[tormento]

Hi people! I just release a new version (v2.4.0) to address the issues introduced with v2.3.0.
:thanks:

[drako]

Dear gpower2,

When I try to extract an image attachment from a MKV container, the module gMKVToolNix.dll throws me an error stating that "the file ...cover.jpg" could not be opened for writing:create_directory() failed.

When I replace the said gMKVToolNix.dll with 2.3.0 version, the error disappears, and the image extracts fine.

Could this just be happening on my system?

Thanks!

[gpower2]

Hey drako!
Could you please post a screenshot or send it to me in a private message in order to see the problem?

[Csimbi]

Hi there,
I'd like to make a request for gMKVExtractGUI.
That is, to zero-pad track numbers.
Current example: _track8_
Future example: _track08_

The reason is simple: so they would show up in correct order in my file manager.
(08,09,10,11 instead of 10,11,8,9)

Thank you!

[dissory]

Hi Gp2, is it possible to add an option to extract tracks with its title property? Especially useful for subs (forced subs, sdh etc) and audio (lossless, lossy, different channels mix etc) where there are multiple of them in the same language and currently it's not easy to differentiate them by name.

An option to extract based on number of chapters/attachments entries each file has would also be very useful!

[girod2033]

Hi!
gMKVExtractGUI 2.4.0.0
mkvtoolnix 28.2.0 (x64)
Win 7 x64 Ultimate
If one item is selected, there is no problem.
https://i.imgur.com/uFztT6V.png
If two or more items are selected, then an error.
https://i.imgur.com/forsNZd.png
https://i.imgur.com/BXDaUU6.png

[Perenista]

https://i.imgur.com/FtEYWbc.png

I am getting this error here... can't use this software anymore.

Any ideas?

[gpower2]

Your OS installation must be corrupted. It's definitely not gMKVExtractGUI's fault.
You can see more info about your error here: https://stackoverflow.com/questions/7297918/com-class-factory-error-80040154-when-opening-get-directory-dialog

[tormento]

I have a strange issue, probably not due to gMKVExtractGUI but to MKVInfo.

Get a m2ts stream from a BD, containing video track and huge audio (DTSHD or similar).

Drag into MKVToolnix and select just a couple of those audio tracks, no video. A .mka will be output.

Now try to drop into gMKVExtractGUI. When a mkv it takes only a few seconds to display tracks, when mka it takes ages or simply crashes, leaving MKVInfo as appended process.

[Overdrive80]

Hi, I found bug with path file when trying extract attachments.

https://www.dropbox.com/s/rcbv3k0rl54hzqi/Untitled%20Project.mp4?dl=0

[gpower2]

Hi everyone, time for a small fix version! As some of you reported, v2.4 had broken attachment extraction. I had this fixed in 2018, however I never released a new version, silly me! :p

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.4.1/gMKVExtractGUI.v2.4.1.7z/download

Changelog:


Fix attachment extraction


Enjoy people! :D

[Overdrive80]

Thanks for fixing it.

[tormento]

Hi everyone, time for a small fix version
Did you read my bug report?

[gpower2]

Hi tormento,

Are you using latest version of gMKVExtractGUI?
I believe that mkvinfo is not being used after v1.9.0 or something like that, so it is really curious that you see mkvinfo.exe hanged.
Have you tried waiting for mkvinfo to finish?

EDIT: I think I found what is happening here... gMKVExtractGUI attempts to find the track delays, assuming the video track as an anchor.
However, there is no such need in matroska files that don't contain any video tracks. New version coming soon...

EDIT2: New version is up! I think that the issue is now fixed! Thanks for your feedback! :)

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.4.2/gMKVExtractGUI.v2.4.2.7z/download

Changelog

Stop trying to find delays in matroska files that don't contain any video tracks

[manolito]

Thanks gpower for the continuing work on the software, since the old MKVExtractGUI2 is no longer maintained your MKVExtractGUI is pretty much the only game in town... :D

Talking about track delays one of the differences to the old GUI is that your software determines the delays and writes the audio delay value into the extracted audio file name. And this feature keeps confusing me over and over.

I am used to how this works for MPEG2 files. Demux the file with DGIndex, the delay value gets written into the file name. Remuxing this audio file with the M2V video track (using MuxMan or Cuttermaran) the audio delay is read from the file name, and the muxing process honors this delay value. This results in a new MPEG2 file in perfect sync.

With gMKVExtractGUI and MKVToolnix this is very different. The delay value is also written into the extracted audio file name, and when remuxing this audio track into a new MKV using MKVMerge the delay value is also detected and honored in the muxing process. BUT THIS IS WRONG. The resulting MKV will be out of sync.

To get a new MKV without sync problems the audio delay value needs to be ignored. Either set the delay to 0 in the MKVToolnix GUI, or remove the delay value from the audio track name.

Do you have an explanation for this? Could it be that mkvextract.exe corrects any delays before extracting tracks?


Cheers
manolito

[gpower2]

Hi manolito, thanks for your kind words, I really appreciate it! :)

As for the delays, it's been thoroughly discussed in this thread, the effective delay is required in order to re-merge the tracks and be in sync with each other. ;)

[manolito]

As for the delays, it's been thoroughly discussed in this thread, the effective delay is required in order to re-merge the tracks and be in sync with each other. ;)

Sorry, I have not followed these thorough discussions, but I do disagree.

Please have a look at this file:
https://www.sendspace.com/file/dsauzo

It is a real world DVB-T2 captured clip, I deal with such clips every day. It comes in an MTS container, I repacked it to MKV using the latest MKVToolnix. It has a huge audio delay, but it plays in perfect sync in all my software players.

Next thing I did was extracting the audio track with gMKVExtractGUI. The filename of the extracted track was "test_track2_[mis]_DELAY -1446ms.aac". Then I remerged this extracted audio file into the original MKV. In my uploaded MKV this remerged audio track appears as audio track #2. Now please play this file in any software player which allows to switch audio tracks during playback. What do you think about the audio sync for track #2?

Sorry I only found a German channel where lip sync can be judged, but I think you can get the idea without speaking German. For the files I regularly work with the audio delay feature in gMKVExtractGUI does not work, I always need to turn it off.


Cheers
manolito

[Mosu]

Sounds like the -1446ms might have to be 1446ms.

[manolito]

No, that's not it. To get the correct audio sync the delay has to be 0.

[mkver]

The second audio track (track #3) starts at 5ms, the first audio track (track #2) at 65ms. The first video keyframe has a timestamp of 1571ms, the lowest video frame has a timestamp of 1511ms (this file uses open GOP). If you extracted both track #2 and track #1 (the video) and muxed it back with mkvmerge, mkvmerge would give the lowest video frame a timestamp of 0ms and the first video keyframe a timestamp of 60ms. This is a difference of 1511ms; in order to keep AV sync, you would have to offset the audio by 1511ms, too; extracting audio to elementary streams makes it loose its initial delay (here 5ms and 65ms) which already amounts to subtracting 5ms resp. 65ms from the audio tracks. So you would have to subtract a further 1511ms - 65ms from track #3. But this is only true if you actually extracted both audio and video and remuxed the elementary tracks -- your comment seems as if you didn't extract the video at all.
Btw: Why extract the tracks to elementary tracks at all? If you have transmission errors (and therefore missing packets), you will loose A/V sync no matter whether the initial offsets were right.

[manolito]

Thanks mkver for the detailed analysis, but this is not really my point...

The average user will not have such analysis skills (I certainly don't), and we have software like mkvextract and mkvmerge to do this automatically. This is all I am asking for.

You are correct, I did not extract the video track at all, I just extracted the audio track and remuxed it into the source MKV. And this resulted in the sync error. I just tried again and extracted both the video and audio tracks, then imported both tracks into MKVMerge to create a new MKV. And yes, this time the only way to avoid sync errors was to honor the audio delay for the muxing process. So it does make a difference if I add an audio track with a delay to an already existing MKV with a video track, or if I create a brandnew MKV with video and audio tracks. Weird, and basically I do not want to deal with this.

The reason why I need to extract the audio track(s) from the source MKV is that I use StaxRip (an older 32-bit version) to recode the HD source HEVC / AAC-LATM (or E-AC3) into an SD AVC / AAC file. And StaxRip processes the audio separately from the video, and the extracted audio always needs to be decompressed to PCM first to make frame accurate editing possible.

And if the captured source has transmission errors, you do have a point. If I have repacked a captured MTS file to MKV first and there are glitches in this file, I will loose audio sync. But by trial and error I found out that this does not happen if I use the original MTS or TS as the source for StaxRip. My source filter is DSS2Mod, and when the source has transmission errors and I use the original Transport Stream as the source then I will see the broken frames, but sync is maintained.

Using the original Transport Stream as the source has its problems, though, and I try to avoid it when I can. Editing out commercials is a major PITA when using HEVC Transport streams, seeking the desired frame by stepping through the frames always brings up corrupt frames because the next I-Frame cannot be found. After repacking the source to MKV these problems disappear completely.

Luckily transmission errors are very rare for me with the DVB-T2 format. I always use TSDoctor to check for transmission errors, and about 95% of my captures are error-free.


Cheers
manolito

[mkver]

The average user will not have such analysis skills (I certainly don't), and we have software like mkvextract and mkvmerge to do this automatically. This is all I am asking for.

The software can't read your mind, but what could be done is that if a Matroska file has a video track and you select to not extract the video track, then the delay that is put into the filenames should not be calculated as if the video started with 0, but rather as if the video timestamps were unchanged (in your example, the delay that would be put in the filenames would be 5ms and 65ms). You may ask gpower2 about it; but who knows: Maybe someone else would call the behaviour just proposed weird.
(And what should happen when there is more than one video track? I don't know.)

There is BTW a second workaround for you that is only applicable when your recording contains a few seconds at the beginning that you want to discard (there needs to be a complete GOP at the beginning that you don't want to keep). When you initially remux from ts to mkv, you can let mkvmerge split by parts based on timestamps in order to discard the very beginning. The lowest timestamp of the main video track will then be zero (for each part). So the problem you encountered here doesn't happen for such files.

The reason why I need to extract the audio track(s) from the source MKV is that I use StaxRip (an older 32-bit version) to recode the HD source HEVC / AAC-LATM (or E-AC3) into an SD AVC / AAC file. And StaxRip processes the audio separately from the video, and the extracted audio always needs to be decompressed to PCM first to make frame accurate editing possible.

I don't use StaxRip, but keep in mind that StaxRip may add confusion of its own to the offsets. (I.e. does StaxRip even care about the offset in the input file (namely that the first video track doesn't start at zero?)? How does it handle the fact that the lowest video timestamp belongs to an undecodable frame (one of the B-frames shared between GOPs?)?)

If I have repacked a captured MTS file to MKV first and there are glitches in this file, I will loose audio sync. But by trial and error I found out that this does not happen if I use the original MTS or TS as the source for StaxRip. My source filter is DSS2Mod, and when the source has transmission errors and I use the original Transport Stream as the source then I will see the broken frames, but sync is maintained.
Newer versions of mkvmerge discard whole PES packets when mkvmerge detects any errors (by looking at the continuity counter). This might explain your observation. The last version that didn't do this was AFAIK 19.0.

[manolito]

The software can't read your mind

It does not have to. All I would like to see is a behavior which is consistent with the behavior of other software for the identical task.

Let's not talk about the peculiarities of captured transport streams, let's also forget about StaxRip. Let's break it down to a very common task which I need to perform frequently (and other users probably too).

I have a clip in an MKV container, MediaInfo reports a certain audio delay. I need to "beautify" the audio. So I need to extract the audio track, decompress to WAV, do all my nasty tricks in WaveLab (or any advanced WAVE editor), save the WAV and convert it to AAC. The last step is to import this audio track into the original MKV, disable the original audio track and remux it into a new MKV. Very simple...

If I do this using gMKVExtractGUI and MKVToolnixGUI then the result will be out of sync, because the audio delay value is written into the file name of the extracted audio track. All following operations will preserve the filename with the embedded delay value. Remerging it back into the original MKV will honor the delay value, and this results in a sync error.

I will not get sync problems if I use FFmpeg or AviDemux for this task. The reason is simple, this other software does not care for audio delay values. Remuxing the "beautified" audio back into the original MKV will give out a new MKV in perfect sync.

So all I am asking for is consistent behavior. It is too bad that Pashin stopped maintaining his MKVExtractGUI2 software, IIRC the last supported MKVToolnix version was v. 20.


Cheers
manolito

[gpower2]

It does not have to. All I would like to see is a behavior which is consistent with the behavior of other software for the identical task.

Let's not talk about the peculiarities of captured transport streams, let's also forget about StaxRip. Let's break it down to a very common task which I need to perform frequently (and other users probably too).

I have a clip in an MKV container, MediaInfo reports a certain audio delay. I need to "beautify" the audio. So I need to extract the audio track, decompress to WAV, do all my nasty tricks in WaveLab (or any advanced WAVE editor), save the WAV and convert it to AAC. The last step is to import this audio track into the original MKV, disable the original audio track and remux it into a new MKV. Very simple...

If I do this using gMKVExtractGUI and MKVToolnixGUI then the result will be out of sync, because the audio delay value is written into the file name of the extracted audio track. All following operations will preserve the filename with the embedded delay value. Remerging it back into the original MKV will honor the delay value, and this results in a sync error.

I will not get sync problems if I use FFmpeg or AviDemux for this task. The reason is simple, this other software does not care for audio delay values. Remuxing the "beautified" audio back into the original MKV will give out a new MKV in perfect sync.

So all I am asking for is consistent behavior. It is too bad that Pashin stopped maintaining his MKVExtractGUI2 software, IIRC the last supported MKVToolnix version was v. 20.


Cheers
manolito

I am sorry manolito, but if your usage scenario involves reencoding the extracted audio track, then it certainly can involve renaming the file!

Extracting audio tracks with the exact delay is and will stay the default action since if this information is lost, then the user can't re-merge the original tracks without losing sync.
If someone uses the extracted track for something more complicated than that, then simply renaming the extracted track's filename will suffice.

In the next version, I will add a custom filename creation mode, in order for the user to choose how the extracted filenames are generated.
I guess you can then change the filename generation rule and your problem will be solved. ;)

[manolito]

Yes, this will certainly solve it for me... :thanks:

[dissory]

Hi gp2, had a few suggestions if you don't mind:

Is it possible to add an option to extract tracks with its title property? Especially useful for subs (forced subs, sdh etc) and audio (lossless, lossy, different channels mix etc) where there are multiple of them in the same language and currently it's not easy to differentiate them by name.

An option to extract based on number of chapters/attachments entries each file has would also be very useful!

[Csimbi]

Hi there,
I'd like to make a request for gMKVExtractGUI.
That is, to zero-pad track numbers.
Current example: _track8_
Future example: _track08_

The reason is simple: so they would show up in correct order in my file manager.
(08,09,10,11 instead of 10,11,8,9)

Thank you!

Pretty please? ;-)

[gpower2]

Hi gp2, had a few suggestions if you don't mind:

Pretty please? ;-)

Hopefully all the above will be addressed with the new version. However, it's not going to be released soon, since my job is keeping me really busy...

[tormento]

EDIT2: New version is up! I think that the issue is now fixed! Thanks for your feedback! :)
:thanks:

[airium]

This is a wonderful software but only one thing. I am wondering if you don't mind to add the utility to automatically create the destination folder if not existing? For people who use a fixed folder, it's a little annoying being warned about "not exist" and manually navigating and creating it. Many thanks if you could implement it for the minority.

Update: Thanks. No need to bother any more. I already had a look at the source code and manually changed it to automatically create the output dir without warning.

[an3k]

Hey gpower2, thanks for the great tool. I love it extracts chapters too! I noticed that there isn't an option for mkvextract --raw so that video streams are extracted to the raw format rather than .avi (at least for vc1 streams).

Could you add that option please? Maybe with the --fullraw if that is of use at all. Thank you very much! :)

[johnsonlam]

Thank you very much! I like your program, simple and easy, it really help!

[gpower2]

Hey guys! I managed to find the time and refactor the inner works for the output filename generation, so that it can now be customizable!
I added a new Options form which can be accessed from a new button located at the bottom of the main form.
I also added some small features that were requested over time and made some changes in the form's controls.

Enjoy people! :D

Changelog

v2.5.0

Ask the user to create the output directory if it doesn't exist
Various improvements on Form Controls
Added new "Options" form to support custom output filename patterns
Check if a file with the same filename already exists before extracting and add a counter to the output filename to avoid overwritting the original file

[manolito]

Thank you so much, just what I needed... :thanks:

[Csimbi]

Changelog

v2.5.0

Ask the user to create the output directory if it doesn't exist
Various improvements on Form Controls
Added new "Options" form to support custom output filename patterns
Check if a file with the same filename already exists before extracting and add a counter to the output filename to avoid overwritting the original file


That update is fantastic!
Even better than I hoped for.
It was well worth the wait.
Thank you, much appreciated!

[gent]

to install gMKVExtractGUI to extract mkv subs, drop the mkv and I don´t see the tracks?????

[gonca]

to install gMKVExtractGUI to extract mkv subs, drop the mkv and I don´t see the tracks?????
If you mean the sub tracks, is it possible the tracks are burned in?

[gent]

If you mean the sub tracks, is it possible the tracks are burned in? ???? I dont know, I have to install inviska mkv extract, but its the slowest I've seen in my life and only to extract subtitles!!!! :scared: I dont know if it would a movie, I thought that gMKVExtractGUI would be faster....but I can't open the mkv with that....

[gent]

???? I dont know, I have to install inviska mkv extract, but its the slowest I've seen in my life and only to extract subtitles!!!! :scared: I dont know if it would a movie, I thought that gMKVExtractGUI would be faster....but I can't open the mkv with that.... Perhaps would MKVcleaver faster?

[gonca]

If you can't open the actual MKV, try first remuxing with MKVToolNix and then using gMKVExtract

[gent]

If you can't open the actual MKV, try first remuxing with MKVToolNix and then using gMKVExtractok thanks

[shag00]

Attempting to get this to work on Kubuntu 19.04 without any success. Are there any instructions? I have extracted the zip file successfully, right clicked the exe file and selected open with Mono and the nothing happens.

[rmlazzari]

My doubt is similar as shag00's: I'd like to use gMKVExtractGUI under Linux but I don't know how.

When I used Windows, I just copyed the three files to the same directory of MKVToolNix and created both, a link for the .EXE in the desktop and associated .MKV files to be opened by gMKVExtractGUI. Can you help me, please?

My Linux configuration is Linux Mint 19.1 Tessa 64 - Base Ubuntu 18.4 bionic - Cinnamon 4.0.10 - Kernel 4.15.0-55-generic - Intel Core i3-2328M CPU @ - 2.20GHz x 2 - Mem 3.7GiB - Monitor 1366x768

[gpower2]

Hi guys, sorry for the late reply!
Unfortunately is not my area of expertise, I just made the code platform-aware in order to support Linux and theoretically OSX.
However my personal experienc was only with an Ubuntu Virtual Machine that simply worked out of the box. I actually executed the exe with mono and it simply worked!

Perhaps some other linux user could enlighten us on the subject?

[darksen]

Thanks for all your work. I've been using your GUI for a couple of years.

[2-perf]

I have this .mkv here that is crashing gMKVExtract. It seems to be related to this audio track which has a delay value of 10000 ms (10 sec). I can extract that same .mkv with MeGUI and tsMuxer. If I remuxe it with MKVToolNix with no delay it works. Is there any audio delay limit value? Otherwise, thanks for the GUI!!

[gpower2]

I have this .mkv here that is crashing gMKVExtract. It seems to be related to this audio track which has a delay value of 10000 ms (10 sec). I can extract that same .mkv with MeGUI and tsMuxer. If I remuxe it with MKVToolNix with no delay it works. Is there any audio delay limit value? Otherwise, thanks for the GUI!!

Hey there! Could you provide with the Log text when you experience this behaviour? Or could you send me a pm with a sample video to reproduce the error?
Thanks for your feedback!

[2-perf]

Well, just mux any audio track with a 5 digit delay value and voilà, it will crash gMKVExtractGUI as soon as you drag & drop the resulting file in the gui.

I found out some other interesting weird stuff looking at this. Not related to gMKVExtractGUI but interesting.

See how MPC-HC starts messing up with how it displays the ac3 specs with a delay value higher than 7487. :)

No delay:
A: French [fre] (ac3, 48000 Hz, stereo, 192 kb/s)[default]

https://dl.dropboxusercontent.com/s/v88xmnxnecnf1wx/No%20Delay.png?dl=0


Delay value of 7487:
A: French [fre] (ac3, 48000 Hz, stereo, 192 kb/s)[default]

https://dl.dropboxusercontent.com/s/pkz52ksb65z3ycx/Delay%20Value%2C%207487.png?dl=0


Delay value of 7488:
A: French [fre] (ac3, 48000 Hz, 2 channels)[default]

https://dl.dropboxusercontent.com/s/wm3cvg696rc51fr/Delay%20Value%2C%207488.png?dl=0

[sneaker_ger]

Well, just mux any audio track with a 5 digit delay value and voilà, it will crash gMKVExtractGUI as soon as you drag & drop the resulting file in the gui.
Might be related to mkvmerge -J only outputting the minimum_timestamp if it's less than 10 seconds?
(See posts #211 (https://forum.doom9.org/showthread.php?p=1762982#post1762982) - #216)


I found out some other interesting weird stuff looking at this. Not related to gMKVExtractGUI but interesting.

See how MPC-HC starts messing up how it displays the ac3 specs with a delay value higher than 7487. :)
I guess there is a maximum probe size. It only analyzes the beginning of the file and if the first AC3 packet is not within the first N Bytes then it is not scanned.

[gpower2]

OK, that was a nasty one!

Indeed, like @sneaker_ger noticed, mkvmerge searches for delays of up to 10sec. However, gMKVExtractGUI being more tenacious, fires up mkvinfo and tries to search the delay the hard way. Then 2 bugs emerged:
1. The mkvinfo output string was changed and I never noticed it till now! :eek:
2. That part of the code tried to find delays for all tracks, while some of them could already be found from mkvmerge (<10sec delays).

Those bugs were fixed and pushed in trunk, new version will follow sometime soon.

Thanks @2-perf and @sneaker_ger for your valuable feedback! :)

[Bozotheclown]

Hello,

Recently get this error during audio track extracting:

CodecID 'A_MS/ACM' is not supported

17122

This is program or user fault?

[gpower2]

Hello,

Recently get this error during audio track extracting:

CodecID 'A_MS/ACM' is not supported

17122

This is program or user fault?

Hello, this audio codec is not supported by mkvextract, you could ask in the MKVToolNix (https://forum.doom9.org/showthread.php?t=175593) thread for support. ;)

[Bozotheclown]

Is fine now, I managed to do it by mkvtoolnix to mka -> eac3to

[tormento]

Is there a way to avoid "Success!" pop up at the end of the extraction?

[gpower2]

Is there a way to avoid "Success!" pop up at the end of the extraction?

Sure! You can just uncheck the "Popup" checkbox in the bottom left part of the screen:
https://i.ibb.co/Nx01RM3/2020-01-11-08-46-34-g-MKVExtract-GUI-v2-5-0-0-By-Gpower2.png (https://imgbb.com/)

[tormento]

Sure! You can just uncheck the "Popup" checkbox in the bottom left part of the screen:

https://i.ibb.co/Nx01RM3/2020-01-11-08-46-34-g-MKVExtract-GUI-v2-5-0-0-By-Gpower2.png (https://imgbb.com/)
Lol I did not notice it!

Thanks!

[jpsdr]

Those bugs were fixed and pushed in trunk, new version will follow sometime soon.

Hello, thanks for your tool.

Any idea of rough ETA of the "soon", as this information is now 2 months old ?

[gpower2]

Hello, thanks for your tool.

Any idea of rough ETA of the "soon", as this information is now 2 months old ?

Probably sometime this week. ;)

[gpower2]

Hey people! New year, new version! This is actually a minor fix version, basically fixes the issues with the long delays reported from @2-perf.
As always, enjoy! :D

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.5.1/gMKVExtractGUI.v2.5.1.7z/download

Changelog

v2.5.1

Fix finding delays with newer mkvinfo versions
Optimize finding delays with mkvinfo by searching only for tracks that couldn't find delays with mkvmerge

[redbtn]

Hey people! New year, new version! This is actually a minor fix version, basically fixes the issues with the long delays reported from @2-perf.
As always, enjoy!

Hey! Thank you!

[gpower2]

Hey people! This is a minor version, fixing a bug I discovered by accident (those are the best! :p).
As always, enjoy! :D

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.5.2/gMKVExtractGUI.v2.5.2.7z/download

Changelog

v2.5.2

Fix issue in checking for an existing job when adding a new job

[mbcd]

Any chance to get a function to remux all together again?

I have a series with lots of episodes where I want to remove all languages I dont understand. So basically there are two languages I need left in all episodes.

It is easy to demux those streams with gMKVExtractGUI by selecting those languages, thats very comfortable doing for all episodes together.

But how to remux all together again to mkv (including chapter, delays, metadata -> language-ID).

With mkvmerge you can do this, but not very comfortable, lots of clicks needed and every episode has to be done manually.

Any chance for a function that not demuxes all mkvs, but only using selected, so "keep" instead of "demux" ... (streams selected streams/tracks into a new file)

[sneaker_ger]

With mkvmerge you can do this, but not very comfortable, lots of clicks needed and every episode has to be done manually.
MKVToolNix GUI can do this automatically:

1. Preferences>Multiplexer>When dropping files>Create one new ... for each file
2. Preferences>Multiplexer>Enabling Items>Only enable copying of tracks with specific languages by default
3. Drag&Drop all your source files
4. Multiplexer>Actions for all tabs> Start multiplexing (, or Add to job queue and then start the jobs)

[SeeMoreDigital]

Any chance to get a function to remux all together again?
Hmm...

gMKVExtractGUI is an extraction (de-muxing) application. If you want a re-muxing application (along with track/stream selection) then MKVToolNix GUI is the way to go ;)

[mbcd]

@sneaker_ger:
Damn, never got this feature. Thank you very much for pointing to it, will try it! :thanks:

@SeeMoreDigital:
Yeah, its also some kind of extraction ... you extract specific tracks out. I think extraction does not mean you get always multiple files for each track, so it was not so far away from being "legit" to ask for it.

You can extract tracks directly into a new mkv, or is there another word to describe this type of extraction better? Of course it is always also some kind of remuxing. But without saving it to seperate files I would call it "extracting into single file".

Demuxing is a clear process (with multiple output) in my eyes, but extracting is a bit unprecise and gives some room for interpretation ...

[lvqcl]

You can extract tracks directly into a new mkv, or is there another word to describe this type of extraction better?
Remuxing.

[gendalv]

suggestion: add an option to batch export standard mediainfo information into txt files with file names
also are there other tools that can do this in a couple of clicks?

I've found this manual https://pastebin.com/V5jt5Zai
but it creates ANSI .txt files, which isn't inclusive enough - if file names contain Japanese or other symbols, how to make it create UTF-8/BOM files ?

[tormento]

suggestion: add an option to batch export standard mediainfo information into txt files with file names
also are there other tools that can do this

You can do from MediaInfo GUI itself, both txt and CSV, customizing the fields you need.

Simply drop the whole bunch of files you need to index and export what you want.

[gendalv]

mkvtoolnix doesn't come with a mediainfo gui, I've tried an official one, but it does the same thing - creating ansi text files when custom is selected (to have a individual .txt per video option) and requires a template too

[tormento]

I've tried an official one, but it does the same thing - creating ansi text files when custom is selected (to have a individual .txt per video option) and requires a template too
Never complain about free work of people or they could reply "do it yourself".

MediaInfo has its own GUI and, I know, create a custom template is a PITA. It took me 45 minutes last week to create a custom CSV sheet for my movie collection. But, hey, it's the "price of free software".

[gpower2]

suggestion: add an option to batch export standard mediainfo information into txt files with file names
also are there other tools that can do this in a couple of clicks?

I've found this manual https://pastebin.com/V5jt5Zai
but it creates ANSI .txt files, which isn't inclusive enough - if file names contain Japanese or other symbols, how to make it create UTF-8/BOM files ?

Hey man, I understand the validity of your request, however you' re barking at the wrong tree here! :P

gMKVExtractGUI has only one use, to extract data from matroska files.

What you're asking is to extract information from media files, so MediaInfo is the tool to use. Perhaps you could make a request to MediaInfo.Net (https://forum.doom9.org/showthread.php?t=176886) project which is a GUI for MediaInfo. ;)

[RainyShadow]

Would it be possible to disable the "Success" dialog? Or, at least make it non-blocking?

[gpower2]

Would it be possible to disable the "Success" dialog? Or, at least make it non-blocking?

Just uncheck the "Popup" checkbox on the bottom left part of the form. ;)

[tormento]

Just uncheck the "Popup" checkbox on the bottom left part of the form. ;)
If you had a dime for every person who asked, you could afford yourself, well, a Coke. :p

Much better to set is disabled in the next version.

[gpower2]

If you had a dime for every person who asked, you could afford yourself, well, a Coke. :p

Much better to set is disabled in the next version.

Haha! Indeed! :P

I am thinking of changing its name to something more intuitive like "Show Success Dialog", I believe this would so it. ;)

[RainyShadow]

Thanks!
I thought that was related to "Jobs" somehow, heh.
A tooltip would be fine too, in case "Show Success Dialog" takes too much space. Or just move it to options.

[tormento]

@gpower2

Sometimes I have to extract the same tracks from different files, where the only thing that changes is the file name.

In the mean time that you find a solution, could you expose the command line, such as mkvtoolnix-gui.exe does?

So I can create batch file, while you are thinking to how to automatize that. :)

[gpower2]

@gpower2

Sometimes I have to extract the same tracks from different files, where the only thing that changes is the file name.

In the mean time that you find a solution, could you expose the command line, such as mkvtoolnix-gui.exe does?

So I can create batch file, while you are thinking to how to automatize that. :)

Hi @tormento!

Since gMKVExtractGUI supports batch mode, I can't see the reason to expose the command line. For your scenario, you can add multiple files from different folders and use the context menu (right-click) and select the same track at once. You can even add jobs and run them at a later time as a batch. ;)

To cut a long story short, current design in gMKVExtractGUI calculates the command line just before it executes it, so it's not easy to expose that beforehand wihout rewriting a significant portion of the current codebase. :(

If you can elaborate on your scenario, perhaps I can provide with a new functionality or improve the existing ones.

Thank you very much for your feedback! :)

[Perenista]

This program is not extracting the audio properly. It's limiting a 14 h 57 min file into 2h31m54s.

This is the file I am talking about:
https://pastebin.com/MGHTc669

Also, check what I said here about it:
https://forum.doom9.org/showthread.php?t=175593&page=20

The entire 14h Matroska file is OK... I can listen to the entire audio track. It's just that I can't extract as WAV 100%. Why is it limiting to 2 hours?

EDIT: Trying this now: https://www.easytechguides.com/extract-audio-from-video.html

[stax76]

Maybe it has something to do with the wav format:

https://en.wikipedia.org/wiki/WAV#Limitations

I suggest to use ffmpeg and W64 format.

[Perenista]

Maybe it has something to do with the wav format:

https://en.wikipedia.org/wiki/WAV#Limitations

I suggest to use ffmpeg and W64 format.It worked. But I tried with Audacity first, as instructed in this site:

https://www.easytechguides.com/extract-audio-from-video.html

https://i.imgur.com/A0IDps1.png

Was this the right option? I selected the first, Signed 16 bit PCM.

This is the MediaINFO from the resulted W64 file:

https://pastebin.com/L5nEiBqz

With ffmpeg this site only instructed me to use this command:

ffmpeg -i video.mkv -f w64 -ab 384000 -vn audio.w64

I'll assume only this is needed, right? 384000 was a figure I was thinking about if I wanted to convert to AAC (FDK).

In this case the original audio track had a bitrate of 1 536 kb/s. So the command line, I guess, it would look like this:

ffmpeg -i video.mkv -f w64 -ab 1536000 -vn audio.w64

[fireattack]

Hi, I want to report a bug/inconsistency in the GUI.

When loading an input file, it shows two "delays" for any track.

According to https://sourceforge.net/p/gmkvextractgui/discussion/general/thread/ee13f7e1/ the first delay is relative to 0 timestamp and the second one is relative to the video.

The original comment only mentions audio track, so what about the video track?
Is the second delay still relative to the video (itself), or to the audio?

Either way, it doesn't seem to match with the behavior.

I made two videos to test: one with audio delayed for 2sec, one with video delayed for 2sec.

The first one (audio delay):

https://i.imgur.com/kWxl4JW.png

The video's second delay says "0ms", so it means it's NOT delay relative to audio, because otherwise it would be "-1978ms".

The second one (video delay):

https://i.imgur.com/HURmwPw.png

Now, here video's second delay says "2000 ms", which means it's indeed relative to the audio. This is inconsistent with example 1.

Summary:

In both cases, the first delay of video track is consistently shows the delay relative to 0 timestamp.
In both cases, the first delay of audio track is consistently shows the delay relative to 0 timestamp.
In both cases, the second delay of audio track is consistently shows the delay relative to the video track.

However, the second delay of video track is inconsistent, it shows the delay relative to the audio in one, but not in another (it is not consistently relative to the video, either.)

[rmlazzari]

First of all, thank for the program, I use it for years. Second, please excuse if this is a newbie question but, well...

Now the request: recently I migrated from Windows to Linux Mint so I'd like to install this GUI under my new OS. I already have MKVToolnix and MKVToolnix-gui because the Mint's Application Manager have options for them. As I'm not familiar with bits & bytes, can somebody please teach me how to install MKVExtractGUI without the App Manager?

(I know how to add a repository and typing some commands in Terminal like apt-get, apt-update etc... no much more beyond that. I'm using two versions of Mint, MATE in the notebook and Cinnamon in the desktop. If you need more information about my sets or something else, please ask me. Thank you.)

[jones1913]

@rmlazzari
You need the 'mono' framework installed to run .net applications on Linux. I think the package name is 'mono-complete' on Ubuntu based distributions.
After that you can run it with
$ mono /path/to/gMKVExtractGUI.exe

But .net applications sometimes look artifical or broken on Linux, on hi-dpi displays mostly unusable.

Alternatives are:
https://forum.ubuntu-fr.org/viewtopic.php?id=1508741
(post is in french but installation instructions are easy to spot)

or:
https://www.videohelp.com/software/Inviska-MKV-Extract
(seems abandoned, developers website is dead)

[rmlazzari]

Thank you, jones1913. Following your advices, I installed MKV Extractor Qt, mainly because it seems to be created natively for Linux and it's not an abandoned project.
It's working fine here. :)

[gpower2]

Hi, I want to report a bug/inconsistency in the GUI.

When loading an input file, it shows two "delays" for any track.

According to https://sourceforge.net/p/gmkvextractgui/discussion/general/thread/ee13f7e1/ the first delay is relative to 0 timestamp and the second one is relative to the video.

The original comment only mentions audio track, so what about the video track?
Is the second delay still relative to the video (itself), or to the audio?

Either way, it doesn't seem to match with the behavior.

I made two videos to test: one with audio delayed for 2sec, one with video delayed for 2sec.

The first one (audio delay):

https://i.imgur.com/kWxl4JW.png

The video's second delay says "0ms", so it means it's NOT delay relative to audio, because otherwise it would be "-1978ms".

The second one (video delay):

https://i.imgur.com/HURmwPw.png

Now, here video's second delay says "2000 ms", which means it's indeed relative to the audio. This is inconsistent with example 1.

Summary:

In both cases, the first delay of video track is consistently shows the delay relative to 0 timestamp.
In both cases, the first delay of audio track is consistently shows the delay relative to 0 timestamp.
In both cases, the second delay of audio track is consistently shows the delay relative to the video track.

However, the second delay of video track is inconsistent, it shows the delay relative to the audio in one, but not in another (it is not consistently relative to the video, either.)

@fireattack
So sorry for the late reply, too much work IRL!
Actually the second delay in the video track will always be the same with the first one, you are right and I should refrain from showing 2 delays for the video tracks.
There is no video delay relative to the audio, since that is not the way MKVToolnix works, at least AFAIK.
I'll check if I can make this fix. :)
Thanks for your feedback!

@rmlazzari
I'm not much of a Linux guy myself, like @jones1913 said, it should work out of the box if you have the mono framework installed (I think Ubuntu comes with it preinstalled).
So, you just download the archive from the DL link, and you run the ".exe" file like you would do in Windows.
If mono is installed, it should run without much fuss! :)
P.S.
I would really like your feedback if you find the time to do this test, thank you in advance! :)

[Perenista]

I am having problems with a MKV... this one was ripped from a DVD I own, and with help from MAKEMKV. Later I did a few changes using MKVTOOLNIX, added and extracted a few files.

Here's the thing: if I wanted to extract subtitles, then gMKVExtractGUI would have worked. But if I ask the program to extract any audio file, this is the end result:

https://i.postimg.cc/fL85PQs8/XAS.png

What is more odd is the fact any other file I have here works just fine with gMKVExtractGUI. And I also believe gMKVExtractGUI WAS INDEED working before, to extract audio streams from this problematic MKV.

What really happened here? Was the file somehow corrupted, something happened that made it broke?

When we try to rip this disc for the 1st time this is what MAKEMKV tells us:

https://pastebin.com/WvZAsDzi

Oddly, as you can see from below, if I try to extract the audio track from the original MKV created by MAKEMKV, it will work:

https://i.postimg.cc/QMTHPQrw/SUP.png

So what went wrong here? Now if I try to extract ANY audio track with gMKVExtractGUI it will fail.

[gpower2]

Hi Perenista!

The open file error that you get means that mkvtoolnix.exe couldn't create the new file for the audio.

Seeing the filepath, I believe that you hit the filesystem limitation of 255 characters in path.

Can you try to extract it in a folder with less characters instead of your desktop? For example try to extract it to a "C:\temp" folder and see if this is indeed your problem.

[Perenista]

Hi Perenista!

The open file error that you get means that mkvtoolnix.exe couldn't create the new file for the audio.

Seeing the filepath, I believe that you hit the filesystem limitation of 255 characters in path.

Can you try to extract it in a folder with less characters instead of your desktop? For example try to extract it to a "C:\temp" folder and see if this is indeed your problem.That's not the case. I renamed the problematic file to 1.MKV and put in C:\.

Still...

https://i.postimg.cc/sXY5Z25N/XX1.png

MAKEMKV has been having a host of issues with several discs lately *. I'll try to rip this thing again and repeat the entire process that lead me to having this Matroska with all these same tracks.

* https://makemkv.com/forum/viewtopic.php?f=8&t=21079

What I don't get it is why gMKVExtractGUI can perfectly extract an audio track (after MAKEMKV rips the DVD FOLDER) and then after a few editions, it refuses to do that.

But...

It still can extract subtitles from this now broken file (broken if I wanted to get something inside it, since now it's refusing to extract).

********
EDIT: The problem has been fixed! I suspected the fact I placed in C:\ was also causing another issue (besides the one you mentioned), then I put the 1.mkv in C:\temp folder, since at C:\ it asked for admin permission.

Inside the C:\temp FOLDER I was then able to extract any audio stream!

https://i.postimg.cc/K85zLgWL/PROBLEMFIXED.png

[Mosu]

Just an addition: MKVToolNix v50 and newer supports file/path names longer than 260 characters on Windows 10 if Windows 10's own support for long paths is turned on (https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/).

[Pulp Catalyst]

Can this program remux, i've been i found MKV optimizer https://www.videohelp.com/software/MKV-Optimizer

it works great for what i need, it quickly removes all steams from files i don't need, improving the reliability of my video converter a lot (ripbotx264)

however mkv optimizer crashes quite often, doesn't like network drives, and just basically is unstable for me

gMKVExtractGUI comes really close to features, but doesn't offer remux option?

is this something that could be added, as it would be just what i need...

i know i can use mkvtoolnix, but it doesn't have the fast default options that i need

for example i need to keep only ENG streams, and only keep DTS track ENG, the rest i want removed. mkvtoolnix wasn't really designed for this quick default process from what i can see. and really has few options for processing multiple/batch files that have different streams. mkvoptimizer is great for this, but crashes all the time, and i can't find the support page to contact developer for help

[Mosu]

for example i need to keep only ENG streams, and only keep DTS track ENG, the rest i want removed. mkvtoolnix wasn't really designed for this quick default process from what i can see.

Quite the opposite. It was designed to be automatable from other applications with very little effort. The basic three-step process is:

Let mkvmerge analyze your source file and output what it finds as a JSON document. JSON was chosen as there are JSON parsers out there for every programming language under the sun. You don't have to create your own parser, just use one that's available. The command to do so is "mkvmerge --identification-format json --identify yourfile.ext" or its shortcut "mkvmerge -J yourfile.ext".
Loop over the information found in the JSON document and pick the track IDs for tracks you want to keep. That's easy enough; for each track the JSON document contains its ID, its type (audio/video/subtitles), its codec, its language and a lot of other information.
Construct a new command line (better: a JSON option file) based on the track IDs gathered in step 2 and run mkvmerge with it.

Remember that mkvmerge's default is to copy everything safe for stuff you tell it not to copy. If your process is to solely remove all audio tracks that aren't DTS in English, you'll only need to collect all track IDs for English DTS audio tracks, add "--atracks <theIDs>" and that's it.

Sure, mkvmerge doesn't contain command line options for all possible scenarios under the sun, but it contains something much more important: command line options for each and every facet of a Matroska file. You have a lot of fine-grained control. Bundled with standards-based file formats (JSON both for identification output and for option files) makes interfacing with it rather straight forward, from whatever platform you're running on.

Of course you're completely free to disagree with my opinion here, and you certainly don't have to use it the process described above is to… whatever for you.

[Pulp Catalyst]

i have no idea what just said LOL

your seriously overestimating my abilities.

:confused:

i think mkv optimizer does all this behind the scenes perhaps, however the moment i load the program i import the files, and it's ready to go.

it also has the ability to delete source files after it processed.

[Asmodian]

This project is significant as the program used by many GUIs like that. I do find it very easy to mux a new file while replacing the audio tracks using the GUI but it obviously isn't designed for advanced batch processing so it does get tedious if I want to do the same thing to several files. It is a GUI that supports the more advanced mkv features well, but not simple batch processing. The two use cases are difficult to merge well and command line tools are great for batch processing.

For advanced batch processing I go into python. ;)

[darksen]

Please add support for the relatively newly supported language codes, I'm demuxing an es-419 audio track and the app names it with only ES.

[gpower2]

That's a nice suggestion @darksen!

I will "play" a bit with it and hopefully come up with a new version soon, thanks for the feedback! :)

[gpower2]

Hey people!
Wow, it's been 2 years since the last release and what years those were...
Hopefully 2022 will be a come back year for most of us, so I'll make a small start by a fresh new release. :)

Main attraction is the support for the new Language IETF element, thanks agan @darksen for the request! :)

Also, a lot of small optimizations here and there under the hood, hopefully they didn't break anything :D

As always, enjoy! :D

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.6.0/gMKVExtractGUI.v2.6.0.7z/download

Changelog

v2.6.0

Add support for new element "Language IETF"
Minor code optimizations/modernization

[oniiz86]

Hi, I want to report a bug/inconsistency in the GUI.

When loading an input file, it shows two "delays" for any track.

According to https://sourceforge.net/p/gmkvextractgui/discussion/general/thread/ee13f7e1/ the first delay is relative to 0 timestamp and the second one is relative to the video.

The original comment only mentions audio track, so what about the video track?
Is the second delay still relative to the video (itself), or to the audio?

Either way, it doesn't seem to match with the behavior.

I made two videos to test: one with audio delayed for 2sec, one with video delayed for 2sec.

The first one (audio delay):

https://i.imgur.com/kWxl4JW.png

The video's second delay says "0ms", so it means it's NOT delay relative to audio, because otherwise it would be "-1978ms".

The second one (video delay):

https://i.imgur.com/HURmwPw.png

Now, here video's second delay says "2000 ms", which means it's indeed relative to the audio. This is inconsistent with example 1.

Summary:

In both cases, the first delay of video track is consistently shows the delay relative to 0 timestamp.
In both cases, the first delay of audio track is consistently shows the delay relative to 0 timestamp.
In both cases, the second delay of audio track is consistently shows the delay relative to the video track.

However, the second delay of video track is inconsistent, it shows the delay relative to the audio in one, but not in another (it is not consistently relative to the video, either.)

@gpower2 I was just wondering if this bug was fixed in the latest v2.6.0?

[gpower2]

@gpower2 I was just wondering if this bug was fixed in the latest v2.6.0?

@oniiz86 This is not a "bug" it's how MKVToolnix works.

The second delay shown in the video track, will always be the same as the first one, I think the only case that it will be different, is if there are multiple video tracks muxed in the same mkv, with different delays. It is not the relative delay to the audio in any case.

So the examples you have posted are by design and not a bug. :)

[oniiz86]

@fireattack
So sorry for the late reply, too much work IRL!
Actually the second delay in the video track will always be the same with the first one, you are right and I should refrain from showing 2 delays for the video tracks.
There is no video delay relative to the audio, since that is not the way MKVToolnix works, at least AFAIK.
I'll check if I can make this fix. :)
Thanks for your feedback!


@oniiz86 This is not a "bug" it's how MKVToolnix works.

The second delay shown in the video track, will always be the same as the first one, I think the only case that it will be different, is if there are multiple video tracks muxed in the same mkv, with different delays. It is not the relative delay to the audio in any case.

So the examples you have posted are by design and not a bug. :)

@gpower2 Thanks for that I wasn't aware it was by design, it was just your comment you had made back then to @fireattack "I'll check if I can make this fix.", I assumed it was an inconsistent visual bug with gMKVExtractGUI v2.5.2, nevermind all is good :)

[Shou]

Hi,
There is a problem when there is a slash character in the track name, e.g. "name/subname" and you have {TrackName} in the output file name.

test.mka
https://i.imgur.com/vavXBFd.png
https://i.imgur.com/gTXWLu1.png

Result:
File "subname].ass" in "/test_02_[und][name/" folder.
File "subname2].ass" in "/test_03_[und][name2/" folder.

-

[gpower2]

@Shou

That's a really nice edge case, I guess this bug existed since forever. :D

I will replace illegal filename character with space, I think that would be the best approach here, any objections?

[Shou]

Yeah, replace with a space (or underscore) should be OK.

[gpower2]

Hey people!
Thank to @Shou's feedback, I just released a minor version to address the issue with invalid file characters in the output filename.

As always, enjoy! :D

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.6.1/gMKVExtractGUI.v2.6.1.7z/download

Changelog

v2.6.1

Replace invalid file characters with underscore character ('_') from output filename

[SeeMoreDigital]

Many thanks ;)

[tormento]

Thank to @Shou's feedback, I just released a minor version to address the issue with invalid file characters in the output filename.
Thank you!

Please consider to switch to GitHub as Sourceforge is giving lot of connection problems lately. :p

[gpower2]

Please consider to switch to GitHub as Sourceforge is giving lot of connection problems lately. :p

It's been on my TODO list like 3 years now :p

I just didn't have the time (or the determination) to change my local repo setup, though it's the next thing to actually tackle. :D

[mastrboy]

Is there a known bug with extracting attachments and using a different template for the name than default?

I tried to change the template to '{FilenameNoExt}_{AttachmentFilename}' and the attachments are extracted as '_{AttachmentFilename}'

For example, I expected episode001_arial.ttf, but got _arial.ttf

[gpower2]

Thanks for reporting this mastrboy, I'll check it. ;)

EDIT: Found the bug, uploading a new version shortly along with another fix :)

[gpower2]

Hey guys!
Thank to @mastrboy's feedback, I just released a minor version to address the issue with attachment extraction filename resolving not working correctly in all cases.
As an added bonus, I fixed another bug in track selection when filtering with empty values (eg. empty track names) and optimized the track selection a bit (should not make a difference in small lists).

As always, enjoy! :D

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.6.2/gMKVExtractGUI.v2.6.2.7z/download

Changelog

v2.6.2

Fix attachment filename for all cases. (Thanks mastrboy!)
Improve track selection when filter value is an empty string
Optimize algo to avoid unnecessary comparisons

[gpower2]

Small note, for some reason, the thread name no longer changes when editing the title of the first post.

If anyone knows how to change the thread title, please pm me or post here, thanks. :)

[SeeMoreDigital]

Small note, for some reason, the thread name no longer changes when editing the title of the first post.

If anyone knows how to change the thread title, please pm me or post here, thanks. :)Yep, this happens after so many years. Often one of the moderating team members can sort this out for you ;)

[hubblec4]

Small note, for some reason, the thread name no longer changes when editing the title of the first post.

Yeah Mosu has also start a new thread.
One solution: never use a version number in the thread title

[tebasuna51]

Yep, only moderators can Edit Thread

[SeeMoreDigital]

Where's that 'thanks' button when you need it ;)

[gpower2]

Thank you everyone for this! :)

[Bigmango]

Could you please add the FORCED tag to the extracted track name? (edit: only if the tag exists on that track, of course)

(and (if possible with mkvtoolnix) name it so that mkvtoolnix will automatically add the "forced" tag like it does with the "delay" when adding the tracks to a new mux)?

(-> currently it's a lot of work when remuxing a lot/often, load mediainfo to check for forced tags, etc... This would remove all of this work)

Many thanks ! :thanks:

[StainlessS]

Yep, this happens after so many years.
I think the magic number is 8 years, then cannot change thread title any more.
Methinks that title IS changed for 1st post, but not externally to the thread, ie not in forum list of new posts [thread title of new post].

One solution: never use a version number in the thread title
Good advice [which I have to remember to do myself].

[mastrboy]

Hey guys!
Thank to @mastrboy's feedback, I just released a minor version to address the issue with attachment extraction filename resolving not working correctly in all cases.
As an added bonus, I fixed another bug in track selection when filtering with empty values (eg. empty track names) and optimized the track selection a bit (should not make a difference in small lists).

As always, enjoy! :D

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.6.2/gMKVExtractGUI.v2.6.2.7z/download

Changelog

v2.6.2

Fix attachment filename for all cases. (Thanks mastrboy!)
Improve track selection when filter value is an empty string
Optimize algo to avoid unnecessary comparisons


Thanks, I'll try it out.


Edit: Can confirm the filename bug with attachements are fixed, thanks.

[winoni71]

Hello all,
I did this in the past but I can't remember how.
I want to extract the tracks in a folder named after the original mkv file, I thought you just had to add "{FilenameNoExt}\" in "Options", but it doesn't work.

Thank you.

[gpower2]

Hi @winoni71,

it was never the intention to add folder in the settings of the filename.

Perhaps it was working unexpectedly before, I added a fix to remove invalid filename characters because it created issues, so I don't think it's possible to extract to separate folders via this technique. :(

[Asmodian]

Perhaps it was working unexpectedly before, I added a fix to remove invalid filename characters because it created issues, so I don't think it's possible to extract to separate folders via this technique. :(

Maybe do not include \ as one of the invalid filename characters? ;)

[gpower2]

Maybe do not include \ as one of the invalid filename characters? ;)

That could lead to other issues, if track names contain the "" character, resulting in creating folders when that was not the intention.

The only solution I can think of, is to add a dedicated placeholder, like {folder_separator} in the options, in order for the user to explicitly express the wanted intentions, but I'll need to investigate.

[winoni71]

Hi @winoni71,

it was never the intention to add folder in the settings of the filename.

Perhaps it was working unexpectedly before, I added a fix to remove invalid filename characters because it created issues, so I don't think it's possible to extract to separate folders via this technique. :(

Bummer, it was a nice feature.
Thanks anyway for your tool.

[tormento]

I'll need to investigate.
I am having problems with attachments, i.e. even using {FilenameNoExt}_{AttachmentFilename}.

I need it to extract fonts. Can you please check it out?

[gpower2]

@tormento could you please send me a private mesage with the log from the file that gives you trouble?

I don't seem to find any issue with my sample files...

[tormento]

I don't seem to find any issue with my sample files...
Just mux a video, an audio, a sub and some fonts to a MKV.

Now demux with your utility.

Everything will have filename prefix but the fonts.

[AnimeSlash]

Hello, been using this for years and its great. Seems I missed many updates since the version I had. However kind of a small thing but would it be possible to have an option to overwrite or skip files if its already made. Mostly just looking for the fonts where I extract a series with many of the same fonts.

[kedautinh12]

I want to report extract audio, my autio track 3 in this file when extract name is xxx_DELAY 986000ms when i check info it's only delay 16 s 970 ms.
Example: https://drive.google.com/file/d/10J2Mh_hyRJ0S3krsj-r_IbnDmRpq0ve1/view?usp=sharing

[gpower2]

I want to report extract audio, my autio track 3 in this file when extract name is xxx_DELAY 986000ms when i check info it's only delay 16 s 970 ms.
Example: https://drive.google.com/file/d/10J2Mh_hyRJ0S3krsj-r_IbnDmRpq0ve1/view?usp=sharing

Thank you very much for your feedback, indeed there is a bug converting nanoseconds to milliseconds on my part!

I will upload a new version shortly :)

[gpower2]

Hey guys!
Thank to @kedautinh12's feedback, I just released a minor version to address the issue with calculating big delays from mkvinfo not working correctly.

As always, enjoy! :D

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.6.3/gMKVExtractGUI.v2.6.3.7z/download

Changelog

v2.6.3

Fix calculating delays from mkvinfo. (Thanks kedautinh12!)

[gpower2]

Also, one kind request for our administrators, could you please remove the version from the thread title since I can not edit the first post title anymore?

Thank you in advance! :)

[kedautinh12]

you're welcome

[Mosu]

Also, one kind request for our administrators, could you please remove the version from the thread title since I can not edit the first post title anymore?

Thank you in advance! :)

That happened to me, too, with the MKVToolNix thread. I've had some back & forth with other people on the platform here (https://forum.doom9.org/showthread.php?t=175541), and it seems that the forum software doesn't allow modification of thread titles after a certain time period. The first post in this thread was in February 2014, making it roughly 8 years, 7 months, and that's a timeframe I seem to remember from my own problems. Maybe there's a hardcoded limit of 100 months or something like that (8 * 12 + 4 = 100, don't know when you last tried to modify the topic's name).

I simply started a new thread & asked the mods to close the old one.

[gpower2]

Yes I had this issue again last time I posted a new version, the mods changed the title then, but I guess removing the version from the title is a nice workaround, inorder not to have to create a new thread. :)

[RyFeR26]

Long time user of this great tool as well for many years, thanks for creating and maintaining it!

I do have a question: would it be possible to add an option to be able to select a specific subtitle language that is then always selected automatically when opening a video file?

Example: when I select Dutch (DUT) as standard subtitle language, opening an .mkv with many subtitles would have DUT selected by default.

[tormento]

Hey guys!
I have just noticed that if you set

{FilenameNoExt} {Language} {TrackName}

and the trackname is empty, it keeps the space after {Language}, leading to a filename .ext format.

Would you please fix that?

[gpower2]

I have just noticed that if you set

{FilenameNoExt} {Language} {TrackName}

and the trackname is empty, it keeps the space after {Language}, leading to a filename .ext format.

Would you please fix that?

Hey Tormento, indeed I could do a final Trim in the filename before appending the extension, thanks for the feedback :)

[gpower2]

Long time user of this great tool as well for many years, thanks for creating and maintaining it!

I do have a question: would it be possible to add an option to be able to select a specific subtitle language that is then always selected automatically when opening a video file?

Example: when I select Dutch (DUT) as standard subtitle language, opening an .mkv with many subtitles would have DUT selected by default.

Hey RyFeR26, at the moment I don't want to add any more complexity to the UI, by adding more options/settings, as it could lead to a more cluttered design, sorry for that.
Hopefully the right click menu can help you easily select all Dutch language elements. :)

[tormento]

thanks for the feedback :)
You are the most welcome.

What about having the project on github?

[RyFeR26]

Hey RyFeR26, at the moment I don't want to add any more complexity to the UI, by adding more options/settings, as it could lead to a more cluttered design, sorry for that.
Hopefully the right click menu can help you easily select all Dutch language elements. :)

Selecting via that way works as well, thanks for the reply.

[oniiz86]

Hey Tormento, indeed I could do a final Trim in the filename before appending the extension, thanks for the feedback :)
@gpower2 I was wondering if this will be implemented soon in v2.6.4 or not worth the effort until there are a quite a few further refinements needed to be added?

[gpower2]

Hey guys!
Another new year, another release!
Thanks to @tormento's feedback, I released a new minor version to address the issue with having spaces in output file names when a pattern placeholder is empty.

As always, enjoy!

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.6.4/gMKVExtractGUI.v2.6.4.7z/download

Changelog

v2.6.4

Minor code optimizations
Add final Trim when generating the output filename (thanks tormento!)

[filler56789]

↑ :thanks:

[oniiz86]

@gpower2 :thanks: so very much for the swift update, once again the mods have yet to update the title thread to v2.6.4 ;)

[Bigmango]

Hi,

There are some gui sizing problems with scaling at 150% on hidpi (4k) screens (this is on linux with mono).

See the attached screenshot.

(it displays fine at 100%)

Could you please fix this ? Many :thanks:

[kedautinh12]

Add images to other image sources like https://imgur.io/ or you will waiting for approvaled by moderator forever :D

[gpower2]

Sorry for the late reply @Bigmango, unfortunately it seems that mono does not respect the DPI aware code the same way as Windows do, I cannot guarantee I will be able to fix this issue, since I need to setup a new Ubuntu box for testing. :(

[badshah]

From version 2.6.0 to latest version, all are showing Trojan.Malware.300983.susgen infection after scanning on virustotal
https://www.virustotal.com/gui/file/22124809cc2d39c2e33558185922f491799fb4bd990d970fa321d88c66488d39

[Zetti]

Not now, maybe earlier.

Check the resuilt again.

[gpower2]

From version 2.6.0 to latest version, all are showing Trojan.Malware.300983.susgen infection after scanning on virustotal
https://www.virustotal.com/gui/file/22124809cc2d39c2e33558185922f491799fb4bd990d970fa321d88c66488d39

This is possibly a false positive from the heuristics of MaxSecure, since the rest 59 AV vendors have no issues.

In any case, this is an open source project, so feel free to download and build the source code yourself in case you feel uneasy with the pre-build binaries. :)

[Perenista]

Does gMKVExtractGUI also have a Mac version? If not, what software would do the same tasks for Mac users?

[gpower2]

Does gMKVExtractGUI also have a Mac version? If not, what software would do the same tasks for Mac users?

In theory, it could run via Mono in Mac, but I haven't been able to set up a VM with OSX to test it...

You could try and give it a go and post your results here :)

[Lathe]

Hey guys!
Another new year, another release!
Thanks to @tormento's feedback, I released a new minor version to address the issue with having spaces in output file names when a pattern placeholder is empty.

As always, enjoy!

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.6.4/gMKVExtractGUI.v2.6.4.7z/download

Changelog

v2.6.4

Minor code optimizations
Add final Trim when generating the output filename (thanks tormento!)


Hey Bro! I just stumbled on this thread because I was doing a search about MKVExtract seemingly running slower than usual lately. Not a huge deal, but noticeable. I normally don't do anything really exotic with it, usually just extract EAC3 audio tracks to convert them to AC3 for my old OPPO player to be able to play them. If that is all I do with it, should I still try your version here? If I do, do I put your files in its own program folder, or do I somehow associate it with MKVMerge?

Thanks kindly for your advice and help!

[gonca]

If I do, do I put your files in its own program folder
Yes.
The first time you run it, it will throw an error.
Click OK.
Then you get the chance to browse to MKVToolNix.
From here on it is clear sailing.

[gendalv]

Can you add simple filters like: show only entries containing "sub" & "eng" but not "SDH". Or at least the first part of it.

[morphinapg]

Is there any way to get this to work with the Windows Store version of mkvtoolnix? If I find the directory that the exe files are located in, it gives me access denied errors. If I modify permissions on the mkvtoolnix folder (which is a little difficult compared to usual) then it works, but then it breaks mkvtoolnix until I uninstall it and reinstall it again.

[Mosu]

I appreciate your support for MKVToolNix, but the answer is unfortunately no. This is a bloody limitation of how packaging for the Windows Store works. See this issue (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3223) & this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Launching-the-command-line-programs-with-the-Microsoft-Store-variant) for more details.

[gpower2]

Is there any way to get this to work with the Windows Store version of mkvtoolnix? If I find the directory that the exe files are located in, it gives me access denied errors. If I modify permissions on the mkvtoolnix folder (which is a little difficult compared to usual) then it works, but then it breaks mkvtoolnix until I uninstall it and reinstall it again.

I think that Windows Store apps are designed to be isolated, so it would be understandable if other apps cannot access them... :(

[Liquid]

http://2advanced.uk/meg.png

using folder prefix in options, does not work anymore, in v2.5.0 it worked, can we have a fix for that.

Folder prefix is converted to {Folder Name}_, where both slashes are converted to underscore.

This change was made in v2.6.1
- Replace invalid file characters with underscore character ('_') from output filename

can we have the ability to export subs to subfolders next to file we exporting from.

Thank You

[gpower2]

Hello and thanks for the feedback!

The options there never actually supported subfolders officially, so this is a new feature that needs to be added.

I will try to tackle it in a new version soon :D

[oniiz86]

@gpower2 I was just wondering if the bug fix that @Liquid had mentioned above regarding folder prefix in options along with subfolders support will be released soon in v2.6.5?

[gpower2]

@gpower2 I was just wondering if the bug fix that @Liquid had mentioned above regarding folder prefix in options along with subfolders support will be released soon in v2.6.5?

Hi! Just to be clear, this is not a bug, this works like this by design 😉

This is a new feature request, I half finished it, but I didn't have the time to properly finish it, hopefully it will be done in 2024 🥹

[vertigo220]

Before I learned about this a few months ago, I was using tsMuxeR, but I've been using this instead since and use it frequently. First off, I'd like to thank you for making it, as it makes things much easier. I do have some feedback, both issues I've found with it and feature requests.

1) The popup to alert when done doesn't show on top of other windows if they're active/focused. For example, if I have a browser open and maximized, but have another small window in the corner focused, the popup will show over the browser, since it's not in focus. However, if it is in focus, the popup will show behind it, so it's not visible when done. To make things worse, it seems to put the popup under all windows when this happens, so it remains hidden even if the window that was active is minimized. For example, I'll start it then switch to watching a fullscreen video, and after a while I'll switch the video to a window, so it's no longer blocking where the popup is, but the popup isn't visible, so it looks like it's not done. I'll check the main window and it will look like it's stuck, with the abort buttons being clickable like it's still running, even though the progress bars are full, making it appear done. Only then will I realize the extra button on the taskbar for the popup, which is behind the other windows that were open in the background. In addition to all of this, there's no option to make a sound when finished.

2) I'm often wanting to compare tracks from two or more files in different locations, but unfortunately if I drag a file from one location into the input files area then drag a file from another location in, the second file replaces the first. It would be really helpful to be able to do this. The best way would be to have two drop locations, one to clear the current files with the dropped file(s), and one to add the dropped file to the current ones.

3) It would be really helpful to have some preset buttons that can be configured by the user for checking track types. For example, I often want to check all audio and subtitle tracks, but not video or chapter or attachments. To do this, I either have to right-click, go to "Check Audio Tracks..." then "All Audio Tracks," then repeat for subtitles, or I have to right-click, "Check All Tracks," then right-click and uncheck the ones I don't want. It would be much faster and save a lot of time if I could set a button to check all audio and subtitle tracks. Or even to have a button each for checking all video, audio, and sub tracks (and possible chapter and attachments), so I could just quickly click the buttons for the track types I want.

4) It would be really helpful if it would show how much space is needed for the selected tracks, changing as the selections change. It could also show the free space for the destination drive, making it easy to see if there's enough space for the selections. It could even warn somehow if there's not enough space.

5) A minor "issue," and perhaps some might have reason for it to work like it currently does, but if you run the same job multiple times, it will keep doing the extractions over again, creating duplicate files, instead of notifying they already exist.

6) A dark mode would be appreciated.

[gpower2]

Hey guys!
Long time no see! :D
Thanks to feedback from @Liquid, @oniiz86 and @vertigo220, I released a new version after quite some time, to address issues and introduce new features.

As always, enjoy!

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

Changelog

v2.7.0

Add explicit support for AV1 video codec
Add support for appending input files via drag and drop (thanks vertigo220!)
Make the success dialog popup appear as top most form across desktop (thanks vertigo220!)
Fix the Abort buttons state before the success dialog pop up appears (thanks vertigo220!)
Add new placeholder for directory separator in Options (thanks Liquid, oniiz86!)
Add new Status Strip in Options form in order to make resize easier
Add min size in the Options form to avoid minimizing it to size 1,1



Regarding the new feature of adding a directory separator, a new placeholder has been introduced as you can see in the screenshot, in order to separate sub-directories from filenames. ��

https://i.imgur.com/NhNh5ui.png

[gpower2]

Old Changelog, since first post got over 16k characters :D

v1.7.0

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


v1.6.6

Fix minutes in Cue Sheet Chapter Format (thanks bin_ch)
Add support for older mkvtoolnix versions (v4.x)


v1.6.5

Fix parsing the number of chapter entries in case there is only one chapter entry (thanks johnsonlam, rock)
Change gMKVToolnix to gMKVToolNix
Add new extraction mode "cues" (thanks bin_ch)
Add new Chapter Type "CUE" which transforms XML chapters to Cue Sheet (thanks isidroco)


v1.6.4

Add support for Linux (thanks djcj)
Add a start up check to ensure that gMKVToolnix.dll is present in the same directory as gMKVExtractGUI.exe
Fix progress labels position in JobManager form (thanks kypec)
Add check on closing in order to ensure that an extraction process does not get interrupted unintentionally (thanks magsood)
Fix Job Manager form Minimum Size
Add context menu to Job Manager Form in order to easily reset job states


v1.6.3

Fix finding mkvtoolnix path for mkvtoolnix v8.4 (while keeping compatibility with older versions)
Add hevc extension


v1.6.2

Fix the wrong setting of the initial form position in the ini file when the form is minimized
Fix typo bug (UFT-8 instead of UTF-8) (thanks bin_ch!)
Add WindowState setting
Make Form remember the last window state
Add a fallback mechanism, in order to use the UserAppData folder for storing the app settings when the current user doesn't have read/write permissions to the app path


v1.6.1

Changed Log Form to refresh the log text when Activated and not when Shown (thanks kongfl888!)
Fix adding Jobs to the Job Manager after loading jobs from XML (thanks kongfl888)
Added CodecPrivate property to gMKVTrack class (thanks dade49)
Removed PostProcessing of segment lists to gMKVHelper class
Changed ExitCode check, in order to avoid error messages when only warnings are present in the output
Remove UTF-8 parameter from mkvinfo


v1.6

Add job manager feature
Add Job Mode to the settings
Changed AutoScaleMode to DPI, hoping it will fix issues with people using larger font schemes
Add gRichTextBox and switch single line text boxes to gTextBox in main form
Some tweaking to Log form
Make main form to show the jobs manager when in job mode from Log button


v1.5.5

Add gTaskbarProgress class to wrap the ITaskbarList3 interface in order to take advantage of Windows Vista+ taskbar features
Fix TrueHD Audio file extension (thanks Giwyy)
Move classes to respective folders
Significantly decrease control flickering
Change taskbar mode while reading file contents
Changed frmLog to gForm class
Comment out a Debug.WriteLine statement in gCheckedListBox


v1.5.4

Enforce english ui language when executing mkvextract
Always make sure that progress bar is set to 100% before showing the completion success message


v1.5.3

Fixed setting the window's initial position to negative coordinates
Added the window's size to settings
Removed the help tooltip


v1.5.2

Fix parsing for Attachment Filenames for newer mkvmerge versions (ignore uid tag)
Added tooltip information about the track list
Added functionality to remember window position


v1.5.1

Increase the drag and drop area for the input file to the group box of input file info
Add a context menu for easy selection of tracks


v1.5

Hopefully fix Abort button from being drawn out of line in some OS (Windows XP ?)
Fix some visual issues
Added Output Directory and Lock Output Directory to the Settings
Replace escape characters in mkvmerge
Changed extraction mode to support grouping of similar tasks into one process call
Added support of finding the delays in video and audio tracks
Now extracted audio tracks have the relative to the video delay
Add an extra check when selecting timecodes extraction mode
Made a few more performance improvements


v1.4

Added abort button. Works per track extraction.
Added Abort All button, to abort all the extraction processes at once.
Refactored ini file and settings in general. Now the chapter type is also included in settings.
If MKVToolnix path is already set, ask the user before changing it.
Added validity check for when setting MKVToolnix path.
Added lock output directory feature. If locked, ouput directory doesn't change.
Changed extension of OGM chapters from ".ogm" to ".ogm.txt".
Make exception messages from mkvextract more sane.
Added check for mkvextract.exe, mkvinfo.exe and mkvmerge.exe existance just before invoking them.
Detect the audio delay via the track's timecodes and add it to the output filename.
Set the Browse... buttons to show the folder that is already specified by the user.
Check for a valid directory when drag and dropping in the output directory textbox.
Added timecodes extraction mode.
Changed the Status Strip Layout.
Changed the Extract Buttons to one Extract Button and a Combo Box.


v1.3.1

Fix loading of ini file
Don't keep the input file in the input textbox, if it is invalid
Add checks for user input when selecting an action


v1.3

Use a simple ini file to store the last used MkvToolnix path
Enable command line arguments in order to allow users to open files with gMKVExtractGUI
Change the tags output filename to "filename_tags.xml"
Use the --identify-verbose option of mkvmerge for checking the track contents of the matroska files, instead of mkvinfo
Removed --gui-mode parameter to mkvinfo since it broke compatibility with older versions of MkvToolnix
Changed the extension filter of the open file dialog to provide with an option that contains all valid extensions of matroska files


v1.2

Make XML chapters to be written in UTF-8 without BOM
Added more allowed extensions (.mka, .mks, .mk3d, .webm) (thanks sneaker_ger)
Added --ui-language parameter to mkvinfo with 'en' value to avoid translations
Added --gui-mode parameter to mkvinfo in order to double check that all output text will be in english
Added --command-line-charset parameter to mkvinfo with value "UTF-8"
Added --output-charset parameter to mkvinfo with value "UTF-8"
Added new Log form, which show the Log of the application
Added new 'Show Log' button in main form which shows the Log form

[Lathe]

Old Changelog, since first post got over 16k characters :D



Hey, thanks for all your hard work mate! :D

So, I am ignorant here (about most things!) is this automatically going to be in the MKVToolnix folder with the current version, or do I download this as a stand alone program or do I place it in the MKVtoolnix folder? What do I do? Thanks!

[vertigo220]

Hey, thanks for all your hard work mate! :D

So, I am ignorant here (about most things!) is this automatically going to be in the MKVToolnix folder with the current version, or do I download this as a stand alone program or do I place it in the MKVtoolnix folder? What do I do? Thanks!

This is a separate program. It's sole purpose it to demux MKVs into their individual tracks, whereas MKVToolNix is used for muxing/demuxing/combining/etc, but doesn't do so well at just extracting the raw tracks. So which program you will use depends on what you're trying to do, but they work separately from each other.

Edit to clarify that what I meant by separately is that while this program uses MKVToolNix by sending it commands to do what you want, that's the only way they're connected. You simply put this wherever you want and tell it where the MKVToolNix exe is so it can issues it commands, but it doesn't matter where each of them are as long as this knows where that is, and you only actually run one or the other and use it individually, depending on your needs. Personally, I have a directory where I house all my portable apps, then create a shortcut in the Start Menu for them and an exe that points to them that I place in a directory located in %path% so they're all accessible via the command line. I've written a script to do most of this so it's mostly automated.

[vertigo220]

I released a new version after quite some time, to address issues and introduce new features.

Thanks for the super-fast turnaround on this stuff! Regarding the appending checkbox, that's certainly much better, but any chance of making it a separate drop zone instead, so rather than having to toggle a checkbox back and forth, and possibly forgetting to check/uncheck it when meaning to append or not, files can simply be dropped into the main window to replace current files and into that area to append them?

Also, while I obviously didn't/don't expect such a fast implementation of my requests, just curious if you plan to add quick-select buttons for different track types. This is by far the biggest change I'd like to see as it would make using this program much faster.

[Lathe]

This is a separate program. It's sole purpose it to demux MKVs into their individual tracks, whereas MKVToolNix is used for muxing/demuxing/combining/etc, but doesn't do so well at just extracting the raw tracks. So which program you will use depends on what you're trying to do, but they work separately from each other.

Oh good, thanks! I will use your program then for extracting tracks as I'm sure it will work better... :)

[vertigo220]

Oh good, thanks! I will use your program then for extracting tracks as I'm sure it will work better... :)

Not my program (gpower2's), but you're welcome all the same.

If this is something you do a lot of and it's always the same task (extracting the eac3 track) you might even want to use a small batch script, add it to the right-click menu, then just right-click the file, select the script, and have it extract automatically, without having to launch a GUI, add the file(s), select the tracks, extract, and close the GUI. Just depends on how often you're doing this.

[Lathe]

Not my program (gpower2's), but you're welcome all the same.

If this is something you do a lot of and it's always the same task (extracting the eac3 track) you might even want to use a small batch script, add it to the right-click menu, then just right-click the file, select the script, and have it extract automatically, without having to launch a GUI, add the file(s), select the tracks, extract, and close the GUI. Just depends on how often you're doing this.

Good suggestion, thanks!

[Decalicatan_Decalicatan]

Thanks @gpower2 and @vertigo220 for the update and the new features!

[gpower2]

1) The popup to alert when done doesn't show on top of other windows if they're active/focused. For example, if I have a browser open and maximized, but have another small window in the corner focused, the popup will show over the browser, since it's not in focus. However, if it is in focus, the popup will show behind it, so it's not visible when done. To make things worse, it seems to put the popup under all windows when this happens, so it remains hidden even if the window that was active is minimized. For example, I'll start it then switch to watching a fullscreen video, and after a while I'll switch the video to a window, so it's no longer blocking where the popup is, but the popup isn't visible, so it looks like it's not done. I'll check the main window and it will look like it's stuck, with the abort buttons being clickable like it's still running, even though the progress bars are full, making it appear done. Only then will I realize the extra button on the taskbar for the popup, which is behind the other windows that were open in the background. In addition to all of this, there's no option to make a sound when finished.

Can you confirm if this is now fixed? Also, a sound should be played already regardless of whether there is a popup or not, the default "Asterisk" sound from Windows.

2) I'm often wanting to compare tracks from two or more files in different locations, but unfortunately if I drag a file from one location into the input files area then drag a file from another location in, the second file replaces the first. It would be really helpful to be able to do this. The best way would be to have two drop locations, one to clear the current files with the dropped file(s), and one to add the dropped file to the current ones.
Thanks for the super-fast turnaround on this stuff! Regarding the appending checkbox, that's certainly much better, but any chance of making it a separate drop zone instead, so rather than having to toggle a checkbox back and forth, and possibly forgetting to check/uncheck it when meaning to append or not, files can simply be dropped into the main window to replace current files and into that area to append them?

Adding 2 separate drop zones would be reducing the drop area significantly, also it would not be easy to separate them visually, or to inform the user of which is which, at least to my eyes. :)
The ability to have drag and drop perfom an append operation was raised by many users in the past, so it was high time I implemented it. ;)

3) It would be really helpful to have some preset buttons that can be configured by the user for checking track types. For example, I often want to check all audio and subtitle tracks, but not video or chapter or attachments. To do this, I either have to right-click, go to "Check Audio Tracks..." then "All Audio Tracks," then repeat for subtitles, or I have to right-click, "Check All Tracks," then right-click and uncheck the ones I don't want. It would be much faster and save a lot of time if I could set a button to check all audio and subtitle tracks. Or even to have a button each for checking all video, audio, and sub tracks (and possible chapter and attachments), so I could just quickly click the buttons for the track types I want.
Also, while I obviously didn't/don't expect such a fast implementation of my requests, just curious if you plan to add quick-select buttons for different track types. This is by far the biggest change I'd like to see as it would make using this program much faster.

Similar with the above request, I can not think of an intuitive way to implement such a feature. Each user has a unique way of working, I tried to find the common denominator and offer it in a simple UI.
Adding even more specifc shortcuts will make it a lot more complex imho, and not really sure of their value.

4) It would be really helpful if it would show how much space is needed for the selected tracks, changing as the selections change. It could also show the free space for the destination drive, making it easy to see if there's enough space for the selections. It could even warn somehow if there's not enough space.

This information didn't exist in the previous versions of MKVToolnix, and not sure if it will be present for all matroska files as it depends on the muxing application.
Also, since the output might be in different target drives, calculating and showing the free space per target drive would be quite a PITA to implement and to actually visualize.
In any case, this is indeed a nice to have feature, but requires A LOT of development and testing time, which I currently don't have. :D

5) A minor "issue," and perhaps some might have reason for it to work like it currently does, but if you run the same job multiple times, it will keep doing the extractions over again, creating duplicate files, instead of notifying they already exist.

This is indeed by design and there are no plans to change this, since "better safe than sorry" :D

6) A dark mode would be appreciated.

This is something I also want to implement, but it is really really hard to implement correctly in the UI I use (WinForms).
If I ever find the time for a big feature, that would be it, and it would also be the v3.0 milestone :)

[oniiz86]

@gpower2 :thanks:so very much for the latest v2.7.0 update & implementing @vertigo220's feature suggestions, it's greatly appreciated, just a heads up the thread title description still has v2.6.4 it should be v2.7.0 ;)

[vertigo220]

Can you confirm if this is now fixed? Also, a sound should be played already regardless of whether there is a popup or not, the default "Asterisk" sound from Windows.

It is fixed, though is now overly aggressive, but not sure how difficult it is to get it just right. It now shows not only the popup but the main window over everything, including a playing video. The preferred behavior, which is what most similar programs do, would be to have the popup separate and show it over all apps not set on top, e.g. over the browser and other windows but not over the video player, so it doesn't show in front of the video but is visible over everything else when I restore the video from fullscreen to a window. That said, this is still at least better.

I think the bigger issue is the sound. I could just use that and not the popup, which is really preferred for me anyway, but while it does in fact play a sound, it's tied to the system output, which I have muted. It should output sounds through itself, not the system. Look at MKVToolNix, for example, when it plays its completed sound, it shows under MKVToolNix in the sound mixer, and its volume can be individually adjusted. I mute system sounds as they are annoying, and therefore, because this program plays through that channel, it's muted as well.

Adding 2 separate drop zones would be reducing the drop area significantly, also it would not be easy to separate them visually, or to inform the user of which is which, at least to my eyes. :)
The ability to have drag and drop perfom an append operation was raised by many users in the past, so it was high time I implemented it. ;)

I just figured the area where the "Append input on drag and drop" is could be made its own drop zone, or the area next to it. Doesn't have to be large. I'm not going to push the issue, but just wanted to put the idea of how to do it out there.

Similar with the above request, I can not think of an intuitive way to implement such a feature. Each user has a unique way of working, I tried to find the common denominator and offer it in a simple UI.
Adding even more specifc shortcuts will make it a lot more complex imho, and not really sure of their value.

Again, not to push the issue, but to offer ideas, there could simply be a series of buttons somewhere (a row between above or below the input files area or a column to the right of it) that can be set to do various things, thus accounting for different users. I could set the buttons to toggle marking vid/aud/sub/chapter tracks, another user could set them to mark all tracks, unmark all tracks, remove selected file, etc. I'm happy to discuss more to come up with a solution, but I also don't want to bother you with it if it's not something you want to do.

This information didn't exist in the previous versions of MKVToolnix, and not sure if it will be present for all matroska files as it depends on the muxing application.
Also, since the output might be in different target drives, calculating and showing the free space per target drive would be quite a PITA to implement and to actually visualize.
In any case, this is indeed a nice to have feature, but requires A LOT of development and testing time, which I currently don't have. :D

Fair enough.

This is indeed by design and there are no plans to change this, since "better safe than sorry" :D

Again, fair, though perhaps it should warn? As I said, this is a minor issue and not one I'm personally concerned with, just a suggestion to perhaps prevent an issue for others if they were to run it more than once unintentionally.

This is something I also want to implement, but it is really really hard to implement correctly in the UI I use (WinForms).
If I ever find the time for a big feature, that would be it, and it would also be the v3.0 milestone :)

Also fair. I have no experience in WinForms, just some in VB years ago, and it seems similar-ish. I did see looking at screenshots that it looks like it can be done. I was going to try and play with it a bit but, in typical MS fashion, they make things as difficult as possible, as just trying to install it all I see is an install for .NET (Digging around more it looks like I need Visual Studio, but don't want to waste bandwidth downloading then deal with installing more MS clutter if that's not it, so can someone confirm? In the meantime I'm going to check out Jetbrains Rider). Looked into WPF/GTK/Qt, but I don't care to spend the time on WPF since I don't plan on staying in the Windows ecosystem much longer, and GTK/Qt are both garbage from initial impressions.

[gpower2]

It is fixed, though is now overly aggressive, but not sure how difficult it is to get it just right. It now shows not only the popup but the main window over everything, including a playing video. The preferred behavior, which is what most similar programs do, would be to have the popup separate and show it over all apps not set on top, e.g. over the browser and other windows but not over the video player, so it doesn't show in front of the video but is visible over everything else when I restore the video from fullscreen to a window. That said, this is still at least better.

I was troubled by the fact that when I pressed the popup, then the main window was not appearing, so I opted for bringing the main window also in front after acknowleding the popup.
In my eyes, if you have selected to have a popup appear, you would also want to continue working with the program after the operation finishes.
Otherwise, the simple sound would be enough to inform you that the operation had finished.

I think the bigger issue is the sound. I could just use that and not the popup, which is really preferred for me anyway, but while it does in fact play a sound, it's tied to the system output, which I have muted. It should output sounds through itself, not the system. Look at MKVToolNix, for example, when it plays its completed sound, it shows under MKVToolNix in the sound mixer, and its volume can be individually adjusted. I mute system sounds as they are annoying, and therefore, because this program plays through that channel, it's muted as well.

That would require to include a separate audio file and also include the media player functionality inside the app. I understand your way of working and how it would benefit you, but it would increase the bundled size of the app, which is something I try to avoid. ;)

Again, not to push the issue, but to offer ideas, there could simply be a series of buttons somewhere (a row between above or below the input files area or a column to the right of it) that can be set to do various things, thus accounting for different users. I could set the buttons to toggle marking vid/aud/sub/chapter tracks, another user could set them to mark all tracks, unmark all tracks, remove selected file, etc. I'm happy to discuss more to come up with a solution, but I also don't want to bother you with it if it's not something you want to do.

Just to avoid any misunderstandings, you are requesting some placeholders to add programmable actions, right?
If this is the case, it would require A LOT of work in order to have this implemented correctly and basically it would require refactoring most of the core codebase in order to split it into separate modules/commands that could be automated.
It is definitely a nice feature, but as mentioned, it requires so much work, that I can't get to at least in the near future.

Also fair. I have no experience in WinForms, just some in VB years ago, and it seems similar-ish. I did see looking at screenshots that it looks like it can be done. I was going to try and play with it a bit but, in typical MS fashion, they make things as difficult as possible, as just trying to install it all I see is an install for .NET (Digging around more it looks like I need Visual Studio, but don't want to waste bandwidth downloading then deal with installing more MS clutter if that's not it, so can someone confirm? In the meantime I'm going to check out Jetbrains Rider). Looked into WPF/GTK/Qt, but I don't care to spend the time on WPF since I don't plan on staying in the Windows ecosystem much longer, and GTK/Qt are both garbage from initial impressions.

Unfortunately everyone has turned to Web, so native applications are second class citizens, with only half baked solutions out there. WinForms for me is the last man standing, offering cross-platform compatibility thanks to Mono.
WPF is pretty, but very much like writing a Web app. QT requires C++ and I am not willing to dive into that. MAUI is only for modern OSes, so compatibility is out of the question and it is WPF-ish.
And then you get Electron with all its clutter and javascript, or Tauri, which requires Rust :D
Thanks, but I'll stick to good old WinForms for small desktop apps like this one :D

Rant aside, dark mode is the one big task I am willing to devote some time, since I also prefer dark mode, though I don't think I will have time to finish this soon...

Thanks for all the feedback! :)

[vertigo220]

I was troubled by the fact that when I pressed the popup, then the main window was not appearing, so I opted for bringing the main window also in front after acknowleding the popup.
In my eyes, if you have selected to have a popup appear, you would also want to continue working with the program after the operation finishes.
Otherwise, the simple sound would be enough to inform you that the operation had finished.

This is true, though IMO it should only show the popup on top, and clicking on that would then bring the main window to the front. This is the typical behavior I'm used to. Though I'm not sure how difficult that is, and it would be less of an issue if the sound can be improved (see next point).

That would require to include a separate audio file and also include the media player functionality inside the app. I understand your way of working and how it would benefit you, but it would increase the bundled size of the app, which is something I try to avoid. ;)

I assumed it was actually in the design, i.e. it would require actual code to play in its own "channel" vs the system one, but if I'm understanding you correctly, it's simply the fact you're having the app play a standard system sound/wav, and that having it play another sound would result in it showing as this app playing the sound in the mixer? If that's the case, could an option be added for the user to select their own sound? Heck, I'd even settle for it using MKVToolNix's sound, since it's already using that app, though not sure if that would be any easier than just allowing the user to select their own.

Just to avoid any misunderstandings, you are requesting some placeholders to add programmable actions, right?
If this is the case, it would require A LOT of work in order to have this implemented correctly and basically it would require refactoring most of the core codebase in order to split it into separate modules/commands that could be automated.
It is definitely a nice feature, but as mentioned, it requires so much work, that I can't get to at least in the near future.

Yes. However, the fully customizable aspect was just a suggestion to allow anyone to set up the buttons to work in whatever way they want. If that's too much, just having a button that toggles each the video, audio, subtitle, and chapter tracks would be immensely helpful. When clicked, it could just check all applicable tracks by running the same sub/function as when right-clicking, going to the "Check {track type} Tracks" option, and selecting the "All" button, then remembering that was the last option so, if clicked again, it would do the same for uncheck. Or even just having strictly check all vid/aud/sub/etc buttons without a toggling feature. But I do understand this could be considered niche and some people might want to check all tracks by language, codec, etc. I just imagine most people are mainly checking/unchecking all of a certain type. And I can certainly see how buttons, especially customizable ones, would be too complicated when accounting for all the various possibilities (different languages, resolutions, codecs, etc), but keeping it simple, just to "all," should be straightforward. Even doing the more specific stuff should be doable by right-clicking the list entry and being presented with the option to assign it to a button, or having a drop-list for each button that's the same as the right-click menu in the list which assigns that function to the button (so clicking the button would be the same as right-clicking in the list, navigating to that option, and selecting it). And either way, the button would be greyed out if the designated function isn't applicable (e.g. if it was set to check all 1080p tracks and there are none). Anyways, as I said, I don't want to keep pushing it, just clarifying what I'm thinking and offering ideas of how to do it. While it's definitely a feature I would like, if it's too much, that's fine.

Unfortunately everyone has turned to Web, so native applications are second class citizens, with only half baked solutions out there. WinForms for me is the last man standing, offering cross-platform compatibility thanks to Mono.
WPF is pretty, but very much like writing a Web app. QT requires C++ and I am not willing to dive into that. MAUI is only for modern OSes, so compatibility is out of the question and it is WPF-ish.
And then you get Electron with all its clutter and javascript, or Tauri, which requires Rust :D
Thanks, but I'll stick to good old WinForms for small desktop apps like this one :D

Rant aside, dark mode is the one big task I am willing to devote some time, since I also prefer dark mode, though I don't think I will have time to finish this soon...

Thanks for all the feedback! :)

Yeah, I agree, and also hate the push to move to web-based apps. From what I've gathered, Electron is bloated, WPF has mixed opinions, Qt frustrated me enough I gave up on it before even getting through the install process (and I wasn't sure what language this program is in and therefore which of these could even be used for it), and I tried installing GTK but it flat-out didn't work. WinForms really seems from what I've gathered to be very good for this type of app, I just hate that it's Microsoft. It's interesting you mention cross-platform/Mono, because that seems a bit iffy from what I've read, and I was wondering if this app would run in Linux. Anyways, I'm hoping at some point to play around with WinForms and see what it's like. No promises, obviously, because I may end up way over my head, but I'd like to see if I can develop a dark theme for this. I'm imagining it's just a matter of designing it, not actually coding, or is that not the case?

[gpower2]

Hey guys, Happy new 2025! :)

New year, new version!
This brings a feature that I also personally wanted for years now, and finally it's here: Dark mode!

This was based heavily on the work of BlueMystical here: https://github.com/BlueMystical/Dark-Mode-Forms

I hope that you will enjoy this release as much as I did and as always enjoy! :D

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

Changelog

v2.8.0

Add support for Dark Mode



I hope some of the mods here can update the thread title, since it is not possible from myside anymore :D

[oniiz86]

@gpower2 :thanks:so much for the update, not sure why the thread title can no longer be changed by the thread starter, @tebasuna51 can you please update the thread title so it simply reads "gMKVExtractGUI" :)

[SeeMoreDigital]

The forum has a time/date limit... It's been here longer than I have ;)

[filler56789]

@gpower2 —
Thank you very much :thanks: for the update :D

[lostclusters]

@gpower2

Dude! this GUI for mkvtoolnix stream extractor is sure came in handy extracting subtitles from one media file for another, for my deaf sister.

Thank you for making this handy utility easier to use!

[vertigo220]

Every time I try enabling dark mode, when the program starts, I get this error:

Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately.

InvalidArgument=Value of '-770479504' is not valid for 'start'.
Parameter name: start.

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ArgumentOutOfRangeException: InvalidArgument=Value of '-770479504' is not valid for 'start'.
Parameter name: start
at System.Windows.Forms.ComboBox.Select(Int32 start, Int32 length)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.8.4772.0 built by: NET48REL1LAST_C
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
----------------------------------------
gMKVExtractGUI
Assembly Version: 2.8.0.0
Win32 Version: 2.8.0.0
CodeBase: file:///C:/Portable%20Apps/gMKVExtractGUI%20(Portable)/gMKVExtractGUI.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.8.4734.0 built by: NET48REL1LAST_C
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.8.4767.0 built by: NET48REL1LAST_C
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.8.4390.0 built by: NET48REL1LAST_C
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
gMKVToolNix
Assembly Version: 2.8.0.0
Win32 Version: 2.8.0.0
CodeBase: file:///C:/Portable%20Apps/gMKVExtractGUI%20(Portable)/gMKVToolNix.DLL
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.8.4762.0 built by: NET48REL1LAST_B
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.8.4190.0 built by: NET48REL1LAST_B
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.8.4084.0 built by: NET48REL1
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

[gpower2]

Thanks for reporting this @vertigo220, I will try to get to the bottom of this, unfortunately I can not reproduce it yet in my local system, can you tell me a bit more about your system? (Windows version mainly)

[gpower2]

@vertigo220 Could you please download this debug test version to see if it fixes the issue?

https://fastupload.io/9442b883c7d34844

Thanks again for the feedback!

[vertigo220]

Tried it and seems to be working. Not sure if it still matters, but W10x64 Version 22H2 (OS Build 19045.5371).

[gpower2]

Thanks for the confirmation, I will release a new official patch version in the following minutes! :thanks:

[gpower2]

Hey guys, new patch version to address the issue reported from vertigo220 regarding Dark mode!

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.8.1/gMKVExtractGUI.v2.8.1.7z/download

Changelog

v2.8.1

fix(dark): Possible fix of a bug with ComboBox in dark mode (thanks vertigo220!)

[vertigo220]

Thanks for the dark mode and the quick fix. Definitely much easier on the eyes. Progress bars still being white looks a bit strange, not sure if they were left that way due to difficulty getting them a different color or intentionally, though not a big deal. The "Selected File Information" box is strange because it's dark until a job is running, then it turns white, then dark again once done. Still not as bright as when the whole window is light-colored, but would be better if it stayed dark. Figured I'd point it out in case you didn't know about it, maybe it's just doing it for me.

Unrelated, one other request is to make the taskbar progress reflect the overall progress instead of the individual file progress. If I'm extracting from multiple files, I can't really tell how far along it is with it in the background, because monitoring the taskbar button only tells me the progress of whichever file it's currently on, which isn't very useful.

[vertigo220]

I'm having an issue since updating to the latest version that right-clicking takes significantly longer to open the context menu for selecting/deselecting multiple tracks when dark mode is activated. It works like normal with the menu opening immediately in light mode, but as soon as I switch to dark mode it's very slow, and switching back makes it fast again.

[oniiz86]

I'm having an issue since updating to the latest version that right-clicking takes significantly longer to open the context menu for selecting/deselecting multiple tracks when dark mode is activated. It works like normal with the menu opening immediately in light mode, but as soon as I switch to dark mode it's very slow, and switching back makes it fast again.

@vertigo220 I've just tried the latest v2.8.1 & am not witnessing this slow behaviour with Dark Mode when Right-Clicking to bring up the Context Menu, it's reasonably fast & behaves the same way whether it's Light Mode or Dark Mode.

@gpower2 I was curious if you've witnessed the above behaviour with v2.8.1 that @vertigo220 is experiencing?

Also can any of this be addressed that @vertigo220 brought up last month?

Progress bars still being white looks a bit strange, not sure if they were left that way due to difficulty getting them a different color or intentionally, though not a big deal. The "Selected File Information" box is strange because it's dark until a job is running, then it turns white, then dark again once done. Still not as bright as when the whole window is light-colored, but would be better if it stayed dark. Figured I'd point it out in case you didn't know about it, maybe it's just doing it for me.

Unrelated, one other request is to make the taskbar progress reflect the overall progress instead of the individual file progress. If I'm extracting from multiple files, I can't really tell how far along it is with it in the background, because monitoring the taskbar button only tells me the progress of whichever file it's currently on, which isn't very useful.

[gpower2]

Thanks for the dark mode and the quick fix. Definitely much easier on the eyes.

Thank you for the feedback, it's nice to hear that this change was helpful. :D

Progress bars still being white looks a bit strange, not sure if they were left that way due to difficulty getting them a different color or intentionally, though not a big deal. The "Selected File Information" box is strange because it's dark until a job is running, then it turns white, then dark again once done. Still not as bright as when the whole window is light-colored, but would be better if it stayed dark. Figured I'd point it out in case you didn't know about it, maybe it's just doing it for me.

These are both known, unfortunately to tackle them, it would require to customly render the whole controls, which is something that I am not willing to do...
I will revisit at some point to see if there is a different way to achieve the same behavior, but unfortunately my first tries were a total failure 🥲

Unrelated, one other request is to make the taskbar progress reflect the overall progress instead of the individual file progress. If I'm extracting from multiple files, I can't really tell how far along it is with it in the background, because monitoring the taskbar button only tells me the progress of whichever file it's currently on, which isn't very useful.

I thought of this myself at some point, this will probably be included in the next version, thanks!

I'm having an issue since updating to the latest version that right-clicking takes significantly longer to open the context menu for selecting/deselecting multiple tracks when dark mode is activated. It works like normal with the menu opening immediately in light mode, but as soon as I switch to dark mode it's very slow, and switching back makes it fast again.

Hmm, I guess you have a low end CPU, since I can understand why this takes longer, since in order to make all the menus in the context menu render in dark mode, I had to manually redraw every one of them...
In my case, I have a high end CPU and there was no difference, I'll see if I can find a more performant way to achieve the same behavior, thanks for the feedback!

@vertigo220 I've just tried the latest v2.8.1 & am not witnessing this slow behaviour with Dark Mode when Right-Clicking to bring up the Context Menu, it's reasonably fast & behaves the same way whether it's Light Mode or Dark Mode.

@gpower2 I was curious if you've witnessed the above behaviour with v2.8.1 that @vertigo220 is experiencing?

Also can any of this be addressed that @vertigo220 brought up last month?

I will try to find some time to work on the above requests, are you also interested in them?

[oniiz86]

I will try to find some time to work on the above requests, are you also interested in them?

@gpower2 Yes as noted by @vertigo220 above, the feature requests would be greatly appreciated, thanks for being so receptive to feedback & always improving this invaluable tool. :)

[THGhost]

Hmm, I guess you have a low end CPU, since I can understand why this takes longer, since in order to make all the menus in the context menu render in dark mode, I had to manually redraw every one of them...
In my case, I have a high end CPU and there was no difference, I'll see if I can find a more performant way to achieve the same behavior, thanks for the feedback!

Registered to say that it's definitely not a low end CPU issue. I have a high end CPU and the right-click context menu still takes a while to load when the dark mode is activated. Roughly 10 seconds. Just thought you should know. Hopefully this can be fixed :thanks:

[gpower2]

@gpower2 Yes as noted by @vertigo220 above, the feature requests would be greatly appreciated, thanks for being so receptive to feedback & always improving this invaluable tool. :)

Thanks for your kind words, always happy to offer back to this amazing community! 🤗

Registered to say that it's definitely not a low end CPU issue. I have a high end CPU and the right-click context menu still takes a while to load when the dark mode is activated. Roughly 10 seconds. Just thought you should know. Hopefully this can be fixed :thanks:

Wow, 10 secs, really? Can you share the number of tracks that you have in order to try and reproduce this locally?

[THGhost]

Thanks for your kind words, always happy to offer back to this amazing community! 🤗



Wow, 10 secs, really? Can you share the number of tracks that you have in order to try and reproduce this locally?

Well, I did say "roughly" :P Literally any file with any number of tracks.

[Hellboy.]

I have a AMD Ryzen 5 5600X 6-Core Processor and i don't see any difference between dark mode and light mode.

[THGhost]

I have a AMD Ryzen 5 5600X 6-Core Processor and i don't see any difference between dark mode and light mode.

Well I have an AMD Ryzen 9 7950X3D and I definitely do. So something is clearly wrong xD

[tormento]

It's a long time that I don't connect to my computer by RDP but, since it happened recently, I have a strange issue to report.

When connecting from a lower resolution monitor, the majority of other programs move themselves in the visible area of the screen.

gMKVExtractGUI doesn't and I had to move it manually from the status bar thru cursor keys to make it visible.

Do you think that it's a fixable bug?

[vertigo220]

These are both known, unfortunately to tackle them, it would require to customly render the whole controls, which is something that I am not willing to do...
I will revisit at some point to see if there is a different way to achieve the same behavior, but unfortunately my first tries were a total failure 🥲

No worries. Still far better, and if it's a major effort to fix these last bits it may not be worth it.

Hmm, I guess you have a low end CPU

Certainly an older CPU, but far from low-end (i7-7820X). Despite its age, I wouldn't expect something like this to be very demanding of it. Could be wrong, though, but based on other responses it seems it's something else. It's bad enough that I've given up on dark mode for now as it's just far too slow to really be usable. As with THGhost, it's at least several seconds every time. Though I just switched back to dark mode to test with different numbers and sizes of files and tracks and it seems faster, only taking between 1-2 seconds for one or two small files with few tracks to 3-4 seconds for more/larger files and more tracks. Still far slower than light mode, which is instant even with several large files with multiple tracks each, but not unbearably slow as it's consistently been up until now. Not sure what the difference is, or if it will stay like this or revert back to being slow. I'm also seeing little to no change in CPU usage when right-clicking multiple times, which further confirms that it's unlikely a CPU issue. And just going back and trying a couple more times, it took a few more seconds (closer to 7 each time), and both times the program went unresponsive for about half a second at around 5-6 seconds. Let me know if I can do anything to help test/troubleshoot.

[THGhost]

Certainly an older CPU, but far from low-end (i7-7820X). Despite its age, I wouldn't expect something like this to be very demanding of it. Could be wrong, though, but based on other responses it seems it's something else. It's bad enough that I've given up on dark mode for now as it's just far too slow to really be usable. As with THGhost, it's at least several seconds every time. Though I just switched back to dark mode to test with different numbers and sizes of files and tracks and it seems faster, only taking between 1-2 seconds for one or two small files with few tracks to 3-4 seconds for more/larger files and more tracks. Still far slower than light mode, which is instant even with several large files with multiple tracks each, but not unbearably slow as it's consistently been up until now. Not sure what the difference is, or if it will stay like this or revert back to being slow. I'm also seeing little to no change in CPU usage when right-clicking multiple times, which further confirms that it's unlikely a CPU issue. And just going back and trying a couple more times, it took a few more seconds (closer to 7 each time), and both times the program went unresponsive for about half a second at around 5-6 seconds. Let me know if I can do anything to help test/troubleshoot.

I concur with these findings. It would appear I've been working with a lot of files with lots of subtitles tracks recently; hence the 10 seconds. But using files with fewer tracks does result in faster times, but still much slower than it is without the dark mode enabled. Very odd indeed.

[gpower2]

Hello guys!

I finally found some time around to finally fix the dark mode issues.
And this time around, I had some help!
I gave Jules from Google a spin, and with its help, I managed to re-implement Dark mode from scratch!
It now supports dynamic theming (bye-bye restarts), fixes some visual issues from the previous implementation,
but most importantly, it fixes the performance issues from the Context menu!

Also, I changed the TaskBar's progress bar to reflect the total progress, instead of each individual job's.

Finally, one big change is that I moved from SourceForge to Github, something I've been meaning to do for some time,
so all new releases will be added in Github from here on out!

I will also update the inital post of the thread to avoid any issues.

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.9.0/gMKVExtractGUI.v2.9.0.7z

Changelog

v2.9.0

fix(progress): Update the task bar progress bar value based on the total progress and not on the individual job progress
fix(code): Switch to unboxed types and minor optimizations.
fix(gForm): Add the form handle in the remaining message boxes in gForm
feat(dark): Implement Dark Mode in a new way with a bit of help from AI (thanks Jules!)
fix(files): Fix file structure
Create README.md


I hope you enjoy this release as much as I did! Thanks for your valuable feedback! :D

[tormento]

Also, I changed the TaskBar's progress bar to reflect the total progress, instead of each individual job's.
Finally on GitHub ;)

Could you implement a double progress bar, such as MakeMKV does, with file progress AND total progress?

Thank you!

[gpower2]

Finally on GitHub ;)

Could you implement a double progress bar, such as MakeMKV does, with file progress AND total progress?

Thank you!

In the main form, this is already implemented, I am not sure that such a feature exists for the Windows TaskBar progress bar...

[vertigo220]

Very nice. All welcome changes, and especially nice to see the move away from SourceForge. A brief test had the context menu opening immediately in dark mode with a bunch of files. I'll do more extensive testing in time, but definitely looks good. I'm curious, as I hadn't heard of Jules before and can see it's very new, and I'm always interested in this kind of thing: how was it? Do you see it, and other similar projects, making it significantly faster and easier to create and improve apps?

[gpower2]

Very nice. All welcome changes, and especially nice to see the move away from SourceForge.

Yeah, it was something I wanted to do for years, just didn't have the courage to perform the migration from SVN to Git in order to keep all the commits intact.
Again, the progress of the AI tools helped a lot ironing out various issues (the official guide from Github is missing some info for edge cases) and managed to do it.

A brief test had the context menu opening immediately in dark mode with a bunch of files. I'll do more extensive testing in time, but definitely looks good.

I've also tested it with a sample of 16k tracks, and it performed exactly the same with the light theme mode, so I am quite confident in this, it's nice to hear that it works for you as well!

I'm curious, as I hadn't heard of Jules before and can see it's very new, and I'm always interested in this kind of thing: how was it? Do you see it, and other similar projects, making it significantly faster and easier to create and improve apps?

This is a very big discussion :D

Jules is one of the many AI agents that appeared lately, it has the advantage of running the tasks in a cloud VM, so it doesn't use your local resources at all.
Regarding the general use of AI and the tools, IMHO, they are great for prototyping, so you can have a working prototype from an idea extremely fast and see if it works or not, and also for tedious tasks, like writing tests, or refactoring parts of the codebase, however, they still require to be reviewed and guided by senior engineers. I am afraid of the effect that these tools will have with junior engineers and also how much of their generated code will end up in production without being actually reviewed and tested...

To summarize, they are definitely a great tool, that can offer amazing results, but only if you know what you're actually doing...

[gpower2]

Hello guys!

It seems the "Github effect" worked and got the first valid issue, which is related to the very old code of the app init and the autodetection of the MKVToolnix path.

So a new release was published, v2.9.1

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.9.1/gMKVExtractGUI.v2.9.1.7z

Changelog

v2.9.1


fix(init): Revamped the init sequence for detecting the MKVToolnix path and added a new button to manually trigger the auto detect sequence.
fix(logs): Fix various logs in FrmMain2 and gMKVHelper.


Notes:

The priority for setting the MKVToolnix path during the app init is now the following:


Check for manual path set via cli arguments
Search in the .ini file for the MKVToolnix path
Search the current directory
For Windows: search the registry for an MKVToolnix installation
For Linux: seatch the usr/bin folder for MKVToolnix


Also, an "Auto Detect" button was detected, in order to easily reset the directory in case a manual override was added via the form.

As always, enjoy! :D

[JohnTHaller]

Hi all! Thought you'd like to know that I created a gMKVExtractGUI Portable (https://portableapps.com/apps/music_videos/gmkvextractgui-portable) package over at PortableApps.com after one of our users requested it. It's designed to be installed alongside MKVToolNix Portable (https://portableapps.com/apps/music_video/mkvtoolnix-portable) and will automatically configure itself to use it. Links back here for the homepage and to the Buy Me a Beer (https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YZZQZYL2Y6UNG) link for donations.

[gpower2]

Hello guys!

A new version is out, v2.10.0

The most notable change, is the bundling of the latest Newtonsoft.Json assembly, which increased the total size a bit.
Other than that, one small fix and one minor feature were added.

Also, there was some preparation work, for an overall refactoring I am planning, in order to bring the codebase to latest standards, since its age is showing...

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.10.0/gMKVExtractGUI.v2.10.0.7z

Changelog

v2.10.0


fix(ui): Show "Extraction completed!" message in the segment info text box instead of the label status, to avoid visual clatter (thanks @dclxvplusone)
feat(chapters): Add new PBF chapter type. It automatically transforms the default XML chapter type to the PBF chapter type. Comes with no guarantees, since documentation is basically non-existent
Reorganize and refactor various parts of the code. Switch to using Newtonsoft.Json via Nuget and update to latest version


As always, enjoy! :D

[oniiz86]

@gpower2 :thanks: so much for the recent updates to your wonderful software utility, is that a typo error in the latest v2.10.0 release, Show "Exctraction completed!" message, does it actually have the correct spelling of Extraction? :D

[gpower2]

Ah that's just the commit message 😁

In the app it remains correct 😉

https://github.com/Gpower2/gMKVExtractGUI/commit/10a845d0ee7d88014d3b15cae6bfd8d97a197f62

[Lathe]

Hello guys!

A new version is out, v2.10.0

The most notable change, is the bundling of the latest Newtonsoft.Json assembly, which increased the total size a bit.
Other than that, one small fix and one minor feature were added.

Also, there was some preparation work, for an overall refactoring I am planning, in order to bring the codebase to latest standards, since its age is showing...

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.10.0/gMKVExtractGUI.v2.10.0.7z

Changelog

v2.10.0


fix(ui): Show "Extraction completed!" message in the segment info text box instead of the label status, to avoid visual clatter (thanks @dclxvplusone)
feat(chapters): Add new PBF chapter type. It automatically transforms the default XML chapter type to the PBF chapter type. Comes with no guarantees, since documentation is basically non-existent
Reorganize and refactor various parts of the code. Switch to using Newtonsoft.Json via Nuget and update to latest version


As always, enjoy! :D

:thanks:

[sbrblz]

Hello, I have a question about tags. Is there a reason why they are not in the listing of things to extract such as the chapters file? I notice you have to change what to extract from tracks to tags, however there does not seem to be any way to customize the output file name like the other attachments. For batch extraction I have everything extract into a separate folder for each file with customized names, but the tags.xml file just keeps the default extracted name outside of the folders.

[gpower2]

Hello, I have a question about tags. Is there a reason why they are not in the listing of things to extract such as the chapters file? I notice you have to change what to extract from tracks to tags, however there does not seem to be any way to customize the output file name like the other attachments. For batch extraction I have everything extract into a separate folder for each file with customized names, but the tags.xml file just keeps the default extracted name outside of the folders.

Basically noone ever cared enough for tags in order to check them further.

Also, tags are not like chapters, they are not tracks of the matroska file, that's why they have different handling.

Indeed, I could add Options for the tags name, in order not to have them hardcoded and in order to be able to take advantage of the directory separator, would that be OK for you?

[sbrblz]

That would be great, that way I can keep all extracted files in their separate folders when doing batch extraction.

[gpower2]

OK, this was an easy implementation, so I added it https://github.com/Gpower2/gMKVExtractGUI/commit/279ced5ecb48ce5f3cc8250cab9c80f48c1fbad4

It will be included in the next release version. Thanks for the feedback! 🤗

[sbrblz]

Thank you! :)

[gpower2]

Hello everyone! :D

Happy August, with a happy new release! :D

This is a quite big release, since I refactored a lot of the core logic, preparing for the upgrade to a newer .NET Framework version, 4.7, which will also bring the end of support for Windows XP.
I know that some folks will not be happy about that, so I tried to tackle any remaining issues and feature requests in this version, so that Win XP users will have all the goodies and not feel left out.

Changelog is one of the biggest since the first release, containing new features, fixes and the huge refactoring of the core.
That means, that I may have introduced a regression bug, so if you notice anything out of place, please mention it here, or in Github, in order for me to tackle it ASAP.

Note: You can also create issues in the Github repo, in order to have better tracking and visibility. ;)

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.11.0/gMKVExtractGUI.v2.11.0.7z

Changelog

v2.11.0

feat: Add tooltips and an option to disable/enable them. Closes #21 (#24)
feat: Support checking/unchecking all Forced tracks per track type.
feat: Add support for the Forced track property. Closes #20
feat: Add option for overwriting existing files when extracting. This closes #18 (#19)
feat(tags): Add output filename options for tags. Closes #12
feat: Changed the output file extension for the OGM chapter type from "ogm.txt" to "txt" in the `gMKVToolNix.MkvExtract` namespace. Closes #4

fix(linux): Fix some more possible Linux issues with P/Invoke
fix(linux): correctly fix gRichTextBox issue in Linux
fix(linux): Fix some issues in Linux by excluding paths with P/Invoke.

docs: Enhance README and add docs folder with a basic User Manual

tests: Introduce Unit Tests and refactor part of the code for testability and performance (#11)

perf: Improve context menu creation
perf: Core refactor
Huge refactor of parsing state, practically making parsing stateless
Refactored the process output handling, by using List instead of StringBuilder to avoid splitting into individual line strings afterwards
Removed file existence checks for batch requests to minimize the IO operations
Various code optimizations in string operations
Various code formatting improvements
Refactor gMKVMerge, option handling and codec private data logic (#15)
Refactor gMKVInfo, fix typos and improve parsing (#14)
Refactor gMKVExtract and related components (#13)


As always, I hope you enjoy this release as much as I did! Thank you all for your valuable feedback! :D

[THGhost]

Having completely forgotten about the slow dark mode context menu issue, I came back here and to my delight it has now been fixed :D Thanks very much :thanks:

[gpower2]

Hello everyone! :D

A new bugfix version is out, thanks to @arestarh report!

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.11.1/gMKVExtractGUI.v2.11.1.7z

Changelog

v2.11.1


fix: Fix issue with Job manager when adding tracks that don't have CodecPrivate data, like PGS subs. thanks arestarh

[oniiz86]

@gpower2 :thanks: so much for the recent updates, I believe it should read v2.11.1 above as well as the home page, the changelog does not mention v2.11.1 for this small revision update. ;)

[gpower2]

@gpower2 :thanks: so much for the recent updates, I believe it should read v2.11.1 above as well as the home page, the changelog does not mention v2.11.1 for this small revision update. ;)

Thanks for the support and feedback! The typos were fixed! :D

[gpower2]

Hello everyone! :D

Happy new year, with a happy new release! :D

Some nice new functionalities were added, hopefully these will help some people who want more advanced options.

Note: You can also create issues in the Github repo, in order to have better tracking and visibility. ;)

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.12.0/gMKVExtractGUI.v2.12.0.7z

Changelog

v2.12.0

doc: Update the user manual with the new Advanced Options.
fix: The Defaults button in Options form now resets the new Advanced Options too.
feat: Add support for raw and fullraw track extraction modes. This closes #22 (#33)
feat: Add option to disable BOM for text files (v96.0+) #31 (#32)
fix: Fix key overrides of custom TextBox controls for Ctrl+A and Ctrl+C
fix: Changed txtLog to gRichTextBox and removed unused code
feat: Add a Select button that displays the Context Menu as another entry point for it. #27 (#30)
fix: fix MkvToolnixPath detection when Settings path is empty (#29) Thanks @lapluis


As always, I hope you enjoy this release as much as I did! Thank you all for your valuable feedback! :D

[Lathe]

Hello everyone! :D

Happy new year, with a happy new release! :D

Some nice new functionalities were added, hopefully these will help some people who want more advanced options.

Note: You can also create issues in the Github repo, in order to have better tracking and visibility. ;)

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.12.0/gMKVExtractGUI.v2.12.0.7z

Changelog

v2.12.0

doc: Update the user manual with the new Advanced Options.
fix: The Defaults button in Options form now resets the new Advanced Options too.
feat: Add support for raw and fullraw track extraction modes. This closes #22 (#33)
feat: Add option to disable BOM for text files (v96.0+) #31 (#32)
fix: Fix key overrides of custom TextBox controls for Ctrl+A and Ctrl+C
fix: Changed txtLog to gRichTextBox and removed unused code
feat: Add a Select button that displays the Context Menu as another entry point for it. #27 (#30)
fix: fix MkvToolnixPath detection when Settings path is empty (#29) Thanks @lapluis


As always, I hope you enjoy this release as much as I did! Thank you all for your valuable feedback! :D

Thanks for all your hard work Bro! :thanks:

[oniiz86]

@gpower2 Happy New Year & thanks so very much for the new update, it's a very welcome update indeed, one small thing the current version on the home page should read v2.12.0 :thanks:

[gpower2]

@gpower2 Happy New Year & thanks so very much for the new update, it's a very welcome update indeed, one small thing the current version on the home page should read v2.12.0 :thanks:

Damn, I totally forgot about that! 😅

Fixed now, thank you so much! 🤗

[shae]

What version (range) of mkvtoolnix is required?

Thanks for the tool!

[gpower2]

What version (range) of mkvtoolnix is required?

Thanks for the tool!

Hi Shae, gMKVToolix should work with any MKVoolnix version, even ancient ones like 4.0.0

If you find any issue with any version, please report it here or in Github and I'll check it

[gpower2]

Hello everyone! :D

I am happy to announce a new release! This is a quite big once, since it introduces a long requested feature: Localization.
gMKVExtractGUI finally supports multiple languages for the UI!
The translations are in separate json files, that are read in runtime, so I split them in a separate archive, in order to avoid adding more files for people who won't want them.
The current languages supported are en, es, de, pt, pt-br, fr, el, zh-cn, zh-tw, ja, ru, it, nl, pl, tr, ro, hi, and ko.

Disclaimer: the translations were made with the use of AI, so if something feels weird in your translation, please reach out to me in Github in order to fix it!

A new Translations form was also added and can be accessed via the Options form. That way, anyone can edit the translation files, or create their own!

Apart from the new localization feature, there were several performance improvements, mainly related to the asynchronous flows,
which should bring some noticeable performance gains in long running operations.


Note: You can also create issues in the Github repo, in order to have better tracking and visibility. ;)

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.13.0/gMKVExtractGUI.v2.13.0.7z
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.13.0/gMKVExtractGUI.locales.v2.13.0.7z

Changelog

v2.13.0


feat: Add localization feature (#39)

perf: Use typed synchronous extraction delegates in gMKVJob and gMKVExtract
perf: Remove DoEvents from SetTableLayoutMainStatus methods in main Form
perf: Replace task polling with continuation-based TPL in main Form.
perf: Replace thread polling with event-driven extraction completion
perf: Send async events for updating the progress and status fields in the forms.

fix(dark): Fix scrollbars in dark mode for RichTextBox.
fix(dark): Fix buttons light mode theming when switching from dark to light mode during runtime.
fix(dark): Fix status strip in dark mode for Mono runtime

fix: Fix gform DPI autoscaling and force initial DPI scaling on Mono in gForm.InitDPI. References issues #36 #41 (#42)

chore: Sanitize all files with the same line endings (CRLF) and encoding (UTF-8 without BOM) for consistency
chore: Fix public API of gMKVToolnix sevices


As always, I hope you enjoy this release as much as I did! Thank you all for your valuable feedback! :D

[Lathe]

Hello everyone! :D

I am happy to announce a new release! This is a quite big once, since it introduces a long requested feature: Localization.
gMKVExtractGUI finally supports multiple languages for the UI!
The translations are in separate json files, that are read in runtime, so I split them in a separate archive, in order to avoid adding more files for people who won't want them.
The current languages supported are en, es, de, pt, pt-br, fr, el, zh-cn, zh-tw, ja, ru, it, nl, pl, tr, ro, hi, and ko.

Disclaimer: the translations were made with the use of AI, so if something feels weird in your translation, please reach out to me in Github in order to fix it!

A new Translations form was also added and can be accessed via the Options form. That way, anyone can edit the translation files, or create their own!

Apart from the new localization feature, there were several performance improvements, mainly related to the asynchronous flows,
which should bring some noticeable performance gains in long running operations.


Note: You can also create issues in the Github repo, in order to have better tracking and visibility. ;)

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.13.0/gMKVExtractGUI.v2.13.0.7z
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.13.0/gMKVExtractGUI.locales.v2.13.0.7z

Changelog

v2.13.0


feat: Add localization feature (#39)

perf: Use typed synchronous extraction delegates in gMKVJob and gMKVExtract
perf: Remove DoEvents from SetTableLayoutMainStatus methods in main Form
perf: Replace task polling with continuation-based TPL in main Form.
perf: Replace thread polling with event-driven extraction completion
perf: Send async events for updating the progress and status fields in the forms.

fix(dark): Fix scrollbars in dark mode for RichTextBox.
fix(dark): Fix buttons light mode theming when switching from dark to light mode during runtime.
fix(dark): Fix status strip in dark mode for Mono runtime

fix: Fix gform DPI autoscaling and force initial DPI scaling on Mono in gForm.InitDPI. References issues #36 #41 (#42)

chore: Sanitize all files with the same line endings (CRLF) and encoding (UTF-8 without BOM) for consistency
chore: Fix public API of gMKVToolnix sevices


As always, I hope you enjoy this release as much as I did! Thank you all for your valuable feedback! :D

Thanks for all the hard work Bro! :thanks:

[manolito]

Thanks so much gpower2, this update is amazing ... :thanks:

Made a couple of short tests, everything seems to work just fine. I also used the German translation, it is just amazing (sometimes frightening) what KI can do these days. Very impressive.

I only found a minor glitch with the translation of "drag and drop" to "Drag & Drop". The "&" character is just omitted in the translation. (Win7 64bit, the standard Unicode character set). I was unable to fix it directly, so I just replaced it with "Drag and Drop" which works fine. I am not really experienced with Unicode, so it may all be my fault...

Whatever, thanks again, I really appreciate your work.


Cheers
manolito

[Lathe]

Thanks so much gpower2, this update is amazing ... :thanks:

Made a couple of short tests, everything seems to work just fine. I also used the German translation, it is just amazing (sometimes frightening) what KI can do these days. Very impressive.

I only found a minor glitch with the translation of "drag and drop" to "Drag & Drop". The "&" character is just omitted in the translation. (Win7 64bit, the standard Unicode character set). I was unable to fix it directly, so I just replaced it with "Drag and Drop" which works fine. I am not really experienced with Unicode, so it may all be my fault...

Whatever, thanks again, I really appreciate your work.


Cheers
manolito

I'm sorry, but I'm not fully clear on what the 'Translation' thing does...? Does it translate subtitles into another language or what?

Thanks!

[manolito]

It translates the User Interface...

I am happy to announce a new release! This is a quite big once, since it introduces a long requested feature: Localization.
gMKVExtractGUI finally supports multiple languages for the UI!
The translations are in separate json files, that are read in runtime, so I split them in a separate archive, in order to avoid adding more files for people who won't want them.
The current languages supported are en, es, de, pt, pt-br, fr, el, zh-cn, zh-tw, ja, ru, it, nl, pl, tr, ro, hi, and ko.

[Lathe]

It translates the User Interface...

Oh, of course, thanks mate!

[magic144]

when i click the Translations... button, i just get the popup error (see attached image - "An error has occurred! Object reference not set to an instance of an object.") - with or without the json files present

what is going wrong?

FYI i have MKVToolNix GUI v98.0 installed

DotNetVersions reports this info for my W11 Home (25H2 Build 26200.8457) x64 system:

C:\Users\User\Desktop\DotNetVersions>DotNetVersions.exe
Currently installed "classic" .NET Versions in the system:
2.0.50727.4927 Service Pack 2
3.0.30729.4926 Service Pack 2
3.5.30729.4926 Service Pack 1
4.0.0.0
4.8.09221

[gpower2]

when i click the Translations... button, i just get the popup error (see attached image - "An error has occurred! Object reference not set to an instance of an object.") - with or without the json files present

Hello!

Can you please paste the logs from the Logs form here? Unfortunately this error is too generic to pinpoint its cause since I can not reproduce it locally...

[magic144]

sure! - didn't see that

here's the log

[2026-05-19][16:29:57] Detected settings path: C:\Users\User\AppData\Roaming\Gpower2\gMKVExtractGUI\2.13.0.0
[2026-05-19][16:29:57] Begin loading settings...
[2026-05-19][16:29:57] Finished loading settings!
[2026-05-19][16:29:58] System.NullReferenceException: Object reference not set to an instance of an object.
at gMKVToolNix.Forms.frmTranslationEditor.ApplyResponsiveLayout()
at System.Windows.Forms.Control.OnSizeChanged(EventArgs e)
at System.Windows.Forms.Control.UpdateBounds(Int32 x, Int32 y, Int32 width, Int32 height, Int32 clientWidth, Int32 clientHeight)
at System.Windows.Forms.Control.UpdateBounds(Int32 x, Int32 y, Int32 width, Int32 height)
at System.Windows.Forms.Control.SetBoundsCore(Int32 x, Int32 y, Int32 width, Int32 height, BoundsSpecified specified)
at System.Windows.Forms.Form.SetBoundsCore(Int32 x, Int32 y, Int32 width, Int32 height, BoundsSpecified specified)
at System.Windows.Forms.Control.ScaleControl(SizeF factor, BoundsSpecified specified)
at System.Windows.Forms.ScrollableControl.ScaleControl(SizeF factor, BoundsSpecified specified)
at System.Windows.Forms.Form.ScaleControl(SizeF factor, BoundsSpecified specified)
at System.Windows.Forms.Control.ScaleControl(SizeF includedFactor, SizeF excludedFactor, Control requestingControl)
at System.Windows.Forms.ContainerControl.Scale(SizeF includedFactor, SizeF excludedFactor, Control requestingControl)
at System.Windows.Forms.ContainerControl.PerformAutoScale(Boolean includedBounds, Boolean excludedBounds)
at System.Windows.Forms.ContainerControl.PerformNeededAutoScaleOnLayout()
at System.Windows.Forms.Form.OnLayout(LayoutEventArgs levent)
at System.Windows.Forms.Control.PerformLayout(LayoutEventArgs args)
at System.Windows.Forms.ContainerControl.LayoutScalingNeeded()
at System.Windows.Forms.ContainerControl.set_AutoScaleMode(AutoScaleMode value)
at gMKVToolNix.gForm..ctor()
at gMKVToolNix.Forms.frmTranslationEditor..ctor(String initialCulture, Boolean skipRuntimeInitialization)
at gMKVToolNix.Forms.frmOptions.btnTranslationEditor_Click(Object sender, EventArgs e)

[magic144]

Hello!

Can you please paste the logs from the Logs form here? Unfortunately this error is too generic to pinpoint its cause since I can not reproduce it locally...

was the previous info i provided enough to tell you what is broken - or can i provide some more detail (if so what/how)?

[oniiz86]

@magic144 It may be best to address your concerns & open an issue here https://github.com/Gpower2/gMKVExtractGUI/issues as I believe @gpower2 will most probably respond more promptly over at github although he has also been fantastic here too when one has any issues that would like to be addressed. :)

[magic144]

ok thanks

i've opened the issue here
https://github.com/Gpower2/gMKVExtractGUI/issues/51

[gpower2]

Sorry guys, I was too busy the past few weeks, I've committed 2 fixes regarding the Translations Editor, if I don't find anything else to commit/fix, I will probably publish a new version later today. 🙏

Thanks for the feedback! 🤗

[gpower2]

Hello everyone! :D

Summer is here and with that, a new release!

This is mainly a bug fix release, hopefully tackling an especially nasty one regarding high DPI windows.

Note: You can also create issues in the Github repo, in order to have better tracking and visibility. ;)

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.14.0/gMKVExtractGUI.v2.14.0.7z
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.14.0/gMKVExtractGUI.locales.v2.14.0.7z

Changelog

v2.14.0


chore(localization): refine Simplified Chinese translations by @ambitiuswisdom in #46

fix: Add guard to ApplyResponsiveLayout for early resize safety. Fixes #51
fix: Fix translation grid cell commit logic in order to avoid overwriting the whole translation text per key stroke. Fixes #45
fix: Fix HighDPI mode for Windows by querying during start up and selecting the best mode available for the current Windows version. Fixes #36


As always, I hope you enjoy this release as much as I did! Thank you all for your valuable feedback! :D

[magic144]

Thanks! Error has gone in 2.14.0 :)

[gpower2]

Hello everyone! :D

A new release that fixes a lot of High DPI issues!
Also, we have the first new translations contributor, JohnFowler58 was kind enough to contribute the Hungarian locale!

Note: You can also create issues in the Github repo, in order to have better tracking and visibility. ;)

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.15.0/gMKVExtractGUI.v2.15.0.7z
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.15.0/gMKVExtractGUI.locales.v2.15.0.7z

Changelog

v2.15.0


feat: Add Hungarian language file by @JohnFowler58 in #52
fix(dpi): Fix issues with dpi scaling and responsive layout. Fix the DPI change when switching screens in real time. by @Gpower2 in #56


As always, I hope you enjoy this release as much as I did! Thank you all for your valuable feedback! :D

[Columbo]

Looking great over here. :thanks:

[Lathe]

Hello everyone! :D

A new release that fixes a lot of High DPI issues!
Also, we have the first new translations contributor, JohnFowler58 was kind enough to contribute the Hungarian locale!

Note: You can also create issues in the Github repo, in order to have better tracking and visibility. ;)

Download link:
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.15.0/gMKVExtractGUI.v2.15.0.7z
https://github.com/Gpower2/gMKVExtractGUI/releases/download/v2.15.0/gMKVExtractGUI.locales.v2.15.0.7z

Changelog

v2.15.0


feat: Add Hungarian language file by @JohnFowler58 in #52
fix(dpi): Fix issues with dpi scaling and responsive layout. Fix the DPI change when switching screens in real time. by @Gpower2 in #56


As always, I hope you enjoy this release as much as I did! Thank you all for your valuable feedback! :D

Thank you! :thanks: