SUGGESTION FOR SOULSEEK (IF POSSIBLE)? (OPINIONS)

Submitted by piccasso on Mon, 05/09/2016 - 03:24
Forums: 
Soulseek General Discussion

Hi basically i have just come to the conclusion that maybe we can upgrade only if possible and (not complaining) just trying to make an idea and possibly an easier way of finding things for hard working music collecting fanatics @ only an opition well probably has been suggested before....

Genre;
Year;

U know we have the size and also the bitrate of the tracks. why not the genre or even the years next to it?
because alot of people are lazy and dont take consideration to there music and also other artists work.

anyway that was just an idea? any thoughts? i would donate but would i get what i want that way? haha

Submitted by sammy123 on Mon, 05/09/2016 - 22:27.

Hi
I'm not sure if that helps. You surely have recognized that there are a lot of clients out there not using SLSKqt, but whatever program just capable of using the the SLSK protocol (like nicotine+ SoulSeex,......). As long as they are not providing the same info the search is still quite unreadable. AND every sharer needs to have such infos tagged (which I lack as I'm not interested when the music was created or in what of the genres it will fit. With Musicians like Frank Zappa it's even more hard to tell what genre he tapped at that very moment.
If the year was important for me (because of recording technology possible at that year) I added it to the name, but I guess I'm one of the very few who put the structure into a strict "ARTIST-{CD/LP/DAT/DVD Title}-Tracknumber-Trackname" order with no tags at all. Every one else is using at best a tracknumber-Title composition which is often not even the right (CD) order, but the cddb cue they found first. One example is "Tori Amos-Live In Denver (Bootleg, 13.04.1999)_CD1-03-Crucify.wav"
Serious collectors are different as they have to invest quite a lot of time into digitizing, manicure and order the right naming to it.
But most are so much individual that one is even writing the complete orchestra composition into the (flac) tag field, while the other one leaves the director out and puts in the most famous cello artist. I'm happy to preserve as most information as possible (when I digitized my extensive MC/DAT and LP collection), but there are limits and who knows what the next format (flac=>...) brings or takes. In twenty-five years of digital music I've lost so much information and almost no one would ever bother about it.
Cheers

Submitted by piccasso on Tue, 05/10/2016 - 01:40.

Okay but not everybody is you though, not to sound rude, but there is people out there that actually do care about when the date it was created and also the genre lol.

thanks anyway i knew it wouldnt happen its just a thought, and clearly every other option n what not has been created, just not the genre, or year. its abit odd. i think it would help soooooo many people and it would be so much reliable when searching.

and another thing nothing works with the favorute saved searches, when i search in search box it works/ odd..... mmmmmm maybe an upgrade would be substantial

Submitted by sammy123 on Fri, 05/13/2016 - 05:35.

Hi piccasso
as mentioned: a lot of sharers have not even the track name right, apart from generic (Track 1... Unknown Performer... unknown Album....) tag info's. To interpret the tags you need to go into the file itself which costs time (scanning the file for min. one time when shared, storing the info somewhere (else at every browse or search request ALL files have to be indexed again). I'm pretty sure there's a reason why Nir hasn't implemented it after such a long time. Big shares (a few hundred k Files might consume all the RAM available for 32 Bit Apps as the tag info's can be quite a lot. As older clients would have to DL such informations as well it might slow down browsing and seeking a lot I'd guess. There are a lot of traps when you have IDtagV1 (with very limited field length) or other codepages and could not index the file the way SLSKqt would need then. Afaik the current indexing is very very simple (Header Bit info) and only a few clients (working as server at the time browsing) shows them. So as long as not everyone is using the same client Version xy and all are supporting the feature it's unreliable.
Background: 12_2015 Nir fixed a bug when sharing/loading files bigger 2GB. After my last scan only 2,3% have this or above version in usage, so in 6 month only 1/50th are able to use that feature (if you do in SACD 2GB are easily reached for longer tracks). SLSK compatible clients will never be able to use the feature...
You might put a feature request into the left hand list "Feature requests", but getting SLSK into the 64Bit range (under windows+OSX) is pretty needed at the same time due to the necessary index table database of all files.
Cheers