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
xtim_41 has quit
sublim20 joined the channel
SothoTalKer joined the channel
sublim20 has quit
JoeLlama joined the channel
JoeLlama has quit
CatQuest has quit
CatQuest joined the channel
sublim20 joined the channel
Lotheric_ is now known as Lotheric
d4rkie joined the channel
vesper11 joined the channel
D4RK-PH0ENiX has quit
rodarmor joined the channel
rodarmor
What MP3 tags does Picard use to recognize MP3s that have already been tagged?
outsidecontext
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
rodarmor
@outsidecontext What are UFIDs? Until looking at the MusicBrainz Tag Mapping page, I had never heard of UFIDs in the context of ID3 tags
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`.
outsidecontext
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
rodarmor
@outsidecontext That makes sense.
Thanks for the help!
outsidecontext
or rather probably MUSICBRAINZ_TRACKID (uppercase)
darwin
fwiw, I'm pretty sure if you were using beets, and used the "convert" plugin, this would all just magically work :)
outsidecontext
it's always a bit tricky if the TXXX names start to match internal names Picard uses
rodarmor
I don't trust beets >_< It's too magical for me. I like to understand what's going on.
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"
Lo_Fidelity joined the channel
Yaniel
what's magical about beets?
Lo_Fidelity
they're by shrute
rodarmor
@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.
outsidecontext
yes, likely. in this case a "$unset(MusicBrainz Track Id)" might help
Yaniel
yea, that's why I usually run it in timid mode where it asks you to confirm what it is about to do
outsidecontext
or rather "$delete(MusicBrainz Track Id)"
it won't touch the UFID, because that would be musicbrainz_recordingid
rodarmor
@Yaniel I didn't know about timid mode, but that's good to know.
@outsidecontext Thanks, I'll try that@
Yaniel
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