MKVToolNix v24.0.0 released

[nevcairiel]

A lot of media applications rely in some form or shape on the so-called "Windows Media Player" components - which include a lot of very low level media components, and not just the player.
Installing a "N" windows version out of spite for Windows Media Player is really just limiting yourself for no good reason. Don't run it if you don't like it, but the media framework parts it includes are important to many other applications. "N" builds exist because of EU politics, but there is no good reason for anyone to really use them.

[mariush]

In Windows there's the old PlaySound API function : https://msdn.microsoft.com/en-us/library/windows/desktop/dd743680(v=vs.85).aspx
sure it's not cross platform but for windows It would have been enough to play some wav file..

if you don't need the absolute latest qt maybe a xp only version could be hacked using this function and a qt that doesn't require those libraries.

anyway we're kinda going offtopic

[hello_hello]

No, I'm not changing frameworks/the methods for sound playback. I'm using what my GUI toolkit of choice is offering regarding cross-platform multimedia playback because that's the most sane, most foolproof, least painful, most debugged method of doing such things in a cross-platform way.

Is that entirely true? Doesn't Qt still support XP? Windows Media Format 11 installs on XP.

Edit. Removed misinformation.
I missed where it says here (http://doc.qt.io/qt-5/qtmultimedia-windows.html) the Media Foundation plug-in only supports Vista and newer, but given DirectShow support appears to be alive and well and Qt supports XP.... doesn't Qt's cross platform cleverness include sound on XP, or would an an XP specific build be required? If using DirectShow is hard or problematic then I'll shut up and go away (I'm trying to understand a bit more, not hassle you for the sake of it), but Media Foundation was instantly problematic enough to require a FAQ on your site, so it's not a perfect choice either.

I don't know much about Qt, but XP compatibility broke once before and then unbroke a while later. I assume you didn't have a change of heart but do you know what happened there?

I've actually typed up quite a long answer listing all the possible choices you have, why I do or do not do certain things, why my choices are the way they are, but all that boiled down to being angry and venting. That's not productive. Therefore I've snipped it.

I wouldn't have minded reading it.
I initially suggesting going "ding" with PowerShell because I thought it might be easy, and eliminate the need to install the Media Foundation, which seems a little ridiculous as a requirement for muxing at first glance, but when it seemed there wasn't an easy solution I let it go and accepted I'd probably be muxing with MKVToolNix 10 for quite a while, as I had previously for version 7.8.0. Nobody expects you to spend a huge amount of time on XP issues. Well I don't at least.

I get it. I really, really, really do. It's your software and you can support whatever you choose, but I'll be honest and say it's frustrating from an user perspective when there's a suggestion such as "tick this box to fix XP" but you won't even look at it, because that effects a lot of people who'd otherwise be using the latest version.

[stax76]

ffmpeg usability feature:


first audio:

-map 0:a:0


second audio:

-map 0:a:1


first subtitle:

-map 0:s:0


Does anybody else find this useful?

[Selur]

nothing new (https://www.ffmpeg.org/ffmpeg-all.html#toc-Advanced-options) + what does this have to do with mkvtoolnix?
(that said: have fun once you play around with filter_complex and the stuff you can do with it :))

[hubblec4]

If you want to improve the chances of that happening, I'd ask you to open an issue over on Github (https://github.com/mbunkus/mkvtoolnix/issues/) for it. Otherwise I will almost certainly forget about it again.

Ok I did it. Only if you have time, Im sure you have many other things to do.

[sneaker_ger]

Does anybody else find this useful?
Yes. The mkvtoolnix system never really made any sense to me. You specify track type and TrackID even though the TrackIDs are unique and not re-used for the different track types.

Well, it does make some sense in that you implicitly deactivate all other tracks of the same type but it is still kinda weird.

[stax76]

nothing new + what does this have to do with mkvtoolnix?

It's new to me :), in the past I used the IDs from MediaInfo for all tools, which was a little bit buggy since every tools using different IDs, for ffmpeg I can use the handy syntax but for mkvmerge text parsing is needed, it's easy to do with .NET though.

Dim stdout = ProcessHelp.GetStdOut(Package.mkvmerge.Path, "-I " + ap.File.Quotes)
Dim values = Regex.Matches(stdout, "Track ID (\d+): audio").OfType(Of Match).Select(Function(match) match.Groups(1).Value.ToInt)
If values.Count = ap.Streams.Count Then tid = values(ap.Stream.Index)

It's a bit slow and fragile in theory, practically only three more lines code.

[kuchikirukia]

Playing a sound when muxing finishes has been requested by users time and again.

Did they list breaking Windows compatibility as an acceptable tradeoff? Breaking the entire N and K lines isn't small.

It may be a nice feature for 0.01% of users who are for some reason incapable of looking down at their taskbars, but it's not exactly vital. It would certainly be the first thing I'd disable.

[Mosu]

ffmpeg usability feature:

Nope, sorry. Changing how IDs are used would require huge changes to the program, and it would be a huge change for all external users of those programs. Meaning it would break a lot of stuff. Definitely not worth the effort.

[Mosu]

I don't know much about Qt, but XP compatibility broke once before and then unbroke a while later. I assume you didn't have a change of heart but do you know what happened there?

It accidentally broke because I used registry access functions that aren't available on XP. It accidentally un-broke when mmg (the old GUI) was removed which meant I simply didn't need that specific code anymore anyway. None of that was intentional as I hadn't supported XP at that point anyway.

[isidroco]

Any chance you'll support win98? :D (now seriously, I still have win98/ XP dual boot :) )

[manolito]

Wow, same here...
I still need Win98 for my WinFax software (which was not maintained by Symantec to work correctly under XP). The built-in WinXP fax application is crap, and I do not want to pay again for a fax softwhere when I already own one which works perfectly...

[Mosu]

Any chance you'll support win98? :D

Sure! I'll get right on it after my breakfast burrito! ;)

[manolito]

Got a problem with DVB-T2 captured streams when the audio stream is in the AAC-LATM format (using the current stable version 11.0.0).

My Xoro receiver stores the captures in a .MTS container. I usually run these files through TS-Doctor, but it makes no difference if I don't.

Before converting the files (using StaxRip) I like to repack them into an MKV container because in the .TS format all seeking operations (to find editing points) are just a pain, no matter if I use LAV Filters or FFMS2 as the source filter.

And this repacking to MKV does not work with MKVMerge. I do not get any error messages, but the resulting file does not play, neither in MPC-HC nor in VLC. If I use a current version of FFmpeg for this repacking, there is no problem whatsoever.

Here is the MediaInfo report for the audio stream in the .TS file:

Audio
ID : 2520 (0x9D8)
Menü-ID : 897 (0x381)
Format : AAC
Format/Info : Advanced Audio Codec
Format-Profil : LC
Muxing-Modus : LATM
Codec-ID : 17
Dauer : 1 h 52 min
Bitraten-Modus : variabel
Kanäle : 2 Kanäle
Kanal-Positionen : Front: L R
Samplingrate : 48,0 kHz
Bildwiederholungsrate : 46,875 FPS (1024 spf)
Video Verzögerung : -248 ms
Sprache : Deutsch

Any ideas?
BTW if the audio stream is in the EAC3 format then MKVMerge works just fine.


Cheers
manolito

[Mosu]

Got a problem with DVB-T2 captured streams when the audio stream is in the AAC-LATM format (using the current stable version 11.0.0).

It's possible that you're hitting this issue (https://github.com/mbunkus/mkvtoolnix/issues/1957), even though the description doesn't seem to indicate a common cause. However, the underlying cause of #1957 was wrong handling of LATM AAC in MPEG TS. Please give the pre-build linked in that issue a try.

[manolito]

Thanks Mosu, yes, the prebuilds from this link do fix the issue... :D

The resulting MKVs play fine now without sync problems, but using them as input for StaxRip is still problematic. For the TS source file MediaInfo reports an audio delay of around -230 ms, the MKV created by MKVMerge has a delay of -1300 ms. This seems awfully high, still the file plays OK. But when I feed it to StaxRip, the conversion result is terribly out of sync.

If I create the MKV using FFmpeg, MediaInfo reports no audio delay at all for the MKV. And StaxRip handles it without sync problems, too. I hate these HEVC files... :devil:


Cheers
manolito

[stax76]

Thanks Mosu, yes, the prebuilds from this link do fix the issue... :D

The resulting MKVs play fine now without sync problems, but using them as input for StaxRip is still problematic. For the TS source file MediaInfo reports an audio delay of around -230 ms, the MKV created by MKVMerge has a delay of -1300 ms. This seems awfully high, still the file plays OK. But when I feed it to StaxRip, the conversion result is terribly out of sync.

If I create the MKV using FFmpeg, MediaInfo reports no audio delay at all for the MKV. And StaxRip handles it without sync problems, too. I hate these HEVC files... :devil:


Cheers
manolito

There is also currently a TS discussion in the German staxrip support thread at gleitz.

http://forum.gleitz.info/showthread.php?26177-StaxRip-Encoding-Frontend-%28Diskussion%29/page999999

What works normally well is to open TS directly with DGDecNV. Other things you can try is demuxing TS with TS Doctor. Delay detection is done with MediaInfo using the Video_Delay property. Unfortunately I don't know the MKV format good enough to know what's causing the async issue with mkvmerge. Good find that ffmpeg works around the issue, so far I only knew Haali muxer works around it, dsmux is integrated in staxrip but the Haali muxer is not really stable.

[sneaker_ger]

If the streams are in-sync within the mkv then it is not an mkv issue. Rather, the mix of tools using to process the video and audio streams aren't harmonized in the way they treat delays and/or vfr or are otherwise used incorrectly.

Comparing all timecodes between the file created by mkvmerge and the one created by ffmpeg should give you enough hints to find the problem.

[stax76]

I would probably need a couple of hours to understand this...

[Mosu]

Hey,

Today I've released v12.0.0 of MKVToolNix. Not too many changes in this one, but at least one rather important bug fix in the HEVC/h.265 code that can result in invalid files. I therefore recommend everyone to update.

Windows users should note that starting with v11.0.0 the GUI requires Microsoft's "Media Foundation" framework to be installed. This is the case out of the box on the consumer versions of Windows other than the N and KN variants of Windows 10. You'll have to download and install it separate on N and KN. On server variants you can install the framework via the server administration console. See this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/DLLs-not-found) for more details.

There have been no additional changes since v11.0.0 that package maintainers should be aware of.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries have already been built and uploaded. Linux binaries are still being built and will be available shortly.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

# Version 12.0.0 "Trust / Lust" 2017-05-20

## New features and enhancements

* MKVToolNix GUI: the key combination Ctrl+Shift+Space will now toggle the selection of the current item in all tree views where multiple selections are allowed. Implements #1983 (https://github.com/mbunkus/mkvtoolnix/issues/1983).
* MKVToolNix GUI: chapter editor: added the extension `*.cue` (for cue sheet files) to the "open chapter file" dialog.
* mkvmerge: cue sheet parser: if the cue sheet contains a non-empty `TITLE` entry and if no other segment title has been set yet, then the segment title will be set to the cue sheet's `TITLE` value. Implements #1977 (https://github.com/mbunkus/mkvtoolnix/issues/1977).
* mkvmerge, MKVToolNix GUI (multiplexer): added an option `--no-date` that prevents the "date" field from being written to the segment information headers. Implements one half of #1964 (https://github.com/mbunkus/mkvtoolnix/issues/1964).
* mkvpropedit, MKVToolNix GUI: header editor: added support for editing the "date" segment information field. Implements the other half of #1964 (https://github.com/mbunkus/mkvtoolnix/issues/1964).

## Bug fixes

* MKVToolNix GUI: preferences → job actions, type "play audio file": the GUI will no longer clear the audio file name input if the user aborts the audio file selection dialog.
* MKVToolNix GUI: preferences → job actions, type "play audio file", on Windows: the default "play audio" action was pointing to the wrong directory. Existing configurations with such a wrong path will be fixed automatically upon starting the GUI. Fixes #1956 (https://github.com/mbunkus/mkvtoolnix/issues/1956).
* mkvmerge: HEVC/h.265 parser: fixed the superfluous copying of the `bitstream_restriction_flag` and its dependent flags in the VUI parameters of the sequence parameter sets if the timing information is present, too. This fixes #1924 (https://github.com/mbunkus/mkvtoolnix/issues/1924) properly, and it also fixes #1958 (https://github.com/mbunkus/mkvtoolnix/issues/1958).
* mkvmerge: MPEG TS reader, AAC parser: the MPEG TS reader will now force the AAC parser to use the multiplex mode that the MPEG TS reader has detected (e.g. LOAS/LATM). This prevents the AAC packetizer from mis-detecting it in its own attempt to identify the mode. Fixes #1957 (https://github.com/mbunkus/mkvtoolnix/issues/1957).
* mkvmerge: MPEG TS reader: valid MPEG transport streams that start with an h.264/h.265 start code (e.g. a file created by cutting at an arbitrary position) were not recognized as a supported file type.
* mkvmerge: MPEG TS reader: fixed a potential read access from invalid memory addresses in the code parsing the program map table (PMT).
* mkvmerge: MPEG TS reader: if packets are encountered that belong to a PID not listed in the program map table (PMT), mkvmerge will attempt to determine their type and codec from the content. This supported content types are AAC (ADTS only) and AC-3. Fixes #1980 (https://github.com/mbunkus/mkvtoolnix/issues/1980).
* mkvmerge: MP4 reader: fixed finding and parsing the `colr` atom if there are more than one video extension atoms and the `colr` atom is not the first one.
* mkvmerge: MP4 reader: the `nclx` colour type of the `colr` atom is now recognized, too (as defined by ISO/IEC 14496-12, "ISO base media format").
* configure: fixed configure aborting if a `moc`, `uic`, `rcc` or `qmake` binary is found, but the binary's version is too old. Fixes #1979 (https://github.com/mbunkus/mkvtoolnix/issues/1979).

Have fun :)

[Selur]

Nice! Thanks for the Update!

[Mosu]

Note that due to a SNAFU in one of my build scripts the installer for both the 32 and the 64bit version claims to install v11.0.0. That's only a cosmetic error in the installer. The included binaries are v12.0.0, and they do show v12.0.0 as their version number.

I'll likely create and upload new builds for both installers later tonight. But that shouldn't prevent you guys & gals from updating now.

[Mosu]

The installers have been replaced with new builds that announce the correct version.

[hello_hello]

Note for XP users....

So far gMKVExtract 1.9.0.0 & MKVCleaver 0.7.0.1 are both working fine with MKVToolNix 12.0.0 on XP, even if mkvtoolnix-gui.exe doesn't. Whether there's an advantage to using them with MKVToolNix 12.0.0. rather than version 10.0.0, I don't know.

MeGUI has MKV and Adaptive muxers under the Tools menu, and they're functioning fine so far with MKVToolNix 12.0.0 on XP, so they could be used as an alternative GUI for muxing MKVs. Admittedly MKVToolNixGUI is probably easier to use if you do a lot of muxing, but at least they're an option if you need to mux with the most recent MKVToolNix.

mkvtoolnix-gui.exe v10.0.0 has also been working fine with mkvmerge.exe v12.0.0 so far, but you have to click the the warning message when you first run it. I don't know if it's necessarily a good idea, but it has worked in my testing so far.

Just thought I'd mention some alternatives.....

[delacroixp]

Can you run multiple instances of MKVToolNix ?

I used to find it useful to run two instances in the passed (eg Appending a short TV series into one file ... but finding that one of the files still needed to have the credits or "next week intro" split out).
I could then run a second instance without reloading the whole sequence of appended files (just modify and replace).

Thanks much ... great app ... love the new interface and customisable options.

It's all good
:) :devil: :D

[Mosu]

No, it's not possible. However, you can edit any job again. Go to the job queue, right-click on the job and select "edit in corresponding tool…" That way you won't have to re-add those files either.

Note that MKVToolNix GUI is fully multi-threaded. You can continue working with it even while jobs are running. You can also configure it not to remove/clear the settings when you start multiplexing (and if you don't want to keep the settings all the time you can just do it once by clicking on the small arrow on the "start multiplexing" and select "afterwards leave the settings as they are" from the popup menu).

Basically there are a ton of options for you to chose from. You really don't need a second instance.

[hello_hello]

Is there any way to kill the warning message MKVToolNix offers when using mkvtoolnix-gui.exe 10.0 with a newer version of mkvmerge.exe?

If there's a switch I'm happy to use it at my own risk, but when running XP, having to click through the warning for the rest of time could get annoying.

I know they're not the same version, but I only need to be told once. ;)

[Mosu]

No, there isn't.

[stax76]

maybe with autoit or autohotkey

[hello_hello]

maybe with autoit or autohotkey

There's an idea.....

Or can we have a special "say goodbye to XP" build of version 10 without the warning? That'll be the last time there'll be a need to disturb the bees in Mosu's XP bonnett, given MKVToolNixGUI will never work on XP again.
Or can AutoHotKey pretend to be a procedure entry point for d3d9.dll? :)

Anyway, I'm off to try autohotkey. I have it installed so I don't know why I didn't think of that myself (smacks self on forehead). Well, a switch would have been easier, I guess.

Don't mention XP. I mentioned it once, but I think I got away with it. ;)

[manolito]

For a much easier solution than AutoHotkey you should try one of those "clicker" applications which are mostly used to automatically click away shareware nag windows. My personal favorite is ClickOff (latest version 1.90). Has not been updated in ages, but still going strong...

Cheers
manolito

[Mosu]

Or can we have a special "say goodbye to XP" build of version 10 without the warning?

It seems I have to repeat myself over and over again: I will not spend any time on anything related to unsupported versions of Windows.

Don't mention XP. I mentioned it once, but I think I got away with it. ;)

Stop trying to be cute. Your whole post was about XP, as was your previous post, as was the one before that. You're not fooling anyone.

[stax76]

If something starts to behave weird some have to remember that some system type of apps might have side effects.

[hello_hello]

It seems I have to repeat myself over and over again: I will not spend any time on anything related to unsupported versions of Windows.

You need to lighten up. I thought following it asking if AutoHotKey could fix the procedure entry point problem would've made it obvious it was tongue in cheek question, but I had no expectation you'd have a change of heart, so self over repeating wasn't required. I was replying to someone else anyway.
Although to paraphrase one of your infamous retorts... because such opportunities are hard to resist and I'm only human.... in the time it's taken you to repeat over and over you won't support XP, you probably could have supported XP. :)

Stop trying to be cute. Your whole post was about XP, as was your previous post, as was the one before that. You're not fooling anyone.

I suspect I've asked XP related questions because I'm using XP, although I'll wait to make sure I don't unexpectedly ask Vista or Win8 related questions in the near future before I'll be confident it's the correct conclusion.
See... that could be construed as being cute. The other thing though....

Seriously... there's tribes of Amazonian pygmies still untouched by western civilization that'd know I was paraphrasing a famous line from Fawlty Towers (http://www.imdb.com/title/tt0578590/quotes) to acknowledge the fact I had mentioned XP a few times.
And the "tribes of Amazonian pygmies" line was lifted from BlackAdder (http://www.thetop100.net/the-entertainment-zone/the-top-100-blackadder-quotes/baldrick-in-the-amazonian-rain-forests-there-are-tribes-of-indians-as-yet-untou/list/z26l54i3106.aspx) in case that's somehow mistaken as not being extremely funny..

[hello_hello]

For a much easier solution than AutoHotkey you should try one of those "clicker" applications which are mostly used to automatically click away shareware nag windows. My personal favorite is ClickOff (latest version 1.90). Has not been updated in ages, but still going strong...

Cheers
manolito

I'll give it a spin. Thanks.

[stax76]

Some thoughts and questions about the command line being easy to generate by a app and easy read by a user:

D:/Software/Medien/mkvtoolnix\mkvmerge.exe --ui-language de --output ^"D:\Temp\staxrip\syl_temp\syl_out1.mkv^" --no-audio --no-subtitles --no-chapters --language 0:eng ^"^(^" ^"D:\Temp\staxrip\syl.mkv^" ^"^)^"

What do the parenthesis and caret/hat symbols mean and why are they needed?

Some additional switch might improve usability:

--only-audio
--only-subs
--only-chapters
--only-attachments
--only-track-tags
--only-global-tags

If --track-order is omitted then file and stream id order is used, it might be more user friendly when the order found in --audio-tracks and --subtitle-tracks instead of the stream id order is used.

[Mosu]

Some thoughts and questions about the command line being easy to generate by a app and easy read by a user:

D:/Software/Medien/mkvtoolnix\mkvmerge.exe --ui-language de --output ^"D:\Temp\staxrip\syl_temp\syl_out1.mkv^" --no-audio --no-subtitles --no-chapters --language 0:eng ^"^(^" ^"D:\Temp\staxrip\syl.mkv^" ^"^)^"

What do the parenthesis and caret/hat symbols mean and why are they needed?

My tools only use the standard "GetCommandLineW" Windows API function. That function provides an array, meaning some of the parsing has already been done at this point, some by cmd.exe itself, some by Microsoft's Visual C runtime library. The carets are due to Microsoft's Visual C runtime library. See this fine blog post by a Microsoft employee (https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/) for all the gritty details on how to escape for cmd.exe properly. In short: it's really, really ugly.

Therefore I highly suggest you use option files (https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.option_files) instead. They're plain JSON files following the default JSON rules. You'll find tons of libraries out there producing valid JSON output, so you won't have to worry about writing your own escaping function. That way you'll only have to provide one argument: the path to a temporary file, and you can usually get away with escaping that with quotation marks.

Some additional switch might improve usability:

--only-audio
--only-subs
--only-chapters
--only-attachments
--only-track-tags
--only-global-tags

I won't add such options. I vastly prefer my options to have as little overlap as possible. That way it's much easier to reason about for the end user. For example, an end user might wonder what happens if she used "--only-audio -s 1".

If --track-order is omitted then file and stream id order is used, it might be more user friendly when the order found in --audio-tracks and --subtitle-tracks instead of the stream id order is used.

Again, this would violate my "options don't overlap" rule from above. Additionally it violates two one of my design goals: 1. options do one thing only; 2. I won't change existing behavior unless there's a really good reason to.

[hubblec4]

@stax76

Like Mosu said: You should use the JSON Option file with all your paras.
I'm very happy about this feature, it makes my programming sooo easy.

@Mosu
Few question about the track-order-code in a JSON option file.
If no track-order-code specified then mkvmerge generate in backround a track-order-code?
The same for the "append-to-code"? What happens if this para not specified?

[Mosu]

The default order for tracks is the order in which they're found. This means that the first source file listed will have its tracks output first, in the order in which mkvmerge's identification output lists them.

Similar rules apply to the append specification. Each track in file N will be appended to the corresponding track in file N-1 (the previous one on the command line). For example, if you have two files with three tracks each, then by default track 1 from file 2 will be appended to track 1 from file 1; track 2 from file 2 will be appended to track 2 from file 1; and track 3 from file 2 will be appended to track 3 from file 1.

The design goal for these options is "do the right thing for the common case" and "don't surprise the user". Processing files in the order in which they're listed on the command line is the "don't surprise the user" part. The common case is that files that you want to append usually contain the same number of tracks in the same order; so appending them should work out of the box without having to add the option "--append-to".

The reason the GUI always adds those options is a different one. The command line generated by the GUI is not tailored towards the end user. Instead, its purpose is to be explicit and exact. It should reflect what's currently visible in the GUI. Another reason is that simplifying the command line in the GUI would require extra code that decides that the currently visible configuration allows omitting certain switches such as "--append-to". Such extra code will always mean extra possibilities for hard-to-diagnose bugs.

[hello_hello]

For a much easier solution than AutoHotkey you should try one of those "clicker" applications which are mostly used to automatically click away shareware nag windows.

I thought I'd try AutoHotkey first as I've had scripts running to do text completion for years, but that was the last time I created one so I had to refresh my memory on the basics, but in this case closing the warning message is probably about as simple as a script gets. This is doing the job so far, if anyone else is interested.

Loop {
if WinActive("Problem with MKVToolNix installation")
WinClose
}

[stax76]

Thanks for the explanation. In the past if I had 20 subtitle streams in a mkv file staxrip would write the file path 20 times to the command line. I wanted to have a command line that is shorter so I added some extra logic, today I noticed the track order is wrong with my new command line generation and I'll need to use --track-order but that is tricky to do with my code base.

json might be the most easy to use way for apps but I have doubts that it is so much easier that it justifies starting from scratch. I get tired quickly from terse curly braces syntax and I don't know if .NET 4.7 has easy to use JSON support, usually I avoid third party libraries to make my app lightweight and easy to maintain.

Probably the best thing to do for me would be not to care about what the command line looks like, write the file path for every subtitle stream etc. if it's much easier to implement. If I remember right Win 10 allows about 8000 characters in the command line and many tools staxrip uses have a 260 character limit so about 30 long paths are possible which is probably enough for all staxrip users.

[Mosu]

You don't even have to use an external library for generating a JSON option file. The escaping mechanism is dead simple: for each word, replace all single backslashes by double backslashes and all quotation marks by \". Then write it out. Waaaaay easier than getting cmd.exe escaping right.

Edit: fixed backslash escaping.

[sneaker_ger]

replace all [..] all quotation marks by "
By \". (Damn forum software.)

[Mosu]

Yeah by backslash quotation-mark. Thanks :)

Edit: geeeez, that forum software is indeed prickly. Preview loses one layer of backslashes. Fun times :)

[stax76]

Not sure what you mean with escaping, in VB.NET what I use strings don't use escape sequences, I've searched my code for caret/hat symbols and they are only ever used as arithmetic operators and in regex expressions. I'm not really a CLI interested person, I learn things to make GUIs work and forget most things quickly after unfortunately, all my life I never learned and used dos/batch more then absolutely necessary, let alone linux, I know some powershell but only us it to for building staxrip extensions.

Right now staxrip don't do any escaping in command line generation, at least nothing I remember or am aware of.

[Mosu]

Then that's a source for potential bugs. It's your prerogative to ignore that, of course.

[stax76]

I'll have to investigate it, if somebody creates an issue on the tracker I'll certainly try to fix it, mp4box has a pretty ugly issue btw., practically you can't use any file names that contain a hash sign in the file name, I cannot imagine mkvtoolnix with issues like this.

https://github.com/gpac/gpac/issues/831

[hubblec4]

The default order for tracks is the order in which they're found. This means that the first source file listed will have its tracks output first, in the order in which mkvmerge's identification output lists them.
OK. Thats clear.


Similar rules apply to the append specification. Each track in file N will be appended to the corresponding track in file N-1 (the previous one on the command line). For example, if you have two files with three tracks each, then by default track 1 from file 2 will be appended to track 1 from file 1; track 2 from file 2 will be appended to track 2 from file 1; and track 3 from file 2 will be appended to track 3 from file 1.

Ok, clear too to me. But when the track order of such files has changed then I have to write a --track-order and --append-to switch?

Short sample:
Two(or more) VOB files with
1. Track video
2. Track audio(eng)
3. Track audio(ger)

Now I want to change the order of the audio streams

2. Track audio(ger)
3. track audio(eng)

(I know for the VOBs there is an option "other files" and I have to use these option but also I must use the normal append option too.)




The reason the GUI always adds those options is a different one. The command line generated by the GUI is not tailored towards the end user. Instead, its purpose is to be explicit and exact.
I like "explicit and exact" things. The command line preview is a very nice feature for me. I can quickly compare my generated JSON option file.

[sneaker_ger]

Ok, clear too to me. But when the track order of such files has changed then I have to write a --track-order and --append-to switch?

Short sample:
Two(or more) VOB files with
1. Track video
2. Track audio(eng)
3. Track audio(ger)

Now I want to change the order of the audio streams

2. Track audio(ger)
3. track audio(eng)
--append-to works with input file/track IDs so the order does not need to be changed if you only want to change the output order. Only change --track-order.