Track artist, single artist or multiple?

[ZenithDK]

Can a track have multiple artists? It is just listed as a string now, but should it only ever be one artist or are multiple allowed? For instance: Placido Domingo and the other two guys from the Three Tenors, just to give an example, or should they be listed as "The Three Tenors"?

[canpolat]

I was thinking about this as well. publisher, album artist and composer can also have multiple values (perhaps there are others).

[sampsyo]

Interesting point. If we do allow multi-valued options, it would be good to come up with some principled way of deciding this (rather than choosing per-field). For example, one easy-to-follow policy would be to say that all string-valued fields should instead be lists of string—or that they can be lists of strings, and that "foo" is equivalent to ["foo"] (one string is a shorthand for a single-element list).

What do folks think about applying this as a blanket policy rather than a per-field one?

[canpolat]

What do folks think about applying this as a blanket policy rather than a per-field one?

I agree :)

[andrewrk]

I'd just like to throw in that I always want fields to have the same type. So if there is an artist field, and there can be more than one artist, then it should be ["artist name"] instead of "artist name" even when there is only one artist. Some people think this is more tedious to code against; I think that it actually results in cleaner and less brittle code.

[ZenithDK]

I'm all for the multiple artists (and composer etc) per field. As for always represnting them as the same type I don't have enough experience to say what is right, but I see your point @andrewrk - I'm in favor.

[sampsyo]

Yes, absolutely—there's a benefit to avoiding code that needs to check the type of the value.

Taking that to the extreme, we could consider making every field a list—which seems like overkill for fields like track where only one value would ever be reasonable. But it would mean that:

• Clients wouldn't need to decide based on the field whether to index the list.
• We wouldn't be stuck with the decision about which fields deserve multiple values and which don't. If we ever dream up a reason for a field that was previously single-valued to become multi-valued, there would be no compatibility headaches.

[andrewrk]

I don't think it makes sense to have track title be a list. What would that mean if there was more than one track title? Someone implementing the aura API might think to themselves "track title is an array even though it's really just one value and that doesn't make sense. Looks like all the fields are like that." then their code only looks at index 0 of the array for all the fields, so they don't realize that artist name is special and truly does have the potential to be more than one.

[Afterster]

I agree with Andrew, it doesn't make sense to have all fields as a list. Some fields are and will never be multiple, it could only result to a leak of understanding.

[sampsyo]

Points well taken about not going overboard with list-valued fields.

If we do choose "string array" (JSON parlance) as the type for some fields, we should (a) think very carefully about which should be which and (b) err on the side of listiness, since this will be hard to go single-to-multiple later, but a single-element list is easy to do.

Examples of fields that should probably be arrays include: artist, albumartist, genre, composer. Anything else come to mind?

I'll make this change now—feedback or direct fixes welcome. :fish: :smiley:

[sampsyo]

@ZenithDK, does a list-valued artist field resolve your question? Or were you getting at something else with the Three Tenors example (i.e., there are multiple ways to "say" the same artist)?

[ZenithDK]

@sampsyo Yes, it does resolve my question. The Three Tenors were just a (may poorly chosen) example to get my point across. I'm actually not even sure what I would put in myself in that case? :-P Maybe all 3 individual artists and then the group name - as this is a sort of special case?

For Mopidy we have the following: https://docs.mopidy.com/en/latest/api/models/#mopidy.models.Track

name (string) – track name artists (list of Artist) – track artists album (Album) – track album composers (string) – track composers performers (string) – track performers genre (string) – track genre track_no (integer) – track number in album disc_no (integer or None if unknown) – disc number in album date (string) – track release date (YYYY or YYYY-MM-DD) length (integer) – track length in milliseconds bitrate (integer) – bitrate in kbit/s comment (string) – track comment musicbrainz_id (string) – MusicBrainz ID last_modified (integer) – Represents last modification time

I'm actually unsure of why composers and performers are not "list of Artist" also....

[asutherland]

There's also the issue of artist name versus unique artist id. Arguably since the URI schema already keys artists based on a unique id, the unique id should have primacy and the links/include mechanism should be used for the names.

In terms of having multiple track titles, an example of a scenario like that is remixes that have had different names on different releases. But that can get messy quickly. This could probably be handled via optional aliases or other optional extensible data that is pulled down from musicbrainz/etc and the UI just knows how to consume the data from that schema.

[sampsyo]

There's also the issue of artist name versus unique artist id.

That's a good point. Yes, the link should probably be used when the server supports it (it need not). And perhaps the "link" from track to artist (and album to artist) should be plural.

In terms of having multiple track titles, an example of a scenario like that is remixes that have had different names on different releases. But that can get messy quickly.

Yes, I think it's a reasonable "non-goal" to work as a complete music taxonomy database like MusicBrainz—no need to reinvent that wheel.

(Good to see you here again, @asutherland! Mind if I add you as a collaborator on this repo?)

[sampsyo]

Thanks for the list, @ZenithDK! That's very helpful. I'm going to steal "comments" at least for the AURA list. Feel free to add more too.

[asutherland]

Sure, feel free to add me. I expect I'll stick to pull requests but I suppose it's handy for me to be able to land things after making any requested review fixes. I'm really looking forward to where this is going!

[andrewrk]

I'm not making an argument for anything in particular with this comment, just thought I'd do what @ZenithDK did and list Groove Basin's fields for reference:

key                   string, unique identifier in database
name                  string, track title
artistName            string
albumArtistName       string
albumName             string
compilation           boolean, whether the album is a compilation, e.g. has multiple artists
track                 integer, track number where 1 is the first track
trackCount            integer, total tracks in album
disc                  integer, disc number where 1 is the first disc
discCount             integer, total discs in set
duration              float, number of seconds
year                  integer, year the track was released
genre                 string
file                  string, path on disk where the track can be found
mtime                 integer, modification time of the file on disk
replayGainAlbumGain   float, volume adjustment to make to the album this track is on
replayGainAlbumPeak   float, tells the peak of the album, helps us know sometimes whether we can use a simple volume adjustment vs a limiter for the album
replayGainTrackGain   float, volume adjustment to make if the next/previous song is not from the same album.
replayGainTrackPeak   float, tells the peak of the song, helps us know sometimes whether we can use a simple volume adjustment vs a limiter for the track
composerName          string
performerName         string
lastQueueDate         date, last time this track was queued. used when randomly selecting songs to favor songs not queued recently
fingerprint           string, acoustid fingerprint
playCount             integer, number of times this track has been played. a play follows the last.fm rules for scrobbling.

[sampsyo]

Thanks, @andrewrk—this is helpful. It might be a good idea to borrow the "artistName", etc., field names as opposed to "artist" to avoid confusion with the links in AURA resources.

[tilboerner]

@asutherland:

In terms of having multiple track titles, an example of a scenario like that is remixes that have had different names on different releases.

I was wondering about that. Another scenario for multiple track titles I can think of are classical pieces. There, the different forms (concerto, symphony, ...) and keys (a minor, D major, ...) have their own names in different languages.

This could probably be handled via optional aliases

I agree, but having the title attribute be a list seems to fit an alias model quite well, especially when there is no obvious hierarchy of which name is more "real" or "true". Anyway, you/the client can always ignore the other elements and only ever go with the first.

As for the cardinality of track fields in general, I agree that many of them could possibly contain multiple values, and I'd like to support that. It seems to me that this mostly concerns metadata that is primarily relevant to human users, as opposed to technical data: people involved, names, genres, stuff like that.

I agree we should err on the list side, especially for "soft" fields like these. Although I don't know if that's good enough to contrive a hard rule for everybody to follow. ^^

@sampsyo

It might be a good idea to borrow the "artistName", etc., field names as opposed to "artist" to avoid confusion with the links in AURA resources.

I don't understand why there would be an artist name field which is somehow not related to an artist resource, and therefore should not be a link instead. Isn't that the real source of the confusion? Either the server supports artist resources, or it doesn't. But if not, what's its business pushing artist names onto me? :)

One last thing: I'm convinced that many track fields don't belong there. This goes exclusively (I think) for album related fields like track, tracktotal, disc, year, albumartist, and so on. All of these belong either to an album resource, or to a track-album relationship. Of course it might be convenient not having to follow that graph; but when you question if a track can appear on other albums, or even on no particular album, you also question if these fields should really belong to a track.

I'm raising this last point here since we're currently discussing these fields in general. It's very much its own issue, though, and I'd be glad to open one if you feel there should be more talk about this.

[sampsyo]

I was wondering about that. Another scenario for multiple track titles I can think of are classical pieces.

I admittedly don't have much experience trying to tag classical music. Can you give a concrete example of a "track" and the multiple titles you would want to assign to it?

Either the server supports artist resources, or it doesn't. But if not, what's its business pushing artist names onto me? :)

Indeed, the artist field would be redundant if the server supports artist resources/links. So maybe we should consider making it optional.

One last thing: I'm convinced that many track fields don't belong there.

I totally get your point, but those fields are there for a reason: it's a design goal to keep support for album resources optional. A fully compliant AURA server should be able to serve up a bag of tracks and let the concept of an "album" be implied by the metadata (i.e., the album name string).

So I fully expect that these duplicated fields to be unsupported on tracks by (some) servers that do have distinct album resources. Maybe it's worth making this intention clearer in the spec.

[canpolat]

I admittedly don't have much experience trying to tag classical music. Can you give a concrete example of a "track" and the multiple titles you would want to assign to it?

A popular one would be Beethoven's "Moonlight Sonata". I believe, it can be called either of the following:

• Piano Sonata No. 14 in C-sharp minor "Quasi una fantasia"
• Moonlight Sonata
• Op. 27, No. 2

And considering classical music titles are generally translated, there may be other names in other languages...

• Sonata para piano n.º 14 en do sostenido menor "Quasi una fantasia"
• C-diyez minör 14. Piyano Sonatı "Quasi una Fantasia"
• Mondscheinsonate
• Måneskinnssonaten

BTW: I always tought of (and used) albumartist to list the artists who have contributed to a certain track (as opposed to using it for listing all artists contributed to the album that track is compiled in).

[tilboerner]

Can you give a concrete example of a "track" and the multiple titles you would want to assign to it?

@canpolat already did that, thanks! :-) I'll add

• Klaviersonate Nr. 14 in cis-Moll op. 27 Nr. 2 "Mondscheinsonate"

and that it might not be uncommon to find people who own several different recordings of it, differently tagged or not. I'm not saying I want to assign all these titles to all of them; any one of the titles is probably enough to identify the track.

The trouble starts when you want a program to bring consistency into the whole or to infer relationships, say, for a search. It might be wise to have a way for users to indicate relationships somehow. Also not saying the API should support this, but allowing multiple titles might be a useful option.

@sampsyo:

it's a design goal to keep support for album [and artist] resources optional. A fully compliant AURA server should be able to serve up a bag of tracks and let the concept of an "album" be implied by the metadata (i.e., the album name string).

So I fully expect that these duplicated fields to be unsupported on tracks by (some) servers that do have distinct album resources. Maybe it's worth making this intention clearer in the spec.

Totally! I thought the album-related fields were optional depending on album support. (I was also wondering why the artist field was not optional, so yeah.) Okay, this design feels weird, especially that track fields might go unsupported because of support for album resources; but I need to think about it some more, before I have anything useful to say (if at all).

[sampsyo]

Thanks for the examples, @tilboerner and @canpolat! I can totally see how these classical works ideally have multiple names. Any guesses as to whether this is something that anyone will actually want to use in their music player? I'd like to understand whether this is a theoretical taxonomy problem or whether there's a real use case that people will miss.

Anyway, as I said before, we'll err on the side of listiness.

Okay, this design feels weird, especially that track fields might go unsupported because of support for album resources; but I need to think about it some more, before I have anything useful to say (if at all).

I hope we can get it feeling un-weird! :smiley: I believe having optional fields on tracks that seem intuitively "album-relevant" is a reasonable approach here (it's conceptually simple, as flexible as possible for servers, and not unduly complex for clients to support via fallbacks), but I'd of course be interested in considering alternative proposals.

[tilboerner]

Any guesses as to whether this is something that anyone will actually want to use in their music player? I'd like to understand whether this is a theoretical taxonomy problem or whether there's a real use case that people will miss.

I'm not really sure of that, myself. A use case I can think of is finding a particular track without having to remember which of the possible terms are in the title, and without wading through a number of related, but different items. However, it targets what seems to me a niche population of the audience; still quite a number of people in theory, who are, on the other hand, already dealing with the problem in some way. The viability of an actual feature depends a lot on ease of use. That's why I suspect that having alternative titles will be one of the results of the process rather than a means to achieve them.

So, there's a lot of uncertainty in this, but I was only hoping to provide a reason to "err on the side of listiness" in this particular case.

I'd of course be interested in considering alternative proposals [for the current approach to the complexity of meta data support].

I'll think about it some more. If I feel the need to come up with something, I'll open another issue. :)

[canpolat]

Any guesses as to whether this is something that anyone will actually want to use in their music player? I'd like to understand whether this is a theoretical taxonomy problem or whether there's a real use case that people will miss.

I'm not sure either. As long as it's possible for the user to somehow include that information and search for it (comments?), I wouldn't insist that there is a pressing need to have multiple titles. But I think the user searching for only one of those titles and hoping to find all executions is a real use case (which depends on correctly tagging their music in the first place).

[yoasif]

A use case I can think of is finding a particular track without having to remember which of the possible terms are in the title, and without wading through a number of related, but different items.

For what it is worth, Musicbrainz solves this problem about multiple recordings of "Moonlight Sonata" by using "works" to signify "distinct intellectual or artistic creations", which are then attached to "recordings".

For the Moonlight Sonata example, it looks like it is present in the MB db as the whole work, along with separate movements:

Sonata for Piano no. 14 in C-sharp minor, op. 27 no. 2 "Moonlight"

---

1. Adagio sostenuto
2. Allegretto
3. Presto agitato

Recordings attached to works can have different titles. If a user in a visionary music player decides to search by the name of one of the titles, the player could possibly use the link to the work to identify other recordings based off of the work.

[sampsyo]

Thanks for the background @yoasif. In AURA, our "track" objects correspond to recordings in MB's schema. Perhaps this is a good argument for including a work_mbid field to make it easy for players to look up associated work information from MB.

[sampsyo]

Sorry to revive an old thread, but I'm getting back to working on AURA again.

Here's something that I'm having trouble deciding: For tracks, should the "artist" string exist distinctly from the "name" string on the linked artist object? (And the same for albums.) Here's why I'm undecided:

• Con: Clearly, this is duplicative. It leads to weird naming collisions and a confusing story about which piece of metadata is more important.
• Pro: As a practical matter, files' metadata—e.g., ID3 tags—have embedded artist strings. So, in lots of software, this embedded string is the "ground truth." Therefore, it makes sense to expose this value, even if the database has a separate concept for "artist objects."

I'm currently leaning toward no, i.e., we should remove the duplicated information. Tell me if that sounds crazy!

[irskep]

It doesn't sound crazy. A naive server implementation could just create album objects on demand for each track and make no attempt to maintain an album database.