Re: [slim] Re: Duplicate Albums

2006-10-06 Thread Jack Coates
On 10/6/06, bossman <[EMAIL PROTECTED]> wrote:
Hi.  I've had a number of versions of slimserver over time, but when Iupgraded to 
6.5 and rescanned my music library, many albums (not justcompilations) suddenly show three listings for every single individualsong.  Albums are only listed once.  So, for example, if I go into analbum with 11 songs (and I've validated that there are only 11 files),
each song shows up three times for a total of 33 songs.  When I look atsong info for the dupes, they show the same path and the rest of theinfo is identical.I've clear the library and rescanned a couple times, and I get the same
effect.My SlimServer is running on Windows XP.  All of my music is under asingle directory on an external hard drive.  I don't have any playlistsand I use a tag editor to clean up the tags.>From the URL's that I see when I hover over each song in the SlimServer
interface, it makes it look like it scanned the library three timesconsecutively or something.  Hard to tell.  Any suggestions?Do you have playlists? How about iTunes or MusicMagic or similar?
-- "I spent all me tin with the ladies drinking gin,So across the Western ocean I must wander" -- traditional
___
discuss mailing list
discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss


Re: [slim] Re: Duplicate Albums

2006-09-24 Thread Johnathan Hershbaum
Hello HTH

Where do I find the  COMPILATION=1

tag

I am not seeing it in my tagger program

Thanks

Johnathan






Hello Siduhe,

Sunday, September 24, 2006, 12:04:46 AM, you wrote:

> Try setting COMPILATION=1 ?

> That is the tag (introduced around 6.3.1 I think) which seems to sort
> most people out.

> HTH





-- 
Best regards,
 Johnathanmailto:[EMAIL PROTECTED]


___
discuss mailing list
discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss


Re: [slim] Re: Duplicate albums titles from tags

2005-05-28 Thread kdf
Quoting jwgraves <[EMAIL PROTECTED]>:

> Is Slimserver truly reading the MP3 tags or does it create it's music
> database from the directory structure?

yes, it definitely does use the tags.  Only when no valid tags can be found,
will it then use something based on directory structure and matching the
patterns set in server settings, formats, Guess Tags.

> It is definitely a bug (IMHO) because when I view an artist, Slimserver
> will show an album that is not by that artist, all because in that album
> is a song title that also happens to be by the original artist. This is
> wrong and does not happen on any other music software I use (including
> portable music players).

I'd suggest that you check your tags first.  The server will look for other
contributor tags, such as composer, band, orig artist etc.  Those are included
as 'artists' for the purposes of browse by artist and more.  There is a server
setting for this under server settings, behavior (I think, might be another
tab).  The setting is Composer in Artists.  You may have to rescan (or even
wipe cache) after changing this setting to reindex all the artist info from
your songs.

If you do eventually determine that this is now happening, please do file a bug
report and attach the two files in question that highlight this effect.

cheers,
kdf

-kdf

___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss


Re: [slim] Re: Duplicate albums titles from tags

2005-05-27 Thread Josh Coalson
--- Pat Farrell <[EMAIL PROTECTED]> wrote:

> On Thu, 2005-05-26 at 16:47 -0400, ron thigpen wrote:
> > Pat Farrell wrote:
> > > The "standard" way most software on the 'net identifies a CD is 
> > > using the CDDB hash, which is not unique, neither is any rational
> > > combination of artist/album names. 
> > 
> > this is just a hash of the CD title track data isn't it?  it might
> not 
> > do the trick all by itself, but if it exists it would be a very
> strong 
> > hint.  hash/ID collisions should be reasonably rare.  but not
> everyone's 
> > tracks will have this tag.
> 
> It is not about the name or title. And it is not associated with the
> specific track/song
> 
> It is a hash calculated from the number of tracks and the length of
> each
> track. Since lots of pop/rock/country CDs have around 10 songs and
> the
> songs are about 3 minutes long each, there are a lot of collisions
> in those types of songs. In other areas, like Classical Symphonies,
> there are usually only 6 movements per Album, and there is a fair
> amount
> of variance, so you don't see that many conflicts.
> I don't know what the actual statistics are, but when you use
> any of the rippers that talk to CDDB (or freedb) to get track info,
> you see it 'frequently' pop up a selection dialog box to let
> the user resolve the collisions.

yes.  CDDB has many collisions because it's a very bad hash.
it doesn't use enough bits from the CD TOC and the hashing
formula is naive.  but there are better ones, like CDindex,
which uses most of the TOC bits and SHA-1 for the hash.  I
use a similar hash for my own collection (which uses even
more TOC bits and a slightly better message formulation).
practically speaking collisions with these hashes only occur
for CDs with identical TOCs.

  http://wiki.musicbrainz.org/wiki.pl?DiscIDCalculation

Josh




__ 
Discover Yahoo! 
Have fun online with music videos, cool games, IM and more. Check it out! 
http://discover.yahoo.com/online.html
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss


Re: [slim] Re: Duplicate albums titles from tags

2005-05-26 Thread ron thigpen

Pat Farrell wrote:

It is not about the name or title. And it is not associated with the
specific track/song


all info concerning CDDB ID acknowledged.  fit w/ what i know about it.

i'm not sure the CDDB ID is the best SS-AlbumID candidate, but i do 
think the approach has merit.


problems with using CDDB directly include all of it's warts: needs 
external access, requires writing to a track's tag data, is only best 
gathered at CD Rip time, may be missing in many files, and may not be in 
a standard tag.


what i was thinking of would be more of an analogue of that approach, 
implemented in SS.  while scanning tags, SS would look at a minimally 
sufficient amount of tag and pathname data to identify albums.  some 
rules might need to fire to use different seed data for certain variants 
(ex: if composer not null use composer, if compilation ignore artist, 
etc).  some condenation or has of this reviewed data could be stored in 
the SS DB.  it wouldn't make a good candidate Albums PK, but could prove 
useful in doing 'SELECT DISTINCT's.


it would still depend on having pretty tight tags, but that's unavoidable.

just thinking out loud.

--rt



___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss


Re: [slim] Re: Duplicate albums titles from tags

2005-05-26 Thread Pat Farrell
On Thu, 2005-05-26 at 16:47 -0400, ron thigpen wrote:
> Pat Farrell wrote:
> > The "standard" way most software on the 'net identifies a CD is 
> > using the CDDB hash, which is not unique, neither is any rational
> > combination of artist/album names. 
> 
> this is just a hash of the CD title track data isn't it?  it might not 
> do the trick all by itself, but if it exists it would be a very strong 
> hint.  hash/ID collisions should be reasonably rare.  but not everyone's 
> tracks will have this tag.

It is not about the name or title. And it is not associated with the
specific track/song

It is a hash calculated from the number of tracks and the length of each
track. Since lots of pop/rock/country CDs have around 10 songs and the
songs are about 3 minutes long each, there are a lot of collisions
in those types of songs. In other areas, like Classical Symphonies,
there are usually only 6 movements per Album, and there is a fair amount
of variance, so you don't see that many conflicts.
I don't know what the actual statistics are, but when you use
any of the rippers that talk to CDDB (or freedb) to get track info,
you see it 'frequently' pop up a selection dialog box to let
the user resolve the collisions.

Some metadata taggers store the value in the MP3/ogg/flac files,
others seem to not bother. It is really an "album" characteristic,
not a song/track characteristic. 

An additional problem is that the cddb data (and the freedb data)
is not very clean. For many albums that I've prepared,
the dialog box from CDex will show three "names" that are clearly
the same album to a person, but that have differing genres, or
punctuation of the names (all the stuff that started this thread).

Still, it is a start, and with a little careful mangling, you
could probably automate 99% of the cases.


-- 
Pat 
http://www.pfarrell.com/music/slimserver/slimsoftware.html


___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss


Re: [slim] Re: Duplicate albums titles from tags

2005-05-26 Thread ron thigpen

Pat Farrell wrote:


I haven't looked at the source recently, that is what the developers
list is about, but it sure had it when I last looked.


if true, that's good news.  any idea on how the value is set?

(happy to move the thread if this gets annoying...)

a key based on uniqueness of Artist-Album concatenation might be good 
enough once the V/A problem is addressed.



This is really a hard problem.


yeah, i understand just enough about this to see how it would be hard.

it helps that SS can probably just shoot for uniqueness _within the 
music library_ and not in the world.  also, i'm not sure uniqueness 
would need to span refreshes of the database.  for purposes of the SS 
UI, it just needs to be a pointer to a group of track files.


the issue is how to define the boundaries of these file groups based 
solely on information available in the tags (and perhaps pathname).


The "standard" way most software on the 'net identifies a CD is 
using the CDDB hash, which is not unique, neither is any rational
combination of artist/album names. 


this is just a hash of the CD title track data isn't it?  it might not 
do the trick all by itself, but if it exists it would be a very strong 
hint.  hash/ID collisions should be reasonably rare.  but not everyone's 
tracks will have this tag.


is this working any differently for those using iTunes integration?

--rt
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss


Re: [slim] Re: Duplicate albums titles from tags

2005-05-26 Thread Pat Farrell
On Thu, 2005-05-26 at 16:19 -0400, ron thigpen wrote:

> "the SQL that populates this display should be constraining by an ID 
> unique to this album"

> is there no unique album key in the SS DB schema?  that's a real 
> weakness.  i can see why it would be hard to nail down, as most audio 
> files are track-based and not album-based.

I haven't looked at the source recently, that is what the developers
list is about, but it sure had it when I last looked.

> a key based on uniqueness of Artist-Album concatenation might be good 
> enough once the V/A problem is addressed.

This is really a hard problem.
The "standard" way most software on the 'net identifies a CD is 
using the CDDB hash, which is not unique, neither is any rational
combination of artist/album names. While most people
don't have duplicate copies of CDs on their shelves (For some
reason, I have half a dozen where I forgot that I bought it already)
if you look at any large collection, you will see "identical"
CDs that are different. Due to lots of reasons, sometimes
they even have differing UPC codes, shorter or longer songs, etc.

Kinda like how we identify people by their "name" when
we know that "Pat Farrell" is hardly unique.

One of the beauties of moving SS 6.* to using Sql is that
you don't need a solution that is 100% applicable out of the box.
Special cases can be handled special.


-- 
Pat 
http://www.pfarrell.com/music/slimserver/slimsoftware.html


___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss


Re: [slim] Re: Duplicate albums titles from tags

2005-05-26 Thread ron thigpen

i wrote too quickly.  to be more precise, i should have said:

"the SQL that populates this display should be constraining by an ID 
unique to this album"


cdfreak wrote:

But if you constrain by both album and artist, you'll have 10-15 of each
compilation cd, and some soundtracks. In this case, you'd need to have a
tag specified for "cdartist" (Various Artists) or to somehow note that
it is a compilation cd or multiple artist album.


you're right.  various artists albums are a special case.  SS needs to 
deal with this case generally.  once that is done, then it should take 
care of this case as well.


it seems like a workable approach to this problem should already exist.
do the standard tagging systems have a marker for compilations?  how do 
other library management and playback applications deal with issue?



Or, you could rename the album to be more than just the common name,
like Footsteps to be Artist - Footsteps. But this would make displaying
look rather poor when it says "Miles Davis - Footsteps by Miles Davis".


could work, but seems a horrible hack.


There's not a very easy solution from a database perspective without a
field that is album unique. If it doesn't come from the id3 tag it
needs to come from the file/folder location.


is there no unique album key in the SS DB schema?  that's a real 
weakness.  i can see why it would be hard to nail down, as most audio 
files are track-based and not album-based.


a key based on uniqueness of Artist-Album concatenation might be good 
enough once the V/A problem is addressed.



Going by *folder* giving each "folder" an ID# in the database, [...]


any solution that relies on identifying unique albums by path is going 
to fail for users that don't follow the expected conventions.  i suppose 
it would be possible to allow user to enter custom masks to hint this 
type of interpretation.


thoughts?

--rt

___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss