MKVToolNix v99.0 released

[j7n]

I read some time ago (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/715) that in MP4 files the tag ITunSMPB was taken into account and converted into a delay in addition to one specified by --sync. What I want to know is which (if any) other elementary stream formats have received similar treatment since that issue was resolved. I'm not asking for any changes, just to clarify the current situation.

[-QfG-]

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.


https://i.imgur.com/fuELiVkl.png

Simply set this switch. I hope in future of the same options for audio, too.

[Mosu]

I read some time ago (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/715) that in MP4 files the tag ITunSMPB was taken into account and converted into a delay in addition to one specified by --sync. What I want to know is which (if any) other elementary stream formats have received similar treatment since that issue was resolved. I'm not asking for any changes, just to clarify the current situation.

There are no other formats that I know of that have similar information on top of the already existing timestamps in the file format.

[hello_hello]

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.

Mosu, any chance of an answer to this one? I'm curious....

Cheers.

[Mosu]

I've written in depth about how mkvmerge's splitting & appending works and am not in the mood to write all that up once again. Sorry. Just be aware that splitting+appending is not a lossless process, for various reasons. You can play around with "--append-mode file" vs "--append-mode track", if you want.

[hello_hello]

I don't know if it's expected, but when I append Test B.mkv to Test A.mkv (from the zip file I linked to) using "add as additional parts", the output is only Test A.mkv and there's no error or warning message.

I played around with "--append-mode file" and "--append-mode track". Neither changes the result.
It doesn't matter which --append-mode I use, after appending, the video timecodes from the output files are the same. There's no "gap" in the timecodes where they were appended.
After appending Test B.mkv to Test A.mkv, regardless of the --append-mode specified, if I then split the output MKV after frame 140, the second part has no video delay.

If I append them while also splitting after frame 140 in a single operation though (as I often do to split the audio and subtitles to match), it doesn't matter which --append-mode I use, the second part has a video delay of 600ms.

So unfortunately playing around with --append-mode didn't explain why appending and splitting in a single operation sometimes creates a video delay for the second part (even when there's no other streams), whereas appending and splitting in two steps doesn't.

[hello_hello]

There are no other formats that I know of that have similar information on top of the already existing timestamps in the file format.

MP3, Ogg and Opus (can) support gapless playback. Foobar2000 always knows the exact duration and number of samples compared to the original lossless file. Obviously it's not the case for AC3 though. Is gapless playback the same thing?

https://en.wikipedia.org/wiki/Gapless_playback

Opus doesn't support a 44.1k sample rate, hence the extra samples, but the duration is correct.

https://imgur.com/EYEyCQn.png

[Mosu]

I don't know if it's expected, but when I append Test B.mkv to Test A.mkv (from the zip file I linked to) using "add as additional parts", the output is only Test A.mkv and there's no error or warning message.

Read this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Adding-files-vs.-Appending-files-vs.-adding-as-additional-parts) for understanding what "add as additional part" is for.

[Mosu]

MP3, Ogg and Opus (can) support gapless playback.

Ogg is a container format, not a codec, unlike MP3 & Opus. Ogg doesn't really have any kind of controls for gaps or no gaps. All it has is a value called "granulepos" for each Ogg page whose interpretation depends on the codec used in the track you're looking at (it's generally described as "the absolute position of this packet in the original uncompressed data stream", but how that's calculated depends on the codec — for some it's simply multiplied by the sampling frequency, for others some bits are a number of frames since the last key frame, for others it's just a fraction of seconds, etc.). With this definition it is possible to precisely locate the end of a stream (and therefore ensure the next stream starts right afterwards). The drawback of only recording the end of the frame is that there's no way to properly encode gaps in such a stream, or offsets at the beginning, without deeply inspecting each frame and maybe eben enocding them. Additionally having different time bases is impossible for most codecs.

For Opus you're correct, in as that it has a pre-roll/pre-skip header fields for specifying the exact start & discard padding packet fields for specifying non-full last frames, thereby specifying the exact end. It's a very good format, not just for that but for its compression properties, too, of course. mkvmerge supports all of these fields for Opus.

All that being said, MP4 with iTunes tags is different insofar as there's the container format that already contains precise timestamps, then there's potential codec-inherent values and THEN there's the iTunes tags-based delay on top of those two. These are three layers of timestamp adjustments, and that's not how Ogg, Mp3 or Opus work. Ogg+Opus are two layers, MP3 in an elementary stream is just one level etc. That tags-based level is… interesting, and that's what I meant with "I don't know if there's any other similar mechanism".

[j7n]

MP3 [..] (can) support gapless playback. Foobar2000 always knows the exact duration and number of samples compared to the original lossless file. Obviously it's not the case for AC3 though. Is gapless playback the same thing?In MP3 the duration of delay and padding are saved in a silent frame, and cut off on playback. Compensating for the delay in a movie is easier than implementing gapless playback because films start and end with silence. Only the starting point needs be offset, and any extra silence at the end doesn't matter. All lossy codecs have a short fade-in, typically around 256 samples. I think Ogg codecs handle it internally.

Should latency compensation be added for other formats, may I suggest it is made opt-in, or an information about the correction is output to the muxing log. The audio stream might already be in perfect sync because X samples were deleted from the start, it was made using the --no-delay parameter in Qaac, or the audio was extracted from another container where sync was corrected using unknown means.

[markfilipak]

...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.
That's fine. I can manage. You-da-man!

I got another problem that really is a problem. Rather than repeat it here, I'll link to it:
https://forum.doom9.org/showthread.php?p=1995140#post1995140

What do you think? Do you have a fix?

Best Regards,
Mark.

[Mosu]

VobSubs have their duration stored within the packets themselves. That's why the .idx doesn't actually need a duration; it's implicit from the bitstream. There's no bug here.

[markfilipak]

VobSubs have their duration stored within the packets themselves.
Thank you, Mosu!

What are the odds that mkvextract is getting the durations found inside the '.sub' file, wrong?

Is there a way to check on mkvextract's work? I'd be able and willing to parse the '.sub' if I knew the struct.

The '.srt's that SubtitleEdit makes are definitely wrong sometimes. SubtitleEdit could be getting the 'end' timestamp calculations wrong of course, and I'm checking at that end. Sometimes the '.srt' that SubtitleEdit makes shows 00:00:00.000 as the 1st 'start' timestamp!

Sometimes the '.idx' that mkvextract makes shows 00:00:00.000 as the 1st 'start' timestamp!

With Best Regards,
Mark.

[Mosu]

What are the odds that mkvextract is getting the durations found inside the '.sub' file, wrong?

Unlikely.

Is there a way to check on mkvextract's work? I'd be able and willing to parse the '.sub' if I knew the struct.

Look up "spu DVD" and similar on Google; you'll find some reverse-engineered information about its structure. The official documentation is MPEG's DVD books; I doubt they're freely available.

Sometimes the '.idx' that mkvextract makes shows 00:00:00.000 as the 1st 'start' timestamp!

That's not inherently wrong. The start timestamp is simply taken from the Matroska packet's timestamp of the subtitle frame.

[markfilipak]

About 00:00:00.000 time stamp: The start timestamp is simply taken from the Matroska packet's timestamp of the subtitle frame.
Aw, really? It's always been wrong. I've not seen it myself, but I think some authors make an initial, blank sub so that subs are on from the git-go. I'm not referring to that. I use mkvextract to make IDXs and SUBs. I feed those to SubtitleEdit. The IDXs with 00:00:00.000 are always bad, and actually, all the times in them are screwed up.
In the 176-episode, 'STAR TREK, TNG' BD box, I found short runs of consecutive episodes in which mkvextract made bad (00:00:00.000) IDXs. I suspect some BD authoring tools produce PGC subs that are flawed, and some authors used them for the series of consecutive episodes that they authored. I could clip some source samples if you're interested.

[markfilipak]

I don't mean to 'pile on', but I have another issue:

This is a show-stopper. The actors in this play:
mkvtoolnix0.mkv (1:32:49.817)
mkvtoolnix1.mkv (1:15:04.461)
mkvtoolnix01.mkv (2:47:54.278) concatenation

This is the 1st of 3 concats to put together a 5 hour video.
(Note: I've left out the drive:\path\ parts for clarity.)

(Note: I'm using redirection: 2>output.txt, to capture 'showinfo' outputs...)

The 1st segment, mkvtoolnix0.mkv, ends on a P-frame -- look:

ffmpeg -i mkvtoolnix0.mkv -map 0 -vf showinfo -c:v rawvideo -sn -an -f null foo.mkv 2>output.txt
:
[Parsed_showinfo_0 @ 0000000003a77dc0] n:133538 pts:5569648 pts_time:5569.65 duration: 41 duration_time:0.041 ... iskey:0 type:P

That should be frame 133538: (3600+32*60+49.648)*24/1.001,... and it is.

mkvtoolnix1.mkv starts on an I-frame -- look:

ffmpeg -i mkvtoolnix1.mkv -map 0 -vf showinfo -c:v rawvideo -sn -an -f null foo.mkv 2>output.txt
[Parsed_showinfo_0 @ 00000000005ffe80] n: 0 pts: 0 pts_time:0 duration: 41 duration_time:0.041 ... iskey:1 type:I
:

Now comes the trouble. I used MKVToolNix to concatenate the two video segments.
I expect that frames 133538-cum-0 will become frames 133538-cum-133539 of course.
Here's the result:

ffmpeg -i mkvtoolnix01.mkv -map 0 -vf showinfo -c:v rawvideo -sn -an -f null foo.mkv 2>output.txt
:
[Parsed_showinfo_0 @ 0000000003a57dc0] n:133538 pts:5571483 pts_time:5571.48 duration: 41 duration_time:0.041 ... iskey:0 type:B <== this is not a P-frame
[Parsed_showinfo_0 @ 0000000003a57dc0] n:133539 pts:5571525 pts_time:5571.53 duration: 41 duration_time:0.041 ... iskey:0 type:B <== this is not an I-frame
:

Where did the P-cum-I-frame combo go?
In fact, there are no P-cum-I-frame combos in mkvtoolnix01.mkv

MKVToolNix doesn't transcode, so frames don't get resexed, so... what's going on?

MPV stepping through the transition:
1:32:49.481
1:32:49.522 <== MPV step (+41 ms)
1:32:49.564 <== MPV step (+42 ms)
1:32:49.606 <== MPV step (+42 ms) - 1/2 second of run with sound on this step
1:32:49.608 <== MPV step - 'time' almost stops
1:32:49.647 <== MPV step (is 1:32:49.606 + 41 ms)
1:32:49.608 <== MPV step - 'time' goes backwards on this step
1:32:51.649 <== MPV step (+2 sec jump) - 1 second of run with sound on this step
1:32:49.689 <== MPV step (-2 sec jump)
1:32:51.691 <== MPV step (+2 sec jump) - 1 second of run with sound on this step
1:32:49.731 <== MPV step (-2 sec jump)
1:32:51.733 <== MPV step (+2 sec jump) - 1 second of run with sound on this step
1:32:51.774 <== MPV step (+41 ms)
1:32:51.816 <== MPV step (+42 ms)
1:32:51.858 <== MPV step (+42 ms)
The 0:02.336 sequence above actually takes about 5 seconds of wall clock during which there are 3 'flashes' of non-black frames.
Audio and subtitles wind up still in sync.

Two issues:
1 - Disappearing P-cum-I-frame combo even though only muxing (sounds impossible to me).
2 - PTSs going forwards and backwards.

The question is not, 'How do I fix it?' The question is, 'How do I avoid it?' ...Please.
(I tried very hard to avoid problems and I planned the trimming as sensibly as I could.)

Regards,
Mark.

Aha! PS: I was reading my post and got a brainwave: Has the timing changed its basic timing of +41 ms/frame through the transition? Answer: No!
1:32:51.774 - 1:32:49.564 = 2.21 s.; (2.21 s)/(41 ms/frame) = 54 frames.
So, there should be 54 frames in the transition.

But 5 seconds in real-time, wall clock time tells me there's actually around 100 frames. So I could conceivably delete the offending frames. I'd have to delete them by frame numbers, not sexagesimal times. I don't know how to do that.

[markfilipak]

It looks to me that exactly 2 seconds are being skipped and that the 'tail' of mkvtoolnix0.mkv and the 'head' of mkvtoolnix1.mkv are overlapped causing 3 sets of back-forward jumps. It's hard to know for sure due to MKV's millisecond rounding granuarity.

:
1:32:49.608
1:32:49.647
1:32:49.608 - - - - - - jump back- - - - - fix: remove this
- - - - - - 1:32:51.649 jump forward - - - fix: move to end
1:32:49.689 - - - - - - jump back
- - - - - - 1:32:51.691 jump forward - - - fix: move to end
1:32:49.731 - - - - - - jump back
- - - - - - 1:32:51.733 jump forward - - - fix: move to end
- - - - - - 1:32:51.774
- - - - - - :

- - - 1:32:49.772 - - - jump over (skip) - fix: insert 48 black frames
- - - 1:32:49.813 - - - jump over (skip)
- - - 1:32:49.854 - - - jump over (skip)
- - - 1:32:49.895 - - - jump over (skip)
- - - 1:32:49.936 - - - jump over (skip)
- - - 1:32:49.977 - - - jump over (skip)
- - - 1:32:50.018 - - - jump over (skip)
- - - 1:32:50.059 - - - jump over (skip)
- - - 1:32:50.100 - - - jump over (skip)
- - - 1:32:50.141 - - - jump over (skip)
- - - 1:32:50.182 - - - jump over (skip)
- - - 1:32:50.223 - - - jump over (skip)
- - - 1:32:50.264 - - - jump over (skip)
- - - 1:32:50.305 - - - jump over (skip)
- - - 1:32:50.346 - - - jump over (skip)
- - - 1:32:50.387 - - - jump over (skip)
- - - 1:32:50.428 - - - jump over (skip)
- - - 1:32:50.469 - - - jump over (skip)
- - - 1:32:50.510 - - - jump over (skip)
- - - 1:32:50.551 - - - jump over (skip)
- - - 1:32:50.592 - - - jump over (skip)
- - - 1:32:50.633 - - - jump over (skip)
- - - 1:32:50.674 - - - jump over (skip)
- - - 1:32:50.715 - - - jump over (skip)
- - - 1:32:50.756 - - - jump over (skip)
- - - 1:32:50.797 - - - jump over (skip)
- - - 1:32:50.738 - - - jump over (skip)
- - - 1:32:50.779 - - - jump over (skip)
- - - 1:32:50.820 - - - jump over (skip)
- - - 1:32:50.861 - - - jump over (skip)
- - - 1:32:50.902 - - - jump over (skip)
- - - 1:32:50.943 - - - jump over (skip)
- - - 1:32:50.984 - - - jump over (skip)
- - - 1:32:51.025 - - - jump over (skip)
- - - 1:32:51.066 - - - jump over (skip)
- - - 1:32:51.107 - - - jump over (skip)
- - - 1:32:51.148 - - - jump over (skip)
- - - 1:32:51.189 - - - jump over (skip)
- - - 1:32:51.230 - - - jump over (skip)
- - - 1:32:51.271 - - - jump over (skip)
- - - 1:32:51.312 - - - jump over (skip)
- - - 1:32:51.353 - - - jump over (skip)
- - - 1:32:51.394 - - - jump over (skip)
- - - 1:32:51.435 - - - jump over (skip)
- - - 1:32:51.476 - - - jump over (skip)
- - - 1:32:51.517 - - - jump over (skip)
- - - 1:32:51.558 - - - jump over (skip)
- - - 1:32:51.599 - - - jump over (skip)

[Emulgator]

.mkv was not made for editing after all.
I would choose a different approach.

[Ripman]

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

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?)

Thanks and best…..

Hi M. Merry and thanks for v81.

From the sept 6 post quoted above…. Any ideas or insights on the VDH VDW values I’m seeing from encoding. Really appreciate. Best and happy…..

[Mosu]

The idea behind the two elements "Display Width" & "Display Height" is to signal the intended/optimal resolution at which to show the final video. A lot of players don't use them that way, though, and only use their ratio, but not the actual dimensions. For those players your huge values should be fine. Players that do follow the intended use, though, will likely show a huge window initially, which is likely not what you want.

[Ripman]

Thanks as usual very much.

I posted about this maybe 2-3 years ago here after dead-ending on the encoder forum.

2 questions:

1. Should I report it as a bug to the encoder devs?

2. IÂ’ll use a script to update the VDW / VDH based on the cropped dimensions - mkvinfo + mkvmerge. You see any issues with this approach?

Merry and happy, M. Best….

[markfilipak]

Regarding https://forum.doom9.org/showthread.php?p=1995186#post1995186 & https://forum.doom9.org/showthread.php?p=1995197#post1995197, I'm redoing all my work, so disregard those posts for the moment.

But I want to comment on something that may be significant:
For the video I trimmed (both ends) using MKVToolNix, the run time shown by MPV is
1194:33:59.458.
For the same video I just trimmed using ffmpeg, the run time shown by MPV is
1:32:51.432.

The requested trim points slightly differ because I found slightly better I-frames for the ffmpeg trim, but still...

What do you make of 1194:33:59.458?

The reason I say this may be significant is that the MKVToolNix subtitle stream is what's 1194:33:59.458, not the video or audio streams. And it's the MKVToolNix subtitle stream that later shows bogus out-times. In fact, once a subtitle is displayed, it's not removed until the next subtitle is displayed, even minutes later.

The ffmpeg subtitle stream works properly.

MKVToolNix has a subtitle timing problem somewhere.

I will pursue this if anyone shows interest -- e.g., has this happened to you? -- otherwise, I'll drop it and stop taking up doom9 space.

Oh, the version is MKVToolNix GUI version: 81.0

[mood]

dark mode on windows 11 and MKVToolNix GUI 81 flash white on startup, I use lastest version 81.0.51, is it possible to fix this??

Edited...

[Mosu]

dark mode on windows 11 and MKVToolNix GUI 81 flash white on startup, I use lastest version 81.0.51, is it possible to fix this??

Not from my end, no. This is up to Qt.

[Mosu]

What do you make of 1194:33:59.458?

I would need access to the source file that was fed into MKVToolNix in order for it to generate such a high timestamp. Without it I really cannot say anything useful.

[73ChargerFan]

Donation Time!
Thank you for your hard work this year. You're the best.

[markfilipak]

I would need access to the source file that was fed into MKVToolNix in order for it to generate such a high timestamp. Without it I really cannot say anything useful.
Of course. The file is many gigabytes.
...May I ask: Are you using the ffmpeg libraries? The reason I ask is that I've found some significant errors that may impact your stuff. I'm pursuing the issue on ffmpeg-user.

Aside: What I found are not obscure or 'corner' cases.

-- Mark.

[Mosu]

Of course. The file is many gigabytes.
...May I ask: Are you using the ffmpeg libraries?

No, I don't.

[RivDoVi]

Hi there :)!

Firstly, i'd like to wish you all a Happy New Year and all the best for 2024 :D

Now, i just updated mkvmerge from v80 to 81 (i only received the update notification yesterday, for an unknown reason) and almost made a heart attack reading that in the changelog :

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.

Is that issue as important as it sounds ?
I've been doing a lot of personal remuxes recently, more than a hundred with v80.
The idea of having to redo all of them to ensure they are proper would be a bit heartbreaking judging by the amount of time all these remuxes required in the first place :eek:

Does this issue occured with AVC streams ?
I mainly use EAC3to to demux audio then use the playlist .mpls in mkvmerge for video/subs/chapters. For extras & bonuses i simply drop the M2TS in mkvmerge.

If a remux is affected by the issue, shouldn't it be obvious to spot like completely out of sync audio & video ?
Any way to spot problematic remuxes easily ?

I'd be happy to receive an answer, i'm a bit panicking right now :).

Also, thanks a lot for the wonderful work on MKVmerge, been using it for years. :o

[Mosu]

Is that issue as important as it sounds ?

I guess this depends on how you do things & how important 100% correctness is for you. Some helpful (?) facts:

This type of problem only occurred sometimes, not for every stream, as the "arrival_time_stamp" that makes up most of the four bytes must have that special byte in them in order to trigger the issue.
It could only happen for MPEG transport streams that were used on Blu-rays, not for ones used for DVB broadcasting, for example.
It doesn't happen if you re-mux a file that another Matroska muxer produced, e.g. if you have a file produced by MakeMKV, then re-muxing that one with mkvmerge would not make it worse.
The number of frames skipped was always rather small (if it happened, usually the first group of pictures, meaning less than one second of content).

Does this issue occured with AVC streams ?

The problem occurred regardless of codecs, so yes.

If a remux is affected by the issue, shouldn't it be obvious to spot like completely out of sync audio & video ?

No, as the content dropped included both the audio & video. In other words, the first few frames of all content are missing, but the relation between audio & video timestamps was unaffected. If a movie starts with a black screen, as most on Blu-rays do, it's very, very likely you won't notice a thing.

Any way to spot problematic remuxes easily ?

No. Personally I would just randomly check ten or so movies done prior to v81 for A/V sync issues. If they seem to play fine, if the start of the movie doesn't show any issues, then I'd simply accept that things are the way they are.

[RivDoVi]

The number of frames skipped was always rather small (if it happened, usually the first group of pictures, meaning less than one second of content).[/list]

In other words, the first few frames of all content are missing, but the relation between audio & video timestamps was unaffected.

No. Personally I would just randomly check ten or so movies done prior to v81 for A/V sync issues. If they seem to play fine, if the start of the movie doesn't show any issues, then I'd simply accept that things are the way they are.

What about if you extracted the audio stream from the m2ts with another software (eac3to in my case) then used mkvmerge for the mpls while adding the eac3to processed audio ? I suppose in that case it should drop the frames for the video but would result in an out of sync audio because audio frames were not dropped by eac3to am i right ?

The dropped video frames by mkvmerge would mean the processed mkv video stream would logically start at the next i-frame which is quite enough to spot audio sync issue if my assumption above is right as it would lead to 400/500ms delay at the very least.

Also, just to be able to clearly have an idea if my ideas are correct, would you be able to kindly share here or via PM some disc titles that were problematic ?
I may have some of them, i suppose a practical example would be the best illustration :o

Kind Regards to you and thanks for your answer !

[Mosu]

What about if you extracted the audio stream from the m2ts with another software (eac3to in my case) then used mkvmerge for the mpls while adding the eac3to processed audio ? I suppose in that case it should drop the frames for the video but would result in an out of sync audio because audio frames were not dropped by eac3to am i right ?

That sounds about right, yes. You would likely be able to see a significant effect in the A/V sync if you're running into this issue.

That being said, exporting audio separately also means that mkvmerge doesn't have access to the audio/video delay information (meaning if they don't start at the same time in the M2TS). You'll have to tell mkvmerge the actual offset anyway. This is totally independent of the bug we're talking about; this is always the case if you separate audio & video & mux them from different source files.

Also, just to be able to clearly have an idea if my ideas are correct, would you be able to kindly share here or via PM some disc titles that were problematic ?

I only have what the reporting user uploaded for issue 3632 (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3632) (there's additional information in that report as well). The one short sample file I have is from a Japanese anime whose name I don't know. I actually don't know of any particular Blu-ray that's affected by the issue. Sorry.

[RivDoVi]

That sounds about right, yes. You would likely be able to see a significant effect in the A/V sync if you're running into this issue.
That being said, exporting audio separately also means that mkvmerge doesn't have access to the audio/video delay information (meaning if they don't start at the same time in the M2TS). You'll have to tell mkvmerge the actual offset anyway. This is totally independent of the bug we're talking about; this is always the case if you separate audio & video & mux them from different source files.

Yes of course.
Eac3to recognizes these delays and corrects them straight into the generated audio file. That is why it's widely used for audio processing/demuxing before using mkvmerge for remuxing as the latter adds delay information as tag which is less preferable for a clean result. This also prevents problem on playlists with multiple m2ts (referred to as "seamless branching).
Eac3to/DGDemux are the main audio demuxing programs used by the communities.

I reviewed 40 of my personal remuxes without encountering a problem for now ; i suppose this 0x47 timecode is pretty rare because normally the problem should be quite obvious with the eac3to/mkvmerge combo in the end since eac3to would not cut audio frames leading to desync, as implied on my previous post.

Lots of thanks for your kind and quick answers :thanks:

[Mosu]

Heya everyone!

Happy new year! Good time for a new release, I guess. This one with lots of bug fixes & enhancements. One important change is that Qt 5 is not supported anymore. The program now requires Qt 6.2 or newer for compilation.

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 82.0 "I'm The President" 2024-01-02
New features and enhancements

mkvmerge: Matroska reader: the "video alpha mode" track header property will be copied to the output file if present. Part of the implementation of #3643 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3643).
mkvmerge: Matroska reader: the "video alpha mode" track header property will be reported in JSON identification mode as the track property "alpha_mode". Part of the implementation of #3643 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3643).
mkvmerge: Matroska reader: the file's timestamp scaling factor will be reported in JSON identification mode as the container property "timestamp_scale".
mkvmerge: MPEG transport stream reader: teletext subtitles intended for hearing impaired people (type 0x05) are now marked as such via the appropriate flag in the track headers.
mkvmerge: file identification: the JSON identification output schema version has been bumped to 19.
mkvmerge: added a new hack "always_write_block_add_ids" that can be used as a workaround for players that don't support the handling of missing "Block Addition ID" sub-elements of "Block More" elements in block additions properly. These are used for e.g. alpha channel data in VP9 with a "Block Addition ID" value of 1, which is also its default value. Workaround for the player issues listed in #3643 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3643).
mkvinfo: added support for the "video alpha mode" track header element. Part of the implementation of #3643 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3643).
mkvpropedit, MKVToolNix GUI's header editor: added support for the "video alpha mode" track header property. In "mkvpropedit" it's called "alpha-mode". Part of the implementation of #3643 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3643).
MKVToolNix GUI: multiplexer: when adding files the GUI can automatically enable the "hearing impaired" flag for audio and subtitle tracks if the file name contains the word "cc" or "sdh" delimited by certain characters (configurable). This feature is turned on by default. Implements #3648 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3648).
MKVToolNix GUI: multiplexer: when scanning for Blu-ray playlists the GUI will now ignore playlists that are likely meant for menus. Currently the GUI considers this to be the case when a playlist contains the same item at least five times. This behavior can be turned off in the preferences. Implements #3658 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3658).

Bug fixes

mkvmerge: MPEG transport stream reader: fixed a crash introduced in v81 that occurred when there was at least one PCM track that wasn't copied from the transport stream file. Fixes #3645 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3645).
mkvmerge: when reading data from Matroska files damaged in a specific way, mkvmerge ended up trying to write various types of elements that aren't allowed to be written (so-called "EbmlDummy" elements as well as elements that don't have a value set) to the output file, which caused the underlying "libebml" library to abort. These types of broken elements are now filtered out.

Build system changes

Qt 5 is no longer supported. Qt 6 is now required for building MKVToolNix. This implies that the options to "configure" revolving around configuring Qt 5 or choosing between the two have been removed (e.g. "--disable-qt6").
Qt 6 detection: if detection fails, error messages from "qmake" can now be found in "config.log". See #3649 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3649).
Qt 6 detection: "configure" will only consider Qt 6.2.0 or newer, not 6.0.x or 6.1.y anymore, due to the lack of support for the multimedia module.
Qt 6 detection: "configure" will now fail to detect Qt 6 if the 'multimedia' module is not found by "qmake" (e.g. due to development packages not being installed). See #3649 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3649).
The bundled "fmt" library was updated to v10.1.1.


Have fun 😁

[tormento]

I'd like to move from TCC prompt (and batches) to PowerShell but I am really just at the beginning.

A typical TCC batch would be:

for %%a in (*.mkv) D:\Eseguibili\Media\MKVToolNix\mkvmerge.exe --output ^"M:\Out\%%~na.mkv^" --language 0:ja ^"%%~na.mkv^" --language 0:it ^"%%~na [ita].ec3^" --language 0:it --track-name ^"0:Cartelli PGS Dynit^" --forced-display-flag 0:yes ^"%%~na [ita] F.sup^" --language 0:ja --default-track-flag 0:no ^"%%~na [jpn].ec3^" --language 0:it --track-name ^"0:Completi PGS Dynit^" --default-track-flag 0:no ^"%%~na [ita].sup^" --chapter-language ja --chapters ^"%%~na.txt^" --track-order 0:0,1:0,2:0,3:0,4:0

but I really can't find a way to translate in PowerShell one.

Can someone with more experience help me?

[Mosu]

Also, just to be able to clearly have an idea if my ideas are correct, would you be able to kindly share here or via PM some disc titles that were problematic ?

The person filing the bugs answered the following when I asked them about the affected discs:

I personally have these:
RWBY vol.4 disc 2 00017.m2ts
Shokei Shoujo no Virgin Road Vol.1 00015.m2ts
I don't have these so I don't know what edition, but have been told they also had this problem. Since i asked to check for 47 byte at the start.
Kino no Tabi 2017 00010.m2ts
Karekano
Shoujo Kakumei Utena
Shakugan no Shana
Inuyasha: (BOX1 JPN)

[tormento]

I will try a second time ;)

Please consider to accept a directory as source for attachments in mkvtoolnixgui and mkvmerge command line.

[Mosu]

Please consider to accept a directory as source for attachments in mkvtoolnixgui and mkvmerge command line.

No, sorry, mostly because it would conflict with how the other "--attachment-…" options work.

[tormento]

No, sorry, mostly because it would conflict with how the other "--attachment-…" options work.
And creating a new --dirattachment switch? That wouldn't break compatibility at all.

[Mosu]

Not interested.

[Nico8583]

Hi, is there a way to treat multi angle playlist from a Blu ray ? Thanks.

[hubblec4]

With chapterEditor you can "feed" MTX with the correct m2ts order.

[Nico8583]

With chapterEditor you can "feed" MTX with the correct m2ts order.
Thank you, I'll look at it

[Nico8583]

Hi, another question.
Is it possible to not combine BL and EL streams when muxing to MKV ? I can't find an option.
Same question for Dolby TrueHD, is it possible to let TrueHD and AC3 combined in the same stream ?
Thank you.

[Mosu]

No, it's not. DV storage in Matroska is the same as DV in MP4: both layers in the same track.

Additionally in Matroska you can only have one codec per track, meaning TrueHD & AC-3 will always be separate tracks.

Matroska is not meant to be an intermediate format for later remuxing into MPEG transport streams. If you need that, don't use Matroska.

[jpsdr]

I've made several tries without succes for now, so i'm asking how to do...
I have a video file (1) at 24fps, another (2) at 23.976 fps. Both are "the same", meaning for exemple the frame number 12987 is exactly the same for both videos.
I want to mux the audio of (2) with the video of (1).
I tried the "streaching" method on video track of (1), with 23.976/24 parameter. But the mediainfo still provided 24.000fps information (when it should be 23.976). Stoped here, didn't think to check if video/audio where in sync.
So, i add the "Set fps default" to 24000/1001 on video track of (1). Mediainfo still provided 24.000fps information, and audio and video where out of sync.

Question : what's the difference between "streaching" and "Set fps default" ? Are they doing the same thing, just changing the duration of a frame ?

I discovered the "Correct binary data on temporal flux" checkbox (don't know if it's proper translation).

So, if i want to : change the fps of the video (1) to 23.976, have it properly detected by mediainfo, and finaly have my video and audio in sync, how should i mux ?

EDIT:
I've been able to have everything in sync, but whatever i do, check or not "Correct binary data on temporal flux", the fps reported by mediainfo is 24.000... :(
(Right click on the video inside MPC-HC and "MediaInfo" informations).

[tormento]

(Right click on the video inside MPC-HC and "MediaInfo" informations).
Try to use real MediaInfo (https://mediaarea.net/it/MediaInfo/Download).

[tebasuna51]

With the full MediaInfo you can see the diferences between check or not that checkbox:

Original MkvT-FPS +Fix bitstream
---------- ---------- --------------
Frame rate mode :
Frame rate (1): 24.000 FPS 24000/1001 24000/1001
Original frame rate (2): - the same 24.000 - the same
Standard :

(1) Frame rate stored in container (preferred at play time with standard players)
(2) Frame rate stored in video stream (ignored at play time but preserved if track is extracted)

Maybe MediaInfo is not clear but the MkvToolNix help yes.

Now you can mux the audio (2) to video (1) and play in sync

[jpsdr]

So... is it better or not to check the "Fix bitstream"... (I don't know why i have the feeling the answer will be "It depends..." ;))
What will give me the file with the less risk of wrong play with several different players ?

Finaly, after understanding (took me a little while) tebasuna51 answer :thanks:, it seems in my case it would be better to check it...

BTW, i thought i have the "Mediainfo" panel with MPC-HC when right click because i have installed Mediainfo, so i thought it uses the "real" Mediainfo.
Never checked if the panel is avaible on a system without Mediainfo. If i remember, i'll check when there is a new release and so install a new version.

[jpsdr]

Here the relevant informations from MediaInfo 24.01.1, opening the files with the "real" MediaInfo program.

Film_24_000

General
Format : Matroska
Format version : Version 4
Duration : 1 h 44 min
Frame rate : 24.000 FPS
Writing library : libebml v1.4.4 + libmatroska v1.7.1

Video
ID : 1
Format : HEVC
Duration : 1 h 44 min
Frame rate mode : Constant
Frame rate : 24.000 FPS


Film_23_976

General
Format : Matroska
Format version : Version 4
Duration : 1 h 44 min
Frame rate : 23.976 FPS
Writing library : libebml v1.4.5 + libmatroska v1.7.1

Video
ID : 1
Format : HEVC
Duration : 1 h 44 min
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS


I mux doing the following :
Audio is from Film_23_976 untouched, video is from Film_24_000 with FPS set to 24000/1001 + "Fix bitstream" checked.

Result is :

General
Format : Matroska
Format version : Version 4
Duration : 1 h 44 min
Frame rate : 24.000 FPS
Writing library : libebml v1.4.5 + libmatroska v1.7.1

Video
ID : 1
Format : HEVC
Duration : 1 h 44 min
Frame rate mode : Constant
Frame rate : 24.000 FPS

It plays fine in sync with MPC-HC, but... Is it realy what it should be...:confused: