SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Featured and "co-artist" handling

#1

Hi (Paul, mostly),
Really, this is about the “co-artist” situation, but I wasn’t sure the title would make much sense without mentioning ‘featured’ artists to help build context.

I’ve noticed in a couple albums (most recently this one by Sia that even though I’ve selected:
When tracks contains featured artists : Only use main artist in the artist field and add others to the title field
The ‘other’ artist still shows up in the artist field. In this case, I’m thinking of Kylie as the ‘other’ artist. I’m looking at track 3, “Dance Alone”, which Sia and Kylie Minogue are apparently sharing performance credit for (depending which release, but in my case, “yes”).

I’m thinking this is probably correct/desired behavior, because it appears they’re being credited as co-performing the song, vs one of them being ‘featured’, as is happening on Track 2, “Immortal Queen” ft. Chaka Khan.

However, I don’t like it :slight_smile:

I use a variety of UIs to listen to music, sometimes including relatively dumb ones that aren’t really feasible to update, and even if updated, may not gain much brains. I’m talking about players built into not-so-fresh cars as the really egregious ones. And of course the ridiculous oddball that Sony produced which we’ve recently discussed.

I typically like to listen to music by album. In a case like this, I’ll select Sia, and play the music for the album (Reasonable Woman), and one or more of my dumb players will end up skipping the song co-performed by Kylie. Also, I’ll have this ‘stupid’ entry on my player’s Artist listing that says “Sia & Kylie Minogue” which lists the album, and just that one single song.

It’s ‘correct’, but annoying, and counter to the way I like listening to music. In the olden days I’d have popped a record or tape or CD in, and listened to the album, which I’d consider a Sia album. It would be sorted on my shelf under Sia, and would of course play all the tracks in order.

Sometimes I use shuffle/random, but not usually. When I do, it doesn’t matter.

To avoid this nuisance, I’d prefer to ‘squash’ Kylie’s involvement from the Artist field. Since SongKong offers the “‘ft xxx’ in the title” feature, which I think is brilliant, I do that. I don’t find adding that info to the title at all offensive, helps remind me that Kylie is the other voice, and doesn’t make a mess of my playback experience.

Yeah, serious first world problem… :smiley:

Could I ask you to add another option in the UI to treat co-artists similarly to featured artists? (I guess giving first-listed credit, or maybe looking at the album artist value…) Not sure if it should be an option in the existing question, or a new question. I’ll let you sort that detail, seeing as it’s your app and you’ve surely given this more thought than I have already. I think a separate question my make more sense, though. I can’t think of a great way to present it that isn’t too cumbersome.

Dance Alone (ft Kylie Minogue) is ok, (though inaccurate in this case, so, no)
Dance Alone (co-performed with Kylie Minogue) seems a bit too wordy.
Dance Alone (with Kylie Minogue) sounds too much like it’s a ‘featuring’ relationship, minimizing her involvement. But maybe that’s ok, since it’s not default behavior, and the tagger (me) is choosing to do it…

Of course, if this is already feasible, and I’m missing it, please let me know.

The ‘data purist’ in me kinda doesn’t like the idea of ‘squashing’ this info out, but I more greatly dislike how the treatment of that info by lousy players screws up the album playback experience. N.B., I do realize that in most (all?) cases I could work around the problem by selecting the album WITHOUT picking the artist first, but that’s not really the way my brain works when I’m deciding what I want to listen to.

For now, I address this by using Jaikoz to ‘fix’ the offending song when I notice it. So, it’s not urgent or anything. It doesn’t come up that often. I do generally notice it when I suck the song into my own playlist management app and go to add the song to a playlist (which is used to keep my usb sticks / music players in sync with what I want on them.)

Thanks for reading.

#2

Hi, okay I understand what you are saying apart from the bit about picking album without artist, don’t you mean allbum artist instead of (track) artist and in this case the album artist is consistently Sia so would be no issue and whole album displayed ?

#3

Sorry, it was a bit rambly…

A lot of players (I’m talking about players in cars, handhelds, etc. NOT iTunes, Plex, etc, which tend to be much more flexible) allow you to drill-down into your selection either by Artist, Album, or Track. That seems to be the lowest common denominator.
Some support more options of course (Album Artist, E.G.)

Picking an Album without first picking an Artist is problematic when you have a lot of music at your finger tips, but can be helpful if you want to play a Soundtrack, or some other collection which would reasonably have “Various Artists” as the Album Artist.

Since my cars (and handheld players) don’t support Album Artist as a selection criteria, my next best option after Artist is Album.

Hope that clears that up.

Thanks

#4

Okay got it, will consider further.

#5

Hi, I thought about this a bit more and Im wondering if the issue actually is that the co-artist can be added to track artist or is just that track artist is not consistent for the album. What I mean by this is in your scenerio you are having to use track artist as the album artist, in most cases they will be the same but in some cases for some tracks some of the track artists may differ from album artist because of co-artists issue that you describe. Now if there is a co-artist credit and the non album artist is first credited then if I apply your fix that track artist will then be different to album artist so even though the track artist field has just one value it wil be different to album artist and hence have same problem.

And there could also be some other circumstances where track artist is not the same for all tracks that would not be fixed by changing the handling of the co-artists.

Whereas if you could just do if(AlbumArtist!=Various Artists" set Track Artist = Album Artist) that would fix the issue for your situation. I already have these two issues that would allow you to do that.

https://jthink.atlassian.net/jira/software/c/projects/SONGKONG/issues/SONGKONG-2625
https://jthink.atlassian.net/jira/software/c/projects/SONGKONG/issues/SONGKONG-2616

I think this would maybe a a better solution for you?

#6

Hi Paul,

I’ve spent several hours thinking about this now, writing, rewriting, reading and exploring (rediscovering!) the existing capabilities of Jaikoz and SongKong, and, I’m getting tired or trying to make this post really coherent and brief. :slight_smile:

That said, the TLDR is:
I’m not sure… I think it may be a better feature for the ‘Scripter’ mentioned in https://jthink.atlassian.net/jira/software/c/projects/SONGKONG/issues/SONGKONG-2625?jql=project%20%3D%20"SONGKONG"%20ORDER%20BY%20created%20DESC

I think the find-replace metaphor may not be ideal because I’d need to update TWO different fields (title and artist) based on relationship of two fields (artist and albumartist)

Here’s my more detailed/roundabout way of coming to that conclusion.

I had forgotten about the Auto Edit feature’s existence, having never used it.

I see the point you’re making in the first paragraph. And yes, you’re right; the real problem is that the [Track] Artist field is inconsistent for the album. This is only a problem when dealing with a UI that doesn’t know to pay attention to Album Artist. Actually, I think the subtleties regarding how a UI should treat Album Artist vs Artist in various scenarios probably warrants a small essay, so I’ll leave it at that, but acknowledge it’s really not quite that simple.

For purposes of this discussion, to work around brain dead UIs, the search and replace operation you’re suggesting would fix that part of the problem.

But it doesn’t update the title to include the co-artist info. (Or ‘other’ artist.). I would like to preserve their involvement in some way, even though that is of secondary concern.

I’m not sure the find/replace metaphor would work for this unless you could build up complex operations:

if (AlbumArtist != "Various Artists") {
  set title = title + " ({ListOfContributors(AlbumArtist, TrackArtists)})"
  set TrackArtist = AlbumArtist
}

This snippet assumes that there is a concept of a multi-valued “TrackArtists” (seems a fair guess) which includes all artists who worked on the track, including an indication of whether they were ‘featured’ or should receive “co-artist” billing. The “ListOfContributors” function would be responsible for figuring that all out. It could be defined by the user, or built-in.

So, my first thought is that this example may be more than you had in mind for the find/replace macro capability. (Actually, I think “find/replace” stops being a good name for it at this point. It’s just a script. (Note from Future Jason: It was shortly after I wrote this last bit, as part of a ‘go back and re-write that part’ that I went back and re-read your JIRAs and noticed you had made mention of a possible “Scripter”) It basically requires what amounts to a domain specific language. But I guess you kind of have that already in the file/folder renaming masks.

Assuming “artists” contains the required data, if you built this, I think that would satisfy my desire.

A few thoughts on that, however.

  1. I’d prefer not to have to run a separate find/replace operation after I’ve done fix songs (I may not even know that it’s required until later)
  2. If it was run as a separate operation, I be concerned about making sure the operation was defined in a way that makes it idempotent so that accidental multiple runs wouldn’t ‘corrupt’ the data. (imagine I have to run it on one album, and then later I run it for the artist, or my whole collection, etc.)
  3. If the operations could be chained to an existing Fix Songs or Monitor Watch Folder profile, that might help address both of the above concerns.

Is that what you had in mind? Or did I just make it way more complicated?

So, that’s where I was when I saw that you had mentioned a Scripter which I guess is on the roadmap, and I thought, crap, I don’t want to re-write all of this AGAIN :).
I think the Scripter (if it resembles what I described above) could do this. Find and replace? Meh, that might be hard (thinking about how that would apply to the title field).
I don’t know for sure that “Artists” is structured the way I’m assuming it is, but I’m guessing that whatever info you used to do the current “featuring” process could be made available, and that a user could write code that could tell the difference between a co-artist and a featured artist.
It would be good if Scripts could be added to Fix Songs and Monitor Watch Folder as post-operations (maybe pre-operations, too? Not sure. I don’t have a use case for that at this moment, and can’t really imagine what the point would be, before the data was Fixed. I guess that depends on what operations are in scope for Scripting.)

The checkbox with multiple options seems a lot simpler, but if you see another solution available that’s more general, flexible, and powerful, but needs your focus to deliver, I get it. I’m not sure how many users would be into that kind of tool. Maybe a lot. (I just realized recently that the community of people who own a swimming pool and maintain it themselves has a much higher proportion of nerds than the general public - maybe this is another such population!)

#7

Okay I forgot about the title thing, yes you are right if you want to do that then find and replace wouldn’t work, and even it did would gave issue if rerun if using title += title idea.

Scripter would be powerful enough for this but may still have the rerun issue.

Your original solution would work (in most cases). But I’m not that keen to add an option that essentially adds wrong data just to compensate for a bad car ui that only you may use.

Will muse further.