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?