31 thoughts on “MKVToolNix v8.1.0 released”

1. tophf June 27, 2015 at 14:26

   GUI doesn’t remember vertical splitter position, makes it hard to work with long file names:

   customized pos: https://puu.sh/iEwNZ/7b249eeb6e.png
   next run resets it: https://puu.sh/iEwOy/4fe2afbd5c.png
   1. mosu Post authorJune 27, 2015 at 14:27

      True, there’s no code for remembering such settings yet. I’ll open an issue for it.
2. Ruben June 27, 2015 at 19:19

   I will reply here instead of in the past version article. You said I didn’t address particular concerns about the new GUI and I just said something like “it’s shit” (your words, not mine). Don’t take me wrong, I appreciate your work and I didn’t criticize the new GUI just for the sake of it. My critique was and is well intentioned.

   It’s hard to see it if you are the one thinking the changes and implementing them. Here are is my constructive criticism:

   – The purpose of having something done quickly and with less click is harder in the new GUI than it was on the old one. You talk about having a wider version instead of taller but the fact is that the split divider in the main tab is awful and doesn’t show the full line of input files or tracks at once like the old one.

   – The left navigation items are ugly and the menu bar for just the 5 of them takes valuable space. The black background looks bad. Maybe you can try to rework this and put them in other place, preferably without any sort of background or button shading background.

   – If the workflow for more than one job is to have a queue, which is a good approach, why have tabs to have more than one file open at a time. This is something that takes screen space when many of the users add jobs to the queue and then open another one and so on. I don’t think many work with more than one job at a time.

   – You can use a proper menu toolbar for the left navigation items and perhaps you can work on the tab for files and replace them with the menu items there’s. Just a thought.

   I look forward to seeing the GUI improved. Regards.
   1. mosu Post authorJune 27, 2015 at 20:00

      You did indeed not say »it’s shit«, and I’m sorry for putting words in your mouth. But you only stated that several things are bad without giving any reason at all resulting in what I considered to be »generic unspecific complaints« – something I cannot work with.

      Today you did indeed make specific and justified complaints, and I thank you for that.

      About your points.

      1. The wider version was a result of user requests. Obviously there are problems with both approaches. You preferred the wider one while others couldn’t work with that and vice versa.

      However, I’m planning to improve on this by a) making the splitter remember its position over restarts and b) implementing an optional layout more similar to the one used by mmg (file list on top, track list in the middle, preferences on the bottom). See issues 1306 and 1304. I have’t fully thought out how to do the layout in the top-down version yet, though, and it’s not that easy to implement in a maintainable way, so don’t expect this to arrive within a week.

      Another improvement in the long run may be that I plan on making the order of the columns presented in the file and track lists configurable. This doesn’t have a high priority at the moment either, though.

      2. The items being ugly is in the eyes of the beholder. Same for the dark background. I’m not opposed to changing the looks but this is not an area I’m going to spend any time on in the near future.

      The tool selector has so much space for a reason: I have concrete plans for three more tools (extraction, info and a tag editor). I’ll think about giving you an option to hide it in the future (the functions are reachable via the »MKVToolNix GUI« menu already; I could add another menu entry for toggling the tool selector). I’ll add an issue for that.

      3. and 4. Having more than one tab open at the same time was again done upon user request. As a matter of fact this was one of the more often requested features. Having actual tabs gives the user more much better visual feedback which file (s)he is currently working on, so I don’t really want to remove the tabs.

      One option could be to make the placement configurable: Qt supports placing the tabs on the left instead of on the top. I don’t know whether or not that would be an improvement for you, though.
      1. Ruben July 2, 2015 at 09:50

         Thanks for the reply. I look forward to those improvements.

         About the left side menu and the background you don’t need to work on it, just use the default control look for each platform, in case it’s possible.

         Support for progress visualization in the Windows taskbar icon is a must. I hope you implement it soon.
         1. mosu Post authorJuly 2, 2015 at 10:51

            Well, your »must have« are another person’s »don’t care« :) It is on my TODO list. I’ll open an issue for it.

            Note that the »stacked layout« feature I’ve talked above has been downgraded to medium priority for me (= will likely not be implemented in 8.2.0) as Lenmaer, the most vocal proponent of such a layout, said that he and his fellow guys would stay with mmg after all. I will implement that optional stacked layout in due time.

            Saving the splitter positions has already been implemented.

            I’ll also open lower-priority issues for making the tool selector background something else than black and for moving the tab headers to the side instead of the top.

            Having issues is good :) It means it’s easier to remember that such requests exist.
3. Lenmaer June 28, 2015 at 12:33

   Well, since 8.1.0 it’s starting to become better.
   Not everything suggested is implemented yet which I do understand.
   There’s one thing that I forgot to address and I don’t see it suggested on github.
   It’s the attachments, having them shown in main window now isn’t ideal, especially for us fansubbers who mux lots of fonts, lots of scrolling when you have to remux a file, also more chances of accidentally unselecting a font and doing errors. The behavior of mmg was much more practical with its split screen in another tab. You could also easily compare the fonts you already had muxed in that way. Now you have to browse tabs.
   1. Lenmaer June 28, 2015 at 12:35

      Now you have to switch tabs, not browse, sorry bad wording.
   2. mosu Post authorJune 28, 2015 at 12:59

      It was also a source of confusion for other users. They complained that it was unclear which attachments came from where. It’s also confusing to have both types in the same list once I implement re-ordering of new attachments. Why? Because the order of existing attachments cannot be changed (!). mkvmerge simply doesn’t support that. So having both in the same list would require existing attachments to be always at the top, clearly marked as being from somewhere else, and moving them around would have to be impossible. It wouldn’t do anything to clear up the confusion.

      This is something that I’m unlikely to change.

      And of course not everything suggested has been implemented yet; I cannot do magic, after all ;)
      1. Lenmaer June 28, 2015 at 13:45

         Well they don’t need to moved around.
         Just in the attachment tab, have two windows, like mmg did with checkboxes.
         Top windows would have the attachments already muxed in, bottom window, the new ones to be muxed in, and all with checkboxes.
         The old mmg right now shows the path of each attachment, so if users really get confused on what belongs to what, then they must really be dumb, because it’s easy to see. ^^
         1. mosu Post authorJune 28, 2015 at 13:46

            I’m sorry, but like I said this is not something that I’m willing to change at the moment.
            1. Lenmaer June 29, 2015 at 07:53

               Oh well, we will have to stay on the old versions then…
            2. mosu Post authorJune 29, 2015 at 16:40

               That’s sad to hear, but your prerogative, of course.
4. chessplayer June 28, 2015 at 14:20

   Crash on second run

   Hi, my scenario is that I usually cut TV recordings and pack them into mkvs, where I normally wait until I have a few to process. I will then set everything up for the first one, mux it, remove the file and replace it by the next recording. This works great in the old mkvmerge GUI, but in the new mkvtoolnix GUI, I consistently get a crash when I try to drag & drop the second file to the sources section. I believe it did work once, but then it crashed during mux.

   So, for the time being, I much prefer to use the old GUI and sincerely hope you will leave the latest version in your package forever, even if you do not actively support it anymore …

   My system: Ubuntu 14.04, mkvtoolnix from your ppa updated this morning.
   1. mosu Post authorJune 28, 2015 at 14:24

      Crashes are obviously bugs that I will fix. Just to be clear: you set up your mux settings, hit »start muxing«, remove the source files from the job, then you drag & drop a file from an external application (e.g. a file manager) onto the merge job and MKVToolNix GUI crashes?
      1. chessplayer June 28, 2015 at 16:04

         Almost (but maybe you mean the same): I try dragging the file from the file manager to the then empty source area, then it crashes.
         1. mosu Post authorJune 28, 2015 at 16:07

            That’s what I meant, yes. I haven’t been able to reproduce such a crash (I tried for ten minutes an hour ago) on my Arch Linux yet, though, so I don’t know whether or not I’ll be able to find the issue. Likely not, especially as I currently don’t have an Ubuntu installation sitting around here (at least not one with a working graphical setup – only my build system which is run from a chroot from which I cannot run graphical programs).
            1. chessplayer June 28, 2015 at 16:31

               Ok, is there anything specific I could test and report back to you?
            2. mosu Post authorJune 28, 2015 at 16:55

               Thanks for the offer. A full stack backtrace might be helpful. For that you’ll have to compile the application with debugging settings, though.

               Generelly: download the source tarball; unpack it; install build dependencies (sudo apt-get build-dep mkvtoolnix ); run »./configure --enable-debug --disable-wxwidgets«; compile with »./drake apps:mkvmerge apps:mkvtoolnix-gui«; install gdb (sudo apt-get install gdb).

               Then run the newly-compiled GUI from inside gdb:

               gdb src/mkvtoolnix-gui/mkvtoolnix-gui
               run

               Do your thing. As soon as it crashes gdb will return to the gdb prompt. At this prompt execute one command:

               bt

               Let it show all lines, then copy me that output. It will probably consist of quite a number of lines; you should send me an email with them to moritz@bunkus.org (and not post them here on the blog).
5. JunkyardCat June 29, 2015 at 13:53

   I’m very pleased with the new GUI on v8.1. With 8.0 the open with menu didn’t actually open the file with Windows 7 x64, now that it’s working again I have no issues with it at all.
   My typical usage is adding/removing subs and/or audio tracks, occasionally extracting subs or audio, so my experience may not reflect some of the more hardcore users. For me it’s outstanding at this point. Thanks for all the hard work and constant refining.
   1. mosu Post authorJune 29, 2015 at 16:38

      Thank you for your feedback and the kind words.
6. zz June 30, 2015 at 04:55

   Uhmmm are you planning to remove the wxwidgets GUI? When I moved to Linux, I was very pleased to find that mkvtoolnix, audacity, aegisub, use the same GUI toolkit, a fairly small one. Qt is a little big
   1. mosu Post authorJune 30, 2015 at 09:00

      Yes, the wxWidgets-based GUI will be dropped. No, I’m not going to reconsider. Sorry.
7. Tyler July 6, 2015 at 04:18

   Can you add more batch options?

   Like say i have 20 files all with the same track layout, and want to remove 1 track from each and change a setting on another.

   Be nice not to have to do it for every file individually.
   1. mosu Post authorJuly 6, 2015 at 09:08

      I’m sorry, but I won’t add batch muxing capabilities to the GUI. See here for the reasons. Individual requirements like yours are best served by learning a tiny bit of scripting and automating mkvmerge’s usage to your hearts content.
8. David July 12, 2015 at 12:16

   Is there any way to automatically remove items from the input list once you add them to the job queue? This was the way it worked with MKVMERGE GUI before, but now you have to add the job, and then delete the files before loading in the next ones.
   1. mosu Post authorJuly 12, 2015 at 12:22

      With v8.1.0 you can change the behavior in the preferences. Look for the option »Clearing settings automatically« on the »Merging« tab.
      1. David July 12, 2015 at 12:28

         That did it. Thanks for the quick response.
         1. mosu Post authorJuly 12, 2015 at 12:32

            You’re quite welcome.
9. rob July 15, 2015 at 07:13

   Hello, thanks for a great line-up of programs! I normally use CLI, so this is very helpful.

   On this new mkvtoolnix(lubuntu), I have a couple of pains. I would like to set the default track flag of audio to initialize as ‘yes’, In most cases I only have one audio, but if there is multiple I can set the secondaries to no and not have to reorder the list.

   I would like to set the default track flag of subtitles to initialize as ‘no’. I rarely have a ‘yes’ default unless the audio is not an understandable language.

   And :) when adding external audios and subs, would there be a way to reorder the list into a preferred sequence instead of adding each file separately. I just added about 20 subs to one video and I found I must add them independently to my preference.

   Thanks again for the superb software, it does save me a lot of time over CLI.
   1. mosu Post authorJuly 15, 2015 at 11:49

      > I would like to set the default track flag of audio to initialize as ‘yes’, In most cases I only have one audio, but if there is multiple I can set the secondaries to no and not have to reorder the list.

      There’s usually no need for that. If you leave the settings at their initial values then mkvmerge will already set the »default track« flag to »yes« for the first audio track. See here for an explanation how this process works.

      > I would like to set the default track flag of subtitles to initialize as ‘no’. I rarely have a ‘yes’ default unless the audio is not an understandable language.

      There’s already a feature request for such functionality. I will probably implement it for v8.3.0.

      > And :) when adding external audios and subs, would there be a way to reorder the list into a preferred sequence instead of adding each file separately. I just added about 20 subs to one video and I found I must add them independently to my preference.

      I don’t really understand what you want to achieve. Maybe you could go into more details and provide some examples of what you’re doing and which part of that work the GUI should be able to do for you.

Comments are closed.