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.14.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.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. :)