MKVToolNix v24.0.0 released

[AYColumbia]

Hmm… please open a ticket in my bug tracker (https://trac.bunkus.org/) about that issue; otherwise I'll most likely forget about it (more than busy at the moment).
I'll put it in the bug tracker now. Thanks.

Okay, I had to grab the 7z file to update to the latest build and it worked great. However, the executable would not launch. I saw, for a split second, the dialog frame and then it would go away. This is happened on both my Windows 8.1 Pro and 7 Ultimate OSes. Both running 64 bit.

[Mosu]

Which executable? mkvextract, mkvpropedit and mkvmerge are pure CLI applications; they don't have a GUI, so it's perfectly normal that there's only a new cmd.exe window that disappearsa gain afterwards.

[AYColumbia]

Which executable? mkvextract, mkvpropedit and mkvmerge are pure CLI applications; they don't have a GUI, so it's perfectly normal that there's only a new cmd.exe window that disappearsa gain afterwards.
Oh, no, I was talking about the install file, i.e., mkvtoolnix-amd64-6.8.0-build20140310-598-441cded-setup.exe. However, this is not an issue any longer. Seems to be working now. Not sure what in the world happened there.

BTW, defect ticket 1005 created.

[Mosu]

I've seen it; thanks.

[hubblec4]

Hi Mosu

I have a question for the mux with mmg at a Bluray with multi editions inside.

My T2 BD will mux every fine but with another BD(multi editions) the mkv has "hiccup's" during the playing.

What could be the problem? or is any other information for mux with mmg neccessary? maybe a timecodes-file?

[Mosu]

I'm not sure how multi-edition BluRays differ from other ones, but I haven't done anything about those things, so I guess they're simply not really supported.

[hubblec4]

that confuses me. m2ts file appending works very well. with or without the mpls file.

manually appending work too, but not in every case.

can you explain me how i can use the timecode file? or is it the wrong way? i found not really much infos.

[bxyhxyh]

Please tell me Traditional Chinese flag. I've searching it for hours from dropdown list.

[Mosu]

Please read this FAQ entry (https://trac.bunkus.org/wiki/FAQ%3AChineseNotSelectableAsLanguage) which explains why you cannot do that.

[Simon88]

Does anyone have the equation necessary to calculate the "Stretch by:" value for a particular video? I have an old video that is 44 minutes and 58 seconds in length. However the audio gradually loses sync. In the beginning it is in sync, and near the end it is off by about 3.5 seconds... Can someone show me how the fraction (ratio) is calculated to obtain the "Stretch by:" value for such a video?

Thanks!!

[sneaker_ger]

(44*60+58)/(44*60+58+3.5) or (44*60+58+3.5)/(44*60+58)?

[Simon88]

(44*60+58)/(44*60+58+3.5) or (44*60+58+3.5)/(44*60+58)?
:thanks:

[Simon88]

I have a Matroska file that has an Aspect Ratio of 16/9. However, it has a VobSub subtitle that looks stretched. So I force the display of the Matroska video with a 4:3 Aspect Ratio and the subtitle looks OK, but the video of course does not.

I realize there is an IDX file for each SUP where I can alter the scale, but the Matroska file container must have a switch somewhere where I can set the Aspect Ratio in the IDX during the importing of the IDX/SUB bitmaps, like the same way we can override the video Aspect Ratio. I'm hoping I don't have to do it manually... :-)

Thanks...

[LeMoi]

You can manually edit the .idx file and change the "# Original frame size" item or the "# Image scaling (hor,ver), origin is at the upper-left corner or at the alignment coord (x, y)" item

[hubblec4]

@ Simon you could use BDSUP2Sub.

[Simon88]

@hubblec4: I'll definitely look at this neat program you mentioned...

@LeMoi: Do you know of generic changes to the IDX that will work for ALL cases of 4:3 --> 16:9 subtitle conversion?

I'm thinking of creating a simple batch file where I can mkvextract the IDX/SUB, then use SED to modify the IDX, and then re-integrate the new one into a new file in a separate directory, whenever I find one in my collection.

Thanks..

[Ars92]

Don't know why I didn't use this tool from the start. So much more reliable than mediacoder. Effortlessly muxes my drm less iTunes file with subs in less than 10 seconds!

Sent from my SM-N9005 using Tapatalk

[Mosu]

Hey,

I've released MKVToolNix 6.9.0. There the usual bug fixes all over the place but nothing major, but it was time for a new release.

For package maintainers nothing has changed compared to 6.8.0.

Here are the usual links:

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

…to the binaries:
http://www.bunkus.org/videotools/mkvtoolnix/downloads.html

Here's the full ChangeLog since release 6.8.0:

2014-04-18 Moritz Bunkus <moritz@bunkus.org>
* Released v6.9.0.
* all: new feature: added a Brazilian Portuguese translation of the programs by Thiago Kühn (see AUTHORS).
* mkvpropedit, mmg's header editor: bug fix: fixed a failed assertion in libEBML when writing the same changes twice to certain files (those for which a seek head with a single entry pointing to the elements modified by mkvpropedit/mmg's header editor; e.g. x264 creates such files). Fixes #1007 (https://www.bunkus.org/trac/ticket/1007).

2014-03-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: reading fonts embedded in SSA/ASS files was sometimes truncating the attachments created from them. Fixes #1003 (https://www.bunkus.org/trac/ticket/1003).
* mkvmerge: bug fix: fixed display of very large IDs during attachment extraction.
* mkvmerge: enhancement: improved file type detection speed for text subtitle formats.

2014-03-10 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: during the extraction of chapters, tags or segment info XML files with the --redirect-output parameter the BOM (byte order mark) was written twice.

2014-03-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG TS: timestamp outliers are ignored if they differ at least five minutes from the last valid timestamp. Fixes #998 (https://www.bunkus.org/trac/ticket/998).
* mkvmerge: enhancements: trailing zero bytes will be removed from AVC/h.264 NALUs. Implements #997 (https://www.bunkus.org/trac/ticket/997).

2014-03-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed timestamp assignment for AVC/h.264 videos in which recovery point SEIs occur in front of the second field of two interlaced fields.

Have fun.

[schorman]

Just installed the newest version, 6.9.0, for 64 bit Windows. When I add tracks it uses up to 10Gb of memory and basically stalls the system. I think there is some kind of memory leak.

I would advise not installing this version yet.

[Mosu]

What kind of file have you added? What kind of tracks are in it?

[Mosu]

Oh wait, I can reproduce this easily. I'll fix it and prepare a new release for that.

[schorman]

Wow, that was fast. Thanks. Just for good measure, it stalled while adding an h264 video track.

[Mosu]

Fixed. I'm now preparing release v6.9.1 which will take the usual two to three hours (building all binaries, posting in the usual places etc). Stick to 6.8.0 until then, please.

[Mosu]

The file type actually doesn't really matter. One of the file type detection modules (called »readers« in mkvmerge terms) was accidentally reading the whole file into memory.

Back with 6.8.0 that reader (a subtitle reader) was probed almost last. Therefore that issue pretty much never came to light. For 6.9.0 I've moved all subtitle readers up to the top because normally they're way, way faster than a lot of other readers (especially the h.264/h.265 ones). That exposed the bug.

As I usually test with small files due to muxing large files taking a lot of time I haven't noticed it before…

Shit happens and stuff :)

[Boulder]

Mosu,

is it generally "safe" to join two mkv files by appending them? The video, audio and subtitle tracks have the same characteristics. I have a few blu-rays which have a documentary part and a concert part which I'd like to join for viewing and then archive that version instead of archiving two clips.

What I've noticed is that the chapter points do not work correctly with joint files, I guess I need to create a new file manually.

[Mosu]

Chapters usually work just fine with appending. And yes, appending is generally safe.

[Mosu]

Hey,

I've released MKVToolNix 6.9.1 mere hours after the release of 6.9.0 due to a severe bug that wasn't present in 6.8.0. Here's the combined announcement for both releases.

There were the usual bug fixes all over the place. No major new features, but it was time for a new release.

For package maintainers nothing has changed compared to 6.8.0.

Here are the usual links:

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

…to the binaries:
http://www.bunkus.org/videotools/mkvtoolnix/downloads.html

Here's the full ChangeLog since release 6.8.0:

2014-04-18 Moritz Bunkus <moritz@bunkus.org>
* Released v6.9.1.
* mkvmerge: bug fix: fixed huge memory usage when probing files (it was reading the whole file into memory for that).
* Released v6.9.0.
* all: new feature: added a Brazilian Portuguese translation of the programs by Thiago Kühn (see AUTHORS).
* mkvpropedit, mmg's header editor: bug fix: fixed a failed assertion in libEBML when writing the same changes twice to certain files (those for which a seek head with a single entry pointing to the elements modified by mkvpropedit/mmg's header editor; e.g. x264 creates such files). Fixes #1007 (https://www.bunkus.org/trac/ticket/1007).

2014-03-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: reading fonts embedded in SSA/ASS files was sometimes truncating the attachments created from them. Fixes #1003 (https://www.bunkus.org/trac/ticket/1003).
* mkvmerge: bug fix: fixed display of very large IDs during attachment extraction.
* mkvmerge: enhancement: improved file type detection speed for text subtitle formats.

2014-03-10 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: during the extraction of chapters, tags or segment info XML files with the --redirect-output parameter the BOM (byte order mark) was written twice.

2014-03-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG TS: timestamp outliers are ignored if they differ at least five minutes from the last valid timestamp. Fixes #998 (https://www.bunkus.org/trac/ticket/998).
* mkvmerge: enhancements: trailing zero bytes will be removed from AVC/h.264 NALUs. Implements #997 (https://www.bunkus.org/trac/ticket/997).

2014-03-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed timestamp assignment for AVC/h.264 videos in which recovery point SEIs occur in front of the second field of two interlaced fields.

Have fun.

[microchip8]

I see no package for openSUSE 13.1. Still building/packaging?

[Mosu]

Yes, packages for certain distros/versions are still being built. I simply didn't want to hold off too long as more and more bug reports were coming in.

[schorman]

Thanks again for the fix and thank you for your wonderful work on mkvmerge. Great program and truly invaluable.

[netmask]

I'm using Firefox with the Foxbleed add-on. When I went to the author's page I was presented with a HeartBleed warning. Not sure if it is a false positive, so far I have only detected it on 2 other web sites.

[Mosu]

The SSL libraries are up to date on my server (I did that on the day Heartbleed was revealed to the public), but I haven't revoked and re-issued the certificate. It is highly debatable whether or not one insignificant site such as mine warrants panic over non-re-issued certificates, though.

PS: Please no discussion about this here, it's highly offtopic.

[Selur]

to the Mac users: http://jonthn.free.fr/MKVtoolnix/ has a new mkvtoolnix build for Mac OS X!

[Mosu]

Indeed, and it's already been added to my download section. I've also been working with a kind German Mac user who has spent quite a lot of hours trying to compile everything, and yesterday he has succeeded (including the GUIs; statically linked; for 10.8 and newer). So we may hopefully expect more up-to-date DMGs in the future – independent of Jon's erratic update schedule.

[Selur]

Jonathans builds are 10.7+ compatible, so personally I would prefer them over the 10.8+ versions. (I would even more prefer a 10.6+ compatible version ;))

[Mosu]

You may use whichever you wish, of course. But Jon's track record for updates hasn't been stellar for a year. So you may have to switch some day. Or maybe he'll update regularly again now. We'll see.

[szabi]

Hi

Is that possible by mkvtoolnix (http://www.bunkus.org/videotools/mkvtoolnix/) after a given time, automatically switch from one audio stream to an other?

bye
szabi

[Mosu]

No, that is not possible (even though I don't really understand what you want I can still answer »no« because none of the possible interpretations that I have for your question can be fullfilled with Matroska in general or MKVToolNix in particular).

[Simon88]

Hi

Is that possible by mkvtoolnix (http://www.bunkus.org/videotools/mkvtoolnix/) after a given time, automatically switch from one audio stream to an other?

bye
szabi

It is the player's job to do the audio track switching, so a script/batch file to "force" the switching from one audio to the other can be done.

Another workaround, is just use the "Append" button in mmg. It will not require any scripting by the media player. File size will of course be doubled... Good luck...

[Simon88]

I have some MKVs w/ parts of it broken. I find MKVtoolnix will skip and re-mux OK if it's the end or somewhere in the middle is broken, with the missing parts eliminated after a re-mux and most of the video recovered and plays fine without freezing the media player.

However, how would I make mkvtools read an MKV file that is broken or missing the beginning of the file? Is there a switch I can use to force the scanning & re-muxing of valid MKVs that is broken in the beginning? Or can you offer a "generic" chunk of binary data I can simply append or hexeditor copy to the beginning of the file to force mkvtools to scan, read, and fix the good portions of the file and create a viewable file? Thanks..

[Mosu]

If the track headers have been damaged: not really, no. First you'd have to know exactly which codecs were used for which track, which track had which track number etc. Then you'd also have to know the exact format of CodecPrivate for a lot of video codecs (which you don't, with almost absolute certainty). From a purely technical standpoint it is possible in some cases, of course, but it would take even someone with in-depth knowledge of Matroska an exorbitant amount of time (think several days for a single file).

If all the files use the very same tracks and the very same codecs with the very same codec settings then it may be possible to copy segment and track headers from another file to your damaged one. However, there's no tool that could automate this kind of work. It would look roughly like this:

Determine the start position and the length of the EBML head, segment info and the track headers elements in the working file and extract them to separate files
Determine the position of the first readable cluster (basically the first cluster ID followed by a length information after which another cluster ID can be found) in the bad file, remember that position
Copy the EBML head, segment info and track headers from step 1 into the new output file
Copy everything from the bad file starting at the position found in step 2 to the new output file
Edit the new output file and modify the segment element's length field to match the new file length (or set it to undefined)
Try to re-mux with mkvmerge or to watch the movie

All of those steps involve heavy work with hex editors, deep knowledge of EBML and Matroska structures, a lot of time and a lot of patience.

[Simon88]

Thanks for detailed explanation... I guess it'll be easier for me to just re-encode and/or re-capture them from the tape source...

btw, if the info for the header is so important and if bytes usage is insignificant, would you consider storing another copy of it at the end, or some other convenient place in a MKV file or provide an option to do so, if feasible, in a future specification update in order for increased robustness?

[Mosu]

Well it's only allowed for the track headers. Storing the EBML head or the segment head twice would pretty much bork the whole file.

Other media formats aren't any better. If you overwrite the first few KB in an AVI or an MP4 file then those files are just as unusable. Again other formats (especially MPEG transport streams) are more resilient by sending the required headers multiple times. They do it because they were explicitly designed for streaming in which you need to be able to join the stream at almost any moment. Matroska wasn't designed for this, and I highly doubt we'll ever adjust it in such a way. Resilience always has a cost: in terms of wasted space, but also in complexity for all software components that need to read such files. How are players supposed to act if they find two differing copies of track headers? What about editing track properties: if the second copy is somewhere in the middle and you enter a very, very long track name so that the track header copy won't fit there anymore; where do I store it now?

On top of all that you have to keep compatibility with existing players in mind.

So the answer is »most likely no«. Sorry.

If you need general resilience then I suggest using something like PAR files and storing them somewhere else (on different hard drives, at least).

[Carpo]

Is it possible to add movie information into the MKV container, like you can with MetaX and MP4 - apologies if this has already been asked

[Simon88]

Is it possible to add movie information into the MKV container, like you can with MetaX and MP4 - apologies if this has already been asked

"File/segment title" and "Attachments"... However, attachments must be crafted in way your front-end or viewer expects them...

[Carpo]

The players in question would be MPC-HC, MPC-BE, J River and Playstation 3, I am guessing the PS3 wouldn't see any of it and to be honest I am not that concerned, as I may just stream directly from the PC to the TV anyway, guess I need to read MKVTool's documentation

[Simon88]

The players in question would be MPC-HC, MPC-BE, J River and Playstation 3, I am guessing the PS3 wouldn't see any of it and to be honest I am not that concerned, as I may just stream directly from the PC to the TV anyway, guess I need to read MKVTool's documentation

If it's cover art, I believe it is explained at:
http://www.matroska.org/technical/cover_art/index.html

And some players use: Movie.nfo within the mkv to display misc. info.

[Carpo]

I know it can do cover art, I was hoping to add such things as, year, director, cast, summary, that sort of thing.

I have looked at the documentation and it seems like I should be able to add most of the above in an .xml file, but I haven't seen anything about adding a plot summary

[sneaker_ger]

http://matroska.org/technical/specs/tagging/index.html
"SUMMARY" might be what you're looking for.

You mentioned "MetaX". The website says it already has support for mkv tagging built-in.

[Carpo]

Thanks, will take a peek :)