Streamlined tagging with XLD: disc IDs, cue sheets and logs from CD rips

MusicBrainz Picard
,
1

Hi all,

I’ve read a few topics recently touching on this but without a definitive answer (that I saw).

I am currently in the process of ripping my CDs with XLD for macOS and saved with each rip is the cue sheet and the logs.

XLD is also kindly calculating the MB disc ID and saving it with each file as the tag ‘musicbrainz_discid’.

Is Picard going to pick up that tag (or the cue/log files) such that a better match will be found than just using the other metadata?

Thanks

1 Like
2

No, Picard currently does not use disc IDs in the tags for a disc ID lookup. But you can lookup a release by disc if you have the disc in the drive.

2 Likes
3

Thanks - but there’s no way I’m going to re-insert those CDs. It seems an oversight for Picard not to use something like a tag or cue sheet to derive more a accurate search criterion. I might create a ticket for that.

I think my description of XLD above was wrong with regard to the disc ID. I think it’s doing an Artist/Release lookup in MB and then pulling down (the first?) disc ID. Which is crazy considering it has better information with the disc it’s physically ripping.

I think the quickest thing for me to do is to write a script that calculates the disc ID from the logs and then does a lookup for that it. Then grab the release ID at add it to the files’ tags.

Am I right in saying Picard will pick up and prefer the MB release ID tag from files over all other information?

Thanks

4

Yep, that’s weird.

If the MusicBrainz Release Id and / or the MusicBrainz Recording Id are set in the tags Picard will use these to load the proper release automatically (unless you disable this in options). See the Picard Tag Mapping on how to properly set those tags depending on file format.

2 Likes
5

That’s easier said than done. A discid can be attached to several different releases.

Also, you need to consider you could be missing out on “better” releases that don’t have a discid attached to them. A matching discid is no guarantee for the overall quality of the metadata attached to that release

3 Likes
6

Yes I would need to prompt when collisions occur. But they should be the exception.

Yes that’s a good point. I’m ambivalent (in the original sense of the word) between choosing either

  • to have less information but record the correct actual release I own, and
  • to have more, correct information from a different (although similar) release

First world concerns…

1 Like
7

You seem to believe that tagging must be perfect as soon as you are finished with ripping the CD. But nothing stops you from feeding Picard with your files again whenever you want. And then you have the advantage that Picard takes the AcoustID fingerprints and is far more likely to find the correct album – and if not, you are in control to choose another release instead (or to improve the database by entering that missing release).

8

True, but re-tagging is not always benign as it often involves renaming. I guarantee you if I put my 1000-odd releases through Picard and pressed “Save” that I would have a not insignificant number of directories and files be renamed.

Which means applications that consume these files need to be refreshed. Which means other non-MB (but rather application specific) metadata gets lost because the link breaks. Kodi for example would need to have the library cleaned and re-scanned. My ratings would get lost, and albums I added years ago would now appear as recent additions. One nice thing about Plex is that the same “track” but with a renamed directory and/or filename maintains its link with its Plex metadata.

Anyway, to summarise: I’d rather my file tags remain static (and therefore just the basic MB IDs) and have my applications get new data from MB. So I’m a tag-once kind of guy.

9

You can restrict Picard not to touch certain kinds of tags. I use XLD as well, and I only type the exact album title (e.g. “Strauss: Vier letzte Lieder”) and exactly one album artist (with his/her/their album artist sort order field, of course) into the metadata fields before I hit the “rip” or “transcode” button. This way they are locked for all times and the folder structure in iTunes will never change – regardless how often I let SongKong (a substitute/supplement for Picard which does a better job with classical music and with iTunes) run over my music. Because these two tags won’t be touched ever again. (Having exactly one album artist also results in a nice and clear folder structure by the way.) SongKong also takes care of telling iTunes to refresh (only) the changed entries in its database – and it has unlimited undo-steps. So, tagging is no work at all for me, because I only have to enter album title and album artist, all the rest can wait and will be tagged automagically with Picard and/or SongKong.

10

Not if you tell Picard not to rename or move files. See the Configuration section of the documentation for more information. Of course, I’d recommend trying it with a few files to begin with, just to make sure that it isn’t doing something that you don’t expect.

11

That’s also true.

I knocked up a one-liner to calculate the discid:

perl -MDigest::SHA=sha1_base64 -e 'while(<>){if(/^\s*(\d+)\s+\|\s+[0-9:]+\s+\|\s+[0-9:]+\s+\|\s+(\d+)\s+\|\s+(\d+)\s*$/){$tt=$1;$los=$3+151;push @sos,$2+150}}$s=sprintf("%02X%02X%08X".("%08X"x99),1,$tt,$los,@sos);$s2=sha1_base64($s)."=";$s2=~tr#+/=#._-#;printf"MB discid: $s2\n";'

The full script is a bit longer as it also chooses the best MB release-id and re-tags the files.