#musicbrainz

hi, I don't know if this is something someone would like to fix or it doesn't matter at all, but just in case it does, I noticed a few artist_credit duplicated values in the database. Check the output of "select * from artist_credit_name where artist_credit in (1, 1033220, 1092748, 1099696, 1223975);". I guess that shouldn't happen

rodarmor: the release and recording id

for ID3 that would be TXXX:MusicBrainz Album Id and TXXX:MusicBrainz Track Id

sorry, UFID in ID3 is the recording ID

currently if there is only the release ID it will load the release and try to match the file to the track by metadata. if there is only the recording ID it will load the recording as a standalone recording

@outsidecontext What are UFIDs? Until looking at the MusicBrainz Tag Mapping page, I had never heard of UFIDs in the context of ID3 tags

rodarmor: http://picard-docs.musicbrainz.org/en/technical...

4.1 UFID Unique file identifier

Okay, I think I'm getting it now. I transcoded some FLACs to MP3s, and I'm trying to fix the tags. It looks like I need to map the `MUSICBRAINZ_TRACKID` tag (the name of the FLAC tag) to an ID3 UFID tag.

And the format of the UFID tag is `http://musicbrainz.org\u{0}MBID_TRACKID`.

So I guess you have the track ID now in a TXXX frame of that name. You could try to have a script in picard like "$set(musicbrainz_recordingid,%musicbrainz_trackid%)$unset(musicbrainz_trackid)", then run that manually on the loaded files and save them. Then load them again

@outsidecontext That makes sense.

Thanks for the help!

or rather probably MUSICBRAINZ_TRACKID (uppercase)

fwiw, I'm pretty sure if you were using beets, and used the "convert" plugin, this would all just magically work :)

it's always a bit tricky if the TXXX names start to match internal names Picard uses

I don't trust beets >_< It's too magical for me. I like to understand what's going on.

Yah, I was getting this after retagging: https://usercontent.irccloud-cdn.com/file/Syjg6...

did you have any script active already to get this? usually the duplicated labels on the left happen because there is both e.g. the musicbrainz_recordingid set (internal name, gets localized to "MusicBrainz Recording Id" on the left) and a verbatim "TXXX:MusicBrainz Recording Id"

what's magical about beets?

they're by shrute

@outsidecontext This is after I had renamed a track with my script, and retagged it with MusicBrainz. I think what's happening is that now the track has a UFID tag and a normal tag called "MusicBrainz Track Id", and this is causing Picard to show duplicate tags.

@Yaniel By default, beets will do a lot of renaming and retagging. If it gets this wrong it is hard to undo.

yes, likely. in this case a "$unset(MusicBrainz Track Id)" might help

yea, that's why I usually run it in timid mode where it asks you to confirm what it is about to do

or rather "$delete(MusicBrainz Track Id)"

it won't touch the UFID, because that would be musicbrainz_recordingid

@Yaniel I didn't know about timid mode, but that's good to know.

@outsidecontext Thanks, I'll try that@

that's what it is called for import (flag is -t), other commands also often have dry-run flags

I started using it because otherwise I'd get digital releases tagged as their CD counterparts