gMKVExtractGUI

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