New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a register to identify an audiotrack as audiocommentry. #357
Comments
You could use Matroska Tags for this. |
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). |
We have a similar open issue We could add a new Track-element(TrackIdentify) which uses an enum: |
Not sure I recommend how #pbcore handles their expression for this, but the concept is similar to http://pbcore.org/elements/instantiationalternativemodes. |
I was inspired by the DVD specs
|
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:
Technically a subtitle track can have |
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? |
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. |
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.
I think this is not the right way for Matroska.
Simple is fine, but accuracy is better. And for subtitles it also useful to know it is a "normal" or hearing-impaired subtitle. 0: visually impaired |
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.
1.. never seen a audio track for hearing imapired because they are heared imapired....
|
This is for subtitles
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....
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. |
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.
The word "forced" is maybe not the right one. The subtitles will be named like: Now I see quickly which stream is what when I play this mkv. EDIT: |
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. |
I know what you mean. But we have more than 2 types of tracks.
A video track can also be a "normal" track or it is the secondary video, mostly the commentary video. 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. |
Maybe is a combination of TrackType with the new TrackIdentify element a possible way? TrackIdentify video enums TrackIdentify audio enums TrackIdentify subtitle enums if TrackType = 1 then use TrackIdentify video enum list |
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 |
I have three thoughts:
|
This is solved by #447 with the addition of |
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.
The text was updated successfully, but these errors were encountered: