Why are so many fields required?

[Siggless]

I am trying to import music files which have many tags missing, and am trying to get around the missing_reqd_fields requirements.
I would like to write a naiive plug-in that populates missing fields with info from the file paths, but this will still not guarantee that all those required fields will be completed.
Trying to get around this, they are even marked not nullable in the database.

Why are fields like track_num and date necessary, and more to the point, why are any fields necessary?
Would it better to use a null object pattern to set any track without an album to Unknown Album, and any albums or tracks without an artist to Unknown Artist (possibly configurable)?
In cases where any other fields are left null, then these tags can just not be stored or written to the file.

[jtpavlock]

Why are fields like track_num and date necessary, and more to the point, why are any fields necessary?

I made the decision to require at the least, what I considered, the minimum fields necessary to identify a track or album. This greatly simplifies many library functions that require or expect these minimum fields to be present.

I am trying to import music files which have many tags missing, and am trying to get around the missing_reqd_fields requirements.

If you'd like to set custom values for any missing fields e.g. "unknown title", you can use the read_custom_tags hook in your plugin.

Just be aware that any track with the same disc #, track #, and album will be considered a duplicate in the database.

[Siggless]

Alright it makes sense if that is necessary for other functions. However I think the less assumptions we make about how someone organises/tags their music, the better. This makes it incompatible for existing libraries without that information already. Just considering the adding and storage, ultimately each track is pointing to one file path.

I've have been writing a plugin to try and get around this and preserve any blank tags, whilst still using the DB and duplicate detection, and it works in my cases now, but it has turned very bodgey so I'm not happy with it. I've linked it here in case anyone else if interested.

[jtpavlock]

Thanks for linking your plugin, it was interesting to see how you used the different hooks for your case. I know requiring certain fields isn't ideal for all cases, but ultimately I think reserving the library for music we can confidently identify and operate on does more good than harm.

As you have now seen, plugins can be created to handle filling in these required fields by implementing the read_custom_tags hook, whether it be by guessing from file information, acoustic ID, filling in info from an online source like musicbrainz, or through prompted manual intervention.