MKVToolNix v24.0.0 released

[Mosu]

I've opened issue 1405 (https://github.com/mbunkus/mkvtoolnix/issues/1405) for this.

[Boulder]

I just noticed a small annoyance with the job queue: mark all jobs to "start automatically", it also runs the jobs that were already finished. After that, it's not very straightforward how to abort the jobs : you have to mark them to "start manually" and then abort the current job. Maybe the commands could be a bit more descriptive?

[Mosu]

You could have chosen »stop the job queue« from the »job queue« menu. The context menu is used for manipulating one or more jobs, the »job queue« menu is used for manipulating the whole queue/the process, basically things that are independent of the currently selected jobs.

[Boulder]

Gah, missed that one :( I tried nearly every other place but couldn't find a way to stop the queue..

Is it possible to start the selected pending jobs or will the option run all of them?

[Mosu]

About job statuses and the various actions.

(A) Status and context menu action »Start automatically«

Any job entered into the queue with status »start automatically« will be started automatically, but at most one job will be running simultaneously. This means if the queue is currently not running then the newly-added job will be started immediately. Otherwise it will be enqueued and run after all the other jobs in the queue with status »start automatically« have been completed.

Jobs will only have a status of »start automatically« if you either submit them from the merge tool with »start muxing« or if you select »start jobs automatically« from the context menu in the job queue tool.

(B) Status and context menu action »Start manually«

Jobs marked as »start manually« will remain in the queue but won't be started unless you, the user, tells the program to do just that. There are two ways for accomplishing this:

Select a couple of jobs in the job queue tool, open the context menu and choose »start jobs automatically«. This will set their status to »start automatically« and they'll be processed as laid out in (A).
Go to the job queue tool, open the »job queue« menu and select »start all pending jobs«. This changes the status of all jobs whose current status is »start manually« to »start automatically«. Then they're processed as laid out in (A).

(C) Context menu action »Start immediately«

This is not a job status per se, but it is an action available in the job queue's context menu. This starts the selected jobs immediately, no matter if there's a job running already. This allows the number of simultaneously running jobs to exceed 1.

Note that as long as at least one job is running no other jobs marked »start automatically« will be started. For example, if you have three jobs in the queue, one currently running, and two set to »stat automatically«. Now you select one of those two marked as »start automatically« and select »start jobs immediately«. This changes the queue to two jobs running, one job still in »start automatically«. Now when one of those running jobs finishes the programm will not start that other job that's still set to »start automatically« as it still has one job running. Only after that second runnig job has finished will the final pending job be started.

(D) Job queue menu action »Start all pending jobs«

This is described in section (B).

(E) Job queue menu actions »Stop job queue«

Choosing one of those two options in the »stop job queue« sub-menu causes all jobs set to »start automatically« to be changed to »start manually«. That way they won't get executed by the GUI unless you tell it to; see (B).

The difference between the two available options is how a potentially running job is handled. In case of »abort current job and stop immediately« the currently running job will be aborted, otherwise it will be left running. Note that aborthing the job will leave it in state »aborted by user«; it won't be re-started unless you tell the program so (via one of the the »start jobs …« context menu actions).

I will put this explanation into a Wiki/FAQ entry as well; it will probably be needed again.

[Mosu]

So if you mean »start only those jobs that I have currently selected AND whose current status us 'start manually'« then no, that's not possible. Either shrink your selection to the jobs you want to start and use the »start jobs automatically« context menu entry (which disregards the job's current status unless it's running) or select »start all pending jobs« from the »job queue« menu which will not pay any heed to the selection and act on all jobs in the queue with status »start manually«.

[Boulder]

So if you mean »start only those jobs that I have currently selected AND whose current status us 'start manually'« then no, that's not possible. Either shrink your selection to the jobs you want to start and use the »start jobs automatically« context menu entry (which disregards the job's current status unless it's running) or select »start all pending jobs« from the »job queue« menu which will not pay any heed to the selection and act on all jobs in the queue with status »start manually«.Thanks for the thorough explanation :)

OK, will use the "start jobs automatically" operation in such cases. Fortunately I rarely need to do that, sometimes I just have the need to remux a few files in case a new subtitle track is included.

[Mosu]

OK - I figured out the issue - it's because I have "Remove job from queue after completion" checked, it must be getting removed from the calculation as well.

This bug should be fixed now. Pre-builds 876, 877 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/) include the fix.

[bartonnen]

This bug should be fixed now. Pre-builds 876, 877 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/) include the fix.

Thanks :)

[73ChargerFan]

New Windows 7 SP1 install, v 8.3.0, new GUI (which I really like, thanks.)

1. Minor bug: in Preferences-Merging-Output file name I have set "Automatically set" and "Previously used output directory". But on every job I create, the automatic output file name is always Drive E, which isn't even in my computer.

2. After getting 2 jobs entered, I select "start automatically". Then while they're working, I create new jobs and add them to the queue, but they get flagged "waiting to start manually". I'd be nice to have a setting so that enqueued jobs always start automatically.

3. Feature Request (as if you had time): Ask madshi for his eac3to code for dealing with HD-DVD files, which can determine languages and extract chapters. I've got almost 300 such disks to finally convert... Maybe it is easy? I'll add this to your tracker.

4. Comment: Windows paths use \ not the / that Linux does. Looks confusing, but I can deal. Perhaps this is a compile time setting in the GUI library?

The new GUI really is nice, and the progress indicators are well placed.

[Mosu]

1. Sounds like a bug. I'll have to investigate.
2. No, because there's such functionality already: »start muxing«. »Add to job queue« will always add them with status »start manually« and »start muxing« will always add them with status »start automatically«. See this explanation of how the queue works (https://github.com/mbunkus/mkvtoolnix/wiki/The-job-queue,-statuses-and-their-actions).
3. I won't spend any time on the outdated and abandoned technology HD-DVD. Sorry.
4. Windows can handle both / and \ in paths just fine. Therefore I haven't bothered to adjust the code to make sure that the usual path separator is used everywhere. It's not just a compile time switch, it's code changes in every place a path is output for the user to see. As Windows has no problems with / in paths I won't spend any time on this any time soon either.

[Mosu]

About the output directory setting: I can reproduce such behavior, but only if I edit the output name manually. If, however, I use the »browse« functionality next to it then the new location is remembered just as I expect it to be. I'll fix the handling of manual changes to the output file name.

[Jamaika]

Can I save the image as the first frame of the container matroska? Is there a hidden function?
http://i61.tinypic.com/xlfbee.jpg
Can I import and cut a timestamp for Sony XAVC NonRealTimeMeta?
Media Info: Language "und (und)" - Type "meta:rtmd" - 240 samples
Unknown Metadata Stream
RFC6381 Codec Parameters: rtmd
All samples are sync

[Mosu]

Uhm… What now? I'm sorry, but I completely fail to understand your questions.

[Mosu]

No to the first question. As for the second question: if you could embed such data in Matroska I'm certain your Sony couldn't read them. No as well here.

[Jamaika]

Thanks for your reply. All understandable. More and more is the Sony camcorder in the world so think that the theme is coming back for some time.;)
https://www.youtube.com/watch?v=ZpWI-7DAC4s

[KoD]

Hi Mosu, I'm either doing something wrong, or I discovered an issue in the mkvtoolnix GUI chapter editor. After loading a chapter file, selecting "Additional modifications -> Shift start and end timecodes by the following amount" on a chapter entry in the editor, does not seem to do anything.

For example, loading a txt file with this content in the chapter editor, and then trying to shift the first chapter by "-00:01:41.518" or "00:01:41.518" does nothing, the chapter start and end timestamps in the editor remain unchanged:
CHAPTER01=00:00:00.000
CHAPTER01NAME=Chapter 01
CHAPTER02=00:01:41.518
CHAPTER02NAME=Chapter 02
CHAPTER03=00:08:50.905
CHAPTER03NAME=Chapter 03
CHAPTER04=00:11:49.291
CHAPTER04NAME=Chapter 04
CHAPTER05=00:20:46.203

PS: multi-selection of chapter entries, to be able to shift them all at the same time would be much appreciated too! :)

[Mosu]

All those modifications only work on the children of the selected node. Shifting only a single chapter entry is therefore not possible.

Having multi-selection enabled for chapters is not currently on my TODO list as it's quite a lot of work to get right.

Sorry.

[KoD]

Ok, I understand.

Is it supposed to work on the root "Edition" entry in the chapter editor, too? Because it did not work on it either, the child chapters were not shifted.

[Mosu]

Huh… You're right, it doesn't work at the moment. That's obviously a bug. I'll fix it.

[KoD]

That's great! Thanks! :)

[Mosu]

Should be fixed in pre-builds 884 & 885 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/). I'd appreciate some testing.

Yes, it's supposed to work on the edition, too (well, it doesn't change the edition but its direct children, of course).

And thanks for the report. I know exactly when this got broken: back in April even before release 7.9.0. Seems you're the first user to actually give this function a try :)

[KoD]

Just tried build 885 on Windows, and it seems to work ok for me. :)

As a suggestion, maybe it makes sense to change the description of the feature from "Shift start and end timecodes by the following amount" to "Shift start and end timecodes of child chapters by the following amount". It might help those that misunderstand the feature, like I did.

[Mosu]

The very first line in that dialog already states what the actions apply to. So no, I don't want to add the same verbiage to each of those options.

However, it shows that I remembered incorrectly: the shifting is indeed applied to the selected element, too, not just to its children.

[Bigmango]

There's a bug in the header editor in version 8.3 (probably the same happens when loading a file in the muxer):

A track (audio, subtitles, video) with language "fra" is not detected as French.

When clicking on "save" in the header editor, all tracks with language "fra" are changed automatically to "und" undetermined.

To avoid this, all tracks must be changed manually to "fre", otherwise the language information is lost after saving.

This didn't happen with the old gui.

FYI, all the french tracks written with Makemkv for my bluray backups have "fra" for French, so this is rather annoying.

Thanks in advance for fixing this.

[sneaker_ger]

It's a feature of the old header editor to work around bugs like the one in makemkv. I suggest you also report the problem to them.
http://www.matroska.org/technical/specs/index.html#languages

[Mosu]

Thanks for reporting this. I'll implement a similar fix for the new header editor.

The correct code to use is indeed »fre« and not »fra«. Matroska uses the bibliographic ISO 639-2 codes (»fre«; also called ISO 639-2/B), not the terminology ones (»fra«). This goes back to when Matroska started; I think at that time the terminology ones weren't favored yet – or something like that.

[Bigmango]

It's a feature of the old header editor to work around bugs like the one in makemkv. I suggest you also report the problem to them.
http://www.matroska.org/technical/specs/index.html#languages

According to the matroska specs (the link you posted), mkv uses ISO-639-2.

fre and fra are both correct according to ISO-639-2.

So, this is indeed a bug of the new gui and has nothing to do with makemkv.

[sneaker_ger]

"fra" is terminology ISO 639-2 but Matroska requires bibliographic ISO 639-2. Both the spec I posted as well as Mosu's post have correctly explained this. If MakeMKV writes "fra" it is a bug.

[Bigmango]

Thanks for reporting this. I'll implement a similar fix for the new header editor.

Thanks.


The correct code to use is indeed »fre« and not »fra«. Matroska uses the bibliographic ISO 639-2 codes (»fre«; also called ISO 639-2/B), not the terminology ones (»fra«). This goes back to when Matroska started; I think at that time the terminology ones weren't favored yet – or something like that.

"fra" is also used by bluray, I guess this is why makemkv is using it.

According to wikipedia "In practice, ISO 639-2 has largely been superseded by ISO 639-3 (2007)", and 639-3 uses only "fra" and not both as ISO 639-2.

This means, if only should be used it should be "fra", so this is a problem with the matroska spec that is not compliant with the standard used today.

Fortunately this never was a problem since all the players are using both.

So yes, mkvtoolnix also using both as you are proposing seems to be the best (or perhaps if you want to 100% stick to the mkv spec, you could automatically convert fra to fre instead of removing the tag as it is now).

Thanks.

[Mosu]

Automatic conversion from fra to fre is what mkvmerge already does. The thing about standards is that you cannot change them willy nilly. This applies to the Matroska specs, too. Like I said we started out with the bibliographic forms of 639-2, and simply changing over to the terminology ones would either invalidate existing files or make players that only support the bibliographic ones seem suddenly buggy – although they've been perfectly compliant with the specs in the past.

If we ever do something about the codes then we will likely introduce a new element that'll use 639-3 to be used alongside with the older 639-2/B elements. For improved backwards compatibility both elements would have to be used at the same time.

[Bigmango]

Automatic conversion from fra to fre is what mkvmerge already does. The thing about standards is that you cannot change them willy nilly. This applies to the Matroska specs, too. Like I said we started out with the bibliographic forms of 639-2, and simply changing over to the terminology ones would either invalidate existing files or make players that only support the bibliographic ones seem suddenly buggy – although they've been perfectly compliant with the specs in the past.

If we ever do something about the codes then we will likely introduce a new element that'll use 639-3 to be used alongside with the older 639-2/B elements. For improved backwards compatibility both elements would have to be used at the same time.

Absolutely, I hear you 100% on this.

It's also 100% fine with me if it converts fra to fre.

But regarding what you say "Automatic conversion from fra to fre is what mkvmerge already does" :

the new gui (header editor) currently removes the "fra" tag so the language information is lost as my tracks are left with "und" undeterminded...

Thanks.

[Mosu]

I was talking about mkvmerge specifically. The GUI is not mkvmerge :) The GUI will be fixed to do the same automatic conversion.

[Bigmango]

I was talking about mkvmerge specifically. The GUI is not mkvmerge :) The GUI will be fixed to do the same automatic conversion.

Many thanks.

[Mosu]

The feature has been implemented in the latest pre-builds (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/) (888, 889).

[FreaQ]

Hi Mosu,

I have a question:

Is there any way to find out if a .mkv has had "header compression" enabled during muxing?
I would need to remux those files because my hardware player always freezes with header compressed mkvs.

[sneaker_ger]

mkvinfo (GUI) and MediaInfo should show it.

[FreaQ]

Thanks found it.

[japouleripeur]

Hi. I created a chapter file with MKVToolNix GUI (8.3.0 on Win10 from scratch) and use it in input of a merge of a mkv file. Whatever the GUI (MKVToolNix GUI or mkvmerge GUI) I get this error:
"Le fichier XML de chapitres 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' contient une erreur : <ChapterTimeStart> n'est pas un élément enfant valable de <EditionEntry> à la position 118."
the chapter XML file 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' is broken : <ChapterTimeStart> is not a valid child item of <EditionEntry> at position 118.
Files uploaded.

BTW I've got this issue as well: "This application has requested the Runtime to terminate it in an unusual way" when I try to add attachments, by drag & drop or right click and "Add", whatever the file (text, picture, etc)
I got this error on Win7 pro with 8.0.0 and 8.1.0 on MKVToolNix GUI only and there was no issue with 8.2.0
On Win10 Fam I get this error on both GUIs with 8.2.0 and 8.3.0. I didn't try previous releases.

[Mosu]

Hi. I created a chapter file with MKVToolNix GUI (8.3.0 on Win10 from scratch) and use it in input of a merge of a mkv file. Whatever the GUI (MKVToolNix GUI or mkvmerge GUI) I get this error:
"Le fichier XML de chapitres 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' contient une erreur : <ChapterTimeStart> n'est pas un élément enfant valable de <EditionEntry> à la position 118."
the chapter XML file 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' is broken : <ChapterTimeStart> is not a valid child item of <EditionEntry> at position 118.
Files uploaded.

Hmm, this should not happen. I'll investigate and try to reproduce it.

BTW I've got this issue as well: "This application has requested the Runtime to terminate it in an unusual way" when I try to add attachments, by drag & drop or right click and "Add", whatever the file (text, picture, etc)
I got this error on Win7 pro with 8.0.0 and 8.1.0 on MKVToolNix GUI only and there was no issue with 8.2.0
On Win10 Fam I get this error on both GUIs with 8.2.0 and 8.3.0. I didn't try previous releases.

This happens when the file data\magic.mgc is missing or if it comes from a different versions. Don't do that. Keep the files I distribute the way they are.

The correct file size for 8.3.0 is 3865680 bytes, SHA1 checksum 903b08d20f1ee749ee76186be5c994985f8ae58d.

[Mosu]

Hi. I created a chapter file with MKVToolNix GUI (8.3.0 on Win10 from scratch) and use it in input of a merge of a mkv file. Whatever the GUI (MKVToolNix GUI or mkvmerge GUI) I get this error:
"Le fichier XML de chapitres 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' contient une erreur : <ChapterTimeStart> n'est pas un élément enfant valable de <EditionEntry> à la position 118."
the chapter XML file 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' is broken : <ChapterTimeStart> is not a valid child item of <EditionEntry> at position 118.
Files uploaded.

The function for »expanding the start/end timecodes of parent entries to the minimum/maximum timecodes of their children« seems to be the culprit. I'll fix it. Thanks for pointing this out.

If you want to salvage your file then this should be easy. Open it in a text editor and remove the <ChapterTimeStart> child from the <EditionEntry> element. Then you should be able to use the file again.

[Mosu]

I've released MKVToolNix v8.4.0. It contains numerous bug fixes in the GUI and even more new features and enhancements. For this release considerable work has gone into mkvmerge again as well fixing a couple of bugs and implementing some more small enhancements.

The most noticeable change is that the old GUI (mmg) has finally been removed.

Changes for package maintainers: the most important change is that the old GUI (mmg) has been removed. Therefore wxWidgets isn't used anymore. If Qt 5.2.0 or newer is present then mkvinfo's Qt GUI will be built autoamtically, as will be the MKVToolnix GUI.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-09-19 Moritz Bunkus <moritz@bunkus.org>
* Released v8.4.0.
* MKVToolNix GUI: chapter editor bug fix: whenever the additional modification of »expanding start/end timecodes to include the minimum/maximum timecodes of their children« was run on an edition entry then ChapterTimeStart and sometimes ChapterTimeEnd nodes were inserted as direct children of the EditionEntry node when saving. This resulted in invalid chapters.

2015-09-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: when dragging & dropping files onto merge settings already containing a file the user can set more options to be always done instead of asking (before: only adding files to the current merge settings could be thus marked; now: adding to current, adding to new settings and adding each file to new settings can be set to perform without asking). Implements #1388 (https://github.com/mbunkus/mkvtoolnix/issues/1388).
* MKVToolNix GUI: merge tool enhancement: when dragging & dropping files onto merge settings already containing a file the dialog asking the user what to do has received a new option for creating one new merge tab for each of the dropped files. Implements #1380 (https://github.com/mbunkus/mkvtoolnix/issues/1380).

2015-09-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the pixel dimensions reported for VC-1 in MPEG transport streams in verbose identification mode was 0x0.
* mkvmerge: bug fix: the number of channels and the sample rate reported for DTS in MPEG transport streams and MPEG program streams in verbose identification mode was 0.
* mkvmerge: container and track properties in verbose identification mode are now output sorted.
* MKVToolNix GUI: new merge tool feature: the »tracks« tree view contains a new column titled »properties« which contains basic track properties: the pixel dimensions for a video track and sampling frequency, number of channels and bits per sample for an audio track. Implements #1295 (https://github.com/mbunkus/mkvtoolnix/issues/1295).

2015-09-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: the verbose identification result for all audio tracks has been extended to include the number of channels, the sample rate and the bits per sample where applicable. Part of the implementation of #1295 (https://github.com/mbunkus/mkvtoolnix/issues/1295).

2015-09-13 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: parsing of strings containing negative values or timecodes was broken on 32bit architectures. Fixes #1425 (https://github.com/mbunkus/mkvtoolnix/issues/1425).

2015-09-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: the verbose identification result for the MPEG program stream, MPEG transport stream and WAV readers has been changed for audio tracks in order to match the Matroska reader's result. The old keys »channels«, »sample_rate« and »bits_per_sample« have been replaced by »audio_channels«, »audio_sampling_frequency« and »audio_bits_per_sample«.
* mkvmerge: enhancement: the pixel width/height will be reported in verbose identification mode for all video tracks.

2015-09-05 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: added a column in the track list showing the effective state of the »default track« flag. It shows the state of the flag as it will be in the output file. Implements #1353 (https://github.com/mbunkus/mkvtoolnix/issues/1353).

2015-09-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: when mkvmerge encounters garbage data in the middle of AC3 or MP3 tracks it will now output the timecode where the garbage occurred in order to make checking for audio/video sync issues easier. Implements #1420 (https://github.com/mbunkus/mkvtoolnix/issues/1420).

2015-09-01 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: added a column in the tree with the edition's/chapter's flags.
* MKVToolNix GUI: new feature: the state of all columns in all list/tree views can be reset (both the shown/hidden state as well as their order) from the column's context menu. See #1268 (https://github.com/mbunkus/mkvtoolnix/issues/1268).

2015-08-30 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: the column headers of all list/tree views can be re-ordered via drag & drop and the GUI will remember their position upon restart. Additionally the columns can be hidden/shown via a context menu by right-clicking on the column headers. Implements #1268 (https://github.com/mbunkus/mkvtoolnix/issues/1268).
* MKVToolNix GUI: new chapter editor feature: added an option for skipping chapters marked as "hidden" in the re-numbering dialog. Implements #1414 (https://github.com/mbunkus/mkvtoolnix/issues/1414).

2015-08-29 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: added a new translation to Serbian (Cyrillic) by Jay Alexander Fleming (see AUTHORS).
* MKVToolNix GUI: enhancement: the header editor will convert ISO 639-2 terminology codes used in language elements to their corresponding bibliographic variants. Implements #1418 (https://github.com/mbunkus/mkvtoolnix/issues/1418).

2015-08-28 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: if the output file name policy »last output directory« was used then manual changes to the output file name weren't recognized as changes to the last output directory. Fixes #1411 (https://github.com/mbunkus/mkvtoolnix/issues/1411).
* MKVToolNix GUI: merge tool bug fix: the »default subtitle charset« is not applied to text subtitles from Matroska files as those are always encoded in UTF-8. Fixes #1416 (https://github.com/mbunkus/mkvtoolnix/issues/1416).
* MKVToolNix GUI: enhancement: the titles and button texts of dialogs asking questions have been improved to be easier understandable. For example, instead of using »yes/no« as the answers to the question »Do you want to close the unmodified file?« the choices are now »Close file/Cancel«. Implements #1417 (https://github.com/mbunkus/mkvtoolnix/issues/1417).

2015-08-27 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor bug fix: the »shift timecodes« action in the mass modification dialog wasn't working at all, and selecting multiple actions in the dialog would result in wrong actions being executed.

2015-08-23 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: when loading simple/ OGM style chapter files that contain non-ASCII characters and which do not start with a byte order mark (BOM) the GUI will let the user chose the character set to use. A preview is shown for the selected character set and updated when the user changes the character set.

2015-08-20 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: added »remove all« and »select all« entries to the attachments context menu. Implements #1386 (https://github.com/mbunkus/mkvtoolnix/issues/1386).
* MKVToolNix GUI: job output enhancement: the output, warnings and error text views are now separated by two splitters enabling the user to change their respective sizes. These changes are remembered over restarts. Implements #1394 (https://github.com/mbunkus/mkvtoolnix/issues/1394).
* MKVToolNix GUI: chapter editor enhancement: pressing shift+return will cause the next appropriate chapter control to be selected depending on where the focus currently is: from a chapter input (start/end time, flags, UIDs) to the next chapter entry's start time, from a chapter name to the next chapter name and from the last chapter name to the next chapter entry's first chapter name. Implements #1398 (https://github.com/mbunkus/mkvtoolnix/issues/1398) and complements #1358 (https://github.com/mbunkus/mkvtoolnix/issues/1358).
* MKVToolNix GUI: chapter editor enhancement: pressing return on the very last chapter entry will wrap and focus the first one in the tree again. Enhances #1358 (https://github.com/mbunkus/mkvtoolnix/issues/1358).

2015-08-19 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed the total job queue progress with respect to removing completed jobs (either automatically or manually). Fixes #1405 (https://github.com/mbunkus/mkvtoolnix/issues/1405).

2015-08-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: mkvmerge is now run in with the same interface language set for the GUI.
* mkvmerge: bug fix: The formula used for calculating the audio delay for garbage data at the start of tracks in AVI files has been fixed again. It now uses the values dwStart, dwScale and dwSampleSize from the AVI stream header structure instead of values derived from the audio packet headers. Fixes #1382 (https://github.com/mbunkus/mkvtoolnix/issues/1382) and still works correctly for #1137 (https://github.com/mbunkus/mkvtoolnix/issues/1137).
* MKVToolNix GUI: enhancement: scrolling over input elements like combo boxes, check boxes and radio buttons located within a scroll area will now scroll the scroll area instead of the element the cursor is over (e.g. a combo box). Implements #1400 (https://github.com/mbunkus/mkvtoolnix/issues/1400).

2015-08-17 Moritz Bunkus <moritz@bunkus.org>
* all: the environment variable <TOOLNAME>_OPTIONS is now parsed for options for TOOL (e.g. MKVMERGE_OPTIONS for mkvmerge). MKVTOOLNIX_OPTIONS is still used for all programs. Fixes #1403 (https://github.com/mbunkus/mkvtoolnix/issues/1403).

2015-08-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed the escaping of the command line for cmd.exe regarding the command name itself (the very first argument). Fixes #1401 (https://github.com/mbunkus/mkvtoolnix/issues/1401).

2015-08-15 Moritz Bunkus <moritz@bunkus.org>
* build system: removal: the switch »--without-mkvtoolnix-gui« has been removed. There are only two GUIs left in the package: the Qt-enabled mkvinfo and MKVToolNix GUI. Both are enabled by default and can be disabled with the option »--disable-qt«. In that case only the text-mode version of mkvinfo is built, and the MKVToolNix GUI is not built at all.
* Removal: all support for wxWidgets has been removed. This means that the mkvmerge GUI (mmg) has been removed and that mkvinfo now only supports a text-mode and a Qt-based interface.
* build system: bug fix: fixed Qt platform plugin detection on MacOS.

[Bigmango]

Thanks.

In the changelog I don't see the language tag fra replaced with fre (header editor). But this fix is in 8.4.0, isn't it?

[nevcairiel]

In the changelog I don't see the language tag fra replaced with fre (header editor). But this fix is in 8.4.0, isn't it?

Its this one, I wager:

* MKVToolNix GUI: enhancement: the header editor will convert ISO 639-2 terminology codes used in language elements to their corresponding bibliographic variants. Implements #1418.

[Mosu]

Nevcairiel is spot on.

[japouleripeur]

The function for »expanding the start/end timecodes of parent entries to the minimum/maximum timecodes of their children« seems to be the culprit. I'll fix it. Thanks for pointing this out.

If you want to salvage your file then this should be easy. Open it in a text editor and remove the <ChapterTimeStart> child from the <EditionEntry> element. Then you should be able to use the file again.

:thanks: it works.

[Mosu]

:thanks: it works.

You're welcome. That particular bug has been fixed in 8.4.0, too.

[japouleripeur]

Hmm, this should not happen. I'll investigate and try to reproduce it.

This happens when the file data\magic.mgc is missing or if it comes from a different versions. Don't do that. Keep the files I distribute the way they are.

The correct file size for 8.3.0 is 3865680 bytes, SHA1 checksum 903b08d20f1ee749ee76186be5c994985f8ae58d.
I always use the installer and do not change any file afterwards. I knew about this "magic" file, you wrote it in another post and I checked size and check-sum. They are ok.
The issue even occured at the first MKVToolNix installation after my fresh Win10 installation from scratch.
BTW I do not understand why it's possible to add the same files in the source tab and not in the attachment tab. For sure I'm not a coding expert.

[AYColumbia]

Anyone else having issues downloading the non-portable Windows install packages? Getting a file not found on both 32 and 64 bit Windows installers. Portable links are fine.

[Mosu]

Do you have write access to the file you're trying to add as an attachment? Both tabs do very, very different things. The input tab will have mkvmerge scan the file for known container formats. On the attachment tab mkvmerge itself is not involved when adding a file, instead libMagic is called for automatic MIME type detection.

Can you provide one file for which the GUI crashes? I sure as hell cannot reproduce it here at the moment. I can add as many attachments as I want to, the GUI happily continues running.