Perhaps these are reasonable tags to establish as standards for the composition-work:

• COMPOSITION
• MUSICBRAINZ_COMPOSITION_WORKID

That leaves WORK and MUSICBRAINZ_WORKID for use for multilevel works.

In the meantime (until standardized composition-work tags are established), I'm using the following script with the workandmovement 1.1 plugin to preserve simple work info:

$set(work,$if2($get(work),$get(_recording_work)))
$set(musicbrainz_workid,$if2($get(musicbrainz_workid),$get(_recording_workid)))

@Robo Tardis: This got discussed these days on IRC. https://github.com/metabrainz/picard-plugins/pull/337 will make the original values for work and work ID available as variables, so you can use scripting to make use of these as you wish. For details please see the comment on the pull request.

So I recently noticed that my "Work" tags are getting cleared by picard, and tracked it down to the Work & Movement plugin.  I had expected the plugin to add more work info, not delete work info that was already in my tags.

If Work is only for multilevel works, then where does picard save MB Work (Recording Of) info? From the above it sounds like maybe it should be in some sort of "Composition" tag, but I don't see any tags with that info in picard if the "Work & Movement" plugin is enabled.

See https://github.com/metabrainz/picard-plugins/pull/184 for a proposed plugin

F***, sorry. It is "SCRIPT", repeating "SCRIPT", all uppercase Sorry for adding to the confusion, I sneakily updated my previous post.

Please confirm in Picard it is still using Script not SCRIPT ?

Yes, in my plan this includes clearing the work if it does not qualify as a multi-level work. Actually the plugin I mentioned for step 3 already does this, and my plan would be to tweak and extend this plugin until the results are satisfying enough to integrate it into Picard.

Rgearding the casing issues: Yes, we always had it as "SCRIPT", I think this misunderstanding was caused by some documentation error (probably by me ). For works I think we have an issue here, and yes, I would like to change this if possible.

Okay great so 3 is a good step, and I hope that 4 includes clear the work if it does not qualify as a multi-level work, that is amy main bugbear with the current way it works.

(Also offtopic, but I  noticed for ID3 that you add Script field but do it as SCRIPT whereas I add as Script, not sure why I have this difference did you used to have it as Script or if you have only ever had it as SCRIPT, I will modify SongKong/Jaikzo to use SCRIPT because that is better. Related to this I feel it would be better if Picard moved form using Work to WORK for ID3)

yes, discussions can sometimes get a bit difficult around those topics.

So my current approach to a solution:

1. Extend Picard so one can actually use and save the tags work, movement, movementnumber, movementtotal to at least capture the iTunes / MusicBee use case (users might still need a more sophisticated structure, but they can use scripting for this and need a more flexible player). This part is mostly ready for next release.
2. Document how to configure the Classical Extras plugin to use these tags, also hopefully set the default configuration for it accordingly
3. Release a more simple plugin, which will fill work and movement from MB data and clear the work if it does not qualify as a multi-level work. I have a prototype ready for this. I see this as an easier solution for users who don't need the flexibility of Classical Extras, but also as a research tool to figure out what is possible and how we could integrate this into Picard.
4. In a future release integrate populating movement and work functionality directly into Picard

P.S.: I will update the mapping sheet in the next days with the new tags.

heh, okay I misunderstood what you meant in that line, but I fully agree with 'More correct would be to say that Picard is dangerously ignorant about the contents of this field and writes whatever it finds as the directly associated "Work". Could be a movement, could be not' although I fear if I had said that on the forums I would have been shot down in flames !

Okay so we both understand the problem, I'm unclear what your solution is ?

You are mixing things up again. What you quoted from me was really a comment about how tags get mapped.

So in Picard we have a work tag, and we will map it so that it shows up in the corresponding work fields of players. Also there will be a movement tag, that gets stored so that it shows up in the movement fields of players. This is the technical prerequisite to allow users to tag this data accordingly. And these are separate tickets.

This ticket here, and what you are talking about, is where this data gets sourced from. Now saying Picard treats it as a movement field is essentially wrong, because it doesn't. More correct would be to say that Picard is dangerously ignorant about the contents of this field and writes whatever it finds as the directly associated "Work". Could be a movement, could be not (e.g. https://musicbrainz.org/recording/61309059-1758-40d6-bf1b-52dedbd7b62b is directly linked to a work).

There is a Picard plugin called Classical Extras that can actually fill this data, but so far cannot place them in the appropriate tags because Picard doesn't support them (so the author recommends writing them to custom tags and using other tag editors to clean it up). With the next release this should change.

Also we can improve the situation in Picard by optionally making use of additional work attributes provided by MB and use some heuristics (e.g. name parsing of the movement) to be able to fill this. I have a couple of ideas I would like to explore with a plugin.

Regarding ©wrk things got clear, it is treated by iTunes really like TIT1 in ID3.  by other players like MusicBee it is interpreted like the work field we store in other formats.

I was responing to the line above, I mean how this data gets filled, i.e. doesnt MusicBee treat @wrk as a work that encompasses movements in a classical context, where as Picard treats essentially it as a movement in classical context.and also adds for non-classical as a simple work of song, most players don't understand this second context.

I am not sure whether you mean how the data get filled (this ticket) or how the "work" tag gets mapped to tagging formats (other tickets). Main problem here is that this got mixed up in all these discussions. So evidence for what exactly?

Sorry do you have evidence for this I dont think work is treated by other players the same way as used in MusicBrainz.

i.e Isnt work is treated as the encompassing work, a work containing movements, whereas MusicBrainz treats it as a movement,  in VorbisComments tools have generally used PART to indicate a movement, and have considered the presence of WORK to indicate a classical release.

I mixed point 2. up above, what I meant is the option to query the hierarchy and not save to work tag if only one level is found. I just would not do this per default, as it requires another set of requests.

Regarding ©wrk things got clear, it is treated by iTunes really like TIT1 in ID3.  by other players like MusicBee it is interpreted like the work field we store in other formats.

I would actually leave it as is for now as the general case. I don't see any harm done if the work tag is saved for cases with only a single level work. But I could see two cases:

1. Leave it up to plugins (such as Classical Extras) to provide a more sophisticated population of the work tag
2. Add an option to Picard like "use top level work", which will always go up the hierarchy and use the top-most names for work (and again leave more sophisticated options to plugins).

Btw, what about using the @wrk tag for MP4, what does this expect? In iTunes is @wrk the same as TIT1 is for MP3? How does iTunes deal with the work tag for FLAC and other formats?

Yes - this is the case. And it's not great. But that's what happens when you try to provide compatibility with other tools that don't think about other people's use of tags and terminology before deciding what to do.

If we were doing this without regard to iTunes Movements then we would probably create a field (which might even be called Composition) that would hold the top-level work(s).

But to do that now (and use TXXX tags to hold the data) would not be a good idea - and counter to the stated purpose of this ticket.

Just one more point we are tagging recordings here, so the fields values are relative to the field, i.e the artist is the artist for the song, the trackno is the trackno of the song etc.But with what you are proposing with the work field it sometimes it means 'this recording is a recording of this work' (what Picard currenlty does) and sometimes it means 'this recording is a recording of part of this work' (when you have work and movement) so the meaning of the work field is different depending upon other fields (whether movement field has a value). I don't think there are any other fields that have this strange double meaning which can only be determined by looking at other fields.

It doesn't seem I'm able to convince you but at least I think you understand my reasoning now,

The issue of the WORK field being wrong IMO is an issue in itself regardless of whether you implement movement/nos so deserves its own ticket.

But it is a Work as far as Musicbrainz is concerned, and possibly it may have been Musicbrainz that first defined the Work field.

Sorry - but I just don't agree.with this proposal for the logical reasons I have stated.

P.S. I think that this discussion would have been better held in PICARD-1043 as it is about the shape of the functionality proposed by PICARD-1043.

Let me rephrase this then "So to reiterate I'm not saying dont use Work/Movement, I'm saying only use Work/Movement terminology when it actually is a Work and Movement when there is not a movement DO NOT use the Work field either since this is not a work in the generally accepted meaning only within MusicBrainz community"

"So to reiterate I'm not saying dont use Work/Movement, Im saying only use Work/Movement terminology when it actually is a Work and Movement"

Which is exactly what this PR does. When it is not a Work and Movement it only uses Work terminology (so as to remain backwardly compatible with previous versions of Picard).

Some clarification need here. I not saying WORK and MOVEMENT should not be used I'm saying they should be only used when a work is part of a larger work, as expected in much classical music. Additionally there is a a need to store a work directly connected to a recording regardless of what type of work it is but because use of this is very much MusicBrainz specific it should be stored in a MUSICBRAINZ_ field so it doesn't interfere with non MusicBrainz apps. Since there can be a x part of relationships rather than just one or two I devised a naming system in https://docs.google.com/spreadsheets/d/1afugW3R1FRDN-mwt5SQLY4R7aLAu3RqzjN3pR1497Ok/edit#gid=0 to allow you to store the directly linked work, the top level work and all the works in between. The WORK/COMPOSITION idea was selected because it makes sense when the directly linked work is a movment and when it is not. Please note i did discuss this in July 2016 to try and get consensus (which precedes iTunes implmentation) https://community.metabrainz.org/t/how-to-explain-works/89790 but at the time there was limited interest from the MusicBrainz community.

So to reiterate I'm not saying dont use Work/Movement, Im saying only use Work/Movement terminology when it actually is a Work and Movement

So in the case of a Work and Movement Jaikzo/SongKogn writes to
WORK
MOVEMENT
MOVEMENT_NO
MOVEMENT_TOTAL
MUSICBRAINZ_WORK_COMPOSITION_ID
MUSICBRAINZ_WORK_COMPOSITION (same value as MOVEMENT)
MUSICBRAINZ_WORK_ID
MUSICBRAINZ_WORK (same value as WORK)

in the case of a recording being linked to a WORK, but that work not being part of anything else then I only write

MUSICBRAINZ_WORK_COMPOSITION_ID
MUSICBRAINZ_WORK_COMPOSITION (same value as the WORK)
MUSICBRAINZ_WORK_ID
MUSICBRAINZ_WORK (same value as the WORK)

This means we always store these musicbrainz work relationships but they dont affect the world view (i.e Itunes) of Work/Movement.

Regarding variable names, variables starting with "musicbrainz" are typically indicative of MBIDs, so I do not think we should go with MUSICBRAINZ_WORK_COMPOSITION instead of "Movement Name" or "Composition".

 Note: AFAICT, SongKong / Jaikoz use MUSICBRAINZ WORK because they use "©wrk" in mp4 files and we use a text field (and presumably Paul doesn't want to have the complexity of handling the merging of their and our work fields). This is probably an error on our part (because Mutagen does not explicitly support "©wrk" - but apparently it will work as a default text field), and I will submit a separate PR to address this once PR #676 is finished.

See also discussion in https://github.com/metabrainz/picard/pull/676.

I accept Paul Taylor's point that the way Picard has used Work for several years is now at odds with the way iTunes has recently introduced Work for classical music.

iTunes differs from Picard in terminology as it appears to use "work" and "movement" only for classical pieces and using "song" (which I think is track title) for other tracks (using a checkbox in their UI to decide which to use). So Work is really an alternative to track title, and Movement equivalent to track sub-title. Two recordings of the same piece of music can be named entirely differently because they are not linked by a work database record like MB. 

MB on the other hand has an entirely different concept for Work, and pop songs can have works too, so we need to be true to our own concept of Work whilst supporting the concept of recording work and overall work and trying to be as compatible with media players first, then iTunes and then other tools like Jaikoz / SongKong / MusicBee / MediaMonkey etc.

Assuming we have separate fields for the recording work and the overall work, then there are really two separate issues here:

a. What simple terminology should we use for the overall work and the recording work? iTunes has proposed Work/Movement and in the solution for PICARD-1043 I am continuing to use this. Paul T is proposing Work/Composition - and I have no real problems with this except I can see no reason why we should not use the iTunes "Movement" and whilst "Work/Movement" implies a hierarchy "Composition" does not suggest any position in the hierarchy as both the recording work and overall work are compositions.

My vote is therefore to continue to use Movement, though changing terminology before PR #676 is merged is not a major issue.

b. How should we use these tags when the recording work is NOT part of an overall work? Do we populate one tag, the other tag or both with this one work? Paul T is proposing that we populate both as standard and then change Work to the container work if the recording work is part of something bigger.

Again this is easy to change in PR #676 if this is agreed as the way forward, however I am unclear what the benefit is of duplicating data for every track. If we leave PR#676 as it currently is to populate Movement only if the recording work is part of a bigger work, then the user can easily make it do as Paul T is suggesting by a tagger script as follows:

$if($eq(%movementname%,),$copy(movementname,work)$copy(musicbrainz_movementid,musicbrainz_workid))

It would of course be just as easy to blank out these if we populated both, but then the PR would introduce a change to the default behaviour.