Multi-artist support

[animaldaydream]

Describe the bug/crash:

When an audio file contains two values on the 'artist' field, only one value is taken.

If another file has this tag, ~it appears as if the first tag detected between each file is the one considered for any following files that contain this tag.~ The first tag alphabetically seems to be the one considered.

Expected behavior

Present all artist values in the 'Artist' view, and on each track. Currently only one of the artists is present in the Artist view, and in the track credit only the first artist (alphabetically) is considered.

(Some music players might opt to concatenate them all instead. This would also be acceptable, though it would clutter the list.)

Steps To Reproduce the bug/crash:

Please see file attached and extract on a phone running Auxio. multipleartist_test.zip Examine the "Artists" view; There should be two artists, and yet there's only one. (Opus files and Ogg files return the same problem.)

Phone Information:

Xiaomi Redmi Note 7, running ArrowOS 12.1 Vanilla.

[animaldaydream]

For the sake of testing, here's another case.

Split releases (the release is split completely between two artists, who each provide their own solo tracks to populate the release) will populate the artist field on each track correctly, but won't populate both on the Artist view regardless.

I don't know if the article 'The' is being ignored here but it seems like the filename does nothing.

splitrelease_test.zip

[animaldaydream]

A third case: Compilations.

If the album artist is "Various Artists", most of the time (but not always), the album artist would differ completely from the track artist. In such cases, (and as long as there's one artist value per track,) the values are populated correctly. However, the 'Artists' view only shows the album artist.

When the album artist is included in one of the tracks, then that's the artist that'll populate the 'Artists' view. Additionally, it seems as though the album artist always takes precedence over the track artist, regardless of sorting order. That's the artist that'll be shown on the track's artist credit.

comp_test.zip

[animaldaydream]

This is the most abstract case yet. (I'm sorry for your notifications.)

The first artist value (as stored in the tags) present in the tags will be in the track credit. However, the first album artist, alphabetically, will be listed in the 'Artists' view regardless.

I don't know how Auxio is reading the tags anymore...

abstractcredit_test.zip

[OxygenCobalt]

Okay, after doing some testing with #128 this is clearer now. More or less, Auxio is always picking the last of your tags, as most metadata parsers don't expect vorbis tags to have multiple values like that.

Here's what I think the expected behaviors should be (And the issues with them):

Case 1: "Dirty Projectors" and "Bjork" are separate artists. Bjork points to both of the given songs, while Dirty Projectors points to it's song. What I would do is set "artist" to "Dirty Projectors, Bjork" and "album artist" to "Bjork"/"Dirty Projectors" depending on who the remixer was. This raises the issue I pointed at before, where I have no idea what artist to navigate to regarding the song that credits both Bjork and Dirty Projectors. Case 2: Every artist within the compilation should point to the particular album. Not only does this have the same artist navigation issue (Just with albums), but I also have no idea what to display in the album view regarding what artist it belongs to. Since there are so many artists, "Various Artists" would be appropriate, but that would not correspond to any artist that points to that album. I would personally use "various artists" and the individual artist for each song. Case 3: "Patricia Taxxon" and "The Ambiguity" should be separate artists that point towards the same album. Same issue as 2, where I have zero idea how to make navigation or the artist display work. I would personally use "Various Artists" for the album artist and then the individual artist names for each song. Case 4: You seemingly want all of the artists to have separate entries all pointing towards the soundtrack. Same issue as 3 and 2. I would personally use "Various Artists" for the album artist here as well, like 2 and 3.

I only really see myself fixing the multiple tags issue in #128 by concatenating vorbis tags with a comma. Anything related to multiple artists will have to wait until I have a model to implement them that won't cause insane app behavior (I haven't even gotten into the issue of how to make MP3 files with with this, they have even worse support for multiple values).

[OxygenCobalt]

Note that I'm not apprehensive towards a better artist system like this. It's just the technical and UI complexity that I am concerned about. I'll be leaving this issue open, as I think it's a good idea to further differentiate Auxio from the sea of so-so FOSS music players. I just want to first deliver an MVP of #128, make some UI reworks to solve the navigation issues, and find a good way to model this in the context of the pre-existing album artist/artist system.

[animaldaydream]

See, the thing about making a music database into a tree is that music doesn't work like that. It's more like a web. An intersecting, non-euclidean tridimensional web.

Case 1: "Dirty Projectors" and "Bjork" are separate artists. Bjork points to both of the given songs, while Dirty Projectors points to it's song. What I would do is set "artist" to "Dirty Projectors, Bjork" and "album artist" to "Bjork"/"Dirty Projectors" depending on who the remixer was. This raises the issue I pointed at before, where I have no idea what artist to navigate to regarding the song that credits both Bjork and Dirty Projectors.

Neither artist is a remixer, they're both the main artist. You can't put priority of one over another because there is none.

Case [3]: Every artist within the compilation should point to the particular album. Not only does this have the same artist navigation issue (Just with albums), but I also have no idea what to display in the album view regarding what artist it belongs to. Since there are so many artists, "Various Artists" would be appropriate, but that would not correspond to any artist that points to that album. I would personally use "various artists" and the individual artist for each song.

There's an album artist though. With the particular abstraction you have in your UI, the only album artist should be No Mana, and that's the only artist the album should be under. The rest of the artists should only be shown in the track's credit.

There's a few alternatives to consider here:

1. You could make it a setting to choose whether to show all artists, or only album artists, on the 'Artists' tab.
   • In the case of the former, you could show either that artist's albums where that artist is the album artist plus a section with all of that artist's tracks below the albums, or inside a button over all the albums.
2. You could use album artists to group the albums in the 'Albums' view. I'm currently preparing to put 1883 albums into my phone and making all albums appear on one screen is absolutely useless.
   • In this case you could use the Artists tab to either do option 1, or just to show the tracks of that artist, without including the tracks where they're only the album artist.

Case [2]: "Patricia Taxxon" and "The Ambiguity" should be separate artists that point towards the same album. Same issue as 2, where I have zero idea how to make navigation or the artist display work. I would personally use "Various Artists" for the album artist and then the individual artist names for each song.

This release, like in case 1, has only two artists. Putting the release under "Various Artists" would complicate things even more, as I have like forty compilations where "Various Artists" is the album artist. And this isn't a compilation in the first place. It's just a misrepresentation of the album, and music taggers just do not ever do this automatically by default, if at all.

Plus, "Various Artists" has its own MusicBrainz ID. The user would have to fix that as well. It's just not user friendly by default.

Case 4: You seemingly want all of the artists to have separate entries all pointing towards the soundtrack. Same issue as 3 and 2. I would personally use "Various Artists" for the album artist here as well, like 2 and 3.

This is not a compilation though. There's exactly three artists that should point to the soundtrack. If not possible, I'd rather concatenate them all, because I have loads of releases that have more than one main album artist.

In summary

Provide two views. One should point to the artist's tracks, another to the album artist's albums.

I realize however, that this is hard to accomplish without retooling the database, but in the meantime, the artists have to be concatenated. If the user expects otherwise, the user needs to fix the tags themselves, like in any other sane music player.

There's not any sane music players in Android though. That's the whole reason I'm drafting this reply at all. I'm extremely frustrated and have been for years.

[animaldaydream]

If you want an example, Poweramp allows you to show albums by album artist, and tracks by artist, both in different sections. I think this is a sane approach.

Poweramp also allows you to show all albums in a single list, but that leads nowhere with a library as huge as mine. It's too long.

I think the main issue here is that you want two views, and in reality there's a need for three. You can fuse two of them with a button in the artist's albums screen leading to all of that artist's tracks, though. That'd be sane enough, me thinks.

The other problem is that some other people want a list of their music tracks, and they have like thirty tracks tops. I don't think that is your place to solve. There's other music players that pull that off more easily. [But you could always leave a checkbox somewhere.]

[OxygenCobalt]

I really don't see myself implementing that. Removing the "Artist" tab, which is a straightforward for most users, and replacing it with 2-3 distinct tabs that all represent slightly different types of artists is absolutely terrible UX for most users (People who extensively tag with Picard tend to be the minority compared to those who just tag with artists and album artists). I downloaded poweramp myself to get a better understanding of what you want, and the library structure feels extremely incoherent and borderline unusable.

While it definitely seems like a nice idea to improve library quality, I simply do not like how you would want it implemented. The next version should concatenate tags with #128, and perhaps I'll revisit this some other time with a different methodology that preserves the artist menu (I generally like Quod libet's approach a bit more with it's "people" menu).

[animaldaydream]

Removing the "Artist" tab, which is a straightforward for most users, and replacing it with 2-3 distinct tabs that all represent slightly different types of artists is absolutely terrible UX for most users.

I don't think I'm communicating properly.

I said the "Albums" and "Artists" tabs need a reorganization, not to be removed and replaced with four tabs.

Like this, for example:

• "Albums" tab
  • (Album by artist) button
    • (List of album artists)
      • (List of albums by that artist)
  • (List of all albums)
• Artist:
  • Artists
    • Tracks by that artist

This would accomodate other people without removing functionality. There's a bunch of other ways to do it, but this is just an example.

• "Albums" tab
  • All albums
• "Artists" tab
  • (List of all album artists)
    • (Albums by that artist)

This is the way you've got it set up, and I like it. I just want the player to acknowledge multiple values for each artist tag. Right now it's just taking one and discarding the rest.

[OxygenCobalt]

I just want the player to acknowledge multiple values for each artist tag. Right now it's just taking one and discarding the rest.

Okay, then that will be resolved in the next version then, as artist values will now be concatenated (At least with vorbis/opus/flac). Not the best solution, but it's also the only thing I can do until I find a model to handle multiple artists properly.

[OxygenCobalt]

Quick question: Is there anything wrong with Quod Libet's "People" model @animaldaydream? In such a model, every collaborator in your artist tags has it's own entry pointing to the songs and albums that it is credited on. Albums and songs can credit can link to multiple people. The only caveat is that such a model is derived from the artist tag and not the album artist tag. I would make it derived from the album artist tag first, but that would cause compilations to still be grouped as "Various Artists".

[animaldaydream]

The only caveat is that it's derived from the artist tag and not the album artist tag.

I don't actually use the ~people internal tag because it includes every single collaborator in the tags, including performer, composer, producer, etc. It's an internal tag populated with a combination of all those tags.

But I only care about the albumartist tag so I've got it replaced there. That model is made to be adapted to both Classical and Pop music.

Having both the Artist and Album Artist tags in the same tab is fine though. I can keep up. I know where my library is. My problem is the albums are hard to find when the tags aren't respected.

On another extreme, some other music players make a new album entry for every single artist combo in the album. If you did that I wouldn't be here.

[OxygenCobalt]

Okay, so you would be okay with a system that prioritizes album artists @animaldaydream? Assuming my logic follows with Quod Libet, this would mean that the new multi-artist system would do something like this:

1. If we have at least one album artist, we disregard ARTISTS and create artist entries based on the ALBUMARTISTS that point to the particular song.
2. Otherwise, we create artist entries based on ARTISTS.
3. With track credits, ARTISTS is always used, falling back to the artists that were created in 1/2.

That would roughly mean this for each case you provided:

Case 1: Bjork and dirty projectors are separate artists. Bjork is linked to both songs, while Dirty Projectors is just linked to one of them. Case 2: Patricia Taxxon and The Ambiguity are separate artists that both point to the same album and songs. However, the songs themselves will be credited individually to Patricia Taxxon and The Ambiguity. Case 3: The first compilation is still grouped as Various Artists, the behavior remains unchanged. No Mana is the only artist entry corresponding to the songs in that release, however James Egbert and Uppermost will still be displayed within the track credits. Case 4: All artists that contributed to the soundtrack will have their own entries. In the track however, the two artists you seemed to have specifically credited will be used instead.

This is just the internal system. This may slightly change as I implement it and discover how this will actually work in-app. If there's something you feel is in-adequate or doesn't exactly line up, let me know.

[OxygenCobalt]

I'll re-open this issue now. Still some time until I can implement it, but I think this system will finally work out.

[animaldaydream]

Sounds perfect!

Maybe I can reply with my few Picard scripts that'll end up with a sane configuration of tags for non-MusicBrainz enabled players, so you can test with arbitrary files as well. I'll do it later though.

In the meantime you can test with the provided ones, which are unambiguous enough to work in a player with this feature, but also ambiguous enough to trip up the database whenever faulty. I think.

[OxygenCobalt]

Yeah, those files you have me are a huge challenge, way more than the test files I've spun up. Always love a nice technical challenge that doesn't involve wrangling the android OS.

[OxygenCobalt]

Quick question @animaldaydream. In Auxio, there are configuration options on how a song should be played when it's selected from the library or from search. For example, Settings -> When playing from the library. One of these is "Play from artist". However, if there are several artists linked to a song, it's unclear what artist the app should play from. Is there any preference for what the app should do here? I really don't want to just drop that option when I add multi-artist support.

[KraXen72]

I'd say play from album artist if there are multiple "artist" tags

[OxygenCobalt]

There can be multiple album artists if I implement this feature @KraXen72, so I can't do that.

[OxygenCobalt]

Judging by the discussion in the related #201, I think my plan for the option is to pick the artist with the most songs in general to play from. Not the best solution, but making the app capable of playing from several artists at once is a bit too much, honestly.

[KraXen72]

yeah that sounds like not great ux. there are some songs, for example Killstation ones from the start of the year where it's a collab with like 20 other people and having to query the library for all these people and their songs and making this giant mix of a queue that no one wanted would be confusing for the user like: " i just played a killstation song why are ther 70 other songs "

here are some of their songs i was talking about btw:

just making it the artist with most songs makes sense by me 👍

[OxygenCobalt]

Yeah. However, OP hasn't given their feedback on this. @animaldaydream any feedback on this? (You might want to read the earlier posts)

[animaldaydream]

I think it should just play the tracks from whichever page you're on. This is easy enough to do because the Now Playing view already has shortcuts to these pages.

Figuring out a 'smart' way to do something is too much trouble. I don't think it's a practical idea here.

A problem there is that the 'Artists' view is album based rather than artists based. If I were you I would put a button on top of the 'Albums' view to browse by album artist. Then for the 'Artists' view, I'd just list track artists. (Perhaps with a button to go to that artist's albums.)

Once the pages are figured out, you really shouldn't need this function anymore. The user would just go to the relevant page and play all tracks from there.

[I recognize this is a massive overhaul though.]

[animaldaydream]

In the meantime, the only practical solution is to just play any song where any of the contributing artists are present. It's a mess, but the function you're describing does not conform to a music library's hierarchy, so it's already flawed.

[OxygenCobalt]

Yeah, that's what I thought. While it doesn't conform to a true music library, I want to stick with technical simplicity and go forward with the idea I've already come up with. Besides, really the setting I'm talking about is a quirk, and the current behavior is already context-based like you suggested.

[animaldaydream]

I want to stick with technical simplicity and go forward with the idea I've already come up with.

I don't know man, if there's multiple artists and I don't know which one is gonna play I would just rather go to the artist's page and play their songs manually.

Trying to figure out what the user's intent is without clear action is more trouble than it's worth.

I don't know if any music junkie would actually use that option.

The average user as well would just change songs manually after each song plays because they wouldn't know what song would play. Might as well play what they're looking at.

---

By the way, may I open an issue regarding the whole track artist vs. album artist debacle? The current UI doesn't make room for people who put random track on their phone, and that type of user also doesn't usually modify their tags to fit their music player's behaviour. I think this is a legitimate issue that needs consideration.

[OxygenCobalt]

I don't know if any music junkie would actually use that option.

Yeah, that's kind of my reasoning for why the way I'm handling that option is a bit lackluster. I only imagine users with more linear libraries would care to leverage it, hence the behavior I'm going for.

Might as well play what they're looking at.

Note that this setting we are talking about also applies to the main library view as well. This is where the contextual issue really comes into focus. If you were playing a song from the actual artist view, then yeah, it would play from that artist.

Perhaps I could show an explicit menu if there were multiple artists for a song. That way, you could choose which artist you want to play from. This would not get in the way too often given that music junkies aren't leveraging this setting that much.

By the way, may I open an issue regarding the whole track artist vs. album artist debacle? The current UI doesn't make room for people who put random track on their phone, and that type of user also doesn't usually modify their tags to fit their music player's behaviour. I think this is a legitimate issue that needs consideration.

I personally find fragmenting the artist view like you suggested to be very cumbersome for my use while benefiting a subset of users. Ease-of-use over edge-cases.

[OxygenCobalt]

Okay, I want to give a brief update on this:

I've decided not to handle the option we discussed by picking the artist/genre that with the most songs. In the situation where an interaction's outcome is unclear because there are more than one artist/genre instances, a new menu will be shown that allows you to explicitly select the artist/genre you want to use.

This does not just apply to playback, but also with navigation as well. For example, if you click on the name of an artist and there are multiple entries in that field, you will have to choose which artist to go to. This is mostly for technical simplicity on my end since I have no idea how to determine which artist one was intending to click on in that situation.

I also brought up the idea of truncating an artist value to "various artists" if they all could not fit on-screen. I don't think I'll be doing this. Instead, I'll just list them all, and if it doesn't fit, Auxio will instead display something like "Artist A, Artist B, and 2 others". The specific threshold will be based on screen size, text length, and information density.

[gergesh]

I came here looking for this issue, very glad to see it's being actively worked on!

I'd love to offer my thoughts on organization of a library with support for multiple artist and album artist tags. In my opinion treating artists and album artists as different beasts results in bad UX, as these are mostly the same people. My suggested approach is having the "artists" tab contain every artist in the library (meaning anyone included in any ARTIST or ALBUMARTIST tag), and the artist page should have an "Appears On" section for albums where the artist is in one of the tracks' artist tags.

For example, if you click on the name of an artist and there are multiple entries in that field, you will have to choose which artist to go to. This is mostly for technical simplicity on my end since I have no idea how to determine which artist one was intending to click on in that situation.

Android's ClickableSpan implements this behavior.

[OxygenCobalt]

In my opinion treating artists and album artists as different beasts results in bad UX, as these are mostly the same people. My suggested approach is having the "artists" tab contain every artist in the library (meaning anyone included in any ARTIST or ALBUMARTIST tag), and the artist page should have an "Appears On" section for albums where the artist is in one of the tracks' artist tags.

That is exactly that I'm going for.

Android's ClickableSpan implements this behavior.

Oh. Sweet. I thought apps like Spotify did some touch target black magic to do that, but this should make the UX much nicer.

[animaldaydream]

Instead, I'll just list them all, and if it doesn't fit, Auxio will instead display something like "Artist A, Artist B, and 2 others".

Didn't iOS run into a bug that would crash the system if a notification with certain characters on it arrived?

Not saying doing this will make your app crash, but you might wanna find some existing implementation instead of truncating names by display space yourself, because that doesn't exactly behave as you'd expect on every script.

If this wasn't a music app I wouldn't say anything but here you just never know what the artist will put on the metadata. If it can be stored it's fair game.

[OxygenCobalt]

Yeah, you're kind of right. I could definitely not do this trick in places like the notification since I simply cannot predict how much space I have. Also, having that "and more" idea also comes a bit into conflict with ClickableSpan, I'd imagine. I don't really know how I'll work this out.

[animaldaydream]

I could definitely not do this trick in places like the notification since I simply cannot predict how much space I have.

For that one I wouldn't even bother. That's system territory and the system will treat it however it wants, and each version will behave differently.

Anyways, IIRC the bug I mentioned came up with Arabic script. When a certain chain of characters is stored, the script mandates it be abbreviated into a single character on display. These however are interpreted as multiple characters by humans, and as such they are stored as multiple characters in Unicode, for the user to erase partially as they see fit.

It just so happens that these short words become longer if you remove characters from them.

There is also the flag emojis, which are actually stored as two characters 🇨🇱

[OxygenCobalt]

So, would you just be fine if I listed every artist, and if it ends up ellipsizing, whatever?

[animaldaydream]

If you manage to figure it out that'd be posh, but I don't necesarily expect for you to do it from scratch either. I think Android is too volatile, I would not think it would be practical (though I'm not speaking from experience).

Showing the list of artists to pick one would be very useful though. Just remember to make that list scrollable as well. Some labels just wanna watch the world burn. https://musicbrainz.org/release-group/ec9c88e7-6e28-448c-b784-5a6098910a72

[OxygenCobalt]

Yeah, I anticipate it to be scrollable. I'm probably going to switch to using the bottom sheet component (which is scrollable, unlike popup menus) because of this change as a result.

[animaldaydream]

Another option would be to make these fields animated; sliding around on the Now Playing screen, that way nothing is truncated. This would also be useful for song titles which are long and then they have the song version title on top.

https://musicbrainz.org/release/8894b63a-36fc-4321-927a-5a0e3d4470a6

[OxygenCobalt]

Yeah. I think I'll try looking around to see how other multi-artist players handle this and come to a conclusion on what I prefer the most.

[gergesh]

Using a ClickableSpan when they all fit together and a scrolling TextView with a pop up otherwise is a good compromise I think. For inspiration, I would take a look at Oto Music. It's very well-designed IMO, with the only issue being that their support for multiple artists is a hacky "split on separator character" implementation.

[OxygenCobalt]

Yeah, I think that will work. Note that while it would scroll in the playback menu, I doubt it will scroll in other places like list items. Those will remain ellipsized as they currently are.

[OxygenCobalt]

Hey @gergesh @animaldaydream @KraXen72, is there any convention regarding "separator conflicts" with multiple artists?

I've said in the past that I dislike parsing by separators since it mangles artist names, like "Black Country, New Road" becoming two artists called "Black Country" and "New Road", since it has a "separator" in them that actually isn't one.

However, the ID3v2 analogue of the "Artists" tag requires me to parse by separator, and since there is seemingly no convention on what separator to use, I'll probably have to check for all of them (; , & + etc.). I would imagine such conflicts would be resolved by escaping the symbol, such as \,), but I don't know.

[gergesh]

I love that you brought it up because this is an issue I have with a lot of other players (and I love even more that you used BCNR as an example haha) I'm not too familiar with tagging internals, so please forgive me if I'm starting the obvious to you, but music tags of various kinds (including ID3v2.4, according to my searches) support specifying a tag multiple times to avoid these issues. The taglib library is able to parse multiple tags successfully, and there are Kotlin bindings for it at https://github.com/timusus/KTagLib

[OxygenCobalt]

Yeah, I'm aware of the "null terminator" trick that ID3v2 uses to have multiple values from my half-dead other project musikr. While technically it's ID3v2.4 specific, nobody cares and it's convention in ID3v2.3 too.

However:

1. I'm using the ExoPlayer parser, which as far as I'm aware has no concept that these multi-value tags exist.
2. TagLib is kind of off of the table, as I don't want to bundle a redundant metadata library, and also I think multi-value support is actually a Kid3 extension.

I guess my tag strategy will be the following:

• Singular Artist tags (TPE2, TPE1, ARTIST, ALBUMARTIST) will be treated as one artist. Doesn't matter if they contain multiple artists, it just has too much variety for me to handle it "sanely".
• Multi-artist tags (TXXX:ARTISTS, TXXX:ALBUMARTISTS, ARTISTS, ALBUMARTISTS) will be considered capable of having multiple artists, but ONLY if separated in the standard way (Multiple tag instances in Vorbis, Null-terminated values in ID3v2)
• If there's enough demand, I'll add additional options to interpret singular tags as containing multiple artists and to parse separators. These will not be default behavior.

I'm going to keep pushing ahead with this feature and probably modify ExoPlayer again to add support for those multi-value tags.

[KraXen72]

sounds pretty good, i just checked how deemix (deezer ripper i use) tags the songs, and it does like this:

not really sure what this tagging means for this new system but if it wasnt supported, 1) i can also just start downloading flac (if it would help + i have a kind of new 256gb card) 2) fix my tags/writre a script to fix my tags to comply with this

[OxygenCobalt]

Oh, so either:

1. Deemix/Deezer is COMPLETELY breaking the spec and duplicating TPE1 tags. If that's actually occuring, it's not too big an issue on my end as the ExoPlayer parser is really liberal in what's considered a valid ID3v2 tag.
2. This is just how this program likes to display multi-value tags. I really hope it's this.

[KraXen72]

probably the second one, I can send you the file on email (in your GitHub profile) so you can check yourself.

[OxygenCobalt]

Sure, go ahead.

Also, I just realized that given how Deemix is formatting these tags, I have to assume TPE1/TPE2 is capable of multiple artist values. Oh well, that's fine.

[OxygenCobalt]

Yep, it's the null-terminated method I expect. Everything is still good.

[animaldaydream]

Yep, it's the null-terminated method I expect. Everything is still good.

that's the standard method on ID3v2, a null character means it's a second tag by standard

[animaldaydream]

not really sure what this tagging means for this new system but if it wasnt supported, This is what the bew system is meant to support.

Instead of showing the featured artist in the title, the database is instead populated with two artists