Support a recording appearing in multiple albums

[derat]

Sometimes a single recording of a song ends up on multiple albums, e.g. https://musicbrainz.org/recording/8cc47fd7-eec3-4e2e-bcce-eba2fd37d891 and https://musicbrainz.org/recording/0ca150e4-f806-446c-b360-1f0c0077d847 (MusicBrainz lists separate recordings there, but I think they're actually the same). Artists also often release songs first as singles on Bandcamp and then re-release them in albums that contain other previously-unreleased songs.

Right now, I deal with this by merging one song into the other and deleting the MP3 and Datastore entity of the former song. I don't care much about the wasted space from storing a second MP3 of the recording, but I don't want to have two entities with separate play histories and potentially-different ratings and tags.

It'd be nice to be able to insert a placeholder song in this case so that the album with the deleted copy can still be played as intended. I haven't thought much about how this would work. Should I create a separate entity type for placeholder songs (how would queries work)? Or should I add an e.g. CanonicalSongID field to the Song struct and update clients to use it instead of SongID when reporting plays or updating ratings and tags? That feels hard too: clients would need to load the canonical song to display the placeholder's ratings or tags unless I tried to duplicate user data.

One other issue is that duplicate songs usually have different volume levels, so the AlbumGain field will be incorrect for one of the albums. (TrackGain often seems to be slightly different too.)

[derat]

Yeah, I'm not sure how this would work. User data would need to be maintained across all versions of a song so that queries based on ratings, tags, or plays would still work. It might also be weird to get multiple copies of the same song when e.g. shuffling by artist.

All versions of a song would need to share these fields:

• SHA1
• Filename
• Length
• TrackGain
• AlbumGain (as mentioned above, this will be wrong for non-canonical versions)
• PeakAmp
• Rating
• Plays
• Tags

Each version would have its own values for these fields:

• CoverFilename
• Artist
• Title
• Album
• AlbumArtist
• AlbumID
• Track
• Disc

And then there are a bunch of generated fields like ArtistLower, Keywords, RatingAtLeast*, etc. that would end up in one group or the other depending on how they're derived.

[derat]

Another (gross?) hack might be to make the unique fields/properties optionally hold multiple values. This might make queries just work (I'm not at all sure about that), but it'd probably make marshaling and unmarshaling to and from Datastore and JSON complicated.

This probably isn't worth the effort.