Why isn't the catalog number field optional?

Tags: #<Tag:0x00007fe3166da500> #<Tag:0x00007fe3166d9dd0> #<Tag:0x00007fe3166d9cb8>

I use Picard to tag my music files, and while I was going through some albums in my library, I noticed that a few had the value “[none]” in the catalog number field.

At first, I thought this was an error. I’ve seen cases where rather than using the checkbox for indicating that a release does not have a barcode, someone has entered the text “[none]” in the field instead, which seemed to me like either a legacy edit style or simply someone who saw the displayed “[none]” on a release group page elsewhere and thought that was what they should type in the field.

I began creating edits for removing these values, until I was informed in this edit, that entering the text string “[none]” as a catalog number is part of the style guidelines.

Entering the string “[none]”, from all aspects I understand, makes no sense for both the sake of database users, and the database itself. By following this standard:

  • The database has many string values which are being filled with “[none]”, rather than a simple binary value indicating whether a catalog number exists or not. Barcodes and release mediums already have this figured out, I feel like there should have been a subsequent change to how catalog numbers are handled.
  • Users, looking to retrieve data from MusicBrainz for a release, are told that the value of the catalog number is “[none]”. There is no indication that this value is a placeholder, or that it has no actual value important to the release (although it may be obvious upon observation). Picard happily applies this metadata to your music files without filtering out the fact that this is a placeholder for the absence of information.
  • It is implied that the catalog number field will always have a value, even when there is no catalog number. The catalog number field having a value is not case-specific, while for an actual release, having a catalog number is.
  • In general, more data is being stored and transferred than is necessary on behalf of the database, and it can be represented and provided in a more efficient manner.

I am aware that there is a precedent for specialized values being encased in brackets, such as the “[unknown]” artist or the label “[no label]”. However, each of these have reasons for why they deserve to fit in the MusicBrainz standard of data entry, and each have their own pages outside of the style guidelines with information on why they exist and how they are used.

The text string “[none]” in the catalog number field lacks a reason like the two examples above, ignoring the fact that using an actual string value in place of something like null to indicate a lack of information is just bad practice. Rather than a simple true/false or existence check, a user who may want to automate counting the number of releases without a catalog number, or more practically, naming folders for organizing their library in, retrieves a string that requires them to run a comparison against both “” and “[none]”.

Is there a reason the catalog number is not optional, or that it is a standard to use a placeholder? Alternatively, is there any agreement from others here for making an issue and suggesting an improvement on the Jira, something in the same style of how barcodes and release mediums are handled?

6 Likes

From the mailing lists:

4 Likes

There is a difference between a release having no catalogue number and it probably has one, but we don’t know it. There is an open ticket to have a checkbox to indicate the “no cat. no.” condition, but as long as this is not available the “[none]” entries should stay. Removing them removes actual information.

If you don’t want it in your tags you can use scripting in Picard to remove it.

$if($eq(%catalognumber%,[none]),$delete(catalognumber))
5 Likes

Interesting to see how long ago the idea of using a checkbox was already considered but dismissed because some people might not understand the checkbox.

I’m already doing this, but like I described in my second to last paragraph, this is needless overhead for anyone using the database. It is a workaround, not a solution.

Thank you for finding this, good to know that there is a chance this gets addressed, and hopefully soon.