Created attachment 2071 [details]
Proposed patch for Bug 5177

Per the comments in the forum thead below, can you clarify whether this patch also addresses requests such as bug 4584?  Will SlimServer then also recognize free-form tags in Ape, Flac, and Ogg files such as 'ComposerSort'?

If so, and if nobody can think of any potential negatives, I think many people would love to see this implemented.

http://forums.slimdevices.com/showthread.php?t=36919

The following roles are defined and returned by the contributorRoles:

'ARTIST'      => 1,
'COMPOSER'    => 2,
'CONDUCTOR'   => 3,
'BAND'        => 4,
'ALBUMARTIST' => 5,
'TRACKARTIST' => 6,

These would therefore work as sort field, too. I'm not sure what you mean by freeform tags, but any *sort tag wouldn't work. ComposerSort would.

(In reply to comment #3)
> The following roles are defined and returned by the contributorRoles:
> 
> 'ARTIST'      => 1,
> 'COMPOSER'    => 2,
> 'CONDUCTOR'   => 3,
> 'BAND'        => 4,
> 'ALBUMARTIST' => 5,
> 'TRACKARTIST' => 6,
> 
> These would therefore work as sort field, too. I'm not sure what you mean by
> freeform tags, but any *sort tag wouldn't work. ComposerSort would.
> 

Provided that Slim::Formats::FLAC::readTag returns any of the above 6 roles with 'SORT' appended, then it should work.  Could someone with a suitable library test this please?  Is the case of the tags important, or does this get normalised somewhere?

I'm not sure about ID3, which tags are used for ComposerSort etc?

I think this capability is would be very good to have, but is it approaching it in the wrong way to use the _role_ names rather than recognizing specific *SORT _tags_?  The roles names currently correspond with common tag names, so it works, but what about other tags that SlimServer may currently or in the future map to those roles?  For instance, if SlimServer mapped the tag 'PERFORMER' to the TRACKARTIST role, or 'ORCHESTRA' to BAND, then the behavior would be a little inconsistent.

(In reply to comment #5)
> I think this capability is would be very good to have, but is it approaching it
> in the wrong way to use the _role_ names rather than recognizing specific *SORT
> _tags_?  The roles names currently correspond with common tag names, so it
> works, but what about other tags that SlimServer may currently or in the future
> map to those roles?  For instance, if SlimServer mapped the tag 'PERFORMER' to
> the TRACKARTIST role, or 'ORCHESTRA' to BAND, then the behavior would be a
> little inconsistent.
> 

Has the attribute hash passed to updateOrCreate not already been through the mapping processes.  The data that's passed in is a list roles optionally with sort information for them.  As you say, at the moment, the mapping is 1:1, but if SlimServer did, say map PERFORMER to TRACKARTIST, then that same mapping should also map PERFORMERSORT to TRACKARTISTSORT.

Given the apparent mess of tagging standards, it does seem to make sense for SS to have its own internal names for metadata, to work exclusively with those internally, and to map from tag data in files to those as early as possible.

Will look at this post-7.0.

Created attachment 6247 [details]
iTunes artist sort.patch

Updated patch against 7.4.1

Requires the changes in Bug 9723

Doesn't this also require mapping these ID3v2 frames in

/server/slim/Formats/MP3.pm

so that these fields are recognized when not importing directly from the iTunes library?

Pretty sure we already support the non-standard iTunes ID3 sort frames:

	TSOP => "ARTISTSORT",
	YTSP => "ARTISTSORT",      # non-standard iTunes tag
	TSOT => "TITLESORT",
	YTST => "TITLESORT",       # non-standard iTunes tag
	'TST ' => "TITLESORT",     # broken iTunes tag
	TSO2 => "ALBUMARTISTSORT",
	YTS2 => "ALBUMARTISTSORT", # non-standard iTunes tag
	YTSC => "COMPOSERSORT",    # non-standard iTunes tag

Note: tags starting with Y are non-standard 3-character v2.3 frames.

(In reply to comment #10)
> Pretty sure we already support the non-standard iTunes ID3 sort frames:

Ok, so it looks like just TSOC is missing in SbS.  This is from id3.org regarding iTunes.

Field              v2.3/v2.4   v2.2
------------------ ---------   ----
Title Sort         TSOT        TST
Artist Sort        TSOP        TSP
Album Sort         TSOA        TSA
Album Artist Sort  TSO2        TS2
Composer Sort      TSOC        TSC

http://www.id3.org/iTunes

Good catch, I'll add that.

Thanks, Andy.  So what else is missing here?  Are these fields not supported in the iTunes Importer plugin?

From what I can tell by looking at /Slim/Formats/MP3.pm Squeezebox Server handles ID3v2 fields by mapping them to the free-form field names that might be encountered in the VorbisComment tags of Flac or Ogg files.

I see that TSOC has been mapped to COMPOSERSORT. But COMPOSERSORT is not itself supported, so the mapping ends up doing nothing.

Jim, what do you mean?  the tag is read in by the scanner but somehow fails?  i'm not following what isn't working or where the fault is.

TSOC is mapped to the scanner's internal field COMPOSERSORT, but that field has no additional meaning to the scanner, so the value is never written to the database.