http://www.makemkv.com/forum2/viewtopic.php?f=1&t=7926
Read it to the end.
This is Mosu's explanation:
Hey,
That does indeed look like a design flaw. The tags are the way they are because back when they were specified only two people (Steve Lhomme and myself) were working on the specs, and tags were something we neither focused on nor something we were particularly interested in.
http://matroska.org/technical/specs/tagging/index.html
![]()
+ Reply to Thread
Results 1 to 21 of 21
-
-
You're right, the fact that the Matroska Tag system is a non-functioning waste of time is not important. Please delete the thread.
-
Just because it's not latest news it might still be important.
Can't they "redesign" it? Or is it too late and would require updates for all mkv decoders. -
I'm pretty sure it is possible to redesign the Tagging system, as for 'updates for all MKV decoders'... there's not one program on the planet that can read Matroska tags properly, they all need updating no matter what happens, however as Jean-Baptiste Kempf put it,
Originally Posted by Jean-Baptiste Kempf
he didn't know the half of it, because no ones ever bothered going that far. The guy who wrote the bloody things didn't understand how they worked until I explained it to him. That's two years of my life down the drain. -
Does this topic have anything to do with the tags version 7 of mmg now writes by default?
I ask because I don't really understand them yet (I haven't researched them at all) and as a result I don't know what adding those tags is supposed to achieve. All I know is I've been successfully playing the MKVs I create for quite a while without those tags being written, so for the moment I've stopped MKVMergeGUI from writing them by using the global "--disable-track-statistics-tags" option. -
To an extent yes. The statistics tags are meant to show the actual makeup of the tracks within a file, before them the only possible way to get that kind of information was to parse through the entire file and count bits. You may not have noticed but MP4 already has tags that give out that kind of information, and MKV tags would have worked exactly the same once programs learned what they were and knew to hide them from human eyes. The problem is, according to the actual Mastroska specifications they're not actually possible. There is no way to assign tags to a track, or an attachment. Programs are displaying them as belonging to the tracks, but they shouldn't be. What the tags are actually pointing at is a title that encompasses all the attachments, all the chapters, all the editions and one track. A song consists of only one track, if I want to add tags to a song it would directly conflict with the way the tags are currently being interpreted. The best example so far of what's wrong with this is my attempt to add images to my TV Shows, seasons and episodes. The tags are being applied to the attachments, when they shouldn't be, because they encompass all the tracks and all the chapters as well. The Mastroska specs allow adding multiple episodes to a single file, if you tried to apply an attachment to each episode you'd run across the same problem. Basically, the MP4 tags work because they assume there's one title in one file and the application of seasons and TV Shows is rather perfunctory. The Mastroska Specification tries to offer more, but they've mucked up the implementation. The tags MKVMerge has been putting into the file aren't actually valid. To make them valid would destroy the ability to assign titles properly. Really there needs to be two kinds of tags, Title tags and Info tags, but there aren't.
-
I didn't add this link in case someone altered the webpage but:
http://matroska.org/technical/specs/tagging/index.html
Once you actually understand it, you'll realise it's a crock. -
This is worthwhile news and worth sharing, but to be honest with you I really could not possibly care less that MKV's tagging is broken since I never use it and have no plans to do so and I bet that more people are like me than you.
-
Pull! Bang! Darn!
-
Well, personally, since Media Center Master adds xml metadata into the directory and Mezzmo is quite capable of collecting its own metadata the only actual use for Matroska metadata I'd have is to have something for MediaInfo to display when I point it at the file. It would be nice if I could get windows to display the stuff too. I honestly thought it would be a nice thing to have. Unfortunately I've been trying to get metadata into these things for two years now, constantly battling MetaX and then MKVPropedit only to finally learn that the bloody things were doomed to failure long before I got to them. Even if they patched them up and got them working, the way they currently work is still ridiculous and getting any decent player support for the things will be almost impossible.
-
OK, this is the MediaInfo output for an MP4
Code:General Complete name : Z:\ITunes\Ben 10- Omniverse\Season 02\Ben 10- Omniverse - 02x10 - Evil's Encore.mp4 Format : MPEG-4 Codec ID : M4V File size : 127 MiB Duration : 21mn 28s Overall bit rate mode : Variable Overall bit rate : 825 Kbps Encoded date : UTC 2014-05-01 13:25:36 Tagged date : UTC 2014-05-01 13:25:36 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L3.1 Format settings, CABAC : Yes Format settings, ReFrames : 7 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 21mn 28s Bit rate : 661 Kbps Maximum bit rate : 15.9 Mbps Width : 1 024 pixels Height : 576 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.045 Stream size : 102 MiB (80%) Title : AVC/H.264/MPEG4 Part 10 (25 fps) Writing library : x264 core 142 r2409 d6b4e63 Encoding settings : cabac=1 / ref=7 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=10 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=250 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=2:0.60 Language : English Encoded date : UTC 2014-05-01 13:25:36 Tagged date : UTC 2014-05-01 13:25:38 Audio ID : 2 Format : AAC Format/Info : Advanced Audio Codec Format profile : LC Codec ID : 40 Duration : 21mn 27s Bit rate mode : Variable Bit rate : 160 Kbps Maximum bit rate : 175 Kbps Channel(s) : 2 channels Channel positions : Front: L R Sampling rate : 48.0 KHz Compression mode : Lossy Stream size : 24.5 MiB (19%) Title : English AAC(2.0) Language : English Encoded date : UTC 2014-04-23 00:51:26 Tagged date : UTC 2014-05-01 13:25:38 Text ID : 3 Format : Timed Text Muxing mode : sbtl Codec ID : tx3g Duration : 21mn 17s Bit rate mode : Variable Bit rate : 72 bps Stream size : 11.2 KiB (0%) Title : English - SDH Language : English Encoded date : UTC 2014-05-01 13:25:38 Tagged date : UTC 2014-05-01 13:25:38 Menu #1 ID : 4 Codec ID : text Duration : 21mn 28s Encoded date : UTC 2014-05-01 13:25:38 Tagged date : UTC 2014-05-01 13:25:38 Bit rate mode : VBR Menu #2 00:00:00.000 : Intro 00:01:18.440 : "Ben 10: Omniverse" 00:01:38.640 : Part 1 00:07:54.120 : Part 2 00:14:20.280 : Part 3 00:20:57.880 : Credits
Code:General Unique ID : 241238336709015606499303205493338220100 (0xB57CD04AB97D125DA99F7DC96A0B2644) Complete name : F:\MKV\Ben 10- Omniverse\Season 02\Ben 10- Omniverse - 02x10 - Evil's Encore.mkv Format : Matroska Format version : Version 4 / Version 2 File size : 196 MiB Duration : 21mn 28s Overall bit rate : 1 276 Kbps Movie name : Ben 10: Omniverse - 02x10 - Evil's Encore Encoded date : UTC 2014-04-30 04:39:27 Writing application : mkvmerge v6.9.1 ('Blue Panther') 64bit built on Apr 18 2014 18:23:38 Writing library : libebml v1.3.0 + libmatroska v1.4.1 TITLE : Evil's Encore PART_NUMBER : 10 TOTAL_PARTS : 20 DESCRIPTION : Dr. Animo remembers the time he had taken control of the Plumber Headquarters inside Mount Rushmore with bugs that easily hack computer codes, planning to mutate everyone on Earth into grotesque, monstrous creatures resembling him. CONTENT_TYPE : TV Show Attachment : Yes Video ID : 2 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L3.1 Format settings, CABAC : Yes Format settings, ReFrames : 7 frames Codec ID : V_MPEG4/ISO/AVC Duration : 21mn 28s Width : 1 024 pixels Height : 576 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Title : AVC/H.264/MPEG4 Part 10 (25.000 fps) Writing library : x264 core 142 r2409 d6b4e63 Encoding settings : cabac=1 / ref=7 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=10 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=250 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60 Language : English Default : Yes Forced : No Audio ID : 3 Format : AAC Format/Info : Advanced Audio Codec Format profile : LC Codec ID : A_AAC Duration : 21mn 28s Channel(s) : 2 channels Channel positions : Front: L R Sampling rate : 48.0 KHz Compression mode : Lossy Delay relative to video : 9ms Title : English AAC(2.0) Default : Yes Forced : No Text ID : 1 Format : VobSub Muxing mode : zlib Codec ID : S_VOBSUB Codec ID/Info : The same subtitle format used on DVDs Title : English - SDH Language : English Default : No Forced : No Menu 00:00:00.000 : en:Intro 00:01:18.440 : en:"Ben 10: Omniverse" 00:01:38.640 : en:Part 1 00:07:54.120 : en:Part 2 00:14:20.280 : en:Part 3 00:20:57.880 : en:Credits
Code:General Unique ID : 187739487076673001148066868579322832807 (0x8D3D4F5B89599895A0074437E29C27A7) Complete name : F:\MKV\Ben 10- Omniverse\Ben 10- Omniverse - 02x10 - Evil's Encore.mkv Format : Matroska Format version : Version 4 / Version 2 File size : 196 MiB Duration : 21mn 28s Overall bit rate : 1 276 Kbps Movie name : Ben 10: Omniverse - 02x10 - Evil's Encore Encoded date : UTC 2014-06-23 13:43:25 Writing application : mkvmerge v7.0.0 ('Where We Going') 64bit built on Jun 9 2014 15:16:27 Writing library : libebml v1.3.0 + libmatroska v1.4.1 TITLE : Evil's Encore PART_NUMBER : 10 TOTAL_PARTS : 20 DESCRIPTION : Dr. Animo remembers the time he had taken control of the Plumber Headquarters inside Mount Rushmore with bugs that easily hack computer codes, planning to mutate everyone on Earth into grotesque, monstrous creatures resembling him. CONTENT_TYPE : TV Show Attachment : Yes Video ID : 2 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L3.1 Format settings, CABAC : Yes Format settings, ReFrames : 7 frames Codec ID : V_MPEG4/ISO/AVC Duration : 21mn 28s Width : 1 024 pixels Height : 576 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Title : AVC/H.264/MPEG4 Part 10 (25.000 fps) Writing library : x264 core 142 r2409 d6b4e63 Encoding settings : cabac=1 / ref=7 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=10 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=250 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60 Language : English Default : Yes Forced : No DURATION : 00:21:27.488000000 NUMBER_OF_FRAMES : 60351 NUMBER_OF_BYTES : 30945566 _STATISTICS_WRITING_APP : mkvmerge v7.0.0 ('Where We Going') 64bit built on Jun 9 2014 15:16:27 _STATISTICS_WRITING_DATE_UTC : 2014-06-23 13:43:25 _STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES Audio ID : 3 Format : AAC Format/Info : Advanced Audio Codec Format profile : LC Codec ID : A_AAC Duration : 21mn 28s Channel(s) : 2 channels Channel positions : Front: L R Sampling rate : 48.0 KHz Compression mode : Lossy Delay relative to video : 9ms Title : English AAC(2.0) Default : Yes Forced : No DURATION : 00:21:15.435000000 NUMBER_OF_FRAMES : 384 NUMBER_OF_BYTES : 378012 _STATISTICS_WRITING_APP : mkvmerge v7.0.0 ('Where We Going') 64bit built on Jun 9 2014 15:16:27 _STATISTICS_WRITING_DATE_UTC : 2014-06-23 13:43:25 _STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES Text ID : 1 Format : VobSub Muxing mode : zlib Codec ID : S_VOBSUB Codec ID/Info : The same subtitle format used on DVDs Title : English - SDH Language : English Default : No Forced : No DURATION : 00:21:28.080000000 NUMBER_OF_FRAMES : 32202 NUMBER_OF_BYTES : 173547833 _STATISTICS_WRITING_APP : mkvmerge v7.0.0 ('Where We Going') 64bit built on Jun 9 2014 15:16:27 _STATISTICS_WRITING_DATE_UTC : 2014-06-23 13:43:25 _STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES Menu 00:00:00.000 : en:Intro 00:01:18.440 : en:"Ben 10: Omniverse" 00:01:38.640 : en:Part 1 00:07:54.120 : en:Part 2 00:14:20.280 : en:Part 3 00:20:57.880 : en:Credits
I don't know what's happening now. -
Actually, I'm going to change my answer to 'no, it has nothing to do with the Track Statistics tags'. The Track Statistics tags themselves are perfect, the problems with them are that people that don't understand what they are and what they do and the system upon which they're built upon. It's the original Mastroska Tag specifications that are the problem, I know people like to vilify the Track Statistics and I don't want to fan those fires. It's hard to know what really happened (ill-conceived seems the best word for it) but the specs seem designed solely to define 'titles', and once you get into it you begin to realise it can't even really do that properly. There are massive holes in the system and it's easy to assume that they're there because you're missing something, or that there must be a simple way around them, but the fact is there isn't. Any simple solution to one problem just opens up more holes somewhere else. And holes aside, the fact is the way the tags work are a pain in the arse to work with and even if you got them working, since once you get past one pain in the arse problem there's another one right behind it, there's no incentive for anyone to write code to interpret them.
Last edited by ndjamena; 23rd Jun 2014 at 12:35.
-
I was away for a few days but I thought I should post and say thanks for the info!
I'll hopefully get a chance to read it properly (digest it better) later today or tomorrow.
One question..... what would be the advantage of the track tags being displayed as individual tracks?
Maybe I just haven't got my head around it yet but it seems like an odd implementation to me. Wouldn't it be better if the tags were invisible or at least directly attached to a track? At the moment the "--disable-track-statistics-tags" doesn't seem to stop existing tags from being re-written.... you need to manually uncheck them.... but if you don't uncheck them I assume "--disable-track-statistics-tags" doesn't stop mmg from correctly updating the tags if streams are replaced or re-ordered etc?
For example what happens if I uncheck the tags for track 0, leave the track 1 tags checked, swap the order of tracks 1 and 2, then remux with "--disable-track-statistics-tags" added to the commandline?
Or what happens if I mux existing MKVs as a single file and each already has tags for track 0 and track 1? That sort of thing.......
Hopefully I'm not being hysterical..... I'm just wanting to understand how it works. When remuxing existing MKVs would it be best to manually uncheck existing tags and let mmg write new ones or wouldn't it matter? -
If you read the original thread you'd see that unless the writing program updates the _STATISTICS_WRITING_APP and _STATISTICS_WRITING_DATE_UTC any tags that remain in the file should be invalidated to any program that knows how to read them properly, even if they're still present. Theoretically, if a new version of MediaInfo is released that can read those tags, not only will it remove them from display, but if the App and Date tags don't match the Segment header it won't even use them at all for statistics purposes. As for MKVMerge not removing the tags with --disable-track-statistics-tags that's something Mosu hasn't got round to yet. It never removes them, just rewrites them. If you happened to remux a file with an old pre version of MKVMerge that added the statistics as Level 30 'track' tags it won't remove those either. Reordering the Tracks is no issue, since the tags point to track UIDs rather than the Track Numbers. UIDs are copied over intact from one MKV to another and it's not actually possible to change them using MKVMerge. If you try to merge two MKVs that contain tracks with the same UID MKVMerge will assign one of the tracks a random UID, I'm not sure what happens to the two sets of tags then, but it will either overwrite them or if you choose --disable-track-statistics-tags they'll become technically invalid. If you'd ever tried to add tags to an MKV you'd know 'theoretically' there are tags for 'global', 'all' and 'tracks'. I'm guessing that's just a product of Mosu not actually understanding his own system. The tags are listed individually to differentiate them from the 'global' tags, I'm not sure if there's a purpose beyond that. I'd still like to know if there's any program on the planet that's actually found a good use for the Matroska tagging system, I had this assumption at first that there must be, but I can't find anything. There's this sad little fact that most people look at the Matroska Tagging system and try to see MP4 tags in it because that's something they understand. Last I checked the Tags MetaX were adding to my files could barely be called MKV tags at all. I don't think Mosu was any different in that regard. Hopefully something will sort itself out.
The tagging system doesn't really make sense. It vaguely makes sense so if you're not actually trying to use them it kind of looks like it makes sense. To use them to their full potential would require a complete understanding of how they work but there are more than enough holes and ambiguities to make a complete understanding impossible.
What I'm mulling over at the moment includes
1: If you add Title and Actor Tags to a TV Show they seem to operate in two different ways. The Title remains a part of the TV Show yet the Actors tags are somehow added to the Actors tags of the Episode as stats for the episode. It does kind of make sense and if you say it perfunctorily it does seem to make sense, but it's inconsistent. But then once you start considering the lower levels like the Level 30 Chapter tags or lower the entire concept seems to fall to pieces. Add to that, when you consider a show like Doctor Who, in Metadata tradition the actors for the TV Show include all the doctors and all the companions, yet according to the MKV Tagging system The TV Show itself has no actors at all, in fact some of the seasons have no actors either. The reality of any TV Show is it's not uncommon for a main actor to leave partway through a season, that doesn't mean the actor shouldn't be considered part of the cast of the season, or in fact the TVShow. And again, once you reach the lower levels it all falls to pieces.
2: VLCs gripe, that Episodes are on Level 50 where Songs are on Level 30. Judging by how the tags are laid out, I'm pretty sure someone in the tagging spec process liked classical music rather then popular music. It is true that some songs can be considered titles in their own right, while other seem more like chapters in a greater piece. The problem here is that there's no definition of 'this', or even a hint of what the actual 'title' should be. Which is a point here, although it is possible to get quite a lot of detailed information into a file using the Matroska tags, far too much of the interpretation of the tags and what they mean is left up to the player, and that's just insane.
3: Kind of ties up with 2 and the current Track Stat issues. They're trying to fit too much in too small a space and it's confusing. The tags need to be spread out more, there needs to be different kinds of tags that operate in different ways. I think there needs to be an entry point so programs know where to begin. But that's just my opinion.
I'm babbling about something I can't make heads or tails of.
Originally Posted by hello_hello -
IMHO, there's no other solution than updating the Matroska specs.
And when we remember that the MKVtoolnix project has only one active developer, ... -
And when we remember that the MKVtoolnix project has only one active developer, .
Cu Selur
Ps.: From my point of view Mosu does an outstanding job maintaining mkvtoolnix, sure it has some flaws and problems but atm. it's the best container format out there. -
Thanks again for the info.
A new version of MediaInfo which hides the tags would be nice, although to be honest I'm still not sure why MKVMergeGUI doesn't also hide them. Having them displayed as tracks seems kind of odd to me, especially as the track statistic tags aren't something a user would modify.
I guess when the way something works is obvious and there's no confusion there won't be much hysteria about it, but when it's a little counter-intuitive...... for instance remuxing this mkv with "--disable-track-statistics-tags" in the commandline
results in this
And without "--disable-track-statistics-tags" in the commandline you get this
So it does appear mmg removes unneeded statistic tags, but at the same time the tags are displayed the same way as tracks, however they aren't treated the same way as a normal track when muxing, which is a counter-intuitive way to implement them.... in my opinion. I guess once you understand the way it all works.....Last edited by hello_hello; 28th Jun 2014 at 20:13.
-
Well, technically, the track tags aren't meant to be just 'statistics' tags. They're just tags that are attached to the track, which could be anything that describes the contents of the track. 'Commentary' could be a tag.
It's odd, now that I've had time to think about it and understand how it should work it's getting hard to understand what everyone else is seeing. I can kind of see how the tags are supposed to work, and sometimes it seems quite elegant and almost usable. I figure what you're supposed to do is create a list of all the attachments, editions and chapters then for each chapter create a list of each track within that chapter. then you start applying tags to each element. Then the really hard part starts, where you have to start counting everything and begin rebuilding all that data into something useful.
I've realised I was probably wrong in the way I added the attachments tags to my files. Without a tag representing TV Show and Season the tags given to the episode attachment don't give a complete identification of the episode. I did ask Mosu if what I was doing was correct and he said yes, so that's what I did. Really I'd need to assign TV show, season and episode tags to the TV Show image, TV show and season tags to the season image and only assign Episode tags to the Episode image. In order to find the attachment that belongs to a TV Show a program would have to search all the tags and find the one whose lowest tag level is level 70. Expecting people to write programs that work like that en masse is a big ask and I think it would be more prudent to organise the tags in a way that's closer to the way a program would actually use them when you put them in the file. It also leaves no room for actual track statistics tags without adding new rules that would further complicate things.
And I really don't understand how the whole inheritance thing works, at least not in a way a computer should see it. There is a rule that all tags in a higher level also apply to those levels beneath... That would work for a 'director' tag, it would work for an 'artist' tag in a music file, but the 'Title' tag specifically breaks that rule yet there's no difference between it's formatting and the formatting of any other tag that I can see. The only explanation I can see is that a higher level tag only applies to a lower level tag if that tag doesn't exist in the lower tag, which opens up a whole new bag of worms. Babylon 5 is the only TV Show I know of that has specific names for each season, so almost every TV show would need a blank 'Title' tag in it's season tags. Of course I just made that up, the Specs themselves don't actually bring the subject up.
And that's the point really, the specs don't explain themselves properly, even if after all this is over Mastroska keeps the existing tagging system the specs themselves will have to be rewritten and every program on Earth that deals with the files will have to be updated to comply. Until that happens, anyone whose looking at the tagging system for any purpose at all is just wasting their time, as I'm sure a lot of people had realised long before I entered the scene.
If I don't kick up a fuss now nothing is ever going to be done about it.Last edited by ndjamena; 29th Jun 2014 at 02:49. Reason: Wrong explanation of image tags
-
I guess I may have sidetracked your own tagging issue a little by bringing up the track statistic tags, but to be honest they're about the first time I've had to deal with mkv tags so I don't have an inkling of an idea as to how they're supposed to work. The sort of tags you're referring to.... "director", "actor", "episode" etc.... I'd have no idea where to even begin.
Anyway..... thanks again for the info. -
Don't worry, I was on the bus on the way to the shops when I realised I'd got the image tag explanation the upside-down, I was specifically trying not to do that. And once again I've realised that since there's no way to NOT assign an attachment to a tag the whole thing collapses once you go bellow level 50.
I barely know what I'm talking about anyway, no one does. The specifications themselves are nonsensical and the only TV Show example on the website does nothing more than add 'title' tags to chapters... don't chapters already have names? (In the example the season doesn't inherit the TV show 'title', nor is it's own blanked out.)
Which brings up a point, did anyone else notice that according to a strict interpretation of the specs, if you have two editions in a file and you specify only the UID of one edition to a tag, that tag applies to every track, every attachment, that edition, all the chapters in that edition and all the chapters in the other edition as well?
At least the example shows how to add multiples of the same UID type to a tag, which I was wondering about.
ps. if I sound sarcastic or like I'm picking on the specs, it's because there's no polite way to bring up these kind of problems.