MKVToolNix v24.0.0 released

[Mosu]

Oh wait! Do you perhaps mean the file selector used on the merge tool's »output« tab? If so you're right, it seems – there's only XML and *. I'll fix that.

[hubblec4]

Originally Posted by Mosu

One thing you could try is to give the portable version a try if you're currently using the installed one and vice versa.

Hi Mosu

I had the same problem with new version 8.2.0.
I had installed v8.0.0 and then I replaced all files with the new 8.1.0 (no problems) and then 8.2.0.

After a few starting mtxcfg files the GUI needs 10 sec to start and closing the Gui needs 6 sec. The GUI will start at a different position as you open the GUI via link.

I had then deleted your registry settings(bunkus.org) completly and the GUI works again and start at the correct position.

[Mosu]

What would be interesting and helpful for me is the size of the entries stored in the bunkus.org registry sub-tree – hence me asking for an export of that sub-tree.

My current guess is that the QSettings class re-writes the whole registry sub-tree when it is saved. Currently the GUI stores not only its settings but also the job queue via QSettings (meaning in the registry if it's the installed version). As the job queue includes the full output of all jobs currently in the queue, even the ones already run but not yet removed, this can amount to quite a bit of data.

If re-writing the whole registry sub-tree is that slow I will have to change how these things are stored significantly and not use the registry at all, even for the installed version. The installed version could store its settings in an appropriate place in C:\Users\<username>\AppData\… (well, the path returned by QStandardPaths::writeableLocation() for QStandardPaths::AppDataLocation). I would also have to migrate the settings from the registry to that location.

[Mosu]

Originally Posted by hubblec4

After a few starting mtxcfg files the GUI needs 10 sec to start and closing the Gui needs 6 sec. The GUI will start at a different position as you open the GUI via link.

Starting a job will actually write the settings twice: once after the job has been added and once each time the job changes state (e.g. from »pending auto« to »running«). That's probably why you seem twice the delay when starting the job versus when you quit the program.

I had then deleted your registry settings(bunkus.org) completly and the GUI works again and start at the correct position.

Like I said above: the portable version stores its settings completely independent from the installed version. Both store the position and size of the windows. So if you switch back and forth between an exe from the installed version and one from a portable one then it's normal behavior that the window positions and sizes differ.

[hubblec4]

Originally Posted by Mosu

What would be interesting and helpful for me is the size of the entries stored in the bunkus.org registry sub-tree – hence me asking for an export of that sub-tree.

I have upload the registry tree to your ftp.

[rsotome]

Is there any way to output the jobs queue to the text editor friendly .mmg extensions with the new GUI, or are we stuck with the jobs being stored in only the registry?

I've found excellent ways to mass edit .mmg files in just a few seconds with Notepad++, with settings/names/attachments/etc that would normally take several minutes using the gui directly. (eg. just about any TV series)

Thank you, and please don't think I'm knocking the new GUI, or all your hard work, I love this program.

[TheBean]

Originally Posted by Mosu

Sure it can. On the merge tool go to the »output« tab. On the lower right you'll see »additional options«. Either enter the option manually or hit the button to the right of it which will open a dialog showing all available additional options. In that dialog you can also opt to have the selected options be set for each new merge job by default.

You can find the same default options in the preferences dialog on the »merging« tab. Here it's called »Default additional command line options« with the same button and the same dialog attached to it.

Thank you! I looked over the UI a couple of times, can't believe I missed that.

Thanks again.

[Mosu]

Originally Posted by hubblec4

I have upload the registry tree to your ftp.

Thanks, I'll investigate it.

[Mosu]

Originally Posted by rsotome

Is there any way to output the jobs queue to the text editor friendly .mmg extensions with the new GUI, or are we stuck with the jobs being stored in only the registry?

If you're using the portable version then the job queue is already stored in an .ini file. For the installed version I will most likely switch to storing all settings including the job queue in an .ini file, too, due to performance reasons (see a couple of posts above yours for information).

However, all jobs are stored in the same .ini file, and not storing each job in its own file was actually a conscious design decision. Having those separate files in addition to the information which files should exist and their order is error-prone.

So yes, you are already respectively will be able to add such jobs with a text editor, albeit with a couple of caveats.

[Mosu]

Hmm, even after using an INI file it's still somewhat slow. The amount of information stored is simply so much that the relative slow speed of QSettings drags things down.

Unfortunately I don't have an easy way out at the moment, especially given that several users prefer to have those job queue editable with a text editor – otherwise I might consider switching to a different storage format. Alas, that would also affect existing .mtxcfg configuration files as they use the same methods for writing their data.

Not an easy choice, unfortunately, and probably not something that I can fix quickly.

[hubblec4]

mmh...
that bad news, i hope the mtxcfg file will not so much changed.

[Mosu]

I don't really want to change them either. My current plan is to save each of the job queue's job in a separate file. That way the application has to write far fewer bytes each time the settings are changed. Additionally changing a single job will only require writing that single job's file.

That being said: the INI files themselves do become kind of huge, especially if you've got as many tracks as you do (more than 20 appended files with > 10 tracks each). I know that this is kind of normal for Blu-ray discs, and therefore there are limits to how fast it'll become, I guess. The INI format isn't the most efficient storage format, unfortunately. It only really supports one level of groups, and therefore deeply-nested structures require listing all of the intermediate group names time and again:

job%200\muxConfig\input\files\0\appendedFiles\0\tracks\12\aacSbrWasDetected=false
job%200\muxConfig\input\files\0\appendedFiles\0\tracks\12\additionalOptions=
job%200\muxConfig\input\files\0\appendedFiles\0\tracks\12\appendedTo=68604232
…

Maybe I will have to change to some other formats capable of storing deeply-nested structures more efficiently (YAML, JSON, even XML…). But let's see how well storing each job in a separate file works.

[NanoBot]

Originally Posted by Mosu

Oh wait! Do you perhaps mean the file selector used on the merge tool's »output« tab? If so you're right, it seems – there's only XML and *. I'll fix that.

Exactly, that is the file requester I am talking about. I often use EAC3to or DVDDecrypter to demultiplex BDs or DVDs, and both of them extract the chapters as a text based file. Therefore it is one step less in the workflow when the .txt and the .ogg file extension is preselected when importing them into the new GUI.

Thx in advance for fixing that.

C.U. NanoBot

[Mosu]

I've already added .txt. I will not add .ogg as an extension there, though. It would be highly confusing. .ogg is usually used for Ogg files, and mkvmerge's --chapter functionality cannot handle Ogg files, only OGM-style text chapters, CUE sheets and XML chapter files.

mkvmerge can handle chapters stored in Ogg/OGM files, but only when using such a file as a regular input file.

[Altober]

Hi. Sorry for my english. I belong to Argentina (spanish language).
Well, this is my ask...
In previous versions, when the original mkv has delay in a audio track, I not need enter manually this delay dragging mkv to mkvmerge gui (old gui).
Dragging mkv to mkvmerge gui (for a new movie mux) I did not need to know value for delay, this value was legacy in automatic mode for oriignal mkv.

But now, in mkvtoolnix gui (new gui) this value (delay value) is LOST.
I need watch the movie, for search the exact delay value, then yes, I can enter manually delay before mux the movie.

My question is... in new gui... is possible to avoid make all work again? Is possible keep the original delay value of original mkv?

Many thanks!

[Mosu]

Both GUIs use the same program (mkvmerge) for the actual work. Re-muxing from Matroska to Matroska works the same in both GUIs, in each case the audio delay is kept.

So if you take the file you're having problems with in the new GUI and re-mux it with the old GUI then you should run into the same sync problems.

See also here for related information.

[Bigmango]

The new gui isn't available for linux?

Why is only mkvtoolnix-cli mkvtoolnix-gtk (which installs the old gui) in archlinux?

Thanks.

[Mosu]

The GUI is available on Linux – my main development is Arch Linux, in fact. That the official Arch Linux package doesn't include the new GUI yet is known; there are two issues about that already. If you want to speed things up you should offer them your help or at least speak up in those reports.

Note that even though I develop on Arch I'm not an Arch Linux maintainer myself. As Arch is usually very fast with releasing package updates I don't offer binaries for Arch myself either.

[Altober]

Originally Posted by Mosu

Both GUIs use the same program (mkvmerge) for the actual work. Re-muxing from Matroska to Matroska works the same in both GUIs, in each case the audio delay is kept.

So if you take the file you're having problems with in the new GUI and re-mux it with the old GUI then you should run into the same sync problems.

See also here for related information.

Understand. Thanks so much for your time for answer.

[ndjamena]

Originally Posted by Nikolaj Olsson - Subtitle Edit

Hi ndjamena,

I can see you know stuff about text in blu-ray subs... do you know anything about the specs for this?
I would like to add support for importing these into SE.

Best regards
Nikolaj

Originally Posted by ndjamena

God… I’d been sitting around thinking of trying to get better processing of TextST subtitles into Subtitle Edit but had to consider the consequences.

I’ve been told by two different sources that they have access to the TextST specs and that they’d be willing to share them with anyone who would like to write a decoder…

But… If you’re just going to write a decoder to convert TestST to srt or ass not only will you be losing some of the formatting options that can’t be reproduced in any other subtitle format, you’ll also be contributing to the ultimate demise of the codec.

The codec is in a very fragile state, and could be snuffed out quite easily. I’m not even sure how many discs have the things on them, but it would be nice if those few disc that have them could have some chance of having them play at some point…

What are the chances of you writing an actual ENCODER… that would actually HELP the standing of the codec.

>> At the risk of being annoying… 608 captions still don’t decode properly from an m4v using 3.4.7, iTunes is the only decoder I have access to that hasn’t been discredited yet… and I wish I could write the damn thing myself… but, any news?

Originally Posted by Nikolaj Olsson - Subtitle Edit

Hi ndjamena,
I've got some info about TEXTST so I'll look more at it tonight or hopefully very soon.
I guess I could try to make a export to TEXTST too (like many other export formats in SE), but I'm not sure what is required to merge them with a video.
Gotta go...

Best regards
Nikse

Originally Posted by Nikolaj Olsson - Subtitle Edit

Hi ndjamena,
I cannot see why SE should not have textst support - it would probably help understanding/testing of the decoding which will be a good thing.
Of course it would be nice to have export too - can mkvtoolnix merge these text subtitles in mkv files?
I've succeeded in having plain text imported into SE from textst (code needs to be cleaned up and allow for split m2ts packages), but the format is quite advanced like ass/ssa with both header styles and inline styles + multiple regions. Also, the formats seems to be at least 8 years old...

About the mp4/m4v I'm actually stuck at extracting the texts from the boxes... I cannot seem to find any info about how many texts are there and where (some subtitles works and other are just different)
Best regards
Nikolaj

I've realised that switching to email whenever something important crops up just gives people the impression that I don't do anything, don't know anything and doesn't help them understand anything either.

The words "properly muxed" have been thrown at me twice already now. Did no one read the streaming section of the specs? Or did they just not consider how it affects muxing and tagging?