Subtitle default mkv flag handling

[morbius]

Hi,

My usual ripping workflow is to tick both my main language subtitle track and the forced version. (I should clarify I am very familiar on the subject of separate dedicated subtitle tracks to provide forced subtitles, e.g. as common on Marvel titles, I am focusing here on the handling of forced subs embedded in the main track, e.g. Game of Thrones).

In the rare occasions where there are forced subtitles within the main track the forced track gets the default flag in the mkv file and the subs seamlessly switch on when the mkv is played through Kodi. If there are no forced subtitles, I'm pretty sure what used to happen is that the main language track would be retained but without the d flag set - i.e. the full subs would only be shown in Kodi upon request. This was perfect, exactly mirroring original-disc playback.

At some point, it looks like things have changed so that in the event the forced track is empty, the mkv default flag is now set for the full main language subtitle track. This means I now get the full subs showing when I don't want them.

Is it correct that the way makemkv handles this has changed at some point? This is a bit of a chore, as I'm having to remux now afterwards to get the flags set correctly, or just gamble that there are not forced subs, whereas before I could usually do the whole thing in one pass. I've not been ripping much in the last year so I'm not sure when this issue came about.

It would be useful to know if handling of sub default flags has changed at some point, and if anyone would object to either changing back or having this set as a user configurable option.

[Grauhaar]

the mkv default flag is now set for the full main language subtitle track. This means I now get the full subs showing when I don't want them.

There are many other threads which addresses this point. Yes, the MakeMKV default profile was changed (no idea why), the solution is (also in the threads) to build your own profile and set the option to "false". Easy task.

as I'm having to remux now afterwards to get the flags set correctly

You can change any flag in the MKV header by using "MKVToolNIX GUI" Header Editor. Change the value, name etc. and save it, instead of remux.

[morbius]

Thanks @grauhaar for referring me to the other posts. Perhaps as more people post about this, it might be considered whether this change in default handling could be reverted back to what it was.

I followed instructions to create my own profile and selected it in my Preferences. I opened a disc and noticed that in the Properties drop-down box for the selected forced-only track, the MKV flags property was blank (previous versions would have this as "d"). I set it to d and ripped, but then I was back to where I started, with the full sub track having the default status, since the forced track was empty.

Can anyone advise what I'm doing wrong? Also, is 1.14.5 the last version of makemkv that had the old defaults for subs, I think I will roll back as this has become a bit of a hassle.

Appreciate also the tip about the post-rip header change.

Code: Select all

<profile>
    <!-- profile name - Default -->
    <name lang="mogz">My Profile</name>

    <!-- Common MKV flags -->
    <mkvSettings 
        ignoreForcedSubtitlesFlag="true"
        useISO639Type2T="false"
        setFirstAudioTrackAsDefault="true"
        setFirstSubtitleTrackAsDefault="false"
        setFirstForcedSubtitleTrackAsDefault="true"
        insertFirstChapter00IfMissing="true"
    />

[morbius]

ok, I dropped down to 1.14.5 and everything "just works" when it comes to subtitles, without any profile hassle, so I will stick with that for now as I don't need AACS 2.1 support.

[Grauhaar]

Did you edit the profile with Notepad without BOM enabled? I use a modified profile and it works as expected (Default flag is off after rip).

Selecting a Forced track in the title list did not say that forced "flagged" subtitles in the subtitle tracks exists. This works only, if in the track are normal and forced flagged subtitles. In this case the flagged subtitles are copied in the new created rack forced track.

[morbius]

Hi

I edited the profile using notepad++ and makemkv had a log entry that the profile was in use during ripping.

I could tinker with this some more but 1.14.5 just works, so I will stick with this for now. It would be good to hear if the change has been an accidental regression or done deliberately for other reasons.

[morbius]

Posting on this again as I do feel there has been a functionality regression in 1.14.6/7. I will use Game of Thrones Series 1 bluray as an example.

Up to version 1.14.5, behaviour was as follows:

Episode 2 (first of many episodes with forces subs embedded in the main sub track). I select PGS English and PGS English (forced only). Output correctly contains two subtitle tracks, second of which contains the forced subs, and this track is marked as default and is automatically displayed in VLC player and Kodi.

Episode 1 (no forced subs in the main track). I select PGS English and PGS English (forced only). There are no forced subs so only one sub track is output, but it does not have the default status set, so VLC and Kodi do not show the full track by default, but the subs are available upon request.

The above scenarios mirror disc playback perfectly.

Version 1.14.7: as we've all noticed, it is defaulting to set the first sub track as default, so whenever we include subs in the rip, VLC and Kodi will show them. This is really annoying. We can fix by editing the rip or prevent it by use of a personal profile and use "setFirstSubtitleTrackAsDefault=false". Unfortunately, this does not quite work as it should. I shall explain.

Let's go back to episode 2 of GoT series 1. In order to get the forced sub track to have a default status, in expert mode I set the "d" for the MKV flag for the PGS English (forced only) track. I've now got this to work and the output contains two sub tracks, with the forced track having a default status so VLC player shows it automatically.

Unfortunately, if we do the same thing for episode 1 (set the d flag for the forced sub track in the GUI), by completion of the rip, there isn't a second subtrack to output as this episode has no forced subs, but the d flag is now set for the sub track that is available, i.e. the full sub track, so I am back to square one, and once again I have to fix this afterwards.

As things stand, with 1.14.7 I have to use a personal profile, and then either not set a d flag for either track in the GUI and fix afterwards if it turns out there are forced subs, or set a d flag for the forced track and fix afterwards if there aren't any forced subs.

None of this was an issue up to 1.14.5.

At the very least, can the issue of the track-specific "d" flag via the GUI be fixed per my episode 1 example above? Better still, just go back to how it was up to 1.14.5?

[Chetwood]

I'm still on 1.14.3 so I haven't used the flagging option from the GUI yet but if I understand this correctly, you're entering the flags manually for each movie? So if there's only one track, wouldn't it be safe to assume it has no forced subs and so you simply don't set the flag? Wouldn't it be easier to simply rip the movie with all subs you need and flag them with MKVToolnix's header editor? That way the file does not have to be remuxed and it takes only a few seconds.

Apparently the problem still stems from the fact that most BDs are authored without flagging the sub properly and unless Mike implements a routine that would recognize the forced sub by it's size (like BD2AVCHD did), errors like this will keep popping up.

[morbius]

I get that it’s possible to fix this post-rip via a header editor, my main point is that up to 1.14.5 perfect authoring was possible via makemkv itself, whereas now I need to be more alert to the need to fix afterwards.

It would be nice to hear if the functionality change is deliberate, if the downsides were known, or if this is just a plain regression. Not the end of the world, but given the sparsity of release notes (which I get in some respects) we are all none the wiser.

[solidus28]

Just checking in on this again. Looks like the behavior still exists in 1.15. Any updates?

[mike admin]

Just checking in on this again. Looks like the behavior still exists in 1.15. Any updates?

Sigh. Believe it or not, this was actually a bugfix -- "if the subtitle track is flagged by default, and then it turns out to be empty, and the track is derived - then flag his parent/base track as default instead". I believe matroska spec requires each track of type to have a default flag. And it turns that VLC et al interpret the "default" flag differently. This will be fixed somehow...

Now, for a workaround. The "thing" that that actually creates an MKV file is a MKV multiplexer library, which is based on libmatroska and is therefore opensource. The muxer library is fairly separated from the makemkcon app, and is being open source is easily changeable. In theory one could even write a library that muxes to mp4 (with dolby vision and transcoding blu-ray PGS subtitles into DVD vobsub, dts to ac3 and such) and transform MakeMKV into MakeMP4

So, for your particular case, if you go to install location of 1.15 and replace libmakemkv.dll (libmakemkv64.dll, libbmakemkv.dylib etc) with a version from 1.14.5, then you will get a latest and greatest MakeMKV GUI/decryption/processing but with MKV muxer from 1.14.5 that handles the default flag the old way. Don't tell anyone

[solidus28]

Exciting! Will try this later today. Thanks, Mike! I can live with this

[morbius]

Just checking in on this again. Looks like the behavior still exists in 1.15. Any updates?

if you go to install location of 1.15 and replace libmakemkv.dll (libmakemkv64.dll, libbmakemkv.dylib etc) with a version from 1.14.5, then you will get a latest and greatest MakeMKV GUI/decryption/processing but with MKV muxer from 1.14.5 that handles the default flag the old way. Don't tell anyone

thank you, this worked. Ran this against episodes 1 and 2 of GoT series 1, and got perfect authoring of subtitle flags under 1.15, without any need for a personal profile or tinkering afterwards with a header editor.

[solidus28]

Just tested my first disc and it worked like a charm for me, too! Thank you, thank you, thank you!

[Chetwood]

I believe matroska spec requires each track of type to have a default flag. And it turns that VLC et al interpret the "default" flag differently.

That's not exactly how I read Moritz' FAQ entry over at hxxps://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Default-and-forced-flags-and-default-yes-no-in-the-GUI:

There are several flags in Matroska with confusing or unclear names ("default", "forced", "enabled"). In addition, the GUI uses similar terms ("default") in drop-down boxes for other controls, not only these flags. This entry tries to explain what those flags mean to the Matroska, for playback, and also how the GUI and therefore mkvmerge decide how to set them depending on the values the controls are set to.
Leaving a flag (no matter which flag) on the "default" settings means the decision whether or not it should be set is up to mkvmerge. mkvmerge usually takes the information provided by the source container into account. For some flag types (especially the "default track" flag) there are other considerations as well.

Setting a flag to "no" will force mkvmerge not to set that flag, no matter what those other considerations would have done and no matter what the source container provided for that flag.

For the "default track" flag: The special consideration is that mkvmerge will automatically set this flag to "yes" for exactly one track of each track type (audio, video, subtitles). You can only prevent this by explicitly setting the "default track" flag to "no" manually for all tracks of a kind (e.g. for all subtitle tracks).

The "default track" flag tells the player that this track should be played unless the user overrides that decision somehow. You usually mark the original audio track with "default track" and leave it off for the rest of them, e.g. for the director's commentary or some translations you don't want [(e.g. The Lord of the Rings, mark "English" as "default track" but not "German" and "Director's comments (English)].

As a lot of users don't want subtitles shown by default, they tell mkvmerge not to set the "default track" flag for any subtitle track.
Now on to the "forced display" flag, in short "forced". If this is set to "on", this track must be played/shown no matter what the user selected for his preferences or what the player would normally chose to show/play. This is used seldom, e.g. only for a subtitle track that only contains the English translation whenever Legolas is talking Elbish.

"Forced" has nothing to do with "default track". If "forced" is set, the player must play that track no matter what "default track" is set to. In fact, normally a track that has "forced" set does not have "default track" set, though it is neither invalid nor undefined behavior.