PDA

View Full Version : Patch: Album Artist



Dan Sully
2005-06-01, 10:07
Here's a first run at having 'Album Artists' - this is mostly usefuly for
compilation albums, and for free-form tagging systems (ie: not ID3).

If both an ALBUMARTIST & ARTIST tag exist, the ARTIST tag will be moved to
the 'TRACKARTIST' role. Searching for "artists" - as controlled by the
"Composer in Artists" pref will only select the roles ARTIST & ALBUMARTIST.

Not sure if I want to overload the Composer In Artists pref or create another one.

-D
--
For every new fool-proof invention there is a new and improved fool.

Christian Pernegger
2005-06-01, 10:18
> If both an ALBUMARTIST & ARTIST tag exist, the ARTIST tag will be moved to
> the 'TRACKARTIST' role.

Great news! Not sure if it matters, but the tag has a space in it, i.
e. "ALBUM ARTIST"

C.

Dan Sully
2005-06-01, 10:27
* Christian Pernegger shaped the electrons to say...

>> If both an ALBUMARTIST & ARTIST tag exist, the ARTIST tag will be moved to
>> the 'TRACKARTIST' role.
>
>Great news! Not sure if it matters, but the tag has a space in it, i.
>e. "ALBUM ARTIST"

Actually it doesn't.. both WMA, and Tag & Rename with FLAC don't have a space.

What format have you seen / used a space in?

-D
--
<Nigel> Please refrain from fearing the reaper.

Robert Moser
2005-06-01, 10:36
Dan Sully wrote:
> Here's a first run at having 'Album Artists' - this is mostly usefuly for
> compilation albums, and for free-form tagging systems (ie: not ID3).

Is the intent here to be able to use ALBUMARTIST in a title format
string? If so, there may be a problem where ALBUM and ARTIST match
against that rather than the single ALBUMARTIST attribute.

In other words instead of "TITLE by ALBUMARTIST from ALBUM" giving you
"Dancing Queen by ABBA from Gold" you could end up with "Dancing Queen
by GoldABBA from Gold"

Dan Sully
2005-06-01, 10:39
* Robert Moser shaped the electrons to say...

>>Here's a first run at having 'Album Artists' - this is mostly usefuly for
>>compilation albums, and for free-form tagging systems (ie: not ID3).
>
>Is the intent here to be able to use ALBUMARTIST in a title format
>string? If so, there may be a problem where ALBUM and ARTIST match
>against that rather than the single ALBUMARTIST attribute.
>
>In other words instead of "TITLE by ALBUMARTIST from ALBUM" giving you
>"Dancing Queen by ABBA from Gold" you could end up with "Dancing Queen
>by GoldABBA from Gold"

The intent was more for not having tons of artists with 1 track only in an
entire collection cluttering up the Artist views.

If you would like to cleanup the infoFormat code to make it not be
'write-once' code, that'd be great. I don't think that your example is valid
anyways in the real world (although I'm sure someone is doing it.) - we
should break them and make the format keys work only on word boundaries.

The infoFormat code is entirely too flexible, and has bitten us way too many times.

-D
--
<Nigel> Please refrain from fearing the reaper.

Marc Sherman
2005-06-01, 10:41
Dan Sully wrote:
> Here's a first run at having 'Album Artists' - this is mostly usefuly
> for compilation albums, and for free-form tagging systems (ie: not
> ID3).

Cool. Did you have a chance to think about my comment[0] regarding
supporting this in id3?
[0] http://bugs.slimdevices.com/show_bug.cgi?id=1463#c3

> If both an ALBUMARTIST & ARTIST tag exist, the ARTIST tag will be
> moved to the 'TRACKARTIST' role. Searching for "artists" - as
> controlled by the "Composer in Artists" pref will only select the
> roles ARTIST & ALBUMARTIST.

Is the TRACKARTIST role currently used anywhere in slimserver? One
thing that might be nice is a new node in the Browse Artists tree for
compilation songs (ie: any song where TRACKARTIST is the artist being
browsed, but ALBUMARTIST is something else).

- Marc

Dan Sully
2005-06-01, 10:44
* Marc Sherman shaped the electrons to say...

>Cool. Did you have a chance to think about my comment[0] regarding
>supporting this in id3? http://bugs.slimdevices.com/show_bug.cgi?id=1463#c3

I did - and would like more discussion on it. I'm really loathe to add yet
another preference toggle. But if we have to, then yes.

>>If both an ALBUMARTIST & ARTIST tag exist, the ARTIST tag will be
>>moved to the 'TRACKARTIST' role. Searching for "artists" - as
>>controlled by the "Composer in Artists" pref will only select the
>>roles ARTIST & ALBUMARTIST.
>
>Is the TRACKARTIST role currently used anywhere in slimserver? One
>thing that might be nice is a new node in the Browse Artists tree for
>compilation songs (ie: any song where TRACKARTIST is the artist being
>browsed, but ALBUMARTIST is something else).

TRACKARTIST is a new role. Could you expand on your thought? I'm not following.

The existing roles are:

ARTIST
COMPOSER
CONDUCTOR
BAND

I would be adding:

ALBUMARTIST
TRACKARTIST

Thanks.

-D
--
<iNoah> my pdp goes to 11.

Marc Sherman
2005-06-01, 10:58
I wrote:
>>
>> Is the TRACKARTIST role currently used anywhere in slimserver? One
>> thing that might be nice is a new node in the Browse Artists tree for
>> compilation songs (ie: any song where TRACKARTIST is the artist being
>> browsed, but ALBUMARTIST is something else).

Dan Sully wrote:
>
> TRACKARTIST is a new role. Could you expand on your thought? I'm not
> following.

Ok, so say I've got the following four albums in my collection:

AlbumA by BandB
TrackX
TrackY
TrackZ

AblumC by BandD
TrackN
TrackM

AlbumE by Various Artists
TrackR by BandB
TrackS by BandG

AlbumF by Various Artists
TrackT by BandB
TrackU by BandG

Then I am proposing that the (entire) Browse Artists tree be:

- Browse Artists
- BandB
- AlbumA
- TrackX
- TrackY
- TrackZ
- Compilation Tracks
- TrackR (from AlbumE)
- TrackT (from AlbumF)
- BandD
- AlbumC
- TrackN
- TrackM
- Various Artists
- AlbumE
- TrackR (by BandB)
- TrackS (by BandG)
- AlbumF
- TrackT (by BandB)
- TrackU (by BandG)

A "Compilation Track" is defined as any track where both ALBUMARTIST and
TRACKARTIST are defined, and are not identical. There are two
intersting points here:
1) the Compilation Tracks node does not appear below BandD, because
there are no compilation tracks by BandD in the library
2) BandG does not appear in the Browse Artists tree, because there are
no non-compilation albums by BandG.

> The existing roles are:
>
> ARTIST
> COMPOSER
> CONDUCTOR
> BAND
>
> I would be adding:
>
> ALBUMARTIST
> TRACKARTIST

It seems to me that you should only add one new role, not two. Having
three roles for artist is redundant. I think that adding TRACKARTIST
and repurposing ARTIST as album artist is the right way to do it for
backward compatibility, but I'm not sure about that.

- Marc

Dan Sully
2005-06-01, 11:04
* Marc Sherman shaped the electrons to say...

>1) the Compilation Tracks node does not appear below BandD, because
>there are no compilation tracks by BandD in the library
>2) BandG does not appear in the Browse Artists tree, because there are
>no non-compilation albums by BandG.

Got it now. Thanks.

>It seems to me that you should only add one new role, not two. Having
>three roles for artist is redundant. I think that adding TRACKARTIST
>and repurposing ARTIST as album artist is the right way to do it for
>backward compatibility, but I'm not sure about that.

You obviously haven't been exposed to the myriad of ways people expect to tag
their music and have it work. :)

It's possible that I could do that - the current way was done for clarity of code & tags.

I don't see any super-huge advantage though either way. Having ALBUMARTIST as
coming from the file itself means that an 'IN' query must be performed for
those two roles.

-D
--
<Nigel> Please refrain from fearing the reaper.

Dan Sully
2005-06-01, 11:20
* Jim shaped the electrons to say...

>Excuse my ignorance, but where is the patch/where do I get it? I've
>checked-out latest CVS but see no difference.

Looks like my attachement didn't go through to the forum. I just added it to the first message.

-D
--
<Nigel> Please refrain from fearing the reaper.

Jim
2005-06-01, 11:24
Excuse my ignorance, but where is the patch/where do I get it? I've checked-out latest CVS but see no difference.

Steve Bernard, Jr
2005-06-01, 11:25
On 6/1/05, Dan Sully <dan (AT) slimdevices (DOT) com> wrote:
> * Marc Sherman shaped the electrons to say...

>
> >It seems to me that you should only add one new role, not two. Having
> >three roles for artist is redundant. I think that adding TRACKARTIST
> >and repurposing ARTIST as album artist is the right way to do it for
> >backward compatibility, but I'm not sure about that.
>
> You obviously haven't been exposed to the myriad of ways people expect to tag
> their music and have it work. :)
>
> It's possible that I could do that - the current way was done for clarity of code & tags.

I, myself, would prefer the ARTIST tag to map to TRACKARTIST, that way
if I were playing that track separately via another method (like on my
portable player) the correct name would display. It would be more
compatible with the outside world instead of having an artist
displayed as "Various Artists" anywhere else.

Marc Sherman
2005-06-01, 11:26
Dan Sully wrote:
>
> You obviously haven't been exposed to the myriad of ways people
> expect to tag their music and have it work. :)

Heh. I've resigned myself to using the filesystem for all my real data
storage, and have written shell scripts to retag my mp3s as required --
so I'll adapt to whatever scheme you end up supporting, as long as you
give me _some_ way of putting AlbumArtist into an MP3. Even if it's
some new slimserver-specific tag you define.

FYI, here's how I do it:

/srv/music/
00-Various Artists
YEAR-Album Name
.genre
NN-Artist Name-Track Name
A .. Z
Artist Name
YEAR-Album Name
.genre
NN-Track Name

The /srv/music dir is my slimserver library root, and is also exported
via samba to the windows boxes on my network. The A..Z directories are
just there to keep the menu structure navigable on one screen in the
Start menu on those windows boxes. ".genre" is a text file containing
the contents of the Genre tag, so my "retag-album" script can recreate
it as needed. Conveniently, samba hides the .genre files automatically
on the windows shares.

Currently, my script tags tracks in the "00-Various Artists" subtree
with "00-Various Artists" as the artist, and "Artist Name-Track Name" as
the track name. It's a simple script change to have it put "00-Various
Artists" as the AlbumArtist, "Artist Name" as the TrackArtist, and
"Track Name" as the track name.

This structure has come in handy quite a bit lately while repairing
incorrect tags on my files. For example, I recently corrected a bunch
of incorrect years, where I'd originally tagged the album with the year
the CD was reissued, instead of the original release date. It was as
simple as renaming the dir in the file system, and running the retag script.

- Marc

Dan Sully
2005-06-01, 11:29
* Steve Bernard, Jr shaped the electrons to say...

>I, myself, would prefer the ARTIST tag to map to TRACKARTIST, that way
>if I were playing that track separately via another method (like on my
>portable player) the correct name would display. It would be more
>compatible with the outside world instead of having an artist
>displayed as "Various Artists" anywhere else.

Steve - TRACKARTIST would be used only inside the SlimServer database - and
would by dynamically set from ARTIST, only if an ALBUMARTIST tag also
existed. It would not affect your files at all for any other use.

-D
--
Welcome to hell. Here's your accordion.

Jim
2005-06-01, 11:32
Looks like my attachement didn't go through to the forum. I just added it to the first message.

Thanks, all clear now.

Looks like your other patch posted (Playlists) didn't go through to forum either: http://forums.slimdevices.com/showthread.php?t=14500

Dan Sully
2005-06-01, 11:33
* Marc Sherman shaped the electrons to say...

>Dan Sully wrote:
>>
>>You obviously haven't been exposed to the myriad of ways people
>>expect to tag their music and have it work. :)
>
>Heh. I've resigned myself to using the filesystem for all my real data
>storage, and have written shell scripts to retag my mp3s as required --
>so I'll adapt to whatever scheme you end up supporting, as long as you
>give me _some_ way of putting AlbumArtist into an MP3. Even if it's
>some new slimserver-specific tag you define.

I'm ok with using the TPE2 tag in ID3 as 'ALBUMARTIST', via a pref.

Personally I've never seen anyone use the TPE2/BAND tag for anything..

-D
--
Welcome to hell. Here's your accordion.

Steve Bernard, Jr
2005-06-01, 12:07
On 6/1/05, Dan Sully <dan (AT) slimdevices (DOT) com> wrote:
>
> Steve - TRACKARTIST would be used only inside the SlimServer database - and
> would by dynamically set from ARTIST, only if an ALBUMARTIST tag also
> existed. It would not affect your files at all for any other use.

Oh, ah, well if it doesn't make a difference to how I tag, you go
right ahead and muck about inside whichever way you want :)

-Steve

Christian Pernegger
2005-06-01, 12:42
> Actually it doesn't.. both WMA, and Tag & Rename with FLAC don't have a space.
>
> What format have you seen / used a space in?

I always try to keep to best practice as recommended by the Hydrogen
Audio folks. Apparently there was some discussion about "ALBUM ARTIST"
vs "ALBUMARTIST" in the accompanying forum thread before a consensus
was reached in favour of the space.

http://www.hydrogenaudio.org/forums/index.php?showtopic=31530

http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Encouraged_Tag_Standard s#ALBUM_ARTIST

[beware of line breaks]

Ultimately it doesn't matter - tiny details such as this are one more
reason to allow arbitrary tags in conjunction with user configurable
display / sort strings and overloading. Yeah, I know ... let a man
dream :)

C.

Robert Moser
2005-06-01, 13:13
Dan Sully wrote:
> The intent was more for not having tons of artists with 1 track only in an
> entire collection cluttering up the Artist views.
>
> If you would like to cleanup the infoFormat code to make it not be
> 'write-once' code, that'd be great. I don't think that your example is
> valid
> anyways in the real world (although I'm sure someone is doing it.) - we
> should break them and make the format keys work only on word boundaries.

I've been thinking of rewriting that code to make it more comprehensible
and possibly faster. Parsing the title format only once and re-using
the results of that parsing is central to my thinking. Along the way,
I'd also like to improve the collapsing heuristics to recognize such
things as (){}[] and ''. I don't think I have a problem with requiring
word boundaries around the data elements.

> The infoFormat code is entirely too flexible, and has bitten us way too
> many times.

Damn, I was also thinking of making it more flexible. Another thing I
was thinking of adding was the ability to plug-in additional data
elements (to make plugins like the MusicInfoSCR easier).

Dan Sully
2005-06-01, 13:19
* Robert Moser shaped the electrons to say...

>I've been thinking of rewriting that code to make it more comprehensible
>and possibly faster. Parsing the title format only once and re-using
>the results of that parsing is central to my thinking. Along the way,
>I'd also like to improve the collapsing heuristics to recognize such
>things as (){}[] and ''. I don't think I have a problem with requiring
>word boundaries around the data elements.
>
>>The infoFormat code is entirely too flexible, and has bitten us way too
>>many times.
>
>Damn, I was also thinking of making it more flexible. Another thing I
>was thinking of adding was the ability to plug-in additional data
>elements (to make plugins like the MusicInfoSCR easier).

If you can make it flexible, and readable, I'm all for that. :)

There's currently an issue that we allow people to specifiy the file format
of the album art they wish to use. Unfortunately, our track object hasn't
been created yet, so it's a bit of a catch-22. Not sure if you want to tackle that too.

I've attached a rather simplistic (yet, surprisingly useful) gutting of the
infoFormat function I did a few months ago.

-D
--
"A good messenger expects to get shot." --Larry Wall

Dan Sully
2005-06-01, 13:23
* Guy Albertelli II shaped the electrons to say...

>> I'm ok with using the TPE2 tag in ID3 as 'ALBUMARTIST', via a pref.
>>
>> Personally I've never seen anyone use the TPE2/BAND tag for anything..
>
>*raises hand*
>
>I have a lot of classical
>
>TPE1 -> soloists
>TPE2 -> orchestra / choir / other accompaniment

You would be ok with a pref toggle then? It would be global however.

>(BTW, Thanks to whoever added conductor support, now we just need TPE4 to get
>added in. My electronica collection would like it.)

This is doable. Would the Vorbis equivalent be MIXARTIST? I've also seen
MIXEDBY floating around.

-D
--
"My pockets hurt." - Homer Simpson

Marc Sherman
2005-06-01, 13:30
Dan Sully wrote:
>
> This is doable. Would the Vorbis equivalent be MIXARTIST? I've also seen
> MIXEDBY floating around.

A configurable mapping of tags -> internal slimserver properties is
beginning to look better and better, if you ask me.

- Marc

Dan Sully
2005-06-01, 13:39
* Marc Sherman shaped the electrons to say...

>>This is doable. Would the Vorbis equivalent be MIXARTIST? I've also seen
>>MIXEDBY floating around.
>
>A configurable mapping of tags -> internal slimserver properties is
>beginning to look better and better, if you ask me.

Yes - I just had a shower thought (this is incomplete, excuse the rambling):

The list of roles (tags) would be configurable, with defaults that
approximate what we have currently.

The pref 'composerInArtists' would become a list of checkboxes to show those
defined in the above pref.

x Artist
x Album Artist
x Track Artist
x Composer
x Conductor
x Band
x Mixed By

Those would also be stored as a pref, and used when browsing the collection.

Mapping ID3 tags to reasonable defaults as we have now would likely stay for round 1.

Thoughts?

-D
--
"My pockets hurt." - Homer Simpson

Dan Sully
2005-06-08, 08:09
* Dan Sully shaped the electrons to say...

>There's currently an issue that we allow people to specifiy the file format
>of the album art they wish to use. Unfortunately, our track object hasn't
>been created yet, so it's a bit of a catch-22. Not sure if you want to
>tackle that too.
>
>I've attached a rather simplistic (yet, surprisingly useful) gutting of the
>infoFormat function I did a few months ago.

Moser - any comments on this?

-D
--
<Nigel> Please refrain from fearing the reaper.

Robert Moser
2005-06-08, 08:39
Dan Sully wrote:
> * Dan Sully shaped the electrons to say...
>
>> I've attached a rather simplistic (yet, surprisingly useful) gutting
>> of the
>> infoFormat function I did a few months ago.
> Moser - any comments on this?

I'm still working on it. The simplistic version you have does no
collapsing, requires % in front of elements, and depends on the order of
the keys of %infoHash to have the longer of keys such as ARTIST and
ARTISTSORT come first. I might be able to make use of the elemLookup
function though.

Dan Sully
2005-06-08, 08:43
* Robert Moser shaped the electrons to say...

>I'm still working on it. The simplistic version you have does no
>collapsing, requires % in front of elements, and depends on the order of
>the keys of %infoHash to have the longer of keys such as ARTIST and
>ARTISTSORT come first. I might be able to make use of the elemLookup
>function though.

Right - the explicit delimiting is a feature, which should help ease the coding.

-D
--
<jwb> if only a gigantic walking octopus would come along and strangle the entire nutjob religious right

Robert Moser
2005-06-08, 10:34
Dan Sully wrote:
> * Robert Moser shaped the electrons to say...
>
>> I'm still working on it. The simplistic version you have does no
>> collapsing, requires % in front of elements, and depends on the order
>> of the keys of %infoHash to have the longer of keys such as ARTIST and
>> ARTISTSORT come first. I might be able to make use of the elemLookup
>> function though.
>
>
> Right - the explicit delimiting is a feature, which should help ease the
> coding.
>
> -D

It still doesn't help distinguish %ARTIST from %ARTISTSORT and results
in a messier looking format string:

%TRACKNUM. %TITLE (%ARTIST)
vs.
TRACKNUM. TITLE (ARTIST)

To solve the substring problem you would need to bracket the element,
which is even messier:
%TRACKNUM%. %TITLE% (%ARTIST%)

Unless of course you just bracket with non-word chars, which restricts a
bit, but isn't too bad. This results in the cleaner version above.
Requiring non-word char delimiters prevents stuff like DISC_TRACKNUM
(since _ is a word char), but I'm willing to live with that.

Dan Sully
2005-06-08, 10:37
* Robert Moser shaped the electrons to say...

>It still doesn't help distinguish %ARTIST from %ARTISTSORT and results
>in a messier looking format string:
>
>%TRACKNUM. %TITLE (%ARTIST)
>vs.
>TRACKNUM. TITLE (ARTIST)
>
>To solve the substring problem you would need to bracket the element,
>which is even messier:
>%TRACKNUM%. %TITLE% (%ARTIST%)
>
>Unless of course you just bracket with non-word chars, which restricts a
>bit, but isn't too bad. This results in the cleaner version above.
>Requiring non-word char delimiters prevents stuff like DISC_TRACKNUM
>(since _ is a word char), but I'm willing to live with that.

Yes - that works for me.

-D
--
Sir, are you classified as human?
Uhh, negative, I am a meat popsicle.

Jim
2005-08-01, 16:49
Any chance of this patch being updated to work with the current suberversion codebase?

I tried to apply manually but it appears a few things have changed.

Thanks

Dan Sully
2005-08-01, 17:01
* Jim shaped the electrons to say...

>Any chance of this patch being updated to work with the current
>suberversion codebase?
>
>I tried to apply manually but it appears a few things have changed.

Yes - I'm hoping to get this into the trunk in the next few days.

-D
--
Ya gotta love UNIX, where else do you wonder whether
you can kill a zombie spawned by a daemon's fork?

Ben Sandee
2005-08-01, 19:17
On 8/1/05, Dan Sully <dan (AT) slimdevices (DOT) com> wrote:
> * Jim shaped the electrons to say...
>
> >Any chance of this patch being updated to work with the current
> >suberversion codebase?
> >
> >I tried to apply manually but it appears a few things have changed.
>
> Yes - I'm hoping to get this into the trunk in the next few days.
>

Is there any provision for an ID3 mapping or will this be Vorbis tag only?