Let’s say I have a .csv stored locally with MBID of Album and a custom tag called Custom_Genre. Is there any way to pull that .csv in as a custom tag?
You could probably accomplish that using a custom plugin.
EDIT: I’m in the middle of another project right now, but if there’s enough interest I can take a look at coding up something for this when I get a chance. At first glance it doesn’t look like it will be too difficult.
That project better be this:
Puts hands up and shouts “me too”.
Hits the Bookmark button.
There are many times I don’t agree with other people’s opinion on Genres
Also, if a plugin could add “custom genre” it looks only a few steps away from “custom release title” or “custom track names”.
I’ve often got cases where I am over-riding the data that MB holds. For example, changing some track titles to add in extra details on the track.
Actually, it isn’t related to MusicBrainz or Picard at all.
Wouldn’t user tags and a plugin to read them be a better way to go? No need to maintain a separate file with MBIDs in it (and how would they be entered?)
So, for example, to add your own genre - just add a tag. The plugin would then only pick up the user’s own tags for the “custom genre”. For non-genre tags, some (user-configurable) format would be required to specify the metadata item to be affected.
My Classical Extras plugin already does this to pick up a user-specified ‘flag tag’ ( default is ‘use_alias’) which indicates that the primary alias for the user’s language should be used instead of the standard MB name (for works).
I had thought of setting an internal variable with the results of the wikidata plugin ie _wikidata_genre or _wikidata_artist_genre.
This would make it possible to have some priority when you have multiple plugins and be able to run something after everything is done to combine results.
Though perhaps only on topic by a slim margin, I’m still trying to figure out a way to copy tags across tracks
… Internal variables. But they don’t seem to be able to cross the line between tracks even.
Depends exactly what you are trying to do. If you are just doing it within an album, you can cycle through all the tracks in an album and then process them. But if you want to continue this conversation, I suggest another thread.
Well, at this point I’d go for between tracks in an album.
To get the value of %tag% from another track. I would imagine reading from an external file there’s going to need to be a way to pair up the particular line with the intended track too.
Pretty much all of the techniques discussed above can be found in the Classical Extras plugin, namely
- Reading and writing a file containing supplementary data
- Reading folksonomy/genre tags and differentiating those added by the user
- Caching MB metadata for an entire album and writing metadata tags based on cached data
Anyone who wants to try their hand at a plugin is welcome to re-use my (admittedly fairly inelegant) code.
Firstly, however, I think it is a good idea to have a clear vision of what the plugin will achieve. There are several ways of doing some of the things discussed above. For example, another option that occurs to me is for the plugin to generate a file with all the artists (and their MBIDs) in the user’s collection. The user could then add default genres and other data to that file, which is read by the plugin to populate metadata in tracks by each artist. This is similar to the approach I use for classical composers, where their existence in the file defines them as “classical” and their details (dates, country) are maintained in the Muso library management software.
I, for one, would rather not try to re-invent the wheel when there is a viable solution already available. It sounds like everything required is already in your Classical Extras plugin. One of these days I’m going to have to take a look at it to see what all else it can do. I’m not sure you give yourself enough credit calling it “inelegant”. If nothing else, it is certainly powerful.
I’m afraid that’s not so. I don’t think the plugin as it stands will deliver the specific requirements expressed in this thread. However, the code for the techniques I mentioned could be adapted to meet those needs. I’m not sure I want to add many more bells and whistles to the plugin itself - it probably already has more options than Picard itself.
A few pointers among the almost 9000 lines of code in the main module:
- Reading data file - see get_references_from_file(release_id, path, filename)
- Writing data file - see write_log(release_id, log_type, message, *args)
- Reading folksonomy tags etc. - see work_add_track(self, album, track, workId, tries, user_data=True)
- Caching etc. is done using dictionary attributes and a simple queue so that the module only finishes once all tracks have been read. I can’t point to a particular piece of code as the approach is embedded throughout the ExtraArtists and PartLevels classes. (In addition the processing for both classes needs to complete before the metadata is written.)