MKVToolNix v24.0.0 released

[ndjamena]

I think this is a continuation of Jamaikas desire to add interactive tags to his files.

JSON changes NOTHING about the files themselves, it has nothing to do with the Matroska Specs. All it does is change the OUTPUT of a single command in the MKVMerge application.

MKVMerge -I file.mkv

or

MKVMerge -i file.mkv

It just makes it easier for other applications to decipher MKVMerges identification output, nothing more.

[Jamaika]

Originally Posted by Mosu

no, that's way too much effort for not enough gain.

Originally Posted by ndjamena

It just makes it easier for other applications to decipher MKVMerges identification output, nothing more.

Thanks all. Now I understand everything.

[cengizhan]

Originally Posted by Mosu

That's normal, intentional and exactly how it should work. The file's duration is the difference between its maximum timestamp and its minimum timestamp. Just because players stop when the video track stop doesn't mean the file ends there.

i thought my video was corrupted or mkvmerge is bugged until i opened the subtitle file with an editor and saw it is longer than video.

[ndjamena]

Is there a technical reason the header editor wouldn't be allowed to shuffle the positions of tracks, ie like rearranging subtitles?

I've been doing it manually, but it would be much easier if I could just drag and drop and not have to keep track of which track number was where in case I wind up duplicating one (or leaving one out, which is the same thing).

[Mosu]

That functionality hasn't been implemented yet, neither in the GUI nor in mkvpropedit. I don't know if I'll ever implement it, though it's that I'd consider sometime in the future.

[ndjamena]

I'll stick to doing it manually then.

[SeeMoreDigital]

Can someone please remind me what the final discussion was regarding to the possibility of muxing Dolby TrueHD streams and preserving the Dolby Digital core within the .mkv container? Is it technically possible now?


Cheers

[Mosu]

If you mean you want to keep both the TrueHD and the AC3 data inside the same track: mkvmerge doesn't support that. Instead it will separate that data into two independent tracks. Meaning all of the data is preserved, but mkvmerge "sees" two tracks in such a case instead of a single one. That works even when re-muxing from M2TS, not just from elementary TrueHD files (.thd+ac3).

[SeeMoreDigital]

Originally Posted by Mosu

If you mean you want to keep both the TrueHD and the AC3 data inside the same track: mkvmerge doesn't support that.

Yes, I realize that mkvmerge does not support this.

What I'd like to know is, is it now technically possible to do this with the Matroska container?

[sneaker_ger]

Mkvmerge does not support it because it is regarded as non-spec-compliant. The Matroska specs have not changed in this regard. (That may not hinder other software developers (makemkv?) to ignore that or interpret the specs in a different way.)

[SeeMoreDigital]

Originally Posted by sneaker_ger

Mkvmerge does not support it because it is regarded as non-spec-compliant. The Matroska specs have not changed in this regard. (That may not hinder other software developers (makemkv?) to ignore that or interpret the specs in a different way.)

Okay, thanks for the confirmation about this!

The reason I asked is because Oppo Digital recently removed TrueHD pass-through support for .mkv contained files due to a reliably issue with the Mediatek A/V decoding chip-set.

Oppo Digital have developed a work-around by transcoding multi-channel TrueHD audio to multi-channel PCM audio. But sadly if the TrueHD stream contains Atmos, the Atmos (object based) data is completely lost.

Sufficed to say, the Mediatek A/V decoding chip-set is able to 'pass-through' a TrueHD stream just fine when it's placed within the .m2ts container.


Cheers

[nevcairiel]

Sounds like they should fix their software. When you transmit TrueHD over HDMI, then the AC3 part is no longer present. The HDMI specs are pretty strict about that.

[SeeMoreDigital]

Originally Posted by nevcairiel

Sounds like they should fix their software. When you transmit TrueHD over HDMI, then the AC3 part is no longer present. The HDMI specs are pretty strict about that.

Yes and no. In the case of TrueHD in m2ts, the AC3 core is still present within the stream as is the AC3 flag. And you are able to select the different streams.

[nevcairiel]

Originally Posted by SeeMoreDigital

Yes and no. In the case of TrueHD in m2ts, the AC3 core is still present within the stream as is the AC3 flag. And you are able to select the different streams.

Not once it reaches HDMI. What the player does in between is not really important there. Of course it can let you select the AC3 stream.

[SeeMoreDigital]

Regardless, it would still be useful if the Matroska container supported TrueHD along with the core (as it does with DTS-HD MA). As it would provide more logical support with playback devices such as Smart TV's.

It's a right pain having to go through all your Blu-ray .mkv back-ups to add the AC3 stream... Indeed, last night I fancied watching a bit of Gravity on my LG television but was greeted with an 'Audio format not supported' message.

Anyway, if it can't be done. It can't be done

[Mosu]

DTS-HD MA is a very different case. TrueHD and AC3 are completely independent sets of data. One can be decoded without the other. The TrueHD data can exist and be decoded alone. So can the AC3 data.

For DTS-HD MA the situation is vastly different. Here the MA part can, in general, NOT be decoded alone. Instead the DTS core is required for decoding the MA part, too.

[nevcairiel]

The only way this actually works in MPEG-TS is that it has special metadata to mark the AC3 frames as a "substream", only this way can players identify which frames belong to the TrueHD stream, and which belong to the AC3 stream. You can't just mux both together and hope for the best, it has to be muxed properly - otherwise every player is going to break.
It seems rather unlikely that inventing a new muxing scheme for such tracks would magically fix smart TVs. It seems far more likely that they are designed to deal with this MPEG-TS variant somehow, but their MKV implementation is just broken. If you have to cater to such a TV, it seems sensible to just keep your videos in MPEG-TS.

Surely it could be muxed in MKV say using BlockAdditions or something like that, just for the sake of keeping the two streams packed "together", but players would still need to handle that, so it wouldn't make any sense and wouldn't fix anything automagically.

[SeeMoreDigital]

Originally Posted by nevcairiel

Surely it could be muxed in MKV say using BlockAdditions or something like that, just for the sake of keeping the two streams packed "together", but players would still need to handle that, so it wouldn't make any sense and wouldn't fix anything automagically.

I guess it's like any other implementation. Until somebody comes up with a method of doing it, device manufacturers wont be able to support it. Which really should be the advantage of adopting 'open-source' software in the first place

[nevcairiel]

Originally Posted by SeeMoreDigital

I guess it's like any other implementation. Until somebody comes up with a method of doing it, device manufacturers wont be able to support it. Which really should be the advantage of adopting 'open-source' software in the first place

You could just mux them in two distinct streams like it is today, and a device manufacturer could read it. Why it would need the AC3 stream in the first place is beyond me, however.
Screams faulty implementation to me. The AC3 stream is not required for the TrueHD stream to work.

[SeeMoreDigital]

Originally Posted by nevcairiel

You could just mux them in two distinct streams like it is today, and a device manufacturer could read it...

Yes I know I can. And I do. But that's not what I was enquiring about