gMKVExtractGUI

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