A question for devs

[Vladimir Kulev]

Jeff Mitchell wrote:
> To go into a little further detail (I'm probably going to close the bug),
> the bug suggests detecting "duplicate songs" by same tags/metadata.  This
> is actually a bad idea.  Even if the tags are *exactly* the same, that
> doesn't mean the song _data_ is the same.  Maybe you have two files with
> the same tags (especially if all you have is the name of the track and the
> artist) but they are both VBR with different bit rates.  Clearly these are
> not duplicate, then.  Maybe one is live but isn't marked as such.  You
> could let the user pick which one to remove, but that gets messy.

I agree - matching metadata is a bad idea, but there IS still a problem and it 
needs some solution.

> This goes back to the use case in the bug of the person with both .flac
> and .mp3 files of the same music.  I used to do this too, and I never ran
> into any problem, because I put the .flac files and .mp3 files in separate
> but identical directory trees.  So my .flacs would be rooted
> in /mnt/music/FLAC and my .mp3s would be rooted in /mnt/music/MP3 with the
> directory trees underneath being the same.  Then you simply add one, or the
> other, to Amarok's collection (and if you want to use the .flacs and
> put .mp3s onto devices, there's always the File Browser).  If you already
> have your .flacs and .mp3s in the same directories, it's trivial to write a
> script to separate them.

I have different music sets in mp3/ogg and flac. There is no reason to convert 
lossy files to lossless and vice versa - in both cases you loose something 
important (quality or disk space and knowledge about real sound quality). Now 
you can suggest to delete lossy duplicates, but assume that you have 
mounted two separate read-only music shares (e.g. lossy and lossless)...

> #2: Delete one or the other of the files when you find them.  This doesn't
> seem like it'd happen too often.
> #3: Take the files that are duplicate, and move them into a separate place
> on your local machine that is not a part of Amarok's collection.  Then when
> you have access to the NFS share, you can get at the files there; when you
> don't, add the directory back into your collection or use the file
> browser/Konqueror to add the files to your playlist when you want.  This
> will also keep statistics sane.  In Amarok 2.0 there will be support for
> multiple local collections, which would mean that you could have these
> files in a second/third/whatever collection and simply ignore that
> collection when you have access to the local NFS mount.

I have thinked a bit and have another suggestion. In most use cases we may 
believe that files of one album is always sit in the same directory. So if 
album consists of files in different dirs, we may consider that it needs to 
be splitted. Since this happened, we can create separate album entries for 
every dir.
Also it is possible to try some heuristics for better appearance:
1) Use stricter splitting conditions - for example splitted dirs must have 
equal track count and close total playing time.
2) Find the main difference between dirs (e.g. file format or collection mount 
point) and show it in artist/collection view. This will help great.

-- 
Vladimir Kulev
http://www.lightoze.net/