beetbox
LABEL metadata tag not stored in database for MP3 files
Upon importing MP3 files that have the LABEL metadata tag filled out, the database does not store the information in the tag.
FLACs work as expected.
Using the PUBLISHER metadata tag for MP3s also works as expected. I'm assuming this is a difference between ID3/Vorbis tags and how they handle non-standard tags?
Exact steps to reproduce:
- Fill in the LABEL metadata tag on an MP3 file (I use Mp3Tag or Foobar2000)
- Import using
beet import -A - Run a query for the label
- No results displayed
Beets version: 2.4.0 (docker)
As far as I know it should be called TPUB not LABEL for mp3 files. See here for idv3 specs. This is also what mediafile expects.
Are you using TPUB or LABEL?
I'm using LABEL. I'm assuming software like Mp3tag and Foobar2000 uses the TXXX frame for non-standard tags like this and adds the relevant description. Digging through mediafile it looks like the MP3ListDescStorageStyle class reads the TXXX frame like that.
Perhaps we could expand the label definition in mediafile to also read LABEL for mp3 files? Something like that seems to be already done with catalognums for example to account for different metadata tags.
Makes it easier to be consistent with tags for libraries that consist of mixed audio formats.
I think it should be no issue to add this to mediafile if it is a common problem. Can you find any documentation for this?
I found https://docs.mp3tag.de/mapping/ which does not include LABEL.
From the idv3 spec you shared above:
This frame is intended for one-string text information concerning the audiofile in a similar way to the other "T"-frames. The frame body consists of a description of the string, represented as a terminated string, followed by the actual string. There may be more than one "TXXX" frame in each tag, but only one with the same description.
So it would just be frame TXXX and the description can be anything (in this case LABEL)
Then in mediafile it should be enough to insert a line which says:
MP3ListDescStorageStyle("LABEL")
That way both the TPUB frame and the non-standard LABEL would get picked up.
I see there is sometimes reference to split_v23 in mediafile for similar non-standard tags, not sure what that does or if it's necessary for this one
I know how TXXX fields work. Im asking about docs or references because we can't just assume TXXX:LABEL is the same as TPUB. We need some precedence for it to justify the addition.
The potential missuse of the specification could be an issue here.
For instance, a user might correctly employ these fields for entirely separate purposes:
TPUB = "Simon & Schuster" # The actual, factual publisher.
TXXX:LABEL = "Gift from Sarah" # A personal, custom note.
If beets begins to treat these fields as interchangeable or synonymous, we could introduce a critical ambiguity.
You could argue this ambiguity already exists because in real life the publisher is not always the same as the label (despite the id3 specs suggesting they are interchangeable).
In addition, publisher and label are already treated interchangeably for non-id3 tags in mediafile.
If this distinction is important perhaps the solution is to have both publisher and label defined separately in mediafile?
I understand the frustration. However, unlike some other, ID3v2 has a defined standard, and TXXX:LABEL falls under custom tags without a standardized meaning. That makes it harder to justify adding unless there's tool support or a broader audience requesting it.
Do you know of any specific tools that write or rely on this tag in the same context?
If this distinction is important perhaps the solution is to have both publisher and label defined separately in mediafile?
This is not the issue. The problem is that label can mean anything here. E.g. I could label my music by mood and use this tag. I would not want beets to use it in this case.
Do you know of any specific tools that write or rely on this tag in the same context?
Mp3tag and foobar2000 will both write to TXXX:LABEL if you fill out a tag called Label. You would have to specifically fill out the Publisher tag for them to write to TPUB as far as I'm aware.
The problem is that label can mean anything here.
I disagree with this. In terms of music, label has a fairly specific meaning and is generally a lot more useful for cataloguing and library management than publisher. I think the fact that the beets database field is called $label and not $publisher is proof enough of that.
I take your overall point but my 2 cents is that while ID3 does have a standard, it's ancient and restrictive. In order to achieve consistency in a library with multiple audio formats you would have to mimic the defined T frames, even though TXXX allows for a lot more flexibility (and hence clarity). As long as the relationships are clearly documented in mediafile, why shouldn't beets take advantage of the flexibility that TXXX allows? I would hazard a guess that most people that use tagging software don't look up and follow the ID3 specs and instead fill out the fields that are useful for them since most tagging software lets you do that.
Since neither modern music players nor tagging software are restricted to the defined frames, shouldn't beets encourage a reasonable amount of flexibility here? I think the objective should be to refer to things the way they are actually called in the real world, rather than stick to a standard that isn't really enforced by any software anyway.
I think the objective should be to refer to things the way they are actually called in the real world,
As I said from the beginning I'm on your side here. You just needed to show us some references or documentation where this is mentioned. Would be no issue from our side once we have something to act on. You telling us there is usage is not enough, sorry.
I looked at mp3tag and foobar documentation and can't find any reference to this usage.
The problem is that there isn't really any documentation for this because any documentation on mp3 tagging will only ever explicitly reference the defined ID3 frames. So it ends up being a vicious circle.
For example foobar just has a page on ID3 mappings that lists the 'native' frames. In the built-in tag editor, anything outside of these native field names is added as TXXX:$FIELD for mp3s.
There are a couple of discussions about PUBLISHER/LABEL on the Mp3tag forums (here and here) that suggest both are acceptable.
I guess ultimately this requires a judgement call about deviating from a defined standard (not entirely but just for a few common tags like this that are already database fields, by the way). I understand if you're not comfortable with that but it does mean beets is beholden to a 25 year old standard that is unlikely to ever be updated.
Thanks for researching this a bit!
This comment was something I was looking for! Moved the issue to mediafile. I think we can act on that 👍
@JOJ0 you agree?
Thank you! If I may add one more into the mix with a similar issue - MEDIA vs. MEDIA TYPE. The latter is the metadata tag that has to be filled out to populate TMED (which beets expects for mp3s), which also causes similar challenges with multiple audio/tag formats.
Mediafile should ideally read both TMED and TXXX:MEDIA, which would provide more consistency between ID3 and non-ID3 tags.
I've had a quick go at making the changes myself and everything seems to be working as expected now. I wasn't sure if split_v23 is necessary for these. Apologies, I'm not too familiar with github overall so not sure what the next steps with this would be.
One thing I noticed was that tags have to be id3v2.4 for these additional tags to be picked up.
https://github.com/endcredits33/mediafile/commit/a5001b89daeaa80c5f5e1129ca21fe73c4ffffa1
Thanks for researching this a bit!
This comment was something I was looking for! Moved the issue to mediafile. I think we can act on that 👍
@JOJ0 you agree?
Yes please! Thank you both! Sorry missed the mention here.
It's often quite tricky to find out what's best with id3/mediatags stuff. I always had a similar approach - find out what others do. mp3tag/foobar2000 /puddletag are good addresses. I recall once I even reached out to Florian/mp3tag around a catalognum thing and we worked on both ends to streamline behavior between beets and mp3tag.
