Release credits question and big performers problem

Hello there,

I searched for a solution on these 2 topics but honestly without any success.

  1. is easy : Is there any way to acess the release credits through Picard tagger? e.g. remastering and remastered at in this release https://musicbrainz.org/release/0d099294-ec29-4d0b-821d-202a32c85a14

  2. is way trickier : I absolutely cannot have it that Picard stores the performer tags in the format PERFORMER=name (instrument). I searched for ways through plugins Standardize Performer Tags and Format Performer Tags, but the both do not change the fact that the performer is stored in the above way. What I need is PERFORMER=instrument: performer. Now if performer would be a multivalue tag this would be easy to do with scripting functions but it is not, they are all separate tags where you have to know the instrument to retrieve it. So now there would have been the possibility through Instruments plugin to get all the instruments listed, then retrieve it via $performer() and rewrite it. But there is the problem that the instruments plugin only retrieves the “blank” instruments, e.g. “percussion” but additions like “additional, solo” etc. would be lost then.
    I spent a really long time to figure that out, would be nice if someone could help me on that matter.

Thanks!

As far as I know (and I wrote the Standardise Performers plugin) Picard already stores Performer data under instrument (see the description of the Standardise Performers plugin to see this).

If you wanted to store it the other way around, i.e. PERFORMER=performer: instruments then it would not be difficult to create a new plugin to do this using Standardise Performers as a starting point.

However the TMCL tag specification does say that the index should be instrument.

Thanks for your reply. But this is the thing, this is not just the other way round, the tags are not stored at all in the form “instrument: performer” or “performer: instrument” but as “performer (instrument)”. This is exactly what activated Standardise Performer plugin does.
e.g.
comment[40]: PERFORMER=James Hetfield (electric guitar)
comment[41]: PERFORMER=Kirk Hammett (electric guitar)
comment[42]: PERFORMER=Jim McGillveray (additional percussion)
comment[43]: PERFORMER=Jason Newsted (electric bass guitar)
comment[44]: PERFORMER=Lars Ulrich (drums (drum set))
comment[45]: PERFORMER=Marianne Faithfull (background vocals)
comment[46]: PERFORMER=James Hetfield (lead vocals)

So please elaborate what you mean because I am getting confused now tbh

Edit : I had a look at your code, too, and what is provided there with : is not what is stored by Picard in the tags as you can see

Edit2 : And I think you are talking of id3 spec here, as in VORBIS comment spec this field is not used at all for “normal” music, so that is that then :slight_smile: And I honestly just need it somehow in “my” proper format so I can use it along/put it with the correct VORBIS fields

It seems that this whole problem of correctly accessing the performers would be fixed with this https://tickets.metabrainz.org/browse/PICARD-2217
@outsidecontext Can you confirm this?

Thanks

I did not get a script to do what I wanted, Picard always saved in this form “performer (instrument)”, as saved in for real in the file.
So now I used the Format Performer Tags script and then wrote another script with lower priority which essentially provided a tagging variable with all the performers in the correct form for me, at the same time deleted all performers Picard wrote and then used the tagging variable to rewrite the whole thing.
Sounds creepy but was the only way that worked and looks exactly like wanted now :
comment[75]: performer=Drums (Drum Set): Lars Ulrich
comment[76]: performer=Vocals, Lead: James Hetfield
comment[77]: performer=Electric Guitar: Kirk Hammett
comment[78]: performer=Percussion (Additional): Jim McGillveray
comment[79]: performer=Electric Bass Guitar: Jason Newsted
comment[80]: performer=Electric Guitar: James Hetfield

REMAINING :
If someone could help with question 1 that would be great. I would also be interested in getting “recorded at” and “mixed at” from the track credits somehow.

Thanks

Sorry - but I think that is how whatever tool you are using to list tags is displaying it as and NOT how it is stored in the file.

I have actually opened an MP3 file I have tagged in a text editor and I can see the pairs of IPLS strings in instrument->player format.

foobar displays the tags as stored, and this is a problem in this case because it is ugly
and we/I am not talking MP3, and not id3 spec

Well - I can assure you that the tags are not stored in the file by Picard as “Performer (instrument)” and I can be certain of this because I have looked. The ID3 spec also doesn’t store it like this, so this is Foobar interpreting the IPLS or TMPL tags and formatting it like this.

Picard follows the ID3 specification and stores them as Instrument:Performer. So you need to take this up with the Foobar folks.

Sadly the ID3 spec is completely irrelevant when a file does not use id3 tags, so for what id3 spec
We are talking of Vorbis Comments in FLAC files and this has nothing to do with foobar…not at all
The excerpts posted are not from foobar but from metaflac which is the very own tool of flac package to read flac tags/meta
foobar just reads them as what they are, as vorbis comments… and this is correct so

foobar2000 doesn’t even read IPLS or TMPL, so it’s definitely not from Picard.

a) I said I fixed it like 5 messages ago
b) This is exactly like Picard stores it in the FLAC files as Vorbis Comment, foobar does everything it has to do, namely reading the tags out there as they are, of course it ignores/does not read a spec that has nothing to do in a file type where this spec is not applicable at all, I live in a world outside of 16kHz shelves and specs associated with it. sorry, but this is not even remotely funny anymore.

And for what its worth I never mentioned that Picard does anything it should not do as it was designed, as this type of mapping to Vorbis is mentioned in the docs, but it simply does not fit my needs, and this was the only thing I was talking about from the beginning. The display of this mapping does not look nice. Talking of specifications that do not apply to FLAC is completely senseless. So I don’t understand the whole issue. It was a question of tag reformatting for the more or less very specific case of PERFORMER here. I found it out on my own, so np

Simply wrong in the case of FLAC, it stores them exactly as I told you and excerpted. And it even mentions this in the docs. You cannot store a tag/tag type that is simply not existing

Well, if you had mentioned previously that it was a Flac file, then we might have been able to know that.

I have now checked the code and there are even comments explaining how it is stored and how the tag is processed when it is read in.

Obviously as a free-form field, it can be stored in whatever way you wish, but research suggests that if there is a de-facto standard for vorbis tags then it is “name (instrument)”. There are only a few references to this, but all that I found are this way around, e.g.:

https://www.legroom.net/2009/05/09/ogg-vorbis-and-flac-comment-field-recommendations

However I did find a plugin from @rdswift that might do what you want (and I have no idea why this is not in the plugins directory)…

Well, I mentioned in my 2nd reply already, and more then one time after that that we are talking of Vorbis and not ID3, several times.

All Vorbis comments are literally free form and this is no de-facto standard. It is an excerpt of a web-page. If you want to have it displayed this way then use it, if not then you have to use another way, simple as that.

The Format Performer tags does simply also not do that, it just refomats the keywords, the format how the Vorbis tag is stored itself in terms of PERFORMER=artist (instrument), however instrument is formatted then, is in the core of Picard. And this is perfectly fine. Because there has to be one way it is stored.

If you don’t want it in that format you have to reformat it in a proper way, which I did in the end. And that is ok, too.
There is no sense in a de-facto standard in a non-standardized field as I don’t want to read/display it as it is stored.

Unless I’m misunderstanding, version 0.8.1 of the plugin is in the list of plugins in Picard and on the Picard website.

yes, it seems to be in the list, this is true though. and it is a very nice plugin

Not directly by scripting, but a plugin could at least easily make the artist available. This would set a tag mastering:

from picard.metadata import register_album_metadata_processor

def album_metadata_processor(album, metadata, release):
  for rel in release['relations']:
    if rel['target-type'] == 'artist' and rel['type'] == 'mastering':
      metadata.add('mastering', rel['artist']['name'])

register_album_metadata_processor(album_metadata_processor)

The place is more difficult, because Picard does by default not query the place relationships. So this needs an extra request, in this case fetching the place relationships for the release with a request like:

https://musicbrainz.org/ws/2/release/0d099294-ec29-4d0b-821d-202a32c85a14?inc=place-rels&fmt=json

One plugin that does such an additional request, only for artist pages, is picard-plugins/plugins/albumartist_website/albumartist_website.py at 642698acf489b0b407448e71fdc0c0adad8ed991 · metabrainz/picard-plugins · GitHub

I guess you would still need to know the instrument names for this. I mean you could be a bit more flexible and have something like $performer(/guitar/) to get all performers that match anything with guitar included, but you cannot get the exact guitar then. So this would match “performer:bass guitar” as well, but you would not know.

I think again this would best be done in a plugin where you can go over all the keys in the metadata and filter those starting with performer and rewrite them properly.

3 Likes

Thanks for the great hints, also for the remastering artist, this is information I want to really have in the files. Both seem not all too hard to do with the albumartis_website.py as a basis. I am using it already anyways.

This is actually what I did on that matter :

def add_performer_tag_tg(tagger, metadata, *args):
performer_tg = set()
for key, values in list(metadata.rawitems()):
    if not key.startswith('performer:'):
        continue
    mainkey, subkey = key.split(':', 1)
    if not subkey:
        continue
    for value in values:
        log.debug("{} Writing performer into tag {}: {}".format(PLUGIN_NAME, subkey, value))
        performer_tg.add(subkey.replace(" (", ", ").replace(")", "") + ": " + value)
    del metadata[key]
metadata["~performer_tg"] = sorted(list(performer_tg))

It worked so far with all my tests. The concept of easy plugin writing is really awesome here
Edit: In scripting I do a simple $setmulti(performer,$title(%_performer_tg%)) then

1 Like

@outsidecontext : I implemented the plugin for mastered at location now. I registered the whole thing as album_metadata_processor. Working with the json responses is really sweet. The plugin seems to work as expected, also when changing the release it gets, or deletes if there is no mastering location in the changed release, correctly.
But I have an understanding problem though. The albumartist_website.py is registered as a track_metadata_processor. It is clear why, because if you have different artists in an album there would be different websites for the artists. But it stays a track_metadata_processor, meaning from my understanding it is executed when loading from MB. So why is there a codepiece in it that changes file_metadata? At this point when you load from MB and track_metadata_processor is executed there did not even a file attachment happen. What do I not get here?
I am asking so I do not make any mistakes or wrong assumptions in future plugins I write.