I’ve released MKVToolNix v7.5.0. It contains a lot of new features dealing with h.265/HEVC video & AAC audio, some minor assorted enhancements and quite a number of bug fixes – especially some which prevent invalid memory access.
One important change for everyone building the packages: libEBML v1.3.1 and libMatroska v1.4.2 are now required. Both have been released today. Note that both libraries have been switched to use an autoconf/automake based build system and provide
MKVToolNix’ own configure script has therefore been changed to look for the libraries via their respective
pkg-config files. This means that the
--with-extra-libs don’t affect the detection of libEBML/libMatroska anymore. Instead you can set the environment variable
PKG_CONFIG_PATH to where the pkg-config scripts of libEBML and libMatroska are located.
You can download the source code or one of the binaries.
Here’s the full ChangeLog since the previous release:
- 2015-01-04 Moritz Bunkus <firstname.lastname@example.org>
- Released v7.5.0.
- mkvmerge: bug fix: If the target drive is full then a nicer error message is output instead of simply crashing due to an uncaught exception.
- mkvmerge: bug fix: Fixed reading MPEG transport streams in which all PATs and/or PMTs have CRC errors. Fixes #1100.
- 2015-01-03 Moritz Bunkus <email@example.com>
- all: bug fix: Re-wrote the whole checksum calculation code. This lead to a fix for the Adler32 checksum algorithm that was triggered under certain circumstances. Adler32 is used in mkvinfo’s output (e.g. in summary mode or if checksums are activated), in the h.265/HEVC bitstream and TrueAudio (TTA) file headers.
- 2015-01-01 Moritz Bunkus <firstname.lastname@example.org>
- mkvmerge: bug fix: fixed handling of HE-AACv2 with object type »parametric stereo«.
- mkvmerge: new feature: implemented support for MP4 DASH files. Implements #1038.
- 2014-12-31 Moritz Bunkus <email@example.com>
- mkvmerge: new feature: implemented reading MPEG-H p2/HEVC video tracks from MP4 files. Implements #996.
- 2014-12-30 Moritz Bunkus <firstname.lastname@example.org>
- mkvinfo: bug fix: track statistics: the duration (and therefore the estimated bitrate) was wrong for files in which the frame with the maximum timecode wasn’t the last frame in the file. Fixes #1092.
- mkvmerge: new feature: implemented support for AAC in LOAS/LATM multiplex if read from MPEG transport streams or raw LOAS/LATM AAC files. Implements #877 and fixes the underlying issue in #832.
- 2014-12-21 Moritz Bunkus <email@example.com>
- build system: libEBML and libMatroska have been changed to provide pkg-config configuration files. Therefore MKVToolNix’ build system has been switched to look for both libraries via pkg-config.
- 2014-12-20 Moritz Bunkus <firstname.lastname@example.org>
- 2014-12-19 Moritz Bunkus <email@example.com>
- build system: libMatroska v1.4.2 is now required as part of a fix for #1096.
- 2014-12-18 Moritz Bunkus <firstname.lastname@example.org>
- build system: libEBML v1.3.1 is now required as a part of a fix for #1089.
- mkvinfo: bug fix: mkvinfo will abort with a proper error message if the first element found is not an EBML head element. See #1089.
- all: enhancement: improved exception messages that can occur when reading damaged Matroska files to make it clearer for the user what’s happening. See #1089.
- 2014-12-16 Moritz Bunkus <email@example.com>
Hey Mosu, !BiG! THX to you, to integrate the “OLD GUi” again!!! <3
This is like Bday and Christmas together in one :D
Now Microsoft only must input the Win7 Gui/Desktop+Startmen to Win10 and i was complete happy!
Greetz and for this i donate your tomorrow!
(This is a machine translation).
How to muxing VFR video from the container MP4. After muxing operation MediaInfo writes CFR video in MKV?
You don’t have to do anything special – mkvmerge already does everything automatically. MediaInfo is just unable to distinguish between CFR and VFR in Matroska reliably and often reports wrong data.
I so and expected.
Still failed to mux the subtitles from the original file…..
I’ve got some questions/suggestions to you:
1) I always thought (I guess other people too) that muxing is absolutely lossless process where total time and average & peak bitrate are always identical/equal as in original source (file). For example I have decided to use Bitrate Viewer and check all parameters in the both files (.mp4 & .mkv). The result you can see here: http://s10.postimg.org/q14lor9qh/Comparison.png
As you can see there is different total time and different average & peak bitrate. My question is: Is that a bug or not a bug? In my opinion it is, but I’m not sure that’s why I’m asking you here. You should know that I have more .mkv files (e.g. BD copy of „Predator”) where those differences are much bigger than in this screenshot. But, on the other hand, I have also only one .mkv file where all parametres are identical (e.g. .m2ts file & .mkv file of „Heat” by Michael Mann). Of course I always use latest version of mkvmerge to mux the files. If there is necessity, I can create new ticket (defect) and make new screenshots for you.
In conclusion: If muxing is lossless process then (in my view) total time and bitrates should be absolutely equal without any deviations. Personally I’m really annoyed when I see that my copy in .mkv is not the same like in the original source. Please note that muxing doesn’t mean (lossy) compression where a „ripper” reduces video bitrate to get much less file size. When I use mkvmerge, I would like to be absolutely sure that my copy in .mkv will be definitely intact.
2) Is it possible to implement, in the new GUI, the following features:
a) In MakeMKV, when I add movie with DTS-HD MA or DTS-HD HR or Dolby TrueHD, I can choose if I want to mux full audio track (MA + DTS Core/HR + DTS Core/TrueHD + AC3 Core) or DTS/AC3 Core only. I would like to implement (have a choice) that option in mkvmerge. I mean something like this: http://s14.postimg.org/46e5t7cw1/Make_MKV.png
Currently, when I want to mux only DTS Core, previously I have to extract it in tsMuxeR and then add it to mmg. Remember please that many people don’t need to mux full lossless audio track (e.g. DTS-HD MA) which size is often very large (e.g. +/- 4 GB or even more). In many cases simply DTS Core (+/- 1 GB) is absolutely sufficient and rewarding. Also I need to mention that a lot people don’t have professional audio decoder to hear lossless sound.
In conclusion: In my opinion it’s very important to implement such feature; thereby you could easily choose which „part” (e.g. MA or DTS Core) to select and mux.
b) In the window of mkvmerge GUI audio tracks like DTS-HD MA and DTS-HD HR are recognized/displayed as »DTS« that is vague designation. It means that users don’t see clear/real name of these tracks. Note that in all other programs (e.g. BDInfo, tsMuxeR and MakeMKV) you can see accurate names of concrete audio tracks. As you guess, I would like to implement transparent names/titles where, instead of »DTS«, will be (for example): DTS-HD MA (or DTS-HD Master Audio), DTS-HD HR (or DTS-HD High Resolution Audio) and DTS Core instead of »usual DTS«. I think it would be very useful and important feature for many people who »don’t know« which DTS audio track to select.
c) My last proposition (I guess it’s impossible?) is to implement extraction for DTS Core and AC3 Core (e.g. Downconvert DTS-HD to DTS like in the tsMuxeR). I suppose that it’s not necessary option, but for sure would be interesting and useful (e.g. when you have a movie where you need to join DTS Core from another release).
I hope you will consider about my suggestions (especially „a” & „b” section). I strongly believe that MKVToolNix can be more precise and friendly tool.
Thank you for your hard work and I keep my fingers for you.
> 1) I always thought (I guess other people too) that muxing is absolutely lossless process
It is. The effective bit rate is not changed at all; the number of bytes that represent encoded content is not changed. The number of bytes that deal with meta data, however, may differ, e.g. mkvmerge removes unnecessary filler data from h.265 content.
I don’t know how Bitrate Viewer calculates the bit rate, and I don’t particularly care, as there are several different ways of calculating it (e.g. do you calculate it based on the file’s total duration or on the track’s? Those differ usually). Therefore differences between content stored in MP4 and Matroska are absolutely expected.
There’s no bug in mkvmerge regarding the bit rates; please don’t file a ticket for this.
> a) In MakeMKV, when I add movie with DTS-HD MA or DTS-HD HR or Dolby TrueHD, I can choose if I want to mux full audio track (MA + DTS Core/HR + DTS Core/TrueHD + AC3 Core) or DTS/AC3 Core only. I would like to implement (have a choice) that option in mkvmerge. I mean something like this: http://s14.postimg.org/46e5t7cw1/Make_MKV.png
That’s a definite »no, sorry«. In Matroska one track may only ever contain a single codec, not two codecs at once (which is how TrueHD + AC3 Core is implemented in other containers).
> b) In the window of mkvmerge GUI audio tracks like DTS-HD MA and DTS-HD HR are recognized/displayed as »DTS« that is vague designation.
This has nothing to do with the GUIs as it would have to be implemented in mkvmerge first anyway. You can create a ticket for that in my bug tracker as a feature request if you want me to implement it as I will most likely forget about it again if there’s no ticket, but I won’t place a high priority on it.
> c) My last proposition (I guess it’s impossible?) is to implement extraction for DTS Core and AC3 Core
Only keeping the core of DTS and AC3 is not that difficult, but it still has to be implemented in mkvmerge. So the same answer as the one for b) applies here as well.
1) Thank you for your clarification. Now I’m assured and I don’t worry about picture quality. But out of curiosity I have made two additional screenshots:
In comparison 2 you can see identical parameters. In comparison 3 those parameters differ.
> „That’s a definite »no, sorry«. In Matroska one track may only ever contain a single codec, not two codecs at once (which is how TrueHD + AC3 Core is implemented in other containers)”.
No, no, no. Excuse me, but it seems that you didn’t understand correctly what I (wrote) meant or maybe I wasn’t precise enough. First of all: I KNOW EXACTLY that in Matroska one track may contain only one single codec — it’s absolutely obvious. In my essence I meant something absolutely different. Now, I will try to explain you again what I mean and what I would like to implement to mkvmerge:
First, just look here: https://trac.bunkus.org/wiki/FAQ%3ATrueHDAndAC3. Two years ago you wrote (quotation):
»In future I may change that behaviour so that mkvmerge will present the interleaved AC3 part as a track of its own so that the user can chose wether to mux the AC3 part into its own track or to discard it«. ==================> THIS IS WHAT I MEAN, THIS IS WHAT I WANT! My intention is only to have a choice, nothing more. The same situation applies DTS-HD MA & DTS-HD HR: both audio formats contain lossy audio track (DTS Core) which — in my opinion — should be displayed in the window of GUI.
Look: On Saturday, when I showed you this: http://s14.postimg.org/46e5t7cw1/Make_MKV.png I didn’t mean to join DTS-HD MA (lossless Master Audio + lossy DTS Core) + DTS Core in one track. I meant to be able to choose if I want to mux DTS-HD MA with DTS Core in one (but separately of course) .mkv file (like this): http://postimg.org/image/fm56vrgnb/ or DTS Core only (without Master Audio).
In conclusion: I hope that you understand now what I want to do. Again: I want to implement to mkvmerge DISPLAY ability of the DTS Core and AC3 Core =========> exactly the same like in the competing programs like MakeMKV or tsMuxeR (especially like in the MakeMKV). Believe me: it’s really horrible for me and for many people (wasting time!) when I/We have to use — for example — tsMuxeR to extract AC3 Core (or DTS Core) and then add it to mmg. It would be very nice and useful to allow people if they want to mux — for expample — only TrueHD (without AC3 Core) or TrueHD with AC3 Core (in one .mkv file, but separately of course). So……. Can I create a new ticket for that? Are you interested to make a life easier for us? :) :) Please, try to understand that discarding (or hiding) the Core is not fortunate.
3) Last but not least: I would like to create a ticket (feature request) for support 3D Blu-ray Discs: .SSIF files & MVC amendment. All right, I know that your personal interest in it is rather low and you don’t have currently time to spend on it, but I don’t want you to forget about it; that’s why I want to apply. Finally, I’ve got something special for you: Because I know that you don’t have any 3D movies, I want to help you: I’m able to upload (easily and quickly) several 3D Blu-ray Discs and 3D Blu-ray Remuxes* to your FTP server. All what I need is your consent of course and I have to know exactly how many 3D movies do you need to start the tests? My proposition is (for example): three 3D Blu-ray Discs and three 3D Blu-ray Remuxes (total = 6). I think 6 movies will be enough for you, unless you need less (?) or more (?). It’s your choice. Of course I realize that you will probably start the work in the very far future, but I can upload those movies in the short time.
In conclusion: Note that competing programs — like tsMuxeR and MakeMKV — support 3D Blu-ray structure. To be honest: they’re not as advanced and prestigious like MKVToolNix; that’s why MKVToolNix (mkvmerge) shouldn’t be worse than them. In my opinion support for 3D is significant in »armaments race«. :D
*3D Blu-ray Remux means a copy with untouched video and audio quality, but without original menu and bonus features like in the 3D BD (1:1).
> »In future I may change that behaviour so that mkvmerge will present the interleaved AC3 part as a track of its own so that the user can chose wether to mux the AC3 part into its own track or to discard it«. ==================> THIS IS WHAT I MEAN, THIS IS WHAT I WANT! My intention is only to have a choice, nothing more.
Ah, I see; I did indeed misunderstand you. There’s nothing changed since writing that FAQ entry; I still don’t have any intention of actually implementing this. The underlying reason is that such a change would require massive re-writes of a lot of code (the DTS, TrueHD, AC3 handling code on the codec side, the MPEG transport stream handling code on the file format side and the GUI’s code so that it’s clear where that track comes from), and I’m simply not willing to do that work at the moment, nor in the near future. Besides, a lot of discs already contain the core (e.g. AC3 for TrueHD+AC3) as a separate audio track so users often have that choice already (not always, but often).
> 3) Last but not least: I would like to create a ticket (feature request) for support 3D Blu-ray Discs: .SSIF files & MVC amendment.
You can create a ticket for that, sure, and those are things I would like to support in the long term, but definitely not any time soon. It’s not just about having the source material to work and test with, it’s mostly about available time and priorities. I would definitely appreciate having files to work with for when I decide to start working on it, but ripping discs and uploading them somewhere else is clearly copyright violation and shouldn’t be discussed here.
Thank you again for your answer. Soon I should create four new tickets. Summarizing:
1) feature request: support for 3D Blu-ray Discs: .SSIF files & MVC extension
2) feature request: accurate designations for audio formats such as DTS-HD MA & DTS-HD HR which are displayed as »DTS«
3) feature request: ability to extract DTS core from DTS-HD MA & DTS-HD HR and AC3 core from Dolby TrueHD
4) feature request: ability to show DTS core and AC3 core which are embedded in HD audio formats such as MA/HR/TrueHD
By the way:
> »Besides, a lot of discs already contain the core (e.g. AC3 for TrueHD+AC3) as a separate audio track so users often have that choice already (not always, but often)«.
To be precise: it depends on the place where you live because there are countries/regions (like USA, West Europe) in which BD releases factually contain additional AC3 as a separate audio track, but there are also countries (like Central and Eastern Europe) in which BD releases don’t contain any AC3 as a separate audio track. In my case, as I live in Poland, I have no choice. I’ve got only two ways:
— use tsMuxeR (wasting time, but necessary) to extract the core and then add it to mmg
— use MakeMKV [which shows, and allows to select (or not), the core] instead of mkvmerge GUI
Now you see why I’m so stubborn. I really care to make MKVToolNix as a matchless tool. I strongly believe in that :)
I know this is not the right place to ask, but:
is it possible to put mkv with chapters into mkv container to disjoint connection between video and audio?
I want a way to reuse video frames to lower file size by 5-10%(animation). But audio must be different every time.
doesn’t work in players and splitters. Besides haali and lav splitters work bad on a frame-level switching.(lag 1-2 seconds). VLC seems to be more accurate, but it’s usseless, because can’t support any kind of audio switching.(I suppose).
* “ChapterTrackNumber” doesn’t work in players and splitters.
Ad vocem to my comment from 20 January, 2015 @ 17:31:
Finally I have created three of four planned tickets because I recognized that ability to extract the cores is not necessary for me at the moment.
How can I link fragments of files with the same, not unique SegmentUID? (chapters)