PDA

View Full Version : Album name



Peter Olufsen
2004-06-09, 02:27
Hi,

Is it correct that you have to make the album name unique in order to avoid that songs from two albums by two artists with the same name get mixed when browsing albums / artwork ?

If so, is this done best by adding the artist name to the album tag field ?

Thanks

dean
2004-06-09, 08:13
Hi Peter,

On Jun 9, 2004, at 2:27 AM, Peter Olufsen wrote:
> Is it correct that you have to make the album name unique in order to
> avoid that songs from two albums by two artists with the same name get
> mixed when browsing albums / artwork ?
>
> If so, is this done best by adding the artist name to the album tag
> field ?
That's right, albums are now uniquely identified by album name. I'll
file a bug against this.

-dean

Pat Farrell
2004-06-09, 11:44
At 11:13 AM 6/9/2004, dean blackketter wrote:
>That's right, albums are now uniquely identified by album name. I'll file
>a bug against this.

Wow, with all the "greatest hits" and similarly non-unique titles, I'm
amazed that this hadn't shown up earlier.

I know that book titles can not be copyrighted. I expect
that albums/LPs/CDs/ etc. titles are considered the same
by the USPTO and courts. That is why you have
to specify "Michener's" Chesapeake to find it directly.
Of course, books have ISBNs that are unique and very handy
in computer databases for exactly this.

Pat

Steve Baumgarten
2004-06-09, 12:17
> Wow, with all the "greatest hits" and similarly non-unique titles, I'm
> amazed that this hadn't shown up earlier.

I remember being burned not too long ago by a related problem: treating an
album track as the "unique" combination of the ID3 tags for album name and
track number.

This worked fine until I realized that some of my albums had tracks with
duplicate track numbers. These tracks simply didn't show up in the web
interface even though the files themselves were fine, and of course if I
created a library consisting of just 1 of the "problem" tracks, everything
would work correctly (making it somewhat frustrating to debug).

http://article.gmane.org/gmane.music.equipment.slimdevices.general/7608

I closed that posting with:

It seems to me that it would be better to use track number only for
puposes of ordering songs -- not for determining how many unique songs
are associated with each album. I'd think that album/song name would be
better and less likely to cause this kind of conflict (or "hiding", I
suppose).

In any event, nothing in the log indicated that there was a duplicate
track number issue, making the problem just slightly harder to debug
than it might have been. If I'd seen a message indicating "duplicate
track number" or something like that, I'd have saved a half hour or so
of detective work.

Basically, whatever scheme is chosen should work even if all the ID3 tags
are the same. If I have 5 files with the same artist, title and all with
the same track number, I'd still expect to see 5 files available in the
web interface -- perhaps sorted randomly, but available nonetheless.

ID3 tags are useful for categorizing and ordering; they were never
intended to be used to uniquely identify anything.

SBB

michael
2004-06-09, 15:06
"Steve Baumgarten" <sbb (AT) panix (DOT) com> writes:
....
> ID3 tags are useful for categorizing and ordering; they were never
> intended to be used to uniquely identify anything.

Well, except perhaps for the UFID tag. And arguably the MCDI at an
album level, though there are still clashes there.

Folks that use things like the musicbrainz tagger probably have tags
on their files already that indicate unique values for
song/album/artist etc. Perhaps a first pass would be to keep this sort
of data in the tag cache? Then fuzzier approaches, such as assuming
that a directory or cuesheet represents a differentiation of
artist/album or whatever, could be added from there to pick up most of
the rest of the users? (perhaps triggering our own ufid type value for
the above mentioned tag cache entries. The data content in those
entries isn't important after all, so long as it's unique within a
slimserver instance.) Just a thought.

-michael
--
"The most merciful thing in the world, I think,
is the inability of the human mind to correlate all its contents."
-H.P. Lovecraft

Steve Baumgarten
2004-06-10, 06:56
>> ID3 tags are useful for categorizing and ordering; they were never
>> intended to be used to uniquely identify anything.
>
> Well, except perhaps for the UFID tag. And arguably the MCDI at an
> album level, though there are still clashes there.

Hmm, not familiar with those, I guess they're fairly new. I was thinking
of the most common ID3 tags, e.g., Artist, Album, Title, Track.

The problem (I'm guessing) is that the server stores in a hash somewhere
something like:

$info{ $album_tag }{ $track_num_tag } = $full_path_to_mp3_file;

This conflates the need to keep track of each file in the library and its
relevant tag info with the desire to do the best job possible of
categorizing and ordering the files in the library; the result is that of
all the tracks that share the (album,track_num) tuple, only one will show
up in user interface to the library (unless perhaps you "browse folder",
in which case you're looking at the actual files on disk).

Perhaps it should be something like:

push( @{ $info{ $album_tag }{ $track_num_tag } }, $full_path_to_mp3_file );

instead, thus allowing for multiple physical files in the library to be
associated with whatever categorizing and ordering schemes are used to
create the user interface.

SBB

Rob Funk
2004-06-10, 08:10
Steve Baumgarten wrote:
> The problem (I'm guessing) is that the server stores in a hash somewhere
> something like:
>
> $info{ $album_tag }{ $track_num_tag } = $full_path_to_mp3_file;

Genre is also included in there, for some strange reason that Sean might be
able to enlighten us on; I think it even predates Dean's involvement.

> Perhaps it should be something like:
>
> push( @{ $info{ $album_tag }{ $track_num_tag } },
$full_path_to_mp3_file );

I'm not sure if a list is the best way to approach it, but I strongly agree
that hash collisions should not cause files to be dropped from the data
structure.

Each file in the library needs to be accessible in the data structure. I
was thinking that just including the full path to the file as the final
hash key in the structure would fix it.

As someone who often ends up with non-album files whose only valid tags are
Artist and Title, this keying on album and track number has been a
longstanding annoyance to me.

--
==============================| "A slice of life isn't the whole cake
Rob Funk <rfunk (AT) funknet (DOT) net> | One tooth will never make a full grin"
http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind"

Steve Baumgarten
2004-06-10, 09:35
> Each file in the library needs to be accessible in the data structure.
> I was thinking that just including the full path to the file as the final
> hash key in the structure would fix it.

My thoughts as well, though perhaps to save space, rather than using the
fully qualified path to a file, an MD5 fingerprint could be used. That way
the hash key length would be restricted to 16 bytes (128 bits) no matter
how long the path.

> As someone who often ends up with non-album files whose only valid tags
> are Artist and Title, this keying on album and track number has been a
> longstanding annoyance to me.

I haven't checked the bug database, but has this one been filed?

I wouldn't consider it a "show stopper" for 5.2, but I do think it's
important, because the current behavior can readily lead to confusion and
annoyance unless you have done a careful job of tagging your files.

If it hasn't already been filed, I'll file it.

SBB