Try as I might, I can’t get it to fail here.
The only thing that I had to change in the settings to get it to work at all was to check Use track relationships under theMetadata section.
But it’s very weird it only happens with flac, and not with mp3 right?
Anyway, me and my pc have been on for too long, shutting down now.
If/when I can replicate this after a restart, another portable installation and different files I’ll report back.
1 Like
In fairness, I did my testing on a clean version of Picard Portable with only the Format Performer Tags plugin installed, and the only change I made to the settings was to enable Use track relationships. Perhaps there is another plugin or settings that’s working in combination to trigger your problem.
Can you tell me what other settings you’ve changed and what other plugins you have loaded, and I’ll try to reproduce the problem here? Thanks.
I narrowed it down.
It has to do with using specific unicode characters.
I have the plugin setup like this:
The culprit are the characters in section 2.
‹ and › (u+2039 and u+203a)
Using this release:
You’ll find that all goes well with mp3 files, but flac files break it.
This is only happening with my portable 2.2.2 setup, not with my installed 2.1.3 version.
1 Like
Those are not valid keys for Vorbis comments. The keys in Vorbis comments are limited to a certain range of ASCII characters. Most printable ASCII characters basically, except = which is used as the separator between key and value.
1 Like
But this was not a problem for Picard 2.1.3?
Also MusicBee, foobar2000, mp3tag all have no problems with these characters?
edit:
And I just found this:
“The data is encoded in [UTF-8], and so any conforming [Unicode] string may be used as a value.”
here:
Earlier versions of Picard would indeed show those tags, but fail when saving the file.
I haven’t checked, but I doubt it. If they indeed support writing invalid keys the files might be broken for other tools.
Vorbis comments are basically a list of “Tagname=Tag value” pairs. You can happily use whatever Unicode character you like for the value, but the keys (tag names) are restricted.
1 Like
Of course I have no doubt whatsoever you have all the facts right about all the ‘hidden’ mechanics and protocols.
And I understand that in this case the tag name ‘PERFORMER’ may not contain these UTF characters.
But are the ones I am using in this plugin not in the content fields, thus allowed?
Experiencing this as a simple end-user:
I just wrote these tags using the plugin and Picard 2.1.3:
Nothing failed, and MusicBee displays it all perfectly.
And, I have been doing this ever since this plugin was released.
Only now with 2.2.2 (portable) issues arise.
Something else must be in play here?
2 Likes
Sorry, I now see the issue: While Picard internally stores this as performer:instrument=Artist (instrument is part of the key) the instrument of course gets written to the value for Vorbis comments (PERFORMER=Artist (instrument)). The detection code for valid Vorbis names does not consider this. I will have this fixed for the next release.
EDIT: Here is the ticket:
4 Likes
Thanks for the fast fix.
I think not, but asking to be sure: should 2.3.0.dev1 contain this fix?
I have been getting some ‘red disc’ error icons.
It looks like it is related to the Format Performer Tags plugin:
Using the most recent Picard 2.3.0.dev1 release.
(the portable edition for Windows)
Please let me know if you need any more details from me?
another release that triggers a red disc error:
I haven’t forgotten you. I just haven’t had an opportunity to look into this yet.
1 Like
I just gave it a new try with the brand new Picard 2.3.0b1 release.
The issue remains.
E.g. these two releases result in ‘red disk’ error icons.
Using 0.6 as offered by Picard, using the default plugin settings.
Sorry for taking so long, but I finally got a chance to take a look at this. I found a couple of problems, and think I have it working now. Before it’s released “officially” through Picard, would you mind downloading a copy from picard-plugins/plugins/format_performer_tags/format_performer_tags.zip at 2.0_RDS_Plugins · rdswift/picard-plugins · GitHub and see if it resolves your issues? Thanks.
2 Likes
I tried it on the two releases I mentioned, and they get processed perfectly now.
There were some other releases that posed problems, but it looks like I removed the ‘problems’ folder they were in.
But I trust the issue is solved, so thanks!
1 Like
I’m wondering about an issue I am having, and if adding an additional feature to this plugin could perhaps be a viable solution.
Suppose you have performer tags present in your files.
And when running them through Picard again at a later moment, some performers details in MusicBrainz’ database were updated.
Picard will add update the information just fine, but the existing tags will also remain in your files.
This can result in having outdated performer tags in your files.
For example:
It looks like ‘bass’ was changed to ‘bass guitar’, which will result in a duplicate entry for the bass player here.
The same would happen if a performer was removed from the database because it was erroneous.
But it would remain as a tag in your file.
Would it be an idea to add an option to the plugin, something like ‘delete existing performers tags’?
Or can this already be achieved in another way that I am overlooking?
(using Picard’s ‘clear existing tags’ is not an option for me here)
3 Likes
Have a look at the $unset script function. I think will do what you want. I haven’t tried it, so if it ends up removing the new performer tags as well, then I’ll have to look at other options.
I am pretty sure $unset cannot remove tags that are present in files.
Perhaps $delete can do something here.
I’ll try some things tomorrow.
1 Like
You’re probably right. I haven’t worked with it before, so I’m not sure.
Perhaps, but I don’t think there’s any wildcard options with $delete so it isn’t the ideal solution either.
It’s beginning to look like it needs to be an addition to the plugin, triggered on a different event.
1 Like