MKVToolNix v24.0.0 released

[hubblec4]

Originally Posted by Mosu

I don't want to change an established format; I'd run the risk of existing applications that parse the format to fail. Sorry.

Why and how should a better precision break other tools?

The nanoprecision is used but filled with zeros.
When you change the entry from
01:48:06.240000000 to
01:48:06.240123456 what should happens?

Or could you add a SimpleTag for the FPS?

hubble

[Mosu]

Believe me, my experience is that parsers break in the most interesting ways. For example: extending the number of digits will change their meaning. If a parser simply parses everything after the . as a number and then treats that number as meaning "milliseconds", then this works nicely with the current format. However, it will break horribly if I extend the number of digits because suddenly there are nine digits that the existing parser still treats as milliseconds even though they're supposed to be nanoseconds now.

It's just too risky.

No, I won't add other tags at the moment either. Sorry.

[filler56789]

@Mosu:

http://forum.videohelp.com/threads/3...act-MKVCleaver

0_o

[Mosu]

@fillter56789: I've created builds where I've re-defined the maximum number of chunks to 1024. The resulting maximum AVI file size should be 1 TB. I haven't tested it, though, as I don't have files that big.

[filler56789]

Originally Posted by Mosu

@fillter56789: I've created builds where I've re-defined the maximum number of chunks to 1024. The resulting maximum AVI file size should be 1 TB. I haven't tested it, though, as I don't have files that big.

Many thanks for the attention.

[ChaosKing]

With the old version MKVToolNix (mmg) it was possible to copy the command line that was used/generated by mmg. Is this still possible with the new gui? I can't see such option there.

Edit:
I'm blind! Found it under "Multiplexer"

[sneaker_ger]

"Multiplexer">"Show command-line". There's a button "Copy to clipboard".

[gpower2]

I believe I stumbled upon a bug in the mkvmerge --identify output. With certain mkv files (created with MKVToolNix v9.3.1 in case it is relevant) mkvmerge --identify returns an output that contains two lines for the last track instead of one.
For example, I get the output:

Track ID 7: subtitles (SubRip/SRT) [codec_id:S_TEXT/UTF8 codec_private_length:0 default_track:0 enabled_track:1 forced_track:0 language:spa minimum_timestamp:7508000000 number:8 text_subtitles:1 track_name:Spanish
 uid:11397892480729494287]

instead of:

Track ID 7: subtitles (SubRip/SRT) [codec_id:S_TEXT/UTF8 codec_private_length:0 default_track:0 enabled_track:1 forced_track:0 language:spa minimum_timestamp:7508000000 number:8 text_subtitles:1 track_name:Spanish uid:11397892480729494287]

I made a quick fix for it in gMKVExtractGUI's parser, but I wanted to report it here in case a better fix could be made.

PS.
I could upload a test file to your ftp if you'd like.

[Mosu]

Looks like mkvmerge isn't escaping newlines. You still should use the JSON output, though…

[gpower2]

I will, at some point, write the parser for the JSON output, however since I'm going for backwards compatibility, I have to be really carefull not to break the existing code and I have to decide which MKVToolNix version and afterwards I will read the JSON output instead of the plain text one.

Are you thinking of deprecating the plain text output at some point?

[Mosu]

I'm definitely planning on deprecating the verbose info API at some point, yes. This particular bug just highlights one of the reasons why; it's a custom format with custom code and custom bugs. It's a rather bad case of NIH syndrome, and the only excuse I have is not wanting to use XML back when I introduced it.

BTW, I'm not sure whether or not I will fix the aforementioned bug. It would require adding more custom codes to the escaping mechanism; I'm simply not convinced that it's actually worth it.

[gpower2]

Fair enough, I'll get to implementing the JSON parser then!
Thanks for the heads up!

[Mosu]

I may actually deprecate the --identify-verbose, --identify-for-gui (similar to --identify-verbose but always in English and never translated) and --identify-for-mmg (old alias for --identify-for-gui) options in the next release. If I do, I won't actually remove the options for another year.

This reminds me that I should really do something about option files, too. Option files use the same escaping functions that --identify-verbose does, meaning that it's currently impossible to use option files to embed line feeds and other special characters. Not that that's actually useful, and no one has ever complained about it, but I will likely introduce JSON as another possible format for option files.

[gpower2]

So the up-to-date options should be:

--identify
--identification-format json

instead of just:

--identify-verbose

Did I get this right?

[Mosu]

That's correct, yes.

[gpower2]

I finally got to set up a VM with Ubuntu in order to check gMKVExtractGUI on Linux. Users reported that the progress bar didn't update while the tracks were extracting.
After a lot of head banging, I realized that mkvextract on Linux writes to Standard Output the string "Progress:###%" followed by the "\r" character instead of "\n".
Unfortunately that really ties my hands since .NET only has an event to read the Standard Output line by line.
Is there any way that this behaviour could change? Or could you offer me an alternative solution for checking on progress? How do you do it in MKVToolNix GUI?

[Mosu]

Well, I'm not a .NET developer, but I'm pretty sure it offers an API for reading output character by character. Just tell mkvextract to use UTF-8 as the output character set, read character by character, and determine a line terminated as soon as either \r or \n arrives.

With mkvmerge the GUI uses the special option "--gui-mode". In that mode mkvmerge ouputs certain lines only meant for consumption by a GUI. The progress is handled via such lines. The output looks like this:

mkvmerge v9.6.0 ('Slave To Your Mind') 64bit
…
'v.avi' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 640/352.
#GUI#progress 3%
#GUI#progress 100%
#GUI#progress 100%

The cue entries (the index) are being written...
Multiplexing took 0 seconds.

mkvextract doesn't have such an option for such a mode at the moment. I may add one one day.

It's not a problem for MKVToolNix GUI yet as it doesn't offer an extraction mode yet.

[Mosu]

Addendum: I'm currently implementing progress output in GUI mode for mkvextract. The lines will look the same way as the ones I've shown above. They're terminated with a new line character (\n).

[gpower2]

Well that would be great! Thanks a lot for digging into this!

[Mosu]

New pre-builds for Windows are up. They include the --gui-mode enhancement to mkvextract I've mentioned.