The ‘Original album/movie/show title’ frame is intended for the title
of the original recording (or source of sound), if for example the
music in the file should be a cover of a previously released song.
whereas TIT1 is defined as:
The ‘Content group description’ frame is used if the sound belongs to
a larger category of sounds/music. For example, classical music is
often sorted in different musical sections (e.g. “Piano Concerto”,
“Weather - Hurricane”).
Now I know TIT1 is typically used for a type of genre grouping so I am not suggesting you should be writing to TIT1 but it is clear the ID3 spec didn’t mean you to use TOAL either. Would make much sense to use TXXX:WORK since you use WORK for other audio formats. FWIW Jaikoz/SongKong also use TXXX:WORK although we only use it for Classical works rather than any work as that works better for our users, we have a separate field MUSICBRAINZ_WORK_COMPOSITION for any recording that is linked to a MusicBrainz work
Actually the documentation is wrong, Picard uses TXXX:Work. This change was made at some point, but AFAIK was reverted before it got released. Unfortunately it made it into the changelog anyway and even the documentation.
There is not such thing as “TXXX/Work” (or you can use this notation if you want, but so far I have seen the colon notation mostly). A TXXX frame is for user defined data, it’s contents are a “description” and the actual tag content. So “TXXX:Work” just says it uses a TXXX frame with the description “Work”. Picard will use the description as the tag name only, anyway. So you just tell Picard to save “Work” and it will save to a “TXXX:Work” frame. If you tell it to store “TXXX/Work” it will just do that, a TXXX frame with value “TXXX/Work” (which in above notation will be TXXX:TXXX/Work).
Minor point I use TXXX:WORK rather than TXXX:Work simply because I find that tools such as DbPoweramp Transcoder and MinimServer UPnP expect the same value to be used for different formats otherwise things gets broken. But I don’t suppose you can/would want to change it at this point.
@sam1912 has submitted https://github.com/metabrainz/picard/pull/666 which switches TXXX:Work to TOAL. This has been approved, in which case if you disagree then you need to make your case for this to be rejected in comments on this PR. It would not be difficult to add basic load and save support for TOAL to my TOPE PR.
MusicBee also uses TXXX:WORK, and incorporates it into special tagging and title formatting for classical music. It has a separate, unrelated TOAL field for original album/title.
Two points: Use of TXXX:Work instead of TXXX:WORK is a problem since ID3 tags are case sensitive so you if used Picard and MusicBee or SongKong then you could end up with TXXX:WORK values and TXXX:Work values, it wouldn’t really be an issue for Flac (though use use WORK anyway) since tags are case insensitive so the later app should overwrite the earlier tag. Also any applications that do not consider TXXX fields in a case-sensitive way could have undefined behaviour if a file contains both a TXXX:Work and a TXXX:WORK field.
Secondly:I think this is more an issue for Work that it might be for other fields since the way MusicBrainz defines a work is rather at odds with how users consider tend to use a work. Consider iTunes for example their work and movement fields are clearly considering a work to contain multiple movements and is aimed at ‘classical’ music.Users who are interested in a work field for the purposes of tagging use them for grouping movement in works. They are not interested in Pop songs that have a part of relationship to a work that is not part of a larger work. I would ask Picard developers to consider using the same field that Songkong does for MusicBrainz works rather than using the WORK field. I struggled to find good name but SongKong uses MUSICBRAINZ_WORK_COMPOSITION for the work that recording is directly linked to and MUSICBRAINZ_WORK for the top level work that you end up with after traversing PART_OF relationships from the MUSICBRAINZ_WORK_COMPOSITION to another Work, and so on. If a recording is linked to just one level of work then MUSICBRAINZ_WORK_COMPOSITION and MUSICBRAINZ_WORK have same value.
I don’t get your reasoning why we need completely different tags than just Work, but the casing issue is important of course. Best file a ticket for Picard.
Because Picard is using WORK in a different way to how everyone else is using WORK. The general concept as used by ITunes, ID3, MinimSever, MusicBee, MediaMonkey, SongKong is that a WORK contains multiple MOVEMENTS, so the encompassing work goes into WORK and the movement represented by the recording goes into MOVEMENT. But Picard is using WORK to either represent a MOVEMENT when that movement is part of a Work, it only represents a WORK when the recording is linked to a WORK without any subparts, not something outside of the MusicBrainz sphere many users tagging their files would even consider a work.