gMKVExtractGUI [Archive] - Page 8

manolito

14th October 2018, 23:26

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

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

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

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

Cheers
manolito

x3inspire

15th October 2018, 08:18

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

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

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

hello_hello

15th October 2018, 12:40

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

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

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

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

hello_hello

15th October 2018, 13:48

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

the _eng_ not detect by mkvtoolnix 27 only [eng]

example 1: music_track1_chi_DELAY 30ms.aac not detect language

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

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

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

gpower2

15th October 2018, 16:45

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

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

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

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

Cheers
manolito

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

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

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

Thanks.

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

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

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

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

videoh

15th October 2018, 18:46

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

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

manolito

15th October 2018, 19:30

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

:thanks:

Intervencion

19th October 2018, 02:29

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

gpower2

27th October 2018, 10:12

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

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

Changelog:

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

As always, enjoy people! :D

manolito

27th October 2018, 11:43

Working nicely, thanks... :thanks:

Intervencion

27th October 2018, 11:45

Same :thanks: Working at 100%

tormento

1st November 2018, 18:11

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

drako

9th November 2018, 20:21

Dear gpower2,

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

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

Could this just be happening on my system?

Thanks!

gpower2

11th November 2018, 13:53

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

Csimbi

15th November 2018, 09:40

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

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

Thank you!

dissory

17th November 2018, 07:48

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

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

girod2033

21st November 2018, 09:29

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

Perenista

16th December 2018, 17:05

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

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

Any ideas?

gpower2

16th December 2018, 17:12

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

tormento

18th January 2019, 17:34

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

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

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

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

Overdrive80

2nd February 2019, 13:51

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

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

gpower2

3rd February 2019, 12:30

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

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.4.1/gMKVExtractGUI.v2.4.1.7z/download

Changelog:

Fix attachment extraction

Enjoy people! :D

Overdrive80

5th February 2019, 12:57

Thanks for fixing it.

tormento

6th February 2019, 14:53

Hi everyone, time for a small fix version
Did you read my bug report?

gpower2

6th February 2019, 18:53

Hi tormento,

Are you using latest version of gMKVExtractGUI?
I believe that mkvinfo is not being used after v1.9.0 or something like that, so it is really curious that you see mkvinfo.exe hanged.
Have you tried waiting for mkvinfo to finish?

EDIT: I think I found what is happening here... gMKVExtractGUI attempts to find the track delays, assuming the video track as an anchor.
However, there is no such need in matroska files that don't contain any video tracks. New version coming soon...

EDIT2: New version is up! I think that the issue is now fixed! Thanks for your feedback! :)

Download link:
https://sourceforge.net/projects/gmkvextractgui/files/v2.4.2/gMKVExtractGUI.v2.4.2.7z/download

Changelog

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

manolito

7th February 2019, 16:13

Thanks gpower for the continuing work on the software, since the old MKVExtractGUI2 is no longer maintained your MKVExtractGUI is pretty much the only game in town... :D

Talking about track delays one of the differences to the old GUI is that your software determines the delays and writes the audio delay value into the extracted audio file name. And this feature keeps confusing me over and over.

I am used to how this works for MPEG2 files. Demux the file with DGIndex, the delay value gets written into the file name. Remuxing this audio file with the M2V video track (using MuxMan or Cuttermaran) the audio delay is read from the file name, and the muxing process honors this delay value. This results in a new MPEG2 file in perfect sync.

With gMKVExtractGUI and MKVToolnix this is very different. The delay value is also written into the extracted audio file name, and when remuxing this audio track into a new MKV using MKVMerge the delay value is also detected and honored in the muxing process. BUT THIS IS WRONG. The resulting MKV will be out of sync.

To get a new MKV without sync problems the audio delay value needs to be ignored. Either set the delay to 0 in the MKVToolnix GUI, or remove the delay value from the audio track name.

Do you have an explanation for this? Could it be that mkvextract.exe corrects any delays before extracting tracks?

Cheers
manolito

gpower2

7th February 2019, 16:56

Hi manolito, thanks for your kind words, I really appreciate it! :)

As for the delays, it's been thoroughly discussed in this thread, the effective delay is required in order to re-merge the tracks and be in sync with each other. ;)

manolito

7th February 2019, 20:16

As for the delays, it's been thoroughly discussed in this thread, the effective delay is required in order to re-merge the tracks and be in sync with each other. ;)

Sorry, I have not followed these thorough discussions, but I do disagree.

Please have a look at this file:
https://www.sendspace.com/file/dsauzo

It is a real world DVB-T2 captured clip, I deal with such clips every day. It comes in an MTS container, I repacked it to MKV using the latest MKVToolnix. It has a huge audio delay, but it plays in perfect sync in all my software players.

Next thing I did was extracting the audio track with gMKVExtractGUI. The filename of the extracted track was "test_track2_[mis]_DELAY -1446ms.aac". Then I remerged this extracted audio file into the original MKV. In my uploaded MKV this remerged audio track appears as audio track #2. Now please play this file in any software player which allows to switch audio tracks during playback. What do you think about the audio sync for track #2?

Sorry I only found a German channel where lip sync can be judged, but I think you can get the idea without speaking German. For the files I regularly work with the audio delay feature in gMKVExtractGUI does not work, I always need to turn it off.

Cheers
manolito

Mosu

7th February 2019, 20:53

Sounds like the -1446ms might have to be 1446ms.

manolito

7th February 2019, 21:47

No, that's not it. To get the correct audio sync the delay has to be 0.

mkver

7th February 2019, 23:07

The second audio track (track #3) starts at 5ms, the first audio track (track #2) at 65ms. The first video keyframe has a timestamp of 1571ms, the lowest video frame has a timestamp of 1511ms (this file uses open GOP). If you extracted both track #2 and track #1 (the video) and muxed it back with mkvmerge, mkvmerge would give the lowest video frame a timestamp of 0ms and the first video keyframe a timestamp of 60ms. This is a difference of 1511ms; in order to keep AV sync, you would have to offset the audio by 1511ms, too; extracting audio to elementary streams makes it loose its initial delay (here 5ms and 65ms) which already amounts to subtracting 5ms resp. 65ms from the audio tracks. So you would have to subtract a further 1511ms - 65ms from track #3. But this is only true if you actually extracted both audio and video and remuxed the elementary tracks -- your comment seems as if you didn't extract the video at all.
Btw: Why extract the tracks to elementary tracks at all? If you have transmission errors (and therefore missing packets), you will loose A/V sync no matter whether the initial offsets were right.

manolito

8th February 2019, 15:24

Thanks mkver for the detailed analysis, but this is not really my point...

The average user will not have such analysis skills (I certainly don't), and we have software like mkvextract and mkvmerge to do this automatically. This is all I am asking for.

You are correct, I did not extract the video track at all, I just extracted the audio track and remuxed it into the source MKV. And this resulted in the sync error. I just tried again and extracted both the video and audio tracks, then imported both tracks into MKVMerge to create a new MKV. And yes, this time the only way to avoid sync errors was to honor the audio delay for the muxing process. So it does make a difference if I add an audio track with a delay to an already existing MKV with a video track, or if I create a brandnew MKV with video and audio tracks. Weird, and basically I do not want to deal with this.

The reason why I need to extract the audio track(s) from the source MKV is that I use StaxRip (an older 32-bit version) to recode the HD source HEVC / AAC-LATM (or E-AC3) into an SD AVC / AAC file. And StaxRip processes the audio separately from the video, and the extracted audio always needs to be decompressed to PCM first to make frame accurate editing possible.

And if the captured source has transmission errors, you do have a point. If I have repacked a captured MTS file to MKV first and there are glitches in this file, I will loose audio sync. But by trial and error I found out that this does not happen if I use the original MTS or TS as the source for StaxRip. My source filter is DSS2Mod, and when the source has transmission errors and I use the original Transport Stream as the source then I will see the broken frames, but sync is maintained.

Using the original Transport Stream as the source has its problems, though, and I try to avoid it when I can. Editing out commercials is a major PITA when using HEVC Transport streams, seeking the desired frame by stepping through the frames always brings up corrupt frames because the next I-Frame cannot be found. After repacking the source to MKV these problems disappear completely.

Luckily transmission errors are very rare for me with the DVB-T2 format. I always use TSDoctor to check for transmission errors, and about 95% of my captures are error-free.

Cheers
manolito

mkver

9th February 2019, 01:14

The average user will not have such analysis skills (I certainly don't), and we have software like mkvextract and mkvmerge to do this automatically. This is all I am asking for.

The software can't read your mind, but what could be done is that if a Matroska file has a video track and you select to not extract the video track, then the delay that is put into the filenames should not be calculated as if the video started with 0, but rather as if the video timestamps were unchanged (in your example, the delay that would be put in the filenames would be 5ms and 65ms). You may ask gpower2 about it; but who knows: Maybe someone else would call the behaviour just proposed weird.
(And what should happen when there is more than one video track? I don't know.)

There is BTW a second workaround for you that is only applicable when your recording contains a few seconds at the beginning that you want to discard (there needs to be a complete GOP at the beginning that you don't want to keep). When you initially remux from ts to mkv, you can let mkvmerge split by parts based on timestamps in order to discard the very beginning. The lowest timestamp of the main video track will then be zero (for each part). So the problem you encountered here doesn't happen for such files.

The reason why I need to extract the audio track(s) from the source MKV is that I use StaxRip (an older 32-bit version) to recode the HD source HEVC / AAC-LATM (or E-AC3) into an SD AVC / AAC file. And StaxRip processes the audio separately from the video, and the extracted audio always needs to be decompressed to PCM first to make frame accurate editing possible.

I don't use StaxRip, but keep in mind that StaxRip may add confusion of its own to the offsets. (I.e. does StaxRip even care about the offset in the input file (namely that the first video track doesn't start at zero?)? How does it handle the fact that the lowest video timestamp belongs to an undecodable frame (one of the B-frames shared between GOPs?)?)

If I have repacked a captured MTS file to MKV first and there are glitches in this file, I will loose audio sync. But by trial and error I found out that this does not happen if I use the original MTS or TS as the source for StaxRip. My source filter is DSS2Mod, and when the source has transmission errors and I use the original Transport Stream as the source then I will see the broken frames, but sync is maintained.
Newer versions of mkvmerge discard whole PES packets when mkvmerge detects any errors (by looking at the continuity counter). This might explain your observation. The last version that didn't do this was AFAIK 19.0.

manolito

9th February 2019, 16:20

The software can't read your mind

It does not have to. All I would like to see is a behavior which is consistent with the behavior of other software for the identical task.

Let's not talk about the peculiarities of captured transport streams, let's also forget about StaxRip. Let's break it down to a very common task which I need to perform frequently (and other users probably too).

I have a clip in an MKV container, MediaInfo reports a certain audio delay. I need to "beautify" the audio. So I need to extract the audio track, decompress to WAV, do all my nasty tricks in WaveLab (or any advanced WAVE editor), save the WAV and convert it to AAC. The last step is to import this audio track into the original MKV, disable the original audio track and remux it into a new MKV. Very simple...

If I do this using gMKVExtractGUI and MKVToolnixGUI then the result will be out of sync, because the audio delay value is written into the file name of the extracted audio track. All following operations will preserve the filename with the embedded delay value. Remerging it back into the original MKV will honor the delay value, and this results in a sync error.

I will not get sync problems if I use FFmpeg or AviDemux for this task. The reason is simple, this other software does not care for audio delay values. Remuxing the "beautified" audio back into the original MKV will give out a new MKV in perfect sync.

So all I am asking for is consistent behavior. It is too bad that Pashin stopped maintaining his MKVExtractGUI2 software, IIRC the last supported MKVToolnix version was v. 20.

Cheers
manolito

gpower2

9th February 2019, 16:46

It does not have to. All I would like to see is a behavior which is consistent with the behavior of other software for the identical task.

Let's not talk about the peculiarities of captured transport streams, let's also forget about StaxRip. Let's break it down to a very common task which I need to perform frequently (and other users probably too).

I have a clip in an MKV container, MediaInfo reports a certain audio delay. I need to "beautify" the audio. So I need to extract the audio track, decompress to WAV, do all my nasty tricks in WaveLab (or any advanced WAVE editor), save the WAV and convert it to AAC. The last step is to import this audio track into the original MKV, disable the original audio track and remux it into a new MKV. Very simple...

If I do this using gMKVExtractGUI and MKVToolnixGUI then the result will be out of sync, because the audio delay value is written into the file name of the extracted audio track. All following operations will preserve the filename with the embedded delay value. Remerging it back into the original MKV will honor the delay value, and this results in a sync error.

I will not get sync problems if I use FFmpeg or AviDemux for this task. The reason is simple, this other software does not care for audio delay values. Remuxing the "beautified" audio back into the original MKV will give out a new MKV in perfect sync.

So all I am asking for is consistent behavior. It is too bad that Pashin stopped maintaining his MKVExtractGUI2 software, IIRC the last supported MKVToolnix version was v. 20.

Cheers
manolito

I am sorry manolito, but if your usage scenario involves reencoding the extracted audio track, then it certainly can involve renaming the file!

Extracting audio tracks with the exact delay is and will stay the default action since if this information is lost, then the user can't re-merge the original tracks without losing sync.
If someone uses the extracted track for something more complicated than that, then simply renaming the extracted track's filename will suffice.

In the next version, I will add a custom filename creation mode, in order for the user to choose how the extracted filenames are generated.
I guess you can then change the filename generation rule and your problem will be solved. ;)

manolito

9th February 2019, 17:04

Yes, this will certainly solve it for me... :thanks:

dissory

9th February 2019, 17:24

Hi gp2, had a few suggestions if you don't mind:

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

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

Csimbi

10th February 2019, 09:43

gpower2

10th February 2019, 11:49

Hi gp2, had a few suggestions if you don't mind:

Pretty please? ;-)

Hopefully all the above will be addressed with the new version. However, it's not going to be released soon, since my job is keeping me really busy...

tormento

26th March 2019, 17:18

EDIT2: New version is up! I think that the issue is now fixed! Thanks for your feedback! :)
:thanks:

airium

19th April 2019, 09:04

This is a wonderful software but only one thing. I am wondering if you don't mind to add the utility to automatically create the destination folder if not existing? For people who use a fixed folder, it's a little annoying being warned about "not exist" and manually navigating and creating it. Many thanks if you could implement it for the minority.

Update: Thanks. No need to bother any more. I already had a look at the source code and manually changed it to automatically create the output dir without warning.

an3k

17th May 2019, 17:48

Hey gpower2, thanks for the great tool. I love it extracts chapters too! I noticed that there isn't an option for mkvextract --raw so that video streams are extracted to the raw format rather than .avi (at least for vc1 streams).

Could you add that option please? Maybe with the --fullraw if that is of use at all. Thank you very much! :)

johnsonlam

23rd May 2019, 16:48

Thank you very much! I like your program, simple and easy, it really help!

gpower2

12th June 2019, 19:59

Hey guys! I managed to find the time and refactor the inner works for the output filename generation, so that it can now be customizable!
I added a new Options form which can be accessed from a new button located at the bottom of the main form.
I also added some small features that were requested over time and made some changes in the form's controls.

Enjoy people! :D

Changelog

v2.5.0

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