MKVToolNix v24.0.0 released [Archive]

Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers > MKVToolNix v24.0.0 released

PDA

View Full Version : MKVToolNix v24.0.0 released

Pages :1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889[90]919293949596979899100101102103104105

Mosu

19th December 2016, 20:08

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

19th December 2016, 20:21

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

Mosu

19th December 2016, 20:28

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

19th December 2016, 20:43

So the up-to-date options should be:

--identify
--identification-format json

instead of just:

--identify-verbose

Did I get this right?

Mosu

19th December 2016, 20:45

That's correct, yes.

gpower2

22nd December 2016, 17:56

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

22nd December 2016, 18:01

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

22nd December 2016, 18:10

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

22nd December 2016, 18:21

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

Mosu

22nd December 2016, 18:38

New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are up. They include the --gui-mode enhancement to mkvextract I've mentioned.

Mosu

27th December 2016, 13:11

This is a more substantial release. There were a lot of enhancements to the GUI all over the place, several bug fixes in mkvmerge, a couple of enhancements there, too.

Note that this release deprecates the options (e.g. "--identify-verbose") and features. These are scheduled to be removed early in 2018. See the first top-most entry in the ChangeLog below for details.

Notes for package maintainers: MKVToolNix now requires a compiler that supports certain features of the C++14 standard. For gcc v4.9.x or later will work, for clang v3.4 or newer is required. Additionally Qt v5.3.x is now required.

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

The Windows and Mac OS binaries have been built already and are available for download. The Linux binaries will be available later today.

Here's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since v9.6.0:

2016-12-27 Moritz Bunkus <moritz@bunkus.org>
* Released v9.7.0 "Numbers".
* Deprecation warning: Several options and features are now deprecated and will be removed at the start of 2018. These are: - mkvmerge: the options "--identify-verbose", "--identify-for-gui", "--identify-for-mmg" and "--identification-format verbose". Please convert existing users of these interfaces to use mkvmerge's JSON identification output which can be invoked with "--identification-format json --identify ". - all command line tools: the old, proprietary format used for option files. Please convert users of this interface to the new JSON option file format introduced in this release. - all command line tools: the option "--check-for-updates" (the GUI will keep its online check for updates, though). There is and will be no equivalent interface in the tools themselves. Users of this interface can switch to retrieving the information about available updates directly from the MKVToolNix website. The information is available as JSON and XML files at the following URLs: https://mkvtoolnix.download/latest-release.json.gz https://mkvtoolnix.download/latest-release.xml.gz

2016-12-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added a new track property in JSON/verbose identification mode called "multiplexed_tracks". It's an array of track IDs that describe which of the tracks mkvmerge reports as separate ones were originally part of the same source track (e.g. TrueHD+AC-3 in a single track in MPEG transport streams). Implements #1835 (https://github.com/mbunkus/mkvtoolnix/issues/1835).

2016-12-23 James Almer <jamrial@gmail.com>
* mkvmerge: added support for skipping APE(v2) tags in TTA files.

2016-12-22 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: enhancement: added support for reporting progress in --gui-mode the same way mkvmerge does.
* mkvmerge: bug fix: when using --track-order without specifying all tracks, the track numbers could end up in a way the user did not expect. Now mkvmerge will always assign track numbers for those tracks that are listed in --track-order first. The other tracks are assigned numbers afterwards. Fixes the second part of #1832 (https://github.com/mbunkus/mkvtoolnix/issues/1832).
* mkvmerge: bug fix: when reading Matroska files the movie title was always taken from the first Matroska source file, even if that file didn't have a title set. Fixes one part of #1832 (https://github.com/mbunkus/mkvtoolnix/issues/1832).

2016-12-19 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: all command line tools can now read JSON-formatted option files. Such a file's name must have an extension of ".json" (e.g. "mkvmerge @options.json"). Its content must be a valid JSON array consisting solely of JSON strings.

2016-12-17 Moritz Bunkus <moritz@bunkus.org>
* build system: building the GUI components of MKVToolNix now requires Qt v5.3.0 or newer.

2016-12-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: header editor & job output enhancement: added menu entries for saving or closing all open tabs.

2016-12-13 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: added menu entries for saving or closing all open tabs.
* build system: MKVToolNix now requires a compiler that supports the following features of the C++14 standard: "std::make_unique()", "digit separators", "binary literals" and "generic lambdas". For the GNU Compiler Collection (gcc) this means v4.9.x or newer; for clang it means v3.4 or newer.

2016-12-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPEG TS/MPLS reader improvements: added support for subtitle tracks that are referenced from the MPLS file as sub-paths in other M2TS files than the main tracks.

2016-12-08 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: re-worked the startup code not to use lock files when trying to open a socket for communicating with an already-running instance. This aims to prevent situations with stale lock files not being cleaned up and the GUI not starting anymore as a result. This might fix or prevent issues like #1805 (https://github.com/mbunkus/mkvtoolnix/issues/1805).
* mkvmerge: teletext subtitle bug fix: fixed the handling of DVB teletext subtitles signaled with data unit ID 0x02 and that contain pages from multiple magazines.

2016-12-05 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: multiplexer enhancement: the file identification process has been re-written to be properly multi-threaded. This allows the user to continue working with the GUI while e.g. playlists from a Blu-ray are identified.

2016-12-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge can now handle Blu-ray playlists from the "BACKUP" sub-directory of a Blu-ray disc.
* MKVToolNix GUI: new multiplexer feature: added a menu entry for copying the title to the destination file name. It will replace the destination file's base name but keep its path & extension.
* MKVToolNix GUI: new multiplexer feature: all positive file identification results will now be cached between runs. This speeds up adding the same file a lot, especially when scanning the same Blu-ray playlists again. Cached results are invalidated automatically with newer MKVToolNix releases or when the source file changes.

2016-12-02 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: multiplexer enhancement: when the user tries to add one of the main Blu-ray index files (index.bdmv, MovieObject.bdmv) the GUI will automatically scan the Blu-ray playlist files and offer them for selection.
* mkvmerge: bug fix: files smaller than 4 bytes were wrongly identified as MPEG transport streams.
* MKVToolNix GUI: multiplexer enhancement: tracks, chapters, tags, attachments not selected for multiplexing will be displayed the same way as other disabled controls. Implements #1819 (https://github.com/mbunkus/mkvtoolnix/issues/1819).

2016-11-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the MPEG transport stream reader was using an outdated format for the "CodecPrivate" element for HDMV TextST subtitles. This has been updated to the current format which only contains the "dialog style element". Existing Matroska files using this outdated scheme can be fixed by running them through mkvmerge v9.6.0 itself or any later release as the old format is automatically converted to the new one when it is read from Matroska files.

Have fun :)

ndjamena

27th December 2016, 13:56

um...

The 64 bit installer on fosshub points to:
Downloads\Programs\audacity-win-2.1.2.exe

I downloaded it, it's definitely audacity.

Mosu

27th December 2016, 14:00

*sigh* I'll contact their support. Thanks for the heads-up.

Edit: doesn't happen to me at the moment. Please try another browser or clear cookies for FossHub, then reload the MKVToolNix download site on FossHub.

ndjamena

27th December 2016, 14:03

It's corrected.

hubblec4

27th December 2016, 22:41

Hi Mosu
Thanks alot for your hard work.

* all: new feature: all command line tools can now read JSON-formatted option files.
Such a file's name must have an extension of ".json" (e.g. "mkvmerge @options.json").
Its content must be a valid JSON array consisting solely of JSON strings.

Thats sounds interessting. How different is it to the old option.file.
Could you provide some samples?

Mosu

27th December 2016, 22:48

Well, just use the same options you've used before and encode them as a JSON array. There are tons of libraries out there, probably more than one for each programming language. Just use one :) That's the biggest advatange of using a standard file format: you don't have to roll your own string encoding code for mkvmerge's old, proprietary format.

If you want to know how such a file looks, just run the GUI, set up the job the way you want it, use the "show command line" functionality and select the JSON escape mechanism.

Mosu

27th December 2016, 23:30

Here's v9.7.1, a hotfix for v9.7.0, which in turn was a more substantial release. There were a lot of enhancements to the GUI all over the place, several bug fixes in mkvmerge, a couple of enhancements there, too.

The Windows and Mac OS binaries have been built already and are available for download. The Linux binaries will be available later today.

Here's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since v9.6.0:

2016-12-27 Moritz Bunkus <moritz@bunkus.org>
* Released v9.7.1 "Pandemonium".
* MKVToolNix GUI: multiplex tool bug fix: under certain circumstances the GUI was creating invalid JSON files when starting to multiplex resulting in an error message ("JSON option files must contain a JSON array consisting solely of JSON strings").
* Released v9.7.0 "Numbers".
* Deprecation warning: Several options and features are now deprecated and will be removed at the start of 2018. These are: - mkvmerge: the options "--identify-verbose", "--identify-for-gui", "--identify-for-mmg" and "--identification-format verbose". Please convert existing users of these interfaces to use mkvmerge's JSON identification output which can be invoked with "--identification-format json --identify ". - all command line tools: the old, proprietary format used for option files. Please convert users of this interface to the new JSON option file format introduced in this release. - all command line tools: the option "--check-for-updates" (the GUI will keep its online check for updates, though). There is and will be no equivalent interface in the tools themselves. Users of this interface can switch to retrieving the information about available updates directly from the MKVToolNix website. The information is available as JSON and XML files at the following URLs: https://mkvtoolnix.download/latest-release.json.gz https://mkvtoolnix.download/latest-release.xml.gz

2016-12-23 James Almer <jamrial@gmail.com>
* mkvmerge: added support for skipping APE(v2) tags in TTA files.

2016-12-17 Moritz Bunkus <moritz@bunkus.org>
* build system: building the GUI components of MKVToolNix now requires Qt v5.3.0 or newer.

2016-12-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: header editor & job output enhancement: added menu entries for saving or closing all open tabs.

Have fun :)

hubblec4

27th December 2016, 23:45

Yes, JSON format is very cool :-). I need only two lines of code for reading values.

There is a small different, in JSON format is no "escape mechanism". That makes it easier to generate such an option file.

Mosu

27th December 2016, 23:58

Well, you still have to escape " and \ with \, but the JSON libraries usually do that for you already, and you don't have to do it yourself.

Brazil2

28th December 2016, 08:39

https://mkvtoolnix.download/downloads.html#windows
Supported Windows versions are Vista and newer.

https://github.com/mbunkus/mkvtoolnix/wiki/Officially-supported-operating-systems-and-versions
Windows
Supported are all desktop versions of Windows (meaning Intel architecture) that Microsoft supports. This means Windows Vista or newer, 32bit and 64bit architectures.

So what is the latest version to officially support Windows XP ?
I can't find this info in the News history, there is a lot about Linux but nothing about Windows.

Mosu

28th December 2016, 09:13

Well… the version that was current around the time when Microsoft's extended support ended, which was in April 2014. That would be v6.9.1. Some of the newer versions are known not to work, some others are known to work.

The reason I'm adding news entries about the supported Linux versions is that I offer binaries for those versions, and the news entries are supposed to indicate which versions I stop offering binaries for. Traditionally on Linux you have to build one package for each operating system & version, unlike Windows where you usually only have a single binary that runs on all of them. So there are binaries that might still run on XP, but as I don't have XP anymore I cannot test it (and wouldn't even if I still had XP).

Just assume that I don't offer support for Windows versions for which Microsoft's extended support has ended. However, saying that i "support" Vista would be disingenious; I don't, really, as I don't have such an installation and don't intend to set one up in case of bug reports for Vista, even though Microsoft's extended support for Vista ends in April 2017.

Brazil2

28th December 2016, 11:18

OK, thanks for the info.

Latest mention to XP in the changelog was for version 8.0.0:
2015-06-19 Moritz Bunkus <moritz@bunkus.org>
* Released v8.0.0.
* all: the detection whether or not the applications are installed on Windows is done by checking for the presence of a special file in the program folder instead of checking for an entry in the registry written by the installer. This enables users to try new portable versions without having to uninstall an installed version first as their settings will be kept separate now. A side effect is that compatibility with Windows XP should be restored.

For the record, I've just tried latest mkvtoolnix-32bit-9.7.1.7z build on XP SP3 with all updates and it still works pretty fine :)

Inviska

29th December 2016, 16:20

I want to transition to Linux but I couldn't find a Linux GUI for MKVExtract. On Windows I use MKV Cleaver, so I thought I'd do something similar in C++/Qt:

http://www.inviska.com/mkvextract/

It's mostly the same as MKV Cleaver but with a few additions, like it shows all elements in the file tree instead of just video, audio and subtitle tracks.

I just had one question about supported codecs and output file formats. Some codecs, such as A_DTS, aren't listed in the MKVExtract documentation (https://mkvtoolnix.download/doc/mkvextract.html#mkvextract.output_file_formats), even though MKVExtract can successfully extract them. I looked at the supported codecs in the Matroska documentation and made a list of the ones not present in the MKVExtract documentation. For the below codecs I was wondering if you could tell me if MKV Extract can extract them, and if so what extension should be used for the outputted file:

/*******************************************************
Codec ID Extension Name
********************************************************
V_UNCOMPRESSED ??? Uncompressed
V_MPEG4/ISO/SP ??? DivX4
V_MPEG4/ISO/ASP ??? DivX5/Xvid/FFMPEG
V_MPEG4/MS/V3 ??? Microsoft MPEG4 V3
V_MPEG1 ??? MPEG1
V_MPEG2 ??? MPEG2
V_QUICKTIME ??? QuickTime Video
V_PRORES ??? Apple ProRes

A_MPEG/L1 ??? MPEG Layer I
A_PCM/INT/BIG ??? PCM
A_PCM/FLOAT/IEEE ??? PCM Floating Point
A_MPC ??? MusePack
A_MS/ACM ??? Microsoft ACM
A_QUICKTIME ??? QuickTime Audio

S_TEXT/WEBVTT ??? WebVTT
S_IMAGE/BMP ??? Bitmap

Sorry if this is a stupid question. I don't know much about video/audio formats. I mostly use MKVToolnix to extract subtitles from one video, retime them and mux them into another source.

Thanks for your help, and thanks for the great work on MKVToolnix.

Mosu

29th December 2016, 16:32

I want to transition to Linux but I couldn't find a Linux GUI for MKVExtract. On Windows I use MKV Cleaver, so I thought I'd do something similar in C++/Qt:

Nice :)

Note that mkvextract doesn't care about the file extension. It'll happily write TrueHD data to a file called "audio.dts". Naming is up to the caller of mkvextract.

Here's the list:

/*******************************************************
Codec ID Extension Name
********************************************************
V_UNCOMPRESSED ??? unsupported
V_MPEG4/ISO/SP ??? unsupported
V_MPEG4/ISO/ASP ??? unsupported
V_MPEG4/MS/V3 ??? unsupported
V_MPEG1 mpg, mpeg MPEG elementary stream (there's no real standard for the extension)
V_MPEG2 mpg, mpeg MPEG elementary stream (there's no real standard for the extension)
V_QUICKTIME ??? unsupported
V_PRORES ??? unsupported

A_MPEG/L1 mp1 (?) MPEG Layer I
A_PCM/INT/BIG wav PCM (Big Endian audio is byte-swapped to Little Endian upon extraction)
A_PCM/FLOAT/IEEE ??? unsupported
A_MPC ??? unsupported
A_MS/ACM ??? unsupported
A_QUICKTIME ??? unsupported

S_TEXT/WEBVTT ??? WebVTT (this is a custom format invented by myself only readable by mkvmerge, hence there's no real extension)
S_IMAGE/BMP ??? unsupported

Inviska

29th December 2016, 18:30

Nice :)

Note that mkvextract doesn't care about the file extension. It'll happily write TrueHD data to a file called "audio.dts". Naming is up to the caller of mkvextract.

Here's the list:

Thanks a lot for the help. I'll update it with that information and upload a final version.

Then I'll flounder around in Linux and make a Linux build :)

Thanks again.

hello_hello

30th December 2016, 03:08

I want to transition to Linux but I couldn't find a Linux GUI for MKVExtract. On Windows I use MKV Cleaver, so I thought I'd do something similar in C++/Qt:

http://www.inviska.com/mkvextract/

One step closer to leaving Windows behind. I'm looking forward to it.
Thank you.

hello_hello

30th December 2016, 03:26

MKVToolNixGUI doesn't seem to be displaying the status of a default subtitle track correctly if it's forced. I don't know if that's expected behaviour but it behaves differently for an audio track, where if it's the default track and forced it displays both.

Open an MKV with a subtitle track.
Set the subtitle track to default and forced
Mux
Open the newly created MKV. The subtitle track doesn't show as default.

I checked a few different versions of the new GUI and they all behave the same way. When opening the MKV with MKVMergeGUI 7.8.0 the subtitle track will display as both default and forced.

Thanks.

Mosu

30th December 2016, 10:24

Hey,

MKVToolNixGUI doesn't seem to be displaying the status of a default subtitle track correctly if it's forced.

Works just fine for me. I've retraced your steps, and in the resulting Matroska file both flags are set.

Note that the multiplexer shows what the flags will be in the output file, not what they're set to in the source file. The user is usually interested in the outcome, not in the current status.

To verify the flags' actual status use the header editor. The "default track" element should be either absent from the file or present and set to "yes" (being absent means that the flag's default value comes into play, and the default value for the "default track" flag is "yes"). The "forced track" flag should be present and set to "yes".

You should also check the preferences: "Multiplexer" → "Default values" → "Disable 'default track' flag for subtitles".

Ripman

30th December 2016, 18:17

Thanks for the new release.

With the implementation of json options files does that mean that the legacy options files are no longer supported? Can I still use legacy options files or do I need to update everything to json? Thanks.

Mosu

30th December 2016, 18:24

I'll refer you back to the release announcement where I've spelled out what's deprecated and when those things will be removed.

hello_hello

31st December 2016, 01:24

You should also check the preferences: "Multiplexer" → "Default values" → "Disable 'default track' flag for subtitles".

That was the problem. Thanks. I guess I forgot you could mux MKVs and they'd appear to be different when opened them again.... at least in respect to subtitle streams.

Mosu

31st December 2016, 09:16

Again, those two columns represent the status of the flags as it will be in the output file. The flags could be different from what they were in the source file even if that preferences option is disabled. For example, when a file contains multiple audio tracks all with "default track" flag set (e.g. produced by a buggy program other than mkvmerge), the GUI would still only show one of those tracks having the "default track" flag set in the output file because that's what mkvmerge will do, too.

The "multiplex" tool is the wrong tool for the job of checking the flags' current status!

Vincent Vega

31st December 2016, 19:55

hello Moritz, happy new year, thank you again for all the hard work over the years!!

so i have this lpcm 5.1 track in m2ts (pcm_bluray), if i remux that m2ts to mkv SL ends up as SR, and SR->SL, why is this happening?
alternatively, if i first demux the audio to wav by eac3to, then use that as input for muxing then channels play same way as in m2ts.
eac3to log also mentioned something about channel swapping/remapping, thats probably relevant.

second part of the question, as long as the lpcm tarck is inside m2ts the two surround channels are reported by LAV as SL/SR, if remuxed to mkv LAV still does see them as SL/SR, however AC3filter reports them now as BL/BR.

i could send you a sample of the file but not sure what tool is recommended nowadays for cutting m2ts so pls let me know

ndjamena

1st January 2017, 01:58

For 5.1, SL/SR and BL/BR are exactly the same thing. They're only distinct positions for 7.1 or above.

Mosu

1st January 2017, 10:51

so i have this lpcm 5.1 track in m2ts (pcm_bluray), if i remux that m2ts to mkv SL ends up as SR, and SR->SL, why is this happening?

Probably because the channel mapping on Blu-ray differs from the one normally used for PCM in WAVs. I don't know much about channel mappings, to be honest. Matroska doesn't have proper support for it yet. There was a discussion about it (https://mailarchive.ietf.org/arch/msg/cellar/HzxRVJouLAtFitvTMWF_ZbHuoKE) a couple of months ago, but nothing came from it.

alternatively, if i first demux the audio to wav by eac3to, then use that as input for muxing then channels play same way as in m2ts.
eac3to log also mentioned something about channel swapping/remapping, thats probably relevant.

Interesting. If you want something similar in mkvmerge, then please open a ticket for it (https://github.com/mbunkus/mkvtoolnix/issues/). I won't have a high priority for me, though.

No idea.

hello_hello

1st January 2017, 11:52

I guess I'm used to muxing with mkvtoolnix, and after opening the output file, the way the tracks were set when muxing are always the same.
I simply forget there was an option in preferences to force subtitles to be a non-default tracks, because I rarely set subtitles as default (hence having the option enabled). My fault for having a bad memory.

Cheers.

Mosu

1st January 2017, 11:55

There are several other options in the preferences that change how a newly added track's attributes are set, especially around the language. The multiplexer tool is a really bad way to check the state of a file :)

Vincent Vega

1st January 2017, 21:59

hi Mosu thanks for reply,
so for quick solution for now, using eac3to to wav/flac first, like i did this time, is what you'd recommend as workaround?
also, this channel mapping issue only pertains to lpcm muxing or any other formats affected too?

couple other things, since i rarely visit -)
about a year ago there was this x265vfw release which i often still use for quick reencodes in virtualdub.
the resulting avi plays fine by lav filters (just need to set fourcc option to HEVC in encoder settings).
however if i remux that avi to mkv i get jerky/stuttery playback. did you ever try that?

and about muxing speeds,
i've been using this nice skylake platform this past year, spacious ramdisk and nvme raid0 array @3GByte/s r/w.
cool thing remuxing mkv->mkv from ramdisk -> the raid0 i get these top speeds of 2GB+ as expected.
but remuxing m2ts->mkv is much slower, never seen peaks of more than 500-600MByte/s, and most of the time even slower.
is that some kind of software bottleneck for m2ts sources? anything i can do in the setup/settings to improve that?
(i'm using 64bit installer mkvtoolnix)

Mosu

1st January 2017, 22:10

so for quick solution for now, using eac3to to wav/flac first, like i did this time, is what you'd recommend as workaround?

Yes.

also, this channel mapping issue only pertains to lpcm muxing or any other formats affected too?

As far as I know there are formats for which the channel mapping is part of the specs or part of the bitstream format. For PCM there's no such standard. It's possible that there are other audio formats for which this is a problem, too. Maybe others can chime in with more knowledge.

about a year ago there was this x265vfw release which i often still use for quick reencodes in virtualdub.
the resulting avi plays fine by lav filters (just need to set fourcc option to HEVC in encoder settings).
however if i remux that avi to mkv i get jerky/stuttery playback. did you ever try that?

No. I don't encode on Windows. I'm not particularly interested in trying this combination either. Sorry.

but remuxing m2ts->mkv is much slower, never seen peaks of more than 500-600MByte/s

M2TS is very CPU intensive to parse due to its many small packets and how they're set up. Other formats are much less CPU intensive to parse, among them MP4, Matroska, AVI… There's nothing you can do about it on your end.

Edit: mkvmerge isn't the most efficient program on the planet. I usually focus more on correctness (bug fixing) & features than on performance.

hello_hello

2nd January 2017, 12:56

I thought I was losing my mind.

I was playing around with the default option for streams of an undefined language nature, and eventually discovered when I opened an MKV with undefined language streams for the first time, MKVToolNix would apply the set language. If I changed the default language and opened the same file again it kept assigning the language I'd set previously.

The relevant part from the 9.7.1 mkvtoolnix-gui.ini file:

[defaults]
defaultAudioTrackLanguage=abk
defaultVideoTrackLanguage=eng
defaultSubtitleTrackLanguage=eng
defaultChapterLanguage=und
defaultChapterCountry=
defaultSubtitleCharset=
defaultAdditionalMergeOptions=--disable-track-statistics-tags
whenToSetDefaultLanguage=1

Version 9.6.0 and 9.7.1 both opening the same MKV.

https://s23.postimg.org/inx4twe0n/960.gif (https://postimg.org/image/inx4twe0n/)

https://s23.postimg.org/p2w5qkkqf/971.gif (https://postimg.org/image/p2w5qkkqf/)

After much banging of my head on the desk I finally discovered the "MKVToolnix\cache" folder and I are now enemies for life. :(

As a side note, I was a little careless at one stage and accidentally opened mkvtoolnix-gui.exe via the Explorer SendTo menu.
Is that what's referred to an an easter egg? I tried remuxing it, but didn't have any luck.

https://s23.postimg.org/xilq82nlj/mkvtoolnix.gif (https://postimg.org/image/xilq82nlj/)

I'm using the 32 bit portable version of MKVToolNix running on........................................... XP.

Mosu

2nd January 2017, 13:00

I was playing around with the default option for streams of an undefined language nature, and for some reason when I opened an MKV with undefined language streams for the first time, MKVToolNix would apply the set language. If I changed the default language and opened the same file again it kept assigning the language I'd set previously.

After much banging of my head on my desk I finally discovered the "MKVToolnix\cache" folder and I are now enemies for life. :(

Oh yikes, that's definitly a bug. The caching seems to happen after the defaults are set whereas it should happen before that. I'll look into it. Thanks for finding the cause.

Mosu

2nd January 2017, 13:30

Should be fixed now. New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are up.

Perenista

2nd January 2017, 17:16

I am having a problem with MKVToolnix, I am sure there's an easy explanation for it, yet I don't see the logic behind. I'd appreciate if you can explain briefly what I am doing wrong.

I am using an emulator (ePSXe), plus Fraps, to record at 1080p@60fps. Then I used VirtualDub to save the AVI, using these settings:

http://i.imgur.com/mo6Y9p6.png

So far I managed to save 5 hours and over 35 GB. All files were created (by FRAPS) as huge AVIs, then reencoded as AVI again, and I used MKVToolnix to save that AVI as MKV.

After that, when two MKVs were available, I used the option "Append".

For example:

- Fraps records file A1.avi.
- Reencoded as AA1.avi using the Imgur settings
- Opened AA1.avi in MKVToolnix, saved as MKV.

- Fraps records file A2.avi.
- Reencoded as AA2.avi using the Imgur settings
- Opened AA2.avi in MKVToolnix, saved as MKV.

--> Opened AA1.mkv in MKVToolnix, then option Append + selected AA2.mkv.

--> Saved as a single MKV.

I repeated this process until the MKV had 35 GB and over 5 hours.

This worked just fine until my last recording.

In the last recording I disabled the Game Shark code (only one code was being used), and proceeded with the recording using FRAPS, in the same way as before.

This is what I did:

- Fraps records file LAST-1.avi.
- Reencoded as LAST-2.avi using the Imgur settings
- Opened LAST-2.avi in MKVToolnix, saved as MKV.

- Opened LAST-2.mkv in MKVToolnix and specified this:

- Output, Split mode:
After output duration: 00:05:00
Maximum number of files: 2

Why did I do that?

Because the first 5 minutes from LAST-1.avi aren't going to be used. If the file has 10 minutes, that means MKVToolnix will create two files:

LAST-2 (001).mkv (first 5 minutes)
LAST-2 (002).mkv (last 5 minutes)

So after this I did the following:

Opened HUGEFILE.mkv, option Append >>>>>> LAST-2 (002).mkv

And this is what went wrong:

*******
The track number 0 from the file 'G:\LAST-2 (002).mkv' cannot be appended to the track number 0 from the file 'G:\HUGEFILE.mkv'. The track parameters do not match.
*******

Why?

sneaker_ger

2nd January 2017, 17:22

Show us the MediaInfo logs of "HUGEFILE.mkv" and "LAST-2 (002).mkv". Are the resolutions identical?

Mosu

2nd January 2017, 17:23

Please post the _full_ output produced by mkvmerge, not just that line.

Perenista

2nd January 2017, 19:25

Show us the MediaInfo logs of "HUGEFILE.mkv" and "LAST-2 (002).mkv". Are the resolutions identical?I discovered that the last recording was in the 1920x1186 resolution instead of 1920x1182. I didn't even bother to look, since all my recordings were using 1920x1182.

That's odd, it must have been some glitch in Fraps or I accidentally changed the window size. I am playing using the Window mode, to make sure it is recording.

I asked if removing a piece from the video could create that error because that was exactly my first suspicion. All files are reencoded the same way.

Mosu

2nd January 2017, 19:40

I asked if removing a piece from the video could create that error because that was exactly my first suspicion.

Definitely not, no.

hello_hello

2nd January 2017, 23:30

Should be fixed now. New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are up.

Yes the language settings appear to be behaving now.

Thanks.

hello_hello

3rd January 2017, 01:17

I may have spoken too soon. Now chapters are displaying oddly. I don't seem to be able to blame the cache folder this time and I can't see a setting that would cause it. The stable version of 9.7.1 doesn't do this, just the pre-build. Pictures to explain. These are the same MKV.

https://s28.postimg.org/ph78ih9g9/Merge1.gif (https://postimg.org/image/ph78ih9g9/)

https://s28.postimg.org/qi7h7lqft/Merge3.gif (https://postimg.org/image/qi7h7lqft/)

kuchikirukia

3rd January 2017, 09:06

I highlighted the problem. Aegisub does not show what's in the file. Use a lower level tool like mkvinfo for analyses of such problems and like Mosu said you will see mkvmerge does not alter the ASS timings.
Now the interesting part is Aegisub's behavior when it comes to different audio formats. It reacts to delayed Opus in a strange way which I believe may be unintended (even when keeping encoder delay in mind). The underlying ffms2 should be able to handle delays more cleanly. Maybe I will look closer and report to Aegisub team later.

/edit:
It's related to the 80ms Opus pre-roll. If delay is less than 80ms Aegisub will skew the subtitle timings according to audio delay. Maybe it's a hack that is ugly but intended. Have to ask them...

It does it with TrueHD too.

- Split double episode m2ts w/ TrueHD into individual episodes
- Time subs for second ep in Aegisub
- mux with mkvmerge
Result: Timings are off on playback and re-import into Aegusub

MKVToolNix v24.0.0 released [Archive] - Page 90 (2025)