multi-tagged [artists] and the Contributing Artists index.
Barry Mossman
I removed a some of my multi-tags at the [artist] level due to the LFM scrobbling issue. I have just kept the “main artist”, which can be a somewhat arbitrary decision. This is ok, as I am used to it due to the limitations of LFM’s database.
Where the album is a collaboration I have multitags at the [AlbumArtist] level. This results in both artists being in the Artists index, which is great.
However this arrangement has unfortunate consequences with respect to the Contributing Artists index.
The track is not included in the non-main collaborator’s index node, ie. the one now missing from the [artist] tag.
If the collaborator is never a “main artist” (ie. appears nowhere in an [artist] tag, the artist is completely missing from the Contributing Artists index.
Would it be possible to continue to index the track in the Contributing index under all artists from the [artist] tag, but to also add any of the [AlbumArtist] entries which were not already found in the [Artist] tag?
Ian Macdonald
> I removed a some of my multi-tags at the [artist] level due to the LFM
> scrobbling issue. I have just kept the "main artist", which can be a
> somewhat arbitrary decision. This is ok, as I am used to it due to the
> limitations of LFM's database.
Are you referring to this:
artist=Foo; Bar
or this:
artist=Foo
artist=Bar
If the latter, what's the Last.fm issue with that? Only one will be
scrobbled, but maybe that can be controlled. Which does Sonos use? Only
the first? Only the last? An arbitrary tag from the set?
> Where the album is a collaboration I have multitags at the [AlbumArtist]
> level. This results in both artists being in the Artists index, which is
> great.
>
> However this arrangement has unfortunate consequences with respect to the
> Contributing Artists index.
>
> The track is not included in the non-main collaborator's index node, ie. the
> one now missing from the [artist] tag.
>
> If the collaborator is never a "main artist" (ie. appears nowhere in an
> [artist] tag, the artist is completely missing from the Contributing Artists
> index.
>
> Would it be possible to continue to index the track in the Contributing
> index under all artists from the [artist] tag, but to also add any of the
> [AlbumArtist] entries which were not already found in the [Artist] tag?
The union of the two sets?
How does it work for the local library? Does Contributing Artists
include both artist and album artist, or just artist?
Regardless of what Sonos might have done, it doesn't seem logical to me
to include album artist in the contributing artist index. Otherwise,
you'd get things like 'Various Artists' as a contributing artist, which
is just noise in an already busy index.
Ian
--
Ian Macdonald | Very few things happen at the right time,
i...@caliban.org | and the rest do not happen at all. The
http://caliban.org/ | conscientious historian will correct these
| defects. -- Herodotus
|
Barry Mossman
> Are you referring to this:
>
> artist=Foo; Bar
>
> or this:
>
> artist=Foo
> artist=Bar
>
I have never looked into a track with a binary viewer. MediaMonkey displays
and makes me create them as a semi-colon separated set, but I don't know
what is actually stored inside the track.
The problem I had is that sonospy put a multi-[artist] track on the queue
with the semi-colon still in place. This is what then gets scrobbled to LFM.
I don't want that. I am happy (arbitrarily) deciding who the "main" artist
is, given that LFM has the limitation that it won't attribute the play to
multiple individual artists in the case of collaboration.
>
> If the latter, what's the Last.fm issue with that? Only one will be
> scrobbled, but maybe that can be controlled. Which does Sonos use? Only
> the first? Only the last? An arbitrary tag from the set?
>
Sonos use the last from the set. I had tagged to take advantage of that.
I am ok with going back to single [artist] tags, if that is what it takes to
keep scrobbling the same way that I have done in the past.
>
> The union of the two sets?
>
> How does it work for the local library? Does Contributing Artists
> include both artist and album artist, or just artist?
>
Yes, the union.
In Sonos, contributing artist just gets the last, or only, named artist in
[Artist}.
I am suggesting that contributing artists should contain all artists who
contribute, ie. the union of [artist] and [albumartist].
>
> Regardless of what Sonos might have done, it doesn't seem logical to me
> to include album artist in the contributing artist index. Otherwise,
> you'd get things like 'Various Artists' as a contributing artist, which
> is just noise in an already busy index.
>
I hadn't thought of "Various Artists", but after thinking of it I still make
the request.
The downside is that Contributing Artists gets one further node.
The upside is that the Contributing Artists index doesn't have any holes in
it, as would happen in the case of a collaboration album (eg. "Raising Sand"
by Robert Plant and Allison Krause) where both are mentioned in
[AlbumArtist], but the {Album] tag only says Robert Plant.
I want the track scrobbled to Robert Plant, for the arbitrary reason that I
see it as one of my Robert Plant albums, having none by Allison Krause, nor
any interest in getting any. ... however I still would like to see Allison
Krause in the Contributing Artists index.
It would come in handy in other situations. Take Miles Davis. He worked with
Gil Evans for a number of lps (Gil was the arranger, and had a big
influence). I probably don't see Gil as belonging in the {artist] tag, but
it would be good to be able to get to his albums via the Contributing index.
The new Gil Scott-Heron album may another example?
> --
> You received this message because you are subscribed to the Google Groups
> "Sonospy Development" group.
> To post to this group, send email to sonosp...@googlegroups.com.
> To unsubscribe from this group, send email to sonospy-
> devel+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sonospy-devel?hl=en.
Ian Macdonald
> I have never looked into a track with a binary viewer. MediaMonkey
> displays and makes me create them as a semi-colon separated set, but I
> don't know what is actually stored inside the track.
I think it's important to know, because Sonos may not treat them the
same.
> > If the latter, what's the Last.fm issue with that? Only one will be
> > scrobbled, but maybe that can be controlled. Which does Sonos use? Only
> > the first? Only the last? An arbitrary tag from the set?
>
> Sonos use the last from the set. I had tagged to take advantage of that.
Sonos may not use the last of the set when there are multiple identical
tag keys. I suspect your files physically use the semi-colon, rather
than multiple tags. Maybe this can even be selected in the preferences.
You should download the open-source FLAC tools and inspect a file with
metaflac --list. Then you'd know for sure.
> In Sonos, contributing artist just gets the last, or only, named artist in
> [Artist}.
And nothing from albumartist?
> I hadn't thought of "Various Artists", but after thinking of it I still make
> the request.
>
> The downside is that Contributing Artists gets one further node.
One further node in every case where albumartist != artist. That could
be a lot of extra nodes.
For me, though, it's not the number. It's simply illogical. I'm afraid
I'm going to have to disagree with you here. I suppose it had to happen
eventually. :-)
> The upside is that the Contributing Artists index doesn't have any
> holes in it, as would happen in the case of a collaboration album (eg.
> "Raising Sand" by Robert Plant and Allison Krause) where both are
> mentioned in [AlbumArtist], but the {Album] tag only says Robert
> Plant.
The album is credited to 'Robert Plant and Allison Krause', so I would
personally choose to scrobble as such. After all, the album isn't by
Robert Plant or Allison Krause or even by both in their individual
capacities; it's by Robert Plant AND Allison Krause as a logical unit.
At the very least, I would include two artist tags in this case.
artist=Robert Plant
artist=Allison Krause
If you want a particular one to be scrobbled and you're sure Sonos
always picks the last, put that one last. It's still a hack, though,
because relying on a particular tag to be last is relying on an
implementational detail that could change.
> I want the track scrobbled to Robert Plant, for the arbitrary reason
> that I see it as one of my Robert Plant albums, having none by Allison
> Krause, nor any interest in getting any. ... however I still would
> like to see Allison Krause in the Contributing Artists index.
Then it seems logical to me to include her with an artist tag (not the
last one, obviously, if that's the one that scrobbles) and have the
albumartist tag say 'Robert Plant'.
I do understand your motivation, but the problem is that it is
arbitrary, as you admit. I would scrobble that album as being by 'Robert
Plant and Allison Krause', because a) it's credited as such and b) it's
not a solo album by either. Both artists feature heavily on the album.
I think we should make it possible for users with arbitrary requirements
to work with or around the software to get what they want. I don't, on
the other hand, believe that Sonospy should exhibit arbitrary behaviour
itself.
> It would come in handy in other situations. Take Miles Davis. He
> worked with Gil Evans for a number of lps (Gil was the arranger, and
> had a big influence). I probably don't see Gil as belonging in the
> {artist] tag, but it would be good to be able to get to his albums via
> the Contributing index.
I think this is logically different yet again. It sounds like you need:
arranger=Gil Evans
and a separate policy for how it's dealt with. :-)
Perhaps what you really need, then, is this:
contributing_artists=artist,albumartist,arranger,composer,producer
but we have to be careful not to go ape-shit with new tags, because they
all need a column in the database.
Whatever rules we decide have to work for everyone. Ultimately, that may
mean they work for no-one. I'm hoping there's some middle ground we can
aim for.
If in doubt, make the area of disagreement configurable, is one of my
maxims. Of course, I can afford to be liberal with the free time of
others.
> The new Gil Scott-Heron album may another example?
I just credit it as it's credited on the spine. Again, when I need to
diverge for display purposes, I use albumartist.
And, no matter what I do, Last.fm's spelling correction kicks in and
does what it has learnt to do, so my choice may get overruled, anyway.
Yes, I know I can turn it off, but it's useful for finding genuine
typos.
Tricky stuff. I'm glad we have a mailing list to discuss it. :-)
Ian
--
Ian Macdonald | If there is a wrong way to do something,
i...@caliban.org | then someone will do it. -- Edward A.
http://caliban.org/ | Murphy Jr.
|
|
BarryM
some time, when I have more free time.
Before getting into the wider issue, can you elaborate on this point
for me please?
>
> One further node in every case where albumartist != artist. That could
> be a lot of extra nodes.
>
there will be only one node created. It will be "Various Artists".
Inside that single node will be all the tracks.
I don't understand where the "lot of extra nodes" could be coming
from.
I can understand that there will be extra ones, but most of these will
be wanted (ie. one of the [AlbumArtists] are not mentioned in [Artist]
for some reason. Most of this will be positive, and will correct for
tagging errors.
The unwanted one, will be the catch-all name used for composite album
("Various Artists" in my case). ... Unless you are saying that you
have various catch names?
I understand that you have other issues with the proposal, but I am
pressed for time to advance my case at the moment. ... I will do so
tomorrow, after u think about it a bit more.
But can we just address this issue prior to that please?
BarryM
>
> I understand that you have other issues with the proposal, but I am
> pressed for time to advance my case at the moment. ... I will do so
> tomorrow, after u think about it a bit more.
>
Changes the meaning a bit doesn't it? :-)
Barry Mossman
> > I have never looked into a track with a binary viewer. MediaMonkey
> > displays and makes me create them as a semi-colon separated set, but I
> > don't know what is actually stored inside the track.
>
> I think it's important to know, because Sonos may not treat them the
> same.
>
OK, I will get the tool.
I did look at a track via Winamp, TagScanner, dBpoweramp & MediaMonkey a few
days ago.
The same track, and at least one of them (can't remember which) showed the
tags as being separate individual [artist] tags, while the others showed
just one artist, semi-colon separated, tag.
I will find out what is physically in there, and get back to you.
I am guessing that it is separate [artist] tags, and that the UI designers
found it easier to present as a token separated list. Easier than a stack,
where the punter had to press an "add" button to create another entry box,
or press a "delete" button. ... The UI programmer would just parse the list
from the single UI control, and build the tags are required.
Ian Macdonald
> Before getting into the wider issue, can you elaborate on this point
> for me please?
>
> > One further node in every case where albumartist != artist. That could
> > be a lot of extra nodes.
>
> If I have a bunch of albums whose [AlbumArtist] is Various Artists,
> there will be only one node created. It will be "Various Artists".
> Inside that single node will be all the tracks.
>
> I don't understand where the "lot of extra nodes" could be coming
> from.
Sorry, my statement was so badly worded that it was incorrect. I meant
"every case where albumartist != artist AND albumartist doesn't
pre-exist".
> I can understand that there will be extra ones, but most of these will
> be wanted (ie. one of the [AlbumArtists] are not mentioned in [Artist]
> for some reason. Most of this will be positive, and will correct for
> tagging errors.
That depends on how albumartists is being used. If it's used for
descriptive grouping, e.g. Various Artists or Soundtracks, it makes no
sense to me for the content of the tag to find its way to Contributing
Artists.
> The unwanted one, will be the catch-all name used for composite album
> ("Various Artists" in my case). ... Unless you are saying that you
> have various catch names?
I don't, but I can easily envisage that being the case.
Since the whole purpose of albumartist is for filing and display
purposes, not to supersede the actual artist, I think we need to be wary
of logical categories (i.e. non-artist names) being propagated to
Contributing Artists, where they really don't belong. That index is only
intended for actual artists, which is why Sonos ignore albumartist when
populating it.
> I understand that you have other issues with the proposal, but I am
> pressed for time to advance my case at the moment. ... I will do so
> tomorrow, after u think about it a bit more.
>
> But can we just address this issue prior to that please?
Sure. Don't worry. I'm sure Mark won't do anything sneaky while you're
sleeping. :-)
I'm sure he's reading this and getting a headache from imagining how
he'd have to translate these complex relationships into code. Some of
this is hard enough to discuss in unambiguous English. :-)
Ian
--
Ian Macdonald | ... with liberty and justice for all ...
i...@caliban.org | who can afford it.
http://caliban.org/ |
|
|
Ian Macdonald
Freudian slip. :-)
I took it at face value, i.e. "After you think about this, you'll be
closer to realising I'm right and I'll have less convincing to do
tomorrow."
Ian
--
Ian Macdonald | When we talk of tomorrow, the gods laugh.
i...@caliban.org |
http://caliban.org/ |
|
|
Ian Macdonald
> On Tue 26 Apr 2011 at 05:35:02 -0700, BarryM wrote:
>
> > The unwanted one, will be the catch-all name used for composite album
> > ("Various Artists" in my case). ... Unless you are saying that you
> > have various catch names?
>
> I don't, but I can easily envisage that being the case.
And no sooner do I write that, than I see this posting on the Sonos
forums:
http://forums.sonos.com/showthread.php?p=130327#post130327
This is an extreme case, i.e. abuse of albumartist to store the genre,
but it illustrates that we can't make the assumption that albumartist is
being used the way we might be inclined to use it.
Ian
--
Ian Macdonald | Too many people are thinking of security
i...@caliban.org | instead of opportunity. They seem more
http://caliban.org/ | afraid of life than death. -- James F.
| Byrnes
|
Ian Macdonald
> I am guessing that it is separate [artist] tags, and that the UI
> designers found it easier to present as a token separated list. Easier
> than a stack, where the punter had to press an "add" button to create
> another entry box, or press a "delete" button. ... The UI programmer
> would just parse the list from the single UI control, and build the
> tags are required.
Yes, but then you need to be able to embed a literal semi-colon somehow.
How do you do that? The UI may be simpler (debatable), but the parser
will be more complex (although the user won't be affected).
Sometimes, you just need to know how the implementor has chosen to do
things at the physical level.
You can get the FLAC tools here:
dbPowerAmp will have been linked with these libraries, but the
stand-alone tools are the authority on what's actually in your files.
Ian
--
Ian Macdonald | "Your butt is mine." -- Michael Jackson,
i...@caliban.org | Bad
http://caliban.org/ |
|
|
Mark Henkelis
collected/used. From the discussions I've read it looks like it may not
be quite what is expected.
Barry Mossman
Adds lots of light. I will send you a treatise on the subject in due time.
:-)
In the meantime is this a typo (is there such a thing as AlbumArtistAlbum ?)
Also, in the case where use_albumartist is not set, is "ArtistAlbum" what I
call [Artist] ?
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
For the artist index:
* If use_albumartist is set in the ini (the default in the code is
false, the default ini has it set to true), the artist index is populated
with unique albumartist entries from AlbumartistAlbum (remember blank ones
will have been populated from artist in movetags).
* If use_albumartist is not set, the artist index is populated with
unique artist entries from ArtistAlbum.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Mark Henkelis
Album, one of the early design decisions that allows simple querying
rather than multiple joins. It's a physical table rather than a foreign
key relationship. AlbumartistAlbum is the same for Albumartist and Album.
The Artists table holds artist and albumartist together in their
concatenated form in a single record, ArtistAlbum and AlbumartistAlbum
hold each individual entry in artist and albumartist respectively. So
ArtistAlbum can be used to represent Artist (but also to find the
relevant albums), and AlbumartistAlbum can be used to represent Albumartist.
Barry Mossman
expected it, and I didn't want to disappoint you. :-)
Who is the Artist?
------------------
In the case of Raising Sand by Robert Plant and Allison Krause.
For me they were just ships which passed in the night. They only released
one album together. They may never release another album together. They have
each subsequently released a new album, this time with other collaborators,
and without any mutual involvement.
For this reason I don't see "Plant & Krause", or any similar joint variant,
as an artist.
IMO the album belongs in any Alison Krause node, as well as in the Robert
Plant node. A "Plant & Krause" node would just be noise in the index.
The situation is even more complex in a jazz or classical music context. In
jazz the whole point is improvisation, and people drift in and out of
collaborations to spice up the mix. Early in a person's career, they may be
of little note, and probably don't appear in the tags at all. Later when
they develop a body of work, the tagger may promote them up to the status of
"artist", requiring retagging of albums where before they were just seen as
unnamed session players.
In a classical concerto there is usually a conductor, an orchestra, and a
soloist of note. These have to be seen as separate artists otherwise the
permutations get out of hand as conductors and soloists move about, work
with differing orchestras for example.
Sonos handling of multi-artist tracks
-------------------------------------
Scorn has been poured upon Sonos indexing and scrobbling of multi-artist
tracks.
For me what they have done seems understandable given their memory space
limitations, viz. they are processing the track for indexing purposes. They
have only one bucket for Artist name. As they read each new artist for the
track, it overwrites any prior artist for that track. When all done, they
flush the index entry, and it is case of the last man standing.
At least it is predictable, and provides a solution for a case where a track
has multiple artists, and one wants to elect a "main" one for the purposes
of LFM scrobbling.
Play counts
-----------
If Mark develops logic to accumulate play counts into his database,
hopefully his logic will handle this kind of case, such that a play of a
track from the album will add 1 play to the track entity, and also 1 to each
individual artist. If I went into his database and added up my track play
counts, I would expect that it would be less than the sum of all the artist
track play counts, due to such collaborations.
In the meantime we are stuck with LFM, which only allows for a single artist
per play. So in this case we have to make a choice (Artist1 or Artist2 or
"Artist1 & Artist2").
Sonospy compounds the issue, as it queues a multi-tagged [artist] track with
artist set to a string containing all of the artist names in a semi-colon
separated list. The play is then scrobbled to LFM with the artist set to
that value. This in not what I want to see, so if I am to make any use of
Sonospy I need to remove the multiple [artist] tags from my tracks.
What is the ARTIST index, and what is the CONTRIBUTING ARTIST index?
--------------------------------------------------------------------
Forgetting how these things are built, let's examine what they are from a
user perspective.
My view is that the Contributing index is the list of all artists who have
contributed in a way which is meaningful to the music library's tagger|user.
... It is an amalgam of major and minor artists from the POV of that user (a
minor artist being someone who contributed a track to a composite album, or
someone who made a significant contribution to an album or track, but which
who isn't the major artist on the track from the POV of the
listener|tagger). The Sonos Contributing Artist index already works in this
way, although it misses all but the last artist in a multi-tagged situation
of course. .. Being an amalgam it is a big unwieldy index.
The Artists index is a filtered view of the Contributing index. It contains
just major artists (people who own , or co-own, whole albums from the POV of
the tagger). The tagger can control this filter by including, or not
including, and artist in the [AlbumArtist] tag. Being smaller, and focused
upon the tagger's interests, it is the artist index of choice.
That is how I see them. It seems illogical to me that an artist could be in
the Contributing index, but not be represented in the Artist index. While
one is forced to drop minor artists from the [artist] tag to direct
scrobbles to the desired artist, it is unfortunate that this then corrupts
the Contributing Artist index.
For this reason I think that there is a case to be made that the
Contributing index should be built from the union of the [Artist] and {Album
Artist] tags.
Benefits:
* auto-corrects any tagging errors where an artist is in the [albumartist]
tag, but missed from the [artist] tag due to any reason, including user
error.
* allows somebody (me :-)) to control whom the track is scrobbled for (ie.
have both artists in [Albumartist], but only the scrobble artist in [artist]
Problems:
---------
* the contributing artist will have one extra node for the tagger's
[albumartist] placeholder of composite albums (eg. "Various Artists"). ....
If a tagger has a mix of placeholders, there could be more than one extra
node. I don't see this as any big deal. The last time I looked my
contributing artist count was over 1,500, so one or two extra is no major
obstacle IMO. ... If someone decided to add grouping tags to their track's
[artist] tag (eg. "Classical"), they are doing this for the very purpose of
creating a node in the Artists index. Why would it be objectionable, or even
odd, for the same node to appear in the Contributing Artists index?
> Since the whole purpose of albumartist is for filing and display
> purposes, not to supersede the actual artist, I think we need to be wary
> of logical categories (i.e. non-artist names) being propagated to
> Contributing Artists, where they really don't belong.
I don't feel so strongly about this. What is problem with a couple of extra
nodes in an already huge index?
If it was seen as being objectionable there could be a
SupressFromContributingIndex list in the ini file.
> Contributing Artists, where they really don't belong. That index is only
> intended for actual artists, which is why Sonos ignore albumartist when
> populating it.
Who knows what the intention was? Maybe the intention was just to create a
filtered and more manageable list as suggested above? ... MediaMonkey has
the same general concept. They have two artist focused indices; "Album
Artist" & "Artist & Album Artist". The placeholders ("Various Artists")
appear in each.
Anyway, are you suggesting that Sonos, the people who threw away all but the
last artist in a multi-tag situation, the people who have an "i" button with
a "view tracks by this artist", within which tracks from composite albums
are invisible, ... those people, are you suggesting that they should be seen
as the arbiters of taste here? :-)
Barry Mossman
> > I have never looked into a track with a binary viewer. MediaMonkey
> > displays and makes me create them as a semi-colon separated set, but I
> > don't know what is actually stored inside the track.
>
> I think it's important to know, because Sonos may not treat them the
> same.
>
Now that Mark has produced his document is there still a point with me
proceeding with this?
It struck me that Mark is probably not looking directly into the binary
soup, but is using a class library which is probably presenting the track to
him as an object. The class library could then present the [artist] tag(s)
in whichever way the class designer thought fit, which may or may not
reflect the physical representation.
ie. if the physical representation was something like <ARTIST
name="foo"><ARTIST name="bar">, the class designer may have decided to
present these in a single field as a concatenated semi-colon separated
string.
Alternatively if the physical representation was some like <ARTIST
name="foo;bar"> the class designer may have decided to present them in an
array as a collection of artist objects.
So the physical representation is not relevant is it?
I have already seen that the same track, looked at with different tools,
displays this information as either a collection or a concatenated string
depending upon the tool chosen.
The other problem that I have is that there isn't any real easy way to
ensure that all of my multi-[artist] tracks are tagged the same way. The
tracks are from a variety of sources. Most I ripped myself, but some I
bought or acquired as digital downloads. In those cases the multi-artist
situation would have been handled according to the conventions of the
originating ripper's tool.
Ian Macdonald
> In the case of Raising Sand by Robert Plant and Allison Krause.
>
> For me they were just ships which passed in the night. They only
> released one album together. They may never release another album
> together. They have each subsequently released a new album, this time
> with other collaborators, and without any mutual involvement.
>
> For this reason I don't see "Plant & Krause", or any similar joint
> variant, as an artist.
What if they'd released two albums together? How about five? Ten? Would
that make a difference?
> IMO the album belongs in any Alison Krause node, as well as in the Robert
> Plant node. A "Plant & Krause" node would just be noise in the index.
Stretching your argument a little further, I could claim that listing
Beatles albums under Beatles is also unnecessary index bloat. I mean, we
could just list those albums under John Lennon, Paul McCartney, George
Harrison and Ringo Starr, right? If I already had solo entries for all
of those, I'd be adding no new entries to the artist index.
Forget that example; it's too far-fetched.
More importantly, there's the issue of being able to distinguish a solo
artist's albums from their collaborations with others. That's valuable
information to have, but your way of tagging discards that relationship.
Basically, I see it as a slippery slope to veer away from the way the
source material was credited. If you're going to clamber onto that
perilous slope anyway, you're going to need to have rules that cover
every single case that the software will encounter.
If you choose to accept the way the original release was credited, on
the other hand, there's nothing to think about. Someone else has done it
for you. Bingo.
For example, what to do with Ian Dury and The Blockheads? One entry
under 'Ian Dury' and another under 'The Blockheads'? The Blockheads
never recorded without Ian Dury, but they didn't perform on every Ian
Dury album either, so to have a separate entry for them would seem
totally redundant, wrong even, to me.
How would the software detect that 'Robert Plant and Allison Krause'
should be handled differently than 'Ian Dury and The Blockheads'?
> The situation is even more complex in a jazz or classical music
> context. In jazz the whole point is improvisation, and people drift in
> and out of collaborations to spice up the mix. Early in a person's
> career, they may be of little note, and probably don't appear in the
> tags at all. Later when they develop a body of work, the tagger may
> promote them up to the status of "artist", requiring retagging of
> albums where before they were just seen as unnamed session players.
I see album credits as immutable. The idea that the weight of artist B's
later work might lead to changes to the artist tags of albums by artist
A on which artist B was not a credited artist is bizarre to me.
You are bringing relativity into the game. The greater the
status/success/body of work of artist B, the more you feel he should
be tagged as an artist of an album by artist A, even if no such sleeve
credit is given on that release. Correct?
That's impossible to codify in software, because it's highly subjective.
Even if I subscribed to your way of thinking, we would still disagree
about the point at which artist B had earned the right to appear as an
artist on artist A's albums.
In fact, it's doubtful that any two people would agree or be able to
state unequivocally how their implementation of this ranking worked. I'd
even go so far as to say that the decisions you would make today
probably wouldn't match the decisions you would make five years from
now, assuming no change in the status of artist B in the public eye.
> In a classical concerto there is usually a conductor, an orchestra,
> and a soloist of note. These have to be seen as separate artists
> otherwise the permutations get out of hand as conductors and soloists
> move about, work with differing orchestras for example.
Current convention with classical music is to list the composer as the
artist, and the performer in parentheses after the album title. However,
this is anything but consistently implemented.
The classical boffins have discussed this to death. I don't have all
that much classical in my collection, so I've not had to think about it
as deeply as they have. Consequently, I was happy to defer to the fruit
of their labours:
http://wiki.musicbrainz.org/Classical_Style_Guide
> Sonos handling of multi-artist tracks
> -------------------------------------
>
> For me what they have done seems understandable given their memory
> space limitations, viz. they are processing the track for indexing
> purposes. They have only one bucket for Artist name. As they read each
> new artist for the track, it overwrites any prior artist for that
> track. When all done, they flush the index entry, and it is case of
> the last man standing.
>
> At least it is predictable, and provides a solution for a case where a
> track has multiple artists, and one wants to elect a "main" one for
> the purposes of LFM scrobbling.
I have only one comment to make here and it's that the behaviour you
describe is, AFAICT, entirely undocumented. In that sense, it's actually
unpredictable, because it could change without warning at any time.
That said, I am not expecting it to change and, as long as we don't rely
on it for anything critical (i.e. anything that cause Sonospy to
malfunction), it seems fine to make the assumption.
> Play counts
> -----------
>
> If Mark develops logic to accumulate play counts into his database,
> hopefully his logic will handle this kind of case, such that a play of
> a track from the album will add 1 play to the track entity, and also 1
> to each individual artist. If I went into his database and added up my
> track play counts, I would expect that it would be less than the sum
> of all the artist track play counts, due to such collaborations.
For tracks with multiple artist tags, this seems to make sense. I
wouldn't choose to split collaborations the way you would, but then
those wouldn't receive any special handling, so no impact.
> In the meantime we are stuck with LFM, which only allows for a single
> artist per play. So in this case we have to make a choice (Artist1 or
> Artist2 or "Artist1 & Artist2").
>
> Sonospy compounds the issue, as it queues a multi-tagged [artist]
> track with artist set to a string containing all of the artist names
> in a semi-colon separated list. The play is then scrobbled to LFM with
> the artist set to that value. This in not what I want to see, so if I
> am to make any use of Sonospy I need to remove the multiple [artist]
> tags from my tracks.
It seems that Sonospy ought to implement the Sonos behaviour here, not
necessarily as the only option, but probably as the default.
> What is the ARTIST index, and what is the CONTRIBUTING ARTIST index?
> --------------------------------------------------------------------
>
> Forgetting how these things are built, let's examine what they are from a
> user perspective.
>
> My view is that the Contributing index is the list of all artists who
> have contributed in a way which is meaningful to the music library's
> tagger|user. ... It is an amalgam of major and minor artists from the
> POV of that user (a minor artist being someone who contributed a track
> to a composite album, or someone who made a significant contribution
> to an album or track, but which who isn't the major artist on the
> track from the POV of the listener|tagger).
I agree that the Contributing Artists index should be configurable by
the user, since definitions of what constitutes a contribution of
significance can and will differ. Your definition is much more liberal
than mine, for example.
> The Artists index is a filtered view of the Contributing index. It
> contains just major artists (people who own , or co-own, whole albums
> from the POV of the tagger).
You're assuming prevalent use of the albumartist tag. Where that's not
the case, the two indices would be identical.
> The tagger can control this filter by including, or not including, and
> artist in the [AlbumArtist] tag. Being smaller, and focused upon the
> tagger's interests, it is the artist index of choice.
It's barely smaller in my case, because I don't want anything displayed
under 'Various Artists', so I use the albumartist tag only to ensure
that cases like 'The Special A.K.A.' get filed under 'The Specials',
because it's one band with two names.
Contributing Artists can't be searched, even in the local library, and I
wanted a searchable index of all artists, which is how I ended up with
everything under Artists and not using the albumartist tag very much.
> That is how I see them. It seems illogical to me that an artist could
> be in the Contributing index, but not be represented in the Artist
> index.
Huh? But you just said:
"The Artists index is a filtered view of the Contributing index."
Are you saying that this is the case with your library, but you wish it
weren't so?
> While one is forced to drop minor artists from the [artist] tag to
> direct scrobbles to the desired artist, it is unfortunate that this
> then corrupts the Contributing Artist index.
You're talking specifically about Sonospy now, right? Because you can
influence scrobbling behaviour with the local library by tagging the
scrobbled artist last.
> For this reason I think that there is a case to be made that the
> Contributing index should be built from the union of the [Artist] and
> {Album Artist] tags.
Again, I see this as a case of trying to combat an illness by treating
the symptom, not the root cause.
You shouldn't (have to) drop artists whose rightful place is in an
artist tag. Sonospy should be able to pass just the last in the series
to Sonos, which would then scrobble it to Last.fm.
If you don't make the compromise at the artist tag level, you never run
into the problem with Contributing Artists.
To my mind, the cure here is much worse than the illness. Removing the
artists from their rightful, logical place and trying to bolt them on
elsewhere will just lead to illogical and unnecessary complexity.
It would also break expected Sonos behaviour, because Sonos doesn't
place the content of albumartist in the Contributing Artists index.
> Benefits:
> * auto-corrects any tagging errors where an artist is in the [albumartist]
> tag, but missed from the [artist] tag due to any reason, including user
> error.
Except that it would auto-botch correct tagging, too, putting 'Various
Artists' into the Contributing Artists index. It's going to be hard to
convince me that that's ever acceptable.
The very purpose of the Contributing Artists index is to ignore any
collation that the albumartist tag has caused in the Artists index.
> * allows somebody (me :-)) to control whom the track is scrobbled for
> (ie. have both artists in [Albumartist], but only the scrobble artist
> in [artist]
>
> Problems:
> ---------
>
> * the contributing artist will have one extra node for the tagger's
> [albumartist] placeholder of composite albums (eg. "Various Artists").
> .... If a tagger has a mix of placeholders, there could be more than
> one extra node. I don't see this as any big deal.
I see the addition of anything to Contributing Artists that is not an
actual artist, but some kind of grouping or abstraction, as a violation
of the purpose of the index and something to be avoided at all costs.
It doesn't matter to me whether 1 new node would be added or 1000. They
don't belong there and to allow them by default is poor design, IMHO.
Now, I'm not about to deny my fellow man his right to do something
entirely inappropriate, which is why I suggested making this
configurable. To recap:
contributing_artists=artist,albumartist,arranger ...
However, I have to ask the question again: wouldn't you just prefer to
have Sonospy pass the final artist tag to Sonos for scrobbling? If so,
we can agree.
Even if we agree on that, having the content of Contributing Artists be
configurable might still be a useful feature to have, just for those
users who are hell-bent on using it for some other purpose.
> If someone decided to add grouping tags to their track's [artist] tag
> (eg. "Classical"), they are doing this for the very purpose of
> creating a node in the Artists index. Why would it be objectionable,
> or even odd, for the same node to appear in the Contributing Artists
> index?
It wouldn't, but your proposal doesn't prevent the opposite from
happening, namely the propagation of groupings (such as 'Various
Artists') that are explicitly not intended to make their way into the
Contributing Artists index.
If you had a proposal that caused propagation to happen when you wanted
it to, but did not cause it to happen when it wasn't desirable, I
wouldn't object so strongly; possibly not at all.
You even agree that the propagation shouldn't occur in such cases, but
you see it as a small enough problem in your own case that you can live
with it.
For me, though, it's a fundamental design decision and I strongly feel
that Sonospy should not do this by default.
Heck, even if I agreed with the proposal in principle, I wouldn't be any
closer to agreeing to its implementation as the default, simply because
it's not the expected Sonos behaviour.
It is therefore my strong recommendation that Sonospy pass to Sonos the
last tagged artist as the artist to be scrobbled.
> > Contributing Artists, where they really don't belong. That index is
> > only intended for actual artists, which is why Sonos ignore
> > albumartist when populating it.
>
> Who knows what the intention was? Maybe the intention was just to
> create a filtered and more manageable list as suggested above?
The Sonos documentation explains:
"Contributing Artists are those who appear on individual tracks within
an album, including those on a compilation or soundtrack album."
Source:
http://www.sonos.com/support/help/3.4/en/Sonos_User_Guide/Chap07_new/Compilation_albums.htm
Given that definition, I feel that we should remain faithful to it in
the default scenario, whilst allowing other usage by configuration.
> Anyway, are you suggesting that Sonos, the people who threw away all
> but the last artist in a multi-tag situation, the people who have an
> "i" button with a "view tracks by this artist", within which tracks
> from composite albums are invisible, ... those people, are you
> suggesting that they should be seen as the arbiters of taste here? :-)
No, but your proposal is contrary to my belief that Sonospy should be a
drop-in replacement for the local library at installation time. I see
that as sacrosanct. I could be in a minority of 1, of course, and
ultimately, it's Mark's call, anyway. But this is my opinion, FWIW.
In every other case I've seen to date, you've also erred on the side of
having Sonospy follow Sonos in its default behaviour. Why not here, too?
You, the user, are the ultimate arbiter of taste and should be given
enough configuration rope with which to hang yourself. Default index
behaviour, however, should mimic Sonos as much as possible.
Ian
--
Ian Macdonald | A word to the wise is enough. -- Miguel
i...@caliban.org | de Cervantes
http://caliban.org/ |
|
|
Ian Macdonald
> > > I have never looked into a track with a binary viewer. MediaMonkey
> > > displays and makes me create them as a semi-colon separated set, but I
> > > don't know what is actually stored inside the track.
> >
> > I think it's important to know, because Sonos may not treat them the
> > same.
>
> Now that Mark has produced his document is there still a point with me
> proceeding with this?
There is, but I've saved you the bother. Sonos does NOT treat them the
same.
A single, semi-colon-separated artist tag receives no special treatment
whatsoever from Sonos.
That's as I suspected, and it explains why Sonos, when passed a similar
artist field by Sonospy, passes it unchanged to Last.fm. It's the same
code path for both local library and WMP sourced files.
> It struck me that Mark is probably not looking directly into the
> binary soup, but is using a class library which is probably presenting
> the track to him as an object. The class library could then present
> the [artist] tag(s) in whichever way the class designer thought fit,
> which may or may not reflect the physical representation.
He's using mutagen, receiving an array of artists and joining them with
semi-colons himself. Correct, Mark?
Given the discussion of artist vs. albumartist, I think Sonospy should
instead, by default, use just the last artist.
> I have already seen that the same track, looked at with different
> tools, displays this information as either a collection or a
> concatenated string depending upon the tool chosen.
Unless you know which particular abstraction is being applied by which
tool, this can lead to false assumptions; and as I've proved through
testing this evening, those various abstractions are handled differently
if you apply them literally to the files they purport to represent.
I appreciate the desire for a consistent UI across heterogenous tagging
schemes, but it's important to know what has been applied at the
physical level.
In other words, none of your artist tags actually contain any
semi-colons. :-)
Otherwise, they would be getting scrobbled.
> The other problem that I have is that there isn't any real easy way to
> ensure that all of my multi-[artist] tracks are tagged the same way. The
> tracks are from a variety of sources. Most I ripped myself, but some I
> bought or acquired as digital downloads. In those cases the multi-artist
> situation would have been handled according to the conventions of the
> originating ripper's tool.
As I said, it seems you can assume that they all contain multiple tags,
as opposed to one log semi-colon-separated tag. You would have noticed,
otherwise.
Incidentally, I could write you a script to iterate over your files and
verify this, but you'd have to have a scripting language like Perl or
Ruby installed. I don't think there's any need for this task.
Ian
--
Ian Macdonald | One of the lessons of history is that
i...@caliban.org | nothing is often a good thing to do and
http://caliban.org/ | always a clever thing to say. -- Will
| Durant
|
Mark Henkelis
> I see album credits as immutable. The idea that the weight of artist B's
> later work might lead to changes to the artist tags of albums by artist
> A on which artist B was not a credited artist is bizarre to me.
>
> You are bringing relativity into the game. The greater the
> status/success/body of work of artist B, the more you feel he should
> be tagged as an artist of an album by artist A, even if no such sleeve
> credit is given on that release. Correct?
>
> That's impossible to codify in software, because it's highly subjective.
> Even if I subscribed to your way of thinking, we would still disagree
> about the point at which artist B had earned the right to appear as an
> artist on artist A's albums.
>
> In fact, it's doubtful that any two people would agree or be able to
> state unequivocally how their implementation of this ranking worked. I'd
> even go so far as to say that the decisions you would make today
> probably wouldn't match the decisions you would make five years from
> now, assuming no change in the status of artist B in the public eye.
>
>
pointed Ian's tags at it it broke. There's basically no logic in
freeform text.
>> In the meantime we are stuck with LFM, which only allows for a single
>> artist per play. So in this case we have to make a choice (Artist1 or
>> Artist2 or "Artist1& Artist2").
>>
>> Sonospy compounds the issue, as it queues a multi-tagged [artist]
>> track with artist set to a string containing all of the artist names
>> in a semi-colon separated list. The play is then scrobbled to LFM with
>> the artist set to that value. This in not what I want to see, so if I
>> am to make any use of Sonospy I need to remove the multiple [artist]
>> tags from my tracks.
>>
>
I don't see that we're stuck with last.fm at all - I know you both rely
on it but we can record internally whatever we want, not just what we
are constrained to send to last.fm.
IIRC Ian asked me to send whatever is in the base tag to Sonos, whatever
was used to select a track in the first place. That's essentially why
you get the full list of artists. It's trivial to change that behaviour.
>
> Now, I'm not about to deny my fellow man his right to do something
> entirely inappropriate, which is why I suggested making this
> configurable. To recap:
>
> contributing_artists=artist,albumartist,arranger ...
>
>
I like this (not just because it's better than Sonos).
> It is therefore my strong recommendation that Sonospy pass to Sonos the
> last tagged artist as the artist to be scrobbled.
>
>
Have we proved that this is how Sonos works across all file formats?
> No, but your proposal is contrary to my belief that Sonospy should be a
> drop-in replacement for the local library at installation time. I see
> that as sacrosanct. I could be in a minority of 1, of course, and
> ultimately, it's Mark's call, anyway. But this is my opinion, FWIW.
>
> In every other case I've seen to date, you've also erred on the side of
> having Sonospy follow Sonos in its default behaviour. Why not here, too?
>
> You, the user, are the ultimate arbiter of taste and should be given
> enough configuration rope with which to hang yourself. Default index
> behaviour, however, should mimic Sonos as much as possible.
>
>
The only thing I'd throw in here is that we're actually mimicking WMP
behaviour and now the Sonos library......
Actually I'll throw something else in - if you look at Sonos as a piece
of hardware to play music, and you had to provide an interface to it,
would you design the Sonos interface? Would you restrict yourself to 6
indexes? I guess the bigger question is "are we constraining ourselves
to fit within the Sonos shrink wrapper for any real reason....."?
Mark Henkelis
On 27/04/11 21:21, Ian Macdonald wrote:
> On Thu 28 Apr 2011 at 01:01:31 +1000, Barry Mossman wrote:
>
>
>>>> I have never looked into a track with a binary viewer. MediaMonkey
>>>> displays and makes me create them as a semi-colon separated set, but I
>>>> don't know what is actually stored inside the track.
>>>>
>>> I think it's important to know, because Sonos may not treat them the
>>> same.
>>>
>> Now that Mark has produced his document is there still a point with me
>> proceeding with this?
>>
> There is, but I've saved you the bother. Sonos does NOT treat them the
> same.
>
> A single, semi-colon-separated artist tag receives no special treatment
> whatsoever from Sonos.
>
> That's as I suspected, and it explains why Sonos, when passed a similar
> artist field by Sonospy, passes it unchanged to Last.fm. It's the same
> code path for both local library and WMP sourced files.
>
>
>> It struck me that Mark is probably not looking directly into the
>> binary soup, but is using a class library which is probably presenting
>> the track to him as an object. The class library could then present
>> the [artist] tag(s) in whichever way the class designer thought fit,
>> which may or may not reflect the physical representation.
>>
> He's using mutagen, receiving an array of artists and joining them with
> semi-colons himself. Correct, Mark?
>
>
I am. Mutagen is returning keys with multiple values. With mutagen I can
get to the actual binary data if required.
Ian Macdonald
> I don't see that we're stuck with last.fm at all - I know you both
> rely on it but we can record internally whatever we want, not just
> what we are constrained to send to last.fm.
I'm not married to it. I use it for scrobbling and it's very nice to
have, but it's important that the tail not be allowed to wag the dog. By
that, I mean that I wouldn't want to see fundamental compromises being
made in the core of the app in order to accommodate peripheral services
that not everyone uses.
Hopefully, though, support for Last.fm can grow without having a
negative impact elsewhere.
> IIRC Ian asked me to send whatever is in the base tag to Sonos,
> whatever was used to select a track in the first place. That's
> essentially why you get the full list of artists. It's trivial to
> change that behaviour.
I asked for that, because I thought that's what Sonos did. And it does,
if that's physically what's in the tag.
However, when multiple tags are used, the content of the last one is
used (which, in an insane world, could still be a list of artists,
separated by semi-colons ;-) ).
> >It is therefore my strong recommendation that Sonospy pass to Sonos the
> >last tagged artist as the artist to be scrobbled.
> >
> Have we proved that this is how Sonos works across all file formats?
I haven't. It's the case for FLAC and therefore presumably the case for
any format that uses Vorbis tags, such as Ogg Vorbis.
ID3 is more complicated, though. I haven't tested that. Other formats,
such as WMA and AAC, would be better tested by people more familiar with
them.
They are certainly all handled by different libraries, however, so there
could very well be implementation differences between formats. Even if
Sonos uses the last tag returned to it by the library function call,
said call may not return the tags in physical order.
> Actually I'll throw something else in - if you look at Sonos as a
> piece of hardware to play music, and you had to provide an interface
> to it, would you design the Sonos interface? Would you restrict
> yourself to 6 indexes? I guess the bigger question is "are we
> constraining ourselves to fit within the Sonos shrink wrapper for
> any real reason....."?
Until such time that it becomes trivial to ditch the Sonos controllers
and use something better, I believe we are doing it for a real reason.
That reason is to maintain application behaviour from one module to the
next in the various hardware and software controllers.
I think it would be pretty bad if 'The ' were removed from artist names
in the Library tab of the DCR, but were left intact just two widgets
away in the Music Services tab. Do you disagree?
In this context, the WMP proxy appears as a kind of plug-in within the
UI of the Sonos controllers. If it behaves in subtly different ways to
the other modules around it, I think that could result in the perception
of it being rough around the edges, not ready for prime-time or
whatever.
The better the fit, the more slick it will seem to users. IMHO.
These considerations go away the moment people are able to install a new
system and jump straight in with a superior third-party controller.
Then, they're coming to the system without the baggage of other
controllers and all bets are off.
That's not yet a realistic proposition, though; although I know it's
your ambition, because the vision of a superior controller is what got
you started on Sonospy.
Ian
--
Ian Macdonald | Charity begins at home. -- Publius
i...@caliban.org | Terentius Afer (Terence)
http://caliban.org/ |
|
|
Barry Mossman
> What if they'd released two albums together? How about five? Ten? Would
> that make a difference?
>
Yes. It is arbitrary. They know that. That is why the information is held in
tags which I can edit, and not welded into the binary soup with the audio,
which I don't want to edit.
>
> For example, what to do with Ian Dury and The Blockheads? One entry
> under 'Ian Dury' and another under 'The Blockheads'? The Blockheads
> never recorded without Ian Dury, but they didn't perform on every Ian
> Dury album either, so to have a separate entry for them would seem
> totally redundant, wrong even, to me.
>
I have "Ian Drury and the Blockheads" together in the one tag, also "Captain
Beefheart and His Magic Band", but I have Buffalo Springfield appearing
under Neil Young, and also under Stephen Stills, as well as under their
group name.
Dan Auerbach from The Black Keys has released a solo album. If he releases
several more I might even try to learn and remember his name, in the
meantime it is useful that I can also find his album in the index via The
Black Keys route.
>
> How would the software detect that 'Robert Plant and Allison Krause'
> should be handled differently than 'Ian Dury and The Blockheads'?
>
I am not suggesting that the software treat these differently at all. I, the
tagger treat them differently. I want the s/w to obey consistent simple
rules.
>
> You are bringing relativity into the game. The greater the
> status/success/body of work of artist B, the more you feel he should
> be tagged as an artist of an album by artist A, even if no such sleeve
> credit is given on that release. Correct?
>
I take relativity with me wherever I go. ... So, yes correct. My tags are a
moving picture. I am always fiddling with and refining them as I change my
relationship with my music.
Take this album for instance:
http://www.cduniverse.com/images.asp?pid=8317398&style=music&image=front&tit
le=Ounaskari%2C+Markku+-+Kuara%3A+Psalms+And+Folk+Songs+CD
How do you file that? To me they are three people who collaborated on an
album, if I allowed every permutation to jam up my indices, they would
quickly become too unwieldy.
Further it is hard enough for me to remember one of these names, all of
which appear foreign to me, remembering three of them is a yard to far. I
filed the album under the first name mentioned, and just junked the rest. I
may revise that situation later if I buy albums recorded under their own
names, or they get onto my radar for some reason. ... I am supported in this
decision by www.allmusic.com They also list the album just under the first
named artist. Amazon lists it by the first two artists as individuals, not
by the collective, and they ignore the third named artist altogether. .. It
is all arbitrary IMO.
And as to sleeve credit, you just watch the sleave change if artist B ever
gains status as a major artist. He name will pop onto the sleeve for
reissues sure as eggs. A case in point is John Coltrane.
>
> That's impossible to codify in software, because it's highly subjective.
> Even if I subscribed to your way of thinking, we would still disagree
> about the point at which artist B had earned the right to appear as an
> artist on artist A's albums.
>
This is where we seem to be having a miscommunication. I don't want the s/w
to handle this complexity. I just do it via my flexible tagging style. The
s/w should just obey nice clear & consistent rules.
>
> Current convention with classical music is to list the composer as the
> artist, and the performer in parentheses after the album title. However,
> this is anything but consistently implemented.
>
> The classical boffins have discussed this to death. I don't have all
> that much classical in my collection, so I've not had to think about it
> as deeply as they have. Consequently, I was happy to defer to the fruit
> of their labours:
>
> http://wiki.musicbrainz.org/Classical_Style_Guide
>
Sonos gave me a composer index, so I ignored that recommendation. Also you
can't use the composer for [albumartist] due to recitals where a performer
records the work from several composers onto the one cd.
>
> > That is how I see them. It seems illogical to me that an artist could
> > be in the Contributing index, but not be represented in the Artist
> > index.
>
> Huh? But you just said:
>
> "The Artists index is a filtered view of the Contributing index."
>
> Are you saying that this is the case with your library, but you wish it
> weren't so?
>
No, I am saying that for me the concept of a Contributing Artist or an
Artists index should be as described. ... At the moment if an artist is
tagged in a track's [AlbumArtist], but not in [Artist] it doesn't implement
this concept.
>
> It's barely smaller in my case, because I don't want anything displayed
> under 'Various Artists', so I use the albumartist tag only to ensure
> that cases like 'The Special A.K.A.' get filed under 'The Specials',
> because it's one band with two names.
>
This is where we approach this differently. You want the index to reflect a
"reality", whereas I want it arranged for the convenience of my imperfect
memory. :-)
>
> Again, I see this as a case of trying to combat an illness by treating
> the symptom, not the root cause.
>
> You shouldn't (have to) drop artists whose rightful place is in an
> artist tag. Sonospy should be able to pass just the last in the series
> to Sonos, which would then scrobble it to Last.fm.
>
> If you don't make the compromise at the artist tag level, you never run
> into the problem with Contributing Artists.
>
Bingo! But I asked about this. Mark didn't answer (was his busy weekend at
work), and you said that Mark would have difficulty achieving what I was
wanting due to some compliance issue with WMP (or whatever the server he is
emulating). I just wanted to use Sonospy, so I just started pruning off the
multi-artist tags.
If I can keep them, but still direct my scrobble to my "arbitrary" target
artist, I am happy. Keeping consistency with Sonos (last mentioned artist)
works best for me.
>
> However, I have to ask the question again: wouldn't you just prefer to
> have Sonospy pass the final artist tag to Sonos for scrobbling? If so,
> we can agree.
>
Yes. Very much so. But I thought that the answer was No, for the reason
mentioned above, and also due to an objection about the seemingly arbitrary,
daft and undocumented nature of the Sonos behaviour.
>
> Even if we agree on that, having the content of Contributing Artists be
> configurable might still be a useful feature to have, just for those
> users who are hell-bent on using it for some other purpose.
>
I have no problem with this, but it is of no strong interest to me once I
regain control of the scrobbled artist.
>
> In every other case I've seen to date, you've also erred on the side of
> having Sonospy follow Sonos in its default behaviour. Why not here, too?
>
I would take this as a win. :-)
Barry Mossman
> Actually I'll throw something else in - if you look at Sonos as a piece
> of hardware to play music, and you had to provide an interface to it,
> would you design the Sonos interface? Would you restrict yourself to 6
> indexes? I guess the bigger question is "are we constraining ourselves
> to fit within the Sonos shrink wrapper for any real reason....."?
>
My vote is to continue to try and address these long term, heavily
requested, features within the Sonos browsers.
I think that this route is the most likely to get community uptake.
I may be blindsided on this as I have no iDevice, no smart phone, and I am
holding off getting any android device until there are proper tablets with a
proper OS. .. So I have no mobile controller other than my CR200.
The Sonos UI may be restrictive, but as Ian said in an earlier email, it has
its back door open, and you are pocking great things through that backdoor.
You hit a great many of the most requested enhancements:
* 65k+
* newly acquired music
* date release sequence
* play counts & date last played
* multi-tagged artists & genres
The UI may be restrictive, but it is reasonably attractive, it is cross
platform, and it is responsive.
A generic browser delivered facility may lose all the restrictions, but it
has a great deal of challenges and deficiencies in the other departments if
you ask me.
Ian Macdonald
> Yes. It is arbitrary. They know that. That is why the information is
> held in tags which I can edit, and not welded into the binary soup
> with the audio, which I don't want to edit.
Fair enough.
> > How would the software detect that 'Robert Plant and Allison Krause'
> > should be handled differently than 'Ian Dury and The Blockheads'?
> >
>
> I am not suggesting that the software treat these differently at all.
> I, the tagger treat them differently. I want the s/w to obey
> consistent simple rules.
We agree, then.
> > You are bringing relativity into the game. The greater the
> > status/success/body of work of artist B, the more you feel he should
> > be tagged as an artist of an album by artist A, even if no such
> > sleeve credit is given on that release. Correct?
>
> I take relativity with me wherever I go. ... So, yes correct. My tags
> are a moving picture. I am always fiddling with and refining them as I
> change my relationship with my music.
And that's a fundamental difference between us. I don't generally retag
old stuff based on new developments.
I might go back and add an albumartist tag if an artist starts to
abbreviate their name on new releases or something similar, but
that's just an abstraction. It doesn't change the immutable data
pertaining to the album, only the filing of that data for display
purposes.
> Take this album for instance:
> http://www.cduniverse.com/images.asp?pid=8317398&style=music&image=front&tit
> le=Ounaskari%2C+Markku+-+Kuara%3A+Psalms+And+Folk+Songs+CD
>
> How do you file that? To me they are three people who collaborated on an
> album, if I allowed every permutation to jam up my indices, they would
> quickly become too unwieldy.
I would use this:
artist=Markku Ounaskari/ Per Jørgensen / Samuli Mikkonen
> Further it is hard enough for me to remember one of these names, all
> of which appear foreign to me, remembering three of them is a yard to
> far. I filed the album under the first name mentioned, and just junked
> the rest. I may revise that situation later if I buy albums recorded
> under their own names, or they get onto my radar for some reason. ...
> I am supported in this decision by www.allmusic.com They also list the
> album just under the first named artist. Amazon lists it by the first
> two artists as individuals, not by the collective, and they ignore the
> third named artist altogether. .. It is all arbitrary IMO.
To me, there's nothing that suggests the second and third artists are
any less prominent than the first. They're all credited equally, so I
tag the album the same way.
> And as to sleeve credit, you just watch the sleave change if artist B
> ever gains status as a major artist. He name will pop onto the sleeve
> for reissues sure as eggs. A case in point is John Coltrane.
In such cases, I've usually seen a sticker appear on the cellophane. I
haven't observed the actual artwork change.
Regardless, though, I'd be inclined to stick with the original release.
> This is where we seem to be having a miscommunication. I don't want
> the s/w to handle this complexity. I just do it via my flexible
> tagging style. The s/w should just obey nice clear & consistent rules.
OK. I think we can put this one to bed, then.
> Sonos gave me a composer index, so I ignored that recommendation. Also
> you can't use the composer for [albumartist] due to recitals where a
> performer records the work from several composers onto the one cd.
Yes, classical music is an order of magnitude more complex.
I have no suggestion to make in this case.
> This is where we approach this differently. You want the index to
> reflect a "reality", whereas I want it arranged for the convenience of
> my imperfect memory. :-)
And we can both get what we want out of it, I think. We just need to
tread carefully where propagation of one index to another is concerned,
because that makes assumptions about how the user is using both indices.
> Bingo! But I asked about this. Mark didn't answer (was his busy
> weekend at work), and you said that Mark would have difficulty
> achieving what I was wanting due to some compliance issue with WMP (or
> whatever the server he is emulating). I just wanted to use Sonospy, so
> I just started pruning off the multi-artist tags.
No, that was because we suspected that Sonos was splitting semi-colon
separated artist tags for files in the local library, but not for WMP.
There appeared to be distinct code paths.
Having tested last night, we now know that Sonos treats artist tags
identically, whether they are from local files or served over WMP.
In short, you CAN have what you want.
> If I can keep them, but still direct my scrobble to my "arbitrary"
> target artist, I am happy. Keeping consistency with Sonos (last
> mentioned artist) works best for me.
We agree again, then.
The only thing we don't know is whether this works consistently across
all file types. Or do you happen to know? Does Sonos treat MP3 files the
same way?
> > However, I have to ask the question again: wouldn't you just prefer to
> > have Sonospy pass the final artist tag to Sonos for scrobbling? If so,
> > we can agree.
>
> Yes. Very much so. But I thought that the answer was No, for the
> reason mentioned above, and also due to an objection about the
> seemingly arbitrary, daft and undocumented nature of the Sonos
> behaviour.
Mark, do you have an opinion about this? It seems simplest to have
Sonospy follow Sonos behaviour here by default.
Ian
--
Ian Macdonald | "No job too big; no fee too big!" -- Dr.
i...@caliban.org | Peter Venkman, "Ghost-busters"
http://caliban.org/ |
|
|
Mark Henkelis
>>> However, I have to ask the question again: wouldn't you just prefer to
>>> have Sonospy pass the final artist tag to Sonos for scrobbling? If so,
>>> we can agree.
>>>
>> Yes. Very much so. But I thought that the answer was No, for the
>> reason mentioned above, and also due to an objection about the
>> seemingly arbitrary, daft and undocumented nature of the Sonos
>> behaviour.
>>
> Mark, do you have an opinion about this? It seems simplest to have
> Sonospy follow Sonos behaviour here by default.
>
>
both request (for last.fm at least, I'll have to think about the
internal scrobbler).