handy features from Soulseek: wishlist + mp3 quality

[frickinfrack]

Hi --

As a long-standing Soulseek user and increasingly active DC++ user, there are two features I really, really love in Soulseek that are sadly missing in DC++, and they're probably very easy to implement:

Wishlist This is a simple .cfg file containing a list of search queries that is periodically sent out over the network. That way, I can enter, say, "residents commercial" into the wishlist. Then, even if no one on the hubs I'm currently connected to has The Residents' "Commercial Album," as soon as someone logs on who *does* have it (or I log onto a hub where someone has it), I'm alerted to that fact. This feature makes Soulseek vastly handier than DC++ at the moment. I can just let it sit there running in the background and then it will tell me when the things I want are available from an online user.

MP3 Quality Info It really sucks to download an entire album only to find out that the user has cobbled it together from a bunch of collections, and that the bitrates span the full range from 96Kbps to 320Kbps. There is currently no way to know whether or not the MP3s in a given directory are at the same bitrate unless the user renames their directories to contain that info. I prefer to download MP3s that are all encoded at the same bitrate, and preferably by the same MP3 codec.

That's all I got. If DC++ incorporates these features, it will rise very near to the top of P2P apps for MP3 trading in my estimation. I'm sure many here will agree!

Thanks for the app!

Frickinfrack

[aDe]

When getting mp3s, one rule works most of the time.. bigger is better.

[frickinfrack]

When getting mp3s, one rule works most of the time.. bigger is better.

While this is true, I'd still rather dl a directory of all 160Kbps files made using Lame than a directory of 224Kbps, 256Kbps, and 320Kbps files made using God-knows-what all jumbled together.

[NattensQje]

When getting mp3s, one rule works most of the time.. bigger is better.

While this is true, I'd still rather dl a directory of all 160Kbps files made using Lame than a directory of 224Kbps, 256Kbps, and 320Kbps files made using God-knows-what all jumbled together.

I think the standard is/should be 192 kbps using Lame. I'm ONLY sharing 192 kbps albums.

Anyway if you should be able to see the codecs in search, the sharelists would be enormous, and it would take ages to load all those id3 (not that I use that) tags.. *right fusbar with the 100k mp3's?*

Sincerely
tChAd

[frickinfrack]

Hmmmmmm... somehow Soulseek is able to do this without any real impact on search bandwidth and regardless of whether the files are ID3-tagged or not...

Perhaps Nir has scored a programming coup?

[ivulfusbar]

full idtags would take loads of time in startup as mentioned in earlier posts... to much time for me, ofcourse you can cash this, but why don't you only download release-music, then you will have no problem, its old music that is stil not re-ripped that fucks up with different bitrate etc...
(and yes i have tons of old music not re-ripped, but i remove it as i or someone rips it an better way).

already now searching is one of dc++ huge disadvantages (in memory cpu), as hub grows to 1000users and more the number of search sent to a client increase dramaticly, i think dc++ has to to raise the limit between auto-search soon. i know arne would gladly accept anything that reduces
bandwidth and cpu when it comes to search, but it ain't easy. He has done a very good job so far...

So your wishlist will probably increase the amount of search sent, so it can't be implimented without raising other search-limits.


im-getting-worried-about-the-amount-of-searches-sent-and-the-cpu-it-takes-on-each-client/hub-to-process-as-all-hubs-grows-ly'ers ;))

[frickinfrack]

Ah ha... well, damn.

[GargoyleMT]

Hmmmmmm... somehow Soulseek is able to do this without any real impact on search bandwidth and regardless of whether the files are ID3-tagged or not...

You don't need a tag to determine quality, just search for the first in a series of valid mpeg frames. If it's a VBR file, it should have either a Xing header or a VBRI (FhG's largely undocumented VBR header). And if it is neither, the bitrate in the first mpeg frame should be the same as the rest of the file (unless it's an early VBR with no header).

The hard part is sending the data back with search results. As Arne pointed out to me, the results are sent via UDP, and so if you changed how the results are sent back, you'd end up confusing a lot of DC++ and NMDC clients most likely. But this is on the plate of a fair number of DC++ modders/contributors already.

[Soap]

On one hand, maximum compatibility and performance should be maintained, but it would be real nice to see extended file data on multimedia files.

Sending back extended data (ID3 tags, bit rate, picture size, etc.) would increase the bandwidth used by searches, thus decreasing performance of the network.

My idea for a ( 1/2? ) solution then is to have the extended info available only in the DcLst file. Also - DC++ should only add this extra info to the bz2 version - thus saving non DC++ users from the data worthless to them, avoiding possible compatibility issues, and allowing the compression to minimize upstream consumption.

I know this isn't nearly as handy as simply being able to see the extended info in your search results window - but I would guess that most people grab a filelist anyway when they see someone with files they like. The DC++ feature of sending filelists even if all upload slots are full also lessens the burden of putting the feature here.

[Soap]

Forgot to mention:

1: IMHO The Standard should be "lame --alt-preset cbr 256"
(VBR theoretically is superior, but at the cost of compatibility with some hardware players, and at a bit rate like 256 I'll take the Pepsi Challenge.)

2: Upstream bandwidth is the most precious commodity of any file sharing network and must be protected like the beautiful, delicate and ephemeral flower that it is.