MVNM is a valid id3 v2.4 tag for ‘movement name’.
But when set to use id3 2.4, Picard will write a TXXX tag.
Could that be corrected for a next Picard version?
1 Like
Can’t promise. There had already been some discussion for this in PICARD-1043, looks like it stalled somewhere. I haven’t looked into the details myself.
2 Likes
Looking at the discussions on the ticket I think that got a bit out-of-hand. All the original reporter of the ticket wanted is to be able to write those tags to MP3, but the discussion digressed into various arguments about storing multi-level works, storing works at all, usage of GRP1 vs. TIT1 and other.
My proposal would be to focus this back to add support for the following tags:
| Internal name | ID3 | MP4 |
|---|---|---|
| movement | MVNM | ©mvn |
| movementnumber | MVIN | ©mvi |
| movementtotal | MVIN | ©mvc |
| showmovement | shwm |
Filling those tags will not be done by Picard, rather they are provided for scripting and plugin usage.
@MetaTunes Calling you in as your plugin probably is the primary target of this. Would this make sense for your plugin and your user’s use cases? What about shwm? Not sure how this works, what to name it and if it needs to be supported.
4 Likes
Classical Extras sets tags for movement details as follows:
a) “Tags for(computed) movement number”. This is not necessarily the embedded movt/part number, but is the sequence number of the movement within its parent work on the current release.
b) “Tags for Movement - excluding embedded movt/part numbers”. As below, but without the movement part/number prefix (if applicable)
c) “Tags for Movement - including embedded movt/part numbers”. This tag(s) will contain the full lowest-level part name extracted from the lowest-level work name, according to the chosen tagging style.
These are written to hidden variables, not tags, but are given names by the user in the options panel.The default names for these are:
a) movement_no
b) (none given)
c) movement
I can always change the defaults.
No variable or tag is written for movementtotal
Frankly I am not a fan of the movementnumber/movementtotal approach - I prefer to use the details as given in MB (i.e. c) which may be more than a simple arabic numeral.
CE also writes a tag “show work movement” (which is not directly modifiable but could be mapped by the user to something else in the tag-mapping panel).
See the extract from the readme below which describes the current work-round that is required:
Note for iTunes users: iTunes and Picard do not work well together. iTunes can display work and movement for m4a(mp4) files, but Picard does not write the movement tag. To work round this, write the movement to the “subtitle” tag assuming that is not otherwise used, and use a simple Mp3tag action to convert it to MOVEMENTNAME before importing to iTunes. If you are writing to a FLAC file which will subsequently be converted to m4a then different tag names may be required; e.g. using dBpoweramp, write the movement to “movement name”. In both cases use “work” for the work. To store the top_work, use “grouping” if writing directly to m4a, but “style” if writing to FLAC followed by dBpoweramp conversion. You can put multiple tags into the boxes described above so that your options are multi-purpose. N.B. if work tags are specified and the work has at least one level (i.e. at least work: movement), then the tag “show work movement” will be set to 1. This is used by iTunes to trigger the hierarchical display and should work both directly with m4a files and indirectly via files which are subsequently converted.
Hope that helps! Obviously, removing the need for work-rounds would be great!
3 Likes
Thanks for these details. I think it makes sense to introduce something like showworkmovement which will be stored to MP4 only as shwm. I still don’t fully understand what different display exactly this triggers in iTunes, but it looks like a user choice some people will want to make for some files. So having this available for scripting makes sense.
Regarding the naming I would like to stick what I had proposed, because it is consistent with other internal tag names Picard uses, and that’s also what initially was used in PICARD-1043 .
I think with these changes it might be almost possible to use the Classical Extras plugin and have the tags written to the files in a way that is compatible with iTunes without requiring additional tools. Maybe what’s missing is support for the @wrk tag for MP4.
How is the preferred way to store works for iTunes? As I understand people make use of the “Work name”, “Grouping” and “Movement” fields in iTunes. Where would they store the top_work provided by your plugin, in “Work name” or “Grouping”? And how comes the suggestion to use style for FLAC?
I am aware that I am starting similar broad discussions that I criticized above to be the reason why this ticket never got resolved. But I have the intention to tackle the core ticket we are discussing about with a rather simple pull request as outlined above. I just want to understand some surrounding details to get a broader picture.
I think just using work for the work name works in iTunes 
I would put top_work into grouping for cataloguing purposes.
I suggest style only if you are using dBpoweramp to convert FLAC to mp4, as (for reasons lost on me) dBpoweramp seems to translate style->grouping.
EDIT: BTW I think writing “show work movement” with the spaces works for iTunes, but showworkmovement does not. It’s a while since I checked any of this out though (not an iTunes fan).
1 Like
This reply is not to be taken as an ingredient for discussion, nor does it contain any relevant suggestions.
It’s just that I appreciate that my request is taken into consideration, and I didn’t want to stay mute after the inquiry about the usage of ‘movements’ in classical music.
I’m not an iTunes user, and I believe that even though the idea of trying to accommodate for classical music and possible levels of compositions is nice, it’s ‘movement’ implementation is far too simplistic and imperfect to work well if you dive deeper into managing classical music.
The only reason I am using (and requesting) the MVNM tag, is that I have a rather complicated scheme with scripts and formulas, and I misuse the ‘movement’ tag as some sort of placeholder for that scheme.
If it’s written as TXXX/ instead of MVNM, it is unnecessarily complicating stuff for me.
1 Like
Not to confuse this thread (and it’s readers) too much, that’s not about MVNM (movement name), but about ‘show movement’.
For this, MusicBee, and I believe also foobar2000 and MP3Tag use ‘showmovement’.
I have no idea about iTunes.
1 Like
Add me to that list, I’m neither using nor liking iTunes. We three seem to be the perfect team discussing how this will be used by iTunes 
Unfortunately you cannot keep it out of the discussion, because Apple invented those non-standard ID3 tags (and their MP4 counterparts) for iTunes. Anyway, I will test this with iTunes. The only thing I really want to make sure is that whatever mapping we come up for ID3 is consistent with what we use for MP4.
2 Likes
Yeah, this is what I was asking for when I made the original ticket. I have a script that uses the recommended work format to split apart movement name, number, etc.
2 Likes
Working on getting this added. But so far nobody mentioned the obvious solution for you, that should also work with existing Picard. You can use the special _id3: syntax like follows:
$set(_id3:MVNM,The Movement Name)
$set(_id3:MVIN,2/8)
Possible that this did not work when you reported the issue, because it requires a Mutagen version supporting these tags (1.37 or later). But as of today this should work.
2 Likes
I submitted the code changes for review
3 Likes
A post was split to a new topic: Best way to determine movement numbers