Picard seems to add an Arranger tag into MP3 files after using the save button on the files. This tag does not appear in the list within Picard, but ends up in the resulting files. There is no data added to this tag, it is blank.
I believe this is a bug, but asking first if this is known.
It actually shouldnāt write the tag if it is not set. If it does this itās a bug somewhere. Looking at the tag writing code for MP3 I cannot see anything obvious, and I also could not find any related issue on https://tickets.metabrainz.org/projects/PICARD/issues/ .
Some thoughts:
Thanks for the reply. My plugins are only 4, Add cluster as release, feat artist in titles, generate cuesheet and keep tags. So a classical plugin issue is unlikely.
I will look further into this then. One thing after reading your reply that came to mind is I do not believe I checked tags prior to using Picard. I normally do not tag anything in Picard, so there could very well be a setting somewhere or even just user error that is the cause. I also need to consider, with that, that Picard does not show all tags in its view, just the ones it is programmed to showā¦ so it is possible the tag may have been preexisting and I just did not see it / know it was there. The files were a ājunkā old rip, so I just tagged as there were no existing tags of value to keep.
Oh, if it might matter, I did āremoveā a bunch of tags prior to hitting save. I doubt that is a factor, but it may be as it is a function that is otherwise not done.
EDIT: I understand I can use the āremove existing tagsā as a test, but I would never want that option since Picard does not show ALL tagsā¦ I would not know what is actually going to be removed.
Musicbrainz 2.0 beta 3 adds always an empty Arranger and Perfomer Tag, when I save changes.
I also use kid3. Kid3 shows me an empty false formatted Arranger and Perfomer Tag after I save changes with musicbrainz.
I will need to stop being lazy and use Picard for some tagging to test this all out again. But, when I read your reply here, that is the same as I get, an empty / misformatted tag.
I did a bit of looking into this issue. I still only see the Arranger tag though in my trials, but none the less, the happenings are the same. What I have found is what I believe to be a malformed metadata resulting from the Picard saveā¦ or ā¦ something in a format in which tosses Kid3 offā¦ which would mean it is not to spec in some way, in theory. No blame intended in any direction there.
Notes: In Kid3, when I try to edit data contained in āArrangerā, it will not save. I can however delete the tag with success. However, once doing so, I use the results from avprobe before and after deletion of said tag and I see no difference. As I can confirm the change was made, it appears that there is some data that is not being picked up by many meta viewers, but Kid3 is seeing it, and likely incorrectly detecting it as a tag when it is really just some data crumbs erroneous in nature.
EDIT: Using eyeD3 to query, I am able to notice that Picard adds a IPLS frame. Prior to Picard, it is not there, and after I delete the strange āArrangerā tag in Kid3, it is back to gone. I can go back-n-forth and the IPLS frame will appear and then be gone. Said frame could ex[plain the Arranger tag as it is for involved people. I would guesstimate that replacing IPLS with TIPL and/or TMCL would resolve the issue. This also could easily explain both Arranger and Performer as seen by @john-soda, since technically IPLS does map to both.
I will also run this past Urs to see if Kid3 is misreading 2.3 vs 2.4 weirdly.
I did a bit more trial and found that I can confirm that Picard is creating the issue. When I take a file as received from its source, make a copy of it, and use that copy in Picardā¦ I open Picard, load and scan the file, gets its match and click the save button, nothing moreā¦ I can see that, while viewing using exiftool, an āInvolved Peopleā empty tag appears and a warning stating ā[minor] Frame āTSOPā is not valid for this ID3 versionā. Given that the warning and empty āInvolved Peopleā tag were not there prior, Picard is the only possible place where the change could be caused.
Things to noteā¦ The reported āInvolved Peopleā frame is not reported by all tagging tools / meta viewers. Using a HEX editor, I can see that the āInvolved Peopleā frame is an IPLS frame. The TSOP, assuming we refer to Performer Sort Order, is interesting because it is a 2.4 frame while the IPLS is a 2.3 frame. This is where I believe the problem is at least tied to, and explains all of the aforementioned issues.
@outsidecontext - could you please have a look at this? I believe this is a bug as stated above and needs correcting.
I gave this a test. I can confirm that after saving with Picard and none of Picardās tags engineer, arranger, producer, djmixer or mixer is set the file will contain a completely empty IPLS (ID3 v2.3) or TIPL (ID3 v2.4) frame. When using ID3 v2.4 this is also true for TMCL (āMusician credits listā, used by Picard for instrument peformers) when you donāt set any performer in Picard.
So far I could not look into this in more detail yet, so I donāt know who is responsible for writing those empty tags. My suspicion is that it is not Picard itself but mutagen, the underlying tagging library. I will have a deeper look later and will open an issue with either Picard or Mutagen. Apart from being there these tags are completely harmless, though.
No, this is completely unrelated to the IPLS / TIPL frame issue, TSOP is something different. Picard writes it even in id3 2.3 mode because it is commonly used and understood. Depending on how you view this you can praise or blame iTunes for this.
This could very well be the case. I may have poorly worded my statementā¦when I say that Picard is where it has happened, I mean it as the fact of using Picard to save the metadata. I did not mean to imply that any certain piece of code had responsibility. Is it Picard, how Picard uses mutagen, mutagen itself, etc ā¦ I did not intend to point blame there. I am also looking at TagLib as it relates to Kid3, unsure if PIcard uses that. But it appears that the handling with TagLib and Kid3 is correct.
I can see it is unrelated, as you say. All I can say is that having a TSOP frame, as it relates to the MP3 meta, in a 2.3 version is a technical violation. This is an issue because there is also an IPLS frame written which is a 2.3 frame and to write it to a 2.4 version is a technical violation. So not matter how you look at it, if both frames are written, it is a technical violation in both directions.
It is my opinion that if a tagging tool is creating technical violation in its tagging process, that is a bug and should not be done, unless explicitly done or made to be done by the user in some manner. Kid3, eyeD3 and other quality tagging editors or viewers will point out these violations to the user, so there is no fault on the part of Kid3 here in my opinion, as the use of Picard turns a valid file into a file including technical violationā¦ which I can fix / put back by use of another tool, in this case Kid3, which will correct the technical violation.
EDIT: If others disagree and feel this is ok, that is fine, I intend no debate on it. I am just pointing out that it is incorrect to do so. So with all respect to others, as I do not really use Picard for tagging anything, my opinion for Picard on a functional level is minimal compared to the wants and needs of the users of this function.
And because of this Picard doesnāt do this (it writes TIPL frames for 2.4)
Itās not a bug then, because it is intentional to write the TSOP frame for v2.3. The original position of Picard in this matter was to not write those tags to id3 v2.3. This turned out to be a not very useful position as iTunes had decided to use those tags even for v2.3 and other players followed, so it was changed.
Of course its not at fault doing so. But if somebody actually wants to use these tags in e.g. iTunes they are well advised to just ignore Kid3ās suggestion. For the user there is no value in following this spec, the spec is for developers. And the sole purpose of such specs is to enable developers to develop compatible software, and big players making up their own things disrupt this.
So, in fairness, I guess this is closed then. I cannot comment on a response to a bug report ofā¦ there is no bug if we know and chose to do it āwrongā. Maybe, though, it should be stated that if you save tags in Picard, your files will (or may) contain technical violation(s) and you have no option to stop it as your version setting is not adhered to? If I misspeak in there, it is because I can only speak to my experience, which I fully admit is limited as I am only using Picard for tagging in order to find the issue that was reported. But at that, I can 100% reproduce it, using my same system, settings and type of files used as inputs. So obviously any change in there could cause differences in output, which a more regular Picard user for tagging would likely know better than I.
I want to add that I use, approx 95% of the time, files with original supplies metadata, and I have used MP3s for testing here with the metadata as-is from the distributor. My point is that I am not testing with anything that any other user will use, assuming the distributor is the same. And it is worth noting as MP3 and iTunes are mentionedā¦ iTunes supplies M4A container files, not MP3 files. But, you may be referring to files that iTunes the software has encoded as MP3 files, or maybe MP3 files tagged in the iTunes software. I cannot speak to that as I do not use Apple software, aside from borrowing specific libraries and such to get the AAC encoder portion.
To each their own though, and I agree it is software and hardware that does not follow the standards that cause the problems, Unfortunately for me, the softwares I use and the types of files I use, the solution is to not use Picardās save button, since Picard turns out to be (for me) one of those softwares that deviates causing issues. I am happy to help test further if there is any interest in fixing anything here, or even if my workflows might help test another aspect. Although I cannot use it, many others do.
I have to clarify a few things here:
That Picard ads empty IPLS or TIPL and TMCL frames is IMHO a bug, and I will add corresponding bug reports once I have looked into it a bit deeper. It is just an extra empty frame, so a very minor bug of āwastingā a few bytes in some cases. This is the original issue discussed here.
Of course Picard adheres to the version setting. You can change whether Picard saves an id3 v2.3 or v2.4 tag structure to your files. A lot of effort was put into Picard writing the tags in a way that is compatible with existing soft- and hardware. The way you put it it sounds like Picard will break your tags and make them incompatible, which is definitely not the case. If it is breaking anything in some software this would be a bug worth investigating.
If you are referring to Picard writing TSOP (and some other v2.4 frames) to v2.3 headers, yes, this is an intentional violation of the standard. One that makes tagged files more compatible with existing software. In the bug report I linked there was discussion of adding an option to turn this off, but it was never implemented. Probably because disabling this would effectively make the files less compatible and so far I havenāt heard about any issue that change was causing in other software.
Yes, please donāt mix this up. We are talking solely about ID3 tags here and MP4 uses a different tagging format.
I refer to the software, the iTunes music player. It can both read and write tags. And it used to be very popular (and AFAIK still is) and influential. Its use of tags had a big influence how other hard- and software started to use and interpret ID3 tags.
Now this is interesting and new to the discussion: Please let us know what issues those are! As I said before, if the files tagged with Picard cause you any trouble in other software we would like to hear about that and investigate it.
5 posts were split to a new topic: File metadata standards and Picardās implementation of these
I wanted to add this, although is is slightly off topic, but I feel it is related enough to quickly mentionā¦
One thing that would help, speaking specifically for me, is a WYSIWYG approach. One of my issues with Picard is that it does not show me the full meta section of the files, only parts of it. Maybe an alternative approach, or an additional one, would be to have a checkbox in settings where I could select a full view or a shortened view, and maybe even have an option to select what appears in the shortened view. Maybe a full selection, or a predefined set of defaults plus optional fields.
I mention this because when I really think about the issues as it relates to this post, it kind of boils down to things happening out of my awareness. When I use my tagging, whether that be Kid3, Puddletag, Mp3Tag or whichever, when I hit save, I know I am saving the frames/atoms and values I see on my screen. (Excluding the occasional bug on random things causing errors which all softwares will have and is expected).
Just a personal opinion and suggestion Maybe if it fits in with other bug reports, ideas or suggestions, it could be a solution to address multiple items.
I had promised to look into this, but until now never did. But the good news is there was a bug report for this at https://tickets.metabrainz.org/browse/PICARD-1219 and the fix for it was just merged and will be in the next Picard release.
Fixing this also uncovered some problems how Picard treated those tags a bit differently then others in regards to preserving existing data and this will be fixed as well.