gMKVExtractGUI v2.6.4

[johnsonlam]

Hi,

Thanks gpower2 for your great GUI!

[hello_hello]

Originally Posted by gpower2

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:

Originally Posted by hello_hello

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.

Originally Posted by hello_hello

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.

Originally Posted by hello_hello

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.

Originally Posted by hello_hello

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.

Originally Posted by hello_hello

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.

Originally Posted by hello_hello

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]

Originally Posted by gpower2

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

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

Originally Posted by gpower2

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.

Originally Posted by gpower2

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!

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]

Originally Posted by 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.

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.

Originally Posted by hello_hello

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 )

Originally Posted by hello_hello

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]

Originally Posted by gpower2

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.

Originally Posted by gpower2

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

[gpower2]

Originally Posted by hello_hello

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!

Originally Posted by hello_hello

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]

Originally Posted by gpower2

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]

Originally Posted by hello_hello

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

Originally Posted by hello_hello

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

Originally Posted by hello_hello

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.

Originally Posted by sneaker_ger

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]

Originally Posted by gpower2

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]

Originally Posted by sneaker_ger

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

Originally Posted by hello_hello

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.