MKVToolNix v99.0 released

[Mosu]

Okay, how to set the PAR to 1:1 on a source?

No need to open an issue anymore. The problem should be fixed by this commit (https://gitlab.com/mbunkus/mkvtoolnix/-/commit/aa2588bb1447826d71391da408cd6b5020128b26). Please read the explanation in the commit's message for details on what actually happend.

[Selur]

Thanks, afk. today, will look at it tomorrow evening and report back.

[Selur]

Okay, I did some tests:
av1:
mkvmerge --ui-language en -o "G:\Output\2023-09-03@18_46_32_6310__02.mkv" --global-tags "J:\tmp\mkvtags_2023-09-03@18_46_32_6310__02.xml" -d 0 --default-track 0:yes --default-duration "0:25/1fps" --aspect-ratio-factor 0:16/11 --no-chapters --compression -1:none --forced-track 0:yes --field-order 0:0 --no-audio --no-subtitles "J:\tmp\av1_1_2023-09-03@18_46_32_6310_01.av1" --track-order 0:1
x264:
mkvmerge --ui-language en -o "G:\Output\2023-09-03@18_46_46_6310__02.mkv" --global-tags "J:\tmp\mkvtags_2023-09-03@18_46_46_6310__02.xml" -d 0 --default-track 0:yes --default-duration "0:25/1fps" --aspect-ratio-factor 0:16/11 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --field-order 0:0 --no-audio --no-subtitles "J:\tmp\2023-09-03@18_46_46_6310_01.264" --track-order 0:1
x265:
mkvmerge --ui-language en -o "G:\Output\2023-09-03@18_46_54_1610__02.mkv" --global-tags "J:\tmp\mkvtags_2023-09-03@18_46_54_1610__02.xml" -d 0 --default-track 0:yes --default-duration "0:25/1fps" --aspect-ratio-factor 0:16/11 --no-chapters --compression -1:none --forced-track 0:yes --field-order 0:0 --no-audio --no-subtitles "J:\tmp\2023-09-03@18_46_54_1610_01.265" --track-order 0:1
Conclusion is: Now x264 and x265 works, but av1 is broken.
I tried av1 files created with QSVEncC, NVEncC, aomenc, svt-av1, to be sure it's not related to av1 from one encoder.
And the funny thing is the av1 streams from av1-svt, rave1 and aomenc are handled correctly, the others are not.
Uploaded the muxed files to GoogleDrive (https://drive.google.com/drive/folders/1oz4h0J5W3l6kRe9mqMtnVciOcloM6ySz?usp=drive_link).

Cu Selur

[Boulder]

Running mkvalidator on one file muxed by mkvmerge 79.0, I get an error "ERR0B1: Block at 1439158911 track #2 is not a keyframe". Didn't try reinstalling the previous version yet, but is this something to submit an issue about?

[Mosu]

Running mkvalidator on one file muxed by mkvmerge 79.0, I get an error "ERR0B1: Block at 1439158911 track #2 is not a keyframe". Didn't try reinstalling the previous version yet, but is this something to submit an issue about?

No. That's wrongly labeled as an error by mkvalidator. In my personal opinion this shouldn't even be a warning. It's not a violation of the specs, it's not even a severe issue wrt. performance. Would it be ideal to have each cluster start with a key frame for each track? Sure. Is it always possible? Definitely not.

[Ripman]

Hey M. Hope you had a nice summer. About 34 today in NYC.

=> Is “Video Display Unit” (VDU) set based on the values for “Video Display Width” (VDW) and “Video Display Height” (VDH) passed with the --display-dimensions option? Or maybe based on whether the --aspect-ratio option or the --aspect-ratio-factor option was used.

(I’m assuming --aspect-ratio can be passed as 16x9, 4x3, 1.85, 2.40, etc., but I’m not sure what values can be passed for --aspect-ratio-factor.)

The reason I ask is because I have a widescreen mpeg2 video, that, after being cropped and encoded to mpeg4, shows a VDW of 11418 and a VDH of 6237 via the MKVToolNix header editor. This will give the proper aspect ratio of (almost) 1.85, but I think these “big” values can cause problems with TVs and other HW because the equipment isn’t expecting numbers that big. The cropped video is 718 wide and 462 high, and with a PAR of 32/27 gives the same aspect ratio as the big numbers above.

(Do these big values 11418 x 6237 seem normal - do they make sense?)

Here is a post where I describe the details with links to work files, etc. Go to the 2 most recent posts at the bottom - August 24.

https://forum.handbrake.fr/viewtopic.php?t=43016

Any insights are very much appreciated. I’m trying to figure out if this is an equipment/HW limitation, an encoding bug, or a lack of understanding on my part. The reason I asked about the options is for the case where it is an equipment/HW limitation or an encoding bug and some repairs would need to be done on older encodes - I’ve already developed a Perl script that uses mkvinfo and mkvmerge and updates the VDW and VDH values based on the “Video Pixel Width” and “Video Pixel Height” from the mkv header. I want know how to handle VDU. Thanks and best…..

[tormento]

I have found this (https://github.com/gnoling/UnlinkMKV) utility.

Is it possible to do the same with "standard" MKVToolnix package?

[Ripman]

I have found this (https://github.com/gnoling/UnlinkMKV) utility.

Is it possible to do the same with "standard" MKVToolnix package?

Yes. MKNToolNix is a more comprehensive tool with excellent stability and accessible expertise. That’s the gui version. There are also command line utilities in the bundle so that all operations can be ‘batched’ - mkvinfo mkvmerge mkvextract.

Read the man pages. They are very detailed.

[tormento]

Sorry if it's been already asked but I have searched and not found.

When importing a BD episodic playlist, sometimes there are opening and ending sections for every episode in the middle of the episode itself, before the epilogue or after the prologue.

Besides having the "Before chapters", it would be nice to have a syntax such as "4-5+10-11, 12-13+18-19" or something like that to tell the program to use from chapters 4 to 11 but chapters 5 and 11 and from chapters 12 to 19 but chapters 13 and 19.

I could do it splitting by hand, encoding and joining by hand but I should deal later with chapters, subtitles, etc.

[hubblec4]

cE has such an option to split and join the parts you have mentioned automatically.
BD2mkv -> Split-section
OK, there you can only enter time stamps, not chapter numbers.

[tormento]

cE has such an option to split and join the parts you have mentioned automatically. BD2mkv -> Split-section
OK, there you can only enter time stamps, not chapter numbers.
Thanks for the info and the feature.

Unfortunately, manually inserting time stamps would be a PITA for large BD collections.

[TheEqualizer]

mp4fpsmod?

-d, --delay <n> Delay audio by n millisecond.



Is it possible to select a specific audio track to apply the delay (we are talking about when there are several audio tracks in the video), I tried the -map parameter, swears that I don't understand, I can't find a solution.

[tormento]

I am trying to split a mpls by frames, using 'After frame/field numbers' and in 'Frames/fiels:' I am feeding the values:

951,44243,79459,85791,121017,124634,127241,129940,162576,166176,172438.175137,204104,207714,209988,212687,245555,251865,287078,290673,292920,295619,328600

The resulting error is:

Invalid frame for '--split' in '--split frames

The resulting CLI is:

mkvmerge.exe --ui-language en --output ^"N:\Raw\26-00017.mkv^" --language 0:en --language 1:it --language 2:ja --language 3:it ^"^(^" ^"N:\Naruto_BD26\BDMV\PLAYLIST\00017.mpls^" ^"^)^" --split frames:2698,37951,44243,79459,85791,121017,124634,127241,129940,162576,166176,172438.175137,204104,207714,209988,212687,245555,251865,287078,290673,292920,295619,328600 --chapter-language und --generate-chapters-name-template ^"Capitolo ^<NUM:2^>^" --track-order 0:0,0:1,0:2,0:3

What am I doing wrong?

[Mosu]

frames: expects a single number, which is taken to mean "split after every n frames".

Try "by parts by frames" or whatever it's called in the GUI; the CLI equivalent: "--split parts-frames:a,b,c,d,…"

[Boulder]

I've been trying to teach the AI to create a simple chunked encoding tool. The basic stuff works fine, but it stumbles upon joining the resulting webm files. Is there a way to feed a simple list of files to concatenate with mkvmerge? I'd rather not use ffmpeg as it seems to cause some issues like repeating frames. The input list would be like:

F:\Temp\Captures\encodes\lotr_fotr\chunks\encoded_chunk_0.webm
F:\Temp\Captures\encodes\lotr_fotr\chunks\encoded_chunk_1.webm

etc. The number indexing is not a problem, that can be adjusted.

[Mosu]

With a shell that expands shell wildcards (e.g. bash, zsh), sure: mkvmerge -o out.webm [ encoded_chunk*.webm ]

[tormento]

With a shell that expands shell wildcards (e.g. bash, zsh), sure: mkvmerge -o out.webm [ encoded_chunk*.webm ]
Your download repository is giving me bad gateway error.

Anyone else?

[Mosu]

Thanks for the heads-up. I've restarted the offending daemon.

[Magister Irrylio]

Will A_MS/ACM support ever be added to mkvextract? I can get around it by just putting it into an mka with mkvtoolnix and then converting that to FLAC with ffmpeg, but it's inconvenient compared to just extracting every track, especially when working with multiple files. Don't really see why mkvextract can't simply extract it.

[Mosu]

I'm not interested in implementing it.

[Mosu]

Heyo!

Time for another release. I'm still in a bit of a coding slump (or rather: preoccupied with all the amazing games that have come out this year); therefore this release is really, really small. I'll likely do one more bug fix release this year that'll be around this size as well. But let's see how things shake out.

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 80.0 "Roundabout" 2023-10-29
New features and enhancements

MKVToolNix GUI: if the system's locale uses one of the Han scripts, the GUI will force Arabic numerals to be used in spin boxes. This prevents Suzhou numerals from being used which seems to be the default on Windows systems sold in China. Implements #3624 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3624).

Bug fixes

build system: fixed detection of Qt6 if "clang" is used for compilation on Linux. In that case Qt's "qmake" added a "gcc"-specific option that "clang" doesn't understand, "-mno-direct-extern-access". "configure" will now pass the parameter "-spec linux-clang" to "qmake" so that it uses the correct compiler flags.
build system: fixed the use of "mktemp" to be more portable to e.g. macOS. Fixes #3608 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3608).
mkvmerge: if a video aspect ratio was given with "--aspect-ratio-factor", the code would apply a second factor based on the pixel resolution, resulting in much too large values for the "DisplayWidth" element. For example, with a pixel resolution of 720x520 & an aspect ratio factor of 1/1 the result should be 720x520, but instead it was 900x520. Up until release 76.0 this has only happened when a track order was given (which unfortunately includes all invocations with MKVToolNix GUI as it always includes the track order). Starting with release 77.0 this has always happened due to the automatic sorting of tracks implicitly creating a track order, even if none was given.


Have fun 😁

[varekai]

Thanks, much appreciated!! :)

[Perenista]

Is there a way to disable the warning about saving files with only the video track?

[Mosu]

Yes, in the preferences → "Multiplexer" → "Warn about missing audio tracks".

[Grimsdyke]

I tried to merge a few files lately using the wonderful chapter feature in MKVtoolNix !!
However there were already some warnings given -> merging was done but video got distorted right at the first warning point. Sound was fine.

I tried all things that I could think of but unfortunately the only way I found was merging in FFmpeg -> conversion to m4V -> adding chapters then with Drax.
So I was wondering. Is there the possibility to "out source" merging towards ffmpeg in MKVtoolNix in such situations ?

[Emulgator]

You would just have to do the outsourcing yourself (i.e. reencode) and I would suggest this in any such case.
A muxer can only mux, maybe check for compliancy and reject things that can not be merged.
Any task beyond that will be job of the person tasking the various softwares, me too ;-)

[oniiz86]

I have an audio delay discrepancy when splitting the file with "By parts based on timestamps", the file's "Delay relative to video" is 2s 2ms (2002ms) & was wondering if it is normal behaviour for the delay variance depending on where a split is made?

The file in its entirety below,

Audio
ID : 2
Format : DTS ES XCh XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 1 h 44 min
Bit rate mode : Variable
Bit rate : 4 738 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs LFE Cb
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 2 s 2 ms
Stream size : 3.44 GiB (25%)
Title : DTS-HD MA 6.1
Language : English
Default : Yes
Forced : No

A 3min sample has a 7ms delay

Audio
ID : 2
Format : DTS ES XCh XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 3 min 0 s
Bit rate mode : Variable
Bit rate : 5 599 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs LFE Cb
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 7 ms
Stream size : 120 MiB (24%)
Title : DTS-HD MA 6.1
Language : English
Default : Yes
Forced : No

A 4min 55s sample has a 1ms delay

Audio
ID : 2
Format : DTS ES XCh XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 4 min 55 s
Bit rate mode : Variable
Bit rate : 4 846 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs LFE Cb
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 1 ms
Stream size : 171 MiB (24%)
Title : DTS-HD MA 6.1
Language : English
Default : Yes
Forced : No

[tormento]

I have an audio delay discrepancy when splitting the file with "By parts based on timestamps", the file's "Delay relative to video" is 2s 2ms (2002ms) & was wondering if it is normal behaviour for the delay variance depending on where a split is made?

Does the track have video too? If positive, AFAIK you can split video only at I-Frames.

[oniiz86]

Does the track have video too? If positive, AFAIK you can split video only at I-Frames.

Sorry, yes it does, the film is X-Men: The Last Stand, is a delay of 2s 2ms (2002ms) fairly significant, I can't detect any audible delay, I was just curious why it varied so much depending on where the timestamps are split when making a short sample, here is the video stream below,

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 44 min
Bit rate : 13.7 Mb/s
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.373
Stream size : 10.00 GiB (74%)
Writing library : x264 core 155 r2901 7d0ff22
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=48 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=25 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Audio
ID : 2
Format : DTS ES XCh XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 1 h 44 min
Bit rate mode : Variable
Bit rate : 4 738 kb/s
Channel(s) : 7 channels
Channel layout : C L R Ls Rs LFE Cb
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 2 s 2 ms
Stream size : 3.44 GiB (25%)
Title : DTS-HD MA 6.1
Language : English
Default : Yes
Forced : No

[Mosu]

I have an audio delay discrepancy when splitting the file with "By parts based on timestamps", the file's "Delay relative to video" is 2s 2ms (2002ms) & was wondering if it is normal behaviour for the delay variance depending on where a split is made?

Yes, this is normal.

The "delay of video relative to audio" is simply the difference of the timestamps of the first video & first audio packets. At the start of the file it's relatively normal to have audio start quite a bit later than the video, in your example more than 2s later.

However, there's absolutely no reason to assume that there's a gap in the audio somewhere in the middle. Therefore when you split the second & all following files will have both audio & video content very near the start of the file, and therefore a much, much smaller difference between the timestamps of the first audio & video packets.

Furthermore, audio & video packets almost always have a different duration. For videos typical values include 40ms (for a 25 FPS video) or 41,708333ms (for a 23.976 FPS video). Typical values for audio on the other hand include 21,333ms for AAC @ 48.000 Hz and similar values.

Let's assume your video is 25 FPS with the aforementioned AAC @ 48.000 Hz audio track, and you have a key frame at the 30th frame, which means at 30 * 40ms = 1200ms. For audio the closest packet that plays at 1200ms starts at 21.333ms * floor(1200ms / 21.333ms) = 21.333ms * 56 = 1194.648ms. However, mkvmerge only includes packets in the new file that start at or after the splitpoint, meaning that audio frame will not be written into the new file. Instead, the next one will be, which starts at 21.333ms * ceiling(1200ms / 21.333ms) = 21.333ms * 57 = 1215,981. The difference between the timestamps of this first audio frame & the video frame where we split is obviously 15.981ms, and that's the value you'll see for this particular split as the delay between audio & video.

You can then make similar calculations for a different split point. Let's assume you have one at 76 frames = 76 * 40ms = 3040ms. The first audio frame that'll end up in the new file is located at 21.333ms * ceiling(3040ms / 21.333ms) = 21.333ms * 143 = 3050.619ms. The difference for this case is 10.6619ms, which is different than the previous example.

[tormento]

I have a strange issue.

I have created a mkv from DVD with MakeMKV (but I don't think that is the cause).

If I try to split by chapters AND I keep only the video — removing audio, subs and chapters entries from Tracks, chapters and tags — MKVToolNix GUI doesn't split the mkv and gives me the full lenght file.

Is it a bug or by design?

[Mosu]

If you opt not to copy chapters from the source, then it cannot split by chapters. The reason is that the split decisions are made way later than the decision whether or not to read chapters from a file.

[tormento]

If you opt not to copy chapters from the source, then it cannot split by chapters. The reason is that the split decisions are made way later than the decision whether or not to read chapters from a file.


I understand. [emoji4]

That’s a pity as if I want to cut a video but to have no chapters in it, I’d have to remix twice. [emoji20]

[hello_hello]

I've noticed that MKVToolNix sometimes applies a delay to the video stream when splitting MKVs. That is, after splitting, a split section might have a video delay, sometimes of a few seconds. Fortunately this doesn't seem to alter the A/V sync. If the first split section begins at the start of the source MKV, it never has an additional delay applied to the video. Only sections from the first split point sometimes have a video delay.

I often use MKVToolNix to split MKVs after I've encoded a video. I do this by also encoding the sections I want to remove (separately), appending them to the sections I'm keeping, then split on the appropriate frames while remuxing. Doing so ensures the video has a keyframe at the split points, and of course it splits any audio and subtitle streams to match so they don't need to be split separately. Once again though, the split MKV sometimes has a substantial video delay, although the A/V sync is okay.

There's a link to a 6kB zip file below containing two small sample MKVs. Neither MKV contains a stream other than (blank) video and neither has a video delay. The first MKV contains 140 frames of AVC video.
If I open "Test A.mkv" from the zip file and append "Test B.mkv", then remux while telling MKVToolnixGUI to split the output after frame 140, logically the output MKVs should be the same as the input MKVs, but in this case the second output MKV has a video delay of 600ms, and I'm just trying to understand why.

Test.zip (https://files.videohelp.com/u/210984/Test.zip)

Cheers.

[Perenista]

Is there a way to actually add a new subtitle to a MKV, but that new track have the "default" disabled by default?

If I am not mistaken, if we enable this option, it also disables the "default" for the others which are already DEFAULTED.

Example: my file has:

1) A video track = DEFAULT track option enabled (english)
2) An audio track = DEFAULT track option enabled (english)
3) A subtitle track = DEFAULT track option enabled (english)

If I add a 4th track:

4) A subtitle track = in another language, like ITALIAN;

I don't want the 4th to have the "DEFAULT" flag enabled; instead, I want it DISABLED.

A 4th or any other additional tracks. All new stuff with this flag turned OFF.

I often use MKVToolNix to split MKVs after I've encoded a video.I stopped splitting any file with MKVToolnix a long time ago, because that always broke the resulting MKV. It had A/V sync issues, and I was unable to revert the damage. Only a few were not affected, it was totally random. I used to do this because I had more than 1 Google Drive acc, with 15 GB each, and some MKVs were big.

I should never have tried this, since it introduces problems I never saw again, once I stopped with this practice. Now I always let the file with its original size, and if needed, use WinRAR to split the thing. Trust me, if you never noticed, it was pure luck, this is always bound to happen, and it doesn't matter if you try to append the splitted parts later. This is similar to destroying a vase, trying to glue the broken pieces, then arguing nothing changed.

[Mosu]

Heyo!

Here's MKVToolNix v81, the latest & greatest etc. etc. A lot of work went into improving & finishing the support for Dolby Vision. Apart from that there are several usability improvements & bug fixes, as usual.

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

Please note that I don't have macOS binaries yet, and due to issues with my build machine I cannot give an ETA for them either.

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

Version 81.0 "Milliontown" 2023-12-02
New features and enhancements

mkvmerge: MPEG transport stream reader: HEVC/H.265: added support for reading single-layer Dolby Vision from Annex B type bitstream read from MPEG transport streams. Partially implements #3113 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3113).
mkvmerge: MPEG transport stream reader, HEVC/H.265 elementary stream reader: added support for reading dual-layer Dolby Vision with both the base & enhancement layers in the same track from Annex B type bitstreams in MPEG transport files & elementary stream files. Implements #3126 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3126).
mkvmerge: MPEG transport stream reader: HEVC/H.265: implemented combining dual-layer Dolby Vision with base & enhancement layers in different tracks. Implements #3127 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3127).
MKVToolNix GUI: multiplexer: added a new option in the preferences for always enabling 'forced' subtitle tracks. A subtitle track is considered to be 'forced' if: the corresponding property is set in the source file; the track's name contains the word 'forced' (in English); deriving the 'forced display' flag from file names is active & the file name matches the corresponding pattern. The option is disabled by default. Implements #3627 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3627).
MKVToolNix GUI: multiplexer: the functionality for detecting file name sequences when adding files can now recognize the patterns used by GoPro's cameras for chaptered video files. Implements #3633 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3633).
xyzvc_dump: the end position of the current NALU will be output in non-portable format as well.
xyzvc_dump: HEVC: the tool will now also output the inner NALU type of Dolby Vision NALUs ("unspec62" and "unspec63").

Bug fixes

mkvmerge: when the user requests processing be stopped after the video ends "mkvmerge" will now take appending files into account properly. It won't stop processing unconditionally after the first file ends anymore. Fixes #3618 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3618).
mkvmerge: AV1 handling in readers: the readers will now provide the pixel dimensions to the AV1 packetizer as early as possible, just like for other video packetizers. That way the pixel dimensions are available for calculating the display dimensions when command-line options such as "--aspect-ratio" & "--aspect-ratio-factor" are used. Before the change the calculation was done based on initial pixel dimension values of 0x0, resulting in display dimensions of 0x0, too. Fixes #3611 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3611).
mkvmerge: HEVC/H.265 packetizer: when reading & appending HEVC/H.265 from Matroska, MP4/MOV or FLV files the first frame of all the appended files was sometimes dropped, resulting in broken video at the point where video is appended. Fixes #3479 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3479).
mkvmerge: MPEG transport stream reader: when reading MPEG transport streams from Blu-rays the four-byte long "TP_extra_header" structure in front of the transport packets are now skipped properly. Before the fix a stray byte with value of "0x47" inside that "TP_extra_header" structure could have thrown off the detection of where the transport packets start, leading to mkvmerge dropping a few audio and/or video frames at the start of the file. Fixes #3632 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3632).
mkvextract: AAC extractor: when an invalid program config element in the GA-specific config element is encountered, the program config element will be disregarded, which avoids mkvextract aborting with an exception. Fixes #3606 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3606).
xyzvc_dump: fixed the tool aborting with an exception when the last NALU in an Annex B type file was shorter than four bytes.

Other changes

AVC & HEVC dumper development tool: the tool has been renamed from "xvc_dump" to "xyzvc_dump" as "xvc" is an abbreviation for an existing video codec (Extreme Video Coding), and the tool has nothing to do with that codec.


Have fun! 😁

[Emulgator]

Nice, many thanks !

[markfilipak]

Hi All. I'm running Win7-64bit. What's the 'last' Win7 release of mkvtoolnix?

I know where the vintage packages are but I can't find any release info, so I don't know which to download. I've been running v.61 but I've encountered an mkvextract bug in v.61 when there's 'extra' dots in the file name (e.g., c:\my..video.mkv). The bug makes scripting too difficult. Thanks -- Mark.

[manolito]

Win7 compatible builds are here:

https://forum.doom9.org/showthread.php?t=184092

At the very end of this thread you can find the current versions which are built to work under Win7.


Cheers
manolito

[Snowknight26]

Did m2ts parsing break in v81?

Tried to remux several Blu-rays and each time v81 silently aborts when the output file has been opened for writing.

v81:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\test.mkv^" --no-audio --no-subtitles --no-chapters --language 0:und ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\PLAYLIST\00001.mpls^" ^"^)^"
mkvmerge v81.0 ('Milliontown') 64-bit
Scanning 2 files in 1 playlist.
Done scanning playlists.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'Z:\temp\test.mkv' has been opened for writing.


v80 (stopped with Ctrl+C):

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\test.mkv^" --no-audio --no-subtitles --no-chapters --language 0:und ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\PLAYLIST\00001.mpls^" ^"^)^"
mkvmerge v80.0 ('Roundabout') 64-bit
Scanning 2 files in 1 playlist.
Done scanning playlists.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'Z:\temp\test.mkv' has been opened for writing.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Extracted the aspect ratio information from the video bitstream and set the display dimensions to 1920/1080.
^Cogress: 3%

[Mosu]

Oh? It shouldn't have, and none of my test cases have failed. That being said, the changes for Dolby Vision did modify the transport stream code quite a bit. It's quite possible something broke that shouldn't have.

Can you provide some more information? I just gave it a try; remuxing the "Solo — A Star Wars Story" Blu-ray via the GUI worked just fine (playlist 00800.mpls).

[Snowknight26]

Ah ok, now I'm getting somewhere. It looks like v81 fails to write anything to the output file if the input is either a Blu-ray playlist or m2ts (and possibly others, but haven't tested) that contains a PCM track and you specifically don't include the PCM track in the output.

v81, M2TS with 2 streams, H.264 and PCM, with PCM unchecked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --no-audio --language 0:und ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts^" ^"^)^"
mkvmerge v81.0 ('Milliontown') 64-bit
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'Z:\temp\temp.mkv' has been opened for writing.


v81, M2TS with 2 streams, H.264 and PCM, with PCM checked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --language 0:und --language 1:ja ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts^" ^"^)^" --track-order 0:0,0:1
mkvmerge v81.0 ('Milliontown') 64-bit
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 1: Using the output module for the format 'PCM'.
The file 'Z:\temp\temp.mkv' has been opened for writing.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00012.m2ts' track 0: Extracted the aspect ratio information from the video bitstream and set the display dimensions to 1920/1080.
^Cogress: 4%

v81, different M2TS with 2 streams, H.264 and PCM, with PCM unchecked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --no-audio --language 0:und ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts^" ^"^)^"
mkvmerge v81.0 ('Milliontown') 64-bit
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'Z:\temp\temp.mkv' has been opened for writing.


v81, different M2TS with 2 streams, H.264 and PCM, with PCM checked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --language 0:und --language 1:ja ^"^(^" ^"Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts^" ^"^)^" --track-order 0:0,0:1
mkvmerge v81.0 ('Milliontown') 64-bit
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 1: Using the output module for the format 'PCM'.
The file 'Z:\temp\temp.mkv' has been opened for writing.
'Z:\temp\ES_FF_XIV_ORCHESTRAL_ALBUM_3\BDMV\STREAM\00010.m2ts' track 0: Extracted the aspect ratio information from the video bitstream and set the display dimensions to 1920/1080.
^Cogress: 4%


v81, playlist with multiple streams (H.264, PCM, DTS-HD MA, chapters), with PCM unchecked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --audio-tracks 2,3,4 --language 0:und --language 2:ja --language 3:ja --language 4:ja ^"^(^" ^"Z:\temp\FFXIV_FATU\BDMV\PLAYLIST\00003.mpls^" ^"^)^" --chapter-language und --generate-chapters-name-template ^"Chapter ^<NUM:2^>^" --track-order 0:0,0:2,0:3,0:4
mkvmerge v81.0 ('Milliontown') 64-bit
Scanning 8 files in 1 playlist.
Done scanning playlists.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 4: Using the output module for the format 'DTS'.
The file 'Z:\temp\temp.mkv' has been opened for writing.


v81, playlist with multiple streams (H.264, PCM, DTS-HD MA, chapters), with PCM checked:

C:\Users\Admin>"C:\Program Files\MKVToolNix\mkvmerge.exe" --ui-language en --priority lower --output ^"Z:\temp\temp.mkv^" --language 0:und --language 1:ja --language 2:ja --language 3:ja --language 4:ja ^"^(^" ^"Z:\temp\FFXIV_FATU\BDMV\PLAYLIST\00003.mpls^" ^"^)^" --chapter-language und --generate-chapters-name-template ^"Chapter ^<NUM:2^>^" --track-order 0:0,0:1,0:2,0:3,0:4
mkvmerge v81.0 ('Milliontown') 64-bit
Scanning 8 files in 1 playlist.
Done scanning playlists.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts': Using the demultiplexer for the format 'MPEG transport stream'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00016.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00018.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00020.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00022.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00024.m2ts' track 4: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 1: Using the output module for the format 'PCM'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 2: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 3: Using the output module for the format 'DTS'.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00027.m2ts' track 4: Using the output module for the format 'DTS'.
The file 'Z:\temp\temp.mkv' has been opened for writing.
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts' track 0: Extracted the aspect ratio information from the video bitstream and set the display dimensions to 1920/1080.
Appending track 0 from file no. 1 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts') to track 0 from file no. 0 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts').
'Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts' track 0: Extracted the aspect ratio information from the video bitstream and set the display dimensions to 1920/1080.
Appending track 2 from file no. 1 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts') to track 2 from file no. 0 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts').
Appending track 3 from file no. 1 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts') to track 3 from file no. 0 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts').
Appending track 4 from file no. 1 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts') to track 4 from file no. 0 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts').
Appending track 1 from file no. 1 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00014.m2ts') to track 1 from file no. 0 ('Z:\temp\FFXIV_FATU\BDMV\STREAM\00039.m2ts').
^Cogress: 7%

[hello_hello]

I stopped splitting any file with MKVToolnix a long time ago, because that always broke the resulting MKV. It had A/V sync issues, and I was unable to revert the damage. Only a few were not affected, it was totally random. I used to do this because I had more than 1 Google Drive acc, with 15 GB each, and some MKVs were big.

Well I can't say I've ever had problems splitting files, and I've done it hundreds of times over the years. The only "issue" has been MKVToolNix applying a video delay to a split section. The delay can be removed by applying an appropriate negative delay to each stream, making the video delay zero. I've never experienced A/V sync problems as a result, but I was curious as to why there's a video delay in the first place, especially in the case of the samples I uploaded, where the video is the only stream....

[markfilipak]

Win7 compatible builds are here:

https://forum.doom9.org/showthread.php?t=184092

At the very end of this thread you can find the current versions which are built to work under Win7.
Thank you, Manolito. I was able to upgrade to v.81. The mkvextract bug is still there.

Script:
set NAME=STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris
set M2TS=h:\BDMV\STREAM\00004.m2ts
set TARGETPATH=g:\Movies I'm working on\STAR TREK, TNG
ffmpeg -i "%M2TS%" -map 0:s:0 -s 1920x1080 -c:s dvdsub -f matroska "%TARGETPATH%\%NAME%.mkv"
"C:\Program Files\MKVToolNix\mkvextract" "%TARGETPATH%\%NAME%.mkv" tracks 0:"%TARGETPATH%\%NAME%"

Result:
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..idx
Should be:
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris.idx

Result:
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..sub
Should be:
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris.sub

--Mark.

[Mosu]

Ah ok, now I'm getting somewhere. It looks like v81 fails to write anything to the output file if the input is either a Blu-ray playlist or m2ts (and possibly others, but haven't tested) that contains a PCM track and you specifically don't include the PCM track in the output.

Interesting. Please open an issue over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/) for it. Thanks.

[Mosu]

Thank you, Manolito. I was able to upgrade to v.81. The mkvextract bug is still there.

This is not a bug. You're effectively calling mkvextract with like this (replacing the variables with copy-pasted content):

"C:\Program Files\MKVToolNix\mkvextract" "g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris.mkv" tracks 0:"g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris"

Note that there's neither ".idx" nor ".sub" at the end. However, mkvextract has to create those two files. It assumes that the user always specifies a file extension for the output file name. It then replaces the extension with .idx for the first file & with .sub for the second file.

The extension is simply the part starting with the last . in the name. Therefore the result is pretty self-explanatory.

If it didn't replace the extension but only appended .idx & .sub, most users would simply end up with "filename.idx.idx" and "filename.idx.sub", which would be assinine.

No, mkvextract cannot read your mind. Therefore it makes the sensible assumption that the user always specifies a file extension.

Just add ".idx" to the end; it should work fine, e.g.

"C:\Program Files\MKVToolNix\mkvextract" "%TARGETPATH%\%NAME%.mkv" tracks 0:"%TARGETPATH%\%NAME%.idx"

[j7n]

Can you say which input formats currently have automatic audio delay compensation implemented? I want to avoid compensating twice.

[Mosu]

For each source file mkvmerge will normalize the timestamps so that the lowest timestamp of that file starts at 0. The relative timestamps will remain intact (e.g. if audio starts at 120ms, video starts at 40ms, then mkvmerge will subtract 40ms from all timestamps from that one file so that audio starts at 80ms, video at 0ms). Meaning that if you take a file containing more than one track & mux it the audio, video & subtitles from that one file should always stay in sync.

There's nothing in mkvmerge to synchronize audio & video from different files apart from the aforementioned normalization to starting at 0ms for each individual file.

On top of that mechanism the GUI can scan file names & recognize a delay mentioned in the file name & apply it via mkvmerge's "--sync" option. mkvmerge itself doesn't have something similar (for good reason).

In other words: manually specifying --sync… should ideally only be needed if you combine tracks from different source files as there's no way for mkvmerge to automagically sync them up.

[markfilipak]

This is not a bug.
Yes, I see that now. But it is illogical.
Note that there's neither ".idx" nor ".sub" at the end. However, mkvextract has to create those two files.
That's why it's illogical.

The template I used was from another site. It appeared from it that only the /path/name was supplied -- no extension (file type). That made sense because mkvextract makes 2 files: IDX & SUB, and calling it with only one extension is illogical.

Your explanation works, thank you, but it doesn't explain why
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987..1994] 1- 23 We'll Always Have Paris
became
g:\Movies I'm working on\STAR TREK, TNG\STAR TREK, TNG [1987.
The extension is simply the part starting with the last . in the name. Therefore the result is pretty self-explanatory.
But why would mkvextract remove the 'extension'. That's illogical. I have plenty of files with names like 'mkvextract.exe.txt'.
If it didn't replace the extension but only appended .idx & .sub, most users would simply end up with "filename.idx.idx" and "filename.idx.sub", which would be assinine.
I disagree. It would be logical and it would be immediately apparent to everyone what happened, and they would supply just /path/name. In my case, I was running a script and when the 'extensions' were removed, there was a collision because the only parts that differed were the 'extensions'. What would be logical is to specify just /path/name like I did.

It's a small deal and I've 'fixed' my code, so don't trouble yourself.
Just add ".idx" to the end; it should work fine, e.g.
Thank you. I am doing that now. But it's still illogical. :-)

[Mosu]

But why would mkvextract remove the 'extension'.

Because most people who use mkvextract do actually specify an extensions such as .idx or .sub when they try to extract VobSub subtitles — as they have to specify extensions for all other file types, too. Therefore mkvextract assumes that people do that and replaces the existing extension for each of the two files.

Don't make the mistake of assuming that what you find logical or illogical is universal. Most people work differently than you do (same goes for anyone, really; most people work differently than I do, for example). I had tried not to replace extensions in the past, which lead to a lot of confused users. The current way of replacing extensions only lead to one complaint (yours) over the last ten years or so. This is my experience, and that's why mkvextract behaves this way.