MKVToolNix v24.0.0 released

[ndjamena]

Originally Posted by 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.

Apparently your file doesn't have a seek head, so MKVMerge goes looking for one...

hmmmmm.

[Mosu]

Originally Posted by rsotome

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.

[Mosu]

Originally Posted by rsotome

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) a try? They implement a different way of checking such files and should handle file type recognition faster.

[Boulder]

Originally Posted by 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. 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.

Originally Posted by 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.

OK. I use the "attachments" without {--raw}.

[szabi]

Hi

Today I wanted to update 8.51 to 8.60, that alert did come up.

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 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, the Windows installer and portable version and the source code.

Here's the full 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.
* 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.
* 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 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.
* 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.
* 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.

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.
* 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.

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.

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.

Have fun.

[Jamaika]

Hi Mosu

Originally Posted by 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,

Originally Posted by Jamaika

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]

Originally Posted by 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?

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.