AFT and file links

[Jeff Mitchell]

On Tuesday 22 April 2008, Cody Christensen wrote:
> On Monday 21 April 2008 11:53:00 am Florian Loeffler wrote:
> > Hello
> > I have posted a question into the Amarok forum a couple of days ago (
> > http://amarok.kde.org/forum/index.php/topic,15284.0.html ) and someone
> > told me I should send an email to this address.
> > So what I have asked about was the behavior of Amarok's  AFT feature
> > regarding file links. The thing is, that probably most music collections
> > will have tracks that occur on different albums but are actually
> > identical (say on the album of its first release and on a best-of
> > compilation). I personally find it not very efficient to treat these
> > files as completely independent, it is not only a waste of hard disk
> > space but also confusing since they have different statistics (e.g.
> > individual playcounts), you have to rate each one seperately and if you
> > create a smart playlist that looks for a certain pattern (labels?) you
> > may have the same song twice or more times in your playlist.
> > Therefore I was wondering if you could have all these different songs
> > point to just one common file by using soft- or hardlinks. I do not
> > exactly know how Amarok creates the unique IDs used for AFT, but since
> > all of them would contain the exact same data, they should get the same
> > unique ID, right? And this in turn would mean they have common
> > statistics? I'm not sure if the problem with the several occurences in a
> > playlist could be solved this way, though.
> > I do not know how other people think about this matter, but I think it
> > may be an interesting feature to consider for some future Amarok version.
> > Right now, however, this is only my personal curiosity, because I have
> > started to learn ruby and was thinking about useful scripts that could be
> > written for Amarok.
> >
> > Thanks
> > Florian Löffler
>
> I personally would love to see this feature of marking two songs as =.
> Sometimes you have a song that is in an album as well as in another album
> such as a sound track of a movie. If you don't want to delete one in order
> to keep the integrity of both albums it would be great to mark their stats
> (score, playcount, labels, place in playlists, etc) as equal. Also
> sometimes they would have slightly different tags such as different album
> tags and the method of marking them as equal should be able to handle that
> IMO.

This probably would not be an AFT thing.  For one thing, AFT hashes on (among 
other things) the tag of the file, so if the album is different then the hash 
will be different too.  In addition, part of the song data is used, and often 
the exact same song data is not on a best-of vs. a normal release (the volume 
is slightly different, the amount of silence in the beginning changes, etc).  
So even then it might not work.

Probably the best way to do this would be outside AFT, for another reason as 
well.  It is similar to a request some others have given us where they have 
files encoded in i.e. FLAC and MP3 for playback on their home computer vs. 
their portable device...but they want don't want to see duplicate files in 
the collection, they want to only see one (the "higher quality one", which is 
actually not easy to determine, especially comparing lossy to lossy and 
lossless to lossless).  And they want the statistics to be the same 
regardless of which one they play.  In such a case, which pretty much matches 
yours, AFT would be totally useless.

I encourage you to think about ways this could be done.  For instance, a 
collection option where files by the same artist and same song name (but 
different album) are listed once and share statistics.  But you'd also need 
to think about how the database would react to this...would you have the 
statistics table be able to have multiple Unique IDs per entry? How would it 
be updated without getting stale?  Etc.  I'm not sure that this can be done 
in a good, non-intrusive way, but if you submit a way that might work well, 
the developers could take a good hard look at it (but no guarantees)...

--Jeff