MKVToolNix v24.0.0 released

[ndjamena]

Actually, you're talking about variable frame rate. The track statistics tags were my fault, and "gaps in the file" was one of Mosu's major reservations about implementing any kind of statistics... VFR can't cause those kind of problems.

[sneaker_ger]

Gaps imply variable framerate, i.e. difference between timecode_x and timecode_x+1 is not constant.

[ndjamena]

If I append three episodes of a TV show, episodes 1 and 3 have audio commentaries as a secondary track, episodes 2 doesn't. There will be a rather large gap in the secondary audio stream that can't be written off a simple VFR.

Are you sure you're not thinking of MP4?

[sneaker_ger]

There will be a rather large gap in the secondary audio stream that can't be written off a simple VFR.
Why not? What do you think would define the difference between gaps and VFR?

[ndjamena]

Gaps are empty, VFR always contains the last frame.

[foxyshadis]

A true gap would be a Cluster that had a timecode beginning some time after the duration of the last Cluster's last BlockGroup ended. I'm sure that could come from real-time recording where the camera is temporarily unavailable and the recorder pauses instead of inserting filler, as well, but it would more likely indicate a damaged stream for most people. I don't think there's any reason for MediaInfo to look for that, that's a job for a file integrity checker.

Jerôme, thanks for the good explanation. I'm glad MediaInfo is as powerful as it is now, and the future is definitely bright.

[ndjamena]

Matroska is supposed to be able to hold multiple titles in a single file. Therefore gaps are necessary, or else you'd have to fill them with junk.

Think ISO, not MP4.

[ndjamena]

Looky:

http://matroska.org/technical/specs/tagging/example-video.html#whole

Did none of you bother reading the specs?

One file, one title.
multiple files, one title.
one file, multiple titles.

It's supposed to be FLEXIBLE...

So if a few of those episodes have commentaries...

http://matroska.org/technical/specs/chapters/index.html

[ChapterTrack]

And once the specs are actually finished and start making sense (it may happen one day) that will just be a simple example.

[sneaker_ger]

I don't see the relevance. There is no mention about how gaps are realized in the video tag section, ripping multiple episodes does not necessarily imply the special situation you had in your case (some episodes with and some episodes without a commentary track). The existence of chapters does not imply gaps.

[ndjamena]

Maybe I'm looking too far ahead, but I can take MKVMerge right now and create a file exactly like that. If you think I shouldn't be able to, you could try filing a bug report on the MKVToolNix bug tracker and see where it gets you.

Since they're just basic implementation of the Matroska file system all players support them by default, VLC goes ballistic when it finds a gap in audio, but my WDTV just interprets them as silence. I, or anyone else on earth, can easily create one of these files and playing them back on my WDTV really isn't that bad. I could just manually switch to the main audio track once the commentary goes silent and per the specs it would be a perfectly valid Matroska file..

Do you really have a problem a with that?

[ndjamena]

And the stream length. Yes, you could simply define that as the difference between the MAX(timecode+duration) and MIN(timecode). But what about gaps in the middle? If you extract back to a raw elementary streams such gaps are lost resulting in different stream lengths.

I'm not saying that such header fields aren't useful, they definitely would have been. They would also have had drawbacks that may not be obvious at first glance, though.



Hmmm, upon reading the entire email I've decided it's best to edit the rest out.

'nuf said I think.

[Chetwood]

My WDTV Live SMP actually sets the frame rate being passed to my TV through HDMI to 23.976fps when I'm playing a blu ray rip.
For 24 FPS files too? Also from m2ts?

[ndjamena]

Well, the moment I start playing anything 23.976fps my TV display jumps up and says declares it as 24p. I just tested an m2ts and it worked with that as well. My video settings are configured to HDMI (auto).

I created a 10 minute black screen file using AviSynth BlankClip and tried playing that back and it still switched to 24p, maybe it can tell from dithering or maybe x264 isn't encoding the blank screen lossless.

I made another at exactly 24fps at crf 1 (the lowest i could go without switch to the incompatible "lossless" mode) and it did indeed switch to 24p.

I turned off Cinema Drive in my TVs settings, which should disable any detection of film and it still says 24p.

I'm not sure how to test it any further.


Bit rates are even trickier with respect to gaps. Do I include the gaps in the calculation? Probably not, but Matroska doesn't require a continues stream of packets, it allows for gaps (even in audio tracks).

I took an episode of Eureka, extracted all the tracks, cut the video track in half using MKVMerge, then recreated the file with the shortened video track, then I appended that episode to the next episode. When I played it back with VLC the moment it reached the cut point it skipped to the next episode. If it was VFR it would have just repeated the last frame until the next episode. VLC is buggy, I'm not sure what it's supposed to do, but what it does at the moment is just annoying (especially when it's just gap in an audio track, even one that's not currently playing. And when the section of file it has to scan through to find the next frame happens to contain 1080p video rather than AAC audio it can get messy.) Thankfully, I have it in good authority that someone is looking into it.

[The actual Matroska specs don't specifically say much at all. Arguments based on that will go nowhere. I just read what Mosu said about MP4, I remembered it wrong, maybe I should check if they can have gaps in the files too.]

[Mosu]

The MP4 headers allow for gaps (don't know about the specs, though). But the gaps will always be a multiples of the duration of a single frame/field (for video tracks) and not arbitrarily long/short. Of course you could also use edit lists in MP4 for creating gaps of arbitrary lengths, I guess. Or abuse the CTTS atom for it.

So many possibilities…

[Mosu]

BTW, when you're saying »if it was VFR…« then you're conflating different issues here. VFR is, abstractly speaking, simply the fact that the duration between adjacent frames is not constant. This can happen in very different situations: if there's an outage during a live capture; if there are segments that use alternating durations between frames (this is what people often refer to as VFR); if there are real gaps in one track but not another.

What would enable a player to handle all situations properly would not be a simple flag »hey this file is VFR«. Instead, a player would have to know what kind of gap or change happens each time so that it could treat case 2 from above differently than case 3. Matroska doesn't provide such information, but neither does any other popular container that I'm aware of.

About the frame rate being necessary for playback. So far the only case in which the frame rate has to be known in advance would mean syncing the playback device's frame rate. This is your example of your TV switching to a certain number of frames per second. Matroska's design did indeed not take this into account, and therefore a nominal frame rate is not part of the track headers. However, it still doesn't make all that much sense. Let's assume you specify a default duration of 40ms and derive a frame rate of 25 FPS from it. But then there's a gap of 12ms right at the beginning (audio starts at 0, video at 12ms). Or even worse: somewhere in the middle! So… now the playback device doesn't have the frame's timecodes synced to its own clock of when frames are supposed to be shown anymore.

Any container that allows arbitrary timecodes (ant not just multiples of the frame rate) suffer from this. M2TS does. MPEG PS does.

[Zenitram]

VFR is, abstractly speaking, simply the fact that the duration between adjacent frames is not constant. (...) This can happen in very different situations: if there's an outage during a live capture;

I kindly disagree: in such case, this is a stream outage, and my users consider such stream as CFR stream having missing frames.
there is a difference between a CFR stream missing some frames and a stream which is authored as VFR.

[Mosu]

Which doesn't affect my point: having a flag in the headers »this stream uses VFR« is simply not enough for handling all situations in which you encounter a frame with a duration different from the ones present in the headers. For true VFR streams in the sense that you're talking about each change in frame rate should be flagged as a change in frame rate along with the new expected frame rate. Similarly other types of duration differences ( = gaps) would have to be signalled.

Unless this is done there will always be ambiguity regarding how things like a streams duration and therefore bitrate is calculated.

[ndjamena]

You could add Null frames to cover missing frames and stream terminators/initiators to cover gaps.

Just saying.

[Mosu]

While that might work for video it wouldn't work so well for audio, I guess. What should a player do with an empty audio frame? Continue playing the last frame over and over like with video?

My whole point is that the topic of gaps in the stream is a complex one with many issues and pitfalls. A simple flag (VFR on/off) or a simple value (frame rate) doesn't cover it.

[ndjamena]

My actual definition of "Active Duration" has always been "the sum of the durations of every frame", which is different than "duration minus gaps" but would sound wrong.

Variable Frame Rate may be the wrong word to use, there seems to be three distinct issues being addressed:

1: Variable Frame Duration
2: Broken Stream (Missing Frames)
3: Stream Termination

1: is the classical definition of VFR
2: can be constant frame rate, the frames do exist in theory and still have the same duration but they're not present in the file
3: There are no frames, and since there are no frames, there's no frame rate. A delay is the most common example and is almost never included in frame rate calculations.

A null audio frame is silence... the stream is broken, there's not much you can do about that. A player can try to improvise something to fill the gap but it most likely won't be worth the effort (and that's essentially what it's doing with the video as well). If I watch something on TV and the signal gets scrambled the audio cuts out, should my TV be doing something else?

I don't imagine I'd ever see a null frame from any of the files I'd use, but I image they'd be counted separately from the proper frames.

[MrVideo]

7.6.0 toolkit

I recently had to rebuild one of my systems and decided to go to XP x64 from XP x86.

I installed the 64 bit version of the toolkit and discovered tonight that mkvmerge will not start. I suspect the other programs won't either. I get the following error:

The procedure entry point inet_pton could not be found in the dynamic link library WS2_32.dll.

Makes perfect sense, since 64 bit programs can't load 32 bit DLLs.

What is the fix for this issue?

Update: In order to be able to use the programs, I installed the 32 bit version. The 32 bit installer needs a minor fix. When installing on a 64 system, it should put the files in "Program Files (x86)" instead of "Program Files."

[foxyshadis]

Update: In order to be able to use the programs, I installed the 32 bit version. The 32 bit installer needs a minor fix. When installing on a 64 system, it should put the files in "Program Files (x86)" instead of "Program Files."

It does for a clean install, but all versions of the installer always default to the last installed location, no matter what. Since 64 was first, that's what came up on the reinstall. Now that you've changed it, the next install will change too.

I installed the 64 bit version of the toolkit and discovered tonight that mkvmerge will not start. I suspect the other programs won't either. I get the following error:

The procedure entry point inet_pton could not be found in the dynamic link library WS2_32.dll.

Makes perfect sense, since 64 bit programs can't load 32 bit DLLs.

Welcome to XP64. Win7 x64 is a much more complete OS, as is Win8; XP64 is 2003 with some XP grafted on, and isn't even compatible with a lot of newer 64-bit software, making it completely pointless unless your only goal is letting the system see all your memory.

WS2_32.dll is a 64-bit DLL, it just doesn't have things like inet_pton() that came in Vista and up. x64 software is often compiled assuming a minimum of Vista or Win7, and the missing functions in XP will cause lots of errors. 32-bit software is at least usually still XP-compatible.

[MrVideo]

Thanks for the info, it is appreciated.

IMHO, the installer should install 64 bit where it belongs and 32 bit where it belongs. This is the first one I've run across that doesn't do that.

As for using XP, there is some software that I might reinstall on the particular box that I have no clue if it will work on Win7, or later. So, I'm sticking with what I know works. I have another new box that I will be testing Win7 on.

I do not like Win8. That is a horrible user interface for desktop users. I'm not the only one who hates it. I have read that there are ways to bring back the desktop we all know and love.

[Gruko]

I couldn't download the latest build of mkvtoolnix (32bit installer version) because Avast blocks the download. I've tried to report the file as a false positive, without success.
No problem with the portable or 64bit installer versions.

[filler56789]

I couldn't download the latest build of mkvtoolnix (32bit installer version) because Avast blocks the download. I've tried to report the file as a false positive, without success.
No problem with the portable or 64bit installer versions.

Stop using Avast, problem solved :)

Seriously,

https://github.com/mbunkus/mkvtoolnix/wiki/Virus-in-installer

[ndjamena]

The MP4 headers allow for gaps (don't know about the specs, though). But the gaps will always be a multiples of the duration of a single frame/field (for video tracks) and not arbitrarily long/short. Of course you could also use edit lists in MP4 for creating gaps of arbitrary lengths, I guess. Or abuse the CTTS atom for it.

So many possibilities…

So, basically, gaps in MP4s are created through the use of inactive "nothing to see here" null frames? (as opposed to AVIs active "ditto" null frames)

[AYColumbia]

I wanted to report this mkvmerge issue after updating to 7.6.0. There are two issues below: 1) Failed to recognize .264 file, 2) Command line errorlevel was still 0 after it failed.
[S] [2015-02-24] [20:43:43] Creating new process: mkvmerge.exe [-o; .\output\title.mkv;
--forced-track; 0:no; --default-duration; 0:30000/1001fps; --display-dimensions; 0:640x480; -d; 0; -A; -S; -T;
--no-global-tags; --no-chapters; (; title.264; ); --language; 0:eng; --sync; 0:32;
--forced-track; 0:no; -a; 0; -D; -S; -T; --no-global-tags; --no-chapters; (; title.ac3; ); -D; -A; -S; -T;
--no-global-tags; (; Q:\Media\DVD Source\title.mkv; ); --track-order; 0:0,1:0; --title; title.mkv [nocues];
--engage; no_cue_duration; --engage; no_cue_relative_position]
[S] [2015-02-24] [20:43:43] Process created successfully (PID: 0x000000EC)
[O] [2015-02-24] [20:43:43] mkvmerge v7.6.0 ('Garden of Dreams') 64bit built on Feb 8 2015 13:04:34
[O] [2015-02-24] [20:43:43] Error: The file 'title.264' has unknown type. Please have a look at the supported
file types ('mkvmerge --list-types') and contact the author Moritz Bunkus <moritz@bunkus.org> if your file type
is supported but not recognized properly.
[S] [2015-02-24] [20:43:43] Process has terminated (exit code: 0x00000002)

This is part of a standard script I run for all encodes. I'll downgrade to a prior version and run it again. The resulting 264 file is created with x264. Please tell me if you need additional information. Thank you.

[EDIT] I forgot to mention that the prior version I was on was 7.4.0. So that will be the version I downgrade to.

[Mosu]

I recently had to rebuild one of my systems and decided to go to XP x64 from XP x86.

I don't support Windows XP anymore.

Update: In order to be able to use the programs, I installed the 32 bit version. The 32 bit installer needs a minor fix. When installing on a 64 system, it should put the files in "Program Files (x86)" instead of "Program Files."

If MKVToolNix (no matter the bitness) is currently installed then the installer will default to the same installation folder. If you want to move an installation from »Program Files« to »Program Files (x86)« or vice versa then uninstall first.

[Mosu]

So, basically, gaps in MP4s are created through the use of inactive "nothing to see here" null frames? (as opposed to AVIs active "ditto" null frames)

I honestly don't know how the MP4 specs want to see it handled ('m not that deep into the specs). I only listed what would work _technically_.

[Mosu]

I wanted to report this mkvmerge issue after updating to 7.6.0. There are two issues below: 1) Failed to recognize .264 file

I will need a test file for that. See my signature where to upload to.

2) Command line errorlevel was still 0 after it failed.

I'm pretty sure that it wasn't. Copy & paste from cmd.exe with 7.6.0:

C:\temp\mkvtoolnix>mkvmerge -i MKVToolNix.url
Error: File MKVToolNix.url has unknown type. Please have a look at the supported file types ('mkvmerge --list-types') and contact the author Moritz Bunkus <mori tz@bunkus.org> if your file type is supported but not recognized properly.

C:\temp\mkvtoolnix>echo %errorlevel%
2
C:\temp\mkvtoolnix>

[AYColumbia]

I just ran the encode again with the only difference being mkvtoolnix downgraded to 7.4.0. Here are results:
[S] [2015-02-25] [08:35:32] Creating new process: mkvmerge.exe [-o; .\output\title.mkv;
--forced-track; 0:no; --default-duration; 0:30000/1001fps; --display-dimensions; 0:640x480; -d; 0; -A; -S; -T;
--no-global-tags; --no-chapters; (; title.264; ); --language; 0:eng; --forced-track; 0:no; -a; 0; -D; -S; -T;
--no-global-tags; --no-chapters; (; title.ac3; ); -D; -A; -S; -T; --no-global-tags; (; title.mkv; );
--track-order; 0:0,1:0; --title; title.mkv [nocues]; --engage; no_cue_duration;
--engage; no_cue_relative_position]
[S] [2015-02-25] [08:35:32] Process created successfully (PID: 0x000000EC)
[O] [2015-02-25] [08:35:32] mkvmerge v7.4.0 ('Circles') 64bit built on Dec 12 2014 12:19:56
[O] [2015-02-25] [08:35:33] 'title.264': Using the demultiplexer for the format 'AVC/h.264'.
[O] [2015-02-25] [08:35:33] 'title.ac3': Using the demultiplexer for the format 'AC3'.
[O] [2015-02-25] [08:35:33] 'title.mkv': Using the demultiplexer for the format 'Matroska'.
[O] [2015-02-25] [08:35:33] 'title.264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
[O] [2015-02-25] [08:35:33] 'title.ac3' track 0: Using the output module for the format 'AC3'.
[O] [2015-02-25] [08:35:33] The file '.\output\title.mkv' has been opened for writing.
[O] [2015-02-25] [08:35:36] The cue entries (the index) are being written...
[O] [2015-02-25] [08:35:36] Muxing took 4 seconds.
[S] [2015-02-25] [08:35:36] Process has terminated (exit code: 0x00000000)
Error level was 0 as it always worked fine prior to 7.6.0, here's how it's checked:if "!errorlevel!"=="0" (...
I'll reinstall 7.6.0 and see if I can mux the elementary streams using the GUI. I'll create a small clip to send you as well. Thank you.

[Mosu]

What I meant with »I'm sure it wasn't«: if mkvmerge fails (no matter which version) then the error level is not 0. Your point »2.« suggested that, even though mkvmerge failed, error level was == 0.

I don't know what language your error level check is written in, therefore I cannot comment if that's the right way to do it.

[AYColumbia]

What I meant with »I'm sure it wasn't«: if mkvmerge fails (no matter which version) then the error level is not 0. Your point »2.« suggested that, even though mkvmerge failed, error level was == 0.

I don't know what language your error level check is written in, therefore I cannot comment if that's the right way to do it.
No problem, I was just letting you know what the batch file was reporting is all. I just run a .cmd file using under CMD prompt in Windows 7.

Although, all this now seems to no longer be an issue. Not sure what happened, but after I re-installed 7.4.0 and then re-installed 7.6.0, it seems to be working just fine now. Here's the output from 7.6.0:[S] [2015-02-25] [09:50:12] Creating new process: mkvmerge.exe [-o; .\output\title.mkv; --forced-track; 0:no; --default-duration; 0:30000/1001fps; --display-dimensions; 0:640x480; -d; 0; -A; -S; -T; --no-global-tags; --no-chapters; (; title.264; ); --language; 0:eng; --forced-track; 0:no; -a; 0; -D; -S; -T; --no-global-tags; --no-chapters; (; title.ac3; ); -D; -A; -S; -T; --no-global-tags; (; title.mkv; ); --track-order; 0:0,1:0; --title; title.mkv [nocues]; --engage; no_cue_duration; --engage; no_cue_relative_position]
[S] [2015-02-25] [09:50:12] Process created successfully (PID: 0x000000EC)
[O] [2015-02-25] [09:50:12] mkvmerge v7.6.0 ('Garden of Dreams') 64bit built on Feb 8 2015 13:04:34
[O] [2015-02-25] [09:50:12] 'title.264': Using the demultiplexer for the format 'AVC/h.264'.
[O] [2015-02-25] [09:50:12] 'title.ac3': Using the demultiplexer for the format 'AC3'.
[O] [2015-02-25] [09:50:12] 'title.mkv': Using the demultiplexer for the format 'Matroska'.
[O] [2015-02-25] [09:50:12] 'title.264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
[O] [2015-02-25] [09:50:12] 'title.ac3' track 0: Using the output module for the format 'AC3'.
[O] [2015-02-25] [09:50:12] The file '.\output\title.mkv' has been opened for writing.
[O] [2015-02-25] [09:50:16] The cue entries (the index) are being written...
[O] [2015-02-25] [09:50:16] Muxing took 3 seconds.
[S] [2015-02-25] [09:50:16] Process has terminated (exit code: 0x00000000)
:thanks:

[Thunderbolt8]

I noticed when I remux my old HD DVD VC-1 movie remuxes (created with eac3to) which still have a pulldown flag, that these second remuxes (remuxed with mkvmerge) are now being played back at 29.97fps and not at 23.976 fps any more. what did change in mkvermge and how can I prevent this?

[Mosu]

No idea, and no idea.

[SeeMoreDigital]

I noticed when I remux my old HD DVD VC-1 movie remuxes (created with eac3to) which still have a pulldown flag, that these second remuxes (remuxed with mkvmerge) are now being played back at 29.97fps and not at 23.976 fps any more. what did change in mkvermge and how can I prevent this?Out of interest... Why didn't you remove the pull-down flag?

[Thunderbolt8]

I guess eac3to didnt do that automatically back then. at least I havent entered any option to keep it if there are any. maybe the default used to be different.

well this only happens when I remux the file with mkvmerge again now. didnt happen back then when I muxed it with mkvmerge for the first time.

[SeeMoreDigital]

When I originally backed up my HD-DVD disc's to Blu-ray.iso files I used TSmuxer GUI to remove the 'pull-down' flags from VC-1 and AVC streams. This was back in the day when I was using an Xtreamer media device to play my media files.

But when I bought an Oppo BDP-103EU I had to re-mux all my Blu-ray.iso files to .mkv because the Oppo does not officially support playback of .iso contained files.

It would be most useful if MKVmerge offered an option to remove pull-down flags but in the meantime, there's nothing stopping you using TSmuxer to achieve this ;)

[Mosu]

I would welcome such functionality but will likely not implement it myself. Patches are welcome.

[Mosu]

Hey,

I've released MKVToolNix v7.7.0. It contains many bug fixes but also interesting new features like keeping the AC3 core of TrueHD+AC3 tracks and reducing DTS-HD tracks to their lossy core (both of those are optional, of course).


Note that the portable versions for Windows do NOT contain the preview of the new GUI anymore. The reason is that many users thought it to be the GUI to run due to its file name (experimental, buggy, incomplete preview version: mkvtoolnix-gui.exe; old but stable and working version: mmg.exe). The installers still include it as the installer also creates properly named start menu entries.

Nothing has changed for package maintainers.

Here are the usual links…

…to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

…to the source code:
https://www.bunkus.org/videotools/mkvtoolnix/source.html

…to the Windows installer and 7zip archive:
http://www.fosshub.com/MKVToolNix.html

All binaries that I provide have been uploaded already.

Here's the full ChangeLog since the previous release:

2015-02-28 Moritz Bunkus <moritz@bunkus.org>
* Released v7.7.0.

2015-02-28 Lionel Fourquaux <lionel.fourquaux@normalesup.org>
* source code: Fixed the compilation on cygwin.

2015-02-27 Moritz Bunkus <moritz@bunkus.org>
* documentation: The Dutch, Ukrainian and Chinese (Simplified) manual pages have contained only untranslated English strings since release 7.0.0. This was due to the files holding the translatable strings having being corrupted by a misbehaving tool in the build process. This has been rectified. Fixes #1134 (https://github.com/mbunkus/mkvtoolnix/issues/1134),

2015-02-25 Mats Peterson <matsp888@yahoo.com>
* mkvmerge: bug fix: Fixed reading all of the private codec data in AVIs from the 'strf' chunk for codecs that don't set biSize to include that data. Fixes #1129 (https://github.com/mbunkus/mkvtoolnix/issues/1129).
* mkvextract: bug fix: Fixed writing AVIs with ckSize fields that were too large. Fixes #1128 (https://github.com/mbunkus/mkvtoolnix/issues/1128).

2015-02-25 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: added a button »toggle all« that enables or disables all tracks. It at least one track is currently disabled then all tracks are enabled when pressing that button. Otherwise (if all tracks are currently enabled) then they will all be disabled. Implements #1130 (https://github.com/mbunkus/mkvtoolnix/issues/1130).
* mmg: new feature: added a new checkbox »reduce to audio core« on the »format-specific options« tab that passes the new --reduce-to-core option to mkvmerge if enabled. Part of the implementation of #1107 (https://github.com/mbunkus/mkvtoolnix/issues/1107).
* mkvmerge: bug fix: fixed determining the key frame status in certain AVIs (those whose dwFlags index field has more bits set than just 0x10).
* build system: new feature: added configure options for building statically-linked binaries (--enable-static). Patches by Florent Thiéry. Implements #1119 (https://github.com/mbunkus/mkvtoolnix/issues/1119).
* mkvextract: new feature: implemented a mode for extracting cue information.

2015-02-24 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo (Qt interface): bug fix: added WebM extensions to the known types in the »Open file« dialog.

2015-02-23 Mats Peterson <matsp888@yahoo.com>
* mkvextract: bug fix: Fixed writing AVIs with the wrong bit depth for video codecs that don't use 24 bits/pixel. Fixes #1123 (https://github.com/mbunkus/mkvtoolnix/issues/1123).

2015-02-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed recognition of E-AC3 audio tracks in MPEG transport streams if they use the type ID 0xa1 (and the same for DTS tracks stored with type ID 0xa2). Fixes #1126 (https://github.com/mbunkus/mkvtoolnix/issues/1126).
* mkvextract: bug fix: Fixed VobSubs being written to the wrong directory if the output file name given by the user didn't have an extension but one of the directories contained a dot. Fixes #1124 (https://github.com/mbunkus/mkvtoolnix/issues/1124).
* mkvpropedit, mmg's header editor: bug fix: if updating the file required creating an EBML void for a 130 bytes long gap then the void element created was one byte too short resulting in an invalid file structure. Fixes #1121 (https://github.com/mbunkus/mkvtoolnix/issues/1121).
* mkvmerge: bug fix: If the MP4 track headers for MP3 tracks contain invalid values (number of channels is 0 or the sampling rate is 0) then mkvmerge will re-derive these parameters from the MP3 bitstream instead of ignoring that track.

2015-02-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Matroska reader: track-specific tags weren't copied for tracks for which the pass-through packetizer was used (e.g. those with the codec ID A_MS/ACM) instead of a specialized one.

2015-02-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: The code for determining the time codes of AAC, AC3, DTS, MP3 and TrueHD packets has been completely rewritten. This improves how timecodes are kept if the source container provides them in many cases.
* mkvmerge: removal: AAC: The hack for using the old codec IDs (e.g. A_AAC/MPEG4/LC/SBR) for AAC tracks has been removed. Those codec IDs have been deprecated for nearly ten years. Reading files that use those IDs will stay supported.
* mkvmerge: removal: TrueHD: The hack for merging a sync frame and all following normal frames into a single Matroska packet has been removed as there are no players that can play such merged frames anyway.

2015-02-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added an option »--reduce-to-core« that tells mkvmerge not to copy HD extensions for DTS tracks. Part of the implementation of #1107 (https://github.com/mbunkus/mkvtoolnix/issues/1107).
* mkvmerge: new feature: mkvmerge will now recognize TrueHD tracks inside MPEG transport streams that contain an AC3 core as consisting of two tracks. Instead of always dropping the AC3 part the user can simply select which tracks to keep. Part of the implementation of #1107 (https://github.com/mbunkus/mkvtoolnix/issues/1107).

2015-02-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: mkvmerge will now recognize TrueHD+AC3 files as consisting of two tracks. Instead of always dropping the AC3 part the user can simply select which tracks to keep. Part of the implementation of #1107 (https://github.com/mbunkus/mkvtoolnix/issues/1107).

Have fun.

[Sparktank]

toggle all

:) Too speechless, my good sir. Too speechless. :)

[Mosu]

Just to make this very clear: »toggle all« enables or disables all tracks at once. It's the same as if you clicked each of the track's checkboxes manually.

It does NOT allow you to select multiple tracks and make any other modification on that selection. This is something that will only come with the new GUI; for the old GUI this would require re-writing roughly half of its code.

[SeeMoreDigital]

Hi Mosu,

Many thanks for the new Dolby TrueHD audio options :)

[JoeGibken]

Thanks Mosu for the wonderful app :D

Anyway, I've been wondering why every time I merge into mkv, the video duration seems to be appearing wrong. The original video and the merged mkv files have different total duration.

After doing some trial and error, I concluded that the mkv output that had wrong duration was because of the .ass subtitle file that had lines that was timed for more than the length of the video file. After retiming the lines of the subtitle file that was over the duration of the video file, then I merge video+audio+subtitle files into mkv, the duration was correct again.

As there will be times I won't be able to check always the subtitle files that overpasses the video file, is there a way or an option in mkvmerge (though I'm next to always use mkvmerge gui) where the merged mkv file would produce the same duration as that of the video files and ignores the full duration of the .ass subtitle files?

Thanks you in advance :)

[Mosu]

No, there's no such option, and there won't be one. The definition of the segment duration is simply the difference between the lowest timecode and the highest sum of packet timecode+duration.

[JoeGibken]

So there is no way to explicitly tell mkmerge what total duration you want for the mkv output?

[Mosu]

That is correct.

[sneaker_ger]

You could abuse --split parts to some extent (make a single part from 0 to desired duration) but mkvmerge will not cut GOPs or subtitle lines in two so it may "bleed" a bit beyond the specified time.

[JoeGibken]

@Mosu Thanks for the clarification and the wonderful app :)
@sneaker_ger Thanks for the idea :)

[Thunderbolt8]

does the TrueHD+AC3 recognition & deciding which of these tracks to keep also work for Dolby Atmos tracks?

[Reino]

2015-02-25 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: added a new checkbox »reduce to audio core« on the »format-specific options« tab that passes the new --reduce-to-core option to mkvmerge if enabled. Part of the implementation of #1107.
Thanks Mosu, but especially Moritz! My Samsung SMART TV has trouble playing DTS-HD MA; the audiotrack is always a little behind and therefore not in sync (for which I hope some future firmware-update could help). Now I can remux in one single step, instead of first having to run eac3to (or ffmpeg) to extract the core and remux afterwards. Works great!

[Mosu]

@Thunderbolt: so far I haven't done anything in that direction. mkvmerge's TrueHD and AC3 handling code might work with the Atmos extensions, but it isn't explicitly supported (not even tested).

@Corone: mosu == Moritz Bunkus

[Lathe]

Does the newer MKVMerge strip out the encode data?

Perhaps it has done this in earlier builds, but I hadn't noticed it. I found out recently when I took MKV files that DID have the full x264 encode data in the stream and I used the most recent version of MKVMerge to slice it into 10 second snippets (to send to Selur for analysis as to why certain MKV files weren't playing on my OPPO BDP-83 player) And, lo and behold, the resulting 10 second snippets had the x264 encode data stripped out!

Has this always been the case or is this something new?

Thank you!

Oh... and if so, IS there some way to use MKVMerge and still keep the x264 encode data?

[sneaker_ger]

x264's custom SEI is in the beginning of the file, only the first part will have it if you cut a file into pieces. It's always been this way. To answer the question: not with mkvtoolnix.

[Lathe]

x264's custom SEI is in the beginning of the file, only the first part will have it if you cut a file into pieces. It's always been this way. To answer the question: not with mkvtoolnix.

Oh..... right.....! I forgot about that :) Thanks m8!

[v0lt]

@Mosu
mkvmerge v7.7.0 incorrectly fills the biSize field in the BITMAPINFOHEADER structure for RGB8 and RGB565 format ("V_MS/VFW/FOURCC").

http://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx
biSize
Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure...

For this reason, I did not work Color Space Converter (http://msdn.microsoft.com/en-us/library/windows/desktop/dd387892%28v=vs.85%29.aspx). I had to make a patch for MPC-BE (http://sourceforge.net/p/mpcbe/code/197/).

[Mosu]

Do you have a sample file? Please upload one to my FTP server (see signature).

The thing is that a LOT of AVIs have biSize include the codec's private initialization bytes and not just the size of BITMAPINFOHEADER. As the MS specs don't say anything about codec private data other than color tables and masks this is very much a grey area.

[v0lt]

twogradients_RGB8_RGB565.7z (http://www.mediafire.com/download/07on6gsf6w8o4gp/twogradients_RGB8_RGB565.7z) (AVI files made in VirtualDub).
I also uploaded to FTP server.

[mastrandrea]

Is mkvmerge the right tool to remux a .mkv with multiple chapters EditionEntry (movie with different cuts) so that I can reorder/keep the chapters of the edition I'm interested and strip the others?

[Mosu]

Not really, no.

[kuchikirukia]

Is this flipping the audio? One is PCM extracted with mkvmerge 7.7.0, the other is with eac3to 3.28

http://s1.postimg.org/h50ag9sr3/untitled.png (http://postimage.org/)
screen shot windows (http://postimage.org/app.php)

The mkvmerge extracted one errors out all of MeGUI's input decoders.

Here's the log, starting off with the eac3to extraction and then moving on to trying to encode using the mkvmerge extracted file:


--[Information] [3/22/2015 3:59:32 AM] Input: D:\magicalmirai_2014_in_OSAKA\magicalmirai_2014_in_OSAKA_t01.mkv
--[Information] [3/22/2015 3:59:32 AM] Arguments: "D:\magicalmirai_2014_in_OSAKA\magicalmirai_2014_in_OSAKA_t01.mkv"
--[Information] [3/22/2015 3:59:35 AM] (core: DTS, 5.1 channels, 1509kbps, 48kHz)
--[Information] [3/22/2015 3:59:35 AM] Feature Retrieval Completed
-[Information] Log for job3 (ext, magicalmirai_2014_in_OSAKA_t01.mkv -> )
--[Information] [3/22/2015 3:59:46 AM] Started handling job
--[Information] [3/22/2015 3:59:46 AM] Preprocessing
--[Information] [3/22/2015 3:59:46 AM] Job commandline: "C:\Program Files\MeGUI_2507_x86\tools\eac3to\eac3to.exe" "D:\magicalmirai_2014_in_OSAKA\magicalmirai_2014_in_OSAKA_t01.mkv" 4:"e:\T4_Audio - Japanese.wav" -progressnumbers
--[Information] [3/22/2015 3:59:46 AM] Process started
--[Information] [3/22/2015 3:59:46 AM] Standard output stream
--[Information] [3/22/2015 3:59:46 AM] Standard error stream
---[Information] [3/22/2015 3:59:49 AM] MKV, 1 video track, 3 audio tracks, 1:55:18, 60i /1.001
---[Information] [3/22/2015 3:59:49 AM] 1: h264/AVC, English, 1080i60 /1.001 (16:9)
---[Information] [3/22/2015 3:59:49 AM] 2: DTS Master Audio, Japanese, 5.1 channels, 24 bits, 48kHz
---[Information] [3/22/2015 3:59:49 AM] (core: DTS, 5.1 channels, 1509kbps, 48kHz)
---[Information] [3/22/2015 3:59:49 AM] "Surround 5.1"
---[Information] [3/22/2015 3:59:49 AM] 3: DTS, Japanese, 5.1 channels, 1509kbps, 48kHz
---[Information] [3/22/2015 3:59:49 AM] "Surround 5.1"
---[Information] [3/22/2015 3:59:49 AM] 4: RAW/PCM, Japanese, 2.0 channels, 24 bits, 48kHz
---[Information] [3/22/2015 3:59:49 AM] "Stereo"
---[Information] [3/22/2015 3:59:49 AM] a04 Extracting audio track number 4...
---[Information] [3/22/2015 3:59:49 AM] a04 Reading RAW/PCM...
---[Information] [3/22/2015 3:59:49 AM] a04 Writing WAV...
---[Information] [3/22/2015 3:59:49 AM] a04 Creating file "e:\T4_Audio - Japanese.wav"...
---[Information] [3/22/2015 4:09:10 AM] a04 The original audio track has a constant bit depth of 24 bits.
---[Information] [3/22/2015 4:09:10 AM] Video track 1 contains 207330 frames.
---[Information] [3/22/2015 4:09:10 AM] eac3to processing took 9 minutes, 22 seconds.
---[Information] [3/22/2015 4:09:10 AM] Done.
--[Information] [3/22/2015 4:09:11 AM] Postprocessing
---[Information] [3/22/2015 4:09:11 AM] Deleting intermediate files
--[Information] [3/22/2015 4:09:11 AM] Job completed
-[Information] Log for job3 (audio, 1.mka -> 7.opus)
--[Information] [3/22/2015 4:36:34 AM] Started handling job
--[Information] [3/22/2015 4:36:34 AM] Preprocessing
--[Information] [3/22/2015 4:36:34 AM] MediaInfo
---[Information] [3/22/2015 4:36:34 AM] File: E:\1.mka
-[Information] Format: Matroska
-[Information] FormatString: Matroska
-[Information] FileSize: 1992837852
-[Information] PlayTime: 01:55:17.910
---[Information] General
-[Information] ID: 1
-[Information] StreamOrder: 0
-[Information] Format: PCM
-[Information] FormatProfile:
-[Information] FormatSettingsSBR:
-[Information] FormatSettingsPS:
-[Information] SamplingRate: 48000
-[Information] SamplingRateString: 48.0 KHz
-[Information] Channels: 2
-[Information] ChannelsString: 2 channels
-[Information] ChannelPositionsString2:
-[Information] BitRateMode: CBR
-[Information] Delay: 0
-[Information] Title: Stereo
-[Information] Language: ja
-[Information] LanguageString: Japanese
-[Information] Default: No
-[Information] DefaultString: No
-[Information] Forced: No
-[Information] ForcedString: No
---[Information] Audio
--[Information] [3/22/2015 4:36:34 AM] Trying to open the file with NicAudio
--[Information] [3/22/2015 4:36:34 AM] Failed opening the file with NicAudio()
--[Information] [3/22/2015 4:36:34 AM] Trying to open the file with BassAudioSource()
--[Information] [3/22/2015 4:36:36 AM] Failed opening the file with BassAudioSource(). File could not be opened!
--[Information] [3/22/2015 4:36:36 AM] Trying to open the file with FFAudioSource()
--[Information] [3/22/2015 4:36:37 AM] Successfully opened the file with FFAudioSource()
-[NoImage] LoadPlugin("C:\Program Files\MeGUI_2507_x86\tools\ffms\ffms2.dll")
-[NoImage] FFAudioSource("E:\1.mka")
-[NoImage] # detected channels: 2 channels
-[NoImage] # detected channel positions:
-[NoImage] return last
--[Information] [3/22/2015 4:36:37 AM] Avisynth script
--[Information] [3/22/2015 4:36:37 AM] Commandline used: --ignorelength --vbr --bitrate 256 - "{0}"
--[Information] [3/22/2015 4:36:37 AM] Avisynth script environment opened
--[Information] [3/22/2015 4:36:37 AM] Script loaded
--[Information] [3/22/2015 4:36:37 AM] Output Decoder
---[Information] [3/22/2015 4:36:37 AM] Channels: 2
---[Information] [3/22/2015 4:36:37 AM] Bits per sample: 32
---[Information] [3/22/2015 4:36:37 AM] Sample rate: 48000
--[Information] [3/22/2015 4:36:37 AM] Job commandline: C:\Program Files\MeGUI_2507_x86\tools\opus\opusenc.exe --ignorelength --vbr --bitrate 256 - "E:\7.opus"
--[Information] [3/22/2015 4:36:37 AM] Process started
--[Information] [3/22/2015 4:36:37 AM] Standard output stream
--[Information] [3/22/2015 4:36:37 AM] Standard error stream
---[Information] [3/22/2015 4:36:37 AM] ERROR: Unsupported WAV sample size.
---[Information] [3/22/2015 4:36:37 AM] Must be 8, 16, or 24 bit PCM or 32 bit floating point PCM.
---[Information] [3/22/2015 4:36:37 AM] Error parsing input file: -
-[Error] [3/22/2015 4:36:37 AM] Exception message: The pipe has been ended.
-[NoImage] at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
-[NoImage] at System.IO.FileStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count)
-[NoImage] at System.IO.FileStream.Write(Byte[] array, Int32 offset, Int32 count)
-[NoImage] at MeGUI.AviSynthAudioEncoder.encode()
-[Error] [3/22/2015 4:36:37 AM] Stacktrace
-[Error] [3/22/2015 4:36:37 AM] Inner exception: null
--[Error] [3/22/2015 4:36:37 AM] An error occurred
--[Information] [3/22/2015 4:36:37 AM] Job completed

[sneaker_ger]

I cannot reproduce that. Muxed a wav file with mkvmerge then demuxed with mkvextact and eac3to. All three files had the same "orientation". Any sample?

[kuchikirukia]

Ok, it's the eac3to one that's flipped, since if I read the mkv with audacity I get the same orientation as mkvmerge's extracted mka. So now the question is why is it still resulting in a file that can't be read by these decoders when it plays just fine?

Sample:
http://s000.tinyupload.com/?file_id=22495506543564835263

E: Dude, what the heck are you using?
http://s3.postimg.org/m5xdphqoz/untitled.png (http://postimage.org/)
image upload with preview (http://postimage.org/)

[sneaker_ger]

I cannot reproduce, something's off about your test setup.

[kuchikirukia]

Well, mkvmerge is working fine so I'll take this elsewhere. May be an incompatibility with XP.

[73ChargerFan]

It's been a while since I've remuxed DVD VOB files, but I seem to remember mmg automatically appending all the subsequent VOB files when I dragged the first into the file list. Am I mistaken or is there an option I missed?

Edit: Never mind, it worked, just didn't show the additional files in the file list like I remembered.

[filler56789]

@Mosu: now that there exists libdcadec

( https://github.com/foo86/dcadec ),

¿how much time until MKVtoolnix supports A_DTS/LOSSLESS and A_DTS/EXPRESS? :)

[nevcairiel]

There is no need for extra DTS codec ids, just shove them all in A_DTS and enjoy support in every player that exists today?
Not that any sources for core-less DTS lossless even exist.

[filler56789]

@nev: AFAIK, MKVtoolnix does not recognize DTS Express yet, the only way to make LBR DTS Matroska-compatible still is through the ACM-compatibility mode.

[Mosu]

That is correct. I don't have any concrete plans for adding support at the moment.

[filler56789]

Thanks for answering.

[Mosu]

I've spent the day trying to implement support for DTS Express. DTS Express is basically a DTS stream without core elements (just the HD extensions). I've got this pretty much under control safe for one thing – determining the number of samples in each packet.

For DTS core packets this is trivial. For HD extensions? Not so much. In ffmpeg there's no decoder for such streams, and the dcadec library linked to by filler56789 is no help either.

The DTS Express sample files I have make dcadec choke with the error message »Unsupported feature«. Browsing through the source code of dcadec leads me to believe that dcadec can only determine the number of samples in an HD extension of type XLL – but my sample files don't use XLL, they use LBR. (dcadec can determine the number of samples from core packets, of course, but DTS Express doesn't use core packets.)

Why do I need the number of samples? In order to calculate a packet's duration and with that information each packet's timecode. No timecodes, no go.

So basically: we're still screwed wrt DTS Express and will likely continue to be for the foreseeable future.

[nevcairiel]

The timing is in the ExSS headers (Extension Substream). In the DTS specification (http://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf), its nuRefClockCode and nuExSSFrameDurationCode which you want to look at.

[Mosu]

Thanks for the info & the pointer to the DTS specs; I only had v1.2.1 which didn't describe LBR. I'll look into it.

[Mosu]

Thanks to nevcairiel's information mkvmerge supports DTS Express now.

[filler56789]

Thanks to nevcairiel's information mkvmerge supports DTS Express now.

:goodpost: , many :thanks: for that! :)

[SeeMoreDigital]

Thanks to nevcairiel's information mkvmerge supports DTS Express now.Nice one Mosu...

Out of interest, does anyone have any DTS Express samples?

[Mosu]

I have three files: two raw ones, one inside an MPEG transport stream. I'll send you a download location via PM.

[hubblec4]

Thanks to nevcairiel's information mkvmerge supports DTS Express now.

is DTS Express from direct load of Bluray/mpls also supported?

[Mosu]

In MPEG transport streams? Yes.

[filler56789]

The next step is, the Linux folks convince foo86 that LBR-decoding *is* important for libdcadec ;-)

https://github.com/foo86/dcadec/issues/8#issuecomment-85062370

[hubblec4]

In MPEG transport streams?

yes, m2ts.

Thanks a lot for your continuous work.

[Mosu]

Hey,

I've released MKVToolNix v7.8.0. Tons of bug fixes, among them an important one that fixes a corruption when dealing with HEVC tracks without aspect ratio information. New features include support for DTS Exrepss and a Swedish translation (work in progress).

Changes for package maintainers: Boost's Math library is now required.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-03-27 Moritz Bunkus <moritz@bunkus.org>
* Released v7.8.0.
* build system: Boost's »Math« library is now required.
* mkvmerge: bug fix: HEVC tracks which did not have an aspect ratio present in their sequence parameter set were copied incorrectly; the resulting sequence parameter set was invalid. Fixes #1081 (https://github.com/mbunkus/mkvtoolnix/issues/1081).
* mkvextract: bug fix: When extracting HEVC tracks mkvextract will use the same start code lengths that x265 uses (four bytes 0x00000001 for the first and video/picture/sequence parameter set NALs and three bytes 0x000001 for all others).

2015-03-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: File type identification will output a more detailed description of the DTS type for DTS audio tracks (DTS-HD Master Audio, DTS-HD High Resolution, DTS Express or just plain DTS). Implements #1109 (https://github.com/mbunkus/mkvtoolnix/issues/1109).
* mkvmerge: new feature: Implemented support for DTS Express.

2015-03-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The number of channels in DTS tracks with more than six channels is now recognized correctly by parsing the DTS HD extensions, too. Fixes #1139 (https://github.com/mbunkus/mkvtoolnix/issues/1139).

2015-03-24 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: added a Swedish translation of the programs by Kristoffer Grundström (see AUTHORS).

2015-03-24 Mats Peterson <matsp888@yahoo.com>
* mkvmerge: bug fix: Fixed handling of the BITIMAPINFOHEADER extra data size handling during merging and extraction for codecs like HuffYUV.

2015-03-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: When appending unframed HEVC/h.265 tracks and setting the default duration the second and all following source parts will use the same default duration as set for the first part. Fixes #1147 (https://github.com/mbunkus/mkvtoolnix/issues/1147).

2015-03-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: enabled the use of tags in WebM files. Tagging elements not supported by the WebM specs are removed. Fixes #1143 (https://github.com/mbunkus/mkvtoolnix/issues/1143).

2015-03-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed detection of audio tracks in QuickTime files whose FourCC code is unknown to mkvmerge.

2015-03-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed detection of video tracks in QuickTime files whose FourCC code is unknown to mkvmerge.

2015-03-10 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Fixed VobSub file naming when mkvextract is built against Boost::Filesystem older than 1.50.0. Fixes #1140 (https://github.com/mbunkus/mkvtoolnix/issues/1140).

2015-03-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed detection of Cinepak video tracks in QuickTime files.
* mkvmerge: bug fix: fixed detection of PCM audio tracks in QuickTime files using the »raw « FourCC.
* mkvmerge: bug fix: fixed detection of tracks in Flash Video files for which the headers do not signal a track.
* mkvmerge: bug fix: fixed a segfault in the Flash Video file format reader.

2015-03-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: The change making the window wider by default has been reverted.
* mkvmerge: bug fix: Fixed file type detection for MP3 files with big ID3 tags at the start of the file (e.g. if they contain cover images).
* mkvinfo (Qt interface): enhancement: implemented support for opening files via drag & drop.

2015-03-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added an option (--engage no_delay_for_garbage_in_avi) for disabling deriving a delay from garbage in audio tracks in AVI files. Requested in #1137 (https://github.com/mbunkus/mkvtoolnix/issues/1137).
* mkvmerge: bug fix: The formula used for calculating the audio delay for garbage data at the start of tracks in AVI files has been fixed. Fixes #1137 (https://github.com/mbunkus/mkvtoolnix/issues/1137).

Have fun.

[filler56789]

^ Many :thanks: for the new version.

[filler56789]

Testing the latest MKVmerge and the latest LAV Filters...

Re: DTS Express — muxing went fine, and playback went fine :)

Re: "Pure Lossless" DTS —
mmg says "everything went fine", BUT the original 35.9MB .dts(hd) file became a 5KB .mka file :p

LAV Splitter and LAV Audio do play the "pure lossless" source, BUT at the wrong speed :D

[Mosu]

I'll need that file you're trying to mux in order to debug it. Please upload it to my FTP server. Thanks.

[filler56789]

^ Done
(archive's name = "MARINA_LIMA~Criancza.zip").

[Mosu]

That's an interesting file, haven't seen such a one yet. ffmpeg generally knows about the format (see here (https://www.ffmpeg.org/doxygen/trunk/dtshddec_8c-source.html)), but cannot decode it either.

Meaning: this kind of DTS-HD container is currently not supported by mkvmerge. Maybe I'll add support for it, but don't count on it.

[SeeMoreDigital]

I'll need that file you're trying to mux in order to debug it. Please upload it to my FTP server. Thanks.^ Done
(archive's name = "MARINA_LIMA~Criancza.zip").May I have that sample too please for my collection?

[filler56789]

@SMD:

http://www.mediafire.com/download/g7dzip5a350e75b/MARINA_LIMA~Criancza.zip

[sneaker_ger]

That's an interesting file, haven't seen such a one yet. ffmpeg generally knows about the format (see here (https://www.ffmpeg.org/doxygen/trunk/dtshddec_8c-source.html)), but cannot decode it either.
The native ffmpeg decoder can't, but ffmpeg can decode it when compiled with (lib)dcadec.

[SeeMoreDigital]

@SMD:

http://www.mediafire.com/download/g7dzip5a350e75b/MARINA_LIMA~Criancza.zipMany thanks...

Well I managed to mux the 'core-less' DTS-HD MA stream into the .m2ts container, in the hope that it might trick MKVmerge into muxing it into .mka, but it did not work.

I also tried playing the 'core-less' DTS-HD MA stream using my Oppo BDP-103 player, but it did not work either...

[Mosu]

mkvmerge has two problems with that file The first is that it uses that strange DTSHDHDR file format. This is not really a big problem as mkvmerge can skip the first 112 bytes and treat the rest as a pure DTS elementary stream. However, even if there weren't a second problem one result of this file format is that mkvmerge would emit a warning about garbage at the beginning of the file. So this has to be fixed, too.

More important than that is that mkvmerge currently only supports core-less DTS files which use LBR extension substreams (that's what DTS Express is: a core-less extension substream consisting solely of LBR extensions). The file in question uses XLL extensions. These are currently not supported by mkvmerge if they're not accompanied by cores.

[kasper93]

That's an interesting file, haven't seen such a one yet. ffmpeg generally knows about the format (see here (https://www.ffmpeg.org/doxygen/trunk/dtshddec_8c-source.html)), but cannot decode it either.

Meaning: this kind of DTS-HD container is currently not supported by mkvmerge. Maybe I'll add support for it, but don't count on it.

You need to build ffmpeg with libdcadec (https://github.com/foo86/dcadec) which is superior to ffmpeg's dca decoder in every way. Simply do ./configure --disable-decoder=dca --enable-libdcadec :)

[Mosu]

Hmm, I've looked through the DTS spec and am somewhat unclear how to retrieve the sampling frequency from a core-less XLL extension sub-stream… The general EXSS headers do have a field called »nuMaxSampleRate« in the asset descriptor, but is that the actual sampling frequency? LBR extension sub-streams have an additional field »nLBRSampleRateCode« in their own headers (LBR audio asset), but there's no such field in the XLL sub-stream headers.

The libdcadec sources aren't helping either.

[filler56789]

Assuming I have not misunderstood everything...



sFreqIndex (original sampling frequency)

This is the sample rate of audio in a channel set. It corresponds to the resulting sampling frequency after interpolation by the nFsInterpolate factor, on the encode side. The 4-bit sFreqIndex field is interpreted as described in Table 8-5. Remember that certain extra fields are encountered in the data stream once the sample rate is greater than 96 kHz.

[Mosu]

That's the sampling frequency for one channel set, and I'm not so sure how to interpret that value.

Your FLAC file has a sampling frequency of 48000 Hz. Your XLL DTS file has sFreqIndex == 5 (meaning 22050 Hz) with a sFsInterpolate == 4. These just don't add up.

For some packets sFreqIndex is even == 8 (indicating 176400 Hz). Yikes?

At least nuMaxSampleRate from the EXSS header audio asset stays constant at 48000 Hz…

[filler56789]

My bad, it seems you are right.

[Mosu]

I've created pre-build 682 (https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) which can read your file just fine. It still relies on that »maximum sampling frequency« field, though, and like I've said I'm not certain at all that this is the right thing to do.

[filler56789]

^ Now I understand you; I had forgotten that almost two years ago, Kostya said to me:


...that specification is known to be incomplete and sometimes wrong.

[ndjamena]

If I select the "Check for updates" option in MMG and close the window before the check is complete a few seconds later MMG will shut itself down.

Remuxing a multi segment VC-1 title from a Star Trek Blu Ray results in occasional broken frames. Extracting those same titles with EAC3To results in a perfectly playable file.

Looking at the Tags MKVMerge adds to the files using FFProbe shows this:

TAG:NUMBER_OF_FRAMES=72760

TAG:NUMBER_OF_FRAMES=72738

The VC-1 stream MKVMerge extracted from the blu ray is missing exactly 22 frames, which - by a strange twist of fate - is the exact number of segments EAC3To reports as being in the title.

[1+2+4+5+7+8+10+11+13+14+16+17+19+20+22+26+28+29+31+32+34+35].m2ts

[Mosu]

About the issue in mmg: I'll look into it.

About the video issue: I'd need the source files in question. Yes, I know that they're huge, but I cannot really do anything about it unless I have sample files.

[ndjamena]

I'm trying to figure out what to send...

I ripped another copy using MakeMKV and the resulting file had the same number of frames as the EAC3To version. So I looked at each of the three files with MKVInfo and it turns out the MMG file is missing the very first frame. I looked at the playlist again with EAC3To to figure out which was the first M2TS and remuxed THAT with MMG, but when I looked at the file with MKVInfo it had the first frame, I'd remuxed an ALAC mp4 using MKVMerge and it had repeated the same timecodes in the cues several times, I've been trying to reproduce that to no avail so I figured you'd changed things in 7.8.0 and all my problems were old news. Just to make sure I ripped the mpls again and... the first frame was missing... Batman has VC1, I ripped that from the mpls and all the frames were accounted for... um, Star Trek TOS disc 1 is a 46GB Blu Ray rip...

-edit-

There's a problem here:
Appending track 18 from file no. 6 ('F:\TeAppending track 9 from file no. 6 ('F:\Temp\backup\STAR_TREK_S1D1\BDMV\STREAM\00010.M2TS') to track 9 from file no. 5 ('F:\Temp\backup\STAR_TREK_S1D1\BDMV\STREAM\00008.M2TS').

[Mosu]

If it's really the very first frame only then it may suffice to have the mpls and the corresponding first m2ts file referenced from that mpls. I wouldn't even need the whole m2ts file; the first 100 MB or so should be plenty.

With such a limited set if data it will be impossible to run certain tools on them (e.g. MakeMKV), but it would be enough for mkvmerge itself.

[ndjamena]

Minor Annoyance.

48000/(24000/1001) = 2002

so encoding audio with a frame size of 2002 samples should make their frame durations match those of NTSC film.

FFMPEG FLAC (MakeMKV): -frame_size 2002

And lo and behold:
| + Codec ID: A_FLAC at 4482
| + Default duration: 41.708ms (23.976 frames/fields per second for a video track) at 4647

Last Audio Block after splitting the file in half:
| + SimpleBlock (key, track number 2, 8 frame(s), timecode 1398.355s = 00:23:18.355) at 4447437747

Eigth last Video block in said file:
| + SimpleBlock (key, track number 1, 1 frame(s), timecode 1398.355s = 00:23:18.355) at 4447401377

And yet:

| + TrackUID: 2 at 4447522639
| + Name: DURATION at 4447522683
| + String: 00:23:18.690000000 at 4447522704

| + TrackUID: 1 at 4447522204
| + Name: DURATION at 4447522249
| + String: 00:23:18.689000000 at 4447522270

One Millisecond off...

***I went with 20mb, it should take about 3 minutes to upload.***

Error: The track number 1 from the file 'E:\Make\backup\IRON MAN DISC 2\BDMV\STREAM\00013.M2TS' cannot be appended to the track number 1 from the file 'E:\Make\backup\IRON MAN DISC 2\BDMV\STREAM\00012.M2TS'. The track parameters do not match.

Should I bother mentioning The Iron Man: Armoured Adventures Season 1 Disc 2, where the PCM audio switches between 16 bit and 24 bit between segments... And how it might be a good excuse to get virtual tracks working... This disc is unrippable using MMG from the mpls at the moment (of course it's actually better to rip each episode individually from their respective m2ts files and add the chapters in manually later, but where's the fun in that?)

[Mosu]

The FLAC packetizer calculates durations in samples. That's pretty much always more accurate than using floating point numbers as the video packetizer has to do. I'm not suprised at all that there's a difference. And no, that's definitely not something I'm going to work on.

About that append issue: well it is how it is. Matroska doesn't support changing track parameters, period. Virtual tracks is an interesting concept, but no one (including myself) has bothered to implement that – so it's only a theoretical cure for such ills. Even if I were to implement support for virtual tracks right now, how long do you think it would take a significant number of player developers and vendors to implement playback support? Look at support for ordered chapters. Abysmal. And that part of the spec has been out for ages now.

[Boulder]

Is mkvalidator still "safe" to use to determine problems in Matroska files? It hasn't been updated for quite a while and gives some unnecessary warnings, but I've disabled those and trusted only the error messages.

[Mosu]

I've updated mkvalidator a couple of days ago with a new release (v0.5.0). It fixes two error message that were just plain wrong. See the following two FAQ entries for MKVToolNix:

ERR009 read DocType version higher than DocType version (https://github.com/mbunkus/mkvtoolnix/wiki/mkvalidator-ERR009-read-doc-type-version-higher-than-doc-type-version)
ERR201 Invalid 'CueRelativePosition' for profile 'matroska v2' in CueTrackPositions (https://github.com/mbunkus/mkvtoolnix/wiki/mkvalidator-ERR201-Invalid-CueRelativePosition-for-profile-matroska-v2-in-CueTrackPositions)

The new release is available on the Matroska website (http://www.matroska.org/downloads/mkvalidator.html).

In order to answer your question: I do consider that release to be safe to use.

[Boulder]

Thanks, will update right away :) I've already saved a lot of work by using the tool, I had some issues with USB drives but I was able to determine which files need to be remuxed instead of all of them..

[Boulder]

Ran a quick test with mkvalidator on a file I just created with the latest mkvmerge; muxed H.264 video, Opus audio and one PGS subtitle track and xml chapters.

ERR201: Invalid 'SeekPreRoll' for profile 'matroska v2' in TrackEntry at 4450
ERR201: Invalid 'CodecDelay' for profile 'matroska v2' in TrackEntry at 4450
ERR201: Invalid 'DiscardPadding' for profile 'matroska v2' in BlockGroup at 2278077190
WRN0C2: The timecode of the Cluster at 1745916440 is not incrementing (may be intentional)
WRN0C2: The timecode of the Cluster at 2278069060 is not incrementing (may be intentional)
................................................................................
WRN0D0: There are 5282 bytes of void data....................Are these anything to worry about?

[Mosu]

ERR201 is the same issue that I've talked about in this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/mkvalidator-ERR201-Invalid-CueRelativePosition-for-profile-matroska-v2-in-CueTrackPositions) and that should have been fixed in mkvalidator v0.5.0. Are you sure you're using the latest version (0.5.0) and not an earlier one?

I also have a FAQ entry for WRN0D0 (https://github.com/mbunkus/mkvtoolnix/wiki/mkvalidator-WRN0D0-void-data).

About WRN0C2: well that can happen, depending on the codecs in question. Just like the warning said, it may be intentional (and is definitely not violating the specs).

[Boulder]

ERR201 is the same issue that I've talked about in this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/mkvalidator-ERR201-Invalid-CueRelativePosition-for-profile-matroska-v2-in-CueTrackPositions) and that should have been fixed in mkvalidator v0.5.0. Are you sure you're using the latest version (0.5.0) and not an earlier one?Yes, that was with the latest one. The previous file passed the test and showed that it was validated with v0.5.0.

EDIT: It seems to happen with Opus tracks. If I use a FLAC track for audio, those warnings do not appear.

[Mosu]

I cannot reproduce this kind of problem. I've just muxed a file with h.264, Opus, PGS subtitles and chapters and the only thing that mkvalidator reports for that file is WRN0D0.

[Boulder]

I've got a muxed sample for you here: https://drive.google.com/file/d/0BzeF_1syecQwYlF4LUpreERQZ1U/view?usp=sharing

Muxed with these settings:
"C:\Program Files (x86)\MKVtoolnix\mkvmerge.exe" -o "b:\\test3.mkv" "--priority" "higher" "--forced-track" "0:no" "-d" "0" "-A" "-S" "-T"
"--no-global-tags" "--no-chapters" "(" "B:\\test2-001_track1_und.h264" ")" "--forced-track" "0:no" "-a" "0" "-D" "-S" "-T"
"--no-global-tags" "--no-chapters" "(" "B:\\test2-001_track1_und.opus" ")" "--forced-track" "0:no" "-s" "0" "-D" "-A" "-T"
"--no-global-tags" "--no-chapters" "(" "B:\\test2-001_track3_fin.sup" ")" "--track-order" "0:0,1:0,2:0"
"--chapters" "B:\\test2-001_chapters.xml" "--engage" "no_cue_duration" "--engage" "no_cue_relative_position" "--disable-track-statistics-tags"

[Mosu]

Aaaaaaaah. The culprit is most likely the two --engage you use. mkvmerge wrongfully thinks that Matroska v2 is enough if neither cue duration nor cue relative position elements are used. But that's wrong if Opus is in the picture as Matroska v4 is also needed for seek pre roll, codec delay and discard padding.

I'll fix mkvmerge accordingly.

[Mosu]

The issue has been fixed in mkvmerge. Pre-builds 686 and higher (https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) contain the fix. Thanks for the heads-up & the test case.

[Boulder]

No problem, happy to help :)

[sneaker_ger]

Mkvmerge add extra one SEI if mux raw HEVC stream, not add extra one if remux from MP4. x265 1.5+444 gives longer SEI (because --rdoq-level and deblock). If longer SEI is doubled, it crash with nVidia decoder.

My software LAV decoder stop working with your example after the SEI was tripled -- in your original MKV it was doubled, I demux video track and mux again to MKV (2 + 1 = 3).

Workaround to this mkvmerge bug: first mux to MP4 and then to MKV not works with large files -- I try with 6 GB HEVC stream and mkvmerge crashes when remuxing from MP4.

If you take v1.hevc file with nonempty SEI and execute:
mkvmerge -o v2.mkv v1.hevc
mkvextract tracks v2.mkv 0:v2.hevc
mkvmerge -o v3.mkv v2.hevc
mkvextract tracks v3.mkv 0:v3.hevc
mkvmerge -o v4.mkv v3.hevc
mkvextract tracks v4.mkv 0:v4.hevc
mkvmerge -o v5.mkv v4.hevc
mkvextract tracks v5.mkv 0:v5.hevc
mkvmerge -o v6.mkv v5.hevc
mkvextract tracks v6.mkv 0:v6.hevc
...

The number of SEI in the files should be equal the number in filename.

Mkvmerge copies the headers into the mkv CodecPrivate element. If you demux in "normal" mode (i.e. without --raw parameter) using mkvextract those headers will be re-added. Since mkvmerge does not remove them the amount of headers will increase with every generation of mux/demux. While this is not wanted it might not qualify as a bug. I think these might be relevant:
https://github.com/mbunkus/mkvtoolnix/issues/1076
https://github.com/mbunkus/mkvtoolnix/commit/4207f953d9061e8c911df928c8ad5b81b81d891c

/edit2:
(Had old mkvtoolnix installed for first test. Ignore my first edit.)

[Mosu]

sneaker_ger's correct. There are several formats for which the data stored in CodecPrivate is duplicated in the frames. These include h.264, h.265 and even older ones like MPEG-1/2. Why? Several reasons.

One problem is that the private information may change over time (e.g. you can concatenate two MPEG-2 files and most players will play resulting file just fine, even if the sequence headers change mid-stream). Coming back to Matroska this means that the change in CodecPrivate content would have to be signalled somehow. For that we introduced the CodecState element (way back when there was no h.264) which would contain the new content for CodecPrivate and be located right before the frame that needed those parameters. Unfortunately no player implemented support for CodecState, and I had to revert to keeping the sequence headers inline.

That's the answer to »why is that data stored in the frames, too«.

Now to mkvextract. At the moment mkvextract extracts the headers (sequence/video/whatever parameter sets) from the CodecPrivate and writes them into the output file. Then mkvextract finds the first frame (which includes those parameter sets as discussed above) and writes that frame into the output file, too – which now includes the headers twice.

Technically speaking mkvextract could be made to scan the first frame for the headers, compare them with what's present in CodecPrivate and only write the parameter sets if they're missing from or different than the ones in the first frame. But I don't really care about that, and my time is limited, so I will definitely not do that myself.

[filler56789]

Nitpick:

"bunkus.org/videotools/mkvtoolnix/win32/pre/" became a misnomer (sort-of), since the amd64 builds can't be executed on Windows XP :)

[Mosu]

I know, but a lot of people know that directory, therefore I haven't renamed it (yet).

[Mosu]

Meh. I decided to rename it to »windows« and promptly made an error during syncing the directory to my server resulting in the whole directory being lost. Good thing I have backups :)

[filler56789]

Me too has backups of MKVtoolnix, I've been downloading and archiving those "pre" builds since ages ago :D

[Qaq]

Just got 1073741819 error code (2-3 attempts). I tried to mux:
- m2v (50i) video from PAL DVD (demuxed by PgcDemux 1205 without any error);
- FLAC from that DVD (LPCM demuxed by PgcDemux and packed to FLAC by eac3to without any error).
MkvMerge is 7.8.0 x64 version. Any tips on whats wrong and how to fix?

[Mosu]

That error code usually means that mkvmerge ran out of memory which is almost always due to either bogus file data or a bug in mkvmerge. I would need the two files in question if you want me to take a look.

[ndjamena]

Just got 1073741819 error code (2-3 attempts). I tried to mux:
- m2v (50i) video from PAL DVD (demuxed by PgcDemux 1205 without any error);
- FLAC from that DVD (LPCM demuxed by PgcDemux and packed to FLAC by eac3to without any error).
MkvMerge is 7.8.0 x64 version. Any tips on whats wrong and how to fix?

Yes, Mosu, please fix that... :)

(try it with just the m2v and see if it still happens, then try... 7.3.0 I think it was...)

[Qaq]

I would need the two files in question if you want me to take a look.PM sent. oops, sorry, didn't see your signature notification cause I had them disabled.
(try it with just the m2v and see if it still happens, then try... 7.3.0 I think it was...)I tried it first with 7.3.0 and just tried with m2v only. Still the same.

EDIT: Mosu, no need to check it. It seems something went wrong with DVD ripping though and data is incomplete. My bad.

[Mosu]

Yeah… I cannot find a problem with the two files here either. I've muxed both three times: on Linux (64bit) and on Windows (both 32 and 64bit builds). Everything's fine, memory usage stays pretty much constant.

[Chetwood]

Mosu, I've tried to append some files that have identical tracks but mmg doens't see it this way. I've uploaded a small zip to your FTP with Mediainfos output. Maybe that is sufficient.

[Mosu]

Do you mean the file append.error-the.formats.do.not.match.rar from April 1st? If so: I've already deleted that file as I couldn't associate it with any request.

What would the actual error message be, BTW? MediaInfo output is most likely not helpful on its own.

[ndjamena]

When remuxing m4vs...

MMG doesn't seem to take into account a tracks "enabled" flag, which behaves much like a "default" flag in an MKV, is this deliberate?

When extracting chapter images, shouldn't MKVMerge save them as attachments rather than as a video stream, after all: it doesn't extract apple text chapters as a subtitle track.

[Mosu]

mkvmerge doesn't evaluate that flag.

Chapters in MP4 files are a steady stream of funny tales… meaning the different ways suck. It's not really unusual that mkvmerge doesn't behave the way you expect it to.

[ndjamena]

It's itunes, and apparently they've been doing it the one way for quite a while:

http://code.google.com/p/subler/issues/detail?id=27

I don't really care, it just took me a while to figure out what the hell that second video track was.

(mkvextract cues, mkvmerge "split at chapters", mkvextract -raw)

[ndjamena]

Just so I'm sure we're on the same page:

Video #2
ID : 8
Format : JPEG
Codec ID : jpeg
Duration : 1h 49mn
Bit rate mode : Variable
Bit rate : 3 891 bps
Width : 640 pixels
Height : 360 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Variable
Frame rate : 0.002 fps
Minimum frame rate : 0.001 fps
Maximum frame rate : 0.004 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 8.444
Stream size : 2.78 MiB (0%)
Language : English
Encoded date : UTC 2014-02-14 22:47:03
Tagged date : UTC 2014-02-14 23:02:54

Menu
ID : 7
Codec ID : tx3g
Duration : 1h 49mn
Language : English
Encoded date : UTC 2014-02-14 22:47:03
Tagged date : UTC 2014-02-14 23:02:54
Source duration : 6589756
Source frame count : 12
Source stream size : 215
Frame count : 12
Stream size : 215
00:00:00.000 : Opening Credits/A Shooting Star
00:09:21.000 : Electrical Marvel
00:19:16.000 : "Run, Dorothy, Run!"
00:28:40.000 : The Yellow Brick Road
00:40:41.000 : Princess Mombi
00:46:23.000 : Jack Pumpkinhead
00:54:19.000 : Powder Of Life
01:04:42.000 : Crash Landing
01:12:37.000 : Three Chances
01:26:26.000 : Scarecrow
01:34:16.000 : Emerald City
01:45:08.000 : End Credits
Bit rate mode : VBR



The chapter thumbnails are there in addition to the apple text chapters. I should think there's something in the file that signals what it's for and it seems to be rather standard itunes stuff.

Encoded date : UTC 2014-02-14 22:47:11
Tagged date : UTC 2014-02-14 23:02:54


In case someone didn't already know.

[Mosu]

I currently have no plans of looking into that.

[ndjamena]

I though it was interesting.

And here's the disabled flag:

Track # 3 Info - TrackID 3 - TimeScale 48000 - Media Duration 01:49:49.760
Track has 1 edit lists: track duration is 01:49:49.759
Track is disabled
Media Info: Language "English (en-US)" - Type "soun:ac-3" - 205930 samples
AC-3 stream - Sample Rate 48000 - 5.1 channel(s) - bitrate 192000
RFC6381 Codec Parameters: ac-3
Alternate Group ID 1
All samples are sync

MP4Box doesn't show it when it's enabled, but it works just like a default flag (other than that if there's two of them for one type, both tracks are played at the same time). It's odd how many people don't know that exists.

[Boulder]

I've got a large amount of ERR312's in the mkvalidator log with Opus audio, for example:

ERR312: CueEntry Track #3 and timecode 8544636 ms not found
ERR312: CueEntry Track #1 and timecode 8545454 ms not found

When muxing the same video and subtitle track with FLAC audio, there are no such errors.

I've not seen these errors with other files, but this one (the first Hobbit movie) is over 3 hrs long which makes it a bit different from the others.

[Mosu]

I cannot reproduce such errors with mkvalidator 0.5.0 and a random file with Opus inside. So you'll have to provide me with a sample file if you want me to take a look…

[Boulder]

While trying to remux the file (because I couldn't reproduce it by demuxing to elements and muxing them), I found out that the Matroska file contains errors. This is really weird because I just muxed the original file and moved it over the network from my desktop PC to the external HD without any CRC differences (used Teracopy to move the file). It seems that the external HD is going bad :(

[Mosu]

Bad hardware will get you all the time, yeah :( I just had to replace two hard drives in my RAID 6 array. Luckily I'm a big fan of RAID 6 and not just of RAID 5…

[Carpo]

When using mkvalidator on any MKV I have made using 7.70 or 7.8.0 I always get the output

ERR200: Missing element 'Targets' in Tag at 12282419123.
WRN0D0: There are 5938 bytes of void data........................

file created with libebml v1.3.1 + libmatroska v1.4.2 / mkvmerge v7.8.0 ('River Man') 64bit built on Mar 27 2015 16:31:37


The targets error changes depending on the size of the file, but I always get those 2 lines on every MKV file, is this any thing to be concerned about and if so how to fix?

[Mosu]

I don't get that error with mkvalidator with 0.5.0 with a file I've just created with mkvmerge 7.8.0. Are you attaching custom tags? Are you merging files with tags (apart from the statistics tags mkvmerge creates itself)?

[Carpo]

Ah yes I forgot about that, I am adding imdb information from a custom made xml file, I will try without this information

[Mosu]

Please send me the XML file in question ( moritz@bunkus.org ) along with the actual command line used. Thanks.

[Carpo]

Sent information as requested

edit: here is the command line as requested

"C:\Program Files\MKVToolNix\mkvmerge.exe" -o "E:\\Batman Returns.mkv" "--language" "0:eng" "--forced-track" "0:no" "--display-dimensions" "0:1920x1080" "--compression" "0:none" "-d" "0" "-A" "-S" "-T"
"--no-global-tags" "--no-chapters" "(" "D:\\Videos\\Movies\\Batman Returns_track1_eng.264" ")" "--language" "0:eng" "--sync" "0:0" "--forced-track" "0:no" "--compression" "0:none" "-a" "0" "-D" "-S" "-T"
"--no-global-tags" "--no-chapters" "(" "D:\\Videos\\Movies\\Batman Returns_track2_eng_DELAY 0ms.ac3" ")" "--track-order" "0:0,1:0" "--global-tags" "D:\\Batman Returns Custom.xml"

[Mosu]

Even with the file and the command line you've sent me I cannot reproduce the issue. mkvalidator 0.5.0 stays silent (apart from the void warning).

Which version of mkvalidator are you using? If it's anything else than 0.5.0 then upgrade to 0.5.0, please.

BTW: Note that your XML file is invalid. Even though it is encoded as plain ASCII or UTF-8 its header states »utf-16«.

[Carpo]

Yes I am using 0.5.0, I will change the XML, Let me try something, I wonder if the HTPC software is doing something

edit: seems my PC must have a gremlin, because I have remuxed it on the Linux PC and it doesnt show an error, and have remuxed it in PC again and its fine, so I havent got a clue.

Will Try a few more movies

[ndjamena]

Should I assume Matroska will never support 608 captions in any form?

[Mosu]

Closed captioning? Well, I do have that on my TODO list somewhere (would be converted into something like S_TEXT/UTF8 subs automatically), but don't hold your breath.

[ndjamena]

???

I got sick to death of DVDs (frame rate conversions, edge enhancement, HD shows that were never released on Blu Ray) and finally made the switch to iTunes, they've included ALL their subtitles as 608 caption tracks. I've extracted them with MP4Box and am half way through writing a utility to convert them to srt. The program works perfectly with the sample file I'm using but it still needs a lot of work to be fully 608 compliant...

I don't know what you know about the captions but they're not self contained frames, they're a continuous series of commands that are applied to buffers, with some of said buffers overlaid onto the screen. Pop-up mode is easy enough to convert to srt, Paint-on mode would be odd in srt form (but doable), roll-up style would never work properly... I think Text Mode is a single line that gets updated with miscellaneous data, and as far as I can tell XDS are more like tags...

I'd feel better if I could store the original data in the file though, I can't image any conversion process being completely lossless. VLC can't read them from the mp4 yet (it is on the to do list though) but it can already decode 608 captions from DVD (it's not like 608 caption decoders are hard to come by) and they're essentially the same thing.

(I'm have trouble figuring out which of the control characters actually take up space... I'm thinking it's all the ones that change the style of the text. One line in my sample simply can't work without the midrow commands taking space (it looks right in iTunes), but the documentation I've found doesn't mention it (or at least I haven't found it yet).)

Just figuring out my options.

[Mosu]

I don't know a lot about CCs, and to be honest being a European I don't particularly care. I do know that they're not simple text that could be converted easily, but that's about all, and that's also one of the reasons why I haven't really bothered looking into it.

Like I said, don't hold your breath.

So Apple uses 608 captions intead of the standardized timed text in MP4 (http://en.wikipedia.org/wiki/MPEG-4_Part_17)? This sounds so ridiculous it isn't even funny anymore.

[ndjamena]

I'm not exactly Pro Apple (I am trying to get them OUT of the m4v, after all), but that doesn't change the fact that these are the best quality versions I can find (I've already wasted a lot of money on DVDs that are now redundant because I didn't want to have to go through iTunes) and I have to deal with these files somehow.

(Both tracks 7 and 8 are listed in each of the other tracks' "chap" headers. Finding a way to add a thumbnail to each chapter is NOT something I'm going to condemn them for, I just wish they didn't have to add them as tracks (and it makes reusing the images without duplicating them impossible).)

[stax76]

I've a MakeMKV created file where MediaInfo shows iw as language code for a vobsub subtitle, when I demux it with mkvextract it's en in the idx and not iw or he, on the ifo file MediaInfo shows he, to MPC-BE iw is unknown too.

[Mosu]

I'd need access to that Matroska file if you want me to comment.

[stax76]

it should be on your ftp in a minute or two.

[Mosu]

Thanks.

This is a bug in MakeMKV. Matroska uses ISO 639-2 language codes (http://www.loc.gov/standards/iso639-2/php/code_list.php) in all of its elements that indicate a language. However, MakeMKV has written »iw« into the »track language« element. While »iw« is a valid ISO 639-1 language code it is not a valid ISO 639-2 language code.

During extraction mkvextract validates that language element, finds it to be invalid and discards it. After discarding it the »track language« is treated the same way as if it were absent from the file, which means that its default value (»eng«) is assumed. Then mkvextract writes the IDX for the VobSub and translates the ISO 639-2 code »eng« into the ISO 639-1 code »en« (VobSub indexes use ISO 639-1 language codes), and that's why you see »en« in the resulting .idx file.

As this has happened in the past mkvmerge corrects such entries automatically during a re-mux: it mapps the ISO 639-1 codes to their corresponding ISO 639-2 codes. Therefore the re-muxed file's track language is set to »heb«. If you extract the VobSubs from that re-muxed file then your .idx file will finally contain »language: he«. But like I said: the original bug is in MakeMKV, not mkvextract.

Edit: fixed information about mkvmerge.

[stax76]

Thanks for looking into it, I reported it to mike. In the past I always ripped German and English only, now I'm always ripping everything to test StaxRip. I map absence to undetermined, it seems more logical to me.

[Mosu]

Mapping absence to »und« is simply wrong. See the specs (http://www.matroska.org/technical/specs/index.html). Yes, »und« should have been the default and not »eng«, but the default value is »eng«, and if you treat absence as anything other than »eng« then your application is buggy and doesn't act like all the other Matroska-supporting applications do.

[stax76]

You are right, sorry for not making a clear statement, I use MediaInfo for everything, it was meant for non Matroska standalone audio files for instance like AC3 or DTS.

[Mosu]

Ah right. That makes perfect sense.

[sneaker_ger]

During extraction mkvextract validates that language element, finds it to be invalid and discards it. After discarding it the »track language« is treated the same way as if it were absent from the file, which means that its default value (»eng«) is assumed. Then mkvextract writes the IDX for the VobSub and translates the ISO 639-2 code »eng« into the ISO 639-1 code »en« (VobSub indexes use ISO 639-1 language codes), and that's why you see »en« in the resulting .idx file.
Mkvextract does this even for mkv tracks that are correctly marked as "und". I tried to search for correct "und" equivalent in idx files but it's not easy to find. In guliverkli source it says "--" but BDSup2Sub does not detect it. There doesn't seem to be a broadly compatible way to do this.

[Mosu]

Thanks for pointing it out, sneaker_ger. I'm not sure whether this behavior is intentional or accidental. I might consider changing it either writing »language: --« or not writing a language line at all if there's interest in such a change.

[ndjamena]

The default value would have been chosen for compression purposes (ie "eng" would likely be used more often than any other language code), have we now decided that that was wrong and that its absence should have indicated a literal lack of a known value?

[sneaker_ger]

No. Absence still means English and this will probably never change.

[sneaker_ger]

Thanks for pointing it out, sneaker_ger. I'm not sure whether this behavior is intentional or accidental. I might consider changing it either writing »language: --« or not writing a language line at all if there's interest in such a change.
I'm not even sure I understood the guliverkli source correctly so I think it's better to leave as is until someone more knowledgeable comes around.

[Mosu]

The default value would have been chosen for compression purposes (ie "eng" would likely be used more often than any other language code)

Disregarding the fact that English is only on third place (http://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers) regarding the number of native speakers this reasoning doesn't really make sense. The language element is five bytes long, therefore space considerations aren't really all that important here.

Even more important: video tracks usually don't have a language. However, most people don't flag a video track as »undefined«. Therefore they implicitly flag them as »English«.

So from a semantic point of view a default value of »und = undetermined« would have been better (meaning anything from »hasn't been set« to »doesn't apply because track has no language«). But specs are specs, therefore this cannot be changed anymore.

[ndjamena]

Most Number of Speakers != most used language code in media files.

Whether video tracks have a language or not is open to interpretation, but things filmed in America can generally be considered "English", because all the signage is in English.

I thought MKVs were primarily designed to hold Movies, TV Shows and other commercial media rather than home movies and such, maybe it's just me being Australian, but I would have thought the majority of those kind of things in circulation in the world would be from the U.S. of A... how often do The Chinese wouldn't watch Indian or Spanish movies?

I have no opinion either way, just assumptions on why things are why they are.

-Edit- And Language alone isn't what improves compression, it's all the defaults combined, including Default Duration.

[Mosu]

Default duration has an impact for each and every group. Its savings scale with the number of frames, and they're the bigger the smaller the frames are (let's TrueHD as an example: one TrueHD frame is often under 1ms in duration resulting in over 1000 frames per second – not having to write the duration for each frame is very, very useful). For the same reasons we introduced the SimpleBlock structure as its simplification over a BlockGroup scales linearly with the number of frames. These savings can be measured in promille or sometimes even percent.

Those optimizations make sense.

The track's language on the other hand is a fixed, five-bytes saving per English track. You usually only have one or two tracks per file which share the same language (one audio, one subtitle or a second audio with e.g. director's comments). Contrast that with the fact that the video track would often have to be tagged with »und« erasing those optimizations. Doing this in order to save space would not make any sense at all; it's savings (if there are any) are not even one thousandth of a promille.

We simply didn't really think it through when we made »eng« the default.

[ndjamena]

We simply didn't really think it through...

I have nothing intelligent to say now, I'm too busy laughing. I've lost count of the number of different ways I've had to find to phrase that sentiment while dealing with the Matroska specs...

I don't suppose MP4 is any better...

[CyberTootie]

Has delay handling recently been changed? I'm having an issue where a h.264 video stream is not being delayed as intended. Negating that value in the audio stream delay gets the sync I want, but cuts off the beginning of the audio.

[hello_hello]

Most Number of Speakers != most used language code in media files.

Whether video tracks have a language or not is open to interpretation, but things filmed in America can generally be considered "English", because all the signage is in English.

I thought MKVs were primarily designed to hold Movies, TV Shows and other commercial media rather than home movies and such, maybe it's just me being Australian, but I would have thought the majority of those kind of things in circulation in the world would be from the U.S. of A... how often do The Chinese wouldn't watch Indian or Spanish movies?

I have no opinion either way, just assumptions on why things are why they are.

As a side note.....
I'd have thought a button to click on that'd automatically set English as the default language might make things easier for English speakers when setting track languages before muxing. It'd make it easier for speakers of any language if you could select which language is set when you click on the default button. The same button could default to setting a track as default and/or forced too, according to user preference. I think I've mentioned the idea before.

Recently I upgraded MKVMergeGUI 7.6.0. I'd been putting it off as I'd read about the introduction of the "Toggle All" button. Sure enough, there it was, mocking me. Laughing at me, fully aware of it's ability to frustrate through it's mere existence. It might have been something useful, a button that with a single click might have reset each track to a pre-specified language and default status etc, but instead I click on the language field, scroll, select English, select the next track, click on the language field, scroll, select English, select the next track, click on the language field, scroll, select English...... whoops, I missed that one and selected "all" instead..... click and scroll again. Now to set the default status for each track.......
And all the while that "toggle all" button laughs at me because it knows it'll rarely be used. If ever.......

Anyway, in all seriousness thanks for the continued work on MKVToolNix Mosu! It's appreciated!

[Mosu]

It might have been something useful, a button that with a single click might have reset each track to a pre-specified language and default status etc, but instead I click on the language field, scroll, select English, select the next track…

It does exactly what the person requesting the feature asked for: enable/disable all tracks.

Anyway, you'll be happy to know that the new GUI (https://github.com/mbunkus/mkvtoolnix/wiki/MKVToolNix-GUI-status/) will allow you to select more than one track at the same time (even all tracks at once!) and change the language for all selected tracks with scrolling through that list only once. It's also written using the Qt library instead of wxWidgets, meaning keyboard shortcuts should work much more consistently (e.g. hitting Ctrl+A when the focus is on the track view should cause all tracks to be selected; hitting any key while a combobox is selected should jump to the first entry starting with that key – e.g. quickly hitting »germ« should leave »German« selected).

[Mosu]

Has delay handling recently been changed? I'm having an issue where a h.264 video stream is not being delayed as intended. Negating that value in the audio stream delay gets the sync I want, but cuts off the beginning of the audio.

I don't recall any such change, and neither can I see a problematic behavior in my short tests (output slighly truncated):

[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o v.mkv --sync 0:100 v.avi
mkvmerge v7.8.0 ('River Man') 64bit built on Apr 15 2015 15:24:23
'v.avi': Using the demultiplexer for the format 'AVI'.
'v.avi' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
…
[0 mosu@sweet-chili ~/prog/video/data] mkvinfo -s v.mkv|grep 'track 1'|head -n 1
I frame, track 1, timecode 100 (00:00:00.100), size 12973, adler 0xc59f1503
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o v2.mkv --sync 0:200 v.mkv
mkvmerge v7.8.0 ('River Man') 64bit built on Apr 15 2015 15:24:23
'v.mkv': Using the demultiplexer for the format 'Matroska'.
'v.mkv' track 0: Using the output module for the format 'AVC/h.264'.
…
[0 mosu@sweet-chili ~/prog/video/data] mkvinfo -s v2.mkv|grep 'track 1'|head -n 1
I frame, track 1, timecode 300 (00:00:00.300), size 12973, adler 0xc59f1503
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o v3.mkv --sync 0:400 v.h264
mkvmerge v7.8.0 ('River Man') 64bit built on Apr 15 2015 15:24:23
'v.h264': Using the demultiplexer for the format 'AVC/h.264'.
'v.h264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
…
[0 mosu@sweet-chili ~/prog/video/data] mkvinfo -s v3.mkv|grep 'track 1'|head -n1
I frame, track 1, timecode 400 (00:00:00.400), size 13008, adler 0xce7e1eab

This I'd consider »working as intended«. Can you provide a lot more details?

[hello_hello]

I tested setting a video delay with MKVMergeGUI 7.6.0 and 7.8.0 after CyberTootie posted about the problem here (http://forum.videohelp.com/threads/371374-MKVmerge-video-delay-not-working) and it seemed to work as expected each time. I suspect it's a player issue.

[ndjamena]

In the MMG chapter editor, when navigating in the Tree View using the up and down arrows can we NOT have the focus change to the Name Textbox, up/down doesn't work from there so it limits movement to a single chapter. It would take 9 tab presses or intervention by a mouse to get back to the tree view from there.

(Or maybe allow moving between chapters using up/down while in the Name Textbox, that would fix it too [although considering including the multiple names box could complicate things].)

[Mosu]

Issues in mmg will not be addressed anymore; see https://github.com/mbunkus/mkvtoolnix/wiki/MKVToolNix-GUI-status/

[CyberTootie]

I don't recall any such change, and neither can I see a problematic behavior in my short tests...

This I'd consider »working as intended«. Can you provide a lot more details?

Thanks, I'm not sure how you're getting those stats, here's a screenshot of what I'm doing in MKVmerge and the resulting pertinent info in MKVinfo:
http://imgur.com/eL1j3To

14736

[hello_hello]

Has delay handling recently been changed? I'm having an issue where a h.264 video stream is not being delayed as intended. Negating that value in the audio stream delay gets the sync I want, but cuts off the beginning of the audio.

I don't recall any such change, and neither can I see a problematic behavior in my short tests

It seems the issue is changing the frame rate and setting a video delay at the same time. If the frame rate is changed and a positive video delay is specified, the video delay is ignored. Changing the frame rate in combination with a negative video delay seems to work though.

The behaviour is the same for versions 7.6.0 and 7.8.0.

[sneaker_ger]

I cannot reproduce. Can you upload a sample and post the complete command?

[hello_hello]

"C:\Program Files\MKVToolnix\mkvmerge.exe" -o "E:\\test.mkv" "--language" "0:eng" "--sync" "0:2000" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:720x404" "--default-duration" "0:24fps" "--language" "1:eng" "--default-track" "1:yes" "--forced-track" "1:no" "-a" "1" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\test.mkv" ")" "--track-order" "0:0,0:1" "--disable-track-statistics-tags"

Every single sample I've tried behaves the same way. The above was originally 25fps h264 and stereo AAC audio (I haven't tested without the audio as the whole point of a delay is usually to sync the video and audio). I specified 24fps and a video delay of 2000ms. The result would normally be (when specifying a positive video delay) the first frame being displayed for two seconds. That doesn't happen. The video and audio start off perfectly in sync, even though they wander out pretty quickly due to the frame rate change.

The extracted video timecodes look like this:

# timecode format v2
0
42
83
125
167
208
250
292

The following gives me a first frame that displays for two seconds and the audio sync is 2 seconds out all the way through as I didn't change the frame rate, so I can only assume "--sync" "0:2000" is being applied this time but not the first for some reason.

"C:\Program Files\MKVToolnix\mkvmerge.exe" -o "E:\\test2.mkv" "--language" "0:eng" "--sync" "0:2000" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:720x404" "--language" "1:eng" "--default-track" "1:yes" "--forced-track" "1:no" "-a" "1" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\test.mkv" ")" "--track-order" "0:0,0:1" "--disable-track-statistics-tags"

The extracted video timecodes look like this:

# timecode format v2
2000
2040
2080
2120
2160
2200
2240
2280

The only way I seem to be able to apply a positive video delay and change the frame rate is by doing it in two steps.

[Mosu]

Thanks for the analysis. This is most likely a bug, and I'm pretty sure what happens. Forcing the default duration is implemented by the same code that handles timecode files. Actual timecode files are supposed to supersede any other calculation (this is the equivalent of "I know better, so shut up already!") and is therefore applied after all other timecode modifications have been done.

Unfortunately these semantics conflict with what one would expect of using --default-duration.

I'll fix it; should be easy enough to simply do.

[hello_hello]

I think I heard a penny drop........ (Edit: It dropped before I read Mosu's post. Honestly. We were typing at the same time..... ;))

It makes sense now I see the command line in front of me. Specifying a positive video delay effectively makes it variable frame rate. When you specify a frame rate, MKVMerge outputs a constant frame rate. So the above command line varies the frame rate, then makes it constant again. I assume......

If that's all the problem is, the GUI would just need to add the two to the command line in the opposite order. It'd also explain why a frame rate change and a negative video delay seems to work as I assume the required number of frames are deleted and the output is constant from then on, although if the specified negative video delay and the gop size don't match and MKVMergeGUI needs to apply some sort of positive video delay to compensate, then it changes the frame rate...... I guess doing it in the opposite order would still be better.

[Mosu]

The order on the command line is irrelevant. The order in the source code is. Therefore it will have to be fixed in mkvmerge, not the GUI.

[sneaker_ger]

Every single sample I've tried behaves the same way.
I only tested raw source files, not mkv. Unlike mkv and mp4 they seem unaffected.

[hello_hello]

The order on the command line is irrelevant. The order in the source code is. Therefore it will have to be fixed in mkvmerge, not the GUI.

I was on the right track though, so I'll at least award myself a couple of clever points. :)

Thanks.

[Mosu]

The --default-duration/--sync problem has been fixed in pre-builds 694 and higher (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/).

[Ex0rcist]

Hi,

http://forum.doom9.org/showpost.php?p=1660312&postcount=3833

I'm wondering the same as the guy in the post I liked above. This only happens when resolution is 718x404. Is there any reason why that happens? If I use the same file and mux it into mp4 container, the "original display aspect ratio" flag isn't present.

[Mosu]

How does that linked post have anything to do with MKVToolNix?

[Ex0rcist]

x264 file:

Width : 718 pixels
Height : 404 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Scan type : Progressive

mkv file:

Width : 718 pixels
Height : 404 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 16:9
Frame rate : 25.000 fps
Scan type : Progressive

mp4 file:

Width : 718 pixels
Height : 404 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Scan type : Progressive


It only appears when using mkv container, that's why.

[Mosu]

I ask again, how is that relevant to MKVToolNix? Where is MKVToolNix used? This is a thread about MKVToolNix, not about the Matroska container in general.

Also: if you want to know why MediaInfo outputs information XYZ then please ask the MediaInfo guys first. I don't know their source code!

[Ex0rcist]

I'm sorry, maybe I should be more specific that .mkv file was made using mkvtoolnix. Anyway, you probably are right, it has to be mediainfo issue. I got tricked because mp4 container didnt have that flag enabled but mkv did, that's why I thought it's mkvtoolnix issue. At least I know what is it all about now. Sorry for the confusion.

[ndjamena]

(Windows) If I inadvertently manage to add a colon (:) to the output file name (ie by copying the title field from the container) mkvmerge will run through the files as normal but I'll be left with a zero length file at the end (with the file name truncated at the colon).

It doesn't even produce a warning.

(Should I take it MKVToolNix supports Linux files with colons in the name now?)

[Mosu]

Interesting bug. Note that certain file systems forbid certain characters in their name. On Windows this includes colons, but those are indeed allowed on Linux. mkvmerge doesn't try to be clever about this, it simply tries to open the file name the user specified. The idea is that the OS should tell mkvmerge that the name is not allowed by signalling an error; why that doesn't work as intended is something I will have to investigate at some point.

[DarkSpace]

[I've been tired, misread stuff, and edited it away. I can't remove my post, though.]

[Edit again] (assuming NTFS)
I think your data is written to file:after_colon after all: The after:colon part is an NTFS substream of file, so try accessing it by e.g. moving file:after_colon to file_data ("move file:after_colon file_data") [I have no idea if that will work, but it's worth a try]

[Edit: rewording of the explanation's first part]
The colon tells Windows to access not file itself, but the substream named after_colon of file. Because this works without a problem, mkvmerge works, Windows accesses file, file doesn't exist so it's created, accesses file's substream, the substream doesn't exist, so it's created, then it's opened. I hope this sounds at least somewhat coherent...

[ndjamena]

http://www.faqforge.com/windows/use-alternate-datastreams-to-hide-important-files-windows-ntfs/

So, basically, if there was program support for it, I could move all my movies out of their dedicated folders and move the cover images to "Transformers_ Age of Extinction (2014):cover.jpg" and all the metadata to "Transformers_ Age of Extinction (2014):movie.xml"... Then I could add things like "Alien (1979).mkv:Directors Cut.mkv" so I could have two versions of the movie taking up one slot in the file system... oh, wait...

[Brother John]

Apparently mmg is a bit more clever/restrictive. It rejects colonised file names.

@ndjamena
Basically, yes, you could do that. Though it’s a really fragile solution. The moment you copy such a file to a non-NTFS file system or you copy it with a non-substream-aware copy routine you’ll lose the substreams.

At the end of the day pestering player developers about better attachment, tags and ordered chapters support seems like the more promising approach. ;)

[ndjamena]

Apparently mmg is a bit more clever/restrictive. It rejects colonised file names.

@ndjamena
Basically, yes, you could do that. Though it’s a really fragile solution. The moment you copy such a file to a non-NTFS file system or you copy it with a non-substream-aware copy routine you’ll lose the substreams.

At the end of the day pestering player developers about better attachment, tags and ordered chapters support seems like the more promising approach. ;)

Actually, I'd love to be pestering developers to support those things, and tried for a while. Unfortunately it's impossible to support things that don't work and make no sense.

[ndjamena]

MMG still doesn't notice anything is wrong when I try to save chapters into an mkv while it's locked by AVIDemux. That was 10 minutes wasted. (Saving chapters to a file that didn't have any using [Save to Matroska File]).

(I assume MKVToolNixGUI uses the same code...)

While I'm at it, Explorer adds double quotes to file names copied using the "Copy Path" button which MMG rejects as invalid. Can TNX be written to remove the quotes instead?

[Mosu]

Technically? Sure. Will I invest time in it? No.

The new GUI will allow drag & drop directly onto file name inputs anyway.

[ndjamena]

Um, I have batch files to handle most of the day to day muxing, and only really use MMG for special cases... and I copy paste the file names into the OUTPUT field (for various reasons). Drag and drop works fine for input already.

Actually, the file selection popup windows accept copy/pasted double quoted names as well, handling them is just a basic part of the processing Windows applies to all file names already, it's just the MMG Output Filename at the bottom that doesn't accept them.

It's not important, but it does get a tad irritating and I thought I'd bring it up.

[Mosu]

And the inputs for tag/chapter/timecode/segmentinfo files. Etc. Basically everywhere which is not a file dialog.

[Megalith]

Where is the option to ignore the AC3 core track from being included from a TrueHD track?

EDIT: Nevermind, I'm an idiot. Obviously you can just uncheck the AC3 stream in the Input options...

[ndjamena]

MakeMKV is complaining bitterly about any VC-1 track that has been remux using MKVMerge, so far the only difference I can see using MKVInfo is that the first frame in the MKVMerge file is 33 bytes longer for some reason. The file was originally created by MakeMKV then remuxed by MKVMerge, so is this added 33 bytes expected?

http://www.makemkv.com/forum2/viewtopic.php?f=8&t=9039

[Mosu]

Hey,

I've released MKVToolNix v7.9.0.

First of all a note to all Windows users: I've renamed the downloads slightly. They're now named e.g. mkvtoolnix-32bit-7.9.0-setup.exe etc. The difference is that 64bit builds use …-64bit-… instead of …-amd64-… and that the 32bit builds include their architecture (-32bit-) in their name for the first time. This was done in order to reduce the confusion sown by the term »amd64« which denotes the processor architecture but not the manufacturer. Many people weren't aware of that differentiation.

As for the changes in this release: A couple of important bugs have been fixed, e.g. a very old bug in handling MPEG-1/2 video preventing the detection of such tracks; if --sync was used at the same time as --default-duration then --sync was ignored; mkvinfo's exit codes were wrong (this may trip up frontends using mkvinfo!); handling of E-AC3 in MPEG transport stream in certain situations etc. See below for all the details.

Since the previous release a serious amount of work has gone into the new GUI, MKVToolNix GUI. It has reached a state in which I consider it fit for wider use. I've therefore removed the preview warning and included it in all the packages that I provide (both Windows and Linux).

If everything goes according to plan then the next release, 8.0.0, will see the old GUI (mmg, mkvmerge GUI) be marked as being deprecated – meaning there will be a popup message warning you about this fact when you start mmg. Two releases later, with 8.2.0, the old GUI will finally be removed among with all support for the wxWidgets toolkit.

Of course all of this depends on the number and seriousness of bugs found in the new GUI ;) Therefore these plans are not set in stone.

Changes for package maintainers: configure will now detect the presence of the Qt libraries version 5.2.0 or later by default and use them if they're found. This means that at the moment both GUIs (mmg and MKVToolNix GUI) will be built unless you tell configure otherwise. There are several switches that deal with the various toolkits:

--disable-gui – don't build any GUI support, neither wxWidgets nor Qt based (same as for the previous releases)
--disable-wxwidgets – don't build wxWidgets-based GUIs (mkvinfo's wxWidgets frontend, mmg)
--disable-qt – don't build Qt-based GUIs (mkvinfo's Qt frontend, MKVToolNix GUI)
--without-mkvtoolnix-gui – build mkvinfo's Qt-based frontend but not MKVToolNix GUI

The two different frontends for mkvinfo are mutually exclusive with the Qt-based version taking precedence over the wxWidgets-based version.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-05-10 Moritz Bunkus <moritz@bunkus.org>
* Released v7.9.0.
* build system: configure will now check for Qt by default. If at least v5.2.0 is found then the Qt versions of mkvinfo's GUI and the new mkvtoolnix-gui will be enabled. You can affect this detection with the options --disable-gui (turns off all GUIs; works the same as before), --disable-qt (will compile the wxWidgets GUI for mkvinfo and mmg) and --without-mkvtoolnix-gui (will compile the Qt version of mkvinfo's GUI but no mkvtoolnix-gui).

2015-05-07 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: mkvinfo would exit with the wrong return code (0 instead of 2) if a non-existing file name had been given. Fixes #1182 (https://github.com/mbunkus/mkvtoolnix/issues/1182).

2015-05-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Two more characters are now escaped in the container and track properties output in verbose identification mode: [ is replaced with \b and ] with \B. This is needed for reliable parsing by other programs, e.g. GUIs.

2015-05-04 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: added context menu entries for tracks: »select all«, »enable all« and »disable all«.

2015-05-02 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: implemented aborting the currently running job.

2015-04-28 Moritz Bunkus <moritz@bunkus.org>
* all: fix compilation on Mac OS in common/command_line.cpp due to boost::range::filtered requiring a copyable functor. Fixes #1175 (https://github.com/mbunkus/mkvtoolnix/issues/1175).
* all: fix compilation on Mac OS in common/version.cpp due to wrong usage of std::stringstream and ostream operators. Fixes #1176 (https://github.com/mbunkus/mkvtoolnix/issues/1176).

2015-04-27 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: implemented the »additional command line options« dialog.

2015-04-25 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature in the chapter editor: added features »set the language/country of the selected chapter and its sub-chapters«.

2015-04-24 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: fixed compilation with Boost 1.58.0. Fixes #1172 (https://github.com/mbunkus/mkvtoolnix/issues/1172).
* mkvmerge: bug fix: Fixed a segmentation fault during cleanup after Ctrl+C was pressed. Fixes #1173 (https://github.com/mbunkus/mkvtoolnix/issues/1173).

2015-04-23 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature in the chapter editor: added features »clamping time stamps of sub-chapters to their parent's time stamps«, »expanding time stamps of chapters to encompass their sub-chapters' time stamps« and »shifting start and end time stamps by an offset«.

2015-04-22 Moritz Bunkus <moritz@bunkus.org>
* all: permanently removed the build times tamp from the version information and the corresponding configure option.

2015-04-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: the main window's size, position and state (maximized/minimized) is saved on exit and restored on startup.
* MKVToolNix GUI: new feature: the GUI is now fully translatable. The German translation has been completed for the GUI, too.

2015-04-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed --sync not doing anything if --default-duration is used for the same track, too.

2015-04-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed aborting file identification with an error message about »aac_error_protection_specific_config« that happened for some files. Fixes #1166 (https://github.com/mbunkus/mkvtoolnix/issues/1166).

2015-04-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: implemented changing the interface language.

2015-04-13 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: implemented often used subtitle character sets.
* MKVToolNix GUI: enhancement: implemented setting a user configurable subtitle character set by default.
* MKVToolNix GUI: enhancement: implemented the automatic removal of jobs configurable by the user.
* mkvmerge: bug fix: fixed specifying track properties like language or name for AC3 cores embedded in TrueHD tracks when they're read from raw thd+ac3 files. Fixes #1158 (https://github.com/mbunkus/mkvtoolnix/issues/1158).
* mkvmerge: enhancement for MPEG program stream handling: mkvmerge will only look for additional files automatically if the source file begins with »VTS_…« and just if it ends in a number. E.g. when reading »video_1.mpg« another file called »video_2.mpg« will no longer be read automatically. Implements #1164 (https://github.com/mbunkus/mkvtoolnix/issues/1164).

2015-04-12 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: display country names in addition to country codes.
* MKVToolNix GUI: enhancement: implemented often used languages and country codes.
* MKVToolNix GUI: chapter editor enhancement: implemented defaults for the language and country settings for newly created chapter names.
* MKVToolNix GUI: merge tool enhancement: added controls for mkvmerge's »reduce audio to its core« and »force NALU size length« features.
* MKVToolNix GUI: new feature: implemented the »Preferences« dialog (not all of the functionality the options refer to has been implemented yet, though).

2015-04-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG-1/2 parser: fixed a long-standing issue that prevented mkvmerge from recognizing certain MPEG-1/2 video tracks and files if the frame's sequence numbers didn't follow a certain expected pattern. Fixes #1162 (https://github.com/mbunkus/mkvtoolnix/issues/1162) and probably others like #1145 (https://github.com/mbunkus/mkvtoolnix/issues/1145) or #1099 (https://github.com/mbunkus/mkvtoolnix/issues/1099).
* MKVToolNix GUI: merge tool enhancement: Implemented adding and append files and adding files as additional parts via drag & drop from external applications.
* MKVToolNix GUI: merge tool bug fix: fixed the column headers on the »attachments« tab.

2015-04-10 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: implemented opening files via drag & drop from external applications.
* MKVToolNix GUI: enhancement: The portable Windows version will store its settings in a file in the same folder instead of the registry.
* MKVToolNix GUI: enhancement: Qt's »Windows Vista« style is now used on Windows instead of the old, Windows 98-like »Windows« style.
* MKVToolNix GUI: merge tool enhancement: The merge tool has been re-written to be tabbed like the header and chapter editors allowing for multiple merge job settings to be open at the same time.

2015-04-08 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: implemented re-ordering chapters and editions with drag & drop.

2015-04-06 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: implemented the chapter editor.

2015-04-04 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: implemented adding attachments via drag & drop from external applications.
* MKVToolNix GUI: new feature: implemented the header editor.

2015-04-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Implemented proper type output during identification for DTS-ES (extended surround) tracks. Implements #1157 (https://github.com/mbunkus/mkvtoolnix/issues/1157).

2015-03-31 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: implemented the online update check.

2015-03-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The calculation of the width and height of h.265/HEVC video tracks did not take the conformance window (cropping) into account. Fixes #1152 (https://github.com/mbunkus/mkvtoolnix/issues/1152).
* mkvmerge: bug fix: Fixed the value of the DocTypeVersion header field if any of the Matroska elements CodecDelay, DiscardPadding or SeekPreRoll is used. This is the case for Opus tracks.
* mkvmerge: bug fix: Fixed the handling of E-AC3 tracks in M2TS files if the AC3 core and the extension are stored in separate packets.
* mkvmerge: new feature: Implemented support for the DTS-HD container format.

2015-03-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Implemented support for core-less DTS streams consisting solely of XLL extension sub-streams.
* mkvmerge: new feature: track selection can be done by language codes as well. Affects the options --audio-tracks, --button-tracks, --subtitle-tracks and --video-tracks. Works only for containers that actually provide a language tag. Implements #1108 (https://github.com/mbunkus/mkvtoolnix/issues/1108).
* source code: bug fix: Accidental uses of the »long double« type have been converted to normal »double«s. This fixes compilation on platforms which don't support the »long double« type in combination with Boost::Math. Fixes #1150 (https://github.com/mbunkus/mkvtoolnix/issues/1150).

Have fun.

[Keiyakusha]

Hey guys. I just tried new MMG GUI and have a few questions. All of these might not be implemented yet, I'm totally fine with that, but I'm still curious.
1) In "Tracks, chapters, tags and attachments" form, how do I re-arrange stream positions?
2) How do I terminate muxing mid-way?
3) How do I disable statistics? (Such as NUMBER_OF_FRAMES, NUMBER_OF_BYTES, _STATISTICS_WRITING_APP etc.)

[Overdrive80]

Any tool for converting mmg option file to new version (mtxcfg)??

[sneaker_ger]

1) In "Tracks, chapters, tags and attachments" form, how do I re-arrange stream positions?
2) How do I terminate muxing mid-way?
3) How do I disable statistics? (Such as NUMBER_OF_FRAMES, NUMBER_OF_BYTES, _STATISTICS_WRITING_APP etc.)
1. Drag&Drop
3. Output options, Additional options (bottom right corner), check --disable-track-statistics

[Zenitram]

3) How do I disable statistics? (Such as NUMBER_OF_FRAMES, NUMBER_OF_BYTES, _STATISTICS_WRITING_APP etc.)

Please don't, such statistics are useful for people who get your file (and they use so little place in the file).

[Sparktank]

Thanks for the hefty update, Mosu!

[Keiyakusha]

1. Drag&Drop
Ouch... should have tried this myself... >__<

3. Output options, Additional options (bottom right corner), check --disable-track-statistics
Yep, this is it, totally missed it. Thanks!

Please don't, such statistics are useful for people who get your file (and they use so little place in the file).

Currently is looks like this (see at the bottom of this post). Only NUMBER_OF_FRAMES provides information that is not already available and still I don't find it useful. In case number of frames matters, most likely I am going to edit the content and have other means to know this information. Thus I consider all of this statistics to be completely useless.

Format : Matroska
Format version : Version 4 / Version 2
File size : 221 MiB
Duration : 8mn 47s
Overall bit rate : 3 506 Kbps
Encoded date : UTC 2015-05-10 15:20:02
Writing application : mkvmerge v7.9.0 ('Birds') 64bit
Writing library : libebml v1.3.1 + libmatroska v1.4.2
DURATION : 00:08:47.744000000
NUMBER_OF_FRAMES : 24738
NUMBER_OF_BYTES : 6590628
_STATISTICS_WRITING_APP : mkvmerge v7.9.0 ('Birds') 64bit
_STATISTICS_WRITING_DATE_UTC : 2015-05-10 15:20:02
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

[Mosu]

Hey guys. I just tried new MMG GUI and have a few questions. All of these might not be implemented yet, I'm totally fine with that, but I'm still curious.
1) In "Tracks, chapters, tags and attachments" form, how do I re-arrange stream positions?
2) How do I terminate muxing mid-way?
3) How do I disable statistics? (Such as NUMBER_OF_FRAMES, NUMBER_OF_BYTES, _STATISTICS_WRITING_APP etc.)

Questions are more than welcome.

Via drag & drop: select a track, drag to new position. Same applies for files & re-ordering them. You can also select multiple tracks & drag and drop them, but only if they're all on the same level (e.g. you cannot drag & drop a non-appended and an appended track at the same time). You can also not change the level (you cannot convert an appended track to not-appended and vice versa).
Select the »Job output« tool and hit the »Cancel« button.
Select the »merge« tool. Go to the »Output« tab. On the lower right you'll find »Additional options«. Here you can either add »--disable-track-statistics-tags« manually or click the button to the right of the input. That'll show a popup where you can select such options. It's the equivalent of the old GUI's »add additional command line options« menu entry.

[Mosu]

Any tool for converting mmg option file to new version (mtxcfg)??

No, and none will be coming. It's too much work, and I have a lot of things still left to implement that I consider of higher priority. Sorry.

[Mosu]

Currently is looks like this (see at the bottom of this post). Only NUMBER_OF_FRAMES provides information that is not already available and still I don't find it useful. In case number of frames matters, most likely I am going to edit the content and have other means to know this information. Thus I consider all of this statistics to be completely useless.

Note that BPS is also one of those tags. MediaInfo doesn't list it as »BPS«, but I guess that the value from »BPS« is displayed as »Overall bit rate«.

Note further that the track's duration (»Duration«) is yet another of those pieces of information that won't be available if you disable the statistics. The track's duration is also different from the file's duration.

I'm not trying to start a discussion about the (lack of) usefulness of those tags, but the facts are that without those tags there's no way to determine:

the amount of bytes in a track,
the amount of blocks ( = frames/fields) in a track,
a track's duration (Matroska only stores a duration for the whole segment and that may differ a lot from each track's duration, especially if you have overlong subtitles),
due to the points above: the track's effective bit rate

Before the tags were introduced MediaInfo used to guesstimate both a track's duration and its effective bit rate. That heuristic was often off and the source for much confusion.

[ndjamena]

You're not supposed to be able to see the Track Statistic tags, it's just MKVMerge/MMG/MediaInfo weren't designed to handle them properly and currently it's a mess. Duration and Number of Bytes are only already available if you either have only a single track in the file or (for Number of Bytes) have only a single Variable bitrate stream (even then if the duration of just one of the tracks is significantly less than the file duration all of MediaInfos current output is worthless).

There's also a BPS tag that you're not seeing because MediaInfo has been programed to hide it, which is what it should be doing to all of them but Zenitram hasn't gotten around to writing the necessary code yet.

The Tag handling should have been fixed long ago, but no one has had the time thus far. Things will get better and your current files without the tags will become outdated.

[Zenitram]

Zenitram hasn't gotten around to writing the necessary code yet.

And I apologize for that. It will be past soon.

[Keiyakusha]

You're not supposed to be able to see the Track Statistic tags, it's just MKVMerge/MMG/MediaInfo weren't designed to handle them properly and currently it's a mess.
Yes, mediainfo output might be not perfect, but my point was that the information in these statistics fields is redundant. Changing mediainfo output may improve the overall mediainfo experience but it won't make the statistics information itself any more useful. (Also personally I don't want statistics to be hidden in mediainfo, or at least indication that they are present in a file)
I think without statistics mediainfo is doing great job displaying all truly relevant information.

Still, even knowing this, and the stuff that Mosu mentioned in the post above, I don't want this information to be present in my files. And if someone receives files from me, he is not supposed to do anything with them anyway (except playback of course)

[ndjamena]

And I apologize for that. It will be past soon.

FFMPEG needs to updated too, and MKVMerge. Be sure to remove everything in the _STATISTICS_TAGS tag and not just the individual tags for forward compatibility.

FFMPEG lists each tag twice, which is annoying and can only compound the general distaste for the tags.

MKVMerge lists them twice as well, once in the "Track Info" and once in the "Track Tags" list. That should change. Actually, according to the specs "TargetTypeValue" (50/60/70) and TargetType (EPISODE/MOVIE) aren't mandatory and really shouldn't be used for the Statistic Tags. I don't know if it does already or not but MKVMerge should probably verify the tags before outputting them and ignore them if they don't pass, and NOT output the security tags (tags starting with "_").

The whole thing needs to be cleaned up before people should be expected to accept them.

-edit- Oh, "TargetTypeValue" has a "default" of "50" (although looking at Tag "defaults" is dangerous business), but target type can be left out completely (and I do object to have MOVIE tags in my TV EPISODES.)

[ndjamena]

Yes, mediainfo output might be not perfect, but my point was that the information in these statistics fields is redundant. Changing mediainfo output may improve the overall mediainfo experience but it won't make the statistics information itself any more useful. (Also personally I don't want statistics to be hidden in mediainfo, or at least indication that they are present in a file)
I think without statistics mediainfo is doing great job displaying all truly relevant information.

Still, even knowing this, and the stuff that Mosu mentioned in the post above, I don't want this information to be present in my files. And if someone receives files from me, he is not supposed to do anything with them anyway (except playback of course)

If you came into this sometime in the future, when the Stat tags were fully mature and hidden, would you care if they were there or not or are you just making arguments based on prejudices caused by the current situation?

[Keiyakusha]

If you came into this sometime in the future, when the Stat tags were fully mature and hidden, would you care if they were there or not or are you just making arguments based on prejudices caused by the current situation?
I would care, assuming I did some research during which I figured out that they exist and what they are for. I think this is similar to x264's SEI information which some people prefer to remove (or use a modified build that doesn't creates it to begin with)

[ndjamena]

Right, I figured out why I thought "TargetTypeValue" could be left out.

This is from a FFMPEG Track tag extracted using MKVExtract:

<Targets>
<TrackUID>1</TrackUID>
</Targets>


I don't know what that means, and since it's the Matroska tagging system I'd rather not know.

But unless I'm missing something in the specs "TargetType" should be able to be left out completely.

[hello_hello]

Thanks for the new version, but........

When trying to run both mmg.exe and mkvtoolnix-gui.exe on XP (downloading mkvtoolnix-32bit-7.9.0.7z) I get the following error:

Entry Point Not Found
The procedure entry point RegGetValueA could not be located in dynamic link library ADVAPI32.dll

[Mosu]

Windows versions prior to Windows Vista are not supported anymore (and haven't been for a couple of releases now).

[filler56789]

Windows versions prior to Windows Vista are not supported anymore (and haven't been for a couple of releases now).

That's a shame indeed. A Matroska multiplexer should have nothing to do with the pesky Windows Registry, to begin with :)

[hello_hello]

Windows versions prior to Windows Vista are not supported anymore (and haven't been for a couple of releases now).

That's odd, as I've been using MKVMergeGUI on XP. Is that mentioned in the changelog somewhere? I can't find it.

mmg.exe from (portable) versions 7.8.0, 7.7.0 and 7.6.0 all run happily on XP. Was it decided to deliberately prevent MKVMergeGUI from running on it?

The timing seems a shame, considering the final version of the new GUI isn't far away. It would have been nice to have the first "non-beta" version working on XP before XP support was dropped.

What about mkvmerge.exe? Programs such as MeGUI use it for muxing. Should I be preventing MeGUI from updating it to version 7.9.0 so I won't find MeGUI suddenly incapable of MKV muxing?

Thanks.

Edit: I tested the last part and no, MeGUI can't mux MKVs if I update MKVMerge to 7.9.0. It seems the maintainer of MeGUI might be unaware of the lack of XP support as MeGUI updated MKVMerge to 7.8.0 when it was released, but fortunately that version does work on XP so no harm there so far.

[Mosu]

Over a year ago I've said a couple of times that I would not spend time on Windows XP support anymore. Windows XP isn't supported by Microsoft anymore either, so why should I? It's insecure, it will stay that way, and I have to set limits to what I can and do support.

I haven't done anything actively in order to prevent things from running on Windows XP. They simply turned out not to anymore, as it seems. Not supporting Windows XP simply means that I will not hunt down the reason for this.

There's a cost to such backwards compatibility. To some it may seem small, but finding the reason why e.g. mkvmerge suddenly doesn't run there anymore? Far from trivial. Maybe even impossible for me if it's due to Qt.

I usually don't mention dropping support for certain operating system versions in the ChangeLog unless there's a conscious decision involved like e.g. requiring function XYZ that's only available in OS version 29 and later. In this case no such decision was made; hence no ChangeLog entry.

[hello_hello]

That's a shame indeed. A Matroska multiplexer should have nothing to do with the pesky Windows Registry, to begin with :)

I'll confess of all the programs to drop XP support, I'd have thought a muxing program would be right at the end of the list still working when almost no other current software does, especially as Win2000 was still supported up to about a year and a half ago, but what do I know..... I don't write software. :(

[filler56789]

That's odd, as I've been using MKVMergeGUI on XP. Is that mentioned in the changelog somewhere? I can't find it.

From the build 726's changelog:

2015-04-10 Moritz Bunkus <moritz@bunkus.org>

* MKVToolNix GUI: enhancement: Qt's »Windows Vista« style is now used on Windows instead of the old, Windows 98-like style.

[Mosu]

I'm pretty sure that that change isn't responsible. Qt draws its own controls and can make them look like anything. You can select the Vista style on Linux, the Windows 95 style on Vista or the Linux style on Windows 8.

[filler56789]

Apologies for the bad guess.
Anyway, so it's time to finally move house to my Windows 7 (yuck) machine...

[hello_hello]

Over a year ago I've said a couple of times that I would not spend time on Windows XP support anymore. Windows XP isn't supported by Microsoft anymore either, so why should I?

There's the "new GUI is just around the corner" reason for continuing XP support until the first stable version is released. That'd at least allow XP users to run one version of the new GUI for the rest of eternity.
Honestly, I get some of the reasons for not supporting XP, but when it comes to Microsoft not supporting it I have no idea what one has to do with the other, given more people still use XP than Vista and Windows 8 and Windows 8.1 combined (according to Wikipedia and the breakdown of computers connected to the internet, although I suspect there's an even larger number of PCs still running XP that aren't used for browsing). I think that should carry more weight than Microsoft's fiscal policy, but I don't write software..... ;)

(I've run XP without a software firewall, without an antivirus program, without an anti-anything program for years without getting infected, just me, Firefox, XP and a router, so I honestly don't get the "insecure" argument either, but that's a whole other debate....... :))

I just see it as a bit of a pity no software writers seem to take a stand a say "well that new version of Windows is a piece of %^#$ and I won't support it", instead helping to force people to upgrade their non piece of %^$% Windows version instead, but as I said, what do I know? I don't write software...... :)

I usually don't mention dropping support for certain operating system versions in the ChangeLog unless there's a conscious decision involved

Now I'm aware of that I'll assume any new version of mkvtoolnix will fail to work without warning unless I'm running the latest version of Windows and upgrade it far more cautiously in the future. ;)

Thanks.

PS. I'm not trying to appear ungrateful, or demanding (hence all the smileys), and it's your time to spend as you so choose, and mkvtoolnix is very, very, very much appreciated as I use it pretty much daily (one of the reasons no support for XP is disappointing for me as even when I build a new Win7 PC in the near future the old PCs will still continue to run XP), but I'm just offering a "user" perspective...... as someone who doesn't write software it's the only one I've got. ;) :)

[Chetwood]

Can anyone point me to the proper QT 'library' to install to get the new GUI? I've installed 5.4.1 and am stil getting the old one on Win 8.1. Thx.

If you came into this sometime in the future, when the Stat tags were fully mature and hidden, would you care if they were there or not or are you just making arguments based on prejudices caused by the current situation?
I don't have any use for stats either and since I'm not sure how they may affect playback on standalones, I've turned them off just as I have done with the cue tags.

And I apologize for that. It will be past soon.
While you're at it would you mind and reconsider outputting reports with ALT+E to the same dir as the file the report is written on? It still makes no sense to have this written to the program dir of all places. Thx.

[Mosu]

Can anyone point me to the proper QT 'library' to install to get the new GUI? I've installed 5.4.1 and am stil getting the old one on Win 8.1. Thx.

You don't have to install Qt yourself. All you have to do is execute mkvtoolnix-gui.exe instead of mmg.exe (start menu entry »MKVToolNix GUI«).

[burfadel]

There's the "new GUI is just around the corner" reason for continuing XP support until the first stable version is released. That'd at least allow XP users to run one version of the new GUI for the rest of eternity.
Honestly, I get some of the reasons for not supporting XP, but when it comes to Microsoft not supporting it I have no idea what one has to do with the other, given more people still use XP than Vista and Windows 8 and Windows 8.1 combined (according to Wikipedia and the breakdown of computers connected to the internet, although I suspect there's an even larger number of PCs still running XP that aren't used for browsing). I think that should carry more weight than Microsoft's fiscal policy, but I don't write software..... ;)

(I've run XP without a software firewall, without an antivirus program, without an anti-anything program for years without getting infected, just me, Firefox, XP and a router, so I honestly don't get the "insecure" argument either, but that's a whole other debate....... :))

I just see it as a bit of a pity no software writers seem to take a stand a say "well that new version of Windows is a piece of %^#$ and I won't support it", instead helping to force people to upgrade their non piece of %^$% Windows version instead, but as I said, what do I know? I don't write software...... :)



Now I'm aware of that I'll assume any new version of mkvtoolnix will fail to work without warning unless I'm running the latest version of Windows and upgrade it far more cautiously in the future. ;)

Thanks.

PS. I'm not trying to appear ungrateful, or demanding (hence all the smileys), and it's your time to spend as you so choose, and mkvtoolnix is very, very, very much appreciated as I use it pretty much daily (one of the reasons no support for XP is disappointing for me as even when I build a new Win7 PC in the near future the old PCs will still continue to run XP), but I'm just offering a "user" perspective...... as someone who doesn't write software it's the only one I've got. ;) :)

Why should Microsoft continue supporting an OS from 2001? It seems counter-intuitive insisting on having the latest MKV tools if you are still running at ancient OS (it is ancient).

Microsoft is going to a continuous support model starting with Windows 10. So, if you don't want to be left out, upgrade to Windows 10 when it comes out :). It might not be called Windows 10 in 6 years, but you will have an upgrade path from base Windows 10.

Continuous support of XP is just an encouragement for people to stick with XP, and is a waste of money and resources.

Also, how do you know you don't have any malicious software on your computer if you don't have any means of knowing it is there?

[nevcairiel]

Honestly, I get some of the reasons for not supporting XP, but when it comes to Microsoft not supporting it I have no idea what one has to do with the other, given more people still use XP than Vista and Windows 8 and Windows 8.1 combined (according to Wikipedia and the breakdown of computers connected to the internet, although I suspect there's an even larger number of PCs still running XP that aren't used for browsing).

Those stats are mostly tainted by companies who got stuck because they use some equally ancient software. Its unfortunate, but we do not have stats on "personal" PCs alone.

On the topic at hand, especially when developing a new UI, trying to support XP gets rather annoying fast, as there are a whole bunch of new things you can use if you don't, so I wouldn't expect especially new software to support XP at all anymore. Who would want to spend extra time on that?
(PS: its not limited to UI either, there is a long list of things that got improved in the win32 API in later versions of windows, from UI, to threading, to file access)

Personally for myself, I'll drop XP support the moment it can save me a couple hours time or a few headaches to do so. If i were to write something new, I would never even bother to try to support it at all.

[foxyshadis]

Supporting XP also means having an XP system, and even if it's a VM it can still be a pain to trot it out to re-run your testing and debugging on it every build. If you care about such things and don't have a Win7 Pro/Enterprise, that might also mean licensing costs. XP users have to realize that they're the burden now, and they can't just argue for support, it's become pony up cash or watch software pass you by. It's almost as ridiculous as IanB sticking to VC6 until just a couple of years ago.

Mosu most likely has better stats on his userbase than anyone else, anyway, no matter what the wide world looks like. I guess it's time to make a big red banner on the update post that XP is reported to not work.

[stax76]

one of the reasons no support for XP is disappointing for me as even when I build a new Win7 PC

Are you seriously saying you want to upgrade from the old WinXP to the new WinXP (Win7 == new WinXP)? Here in Germany Win7 still costs minimum 60€, the real retail Version (no Dell crap that is often pirated I believe) is still above 100€ I believe. Win10 on the other hand is free for Windows Insiders and for the first year and as long as you don't have to reinstall you can use it for free for ten years or more. Some might think the first year is free like the first heroin is free and it might be true that after the first year it will be as expensive as MS office is now but it's still likely possible to run it the next ten years for free.

[Mosu]

Folks please. This is not a thread about a general discussion between the pros and cons of various Windows versions. A couple of points have been made. Please let's leave it at that and return to the thread's intended topic: MKVToolNix.

Thanks.

[sneaker_ger]

So, what exactly caused the XP incompatibility? Some library update or just a simple compiler switch? Esp. if it's the latter it could be useful for people looking into building their own XP-compatible binaries.

(Disclaimer: I don't use anything older than Win 7)

[Mosu]

I don't know. Figuring that out is part of the cost of that »support for Windows XP« thingy.

[ndjamena]

New chapter editor... Can it auto-select the first name in the list when a chapter is highlighted? This is painful.

(or the first one the first time and the closest to the currently selected the next time... or whatever, just not this.)

[Mosu]

Actually I did it that way at first, but that totally destroyed keyboard navigation in the tree. The latter is a complaint that has been raised against the old GUI as well; therefore I decided not to auto-set the focus.

[ndjamena]

Not set the focus to the chapter name field, I mean automatically select a chapter name from the list, rather than having the Name/Language/Country greyed out (nothing selected).

[Mosu]

Ah, sorry. I misunderstood. I'll do something about that, but not right now (let's say within two releases).

[ndjamena]

OK then, I can't use it like this, so I'll switch back to MMG for now.

-edit- cool, keyboard navigation works now!

[qyot27]

So, what exactly caused the XP incompatibility? Some library update or just a simple compiler switch? Esp. if it's the latter it could be useful for people looking into building their own XP-compatible binaries.

(Disclaimer: I don't use anything older than Win 7)

I don't know. Figuring that out is part of the cost of that »support for Windows XP« thingy.

Since it's what the error message complains about, it's more than likely the use of RegGetValueA (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868%28v=vs.85%29.aspx) in src/common/fs_sys_helpers/windows.cpp @ line 146. That function is Vista+ (or seemingly 2k3+).

Supporting XP in that instance would mean using a different registry querying function. RegQueryValueEx, as the answers on SO point to, but I doubt the actual parameters taken by RegQueryValueEx vs. RegGetValue are the same, so it'd require special-casing to support both (or simply an option to disable registry support at configure time so it doesn't build that part at all - which might make some degree of sense for portable builds, regardless of any OS version squabbling).


I haven't tried doing this in several years, but Wine could be used to patch over XP itself to avert this (http://wiki.winehq.org/WineOnWindows). Wine can run 7.9.0 seemingly without problems*, since it implements support for higher versions of the Windows program APIs (if the OS itself was stable enough, it'd probably work swimmingly in ReactOS as it has a symbiotic relationship with Wine for program support while currently targeting NT kernel version 5.2). You just have to cross-compile Wine's DLLs under MinGW-w64 so that it routes the calls into win32. It could probably also be done under MSys2 or Cygwin.

*obviously, I'd normally just use the native build instead if I'm logged in under Ubuntu, but not everyone wants to switch their XP machines to Linux.

I had to resort to doing this in 2011 for a game that kept crashing using the Microsoft DirectX runtime. After I got Wine's d3dx9_43.dll built I dropped it into the game's directory, and everything was peachy. Since Windows prioritizes DLLs in a program's home directory, it'll use those before it tries the ones from the system. So if a cross-compiled copy of Wine's ADVAPI32.dll were in there, it'd more than likely work as-is without specific XP support. Provided that ADVAPI32.dll itself doesn't require more of the Wine DLL ecosystem.


EDIT: after testing a cross-compiled Wine (1.7.42-137-g6d323d8), that trick won't work atm. Windows is either smart enough to not load *those* particular .dlls from the application directory, or we're going to need a much more complete WineOnWindows environment (read: wine.exe itself, which the limited cross-compiling support in Wine can't do yet) to be able to do anything regarding that. But really, going to that much trouble generally isn't worth it when you can run an up-to-date version of [insert Linux distro name here] on the same machine and use the native build of MKVToolNix just fine. For ancient setups like mine, that's pretty much the only thing you can do short of just staying back at 7.8.0. The jury's still out on ReactOS since right now I don't have access to the VM I normally use, but ROS is still not anywhere close to stable for daily use.

[filler56789]

Since it's what the error message complains about, it's more than likely the use of RegGetValueA (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868%28v=vs.85%29.aspx) in src/common/fs_sys_helpers/windows.cpp @ line 146. That function is Vista+ (or seemingly 2k3+).

Already available in "Windows XP Professional x64 Edition", according to that same page (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868%28v=vs.85%29.aspx).

[Mosu]

Not set the focus to the chapter name field, I mean automatically select a chapter name from the list, rather than having the Name/Language/Country greyed out (nothing selected).

I've implemented something along these lines in pre-build 729 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/). Is this what you had in mind?

[hello_hello]

Folks please. This is not a thread about a general discussion between the pros and cons of various Windows versions. A couple of points have been made. Please let's leave it at that and return to the thread's intended topic: MKVToolNix.

Just a post to answer some questions asked of me then I'll leave it at that.

Why should Microsoft continue supporting an OS from 2001? It seems counter-intuitive insisting on having the latest MKV tools if you are still running at ancient OS (it is ancient).

I never said they should. I simply said I don't see any direct relationship between the version of Windows software should run on and whether that version is still supported by Microsoft. The "old OS" argument breaks down for me when you compare it to a "number of users" argument which at the moment still includes something like 15% of PC users, while supporting OSs with a combined market share of something like 3%. If you could show me stats along the lines of "98% of people downloading converting/muxing software run Win7 or newer", then that'd possibly be a different story.

I'm not insisting on anything, but I'd like a warning if a new version won't run on a particular flavour of Windows so I know not to upgrade, find it won't run, post in the mkvtoolnix forum about the problem thinking I'm contributing to bug fixing in a small way, only to be told to &%$ off and upgrade Windows. :)

Also, how do you know you don't have any malicious software on your computer if you don't have any means of knowing it is there?

Once every year or so I install antivirus software and run a full scan. Just to see what it'll find. Then I restore the previous year's Windows and programs image, update everything and make a new image. I've been doing that for years and the scans have never found anything worse than a few naughty cookies.

Are you seriously saying you want to upgrade from the old WinXP to the new WinXP (Win7 == new WinXP)?

Maybe I'd be happy if Win XP had been like Windows 10. Free to use and perpetually upgrade, or however it'll work. ;)
I'll possibly upgrade to Win7 initially because I have a legit copy that was given to me that's never been used and there's no XP drivers for the MB I want. I've not looked closely at Win10 yet.

[qyot27]

Already available in "Windows XP Professional x64 Edition", according to that same page (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868%28v=vs.85%29.aspx).
64-bit XP Pro is not the same OS as 32-bit XP. The 64-bit edition is derived from 2k3 (so I did technically include it in that 2k3+ addendum). Most XP users aren't using the 64-bit edition, though.

[Chetwood]

All you have to do is execute mkvtoolnix-gui.exe instead of mmg.exe (start menu entry »MKVToolNix GUI«).
Thanks. Being a windows user I skipped over any and all mentions of the command-line as usual ;)

I also think, XP is over, also because M$ offered Win 8 licenses for only 30 € for a while.

[Helios61]

Thanks Mosu for your effort with MKVToolnix. One thing i am missing within the new GUI: Is ist possible to add the UP and Down buttons in one of the next releases?

[Mosu]

I won't add such buttons as you can re-order tracks & files via drag & drop.

[manolito]

@ Mosu

Windows

The current version v7.9.0 is available as an installer and as a portable 7zip archive from fosshub.com. Supported Windows versions are XP and newer from the client OS line and Windows Server 2008 and later from the server line.


Could you please update your website and also mention that version 7.8.0 is the last one which works under XP... :rolleyes:


@ qyot27

Thanks a lot for testing it with a cross-compiled Wine DLL. I also extracted the ADVAPI32.dll from the latest ReactOS and copied it into the MKVToolnix root folder, but no luck...



Cheers
manolito

[Mosu]

manolito: good point. Done.

[qyot27]

@ qyot27

Thanks a lot for testing it with a cross-compiled Wine DLL. I also extracted the ADVAPI32.dll from the latest ReactOS and copied it into the MKVToolnix root folder, but no luck...
Also, as I'd predicted before, even ReactOS 0.3.17 from last November can run 7.9.0's binaries* (I did manage to get to the VM), but also like I said, the OS itself is not really in any state to seriously use right now. It will [eventually] be the optimal OS upgrade path for old XP machines that can't run Win7, but it still needs to be able to boot on the real hardware, which I've had mixed or zero results with thus far.

*the installer fails; use the 7z package or extract the binaries from the installer with 7zip

[filler56789]

The situation is even more complicated than I thought...

after hexediting mkvmerge.exe for calling advapi48.dll, and after placing the Vista advapi32.dll in the same folder as mkvmerge, and after renaming the DLL accordingly,
I got a different error message :(

The procedure entry point EtwNotificationUnregister could not be located in the dynamic link library ntdll.dll
:mad:

UPDATE:
After editing three more DLLs — kernel32, ntdll and rpcrt4 — ,
now the result is:
"the application failed to initialize properly (0xc00000fd)"

so there is no workaround, someone would have to fix the source-code itself.

[ryrynz]

I'll possibly upgrade to Win7 initially because I have a legit copy that was given to me that's never been used and there's no XP drivers for the MB I want. I've not looked closely at Win10 yet.

Take it to 10 from 7, you'll have a year to do it. I can't think of any reason why someone would want to stay on 7. I believe 10 is superior in just about every aspect.

[hello_hello]

Take it to 10 from 7, you'll have a year to do it. I can't think of any reason why someone would want to stay on 7. I believe 10 is superior in just about every aspect.

I discovered something the other day I didn't know before.
Windows 10 will be a free upgrade for software pirates, too. (http://www.pcworld.com/article/2898668/windows-10-will-be-a-free-upgrade-for-software-pirates-too.html)

It looks like Microsoft want to move everyone to Win10 one way or another. No doubt so they can fleece everybody hard eventually, but in the meantime it's changed my thinking a bit. I might become a temporary software pirate and upgrade every PC here that can run it to Win10. Unless I can find a way to go straight from XP to 10 without a lot of unnecessary messing around in between, but I'm downloading a preview of Win10 now to take it for a test drive. It looks like I might be (mostly) saying goodbye to XP after-all.

Now if only software authors would continue to support XP till the next (hopefully) usable version of Windows arrives. :)

[stax76]

I'm not sure about pirates but I heard Windows Insiders testing Win10 will get it free.

[Mosu]

Again, folks, this is not a thread about Windows. Please stay at least somewhat on topic. Thanks.

[ndjamena]

MakeMKV is complaining bitterly about any VC-1 track that has been remux using MKVMerge, so far the only difference I can see using MKVInfo is that the first frame in the MKVMerge file is 33 bytes longer for some reason. The file was originally created by MakeMKV then remuxed by MKVMerge, so is this added 33 bytes expected?

http://www.makemkv.com/forum2/viewtopic.php?f=8&t=9039

I just remuxed a VC-1 file previously muxed using MKVMerge and checked the first frame and it was 30 bytes longer than the original, then I remuxed THAT file and checked again and the third version was 30 bytes longer than the previous one (60 bytes longer than the first).

Is this new or should I assume all my VC-1 files have these extra 30 bytes?

[Mosu]

As the VC-1 handling code hasn't changed in ages this has probably been present for a long time.

[Thunderbolt8]

I just remuxed a VC-1 file previously muxed using MKVMerge and checked the first frame and it was 30 bytes longer than the original, then I remuxed THAT file and checked again and the third version was 30 bytes longer than the previous one (60 bytes longer than the first).

Is this new or should I assume all my VC-1 files have these extra 30 bytes?does this somehow translate into audio/video delay issues? how big of a delay would that be?

[Mosu]

Uhm… I doubt that. 30 bytes sounds more like CodecPrivate being duplicated (think of SPS/PPS info in h.264 tracks being duplicated by extraction).

[ndjamena]

I was thinking that but Codec Private was 74 bytes and MakeMKV is refusing to remux them. They play fine though but that could be error correction or not.

Mike should be looking at a sample by now and hopefully the next version of MakeMKV will be able to read through whatever it is.

It might be nothing, but Batman is VC-1 and I know I've remuxed that movie several times already, and I'm trying to get a final version of The Matrix done at the moment, the audio is being a pain...

I would like to know exactly what it is though.

[Boulder]

Is there a possibility that mkvalidator is not playing nicely or is it possible that a Matroska file corrupts in a few minutes?

First I got:

R:\>mkvalidator --no-warn "The X-Files - S07E01 - The Sixth Extinction.mkv"
................................................................................
mkvalidator 0.5.0: the file appears to be valid
file created with libebml v1.3.1 + libmatroska v1.4.2 / mkvmerge v7.9.0
('Birds') 64bit

A few minutes later I got:

R:\>mkvalidator --no-warn "The X-Files - S07E01 - The Sixth Extinction.mkv"
ERR066: The SeekPoint at 87 references an unknown Cues at 401390961
file created with libebml v1.3.1 + libmatroska v1.4.2 / mkvmerge v7.9.0
('Birds') 64bit

I have also other files from the same season which have the same thing happen to them.

I used "for %f in (*.mkv) do mkvalidator --no-warn "%f"" to check the files.

[Mosu]

Hmm such things could happen due to uninitialized variables (= a bug). You should file a report at https://github.com/Matroska-Org/foundation-source/issues

[Boulder]

Is it possible to compare Matroska files? I'd like to make sure that my computer is not to blame, but using an MD5 checksum doesn't work.

[Mosu]

I don't know of an easy-to-use tool for that. One possibility is to run mkvinfo -v on both files, direct the output to text files, use a diff tool and to ignore those elements known to be unique to each file (e.g. muxing date, all the UIDs).

[Boulder]

It seems that I can pinpoint the problem to occur on two hard drives that are in an external USB dock (connected to USB 3.0 via a PCIe card). Copying the same (working) muxed files from a different drive to one with problems doesn't seem to break them. Also other drives attached to the same PCIe card don't have the problem. I also tested a few FLAC files I have there but they are fine.

My question is: does mkvmerge use some special method to write the files? I have had write caching disabled so the drives are in quick removal mode.

[Mosu]

mkvmerge uses the default functions offered by the operating systems; WriteFile() on Windows and fwrite() everywhere else.

[Boulder]

I was able to make all USB drives corrupt data, no matter if they were directly connected to the motherboard or via the PCIe card. Then I enabled write caching (the "Better performance" option) in Device Manager for all my USB drives and the issue is now gone. I have absolutely no clue why the setting would have anything to do with it, in fact I would expect the exact opposite, but no more corruption when muxing :) I do recall reading that uTorrent and KTorrent had similar issues related to Windows caching some time in the past.

[hello_hello]

Boulder,
I think that problem has been mentioned in the VideoHelp computer sub-forum a few times and from memory it only applies to the 64 bit version of Windows 7. Is that what you're using? Have a look there but I'm not sure if anyone found another solution, aside from not using Windows Explorer to copy and paste but using a third party copying utility instead, although of course that probably doesn't help when using a USB drive as the destination drive when muxing it.

Anyway, I just thought I'd mention it in case you wanted to look at those threads. Maybe it's related, or maybe not.

[Selur]

Here's what I do is:
I analyse my input with mkvinfo
mkvinfo.exe --ui-language en -s "H:\193.mkv"
which gives me:
...
Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: High 10 @L3.0), mkvmerge/mkvextract track ID: 0, default duration: 41.708ms (23.976 frames/fields per second for a video track), language: jpn, pixel width: 698, pixel height: 478, display width: 698, display height: 537
Track 2: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 1, default duration: 32.000ms (31.250 frames/fields per second for a video track), language: jpn, sampling freq: 48000, channels: 2
...

and MediaInfo
"G:\MkvCutter\MediaInfo.exe" --Full "H:\193.mkv"
which gives me:

...
Video
Count : 311
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
ID : 1
ID : 1
Unique ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format/Url : http://developers.videolan.org/x264.h
tml
Commercial name : AVC
Format profile : High 10@L3
Format settings : CABAC / 6 Ref Frames
Format settings, CABAC : Yes
Format settings, CABAC : Yes
Format settings, ReFrames : 6
Format settings, ReFrames : 6 frames
Internet media type : video/H264
Codec ID : V_MPEG4/ISO/AVC
Codec ID/Url : http://ffdshow-tryout.sourceforge.net
/
Codec : V_MPEG4/ISO/AVC
Codec : AVC
Codec/Family : AVC
Codec/Info : Advanced Video Codec
Codec/Url : http://ffdshow-tryout.sourceforge.net
/
Codec profile : High 10@L3
Codec settings : CABAC / 6 Ref Frames
Codec settings, CABAC : Yes
Codec_Settings_RefFrames : 6
Duration : 1461712
Duration : 24mn 21s
Duration : 24mn 21s 712ms
Duration : 24mn 21s
Duration : 00:24:21.712
Duration : 00:24:22;02
Duration : 00:24:21.712 (00:24:22;02)
Bit rate : 1044138
Bit rate : 1 044 Kbps
Width : 698
Width : 698 pixels
Height : 478
Height : 478 pixels
Pixel aspect ratio : 0.890
Original pixel aspect ratio : 0.889
Display aspect ratio : 1.300
Display aspect ratio : 4:3
Original display aspect ratio : 1.298
Original display aspect ratio : 1.298
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 23.976
Frame rate : 23.976 fps
Frame count : 35046
Resolution : 10
Resolution : 10 bits
Colorimetry : 4:2:0
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10
Bit depth : 10 bits
Scan type : Progressive
Scan type : Progressive
Interlacement : PPF
Interlacement : Progressive
Bits/(Pixel*Frame) : 0.131
Delay : 0
Delay : 00:00:00.000
Delay, origin : Container
Delay, origin : Container
Stream size : 190778595
Stream size : 182 MiB (72%)
Stream size : 182 MiB
Stream size : 182 MiB
Stream size : 182 MiB
Stream size : 181.9 MiB
Stream size : 182 MiB (72%)
Proportion of this stream : 0.71656
Writing library : x264 - core 142 r2453 ea0ca51
Writing library : x264 core 142 r2453 ea0ca51
Encoded_Library_Name : x264
Encoded_Library_Version : core 142 r2453 ea0ca51
Encoding settings : cabac=1 / ref=6 / deblock=1:1:1 / ana
lyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me
_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_p
skip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=
0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / b
frames=9 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=
0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_
lookahead=60 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.70 / qpmin=0 / qpmax=81 /
qpstep=4 / ip_ratio=1.40 / aq=1:0.60
Language : ja
Language : Japanese
Language : Japanese
Language : ja
Language : jpn
Language : ja
Default : Yes
Default : Yes
Forced : No
Forced : No
...
then I split the file, using:

-o
H:\\Temp\\test.mkv
--split
parts-frames:32545-34102,34102-34352
--no-audio
--no-subtitles
--no-buttons
--no-track-tags
--no-chapters
--no-attachments
--no-global-tags
H:\\193.mkv
as H:\Temp\test_mkvOptions.txt
with:
"G:\MkvCutter\mkvmerge.exe" @"H:\Temp\TEST_M~1.TXT"
which creates:

H:\Temp\test-001.mkv
H:\Temp\test-002.mkv


then I cut the file using
LoadPlugin("G:\MkvCutter\LSMASHSource.dll")
LWLibavVideoSource("H:\Temp\test-002.mkv", format="YUV420P10", cache=false)

Trim(0,length=195) as: H:\Temp\test-002.avs
and rencode the file using:
"G:\MkvCutter\avs2yuv.exe" -raw "H:\Temp\test-002.avs" -o - | "G:\MkvCutter\x264-10bit.exe" --profile high10 --level 30 --sps-id 0 --cabac --ref 6 --deblock 1:1 --partitions all --me umh --subme 10 --psy-rd 0.40:0.00 --merange 24 --trellis 2 --8x8dct --deadzone-inter 21 --deadzone-intra 11 --qblur -2 --bframes 9 --b-pyramid normal --b-adapt 2 --b-bias 0 --direct auto --weightp 2 --keyint 250 --min-keyint 23 --scenecut 40 --rc-lookahead 60 --qcomp 0.70 --qpmin 0 --qpmax 81 --qpstep 4 --ipratio 1.40 --aq-mode 1 --aq-strength 0.60 --chroma-qp-offset -2 --stitchable --non-deterministic --thread-input --crf 19 --demuxer raw --input-depth 10 --input-res 698x478 --fps 24000/1001 --sar 1000:890 -o "H:\Temp\test-002_reencode.264" -
encoding next file,...

raw [info]: 698x478p 100:89 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=100/89
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
x264 [info]: profile High 10, level 3.0, 4:2:0 10-bit
1 frames: 1.36 fps, 745.56 kb/s
23 frames: 22.16 fps, 147.96 kb/s
46 frames: 34.10 fps, 127.19 kb/s
64 frames: 39.98 fps, 119.78 kb/s
85 frames: 45.14 fps, 116.71 kb/s
107 frames: 49.22 fps, 114.23 kb/s
137 frames: 56.03 fps, 114.47 kb/s
170 frames: 63.08 fps, 117.26 kb/s
x264 [info]: frame I:1 Avg QP:27.84 size: 3887
x264 [info]: frame P:38 Avg QP:30.81 size: 1305
x264 [info]: frame B:156 Avg QP:34.43 size: 409
x264 [info]: consecutive B-frames: 1.0% 0.0% 3.1% 12.3% 33.3% 43.1% 7.2% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 62.2% 36.2% 1.6%
x264 [info]: mb P I16..4: 2.8% 1.5% 0.0% P16..4: 41.0% 2.2% 1.9% 0.0% 0.0% skip:50.5%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 24.9% 0.9% 0.1% direct: 0.2% skip:73.9% L0:50.1% L1:48.7% BI: 1.2%
x264 [info]: 8x8 transform intra:36.6% inter:88.6%
x264 [info]: direct mvs spatial:95.5% temporal:4.5%
x264 [info]: coded y,uvDC,uvAC intra: 10.7% 0.0% 0.0% inter: 0.8% 0.0% 0.0%
x264 [info]: i16 v,h,dc,p: 20% 25% 11% 44%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 5% 6% 50% 5% 8% 5% 9% 4% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 6% 20% 13% 4% 10% 3% 33% 2% 9%
x264 [info]: i8c dc,h,v,p: 100% 0% 0% 0%
x264 [info]: Weighted P-Frames: Y:44.7% UV:0.0%
x264 [info]: ref P L0: 37.4% 20.1% 18.0% 9.9% 9.9% 4.7% 0.1%
x264 [info]: ref B L0: 73.9% 11.9% 8.4% 4.1% 1.7%
x264 [info]: ref B L1: 93.0% 7.0%
x264 [info]: kb/s:115.36

encoded 195 frames, 68.06 fps, 115.36 kb/s

Note that is used '--sar 1000:890'.
Now I cut the audio using:
-o
H:\\Temp\\test_AudioCut.mkv
--split
parts:00:22:37.398-00:23:50.471
--no-video
--no-subtitles
H:\\193.mkvas: H:\Temp\test_AudioCut_mkvOptions.txt
which creates:

H:\Temp\test_AudioCut.mkv


Then I join the audio&video files again, using H:\Temp\test-001_mkvOptions.txt:

-o
H:\\Output\\test.mkv
--clusters-in-meta-seek
--engage
no_simpleblocks
--disable-lacing
--engage
no_cue_duration
--engage
no_cue_relative_position
--no-global-tags
--no-chapters
--no-subtitles
--no-track-tags
--no-buttons
--no-audio
--no-attachments
--forced-track
0:no
--default-duration
0:24000/1001p
--fix-bitstream-timing-information
0:1
H:\\Temp\\test-001.264
--no-global-tags
--no-chapters
--no-subtitles
--no-track-tags
--no-buttons
--no-audio
--no-attachments
--forced-track
0:no
--default-duration
0:24000/1001p
--fix-bitstream-timing-information
0:1
+
(
H:\\Temp\\test-002_reencode.264
)
--no-video
--no-global-tags
--no-chapters
--no-subtitles
--no-track-tags
--no-buttons
H:\\Temp\\test_AudioCut.mkv
--append-to
1:0:0:0
and:
"G:\MkvCutter\mkvmerge.exe" @"H:\Temp\test-001_mkvOptions.txt"
so far so good, problem is that when I know analyse the output with MediaInfo, I see:
...
Video
Count : 311
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
ID : 1
ID : 1
Unique ID : 12902876771495624352
Format : AVC
Format/Info : Advanced Video Codec
Format/Url : http://developers.videolan.org/x264.h
tml
Commercial name : AVC
Format profile : High 10@L3
Format settings : CABAC / 6 Ref Frames
Format settings, CABAC : Yes
Format settings, CABAC : Yes
Format settings, ReFrames : 6
Format settings, ReFrames : 6 frames
Internet media type : video/H264
Codec ID : V_MPEG4/ISO/AVC
Codec ID/Url : http://ffdshow-tryout.sourceforge.net
/
Codec : V_MPEG4/ISO/AVC
Codec : AVC
Codec/Family : AVC
Codec/Info : Advanced Video Codec
Codec/Url : http://ffdshow-tryout.sourceforge.net
/
Codec profile : High 10@L3
Codec settings : CABAC / 6 Ref Frames
Codec settings, CABAC : Yes
Codec_Settings_RefFrames : 6
Duration : 73073
Duration : 1mn 13s
Duration : 1mn 13s 73ms
Duration : 1mn 13s
Duration : 00:01:13.073
Duration : 00:01:13;02
Duration : 00:01:13.073 (00:01:13;02)
Bit rate : 914620
Bit rate : 915 Kbps
Width : 698
Width : 698 pixels
Height : 478
Height : 478 pixels
Pixel aspect ratio : 1.123
Original pixel aspect ratio : 0.889
Display aspect ratio : 1.640
Display aspect ratio : 16:10
Original display aspect ratio : 1.298
Original display aspect ratio : 1.298
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 23.976
Frame rate : 23.976 fps
Frame count : 1752
Resolution : 10
Resolution : 10 bits
Colorimetry : 4:2:0
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10
Bit depth : 10 bits
Scan type : Progressive
Scan type : Progressive
Interlacement : PPF
Interlacement : Progressive
Bits/(Pixel*Frame) : 0.114
Delay : 0
Delay : 00:00:00.000
Delay, origin : Container
Delay, origin : Container
Stream size : 8354260
Stream size : 7.97 MiB (69%)
Stream size : 8 MiB
Stream size : 8.0 MiB
Stream size : 7.97 MiB
Stream size : 7.967 MiB
Stream size : 7.97 MiB (69%)
Proportion of this stream : 0.69014
Default : Yes
Default : Yes
Forced : No
Forced : No

... which indicates 'Pixel aspect ratio : 1.123'
-> Any idea why the Pixel Aspect ratio isn't 0.89?


Cu Selur

[RDF]

Hello, Mosu

Is mkvtoolnix ever going to switch to ISO 639-3 language codes or will stay forever with the standard ISO 639-2?

[Mosu]

RDF: The Matroska file format uses ISO 639-2. Therefore mkvmerge cannot simply use 639-3 codes. So the first step would have to be to extend the Matroska file format with new language elements that use the 639-3 codes, then to have support implemented in muxers like mkvmerge (and the associated GUIs), ffmpeg or gstreamer, and then in the players. A shitload of work, all in all, especially as all tools would have to be able to deal with two language attributes at once suddenly.

In short: it's highly unlikely that this will ever happen unless someone who cares about such a feature does the work. I don't care about that enough, so it won't be me.

[Mosu]

Selur: I really don't understand your question. You're actively telling x264 to use a pixel/sample aspect ratio of 1000/890 which is 1.1235… and then you wonder why MediaInfo outputs exactly that very same pixel/sample aspect ratio? Anyway, I have no clue whatsoever which value(s) MediaInfo choses to output as the various aspect ratios (sample/display/original sample/original display/pixel/whatever…); so may this question would be better off in a MediaInfo thread.

[Selur]

DOH,.. you are right I totally overlooked that I used 1000/890, when I wanted to use 890/1000. Man looked at it for quite some time and totally overlooked it. :)

[Mosu]

You even pointed it out in your post ;)

[Selur]

I know,.. I really need some more sleep. :)

[v0lt]

I downloaded the video stream (747MB hd1080 video/mp4) from here (http://www.youtube.com/watch?v=bS5P_LAqiVg) and packed in mkv using mkvmergeGUI v7.9.0. But mkv file freezes when rewinding in MPC-BE and MPC-HC. With mp4 file no such problem.

[Mosu]

Thanks for the report. Turns out that key frame detection was completely broken for video tracks in MP4 DASH files. I've fixed the issue and uploaded pre-build 749 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/) which includes the fix.

[v0lt]

Thank you. Pre-build 749 works correctly.

[NikosD]

Hello.

Is it possible to mux this m2ts file to MKV, keeping the original frame rate ?

Sample here:
https://www.sendspace.com/file/igxqjm

With mp4 and mov containers, there is no problem.

[sneaker_ger]

I don't see any problem?
mkvmerge -o output.mkv input.m2ts
Plays like source.

/edit:
Oh, I see. You probably mean MediaInfo. You better provide more solid proof by showing timecodes are wrong. MediaInfo is not reliable.

[NikosD]

With what frame rate ?

Does it keep the original 59.940 or changes it to 59.880 ?

[Mosu]

Obligatory note about frame rates in Matroska: https://github.com/mbunkus/mkvtoolnix/wiki/Wrong-frame-rate-displayed

Short summary: Matroska doesn't store that piece of information. If playback works correctly then everything's OK.

[sneaker_ger]

With what frame rate ?

Does it keep the original 59.940 or changes it to 59.880 ?No, looking pretty much exactly correct here. There is a delay at start, maybe that messes up your calculation? (I averaged by taking timecode of last picture minus delay divided by number of pictures. As Mosu said there isn't really any authorative fps value.)

[NikosD]

Thanks, but I think that MKV has also some limitations regarding its timebase accuracy of 1ms and it's difficult to handle frame rate of 60000/1001 for example, like the sample.

[huhn]

Thanks, but I think that MKV has also some limitations regarding its timebase accuracy of 1ms and it's difficult to handle frame rate of 60000/1001 for example, like the sample.

who said it is limited to 1ms accuracy?

mkv can do 24000/1001 and 60000/1001 just fine.

[nevcairiel]

Thanks, but I think that MKV has also some limitations regarding its timebase accuracy of 1ms and it's difficult to handle frame rate of 60000/1001 for example, like the sample.

1ms is the default accuracy, but it can use any other, higher or lower.

[Zenitram]

who said it is limited to 1ms accuracy?

mkv can do 24000/1001 and 60000/1001 just fine.

Just fine???

First, I wish to find 24000/1001 files without the default TimeCodeScale of 1 ms. Currently I have files with only the default TimeCodeScale, and it is not easy to detect 24000/1001 vs 24000/1000.

Second, I wonder, even in theory, how you can do 24000/1001 just fine : if I understand well the spec, the precision of the time code can be maximum 1 nanosecond. unfortunately, the duration of a frame at 24000/10001 is 41708333.3333333333333 nanoseconds, wich can not be represented "just fine" even with a TimeCodeScale of 1 nanosecond.

Maybe I miss something, but in that case please provide a MKV file with "60000/1001 just fine" ("just fine" means without any rouding, else it is a not "just fine", it is "unprecise due to technical limitations i.e. no numerator/denominator pair, but not too much unprecises so it is ok at least for me"). MP4/MOV, for example, stores a frequency e.g. the frequency is set to 60000 and the timecode is 1001 for the 2nd frame, and it is just fine (it is exactly, without any rounding, the presentation time of the frame)

That said, having a 1 ms precision is enough for most users (including me for personnal use). Just "not fine" for some people who are not "most users" (including me for professional use).

Oh, I see. You probably mean MediaInfo. You better provide more solid proof by showing timecodes are wrong. MediaInfo is not reliable.

I (the developer of MediaInfo) confirm that MediaInfo is not reliable about frame rate detection (due to the 1 ms precision ;-), I need to estimate the frame rate based on the unprecise time stamp and sometimes the algo provides wrong result, it is on my toto-list to have a more precise algorithm and also read the new tags Mosu has implemented).

[Mosu]

It's true that 24000/1001 is a rational number, but that doesn't mean that you cannot express timecodes properly. As long as you don't calculate the timecode of frame n by adding something on top of the timecode of frame n - 1 but by multiplying the frame number by the frame rate (or as long as you do all your internal calculations taking the rounding error into account and only rounding to the container's precision when writing out that frame) you're good to go.

[nevcairiel]

TimeCodeScale does not have to be 1ms or 1ns, it would be feasible to use some odd number to reproduce 24000/1001 exactly if a muxer wanted to do that. But alas, no MKV muxer seems to use that freedom.

[Mosu]

The problem with selecting such a time code scale value would be that it would affect the time codes of all time codes in the file, e.g. the audio ones, too. This may pose problems with audio playback – but I haven't actually tested it.

BTW, a couple of days ago I made a few unscientific tests with other time code scale values. Switching frmo 1ms to 1us precision (* 1000) resulted in an overall increase in file size of 0.12%, and going from 1ms to the maximum of 1ns (* 1000000) resulted in an increase of 0.20%. I'm actually considering switching to us precision by default for a release or two and see what happens.

[Zenitram]

you're good to go.

Mosu, sorry but some people don't agree about rounding (even rouding at 1 ns).
For them, 41708333 nanoseconds is not equal to 1001/24000.

Can you put in MKV the exact value 1001/24000 (or 3754/90000, MPEG-TS has a frequency of 90 kHz) for the time code of a frame? If not, some people are not good to go because I cannot express timecodes properly.

Please provide a hint about having proper timecodes with 1001/24000 i.e. being able to say that the 2d frame is at 41708333.3333333333333... nanoseconds (actually a way to provide a rational number) instead of 41708333 nanoseconds (whih is not the proper timecode), else for the moment I understand it is not possible to have proper timecodes, only a rounding.

Again, I fully understand it is more than enough for most people, it is just not "proper" timecode for people wanting more (actually the exact, without any rounding, never) precision. I also fully understand that it can not be easily changed due to Matroska design, and the goal is not to blame you, I understand that Matroska was not designed with such people in mind (and I didn't design MediaInfo with them in mind too, e.g. I show "29.970 fps" for 30000/1001 fps but some people want to be able to do the difference between 30000/1001 fps and 29970/1000 fps, even if the difference is only ~0.0001%, it is important for them)

The problem with selecting such a time code scale value would be that it would affect the time codes of all time codes in the file, e.g. the audio ones, too. This may pose problems with audio playback – but I haven't actually tested it.

Another design issue of Matroska ;-).
Time scale should be per track (24000/1001, 48000/1...), not per file. Anyway, it happens, we can not think to all when a format is designed.

BTW, a couple of days ago I made a few unscientific tests with other time code scale values. Switching frmo 1ms to 1us precision (* 1000) resulted in an overall increase in file size of 0.12%, and going from 1ms to the maximum of 1ns (* 1000000) resulted in an increase of 0.20%. I'm actually considering switching to us precision by default for a release or two and see what happens.

I speak of it, but I don't want to make you change your mind "just for me", 0.20% is not so small, Matroska is appreciated also for its small overhead and that usage (more than 1 ms of precision) is for very specific users who will not be a lot more happier because it is still not precise enough from their point of view.
I think that letting the end user choose the TimeCodeScale and letting default to 1ms is not bad.
I would argue more for having a "tag_framerate" tag with a rational number (e.g. "24000/1001") when you can have this value from the source (e.g. from MP4 track header) but the tag_duration and tag_number_of_frames are already good stuff (maybe adding a tag when the frame rate is not constant?).

it would be feasible to use some odd number to reproduce 24000/1001

Give the numbers... I don't see how. because you can not express such number in nanosecond...

[huhn]

you are aware that even with 1ns you are still rounding. PCs are doomed to round numbers at some point no matter what you do.

[Zenitram]

you are aware that even with 1ns you are still rounding. PCs are doomed to round numbers at some point no matter what you do.

Sorry to inform you that e.g. MP4 can provide time codes without any rounding (it provides num and den: 2nd frame time code is 1001/60000, exactly, no rounding). Please read again my previous comment.
Rounding number during display in order to fit limitations of the player (lose of information is not important, it is displayed then trashed) is totally different than storing a rounded number in a file (information is lost forever).

Again, I totally understand that most people don't care of precise time codes, but some other people do care. 1000/1001 frame rates are a mess, but they do exist, and 30000/1001 is not 29970/1000 for some people.

[foxyshadis]

Sorry to inform you that e.g. MP4 can provide time codes without any rounding (it provides num and den: 2nd frame time code is 1001/60000, exactly, no rounding). Please read again my previous comment.
Rounding number during display in order to fit limitations of the player (lose of information is not important, it is displayed then trashed) is totally different than storing a rounded number in a file (information is lost forever).

Again, I totally understand that most people don't care of precise time codes, but some other people do care. 1000/1001 frame rates are a mess, but they do exist, and 30000/1001 is not 29970/1000 for some people.

Another instance where MediaInfo needs "better parsing" and maybe "full parsing" options. People request that for bitrate all the time, but you could certainly make framerate more precise by parsing a few minutes of frames.

[Zenitram]

Another instance where MediaInfo needs "better parsing" and maybe "full parsing" options. People request that for bitrate all the time, but you could certainly make framerate more precise by parsing a few minutes of frames.

It is not a thread about MediaInfo so a very quick answer: it is always a problem of performance, lot of users already complain about parsing too many frames in the default behavior (too much slow with "only" few frames, and "few minutes of frames" means sometimes few Gigabytes of data to read from HDD), and full parsing option is already implemented for some customers with specific needs with a very precise computing of lot of things. It is just not available in the GUI and for Matroska specificly because nobody considered to sponsor such feature. But it will change in the near future because there is now a sponsoring of improvement of Matroska parsing, check MediaConch (https://mediaarea.net/MediaConch/) project for more information.

Additionaly, Mosu fixed the issue about missing bitrate with statistic tags so I "just" need to implement them on my side, without the need to parse the whole file (also planned during hte development of MediaConch). MediaInfo will have a far better support of Matroska in the upcoming months.

[stax76]

You are right Zenitram, for many tools performance is very important.

[v0lt]

I find the longest sequence of ±1 tc for the first 120 frames and calculates fps. Then I rounded up to the standard values if the difference is not more than 0.05%.
This is certainly not an accurate method, but it works well in most cases.

[v0lt]

@Mosu
I opened mkv-file with one video stream and frame rate equal to 23.976. In the setting of the video stream I forced 24000/1001p. Then, in the advanced settings I recorded "--timecode-scale <n>", and received the following timecodes for the first frame for any n.
n=1 -> tc=42000000
n=10 -> tc=4200000
n=100 -> tc=420000
n=1000 -> tc=42000
n=10000 -> tc=4200
n=100000 -> tc=420
n=1000000 -> tc=42
n=10000000 -> tc=4
But, if I understand correctly, it should be the following:
n=1 -> tc=41708333
n=10 -> tc=4170833
n=100 -> tc=417083
n=1000 -> tc=41708
n=10000 -> tc=4171
n=100000 -> tc=417
n=1000000 -> tc=42
n=10000000 -> tc=4

[Mosu]

It's possible that forcing the frame rate doesn't work for your combination and that the source file's timecodes are re-used. Try with an elementary stream (e.g. a raw h.264 file).

[v0lt]

With elementary stream:
n=1 -> tc=41708332
n=10 -> tc=4170833
n=100 -> tc=417083
n=1000 -> tc=41708
n=10000 -> tc=4171
n=100000 -> tc=417
n=1000000 -> tc=42
n=10000000 -> tc=4
More correctly, but there is a strange rounding "n = 1 -> tc = 41708332".

[Mosu]

Might be a bug, but one that I will likely not invest time into any time soon.

[mike23]

How do I find out the audio+video codec properties (e.g. audio/video bitrate, aspect ratio,...) of a mkv file?

I expect such an info in MKVtoolix GUI but did not found it.

Can this be integrated in the next release?

Thank you

[foxyshadis]

Next thread down (https://forum.doom9.org/showthread.php?t=96516), MediaInfo will give you what you need.

[Mosu]

If you want a compressed view/overview then MediaInfo is what you should use, just as foxyshadis has pointed out.

If you need a detailed view of the structure and content of a Matroska file then use the »mkvinfo GUI« that comes with the MKVToolNix package for the time being. Integrating mkvinfo's GUI into the »MKVToolNix GUI« is on the TODO list, albeit with a very low priority.

[mike23]

If you want a compressed view/overview then MediaInfo is what you should use, just as foxyshadis has pointed out.

If you need a detailed view of the structure and content of a Matroska file then use the »mkvinfo GUI« that comes with the MKVToolNix package for the time being. Integrating mkvinfo's GUI into the »MKVToolNix GUI« is on the TODO list, albeit with a very low priority.

Thank you.

"but mkvinfo GUI" from mkvtoolnix package is NOT a GUI but only a simple cmdline tool.
Is there a separate download for the GUI version?

[Mosu]

You're likely using the portable version. In that case you have to run »mkvinfo -g« (meaning you have to add the command-line option »-g« in order to start the GUI). The installer creates a start menu entry for it which already contains that command-line option.

No, it's not separate download, and no, it's not a simple command-line tool, it's both, actually.

[FireFreak111]

Any idea on how to fix the following problem? Any help would be greatly appreciated :)

When I use a FLAC track externally next to an MKV, it plays with 1:1 sync, loaded correctly, all good. When I mux it into that MKV using MKVmerge, it seems to cut off ~15 seconds of audio, starting too early, If I try to shift the audio by that much, its cut off still, but can start at the right time (just ~15 seconds no audio). The original file is a TrueHD file, and it does the same. (FLAC makes no difference)

There seem to be no warnings, no errors. Any idea why it's breaking?

The original problem is that the .ac3 file the track came from was damaged (its meant to be a TrueHD/AC3 file), reading in MKVMerge as a H264 clip. I used eac3to to extract the audio out of the file, and as stated it works perfectly as an external track. It's only when I try to mux the extracted track into the file that the sync is lost.

Finally, this file is alongside 24 other .ac3 files, which all play perfectly as a TrueHD track when muxed. I had to apply a -1ms shift to them all only when they are muxed into the file (unmuxed they are synced)

[hubblec4]

Hi Mosu

How many digits are allowed for an UID? In mmg->chapter editor are 19 digitis max and in the new gui 20.
The specs says an unsigned integer so could we use more then 20 digits, maybe infinite?

[nevcairiel]

Hi Mosu

How many digits are allowed for an UID? In mmg->chapter editor are 19 digitis max and in the new gui 20.
The specs says an unsigned integer so could we use more then 20 digits, maybe infinite?

Numbers in Matroska are limited to 64-bit, so the largest number it can represent is 18446744073709551615 (unsigned 64-bit integer), which happens to be 20 digits. But when using 20 digits, the first always has to be a 1.

[hubblec4]

many thanks nevcairiel.

[ndjamena]

C:\Users\User>mkvextract chapters "Z:\Dummy.mkv" -r "C:\Users\P
ublic\Desktop\Create Folder\chapters.xml"
terminate called after throwing an instance of 'mtx::mm_io::create_directory_x'
what(): create_directory() failed

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

[ndjamena]

https://github.com/mbunkus/mkvtoolnix/issues/1095

MKVMerge doesn't seem to be having any problems reading from m2vs on my machine any more, yet I still can't get FFMPEG to read a .wav without crashing and I'd assumed they were caused by the same "problem" on my PC.

I remuxed several m2vs repeatedly using the current version this morning without a hitch, so I downloaded 7.4.0 and tried again with that version and the second attempt bugged out on me.

What did you change?

[Mosu]

Things. Stuff. Code. The magic condition that made things go boom on your machine.

Read: I really have no idea why it's not crashing for you anymore.

[NikosD]

This file appears to have PGS subtitles, but mkvmerge complains about it.

Is track 3: only declared but with no content ?

http://www.filedropper.com/1latraviata

[Mosu]

The current 7.9.0+ does not complain about that file at all. It happily remuxes all three tracks.

What exactly is the complaint? Screenshots?

[NikosD]

You 're right.

Using directly mkvmerge works fine, so I posted again to StaxRip's thread which says that it's mkvmerge's fault.

http://forum.doom9.org/showthread.php?p=1726891#post1726891

[stax76]

Looking at my code I see that it permits error code 0 and 1 and aborts with everything else. I'll have to look for mkvmerge error codes documentation...

[Mosu]

That sounds about right. 2 = actual errors (all tools abort right after the first error, meaning with exit code 2 you will always only have one actual error message); 1 = warnings but no errors; 0 = neither errors nor warnings.

[Mosu]

Hey,

I've released MKVToolNix v8.0.0. A ton of work has gone into the new GUI, MKVToolNix GUI, which is now officially the GUI to use. The old GUI is now marked as being deprecated (it will show a warning about that when you start it) and will be removed within the next two releases.

Apart from all the improvements to the new GUI there have been a couple of bug fixes in other parts of the program suite. The most important or most noticeable is probably a bug fix to mkvmerge's key frame detection handling for MP4 DASH files.

Changes for package maintainers: nothing's changed since 7.9.0.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-06-19 Moritz Bunkus <moritz@bunkus.org>
* Released v8.0.0.
* MKVToolNix GUI: improved locating the mkvmerge executable on non-Windows systems. Fixes #1246 (https://github.com/mbunkus/mkvtoolnix/issues/1246).

2015-06-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor bug fix: dragging & dropping a file onto the chapter editor that cannot be parsed as chapters was causing a confusing warning about changed chapters not being saved.

2015-06-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: fixed several controls not changing their language correctly when the interface language is changed.

2015-06-10 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: drag & drop of files works even if no mux settings are currently open. Implements #1245 (https://github.com/mbunkus/mkvtoolnix/issues/1245).
* mkvmerge: bug fix: fixed codec identification for MP2 audio read from MPEG program/transport streams. Fixes #1242 (https://github.com/mbunkus/mkvtoolnix/issues/1242).

2015-06-09 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: job output enhancement: when clicking the »abort« button the GUI asks for confirmation before aborting. Both this check and the one when quitting the application can be turned off via an option in the preferences. Implements #1238 (https://github.com/mbunkus/mkvtoolnix/issues/1238).
* MKVToolNix GUI: job output bug fix: fixed displaying the estimated remaining time in tabs that have been opened for specific jobs. Fixes #1244 (https://github.com/mbunkus/mkvtoolnix/issues/1244).

2015-06-07 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool, header & chapter editor features: the GUI will ask for confirmation before closing or reloading tabs that have been modified and before quitting if there are modified tabs. This check can be disabled in the preferences. Implements #1211 (https://github.com/mbunkus/mkvtoolnix/issues/1211).
* MKVToolNix GUI: new merge tool feature: implemented an option that allows the user to set up a list of languages. When adding files only those tracks whose language is included in that list are set to be muxed by default. Implements #1227 (https://github.com/mbunkus/mkvtoolnix/issues/1227).
* MKVToolNix GUI: header editor bug fix: fixed the editor assuming values were changed if a track is present whose language element is not present in the file. Fixes #1240 (https://github.com/mbunkus/mkvtoolnix/issues/1240).

2015-06-06 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed the translation of the tool tip for the »close tab« buttons after changing the interface language. Fixes #1237 (https://github.com/mbunkus/mkvtoolnix/issues/1237).
* MKVToolNix GUI: bug fix: appended tracks will be disabled automatically when starting to mux if the track they're appended to has been disabled by the user.
* MKVToolNix GUI: new feature: added an option in the preferences for disabling additional lossless compression for all track types. Implements #1174 (https://github.com/mbunkus/mkvtoolnix/issues/1174).
* mkvmerge, MKVToolNix GUI: new feature: added an option (»--engage keep_last_chapter_in_mpls«) that will cause mkvmerge not to remove the last chapter entry from a Blu-ray play list file which mkvmerge normally does if that entry's timecode is within five seconds of the movie's end. Implements #1226 (https://github.com/mbunkus/mkvtoolnix/issues/1226).
* MKVToolNix GUI: fixed updating the number of pending jobs info in the status bar when manually starting jobs. Fixes #1236 (https://github.com/mbunkus/mkvtoolnix/issues/1236).
* MKVToolNix GUI: merge tool bug fix: fixed a crash when removing source files. Fixes #1235 (https://github.com/mbunkus/mkvtoolnix/issues/1235).

2015-06-05 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new watch jobs tool feature: implemented estimating the remaining time for both the current job and the whole queue.
* MKVToolNix GUI: merge tool bug fix: the default settings for the »output directory policy« was changed to »same directory as the first input file«. Fixes #1234 (https://github.com/mbunkus/mkvtoolnix/issues/1234).

2015-06-04 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: the following dialogs can now be maximized: the »preferences« dialog; the »additional command line options« dialog; the dialog showing the command line; the dialog where the user selects the play list to add. Implements #1231 (https://github.com/mbunkus/mkvtoolnix/issues/1231).
* MKVToolNix GUI: merge tool enhancement: pressing delete when the source files view is focused will cause the selected source files to be removed. Implements #1225 (https://github.com/mbunkus/mkvtoolnix/issues/1225).
* MKVToolNix GUI: merge tool enhancement: implemented toggling of »mux this« for all selected tracks by either double-clicking on the tracks or pressing enter/return when the tracks view is currently focused. Implements #1225 (https://github.com/mbunkus/mkvtoolnix/issues/1225).
* MKVToolNix GUI: job queue enhancement: added a menu entry for starting all jobs pending manual start. Implements #1228 (https://github.com/mbunkus/mkvtoolnix/issues/1228).
* MKVToolNix GUI: enhancement: the text in all message box dialogs can now be selected & copied, even on Windows. Implements #1230 (https://github.com/mbunkus/mkvtoolnix/issues/1230).
* 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. Implements #1229 (https://github.com/mbunkus/mkvtoolnix/issues/1229).

2015-06-02 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: on Windows the job queue was accidentally always saved to and loaded from the registry even if the portable version was used.
* MKVToolNix GUI: job queue bug fix: fixed accidental duplication of lines when using drag & drop in certain ways. Fixes #1221 (https://github.com/mbunkus/mkvtoolnix/issues/1221).

2015-06-01 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: if a job is running when the user wants to quit requires confirmation from the user that the running job should be aborted. Fixes #1219 (https://github.com/mbunkus/mkvtoolnix/issues/1219).
* MKVToolNix GUI: bug fix: fixed the initial status display when viewing a job's output from the queue.
* MKVToolNix GUI: bug fix: running jobs cannot be removed from the job queue anymore. Fixes #1220 (https://github.com/mbunkus/mkvtoolnix/issues/1220).
* MKVToolNix GUI: bug fix: when starting the GUI old jobs from the queue were silently discarded if they included additional parts (e.g. VOBs).
* MKVToolNix GUI: bug fix: job queue: when saving the job queue jobs removed in the GUI were not removed from the stored settings.
* MKVToolNix GUI: bug fix: when viewing the job output of a job that hasn't been run yet the »save output« button was enabled.
* mkvmerge, mkvpropedit: bug fix: fixed an invalid memory access leading to a crash in the Base 64 decoder. Fixes #1222 (https://github.com/mbunkus/mkvtoolnix/issues/1222).

2015-05-31 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed progress parsing for interface languages other than English.
* mkvmerge: enhancement: if running in GUI mode (parameter »--gui-mode«) then the progress will be output as the untranslated »#GUI#progress …%« in order to facilitate parsing of progress by GUIs.
* mkvmerge: bug fix: fixed key frame designation for video tracks in MP4 DASH files.

2015-05-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the track statistics tags of Matroska source files are always discarded, no matter whether or not they're to be created for the output file. That way they won't be reported as track tags by mkvmerge's identification mode. This makes it easier for the user to create output files without track statistics tags as (s)he only has to use the option »--disable-track-statistics-tags« and not disable all the track tags as well anymore. Fixes #1186 (https://github.com/mbunkus/mkvtoolnix/issues/1186).
* mkvmerge, mkvinfo, mkvextract: bug fix: fixed a crash with certain types of invalid Matroska files. Fix for #1183 (https://github.com/mbunkus/mkvtoolnix/issues/1183).

2015-05-26 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: removed some unused code thereby fixing compilation on OpenBSD (#1215 (https://github.com/mbunkus/mkvtoolnix/issues/1215)).

2015-05-25 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fix alignment of the tool contents with the tool selector at the bottom. Fixes #1194 (https://github.com/mbunkus/mkvtoolnix/issues/1194).
* MKVToolNix GUI: new feature: added a »help« menu with links to several parts of the MKVToolNix documentation. Implements #1195 (https://github.com/mbunkus/mkvtoolnix/issues/1195).
* MKVToolNix GUI: job output tool: added a button for acknowleding the warnings/errors produced for the job shown. Implements #1210 (https://github.com/mbunkus/mkvtoolnix/issues/1210) and is the last part of the implementation of #1196 (https://github.com/mbunkus/mkvtoolnix/issues/1196).
* MKVToolNix GUI: merge tool: the »save« button has been removed in favor of the »save…« menu entries. This also improves consistency with the other tools.
* MKVToolNix GUI: enhancement: header editor: made the meaning of the »Reset« button clearer with a better label and an additional tool tip. Implements #1212 (https://github.com/mbunkus/mkvtoolnix/issues/1212).
* MKVToolNix GUI: enhancement: the tabs for the tools that haven't been implemented yet (extraction, info and the tag editor) are not shown anymore.
* MKVToolNix GUI: bug fix: header editor: fixed the track language shown if the element is not present in the file.
* MKVToolNix GUI: bug fix: when browsing the output file name the currently entered file name is pre-selected in the dialog. Fixes #1207 (https://github.com/mbunkus/mkvtoolnix/issues/1207).
* MKVToolNix GUI: enhancement: the update check dialog showing the change log can now be maximized. Implements #1204 (https://github.com/mbunkus/mkvtoolnix/issues/1204).
* MKVToolNix GUI: new feature: implemented viewing the output of any job in the job queue.
* MKVToolNix GUI: new feature: implemented saving the job output to a file.
* MKVToolNix GUI: enhancement: language and country drop-down boxes will contain the common languages/countries both at the top as well as in the full list. Part of the implementation of #1200 (https://github.com/mbunkus/mkvtoolnix/issues/1200).
* MKVToolNix GUI: enhancement: the entry »Undefined (und)« is always shown at the top of the language drop-down boxes. Part of the implementation of #1200 (https://github.com/mbunkus/mkvtoolnix/issues/1200).
* MKVToolNix GUI: enhancement: the number of new warnings and errors are shown in the status bar. Both counters can be acknowledged via context menus on the status bar and in the job queue view. Part of the implementation of #1199 (https://github.com/mbunkus/mkvtoolnix/issues/1199).

2015-05-24 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: the number of jobs pending automatic/manual execution is listed in the status bar. Part of the implementation of #1199 (https://github.com/mbunkus/mkvtoolnix/issues/1199).

2015-05-23 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: the progress widget in the stats bar is not reset to 0 once all the jobs have been processed in order to signal the user that the jobs have actually been processed. Part of the implementation of #1198 (https://github.com/mbunkus/mkvtoolnix/issues/1198).
* MKVToolNix GUI: merge tool enhancement: a short animation of a moving icon is shown when a job is started or added to the job queue as a clue to the user what's happening and where to look for output. This animation can be disabled in the preferences. Implements #1198 (https://github.com/mbunkus/mkvtoolnix/issues/1198).

2015-05-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: job output bug fix: fixed superfluous empty lines in job output/warning/error output.
* MKVToolNix GUI: merge tool bug fix: when adding a VOB from a DVD the tree items for the additional parts (the other VOBs processed automatically) weren't shown.

2015-05-11 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool: fixed the scroll bar not disappearing in the input tab if the window is high enough. Fixes #1193 (https://github.com/mbunkus/mkvtoolnix/issues/1193).
* MKVToolNix GUI: chapter editor enhancements: when selecting a chapter the the chapter name closest to the previously selected chapter name (or the first if there wasn't a previously selected one) is selected automatically.
* MKVToolNix GUI: chapter editor enhancements: when starting a new file a single edition and a single chapter are added automatically.
* MKVToolNix GUI: merge tool enhancement: the »add files« button has been re-labeled »add source files« in order to make it clearer that it cannot be used for adding attachments, even if the attachments tab is the currently selected tab.
* MKVToolNix GUI: merge tool & job queue tool enhancement: short tool tips will be shown for the files, tracks, attachments and jobs views telling the user to right-click for adding files and similar actions.
* MKVToolNix GUI: new feature for the merge tool, the header and chapter editors: if no file is open then »new« and »open file« buttons are shown.
* build system: desktop files and icons were only installed if wxWidgets was enabled. Fixes #1188 (https://github.com/mbunkus/mkvtoolnix/issues/1188).
* man pages: clarify functionality of --default-duration. Fixes #1191 (https://github.com/mbunkus/mkvtoolnix/issues/1191).
* build system: bug fix: fixed running rake if no locale or one with an encoding other than UTF-8 is set. Fixes #1189 (https://github.com/mbunkus/mkvtoolnix/issues/1189).

Have fun.

[Mosu]

C:\Users\User>mkvextract chapters "Z:\Dummy.mkv" -r "C:\Users\P
ublic\Desktop\Create Folder\chapters.xml"
terminate called after throwing an instance of 'mtx::mm_io::create_directory_x'
what(): create_directory() failed

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.


Looks like I forgot to respond to this one. Thanks for pointing it out. I've fixed this to report an appropriate error message before release 8.0.0.

[Snowknight26]

In Windows, if the mouse cursor is placed over a disabled button, radio button or check box, scrolling doesn't work.

For example, when you open the MKVToolNix GUI, immediately place your mouse over the Tags browse button for example. Scrolling now does not work.

[Mosu]

Nothing I can fix; that's up to the GUI toolkit. Sorry.

[Thunderbolt8]

is it still recommended to stick to the 32-bit version as it used to be with older versions?

[Mosu]

I wonder where you got that impression from. All I've ever said during the time when I didn't offer 64bit binaries was that the 32bit binaries could do anything potential 64bit binaries could do. For MKVToolNix 64bit or 32bit doesn't make a difference; both versions offer the same set of features, and the resource usage (especially memory) is normally way below the limit for 32bit systems.

Meaning: chose whichever fits your operating system for supposedly best performance.

[hubblec4]

Hi Mosu

In the new gui the append-function works not correct.
I will append a 00003.m2ts to 00002.m2ts. The Video stream (only 1) appends correct, but there are 3 audio tracks and 12 subtitles.
The audio tracks from 00003.m2ts will all append to audio track 1 of the 00002.m2ts. Same with the subtitles

the mux prozess abort with an error message.

OR, I move manually all appended tracks to the correct track of 00002.m2ts.

[Dion]

I really hope you don't kill off the old GUI. It works perfectly fine and is VERY simple to use.

[rsotome]

Is there any way to get rid of the "mkvmerge GUI deprecated" message every time the program is started?

Not really that thrilled with the new GUI yet (maybe one day) & the old one works perfectly.

[mood]

please disable the "mkvmerge GUI deprecated" message every time the program is started.

why the new GUI save mka instead mkv?? It never happened to me with "old GUI"

If I have a file with name "RiseUp" for example

the old GUI changes it to RiseUp(1).mkv

the new GUI changes it to RiseUp.mka

why mka? And Why disable tracks automatically like video tracks

the old GUI works very well why change it

[LeMoi]

Is there any way to get rid of the "mkvmerge GUI deprecated" message every time the program is started?

Not really that thrilled with the new GUI yet (maybe one day) & the old one works perfectly.

+1. The message is quite annoying, at least, with previous versions, when there was an update, it showed the message only once ^^
I'm not really confortable with the new GUI, which is not as practical as the old one, so please, keep updating the new one but leave the old one with it ^^

[Mosu]

Thanks for your feedback. That message cannot be turned off at the moment. I will make it a one-shot message for the next release. If you want to get rid of it RIGHT FRIGGIN' NOW then you should be able to use mmg.exe from 7.9.0 until release 8.1.0.

The old GUI will definitely go away. Sorry. There are several reasons for that decision, among the most important for me that wxWidgets is a pain in the ass that requires constant attention. At the moment, for example, compiling MKVToolNix with a certain compiler switch used to highlighting the use of deprecated functions causes more than 60.000 lines of warnings to be emitted! And it's not mmg that's using those functions; those functions just happen to be part of a class that mmg uses. So there's not even anything I can do about it (apart from not using that switch which kind of defeats the purpose of such helpful switches).

Maintaining two GUIs at the same time is also simply not possible. And even before I started working on the new GUI I was so fed up with the toolkit (wxWidgets) the old GUI uses that I didn't want to implement anything in the old GUI anymore.

More reasons for that switch can be found in this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/MKVToolNix-GUI-status).

If you want to keep using the old GUI then you should be able to use mmg.exe from 7.9.0 for the time being and the foreseeable future. But do note that I do not make any guarantees that mkvmerge from a future version will continue to work with the old mmg.exe. The interface between mkvmerge and the GUIs doesn't change that often, but it does change sometimes, and I will not go out of my way to keep old technology working.

[Mosu]

Hi Mosu

In the new gui the append-function works not correct.
I will append a 00003.m2ts to 00002.m2ts. The Video stream (only 1) appends correct, but there are 3 audio tracks and 12 subtitles.
The audio tracks from 00003.m2ts will all append to audio track 1 of the 00002.m2ts. Same with the subtitles

the mux prozess abort with an error message.

OR, I move manually all appended tracks to the correct track of 00002.m2ts.

Thanks for the feedback. Hmm that doesn't sound right :) I can currently not reproduce the issue here but would like to fix it. Can you please provide me with screenshots after adding each file to its own mux job? What I need to know is the exact number of types of tracks; hence me asking for the screen shots so that I create a similar situation.

Alternatively I could also upload the first ~50MB of each file to my FTP server (https://github.com/mbunkus/mkvtoolnix/wiki/FTP-server) if you want. That should do the trick, too.

[Mosu]

why the new GUI save mka instead mkv?? It never happened to me with "old GUI"

Thanks for the heads-up. The output file name's extension is determined by the track types that are present in the file. If there are video tracks then .mkv should be used. If there are no video tracks present but audio tracks then .mka should be used.

That being said it's quite possible that the automatic adjustment of the output file name is currently buggy. I will look into this.

the old GUI works very well why change it

The point above sounds like a bug and not an intentional change. In this regard the new GUI should work like the old one.

I've already commented on some reasons for implementing a new GUI above; other reasons can be found here (https://github.com/mbunkus/mkvtoolnix/wiki/MKVToolNix-GUI-status).

[hubblec4]

Thanks for the feedback. Hmm that doesn't sound right :) I can currently not reproduce the issue here but would like to fix it. Can you please provide me with screenshots after adding each file to its own mux job? What I need to know is the exact number of types of tracks; hence me asking for the screen shots so that I create a similar situation.

Alternatively I could also upload the first ~50MB of each file to my FTP server (https://github.com/mbunkus/mkvtoolnix/wiki/FTP-server) if you want. That should do the trick, too.


Sample files will be uploaded.

and here the Screenshots.
The append issue occurs for every Bluray for me.

[Mosu]

Thanks. Definitely a bug, and I'll fix it. I've opened an issue for it (https://github.com/mbunkus/mkvtoolnix/issues/1257).

[hubblec4]

Another (issue)?

the old mmg config file: when i double click it, mmg open and all settings loaded.
the new config file dont open the new gui. when I choose in windows, "open file with..." and set the standard application, then the new gui open, but no settings will be loaded.

[hubblec4]

I hope the old gui will be work a long time, then it work perfect for me since many years.

but, i think we all will accustom to the new gui.

[Mosu]

That's the command-line options not having been implemented yet. It's on my TODO for the next release already (https://github.com/mbunkus/mkvtoolnix/issues/1209).

[hubblec4]

That's the command-line options not having been implemented yet. It's on my TODO for the next release already (https://github.com/mbunkus/mkvtoolnix/issues/1209).

ah ok, thanks. also a double click on the new config file will be the same behavior as the old config file?

[Mosu]

That's the plan, yes.

[mikeyakame]

Mosu,

Would it be possible for Preferences\Merging\Output file name\'Use fixed directory' in the new GUI, to treat a relative path as relative to the first input files path, rather than how it currently behaves, relative to the start directory of the GUI executable?

I can only speak as a Windows user, but typically I'd run the GUI from a shortcut and never from the console, as I just use the cli binaries if I have the console open instead. If this wasn't intended, would you be able to give it some thought?

Speaking for myself (and possibly others) where we work in a project layout, and can generally express the output path as relative to the input path, this would save having to browse or hand-edit the output file each time we create a new merge, and where it doesn't exist the current behaviour of 'Same path as first input file' is reasonable.

[Mosu]

Would it be possible for Preferences\Merging\Output file name\'Use fixed directory' in the new GUI, to treat a relative path as relative to the first input files path, rather than how it currently behaves, relative to the start directory of the GUI executable?

Thank you for the feedback. That's a good suggestion, at least partially. I will likely implement such an option but rather as an additional choice instead of replacing the current behavior of the »fixed directory choice«. Having a fixed output directory (e.g. on a separate, huge drive) is something that I know people are using; they wouldn't welcome the loss of that functionality.

What »relative directory« may replace, though, is the »parent directory of first output file« as that can be expressed as the relative directory »..«.

I'll open an issue for that.

[rsotome]

You're running with the new GUI, I get you don't want to have to worry about aging software, but maybe there's a way to customize the new GUI a bit to make the transition a little easier.

A problem I've been having is that the new GUI doesn't save attachments when I mux to an MKV file, so far I've only tried adding font files as attachments, so maybe it's an isolated incident.

After adding a new job to the 'job queue', can you make the current job box clear & load a blank one, much like the old GUI did?

Under input, bottom area "Tracks, chapters, tags and attachments:" can you make it possible for the new GUI to save my custom column layouts? Like I don't need to see the Codec, Type or ID columns, and I would like to organize the layout to see the Source file column first, Name column second, and the rest last.

Under output, adding a chapter file, can you make the default both .xml & .txt files? It's a bit picky I know, but when you're adding a laundry list of jobs, it gets annoying to have to keep selecting All files (*) for each one.

Thank you for taking the time to listen & for this great program. :)

[Mosu]

but maybe there's a way to customize the new GUI a bit to make the transition a little easier.

The new GUI has more customization options than the old one already, and I do plan on implementing a lot more configurable options so that users can fine-tune its behavior. See all the issues opened for the new GUI (https://github.com/mbunkus/mkvtoolnix/issues?q=is%3Aopen+is%3Aissue+label%3A%22app%3AMKVToolNix+GUI%22): in a lot of them I plan to implement the requested feature as an optional feature.

A problem I've been having is that the new GUI doesn't save attachments when I mux to an MKV file, so far I've only tried adding font files as attachments, so maybe it's an isolated incident.

This is a bug. Issue 1260 (https://github.com/mbunkus/mkvtoolnix/issues/1260) has already been opened for it.

After adding a new job to the 'job queue', can you make the current job box clear & load a blank one, much like the old GUI did?

Issue 1254 (https://github.com/mbunkus/mkvtoolnix/issues/1254) has already been opened for that. Yes, the feature will be implemented in the new GUI, too.

Under input, bottom area "Tracks, chapters, tags and attachments:" can you make it possible for the new GUI to save my custom column layouts? Like I don't need to see the Codec, Type or ID columns, and I would like to organize the layout to see the Source file column first, Name column second, and the rest last.

Interesting request. I'll open a new issue for it, and I will likely implement it, but it'll have a lower priority. Probably in 8.2.0 or 8.3.0. (It's issue 1268 (https://github.com/mbunkus/mkvtoolnix/issues/1268) now.)

Under output, adding a chapter file, can you make the default both .xml & .txt files? It's a bit picky I know, but when you're adding a laundry list of jobs, it gets annoying to have to keep selecting All files (*) for each one.

Sure, that's easy enough to do. I've opened issue 1269 (https://github.com/mbunkus/mkvtoolnix/issues/1269) for it.

Thank you for taking the time to listen & for this great program. :)

You're quite welcome, and thanks for your feedback & your kind words.

[Mosu]

And Why disable tracks automatically like video tracks

The new GUI has an option to only enable tracks that have a certain language (e.g. only enable English and German tracks but not the others). As video tracks often don't have a language you can additionally tell the GUI to always enable video tracks, no matter which language is selected for them.

My guess is that you've accidentally messed with that setting. The default setting is to always have all tracks enabled when you add them. You can achieve that by going to the preferences, selecting the »merging« tab and disabling the option »only enable muxing of tracks with specific languages by default«.

Note that the file name suggestion of .mka only happens if your current muxing job doesn't include a video track, or of all video tracks are disabled – meaning if an audio-only file would be created. This is the intended behavior. As soon as there's a video track present and enabled the new GUI will use .mkv as the extension, too.

[LeMoi]

I can't find in the new GUI the 'mis' language code that was present in mmg, i just see the 'und' code but not the 'mis'

[Mosu]

The new GUI sorts the language list by their description as I figured that most users know a language's name but not necessarily its ISO 639-2 code. The code »mis« belongs to the entry »Uncoded languages« which you can find in the new GUI as well (I've just checked).

Keep in mind that the new GUI always sorts »undefined (und)« first followed by the list of common languages (which can be configured in the preferences) in alphabetical order followed by all other languages in alphabetical order.

[LeMoi]

Thanks for the quick answer, indeed, i thought it still was miscellaneous language, that's why I could'nt find it :)

[DMD]

Good morning

Sorry for the trivial question
MI are accustomed to the old interface "mkvmerge GUI", wondering how to avoid the warning every time I launch the program.

http://i58.tinypic.com/2w1tixt.jpg

Thanks

[hubblec4]

this message will removed in next version 8.1.0

[DMD]

THANK YOU :)

lthen I will have to wait download the next version.

[Overdrive80]

Could be implemented any for can change order of attachments?? I ask it because order is important if you use cover art. Thanks.

[Mosu]

Could be implemented any for can change order of attachments?? I ask it because order is important if you use cover art. Thanks.

That is on my TODO list but with a lower priority. Will probably not be implemented in 8.1.0; maybe for 8.2.0. I've opened issue 1276 (https://github.com/mbunkus/mkvtoolnix/issues/1276) for it so that it won't be forgotten.

[Mosu]

this message will removed in next version 8.1.0

Minor nitpick: I will make the GUI show the message only once instead of every time. It won't be removed completely, though.

[kuchikirukia]

I have a video where there's a very clear short speedup right after scene changes when muxing with 8.0, either mkvmerge or mkvtoolnix GUI.

- Encoded video in MeGUI 2525 (muxed with 7.7): Fine (And if you mux it with 8.0 from that it's fine)
- Cut with AVIdemux: Fine
- Remuxed with 8.0: 20 seconds in there's a series of cuts to pans with clear jerks in MPC-HC

- Muxed the AVI with 7.7 and it's good.

Manually setting the frame rate doesn't help.

Remuxing the bad 8.0 mkv in 7.7 also outputs a bad video.

[Mosu]

Can you please open an issue on github (https://github.com/mbunkus/mkvtoolnix/issues/) and upload a sample file before muxing to my FTP server (https://github.com/mbunkus/mkvtoolnix/wiki/FTP-server), please? I'm completely booked with working on the new GUI at the moment, and I will most likely forget about your issue otherwise. Thanks.

[bartonnen]

I usually mux by first dragging in a video file and then an audio file - now with the new v8 GUI an "Adding or appending files" dialog appears.

Can we please have an option to either default to "adding", "appending" or "ask".

In my case I only ever want to add files.

[bartonnen]

With the job queue panel can we please have action buttons like in the old GUI: at least a START button and a DELETE button.

[Mosu]

I usually mux by first dragging in a video file and then an audio file - now with the new v8 GUI an "Adding or appending files" dialog appears.

Can we please have an option to either default to "adding", "appending" or "ask".


That's already on my TODO list for the next release (https://github.com/mbunkus/mkvtoolnix/issues/1259). The default setting will be to not show that dialog.

[Mosu]

With the job queue panel can we please have action buttons like in the old GUI: at least a START button and a DELETE button.

Starting all pending jobs is available from the »Job queue« menu. Deleting jobs is available from the context menu (right-click on a job for that menu, or select multiple jobs and then right-click for deleting them).

I explicitly do not want to plaster buttons for some functions all over the GUI.

[bartonnen]

Starting all pending jobs is available from the »Job queue« menu. Deleting jobs is available from the context menu (right-click on a job for that menu, or select multiple jobs and then right-click for deleting them).

I explicitly do not want to plaster buttons for some functions all over the GUI.

OK - that's fair enough. How about adding a keyboard shortcut for "Start all pending jobs"?

How is the context menu "Start jobs automatically" supposed to work? It seems to be greyed-out unless I have some files selected and then it seems to do the same as the menu option "Start all pending jobs".

The name "Start jobs automatically" makes it sound like jobs will start as soon as they're added to the list.

Also, any chance of having the "Enter job description" dialog be optional? The default job name is always acceptable to me.

[Mosu]

OK - that's fair enough. How about adding a keyboard shortcut for "Start all pending jobs"?

That I'm definitely open to. I'll open an issue for it.

How is the context menu "Start jobs automatically" supposed to work? It seems to be greyed-out unless I have some files selected and then it seems to do the same as the menu option "Start all pending jobs".

The name "Start jobs automatically" makes it sound like jobs will start as soon as they're added to the list.

The context menu entry can be used for re-enabling the selected jobs that have failed before (e.g. due to missing permissions on the destination folder). After re-enabling those jobs the queue will be started automatically (if it hasn't been running at that moment). Note that only one job can be running at the same time, meaning that if the queue is currently running and you select »start jobs automatically« from the context menu then those jobs will be started by the queue once the current job finishes. The queue is run from top to bottom, so there may be other jobs inbetween.

What I'm trying to say is that »Start jobs automatically« does not mean »start them right now«; it only schedules them to be run automatically once the queue gets to them.

The menu entry »start pending jobs« on the other hand will also start the jobs that are currently in state »pending manual start«. It will not touch jobs that have failed for one reason or another.

Also, any chance of having the "Enter job description" dialog be optional? The default job name is always acceptable to me.

Can do, will open another issue for it.

[bartonnen]

That I'm definitely open to. I'll open an issue for it.

...

Can do, will open another issue for it.

Awesome - thanks :thanks:

[Carpo]

Little naming issue if i use MKVToolNix GUI

Say I mux Batman, givng it the name Batman.mkv

it muxes correctly

if i select clear files and than add Batman Returns.264 and Batman Returns.ac3 - the ouput file name changes to Batman(1).mkv, instead of Batman Returns.mkv.

If I use mkvmerge GUI the output name is indeed changed correctly when I add Batman Returns.264, not a big bug, just means you have to double check the output name.

[Mosu]

That's due to the GUI not clearing the output file name properly. See this issue (https://github.com/mbunkus/mkvtoolnix/issues/1254) that I've already fixed.

[Carpo]

ah okay, I have only just started to use the new GUI so wasn't sure if it had been reported, my bad

[Lenmaer]

That new gui is just awful and painful to use. I guess, I’ll then have to forever stay on older versions.
Too bad no one listens to us…
That’s it then with updating mkvtoolnix.

[Mosu]

As I don't want to copy & paste my answer as Lenmaer has has question: see here (https://www.bunkus.org/blog/2015/06/mkvtoolnix-v8-0-0-released/#comment-24965).

[sl1pkn07]

finaly Qt instead of wxGTK!!

thanks a lot!

[Lenmaer]

As I don't want to copy & paste my answer as Lenmaer has has question: see here (https://www.bunkus.org/blog/2015/06/mkvtoolnix-v8-0-0-released/#comment-24965).

Well, I answered you on your blog. But to make it short, fansub groups will forever stick with 7.9.0. We (Several group leaders) had a discussion before 7.9.0 was released and agreed to forever stick with the latest version having the old gui.

[Mosu]

And I've replied there as well. Let's keep this discussion on the blog where it started, ok? No need to cross-post for us here for each reply.

[Mosu]

finaly Qt instead of wxGTK!!

thanks a lot!

You're quite welcome. I've already had a complaint from the other side, though: »oh no, Qt, it doesn't fit nicely into Gnome« ;)

Well, that's the crux of all those toolkit libraries on Linux: they just don't fit well into foreign desktop environments (GTK in KDE, Qt in Gnome etc.). No way to please everyone.

[Zenitram]

Well, I answered you on your blog. But to make it short, fansub groups will forever stick with 7.9.0. We (Several group leaders) had a discussion before 7.9.0 was released and agreed to forever stick with the latest version having the old gui.

As usual, some people code and some other do critisism "it was better in the past" without coding (and without real argument / improvement ideas).
And as usual, such people will stay with the last "lovely" version, and some time later they'll switch to the newest version without saying anything when they'll need improvements from a newest version (else other group leaders, using the newest version, would be prefered by the end users)

Nothing new, this is the classic pain of people who create something.

[Lenmaer]

All we are saying is that new gui looks nice but totally unadapted for heavy users. It's perfect for casual users like yourself, Zenitram.

[Mosu]

Again, please name the issues that make it unsuitable for heavy users. I would REALLY like to have it work well for almost everyone, but if you don't share what you think is broken or not working well then I cannot fix it.

[Zenitram]

No way to please everyone.

There is a way: the native UI of each target (Qt, GTK, Cocoa...). It is "only" more work (and obviously, lot of people complain but nobody offers to develop and maintain the code :D ).

Good move.

[stax76]

Being also a open source programmer and having programmed much GUI code for CLI tools I find Lenmaer's feedback somehow frustrating...

[foxyshadis]

Lenmaer, if you want to post something constructive, you're free to. Ranting isn't called for though, especially given that the new is a work in progress that's steadily improving.

[Chetwood]

But to make it short, fansub groups will forever stick with 7.9.0.
A fitting quote from Angel:

And yet, somehow, I just can't seem to care.

[Mosu]

Folks, please stay civil; bashing isn't constructive either. I do appreciate the support, but Lenmaer and I did have a discussion about his two most important grievances over on my blog (search for his nick there) (https://www.bunkus.org/blog/2015/06/mkvtoolnix-v8-0-0-released/#comments), and both of them will be addressed; one already has.

[Kurtnoise]

Hi Mosu,

The current GUI says that a new version 8.1.0 is available but the downloads still link to 8.0.0. Is it normal ?

[Mosu]

Meh… I've uploaded that update info file too early. The new release is still building (will be a couple of hours until it's done). Thanks for pointing it out.

Edit: I've fixed the information on the server.

[Mosu]

Hey,

I've released MKVToolNix v8.1.0 just eight days after 8.0.0. It incorporates a big amount of feedback on the new MKVToolNix GUI from users. Major bugs have been squashed, many usability enhancements have been implemented and even a couple of new features were added. If you're using 8.0.0 I urge you to upgrade.

As this release comes so quickly after the last one I have also decided to keep the old GUI around until at least 8.3.0 (the prior plan was to drop it after 8.2.0).

Changes for package maintainers: nothing's changed since v8.0.0.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-06-27 Moritz Bunkus <moritz@bunkus.org>
* Released v8.1.0.
* mmg: bug fix: fixed handling of the characters [ and ] in container and track properties.
* MKVToolNix GUI: merge tool enhancement: moved the »output file name« controls below the three tabs so they're always visible. Also added an option in the preferences to move them back inside the »output« tab. Implements #1266 (https://github.com/mbunkus/mkvtoolnix/issues/1266).

2015-06-26 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new chapter editor feature: added a function for generating a certain number of evenly spaced sub-chapter. Implements #1291 (https://github.com/mbunkus/mkvtoolnix/issues/1291).
* MKVToolNix GUI: merge tool bug fix: fixed various menu entries not working correctly after closing a tab or switching to another one. Fixes #1301 (https://github.com/mbunkus/mkvtoolnix/issues/1301).

2015-06-25 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new chapter editor feature: implemented loading chapter entries from Blu-ray playlists.
* MKVToolNix GUI: job queue enhancement: added menu entries for acknowledging both warnings and errors at the same time.

2015-06-24 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: if »automatically set the file title« is enabled then the title field will be cleared after all source files have been removed.
* MKVToolNix GUI: new watch jobs tool feature: the first tab showing the output of the current job has been changed to show the output of all jobs that have been run since the GUI's been started. This can be turned off in the preferences so that only the output of the currently running job is shown again. Implements #1263 (https://github.com/mbunkus/mkvtoolnix/issues/1263).
* MKVToolNix GUI: merge tool bug fix: fixed a crash when enabling/disabling chapters coming from an appended file. Fixes #1293 (https://github.com/mbunkus/mkvtoolnix/issues/1293).
* MKVToolNix GUI: new merge tool feature: added an option to set a directory relative to the first input file as the default output directory. Implements #1261 (https://github.com/mbunkus/mkvtoolnix/issues/1261).
* MKVToolNix GUI: merge tool bug fix: it was possible to set the »default track flag« to »yes« for multiple tracks of the same type. Fixes #1289 (https://github.com/mbunkus/mkvtoolnix/issues/1289).
* MKVToolNix GUI: enhancement: the »open file« dialogs for the chapter and header editor tools will use the same directory that was last used in the merge tool. Fixes #1290 (https://github.com/mbunkus/mkvtoolnix/issues/1290).

2015-06-23 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed reading the »default track« flag of tracks from added Matroska files. Fixes #1281 (https://github.com/mbunkus/mkvtoolnix/issues/1281).
* MKVToolNix GUI: new feature: added a check box to the track/chapters/tags/attachments list. This offers an additional way of toggling the »mux this« state of entries, same as the drop down box on the right and as double-clicking on the item already did. Implements #1277 (https://github.com/mbunkus/mkvtoolnix/issues/1277).
* MKVToolNix GUI: merge tool bug fix: when appending files with multiple tracks of a type (e.g. multiple audio tracks) then all tracks of that kind would get assigned to the first track of that kind of the file they're appended to. Now the second audio track from the appended file is appended to the second audio track of the existing file, the third to the third etc. Fixes #1257 (https://github.com/mbunkus/mkvtoolnix/issues/1257).
* MKVToolNix GUI: merge tool bug fix: fixed automatic output file name re-generation when the mux status of tracks changes. Fixes #1253 (https://github.com/mbunkus/mkvtoolnix/issues/1253).
* MKVToolNix GUI: new feature: added an option for always using the suggested description and not asking the user when adding a job to the queue. Implements #1288 (https://github.com/mbunkus/mkvtoolnix/issues/1288).
* MKVToolNix GUI: job queue enhancement: added the shortcut Ctrl+R for the menu entry »start all pending jobs«. Implements #1287 (https://github.com/mbunkus/mkvtoolnix/issues/1287).
* MKVToolNix GUI: new feature: added an option to always treat files dragged & dropped external applications as being added circumventing the question what to do with them (add, append or add as additional parts). This option is enabled by default changing the default behavior from release 8.0.0. Implements #1259 (https://github.com/mbunkus/mkvtoolnix/issues/1259).
* MKVToolNix GUI: new feature: added an optional action after starting a job or adding one to the queue. This can be either to create whole new settings or to only remove all input files. Implements #1254 (https://github.com/mbunkus/mkvtoolnix/issues/1254).
* mmg: bug fix: the deprecation warning will only be shown once. Fixes #1252 (https://github.com/mbunkus/mkvtoolnix/issues/1252).
* Installer for Windows: enhancement: associated the .mtxcfg files with MKVToolNix GUI. Implements #1258 (https://github.com/mbunkus/mkvtoolnix/issues/1258).
* MIME and desktop files: enhancement: added file associations for .mtxcfg with MKVToolNix GUI. Implements #1258 (https://github.com/mbunkus/mkvtoolnix/issues/1258).

2015-06-22 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: implemented command line handling. You can open configuration files, add files to merge jobs, open files in the chapter or header editors. Implements #1209 (https://github.com/mbunkus/mkvtoolnix/issues/1209).

2015-06-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed recognition of (E)AC3 audio tracks using a FourCC of »ec-3«. Fixes #1272 (https://github.com/mbunkus/mkvtoolnix/issues/1272).
* MKVToolNix GUI: merge tool bug fix: fixed attachments not being merged into the file in certain situations. Fixes #1260 (https://github.com/mbunkus/mkvtoolnix/issues/1260).
* MKVToolNix GUI: merge tool bug fix: fixed showing existing attachments present in source files in the »tracks, chapters, tags and attachments« list. Fixes #1256 (https://github.com/mbunkus/mkvtoolnix/issues/1256).
* MKVToolNix GUI: merge tool bug fix: the jobs created when appending files were incorrect resulting in an error message from mkvmerge. Fixes #1271 (https://github.com/mbunkus/mkvtoolnix/issues/1271).
* mkvpropedit: bug fix: fixed a warning about »edit specifications resolving to the same track« when changing the track properties and setting tags for the same track simultaneously. Fixes #1247 (https://github.com/mbunkus/mkvtoolnix/issues/1247).
* MKVToolNix GUI: merge tool bug fix: the output/destination file name is cleared when all files are removed. Fixes #1265 (https://github.com/mbunkus/mkvtoolnix/issues/1265).
* MKVToolNix GUI: merge tool bug fix: fixed command line escaping for empty arguments. Fixes #1270 (https://github.com/mbunkus/mkvtoolnix/issues/1270).
* MKVToolNix GUI: merge tool bug fix: fixed creating files without a title if one of the input files contains a file title. Fixes #1264 (https://github.com/mbunkus/mkvtoolnix/issues/1264).
* MKVToolNix GUI: bug fix: if the job removal policy is set to »remove even if there were warnings« then jobs that were muxed without warnings weren't removed. Fixes #1262 (https://github.com/mbunkus/mkvtoolnix/issues/1262).

2015-06-20 Moritz Bunkus <moritz@bunkus.org>
* Build system: fixed inclusion of desktop files for the two GUIs for Debian/Ubuntu packages. Fixes #1255 (https://github.com/mbunkus/mkvtoolnix/issues/1255).

Have fun.

[bartonnen]

Well, version 8.1 is much better - thanks for all your hard work Mosu.

I did find one issue though - with "Clearing setting automatically" set to "remove input files", after adding a job to the queue the settings are all cleared as expected and the name on the tab reverts to "<no output file>".

If I then try to exit the app (or close the tab) - I get the following warning:

"The file »<no output file>« has been modified. Do you really want to close? All changes will be lost."

[Mosu]

That's somewhat expected. The functionality »remove input files« does NOT revert the setting into a pristine state. The tool tip in the preferences hints at this. It only removes the input files, the tracks, and it clears the output file name and the file/segment title if and only if those two have been set automatically (enabled in the preferences). The other controls (e.g. split settings, chapters, attachments…) aren't touched.

This is definitely intentional behavior. It allows users to mux several files sharing common settings in succession quickly.

If your use case is to start over with pristine settings after muxing then set the option in the preferences to »create new settings« – that's what the option is there for.

[DMD]

Good morning

Sorry for the trivial question
MI are accustomed to the old interface "mkvmerge GUI", wondering how to avoid the warning every time I launch the program.

http://i58.tinypic.com/2w1tixt.jpg

Thanks

(Release 8.1.0) The warning appears only when you first start.

Thanks

[sneaker_ger]

The warning should only appear once in 8.1.0. Did you already try a second time?

[DMD]

I confirm, The warning appears only when you first start.

sorry

[TheShadowRunner]

yeah thank god (Mosu) for deprecation_warning_shown.

[mood]

Thanks Mosu for your hard work ;)

[DMD]

Thank you personally, Mosu for the great work and the time devoted to the development of this amazing program that I use for many years.

My request of previous posts, was motivated only by the fact that with the old interface knew by heart the settings.

But this is not a problem to get used to the new interface, which is very beautiful, functional and makes more professional program.
(In the next release could also be eliminated)

Thanks for allowing us to have this program and continues always so. http://www.ntacalabria.it/smile/tifosi/img/10.gif http://www.ntacalabria.it/smile/tifosi/img/11.gif

[stax76]

There is a merge/append feature in StaxRip, for VOB files StaxRip appends with DGIndex but with other files it just uses mkvmerge, occasionally something goes wrong and StaxRip ask the user then to send me the log file, usually I reply then telling to merge/append it manually somehow or not split in the first place. What I will improve in the future is writing MediaInfo for every part to be appended to the log file. Maybe Mosu, sneaker_ger or someone else might have a idea what's the problem. What actually returns a error is mp4box but there might already a problem with the mkvmerge output because MediaInfo doesn't output proper MediaInfo, after mkvmerge appends mkvextract is used to demux for which again is no proper MediaInfo available, StaxRip usually writes full MediaInfo of the output and input files to the log file after every processing step.

------------------------------------------------------------
Merge source files
------------------------------------------------------------

"C:\-Video\StaxRip\Tools\MKVToolNix\mkvmerge.exe" -o "G:\foo\1.mp4-muxed_merged.mkv" "G:\foo\1.mp4-muxed.mp4" + "G:\foo\2.mp4-muxed.mp4" + "G:\foo\3.mp4-muxed.mp4" + "G:\foo\4.mp4-muxed.mp4" + "G:\foo\5.mp4-muxed.mp4"

mkvmerge v7.9.0 ('Birds') 64bit
'G:\foo\1.mp4-muxed.mp4': Using the demultiplexer for the format 'QuickTime/MP4'.
'G:\foo\2.mp4-muxed.mp4': Using the demultiplexer for the format 'QuickTime/MP4'.
'G:\foo\3.mp4-muxed.mp4': Using the demultiplexer for the format 'QuickTime/MP4'.
'G:\foo\4.mp4-muxed.mp4': Using the demultiplexer for the format 'QuickTime/MP4'.
'G:\foo\5.mp4-muxed.mp4': Using the demultiplexer for the format 'QuickTime/MP4'.
'G:\foo\1.mp4-muxed.mp4' track 0: Using the output module for the format 'AVC/h.264'.
'G:\foo\1.mp4-muxed.mp4' track 1: Using the output module for the format 'AAC'.
'G:\foo\2.mp4-muxed.mp4' track 0: Using the output module for the format 'AVC/h.264'.
'G:\foo\2.mp4-muxed.mp4' track 1: Using the output module for the format 'AAC'.
'G:\foo\3.mp4-muxed.mp4' track 0: Using the output module for the format 'AVC/h.264'.
'G:\foo\3.mp4-muxed.mp4' track 1: Using the output module for the format 'AAC'.
'G:\foo\4.mp4-muxed.mp4' track 0: Using the output module for the format 'AVC/h.264'.
'G:\foo\4.mp4-muxed.mp4' track 1: Using the output module for the format 'AAC'.
'G:\foo\5.mp4-muxed.mp4' track 0: Using the output module for the format 'AVC/h.264'.
'G:\foo\5.mp4-muxed.mp4' track 1: Using the output module for the format 'AAC'.
No append mapping was given for the file no. 1 ('G:\foo\2.mp4-muxed.mp4'). A default mapping of 1:0:0:0,1:1:0:1 will be used instead. Please keep that in mind if mkvmerge aborts with an error message regarding invalid '--append-to' options.
No append mapping was given for the file no. 2 ('G:\foo\3.mp4-muxed.mp4'). A default mapping of 2:0:1:0,2:1:1:1 will be used instead. Please keep that in mind if mkvmerge aborts with an error message regarding invalid '--append-to' options.
No append mapping was given for the file no. 3 ('G:\foo\4.mp4-muxed.mp4'). A default mapping of 3:0:2:0,3:1:2:1 will be used instead. Please keep that in mind if mkvmerge aborts with an error message regarding invalid '--append-to' options.
No append mapping was given for the file no. 4 ('G:\foo\5.mp4-muxed.mp4'). A default mapping of 4:0:3:0,4:1:3:1 will be used instead. Please keep that in mind if mkvmerge aborts with an error message regarding invalid '--append-to' options.
Warning: The track number 0 from the file 'G:\foo\4.mp4-muxed.mp4' can probably not be appended correctly to the track number 0 from the file 'G:\foo\3.mp4-muxed.mp4': The codec's private data does not match (lengths: 43 and 38). Please make sure that the resulting file plays correctly the whole time. The author of this program will probably not give support for playback issues with the resulting file.
Warning: The track number 0 from the file 'G:\foo\5.mp4-muxed.mp4' can probably not be appended correctly to the track number 0 from the file 'G:\foo\4.mp4-muxed.mp4': The codec's private data does not match (lengths: 38 and 43). Please make sure that the resulting file plays correctly the whole time. The author of this program will probably not give support for playback issues with the resulting file.
The file 'G:\foo\1.mp4-muxed_merged.mkv' has been opened for writing.
Progress: 0%
Appending track 0 from file no. 1 ('G:\foo\2.mp4-muxed.mp4') to track 0 from file no. 0 ('G:\foo\1.mp4-muxed.mp4').
Appending track 1 from file no. 1 ('G:\foo\2.mp4-muxed.mp4') to track 1 from file no. 0 ('G:\foo\1.mp4-muxed.mp4').
Progress: 30%
Appending track 0 from file no. 2 ('G:\foo\3.mp4-muxed.mp4') to track 0 from file no. 1 ('G:\foo\2.mp4-muxed.mp4').
Appending track 1 from file no. 2 ('G:\foo\3.mp4-muxed.mp4') to track 1 from file no. 1 ('G:\foo\2.mp4-muxed.mp4').
Progress: 58%
Appending track 0 from file no. 3 ('G:\foo\4.mp4-muxed.mp4') to track 0 from file no. 2 ('G:\foo\3.mp4-muxed.mp4').
Appending track 1 from file no. 3 ('G:\foo\4.mp4-muxed.mp4') to track 1 from file no. 2 ('G:\foo\3.mp4-muxed.mp4').
Appending track 0 from file no. 4 ('G:\foo\5.mp4-muxed.mp4') to track 0 from file no. 3 ('G:\foo\4.mp4-muxed.mp4').
Appending track 1 from file no. 4 ('G:\foo\5.mp4-muxed.mp4') to track 1 from file no. 3 ('G:\foo\4.mp4-muxed.mp4').
Progress: 89%
Progress: 100%
Progress: 100%
The cue entries (the index) are being written...
Muxing took 2 seconds.

------------------------------------------------------------
Environment
------------------------------------------------------------

StaxRip version : 1.3.1.0
OS : Windows 7 Professional N
Language : Serbian (Cyrillic, Serbia)
CPU : Intel(R) Core(TM)2 Duo CPU E4700 @ 2.60GHz
GPU :
LAV Filters : LAV Filters 0.65

------------------------------------------------------------
Source file MediaInfo
------------------------------------------------------------

G:\foo\1.mp4-muxed_merged.mkv

Matroska : 250 MiB, 46mn 55s646*480 (4:3), at 25.000 fps, AVC (Main@L3) (CABAC / 3 Ref Frames)44.1 KHz, 2 channels, AAC (LC)

------------------------------------------------------------
Demux audio using mkvextract
------------------------------------------------------------

"C:\-Video\StaxRip\Tools\MKVToolNix\mkvextract.exe" tracks "G:\foo\1.mp4-muxed_merged.mkv" 1:"G:\foo\1.mp4-muxed_merged temp files\1.mp4-muxed_merged - ID2.aac" --ui-language en

Extracting track 1 with the CodecID 'A_AAC' to the file 'G:\foo\1.mp4-muxed_merged temp files\1.mp4-muxed_merged - ID2.aac'. Container format: raw AAC file with ADTS headers

Start: 14:38:35
End: 14:38:39
Duration: 00:00:03

ADTS : 43.0 MiB44.1 KHz, 2 channels, AAC (Version 4) (LC)

------------------------------------------------------------
Mux AAC to M4A
------------------------------------------------------------

"C:\-Video\StaxRip\Tools\MP4Box\MP4Box.exe" -add "G:\foo\1.mp4-muxed_merged temp files\1.mp4-muxed_merged - ID2.aac:name= " -new "G:\foo\1.mp4-muxed_merged temp files\1.mp4-muxed_merged - ID2.m4a"

------------------------------------------------------------
Error Mux AAC to M4A
------------------------------------------------------------

Mux AAC to M4A failed with exit code -1073741701

[hubblec4]

Hi Mosu

With a doubleclick on the mtxcfg and the new gui open, like you promised. :-)
But a doubleclick on a second mtxcfg and nothing happens. with the drag&drop it works and a new tab is created.

[Mosu]

If an instance is running already then the second config should have been opened in that already-running instance. I definitely remember having tested that on Windows, too. Will have to re-test tonight.

[hubblec4]

If an instance is running already then the second config should have been opened in that already-running instance.

After few new tests: The second mtxcfg open a new tab sometimes. (But mostly nothing happens)

[hubblec4]

I found a small issue in the chapter editor.
when i load a xml file with drag&drop, all "save" option keeps grey and can't be used.

[Mosu]

That problem has already been fixed; see https://github.com/mbunkus/mkvtoolnix/issues/1312

[XinHong]

Hi Mosu

I am having an issue with the default charset on subtiles.

With mkvmerge GUI the charset is set to "Default" and subtitles are displayed properly but with MKVToolNix GUI the charset is ISO-885915.
In that case subtitles with accent are displayed like this: "é" is translated "é".

Witch charset is the same than the "Default" of mmg ?

[Mosu]

Huh… the equivalent should have been no selection at all, but unfortunately the combo box in the preferences does not contain an empty entry. That's a bug, obviously, and I'll fix it.

The »default« is a character set depending on your Windows installation. It's often CP1252 or something like that. But maybe your file uses UTF-8 encoding? You should give that a try, too.

[XinHong]

There is an empty entry (above ISO-885915) but it does not work.

Anyway it's working with UTF-8, thanks for the tip.

[Mosu]

With a doubleclick on the mtxcfg and the new gui open, like you promised. :-)
But a doubleclick on a second mtxcfg and nothing happens. with the drag&drop it works and a new tab is created.

I've implemented a fix that works well on my Windows and Linux systems. I'd appreciate it if you could give it a try, too. Pre-builds 805 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/) and higher contain that fix.

That pre-build contains the fix for the chapter editor menu entry issue you've mentioned, too, of course.

The 32bit binaries are still being built, BTW, they should be done and uploaded in a couple of minutes.

Thanks.

I am having an issue with the default charset on subtiles.

With mkvmerge GUI the charset is set to "Default" and subtitles are displayed properly but with MKVToolNix GUI the charset is ISO-885915.
In that case subtitles with accent are displayed like this: "é" is translated "é".

The pre-builds mentioned above contain the fix that the »default subtitle character set« combo box in the preferences can be set to »– no selection by default –« which uses the aforementioned operating-system dependent defaults. That combo box in the preferences dialog is the one that didn't contain an empty entry.

[Keiyakusha]

Hi. This is most likely was already discussed but still I want to mention... In my case it takes around 10 seconds for the new GUI to start, close or perform action after I press mux button (or other similar buttons). Not sure when this started. When I tried one of the early versions (that still included mkvextract stub) it wasn't the case. Edit: on windows7, x64 version of the gui

[Mosu]

No, I haven't had such a report before. Sounds like every time the settings are loaded from/saved to disk. I don't know what could cause that, I haven't seen it happen before, and I don't have a clue how to debug it. Sorry.

[hubblec4]

I've implemented a fix that works well on my Windows and Linux systems. I'd appreciate it if you could give it a try, too.

That pre-build contains the fix for the chapter editor menu entry issue you've mentioned, too, of course.

Thanks Mosu, all works fine.

[hubblec4]

Hi Mosu

I need an explanation for nested chapters and the options "hidden" and "enabled".
When a chapter is set to hidden/disabled, then are all nested chapters hidden/disabled?
So i could set all nested chapters hidden flags to 1 and enabled flags to 0 ?

[Mosu]

I cannot help you with that as I wasn't the one doing the chapter specs. I've also never experienced with these kinds of settings.

Maybe someone else can answer that.

[sneaker_ger]

When a chapter is set to hidden/disabled, then are all nested chapters hidden/disabled?
I'd say yes. (According to spec. Players might be different.)

http://www.matroska.org/technical/specs/chapters/index.html#flags

[Boulder]

I've given the new GUI a go muxing some TV series, and I must say that I like it :) I thought that I would have problems adjusting to it but it seems that I'm able to do my stuff much easier and faster with the new GUI.

One small request though: would it be possible to have a separate default language for audio and subtitles?

[Mosu]

Yeah, though that means I'll have to provide one for video tracks, too. I'll add a feature request with medium priority.

[hubblec4]

I'd say yes. (According to spec. Players might be different.)

http://www.matroska.org/technical/specs/chapters/index.html#flags

Such explanaitons are confuse me :-)

For example: Let's assume a parent atom with flag hidden set to true; that parent contains two child atom, the first with hidden set to true as well and the second child with the flag either set to false or not present at all (in which case the default value applies, and that again is false).

The first child node is hidden and a second not...mmh i dont understand.

I think LAV Splitter is the new standard for mkv. A hidden chapter will not shown but all the nested chapters.
Disabled chapters will be ignored and not shown (include all nested chapters).


Mosu: Who was that one doing the chapter specs?

[Mosu]

Steve Lhomme, if I remember correctly.

[qyot27]

Would it be possible to allow using keyboard shortcuts to reorder tracks (i.e. the + and - numpad buttons) in addition to drag-and-drop? It can be kind of difficult to perform a drag-and-drop if the user's input device isn't a mouse.

[Mosu]

It's on the TODO list, but it turns out to be quite difficult to implement (the algorithm that does the actual moving – not the keyboard interaction with it).

[stax76]

It's on the TODO list, but it turns out to be quite difficult to implement (the algorithm that does the actual moving – not the keyboard interaction with it).

Can't you just remove and insert items in a list? I needed to do it 3 weeks ago for WinForms DataGridView so I searched for code I can use, several people posted examples but none supported multi selection so I used the code I wrote for ListView, it works the same, just moves the item above or below the selection.

https://github.com/stax76/staxrip/blob/master/Extensions/UI%20Extensions.vb#L107

https://github.com/stax76/staxrip/blob/master/UI/Controls/ListViewEx.vb#L64

[Mosu]

The thing is to decide which items go where – especially taking multiple selections and appended tracks into account. They cannot be moved everywhere (an appended audio track mustn't be moved to a video track etc). Then there are things like if you have both a parent and some of its children selected then user usually only wants the parent moved (and all of its children with the parent) – but the selected children should not be moved after the parent has been moved. Etc.

The code is far from trivial, and it's finicky to test. It's also a problem that there are two structures that have to be kept in sync: the GUI's list widget and the internal configuration settings.

The devil is in the details. »just remove and insert« isn't as easy as you make it sound. See here for the current implementation (https://github.com/mbunkus/mkvtoolnix/blob/master/src/mkvtoolnix-gui/merge/track_model.cpp#L457). Not overly long, but getting it right, especially for the corner cases, is the tricky part.

I've got the code for moving tracks already, but moving files hasn't been implemented yet. It'll be similar, but it'll also have to take even more situations into account as there are additional parts to consider, too.

And if I provide such controls for the track and file lists then users will request similar controls for the chapter editor, the job queue… The chapter editor will be fun, too, as I have to think about useful key bindings for »move level up/down«, too, not just »move up/down on the same level«.

[73ChargerFan]

Wow, thanks for this:

MKVToolNix GUI: new chapter editor feature: implemented loading chapter entries from Blu-ray playlists.

[Mosu]

You're quite welcome :)

[73ChargerFan]

The chapter editor will be fun, too, as I have to think about useful key bindings for »move level up/down«, too, not just »move up/down on the same level«.

Does QT differentiate between "UpArrow" and "SHIFT+UpArrow" key presses?

If so, then the SHIFT key could be a modifier from a commonly used command (e.g. "UpArrow" = move line up in same level) to a closely related, less frequently used command ("SHIFT+UpArrow" = move entire level up.)

A similar example would be in a text editor, where "UpArrow" = move cursor up a line, while "SHIFT+UpArrow" = move cursor up a paragraph.

Trying to be helpful. :)

[Mosu]

Yes, it does, but Shift+Arrows is already used for shrinking/expanding in a select (applies to the files/tracks/attachments lists, but not the chapter editor, however, I won't use the same basic key bindings for different functionality within my GUI).

I'm currently thinking about Ctrl+Up/Down for moving up/down on the same level, Ctrl+Left for »move one level up« (in direction of the root) and Ctrl+Right for »move one level down« (away from the root). Using left/right is similar to a basic tree view functionality: expanding the current item (right arrow) and collapsing it (left arrow).

[73ChargerFan]

Yeah, I forgot the Windows convention of using shift & ctrl expand selections.

[ndjamena]

Such explanaitons are confuse me :-)


The first child node is hidden and a second not...mmh i dont understand.

I think LAV Splitter is the new standard for mkv. A hidden chapter will not shown but all the nested chapters.
Disabled chapters will be ignored and not shown (include all nested chapters).


Mosu: Who was that one doing the chapter specs?

https://forum.videolan.org/viewtopic.php?f=2&t=118984

The Specs look like they were written by the village idiot

That's my take on the whole Matroska situation. I've tried my hand at Tags, I've tried writing a chapter editor. It seems no matter where I look in the Matroska world it always comes to a grinding halt, and the fact that I'm running into other people who are having the same problems as me is the only evidence I have that's it's not entirely my fault. I was hoping at first that you knew what you were doing and had some insider information the rest of us didn't have, but then I did some reading and found out where that info of yours was coming from.

https://forum.videolan.org/viewtopic.php?f=14&t=124278

I still haven't figured out how "gaps" work exactly, but I re-ripped the DVD I was having problems with using MakeMKV again and ran it through some tests.

https://github.com/mbunkus/mkvtoolnix/issues/1104

MKVMerge still splits it properly. And since Lhomme did some tinkering in VLCs inner workings the nightly no longer goes skitzo when it finds the end of the stream (or a gap or whatever).

I'm kind of hoping somewhere out of my program group (VLC, MakeMKV, MKVToolNix) exists people who actually know how the Matroska works... it's not MediaPortal, I know that.

Mosu has been telling me to ask Lhomme how everything actually works, so I did, and got no answer. So I think it's best if people just don't fiddle with these kind of things until the Specs have been brought up to... specs.

I've been looking half-heartedly through the specs for the part where it specifically mentions unknown elements should be skipped... I haven't found it yet, I can see where it could be implied though...


http://www.matroska.org/technical/specs/notes.html
Beginning of File

An EBML file always starts with 0x1A. The 0x1A makes the DOS command "type" ends display. That way you can include ASCII text before the EBML data and it can be displayed. The EBML parser is safe from false-alarm with these ASCII only codes.

Next the EBML header is stored. This allows the the parser to know what type of EBML file it is parsing.


I've been trying to figure out why it mentions this and what it's trying to say exactly. I've tried adding text to the beginning of a MKV using a hex editor and not even MKVMerge could read the bloody thing ('type' worked nicely though).

[hubblec4]

... I was hoping at first that you knew what you were doing and had some insider information the rest of us didn't have, but then I did some reading and found out where that info of yours was coming from.

All my information I have collected in the last time be useless, because no AV-Splitter can handle the full of mkv-properties.
LAV is atm the best way but far away from that what Matroska can do.
I'm sure its not a problem for me to build Menu.xml chapter files like DVDMenuExtractor or other nice things (like Track-selection).

We must live with that what others do for us.

Mosu is my hero and its nice to know, that he work continuously on MKVToolNix.

[ndjamena]

MKVToolNix is the best thing about Matroska.

And VC-1 and PGS, but PGS is MakeMKVs doing, so I guess MakeMKV goes on the list too.

[bartonnen]

I noticed an issue with 8.1 - if I drag an mkv into the "edit chapters" screen and alter some chapter names, none of the three save options on the menu are available. If I then click on another page and back to "edit chapters" again, the save options are now available. Same thing happens when using the open option from the menu.

The save options should be available as soon as a file is dragged in or opened.

[Mosu]

Thanks for reporting. That's a known issue that's already been fixed (https://github.com/mbunkus/mkvtoolnix/issues/1312).

[Mosu]

Hey,

I've released MKVToolNix v8.2.0. This is another release implementing a lot of enhancements and new features for MKVToolNix GUI. Nearly all of them are a direct result of all the feedback received for versions 8.0.0 and 8.1.0. Therefore I urge you to upgrade, especially if you're still using 8.0.0.

The old GUI (mkvmerge GUI) is still included and scheduled to be removed after 8.3.0.

Changes for package maintainers: nothing's changed since v8.1.0.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-07-18 Moritz Bunkus <moritz@bunkus.org>
* Released v8.2.0.
* mkvmerge, MKVToolNix GUI: bug fix: fixed the container type not being recognized properly by the GUI. Now the numerical container type ID is output in verbose identification mode by mkvmerge.
* MKVToolNix GUI: chapter editor enhancement: the template for chapter names can now contain a number of places for the chapter number, e.g. '<NUM:3>'. The number will be zero-padded if there are less places than specified.
* MKVToolNix GUI: new chapter editor feature: implemented a function for renumbering chapters. This allows the user to automatically assign new chapter names to one level of sub-chapters with ascending numbers. Implements #1355 (https://github.com/mbunkus/mkvtoolnix/issues/1355).

2015-07-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: the position of the tab headers of all tab widgets can be changed in the preferences. Implements #1334 (https://github.com/mbunkus/mkvtoolnix/issues/1334).

2015-07-12 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: added an option for hiding the tool selector.
* MKVToolNix GUI: new job queue feature: added menu options for stopping the queue either immediately or after the current job has finished. Implements #1303 (https://github.com/mbunkus/mkvtoolnix/issues/1303).
* MKVToolNix GUI: new job queue feature: added a context menu option for setting jobs to status »pending manual start«.

2015-07-11 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor bug fix: the file is not kept open so that you can open it in other applications at the same time.
* MKVToolNix GUI: new merge tool feature: added context menu options for selecting all tracks of a specific type (e.g. all audio tracks). Implements #1197 (https://github.com/mbunkus/mkvtoolnix/issues/1197).
* MKVToolNix GUI: merge tool enhancement: the dialog shown after dragging & dropping files from external applications asking if those files should be added or appended now has an option to always add and never to show that dialog again. For new MKVToolNix installations the default is now to show this dialog again until the user deactivates it either in the dialog or in the preferences.
* MKVToolNix GUI: new feature: added additional ways to move selected files, tracks and attachments around: keyboard shortcuts (Ctrl+Up and Ctrl+Down) and optional buttons (those have to be enabled in the preferences). Using drag & drop remains possible. Implements #1279 (https://github.com/mbunkus/mkvtoolnix/issues/1279).

2015-07-05 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: if a GUI language other than English was selected then the warning/error messages output by mkvmerge were not recognized properly and output in the wrong text views.
* MKVToolNix GUI: merge tool bug fix: fixed loading saved settings in which an appended file contains chapters/tags/attachments.

2015-07-04 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: dragging files from external applications now allows you to create new mux settings and add the dropped files to those if the »always add dropped files« option is off. Implements #1297 (https://github.com/mbunkus/mkvtoolnix/issues/1297).
* MKVToolNix GUI: new feature: added support for displaying the queue progress on the task bar button. Implements #1335 (https://github.com/mbunkus/mkvtoolnix/issues/1335).
* mkvmerge: bug fix: fixed handling of MPEG transport streams where all PATs and PMTs have CRC errors. Fixes #1336 (https://github.com/mbunkus/mkvtoolnix/issues/1336).
* MKVToolNix GUI: new merge tool feature: implemented support for re-ordering new attachments via drag & drop. Implements #1276 (https://github.com/mbunkus/mkvtoolnix/issues/1276).

2015-07-03 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed the command line option used when the »fix bitstream timing info« check box is checked. Fixes #1337 (https://github.com/mbunkus/mkvtoolnix/issues/1337).

2015-07-01 Moritz Bunkus <moritz@bunkus.org>
* docs: added a Spanish translation of the man pages by Israel Lucas Torrijos (see AUTHORS).
* MKVToolNix GUI: enhancement: several drop down boxes have had their options renamed slightly to be more consistent overall and easier to select via the keyboard. Implements #1309 (https://github.com/mbunkus/mkvtoolnix/issues/1309).
* MKVToolNix GUI: fix compilation with the upcoming Qt 5.5.0. Fixes #1328 (https://github.com/mbunkus/mkvtoolnix/issues/1328).

2015-06-30 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: job queue bug fix: when re-starting a job the »date finished« field wasn't reset. Fixes #1323 (https://github.com/mbunkus/mkvtoolnix/issues/1323).
* MKVToolNix GUI: merge tool bug fix: the option »set output file name relative to first input file« caused the relative path to be applied each time a file was added resulting in the wrong directory. Fixes #1321 (https://github.com/mbunkus/mkvtoolnix/issues/1321).
* MKVToolNix GUI: merge tool bug fix: when adding a Blu-ray playlist and aborting the »select playlist to add« dialog the originally opened playlist was added even so.
* mkvmerge: bug fix: the MPEG-1/2 video code was causing an illegal memory access under certain conditions. Fixes #1217 (https://github.com/mbunkus/mkvtoolnix/issues/1217) and #1278 (https://github.com/mbunkus/mkvtoolnix/issues/1278).

2015-06-29 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the »default subtitle character set« combo box required a selection without an option for using the system's default. An entry »– no selection by default –« has been added at the top.
* MKVToolNix GUI: bug fix: fixed parsing command line arguments to an already-running instance on Windows. Fixes #1322 (https://github.com/mbunkus/mkvtoolnix/issues/1322).

2015-06-28 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: position and size of the several additional windows are saved and restored. These include: the preferences window, the dialog for additional command line options, the dialog showing the command line and the dialog for selecting the playlist to add. Implements #1317 (https://github.com/mbunkus/mkvtoolnix/issues/1317).
* MKVToolNix GUI: bug fix: fixed the combo boxes with languages, countries and character sets not being re-initialized after changes to the list of common languages/countries/character sets in the preferences. Fixes #1224 (https://github.com/mbunkus/mkvtoolnix/issues/1224).
* MKVToolNix GUI: enhancement: the relative sizes of all splitters are saved and restored. Implements #1306 (https://github.com/mbunkus/mkvtoolnix/issues/1306).
* MKVToolNix GUI: chapter editor bug fix: fixed the menu entries »save to XML file« and »save to Matroska file« not being available after loading chapters until the tool or tab was changed. Fixes #1312 (https://github.com/mbunkus/mkvtoolnix/issues/1312).
* MKVToolNix GUI: bug fix: fixed labels and therefore the window becoming excessively wide with long file names. Fixes #1314 (https://github.com/mbunkus/mkvtoolnix/issues/1314).
* MKVToolNix GUI: merge tool bug fix: fixed the focus marker around combo boxes inside scroll areas not being drawn. Fixes #1310 (https://github.com/mbunkus/mkvtoolnix/issues/1310).
* MKVToolNix GUI: merge tool bug fix: fixed the stereoscopy mode being off by one. Fixes #1311 (https://github.com/mbunkus/mkvtoolnix/issues/1311).
* MKVToolNix GUI: merge tool bug fix: fixed the --append-to calculation if more than one file has been appended. Fixes #1313 (https://github.com/mbunkus/mkvtoolnix/issues/1313).

Have fun.

[Keiyakusha]

Hi Mosu. Unfortunately for me this version still has that 10-sec-delay-before-action issue. Do you have any tips as to what can I check/fix or something? Could it be some leftovers from old beta versions that are interfering? Old GUI is lightning-fast as always. Edit: win7 x64, x64 MKVtoolnix

[ndjamena]

* mkvmerge: bug fix: the MPEG-1/2 video code was causing an illegal memory access under certain conditions. Fixes #1217 and #1278.

Wow, there's been a bug in the m2v reading code since 7.4.0 that only shows itself in random situations, it's odd that no one tried to report that the moment 7.4.0 was released.

On an unrelated note, I really need to figure out how to get access to a second computer...

[Mosu]

Hi Mosu. Unfortunately for me this version still has that 10-sec-delay-before-action issue. Do you have any tips as to what can I check/fix or something? Could it be some leftovers from old beta versions that are interfering? Old GUI is lightning-fast as always. Edit: win7 x64, x64 MKVtoolnix

Unfortunately I don't have an idea why it's doing it or what to do about it. Sorry.

[Mosu]

Hi Mosu. Unfortunately for me this version still has that 10-sec-delay-before-action issue. Do you have any tips as to what can I check/fix or something? Could it be some leftovers from old beta versions that are interfering? Old GUI is lightning-fast as always. Edit: win7 x64, x64 MKVtoolnix

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

[Keiyakusha]

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

I usually prefer portable versions of the software but with MKVtoolnix I somehow ended up using installer all the time. But anyway, you are right. Portable version does not have this issue for me. I'll just use it from now on. :thanks:

[Mosu]

Uhm… the portable works nicely and the installed one has those delays!? Wow, that's interesting. The only difference between those two is how the settings are stored: in an .ini for the portable one and in the registry for the installed version (same code in both cases, which code path is used is determined by the presence or absence of the file data\portable-app).

Do you still have the registry settings from the installed version? They're stored as HKEY_CURRENT_USER\Software\bunkus.org. If so, can you please export that sub-tree and send it to me to moritz@bunkus.org? Thanks.

[TheBean]

Is it possible to disable the generation of global tags / track tags with the new GUI? I'm still using 7.9.0 because I like to have them disabled with the command line and can't figure out how to do it with 8.2.0.

[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.

[NanoBot]

Hi Mosu, hi everybody,

I would like to suggest a small cosmetic change concerning the import of chapter files:

The file requester by default offers the ".xml" file extension for xml-based chapter files, but it does not offer the ".txt" or ".ogg" file extension for text-based chapter files. Of course it is possible to change the extension filter from ".xml chapter files" to "all files", but I would suggest to change the default file extension to ".xml, .ogg, .txt", which would allow to import both xml- and text-based chapter files without changing the file extension filter to "all files".

C.U. NanoBot

[Mosu]

Well… someone else has reported such a thing in the past, but I haven't been able to reproduce this. For me the file type filter lists a lot more options, and it defaults to »all supported file types«. See here:

https://www.bunkus.org/pics/mtx-open-chapters-file-type-filter-windows.png

Same on Linux:

https://www.bunkus.org/pics/mtx-open-chapters-file-type-filter-linux.png

Which operating system are you using? Which version of MKVToolNix GUI? Which translation are you using?

[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]

Hi Mosu. Unfortunately for me this version still has that 10-sec-delay-before-action issue. Do you have any tips as to what can I check/fix or something? Could it be some leftovers from old beta versions that are interfering? Old GUI is lightning-fast as always. Edit: win7 x64, x64 MKVtoolnix

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 (doc.qt.io/qt-5/qsettings.html) 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() (http://doc.qt.io/qt-5/qstandardpaths.html#writableLocation) for QStandardPaths::AppDataLocation). I would also have to migrate the settings from the registry to that location.

[Mosu]

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]

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]

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]

I have upload the registry tree to your ftp.

Thanks, I'll investigate it.

[Mosu]

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]

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 (https://github.com/mbunkus/mkvtoolnix/wiki/Delay-not-shown-in-the-GUI) 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 (https://bugs.archlinux.org/task/45439) issues (https://bugs.archlinux.org/task/44948) 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]

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 (https://github.com/mbunkus/mkvtoolnix/wiki/Delay-not-shown-in-the-GUI) for related information.

Understand. Thanks so much for your time for answer.

[ndjamena]

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


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?


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


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?

[Mosu]

MakeMKV can mux TextST into Matroska. I have experimental patches for mkvmerge enabling the same thing, but there are still some unresolved issues left to tackle, e.g. retrieving the bloody encoding and re-encoding the text to UTF-8 if it isn't UTF-8 already.

[ndjamena]

OK, then.

I'm well aware that most of the time things aren't as easy as they would seem based on a cursory examination. That would be why I haven't mentioned it recently.

I'm more than willing to wait if it means getting the thing done properly. Anticipation of something worthwhile is better than knowledge of that possibility snuffed out.

[Mosu]

Well, I also lack a Blu-ray disc with TextST tracks on it, therefore testing has been extremely limited for the time being. I only have a single .m2ts and the .mkv that MakeMKV has created for them. That's pretty much the reason I've stopped working further on this as extracting the subtitle encoding requires parsing additional files on the disc (the clip info files which mkvmerge doesn't parse at the moment).

So some pointers which Blu-rays contain HDMV text subtitles so that I can obtain one would be appreciated.

Additionally I think Mike from MakeMKV and I weren't in agreement yet about all the details of how to store TextST subs outside of M2TS and Matroska files, and there may also have been some disagreement on the exact layout of CodecPrivate. But I'll have to dig out our email conversation to make sure I remember correctly.

[ndjamena]

I uploaded three entire Blu Ray structures, minus the actual video files, in a zip file to your server a while ago.

http://www.mediafire.com/download/21njtxzejbz2h4m/Blu_Ray_Text_Subtitles.zip

I posted a link to the file on the forum and VLC bug tracker as well. It's been downloaded 56 times already. If there's something wrong with it I really ought to have been told.

Do you need an entire disc with video and all? My ADSL has unlimited download but it's not exactly lightning fast.

[Mosu]

I'm about to go on vacation and will follow up once I'll have returned.

[ndjamena]

Bon voyage!

[ndjamena]

Hi again,
I've chatted with a guy who uses a lot of bd and he says that bd text subs now are much more common than pgs - at least on nordic discs...
I've committed some initial code here (a lot of work left): https://github.com/SubtitleEdit/subtitleedit/commit/830aa1fcb5ff364bb096e05ad8c4c4ddd4cdf91b
Also, do you know how to merge textst into mkv files?


I've told him not yet, I guess we'd need an extraction format first. I'd love to be able to get custom TestST into a m2ts file though.

The discs I have that I know have TextST subtitles in are The Mummy, The Mummy Returns, The Mummy Tomb of the Dragon Emperor and Van Helsing. Apparently there are more around the world.

[Kurtnoise]

Hi Mosu,

May I ask you a new feature about the GUI ? When we click on "Start Muxing" button, the ability to display directly the job output panel...That would be awesome.

Thanks in advance.

[kypec]

Hi Mosu,

May I ask you a new feature about the GUI ? When we click on "Start Muxing" button, the ability to display directly the job output panel...That would be awesome.

Thanks in advance.

+++:goodpost: I second that request. Today I tried new GUI for the first time and was like 'huh? what's going on? did clicking the button worked or not? where's the progress bar & all info about ongoing muxing process?'

[hubblec4]

push!

The output panel I miss too.

[Mosu]

Please file feature requests on Github, otherwise they're likely to be forgotten.

I will definitely not bring back the modal progress dialog. One of the main reasons for rewriting the GUI was to be able to continue working with the program while a mux job is running, and such a modal dialog prevents it.

hubblec4: I don't really know what you mean by "output panel". If you mean the dialog showing the mux progress, the output, warnings and errors reported by mkvmerge then see above.

[bartonnen]

...where's the progress bar...

Bottom right corner of the window.

[kypec]

I will definitely not bring back the modal progress dialog. One of the main reasons for rewriting the GUI was to be able to continue working with the program while a mux job is running, and such a modal dialog prevents it.

No one had mentioned that the dialog should be modal, where did you get that from?
I and probably all other guys are perfectly fine with current muxing dialog as it is (non-modal). It's just that once you click Start button nothing happens visually on the GUI to indicate that muxing had really started. I suppose the best would be to implement checkbox with two options:

Keep current dialog/tab after muxing was started (this is the current GUI behaviour)
Switch to muxer stats dialog/tab immediately after muxing was started (this is what we are missing)

The first option is meant for people who prefer to add jobs in the queue without any interruption.
The second choice is for us, casual muxers who want to get overview of muxing job done straight away after it was executed because we tend to run jobs once in a while only. ;)

[ndjamena]

Apparently I forgot to add most of the m2ts files to the "Mummy" movies in the zip file.

I've added Van Helsing as well.

[73ChargerFan]

Feature Suggestion: When jobs are running in the background, enable an animated icon with text below indicating the job number. If the user clicks on the icon, then a non-modal job status screen opens.

Calibre is a great example. Copying multiple files to my Kindle creates automatic epub to mobi conversion jobs, and a spinning icon indicates that something is going on, and it cycles though labels "Job 1", "Job 2", ..., and finally "Jobs Completed".

[Mosu]

I will not implement additional dialogs, be they modal or not. There is such a functionality, it is the "job output" tool.

I will likely implement an option to switch to the output tool as soon as the user starts muxing, and I only asked for you guys to file a feature request for it on Github. Otherwise chances are high that I will forget about it again as I have a lot of features to implement and bugs to fix.

I will likely extend the number of jobs shown in the status bar somehow, e. g. indicate whether or not one is currently running. In the same spirit clicking on those numbers could cause the GUI to switch to the job queue or the output (depending on where the user clicked). Having a feature request on Github for this would be beneficial for the same reasons stated above.

[Boulder]

Is it possible output the results from mkvalidator to a file (on Windows 7)? I'm trying to check all the Matroska files on my removable hard drive and a file with serious errors will often cause a lot of lines to appear in the console output. This means that the buffer runs out and I cannot see the earlier messages at all even if I've set the buffer size very high.

[sneaker_ger]

mkvalidator.exe input.mkv 2> log.txt

[Boulder]

Seems to work partially, it exports the output but the filename is missing so I don't know which files the errors concern..

[sneaker_ger]

Just echo the filename first:
for %%a in (*.mkv) do (
echo %%a >> log.txt
mkvalidator.exe "%%a" 2>> log.txt
)

[Boulder]

Thanks, works perfectly :)

[kuchikirukia]

Before I go and make an account to ask the Mediainfo guy, I thought I'd ask the mkv experts here.
Mediainfo currently doesn't support showing individual audio/video bitrates when combined in MKV. It does in MP4. Is there a limitation of the MKV container that prevents this information being discovered, or is this a feature that Mediainfo could support?

[sneaker_ger]

To find out such information parsing of the complete Matroska file might be necessary so it can't be done within a few seconds by MediaInfo for every file (there are tricks for good estimates but they only work for specific files). Newer mkvmerge versions write the tracks' bitrates as tags and the MediaInfo author has said he has reading these tags (and other Matroska improvements) on his to-do list. So there is no need to contact him.

[kuchikirukia]

Cool. Thanks!

[hubblec4]

Hi Mosu

Is it possible to add a feature, so that mkvmerge options files can be loaded in the new gui like the mtxcfg.file?

[Mosu]

I'm afraid that's way too difficult to implement. Option files, just like command line arguments, are pretty free in the order they can do things. I also don't see much of a use-case for this (meaning only a very small number of people would actually use such a feature). I have an idea what you would use it for (generating option files instead of .mtxcfg files like you're trying to do at the moment), but to be honest the amount of work would be daunting.

Sorry.

[Boulder]

What do you mean? DTS-HD MA files work just fine.

[P.J]

What do you mean? DTS-HD MA files work just fine.

Yes, the problem was another thing :o

[hubblec4]

I'm afraid that's way too difficult to implement. Option files, just like command line arguments, are pretty free in the order they can do things. I also don't see much of a use-case for this (meaning only a very small number of people would actually use such a feature). I have an idea what you would use it for (generating option files instead of .mtxcfg files like you're trying to do at the moment), but to be honest the amount of work would be daunting.

Sorry.

no problem.
I thought so that it will be too complicated.
Creating a mtxcfg file is done in my chapterEditor(next rev), but for muxing separete mkv-parts(split by timecodes), i can just create such mtxcfg file for the cutting-process when is done.
(scan the mkv-parts with mkvmerge --identify-for-mmg)

Maybe i can create an option and cmd file for the mkv-parts.
mkvmerge: when i use such option file, mkvmerge will scan the mkv-parts automaticly? There are no settings in the option file for --identify-for-mmg(properties).

[Mosu]

File identification is always and automatically done by mkvmerge for each input file. The step with »mkvmerge --identify… yourfile.ext« is separately only so that the GUI can retrieve certain parameters to use (container type, track types, current properties like language, title, track name…).

[hubblec4]

thats sounds good, so i can use the option and cmd file for the separate muxing process.
split option: split by parts based on timecodes works perfect and i need one mtxcfg file only.

[RDF]

I am reporting to have the same problem with Windows 10 (64bit) as HassiD (https://www.bunkus.org/blog/2015/07/mkvtoolnix-v8-2-0-released/#comment-25030). For some reason I am still able to use the old gui version.

I'm liking the new GUI version so far. At first, I hate it but I got used to it very quickly. Please verify this problem in Windows 10 (64bit) when you can. I really want to keep using the new GUI because it's easier to edit chapters with it.

Thanks you.

[Mosu]

Problem is that I don't have Windows 10 yet, nor do I want to upgrade my sole Windows machine to it just yet...

[Chetwood]

And rightfully so: https://i.imgur.com/iHge6RJ.jpg.

Slighty OT as mentioned in the other thread but since you've brought it up...

[Mosu]

@RDF: I've opened an issue for it (https://github.com/mbunkus/mkvtoolnix/issues/1384) and will investigate it, but as I don't have Windows 10 yet (nor an idea what the cause might be) I cannot say when I'll be able to fix it.

[bartonnen]

I am reporting to have the same problem with Windows 10 (64bit) as HassiD (https://www.bunkus.org/blog/2015/07/mkvtoolnix-v8-2-0-released/#comment-25030). For some reason I am still able to use the old gui version.

I know this doesn't help - but I have Windows 10 64bit and the new GUI runs fine for me. Maybe because I just upgraded directly from Win 8.1 and haven't done a clean Win 10 install.

[Mosu]

@RDF: You might give pre-builds 838 or 839 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/) a try. Note that I haven't tried them myself, but they've been built with a newer version of the GUI toolkit library I'm using (Qt 5.5.0 instead of 5.4.2).

[Atak_Snajpera]

Problem is that I don't have Windows 10 yet, nor do I want to upgrade my sole Windows machine to it just yet...

You can test your app on virtual machine. I'm using free Vware player with win10. You can easily download iso from torrent sites. (key/activation is not required for trial mode)

[amayra]

if you add mkv extract this well be great :D :goodpost:

[Mosu]

That is on the TODO list but still a couple of months off.

[ndjamena]

The latest version of Subtitle Edit can export TextST into PES format.

[Mosu]

You can test your app on virtual machine. I'm using free Vware player with win10. You can easily download iso from torrent sites. (key/activation is not required for trial mode)

I've installed both the 32bit and 64bit versions of Windows 10 Professional (you can get ISO images legally directly from Microsoft without a problem, BTW). I've tried both the 32bit and the 64bit version of MKVToolNix. Here are the results:

| | Windows 10 32bit | Windows 10 64bit |
|---------------------------+------------------+------------------|
| 8.2.0 release 32bit | ✓ | ✓ |
| 8.2.0 release 64bit | – | ✓ |
| 8.2.0 current devel 32bit | ✓ | ✓ |
| 8.2.0 current devel 64bit | – | ✓ |


Meaning that for me, at least, all possible combinations run just fine, and I cannot reproduce the issue locally.

[Atak_Snajpera]

(you can get ISO images legally directly from Microsoft without a problem, BTW)
Downloading iso from torrent is just simpler and faster for me.

[Bigmango]

I've installed both the 32bit and 64bit versions of Windows 10 Professional (you can get ISO images legally directly from Microsoft without a problem, BTW). I've tried both the 32bit and the 64bit version of MKVToolNix. Here are the results:

| | Windows 10 32bit | Windows 10 64bit |
|---------------------------+------------------+------------------|
| 8.2.0 release 32bit | ✓ | ✓ |
| 8.2.0 release 64bit | – | ✓ |
| 8.2.0 current devel 32bit | ✓ | ✓ |
| 8.2.0 current devel 64bit | – | ✓ |


Meaning that for me, at least, all possible combinations run just fine, and I cannot reproduce the issue locally.
Version 8.2 is also working fine here on windows 10 x64 clean install.

[Mosu]

RDF just posted on Github (https://github.com/mbunkus/mkvtoolnix/issues/1384#issuecomment-129027824) that it seems to be a permission problem on the MKVToolNix installation folder caused by the upgrade to Windows 10.

[KoD]

Hi mosu, I've noticed a little user interface issue with the mkvmerge GUI on Ubuntu. It seems like each time a window or dialog is opened, its size is increased over what it was when the window/dialog was last closed. The easiest way to observe this is to start a mux, let it finish and then close the dialog, then start a mux again - now, the dialog that opens is not only moved to a different position (which is somewhat annoying, but not the real issue here) but it's also larger than it was when closing it. This can also be seen with the mkvmerge GUI window itself. After several muxes, the dialog that shows is so big that it's larger than the display area. And this behavior seems to persist after closing mkvmerge and opening it again.

In case it matters, this is on Ubuntu 14.04 Desktop, with the default Unity window manager, and using the 64 bit build of mkvmerge from your apt repository.

[Mosu]

The mkvmerge GUI is not supported anymore and will be removed in release 8.4.0. Please switch to the MKVToolNix GUI.

[KoD]

Ah, ok!

Just tried it now, and there is a problem with the tab titles in the new GUI though:
http://s9.postimg.org/y0kyp07bf/tabs_issue.jpg (http://postimg.org/image/y0kyp07bf/)

[Mosu]

That's a known issue on Linux with certain window managers that's been fixed since the release already. You can compile your own package (https://www.bunkus.org/videotools/mkvtoolnix/source.html#debian_ubuntu_package) for the current development sources, if you want.

[v0lt]

@Mosu
mkvmerge packs TrueHD streams in blocks of 1 ms. I think it is wrong. Standard size TrueHD unit is 50 ms.

sample (https://yadi.sk/i/9yOzspEOiRZsJ)

[Mosu]

No, that's not wrong. Each packet really contains only that few samples.

TrueHD has two types of headers: full ones including a sync word and those small ones that basically consist of the packet's data size only, but nothing more. I've tried to pack them together (one sync frame and all following non-sync frames) into a single Matroska block in the past. That was a monumental failure; no player could play such packed frames properly.

[v0lt]

The problem is that 0.83ms is very small. In addition to send TrueHD HDMI in, we have to group the packages of 24 pieces (20ms).

[nevcairiel]

The problem is that 0.83ms is very small. In addition to send TrueHD HDMI in, we have to group the packages of 24 pieces (20ms).

You have to do that anyway, as you get TrueHD out of BD m2ts this way, so getting it the same way out of all containers is actually a good thing.

[Mosu]

nevcairiel made my point much better than I did. All containers actually packetize TrueHD in such small frames, especially MPEG transport streams.

How certain special outputs require their packets formatted should be of no concern to a container format. Converting from storage to the actual format required for playback is the demuxer's job (additional filters and other processing might be required as well).

[Mosu]

Hey,

I've released MKVToolNix v8.3.0. Even if I'm starting to sound like a broken record: this release implements a lot of enhancements and new features for MKVToolNix GUI, pretty much all of them requested by users. Several bugs in the GUI have been fixed as well.

This is the last release that includes the old GUI (mkvmerge GUI).

Changes for package maintainers: nothing's changed since v8.2.0.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-08-15 Moritz Bunkus <moritz@bunkus.org>
* Released v8.3.0.
* MKVToolNix GUI: chapter editor enhancement: pressing return will cause the next appropriate chapter control to be selected depending on where the focus currently is: from a chapter input to the first chapter name, from a chapter name to the next chapter name and from the last chapter name to the next chapter entry's start time. Implements #1358 (https://github.com/mbunkus/mkvtoolnix/issues/1358).

2015-08-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: the number of running jobs is shown in the status bar. Implements #1381 (https://github.com/mbunkus/mkvtoolnix/issues/1381).
* MKVToolNix GUI: new job queue feature: added a context menu for force-starting selected jobs. This allows for running more than one job at the same time. Implements #1395 (https://github.com/mbunkus/mkvtoolnix/issues/1395).
* MKVToolNix GUI: new merge tool feature: added an option for automatically setting the »default track« flag to »no« for all subtitle tracks when they're added. Implements #1339 (https://github.com/mbunkus/mkvtoolnix/issues/1339).

2015-08-12 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: dragging & dropping files onto line edit controls that expect file names (e.g. the »chapter file« control) will set that line edit's text to the dropped file name. Implements #1344 (https://github.com/mbunkus/mkvtoolnix/issues/1344).
* mkvmerge: bug fix: track statistics tags can be kept with the option »--engage keep_track_statistics_tags«. This allows outputting them in verbose identification mode for easier parsing. Fixes #1351 (https://github.com/mbunkus/mkvtoolnix/issues/1351).

2015-08-11 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: jobs in the queue can now be edited again. For that they're re-opened in the corresponding tool and removed from the queue. Implements #1296 (https://github.com/mbunkus/mkvtoolnix/issues/1296).
* build system: stack protection is enabled when building with gcc on all platforms. For Windows DEP and ASLR is enabled. Implements #1370 (https://github.com/mbunkus/mkvtoolnix/issues/1370).

2015-08-09 Moritz Bunkus <moritz@bunkus.org>
* build system: the Boost detection macros were updated from www.gnu.org resulting in better compatibility with bare-bones shells like dash.
* MKVToolNix GUI: enhancement: the format of the setting and queue files has been changed from INI style to JSON documents. Reading older setting files in INI style remains supported, but saving will convert them to JSON. Together with the other three changes mentioned below this results in a noticeable reduction in the time needed for writing the queue files, e.g. when pressing »start muxing« or when quitting the application.
* MKVToolNix GUI: enhancement: the way the job queue is stored has been changed. Earlier all jobs were stored in the same file (or registry on Windows) as the preferences. Now they're stored in a sub directory called »jobQueue« with one file per queue entry.
* MKVToolNix GUI: enhancement: on Windows the preferences are not stored in the registry anymore, not even if the application has been installed. Instead they're stored in an INI file in the user's AppData\Local directory tree.
* MKVToolNix GUI: enhancement: the number of times the queue files are saved has been reduced. The queue files are also loaded only once on startup, not twice.
* MKVToolNix GUI: bug fix: fixed various crashes when dragging & dropping in all of the tree views (merge tool: files view, tracks view, attachments view; chapter editor: edition/chapter tree, chapter name list; job queue). Fixes #1365 (https://github.com/mbunkus/mkvtoolnix/issues/1365).

2015-08-08 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: if an instance is already running when the application is started a second time then the GUI requests that the already-running instance will be activated. Implements #1379 (https://github.com/mbunkus/mkvtoolnix/issues/1379).
* MKVToolNix GUI: new feature: added an option in the preferences for automatically switching to the job output tool whenever the user starts a job (e.g. by pressing »start muxing«). Implements #1376 (https://github.com/mbunkus/mkvtoolnix/issues/1376).
* MKVToolNix GUI: new job output and job queue feature: added a function for opening the output folder. Implements #1342 (https://github.com/mbunkus/mkvtoolnix/issues/1342).
* MKVToolNix GUI: new job output tool feature: added a way to clear the output, warnings and errors views. Implements #1356 (https://github.com/mbunkus/mkvtoolnix/issues/1356).
* MKVToolNix GUI: merge tool bug fix: attachments: sometimes changing values didn't apply the changes to all selected attachments depending on how they were selected. Fixes #1373 (https://github.com/mbunkus/mkvtoolnix/issues/1373).
* MKVToolNix GUI: merge tool bug fix: the automatically suggested description for new jobs contained the file name twice, even in the directory portion. Fixes #1378 (https://github.com/mbunkus/mkvtoolnix/issues/1378).
* MKVToolNix GUI: merge tool bug fix: if »set output file name automatically« is enabled then file names ending with a number in parenthesis (e.g. »Berlin (1962).mkv«) will keep their number in the generated output file name. Fixes #1375 (https://github.com/mbunkus/mkvtoolnix/issues/1375).
* MKVToolNix GUI: merge tool bug fix: the GUI will keep manual changes to the output file name even if »set output file name automatically« is enabled. Fixes #1372 (https://github.com/mbunkus/mkvtoolnix/issues/1372).
* MKVToolNix GUI: bug fix: fixed the stereoscopy drop down box not being re-translated when the GUI language is changed. Fixes #1224 (https://github.com/mbunkus/mkvtoolnix/issues/1224).

2015-07-22 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor bug fix: it was possible to drop chapter entries on the top-level reserved for editions. Fixes #1369 (https://github.com/mbunkus/mkvtoolnix/issues/1369).

2015-07-21 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: Windows: if the application has been installed then its settings will no longer be saved in the registry but in an INI file in the user's data application folder (e.g. C:\Users\mbunkus\AppData\Local\bunkus.org\mkvtoolnix-gui).

2015-07-20 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: added »Simple OGM-style chapter files (*.txt)« to the file selection dialog when selecting a chapter file. Implements #1269 (https://github.com/mbunkus/mkvtoolnix/issues/1269).

2015-07-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed compilation when building without curl support. Fixes #1359 (https://github.com/mbunkus/mkvtoolnix/issues/1359).

Have fun.

[hubblec4]

many thanks mosu

the gui start/close very quickly.

There are any changes in the mtxcfg?

[Mosu]

Yes. I've implemented several changes to how the GUI stores its configuration and its job queue. Those are four of the commits listed for 2015-08-09.

The new format is JSON, BTW. The structure itself is the same (meaning the groups and keys have retained their names and the values should be encoded in roughly the same manner they had been encoded before – safe for how escaping is done in JSON vs. that INI format, of course).

In order to save space the GUI writes compact JSON, but you can force it to write properly indented JSON by having the environment variable MTX_JSON_FORMAT set to »indented« before starting the GUI. That can be useful if you want to analyze the format. Or you could just run the content through any JSON pretty printer out there.

Note that the GUI can still read the old config file format. It will continue to support reading both formats for the foreseeable future as I currently don't have any plans for dropping support for that INI format. The GUI will not write that INI format anymore, though (only for the preferences, but those are small enough not to matter too much regarding the performance).

[Mosu]

Apart from the format changes there has been one addition: the key destinationAuto. It's set by the GUI to the automatically generated output file name (if that feature is activated) so that the GUI can determine whether or not the user has changed the output file name manually. If (s)he has then the GUI will not touch the output file name anymore.

[mastrboy]

Just wanted to thank you for another update.

Considering this is the only useable muxing/demuxing software for mkv and that you have been doing pretty much everything by yourself for years is quite impressive.

Github lists 49 contributors, so also a thanks to them :)

[Sparktank]

Just wanted to thank you for another update.

Github lists 49 contributors, so also a thanks to them :)

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

[rsotome]

So far, a great deal of nice improvements to the new GUI, especially storing each job in a separate file, thank you for all your hard work. :)

I do have 2 questions about the .mtxcfg format & jobQueue.

-Is it possible to generate better filenames in the jobQueue, instead of what seems like a mix of random letters & numbers?
-Will it ever be just as easy to mass edit .mtxcfg files as it is the older .mmg files with a text editor (eg. Notepad++) ?

The .mtxcfg is hard to make heads or tails out of, and mass editing 20+ TV series jobs is still much easier with the .mmg format.

Hopefully I didn't put a damper on your new release, since it's really starting to take shape. :)

[Mosu]

Hey,

So far, a great deal of nice improvements to the new GUI, especially storing each job in a separate file, thank you for all your hard work. :)

You (and the others who thanked me) are quite welcome :)

I do have 2 questions about the .mtxcfg format & jobQueue.

-Is it possible to generate better filenames in the jobQueue, instead of what seems like a mix of random letters & numbers?

Those are GUIDs (Globally Unique Identifiers) (https://en.wikipedia.org/wiki/Globally_unique_identifier). They're used by the GUI in order to ensure that each job file has a unique name. This also facilitates copying those job files to another installation without clashing with any existing job queue file on that installation, be it on the same computer or on other computers.

I don't have any plans on changing that schema as I don't see a compelling reason. If you want to manually add your own jobs to the queue without the GUI and you're worried about having to name the files in a similar way: don't be. The GUI should pick up all files in the jobQueue directory whose extension is ».mtxcfg« and assign a GUID automatically.

Knowing that do you still want the GUI to use different a file naming scheme? If so what are the reasons?

-Will it ever be just as easy to mass edit .mtxcfg files as it is the older .mmg files with a text editor (eg. Notepad++) ?

Like I've said above in a reply to hubblec4: the GUI uses JSON for writing .mtxcfg files now. If you want to edit those files manually make sure the environment variable »MTX_JSON_FORMAT« is set to »indented«. That way they'll even look nice.

I consider JSON to be a good choice. There are bindings for parsing and writing JSON available in pretty much each and every programming language. Modifying those files should be very, very easy.

The .mtxcfg is hard to make heads or tails out of, and mass editing 20+ TV series jobs is still much easier with the .mmg format.

You already know the .mmg format, you don't know the .mtxcfg format yet. Of course .mmg is easier for you under those circumstances. Why don't you just ask about the points in .mtxcfg that you don't understand? I'm happy to explain the meaning of those things, you know ;)

The internal format won't change, sorry, you should get used to it if you want to fiddle around with it.

hubblec4 generates his own .mtxcfgs, too. Here are a couple of points I've explained to him a while ago:

It's UTF-8 encoded JSON. The same JSON used everywhere else.
There's one important distinction between .mtxcfg saved from the merge tool and the .mtxcfg used in the jobQueue. The files in the jobQueue contain more information on the top level, and the merge configuration is nested one level down in the »muxConfig« key. Think of structures/classes in a programming language. There's a class called »MuxConfig« and one called »Job«. »Job« contains a member of type »MuxConfig«, and that's how they're stored in the jobQueue. Manually-saved .mtxcfg files from the merge tool, however, only contain the »MuxConfig« instance and aren't wrapped in an instance of »Job«.
objectId is just a numeric value uniquely identifying each object within the file. The GUI uses memory addresses, but you could just as well use serial numbers.
properties are the key/value pairs output by »mkvmerge --identify-for-mmg«. Note that mkvmerge escapes certain characters (https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.escaping), and that escaping has already been undone when the values are stored in the .mtxcfg.
The »type« member for a track is the numeric track type. See this list (https://github.com/mbunkus/mkvtoolnix/blob/master/src/mkvtoolnix-gui/merge/track.h#L23): audio equals 0, all following are numbered sequentially.
Tye »type« member for containers is the numeric container type. See this list (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/file_types.h#L31): unkown equals 0, all following are numbered sequentially.

[hubblec4]

-Will it ever be just as easy to mass edit .mtxcfg files as it is the older .mmg files with a text editor (eg. Notepad++) ?

The .mtxcfg is hard to make heads or tails out of, and mass editing 20+ TV series jobs is still much easier with the .mmg format.

I can feel with you, in the past i have do the same.
Create one mmg manually, and all other episodes by copy/paste(replace) the paths in the mmg.



@Mosu

puuhhh the new format JSON looks like not so well for me.
There is only one line in the mtxcfg.
But the old mtxcfg will supported in future? So I can use this?

[hubblec4]

The new JSON mtxcfg seems to be easier.
When path's contains "ä , ö , ü ..etc" the format will not changed like in the old mtxcfg (ä = \xe4). Now its very easy to change mass mtxcfg's with an editor.

I will change to JSON too.

[Mosu]

Like I said: set that environment variable and the GUI will write nicely formatted JSON. It can always read both the compact and the indented variants.

[AYColumbia]

Mosu, any estimate on when the command line stuff will be complete in the new UI? Also, I noticed the current Windows cmd.exe is escaping the double quotes, i.e., ^" but they don't need to be escaped, however, the parans do, i.e., ^( and ^). Thank you.

BTW, I copied the current command line and tried to run it manually and received an error. Obviously if CLI not ready you can ignore this. ;)
"mkvmerge.exe" "--output" "title.mkv" "--language" "0:und" ( "sourceTitle.mkv" ) "--language" "0:und"
( "sourceTitle.ac3" ) "--language" "0:und" ( "sourceTitle.sup" ) "--chapters" "sourceTitle_chapters.txt"
"--engage" "no_cue_duration" "--engage" "no_cue_relative_position" "--track-order" "0:0,1:0,2:0")
mkvmerge v8.3.0 ('Over the Horizon') 64bit
Error: '0)' is not a valid file ID in '--track-order 0:0,1:0,2:0)'.

[Mosu]

The command line handling is ready: Merge → Show command line. The quoting is intentional. It may look ugly, but it actually is the only proper way to escape for cmd.exe.

What you think you know about escaping for cmd.exe is most likely incorrect or at least incomplete. See this informative but frightening (http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx) blog post from a Microsoft employee.

BTW: I'm sorry to say but cmd.exe stinks. Especially if one is used to sane shells like zsh or bash.

And what do you mean – you »copied the current command line«? You definitely copied one closing parenthesis too much, I have no idea where you got that one from.

[AYColumbia]

I copied the command line string from the UI from the same location you mention, i.e., Merge > Show command line. I didn't notice that it had an extra paran on the end so good catch.

Regarding the escaping, yes, I just realized that it's fine the way it is since it's meant to be copied and executed on the command line directly as opposed to be consumed by a script/batch file. I was looking at it from a command file script perspective which is not correct here.

I don't use zsh or bash. Just basic Windows CLI to batch process stuff. I'm sure you're passionate about not liking CLI but please don't be condescending towards those of us that still use it. Speaking for myself, the reason I still use it, is the lack of a UI to accomplish what I need for each situation whether it's re-encoding, re-muxing or what have you.

[Mosu]

Not liking the CLI? Geez, you misunderstood me completely :) I love the command line! But cmd.exe is simply not a good shell. zsh and bash are: way more powerful, much saner… That's all I wanted to say.

What you've pasted above doesn't look like the new GUI's version of a command line escaped for cli.exe but for Linux shells. You should not use that escaping with cmd.exe, instead switch to the cmd.exe escaping mechanism. And if you're still using mmg.exe for generating command lines: please use the new GUI instead. mmg.exe's command lines are not correct for cmd.exe in certain situations (e.g. if quotation marks are involved).

[sneaker_ger]

This is intended?
http://abload.de/img/mkvtoolnixgui_830_cnd45r31.png

[Mosu]

Like I've said above (http://forum.doom9.org/showthread.php?p=1734612#post1734612): yes.

[sneaker_ger]

Quoting the path to mkvmerge.exe in this manner does not work here. It stops at the first space in the path. (c:/program not found)

[Mosu]

That's interesting. I'll have to look into it.

[Boulder]

Probably because there's a slash instead of a backslash (Windows paths..)

[Mosu]

Like I said: cmd.exe and command line parsing on Windows is completely bonkers.

Looks like cmd.exe uses different rules for escaping the initial argument than the MS Visual C libraries use for all remaining arguments. The joy!

I'll have to fix that and will open an issue for it in the meantime. Note that only the escaping of the very first argument (the path to mkvmerge.exe) has to be changed – the other arguments are escaped correctly.

[Mosu]

No, backslashes vs. slashes is not what's wrong here. cmd.exe doesn't interpret ^" the way that CommandLineToArgvW() does. If you just use "C:/Program Files/MKVToolNix/mkvmerge.exe" and leave the rest as it is then it does work. Windows does support forward slashes just fine.

[Boulder]

Windows does support forward slashes just fine.Whoa..you definitely learn something new each day. That one just removed one almost 30-year-old piece of knowledge off my head :)

[Mosu]

The cmd.exe escaping snafu has been fixed in pre-builds 867/868 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/).

[AYColumbia]

Not liking the CLI? Geez, you misunderstood me completely :) I love the command line! But cmd.exe is simply not a good shell. zsh and bash are: way more powerful, much saner… That's all I wanted to say.

All good. :) Sorry for the misunderstanding on my part. It just came across as harsh rather than sarcastic is all.

What you've pasted above doesn't look like the new GUI's version of a command line escaped for cli.exe but for Linux shells. You should not use that escaping with cmd.exe, instead switch to the cmd.exe escaping mechanism. And if you're still using mmg.exe for generating command lines: please use the new GUI instead. mmg.exe's command lines are not correct for cmd.exe in certain situations (e.g. if quotation marks are involved).
You're correct. I had to remove the ^" because am running in a Windows cmd.exe (already addressed by earlier posts by others so won't delve further). I saw you had a fix build already in the latest post. Many thanks for jumping on this so quickly. Very much appreciated. :)

BTW, I have switched over to the new GUI which is how I ran into the escaping thingy. ;) It's taking some getting used to but I like it.

[ShadyCrab]

Whenever I select a video file in the new GUI (8.3.0 and current nightly 64 bit, both through the Installer) an error pops up saying 'the mkvmerge executable was not found'. I went to task manager, opened the file location and its definitely launching from the same folder as mkvmerge.exe. I deleted the bunkus.org AppData folder, didn't help. Portable edition works, but installer will not. Tried reinstalling 4 times, even deleting old regedit data (though the new one doesn't use it, just to be sure).

[Mosu]

@ShadyCrab: I cannot reproduce such issues, and I haven't received similar reports either. Therefore I guess it's something on your end. Maybe incorrect folder/file permissions after the installation? Both the installed and the portable version use the very same code for finding and executing mkvmerge.exe. They only differ on where they store their settings.

[noee]

Mosu:
First, thanks for the great tool - indispensable, it is.

Build question: I've got a openSUSE TW box that use for dev work (latest QT5, KF5, Plasma5, etc.) and I have to change to -fPIC in the "makefile" after config or it complains at the kax_qt step. Is this expected? I'm building x86_64.

[Mosu]

You mean you have to change -fPIE to -fPIC? Or what do you have to change, exactly?

If so I'm somewhat surprised. I don't build on Tumbleweed myself, but I do build on 13.1 and 13.2, and neither requires such changes. Additionally I also compile with the latest Qt 5 (MKVToolNix has nothing to do with KDE so those libraries don't count) and the latest gcc (5.1.0) on Arch Linux, and I don't need any such changes for those either.

So no, this isn't expected.

[noee]

Yeah, exactly, I changed -fPIE to -fPIC. It might be the way the KDE team at openSUSE builds QT, IDK. Either way, it works and the mkvtoolnix tools seem to work as expected. TW has a later version of boost, so the repos using the OBS only have mkvtoolnix up to 7.9. Also, TW is up to gcc 5.1.1, fwiw.

[Mosu]

Huh, interesting. I don't have any preference regarding using -fPIE instead of -fPIC. I only do because created a pull request (https://github.com/mbunkus/mkvtoolnix/pull/1361) for it and judging from the compiler's documentation it sounded sensible. I think I'll revert it as it obviously causes problems.

[bartonnen]

(version 8.3.0)
I added a bunch of jobs to the queue today, switched to the job queue tab and pressed Ctrl-R to start the queue. The jobs started one by one as expected and they all completed successfully - but I noticed that the right-hand "total progress" bar kept resetting to 0% as each job completed, instead of just continuing to increase.

[Mosu]

Thanks for the report. Hmm, I cannot reproduce such behavior. For me the left of the two progress bar resets to 0% as soon as a job starts, the right one never resets as long as the queue is running. I've tried this with five jobs.

If you can give me a list of all the exact steps you've taken and if you can reproduce the issue then I'll look into this some more.

[bartonnen]

I did have two failed jobs from a previous day still at the top of the list, perhaps they affected it.

[bartonnen]

OK - I figured out the issue - it's because I have "Remove job from queue after completion" checked, it must be getting removed from the calculation as well.

[Mosu]

(oops, I misread your comment)

Yes, removing jobs affects the total, and therefore the total will always reset to 0 as the completed jobs are taken out of play almost immediately.

This is somewhat surprising for users, I guess… I'll have to look into how to fix this properly.

[Mosu]

I've opened issue 1405 (https://github.com/mbunkus/mkvtoolnix/issues/1405) for this.

[Boulder]

I just noticed a small annoyance with the job queue: mark all jobs to "start automatically", it also runs the jobs that were already finished. After that, it's not very straightforward how to abort the jobs : you have to mark them to "start manually" and then abort the current job. Maybe the commands could be a bit more descriptive?

[Mosu]

You could have chosen »stop the job queue« from the »job queue« menu. The context menu is used for manipulating one or more jobs, the »job queue« menu is used for manipulating the whole queue/the process, basically things that are independent of the currently selected jobs.

[Boulder]

Gah, missed that one :( I tried nearly every other place but couldn't find a way to stop the queue..

Is it possible to start the selected pending jobs or will the option run all of them?

[Mosu]

About job statuses and the various actions.

(A) Status and context menu action »Start automatically«

Any job entered into the queue with status »start automatically« will be started automatically, but at most one job will be running simultaneously. This means if the queue is currently not running then the newly-added job will be started immediately. Otherwise it will be enqueued and run after all the other jobs in the queue with status »start automatically« have been completed.

Jobs will only have a status of »start automatically« if you either submit them from the merge tool with »start muxing« or if you select »start jobs automatically« from the context menu in the job queue tool.

(B) Status and context menu action »Start manually«

Jobs marked as »start manually« will remain in the queue but won't be started unless you, the user, tells the program to do just that. There are two ways for accomplishing this:

Select a couple of jobs in the job queue tool, open the context menu and choose »start jobs automatically«. This will set their status to »start automatically« and they'll be processed as laid out in (A).
Go to the job queue tool, open the »job queue« menu and select »start all pending jobs«. This changes the status of all jobs whose current status is »start manually« to »start automatically«. Then they're processed as laid out in (A).

(C) Context menu action »Start immediately«

This is not a job status per se, but it is an action available in the job queue's context menu. This starts the selected jobs immediately, no matter if there's a job running already. This allows the number of simultaneously running jobs to exceed 1.

Note that as long as at least one job is running no other jobs marked »start automatically« will be started. For example, if you have three jobs in the queue, one currently running, and two set to »stat automatically«. Now you select one of those two marked as »start automatically« and select »start jobs immediately«. This changes the queue to two jobs running, one job still in »start automatically«. Now when one of those running jobs finishes the programm will not start that other job that's still set to »start automatically« as it still has one job running. Only after that second runnig job has finished will the final pending job be started.

(D) Job queue menu action »Start all pending jobs«

This is described in section (B).

(E) Job queue menu actions »Stop job queue«

Choosing one of those two options in the »stop job queue« sub-menu causes all jobs set to »start automatically« to be changed to »start manually«. That way they won't get executed by the GUI unless you tell it to; see (B).

The difference between the two available options is how a potentially running job is handled. In case of »abort current job and stop immediately« the currently running job will be aborted, otherwise it will be left running. Note that aborthing the job will leave it in state »aborted by user«; it won't be re-started unless you tell the program so (via one of the the »start jobs …« context menu actions).

I will put this explanation into a Wiki/FAQ entry as well; it will probably be needed again.

[Mosu]

So if you mean »start only those jobs that I have currently selected AND whose current status us 'start manually'« then no, that's not possible. Either shrink your selection to the jobs you want to start and use the »start jobs automatically« context menu entry (which disregards the job's current status unless it's running) or select »start all pending jobs« from the »job queue« menu which will not pay any heed to the selection and act on all jobs in the queue with status »start manually«.

[Boulder]

So if you mean »start only those jobs that I have currently selected AND whose current status us 'start manually'« then no, that's not possible. Either shrink your selection to the jobs you want to start and use the »start jobs automatically« context menu entry (which disregards the job's current status unless it's running) or select »start all pending jobs« from the »job queue« menu which will not pay any heed to the selection and act on all jobs in the queue with status »start manually«.Thanks for the thorough explanation :)

OK, will use the "start jobs automatically" operation in such cases. Fortunately I rarely need to do that, sometimes I just have the need to remux a few files in case a new subtitle track is included.

[Mosu]

OK - I figured out the issue - it's because I have "Remove job from queue after completion" checked, it must be getting removed from the calculation as well.

This bug should be fixed now. Pre-builds 876, 877 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/) include the fix.

[bartonnen]

This bug should be fixed now. Pre-builds 876, 877 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/) include the fix.

Thanks :)

[73ChargerFan]

New Windows 7 SP1 install, v 8.3.0, new GUI (which I really like, thanks.)

1. Minor bug: in Preferences-Merging-Output file name I have set "Automatically set" and "Previously used output directory". But on every job I create, the automatic output file name is always Drive E, which isn't even in my computer.

2. After getting 2 jobs entered, I select "start automatically". Then while they're working, I create new jobs and add them to the queue, but they get flagged "waiting to start manually". I'd be nice to have a setting so that enqueued jobs always start automatically.

3. Feature Request (as if you had time): Ask madshi for his eac3to code for dealing with HD-DVD files, which can determine languages and extract chapters. I've got almost 300 such disks to finally convert... Maybe it is easy? I'll add this to your tracker.

4. Comment: Windows paths use \ not the / that Linux does. Looks confusing, but I can deal. Perhaps this is a compile time setting in the GUI library?

The new GUI really is nice, and the progress indicators are well placed.

[Mosu]

1. Sounds like a bug. I'll have to investigate.
2. No, because there's such functionality already: »start muxing«. »Add to job queue« will always add them with status »start manually« and »start muxing« will always add them with status »start automatically«. See this explanation of how the queue works (https://github.com/mbunkus/mkvtoolnix/wiki/The-job-queue,-statuses-and-their-actions).
3. I won't spend any time on the outdated and abandoned technology HD-DVD. Sorry.
4. Windows can handle both / and \ in paths just fine. Therefore I haven't bothered to adjust the code to make sure that the usual path separator is used everywhere. It's not just a compile time switch, it's code changes in every place a path is output for the user to see. As Windows has no problems with / in paths I won't spend any time on this any time soon either.

[Mosu]

About the output directory setting: I can reproduce such behavior, but only if I edit the output name manually. If, however, I use the »browse« functionality next to it then the new location is remembered just as I expect it to be. I'll fix the handling of manual changes to the output file name.

[Jamaika]

Can I save the image as the first frame of the container matroska? Is there a hidden function?
http://i61.tinypic.com/xlfbee.jpg
Can I import and cut a timestamp for Sony XAVC NonRealTimeMeta?
Media Info: Language "und (und)" - Type "meta:rtmd" - 240 samples
Unknown Metadata Stream
RFC6381 Codec Parameters: rtmd
All samples are sync

[Mosu]

Uhm… What now? I'm sorry, but I completely fail to understand your questions.

[Mosu]

No to the first question. As for the second question: if you could embed such data in Matroska I'm certain your Sony couldn't read them. No as well here.

[Jamaika]

Thanks for your reply. All understandable. More and more is the Sony camcorder in the world so think that the theme is coming back for some time.;)
https://www.youtube.com/watch?v=ZpWI-7DAC4s

[KoD]

Hi Mosu, I'm either doing something wrong, or I discovered an issue in the mkvtoolnix GUI chapter editor. After loading a chapter file, selecting "Additional modifications -> Shift start and end timecodes by the following amount" on a chapter entry in the editor, does not seem to do anything.

For example, loading a txt file with this content in the chapter editor, and then trying to shift the first chapter by "-00:01:41.518" or "00:01:41.518" does nothing, the chapter start and end timestamps in the editor remain unchanged:
CHAPTER01=00:00:00.000
CHAPTER01NAME=Chapter 01
CHAPTER02=00:01:41.518
CHAPTER02NAME=Chapter 02
CHAPTER03=00:08:50.905
CHAPTER03NAME=Chapter 03
CHAPTER04=00:11:49.291
CHAPTER04NAME=Chapter 04
CHAPTER05=00:20:46.203

PS: multi-selection of chapter entries, to be able to shift them all at the same time would be much appreciated too! :)

[Mosu]

All those modifications only work on the children of the selected node. Shifting only a single chapter entry is therefore not possible.

Having multi-selection enabled for chapters is not currently on my TODO list as it's quite a lot of work to get right.

Sorry.

[KoD]

Ok, I understand.

Is it supposed to work on the root "Edition" entry in the chapter editor, too? Because it did not work on it either, the child chapters were not shifted.

[Mosu]

Huh… You're right, it doesn't work at the moment. That's obviously a bug. I'll fix it.

[KoD]

That's great! Thanks! :)

[Mosu]

Should be fixed in pre-builds 884 & 885 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/). I'd appreciate some testing.

Yes, it's supposed to work on the edition, too (well, it doesn't change the edition but its direct children, of course).

And thanks for the report. I know exactly when this got broken: back in April even before release 7.9.0. Seems you're the first user to actually give this function a try :)

[KoD]

Just tried build 885 on Windows, and it seems to work ok for me. :)

As a suggestion, maybe it makes sense to change the description of the feature from "Shift start and end timecodes by the following amount" to "Shift start and end timecodes of child chapters by the following amount". It might help those that misunderstand the feature, like I did.

[Mosu]

The very first line in that dialog already states what the actions apply to. So no, I don't want to add the same verbiage to each of those options.

However, it shows that I remembered incorrectly: the shifting is indeed applied to the selected element, too, not just to its children.

[Bigmango]

There's a bug in the header editor in version 8.3 (probably the same happens when loading a file in the muxer):

A track (audio, subtitles, video) with language "fra" is not detected as French.

When clicking on "save" in the header editor, all tracks with language "fra" are changed automatically to "und" undetermined.

To avoid this, all tracks must be changed manually to "fre", otherwise the language information is lost after saving.

This didn't happen with the old gui.

FYI, all the french tracks written with Makemkv for my bluray backups have "fra" for French, so this is rather annoying.

Thanks in advance for fixing this.

[sneaker_ger]

It's a feature of the old header editor to work around bugs like the one in makemkv. I suggest you also report the problem to them.
http://www.matroska.org/technical/specs/index.html#languages

[Mosu]

Thanks for reporting this. I'll implement a similar fix for the new header editor.

The correct code to use is indeed »fre« and not »fra«. Matroska uses the bibliographic ISO 639-2 codes (»fre«; also called ISO 639-2/B), not the terminology ones (»fra«). This goes back to when Matroska started; I think at that time the terminology ones weren't favored yet – or something like that.

[Bigmango]

It's a feature of the old header editor to work around bugs like the one in makemkv. I suggest you also report the problem to them.
http://www.matroska.org/technical/specs/index.html#languages

According to the matroska specs (the link you posted), mkv uses ISO-639-2.

fre and fra are both correct according to ISO-639-2.

So, this is indeed a bug of the new gui and has nothing to do with makemkv.

[sneaker_ger]

"fra" is terminology ISO 639-2 but Matroska requires bibliographic ISO 639-2. Both the spec I posted as well as Mosu's post have correctly explained this. If MakeMKV writes "fra" it is a bug.

[Bigmango]

Thanks for reporting this. I'll implement a similar fix for the new header editor.

Thanks.


The correct code to use is indeed »fre« and not »fra«. Matroska uses the bibliographic ISO 639-2 codes (»fre«; also called ISO 639-2/B), not the terminology ones (»fra«). This goes back to when Matroska started; I think at that time the terminology ones weren't favored yet – or something like that.

"fra" is also used by bluray, I guess this is why makemkv is using it.

According to wikipedia "In practice, ISO 639-2 has largely been superseded by ISO 639-3 (2007)", and 639-3 uses only "fra" and not both as ISO 639-2.

This means, if only should be used it should be "fra", so this is a problem with the matroska spec that is not compliant with the standard used today.

Fortunately this never was a problem since all the players are using both.

So yes, mkvtoolnix also using both as you are proposing seems to be the best (or perhaps if you want to 100% stick to the mkv spec, you could automatically convert fra to fre instead of removing the tag as it is now).

Thanks.

[Mosu]

Automatic conversion from fra to fre is what mkvmerge already does. The thing about standards is that you cannot change them willy nilly. This applies to the Matroska specs, too. Like I said we started out with the bibliographic forms of 639-2, and simply changing over to the terminology ones would either invalidate existing files or make players that only support the bibliographic ones seem suddenly buggy – although they've been perfectly compliant with the specs in the past.

If we ever do something about the codes then we will likely introduce a new element that'll use 639-3 to be used alongside with the older 639-2/B elements. For improved backwards compatibility both elements would have to be used at the same time.

[Bigmango]

Automatic conversion from fra to fre is what mkvmerge already does. The thing about standards is that you cannot change them willy nilly. This applies to the Matroska specs, too. Like I said we started out with the bibliographic forms of 639-2, and simply changing over to the terminology ones would either invalidate existing files or make players that only support the bibliographic ones seem suddenly buggy – although they've been perfectly compliant with the specs in the past.

If we ever do something about the codes then we will likely introduce a new element that'll use 639-3 to be used alongside with the older 639-2/B elements. For improved backwards compatibility both elements would have to be used at the same time.

Absolutely, I hear you 100% on this.

It's also 100% fine with me if it converts fra to fre.

But regarding what you say "Automatic conversion from fra to fre is what mkvmerge already does" :

the new gui (header editor) currently removes the "fra" tag so the language information is lost as my tracks are left with "und" undeterminded...

Thanks.

[Mosu]

I was talking about mkvmerge specifically. The GUI is not mkvmerge :) The GUI will be fixed to do the same automatic conversion.

[Bigmango]

I was talking about mkvmerge specifically. The GUI is not mkvmerge :) The GUI will be fixed to do the same automatic conversion.

Many thanks.

[Mosu]

The feature has been implemented in the latest pre-builds (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/) (888, 889).

[FreaQ]

Hi Mosu,

I have a question:

Is there any way to find out if a .mkv has had "header compression" enabled during muxing?
I would need to remux those files because my hardware player always freezes with header compressed mkvs.

[sneaker_ger]

mkvinfo (GUI) and MediaInfo should show it.

[FreaQ]

Thanks found it.

[japouleripeur]

Hi. I created a chapter file with MKVToolNix GUI (8.3.0 on Win10 from scratch) and use it in input of a merge of a mkv file. Whatever the GUI (MKVToolNix GUI or mkvmerge GUI) I get this error:
"Le fichier XML de chapitres 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' contient une erreur : <ChapterTimeStart> n'est pas un élément enfant valable de <EditionEntry> à la position 118."
the chapter XML file 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' is broken : <ChapterTimeStart> is not a valid child item of <EditionEntry> at position 118.
Files uploaded.

BTW I've got this issue as well: "This application has requested the Runtime to terminate it in an unusual way" when I try to add attachments, by drag & drop or right click and "Add", whatever the file (text, picture, etc)
I got this error on Win7 pro with 8.0.0 and 8.1.0 on MKVToolNix GUI only and there was no issue with 8.2.0
On Win10 Fam I get this error on both GUIs with 8.2.0 and 8.3.0. I didn't try previous releases.

[Mosu]

Hi. I created a chapter file with MKVToolNix GUI (8.3.0 on Win10 from scratch) and use it in input of a merge of a mkv file. Whatever the GUI (MKVToolNix GUI or mkvmerge GUI) I get this error:
"Le fichier XML de chapitres 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' contient une erreur : <ChapterTimeStart> n'est pas un élément enfant valable de <EditionEntry> à la position 118."
the chapter XML file 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' is broken : <ChapterTimeStart> is not a valid child item of <EditionEntry> at position 118.
Files uploaded.

Hmm, this should not happen. I'll investigate and try to reproduce it.

BTW I've got this issue as well: "This application has requested the Runtime to terminate it in an unusual way" when I try to add attachments, by drag & drop or right click and "Add", whatever the file (text, picture, etc)
I got this error on Win7 pro with 8.0.0 and 8.1.0 on MKVToolNix GUI only and there was no issue with 8.2.0
On Win10 Fam I get this error on both GUIs with 8.2.0 and 8.3.0. I didn't try previous releases.

This happens when the file data\magic.mgc is missing or if it comes from a different versions. Don't do that. Keep the files I distribute the way they are.

The correct file size for 8.3.0 is 3865680 bytes, SHA1 checksum 903b08d20f1ee749ee76186be5c994985f8ae58d.

[Mosu]

Hi. I created a chapter file with MKVToolNix GUI (8.3.0 on Win10 from scratch) and use it in input of a merge of a mkv file. Whatever the GUI (MKVToolNix GUI or mkvmerge GUI) I get this error:
"Le fichier XML de chapitres 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' contient une erreur : <ChapterTimeStart> n'est pas un élément enfant valable de <EditionEntry> à la position 118."
the chapter XML file 'D:/Conversion/Projects/XXX/Chapitres de XXX.xml' is broken : <ChapterTimeStart> is not a valid child item of <EditionEntry> at position 118.
Files uploaded.

The function for »expanding the start/end timecodes of parent entries to the minimum/maximum timecodes of their children« seems to be the culprit. I'll fix it. Thanks for pointing this out.

If you want to salvage your file then this should be easy. Open it in a text editor and remove the <ChapterTimeStart> child from the <EditionEntry> element. Then you should be able to use the file again.

[Mosu]

I've released MKVToolNix v8.4.0. It contains numerous bug fixes in the GUI and even more new features and enhancements. For this release considerable work has gone into mkvmerge again as well fixing a couple of bugs and implementing some more small enhancements.

The most noticeable change is that the old GUI (mmg) has finally been removed.

Changes for package maintainers: the most important change is that the old GUI (mmg) has been removed. Therefore wxWidgets isn't used anymore. If Qt 5.2.0 or newer is present then mkvinfo's Qt GUI will be built autoamtically, as will be the MKVToolnix GUI.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-09-19 Moritz Bunkus <moritz@bunkus.org>
* Released v8.4.0.
* MKVToolNix GUI: chapter editor bug fix: whenever the additional modification of »expanding start/end timecodes to include the minimum/maximum timecodes of their children« was run on an edition entry then ChapterTimeStart and sometimes ChapterTimeEnd nodes were inserted as direct children of the EditionEntry node when saving. This resulted in invalid chapters.

2015-09-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: when dragging & dropping files onto merge settings already containing a file the user can set more options to be always done instead of asking (before: only adding files to the current merge settings could be thus marked; now: adding to current, adding to new settings and adding each file to new settings can be set to perform without asking). Implements #1388 (https://github.com/mbunkus/mkvtoolnix/issues/1388).
* MKVToolNix GUI: merge tool enhancement: when dragging & dropping files onto merge settings already containing a file the dialog asking the user what to do has received a new option for creating one new merge tab for each of the dropped files. Implements #1380 (https://github.com/mbunkus/mkvtoolnix/issues/1380).

2015-09-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the pixel dimensions reported for VC-1 in MPEG transport streams in verbose identification mode was 0x0.
* mkvmerge: bug fix: the number of channels and the sample rate reported for DTS in MPEG transport streams and MPEG program streams in verbose identification mode was 0.
* mkvmerge: container and track properties in verbose identification mode are now output sorted.
* MKVToolNix GUI: new merge tool feature: the »tracks« tree view contains a new column titled »properties« which contains basic track properties: the pixel dimensions for a video track and sampling frequency, number of channels and bits per sample for an audio track. Implements #1295 (https://github.com/mbunkus/mkvtoolnix/issues/1295).

2015-09-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: the verbose identification result for all audio tracks has been extended to include the number of channels, the sample rate and the bits per sample where applicable. Part of the implementation of #1295 (https://github.com/mbunkus/mkvtoolnix/issues/1295).

2015-09-13 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: parsing of strings containing negative values or timecodes was broken on 32bit architectures. Fixes #1425 (https://github.com/mbunkus/mkvtoolnix/issues/1425).

2015-09-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: the verbose identification result for the MPEG program stream, MPEG transport stream and WAV readers has been changed for audio tracks in order to match the Matroska reader's result. The old keys »channels«, »sample_rate« and »bits_per_sample« have been replaced by »audio_channels«, »audio_sampling_frequency« and »audio_bits_per_sample«.
* mkvmerge: enhancement: the pixel width/height will be reported in verbose identification mode for all video tracks.

2015-09-05 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: added a column in the track list showing the effective state of the »default track« flag. It shows the state of the flag as it will be in the output file. Implements #1353 (https://github.com/mbunkus/mkvtoolnix/issues/1353).

2015-09-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: when mkvmerge encounters garbage data in the middle of AC3 or MP3 tracks it will now output the timecode where the garbage occurred in order to make checking for audio/video sync issues easier. Implements #1420 (https://github.com/mbunkus/mkvtoolnix/issues/1420).

2015-09-01 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: added a column in the tree with the edition's/chapter's flags.
* MKVToolNix GUI: new feature: the state of all columns in all list/tree views can be reset (both the shown/hidden state as well as their order) from the column's context menu. See #1268 (https://github.com/mbunkus/mkvtoolnix/issues/1268).

2015-08-30 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: the column headers of all list/tree views can be re-ordered via drag & drop and the GUI will remember their position upon restart. Additionally the columns can be hidden/shown via a context menu by right-clicking on the column headers. Implements #1268 (https://github.com/mbunkus/mkvtoolnix/issues/1268).
* MKVToolNix GUI: new chapter editor feature: added an option for skipping chapters marked as "hidden" in the re-numbering dialog. Implements #1414 (https://github.com/mbunkus/mkvtoolnix/issues/1414).

2015-08-29 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: added a new translation to Serbian (Cyrillic) by Jay Alexander Fleming (see AUTHORS).
* MKVToolNix GUI: enhancement: the header editor will convert ISO 639-2 terminology codes used in language elements to their corresponding bibliographic variants. Implements #1418 (https://github.com/mbunkus/mkvtoolnix/issues/1418).

2015-08-28 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: if the output file name policy »last output directory« was used then manual changes to the output file name weren't recognized as changes to the last output directory. Fixes #1411 (https://github.com/mbunkus/mkvtoolnix/issues/1411).
* MKVToolNix GUI: merge tool bug fix: the »default subtitle charset« is not applied to text subtitles from Matroska files as those are always encoded in UTF-8. Fixes #1416 (https://github.com/mbunkus/mkvtoolnix/issues/1416).
* MKVToolNix GUI: enhancement: the titles and button texts of dialogs asking questions have been improved to be easier understandable. For example, instead of using »yes/no« as the answers to the question »Do you want to close the unmodified file?« the choices are now »Close file/Cancel«. Implements #1417 (https://github.com/mbunkus/mkvtoolnix/issues/1417).

2015-08-27 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor bug fix: the »shift timecodes« action in the mass modification dialog wasn't working at all, and selecting multiple actions in the dialog would result in wrong actions being executed.

2015-08-23 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: when loading simple/ OGM style chapter files that contain non-ASCII characters and which do not start with a byte order mark (BOM) the GUI will let the user chose the character set to use. A preview is shown for the selected character set and updated when the user changes the character set.

2015-08-20 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: added »remove all« and »select all« entries to the attachments context menu. Implements #1386 (https://github.com/mbunkus/mkvtoolnix/issues/1386).
* MKVToolNix GUI: job output enhancement: the output, warnings and error text views are now separated by two splitters enabling the user to change their respective sizes. These changes are remembered over restarts. Implements #1394 (https://github.com/mbunkus/mkvtoolnix/issues/1394).
* MKVToolNix GUI: chapter editor enhancement: pressing shift+return will cause the next appropriate chapter control to be selected depending on where the focus currently is: from a chapter input (start/end time, flags, UIDs) to the next chapter entry's start time, from a chapter name to the next chapter name and from the last chapter name to the next chapter entry's first chapter name. Implements #1398 (https://github.com/mbunkus/mkvtoolnix/issues/1398) and complements #1358 (https://github.com/mbunkus/mkvtoolnix/issues/1358).
* MKVToolNix GUI: chapter editor enhancement: pressing return on the very last chapter entry will wrap and focus the first one in the tree again. Enhances #1358 (https://github.com/mbunkus/mkvtoolnix/issues/1358).

2015-08-19 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed the total job queue progress with respect to removing completed jobs (either automatically or manually). Fixes #1405 (https://github.com/mbunkus/mkvtoolnix/issues/1405).

2015-08-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: mkvmerge is now run in with the same interface language set for the GUI.
* mkvmerge: bug fix: The formula used for calculating the audio delay for garbage data at the start of tracks in AVI files has been fixed again. It now uses the values dwStart, dwScale and dwSampleSize from the AVI stream header structure instead of values derived from the audio packet headers. Fixes #1382 (https://github.com/mbunkus/mkvtoolnix/issues/1382) and still works correctly for #1137 (https://github.com/mbunkus/mkvtoolnix/issues/1137).
* MKVToolNix GUI: enhancement: scrolling over input elements like combo boxes, check boxes and radio buttons located within a scroll area will now scroll the scroll area instead of the element the cursor is over (e.g. a combo box). Implements #1400 (https://github.com/mbunkus/mkvtoolnix/issues/1400).

2015-08-17 Moritz Bunkus <moritz@bunkus.org>
* all: the environment variable <TOOLNAME>_OPTIONS is now parsed for options for TOOL (e.g. MKVMERGE_OPTIONS for mkvmerge). MKVTOOLNIX_OPTIONS is still used for all programs. Fixes #1403 (https://github.com/mbunkus/mkvtoolnix/issues/1403).

2015-08-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed the escaping of the command line for cmd.exe regarding the command name itself (the very first argument). Fixes #1401 (https://github.com/mbunkus/mkvtoolnix/issues/1401).

2015-08-15 Moritz Bunkus <moritz@bunkus.org>
* build system: removal: the switch »--without-mkvtoolnix-gui« has been removed. There are only two GUIs left in the package: the Qt-enabled mkvinfo and MKVToolNix GUI. Both are enabled by default and can be disabled with the option »--disable-qt«. In that case only the text-mode version of mkvinfo is built, and the MKVToolNix GUI is not built at all.
* Removal: all support for wxWidgets has been removed. This means that the mkvmerge GUI (mmg) has been removed and that mkvinfo now only supports a text-mode and a Qt-based interface.
* build system: bug fix: fixed Qt platform plugin detection on MacOS.

[Bigmango]

Thanks.

In the changelog I don't see the language tag fra replaced with fre (header editor). But this fix is in 8.4.0, isn't it?

[nevcairiel]

In the changelog I don't see the language tag fra replaced with fre (header editor). But this fix is in 8.4.0, isn't it?

Its this one, I wager:

* MKVToolNix GUI: enhancement: the header editor will convert ISO 639-2 terminology codes used in language elements to their corresponding bibliographic variants. Implements #1418.

[Mosu]

Nevcairiel is spot on.

[japouleripeur]

The function for »expanding the start/end timecodes of parent entries to the minimum/maximum timecodes of their children« seems to be the culprit. I'll fix it. Thanks for pointing this out.

If you want to salvage your file then this should be easy. Open it in a text editor and remove the <ChapterTimeStart> child from the <EditionEntry> element. Then you should be able to use the file again.

:thanks: it works.

[Mosu]

:thanks: it works.

You're welcome. That particular bug has been fixed in 8.4.0, too.

[japouleripeur]

Hmm, this should not happen. I'll investigate and try to reproduce it.

This happens when the file data\magic.mgc is missing or if it comes from a different versions. Don't do that. Keep the files I distribute the way they are.

The correct file size for 8.3.0 is 3865680 bytes, SHA1 checksum 903b08d20f1ee749ee76186be5c994985f8ae58d.
I always use the installer and do not change any file afterwards. I knew about this "magic" file, you wrote it in another post and I checked size and check-sum. They are ok.
The issue even occured at the first MKVToolNix installation after my fresh Win10 installation from scratch.
BTW I do not understand why it's possible to add the same files in the source tab and not in the attachment tab. For sure I'm not a coding expert.

[AYColumbia]

Anyone else having issues downloading the non-portable Windows install packages? Getting a file not found on both 32 and 64 bit Windows installers. Portable links are fine.

[Mosu]

Do you have write access to the file you're trying to add as an attachment? Both tabs do very, very different things. The input tab will have mkvmerge scan the file for known container formats. On the attachment tab mkvmerge itself is not involved when adding a file, instead libMagic is called for automatic MIME type detection.

Can you provide one file for which the GUI crashes? I sure as hell cannot reproduce it here at the moment. I can add as many attachments as I want to, the GUI happily continues running.

[Mosu]

Anyone else having issues downloading the non-portable Windows install packages? Getting a file not found on both 32 and 64 bit Windows installers. Portable links are fine.

I just had to re-build both installers as the version numbers shown were wrong due to a stupid mistake. Please re-visit the FossHub download page and try again.

[Mosu]

…and it seems I have to re-re-upload the installers with different file names, otherwise FossHub's interface will continue to have a problem with them. Give me five minutes.

[AYColumbia]

Thank you Mosu. No problem, just wanted to give a heads up. I was able to grab what I need from your builds. Many thanks for continuing to improve this tool. :)

[Mosu]

Done. Please re-visit the FossHub download (http://www.fosshub.com/MKVToolNix.html) page. I've confirmed that both installers can be downloaded properly now.

[AYColumbia]

Done. Please re-visit the FossHub download (http://www.fosshub.com/MKVToolNix.html) page. I've confirmed that both installers can be downloaded properly now.
Confirmed. Thanks again.

[ShadyCrab]

I'm not sure if it was intentional, but you cant use the Mouse Scroll to change the fields anymore (scrolling down to change Default track from Yes to No for example). This was a real time saver in 8.3.0, especially when dealing with many, many files (small repetitive savings add up, and it reduces the 'mental fatigue' on repetitive tasks when they take less steps). Is it possible this could be added back as an option or something?

I really like the default track column addition in 8.4, its an incredible help in making sure you dont mess up default settings.

[Mosu]

I'm not sure if it was intentional, but you cant use the Mouse Scroll to change the fields anymore (scrolling down to change Default track from Yes to No for example).

This was indeed intentional as it made scrolling the whole pane a pain. Users complained about that, quite often.

You can still scroll the combo boxes, though, but only if they currently have the focus. So click on e.g. the language combo box and the scroll wheel will send its events to that combo box.

I don't plan on making this optional at the moment. Sorry.

[hubblec4]

Hi Mosu

I asked you for a while, could you change the output of the time in nano precession for the "identify-for-mmg" switch.
You said you cant change the output, cause other people had then problems with parsing.

mmmh ... now you have change something (grrr.)
please change the time format from ms to ns!!!

[Mosu]

No, sorry. I do know of people who parse those timestamps. I won't change them lest I break their application. However, I don't know of anyone having used the audio_* values in verbose identification mode. And if someone complains about them I can still re-add the old values in addition to the new ones, and that wouldn't break anything. Big difference.

[hubblec4]

...
However, I don't know of anyone having used the audio_* values in verbose identification mode. And if someone complains about them I can still re-add the old values in addition to the new ones, and that wouldn't break anything. Big difference.

I parse this values :-)

It's ok with your change, I will update to your changes.
Dont waste your time for re-adding!

Can you add a new switch please?
(identify-for-mmg-ns)

[Mosu]

No, I don't like that there are three different identification modes already. I won't add a fourth one.

Ask me again in a release or two, maybe I'll change my mind about the formatting.

[hubblec4]

No, I don't like that there are three different identification modes already. I won't add a fourth one.

Which are the other two modes?


Ask me again in a release or two, maybe I'll change my mind about the formatting.

Yes ok, i will do that.

Maybe you add the switch --time-ns and an additionally entrie appear at the end of the text.


Time in ns is very important for me, because splitting,"ordered chapters" and my Matroska Menu Editor need this to work perfectly.

[Mosu]

--identify, --identify-verbose, --identify-for-gui (or its older version --identify-for-mmg which continues to work).

[Mosu]

Uhm… remind me again. For which values do you need ns precision?

[hubblec4]

For which values do you need ns precision?

In a prev version of mkvmerge was the identify-output for a mkv "Duration:".

First the hh:mm:ss:ms code followed by the time in second with millisec(1,234).

Now, there is a value "duration:" and many digits:

Example:
...
container: Matroska [container_type:17 duration:7724190000000 is_providing_timecodes:1 segment_uid
:9d8243fdc3600b69a474fb2a0ec8448a]
...

Is this the duration of the mkv, which format?

There are other duration values at the tracks. I think this are not so interessting.

[Mosu]

The duration: entry in the container line is the segment duration in nanoseconds. There's a »default_duration« entry for tracks, again in nanoseconds, but that's not the track's duration, obviously.

Earlier versions of mkvmerge also listed the track statistics tags. You can force mkvmerge to include them again by adding »--engage keep_track_statistics_tags« in addition to »--identify…«. mkvmerge does not reformat those tags, it outputs them the way they are. mkvmerge writes those tags as HH:MM:SS.nnnnnnnnn, but other applications may chose less precision – and that's nothing mkvmerge could change.

So basically there's nothing for me to do here.

[hubblec4]

Sorry Mosu

I get the movie duration value from mkvinfo.exe.

So can you add there a posibillity to get the durations with ns?

[wanezhiling]

http://i3.tietuku.com/f1b46cbc3687490a.png
http://i3.tietuku.com/bcd405a25c250f49.png
http://i3.tietuku.com/3993a0ff47076283.png
It seems that the simplified Chinese language in 8.4 is not complete even comparing to the one in 8.3? And the sc lang size is much smaller in 8.4 too. A mistake?

[Mosu]

I get the movie duration value from mkvinfo.exe.

So can you add there a posibillity to get the durations with ns?

Like I said: the movie duration is already part of the properties, it's »duration:« in the container line. It is the duration in ns.

[Mosu]

It seems that the simplified Chinese language in 8.4 is not complete even comparing to the one in 8.3? And the sc lang size is much smaller in 8.4 too. A mistake?

The translator for Chinese Simplified does not update the translation often. As I don't speak Chinese myself there's not a lot I can do about it; I need translators who do the actual work.

The translation file in 8.4.0 is smaller because the old GUI and all associated strings have been removed from MKVToolNix. That's exactly how it should be.

[hubblec4]

Like I said: the movie duration is already part of the properties, it's »duration:« in the container line. It is the duration in ns.

Ok, thats clear

BUT

the ns value seems to me not really good calculated.
Every ns value ends with "000000".
Only three digits for ms not "000".

In mkfinfo.exe(output) there is not really a "container line", or??

[Mosu]

The »container« line refers to the output of mkvmerge's identification mode.

The segment duration field in the Matroska file is scaled via TimecodeScale. That value defaults to 1000000. This means that the duration field itself only has a precision of ms. mkvmerge outputs what's in that field, it doesn't scan the whole file for calculating anything.

So no, mkvmerge cannot give you the information you want. You would have to parse mkvinfo's full output and calculate everything yourself, I guess.

You're probably going to ask me to extend mkvinfo's output to ns precision next. Please open a feature request on Github (https://github.com/mbunkus/mkvtoolnix/issues/) for that.

[LeMoi]

If we install this version over previous one, will the MMG be preserved or will it be removed?

[Mosu]

The installer will clean up obsolete files and therefore remove mmg.exe. Use the portable version if you want to keep mmg.exe around.

[LeMoi]

So if i still want to use the old GUI, I just have to keep the mmg.exe file?

[Mosu]

You also need data\magic.mgc from 8.3.0 and the locale folder from 8.3.0. Unfortunately you cannot simply mix magic.mgc from different versions generally as that will lead to segmentation faults in one of the applicaitons.

In such a situation it would probably be simpler to keep two folders around, one with mmg.exe and its associated files (you can remove the other .exe from that folder) and one folder with the current MKVToolNix. Then point mmg.exe to the location of the newer mkvmerge.exe.

[Bigmango]

Now that the mkvmerge-gui was removed there's no gui anymore in the archlinux version... :(

[Mosu]

There are three bugs open (https://bugs.archlinux.org/index.php?string=mkvtoolnix&project=0&search_name=&type%5B%5D=&sev%5B%5D=&pri%5B%5D=&due%5B%5D=&reported%5B%5D=&cat%5B%5D=&status%5B%5D=open&percent%5B%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=&do=index) for this already, the oldest one from the 8.0.0 release. Complain to the Arch Linux maintainers, please, it's their job to keep things up to date.

Or compile it yourself for the time being. Arch Linux is my main development platform, and the GUI works nicely there.

There's also an AUR package (https://aur.archlinux.org/packages/mkvtoolnix-git/) called mkvtoolnix-git which builds the Qt-based GUIs.

[Murcetieb]

It seems that the simplified Chinese language in 8.4 is not complete even comparing to the one in 8.3? And the sc lang size is much smaller in 8.4 too. A mistake?

8.3 ships with a translation that has been reverted as per user report (https://github.com/mbunkus/mkvtoolnix/issues/1399).

I've started working on the Simplifed Chinese translation, and have just finished untranslated and fuzzy entries. Going to do a thourough check of all entries in the next a few days. Will submit to Mosu when I feel it's ready, hopefully this can be done within this week.
You can check my progress on my Github repo (https://github.com/DonghuiLi-81/mkvtoolnix/commits/zh_CN?author=DonghuiLi-81). Feedback is welcome.

[Mosu]

That's great to hear! Thanks, Murcetieb, I appreciate it.

[wanezhiling]

https://www.sendspace.com/file/1f6aa1
latest simplified Chinese language file

[Chetwood]

Typo in German GUI:

Was wollen Sie mit den Dateien machen, die sie hier her gezogen undfallen gelassen haben?

should read

Was wollen Sie mit den Dateien machen, die sie hierher gezogen und fallen gelassen haben?

[Mosu]

Fixed, thanks.

[Thunderbolt8]

is this meant to be a translation for drag and drop? I'd rather use "die Sie hier eingefügt haben", there is no need to translate the whole thing literally. What matters is just the outcome, where the files are now.

right now it sounds clumsy.

[Chetwood]

Still, ziehen und fallenlassen appears to be the proper translation and also being used in professionally translated OSs like Windows (the translation is professional, not the OS).

[Thunderbolt8]

it still sounds rather clumsy and stupid. there is really no need to translate the whole process when the result is all that matters. what happened is that bestimmte Dateien dort eingefügt worden sind. how his happened, no one cares.

[Chetwood]

Says you. So?

[Perenista]

I am getting this error (click to enlarge):

http://s9.postimg.org/6oy940ah7/Sem_t_tulo.jpg (http://postimg.org/image/6oy940ah7/)

It wasn't happening BEFORE I updated to the last version of this program.

[Mosu]

Well, don't try to write to directories you don't have write access to, like C:\Program Files\…

[Perenista]

Well, don't try to write to directories you don't have write access to, like C:\Program Files\…What? This is what you get from using version 7.4.0...

http://s29.postimg.org/uh5343lv7/Sem_t_tulo.jpg (http://postimg.org/image/uh5343lv7/)

I had to search for a previous version to see if was not some sort of bug. Apparently, it is.

As you can see, I am able to add an audio and subtitle track to the MKV successfully. The file tested was in the same location. My OS version is Windows 8.1 PRO 64 bit.

EDIT: Sorry for the misunderstanding. I changed the output folder, and it worked in the last version. Didn't know about the write access thing. This is going to confuse some people.

BTW, why can't I open more than one instance from this program now? In the past I worked with more than one file at the same time, to speed up things.

[Mosu]

You cannot open more than one instance because you don't have to. You can open as many tabs inside that instance as you want. You can continue working while the program is muxing.

Additionally starting the program when an instance is already running is adding the files the second instance was started with to the running instance's current merge settings (think of drag & drop to an icon on the desktop or the »send to…« context menu facility).

[foxyshadis]

What? This is what you get from using version 7.4.0...

http://s29.postimg.org/uh5343lv7/Sem_t_tulo.jpg (http://postimg.org/image/uh5343lv7/)

I had to search for a previous version to see if was not some sort of bug. Apparently, it is.

As you can see, I am able to add an audio and subtitle track to the MKV successfully. The file tested was in the same location. My OS version is Windows 8.1 PRO 64 bit.

EDIT: Sorry for the misunderstanding. I changed the output folder, and it worked in the last version. Didn't know about the write access thing. This is going to confuse some people.

How did you manage to do that? The only way I can think of is that you accidentally manually selected the mkvmerge folder when choosing output, because I've blanked my settings file a few times and tried to open files different ways, and still can't get it to default to anywhere but the original file's folder. If you have a workflow that exposes a bug, it'd help to describe it. No one else has run into the restricted folder problem so far because it should never default there.

[Mosu]

It can happen in several cases. The file dialog receives an argument which directory to show initially. If that argument is empty then the file dialog will default to the current working directory, which in turn defaults to the folder the program's run from on Windows – with the installed version this is C:\Program Files\MKVToolNix by default.

If you start the GUI from a fresh installation ( = no settings saved yet), don't add a file but click on the »browse« button next to the output file name, then the dialog should default to the installation folder if I'm not mistaken. Now enter a name without actually checking the folder and you're in such a situation.

I will probably not spend time on making this foolproof, though. As we all know that would be futile ;) The universe and bigger fools etc.

[magsoud]

Add MKVToolNix in Video ContextMenu.
Add new window for "Success Mux" finish.
Add Up or Down Key for Tracks...

[Mosu]

First of all: I'm more inclined to listen to requests if you're actually polite. Just saying »do this« and »do that« doesn't fit the bill. Is it so hard to actually ask? Maybe even include a »please« somewhere?

Add MKVToolNix in Video ContextMenu.

I'm not sure what this means.

Add new window for "Success Mux" finish.

Nope, sorry. Such a dialog doesn't fit into the GUI's design. In the old GUI the workflow was limited: when it was muxing you couldn't do anything else with the GUI and had to wait for muxing to finish. In the new GUI, however, you can continue working just fine: create more mux jobs, edit chapters or file headers, you can even run more than one muxing job at the same time.

Add Up or Down Key for Tracks...

That's already implemented. There are actually three ways for re-ordering entries (not just tracks!):

Use drag & drop like in any other Windows application.
Hold Ctrl and press the cursor up/down keys while the list view has the focus.
Go to the preferences and enable »show buttons for moving list entries up and down«. Then you'll see push buttons like in the old GUI.

[magsoud]

Add MKVToolNix in Video ContextMenu.


I'm not sure what this means.

With changes the Registry, Like shape...

[Mosu]

Ah, I see. I won't spend time on it. Patches to the installer for such functionality would be welcome, though.

[Overdrive80]

What program should I use to translate this https://github.com/mbunkus/mkvtoolnix/tree/master/doc/man/es???

[mike23]

How to solve error in file structure?

I opened a given *.kmv file in mkvmerge GUI v8.3.0 which is included in package 8.4.0.
Without any changes I start muxing the video into a new file.

The log window shows after approx 30% an error:

E:\xxx.German.DL.1080p.BluRay.x264-ENCOUNTERS.mkv: Error in the Matroska file structure at position 1160154794. Resyncing to the next level 1 element.
The last timecode processed before the error was encountered was 00:32:38.261666662.
Still resyncing at position 1373987038.
Still resyncing at position 1615741628.
...

After a minute or so the muxing process is aborted and the target file contains only the first 32min.

So why is mkvmerge not able to detect/inspect the full video?

How can I repair the video ?

[DMD]

Good morning

When demuxing (using tsMuxeR) a file created with MKVToolnix 8.4.0-1 get the following error :confused:

http://i58.tinypic.com/15e8iub.jpg



When demuxing the same file created with MKVToolnix 8.3.0, demux is OK

http://i61.tinypic.com/2uifc3k.jpg



It 'a problem that can be solved?

THANK YOU

[DragonQ]

Is there a way to view/copy the command line string being used by the MKVtoolnix GUI? I want to create a batch script but it's going to be a complicated merge of various files and I've done it in the GUI but am either not finding this button or it's not added yet?

[sneaker_ger]

http://abload.de/img/toolnixgui_show_cli_4xs9l.png

When demuxing (using tsMuxeR) a file created with MKVToolnix 8.4.0-1 get the following error :confused:
Can you share samples of input and output files? If mkvmerge was to mux H.264 wrong it would be a huge problem.

[DragonQ]

Thanks!

[DMD]

...
Can you share samples of input and output files? If mkvmerge was to mux H.264 wrong it would be a huge problem.
all afternoon I'm carrying out tests to demux and remux MKV.
Now I am trying to make and demux with MKVExtractGUI2 2.2.2.29, then it makes remuxing and I check with tsMuxeR.
as soon as I finish I tell you what happens.

[DMD]

I made the demux with MKVExtractGUI2 and remuxing with mkvtoolnix GUI (8.4.0-1), after I did the test with tsMuxeR demux and process everything went OK with no errors.

I checked with Mediainfo the file, and do not understand the latest data highlighted that in the source file does not exist.
What's with that data? :confused:

http://i62.tinypic.com/23wod49.jpg



MKV files source

http://i57.tinypic.com/5czxw0.jpg

[Asmodian]

Those are simply new data fields written my mkvmerge, they make it easier for players or other tools to get the duration of the file but they are not critical and don't do anything themselves.

[Megalith]

Does this give you the option of demuxing an .mkv?

[mike23]

I have a MKV file which can be played (in VLC) but seems to be not fully correct.

Example:
When I start to do some conversions for a video file and ffmpeg.exe a got an error:

[avi @ 00000000026a0520] H.264 bitstream malformed, no startcode found, use the video bitstream filter 'h264_mp4toannexb' to fix it ('-bsf:v h264_mp4t
av_interleaved_write_frame(): Invalid data found when processing input

I don't want to fiddle around with some parameters.

I want a simple solution.

So is there a "one-size-fits-all" solution :-)

e.g. something like

mmg.exe -checkandrepair -in=myvideo.mkv -out=myvideoout.mkv

[bartonnen]

Does this give you the option of demuxing an .mkv?

It has demuxing (mkvextract) - but you need to add a GUI (it gives a link to a suitable GUI during installation): gMKVExtractGUI (http://sourceforge.net/projects/gmkvextractgui/)

[Mosu]

What program should I use to translate this https://github.com/mbunkus/mkvtoolnix/tree/master/doc/man/es???

Thanks for the offer. Please contact me via email at moritz@bunkus.org if you want to help out with translations.

[Mosu]

How to solve error in file structure?

mkvmerge already does its best trying to recover as much data as possible. The message "Still resyncing…" means that it cannot find valid Matroska cluster IDs in the data. Basically there is no valid data left to recover.

To me it looks like an incomplete download, e.g. you started downloading via a BitTorrent client which pre-allocates the space, but it only the first part was actually downloaded. The rest of the file's allocated space is just garbage.

[Mosu]

Does this give you the option of demuxing an .mkv?

The MKVToolNix package contains a command-line only tool mkvextract for extraction. The MKVToolNix GUI doesn't have functionality for this yet, but it is on the TODO list.

There are third-party GUIs for mkvextract available, see e.g. the MKVToolNix links page (https://www.bunkus.org/videotools/mkvtoolnix/links.html).

[Mosu]

I have a MKV file which can be played (in VLC) but seems to be not fully correct.
…
So is there a "one-size-fits-all" solution :-)

No, not really.

[Bigmango]

Does mkvtoolnix proprerly handle the A/V sync issues that sometimes happen with seamless branching blurays?

Makemkv always removes 1 video frame as soon as the sync issue reaches 10ms to keep it properly in sync.

Does mkvtoolnix also do this, or is it still better to use makemkv to remux blurays?

Thanks.

[Mosu]

I honestly cannot answer that.

Have you given MKVToolNix a try? Did you encounter any problems with the sync in such a situation?

[Bigmango]

Is seamless branching support a planned feature for mkvtoonlix?

So we can:


Have theatrical and extended versions of a movie in the same mkv (saving a lot of HD space compared to keeping 2 files)
Have multi-language video (i.ex sometimes the titles and some texts in movies are written in several languages)- -> Kodi (xbmc) already automatically switches forced subtitles on the right language to match the audio language (it makes 100% use of the mkv language tags :)). With this feature it could also play the correct language titles and text parts in the videos.
Have multi-angle support (some movies like Start Wars have up to 6 or 7 angles).

This is imho definitely needed to bring mkv to the next level.

Thanks.

[Bigmango]

I honestly cannot answer that.

Have you given MKVToolNix a try? Did you encounter any problems with the sync in such a situation?

I am asking because I haven't tried it.

Ok, unless someone has the answer untill then, I'll try it next time I encounter this with makemkv.

[hubblec4]

I use my chapterEditor to prepare Bluray-disks and I get then a mtxcfg-file. So I can use MKVToolNiX-GUI for all BD's. I have a lot of multi-editions(seamless branching) BD's mux to mkv without sync issues.

[Bigmango]

I use my chapterEditor to prepare Bluray-disks and I get then a mtxcfg-file. So I can use MKVToolNiX-GUI for all BD's. I have a lot of multi-editions(seamless branching) BD's mux to mkv without sync issues.

:goodpost:

I am floored. I just remuxed my Avatar Collector's Edition bluray and got an MKV with the 3 editions (Extended, Special and Theatrical). And only 40Gb instead of 100+Gb. Awesome.

VLC sees the 3 editions and I can switch between them in the menu. You are a genius.

But, when I load this mkv (which was created by mkvtoolnix with your chapter editor) in mkvtoolnix it only sees it as 1 video track (with single audio tracks) and doesn't see the 2 other editions the mkv contains.

@ Mosu:


Could you please have mkvtoolnix show some information that there are several editions in the mkv?
as we already have bluray playlist loading in mkvtoolnix, it makes sense to add this multi-edition selection feature directly into mkvtoolnix, so we have complete bluray seamless branching support in mkvtoolnix (with the new GUI, mkvtoolnix now looks like an "MKV Workstation". I think we can definitely see this feature going in there)?


This would also attract more player support (for title selection) as this ordered chapters mkv feature (in the mkv specs for many years) would become more used and widely known.

I, for one, have used mkvtoolnix for years and had absolutely no clue this even existed.

WHY isn't this HUGE mkv feature used everywhere? -> Because no one knows about it as mkvtoonlix isn't even showing this exists.

Many thanks.

[Bigmango]

I use my chapterEditor to prepare Bluray-disks and I get then a mtxcfg-file. So I can use MKVToolNiX-GUI for all BD's. I have a lot of multi-editions(seamless branching) BD's mux to mkv without sync issues.

One more question:

How do you demux, or extract / separate the multiple editions into separate mkv files if need be (for future safe keeping /availability of the separate editions)?

Neither mkvtoolnix nor gmkvextractgui sees the multiple editions contained in the mkv (they only see the first title).

[ndjamena]

I'm pretty sure they don't see any of the "titles", just the base streams that the titles are constructed from.

The "titles" are in the chapters, but MKVMerge -I doesn't seem to mention the existence of multiple editions...

MKVMerge could provide a more detailed breakdown of the chapters that includes editions, but if you want to "see" each individual title as a separate file Mosu would have to either completely reinvent the -I option or create a secondary Info option to support it.

[ndjamena]

Would it be possible to include some indication of "Pre-parsing FLAC file: ##%" in the progress bar. I keep thinking it isn't working.

[Bigmango]

I'm pretty sure they don't see any of the "titles", just the base streams that the titles are constructed from.

Yes.

The "titles" are in the chapters, but MKVMerge -I doesn't seem to mention the existence of multiple editions...

Exactly. This is the "ordered chapters", which has been a feature in the mkv specs for many years as I understand it.


MKVMerge could provide a more detailed breakdown of the chapters that includes editions, but if you want to "see" each individual title as a separate file Mosu would have to either completely reinvent the -I option or create a secondary Info option to support it.

It's of course up to Mosu to decide how he wants to implement this, but I think:


it would be nice to see the separate editions clearly in the track list (with perhaps a flag or someting to show the track is virtual)
the above point 1 should also allow demuxers to demux (or extract as separate mkvs) the separate editions (to for example bring back the editions as separate mkvs if needed in the future)

[Bigmango]

I use my chapterEditor to prepare Bluray-disks and I get then a mtxcfg-file. So I can use MKVToolNiX-GUI for all BD's. I have a lot of multi-editions(seamless branching) BD's mux to mkv without sync issues.

As I understand, there are no sync issues because you are using eac3to to demux (eac3to fixes sync issues).

This means that when using mkvtoolnix to load the bluray playlist directly there will be sync issues?

This is what I get in the output with Makemkv on the Avatar extended cut:

AV synchronization issues were found in file 'C:/video/Extended_Collector's_Edition_Disc_1_t02.mkv' (title #3)
AV sync issue in stream 1,3 at 0:00:00.001 with duration of 10.666ms : 1 early frame(s) dropped at start
AV sync issue in stream 2 at 0:00:00.023 with duration of 32ms : 1 early frame(s) dropped at start
AV sync issue in stream 3 at 0:10:24.452 with duration of 7.911ms : encountered overlapping frame, audio skew is +7.911ms
AV sync issue in stream 2 at 0:10:24.452 with duration of 18.577ms : encountered overlapping frame, audio skew is +18.577ms
AV sync issue in stream 1,3 at 0:28:10.487 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 3 at 0:28:10.487 with duration of 2.752ms : encountered overlapping frame, audio skew is +10.663ms
AV sync issue in stream 2 at 0:28:10.487 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 0:28:10.487 with duration of 13.419ms : encountered overlapping frame, audio skew is +31.997ms
AV sync issue in stream 1,3 at 0:28:52.320 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 0:28:52.331 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 0:28:52.331 with duration of 11.541ms : encountered overlapping frame, audio skew is +43.538ms
AV sync issue in stream 2 at 0:28:52.375 with duration of 32ms : 1 frame(s) dropped to reduce audio skew to +11.538ms
AV sync issue in stream 3 at 0:28:52.320 with duration of 0.875ms : encountered overlapping frame, audio skew is +11.538ms
AV sync issue in stream 3 at 0:28:52.332 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +0.872ms
AV sync issue in stream 3 at 0:30:20.439 with duration of 9.791ms : encountered overlapping frame, audio skew is +10.663ms
AV sync issue in stream 2 at 0:30:20.439 with duration of 20.458ms : encountered overlapping frame, audio skew is +31.997ms
AV sync issue in stream 2 at 0:32:27.896 with duration of 30.044ms : encountered overlapping frame, audio skew is +62.041ms
AV sync issue in stream 2 at 0:32:27.959 with duration of 32ms : 1 frame(s) dropped to reduce audio skew to +30.041ms
AV sync issue in stream 3 at 0:32:27.896 with duration of 8.711ms : encountered overlapping frame, audio skew is +19.375ms
AV sync issue in stream 3 at 0:32:27.916 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +8.708ms
AV sync issue in stream 1,3 at 0:47:36.812 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 3 at 0:47:36.812 with duration of 1.955ms : encountered overlapping frame, audio skew is +10.663ms
AV sync issue in stream 2 at 0:47:36.823 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 0:47:36.823 with duration of 1.955ms : encountered overlapping frame, audio skew is +31.997ms
AV sync issue in stream 1,3 at 0:48:07.134 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 0:48:07.156 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 0:48:07.156 with duration of 2.952ms : encountered overlapping frame, audio skew is +34.95ms
AV sync issue in stream 2 at 0:48:07.191 with duration of 32ms : 1 frame(s) dropped to reduce audio skew to +2.95ms
AV sync issue in stream 3 at 0:48:07.134 with duration of 2.952ms : encountered overlapping frame, audio skew is +13.616ms
AV sync issue in stream 3 at 0:48:07.148 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +2.95ms
AV sync issue in stream 3 at 0:53:33.751 with duration of 7.708ms : encountered overlapping frame, audio skew is +10.658ms
AV sync issue in stream 2 at 0:53:33.751 with duration of 29.041ms : encountered overlapping frame, audio skew is +31.991ms
AV sync issue in stream 2 at 0:54:13.809 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 0:54:13.809 with duration of 5.466ms : encountered overlapping frame, audio skew is +37.458ms
AV sync issue in stream 2 at 0:54:13.847 with duration of 32ms : 1 frame(s) dropped to reduce audio skew to +5.458ms
AV sync issue in stream 3 at 0:54:13.788 with duration of 5.466ms : encountered overlapping frame, audio skew is +16.125ms
AV sync issue in stream 3 at 0:54:13.804 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +5.458ms
AV sync issue in stream 1,3 at 0:57:47.969 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 0:57:47.959 with duration of 26.541ms : encountered overlapping frame, audio skew is +32ms
AV sync issue in stream 2 at 0:57:47.991 with duration of 32ms : 1 frame(s) dropped to reduce audio skew to +0ms
AV sync issue in stream 3 at 0:57:47.969 with duration of 5.208ms : encountered overlapping frame, audio skew is +10.666ms
AV sync issue in stream 3 at 0:57:47.980 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +0ms
AV sync issue in stream 1,3 at 0:58:32.050 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 3 at 0:58:32.050 with duration of 4.625ms : encountered overlapping frame, audio skew is +4.625ms
AV sync issue in stream 2 at 0:58:32.039 with duration of 15.291ms : encountered overlapping frame, audio skew is +15.291ms
AV sync issue in stream 3 at 1:03:13.996 with duration of 6.033ms : encountered overlapping frame, audio skew is +10.658ms
AV sync issue in stream 2 at 1:03:14.007 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 1:03:14.007 with duration of 16.7ms : encountered overlapping frame, audio skew is +31.991ms
AV sync issue in stream 1,3 at 1:03:57.215 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 3 at 1:03:57.215 with duration of 1.922ms : encountered overlapping frame, audio skew is +12.58ms
AV sync issue in stream 3 at 1:03:57.228 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +1.913ms
AV sync issue in stream 2 at 1:03:57.215 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 1:03:57.215 with duration of 23.255ms : encountered overlapping frame, audio skew is +55.247ms
AV sync issue in stream 2 at 1:03:57.271 with duration of 32ms : 1 frame(s) dropped to reduce audio skew to +23.247ms
AV sync issue in stream 2 at 1:09:57.271 with duration of 8.747ms : encountered overlapping frame, audio skew is +31.994ms
AV sync issue in stream 3 at 1:09:57.271 with duration of 8.747ms : encountered overlapping frame, audio skew is +10.661ms
AV sync issue in stream 1,3 at 1:15:53.800 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 3 at 1:15:53.800 with duration of 4.044ms : encountered overlapping frame, audio skew is +14.705ms
AV sync issue in stream 3 at 1:15:53.815 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +4.038ms
AV sync issue in stream 2 at 1:15:53.800 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 1:15:53.800 with duration of 14.711ms : encountered overlapping frame, audio skew is +46.705ms
AV sync issue in stream 2 at 1:15:53.847 with duration of 32ms : 1 frame(s) dropped to reduce audio skew to +14.705ms
AV sync issue in stream 3 at 1:17:37.313 with duration of 6.627ms : encountered overlapping frame, audio skew is +10.666ms
AV sync issue in stream 3 at 1:17:37.324 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +0ms
AV sync issue in stream 2 at 1:17:37.303 with duration of 17.294ms : encountered overlapping frame, audio skew is +32ms
AV sync issue in stream 2 at 1:17:37.335 with duration of 32ms : 1 frame(s) dropped to reduce audio skew to +0ms
AV sync issue in stream 1,3 at 1:18:02.557 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 1:18:02.557 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 1:18:02.557 with duration of 25.291ms : encountered overlapping frame, audio skew is +25.291ms
AV sync issue in stream 3 at 1:18:02.557 with duration of 3.958ms : encountered overlapping frame, audio skew is +3.958ms
AV sync issue in stream 3 at 1:25:54.273 with duration of 6.705ms : encountered overlapping frame, audio skew is +10.663ms
AV sync issue in stream 2 at 1:25:54.295 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 1:25:54.295 with duration of 6.705ms : encountered overlapping frame, audio skew is +31.997ms
AV sync issue in stream 1,3 at 1:27:59.987 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 1:27:59.987 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 1:27:59.987 with duration of 3.794ms : encountered overlapping frame, audio skew is +35.791ms
AV sync issue in stream 2 at 1:28:00.023 with duration of 32ms : 1 frame(s) dropped to reduce audio skew to +3.791ms
AV sync issue in stream 3 at 1:27:59.987 with duration of 3.794ms : encountered overlapping frame, audio skew is +14.458ms
AV sync issue in stream 3 at 1:28:00.001 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +3.791ms
AV sync issue in stream 1,3 at 1:35:45.367 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 1:35:45.367 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 1:35:45.367 with duration of 28.205ms : encountered overlapping frame, audio skew is +31.997ms
AV sync issue in stream 3 at 1:35:45.367 with duration of 6.872ms : encountered overlapping frame, audio skew is +10.663ms
AV sync issue in stream 3 at 1:37:30.802 with duration of 4.122ms : encountered overlapping frame, audio skew is +14.786ms
AV sync issue in stream 3 at 1:37:30.817 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +4.119ms
AV sync issue in stream 2 at 1:37:30.781 with duration of 25.455ms : encountered overlapping frame, audio skew is +57.452ms
AV sync issue in stream 2 at 1:37:30.839 with duration of 32ms : 1 frame(s) dropped to reduce audio skew to +25.452ms
AV sync issue in stream 3 at 1:46:51.692 with duration of 6.544ms : encountered overlapping frame, audio skew is +10.663ms
AV sync issue in stream 2 at 1:46:51.703 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 1:46:51.703 with duration of 6.544ms : encountered overlapping frame, audio skew is +31.997ms
AV sync issue in stream 2 at 1:48:58.170 with duration of 28.702ms : encountered overlapping frame, audio skew is +60.7ms
AV sync issue in stream 2 at 1:48:58.231 with duration of 32ms : 1 frame(s) dropped to reduce audio skew to +28.7ms
AV sync issue in stream 3 at 1:48:58.191 with duration of 7.369ms : encountered overlapping frame, audio skew is +18.033ms
AV sync issue in stream 3 at 1:48:58.209 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +7.366ms
AV sync issue in stream 1,3 at 2:32:40.364 with duration of 10.666ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 3 at 2:32:40.364 with duration of 3.291ms : encountered overlapping frame, audio skew is +10.658ms
AV sync issue in stream 2 at 2:32:40.375 with duration of 32ms : 1 overlapping frame(s) dropped at segment boundary
AV sync issue in stream 2 at 2:32:40.375 with duration of 3.291ms : encountered overlapping frame, audio skew is +31.991ms
AV sync issue in stream 3 at 2:33:17.853 with duration of 4.175ms : encountered overlapping frame, audio skew is +14.833ms
AV sync issue in stream 3 at 2:33:17.868 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +4.166ms
Too many AV synchronization issues in file 'C:/video/Extended_Collector's_Edition_Disc_1_t02.mkv' (title #3) , future messages will be printed only to log file

This is up to 80% of the remux, more is in the log for the last 20%.

@ Mosu

This happens with all of the seamless branching blurays.

I have now also tested remuxing this by loading the playlist directly in mkvtoolnix: it shows absolutely no information regarding audio skew or dropped frames.

I understand this means mkvtoolnix has a sync issue when seamless branching happens?

Until this is fixed, shouldn't the output display a warning that the resulting mkv will have sync issues to at least let the user know?

Thanks.

[Bigmango]

And here is the output with eac3to.

Eac3to starts a 2nd pass to fix the audio gaps. The result leaves it with only a 1 ms skew.

[a02] Extracting audio track number 2...
[a02] Applying DTS delay...
[a02] A remaining delay of +1ms could not be fixed.
[a02] Creating file "C:\video\[a02] 2 - DTS Master Audio, 5.1 channels, 24 bits, 48kHz, -9ms, English.dtsma"...
[a02] Audio overlaps for 8ms at playtime 0:10:24. <WARNING>
[a02] Audio overlaps for 13ms at playtime 0:28:10. <WARNING>
[a02] Audio overlaps for 12ms at playtime 0:28:52. <WARNING>
[a02] Audio overlaps for 10ms at playtime 0:30:20. <WARNING>
[a02] Audio overlaps for 9ms at playtime 0:32:28. <WARNING>
[a02] Audio overlaps for 13ms at playtime 0:47:37. <WARNING>
[a02] Audio overlaps for 14ms at playtime 0:48:07. <WARNING>
[a02] Audio overlaps for 8ms at playtime 0:53:34. <WARNING>
[a02] Audio overlaps for 5ms at playtime 0:54:14. <WARNING>
[a02] Audio overlaps for 16ms at playtime 0:57:48. <WARNING>
[a02] Audio overlaps for 15ms at playtime 0:58:32. <WARNING>
[a02] Audio overlaps for 6ms at playtime 1:03:14. <WARNING>
[a02] Audio overlaps for 13ms at playtime 1:03:57. <WARNING>
[a02] Audio overlaps for 9ms at playtime 1:09:57. <WARNING>
[a02] Audio overlaps for 15ms at playtime 1:15:54. <WARNING>
[a02] Audio overlaps for 7ms at playtime 1:17:37. <WARNING>
[a02] Audio overlaps for 15ms at playtime 1:18:03. <WARNING>
[a02] Audio overlaps for 7ms at playtime 1:25:54. <WARNING>
[a02] Audio overlaps for 14ms at playtime 1:28:00. <WARNING>
[a02] Audio overlaps for 18ms at playtime 1:35:45. <WARNING>
[a02] Audio overlaps for 11ms at playtime 1:46:52. <WARNING>
[a02] Audio overlaps for 7ms at playtime 1:48:58. <WARNING>
[a02] Audio overlaps for 14ms at playtime 2:32:40. <WARNING>
[a02] Audio overlaps for 21ms at playtime 2:35:15. <WARNING>
[a02] Audio overlaps for 12ms at playtime 2:35:41. <WARNING>
[a02] Audio overlaps for 9ms at playtime 2:40:51. <WARNING>
[a02] Audio overlaps for 7ms at playtime 2:41:06. <WARNING>
[a02] Audio overlaps for 21ms at playtime 2:49:16. <WARNING>
[a02] Audio overlaps for 16ms at playtime 2:58:09. <WARNING>
[a02] Audio overlaps for 7ms at playtime 3:04:40. <WARNING>
[a02] Audio overlaps for 12ms at playtime 3:05:03. <WARNING>
[a02] Audio overlaps for 12ms at playtime 3:05:49. <WARNING>
[a02] Audio overlaps for 12ms at playtime 3:06:15. <WARNING>
[a02] Audio overlaps for 7ms at playtime 3:06:38. <WARNING>
[a02] Audio overlaps for 15ms at playtime 3:06:54. <WARNING>
[a02] Audio overlaps for 11ms at playtime 3:09:14. <WARNING>
[a02] Audio overlaps for 9ms at playtime 3:09:21. <WARNING>
[a02] Audio overlaps for 6ms at playtime 3:09:57. <WARNING>
[a02] Audio overlaps for 19ms at playtime 3:11:19. <WARNING>
[a02] Audio overlaps for 7ms at playtime 3:12:22. <WARNING>
[a02] Audio overlaps for 13ms at playtime 3:12:52. <WARNING>
[a02] Audio overlaps for 15ms at playtime 3:13:11. <WARNING>
[a02] Audio overlaps for 17ms at playtime 3:13:20. <WARNING>
[a02] Audio overlaps for 10ms at playtime 3:13:51. <WARNING>
[a02] Audio overlaps for 8ms at playtime 3:18:50. <WARNING>
[a02] Audio overlaps for 10ms at playtime 3:21:37. <WARNING>
[a02] Starting 2nd pass...
[a02] Realizing DTS gaps...
[a02] Creating file "C:\video\[a02] 2 - DTS Master Audio, 5.1 channels, 24 bits, 48kHz, -9ms, English.dtsma"...

All these ms add up to a lot.... which isn't fixed when remuxing with mkvtoolnix?

[hubblec4]

One more question:

How do you demux, or extract / separate the multiple editions into separate mkv files if need be (for future safe keeping /availability of the separate editions)?

Neither mkvtoolnix nor gmkvextractgui sees the multiple editions contained in the mkv (they only see the first title).

In the Xin1Generator thread is a way discribed.

I never extract from mkv.
The editions are generated while loading a mkv in your player. When the player can interpret the chapters.xml(inside mkv)
then it shows and work.

BUT there are every ONE big video stream(audio and subs too).

[hubblec4]

As I understand, there are no sync issues because you are using eac3to to demux (eac3to fixes sync issues).

This means that when using mkvtoolnix to load the bluray playlist directly there will be sync issues?


No, eac3to will demux the streams only if you use the "BD-demux" button otherwise MKVToolNix-GUI(MTX-GUI) load all m2ts files in order and mux it directly from the BD-structure.

When you load a playlist directly in the MTX-GUI you will never get multi editions mkv's, also not if you all m2ts load manually. The "editions-magic" is a part of the chapters.xml AND the tags.xml.

I could do a bit more for Matroska, but the old song: no player or splitter supports this features.

[mariner]

Greetings Mosu.
Appreciate if you could kindly assist with a problem of wav audio (LPCM) in mkv not recognised by tsmuxer.
Many thanks and best regards.

[markanini]

How can I get MKVToolNix GUI to generate a chapter mark between appended files?

[Mosu]

@ Mosu:


Could you please have mkvtoolnix show some information that there are several editions in the mkv?
as we already have bluray playlist loading in mkvtoolnix, it makes sense to add this multi-edition selection feature directly into mkvtoolnix, so we have complete bluray seamless branching support in mkvtoolnix (with the new GUI, mkvtoolnix now looks like an "MKV Workstation". I think we can definitely see this feature going in there)?


You only see one video track because the editions are solely virtual constructs indicated by the chapters. Each edition in the chapter references different parts of that one video track. I don't have any plans on implementing support for working with editions the same way you work with tracks or something like that as that would take a huge effort and amount of time. Sorry.

[Mosu]

Greetings Mosu.
Appreciate if you could kindly assist with a problem of wav audio (LPCM) in mkv not recognised by tsmuxer.
Many thanks and best regards.

Sorry, but I cannot help you with that. That's tsmuxer's problem.

[Mosu]

How can I get MKVToolNix GUI to generate a chapter mark between appended files?

You cannot as there is no such feature at the moment, and I currently don't have any plans on implementing one – mostly because mkvmerge's flexibility makes it very hard to say where such a mark would have to be put exactly.

[Mosu]

Hey,

I've released MKVToolNix v8.5.0. It contains the usual mix of bug fixes and enhancements, most of them for the GUI but some for mkvmerge, too. Most of these correspond directly to entries in the issue tracker.

There's one small change for package maintainers: there's a new translation of the man pages into Catalan.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-10-17 Moritz Bunkus <moritz@bunkus.org>
* Released v8.5.0.

2015-10-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the cropping parameters contained the "cropping:" prefix twice in the verbose identification output.
* MKVToolNix GUI: merge tool enhancement: when dropping files onto the GUI the last file's directory is remembered as the last directory a file was opened from causing the next open file dialog to start in that directory. Implements #1477 (https://github.com/mbunkus/mkvtoolnix/issues/1477).
* all: new feature: added a Catalan translation of the man pages by Antoni Bella Pérez (see AUTHORS).

2015-10-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: the start and end timestamps in the tree are displayed with nanosecond precision. Implements #1474 (https://github.com/mbunkus/mkvtoolnix/issues/1474).
* MKVToolNix GUI: merge tool enhancement: added a column to the track list containing the state of the "forced track" flag. Implements #1472 (https://github.com/mbunkus/mkvtoolnix/issues/1472).

2015-10-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: pressing the delete key in the attachments list removes the selected entries. Implements #1473 (https://github.com/mbunkus/mkvtoolnix/issues/1473).

2015-10-13 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: if the last directory opened doesn't exist anymore then default to one that does in order to prevent an error message from older Windows versions about a location not being available. Fixes #1438 (https://github.com/mbunkus/mkvtoolnix/issues/1438).

2015-10-10 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: the context menu for the status bar job status counters is now shown when the user clicks with any mouse button, not just the right one. This should make the feature easier to discover. Implements #1396 (https://github.com/mbunkus/mkvtoolnix/issues/1396).
* MKVToolNix GUI: new job queue feature: added an option in the preferences for resetting the warning and error counters of all jobs and the global counters in the status bar to 0 when exiting the program. Implements #1437 (https://github.com/mbunkus/mkvtoolnix/issues/1437).
* MKVToolNix GUI: current job output enhancement: the separator lines for warnings and errors ("--- Warnings emitted by Job … started on … ---") are only shown when warnings/errors actually occur and not for each job that's run.

2015-10-09 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the menus that are currently not shown are disabled properly so that they don't react to keyboard shortcuts anymore. This affected e.g. Alt+J with the English localization as there were three shortcuts active: the "add to job queue" button (if the merge tool is active), the "job queue" menu and the "job output" menu.

2015-10-08 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix (Windows): changed some options for Qt's file dialogs in order to speed up access to network shares in certain situations. Fixes #1459 (https://github.com/mbunkus/mkvtoolnix/issues/1459).

2015-10-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: improved identification output for DTS 96/24. Implements #1431 (https://github.com/mbunkus/mkvtoolnix/issues/1431).

2015-10-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: PCM tracks: if the number of samples per packet varies then no default duration will be written. Fixes #1426 (https://github.com/mbunkus/mkvtoolnix/issues/1426).
* MKVToolNix GUI: merge tool enhancement: added buttons for previewing the character sets for text subtitles read from SRT and SSA/ASS files as well as for chapter files. They're located next to the drop down boxes for the character sets on the input and output tabs.
* MKVToolNix GUI: merge tool enhancement: added buttons next to the 'segment UID', 'previous segment UID' and 'next segment UID' controls that enable the user to select a Matroska file. The GUI reads that file's segment UID and enters its value into the corresponding control. Part of the implementation of #1363 (https://github.com/mbunkus/mkvtoolnix/issues/1363).
* mkvmerge: new feature: The three options that use segment UIDs (--segment-uid, --link-to-previous and --link-to-next) can now read the segment UID of an existing Matroska file. For this the file's name must be given as an argument prefixed with = (e.g. '--segment-uid =some_file.mkv'). Implements #1363 (https://github.com/mbunkus/mkvtoolnix/issues/1363).
* MKVToolNix GUI: chapter editor enhancement: Added another variable to the chapter name templates called <START> which is replaced by the chapter's start timestamp. An optional format can be specified, e.g. <START:%H:%M:%S.%3n> resulting in something like 01:35:27.734. This can be used in the 'generate sub-chapters' or the 'renumber sub-chapters' functionality. Implements #1445 (https://github.com/mbunkus/mkvtoolnix/issues/1445).

2015-10-03 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: If there's currently no source file present when the user drags & drops files onto the merge tool then the GUI will no longer leave an empty, superfluous tab for certain drop modes. Fixes #1446 (https://github.com/mbunkus/mkvtoolnix/issues/1446).
* MKVToolNix GUI: merge tool enhancement: implemented the optional warning before overwriting existing files when starting to mux or adding a job to the queue. The pending jobs in the queue are checked for the same destination file name as well. Implements #1390 (https://github.com/mbunkus/mkvtoolnix/issues/1390).
* MKVToolNix GUI: enhancement: pressing the delete key in the chapter editor and the job queue removes the selected entries. Implements #1454 (https://github.com/mbunkus/mkvtoolnix/issues/1454).
* MKVToolNix GUI: merge tool enhancement: dropping chapter, tag and segment info files from external applications will cause those file names to be added to the appropriate controls on the 'output' tab. Implements #1332 (https://github.com/mbunkus/mkvtoolnix/issues/1332) and 1345.
* MKVToolNix GUI: merge tool enhancement: the feature "default track language" has been split into track languages by type. There are now three separate settings for audio, video and subtitle tracks. Implements #1338 (https://github.com/mbunkus/mkvtoolnix/issues/1338).

2015-09-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: the verbose identification for MP4 files will now derive basic audio parameters of MP3 and AC3 tracks from the bitstream instead of relying on the values in the track headers.

2015-09-27 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: implemented an optional vertical layout mode for the "input" tab in which the track properties are shown below the track list. Implements #1304 (https://github.com/mbunkus/mkvtoolnix/issues/1304).

2015-09-26 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: the "default track flag in output" column wasn't updated properly directly after loading settings.

2015-09-25 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: when browsing for chapter files on the "output" tab the initial directory is the first input file's directory instead of the directory accessed last.
* MKVToolNix GUI: merge tool bug fix: the cropping parameters were not converted into parameters for mkvmerge at all.

2015-09-22 Moritz Bunkus <moritz@bunkus.org>
* all: several ISO 639-2 codes of languages that are very old and not spoken anymore have been removed (e.g. "English, Middle (1100-1500)").
* MKVToolNix GUI: enhancement: on Windows the drop down boxes were elliding overlong text. This has been changed to making the open combo boxes' scroll areas wide enough to contain the whole entries. This matches the behavior of Qt on other operating systems.
* all: fixed the spelling of the AC-3, E-AC-3 and VC-1 codec names.

2015-09-21 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: added context menu entries for opening the selected files/the source files of selected tracks in MediaInfo. Implements #1423 (https://github.com/mbunkus/mkvtoolnix/issues/1423).

2015-09-20 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the interface language selection has been improved not to select wrong entries resulting in error messages from mkvmerge about unknown translations. Fixes #1434 (https://github.com/mbunkus/mkvtoolnix/issues/1434).
* MKVToolNix GUI: bug fix: if the Windows version of the GUI was started from a symbolically linked folder then it would crash when the user added a file. Fixes #1315 (https://github.com/mbunkus/mkvtoolnix/issues/1315).

Have fun.

[Music Fan]

Hi,
I installed version 8.5.0 and I don't find the GUI for MKVmerge, is it abandoned ?
I prefer the ususal GUI than the new one (mkvtoolnix-gui), is there a way to continue with the usual GUI using the new mkvmerge.exe ?

[Mosu]

Yes. No, at least not a supported one.

What I suggest you do instead is to start using the new GUI and telling me what you don't like about it. Maybe you're missing functions from the old GUI that you didn't know exist already in the new GUI? Or maybe trying to do things one way while not being aware that the new GUI offers you other ways, often more effective, to achieve the same result? But please be specific; I cannot do anything with a generic "I don't like it". Thanks.

[ndjamena]

I don't like the layout of the header editor, it was the one thing I wanted changed from MMG but you kept it the same.

Look at the way the "merge" header elements are managed and compare it to the "edit headers" method.

Is there some reason you prefer that particular layout?

[Mosu]

ndjamena: I'm sorry but I don't quite get what you mean. Can you describe in more detail what kind of a layout you'd prefer to see?

What I cannot really do is list all of the properties beneath each other as in the track properties in the merge tool, if that's what you mean. There's way too much text to be displayed for such a layout not to look confusing, I'm afraid.

[Music Fan]

What I suggest you do instead is to start using the new GUI and telling me what you don't like about it.
That's confusing, too different from MKVmergGUI with too many things written and more little windows.
I don't understand why you changed the interface that was clear and to which we were used.

[ndjamena]

Could you put editable track Name, Language, UID, Default and Forced elements in the track root node properties at least, to make them more accessible?

[Mosu]

Because users were requesting several things that weren't possible with the old layout. A really quite common complaint was that the (old) GUI was too high, especially on notebooks with rather low resolution where the GUI wouldn't even fit. Monitors have been getting wider and less high (I had been using 1600x1200 for a long time, but try to get something > 1024 pixels high without going up to 2500x… nowadays), and the old GUI was designed exactly the wrong way around.

However: If you prefer the vertical layout used in the old GUI then with 8.5.0 you can switch the new GUI to a vertical layout, too.

And "too man things written"…? Uhm, excuse me, but what?

I also don't get what you mean by "little windows". Like I said, please be specific.

[Mosu]

Could you put editable track Name, Language, UID, Default and Forced elements in the track root node properties at least, to make them more accessible?

No, sorry, that would make the whole point of a tree-ish layout moot and somewhat confusing. Especially as the fact whether or not the default track flag is present in the file is actually important regarding the interpretation of the value (not present means its effective value is "yes/on" due to the element's default value).

[markanini]

You cannot as there is no such feature at the moment, and I currently don't have any plans on implementing one – mostly because mkvmerge's flexibility makes it very hard to say where such a mark would have to be put exactly.

I was offered a solution here which I'll use for the time being: http://forum.videohelp.com/threads/374776-Q-MKVToolNix-Chapters-and-appended-files?p=2414720&viewfull=1#post2414720

[73ChargerFan]

Yep, that technique works fine with the current release. Thanks markanini!

It'll be very useful to convert extras from blu-ray disks into a single mkv. I've tried manually creating chapter files for this, but they're always off by half a second here, half a second there.

[ndjamena]

To use your own argument against you, if I'm processing movie subtitles and copying "names" from one file to the next, I don't have enough vertical real estate to have more than two subtitles tracks expanded at a time without maximising the entire window. Not to mention the fact that it's difficult to blindly search and select the correct one given the current layout. There's no indication from the outside which subtitle has any particular name and after expanding the tracks the name nodes are so far apart that fitting them on the screen and finding them is a pain.

At the same time there's a whole lot of real estate in the bottom right that's just been wasted on emptiness.

Checking the UIDs of each track is difficult too, you have to expand each and every one and hunt down the UID nodes.

The layout is just difficult, I don't pretend to know what you're trying to accomplish or what a better solution would be but...

[Mosu]

If the problem is finding the right track to modify then I can probably make that easier without a lot of work (which re-working the whole layout would require).

In the tree I already include the CodecID. In the same spirit I can incorporate more information, probably in the form of real columns and not just as text in the first column. Track name, UID, codec ID, default track flag, video resolution/audio sampling frequency & number of channels come to mind.

[ndjamena]

As long as I can copy from there that would be an improvement.

How difficult would providing a dropdown box with a list of custom entries to choose from in the name section be? Too hard?

I won't be too pedantic about it, it's just that I accidently deleted my batch script that renamed the tracks and now I'm stuck using the Header Editor until I can pull something together to replace it. Not that I was happy about it before then or even before the new GUI.

[Mosu]

You won't be able to copy from those columns, no, but I think I'll do something in addition to those columns: I'll add some more information on the track's page and enable mouse selection for those entries. So your workflow could look like this: determine the track to click on by looking at the various columns in the tree view, click on that track's entry in the tree, select the name on the right, copy.

You can already customize which columns are shown in other views by right-clicking on the column headers; the same mechanism will apply to the tree view in the header editor, too.

The header editor wasn't built for mass-modification. That's the domain of mkvpropedit, much like mass-muxing is the domain of mkvmerge and not of the GUI. Instead the header editor's current design is to be precise in how it represents the file's content and to allow the user to do exactly what (s)he wants to – e.g. remove element XYZ.

I may implement a whole different editing mode in the future that's more along the lines of a tabular view of editable fields for everything, but that's not that easy to implement. Other things in the GUI will have higher priority for me, though.

[ndjamena]

I've already created simpler batch scripts for TV shows with hard coded values, the problem is every cinematic movie is unique and needs more complicated routines to help fill them in, hence the manual copy/pasting at the moment.

[Fullmetal Encoder]

...and I currently don't have any plans on implementing one – mostly because mkvmerge's flexibility makes it very hard to say where such a mark would have to be put exactly.

How so? Assuming they aren't corrupt don't video files begin with an I-frame? So couldn't a blank chapter be attached at the beginning of each file segment that's being appended just prior to the appending process? That way each chapter would begin precisely on an I-frame and when multiple files with blank chapters are appended MKVToolNix GUI automatically adjusts the starting and ending times of each chapter in the resulting combined MKV. So it seems that the program can already do the bulk of the work, only the way it is now, to achieve the same result, we would have to manually create and attach a blank chapter file to each and every video segment separately before appending. And if a user wanted more fine grained control over where each chapter mark actually begins they wouldn't be using such a feature anyway since it would actually create more work for them by having to edit the starting times in the chapter file of the combined MKV.

This is useful in the case where different video processing may need to be done on separate chapters within say, a DVD, for example. We separate the chapters (or VOBs) perform our processing on the segments then rejoin them back into a single large MKV.

[Mosu]

Like I said, mkvmerge is flexible. There are cases for which such a functionality would be more or less easy to implement: a typical file with a single video track, one or more audio tracks. In such a case the start of the next file would probably be the first video track's timestamp. Oh wait, video tracks actually don't have to start with an I frame (think open GOP), so first I frame's timestamp.

Yeah ok. But what about files with multiple video tracks? Which video track do I use in that case? The first? What if the second one has its "default track flag" set instead of the first one? Which one is actullay the "first" if the user re-orders the tracks so that the second from the source file will be the first in the input file?

Next case: two video tracks in different files (meaning you have four files in total, mux two of them in parallel and append one to each of the other so that the output file will contain two video tracks). Now it's quite possible (likel, even) that one of the video tracks' first file is shorter than the other. So how to I handle that situation? Create two chapter entries? Only one? If only one then the same as the question above applies.

What if you're appending different number of files? Yes, I have had reports from users doing just that: they had three video segments and two audio segments, all of which would end up with the same total length. Imagine a situation with two video tracks and different number of segments. Same question as above: where should it create chapter markings?

mkvmerge appends on a track-by-track basis, not on a file-by-file basis. That's what makes it incredibly flexible. But it also means that such new functionality requires a lot of thought in order to get it right, and a lot of effort to implement and test properly. I'm not willing to invest that time. I would love for someone to step up and offer code for this, but my experience from the past is that apart from minor bug fixes people only contribute to MKVToolNix in the form of translations, not code. That's quite OK, but that also means that I'm the only person to implement new features, and my time is limited. So please respect that I sometimes simply don't _want_ to tackle an issue, even if it would fit into its scope and design. Thanks.

[Mosu]

As long as I can copy from there that would be an improvement.

I've implemented both changes that I've talked about. Here's the corresponding ChangeLog entry:

* MKVToolNix GUI: header editor enhancement: several track
properties like name or language are shown as columns in the tree
for easier distinction between tracks. They're also shown on the
overview page on the right when that track's entry is selected in
the tree. The text in the labels on this overview page can be
selected with the mouse for copying & pasting elsewhere.

Identifying which track to click on and copying & pasting the track name will be easier with these changes, and I hope they can help you with your workflow a bit, too.

A small tip: you can select the whole label for a property by triple-clicking on it, even across spaces and other non-word characters.

I'd appreciate some testing & feedback. You can get new pre-builds from here (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/); build numbers 986 and higher contain the change.

How difficult would providing a dropdown box with a list of custom entries to choose from in the name section be? Too hard?

If you don't need all those columns then remember you can hide them by right-clicking on the column labels (or re-order them via drag & drop). Those changes are remembered across restarts, of course.

[ndjamena]

I got half way through my current batch before I found the first movie that it turned out to be useful. It does help. I remember even before deleting my batch having to have MediaInfo and the MMG Header Editor open at the same time so I could copy/paste track names at least this is better than that.

Oh, right, one thing I've always noticed was missing in the header editors was the ability to simply remove the header for a track completely like MakeMKV does with empty forced tracks. At the moment I'm just setting the subtitles I don't want to "fre" so that they'll be removed when I remux them but nuking the header completely would be better.

Would that be something you'd be willing to implement or would that be too dangerous? Do players generally care if they come across blocks for tracks they can't identify?

( Sword and the Stone has both normal and SDH forced tracks... I'm currently trying to figure out what the hell to call the SDH one... English Translations SDH - PGS..? Maybe I should have been calling the SDH tracks "English Main SDH - PGS", then I'd already have a protocol in place for when I'm ripping SDH commentary tracks... English (UK) Translations SDH (CC) - PGS )

*sigh*

[Mosu]

Thanks for the feedback, ndjamena.

Oh, right, one thing I've always noticed was missing in the header editors was the ability to simply remove the header for a track completely like MakeMKV does with empty forced tracks. At the moment I'm just setting the subtitles I don't want to "fre" so that they'll be removed when I remux them but nuking the header completely would be better.

Would that be something you'd be willing to implement or would that be too dangerous? Do players generally care if they come across blocks for tracks they can't identify?

To be honest I don't know of a player that would choke on finding content for a track number for which corresponding track headers exist, but I'd rather not risk it. My past experience with Matroska players (especially with hardware devices) is really bad – the slightest problem (more likely: unanticipated situation) can throw them off. If I provide such a mechanism then I'm more or less condoning the creation of invalid files, or ones whose validity is highly questionable.

Note that mkvmerge will emit a warning for each block group for which no corresponding track header was found as such a situation usually indicates file corruption.

Can't you just set the Enabled flag of those tracks to 0?

[ndjamena]

That's interesting, MPC-HT actually obeys the enabled flag. Nothing else does.

Really I'm just looking for a way to tell a remuxer NOT to remux the track, my batch used to rename them as "###REMOVE###", but that only works when used alongside my remuxing batch. MediaInfo doesn't read the enabled flag so, that's no good. Interestingly both MKVToolNixGUI AND MakeMKV can remove tracks automatically based on language, it's just that nuking the header would be more efficient and I wouldn't have to look at them. It doesn't help that I feel like I'm insulting any language that I happen to select for the purpose.

It's not important.

[SeeMoreDigital]

My past experience with Matroska players (especially with hardware devices) is really bad – the slightest problem (more likely: unanticipated situation) can throw them off.Indeed...

There are more hardware playback devices than ever capable of supporting the Matroska container, including televisions. And TV manufacturers are pretty bad at offering updates when third-party software developers decide to change the way their software's function.

It's bad enough getting TV manufacturers to support YouTube app changes :eek:

[Mosu]

I've released MKVToolNix v8.5.1 only four days after 8.5.0. The reason is that Cisco's Talos Research Group has found several cases of invalid memory access and instances of freeing memory twice in libEBML (TALOS-CAN-0036, TALOS-CAN-0037). The consequences range from heap information disclosure to denial of service.

Those issues have been fixed along with some more cases of invalid memory access discovered while investigating the TALOS-CAN reports. New releases of libEBML (v1.3.3) and libMatroska (v1.4.4) were made yesterday (http://lists.matroska.org/pipermail/matroska-users/2015-October/006985.html). Today's release of MKVToolNix incorporates both updated libraries, and its build system requires at least those versions if you want to use globally-installed copies.

As MKVToolNix and therefore both libEBML and libMatroska are often used to process content from arbitrary sources I highly recommend everyone to upgrade.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-10-21 Moritz Bunkus <moritz@bunkus.org>
* Released v8.5.1.

2015-10-20 Moritz Bunkus <moritz@bunkus.org>
* build system: libEBML v1.3.3 and libMatroska v1.4.4 are now required due to important fixes for invalid memory accesses in those two releases. The copies included in the MKVToolNix source code have been updated to those releases as well.

2015-10-19 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the "save file" dialogs did not have the currently entered file name pre-selected anymore. Fixes #1480 (https://github.com/mbunkus/mkvtoolnix/issues/1480).
* MKVToolNix GUI: header editor enhancement: several track properties like name or language are shown as columns in the tree for easier distinction between tracks. They're also shown on the overview page on the right when that track's entry is selected in the tree. The text in the labels on this overview page can be selected with the mouse for copying & pasting elsewhere.

2015-10-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed a crash when loading corrupted job settings.
* MKVToolNix GUI: header editor bug fix: the tree items weren't re-translated when the GUI language was changed.
* mkvmerge: bug fix: updating the track headers wasn't working in some rare cases (corresponding error message "Re-rendering track headers: data_size != 0 not implemented yet").

2015-10-17 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix (Linux): the function "open folder" was inserting a superfluous leading slash in the directory name. This causes some file managers (in this particular case Dolphin on Linux) to interpret a directory name like "//home/mosu/…" as a share called "mosu" on a Samba/Windows server called "home" and to prepend the whole name with the "smb://" protocol. Fixes #1479 (https://github.com/mbunkus/mkvtoolnix/issues/1479).

Have fun.

[Atak_Snajpera]

Question: Is there any reason why you don't use ULTRA preset in 7-zip while compressing portable version? Your 7z file is 15,5 MiB but with ULTRA preset you can reduce size even down to 11 MiB.

[Mosu]

The reason is that I don't care that much about the size. It already takes too long to compress the archives, especially when I build ten or twelve a day.

[ndjamena]

Can I just voice a minor annoyance.

When MKVToolNixGUI informs me that a new version is out it gives a link to the download page here:

https://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows

That's not the actual link it provides, it would be nice if it would automatically append the #windows bit (or appropriate OS).

But that's not the problem. The problem is that page gives four separate versions to download, and of course each time I get there I sit and take the time to figure out which one I need to click, effort which is ultimately wasted because all four links go to the same page.

http://www.fosshub.com/MKVToolNix.html

And then I have to repeat the process again to begin the download. I feel like a sucker each time...

Since they all go to the same place anyway, would it be too much to ask for one, single, clearly marked download link so I don't have to feel like I'm playing mind games with the website?

[Atak_Snajpera]

The reason is that I don't care that much about the size. It already takes too long to compress the archives, especially when I build ten or twelve a day.

I do not know what you have there but difference between Normal vs ULTRA on my cpu is only 2 seconds (15s vs 17s). 7-zip most of the time uses only two cores while compressing mkvtoolnix so you do not need expensive i7 cpus at all.

[Mosu]

Atak_Snajpera: When I said that I don't care about size then I meant that I haven't even tried to measure it. Because I don't care about the size.

[Mosu]

ndjamena: Well, that was easy to change. Done.

[Jamaika]

OK. I understand now that "zlib" is an addition to advertising. Indeed, these are trifles finishing, which need a bit more memory when displaying subtitles. I wanted to ask, is it possible to pack text in global-tags.xml?

[Mosu]

Uhm… what!? I honestly don't understand you're talking about, never mind what you're actually asking, Jamaika.

[Jamaika]

Uhm… what!? I don't understand you're reading about, Mosu. I thought talking about functions --compression zlib. Good night.

[Mosu]

If you're asking whether or not you can compress tags: you can't. The Matroska spec only has provisions for compressed track content.

[Jamaika]

I am surprised, because in the container ASS are additives fonts and images. They can be encoded and aren't track content.

[Mosu]

Matroska doesn't care about the _content_ of attachments. Its interpretation is up to the application using those attachments. If an applications supports using e.g. attached compressed fonts then that's great, but Matroska doesn't have anything to do with that.

[Mosu]

Question: Is there any reason why you don't use ULTRA preset in 7-zip while compressing portable version? Your 7z file is 15,5 MiB but with ULTRA preset you can reduce size even down to 11 MiB.

Looks like I was wrong. There obviously was a time when I cared about this enough to devise the following options for compression:

-t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on

I'm pretty sure that this is from back when 7z didn't support lzma2. I'll replace all of those by -mx=9 which means that my current p7zip will default to lzma2 achieving better compression.

[Carpo]

think you need to add -m0=lzma2 to make it use lzma2, don't think -mx9 on its own selects it, unless the newer 7zip 15.x version has changed it, still using 9.20 myself

[Mosu]

p7zip 9.38 beta here, and the docs have this to say about -mx=…:

x=[0 | 1 | 3 | 5 | 7 | 9 ]

Sets level of compression

Level Method Dictionary FastBytes MatchFinder Filter Description
0 Copy No compression.
1 LZMA2 64 KB 32 HC4 BCJ Fastest compressing
3 LZMA2 1 MB 32 HC4 BCJ Fast compressing
5 LZMA2 16 MB 32 BT4 BCJ Normal compressing
7 LZMA2 32 MB 64 BT4 BCJ Maximum compressing
9 LZMA2 64 MB 64 BT4 BCJ2 Ultra compressing

Note: "x" works as "x=9".

A short test confirmed that "-mx=9" and "-mx=9 -m0=lzma2" produce identical results.

[Carpo]

Ah well, as long as it works :)

[Mosu]

My thoughts exactly :)

[magsoud]

Please Add Use Registry to store Settings...

[Mosu]

If you use the installed version then the settings will be stored in the registry. That's the main point for a portable version: it doesn't store settings in the registry allowing you to have the full installation on a portable device.

[magsoud]

If you use the installed version then the settings will be stored in the registry. That's the main point for a portable version: it doesn't store settings in the registry allowing you to have the full installation on a portable device.
Settings Store to:
"%LocalAppData%\bunkus.org\mkvtoolnix-gui\mkvtoolnix-gui.ini"

[Mosu]

Ah you're right. Earlier versions used to store to the registry. I changed that intentionally due to performance reasons. I see no reason to change that back.

[foxyshadis]

magsood, what's the use case of changing to registry vs. known file for settings?

[Altober]

Hi:
Like always... Thanks! For your great software and for your time for answers questions here.

My problem is this:
I have a shared folder in local LAN for can access through Smart TV or any Android device (Smartphone, Notebook, Tablet, etc).

I like so much watch video series from my bed :)
Well, my problem is... All my MKV videos maked for older versions I can watch through my LAN, is NOT necessary the video copy to my portable (Android) device.
But when I try to play my MKV videos maked with new MKVtoolnix versions always I obtain "Is impossible to play this video".

I try with many (the bests) Android Video Players (MX Player, VLC, etc)

First I think in some error in MKV file, then I proceed to copy these videos to my portable Android device, then YES, I can watch this videos.

Is very important to me can access directly to my MKV videos, without copy this videos to my device, but I not understand where is the problem.

I hope you can help me.
Thanks So Much

Edit (New Data):
I have downloaded Supernatural Episode (mkv file, of course) with mkvmerge v8.4.0 ('A better way to fly') 64bit / libebml v1.3.1 + libmatroska v1.4.2
And I CAN watch trough LAN net wihout problems...

But I have previous episode maked with the same mkvmerge version (v8.4.0 ('A better way to fly') 64bit / libebml v1.3.1 + libmatroska v1.4.2)
AND NOT, impossible to watch... The problem are the videos re-processed by me :-(

I can see some "rare here"
Downloaded Video
Lenght: 41 minutes
1.70Gb

NUMBER_OF_FRAMES: 78035
NUMBER_OF_BYTES: 119861760


Re-Processed Video
Lenght: 43 minutes
2.02Gb

NUMBER_OF_FRAMES: 541
NUMBER_OF_BYTES: 16511


O_O "My" video have VERY few frames and very few bytes!!
Really I don't understand. I think this could that be the problem? Really I don't know.

[sneaker_ger]

Try:
Go to output tab, add additional options (bottom right): --clusters-in-meta-seek --engage no_cue_duration --engage no_cue_relative_position

That way output is more like that of older versions and works in most players.
For further information see https://github.com/mbunkus/mkvtoolnix/wiki/Improving-playback-compatibility-with-players

If that isn't enough compare working and non-working files in MediaInfo and look for differences.

[Altober]

Thanks sneaker_ger:
No, unfortunately I made a new MKV video from "working MKV" (Of course I save original video in another folder)... and not.
Not work.
I have Mediainfo date, some differences are in "Edit" section of my original message.
If you want (and if is possible) I can upload complete Mediainfo information of "work" and "no-work" videos.

My doubt is because this board not can (or I not found) Spoiler function, and Mediainfo have too much text :confused:

Thanks for your help

Edit
The answer to my problem is very close...
I obtain the same MKVToolmix version that already I have, but in portable version
I proceed to make a "working" MKV and the new MKV work too.
Now I have "one to one" the checked options for found the "problematic" option.

[ndjamena]

What are you using to look at the Tags?

MediaInfo applies tags to the wrong tracks (or to the file) if UIDs don't match Track Numbers.

FFProbe is the best way of looking at tags I know of.

[Jamaika]

First, you can examine and separate tracks old movie for the help MKVextract. Followed merge the latest muxer v8.5.1.
If this doesn't help, put mkvmerge and reapply the latest ffmpeg. It should be fine.

[NailBomber]

Apologies if that's an incorrect thread to ask for help.

I have a recorded stream of youtube that's according to MediaInfo is MPEG-TS container with AVC video inside. The video has a seeking problem and wrong duration. Until this point I fixed such videos by remuxing them through MKVToolNix into a mkv, but this time I got a new problem when viewing resulting mkv - gray block artifacts: http://s013.radikal.ru/i325/1510/af/7d1a62646eac.jpg

Is there options in MKVToolNix I can use to remove such artifacts or is the video unsalvageable?

[magsoud]

one suggestion for MKVtoolnix:
When we click on "Start muxing", automatically displayed "job output" page.

[Mosu]

Preferences → "GUI" tab → "Jobs and job output" → "Always switch to the job output tool after starting one immediately"

[magsoud]

Preferences → "GUI" tab → "Jobs and job output" → "Always switch to the job output tool after starting one immediately"
Thanks Mosuhttp://i47.tinypic.com/2dvsw2p.gif

[Mosu]

Hey,

Here's another release of MKVToolNix, v8.5.2, a couple of days after 8.5.1. This time a bug in the HEVC/h.265 handling has been fixed that quite a lot of users seem to be hitting.

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-11-04 Moritz Bunkus <moritz@bunkus.org>
* Released v8.5.2.

2015-11-03 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the file/track columns aren't resized to fit their content when expanding/collapsing tree nodes anymore. Such expansion also happened when moving entries with the "move up/down" buttons. Fixes #1492 (https://github.com/mbunkus/mkvtoolnix/issues/1492).
* mkvmerge: bug fix: fixed the values of the "previous/next segment UID" elements when splitting by parts with segment linking enabled. Fixes #1497 (https://github.com/mbunkus/mkvtoolnix/issues/1497).
* mkvmerge: bug fix: mkvmerge no longer creates a "next segment UID" field in the last file when splitting and segment linking is active.

2015-10-22 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, MKVToolNix GUI header editor: enhancement: added the "codec delay" track header field as an editable property.
* mkvmerge: bug fix: fixed an endless loop when updating track headers caused by the fix for "Re-rendering track headers: data_size != 0 not implemented yet". Fixes #1485 (https://github.com/mbunkus/mkvtoolnix/issues/1485).

Have fun.

[mariner]

Sorry, but I cannot help you with that. That's tsmuxer's problem.

Thanks for the kind reply, Mosu.

Raw PCM audio is detected by mkvmerge as video. Is it supported?

[Mosu]

No, it isn't. It must be in a container, e. g. WAV.

[mariush]

Mosu.. if i may make a small suggestion. Maybe you could add an option or something to show the properties panel in mkvtoolnix gui in two columns instead of a huge single column that often requires scroll. In today's world where people have 16:9 monitors with lots of horizontal width, the gui is stuck at about 950 pixels minimum width.
I'd say probably 80-90% of the people out there have at least 1366x768 displays so you could stretch the minimum width a bit, or make a horizontal scroll bar at the bottom of the properties section.


I know about "use a vertical layout for the input tab" in the options, but if enabled I'd say it's a tradeoff or even a step backwards because now user has to click on each of those 5 tabs to see what he can change, while before he could see everything with a scroll.

Here's a quick mock-up in mspaint of what I mean : http://savedonthe.net/image/2456/example.png

In the picture, the width is 1351 pixels which is a bit much, but if the verticall scrollbar for the properties is removed and the individual columns are just a bit squeezed, it may even fit on 1280x800 lcd displays without resorting to horizontal scrollbar.

The height will also not be a an issue, right now the gui goes down to 650 pixels and the layout in the picture would only need 30-50 pixels more, still safe for 768-800 pixel high monitors.

[Mosu]

Thanks for the suggestion. That idea isn't half bad. I'll think about it.

[73ChargerFan]

I LOVE SPLIT BY CHAPTERS! I submitted issue #1500 on GitHub because it split a little bit early and also each file except the last incorrectly included the first chapter name from the following file.

[LeMoi]

When I open a mtxcfg file directly by double-clicking on it, it opens the MKVtoolnix GUI with 2 tabs, one empty and the other one with the config file. Is it possible to make only the configured tab open, and not an empty one next to it?

[Mosu]

Possible? Sure, but that's a purely cosmetic issue. Please don't expect a timely fix, and please open an issue on Github for it – otherwise it will likely be forgotten.

[LeMoi]

I'll do, thanks in advance.
And would it be also possible to make the Ctrl-F4 shortcut close the current tab? I like using shortcut, and i noticed that this one doesn't close the current tab!

[Mosu]

You can close the current tab with Ctrl+w.

[ndjamena]

http://forum.videohelp.com/threads/375118-MKVToolNix?p=2418063&viewfull=1#post2418063

:)

[LeMoi]

You can close the current tab with Ctrl+w.

Thanks for the tip!

[ndjamena]

Now that MediaInfo should be getting proper tag handling in the next version...

What's the chance of adding a mode in MKVInfo or MKVPropEdit that adds the statistics tags to files that otherwise have none... just for the benefit of those people who chose to remove them or are using mkvs from a different muxer.

It would be nice when people start complaining on forums to be able to give them a method to add the tags that doesn't involve recreating the entire file.

[Mosu]

Hmmm sounds somewhat useful, though I highly doubt a lot of people would actually use it. But I'm willing to implement it in the future. If you want something like that then please open an issue on Github (https://github.com/mbunkus/mkvtoolnix/issues/) for it; otherwise I'll likely forget about it again. Thanks.

[ndjamena]

I'm currently attempting to write in the chapter names for the extended editions of The Lord of the Rings...

Is there a good reason the focus keeps returning to ChapterTimeStart when I press enter to move to the next chapter?

I'd rather it stayed where I left it.

[Mosu]

Different people prefer different workflows.

Often you generate a lot of chapters first (or import them from a DVD) and adjust all their timestamps or names in one go (sounds like what you're trying to do). On the other hand other people prefer to generate chapters once and then they want to tweak each entry (requiring to change both the timestamp and the name, then go to the next chapter entry, rinse & repeat).

The GUI supports both workflows. It defaults to supporting the second kind of workflow: when you press enter you move from the timestamp field to the name field. If the focus is already on the name field then the next chapter entry is selected and that entry's timestamp field is focussed.

However, in this mode you can also press Shift-Return. This causes the GUI to select the next chapter entry no matter where the focus currently is and to keep the focus in the same field.

And that's your answer. Either press Return twice or Shift-Return once; both will result in what you want to achieve.

[ndjamena]

How long do we have to wait for a pre with the VC-1 fix?

[mariner]

No, it isn't. It must be in a container, e. g. WAV.
Thanks again, Mosu.

[Mosu]

How long do we have to wait for a pre with the VC-1 fix?

FYI: I often find your style of asking questions to be a bit offensive. For example, I read this question as you thinking I have some kind of obligation to provide pre-builds in a timely manner. That's probably not what you think, but it can come across this way. If you had just asked "Can you please provide a pre-build with the VC-1 fix?" it would have gone over much better.

Here are your pre-builds 1002 and 1003 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/).

[ndjamena]

I think you got it the wrong way around.

I was asking how long I had to wait... and that's exactly what I meant. NOT KNOWING is annoying.

"Can you please provide a pre-build" is asking you to do something, like you have some kind of obligation.

You're inserting sarcasm in what I'm saying that doesn't exist. (Try timidity and helplessness instead.)

[Mosu]

Fair enough, but for the record: asking someone to do something is, to me, the most normal thing on earth. The person is under no obligation to heed the request, therefore there's no pressure (e.g. if I had no time to create one I would simply say so without feeling bad about not having fulfilled the request). And such a question shows your actual desire (you want to have such a build). I wasn't even aware there was a need for such a build; so asking for how long it will take for the build to materialize seems like skipping steps (first communicate the fact that there is such a need).

My whole point was: communication is complicated, especially if it's only text without body language to accompany it, and I wanted to let you know how your question seemed _to me_. Like I said I didn't really think you meant it the way it was received, and it's good to know that it indeed wasn't.

[Boulder]

English is probably not ndjamena's mother tongue so the sentence may sound a bit harsh. "How long do we have to wait" does have a negative tone but it's understandable in that case.

Anyway, "please" is a very useful word no matter what you ask for :)

[beastbg8]

I finally updated it some days ago and i must say: I'm not a big fan of the new GUI. I liked the older one better.

[Mosu]

What exactly don't you like? Are you missing certain features? Do features not use the way you want them to? Do you have a beef with the layout? Do you not understand how to do certain things?

The new GUI can do everything the old GUI can do, but it does things differently. I'd like to help you, but you'll have to be specific with your complaints. I cannot do anything with "I prefer blue over red".

[nada2k]

In the past I saved some .mmg settings files. Is it correct that the new MKVToolNix GUI can not open these anymore?

In the job cue some menu items are available over the "Job queue" menu on top and some over the right-click context menu. Some are exclusive to each menu, some appear in both. Is there a setting to make both menus show the same, combined content?

[Mosu]

In the past I saved some .mmg settings files. Is it correct that the new MKVToolNix GUI can not open these anymore?

That's correct. The new GUI uses a different storage format with different keys and values.

In the job cue some menu items are available over the "Job queue" menu on top and some over the right-click context menu. Some are exclusive to each menu, some appear in both. Is there a setting to make both menus show the same, combined content?

There are no duplicates, even if some of the options look similar. The options in the menu on the top are the ones that operate on the whole queue. The ones in the context menu operate on the ones that are selected when you open the context menu.

For example, the context menu option "Remove jobs" removes then ones that are currently selected whereas the main menu option "Remove completed jobs" removes all jobs that have been completed regardless of their current selection status.

Another example: "Start pending jobs" from the main job queue menu sets all jobs to "start automatically" that are currently in state "start manually". Whether or not they're selected doesn't matter. On the other hand the context menu option "Start jobs automatically" sets the status of all selected jobs to "start automatically" no matter what their current status is (which means that you can use this option to re-enable particular jobs that have already been completed).

It's easy enough to remember: do you want to manipulate the currently selected job(s)? Then use the context menu. Otherwise you'll find the corresponding option in the main job queue menu.

See also this related wiki article (https://github.com/mbunkus/mkvtoolnix/wiki/The-job-queue,-statuses-and-their-actions) about "The job queue, statuses and their actions".

[magsoud]

MKVtoolnix not show about This errors and warnings (Show in image):
Please Fix This!

[LeMoi]

Some dialogs need (at least French) translation, like overwriting confirmation, for example.

EDIT : never mind, looks it's been fixed in latest version

[bin_ch]

I love the new GUI. Particularly for it showing the properties on the right side as a single scrollable widget. With the old mmg, I had to switch between tabs to set different options. I am just wondering is it possible to assign all the properties options with access keys (the underlined letters)? That would make jumping betweeen options even faster. Currently, access keys are only available for the top three options (Mux this track, Track name, Language).

Also, I sorta miss the "Copy to clipboard" button. Currently in the new GUI, one wants to copy the command line options has to go to Merge menu --> Show command line --> Copy to clipboard. I can understand it may not deserve a dedicated button in the main window because it's not very frequently used for normal users. But I personally often use it. What do you think about adding an entry under Merge menu (say, above/below "Show command line", like in mmg)?

Thank you.

[Mosu]

I love the new GUI. Particularly for it showing the properties on the right side as a single scrollable widget. With the old mmg, I had to switch between tabs to set different options. I am just wondering is it possible to assign all the properties options with access keys (the underlined letters)? That would make jumping betweeen options even faster. Currently, access keys are only available for the top three options (Mux this track, Track name, Language).

Unfortunately assigning more hotkeys isn't as easy as one might hope. The whole "merge" tab dialog is a single form, and Qt's Creator tool doesn't really allow me to re-use the same hotkeys on different tabs. Some are silently changed whenever I make a change, and I don't want to have to fight the Qt Creator each time I edit the form.

Additionally there are so many options that selecting distinct hotkeys for all of them isn't even possible.

Also, I sorta miss the "Copy to clipboard" button. Currently in the new GUI, one wants to copy the command line options has to go to Merge menu --> Show command line --> Copy to clipboard. I can understand it may not deserve a dedicated button in the main window because it's not very frequently used for normal users. But I personally often use it. What do you think about adding an entry under Merge menu (say, above/below "Show command line", like in mmg)?

Nothing, to be honest. That would only move it one layer up and not improve your situation much. And you're right, copying to the clipboard is something that few people do regularly.

You seem to be a keyboard user. Why don't you memorize the hotkeys you need to press for copying to the clipboard? After doing it a couple of times pressing them should become somewhat automatic. For the English version it's Alt+M, h, Alt+O, Alt+C. You can even use Alt+H in the second step, so you don't even have to take your finger off Alt. Basically: Press and hold Alt, then hit m h o c in sequence. Release Alt.

[bin_ch]

Unfortunately assigning more hotkeys isn't as easy as one might hope. The whole "merge" tab dialog is a single form, and Qt's Creator tool doesn't really allow me to re-use the same hotkeys on different tabs. Some are silently changed whenever I make a change, and I don't want to have to fight the Qt Creator each time I edit the form.

Additionally there are so many options that selecting distinct hotkeys for all of them isn't even possible.
I see, didn't know the technical details.



Nothing, to be honest. That would only move it one layer up and not improve your situation much. And you're right, copying to the clipboard is something that few people do regularly.

You seem to be a keyboard user. Why don't you memorize the hotkeys you need to press for copying to the clipboard? After doing it a couple of times pressing them should become somewhat automatic. For the English version it's Alt+M, h, Alt+O, Alt+C. You can even use Alt+H in the second step, so you don't even have to take your finger off Alt. Basically: Press and hold Alt, then hit m h o c in sequence. Release Alt.
True. After imagining the workflow now I completely agree, three keystrokes indeed isn't too much different than five.

Thanks for the reply, and the new GUI.

[dansrfe]

It would be great to select/deselect by en-masse highlighting in the tracks, chapters, tags, and attachments section. For example to deselect a long list of subtitle streams.

[foxyshadis]

It would be great to select/deselect by en-masse highlighting in the tracks, chapters, tags, and attachments section. For example to deselect a long list of subtitle streams.

All the usual text selection shortcuts work, along with the context (right-click) selection options. Maybe a shortcut and option for invert selection would be useful? Or perhaps being able to sort by the track headings, making it easy to use shift to select the right things.

[dansrfe]

All the usual text selection shortcuts work, along with the context (right-click) selection options. Maybe a shortcut and option for invert selection would be useful? Or perhaps being able to sort by the track headings, making it easy to use shift to select the right things.

Right, the right-click menu as is applied actions to the entire set of tracks, regardless of the subset of tracks which have been highlighted. The space-bar shortcut working with with a subset highlight would be nice as well.

[Mosu]

dansfre: use the right-click menu to select e.g. all subtitle tracks, then use the "mux this track" drop down on the right to toggle the state for all of the selected ones.

You're right about the space key only toggling the one track that's currently focussed. This should work on all selected tracks, and I'll fix it accordingly.

See also this short introduction video (https://www.youtube.com/watch?v=QET-MifgJLM) for selecting and changing multiple tracks at once.

[Mosu]

Oh wait, space isn't supposed to toggle all, that's what Enter/Return is there for. Space is supposed to work on the current one only.

[LeMoi]

I have 698 MB MKV file muxed with mkvmerge 7.9.0 5 months ago. I want to replace two audio tracks (LC-AAC 6ch, each one is 104 MB) with tow other ones with the exact same bitrate (160 kbps, both tracks have exactly the same size as the ones I want to replace).
When I mux the file with latest MKVToolnix, the result file is 707 MB!! And if I just remux the original file without unchecking or adding any track, the file is 704 MB!!
Is there a reason why the new version adds those MB?

[Mosu]

There are a couple of potential reasons, e.g. differences in how cues were created, or maybe the original muxer packed frames together in an illegal way (which mkvmerge doesn't). But that's all guesswork. Can you please create four files with mkvinfo and upload those to my FTP server (https://github.com/mbunkus/mkvtoolnix/wiki/FTP-server) so that I can analyze them? I'll need:

mkvinfo -v -v --redirect-output original-vv.txt original.mkv
mkvinfo -s --redirect-output original-s.txt original.mkv
mkvinfo -v -v --redirect-output remux-vv.txt remux.mkv
mkvinfo -s --redirect-output remux-s.txt remux.mkv

original.mkv is the orignal file you're trying to remux/change audio tracks in, and remux.mkv is the file after remuxing without changing anything (no audio tracks removed/added).

Thanks.

[LeMoi]

Remuxing with 8.3.0 resulted in a 698 MB file too. I'll upload the files on your server so that you can analyze them

[Mosu]

Your original file uses content compression (zlib compression) for the VobSub tracks; your remuxed file doesn't. Hence the bigger files.

[LeMoi]

I dind't change any setting, shouldn't zlib compression be enabled by default?

[Mosu]

Depends on your settings in the GUI ("Preferences" → "Merging" → "Disable additional lossless compression for all track types"). That setting is off by default (https://github.com/mbunkus/mkvtoolnix/blob/master/src/mkvtoolnix-gui/util/settings.cpp#L151), meaning that in a new installation the GUI will leave the setting on its default causing mkvmerge to use zlib compression for VobSub tracks.

The command-line mkvmerge uses zlib compression by default, too.

[LeMoi]

So since I began using the new GUI, all the files I muxed didn't have this (zlib) compression, since I didn't change that default setting? And if I remux a file in which tracks have this compression, if I don't enable it in settings, i'll lose this compression?
Can't you make the GUI keep the compression of tracks in files when you remux them?

[sneaker_ger]

You did change the defaults, that checkbox is not ticked by default. If the box is not ticked all idx/sub and pgs tracks will be compressed using zlib regardless of the source file. If the box is ticked all idx/sub and pgs tracks will be uncompressed regardless of the source file.

[LeMoi]

Thanks for the explanation, I just wanted to be able to keep track settings when I remux a file regardless of the default options, I wanted these options to concern new muxings only.
I don't remember unchecking this option, but maybe I did some weeks ago not knowing what it means!

[Mosu]

You misunderstood me.

If that option is [ ] unchecked then mkvmerge WILL use zlib compression. The default for new installations is to leave the option [ ] unchecked. Therefore a new installation WILL use zlib compression.

The option exists for people whose players DON'T support zlib compression. Those people can [✓] check the option and then mkvmerge will NOT use zlib compression.

So if the option is [✓] checked for you then you've enabled it manually sometime in the past.

[LeMoi]

That's why I understood.
I don't really remember, but maybe i checked this box some years ago when video compression was not compatible with some software or hardware players. But as far as I remember, i was still using subtitles compression, maybe when I updated to the new GUI, it also disabled the compression for every type of tracks. That could explain why my subs tracks are bigger then they used to be some weeks ago when I was still using the old GUI ^^

[ndjamena]

I'm currently looking at working on fixing MediaInfo's handling of seek heads at the very ends of files, but I no longer have any examples to work with.

Is there any way of doctoring a file with that configuration or am I stuck playing around with MKVPropEdit until something works out?

[sneaker_ger]

mkvmerge --clusters-in-meta-seek?

[Mosu]

Is there any way of doctoring a file with that configuration or am I stuck playing around with MKVPropEdit until something works out?

This is actually pretty easy to achieve if you know how. First create a Matroska file; content doesn't really matter, e.g. a single track will suffice, but don't add any attachments.

Next take a look at it with mkvinfo. You should notice an EbmlVoid element located directly behing the seek head. For example this is how a file I've just created looks:

…
+ Segment, size 3970442
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4029)
|+ Segment information
…

Now all you have to do is use mkvpropedit to add a new attachment that'll fit into that void. Use any small text file, a couple of bytes will suffice. Just don't use anything too close to the void's size as there are some more elements like attachment name and attachment MIME type that'll be added as well.

The result is that the attachments will be written into that void. Then mkvpropedit tries to add a pointer to the attachments element into the existing seek head, but it'll find that it cannot do that as there's no space behind the seek head anymore (that's now occupied by the attachments themselves). Therefore mkvpropedit will create secondary seek head at the end.

TL;DR:

[0 mosu@sweet-chili ~/prog/video/data] ls -l x.txt
-rw-r--r-- 1 mosu vj 1420 Feb 24 2015 x.txt
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o v.mkv v.avi > /dev/null
[0 mosu@sweet-chili ~/prog/video/data] mkvpropedit v.mkv --add-attachment x.txt > /dev/null
[0 mosu@sweet-chili ~/prog/video/data] mkvinfo -v -v v.mkv | sed -e '1,8d' -e '15q'
+ Segment, size 3970521 at 40
|+ Seek head at 52
| + Seek entry at 57
| + Seek ID: 0x11 0x4d 0x9b 0x74 (KaxSeekHead) at 60
| + Seek position: 3970440 at 67
|+ EbmlVoid (size: 37) at 73
|+ Attachments at 119

[ndjamena]

That did it. MediaInfo is now incapable of reading the tags and presumably the cues as well.

Should I assume I need to be capable of reading header elements sandwiched between clusters? There aren't any actual rules as to where anything can go is there?

Things go where ever, and MediaInfo has to read anything a pointer points to?

[Mosu]

The rules players have to follow are pretty simple:

Start reading from the start until you find the first cluster
For each seek head found so far read any other seek head it points to
For each level 1 element found by one of the two steps above read and process those level 1 elements

Now the player is ready to start playing.

Following seek heads that way is only required once, meaning that if there's a seek head A at the start pointing to a seek head B somewhere else and if that seek head B points to yet another seek head C then you only have to process seek heads A and B but not C anymore. mkvmerge does support following an arbitrarily long chain of seek heads but that's purely optional, and none of my tools (nor any other tools I know of) produces a chain of seek heads longer than two.

[Mosu]

Should I assume I need to be capable of reading header elements sandwiched between clusters?

In case my answer above wasn't clear: only if a seek head points to an element sandwiched between clusters. Level 1 elements must be found if they're either located before the first cluster or if they're reachable by a seek head that's located before the first cluster.

You don't have to scan the whole file from start to finish.

[ndjamena]

Sorry, I'm looking at the source code and the assumptions it makes. It follows one pointer, once. The pointer with the lowest value that's higher than the current position in the file, then it reads to the end of the file.

I'm guessing every time it reaches either a cluster or an end of file it needs to look at all the available seeks, check them against where it's already been, and if it finds somewhere it hasn't been, go there and repeat until there's no seeks left.

THEN, start reading the clusters. Now I'm just wondering what's supposed to happen if it comes across a non-cluster element it hasn't parsed before within the clusters. I know the specs say you can put tags there at least.

[Mosu]

Such elements can be ignored if they're not pointed to with seek heads.

[Boulder]

When appending Matroska files, the job output sometimes starts to show things like these after the first part is muxed:

#GUI#progress -12%
#GUI#progress -11%
#GUI#progress -10%
#GUI#progress -9%
#GUI#progress -8%

[Mosu]

Interesting. I cannot reproduce that at the moment. Can you please tell me more about your mux settings? What kind of files are involved, what's appended to where? Ideally you could send me a mux setting file or the corresponding job queue file (https://github.com/mbunkus/mkvtoolnix/wiki/mtxcfg-file-format-and-the-jobQueue). I'd also like to know how big the files in question are exactly.

[Mosu]

Hey,

The next release of MKVToolNix is available: v8.6.0. Like the previous couple of releases this one focuses on bug fixes primarily. However, it also introduces one interesting new feature with support output mkvmerge's identification result as JSON for improved scripting.

There's also an important change breaking backwards compatibility: text files created by the tools (e.g. chapters extracted with mkvextract or redirected output of any of the tools) won't start with a byte order mark (BOM) anymore, even if they're encoded in one of the UTF-* encodings. Back in the day people believed that text files would be encoded primarily in UTF in the future and that distinguishing between those formats automatically with a byte order mark seemed sensible.

Reality has shown that things turned out differently: text files are overwhelmingly encoded in UTF-8 if they originate on Linux/Unix/Mac OS and in Windows' local encoding otherwise. Writing byte order marks isn't recommended anymore anyway.

This is an experimental change in so far as I'm willing to reverse it if enough people speak out for keeping the BOMs. So if you have legitimate concerns about this then please drop me a line.

An important change for package maintainers is that gcc 4.8.0 or newer/clang 3.4 or newer is now required for compilation due to the (header-only) library used for generating the JSON output. This concerns CentOS 6 and Debian 7 "wheezy" for which I don't offer binaries anymore as a consequence.

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

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

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

2015-11-28 Moritz Bunkus <moritz@bunkus.org>
* Released v8.6.0.
* all: change: none of the tools will write a byte-order mark (BOM) to text files encoded any of the UTF-* schemes anymore.

2015-11-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Matroska reader bug fix: the info about which packetizer is used was output twice for each HEVC track. Fixes #1522 (https://github.com/mbunkus/mkvtoolnix/issues/1522).
* MKVToolNix GUI: bug fix: implemented a workaround for a bug in Qt which caused the GUI not to start anymore due to failing to detect a stale lock file if the GUI had crashed before on a computer with a host name that included non-ASCII characters. See https://bugreports.qt.io/browse/QTBUG-49640

2015-11-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: a track's number of bits per audio sample wasn't output in verbose identification mode even if it was present in the file.
* mkvmerge: enhancement: if no seek head is found before the first cluster when reading Matroska files then mkvmerge will attempt a deeper scan of all elements in the file in order to find track headers, attachments, chapters and tags located at the end of the file. See #1513 (https://github.com/mbunkus/mkvtoolnix/issues/1513) for the rationale.

2015-11-21 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: header editor bug fix: the "status" description wasn't adjusting its height properly resulting in its text being cut off. Fixes #1517 (https://github.com/mbunkus/mkvtoolnix/issues/1517).
* MKVToolNix GUI: bug fix: the program changes its working directory to the user's profile/home directory on startup allowing the removal of its installation folder even if a program started by the GUI (e.g. a web browser) is still running. Fixes #1518 (https://github.com/mbunkus/mkvtoolnix/issues/1518).
* ebml_validator: bug fix: elements with an unknown size weren't handled correctly.
* build system: fixed building and linking against libEBML and libMatroska if they're installed in a non-standard location.
* mkvpropedit, MKVToolNix GUI's chapter and header editors: the tools were unable to update elements in files without a seek head present. Fixes #1516 (https://github.com/mbunkus/mkvtoolnix/issues/1516).

2015-11-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two issues causing mkvmerge to write invalid data when updating track headers caused by the fix for "Re-rendering track headers: data_size != 0 not implemented yet". Fixes #1498 (https://github.com/mbunkus/mkvtoolnix/issues/1498).
* all: MKVToolNix now requires gcc 4.8.0 or later or clang 3.4 or later for compilation.

2015-11-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the options for linking to the next/previous segment UID were wrong. Fixes #1511 (https://github.com/mbunkus/mkvtoolnix/issues/1511).

2015-11-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added JSON as an output format for file type identification. It can be activated with "--identification-format json --identify yourfile.ext" (or their short counterparts "-F json -i yourfile.ext").

2015-11-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the VC-1 handlig code was duplicating the first sequence headers with each mux. Fixes #1503 (https://github.com/mbunkus/mkvtoolnix/issues/1503).

2015-11-08 Moritz Bunkus <moritz@bunkus.org>
* build system: bug fix: configure was checking for and using libintl if --without-gettext was used. Fixes #1501 (https://github.com/mbunkus/mkvtoolnix/issues/1501).

Have fun.

[filler56789]

Currently it's impossible to download the Windows builds from the FossHub site,
whenever I click on the links,
all that I get is a page reload :confused:

[Sparktank]

Currently it's impossible to download the Windows builds from the FossHub site,
whenever I click on the links,
all that I get is a page reload :confused:

Try disabling AdBlock and/or other plugins that block content on the site.

I got that at first but when I disabled AdBlock, it gave me the download right away.


---horizontal-line---

Thanks for the updates. :)

It's time I use the new GUI. I've been waiting out a few versions.

[filler56789]

@Sparktank: I don't have AdBlock, and FossHub is on the white list of my NoScript since ages ago.

Fortunately Videohelp does not use too much AJAX faggotry :cool:

P.S.: @Mosu: :thanks: again.

[rsotome]

Is anyone else having this problem with the new 8.6.0 build?

When I drag 'n drop an MKV file that has previously been written to by Haali Matroska Writer b0 (which is what Simple x264/x265 Launcher uses when encoding directly to an mkv file (x264 codec)), MKVToolnix 8.6.0 takes an extremely long time to recognize the file (locks up for around 30 seconds+, then lets me continue), but 8.5.2 recognizes it immediately.

[Mosu]

Currently it's impossible to download the Windows builds from the FossHub site,
whenever I click on the links, all that I get is a page reload :confused:

I can download just fine with Chrome & Edge, however, Firefox shows the same reloads you're seeing. And this is Firefox without any addon affecting JavaScript or ads. I'll contact the FossHub staff; they're usually pretty fast in their reaction.

Edit: seems to me that after clicking on a download link again that page reload does trigger the regular download even on Firefox. Maybe that'll work for you, too.

[ndjamena]

Is anyone else having this problem with the new 8.6.0 build?

When I drag 'n drop an MKV file that has previously been written to by Haali Matroska Writer b0 (which is what Simple x264/x265 Launcher uses when encoding directly to an mkv file (x264 codec)), MKVToolnix 8.6.0 takes an extremely long time to recognize the file (locks up for around 30 seconds+, then lets me continue), but 8.5.2 recognizes it immediately.

Apparently your file doesn't have a seek head, so MKVMerge goes looking for one...

hmmmmm.

[Mosu]

When I drag 'n drop an MKV file that has previously been written to by Haali Matroska Writer b0 (which is what Simple x264/x265 Launcher uses when encoding directly to an mkv file (x264 codec)), MKVToolnix 8.6.0 takes an extremely long time to recognize the file (locks up for around 30 seconds+, then lets me continue), but 8.5.2 recognizes it immediately.

This is most likely due to the following change:

* mkvmerge: enhancement: if no seek head is found before the first
cluster when reading Matroska files then mkvmerge will attempt a
deeper scan of all elements in the file in order to find track
headers, attachments, chapters and tags located at the end of the
file. See #1513 for the rationale.

I wasn't aware this had such a negative impact on a common kind of file. Looks like I'll have to disable that functionality again or implement it some other way…

Edit: new pre-builds 1018 (32bit)/1019 (64bit) with that feature temporarily disabled are available (https://mkvtoolnix.download/windows/pre/).

[Mosu]

When I drag 'n drop an MKV file that has previously been written to by Haali Matroska Writer b0 (which is what Simple x264/x265 Launcher uses when encoding directly to an mkv file (x264 codec)), MKVToolnix 8.6.0 takes an extremely long time to recognize the file (locks up for around 30 seconds+, then lets me continue), but 8.5.2 recognizes it immediately.

Can you please give pre-builds 1020 (32bit)/1021 (64bit) (https://mkvtoolnix.download/windows/pre/) a try? They implement a different way of checking such files and should handle file type recognition faster.

[Boulder]

Interesting. I cannot reproduce that at the moment. Can you please tell me more about your mux settings? What kind of files are involved, what's appended to where? Ideally you could send me a mux setting file or the corresponding job queue file (https://github.com/mbunkus/mkvtoolnix/wiki/mtxcfg-file-format-and-the-jobQueue). I'd also like to know how big the files in question are exactly.I had to remove the three different cases which caused the issue - I'm currently moving stuff from my backup DVDs to my external HDD attached to the media player due to a HD crash. I'll have several other cases in which the backup MKVs were split in parts when muxing so I'll try to reproduce it while processing the discs.

I'll update to the latest version to make sure the bug report's still valid.

[Jamaika]

I wanted to ask about the export function {--raw}? How can it be used? Video and audio files don't work after unpacking.

PS If the function doesn't work it can be removed.

[Mosu]

That function is there for codec IDs mkvextract knows nothing about. Whether or not the result is something that can be used depends on the content and on the application trying to read it after extraction.

[ndjamena]

Some iTunes files have a jpg "video" track containing images for the chapters, MKVMerge sees it as an actual video track and muxes it as such. If you split the file by chapters afterwards, and then extract the "track" from each resulting file using --raw you'll end up with several perfectly functional *.jpg files.

That's just one use.

[Jamaika]

I compared the function ex. with MP4Box. There raw works. It annoys me too duplication of the file information X264 / X265. I have to create an x-Info is better probably let deletes completely.
Some iTunes files have a jpg "video" track containing images for the chapters, MKVMerge sees it as an actual video track and muxes it as such. If you split the file by chapters afterwards, and then extract the "track" from each resulting file using --raw you'll end up with several perfectly functional *.jpg files.

OK. I use the "attachments" without {--raw}.

[szabi]

Hi

Today I wanted to update 8.51 to 8.60, that alert did come up.
http://abload.de/img/avast_mkvextract860nebvx.png
Any of you have this issue?

bye
szabi

[Mosu]

That's a false positive.

[szabi]

Previous versions did never have it.

[Mosu]

Oh yes they did, dating all the way back to 2.4.1. I've even got a FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/Virus-in-installer) about this topic!

Anti virus tools are notoriously overzealous when it comes to binaries they've never seen before. And new releases of software are by their very nature binaries the scanners have never seen before.

Such false positives are, unfortunately, rather common; there's one in at least all of the releases. Mostly in the installer itself but often enough in the binaries, too.

[Boulder]

One more reason to disable the heuristic scan of the AV program. I don't know if it ever catches anything, but it'll at least produce a lot of useless false alarms over time.

[szabi]

Ok. Correction. First time I see this.
I believe you both what say so it is added to false alert list, thx.

[Mosu]

Hey,

Just one day later, another release of MKVToolNix: v8.6.1. I'm therefore including and extending the previous announcement.

The next release of MKVToolNix is available: v8.6.0. Like the previous couple of releases this one focuses on bug fixes primarily. However, it also introduces one interesting new feature with support output mkvmerge's identification result as JSON for improved scripting.

There's also an important change breaking backwards compatibility: text files created by the tools (e.g. chapters extracted with mkvextract or redirected output of any of the tools) won't start with a byte order mark (BOM) anymore, even if they're encoded in one of the UTF-* encodings. Back in the day people believed that text files would be encoded primarily in UTF in the future and that distinguishing between those formats automatically with a byte order mark seemed sensible.

Reality has shown that things turned out differently: text files are overwhelmingly encoded in UTF-8 if they originate on Linux/Unix/Mac OS and in Windows' local encoding otherwise. Writing byte order marks isn't recommended anymore anyway.

This is an experimental change in so far as I'm willing to reverse it if enough people speak out for keeping the BOMs. So if you have legitimate concerns about this then please drop me a line.

An important change for package maintainers is that gcc 4.8.0 or newer/clang 3.4 or newer is now required for compilation due to the (header-only) library used for generating the JSON output. This concerns CentOS 6 and Debian 7 "wheezy" for which I don't offer binaries anymore as a consequence.

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

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

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

2015-11-29 Moritz Bunkus <moritz@bunkus.org>
* Released v8.6.1.
* mkvpropedit, GUI's chapter & header editors bug fix: in certain situations the modified file would not contain a seek head before the first cluster anymore resulting in most players not finding elements such as attachments or the index located at the end of the file anymore. Fixes #1513 (https://github.com/mbunkus/mkvtoolnix/issues/1513).
* mkvmerge: bug fix: the change to do a deeper file analysis if no seek head was found was causing huge increases in file type detection time as popular tools like x264 don't write seek heads. The way elements at the end are searched has been changed to only scan the last 5 MB of the file instead of iterating over every level 1 element from the beginning of the file.

2015-11-28 Moritz Bunkus <moritz@bunkus.org>
* Released v8.6.0.
* all: change: none of the tools will write a byte-order mark (BOM) to text files encoded any of the UTF-* schemes anymore.

2015-11-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Matroska reader bug fix: the info about which packetizer is used was output twice for each HEVC track. Fixes #1522 (https://github.com/mbunkus/mkvtoolnix/issues/1522).
* MKVToolNix GUI: bug fix: implemented a workaround for a bug in Qt which caused the GUI not to start anymore due to failing to detect a stale lock file if the GUI had crashed before on a computer with a host name that included non-ASCII characters. See https://bugreports.qt.io/browse/QTBUG-49640

2015-11-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: a track's number of bits per audio sample wasn't output in verbose identification mode even if it was present in the file.
* mkvmerge: enhancement: if no seek head is found before the first cluster when reading Matroska files then mkvmerge will attempt a deeper scan of all elements in the file in order to find track headers, attachments, chapters and tags located at the end of the file. See #1513 (https://github.com/mbunkus/mkvtoolnix/issues/1513) for the rationale.

2015-11-21 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: header editor bug fix: the "status" description wasn't adjusting its height properly resulting in its text being cut off. Fixes #1517 (https://github.com/mbunkus/mkvtoolnix/issues/1517).
* MKVToolNix GUI: bug fix: the program changes its working directory to the user's profile/home directory on startup allowing the removal of its installation folder even if a program started by the GUI (e.g. a web browser) is still running. Fixes #1518 (https://github.com/mbunkus/mkvtoolnix/issues/1518).
* ebml_validator: bug fix: elements with an unknown size weren't handled correctly.
* build system: fixed building and linking against libEBML and libMatroska if they're installed in a non-standard location.
* mkvpropedit, MKVToolNix GUI's chapter and header editors: the tools were unable to update elements in files without a seek head present. Fixes #1516 (https://github.com/mbunkus/mkvtoolnix/issues/1516).

2015-11-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two issues causing mkvmerge to write invalid data when updating track headers caused by the fix for "Re-rendering track headers: data_size != 0 not implemented yet". Fixes #1498 (https://github.com/mbunkus/mkvtoolnix/issues/1498).
* all: MKVToolNix now requires gcc 4.8.0 or later or clang 3.4 or later for compilation.

2015-11-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the options for linking to the next/previous segment UID were wrong. Fixes #1511 (https://github.com/mbunkus/mkvtoolnix/issues/1511).

2015-11-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added JSON as an output format for file type identification. It can be activated with "--identification-format json --identify yourfile.ext" (or their short counterparts "-F json -i yourfile.ext").

2015-11-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the VC-1 handlig code was duplicating the first sequence headers with each mux. Fixes #1503 (https://github.com/mbunkus/mkvtoolnix/issues/1503).

2015-11-08 Moritz Bunkus <moritz@bunkus.org>
* build system: bug fix: configure was checking for and using libintl if --without-gettext was used. Fixes #1501 (https://github.com/mbunkus/mkvtoolnix/issues/1501).

Have fun.

[Jamaika]

Hi Mosu

However, it also introduces one interesting new feature with support output mkvmerge's identification result as JSON for improved scripting.
Do you have any examples of applications? I understand that you can change the record XML tags, chapters, attachments on JSON. Are they included any new functions supports interactive?
https://pl.wikipedia.org/wiki/JSON

[ndjamena]

Powershell has a function called "ConvertFrom-Json" so now I can load MKVMerge -I output directly into an object without needing a complicated script to disassemble it.

There are numerous JSON libraries for c++. C# can translate it natively.

Hell, if MKVMerge had been able to output in JSON or XML a year or two ago I might have actually managed to finish the new version of MyMediaBatch before my head gave out.

[cengizhan]

adding a longer subtitle to a video, makes the video longer. for example: add a 100minutes subtitle to a 50 minutes video. the output video will be 100 minutes which you cant seek after 50 minutes.
is this a bug or a normal behaviour?

[Mosu]

Hey,

Do you have any examples of applications?

Not yet, but as ndjamena said it's trivial to import mkvmerge's identification output into data structures for your preferred programming language. Here's a trivial example in Ruby that prints the language of each track:

#!/usr/bin/env ruby

require "json"

output = `mkvmerge -F json -i #{ARGV[0]}`
result = JSON.parse(output) or fail

if !result["container"]["supported"]
puts "Container format not supported, no information possible"
exit 0
end

result["tracks"].each do |track|
if track["properties"]["language"]
puts "Track ID #{track["id"]} has language #{track["properties"]["language"]}"
else
puts "Track ID #{track["id"]} does not have a language set"
end
end

I understand that you can change the record XML tags, chapters, attachments on JSON.

I… don't really understand this sentence. If you mean whether or not tags and chapters will use JSON instead of XML: no, that's way too much effort for not enough gain.

Are they included any new functions supports interactive?

I really don't understand this sentence either. I'm sorry.

[Mosu]

adding a longer subtitle to a video, makes the video longer. for example: add a 100minutes subtitle to a 50 minutes video. the output video will be 100 minutes which you cant seek after 50 minutes.
is this a bug or a normal behaviour?

That's normal, intentional and exactly how it should work. The file's duration is the difference between its maximum timestamp and its minimum timestamp. Just because players stop when the video track stop doesn't mean the file ends there.

[ndjamena]

I think this is a continuation of Jamaikas desire to add interactive tags to his files.

JSON changes NOTHING about the files themselves, it has nothing to do with the Matroska Specs. All it does is change the OUTPUT of a single command in the MKVMerge application.

MKVMerge -I file.mkv

or

MKVMerge -i file.mkv

It just makes it easier for other applications to decipher MKVMerges identification output, nothing more.

[Jamaika]

no, that's way too much effort for not enough gain.

It just makes it easier for other applications to decipher MKVMerges identification output, nothing more.
Thanks all. Now I understand everything.

[cengizhan]

That's normal, intentional and exactly how it should work. The file's duration is the difference between its maximum timestamp and its minimum timestamp. Just because players stop when the video track stop doesn't mean the file ends there.

:thanks: i thought my video was corrupted or mkvmerge is bugged until i opened the subtitle file with an editor and saw it is longer than video.

[ndjamena]

Is there a technical reason the header editor wouldn't be allowed to shuffle the positions of tracks, ie like rearranging subtitles?

I've been doing it manually, but it would be much easier if I could just drag and drop and not have to keep track of which track number was where in case I wind up duplicating one (or leaving one out, which is the same thing).

[Mosu]

That functionality hasn't been implemented yet, neither in the GUI nor in mkvpropedit. I don't know if I'll ever implement it, though it's that I'd consider sometime in the future.

[ndjamena]

I'll stick to doing it manually then.

[SeeMoreDigital]

Can someone please remind me what the final discussion was regarding to the possibility of muxing Dolby TrueHD streams and preserving the Dolby Digital core within the .mkv container? Is it technically possible now?


Cheers

[Mosu]

If you mean you want to keep both the TrueHD and the AC3 data inside the same track: mkvmerge doesn't support that. Instead it will separate that data into two independent tracks. Meaning all of the data is preserved, but mkvmerge "sees" two tracks in such a case instead of a single one. That works even when re-muxing from M2TS, not just from elementary TrueHD files (.thd+ac3).

[SeeMoreDigital]

If you mean you want to keep both the TrueHD and the AC3 data inside the same track: mkvmerge doesn't support that. Yes, I realize that mkvmerge does not support this.

What I'd like to know is, is it now technically possible to do this with the Matroska container?

[sneaker_ger]

Mkvmerge does not support it because it is regarded as non-spec-compliant. The Matroska specs have not changed in this regard. (That may not hinder other software developers (makemkv?) to ignore that or interpret the specs in a different way.)

[SeeMoreDigital]

Mkvmerge does not support it because it is regarded as non-spec-compliant. The Matroska specs have not changed in this regard. (That may not hinder other software developers (makemkv?) to ignore that or interpret the specs in a different way.)Okay, thanks for the confirmation about this!

The reason I asked is because Oppo Digital recently removed TrueHD pass-through support for .mkv contained files due to a reliably issue with the Mediatek A/V decoding chip-set.

Oppo Digital have developed a work-around by transcoding multi-channel TrueHD audio to multi-channel PCM audio. But sadly if the TrueHD stream contains Atmos, the Atmos (object based) data is completely lost.

Sufficed to say, the Mediatek A/V decoding chip-set is able to 'pass-through' a TrueHD stream just fine when it's placed within the .m2ts container.


Cheers

[nevcairiel]

Sounds like they should fix their software. When you transmit TrueHD over HDMI, then the AC3 part is no longer present. The HDMI specs are pretty strict about that.

[SeeMoreDigital]

Sounds like they should fix their software. When you transmit TrueHD over HDMI, then the AC3 part is no longer present. The HDMI specs are pretty strict about that.Yes and no. In the case of TrueHD in m2ts, the AC3 core is still present within the stream as is the AC3 flag. And you are able to select the different streams.

[nevcairiel]

Yes and no. In the case of TrueHD in m2ts, the AC3 core is still present within the stream as is the AC3 flag. And you are able to select the different streams.

Not once it reaches HDMI. What the player does in between is not really important there. Of course it can let you select the AC3 stream.

[SeeMoreDigital]

Regardless, it would still be useful if the Matroska container supported TrueHD along with the core (as it does with DTS-HD MA). As it would provide more logical support with playback devices such as Smart TV's.

It's a right pain having to go through all your Blu-ray .mkv back-ups to add the AC3 stream... Indeed, last night I fancied watching a bit of Gravity on my LG television but was greeted with an 'Audio format not supported' message.

Anyway, if it can't be done. It can't be done :(

[Mosu]

DTS-HD MA is a very different case. TrueHD and AC3 are completely independent sets of data. One can be decoded without the other. The TrueHD data can exist and be decoded alone. So can the AC3 data.

For DTS-HD MA the situation is vastly different. Here the MA part can, in general, NOT be decoded alone. Instead the DTS core is required for decoding the MA part, too.

[nevcairiel]

The only way this actually works in MPEG-TS is that it has special metadata to mark the AC3 frames as a "substream", only this way can players identify which frames belong to the TrueHD stream, and which belong to the AC3 stream. You can't just mux both together and hope for the best, it has to be muxed properly - otherwise every player is going to break.
It seems rather unlikely that inventing a new muxing scheme for such tracks would magically fix smart TVs. It seems far more likely that they are designed to deal with this MPEG-TS variant somehow, but their MKV implementation is just broken. If you have to cater to such a TV, it seems sensible to just keep your videos in MPEG-TS.

Surely it could be muxed in MKV say using BlockAdditions or something like that, just for the sake of keeping the two streams packed "together", but players would still need to handle that, so it wouldn't make any sense and wouldn't fix anything automagically.

[SeeMoreDigital]

Surely it could be muxed in MKV say using BlockAdditions or something like that, just for the sake of keeping the two streams packed "together", but players would still need to handle that, so it wouldn't make any sense and wouldn't fix anything automagically.
I guess it's like any other implementation. Until somebody comes up with a method of doing it, device manufacturers wont be able to support it. Which really should be the advantage of adopting 'open-source' software in the first place ;)

[nevcairiel]

I guess it's like any other implementation. Until somebody comes up with a method of doing it, device manufacturers wont be able to support it. Which really should be the advantage of adopting 'open-source' software in the first place ;)

You could just mux them in two distinct streams like it is today, and a device manufacturer could read it. Why it would need the AC3 stream in the first place is beyond me, however.
Screams faulty implementation to me. The AC3 stream is not required for the TrueHD stream to work.

[SeeMoreDigital]

You could just mux them in two distinct streams like it is today, and a device manufacturer could read it...Yes I know I can. And I do. But that's not what I was enquiring about ;)

[Mosu]

I think nevcairiel's point was:

Your devices manufacturer is already doing something special regarding splitting of TrueHD+AC3 tracks M2TS so that they can decode TrueHD and throw away the AC3 part (as the AC3 part is neither required nor actually used for decoding TrueHD).
Currently TrueHD in Matroska doesn't work on that device.
Putting TrueHD+AC3 together into Matroska would require special support in a device to separate later, and that support doesn't exist yet. Therefore putting TrueHD+AC3 together into Matroska wouldn't give you any advantages over the current situation.
If the device manufacturer implemented the special support mentioned in 3. then it could just as well fix proper TrueHD support in Matroska, and you wouldn't need to put AC3 together with AC3 into Matroska anymore.

No matter which way you look at it TrueHD+AC3 in Matroska would be nonsensical.

[ndjamena]

iTunes m4vs have an atom in their headers call 'fall' that tells a player that two audio streams contain identical content encoded with different codecs.

That would be the way Matroska could implement similar functionality. Then you could mux both TrueHD and it's core into a file and have the player see them as the same, or use it on any other set of codecs as well.

Physically muxing the things into the same stream would be a hair-brained way of doing it in comparison.

[Mosu]

Hmm I don't see much use for such a flag.

It seems to me that the reson why DVDs and Blu-rays put the same content encoded with different codecs onto the same disc is compatibility. The standards don't mandate that all players must support all codecs. Additionally existing hardware should be supported (AC3) while offering improved (= lossless) content for newer hardware that supports it (TrueHD).

Back to Matroska: the problem is already that players don't support certain features (TrueHD in Matroska). To me the probability that players will implement proper support for these codecs inside Matroska is much, much higher than that they will implement support for a flag that says "these two tracks are the same; for compatibility reasons we've added both, use the one you support". They'd need an update for a functionality that supposedly would make it easier for them not to need updates ;)

As the use for such a flag would be limited to these kinds of compatibility scenarios I don't see the widespread use of it at all.

Not everything MP4 does makes sens for Matroska in my opinion.

[ndjamena]

I believe the point is if there's a main and a commentary the player knows not to use the commentary/audio description as default if they don't support the main codec, and all the 'fall' tracks effectively inherit the default flag from the master track.

iTunes uses it for AC3 tracks, the AAC is muxed in first with the enabled flag set. Any player that understands the 'fall' atom will find the AC3 and play that instead if it can, the rest will just play the AAC as normal.

It is better than trying to mux them all into the same track.

[Boulder]

I had to remove the three different cases which caused the issue - I'm currently moving stuff from my backup DVDs to my external HDD attached to the media player due to a HD crash. I'll have several other cases in which the backup MKVs were split in parts when muxing so I'll try to reproduce it while processing the discs.

I'll update to the latest version to make sure the bug report's still valid.I reproduced the error, here's the job queue file: https://drive.google.com/file/d/0BzeF_1syecQwQllKbTRkSlBqUTA/view?usp=sharing

[Frechdachs]

Hi, I'd like to report that, at least for me, mkvmerge ist handling encoding delay (also known as priming) of AAC incorrectly.

I did some tests:

1. encoding with qaac --> muxing with a video file using mkvmerge; this results in a delay of -22ms relative to the source, so mkvmerge actually cuts off more than it has to.
2. encoding with NeroAacEnc --> muxing with video file using mkvmerge; this results in a delay of -10ms relative to the source, also cutting off more than it should.
3. encoding with qaac with --no-delay flag enabled --> muxing with video file using mkvmerge; this works fine, qaac itself removes the delay and mkvmerge does not cut anything off.

Can anyone confirm this results?

If I recode the AAC tracks with ffmpeg to flac (before muxing obviously), the delay gets handled properly. Muxing those flacs with mkvmerge results in no delay.

Edit: Note that I used a stereo file with a sample rate of 48KHz in this test. Also, my results could be off by +/-1ms, since I used Audacity and my eyes for testing.
Update: Old ffms2 was the culprit, not mkvmerge.

[sneaker_ger]

AAC delay handling has been tested by a number of people and should be correct. What exactly do you expect to happen in cases #1 and #2? Can you upload samples to show what's wrong? Things like sampling frequency and frame length are important to know to correctly judge this.

[sneaker_ger]

Edit: Note that I used a stereo file with a sample rate of 48KHz in this test. Also, my results could be off by +/-1ms, since I used Audacity and my eyes for testing.
Did you factor in the positive delay (look at first audio timecode) or did you just extract and open in Audacity? Mkvmerge drops every frame starting before 0ms and has to delay via timecode to make up for it in most cases. I.e. if a frame is 20ms long, the encoder delay is 10 ms, the frame would have to start at -10ms. What mkvmerge does is delete the frame and set first timecode to +10ms.

[Frechdachs]

Can you upload samples to show what's wrong?
Sure. (https://0x0.st/-VN.7z)

What exactly do you expect to happen in cases #1 and #2?
The same as in case #3.

Did you factor in the positive delay (look at first audio timecode) or did you just extract and open in Audacity?
No, can you tell me how I can look at the actual timecodes?

Here's how I tested it:
I first noticed the delay in Aegisub. It uses FFmpegSource to decode audio, so if there is a positive delay shouldn't it be taken into consideration?
Then I demuxed and encoded the track to PCM to open it in Audacity, same result.

[sneaker_ger]

No, can you tell me how I can look at the actual timecodes?
Different ways:
1. Look at delay info in MediaInfo
2. use mkvextract: mkvextract timecodes_v2 file.mkv 0:timecodes_of_first_track.txt 1:timecodes_of_second_track.txt 2:timecodes_of_third_track.txt etc.
3. use mkvinfo (GUI), show all elements (ctrl+a) and look into clusters for first timing


I first noticed the delay in Aegisub. It uses FFmpegSource to decode audio, so if there is a positive delay shouldn't it be taken into consideration?
I don't know from the top of my head. The latest "stable" Aegisub is quite old and there have been delay bugfixes in ffms2 in the meantime. Might want to check a recent trunk build (http://plorkyeran.com/aegisub/). (Maybe exchanging the ffms2 dll is also possible, have not tested)

Then I demuxed and encoded the track to PCM to open it in Audacity, same result.
When you demux to a raw format you lose all delay info so that is bound to give incorrect results.

[Frechdachs]

I don't know from the top of my head. The latest "stable" Aegisub is quite old and there have been delay bugfixes in ffms2 in the meantime. Might want to check a recent trunk build (http://plorkyeran.com/aegisub/).
Thank you very much. I updated from r8700 to r8792 and it actually solved the problem with qaac and Nero! There have been three updates to ffms2 since. Completely forgot about that. I'm used to rarely update Aegisub, since I know from my own experience that recent trunk builds can be highly unstable.

However, I did another test with FDK AAC. After muxing with mkvmerge there is still a positive delay of ~40ms according to Aegisub. My fdk_aac enabled ffmpeg build was build on 03/24/2014, though. So it would be nice if someone with a recent build can test that also. I assume the priming should be stored somewhere in the metadata of the .m4a by the encoder, right? Or is it hardcoded in mkvmerge depending on the used encoder?
Additional samples. (https://0x0.st/-VW.7z)

[sneaker_ger]

The delay values mkvmerge uses are not hardcoded (not that there is any good way to detect the encoder used in the first place). It can use two different infos:
- proprietary Apple atom ("iTunSMPB")
- mp4 edit list
QAAC, Nero and fhgaacenc write the Apple atom by default, (qaac has an option to choose one or write both IIRC).

Your ffmpeg/fdk_aac sample does not have this atom. It does have an edit list, though, and from what I can see mkvmerge does not obey it. I'm not sure why. Either it's a bug or it's a feature since there is no other track to sync it to (read: no other tracks to delay). Mosu should be able to comment on that.

/edit:
I think this is relevant, i.e. it's by design and not considered a bug (last 4 posts):
https://github.com/mbunkus/mkvtoolnix/issues/780

Can't say I agree with it but it seems that's how Mosu thinks about the issue.

[Frechdachs]

Well, thanks for clearing that up.

I guess, I'll just refrain from using FDK AAC for video files for now.

[ndjamena]

The Frame Count in the tags for PGS Subtitles is twice the number of actual subtitles as confirmed by both eac3to and DVDSubextractor.

Extracting the cues for the subtitle track shows the double count though.

Is this normal for PGS? Is there an end of caption frame for each display frame maybe? Is there ever LESS than double (or possibly more)?

[sneaker_ger]

Is this normal for PGS? Is there an end of caption frame for each display frame maybe?
Yes.
http://forum.doom9.org/showthread.php?p=1736749#post1736749

[ndjamena]

Crap.

I thought Matroska had it's own frame duration and removed that kind of nonsense from the streams.

The Count of Elements added to MediaInfo is still kind of useful, but now I'm wondering.

Since SDH encoded in "Closed Caption" mode (with a black background) comes out having a smaller size than regular subtitles (despite having more frames), now it's possible a SDH subtitle could have less frames as well if the regular subtitle over-uses clear-screen frames where the SDH doesn't.

*sigh*

So much for trying to be clever. It should make forced subtitles stand out at least.

[sneaker_ger]

I thought Matroska had it's own frame duration and removed that kind of nonsense from the streams.
I was talking about raw .sup files. Empty frames should not be needed within the mkv container because we have the BlockDuration element. That said, I have never taken a closer look as to how mkvmerge does it - maybe they are kept? Should be fairly simple to see in e.g. mkvinfo.

[ndjamena]

Yup, every second frame is 36 or 37 bytes in size.

That would be why MakeMKV sometimes copies several non-forced frames into the forced track if they're directly after a forced frame. I suppose a Blu Ray player just treats non-forced frames as clear-alls in a forced situation.

[foxyshadis]

Is there any PGS or Blu-ray spec document available yet? That would really help with some of the strange corner cases....

[sneaker_ger]

Is there ever LESS than double (or possibly more)?
Since mkvmerge seems to treat the empty frames just like normal ones (except for calculating end the time of previous frames) it means you may happen to cut to uneven counts of subtitle frames if you cut in a middle of one. I.e. you might get a stray empty one at the beginning of a file or a regular frame without an empty one at the end. This also means you cannot guess correctly even if you know this. A count of 41 might mean a stray empty one at beginning (=20 "real" frames) or a missing empty one at the end (=21 "real" frames).

[kuchikirukia]

Would it be possible to get a Split By Chapter option that only output the selected chapter(s)? When I split by chapter it's almost always because I want only certain chapters, not the entire video.
"Split selected chapters," would be nice.

[Mosu]

Would it be possible to get a Split By Chapter option that only output the selected chapter(s)? When I split by chapter it's almost always because I want only certain chapters, not the entire video.
"Split selected chapters," would be nice.

It's unlikely that I'll implement such an option. Sorry. I'd welcome patches that add such an option, though, I just don't want to spend time on it myself.

[Mosu]

I reproduced the error, here's the job queue file: https://drive.google.com/file/d/0BzeF_1syecQwQllKbTRkSlBqUTA/view?usp=sharing

Thanks for the file. Are you sure this is the right file? Its content shows that the job hasn't been run yet – the end date isn't set and the job output is empty.

Just in case I've tried to reproduce it by creating a similar setup (same file types, same file names, same numbers and types of tracks) here – still no dice.

In the queue file I can see that you're muxing two files appending the second one to the first one. How big are those two files (in bytes)? Are you using the 32bit or the 64bit variant of MKVToolNix? Which MKVToolNix version? And are you 100% sure you've sent me the correct job queue file?

[Boulder]

Thanks for the file. Are you sure this is the right file? Its content shows that the job hasn't been run yet – the end date isn't set and the job output is empty.

Just in case I've tried to reproduce it by creating a similar setup (same file types, same file names, same numbers and types of tracks) here – still no dice.

In the queue file I can see that you're muxing two files appending the second one to the first one. How big are those two files (in bytes)? Are you using the 32bit or the 64bit variant of MKVToolNix? Which MKVToolNix version? And are you 100% sure you've sent me the correct job queue file?It's a correct file, I just reproduced the issue with a different movie and it also contains "null" for dateFinished and dateStarted.

I'm using the 64-bit version of mkvmerge v8.6.1. I can reproduce the issue with many but not with all files. It also occurs via the command line so it's not a GUI problem.

In this latter case, the first file is 4564850985 bytes and the next file is 1528773206 bytes. They were created using the link files option.

https://drive.google.com/file/d/0BzeF_1syecQwSGlyOTIxQndjSFU/view?usp=sharing

[Mosu]

Yeah I can reproduce the issue now. It's only triggered with files that were split using linking. Thanks for the input. I'll fix it.

[Mosu]

Oh, and the reason the job file was still showing "dateFinished" set to null is that the job queue is only saved when you exit the program.

[Mosu]

Fixed in pre-builds 1049 & 1050 (https://mkvtoolnix.download/windows/pre/).

[ndjamena]

Did you know AnyDVDs CloneBD has been muxing TrueHD into Matroska files with the embedded AC-3 core intact.

Is this a problem? Is this moving in a direction you're willing to support?

[Mosu]

Nothing's changed for me. I still consider embedded AC3 in TrueHD in Matroska to be non-compliant. I'm sure players will play it just because they also have to support TrueHD+AC3 in M2TS etc. But mkvmerge never will.

[ndjamena]

OK then. They've also added a duration tag without the security tags, there's some crap in the tags that are just targets with no values and they seem to be marking every track as default (or at least NOT marking any as NOT being default).

I'm just testing it out and am commenting on what I've found. Really, if I were to decide to use the program all I'd want from MKVMerge at the moment is the ability to strip the AC-3 core during remux, but if you don't want to touch it I understand perfectly.

It has potential but it has a long way to go before it can be considered a viable replacement for MakeMKV.

[Mosu]

I'm… actually not certain how mkvmerge treats TrueHD+AC3 when reading it from a Matroska file as I don't think that I've ever had a sample file to work with. It's possible that the AC3 core is simply dropped. I don't think that the AC3 core would be presented as an extra track as mkvmerge does with e.g. M2TS as that requires extra work from me for each demuxer, and as I have no sample file I don't think I implemented such support in the past.

I would be willing to work on improving this so mkvmerge treats the embedded AC3 core like a separate track just like in M2TS. My earlier "mkvmerge doesn't support" was only meant to say that mkvmerge won't create such files itself.

[Selur]

would be interested in such a sample too :)

[ndjamena]

I extracted the track with MKVExtract, then remuxed the elementary stream using MKVMerge and wound up with a fully functional AC-3 track, so its definitely there.

MPC-HC doesn't like the file at all. It seems to think it's 20 hours long and there's definitely something wrong with the audio. I think it might be trying to play two tracks at once, but one of the tracks seems to be from a different part of the movie.

Remuxing with MKVMerge didn't fix any of that, the AC-3 core was still present, I could still extract the TrueHD and remux the AC-3 from the elementary stream, and the movie was still 20 hours long. Remuxing without the TrueHD/AC-3 track restored the file to its proper duration.

I could probably split off a few seconds of the file for you to play with if you like. Remuxing doesn't seem to affect anything.

[nevcairiel]

MPC-HC doesn't like the file at all. It seems to think it's 20 hours long and there's definitely something wrong with the audio. I think it might be trying to play two tracks at once, but one of the tracks seems to be from a different part of the movie.

Thats why its considered non-compliant. There is no clean way to split the tracks without careful bitstream parsing. In m2ts, there is metadata that identifies the embedded ac3 core, so you can read that and split it cleanly without any knowledge of the stream layout itself. Without such metadata, splitting the TrueHD from the AC3 core is serious effort. In fact, I would consider a m2ts demuxer "broken" if it doesn't split the TrueHD and AC3 into distinct tracks (or at least drops one of them), since they *are* just that.

So, just don't create those tracks, ever, and software that does is plain broken.

[ndjamena]

You make it sound like I was happy to find out what it had done.

I was actually hoping it would help me split certain play alls into individual episodes but it's not very good at that either.

Still, the thing is still in early development and it's more likely to get such a feature implemented properly before MakeMKV, especially since it should be doing it already, it's just a pain in the arse to use. If this is how it's going to treat TrueHD then anyone who uses it has to work with that.

My concern isn't inflicting absolute support for embedded AC-3 cores in TrueHD on the Matroska world, it's getting rid of that damn core from the stream without having to demux it from the file. I've been told MKVMerge should be able to read from any matroska file, whether it complies absolutely with the specs or not, it just won't make one that doesn't. I don't know how far that stretches in reality but this situation would seem to be a likely candidate.

[ndjamena]

AC-3 has frames with a duration of 32ms or 31.25fps.

According to MediaInfo TrueHD has a frame rate of 1200fps or a duration of 0.833..ms.

According to MKVInfo each frame is the file is 32 ms long, but 32 doesn't divide cleanly by 0.833..

The frames have a variable size so I'm assuming they can't be all AC-3, which means a variable number of TrueHD frames must be packaged with each AC-3 frame in the file.

So since MKVMerge can identify it and remux it perfectly after MKVExtract has extracted it, I'm assuming it must be nothing but an elementary stream cut at the start of each AC-3 frame, with each section placed in a single Matroska frame.

If that makes sense.

[SeeMoreDigital]

Did you know AnyDVDs CloneBD has been muxing TrueHD into Matroska files with the embedded AC-3 core intact.Out of interest, have you tried directly muxing these .mkv files into the .m2ts container using TSmuxerGUI?... Does it accept or reject them?

I would be willing to work on improving this so mkvmerge treats the embedded AC3 core like a separate track just like in M2TS. My earlier "mkvmerge doesn't support" was only meant to say that mkvmerge won't create such files itself.If you are able to do this I will arrange to have some samples sent to OppoDigital and Panasonic ;)

[ndjamena]

TSMuxer still rejects it.

Interestingly enough after converting the file to be spec compliant using MKVMerge the original rip is still 4 mb small than the new one. Simply remuxing the original file without correcting it results in a file that's almost 80 mb smaller than the spec complaint version.

Considering the AC3 core is over 5gb and (unless you're stuck with badly outdated audio equipment) is completely redundant, just removing the thing would still be preferable though.

They "solved" the "problem" of the TrueHDs AC-3 core, and they "solved the problem" of TrueHDs miniscule frame size. I seem to recall both issues have come up recently...

[Mosu]

Can you please upload a sample file created by AnyDVD to my FTP server? It doesn't have to be the full file; just stop uploading after 100 MB or so. Assuming the track headers are located at the front this should still be readable. Thanks.

[ndjamena]

I uploaded a little over 200mb of Age of Extinction.

It may be a moot point for me at least. I just discovered AnyDVD don't accept MasterCard, and my trial expires soon.

But other people may find anything you can do with it useful though.

[Mosu]

Thanks for the file. I can work with it and will investigate.

[kuchikirukia]

So you can't add custom command lines to mkvmerge anymore?

This MKVtoolnix GUI is sooo much worse than the old mkvmerge.

[wanezhiling]

This MKVtoolnix GUI is sooo much worse than the old mkvmerge.
Can't agree more, I just gave up the app for this reason... :o

[Boulder]

So you can't add custom command lines to mkvmerge anymore?

This MKVtoolnix GUI is sooo much worse than the old mkvmerge.
:confused:

The additional options are in the Output tab.

[ndjamena]

??? Is the pre I'm using really that more advanced than what you guys have?

There's 'additional options' fields in the properties of each track and another one in the output tab.

Unless you feel the need to add entire input files via extra command lines I don't see why you'd need anything more...

...(or is this just a deliberate attempt to not look properly just to have an excuse to protest the perceived slight inflicted by daring to change something you'd gotten used to.)

To be honest I use the actual command line FAR more than I use the GUI, and despite rarely ever using it I've had zero problems migrating from MMG to MKVToolNix GUI.

[Mosu]

So you can't add custom command lines to mkvmerge anymore?

You can change the additional options for the current mux settings on the "output" tab, bottom right, inside the "Miscellaneous" group. The button next to the input will open a dialog presenting all known extra options you cannot set otherwise in the GUI.

Changing the additional options for all future mux settings can be achieved both from the aforementioned dialog (there's a checkbox at the bottom to use the current options for all future settings, too) and from the "preferences". You'll find the input with its associated button on the "Merging" tab; it's called "Default additional command line options" there.

??? Is the pre I'm using really that more advanced than what you guys have?

No :) These two controls have been part of the new MKVToolNix GUI release ever since its first official release in 8.3.0.

This MKVtoolnix GUI is sooo much worse than the old mkvmerge.
Can't agree more, I just gave up the app for this reason...

What exactly don't you like? Are there particular features that you're missing? Does it do things you don't want it to (if so, which)? Please be speciffic, because then I can maybe help you discover features about the GUI you didn't know exist; or I can point you to how you can change the GUI's behavior.

[Mosu]

Did you know AnyDVDs CloneBD has been muxing TrueHD into Matroska files with the embedded AC-3 core intact.

Is this a problem? Is this moving in a direction you're willing to support?

Thanks again for the test file. Your observation that simply re-muxing such a file with mkvmerge was keeping the track intact (including its AC-3 core) was indeed correct. The reason is that up to and including the latest release mkvmerge was using its "pass-through" packetizer for TrueHD tracks instead of using its specialized TrueHD packetizer. This seems to be an omission, and I've changed this since.

Now the TrueHD packetizer is used. The immediate effect is that twofold:

The AC-3 core is dropped from that track.
The TrueHD packets that are currently grouped into a single Matroska block are split up properly into separate blocks.

Now the re-muxed files are spec-compliant again.

This was step one. You can check the result in the latest pre-builds (https://mkvtoolnix.download/windows/pre/) (1080 32bit, 1081 64bit).

I will most likely implement exposing the AC-3 core as a separate track just like it's done for the M2TS reader and other readers, too.

[ndjamena]

The file muxed perfectly, MPC-HC now shows the correct duration and the audio sounds fine.

Have you thought about how to output the info in -I mode? Is it just going to be a property of the TrueHD track or will it be listed as a separate track?

Listing it as a separate track could be a problem for MKVExtract and/or MKVPropEdit. NOT listing it as a separate track could be a problem for MKVMerge GUIs, unless you're happy to scrap the core by default and only rescue it if specifically told to.

[Mosu]

I'm not sure yet. Yes, the track numbering would be a big problem for mkvpropedit and mkvextract. For the time being I will likely only drop the AC-3 core and NOT expose it as a separate track. I don't think this would be too much of a problem: in Matroska TruehHD+AC-3 core inside a single track is non-compliant whereas in M2TS it is compliant or even required. Therefore simply dropping it when reading shit from Matroska would be fine with me.

I also don't want to encourage using TrueHD+AC-3 inside Matroska any more than I have to, and supporting this just like any other track would signal validity where there is none.

[ndjamena]

Assigning things like names or track order to a rescued AC-3 core during remux would be a pain too if you don't output it with its own TrackID, unless you just duplicate whatever has been assigned to the TrueHD and let the CodecID do the talking. There are a bunch of things you could do that you most likely can't be bothered doing. You COULD output it with its own TrackID, and then if MKVPropEdit or the header editor is pointed at it, create a new header for the AC-3 track with the same track number as the TrueHD track. That's how I envision 608 caption data would work in Matroska, with CC1 and CC2 muxed into the same track, but each given their own header differentiated only by their CodecIDs (S_EIA608-CC1, S_EIA608-CC2 or something), it could work just as well for TrueHD and it's core. And if MKVExtract is told to extract the core... extract the core, if it's told to extract the core and the TrueHD into the same file then that shouldn't be too hard.

*sigh* I'd been meaning to try pointing two headers at the same track and remuxing with MKVMerge to see what would happen, I almost did it accidently with subtitles but cancelled before seeing what happened to the output.

I guess I should just check if Subtitle Edit or CCExtractor can read 608 captions from mp4s properly yet...

I have a few days to figure out if I should buy CloneBD without AnyDVD or bits and pieces from the DVD Fab suite before all the sales end... Decide whether I feel up to spending actual money to put up with the bugs, limitations and other crap from yet more programs.

[SeeMoreDigital]

This MKVtoolnix GUI is sooo much worse than the old mkvmerge.How strange... I think it's much easier :)

[ndjamena]

Does anyone happen to know if the Oppo BD-93 has problems with Track Statistics Tags?

[SeeMoreDigital]

Does anyone happen to know if the Oppo BD-93 has problems with Track Statistics Tags?I can't help you with the Oppo BD-93 but I can confirm that the Oppo BDP-10x range of players are okay with them ;)

[Mosu]

Hey,

here's the last release for this year: 8.7.0. This release contains a more even mix of bug fixes and enhancements. One area that has received special attention is the HEVC/h.265 code where multiple issues have been fixed. I strongly urge everyone to upgrade if you're dealing with HEVC/h.265 in Matroska.

The enhancements and new features include:

a reworked preferences dialog in the GUI
a rather flexible method of running arbitrary programs after the GUI has finished a job or the whole queue
more items output in verbose & JSON identification modes
more options for dealing with attachments and track statistics tags in mkvpropedit

I've also decided to revert the change to writing byte order marks (BOMs) for UTF-8 encoded files that was introduced in the last release. This was due to user feedback. A common workflow is to extract subtitles to an extern file, to edit them somehow and to mux the back. On Windows this became annoying without BOMs: the extracted text files are UTF-8, but mkvmerge defaults to Windows' own locale when reading text files – unless a BOM is found.

Another change I've reverted due to user feedback is the removal of several ISO 639-2 codes for very old languages. Certain users have used those codes to indicate variations to the default language, and the earlier removal broke this workflow.

Nothing has changed for package maintainers compared to v8.6.1.

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

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

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

2015-12-31 Moritz Bunkus <moritz@bunkus.org>
* Released v8.7.0.

2015-12-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed the handling of a PES size of 0 ( = unknown). Tracks whose PES packets had such a size were sometimes not detected at all, and even if they were their content was incomplete. Fixes #1553 (https://github.com/mbunkus/mkvtoolnix/issues/1553).
* mkvmerge: bug fix: made the MPEG 1/2 video elementary stream file type recognition more resilient and more flexible dropping the requirement for a file to start with an MPEG start code (0x00 00 01). Fixes #1462 (https://github.com/mbunkus/mkvtoolnix/issues/1462).
* mkvpropedit: bug fix: when changing the track language it is now verified to be a valid ISO 639-2 language code before writing it to the file. Fixes #1550 (https://github.com/mbunkus/mkvtoolnix/issues/1550).
* mkvmerge: enhancement: the MP4 reader will keep the display dimensions from the track header atom ("tkhd") and use them as the display width & height. See also #1547 (https://github.com/mbunkus/mkvtoolnix/issues/1547).

2015-12-29 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: the "add source files" button now has optional popup menu containing actions for adding/appending files and adding files as additional parts for easier discovery of those actions. This popup is only shown if the user clicks on the arrow shown on the right of the button.
* mkvmerge: new feature: TrueHD tracks that contain Dolby Atmos will be identified as "TrueHD Atmos". Implements #1519 (https://github.com/mbunkus/mkvtoolnix/issues/1519).
* mkvmerge: bug fix: the Matroska reader now uses TrueHD-specific code when reading Matroska files. This can fix things like wrong frame type flags.

2015-12-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MP4 edit lists of certain types (two entries, first entry's media_time is -1, second entry's segment_duration is != 0) weren't handled properly resulting in key frame flags being assigned to the wrong frames. Fixes #1547 (https://github.com/mbunkus/mkvtoolnix/issues/1547).
* mkvmerge: bug fix: the h.265/HEVC code was writing SEI NALUs twice. This had already been mentioned in #1076 (https://github.com/mbunkus/mkvtoolnix/issues/1076) but never fixed. Patch by Vladimír Pilný.
* mkvmerge: bug fix: the h.265/HEVC code wasn't converting slice NALUs to RBSP form before parsing it resulting in wrongly timestamped frames under certain conditions. This is a similar fix to the issues reported in #918 (https://github.com/mbunkus/mkvtoolnix/issues/918) and #1548 (https://github.com/mbunkus/mkvtoolnix/issues/1548).
* mkvmerge: bug fix: the h.264/AVC code wasn't converting slice NALUs to RBSP form before parsing it resulting in wrongly timestamped frames under certain conditions. Fixes #918 (https://github.com/mbunkus/mkvtoolnix/issues/918) and #1548 (https://github.com/mbunkus/mkvtoolnix/issues/1548).
* mkvmerge: bug fix: the MP4 reader can now understand the 'random access point' sample grouping information for marking open GOP random access points as key frames. Fixes #1543 (https://github.com/mbunkus/mkvtoolnix/issues/1543).

2015-12-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed the decisions whether or not to write the last frame of a track as a BlockGroup or a SimpleBlock and whether or not to write a block duration for that frame. Fixes #1545 (https://github.com/mbunkus/mkvtoolnix/issues/1545).
* MKVToolNix GUI: new merge tool feature: added menu options in the "Merge" menu for copying either the first source file's name or the current output file's name into the "file title" control.

2015-12-22 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit: new feature: added an option for calculating statistics for all tracks and adding new/updating existing statistics tags in a file. Second half of the implementation of #1507 (https://github.com/mbunkus/mkvtoolnix/issues/1507).

2015-12-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the progress calculation was sometimes outputting negative numbers when appending Matroska files whose timestamps don't start at 0 (e.g. if they were created by splitting with linking enabled). In the the GUI this resulted in lines like "#GUI#progress -2%" in the job's output.
* mkvpropedit: new feature: added an option for removing all existing track statistics tags from a file. Part of the implementation of #1507 (https://github.com/mbunkus/mkvtoolnix/issues/1507).
* mkvmerge: bug fix: AAC with low sampling frequencies was sometimes mis-detected with the wrong profile preventing appending it to other AAC tracks. Fixes #1540 (https://github.com/mbunkus/mkvtoolnix/issues/1540).

2015-12-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: chapters were output as both "chapters" and "track_tags" in JSON identification mode. Fixes #1538 (https://github.com/mbunkus/mkvtoolnix/issues/1538).
* mkvmerge: enhancement: added the container's internal track ID as the "number" attribute in verbose & JSON identification modes for several container types (QuickTime/MP4: the track ID from the 'tkhd' atom; MPEG program stream: the sub-stream ID in the upper 32 bits and the stream ID in the lower 32 bits; MPEG transport stream: the program ID; Ogg/OGM: the stream's serial number field; RealMedia: the track ID). Implements #1541 (https://github.com/mbunkus/mkvtoolnix/issues/1541).

2015-12-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the "split mode" drop-down box got reset to "do not split" each time the preferences dialog was closed with the "OK" button. Fixes #1539 (https://github.com/mbunkus/mkvtoolnix/issues/1539).
* mkvmerge: enhancement: if JSON identification mode is active then warnings and errors will be output as JSON as well. They're output as arrays of strings as the keys "warnings" and "errors" of the main JSON object. Implements #1537 (https://github.com/mbunkus/mkvtoolnix/issues/1537).
* all: reversion of a change: several ISO 639-2 codes of languages that are very old and not spoken anymore have been re-added (e.g. "English, Middle (1100-1500)") due to feedback from users who did have a use for such codes.
* all: reversion of a change: all of the tools will write a byte-order mark (BOM) to text files encoded any of the UTF-* schemes again. This reverts the change in release 8.6.0 due to user feedback preferring the old way.

2015-12-12 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit: enhancement: when using --add-attachment, --replace-attachment or --update-attachment the UID can be changed with --attachment-uid. See #1532 (https://github.com/mbunkus/mkvtoolnix/issues/1532).
* mkvpropedit: new feature: added an option "--update-attachment" for updating the properties of existing attachments without replacing their content. Implements #1532 (https://github.com/mbunkus/mkvtoolnix/issues/1532).

2015-12-11 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: added options for running arbitrary programs after a job has finished or after the queue has finished. Implements #1406 (https://github.com/mbunkus/mkvtoolnix/issues/1406).

2015-12-09 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: if files are dragged & dropped from an external application with the right mouse button being pressed then the GUI will always ask the user what to do with the files even if the user has configured the GUI not to ask. Implements #1508 (https://github.com/mbunkus/mkvtoolnix/issues/1508).
* MKVToolNix GUI: enhancement: when starting the GUI with a saved settings file then the GUI won't contain an empty tab in the merge tool anymore. Fixes #1504 (https://github.com/mbunkus/mkvtoolnix/issues/1504).

2015-12-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed the key frame detection for VP9 video tracks.
* MKVToolNix GUI: bug fix: relative file names given on the command line were interpreted as being relative to the user's home directory. Fixes #1534 (https://github.com/mbunkus/mkvtoolnix/issues/1534).

2015-12-01 Moritz Bunkus <m.bunkus@linet-services.de>
* MKVToolNix GUI: the preferences dialog has been reworked heavily in order to provide a better overview and to be less overwhelming.

Have fun :)

[sneaker_ger]

Does anyone happen to know if the Oppo BD-93 has problems with Track Statistics Tags?
Tags aren't exactly a new feature, are they? I have not seen any reports whatsoever about related playback problems.

[ndjamena]

Someone on the MakeMKV forum is complaining that the latest version is messing up the playback of subtitles for no player other than his oppo 93. As far as I'm aware the only thing that's changed is the addition of statistics tags. Should the oppo even be touching them?

[SeeMoreDigital]

Someone on the MakeMKV forum is complaining that the latest version is messing up the playback of subtitles for no player other than his oppo 93. As far as I'm aware the only thing that's changed is the addition of statistics tags. Should the oppo even be touching them?Hmmm...

Which MKV muxer does MakeMKV use?

[nevcairiel]

Which MKV muxer does MakeMKV use?

MakeMKV have their own.

[SeeMoreDigital]

MakeMKV have their own.Indeed, so I guess there could be an issue with their muxer ;)

[Chetwood]

Tags aren't exactly a new feature, are they? I have not seen any reports whatsoever about related playback problems.
You should check out a file muxed with global tags/tags for track 0 on the WDTV then. After 5 min max it stops playing and only remuxing will fix this.

[ndjamena]

You should check out a file muxed with global tags/tags for track 0 on the WDTV then. After 5 min max it stops playing and only remuxing will fix this.

When did that start? I filled all my files with an abundance of tags before I discovered how unreadable the specs were and my WDTV SMP never even flinched.

(most files stopped playing part way through (mp4 or mkv) using the latest firmware, that's why I'm back to using the previous firmare, which apparently I'm stuck with now til death do us part.)

[Chetwood]

Don't know. Since the tags were introduced I've been muxing without them to insure standalone compatibility (and it's not that I actually need them, I've been doing fine all the time before), so I never realized this. It was only till the other day when a friend came over and we watched one of his MKVs.

[SeeMoreDigital]

Don't know. Since the tags were introduced I've been muxing without them to insure standalone compatibility (and it's not that I actually need them, I've been doing fine all the time before), so I never realized this. Same here. Since none of my hardware playback devices make use of the tags, I mux without them...

[Mosu]

Hey,

today I've implemented a third optional layout for the track properties: again to the right of the "files" and "tracks" lists but all groups in two fixed columns. This results in a somewhat wider window but also provides a better overview over all settings. You can switch between the layouts in the "merge" section of the preferences.

I'd like some feedback on this feature which is available in pre-builds 1099 (32bit) and 1100 (64bit) (https://mkvtoolnix.download/windows/pre/), especially regarding two different aspects:

Most of you here are what I'd call power users. Do you personally like it? If not, why not?
Now consider the average user or a user new to MKVToolNix. Which of the three layouts available would you consider best when a user starts the GUI for the first time?

Thanks :)

[sneaker_ger]

I like the first setting ("scrollable column on the right of the files and tracks") best.
Why?
I usually don't maximize the window because drag&drop et al. are easier when I can see both the mkvtoolnix GUI and the explorer with my files in the background. Does it mean I have to scroll the track options? Actually, no. The options I need 99% of the time are visible without scrolling anyways. This is the biggest plus compared to the old MMG, IMHO. Naturally, the third option is not for me, unless I want to edit files with long track names etc.

I think the new (second) layout is probably well suited for people who maximize the window (usually with dual displays?). Not for me, but I can see when it might come in handy.


As for new users:
The biggest problem for them is the pure mass of options they get to see. It can be overwhelming. Not sure which of the three layouts would be best suited for them, though. I think the scrolling one might still look the cleanest.

[AYColumbia]

It's hard to say for new users other than, if they're using MKVToolNix, they're advanced enough to deal with either interface.

Personally, I like how you have it currently. I prefer to see as much info as possible. So order of preferences for me:
- two fixed columns
- tabs below
- scrollable list

For me, the scrollable list is a big waste of "real estate" as labels, inputs, combos, etc. don't need to be that wide. Maybe consider, in that view, to take a 3rd of it and add more to the left side. Just a thought. :)

Also, would love to see these "layouts" available in a pull-down list on the UI or maybe in a "Layout" menu between Merge and Help to change the layout instantly. Thanks a lot for continuing to improve this app. :D

[Mosu]

For me, the scrollable list is a big waste of "real estate" as labels, inputs, combos, etc. don't need to be that wide. Maybe consider, in that view, to take a 3rd of it and add more to the left side. Just a thought. :)

There are splitters between the left side (files & tracks) and the properties as well as between the files and the tracks lists. You can adjust their position manually (within limits; all controls have a certain minimum size). This means that you could give the tracks list twice the space the files list has and assign the left side tripple the space of the track properties if the window is large enough.

[Boulder]

If you want to make an easy way for newbies to use the program, why not create a simple wizard for simple (re)muxing tasks? I have to admit that the first time I saw the GUI long ago, I was very unsure of what I should do :)

[Mosu]

I don't want to make it really easy for newbies. That's not my mission. Creating files correctly isn't trivial, and a wizard would only help so much. For example: adding text subtitles requires the user knows stuff about character sets and encodings.

I'd rather produce more tutorial videos (https://www.youtube.com/user/mbunkus/videos) (probably with audio this time around). That allows one to focus on certain topics, e.g. the handling of subtitles.

A wizard would become pretty complicated pretty quickly. Sure, the basics are trivial: "first select a file to add. Oh, I see you have an audio track here. Do you want to set its language? Give it a description maybe? And what about the whole movie – a title perhaps? You could add more files, you know." But as soon as subtitles come into the picture it gets complicated. "Here's a 200 word introduction to character sets and encodings. Understood everything? Great, now select the correct character set."

And where does "simple remuxing" end? "Yo, my ACME Corporation TV doesn't play this Matroska file! Your wizard sucks!" Yeah… now you need the full power of all those settings. "You've added a file that might belong to a Blu-ray disc. Want me to scan the whole disc?" That's something that the GUI does already, but everything would have to integrated into one huge, complex wizard. More or less two separate implementations for the "merge" tool.

I'm not saying it couldn't work. It surely could. But it would be a chore for me, definitely not fun, and I'm not even certain it would have that much of an advantage over simple, short introduction videos.

[sneaker_ger]

For me, the scrollable list is a big waste of "real estate" as labels, inputs, combos, etc. don't need to be that wide. Maybe consider, in that view, to take a 3rd of it and add more to the left side. Just a thought. :)
Which pre-version are you using?
For me the right bar of the first layout would sometimes get stuck being way too big. I was just about to file a bug report but it seems Mosu already fixed it in the newest pre.

What I currently don't like is how the track info columns all get reset once you add another file. Really annoying, especially the default/forced track columns become extremely wide because of their names although they only have these little red/green signs. It would be nice to directly edit in the columns, btw. Like double-click the "forced" sign and it would switch to the other value. A small drop-down for languages, at least the common ones.

[Mosu]

Re "track properties in scroll area too wide": this was indeed the case in the very first pre-build that included the change. It only happened when you switched from the two-column layout to the scroll area layout. As soon as you restarted the program you could make the scroll area layout narrower again. It's also been fixed in the meantime as you've mentioned.

Re "re-sizing the columns": This is something I've been struggling with for the past couple of months (from the perspective of the developer). Ideally the program would remember the sizes of all columns if the user changes them manually. However, detecting this is really difficult. Qt provides a signal that is emitted whenever column widths change, but that change can occur for multiple reasons: the user has manually changed it, or its size has been forced by the GUI itself. The signal is even emitted when the control is set up and still completely empty!

Therefore I cannot save the column widths the moment they're changed (at least I haven't found a reliable way to distinguish between user-triggered resizing and program-triggered).

What I could do is to save them when the program exits. This has the drawback then anything in between uses the old values. For example, you have a merge tab open, add some files, change some column widths, then open another merge tag. At that point the changed column widths haven't been saved yet, hence the new tab will user other values. And even if I saved on exiting the program – which values would I use if multiple tabs are open? The first tab's? The last one's?

Another problem is that if I don't adjust the column widths automatically then the default width will be used (100 pixels if I'm not mistaken). So the first time the user starts the program and adds files (s)he will see a very dense view that's not easily readable.

So you see the problem isn't that easy to solve :( I'd really like to; I just don't know how exactly.

Re "editing values directly in the track list": I'm pretty undecided and have been for a long while. There are arguments in favor and some against. It's also not so easy to implement properly if you want it to be editable via keyboard as well, and that would be a must for me. I won't implement this mouse-only.

[Mosu]

BTW: Thanks for all the feedback so far, everyone. Keep it coming :)

[Boulder]

I have an input file from which the TrueHD track doesn't seem to be recognized by mkvmerge. I'm still recovering my videos from my media player archives so this one is a two-part MKV file which has been split using the Link files option.

This is what mkvinfo says about the second part:
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 834433118
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4029)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v1.2.3 + libmatroska v1.3.0
| + Writing application: mkvmerge v5.7.0 ('The Whirlwind') built on Jul 10 2012
18:39:26
| + Duration: 1072.489s (00:17:52.489)
| + Date: Thu Aug 02 03:05:51 2012 UTC
| + Segment UID: 0x9b 0x79 0xc1 0x91 0x1c 0xc1 0x0c 0x16 0x83 0xa9 0xc5 0xf3 0x
c 0xcf 0x1c 0x2f
| + Next segment UID: 0xaa 0x61 0x48 0x63 0x9b 0x32 0x9c 0x30 0xb3 0x90 0x28 0x
f 0xb7 0xec 0x1a 0x9c
| + Previous segment UID: 0xaf 0xdf 0xc1 0xcf 0x03 0xc5 0x5a 0xa2 0x9b 0x23 0xf
0xde 0x1a 0x2c 0x7b 0xd3
|+ Segment tracks
| + A track
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 8173216859290468522
| + Track type: video
| + Lacing flag: 0
| + MinCache: 1
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 46 (h.264 profile: High @L4.1)
| + Default duration: 41.708ms (23.976 frames/fields per second for a video tr
ck)
| + Language: und
| + Video track
| + Pixel width: 1280
| + Pixel height: 528
| + Display width: 1280
| + Display height: 528
| + A track
| + Track number: 2 (track ID for mkvmerge & mkvextract: 1)
| + Track UID: 8191596950013731458
| + Track type: audio
| + MinCache: 1
| + Codec ID: A_TRUEHD
| + Audio track
| + Sampling frequency: 48000
| + Channels: 6
| + A track
| + Track number: 3 (track ID for mkvmerge & mkvextract: 2)
| + Track UID: 15392436905305701051
| + Track type: subtitles
| + Lacing flag: 0
| + Codec ID: S_HDMV/PGS
| + Language: fin
| + Content encodings
| + Content encoding
| + Content compression
|+ EbmlVoid (size: 1132)
|+ Chapters
| + EditionEntry
| + EditionFlagHidden: 0
| + EditionFlagDefault: 0
| + EditionUID: 4572585569313503892
| + ChapterAtom
| + ChapterUID: 10256582477866524061
| + ChapterTimeStart: 01:40:06.959000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: 01:39:44.228
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 9039299565280919211
| + ChapterTimeStart: 01:49:59.218000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: 01:49:59.218
| + ChapterLanguage: eng
|+ EbmlVoid (size: 795)
|+ Cluster

If I try to append the two parts, the second one seems to be missing the audio track. At least it doesn't appear in the list of tracks even if I just add the MKV file separately. I've not come across this kind of an issue before.

[sneaker_ger]

I just splitted and re-merged a TrueHD file without problems so it does not appear to be a general problem. I suggest you upload samples.

[Mosu]

@Boulder: yes, I'll need a file for which this fails, please.

[Boulder]

How large files can you host on your FTP server? The file in question in 795 MB, I probably cannot cut it because mkvmerge doesn't recognize the TrueHD track :)

[Mosu]

Don't worry, I have more than a TB of space left :)

[Boulder]

Don't worry, I have more than a TB of space left :)OK, I'll upload the file right away..

[Boulder]

It's done, hope you'll find out something useful.

[Mosu]

Thank you very much.

[Mosu]

@Boulder: fixed in the latest pre-builds (https://mkvtoolnix.download/windows/pre/). Thanks again for the file.

[Boulder]

No problem, happy to help as always. I'll put the pre-build into good use as there's still a lot of videos to process :)

[AYColumbia]

There are splitters between the left side (files & tracks) and the properties as well as between the files and the tracks lists. You can adjust their position manually (within limits; all controls have a certain minimum size). This means that you could give the tracks list twice the space the files list has and assign the left side tripple the space of the track properties if the window is large enough.
Yup, I noticed that, however, as you say, it was limited in how far it goes to the right. Either way, I like having the layout options. :)

Which pre-version are you using?
For me the right bar of the first layout would sometimes get stuck being way too big. I was just about to file a bug report but it seems Mosu already fixed it in the newest pre.
...
I used the one linked to by Mosu initially, i.e., 1100. I should have grabbed the latest but wasn't sure and didn't have a lot of time then. I'll pull down the latest if I have some time to look tonight or tomorrow night.

[AYColumbia]

Latest pre-build scrollable looks great. I still prefer the two-column though. :)

BTW, it would be nice to have a UI reset of some sort that resets the UI back to default settings without having to manually deleting the INI file. Thanks for considering it.

[Overdrive80]

#Cosmetics Request.

* Name of tabs on 'merge' option is independent of output name´s. For files with large names is very hard look for one job/task. Like that:

http://s6.postimg.org/7vmcyu6rl/Captura_de_pantalla_2016_01_06_14_10_01.png

[Boulder]

I've also one request for the GUI: it would be nice if you could change the language of track via a right mouse button quick menu or a drop-down selection in the "Tracks, chapters.." sheet. Currently you need to select the track and then head over to the Properties sheet to change the language.

[Mosu]

BTW, it would be nice to have a UI reset of some sort that resets the UI back to default settings without having to manually deleting the INI file. Thanks for considering it.

Won't do it, sorry. First of all it's a lot of work, second users would then want to reset only certain parts but not others etc. I also don't think it's of much use (meaning nothing a lot of users would use regularly).

[Mosu]

Name of tabs on 'merge' option is independent of output name´s. For files with large names is very hard look for one job/task.

Won't do that either, sorry. Naming them only after an arbitrary number would become confusing quickly. And annoying: "which tab was the one with Star Trek? *click* nope *click other* neither this one *click* ah found it". And what happens when you close tab 1? Would tab 2 suddenly be renamed tab 1 (of course not, it would be even more confusing)? So leave numbers empty? Nah, I don't like it at all.

[Mosu]

I've also one request for the GUI: it would be nice if you could change the language of track via a right mouse button quick menu or a drop-down selection in the "Tracks, chapters.." sheet. Currently you need to select the track and then head over to the Properties sheet to change the language.

As I've said earlier in a response to Sneaker_ger: maybe, but not any time soon.

[mariner]

Problem loading large ac3 file

Greetings mosu.

Appreciate if you could kindly help with the issue of mkvmerge hanging when loading large ac3 files. These are ffmpeg generated 2 channel 48k 640k ac3 files, with duration greater than 4hrs.

Many thank and best regards.

[Mosu]

Hey,

a new year, a new release – v8.8.0. Only ten days since 8.7.0, but a lot of users are hitting a regression in 8.7.0 that makes mkvmerge crash. The user-visible result is that the GUI (wrongfully) claims that the mkvmerge executable couldn't be found. The underlying cause is a bug in the TrueHD detection code wrongfully thinking a file is indeed a TrueHD file while it actually isn't – e.g. it's happened with MPEG 2 video files, DTS files, h.264/AVC files etc.

Still, several enhancements and new features have been implemented in these ten days as well. Therefore this release is 8.8.0 and not 8.7.1.

Nothing has changed for package maintainers compared to v8.7.0.

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

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

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

2016-01-10 Moritz Bunkus <moritz@bunkus.org>
* Released v8.8.0.

2016-01-09 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: "run program after XYZ" enhancement: added a button for executing the program right now as a test run. See #1570 (https://github.com/mbunkus/mkvtoolnix/issues/1570).
* MKVToolNix GUI: "run program after XYZ" enhancement: an error message is shown if the program couldn't be executed. See #1570 (https://github.com/mbunkus/mkvtoolnix/issues/1570).
* MKVToolNix GUI: "run program after XYZ" enhancement: any leading spaces in the executable path are removed in order to make copying & pasting less error-prone.
* MKVToolNix GUI: "run program after XYZ" bug fix: the paths used in the variables and the executable are converted to the platforms native path separators. This fixes compatibility with Windows applications that don't support the use of forward slashes in path names like e.g. VLC. See #1570 (https://github.com/mbunkus/mkvtoolnix/issues/1570).

2016-01-08 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit: enhancement: mkvpropedit will accept terminology variants of ISO 639-2 language codes and convert them to the bibliographic variants automatically. Implements #1565 (https://github.com/mbunkus/mkvtoolnix/issues/1565).

2016-01-06 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: the GUI's default font's size is now scaled with the screen's DPI and is at least 9 points high (up from 8). Additionally on Windows "Segoe UI", which is Windows' default user interface font, is used instead of the default provided by Qt, "MS Shell Dlg 2".
* MKVToolNix GUI: enhancement: the user can select the font family and size for the GUI in the preferences.

2016-01-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed TrueHD detection both as raw streams as well as inside other contains if the stream does not start with a TrueHD sync frame.

2016-01-03 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: added a layout for the track properties where they're on the right of the files/tracks lists in two fixed columns. Implements #1526 (https://github.com/mbunkus/mkvtoolnix/issues/1526).

2016-01-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed a mis-detection of an MPEG-2 video elementary stream as a TrueHD file which then caused a segmentation fault. Fixes #1559 (https://github.com/mbunkus/mkvtoolnix/issues/1559).
* mkvmerge: bug fix: Matroska attachments with the same name, size and MIME type were not output during file identification.
* MKVToolNix GUI: merge tool enhancement: added a column to the "attachments" tab containing the file size.
* MKVToolNix GUI: enhancement: pressing the insert key when the focus is on the merge tool's source files or attachments list, on the chapter editor's chapter list or on the header editor's list will invoke the corresponding action for adding elements to that list.

2016-01-01 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: when using one of the "select all tracks (of type…)" actions the "properties" column didn't show the selection.
* MKVToolNix GUI: new feature: implemented adding, changing and removing attachments in existing Matroska files as part of the header editor. Implements #1533 (https://github.com/mbunkus/mkvtoolnix/issues/1533).

Have fun :)

[LeMoi]

Windows SmartScreen doesn't allow the setup file to be opened, first time i have this bug^^

[Mosu]

*shrug* Nothing I can do about it…

[nevcairiel]

*shrug* Nothing I can do about it…

Signing the executable with a valid digital signature generally prevents it from doing that, so... Yes there is! ;)

[LeMoi]

Windows automatically updated some days ago, maybe it's a new security feature for downloaded executabe files, I just chose execute anyway and it worked fine

[Mosu]

@nevairiel: true, of course, so let me re-phrase: nothing I'm willing to do at the moment :)

[foxyshadis]

Windows automatically updated some days ago, maybe it's a new security feature for downloaded executabe files, I just chose execute anyway and it worked fine

Windows is just a bit schizophrenic about what to allow; as long as its untrusted zone stream is removed, it will never pop up that message, but when it does and doesn't apply it seems a bit random. The nightlies from the FTP seem to pick it up most of the time (but not always!) and the official downloads never do, on 8.1.

[AYColumbia]

Windows SmartScreen doesn't allow the setup file to be opened, first time i have this bug^^
If you get the message in the banner across the screen, there's I believe a "Read More" or "More Info" (i can't recall exact wording) link in the message. If you click it, it opens/shows another part where a "Run anyway" button is available to allow you to run the program. You're basically acknowledging that you know the install is from a trusted source.

[LeMoi]

Thanks, that's what I said I did ;)

[ndjamena]

Riddle me this:


|+ EbmlVoid (size: 2550) at 6251
|+ Cluster at 8804
| + Cluster timecode: 0.029s at 8811
| + SimpleBlock (key, track number 1, 1 frame(s), timecode 0.029s = 00:00:00.029) at 8814
| + Frame with size 9236
| + SimpleBlock (track number 1, 1 frame(s), timecode 0.071s = 00:00:00.071) at 18057
| + Frame with size 5
| + SimpleBlock (key, track number 2, 8 frame(s), timecode 0.071s = 00:00:00.071) at 18068
| + Frame with size 2560
| + Frame with size 2560
| + Frame with size 2560
| + Frame with size 2560
| + Frame with size 2560
| + Frame with size 2560
| + Frame with size 2560
| + Frame with size 2560
| + SimpleBlock (key, track number 3, 8 frame(s), timecode 0.071s = 00:00:00.071) at 38557
| + Frame with size 768
| + Frame with size 768
| + Frame with size 768
| + Frame with size 768
| + Frame with size 768
| + Frame with size 768
| + Frame with size 768
| + Frame with size 768


The first episode of Supernatural, taken straight from it's original M2TS file. For some reason the first VC-1 frame, and therefore the file, begins at 29ms, then the second frame and all the audio tracks begin at 71ms. The problem being, if I point eac3to, tsmuxer or MediaInfo at the original m2ts file, none of them report a delay in it. If I extract the Play All using MakeMKV it doesn't add a delay either. If I remux the m2ts file using TSMuxer and ADD a delay to the audio, MediaInfo, EAC3To, TSMuxer AND MakeMKV will all happily report the new delay. It's a similar story with the first episode of Falling Skies, although it actually starts at 00:00:00.000 and therefore lacks the 29ms void in the beginning. Using that I assumed there was a bug in MKVMerge, but as a final test I decided to point FFMPEG at the things and remux them. The complication is FFMPEG added the same delays as MKVMerge (ie, all the audio frames began at the same timecode as the second video frame) although even it didn't add the 29ms void to the beginning of Supernatural.

So there's a problem here. Either MediaInfo, Eac3to, TSMuxer and MakeMKV are buggy, MKVMerge and FFMPEG are buggy, or there's something going on here that I don't understand.

(If I remux the TSMuxer 96ms delayed m2ts file with MKVMerge I wind up with a 138ms delay. The MakeMKV and MKVMerge files at least have the same number of frames and judging by the frame sizes the frames are in the same positions countwise, they just have the differing timecodes.)

[Thunderbolt8]

is anyone able to explain how the command line input has changed with the emergence of the new GUI? I put some files into mkvmerge, copied the cmd line and tried to modify it so that I can do batch work with it. first of all, which of the ways the cmd line can be displayed do I have to use with a batch file? the cmd one? the "dont escape" one?

this worked with the old version of mkvmerge:

for %%a in (*.mkv) do ("C:\Program Files (x86)\MKVToolNix\mkvmerge.exe" -o "test%%a" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:no" "-s" "0" "-D" "-A" "-T" "--no-global-tags" "--no-chapters" "(" "%%~na.ass" ")" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:no" "-a" "0" "-D" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "%%~na.dtsma" ")" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1920x1080" "-d" "0" "-A" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "%%a" ")" "--track-order" "2:0,1:0,0:0")

so how can I modify the current way the cmd line is displayed in order to have the same result I get from the old one?

this is my template I want to use with for %%a in (*.mkv) do (...)

windows (cmd.exe) format: "C:/Program Files/MKVToolNix\mkvmerge.exe" ^"--ui-language^" ^"en^" ^"--output^" ^"testTVShowS01E01.mkv^" ^"--language^" ^"0:und^" ^"--default-track^" ^"0:yes^" ^"--compression^" ^"0:none^" ( ^"TVShowS01E01.mkv^" ) ^"--language^" ^"0:ita^" ^"--default-track^" ^"0:yes^" ^"--compression^" ^"0:none^" ( ^"TVShowS01E01.flac^" ) ^"--language^" ^"0:eng^" ^"--default-track^" ^"0:yes^" ^"--forced-track^" ^"0:yes^" ^"--compression^" ^"0:none^" ( ^"TVShowS01E01.ass^" ) ^"--track-order^" ^"0:0,1:0,2:0^"

dont't escape format: C:/Program Files/MKVToolNix\mkvmerge.exe --ui-language en --output testTVShowS01E01.mkv --language 0:und --default-track 0:yes --compression 0:none ( TVShowS01E01.mkv ) --language 0:ita --default-track 0:yes --compression 0:none ( TVShowS01E01.flac ) --language 0:eng --default-track 0:yes --forced-track 0:yes --compression 0:none ( TVShowS01E01.ass ) --track-order 0:0,1:0,2:0

simply replacing the file names

testTVShowS01E01.mkv
TVShowS01E01.mkv
TVShowS01E01.flac
TVShowS01E01.ass

with

test%%a
%%a
%%~na.flac
%%~na.ass

does not seem to work any more because I get error messages when I try to run that modified cmd line (perhaps the error is due to something else though)

[ndjamena]

If there are spaces in the files' path names you need to surround them with double quotes.

"test%%a"
"%%a"
"%%~na.flac"
"%%~na.ass"

And you should probably make sure you're in the right directory or use "%%~dpna", "%%~fa" instead of just "%%a".

Getting the command line working isn't hard, it's all I ever use and I create mine from scratch. I don't know how much you know about it though.

[sneaker_ger]

If you do a FOR loop with parantheses you need to escape the parantheses of the mkvmerge command.

http://www.robvanderwoude.com/escapechars.php

[Thunderbolt8]

Ill try again. but which of these two cmd templates should I use now? do both work in the batch file?

[ndjamena]

If you're just issuing a single command you don't need the parantheses at all, then you won't need to escape them in the command.

[Mosu]

mkvmerge's syntax and escaping rules have NOT changed when the new GUI was introduced. The reason the new GUI uses something different than the old one is that the method used by the old GUI was incomplete/buggy if the file name in question contains "quotation marks" or ^carets^. cmd.exe's escaping together with how the C library interprets command line arguments is convoluted.

If your file names contain neither quotation marks nor carets then your old way should still work.

You can use the new GUI's cmd.exe escaping variant in batch files, too. Simply replace the whole argument that contains the file name (including all the escape characters) with the variable in quotation marks as ndjamena has shown.

Just don't use the totally unescaped variant.

[Thunderbolt8]

It works now for me:

for %%a in (*.mkv) do ("C:/Program Files/MKVToolNix\mkvmerge.exe" "--ui-language" "en" "--output" "test%%a" "--language" "0:und" "--default-track" "0:yes" "--compression" "0:none" "(" "%%a" ")" "--language" "0:ita" "--default-track" "0:yes" "--compression" "0:none" "(" "%%~na.flac" ")" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:yes" "--compression" "0:none" "(" "%%~na.ass" ")" "--track-order" "0:0,1:0,2:0")

I put everything into quotation marks, then it was fine.

for %%a in (*.mkv) do ("C:/Program Files/MKVToolNix\mkvmerge.exe" "--output" "test%%a" "--language" "0:und" "--default-track" "0:yes" "--compression" "0:none" "(" "%%a" ")" "--language" "0:ita" "--default-track" "0:yes" "--compression" "0:none" "(" "%%~na.flac" ")" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:yes" "--compression" "0:none" "(" "%%~na.ass" ")" "--track-order" "0:0,1:0,2:0")


edit:

actually this was enough already, yes: for %%a in (*.mkv) do ("C:/Program Files/MKVToolNix\mkvmerge.exe" --ui-language en --output "test%%a" --language 0:und --default-track 0:yes --compression 0:none "(" "%%a" ")" --language 0:ita --default-track 0:yes --compression 0:none "(" "%%~na.flac" ")" --language 0:eng --default-track 0:yes --forced-track 0:yes --compression 0:none "(" "%%~na.ass" ")" --track-order 0:0,1:0,2:0)

[Mosu]

BTW, I just noticed a bug. I have code in the GUI's escaping for Windows that checks whether an argument actually needs to be escaped or not. The idea was to have a simplified escaped view, e.g. arguments like --track-language or 1:ger don't need escaping after all.

Unfortunately that code is wrong, so everything's escaped making the whole thing look much more daunting than necessary. I'll fix that.

[Thunderbolt8]

I was already suspicious of much "^ stuff like that there was :p

[Mosu]

They're not wrong. They're just superfluous for most arguments.

[73ChargerFan]

mkvmerge's syntax and escaping rules have NOT changed when the new GUI was introduced. The reason the new GUI uses something different than the old one is that the method used by the old GUI was incomplete/buggy if the file name in question contains "quotation marks"

Did you mean the single quote character '
or the double quote character "

The single quote character ' is acceptable in a Windows file name.

Windows file naming convention (https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#naming_conventions) prohibits the reserved character " (double quote). Files can be created with invalid file names, but they can be difficult or impossible for Windows Explorer and command line interfaces to then delete.

[Mosu]

The real problem wasn't so much file names but the free-form strings the user might use: segment/file title, track names… Mentioning file names was misleading.

If you want to know the full extent of how unintuitive the whole escaping issue is with cmd.exe and the C runtime library then read this fine article (http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx). It contains detailed explanation how each part acts and a lot of examples where you'd just think "what the frak!?" mmg's escaping worked for a lot of cases, but it also got cases wrong. That people didn't notice this much is due to mmg NOT using the command line when executing mkvmerge safe for the location of the option file.

[Jamaika]

Hi Mosu
I can't add tags with MP4. Do you know how to do it?

[sneaker_ger]

What exactly are you trying to do? Mkvmerge cannot ever output mp4 files. Mkvpropedit cannot edit mp4 files.
You can use mp4 files as input for mkvmerge but the output will always be mkv. You can add tags while converting from mp4 to mkv just like with any other input file.

[Jamaika]

I thought about the creation of MKV container. However, I don't want to add tags.xml. Tags are in the MP4 container.

[SeeMoreDigital]

I thought about the creation of MKV container. However, I don't want to add tags.xml. Tags are in the MP4 container.If you want to discuss tags for the .mp4 container. I suggest you either create a new topic or find an old topic about the subject.

[Jamaika]

If you want to discuss tags for the .mp4 container. I suggest you either create a new topic or find an old topic about the subject.
Thanks for the tip. I'm not interested MP4 container.:mad:

As a courtesy I don't ask about compatible subtitles (mov_text) and attachments (add-item) for players PC to the mp4 container.

[foxyshadis]

Pretty sure he's asking why tags aren't automatically propagated from mp4 input files to mkv output.

[Mosu]

The answer would be "because mkvmerge doesn't support it and because I haven't been motivated to implement something like that at all".

[Thunderbolt8]

when I muxed a file with subtitle (.ass) compression and I remux this file without selecting compression, will the compression then be removed? or is it like that once muxed with compression the state of the file will always be compressed/altered and cannot be reverted?

[Mosu]

It depends on the codec in question. The following codec types will always use compression unless it's actively turned off: VobSub, PGS subtitles, USF text subtitles, VobButton. All other types will never use compression unless it's actively turned on. Whether or not it was compressed in the source file plays no role in that decision.

[Thunderbolt8]

how can I check whether the subtitle file I muxed into my movie file might have compression applied to it? I cant find any information about this in the header editor.

[Mosu]

Analyze mkvinfo's output of the track headers. If it contains a "content encoding" element then it's compressed. Maybe MediaInfo outputs similar information, too.

[Nerva]

I bought a simple DVD on teaching football, and wanted to convert it to a MKV so it could be watched on a phone or tablet etc. It turns out there was no playlist on the DVD and hence no chapters -- so when I ripped it, all I got were dozens of individual tracks. When I tried joining them together using MKVToolNix, I got one big file with no chapters, which is pretty useless. I am wondering if there's an option I'm not aware of in MKVToolNix to have it create chapters based simply on the tracks that are being appended?

[Mosu]

No, there isn't, and I have no plans whatsoever of adding one due to various technical problems.

[Nerva]

No problem -- it looks like DVDFab can handle it -- not my first choice, but at least it will work.

[mastrandrea]

I'm having a problem remuxing mkvs from handbrake (encoding video only) with mkvmerge (8.8.0 win 64bit): when I try to add audio from the same source I used for the encode, the resulting mkv has a -83ms delay on each audio track, and the a/v sync is off by that value (forcing a +83 delay restore the sync), is there an option I can turn on/off to disable this behavior or is this intended am I missing something?

[Mosu]

mkvmerge can only keep A/V sync for tracks that are currently in the same container. If you're adding e.g. a raw DTS file to a Matroska file then you'll have to adjust that DTS file's sync manually in many cases. This is perfectly normal as those raw tracks simply don't provide the timestamp information required for A/V sync.

Even if you use a container that does provide timestamps (e.g. a M2TS file) and only use an audio track from it you'll end up having to adjust the sync manually as mkvmerge normalizes the timestamps from all tracks read frmo the same M2TS file to start from 0. This is required as a lot of M2TS files have timestamps that start anywhere – e.g. when you record a DVB broadcast.

So yes, this behavior is expected. In general A/V cannot be fixed automatically (that's true in general, not just for mkvmerge). It requires human attention.

[mastrandrea]

Ok, understood, thank you.

[isidroco]

You cannot as there is no such feature at the moment, and I currently don't have any plans on implementing one – mostly because mkvmerge's flexibility makes it very hard to say where such a mark would have to be put exactly.

I understand the general case problem for chapters. But it could be easily implemented if it just uses first video track length (or a tick for first audio track) of each file to be joined as the start time of the next chapter mark. Worst that can happen is to have chapter marks on undesired places on complex cases.
Most joining are of simple files (1 audio+ 1 video of same length). When filming a show I have to cut on each song. Rejoining is easy, but chapter marks takes a LOT of manual chapter edition for a typical case of 20 songs. Probably 90% of joining are of simple files where chapter marks would be on the right place...

[Nico8583]

Hi :)
I'm using mkvtoolnix 6.8.0 and I would like to try mkvtoolnix 8.8.0 in order to be up-to-date but I read I may use --disable-track-statistics-tags, --engage no_cue_duration and --engage no_cue_relative_position. Is it true ? What are the elements to consider when upgrading from older version (like 6.8.0) to a new version (like 8.8.0) ?
Thank you !

[sneaker_ger]

CueDuration and CueRelativePosition elements have already been introduced back in version 5.9.0. Only track statistics are new IIRC.

[Nico8583]

Thank you, I believed CueDuration and CueRelativePosition was introduced after 7.0.0 but this cannot be correct. So my 6.8.0 should already use CueDuration and CueRelativePosition and only Statistics tags could be problematic with some players ?

[Mosu]

CueDuration and CueRealtivePosition were introduced shortly after the release of v5.8.0.

[Nico8583]

Ok thank you for confirmation, so if I have a problem with a MKV I'll look at Statistics tags.

[Nico8583]

Is it possible to get informations about global tags from mkvinfo (at least the number of tags) ? Or it's only possible with mkvmerge -i ?

[Mosu]

Only with mkvmerge's identification mode. That's what it's there for, after all. Use mkvmerge's JSON output for easier parsing: "mkvmerge -F json -i yourfile.mkv".

[Jamaika]

Hi Mosu
Can you give examples of the "append-mode"? I want to join the files in the group.

[Mosu]

Don't play with --append-mode unless you have issues with A/V in the appended parts. The default is usually fine. There are very few cases in which "--append-mode track" works better than the default ("file"); whether or not that is the case can only be determined by experimentation.

[Mosu]

Hey,

Development speed has slowed down a little in the last couple of days. Nevertheless today's release v8.9.0 contains a lot of bug fixes and enhancements.

There's one small change for package maintainers: a Polish translation of the man pages has been added.

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

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

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

2016-02-21 Moritz Bunkus <moritz@bunkus.org>
* Released v8.9.0.
* MKVToolNix GUI: the default font size adjustment has been deactivated for the time being as it causes problems on high DPI displays. See #1602 (https://github.com/mbunkus/mkvtoolnix/issues/1602).
* MKVToolNix GUI: bug fix: ampersands (&) in file names were shown as keyboard shortcuts in tab titles in various tools (merge tool, chapter and header editors, job output tool). Fixes #1603 (https://github.com/mbunkus/mkvtoolnix/issues/1603).

2016-02-20 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: header editor enhancement: when the user drags & drops files on an open header editor tab the GUI will ask the user what to do with them: either open the files as new header editor tabs or add the files as new attachments to the current tab. The action can also be set as the default. Implements #1585 (https://github.com/mbunkus/mkvtoolnix/issues/1585).
* MKVToolNix GUI: chapter & header editor enhancement: Matroska files are initially opened in read-only mode and only later re-opened in read/write mode in order to enable reading from write-protected files. Part of the implementation of #1594 (https://github.com/mbunkus/mkvtoolnix/issues/1594).
* MKVToolNix GUI: chapter & header enhancement: the error messages shown when a Matroska file could not be parsed have been improved to include the most likely reasons. Part of the implementation of #1594 (https://github.com/mbunkus/mkvtoolnix/issues/1594).
* MKVToolNix GUI: chapter editor enhancement: added a menu entry for removing chapters from an existing Matroska file. Inspired by #1593 (https://github.com/mbunkus/mkvtoolnix/issues/1593).
* MKVToolNix GUI: chapter editor enhancement: it is now possible to save chapters to Matroska files after having removed all entries (editions and chapter atoms). This effectively removes the chapters from the file. Implements #1593 (https://github.com/mbunkus/mkvtoolnix/issues/1593).

2016-02-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: job queue enhancement: added keyboard shortcuts for removing all completed jobs and for removing successfully completed jobs. Implements #1599 (https://github.com/mbunkus/mkvtoolnix/issues/1599).
* MKVToolNix GUI: merge tool enhancement: added icons to the context menu actions in the "attachments" sub-tab. Implements #1596 (https://github.com/mbunkus/mkvtoolnix/issues/1596).
* MKVToolNix GUI: merge tool enhancement: made the context menu entries in the "attachments" sub-tab clearer. Implements #1597 (https://github.com/mbunkus/mkvtoolnix/issues/1597).

2016-02-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed the handling of AVIs with a negative video height (which signals that the rows are arranged top-to-bottom).

2016-01-31 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: job queue bug fix: fixed an invalid memory access in the "edit in corresponding tool and remove from queue" functionality.
* MKVToolNix GUI: re-write, merge tool bug fix: the file identification is now based on mkvmerge's JSON output instead of its verbose output. This also fixes the merge tool not showing names of attachments inside Matroska files properly if those names contain spaces (#1583 (https://github.com/mbunkus/mkvtoolnix/issues/1583)).
* MKVToolNix GUI: merge tool bug fix: the "mux this" combo box was disabled if a single attachment was selected.
* mkvmerge: bug fix: removed spurious output generated during file identification in the HEVC detection code (e.g. "Error No Error").
* mkvmerge: bug fix: fixed the output of the "playlist_file" and "other_file" properties of the "container" entity in the JSON identification format from a single string to an array of strings. The format version has been bumped to 3 due to this change.

2016-01-30 Moritz Bunkus <moritz@bunkus.org>
* docs: added a Polish translation of the man pages by Daniel Kluz (see AUTHORS).
* MKVToolNix GUI: "run program after XYZ" enhancement: configurations can now be deactivated without having to change them. Implements #1581 (https://github.com/mbunkus/mkvtoolnix/issues/1581).

2016-01-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed parsing of AAC in MP4 with a program config element with an empty comment field at the end of the GA specific config. Fixes #1578 (https://github.com/mbunkus/mkvtoolnix/issues/1578).

2016-01-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: when reading Matroska files created by HandBrake that contain chapters the existing edition UIDs and chapter UIDs are removed and random ones created. This is necessary as HandBrake assigns sequential numbers starting at 1 for each file. Therefore there are two chapter entries with the UID 1, two with the UID 2 etc. and those should, strictly speaking, be treated as if they were a single chapter whereas the user expects those entries to stay separate entries. Implements an improvement for issues such as #1561 (https://github.com/mbunkus/mkvtoolnix/issues/1561).
* MKVToolNix GUI: merge tool bug fix: the GUI no longer requires at least one source file to be present before muxing can start in order to allow creation of track-less files. Fixes #1576 (https://github.com/mbunkus/mkvtoolnix/issues/1576).

2016-01-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: the "escape for Windows' cmd.exe" mechanism will only escape arguments that actually need escaping in order to produce easier to read command lines.

2016-01-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: QuickTime/MP4 reader: fix a division by zero in the index generation for certain old audio codecs that have certain header fields (bytes_per_frame, samples_per_packet) set to 0.

2016-01-13 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: global elements (EBML void and CRC-32 elements) are now handled correctly if they're located inside the segment info or the chapter translate parents.

Have fun :)

[filler56789]

Released v8.9.0

Danke! :thanks:

[SeeMoreDigital]

Cheers :)

[Sparktank]

Thanks for the bugfixes.:thanks:

[Jamaika]

Development speed has slowed down a little in the last couple of days. Nevertheless today's release v8.9.0 contains a lot of bug fixes and enhancements.
Do not worry, it's okay. Even when we complain. Practically there is nothing to improve. :)

[AYColumbia]

@Mosu,
Thank you for the update. I noticed that link to MKVcleaver on the last installation dialog is no longer available. Thought you'd want to know. ;)

[Mosu]

Thanks for the hint. I'll update the link.

[isidroco]

Sorry for the insistance, wouldn't it be possible to generate chapter marks on MKVs merged of only one type of content (ie: only WAVs as on a CD, or only video). Then one could add the rest of the content if needed.

[thewebchat]

I'm finding that mkvmerge is mangling the character encoding of ASS files. I have to explicitly specify the encoding as UTF-8 to avoid characters like emdash being replaced by gibberish. The only valid encoding of ASS scripts is UTF-8. Please fix.

[filler56789]

The only valid encoding of ASS scripts is UTF-8.

Nope, it isn't. Also, there is a difference between 'encoding schemes' and 'character sets'.

[leon]

Hi

this happens only for me ?

http://i65.tinypic.com/25ku9gy.jpg

[davidsama]

Yes, i just tried the site in firefox 44.02, ie 11 and chrome 48. I never once got any warning like that.

[Mosu]

I've implemented generating chapters in mkvmerge. Updated pre-builds (https://mkvtoolnix.download/windows/pre/) are available (build numbers 1144 and up).

[stax76]

Hello,

this is from a log file a french StaxRip user has sent me, first I though the mkv was MakeMKV created but it's mkvmerge created. StaxRip tried to extract A_PCM/INT/BIG with mkvextract and after it failed it used ffmpeg as fallback routine and this failed as well.

This is the message from the user:


It's because the audio format is "pcm_s16be" (aka A_PCM/INT/BIG) and ffmpeg can't demux this. I used eac3to for demux to pcm_s16le and it works.


Isn't wav suitable to extract A_PCM/INT/BIG ?


------------------------------------------------------------
Demux audio using mkvextract
------------------------------------------------------------

"E:\EvolFox\Desktop\DBconvert\StaxRip_x64_1.3.1.7_beta\Apps\MKVToolNix\mkvextract.exe" tracks "E:\Vidéo\EVANGELION_AIR\Bluray.mkv" 1:"E:\Vidéo\EVANGELION_AIR\Bluray temp files\Bluray ID2 Japanese.wav" --ui-language en

Error: Extraction of track ID 1 with the CodecID 'A_PCM/INT/BIG' is not supported.



General

Unique ID : 228284693106921395829134651014545420454
Complete name : E:\Vidéo\EVANGELION_AIR\Bluray.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 22.5 GiB
Duration : 1h 27mn
Overall bit rate mode : Variable
Overall bit rate : 37.0 Mbps
Encoded date : UTC 2016-03-03 08:31:01
Writing application : mkvmerge v8.8.0 ('Wind at my back') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4
DURATION : 01:27:02.764000000
NUMBER_OF_FRAMES : 4372
NUMBER_OF_BYTES : 23804592
_STATISTICS_WRITING_APP : mkvmerge v8.8.0 ('Wind at my back') 64bit
_STATISTICS_WRITING_DATE_UTC : 2016-03-03 08:31:01
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Video

ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=3, N=12
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 27mn
Bit rate mode : Variable
Maximum bit rate : 40.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio #1

ID : 2
Format : PCM
Format settings, Endianness : Big
Codec ID : A_PCM/INT/BIG
Duration : 1h 27mn
Bit rate mode : Constant
Channel(s) : 6 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Language : Japanese
Default : Yes
Forced : No

Audio #2

ID : 3
Format : PCM
Format settings, Endianness : Big
Codec ID : A_PCM/INT/BIG
Duration : 1h 27mn
Bit rate mode : Constant
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Language : Japanese
Default : No
Forced : No

[stax76]

another report I received was this:

Error: The file 'H:\Renamed\Movies\Star Wars - Episode I - The Phantom Menace (1999 6.3)\Star Wars - Episode I - The Phantom Menace (1080p) temp files\Star Wars - Episode I - The Phantom Menace (1080p)_attachment_Star.Wars.I.1999.German.DTSHD.DL.1080p.BluRay.x264-iNCEPTiON.nfo' could not be opened for writing: open file error.

the path length is 261 and the stupid Windoof limitation is 260, hence the error. In recent StaxRip builds all routines shorten paths if the limit of 260 is exceeded, I think the user's StaxRip build was too old.

mkvextract technically could support longer paths I think, here is some info:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396#maxpath

[73ChargerFan]

Did you notice that the file referenced is a text file? NFO
I wasn't aware that was a supported file type in StaxRip.

EDIT: As a work around, the windows command SUBST can create a virtual drive that points to the directory.

[wanezhiling]

http://forum.doom9.org/showthread.php?p=1759700#post1759700
Hi Mosu, can you do something?

[Mosu]

Neither mkvmerge nor mkvextract support a codec ID S_DVBSUB. The official Matroska codec specs (https://www.matroska.org/technical/specs/codecid/index.html) don't contain such an ID either. This means that whoever wrote the program that creates such files went around the Matroska team. I have no plans to spend time on that.

[Mosu]

Isn't wav suitable to extract A_PCM/INT/BIG ?

I'm not sure, but I don't think there's a format tag for Big Endian PCM; so that would be »no, it doesn't«.

Nevertheless, I've just implemented support for extracting A_PCM/INT/BIG to WAV by byte-swapping it to Little Endian PCM. Pre-builds (https://mkvtoolnix.download/windows/pre/) are currently being compiled and should be up in a couple of minutes.

Additionally I've implemented the same byte-swapping inside mkvmerge, too – meaning that all PCM data will now be written in Little Endian with A_PCM/INT/LIT as the codec ID. This should prove helpful to people whose players don't support Big Endian PCM inside Matroska.

[Mosu]

Did you notice that the file referenced is a text file? NFO
I wasn't aware that was a supported file type in StaxRip.

I'm guessing that the user wanted to extract an attachment. mkvmerge doesn't support NFO files as anything other than an attachment; they're free-form text files with arbitrary content, after all.

[stax76]

I'm not sure, but I don't think there's a format tag for Big Endian PCM; so that would be »no, it doesn't«.

Nevertheless, I've just implemented support for extracting A_PCM/INT/BIG to WAV by byte-swapping it to Little Endian PCM. Pre-builds (https://mkvtoolnix.download/windows/pre/) are currently being compiled and should be up in a couple of minutes.

Additionally I've implemented the same byte-swapping inside mkvmerge, too – meaning that all PCM data will now be written in Little Endian with A_PCM/INT/LIT as the codec ID. This should prove helpful to people whose players don't support Big Endian PCM inside Matroska.

Thanks Mosu, I told the user to try it again after the next mkvtoolnix release.