Matroska mapping

Support
1

Thanks for finally having Mp3tag support Matroska files. Matroska is quite a powerful and flexible container, thus a fitting addition to Mp3tag.

My question is, what "text" should I input into the "Options > Tags > Mapping" for Matroska? This is the place where after a fresh installation, there are 3 items there, which are all of "VorbisComment".

I want to map some Matroska tags but I had no luck. I tried inputting "Matroska", "MKV", and "MKA", but no luck, it just constantly reverts to "ID3v2". Thanks in advance.

2

It's not possible to change the mapping for Matroska (yet). I'd need to add the different levels of Matroska tags to the mapping description, which also isn't possible yet.

Can you describe the mapping you're trying to add? Maybe it's something which makes sense as a default.

3

I just want to link Mp3tag's WWW to Matroska's URL tag. Which I think are the direct coounterpart of each other? Thanks and more power.

4

I'd like to add my thanks for the fabulous work done in supporting Matroska files so far.

I also think it'd be great if you could somehow implement user-defined mapping functionality, including the target type levels, for Matroska tags.

A mapping I'd particularly like to add, which I think would make sense to have as a default, if it could be done more quickly that way, would be from Mp3tag's TVSEASON field to Matroska's PART_NUMBER tag at target type level 60 (T=60).

If I create this T=60 PART_NUMBER Matroska tag longhand (by writing an XML file and muxing in via via MKVToolNix rather than using Mp3tag), then MS Windows will display the held number value for me as Season number (Windows property name = System.Media.SeasonNumber).

If I use Mp3tag's TVSEASON field when tagging an MP4 video file, that'll also display the same way in Windows.

So, it'd make sense if the TVSEASON field worked in a consistent way, to facilitate Windows showing a season number for Matroska video too.

Similarly for TVEPISODE as well.

If I use Mp3tag's TVEPISODE field when tagging an MP4 video file, that'll display as Episode number in Windows (System.Media.EpisodeNumber).

Windows would also display an Episode number for MKV video if Mp3tag's TVEPISODE field were mapped to Matroska's PART_NUMBER tag at target type level 50 (T=50).

Further notes:

There is a workaround to get a Matroska PART_NUMBER tag created at target type level 50 (T=50) for the purposes of an episode number, which is to use Mp3tag's DISCNUMBER field instead of TVEPISODE.
An Mp3tag DISCNUMBER entered numeric value will display in Windows as Episode number.
I think mapping TVEPISODE to T=50 PART_NUMBER would be better for MKV video though, making it more consistent with the way MP4 video tagging works for example.

I don't think there's any workaround to create a PART_NUMBER tag at target type level 60 (T=60) in Mp3tag (thus displaying in Windows as Season number).
TVSEASON mapping to T=60 PART_NUMBER would therefore the priority request from that point of view.

However, bear in mind also, while I don't think there's a currently a way to create a Matroska T=60 PART_NUMBER tag using Mp3tag; it will display a pre-existing one (a tag created by writing an XML file and muxing via MKVToolNix, say).
Mp3tag displays this T=60 PART_NUMBER value in its DISCNUMBER field, along with any T=50 PART_NUMBER, showing the two separated by a double backslash.
For an MKV video file with both a season number tag and an episode number tag, Mp3tag would show, for example, T=60 PART_NUMBER holding the value 61, and T=50 PART_NUMBER holding the value 58, as DISCNUMBER = 61\\58
If you try and edit this displayed DISCNUMBER value, say, from 61\\58 to 61\\59, then that has the effect of disappearing the underlying MKV file's original T=60 level PART_NUMBER, and creating its held value at level T=50 instead. Thus losing the season number and ending up with two episode level T=50 PART_NUMBER tags, one holding a value of 61, and the other holding an updated value of 59.

I'd suggest the solution to that issue is to have Mp3tag's DISCNUMBER field functionality fixed, to ignore and leave well alone any T=60 PART_NUMBER tags.

Version and OS info:
At time of writing I'm using the most current Mp3tag version, v3.23
OS Name: Microsoft Windows 10 Pro (version: 10.0.19045 Build 19045).

TL;DR Summary

For MKV files:

Mp3tag's TVSEASON field should be mapped to Matroska's PART_NUMBER T=60 tag.
Mp3tag's TVEPISODE field should be mapped to Matroska's PART_NUMBER T=50 tag.
+
Mp3tag's DISCNUMBER field shouldn't display/edit any PART_NUMBER T=60 tags.

5

I've just released Mp3tag v3.28e, which adds a mapping of TVEPISODE to T=50 PART_NUMBER and a mapping of TVSEASON to T=60 PART_NUMBER for MKV Matroska video files.

6

I've tested Mp3tag v3.28e and I think it works well.
No major issues as far as I can see, but here are some observations.

When you enter DISCNUMBER for MKV with this new v3.28e, the field disappears from view in the tag panel, and the entered value pops up in the TVEPISODE field instead.
If you repeat the process (or if TVEPISODE already has a value), then the TVEPISODE field shows multiple occurrences separated by double backslashes (\\), creating multiple T=50 PART_NUMBER tags in the MKV file.
I think this is okay though.
When you enter a single value in the TVEPISODE field then any multiple occurrences get tidied up into a single T=50 PART_NUMBER tag.
Other than using DISCNUMBER field as previous workaround (prior to this fix), it doesn't really make much sense to try and enter a DISCNUMBER value for MKV anyway.
There's nothing much else that could be done with it, apart from maybe creating a non-standard unofficial DISCNUMBER Matroska tag, so I think the observed behaviour is alright.

Any MKV tags such as Director and Genre sitting at level T=30 (since they were created using an earlier version of Mp3tag), will remain that way unless actually edited with this new version of Mp3tag.
For example, an edit that changes Genre but leaves Director untouched will move the Genre tag to T=50, but leave the Director tag where it was, at T=30.
This means you'd have to do a dummy edit, changing the value of Director, saving it, then changing it back again, to get it to move to T=50.
Again, I think this is okay though.
It would probably create more problems than it resolves to try and automatically correct the target type value levels of unedited tags.

Mp3tag's TITLE field continues to produce TITLE T=30 tags (ie. at chapter level) for MKV.
There's an argument for setting it to level 50.
However, it's still possible to use the ALBUM field to produce TITLE T=50 tags for MKV, so I think that's fine for the time being.

Similar to the way that DISCNUMBER field entered values now disappear and pop up instead in the TVEPISODE field, Mp3tag's SUBTITLE field values still disappear when entered for MKV, continuing to pop up in SETSUBTITLE field instead.
There's an argument for reconsidering this behaviour now T=50 is the new default level for MKV.
But, it's just how it was working before, and thus, using the SETSUBTITLE field, it remains possible to create SUBTITLE T=50 tags for MKV, so it's not something that should hold up Mp3tag v3.28e going live I'd suggest.

7

Further findings:

Mp3tag's ARTIST field continues to map to ARTIST T=30 tag for MKV.

ENCODED_BY is doing the same.

As with the other observations, I don't think these are showstoppers.

Having tags appear at T=50 rather than T=30 for MKV is for the most part something I'd consider as quite nice to have.
I don't think it affects functionality all that much, but it would make Matroska tags more consistent and generally easier to comprehend.

However, note also the following pre-existing tag field mapping issue :
Using Mp3tag's ENCODERSETTINGS field results in the creation of a Matroska tag wrongly called ENCODERSETTINGS.
The correct Matroska tag name is ENCODER_SETTINGS (ie. including an underscore).
Windows displays the correctly named Matroska tag as Encoding settings (System.Media.EncodingSettings).
Windows doesn't recognise the incorrectly named tag.

8

Yes, there is still the existing mapping — I didn't want to remove it, because otherwise any existing actions that use this field name would break.

Correct, and it wouldn't be possible without writing to the file and modifying the metadata.

This would result in a mapping of both Mp3tag's TITLE and ALBUM to Matroska's TITLE at T=50. Besides that, I think it's helpful to still be able to enter title-specific information on T=30 level.

This is the problem I've mentioned above. Both Mp3tag's SUBTITLE and SETSUBTITLE are now mapped to Matroska's SUBTITLE on T=50. SETSUBTITLE most likely needs to be raised to T=60 now for MKV.

Noted, thank you.

9

Chapters have their own system in MKV files, supported by separate XML files, so I'd suggest creating tags such as TITLE at T=30 (chapter level) isn't really useful.

There's currently no way of creating TITLE T=60 tags (season level) using Mp3tag, so I'd say there's a stronger case for mapping Mp3tag's ALBUM field to MKV's TITLE T=60 tag, and mapping Mp3tag's TITLE field to MKV's TITLE T=50 tag.

I haven't pushed for this so far because my personal use of tags is very 'Windows-centric', and, unlike with PART_NUMBER, where Windows does make a useful distinction between T=60 and T=50 levels (displaying them as Season number and Episode number respectively), Windows will only display the last TITLE tag it finds (thus it won't display a season title along with an episode title).

Windows displays any SUBTITLE tag (regardless of level), showing it as Episode name (Windows property: System.RecordedTV.EpisodeName), so that's what I use instead of two levels of title.

However, somebody less 'Windows-centric' than me might want to follow the Matroska spec a bit closer, and have a TITLE tag specifically at T=60 to indicate a series/season title.

As I say, there's currently no way of doing this with Mp3tag at the moment, so mapping Mp3tag's ALBUM field to MKV's TITLE T=60 tag, and mapping Mp3tag's TITLE field to MKV's TITLE T=50 might be considered more useful.

Yes, I agree. Mp3tag's SETSUBTITLE field would be better mapped to MKV's SUBTITLE T=60 tag, and Mp3tag's SUBTITLE field to MKV's SUBTITLE T=50.

I'd thus suggest adopting a similar approach to the mapping of Mp3tag's ALBUM and TITLE fields for MKV files (ALBUM →TITLE T=60, and TITLE →TITLE T=50) would be quite consistent with that two level subtitle approach.

10

I agree and I've implemented this, along with the changes outlined above, with Mp3tag v3.28f.

Many thanks for your helpful suggestions!