*** 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!
_______________________________________________
Mailing list: https://launchpad.net/~linuxdcpp-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~linuxdcpp-team
More help : https://help.launchpad.net/ListHelp
