MKVToolNix v99.0 released

[Mosu]

Hey y'all!

Even though not much has happened with MKVToolNix over the last six or seven weeks, I've decided to finalize the first release of the year, v73. Nothing overly amazing in it.

One note for macOS users that isn't stated in the NEWS below: this release's DMG was built with FLAC support again. Sorry for the confusing in the previous version; that was due to build system setup SNAFUs on my end.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG & Linux AppImage (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

Version 73.0.0 "25 or 6 to 4" 2023-01-02
New features and enhancements

mkvmerge: greatly enhanced the speed of Base64 decoding which is used used e.g. when reading pictures embedded in Ogg or FLAC files or for binary data inside XML chapter & tag files. Even small blocks of data could take unreasonably long.
mkvmerge: added support for reading HEVC/H.265 video from FLV containers. Implements #3466 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3466).

Bug fixes

mkvmerge: splitting: fixed a typo in the string output in GUI mode regarding the timestamps before which splitting was done. See #3421 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3421).
MKVToolNix GUI: job output: after having run multiple jobs the "Clear output" functionality only reset the visible parts. However, using the "save output" function would also save the output generated before the user used "clear output". Now only the output after the last use of "clear output" is saved. Fixes #3438 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3438).
build system: when probing for the FLAC library the Ogg libraries will be linked with the compiled test program as well. This fixes detection if the "pkg-config" settings for FLAC don't list Ogg & the linker doesn't find the library automatically (e.g. for my macOS builds). Fixes #3439 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3439).


Have fun 😁

[VBB]

Thank you Moritz, and Happy New Year!

[filler56789]

Thanks for liking The Chicago Transit Authority. :)

[Mosu]

Chicago (with and without the suffix) has been a favorite of mine for more than 30 years now, and I still love their music to pieces today.

[outhud9]

Hi,

I've been having trouble getting MKVToolnix GUI to open on Linux Mint for a while now. Same issue on both LM21 and 21.1. I upgraded from LM20.3 a few months ago, but can't tell for certain if this is when the problem started. It had been working fine for years.

I've tried the version from the default repos (v65 I think?) and also 71 and now 73 today. I've tried with the mkvtoolnix Ubuntu repo, the Linux Mint repo and also with the AppImage. I used apt remove --purge mkvtoolnix* between different install attempts.

Same issue on all of them, the GUI doesn't open.

From a terminal --help and --version give the expected outputs, but running mkvtoolnix-gui alone doesn't open the GUI window.

After running mkvtoolnix-gui, I see this is from ps aux for about 10-15 seconds:

me@me-desktop:~$ ps aux | grep MKV
me 28416 1.4 0.0 388296 31708 pts/0 Sl+ 11:17 0:00 /tmp/.mount_MKVTooQcX2CD/usr/bin/mkvtoolnix-gui
me 28419 4.6 0.0 12572 2528 ? Ssl 11:17 0:00 ./MKVToolNix_GUI-73.0.0-x86_64.AppImage

and then both of these end, and I'm returned to a terminal prompt.

Anything I can try to debug this? Thanks!

[Ripman]

Hi Moritz. HNY. Thanks for the years of quality sw.

Sometimes we get subtitles that are formatted as closed captions - basically, subtitles that are fixed width. You can extract CC's as srt subtitles with CCExtractor_win_portable_v0.94, as an example.

So I got one CC srt file recently, and I wanted to add it to an MKV. These fixed width subtitles are always the same length per line - for the attached, it seems like 32 and 39. The non- white space text can start in any column. Even if your player centers subtitle text, the fixed width ensures that whatever "positioning" was used in the CC is also maintained.

So I muxed the fixed width srt into an mkv, and it gave strange results. I extracted the muxed srt, and it looks like white space is being chomped, but not for every line. It seems like all trailing white space is chomped, but not all leading white space is chomped. Ideally, unless the standard says otherwise, the subtitle text should not be changed at all - no chomping.

I have attached the original fixed width srt, and the srt extracted from the mkv I muxed.

Any insights on this one, M? Best.....

[Klaus1189]

Upload to Google drive or similar

[Ripman]

Upload to Google drive or similar

Regarding the fixed width srt finding I posted above, here is a link to all relevant files.

https://www.dropbox.com/sh/ke6mpcllswk99q0/AAB-tvtuKOR2zqL2-5dGgVbLa?dl=0

Win 10. Mkvtoolnix mkvmerge mkvextract v73.0.0.

The extracted srt file that is chomped - it displays that way on a TV or Vic when playing.

[Mosu]

I'm not sure if always keeping all whitespace is really the right thing to do. I'm definitely willing of making the behavior configurable, though. Please open an issue over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/) for it. Otherwise chances are I'll forget about it again. Thanks.

[Ripman]

I agree on the white space issue. None of the subtitle processing tools even give an option to preserve white space - Subtitle Edit, aegissub, SubSync, etc.

Either way, thanks as usual. I’ll put something over at git.

[Ripman]

I agree on the white space issue. None of the subtitle processing tools even give an option to preserve white space - Subtitle Edit, aegissub, SubSync, etc.

Either way, thanks as usual. I’ll put something over at git.

I created issue 3470 over at gitlab. Here is the link.

https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3470

Thanks everyone.

ADDED: I will say that editing these fixed width files can be tricky because of the aforementioned lack of support in some of the popular subtitle processing tools. So, in this particular case, the fixed width CCs are what comes from the video container - it's the source. I then re-created the srt without white space, which is in the dbox folder. I used SubSync to align these subtitle timecodes more closely. I then used a custom perl script I had to transfer the updated timecodes to the fixed width srt, which is also in the dbox folder. The UTF-8 srt files that come from CCExtractor_win_portable_v0.94 do not contain a BOM, so I had to manually insert those 3 bytes => used UltraEdit in hex mode.

[tormento]

Would be possible to give a directory for the files to attach?

It could be useful for many (who said fonts?) and positively useful for me :)

[Mosu]

Since v72 you can drag & drop directories onto the "attachments" tab and the GUI will attach all files in that directory.

[tormento]

Since v72 you can drag & drop directories onto the "attachments" tab and the GUI will attach all files in that directory.
I want to do it with command line, as it's a batch.

[Mosu]

You'll have to set up the command line with all the file names from that folder yourself; mkvmerge cannot help you with it.

[Ripman]

Thanks for that update. I tested 73.0.0.11 from the continuous builds with the new option that was added and the fixed width srt from the dbox link above. The srt file gets muxed in without any issues or changes.

Unfortunately- the idea of fixed width srt text files is not workable based on my simple tests. Vlc doesnÂ’t use fixed spacing for text subtitles, so the fixed width formatting doesnÂ’t work there. On my pioneer BDP-80 Elite, it doesnÂ’t even show the first subtitle - the unit freezes. The unit works fine with leading spaces on either subtitle lines 2 or 3.

So nothing useful here but at least the spaces are trimmed by default now. The thanks again btw.

[tormento]

You'll have to set up the command line with all the file names from that folder yourself; mkvmerge cannot help you with it.
In spare time, please, add the capability to use directory name too to include the files. It would help (at least me) to make scripts much readable and faster to paste in terminal.

[Ripman]

Thanks for that update. I tested 73.0.0.11 from the continuous builds with the new option that was added and the fixed width srt from the dbox link above. The srt file gets muxed in without any issues or changes.

Unfortunately- the idea of fixed width srt text files is not workable based on my simple tests. Vlc doesnÂ’t use fixed spacing for text subtitles, so the fixed width formatting doesnÂ’t work there. On my pioneer BDP-80 Elite, it doesnÂ’t even show the first subtitle - the unit freezes. The unit works fine with leading spaces on either subtitle lines 2 or 3.

So nothing useful here but at least the spaces are trimmed by default now. The thanks again btw.

I may have spoken too soon - apologies for that.

Using mkvmerge/mkvextract/gui 73.0.0.11 on Win10.

It would seem that using the new "whitespace" option is doing something a little different to the input srt file. Attached: 1. An srt that I muxed into an mkv; and 2. What gets extracted from the muxed mkv using mkvextract from the command line.

It would seem there is one extra crlf being inserted between subtitle entries when using the "whitespace" option. Interestingly, I put a double-space in sub #684 of the input file and it seems to be maintained - so that's good. The one extra crlf may be the source of freezing units I mentioned in previous posts on the topic, but that remains to be seen. I've tested SRTs when NOT using the new "whitespace" option, and everything seems to go in and come out as expected.

You should be able to take the input SRT in the attached, mux it into any mkv you have using the new "whitespace" option, and then extract the SRT to get the output SRT in the attached. Easy breezy. Thanks Moritz.

[Mosu]

Shoudl be fixed now.

[Ripman]

Shoudl be fixed now.

All good with 73.0.0.18. I inserted a fixed width srt file into an mkv. I extracted the srt with mkvextract and diff it with the original - everything matches and is fine.

No player freezes either. So that’s good.

I still don’t think these types of things work too well bc it requires the display to output fixed width characters, which most don’t. I suppose playing with various fonts on the playing device or sw could help.

Btw - I came across this while looking at some old DVDs that I’d replaced with BDs. Seems some old mpeg2 tracks have CCs embedded. Some examples I’ve come across:
- The Sting 2DVD special edition
- The Parallax view
- The Sheena Easton video on the Bond BD - For your eyes only
- Men of respect - early 90s DVD

THANKS AGAIN M. THE SW IS REALLY GREAT.

[r0lZ]

Hi Mosu.
A user of BD3D2MK3D has this error with mkvmerge: CreateEventA not found in library api-ms-win-core-synch-l1-2-0.dll. I suppose it's because he uses an unsupported version of Windows. Car you confirm? Or is it an outdated library?
Original thread at VideoHelp here (https://forum.videohelp.com/threads/395498-BD3D2MK3D-Convert-3D-BDs-or-MKV-to-3D-SBS-TAB-or-FS-MKV-Support-thread/page13#post2680579).

[lvqcl]

I suppose it's because he uses an unsupported version of Windows.

https://forum.doom9.org/showthread.php?p=1971554#post1971554 and several posts below it.

[Mosu]

Hi Mosu.
A user of BD3D2MK3D has this error with mkvmerge: CreateEventA not found in library api-ms-win-core-synch-l1-2-0.dll. I suppose it's because he uses an unsupported version of Windows. Car you confirm? Or is it an outdated library?
Original thread at VideoHelp here (https://forum.videohelp.com/threads/395498-BD3D2MK3D-Convert-3D-BDs-or-MKV-to-3D-SBS-TAB-or-FS-MKV-Support-thread/page13#post2680579).

Sounds like they're running Windows version not supported by MKVToolNix, e.g. 7.

[r0lZ]

Yes. I have just received confirmation that Win7 is his OS.
Thanks.

[kedautinh12]

Yes. I have just received confirmation that Win7 is his OS.
Thanks.

Win7 can use this ver
https://forum.doom9.org/showthread.php?t=184092&page=4

[r0lZ]

Indeed. Thanks.

[Mosu]

Hey y'all!

MKVToolNix v74 is out. This is another one in a longer line of small-ish bug fix releases. Nothing too earth shattering. Anyway, have fun with it.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

Version 74.0.0 "You Oughta Know" 2023-02-12
New features and enhancements

mkvmerge: SRT handling: added a hack called "--engage keep_whitespaces_in_text_subtitles" which disables stripping whitespaces from the start & end of each line of SRT entries during muxing. Part of the implementation of #3470 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3470).

Bug fixes

all: Windows: UNC paths of type "\\?\C:\…" are supported again by switching back to Boost's file system library instead of using C++17's file system library. Fixes #3058 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3058).
mkvmerge: AVC/H.264 & HEVC/H.265 packetizers: when appending tracks the pixel dimensions will be checked & muxing will be aborted if they don't match. Fixes #3480 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3480).
mkvmerge: file type detection: file types that can be detected unambiguously by their content (e.g. Matroska, MP4, WAV…) will now preferred in the detection order over file types based on their extension. Prevents certain cases of mis-detection, e.g. DTS in WAV but with a file name extension of ".dts" being detected as the wrong type of DTS. Fixes #3462 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3462).
mkvmerge: SRT handling: whitespaces will now be stripped from the start & the end of each line of each entry, not just from the end of the last line. Part of the fix of #3470 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3470).
mkvextract: SRT extraction: whitespaces will not be stripped from the start & end of the whole entry anymore. Part of the fix of #3470 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3470).
MKVToolNix GUI: multiplexer: when adding multiple files that include certain file types (chapters, segment info and tag files) and when the choice where to add them is "all files to a single new tab", these certain file types will now be added in the newly added tab as well instead of the current tab that had already been open. Fixes #3469 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3469).
build system: fixed compatibility with Ruby 3.2.0 by using "FileTest.exist?" instead of "File.exists?", "Dir.exists?" & "FileTest.exists?" which were removed in that release.

Build system changes

MKVToolNix is now using & requiring Boost's "file system" and "system" libraries again instead of C++17's file system library. This is due to gcc's library not supporting UNC paths of types "\\?\C:\dir\file.ext".


Have fun 😁

[Ripman]

Hi M. Thanks for the new v74 release.

Sometimes I use the gui to generate an options file. I noticed that sometimes the gui will put the —display-dimensions option with a width X height argument in the options file.

I never use the —display-dimensions from the command line. Is the option required? What happens if not used?

I did read the man page but didn’t see anything explicit about the questions I asked. Just wondering. I’m thinking if the option is not present, mkvmerge uses what it sees in the video stream.

Thanks again. Best…..

[Mosu]

In general mkvmerge will always set the display dimensions on the output file. If they're provided via a CLI option, then those will be used. Otherwise, if they're provided by the source container (Matroska), those values will be used. Otherwise, the pixel dimensions will be used. Therefore you only need to set the parameters if they're different from the ones derived by the scheme outlined earlier. The goal for mkvmerge is to preserve as much information as possible verbatim by default.

That being said, the GUI has slightly different use case & different goal. One of its purpose is to make the user more aware of settings that are set somewhere in the source file. In the case of e.g. the movie's title that title is therefore shown in the appropriate line edit. The same goes for the display dimensions: if the source container provides display dimensions, those values are shown in the track's display width & height line edits — so that the user can easily see that they're set & what they're set to. Last, the GUI doesn't try to reduce the command line to the smallest possible CLI. It simply gives all the options for which some control is set in the GUI. Therefore sometimes those options are redundant.

For example, if you add a Matroska file with a video track whose pixel dimensions and display dimensions are both 1000x600. In such a case you wouldn't need to specify "--display-dimensions 0:1000x600" as that would be mkvmerge's default to use anyway. The GUI doesn't care, though; it doesn't try to recreate all of mkvmerge's internal decision making & adds "--display-dimensions 0:1000x600" anyway.

[NVF]

First, thanks so much for the tool.

I've gotten time stamp error warnings in the past (.srt overlaps if I understood them correctly) but no longer. Any help understanding and/or fixing this issue would be appreciated.

Thanks.

[Mosu]

Heyo!

Time for another release. Again nothing major, just some bug fixing & adding a simple converter from timed-text to Matroska's simple format (SRT-like).

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads (https://mkvtoolnix.download/downloads.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

Version 75.0.0 "Goliath" 2023-03-26
New features and enhancements

mkvmerge: MP4 reader: mkvmerge will now read Timed Text (FourCC "tx3g") subtitle tracks & convert them on the fly to Matroska's simple text subtitle format ("S_TEXT/UTF8"; text only, no styles). Implements #2208 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2208), #2242 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2242), #2613 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2613), #3000 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3000), #3243 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3243), #3418 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3418) and possibly others.

Bug fixes

all: switched back to using "boost::filesystem" functions for creating directories instead of the ones introduced to work around bugs in "std::filesystem". The latter didn't work correctly with UNC paths after the switch to "boost::filesystem::path" in v74. Fixes #3483 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3483).
mkvmerge: VobSub reader: mkvmerge will now probe the ".idx" file during VobSub identification even if the ".sub" file is passed as the source. Avoids mis-detection of the ".sub" as MPEG program streams. Fixes #3489 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3489).
MKVToolNix GUI: the GUI could abort with an exception on startup while looking for the "mkvmerge" or "mediainfo" executables due to inaccessible folders. Fixes #3481 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3481).
MKVToolNix GUI: preferences: when opening the preferences the first time the UI might pre-select the first entry in the list of interface languages if the operating system's language is not available for MKVToolNix. This might also happen on Linux if e.g. "en_GB" is set, even though "en_US" is available. Now English ("en_US") will be selected instead. Fixes #3486 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3486).
MKVToolNix GUI: multiplexer: when adding files the GUI has special handling for chapter/tags/segment info files. This is done by comparing their content to certain patterns. This recognition could wrongfully be triggered if any such file was embedded in another file verbatim, e.g. with a chapter XML file attachment in a Matroska file. When trying to add that Matroska file, the GUI would treat it as a chapter file instead of a regular one. This content-based detection was fixed. Fixes #3487 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3487).

Other changes

mkvpropedit, GUI's header editor: removed support for the deprecated "minimum cache" & "maximum cache" track header elements.


Have fun ��

[NanoBot]

Thx for the new version.
I would like to mention that the link for the windows versions points to fosshub where only the outdated version 73.0 is available. The newest windows version is available here: https://mkvtoolnix.download/downloads.html#windows

:thanks:

[Mosu]

Oooooh right, I forgot to update my boilerplate macro. Thanks.

[Perenista]

https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3194

"Disable default track flag for audio tracks"

Where is that option?

[Mosu]

There is no such option.

[ctl-tx]

If you're taking suggestions, can the "Tracks, chapters and tags" window have a "en/disable selected items" option on the right click menu, just like in the "Attachments from source files" window? I'd like to be able to select and disable ten items there at once instead of one at a time.

[Mosu]

All actions taken in the "properties" pane apply to all selected tracks. Meaning there are two ways to achieve what you want to do already. After having selected a couple of tracks, you can

switch the "copy this item" drop-down box to "no" or
hit the return key, assuming your focus is still on the tracks view.

As I don't really like all that much duplicated stuff, I will not add a third option to that list.

The difference with the other view is that the other view doesn't have a properties pane in which there is such an option already.

[ctl-tx]

That's good enough for me! Thanks for the tip!

[AYColumbia]

I was encoding some old DVDs at 720x480. After running the merge command below, the AR is translating to 1280x960 instead of 720x540. Ideas? I'm having to use the property editor (CLI) to fix it for now. The elementary stream is 720x480.

"D:\MKVToolNix\mkvmerge.exe" --ui-language en --output ".\output\video.mkv"
--no-audio --no-video --title "video.mkv [nocues]" "(" "K:\DVD Source\video.mkv" ")"
--default-duration 0:24000/1001fps --aspect-ratio 0:4/3
--language 0:und "(" "video.hevc" ")"
--language 0:eng --no-chapters "(" "video.ac3" ")"
--track-order 0:0,1:0 --engage no_cue_duration --engage no_cue_relative_position

Thanks.

[UPDATE] Getting more strange results. The command below specifies specific dimensions so the display numers are correct in the resulting MKV but the pixel dimensions are 720x960 instead of 720x480.
"E:\MultiMediaTools\MKVToolNix\mkvmerge.exe" --ui-language en --output ".\output\video.mkv"
--no-audio --no-video --title "video [nocues]" "(" "K:\DVD Source\video.mkv" ")"
--default-duration 0:24000/1001fps --display-dimensions 0:720x540
--language 0:und "(" "video.hevc" ")"
--language 0:eng --no-chapters "(" "video.ac3" ")"
--track-order 0:0,1:0 --engage no_cue_duration --engage no_cue_relative_position

Here's the mediainfo output for the main+video to help. Maybe I'm missing something. Thanks a lot.
General
Unique ID : 9682556509059931718141687288042861920 (0x748CAE4AE737FE43B9CCF22F653B560)
Complete name : E:\media\work\video.mkv
Format : Matroska
Format version : Version 4
File size : 144 MiB
Duration : 25 min 32 s
Overall bit rate : 787 kb/s
Movie name : video [nocues]
Encoded date : UTC 2023-04-23 13:09:48
Writing application : mkvmerge v75.0.0 ('Goliath') 64-bit
Writing library : libebml v1.4.4 + libmatroska v1.7.1

Video
ID : 2
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L3.1@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 25 min 32 s
Bit rate : 593 kb/s
Width : 720 pixels
Height : 960 pixels <- pixel height in MKV
Original height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.036
Stream size : 108 MiB (75%)
Writing library : x265 3.5+37+12-4e46995bc:[Windows][MSVC 1931][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr /
no-ssim / log-level=2 / input-csp=1 / input-res=720x480 / interlace=1 / total-frames=36755 /
level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers /
annexb / no-aud / no-eob / no-eos / no-hrd / info / hash=0 / no-temporal-layers / open-gop /
min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=3 / b-adapt=0 / b-pyramid / bframe-bias=0 /
rc-lookahead=5 / lookahead-slices=0 / scenecut=69 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh /
ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 /
limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / no-signhide / no-tskip / nr-intra=0 /
nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=0 / no-limit-modes /
me=0 / subme=0 / merange=57 / temporal-mvp / no-frame-dup / no-hme / no-weightp / no-weightb /
no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=2 / selective-sao=0 / early-skip /
rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 /
psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 /
qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=10000 / vbv-bufsize=10000 / vbv-init=0.9 /
min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 /
aq-mode=1 / aq-strength=0.00 / aq-bias-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 /
no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=6 /
transfer=6 / colormatrix=6 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 /
log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps /
no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion /
no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 /
analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 /
refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 /
copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field /
qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 /
decoder-max-rate=0 / no-vbv-live-multi-pass
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.601 NTSC
Transfer characteristics : BT.601
Matrix coefficients : BT.601

[AYColumbia]

Bueller, Bueller, anyone, anyone... ;)

[nevcairiel]

Interlaced HEVC is practically unsupported in the entire open-source video world. Would strongly advise to not use it.

[AYColumbia]

Interlaced HEVC is practically unsupported in the entire open-source video world. Would strongly advise to not use it.
The input is interlaced but the output is NOT. I only add the --interlace switch because the x265 docs state that it indicates the input is interlaced.

I'm just trying to figure out why the resolution is winding up as it is.

[nevcairiel]

If the input is interlaced, then the output is interlaced. If you want it otherwise, deinterlace it first. --interlace indicates the input is interlaced, quite right, but it also tasks x265 to encode it as interlaced.
If you set --interlace with x265, it expects you to feed it individual fields, which you likely did not do, so it got frames, thinking those are fields (which would be half the height), hence your output is double the height.

[AYColumbia]

If the input is interlaced, then the output is interlaced. If you want it otherwise, deinterlace it first. --interlace indicates the input is interlaced, quite right, but it also tasks x265 to encode it as interlaced.
If you set --interlace with x265, it expects you to feed it individual fields, which you likely did not do, so it got frames, thinking those are fields (which would be half the height), hence your output is double the height.
Oof, yikes. I didn't realize that based on the full help and how it's worded. I also made and incorrect assumption that MediaInfo would show it as interlaced which it does NOT. I really appreciate you responding and clarifying. I'll have to reencode one more time. Thanks again. :)

[Perenista]

I put 938906 ms in delay for MKVToolnix for a MP3 track (to be in sync with a MKV more than 15 minutes later) and the app returned an error. Why? Is there a limit?

[Mosu]

There's no limit. Just guessing, as you didn't post the actual error message: you entered "938906 ms", but that option simply doesn't take a unit suffix. It only expects a number, and that number is interpreted as milliseconds.

[Mosu]

Heyo!

here's yet another release, v76.0. This is a slightly bigger one in terms of the number of fixed bugs & implemented improvements. Due to the change wrt. the handling of BlockAddition elements (which is required for HDR content for WebM, VP9, AV1`) I strongly recommend users to upgrade.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

Version 76.0 "Celebration" 2023-04-30
Important notes

mkvmerge: removed the option "--blockadd". Removing block additional data is not possible anymore, as it is often required for proper decoding. Part of the implementation of #3511 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3511).

New features and enhancements

mkvmerge: JSON file identification: added a child element called "num_index_entries" to the "properties" track element containing the number of index entries found for a track. Currently only implemented for Matroska files where it contains the number of cue points. See #3510 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3510).
mkvmerge: the maximum block addition ID track header value is now calculated automatically from both the existing mappings & the actually used block additions in the block groups. Part of the implementation of #3511 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3511).
mkvmerge: Matroska reader: when reading WebM files that use block additions with ID 4 (HDR for VP9) an appropriate block addition mapping will be created automatically. Part of the implementation of #3511 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3511).
mkvmerge: MP4 reader: the title/movie name meta data (content of the "udta.meta.ilst.©nam" atom) will now be copied over as the segment title track header attribute. Part of the implementation of #3475 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3475).
mkvmerge: MP4 reader: the comment & encoder meta data (content of the "udta.meta.ilst.©cmt" & "….©too" atoms) will now be copied over as global tags "COMMENT" & "ENCODER" respectively. Part of the implementation of #3475 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3475).
mkvmerge, MKVToolNix GUI's multiplexer: added an option to stop processing after the primary video track ends called "--stop-after-video-ends". This discards any remaining packets of other tracks. Part of the implementation #3506 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3506).
MKVToolNix GUI: only on Windows: the GUI now uses Qt's "Fusion" style instead of the deprecated "Windows Vista" style. The advantage is that as of Qt 6.5 the "Fusion" style properly supports Windows 10's & 11's dark application mode. The Windows binaries are now built with said Qt version. Therefore the option to disable the dark mode has been removed. Fixes #3264 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3264) and likely others.
MKVToolNix GUI: multiplexer: automatically setting the destination file name: added an option in the preferences for using the first source file's directory name instead of its file name as the basis for the destination file name. Implements #3512 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3512).
MKVToolNix GUI: multiplexer: double-clicking on certain columns in the "tracks" view will now toggle them directly (columns "Default track" & "Forced track") or activate the corresponding control (columns "Language", "Name" & "Delay"). Double-clicks on other columns will do what they've done before, too: toggling the "Copy item" state. Implements #3513 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3513) & others.
MKVToolNix GUI: the dialog for editing language tags is now created only the first time the user wants to edit a language tag & cached afterwards instead of creating a new instance each time. This makes subsequent uses instant.

Bug fixes

mkvmerge: mkvmerge will now only try to probe for VobSubs if the name of the file to identify ends in either ".idx" or ".sub", preventing mis-identification of other file types if VobSubs with the same base name exist in the same directory. Fixes #3508 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3508).
mkvmerge: AC-3: mkvmerge will now skip certain types of garbage data (16 bytes starting with 0x01 0x10) that can occur before each sync frame, fixing the file not being identified as AC-3. Fixes #3484 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3484).
mkvmerge: Matroska reader: when reading files that use block additions with IDs other than 1 (e.g. 4 for HDR for VP9) the IDs will now be kept & written to the output file. Before no ID would be written, effectively using 1 as that's the default value for the corresponding element. Part of the implementation of #3511 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3511).
mkvmerge: mkvmerge will no longer write block addition mappings or the max block addition ID track header elements when creating a WebM file as those elements aren't supported there. Part of the implementation of #3511 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3511).
mkvpropedit: fixed replacing chapters & tags in files that don't contain tracks. Fixes #3498 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3498).


Have fun 😁

[hubblec4]

Many thanks for your work, Mosu!!

[AYColumbia]

Many thanks for your work, Mosu!!
My sentiment exactly. Thanks Mosu! 😊

[Kuler087]

love the new features. thanks! :)