Tagging of multi-disc sets?

[Caleb Epstein]

Does the slimserver support any sort of tag that indicates
that a given track is from disc N of an M disc compilation?
In my perfect world, all the discs of a box set (for example)
should have the same Album title, but some other tag to
distinguish one disc from another.

I know iTunes provides entry fields for this, but I'm
wondering what these tags are called and if they are
used/honored by the slimserver.

--
Caleb Epstein | bklyn . org | Love conquers all things; let us too surrender
cae at | Brooklyn Dust | to love.
bklyn dot org | Bunny Mfg. | -- Publius Vergilius Maro
| | (Virgil)

[Robert Moser II]

Caleb Epstein blurted out:
> Does the slimserver support any sort of tag that indicates
> that a given track is from disc N of an M disc compilation?
> In my perfect world, all the discs of a box set (for example)
> should have the same Album title, but some other tag to
> distinguish one disc from another.
>
> I know iTunes provides entry fields for this, but I'm
> wondering what these tags are called and if they are
> used/honored by the slimserver.
>

In the infoCacheEntry these are stored in the DISC (for the disc number)
and DISCC (for the total number of discs) fields. These are accessible
through the Slim::Music::Info::disc and Slim::Music::Info::discCount
functions. The actual info seems to come from the SET tag.

When you have such an album and you do Browse Albums it looks like this:

AlbumName (Disc DISC of DISCC)

It looks like the ALBUM information that we work from is modified to
include this (no modification of the tag). So internally, we would see
that 5 disc set as 5 albums, regardless of whether you have the ALBUM
tag set to the same thing in each of them.

[Robert Moser II]

Robert Moser II blurted out:

> Caleb Epstein blurted out:
>> I know iTunes provides entry fields for this, but I'm
>> wondering what these tags are called and if they are
>> used/honored by the slimserver.
> functions. The actual info seems to come from the SET tag.

Slight correction, in ID3v2.w the tag is TPA and in ID3v2.3 it is TPOS

[Caleb Epstein]

On Sun, Dec 14, 2003 at 06:45:11PM -0800, Robert Moser II wrote:

> In the infoCacheEntry these are stored in the DISC (for the disc
> number) and DISCC (for the total number of discs) fields. These are
> accessible through the Slim::Music::Info::disc and
> Slim::Music::Info::discCount functions. The actual info seems to
> come from the SET tag. When you have such an album and you do
> Browse Albums it looks like this: AlbumName (Disc DISC of DISCC) It
> looks like the ALBUM information that we work from is modified to
> include this (no modification of the tag). So internally, we would
> see that 5 disc set as 5 albums, regardless of whether you have the
> ALBUM tag set to the same thing in each of them.

Hm, I'm not so sure I like that particular behavior,
particularly when all of the discs form a logical unit that I
want to treat as one. Really I only care about the DISC
index as a sorting key so that Disc 2 Track 1 comes after Disc
1 Track <LAST> when I play everything back. Discs as logical
units are almost meaningless once the files are on a hard
drive.

Looking at Slim/Music/Info.pm, there is definitely code which
when faced with the SET tag, will use that as the DISC tag
and, if it looks like <number>/<number>, will set the second
number as DISCC (and reset DISC to the first number). Then
the code goes on to modify the ALBUM tag to add " (Disc
<N>)" (if DISCC is not set) or " (Disc <N> of <M>)".

If you have a lot of multi-disc sets by a single artist, this
code will make it more work to play one of them as a unit -
you'll need to go to each individual disc and add it to a
playlist, instead of just adding the entire multi-disc album
as a single unit. Do people like this behavior? Maybe it
could be made user-settable?

Anyway, attached is a patch for Slim/Formats/FLAC.pm
which maps the Ogg DISCNUMBER tag to the slimserver DISC
tag (See URL:
http://reactor-core.org/ogg-tag-recommendations.html).

By not using the ID3-ish SET tag, it skirts this
ALBUM-mangling issue. Thoughts?

The patch also includes a change to convert.conf to use
$shorten$ instead of "shorten" as was suggested by someone on
this list.

diff -ubr SlimServer_v2003-12-15.orig/Slim/Formats/FLAC.pm SlimServer_v2003-12-15/Slim/Formats/FLAC.pm
--- SlimServer_v2003-12-15.orig/Slim/Formats/FLAC.pm 2003-12-15 08:01:36.000000000 -0500
+++ SlimServer_v2003-12-15/Slim/Formats/FLAC.pm 2003-12-15 10:46:40.000000000 -0500
@@ -23,6 +23,7 @@
'DATE' => 'YEAR',
'SAMPLERATE' => 'RATE',
'TRACKLENGTH' => 'SECS',
+ 'DISCNUMBER' => 'DISC',
);

# Given a file, return a hash of name value pairs,
Only in SlimServer_v2003-12-15/Slim/Formats: FLAC.pm~
diff -ubr SlimServer_v2003-12-15.orig/convert.conf SlimServer_v2003-12-15/convert.conf
--- SlimServer_v2003-12-15.orig/convert.conf 2003-12-15 08:01:35.000000000 -0500
+++ SlimServer_v2003-12-15/convert.conf 2003-12-15 10:45:32.000000000 -0500
@@ -44,10 +44,10 @@
$lame$ --silent -b $BITRATE$ $FILE$ -

shn mp3 * *
- shorten -x $FILE$ - | $lame$ --silent -b $BITRATE$ - -
+ $shorten$ -x $FILE$ - | $lame$ --silent -b $BITRATE$ - -

shn wav squeezebox *
- shorten -x $FILE$ -
+ $shorten$ -x $FILE$ -

flc mp3 * *
$flac$ -dc $FILE$ | $lame$ --silent -b $BITRATE$ - -

--
Caleb Epstein | bklyn . org | "It's not just a computer -- it's your ass."
cae at | Brooklyn Dust | -- Cal Keegan
bklyn dot org | Bunny Mfg. |

[Dan Sully]

* Caleb Epstein <cae (AT) bklyn (DOT) org> shaped the electrons to say...

> --- SlimServer_v2003-12-15.orig/Slim/Formats/FLAC.pm 2003-12-15 08:01:36.000000000 -0500
> --- SlimServer_v2003-12-15.orig/convert.conf 2003-12-15 08:01:35.000000000 -0500

Applied and commited. Thanks!

-D
--
Minds are like parachutes... they work best when open.