linuxdcpp-team team mailing list archive

[eMTee <388985@xxxxxxxxxxxxxxxxxx>]

*** This bug is a duplicate of bug 211753 ***
    https://bugs.launchpad.net/bugs/211753

** This bug has been marked a duplicate of bug 211753
   Protocol suggestion: search metadata
 * You can subscribe to bug 211753 by following this link: https://bugs.launchpad.net/dcplusplus/+bug/211753/+subscribe

-- 
Wishlist: Identical MP3s with different tags detected as alternates
https://bugs.launchpad.net/bugs/388985
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.

Status in DC++: New

Bug description:
I appreciate that this is going to be a bit unconventional and probably ultimately turned down for effort/developer interest reasons, but I for one think it would be incredibly handy.

The problem that I currently see is that many people have an MP3 for the same song, but have all attached their own tags. This happens because tagging is done quickly, easily and in some cases automatically by many software players. The result is many many different versions of each song floating around DC, often all of the same size from the same encoding source.

My solution would be to change the way MP3s are displayed in the filelist completely, and have them viewed separately. Instead of the current system of displaying the filename and TTH for an MP3, with the TTH computed on the complete file (just as any other file is done), I propose instead that the basic tag information (Artist, Song title, Album, Year, etc. for everything except embedded album art) is actually contained within the filelist itself as added pieces of information about each MP3 file. Then, when the TTH is computed by the sharing computer, it is computed on a version of each MP3 stripped of all tag and metadata information. When the song is then requested by the other user, it is then sent without any tags. The file on the sharing computer is unchanged.

This means that everyone can continue to have their own custom tags on every MP3 file, but the base file remains shareable with plenty of alternates available.

The practical issues with this:
Firstly, this will increase the size of the filelist. To save space, most MP3s share a large portion of the tag information with other MP3s in the collection (i.e. a typical mp3 will have the same artist as maybe 50 other mp3s in share, for the other works by that artist, and the same album and year as perhaps 10 others, for other songs in that album). I think in a total sense that most filelists are still very small in the big scheme of things.

Secondly, it will (perhaps greatly) increase the time needed to hash a large collection of MP3s. I don't see how this would be too much of a problem though, as most are on direct connect for not hours, but months and years at a time. 

Thirdly, a mechanism must be worked out so that an MP3 without tag information can be sent. An idea on how to do this simply would be for a new copy of the requested song to be created without tags and stored in a temporary directory somewhere, and this directory would be cleared out on DC++ close or shutdown. There should be no variation in the file hash for repeated stripping of the tags.

Fourthly, it will be a significant investment in programming to achieve this. I am personally prepared to donate a small bounty of $100 to the implementation of this in the mainstream DC++ client. It is probably an insulting amount compared to the amount of work involved, but lacking any C++ skill myself, I'm not sure how else to help the idea come to fruition. I would perhaps learn the language to implement it :)

Cheers!