Create a register to identify an audiotrack as audiocommentry.

[felisucoibi]

Some bd's have audiocommentary tracks, and could be very usefull when you auto9matize renaming, or identifying languages to know wich ones are audiocommentary ones, so can be marked in the mmkv protocol and used when needed.

[hubblec4]

You could use Matroska Tags for this.

[JeromeMartinez]

True that we are lacking of "standard" indicator for e.g. visually impaired or commentary, and it could be either an element as the Language element is or a tag we reserve for that (with a list of known values).

[hubblec4]

We have a similar open issue https://github.com/cellar-wg/matroska-specification/issues/313

We could add a new Track-element(TrackIdentify) which uses an enum: 0: visually impaired 1: hearing impaired 2: audio commentary

[dericed]

Not sure I recommend how #pbcore handles their expression for this, but the concept is similar to http://pbcore.org/elements/instantiationalternativemodes.

[hubblec4]

I was inspired by the DVD specs http://stnsoft.com/DVD/ifo.html#vidatt Scroll a bit down to the Title Audio Attributes table and have a look at byte 5.

code extension, 0 = unspecified, 1 = normal, 2 = for visually impaired, 3 = director's comments, 4 = alternate director's comments

[robUx4]

It seems that 2 values apply to audio tracks (visually impaired, commentary). The hearing impaired is more for subtitle tracks.

The audio properties don't seem mutually exclusive. If you have an audio commentary it may be "enhanced" for visually impaired people, explaining what is happening on the screen. It seems a bit far fetched, but IMO it's a possibility that visually impaired people might be happy to use.

So I think each of 3 values should have an element in the TrackEntry. Just like we put the language so it can be selected automatically based on the user preferences, the kind of audio selected can be done automatically. IMO it shouldn't go in Tags which should not change the playback behavior.

So I propose:

• 0*1(\Segment\Tracks\TrackEntry\Audio\Commentary) 0=none, 1=director, 2=alternate director

• 0*1(\Segment\Tracks\TrackEntry\Audio\Impaired) 0=none, 1=visually impaired

• 0*1(\Segment\Tracks\TrackEntry\Video\Impaired) 0=none, 1=hearing impaired

Technically a subtitle track can have TrackEntry\Video when it's bitmap based. There might also be special video tracks specifically for hearing impaired people (with visible cues for a bang for example). It may seem odd for a text based subtitle track but we can't have 2 values for the same thing and there is no TrackEntry\Subtitle because the elements that could be useful are already in Track\Video.

[hubblec4]

Why is there no 'TrackEntry\Subtitle'? It was never needed?

What you propose, create 3 new elements with not clear behaviour for the subtitles. I think this is not so good.

Why not only one new element for all Tracks? Identify a track is not necessary for playback. 0*1(\Segment\Tracks\TrackEntry\TrackIdentify)

[felisucoibi]

I think only is necessary to mark the track if it's an audiocomentary forget about director, or impaired etc... make it simple or nobody will use it. The goal of to be able to know if there is a audocommentary track is to deintify ti not as a dubbed language track but a audiocomment track, to be able to for example change the filename with a software to say this video has 3 languages and also has as a extra audocommentarie track.

Example "1989 - title of the movile - director 1080p ENG ac3 2.0 ESP dts 2.0 ENG COM ac3 2.0.mkv"

So you can easilly know thwet there are two english tracks but one of them is audiocomentary as an extra, this info is important.

Audiocommentaries are something that first time appeared in laserdics and are amazing to have them, but are not a real language track, so is nice to be abel to see the difference, but only this by now, i dont care if is the director, or another person, or even other thing, but i can see the difference between the real language tracks.*

There are lot of movies with audocommentaries, but i never aseen one with a visual impaired track, so they can use also audomentary flag for the same thing.

[hubblec4]

There are lot of movies with audocommentaries, but i never aseen one with a visual impaired track, so they can use also audomentary flag for the same thing.

Maybe such disc's are rare, but I had one where an visual impaired track is present. Sometimes describes a speaker the situation between the actors dialogs.

Example "1989 - title of the movile - director 1080p ENG ac3 2.0 ESP dts 2.0 ENG COM ac3 2.0.mkv"

I think this is not the right way for Matroska.

I think only is necessary to mark the track if it's an audiocomentary forget about director, or impaired etc...

Simple is fine, but accuracy is better. And for subtitles it also useful to know it is a "normal" or hearing-impaired subtitle. It just occurred to me we could add an enum(4) for a forced subtitle.

0: visually impaired 1: hearing impaired 2: audio commentary 3: audio alternate commentary 4: forced subtitle

[felisucoibi]

as you wish, i dont agree at all with you, accurate makes things to not be used.

But.... it does not make sense at all 2 and 3..... audiocommentaries there are a lot, there is not a main audocommentary, usually there is only one, but sometimes there are some of them, and there is not a main one.... so all of them should have the same flag to simplify scripts.

0. is ok, but less important because there are really few of them, but is ok.

1.. never seen a audio track for hearing imapired because they are heared imapired....

4. there is already a forced subtitle flag, or what do you mean?

[hubblec4]

1.. never seen a audio track for hearing imapired because they are heared imapired....

This is for subtitles

there is already a forced subtitle flag, or what do you mean?

Yes there is a forced flag which tells the player use this stream, but you can have multiple forced subtitle streams of different languages in one mkv.

[felisucoibi]

1.. never seen a audio track for hearing imapired because they are heared imapired....

This is for subtitles

there is already a forced subtitle flag, or what do you mean?

Yes there is a forced flag which tells the player use this stream, but you can have multiple forced subtitle streams of different languages in one mkv.

so why mix, subtitles with audios? create one flag for audio things and another for subs things.... i don't think makes sense the same tag for subs and audios....

Yes there is a forced flag which tells the player use this stream, but you can have multiple forced subtitle streams of different languages in one mkv.

I don'0t arrive to understand, this is more a thing of the player implementation, to choose the right sub and audio depending of thr config of the player, and language of the player.

[hubblec4]

so why mix, subtitles with audios? create one flag for audio things and another for subs things.... i don't think makes sense the same tag for subs and audios....

Yes, maybe you are right. Like Steve suggestions, but there is no Subtitle TrackEntry and for the subtitles you have also different types.

For me is this only an information, useful of course, but 3 new elements which do the same could be used in one new element.

I don'0t arrive to understand, this is more a thing of the player implementation, to choose the right sub and audio depending of thr config of the player, and language of the player.

The word "forced" is maybe not the right one. When I create my mkv's from a BD, there is an english subtitle "normal", another is for hearing-impaired and one more is the "forced" subtitle which have only a small amount of captions.

The subtitles will be named like: eng - forced (only the most necessary) eng - normal eng - hearing-impaired eng - directors comment ger - nur das Nötigste ger - normal ger - für Hörgeschädigte ger - Regiekommentar

Now I see quickly which stream is what when I play this mkv.

EDIT: On some BDs you have subtitles which uses pictures instead of text. Furthermore there is sometimes a secondary video. All this types of streams would get an enum from me.

[felisucoibi]

I understand subtitles maybe also need a register to mark them with different meanings like a audocommentary sub, or a hearing impaired sub, but different, don'0t reuse a registry for different things.

All these makes sense but the important by now for me is just audio-comment audio, because is so so common, but if at the same time we create 2 kinds of registry's one for special audio tracks and one for special subs is ok.

[hubblec4]

...don'0t reuse a registry for different things. ...but if at the same time we create 2 kinds of registry's one for special audio tracks and one for special subs is ok.

I know what you mean. But we have more than 2 types of tracks. The TrackType element:

A set of track types coded on 8 bits. 1 - video, 2 - audio, 3 - complex, 16 - logo, 17 - subtitle, 18 - buttons, 32 - control

A video track can also be a "normal" track or it is the secondary video, mostly the commentary video. Both video tracks can be played/shown simultaneously . OK, for complex, logo, buttons or control we don't need an identify (but how knows).

I don't see an advantage to split the track types for an identify. When we add 3 new elements, one for video, audio and subtitle this increases the code of a parser or script. If you have only one TrackIdentify element like TrackType, I think this is easier to handle.

[hubblec4]

Maybe is a combination of TrackType with the new TrackIdentify element a possible way?

TrackIdentify video enums 0: normal 1: secondary video

TrackIdentify audio enums 0: normal 1: visually impaired 2: commentray 3: alternate commentray

TrackIdentify subtitle enums 0: normal 1: hearing-impaired 2: commentary 3: forced (only the most necessary)

if TrackType = 1 then use TrackIdentify video enum list if TrackType = 2 then use TrackIdentify audio enum list if TrackType = 17 then use TrackIdentify subtitle enum list

[Nottt]

I find insulting that this is considered more urgent than supporting language tags like pt-pt, pt-br, and others...

Which actually causes lot of issues for people and software

[mcr]

I have three thoughts: 1) if have to name languages, then naming them using the ISO-2-letter codes should be done, akin to how locales work. 2) better to introduce new tags than overload existing ones 3) @Nottt , I'm guessing here that sometimes non-controversial minor things are easier to propose than ones that take more discussion, so don't take people working on X rather than Y meaning that X is more important/urgent than Y. It may be less important/urgent, and as a result, easier to get consensus. Pull requests accepted.

[robUx4]

This is solved by #447 with the addition of FlagHearingImpaired, FlagVisualImpaired and FlagCommentary.