MKVToolNix v24.0.0 released

[nautilus7]

That was quick. Thank you!

[Perenista]

When I select "determine automatically" in an audio or subtitle track, does that mean I am not forcing the player to select that track by default, and letting the player do the choosing?

I mean, if I select "default track" for english DD 5.1, for example, even if the player is set to prefer the portuguese language and to select by default the Portuguese tracks, will the "default: yes" from the english 5.1 override that setting from the player?

[Mosu]

When I select "determine automatically" in an audio or subtitle track, does that mean I am not forcing the player to select that track by default, and letting the player do the choosing?

It solely means that mkvmerge will determine the corresponding flag on its own. See the "default track in output" column for what it'll be set to.

I mean, if I select "default track" for english DD 5.1, for example, even if the player is set to prefer the portuguese language and to select by default the Portuguese tracks, will the "default: yes" from the english 5.1 override that setting from the player?

The intent of the "default track" flag is to mark a track to play be default unless the user has instructed its player otherwise. That's a big vague, true, but it's vague on purpose. Selecting a language to prefer in the player seems to me a case of the user making such a choice; therefore such a choice should probably override the container's "default track" flag.

[Mosu]

A new release of MKVToolNix with several bug fixes in mkvmerge and minor feature enhancements in the GUI. Nothing critical.

Nothing's been changed regarding the packaging since v9.4.2.

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

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's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since v9.4.2:

2016-10-16 Moritz Bunkus <moritz@bunkus.org>
* Released v9.5.0 "Quiet Fire".
* mkvmerge, mkvextract: VobSub handling bug fix: mkvmerge and mkvextract will now update the duration stored in the SPU bitsream with the duration from the container level if it differs at least 1ms. Fixes #1771 (https://github.com/mbunkus/mkvtoolnix/issues/1771).

2016-10-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: h.264 elementary stream handling bug fix: if mkvmerge ever encounters changing SPS or PPS NALUs (ones where their ID has been encountered before with different settings) in the h.264 then it will prepend all following key frames with all currently active SPS and PPS NALUs. This enables playback from arbitrary key frames even if they require other SPS or PPS settings than the ones stored in the AVCC in CodecPrivate. Fixes #1711 (https://github.com/mbunkus/mkvtoolnix/issues/1711).

2016-10-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvpropedit, MKVToolNix GUI: added support for the "field order" video track header element.
* mkvinfo: added support for the "field order" video track header element. Patch by James Almer (see AUTHORS).
* mkvmerge: MPEG transport stream reader bug fix: fixed the handling of Blu-ray PCM audio with an odd number of channels by removing their alignment bytes.

2016-10-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPEG transport stream reader bug fix: fixed mis-detection of certain h.264 files as MPEG transport streams.

2016-10-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: WAV reader bug fix: the track properties (channels, sample rate) for DTS and AC-3 in WAV will now be derived from the decoded bitstream headers instead of the WAV file header as the latter is often incorrect.
* mkvmerge: WAV reader bug fix: fixed detection and merging of DTS in WAV that uses the 14-bytes-in-16-bytes packing method.

2016-10-08 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: added menu entries that execute the "close", "save settings", "start muxing" or "add to job queue" action for all currently open tabs.

2016-10-07 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: when dragging & dropping directories the GUI will process all files within those directories recursively instead.

2016-10-06 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, MKVToolNix GUI's header editor: added options to modify the "muxing application" and "writing application" elements in the "segment information" container. Implements #1788 (https://github.com/mbunkus/mkvtoolnix/issues/1788).

2016-09-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The Ogg/OGM reader did not recognize Opus files with comment headers anymore. This was broken by the fix to not require Ogg/OGM files to have comment headers in v9.4.0.

Have fun :)

[Mosu]

Like I've stated in issue #1711 (https://github.com/mbunkus/mkvtoolnix/issues/1711) I've tried the samples I had with both VLC and MPC-HC. Prior to the change I was able to observe the problems when seeking to key frames in both players; after the change I haven't been able to reproduce the problems.

If you have a file for which remuxing with v9.5.0 does not produce a proper result I'd like to take a look at it. Note that mkvmerge only dose this kind of processing if it uses the elementary stream packetizer (e.g. when reading h.264 from .h264 files or from MPEG program & transport streams), but not if the h.264 is already packetized (e.g. when reading it from Matroska or MP4 files).

[sneaker_ger]

Sorry, I had already deleted my post. I think I may have misunderstood the purpose of the change and will need to re-read the discussion on the issue tracker. I somehow believed this could also be used for appending differing H.264 streams while keeping playback intact.

[nautilus7]

Hi, I am trying to mux a blu-ray (mpls file) into mkv. The disc is Ran (1985) Remastered Japanese version. It contains 2 seamless branching playlists. First consists of two m2ts files. No problem here. The 2nd is the problematic one. It contains 4 m2ts files, but the 2 of them are not played from start to end, but from a intermediate point. Sequence is like this:

start_of_1st.m2ts --> end_of_1st.m2ts --> middle_of_2nd.m2ts --> end_of_2nd.m2ts -->
start_of_3rd.m2ts --> middle_of_3rd.m2ts --> start_of_4th.m2ts --> end_of_4th.m2ts

Trying to remux this playlist into mkv didn't result in a correct file (3rd and 4th files weren't included at all). I can provide samples, but only the mpls structure, because the m2ts files are huge...

Speaking of seamless branching, how does mkvmerge handle overlapping video or audio frames at the transition points between m2ts files? I know eac3to removes identical frames or frames with the same time stamps.

[Mosu]

Trying to remux this playlist into mkv didn't result in a correct file (3rd and 4th files weren't included at all).

Have you actually _appended_ the second MPLS file? And not _added_ it?

Speaking of seamless branching, how does mkvmerge handle overlapping video or audio frames at the transition points between m2ts files? I know eac3to removes identical frames or frames with the same time stamps.

It doesn't have any special handling for something like that. If there are identical frames then they'll both be included.

[nautilus7]

Sorry, I wan't clear. The 2 playlists are independent. I shouldn't have mention about the first one. It's a playlist, that has 4 m2ts files, that causes the problem. There is not other playlist to append.

[Mosu]

I see. Well, you can upload the MPLS structure if you want, but I doubt I'll be able to do much about it without the accompanying M2TS files…

[hubblec4]

Hi nautilus7

If its not a problem for you, I would like to have this Bluray-structure too.
Like Mosu said, without the M2TS files is not good.

You could try my chapterEditor, Multi Editions Editor: its designed to mux seamless branching Bluray's.

[nautilus7]

@mosu, your ftp server is not working. I am connecting, but I cannot upload any file.

@hubblec4, your program as far as I can see is based on eac3to. eac3to cannot (de-)mux this playlist correctly either.

[Mosu]

@mosu, your ftp server is not working. I am connecting, but I cannot upload any file.

Thanks for the heads-up. Should be fixed now.

[hubblec4]

@hubblec4, your program as far as I can see is based on eac3to. eac3to cannot (de-)mux this playlist correctly either.

Very interessting.
My program is not fully depend on eac3to. Only if you want reencode audio streams or demuxing subtitles. OK there are a function to demux a playlist but you must not use it.

MTX-GUI is the program that generate the mkv directly from the Bluray.
I feed MTX-GUI with the necessary m2ts files (not with the mpls) and then generate my program an ordered chapter.xml which makes all to play.


@Mosu:
It is possible to share the uploaded Bluray content with me?

[Mosu]

@hubblec4: sure, I'll drop you a PM once it's been uploaded.

[nautilus7]

I just uploaded the blu-ray structure, except "stream" folder to Mosu's ftp. Here's a link (https://www.sendspace.com/file/fbd3sr) for others interested.

Mkvmerge muxes 1st and 2nd m2ts files, but stalls (no message, just keeps running and running without increasing output filesize) at the start of the 3rd m2ts.
Hope you can figure out what's wrong...

[hubblec4]

I have downloaded the Ran1985.zip and without the m2ts files is it not possible to check the issue.
Maybe has Mosu better analysis tools which work without the m2ts files.

I see in the 00001.mpls a 5th m2ts file which is used (00017.m2ts).
Can you think about to upload the whole Bluray to Mosu's ftp?

ChapterEditor reads the 00001.mpls (and it seems it's all ok), but I can't test the muxing process.

[Mosu]

Hey,

Mkvmerge muxes 1st and 2nd m2ts files, but stalls (no message, just keeps running and running without increasing output filesize) at the start of the 3rd m2ts.

Without having looked at the file yet. mkvmerge cannot jump directly to the middle of the M2TS file where the MPLS file stated it should start playing from. It simply reads the whole file from start to finish but only processes the frames that fall into the time frame specified by the MPLS file (actually it won't read until the end but only until the end timestamp given by the MPLS file has been reached).

Therefore I suggest you leave it running a lot longer. Maybe it's only doing its job and it simply takes quite a while.

Which of the MPLS files is the one giving you the trouble?

[nautilus7]

Problematic playlist is 00001.mpls.

Mosu, I let mkvmerge run for about 1 hour, without any success.

[Ripman]

I've fixed the problem which only affected PCM tracks with an odd number of channels (https://github.com/mbunkus/mkvtoolnix/commit/2cac968f958e5c1b3c6fe9a4e84ecc7ddc036d0b). New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are available.

Hi Mosu. Thanks for this fix.

I could not reproduce this problem in mkv's having an odd number of channels in selected lpcm audio tracks. (Mkv's created with makemkv and muxed with Mmg.) Does the problem only occur for m2ts sources, or if the lpcm audio is default?

As examples, this AM I opened the following CR titles with mono lpcm audio tracks selected, and had no "half-speed" issue: Lola, red river, my darling clementine, L'eclisse, L'aventurra, identification of a woman. (These mkv files were muxed with Mmg v7x.) Thanks.

[Mosu]

LPCM as packaged in M2TS has this problem. Most likely the source of the PCM data were either other container types or the muxer(s) in question already took care of it.

[nautilus7]

I am trying to append some Η264 files (cut from 2 Blu-ray's - theatrical and extended cut of the same movie - on IDR frames using mkvmerge). I get a warning about video parts having different private data lengths:

The codec's private data does not match (lengths: 114 and 114). Please make sure that the resulting file plays correctly the whole time.

But why 114 is different than 114? :( I checked playback and it seems ok though.

Also I noticed a bug (?): I insert a few files for appending. I drag and drop them to change the order and then mux. The resulting file has the initial order (the one the files were loaded into mkvmerge) and not the rearranged one.

[nevcairiel]

The codec's private data does not match (lengths: 114 and 114). Please make sure that the resulting file plays correctly the whole time.

But why 114 is different than 114? :( I checked playback and it seems ok though.


Same length does not imply the same content. When you remux from Blu-ray its usually going to be fine with the majority of players, as the Blu-ray streams contain the required private data in the stream again, but there could be players which don't like that - or when you mux other stream sources, which don't contain it inside the stream, it could break entirely.

[Mosu]

Also I noticed a bug (?): I insert a few files for appending. I drag and drop them to change the order and then mux. The resulting file has the initial order (the one the files were loaded into mkvmerge) and not the rearranged one.

This is not a bug. You change the order of the tracks by dragging & dropping tracks, not by dragging & dropping files.

[nautilus7]

Same length does not imply the same content. When you remux from Blu-ray its usually going to be fine with the majority of players, as the Blu-ray streams contain the required private data in the stream again, but there could be players which don't like that - or when you mux other stream sources, which don't contain it inside the stream, it could break entirely.

Thanks. What do these private data contain?

This is not a bug. You change the order of the tracks by dragging & dropping tracks, not by dragging & dropping files.

Yes, of course.... My bad. :o

[Ripman]

Mkvmerge and Mkvextract can accept options files on the command line via the @ sign.

Can options files be utf-8 encoded?

(I'm thinking about those special angled quotes - 0x93 0x94 - and some of the other accented characters that could be used for filenames, etc.)

[Mosu]

The programs use the same methods for reading option files they use for reading other text files. This means that they will use the system's local character set if the file does not start with a Byte Order Mark (BOM). If it does start with a Byte Order Mark then the encoding signaled by the BOM will be used.

So in order to make sure that UTF-8 is used create option files that start with a UTF-8 BOM.

That's what the GUI does, too, BTW.

[Perenista]

I have been doing some tests here with the app Infuse for iOS (I use in the IPP 9.7 and Apple-TV). The app does not support audio files (one major flaw), so I had the idea to create videos and insert the audios in them.

- It does not support MKA (what is created by MKVToolnix if I only add the audio). If I rename the MKA to MKV, it opens in Infuse, but when I fast-forward (for example), the playback stops (even though it plays from start to end).

So I had the idea to use Sony Vegas to create a video with a static image, saving as .MP4, with the same length as the audio track, which is FLAC.

My question is: if I open MKVToolnix and insert both the MP4 (video mentioned above, with only a static image) and add that FLAC, then save it as a Matroska, will this somehow degrade the audio quality (since FLAC is lossless)? MKVToolnix is using the default settings.

I was going to ask the same question about videos, created by MakeMKV, from DVDs/Blu-rays. I remember someone once said that everything we do with this software does not reencode anything, but it was a long time ago and I don't remember who said that.

[Brother John]

will this somehow degrade the audio quality (since FLAC is lossless)?
No, quality will stay exactly the same. MKVToolnix just muxes and demuxes. It never re-encodes any stream. That’s true for audio and video.

[Mosu]

Problematic playlist is 00001.mpls.

This was rather difficult to figure out for several reasons: a single debug run taking roughly 30 minutes for one thing and there being two completely unrelated bugs for another. Anyway.

I've fixed both issues & uploaded new debug builds (https://mkvtoolnix.download/windows/debug/) for you to test.

[nautilus7]

I will test later today. Thanks!

[nautilus7]

It works fine now! Great job! :D

[Mosu]

Thanks for the feedback!

[filler56789]

Guten Tag, Mosu.

There is a problem in mkvtoolnix.download...

My browser says:

The connection was refused when attempting to contact mkvtoolnix.download

:confused:

[Mosu]

Earlier today the server was down for maintenance. It's up now.

[Perenista]

Unfortunately I am having an unusual problem here, and it's the first time ever this is happening. Since I can't provide the actual files here, I urge you to pay attention to all the details.

- These are all the tracks from the Matroska lossless extracted from the Blu-ray:

http://pastebin.com/Bi96zcXP

I did the following:

- Added 2 SRT subtitle tracks;
- Added another audio file, instructing MKVToolnix this: +750ms (delay). This was done because I noticed the dubbing was not synced with the video.

- And I finally splitted the MKV into 3 parts. Each one with 14500 MB. Which resulted in 3 files, the first two with 14.1 and the 3rd 8.47 GB.

This is how the 1st part looks like:

http://pastebin.com/ytP1r1r2

My problem is this: when I add (option: append files, and this issue happens with all 3 combined or just the first two), in exactly the moment where (in the movie) we have a switch between parts (in the now unique file) the scene hangs from 40:46 to 40:50.

Meaning that exactly at 40:46 it freezes, while the audio continues to be played, and advances to at least 40:48.

What do I mean?

It's like this:

1st part ends at 40:46.
2nd part continues from 40:46 onwards.
3rd part has, let's say, the final 10 minutes.

When we append parts 1-2, this is what is happening:

- Unique file with 28.3 GB and 1h20m.

At 40:46, the bug occurs. Because this is the exact moment where the now unique file had the combination.

I'll do another test here, this time removing the dubbing and its +750ms delay. But it can't be that what is causing all this. What is more strange is that I think that the unique file (without any splitting, the one I created before the actual splitting) wasn't plagued by this problem.

So what changed when I did the splitting and rejoined the files? Can you make a guess what happened?

[sneaker_ger]

Is there a subtitle line in any of the two SRT files that extends from <=40:46 to 40:50? Mkvmerge cannot split such subtitles in the middle. It also has problems with splitting open gop H.264 but since keyframe interval should only be max 1 second on your BluRay it shouldn't result in a 4 second problem by itself.

Btw, usually --append-mode track is better suited to re-append previously split continuous files.
https://mkvtoolnix.download/doc/mkvmerge.html#d4e760

[kuchikirukia]

- And I finally splitted the MKV into 3 parts.

Don't do this.
Problem solved.

[VictorLS]

I am novice here and I want to ask some questions:
1. mkvtoolnix is one freeware application to split h265 without encoding now (as i.e. VideoReDo for h264) or I am wrong?
2. Is there possibility to cut h265 file from some time to the end of file without saving first part from beginning to that some time because I have a little free space on HDD?
3. Is possibility to do first frame of result (read my second question) I-frame in mkvtoolnix only? Or I have to know exactly time of I-frame in another application? What freeware can be proposed for that?

[sneaker_ger]

1. You mean "the only one"? No. For example ffmpeg.
2. "split by parts based on[...]" E.g. "00:05:03.200-". This saves everything from 5 minutes, 3 seconds, 200 ms to the end of the file.
3. Mkvmerge will split on the next following keyframe. You can't look this up using mkvmerge (no preview). You need another application to do that.

https://mkvtoolnix.download/doc/mkvmerge.html#d4e760

[Jamaika]

3. Is possibility to do first frame of result (read my second question) I-frame in mkvtoolnix only? Or I have to know exactly time of I-frame in another application? What freeware can be proposed for that?
Now a few words about praised on forums SolveigMM Video Splitter Business Edition and more. These are the scissors to cut the film. Only every are they worth?
Splitter is currently only codec H264.
Speech was that the frame "P" or "B" will have to be converted. Unfortunately, so when we have a long-GOP. How does it work in practice?
When you want to get rid of "extra frames" we must be aware that the area of frames from the cut to the next frame I must be converted to lossy. -? Consequently, and whether it makes sense to cut short films? Not really, it is better to convert again. :idea:
Easy to use, lossless video editor for AVC/H264, MP4, MOV, WEBM, FLV, MKV, MPEG-2, WMV, ASF, AVI frame-accurate trimming and joining.
http://www.solveigmm.com/en/products/video-splitter/
http://www.solveigmm.com/images/stories/PR/scheme--frame-accuracy--frame-accuracy-eng.jpg

[hubblec4]

@ Perenista

Splitting is ever not so easy and simple.
But it could be a problem of the video decoder.
Sometimes I cut from Bluray series the middle part, and mux part 1 and part 3 together with a stuttering result.
But I changed the video decoder from LAV-h264 to Microsoft DTV DVD video decoder and all works fine.

[Perenista]

Don't do this.
Problem solved.For everything we do there's a reason, and this, of course, wouldn't be any different. I don't need to split at all, since all my devices can read the unique file.

It's just that Google Drive offers only 15 GB of actual free disk space. So you have 2 options:

1) Either split into multiple files and then you can watch the whole thing, even if it's splitted;

2) You leave it as a unique file, but put it inside a RAR with 38 GB, also splitted, meaning each RAR will have 15 GB, but you wouldn't be able to watch any of it, obviously.

Currently I watch all my movies with a PC/Hard Drive (or for some, a NAS) online, from my iPAD, so this isn't necessary. But I would like a watchable copy to exist in GD, also serving as a backup whenever I want to download to my HDD.

What is odd about this case is that this only occurs when I append all the splitted files. I can only assume this is happening due to the excessive number of tracks or maybe it is entirely related wiith the delay inserted for the dubbing, since splittling and appending cannot have caused this. Don't you all said that everything MKVToolnix modifies cannot change the MKVs (meaning they will continue to be lossless)?

I'll report later with more conclusions...

[sneaker_ger]

2) You leave it as a unique file, but put it inside a RAR with 38 GB, also splitted, meaning each RAR will have 15 GB, but you wouldn't be able to watch any of it, obviously.
I don't know how your Google Drive mounting works but players like VLC and MPC-HC can read directly from splitted RAR archives. Just make sure to turn off compression (doesn't do much on modern codecs anyways) and encryption.

What is odd about this case is that this only occurs when I append all the splitted files.
Read my remark about subtitle splitting and the doc about the append modes. Then it may make sense to you.

[Perenista]

sneaker_ger, here's what I discovered so far:

1) The problem happens regardless of the dubbing added with its delay. So disregard that remark about adding 750ms. Let's not even mention this track anymore.

2) It can also occur when this option is used:
http://forum.doom9.org/showthread.php?t=63956

By default, it's disabled. The option makes MPC-HC read as if it was a single file, instead of 3 splitted. But in my case, when I append all 3, the problem is still there.

***************
In case you are wondering, this is what I was doing here. Let's call this movie "X1".

The Blu-ray from "X1" has:

- For the movie:

- DTS-HD MA 5.1
- DTS 5.1
- DTS-HD MA 2.0
- DTS 2.0

Audio commentary #1 in

DTS-HD MA 2.0
DTS 2.0

Audio commentary #2 in

DTS-HD MA 2.0
DTS 2.0

Isolated Score in

DTS-HD MA 2.0
DTS 2.0

Plus: English (CC) track for the movie. All these tracks from the BD.

The video:

Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC

OK, so I have an unique file with all these 11 tracks (total), and more than 30 GB (besides "24 entries", which refer to chapters). Created by MakeMKV from the original BD. This MKV (lossless) is perfectly fine.

What did I do next?

- With MKVToolnix and this file open, I added:

- A single subtitle (SRT) file, that covers the entire movie. This file is not splitted. English (normal) subtitles.
- A second SRT (same condition as above), from another language (portuguese).

Next thing I did was: Split mode: after output size: 14500M. Maximum number of files: Unlimited. And the box "Link files" unchecked.

**********
After all 3 files were created, I opened the 1st (now preparing for Google Drive) and selected: append files, pointing to the 2nd file, then append: and selecting the 3rd.

What happened after all that was what I reported here. In the exact moment we switch between parts in the now unique 30+ GB file, a "delay" of at least 2 seconds occurs, with that stuttering.

Is there a subtitle line in any of the two SRT files that extends from <=40:46 to 40:50? Mkvmerge cannot split such subtitles in the middle. It also has problems with splitting open gop H.264 but since keyframe interval should only be max 1 second on your BluRay it shouldn't result in a 4 second problem by itself.This is happening even if I change the splitted size. So if happened at 40:46, it's now occurring at 41 minutes, after I changed the split size from 14500 to 14600 MB.

Meaning this is entirely MKVToolnix's fault. Even if there was a subtitle line that extended from one point to another, even if it extended from 40:46 to 1h, what difference does that make, since you are instructing the program to split anything, anyway?

I'll do another test, this time including not 13, but 2 tracks. And leaving the rest outside the file. Considering that this issue never affected any movie I tried before, I believe it's due to the excessive number of tracks.

[hubblec4]

....
Next thing I did was: Split mode: after output size: 14500M. Maximum number of files: Unlimited. And the box "Link files" unchecked.
....

What happens if you use the box "Link files" checked?
After muxing start the first part and all other parts should append automaticly by the player (MPC-HC).

[sneaker_ger]

This is happening even if I change the splitted size. So if happened at 40:46, it's now occurring at 41 minutes, after I changed the split size from 14500 to 14600 MB.
Is there or is there not a subtitle line at intended split point (or next keyframe)?

And: did you test other --append-mode like I suggested or did you not?

What happens if you use the box "Link files" checked?
Shouldn't make any difference. This is only for the uid linking tags.

[Perenista]

OK, I tested now with only the DTS-HD MA 5.1 track and the BD subtitle. The issue is not happening again.

As for the SRT, this is what I see inside it (the english one):

00:40:40,274 --> 00:40:41,474 - Dialogue
00:40:44,445 --> 00:40:46,765 - Dialogue
00:40:48,325 --> 00:40:49,725 - Dialogue
00:40:51,452 --> 00:40:54,332 - Dialogue

And the 2nd SRT (in portuguese):

00:40:41,748 --> 00:40:44,615 - Dialogue
00:40:45,652 --> 00:40:47,677 - Dialogue
00:40:48,622 --> 00:40:52,524 - Dialogue

My point is that I never had to worry about any of this. I just did all the procedure described here and uploaded to GB. So what you are saying is that the subtitle itself caused the stuttering? I had to add it because in GD I can make use of a splitted SRT (and it has to be SRT), too, and I used MKVToolnix to do this job of splitting into 3 parts, then MKVExtractGUI2 to collect the SRTs from all 3 files, to be embedded in each part in GD.

Can I assume this stuttering won't even occur if the SRT isn't there, even after I split and try to append the files? If that's the case then it's OK.

This (according to you) is what happened:

1) - Unique file.
1.1) - Added SRTs mentioned above.

2) - Divided into 3 parts with those two SRTs.
3) - Appending all 3 parts into an unique file like 1) = stuttering caused by the SRT.

The solution being creating an unique file again, and only after that adding both SRTs.

[sneaker_ger]

One potential solution. Other potential solutions:
1.) choose split point not in the middle of a subtitle
2.) use different --append-mode

But I'm not 100% sure it's the cause. You can extract the SRTs after the split and see exactly how mkvmerge split them. And you can see how long the video and audio tracks are (mkvinfo). Then compare the lengths.

[Perenista]

One potential solution. Other potential solutions:
1.) choose split point not in the middle of a subtitle
2.) use different --append-mode

But I'm not 100% sure it's the cause. You can extract the SRTs after the split and see exactly how mkvmerge split them. And you can see how long the video and audio tracks are (mkvinfo). Then compare the lengths.Now I am 101% sure (after my last test): the SRT subtitles caused the issue! You were right. :rolleyes:

I splitted and rejoined the 3 parts, except that now I left them out. And I even included the dubbing with the 750ms delay.

It had nothing to do with the number of tracks. And I used the append option to create the unique file.