New MP4 Field Requests ©dir and ©wrt

Support
1

[The following request was written at my request by Microsoft’s AI agent, Copilot]

Subject: Feature Request: Support for MP4 Director/Writer Atoms (©dir, ©wrt)

Hi everyone,

I wanted to float a small feature request that might be useful to others who work with MP4/M4V video files, especially those who use Plex, Jellyfin, or similar media managers that read embedded MP4 metadata.

Mp3tag already handles most MP4 atoms beautifully — title, description, long description, genre, artwork, sort fields, and even cast/performer information all come through perfectly. It’s one of the reasons I rely on Mp3tag so heavily in my workflow.
There are just two atoms that seem to be missing from Mp3tag’s MP4 writing support:
• ©dir — Director
• ©wrt — Writer

Even though Mp3tag exposes a “DIRECTOR” field in the UI, that field maps to ID3/Vorbis/APE tag systems, not to MP4 atoms. As a result, when tagging MP4/M4V files, the director and writer information never makes it into the file in a form that Plex (or other media managers) can read.

Performers/cast do make it through correctly, which is great — but directors and writers have to be entered manually inside Plex, which breaks the otherwise smooth “tag once, import anywhere” workflow that Mp3tag is so good at.

Proposed enhancement:
Add native support for writing the MP4 atoms:
• ©dir (Director)
• ©wrt (Writer)
…in the same way Mp3tag already writes atoms like ©nam, ©alb, desc, ldes, ©gen, and covr.

This would allow Mp3tag to fully support MP4 video metadata for users who rely on embedded metadata rather than online agents.
I’m curious whether other MP4‑oriented users would find this helpful as well. I know many people use Mp3tag primarily for audio, but there’s a growing number of us who use it for video libraries too, and this would close one of the last remaining gaps.

Thanks for considering it — and thanks to Florian for continuing to maintain such an elegant and reliable tool.

— Web (with assistance from Microsoft Copilot)

2

I wish the AI would have quoted from the MP3tag documentation.
You find ©wrt as COMPOSER in MP3tag
You find DIRECTOR ©dir to be an exclusive field for MP4 files also already available.
See e.g. here:

3

Thanks for adding a AI disclaimer to your post.

Mp3tag already supports the ©dir MP4 atom via DIRECTOR. Can you try using this and see if Plex is picking up its contents?

It's possible that Plex even ignores that and reads the information from iTunMOVI tag. Here is something I found regarding this on the Plex forums

Mp3tag also supports writing ©wrt MP4 atoms via the COMPOSER field name, c.f,

This is where the LLM started generating nonsense. Mp3tag would never write any of those formats, as it would effectively destroy the integrity of the MP4 container. I wish these systems weren't so good at confidently making things up.

4

I agree with what you're saying but the problem lies far more with other software not supporting @dir, @wrt and frankly plenty other tags more appropriately. Plex in particular is pretty bad with local metadata that isn't scraped. Media software does indeed rely far more on an ITUNMOVI tag for reading Director and Writer from MP4’s.

If it’s of any help, I made a script for The Movie Database that’ll create ITUNMOVI for you. It can also save a TMDB tag that you can then use as part of your media’s filenames to enable scraping: either method should get cast, directors, producers, writers and so much more showing up in your software.

5

It is unfortunate that “wrt” has been turned into Composer by current sofware. It is my understanding that this field contains the author(s) of both music and words - Writer or Songwriter. A composer is only the author of music and may come with a lyricist. It seems that the Apple tag scheme gets constantly revised with new 3 or 4 letter codes, and not all software agrees on them. This is among the reasons why I never use the AAC format, and extract E-AC-3 out and tag it with APEv2.

I don’t use tagging for films. I suspect that some other fields should be used unambiguously instead of repurporsing music-related fields. In movies you have an author of “screenplay” in addition to music. Similar situation exists in radio dramas where the writing is not the same as “lyrics”.

6

It has been this for ages, the problem is rather that they originally was for movies (writer/screenwriter), and then repurposed into music, and then the music software grabbed this for composer. I don’t find that the tag changes a lot, but without any central authority, they are up to the whims of the app developers.

7

In a perfect situation, one tag would be used but simply labelled differently between media types: @wrt, TCOM, WM/Composer etc. would be Composer for anything music related, Writer for videos, Author for books etc., even more-so for things like Track / TV Episode / Book Number could be unified. I think that’s what MKV somewhat tried to achieve with its target type method.

That being said, I wouldn’t unify Artists / Actors / Characters etc. given your point that some fields are too centred towards a particular property. I use a custom WRITER tag for MP4 movies rather than COMPOSER but I still hum-and-haw over whether that’s actually practical so I simply try to support the use of either in what I develop. (Edit: that’s a lie, I DID use WRITER then changed to WRITTEN_BY because I use MKV :shaking_face: )

This exactly. There’s simply too much diversity between file formats, their supported tags and their actual implementation between media software that still cares to support it to ever really get a unified approach. Most decisions on how metadata is structured seems to be proprietary to a company, particularly in how they want to stream data to you, rather than how they allow you to view your own data.

The most that can be done is pick one media software, cater metadata to it, convert metadata if you change your software. Tagging videos is really just for personal organisation at this rate.

8

Are there any examples of tagging MOV/MP4 video files in the Mac ecosystem? I recall Itunes started as music-only, and then music videos got added to albums later.

I am looking back at older software. The Coding Technologies plugin for Winamp 2 has a field for Writer in the tag dialog. Foobar 0.8.3 through Foobar 0.9.5.4 interpret it as writer, XMPlay 3.8.5 interprets it as writer. In modern pop music they don’t distinguish composer and lyricist, and one cuesheet field songwriter contains all.

I prefer other tag formats that spell out the entire (short) word unambiguously. Matroska does this too in addition to Ogg/FLAC/Ape.

9

The MPEG4 started out as the QuickTime format, and was primarily for video editing. When Apple acquired iTunes, it was MP3 only I believe and they added AAC using MP4 and adapted the QuickTime format which was formalized by ISO a few years earlier. QuickTime tagging is limited but contain cores of what is used today. There are a few other tools that specify metadata for MP4, but iTunes have become de facto standard.

10

I’ve entered data for both “COMPOSER” and “DIRECTOR” to the mp4 metadata via Mp3tag and neither one gets added to the Plex database. If I add the data to the “WRITER” and “DIRECTOR” fields to the Plex database using the Plex editor, it works fine. But I would really like Plex to be able to pick it up from the mp4 metadata.

11

I routinely add DIRECTOR and COMPOSER when I index my mp4 files in the hopes that it will end up working with Plex with each new release of Mp3tag and Plex but so far neither DIRECTOR nor COMPOSER make it to the Plex database, at least not for me. I even tried mapping DIRECTOR to ©dir. ARTIST works great and if I were desperate I could add the name(s) of the DIRECTOR and COMPOSER as ARTISTs but my goal is to get them to display in Plex with the proper labels, which I can do if I add them to the Plex database using the Plex editor but I’d rather add them via Mp3tag.

12

Does the data appear in the tags? Or does the player only store it in its own database?
Please check the extended tags dialogue of a file for which you entered writer and director with the plex editor

13

Thanks for the info and the offer but I don’t know what ITUNMOVI is although it looks like it’s probably something to do with Apple. I just want to be able to get info from Mp3tag to Plex. What I’m doing now is entering DIRECTOR into Mp3tag in the hope that someday the Plex metadata scraper for mp4 files will pick it up, and also adding it directly into the Plex database via the Plex editor so it will be displayed by Plex in the meantime.

14

By “in the tags” I assume you mean the metadata portion of the mp4 container. If not, let me know. I think Mp3tag must properly store the data the metadata part of the mp4 container because once I add the data via Mp3tag and save it, the data is there when I go back with Mp3tag and pull it up again. But Plex never finds the data, so the Plex scanner may not be looking in the metadata for the missing fields at all, or it could be looking in a place that’s different from the one where Florian saves them.

15

I would like you to check the other way round:
Use a file that does not show the 2 fields and enter data with the plex editor for this file.
After Plex shows the data, open the same file in MP3tag and check in MP3tag whether the data also shows up.
If not, then Plex neither reads nor writes this data but keeps it only in its database.
The second approach would be to edit all the metadata in MP3tag first and then import it into Plex as a completely new file and check which data gets displayed in Plex.

For the standardized tags there is no other place.

16

I’ll set up the test and run it tomorrow but I’m 99.44 percent sure that Plex doesn’t alter the mp4 containers in any way, ever. So info entered directly into the Plex database (as opposed to being extracted from the mp4 metadata by the Plex scanner) doesn’t end up in the mp4 metadata. And I edit mp4 metadata using Mp3tag on a regular basis and everything I enter makes it to the Plex database just fine, with the exception of CONDUCTOR (which I keep calling “DIRECTOR” because DIRECTOR is the Mp3tag label I use for the CONDUCTOR tag) and WRITER. Also if I read you correctly, you have a lot more faith in standardization than I do. There are some pretty glaring anomalies in the mapping of Mp3tag names and Plex names. The best one is the Plex tag DESCRIPTION which maps to Mp3tag PODCASTDESC (Plex does have a DESCRIPTION field, but it’s much more limited than PODCASTDESC, probably for historic reasons). Another example is the DIRECTOR/CONDUCTOR kerfuffle. Point is, standards evolve but people use workarounds, and sometimes they don’t update the workarounds when the standards change. So IMO it’s frustrating but understandable when data doesn’t map cleanly between applications, and updating or clarifying or modifying a standard doesn’t automatically update all the data that was coded before the change, so we’re effectively stuck with the workaround forever. Writer/Composer, Conductor/Director. I guess I should retest using both variations, maybe I’m using the wrong ones.

17

Please do not mix the program internal long names with the actual atoms/fields/chunks etc. to which they get written.
Even in MP3tag you can put a different label over the display of data to suit you better and it would still not alter the target.
That target is defined in the mapping table.
I mean: if plex would show the real names of the information bits it reads, you would not see Writer but ©wrt - and as a plain user, you would not know what that is supposed to be.
And that only applies to MP4 files.
If you have a mixture of different file types, then the descriptor would change as soon as you switch to the next file type - which also would probably be irritating.
We have some other examples in the forum, e.g. for VLC which does not read the standard field TBPM but only displays a user-defined field TXXX BPM (for MP3 files) - so it is really down to the implementation of the player which fields it cares to read or ignore.

I think that the standard for MPx tags has not been modified for more than a decade.

18

In Copilot’s defense, the AI was explaining to me why my experiment to use mapping to bridge the gap between Mp3tag and Plex by mapping DIRECTOR to ©dir was vacuous for the reason you stated, and therefore couldn’t work. Also I’ve been using CONDUCTOR (with the label “Director(s)” instead of DIRECTOR recently so I will try DIRECTOR again and see if it makes a difference.

19

I was referring to mapping between Mp3tag names and Plex names, not to the Mp3tag Mapping panel. As I understand it, the Mp3tag mapping panel isn’t useful for mp4 files and in any event I don’t use it.

20

That is a misunderstanding.
Due to the various file- and tag-format that MP3tag supports, the MP3tag internal names are mapped to tag-specific items. This mapping can be seen in the mapping table.
This mapping table also clearly states that the fields for which you requested support, are already supported.
To address these fields, please use the MP3tag names found in the mapping table.
E.g.

COMPOSER
Internal COMPOSER
ID3v2.3 TCOM
ID3v2.4 TCOM
MP4 ©wrt
Matroska T=30
ASF/Windows Media WM/Composer

Use %composer% to address this field in MP3tag.
When writing or reading ID3V2.3 tags, the contents can be found in the file in the section introduced with TCOM.
In MP4 tags the same contents gets the ID ©wrt.

So there is not much more that MP3tag can do if Plex refuses to read these standard fields. And whether that is the case under which circumstances would be the subject of your tests.