I would argue the primary purpose is to be able to list compilations separately from one-artist albums and avoid them being broken up by the database into 20 one-artist albums with 1 track, not to hide its artists.
So someone uses ‘/’ as a separator, someone else uses ‘:’ and why stop there.
Especially dangerous with artists like AC/DC . By the way, there is a standard defined in id3v2.4:
All text information frames supports multiple strings,
stored as a null separated list, where null is reperesented by the termination
code for the charater encoding.
Likewise, there’s no way I want all the artists of odd singles I have to be mixed up with all the artists whose albums I have.
But this personal viewing/filtering preference of which artists you want to see or not is something you should normally do on the GUI/client/query level, not upstream in the scanner/DB level.
I think for a music DB, the preferred setup is to have all group/person entities (be they album artist, artist, composer, producer, lyricist, arranger, remixer of coffee boy) in one Artist table, and have artist pages where you have filter/subsections by role. This is how Discogs, RYM and even libraries like Emby do it, and has been suggested for Plex a while ago by @beckfield in this post Tag support for ROBUST music library organization - #44 by beckfield
making use of the Compilation tag could also be nice to have, but since it can mean 2 rather different things, its use is somewhat ambiguous so it’s actually not as useful as you seem to think
On its own, no. In combination with Album Artist (empty for V/A comps, filled in for one-artist compilations), it’s completely unambiguous.
They should have used database designers to define what was required and how, instead of kids just thinking in flat file terms, but that’s too late now.
I don’t think the problem is that they are db designers, but not record collectors - and they fail to realise that their limited assumption of what an album is (“it has a year, an artist, a genre”), isn’t so strict. So it goes: Build support for albums in your library, testing with your ten-album collection, yes it works, release! But oh wait - here’s an album with tracks from different years! And the album might have tracks with different genres! Artist can be a multivariant field! Never thought that could happen. But changing it on the db level means rebuilding all queries and UIs on the client side. Way too much work, let’s just not do it. I’ve seen this happen with a lot of music db’s, these considerations pop up too late in the development process, when the db engineers have already done their design, and their assumptions clash with the real world.
An EP is an Album, just with fewer tracks.
That’s a tricky assumption - there are EP’s with 20 tracks or 70 minutes, and albums with just one track or less than 20 minutes. Even some remarkably long singles…
From a database point of view, they are the same thing. Even a single is technically the same, just with 2 tracks.
Digital singles are usually one track these days, so that’s another tricky generalisation. With a release with track numbering 1/1 you can have either a single on your hands, an EP or an album. Or even a V/A compilation, if you have DJ mixes mastered as 1 track.
This is why an explicit Release Type field is so sorely missed, since you cannot infer it from any other field: not length, not numbers of tracks.
You can (ab?)use the Grouping (TGRP) tag for it, which works well in eg iTunes or foobar2k, but Plex doesn’t support it. I’ve seen the Grouping being used for lots of things in the wild: record label, country, release type, etc, and I guess that was the idea, to have a freeform tag that people can use for whatever info. I think it’s messy, but it’s better than nothing. Plex actually has something like this in its internal database, “Collections”.
My suggestion to allow the user to enter multiple strings (and descriptions) to be used as VARIOUS ARTISTS equivalents would not only completely solve that issue for me, but also for you as you could continue to leave AA blank and indeed, solve it for everyone…
I would be perfectly happy with that. However, this requires changes in the code of the new Plex Music scanner, and the Plex devs might be hesitant to throw more options into the already pretty crowded UI.
Just to be clear about the Plex database, they are absolutely correct to attach some tag data to the album and some to the track. That accurately represents reality. However, they don’t seem to have all the right metadata at each level and some tags/fields need to be at both levels, usually not with the same data. So there’s still work to be done there.
I fully agree - there’s a bit of a fundamental issue that local metadata is stored on track level, and need to be rolled up to Album and Artist level, which then has to be reconciled with with the matching process against Allmusic, MusicBrainz, who mainly have their metadata on the Album and Artist level.
Once we get that sorted, then maybe we can push for improved database structure.
It would help a lot, that’s for sure. The DB structure isn’t that bad at all, it’s just not populated fully.
For example:
- Genre and Year can already be stored on the track level in the current Plex database design - the “Plex Music” scanner just doesn’t populate these fields, and even if you populate them manually, Plex only uses album-level data towards the clients/API.
- There is a flag for Compilation in the internal Plex DB. The scanner doesn’t simply read it from the tags, it tries to figure this out based on a fuzzy combination of filename/folders and Artist, Album Artist and Album Title tags
- Artists are scanned and stored on the track level, but only Album Artists get included in search, and compilation tracks are not visible on the Artist page. So here, the scanner puts the data there, but the client-side queries don’t include it.
- Multivariate fields on the track level: Artist, Genre
The things I expect can be added easily, since they are in the MusicBrainz DB and integrating more with that is where Plex is heading:
- Release Type (album level)
- Language (track level)
- Country (album level)
Fields that are in id3v2 and iTunes, but Plex has never felt it needed to include:
- Work/Movement (for classical music)
TIT2andTIT3 - Composer
TCOM
