mp3 bitrate

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Wisp
Posts: 218
Joined: 2003-04-01 10:58

mp3 bitrate

Post by Wisp » 2003-04-21 09:39

At this moment, the only thing I need in DC++ is an option to show the Mp3 bitrate. I only want to download >192kbps, so i have to download different files, check the bitrate, and decide if i want to keep downloading it. very annoying

Will this be added in the feature?

Wrath
Posts: 4
Joined: 2003-04-13 13:25

Post by Wrath » 2003-04-21 09:45

How can that be done?

Never heard of a filesharing prog that has that option.

Kenneth-Chile
Posts: 80
Joined: 2003-03-21 10:17
Location: Concepcion, Chile.

Post by Kenneth-Chile » 2003-04-21 12:13

Wrath wrote:How can that be done?

Never heard of a filesharing prog that has that option.


Never heard Napster, Kazaa, ,win MX? :D


Dc++ is not oriented to search and download mp3, but I think, that it only could display bitrate information when a searched file is mp3. (not to search < or > or = than a bitrate)
In Theory, there is no difference between Theory and Practice. In Practice, there is.

Wrath
Posts: 4
Joined: 2003-04-13 13:25

Post by Wrath » 2003-04-21 12:22

Heh, yeah I have heard of them but have not used them for years now, don't remember the options/functions they had. I'm a full DC (now DC++) nut. :lol:

[KUN.NL]mepmuff
Posts: 73
Joined: 2003-01-06 09:32

Post by [KUN.NL]mepmuff » 2003-04-21 16:15

The problem with these kind of things is that the files have to be opened to get that information (think of kazaa's speed when building a share-list), whereas now the only info in the filelist, is pure file information which can be read without opening them.

volkris
Posts: 121
Joined: 2003-02-02 18:07
Contact:

Post by volkris » 2003-04-21 16:29

[KUN.NL]mepmuff wrote:The problem with these kind of things is that the files have to be opened to get that information (think of kazaa's speed when building a share-list), whereas now the only info in the filelist, is pure file information which can be read without opening them.


It seriously doesn't take much time to grab the bitrate off of an mp3. It's not as if the whole file has to be read or anything...

[KUN.NL]mepmuff
Posts: 73
Joined: 2003-01-06 09:32

Post by [KUN.NL]mepmuff » 2003-04-21 16:37

True, but over loads of mp3's it adds up quickly. There was an idea in some thread to read additional file-info in the background once DC++ was up and running which would be a reasonable way of dealing with the problem.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-21 18:39

It's easy to get the information out of the file and cache it.

The problem is that there's no easy way to return this in the way other P2P applications do - in the search results. This has been suggested before, and indeed was one of the features I had in mind when starting to contribute to DC++.

For other threads, see the concept of meta-data. (Hashes can be considered a form of meta-data too.)

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-04-22 02:59

GargoyleMT wrote:It's easy to get the information out of the file and cache it.

The problem is that there's no easy way to return this in the way other P2P applications do - in the search results. This has been suggested before, and indeed was one of the features I had in mind when starting to contribute to DC++.

For other threads, see the concept of meta-data. (Hashes can be considered a form of meta-data too.)

It would be nice to also add theguessed encoder and quality just like in wincue

http://cd-rw.org/software/audio_softwar ... ncspot.cfm

The bitrate/quality/encoder guessing is allmost realtime

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-04-22 03:00

Wisp wrote:
GargoyleMT wrote:It's easy to get the information out of the file and cache it.
It would be nice to also add theguessed encoder and quality just like in wincue

http://cd-rw.org/software/audio_softwar ... ncspot.cfm

The bitrate/quality/encoder guessing is allmost realtime
i mean encspot instead of wincue

(why cant you edit ur posts here?)

mai9
Posts: 111
Joined: 2003-04-16 23:02

Re: mp3 bitrate

Post by mai9 » 2003-04-22 05:12

Wisp wrote:I only want to download >192kbps, so i have to download different files, check the bitrate, and decide if i want to keep downloading it. very annoying

Will this be added in the feature?


What about joining a high quality mp3 hub? :shock:

It couldn't be easier :wink:

leadenboy
Posts: 15
Joined: 2003-04-22 05:51
Location: Paris, France

Up with MP3 bitrate encoding!

Post by leadenboy » 2003-04-22 07:06

What about joining a high quality mp3 hub?

It couldn't be easier


Ohhhhhh yes it could.

1) Barring users with a mix of bitrates will exclude the vast majority of users. Along with them will go most of the music out there.

2) If you want to run a specialized hub, you're already limiting the potential pool of users drastically. Piling this limitation on top of it makes your hub almost sure to fail.

3) Even if you want to run such a hub, how do you know if the people trying to join are following the all-high-bitrates rule? Download all their music bit by bit?

In any case, this one feature will make DC++ *way* more attractive to a range of people. I started out using it for a while, then switched to mostly using Soulseek because downloading and sifting out low-bitrate stuff turns out to be very irritating and time-consuming.

Sorry to continue a thread that's a kind of repeat, but I think the whole techy metadata discussion has a bigger scope than necessary. A cheap hack to deal with just mp3s would be *very* widely appreciated.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-22 08:18

Wisp wrote:It would be nice to also add theguessed encoder and quality just like in encspot


Thought of that too. I know encspot is based on some other piece of code, but I long lost the url of the post in the (other) forum. Plus, encspot seems to get stuff wrong, and I don't think he's updated the fingerprinting in a while. It doesn't detect iTunes (or whatever the original app was) at least.

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Re: Up with MP3 bitrate encoding!

Post by sarf » 2003-04-22 10:07

leadenboy wrote:Sorry to continue a thread that's a kind of repeat, but I think the whole techy metadata discussion has a bigger scope than necessary. A cheap hack to deal with just mp3s would be *very* widely appreciated.


Cheap hacks, while popular, have a nasty tendency to sometimes (read: so often you'd be afraid if you knew exactly how often) turn into bug-laden, unmaintainable chunks of code that everyone wants to expand on, since "it's just a tiny, teensy bit of coding to do".

This said, programmers do not want to do cheap hacks. We (or at least I) do not want to build a chair to sit on, we want to build the Ultimate Chair, with all the features you could possibly need, the flexibility to add on what you might've forgotten when you built it and the ease of use found in a hammer.
Needless to say, we often get frustrated when people just want a comfortable chair, just because they feel eternity is a long time to wait for delivery. Fools. :)

Sarf
---
"I've realised that users are not just a good way of holding down office furniture which might otherwise blow away." - Daniel Rutter

mai9
Posts: 111
Joined: 2003-04-16 23:02

Re: Up with MP3 bitrate encoding!

Post by mai9 » 2003-04-23 06:19

leadenboy wrote:1) Barring users with a mix of bitrates will exclude the vast majority of users. Along with them will go most of the music out there.

Barring Xing from a vast majority of users, will make this world a better place to live.

leadenboy wrote:2) If you want to run a specialized hub, you're already limiting the potential pool of users drastically. Piling this limitation on top of it makes your hub almost sure to fail.

Well, imagine you could join a hub with 4TB of high quality non-duplicated mp3 (I understand high quality is lame v3.90.2 APS/APX). I feel the potential users for that hub are very huge.

What I know for sure is that a hub with crappy Xing mp3 is doomed.

leadenboy wrote:3) Even if you want to run such a hub, how do you know if the people trying to join are following the all-high-bitrates rule? Download all their music bit by bit?

Well, ops can kick :wink:


From what you write, I feel that you compare DC++ to Shareaza or any other massive p2p. DC is a complete different world. You can do things in DC that simply can't be done with other tools.

Marvin
Posts: 147
Joined: 2003-03-06 06:56
Location: France
Contact:

High quality MP3

Post by Marvin » 2003-04-23 07:14

mai9 wrote:high quality (...) mp3

Don't we call them Ogg Vorbis ? :wink:

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Re: Up with MP3 bitrate encoding!

Post by GargoyleMT » 2003-04-23 08:07

mai9 wrote:Barring Xing from a vast majority of users, will make this world a better place to live.


Try just finding some albums in non-Xing format. For instance, certain Video Game soundtracks. Of course, if most people knew it was Xing, they'd search for better copies. Same goes for incomplete/corrupt mp3s.

Yes, I have a lot of ideas - like a share manager, and coloring incomplete mp3s red so that the sharer knows they're literally bad files.

mai9 wrote:I feel the potential users for that hub are very huge.


Well, I hope that on MP3 hubs, just allowing users to easily see the quality of their files will be enough for the ones who care (read: obsessive/compulsive) to get better copies.

mai9 wrote:From what you write, I feel that you compare DC++ to Shareaza or any other massive p2p. DC is a complete different world. You can do things in DC that simply can't be done with other tools.


Like form specific topic hubs? :) There are certain benefits to DC/DC++. There are also drawbacks.

mai9
Posts: 111
Joined: 2003-04-16 23:02

Post by mai9 » 2003-04-24 04:06

which videogames' soundtracks are you looking for?


Maybe adding specific files functions in dc++ will make it slower? and if dc++ has some mp3 features, ogg users will ask the same.

btw, could dc++ build your filelist once the program is loaded? My DC++ take ages to start.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-24 07:28

mai9 wrote:Which videogames' soundtracks are you looking for?


None... Though Dragon Quest/Warrior was my specialty once. They have way over 50 albums. The real question is what video game soundtracks you're interested in. :) It's a whole themed hub. Well, I think there are two actually, but only one is public (the other is for "active" members in a forum).

mai9 wrote:Maybe adding specific files functions in dc++ will make it slower? and if dc++ has some mp3 features, ogg users will ask the same.


Well, that's why, in my mind, mp3 information is abstracted into a general meta-data interface/database. I found a program called libextractor that I thought might be nifty for extending to extract information from various file types. Something like bittorrent might be better. You could gather color depth/resolution from images, audio/video codecs from movie files, etc. with a properly extensible system.

mai9 wrote:btw, could dc++ build your filelist once the program is loaded? My DC++ take ages to start.


Mine takes a number of seconds, with my main share at least. My first thought is at least a progress bar. Yes it can be done, but I'm not sure what the best way to solve the problem is - just refresh the share when the main window comes up, or start the thread in the background, or write some additional file containing your share and load it on startup, etc.

mai9
Posts: 111
Joined: 2003-04-16 23:02

Post by mai9 » 2003-04-24 08:10

GargoyleMT previously wrote:Try just finding some albums in non-Xing format. For instance, certain Video Game soundtracks.
GargoyleMT wrote:
mai9 wrote:Which videogames' soundtracks are you looking for?

None... Though Dragon Quest/Warrior was my specialty once. They have way over 50 albums. The real question is what video game soundtracks you're interested in. :) It's a whole themed hub. Well, I think there are two actually, but only one is public (the other is for "active" members in a forum).

I understood that you couldn't find them. I thought that that was my chance to motivate you for the 'Offline Searches' :roll:

GargoyleMT wrote:
mai9 wrote:btw, could dc++ build your filelist once the program is loaded? My DC++ take ages to start.

Mine takes a number of seconds, with my main share at least. My first thought is at least a progress bar. Yes it can be done, but I'm not sure what the best way to solve the problem is - just refresh the share when the main window comes up, or start the thread in the background, or write some additional file containing your share and load it on startup, etc.

I remember reading in the changelog that dc++ can build filelists in the middle of a session (this was done to avoid the delete filelist trick) when a user requests your filelist. So I understand that creating the filelist in the beginning can be directly avoided. The only case when you need the filelist in the beginning of the session is when you want to see your own filelist and nobody has still requested it, for that case I suggest adding another button, or menu item, for that. Having a button for your own filelist would be greatly appeciated by some users, including me :wink:

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-24 11:02

mai9 wrote:I understood that you couldn't find them. I thought that that was my chance to motivate you for the 'Offline Searches' :roll:


It may yet work. Having a nice person engaging in conversation about a feature is a huge plus. It's keeping it fresh, at least. :-D

mai9 wrote:I remember reading in the changelog that dc++ can build filelists in the middle of a session (this was done to avoid the delete filelist trick) when a user requests your filelist. So I understand that creating the filelist in the beginning can be directly avoided. The only case when you need the filelist in the beginning of the session is when you want to see your own filelist and nobody has still requested it, for that case I suggest adding another button, or menu item, for that. Having a button for your own filelist would be greatly appeciated by some users, including me :wink:


The problem is that, as others have pointed out to me, the .dclist and .bz2 file lists do not contain all the information necessary to populate your file list. Specifically, they do not include the real local path to each shared file. I think it could be fudged back together by reading the directories in the Settings box and using some logic to prepend them to the appropriate lists in the file list... The order should be the same. This might be an ugly hack, and arnetheduck has a pre-disposition against ugly or inelegant patches.

Oh, and I agree about opening your own file list. It could be the "Share Manager" window or similar. Opening your own list through the generic File > Open List is only a workaround.

Don't forget that you can have hubs set to auto-connect on startup, through the favorites, and you need your shares fully populated to answer to search requests, which you will likely being recieving within seconds of joining a hub.

leadenboy
Posts: 15
Joined: 2003-04-22 05:51
Location: Paris, France

Post by leadenboy » 2003-04-24 12:26

Okay, so this topic got to be about some other stuff, but just a quick note about mai9's comments on my comments. The simple truth is that the vast majority of DC++ users - say, 97%, but it's probably higher than that - will have already picked up files from other p2p services, or from DC++ hubs without your high-bitrate, good-encoding requirement.

Some people may personally be satisfied sharing only with the remaining 3% (or however many) who meet the criterion of having only high-bitrate mp3s - even knowing that it's basically a statistical inevitability that this will drastically reduce the range of music available. But I'm not, and I doubt that many people are.

On the other hand, very many users of DC are specifically interested in knowing the bitrate (and possibly the encoding) of mp3s they are thinking of downloading before they download them. And my guess is that very many more people would start using DC++ if this feature were added, including some that mai9 would like. ;)

From what you write, I feel that you compare DC++ to Shareaza or any other massive p2p. DC is a complete different world. You can do things in DC that simply can't be done with other tools.


Nope. I've already been using DC++ a lot, checking out quite a few hubs, and I'm comparing it to itself.

(How do you show who a quote comes from?)

mai9
Posts: 111
Joined: 2003-04-16 23:02

o_0

Post by mai9 » 2003-04-25 01:43

leadenboy wrote:The simple truth is that the vast majority of DC++ users - say, 97%, but it's probably higher than that

I am not discussing your idea, but where did you get the '97' number?

leadenboy wrote:And my guess is that very many more people would start using DC++ if this feature were added, including some that mai9 would like. ;)

Well, I only use DC++ on a eac+lame hub, but you never know ;)
leadenboy wrote:(How do you show who a quote comes from?)

There's a button called 'quote' at the top-right of every post.

GargoyleMT wrote:Don't forget that you can have hubs set to auto-connect on startup, through the favorites, and you need your shares fully populated to answer to search requests, which you will likely being recieving within seconds of joining a hub.

yes, I forgot that :roll:

GargoyleMT wrote:This might be an ugly hack, and arnetheduck has a pre-disposition against ugly or inelegant patches.

And I really like it :o

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-04-25 06:45

Can some developer tell me how high this feature is on the to-add list?

I think this can make DC++ much more popular than kazaa or emule

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-25 08:19

Ok, well the only developer for DC++ is arnetheduck. He's also writing dch++, a DirectConnect hub. There are a number of people who maintain publically forked versions - Sarf, Opera, and cologic. There are also some people who just patch DC++, like me and hmm dunno sandos and sedulus?

As far as I understand it, there is no central list of features for people to work on, and no real priority scale. Fixing critical bugs (like the hang on close in 9x is pretty important [fixed in 0.233]) is important, so are regressions - where a feature no longer works that once did. Beyond that, DC++ doesn't have a roadmap or plan for future features.

It makes sense, given that everyone is doing this in their spare time and nobody is being paid to do it.

Sometimes, the squeaky wheel gets the grease - if you ask for a feature a lot you'll motivate someone to code it. But that can also backfire if you're just whining or bugging them. :)

You could motivate one of the modified client makers to add this feature, but none of them have a particularly stellar record of contributing fixes or features back to DC++ proper. And arnethduck will only accept patches from people who actually wrote the code and own the copyright (for reasons now spelled out in compiling.txt).

Note: the above is how I see things. It may not be the way they actually are.

sandos
Posts: 186
Joined: 2003-01-05 10:16
Contact:

Post by sandos » 2003-04-25 13:14

GargoyleMT wrote:Note: the above is how I see things. It may not be the way they actually are.


Its not necessarily how they are: I have contributed at most 10 lines of code of my own I think (cant remember what that would be?), and I also sent Sedulus´ 302 redirect code (which I only debugged once). So I wouldnt say I send patches :)

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-25 13:51

sandos wrote:Its not necessarily how they are: I have contributed at most 10 lines of code of my own I think (cant remember what that would be?), and I also sent Sedulus´ 302 redirect code (which I only debugged once). So I wouldnt say I send patches :)


Thanks for calling me on that. You and Sedulus are the only two who I could immediately think of in recent memory who've contributed patches to DC++. Henrik also comes to mind, with the uber-useful ADLSearch.

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-04-27 17:50

maybe it's a good idea to make an 'info' column for each file, and put there info about the file depending what file type it is. So in case of mp3 you can but the bitrate/encoder, and in case of movies you can put the resolution/framerate, and maybe in case of zip/rar you can put a CRC verification or something..

i don't know about other file formats but there are plenty of usefull things you can put there, similar to kazaa

yilard
Posts: 66
Joined: 2003-01-11 06:04
Location: Slovakia

Post by yilard » 2003-04-27 18:10

Wisp wrote:maybe it's a good idea to make an 'info' column for each file, and put there info about the file depending what file type it is.
...
i don't know about other file formats but there are plenty of usefull things you can put there, similar to kazaa


Maybe it would be nice, but personally I'm not too into this. Proper format detection would add really big bloat to the DC++ code which is not too good thing.

Anyone knows if there is any library which provides some generic file identification (something like Un*x file command) and preferably getting file information?
In the age of super-boredom/hype and mediocrity/celebrate relentlessness/menace to society --KMFDM

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-04-27 19:05

yilard wrote:
Wisp wrote:maybe it's a good idea to make an 'info' column for each file, and put there info about the file depending what file type it is.
...
i don't know about other file formats but there are plenty of usefull things you can put there, similar to kazaa


Maybe it would be nice, but personally I'm not too into this. Proper format detection would add really big bloat to the DC++ code which is not too good thing.

Only when DC++ is loading the hublist it may take some more time, I can live with that :)

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-04-27 19:06

[quote="Wisp]Only when DC++ is loading the hublist it may take some more time, I can live with that :)[/quote]
I mean file list offcourse :oops:

leadenboy
Posts: 15
Joined: 2003-04-22 05:51
Location: Paris, France

Forget elegance and comprehensiveness!

Post by leadenboy » 2003-04-28 05:12

yilard wrote:
Wisp wrote:maybe it's a good idea to make an 'info' column for each file, and put there info about the file depending what file type it is.
...
i don't know about other file formats but there are plenty of usefull things you can put there, similar to kazaa


Maybe it would be nice, but personally I'm not too into this. Proper format detection would add really big bloat to the DC++ code which is not too good thing.


I'm not into this for a different reason - namely, that now we're back to the overall metadata discussion, which is probably going to get bogged down and grind to a halt. I still think that an mp3 bitrate information feature in the relative short term is better than an overall metadata feature in the indefinite long term. Am I alone on this?

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Re: Forget elegance and comprehensiveness!

Post by Wisp » 2003-04-28 08:08

yilard wrote:I'm not into this for a different reason - namely, that now we're back to the overall metadata discussion, which is probably going to get bogged down and grind to a halt. I still think that an mp3 bitrate information feature in the relative short term is better than an overall metadata feature in the indefinite long term. Am I alone on this?

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-04-28 08:11

sorry about last post, i can't edit on this forum

what i wanted to ask was; what is the problem with meta data? the only disadvantage i can think of is that DC++ will take a little longer when building the file list. But this could be prevented by first building the file list without meta data, and when dc++ is running it could add the metadata in the background

I can't think of any other disadvantage

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-04-28 09:51

Disadvantage of metadata thingy:
Probability of feature being designed to cope with all things approaches one. If something is designed to cope with all things the time needed to code/design said thing approaches infinity.

Thus, what is needed is (in my own, very humble opinion) :

1. A way to get and send meta-data information that is context-independent (I'd suggest XML).
2. (optional) Inclusion of this information in a file list if someone feels it is necessary.
3. Some manner of plug-in/library system to handle different formats (to remove the need for arnetheduck to incorporate patches into DC++).
4. Quite a few lines of code from arnetheduck to incorporate the above-mentioned points into DC++ (even if someone decides to make a patch for him).

Does everyone agree? Good, then I won't have to bonk you with my rubber chicken. :)

Sarf
---
There is no knowledge that is not power. I am not wearing any underwear.

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-04-28 10:18

agreed =]

leadenboy
Posts: 15
Joined: 2003-04-22 05:51
Location: Paris, France

Post by leadenboy » 2003-04-30 05:34

sarf wrote:Disadvantage of metadata thingy:
Probability of feature being designed to cope with all things approaches one. If something is designed to cope with all things the time needed to code/design said thing approaches infinity.

Thus, what is needed is (in my own, very humble opinion) :

1. A way to get and send meta-data information that is context-independent (I'd suggest XML).
2. (optional) Inclusion of this information in a file list if someone feels it is necessary.
3. Some manner of plug-in/library system to handle different formats (to remove the need for arnetheduck to incorporate patches into DC++).
4. Quite a few lines of code from arnetheduck to incorporate the above-mentioned points into DC++ (even if someone decides to make a patch for him).



Am I wrong to think that this wish list is another way of saying "it's not going to happen for a long, long time, if at all"? I'm not at all complaining that arnetheduck doesn't have time to deal with changes this broad and complex. I just don't get what the compulsion is to handle all types of metadata in the year 2021, when handling just a single one would make DC++ very much more useful for a large subset of its users (which would probably become a larger subset relatively quickly with this feature added). But I guess I'm repeating myself pretty boringly by now. I wish that if anyone agreed with me they would say something. :wink:

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-04-30 08:57

Sorry for spamming you with my opinions, but hey, no one has removed my Submit button from me yet... and you'll never get it from me while I'm alive! BWAHAHAHAHA!

leadenboy wrote:[snipped my list]
Am I wrong to think that this wish list is another way of saying "it's not going to happen for a long, long time, if at all"?

Uhm... probably, yes.

leadenboy wrote:I'm not at all complaining that arnetheduck doesn't have time to deal with changes this broad and complex. I just don't get what the compulsion is to handle all types of metadata in the year 2021, when handling just a single one would make DC++ very much more useful for a large subset of its users.[snip]

Well... the list is only my opinion, but it is based on how I - as well as other coders which I have spoken with - think.
The reason for this are several, but can be summed up with: if the coders are calling the shots, they will only do features that they know are a) feasible, b) fun to do and/or "cool" as well as c) somewhat usable (at least for the person who coded it).

Let's take the MP3 tag as an example. Let's say that we "patch" DC++ so that it translates the name of a file to include the bitrate and the encoder in its filename. This would then mean that any searches would turn up the bitrate and the encoder and that you would see the info in the filelist.
Hard to do? ... no, not really. Usable? Yeah.
Fun to do? Probably not. Cool? Ditto.

Projected future number one ("Doom, gloom and increase of entropy") :
arnetheduck is heralded as the Savior of the Holy MusicLeech. The praise/complaints forum is flooded with compliments on his achievement.
A few days later, someone suggests that he add OGG support as well.
arnetheduck is busy, so he answers it with "we'll see" (unlikely, but hey, it could happen). Two days later, the DC++ bulletin board is brought to its knees when the thousands of frustrated Ogg supporters flood the features forum.
After enduring this for two weeks, arnetheduck decides to do the "teensy, tiny OGG patch" as it has been called on the feature forum (since he found a nifty freeware library that did what he wanted)... and there was much rejoicing. For two days.
Someone posts to the feature forum - whom is never determined. From the content of the message, no information can be extracted other than "y00 a11 suX0r" and "y00 m4m4 w4nt5 WMA 5upp0rt". After a few days of deliberation, GargoyleMT decodes the alien message to mean that someone (going by the nickname max69999) wants arnetheduck to implement support for WMA. The whining starts again...

Projected future number two ("Utopia") :
arnetheduck adds MP3 filename translation as an optional feature (but it defaults to on). He extends the upload-translation of filenames to handle both old filenames and new MP3-enabled ones.
Everyone lives happily ever after.

I'm a pessimist.

Final note: This post is intended for a mature, adult audience (eight years or above) and is not to be taken seriously.

Sarf
---
"Cats are Murphy's way of saying 'Nice furniture!'" - NancyButtons.com

mai9
Posts: 111
Joined: 2003-04-16 23:02

Post by mai9 » 2003-04-30 17:37

sarf wrote:if the coders are calling the shots, they will only do features that they know are a) feasible, b) fun to do and/or "cool"

sarf also wrote:Final note: This post is intended for a mature, adult audience (eight years or above) and is not to be taken seriously.

I wonder if they are related :wink:

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

not true

Post by GargoyleMT » 2003-05-01 08:41

leadenboy wrote:Am I wrong to think that this wish list is another way of saying "it's not going to happen for a long, long time, if at all"? I'm not at all complaining that arnetheduck doesn't have time to deal with changes this broad and complex. I just don't get what the compulsion is to handle all types of metadata in the year 2021, when handling just a single one would make DC++ very much more useful for a large subset of its users (which would probably become a larger subset relatively quickly with this feature added). But I guess I'm repeating myself pretty boringly by now. I wish that if anyone agreed with me they would say something. :wink:


It's an impossible line to walk, isn't it, for those of us who code on DC++? I will not code a half-assed feature, and if I code it, only my client will have that feature; arnetheduck will not put an ugly hack into DC++. Please get the "it's not a big change, just do a quick hack now" idea out of your pretty little head.

I want to work on this feature, and make users happy (mai9 and kenneth-chile have been outstanding in this respect), but I'm just another guy who's doing this in his free time and also tries to answer people's problems in general with DC++. I only have so much free time, and DC++ is getting all of it.

The most cynical part of me says: "patches are welcome" - if you can code it, make a feature and please don't make judgements about how "easy" something is. This
post
also encapsulates some of these meta-issues.

leadenboy
Posts: 15
Joined: 2003-04-22 05:51
Location: Paris, France

Re: not true

Post by leadenboy » 2003-05-05 06:02

GargoyleMT wrote:It's an impossible line to walk, isn't it, for those of us who code on DC++? I will not code a half-assed feature, and if I code it, only my client will have that feature; arnetheduck will not put an ugly hack into DC++. Please get the "it's not a big change, just do a quick hack now" idea out of your pretty little head.


I'm sorry if I seemed to be presuming this was easy. I've been doing my best to leave the assessment of how hard it would be to do this to people who would actually know. I was just trying to stir things up around the question of priorities - and see if this feature might move up on the priority list if it wasn't seen as part of a Greater Metadata issue that, if I understand, is currently very low on the list, at least partly because it will require a big investment of time. From the coders' reactions in this thread, it seems that it won't, because any plus that might come out of its being simpler to do is outweighed by new minuses - most notably the inelegance of the thing. Obviously I think that's a shame, but I'm only one guy. Thanks for listening, anyway. :wink:

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-05-05 18:53

Well, I'll tell you that it's got a high fun factor for me... I may support only MP3 bitrates when (if?) I first implement it, but I'll still wrap it in whatever appears to be the best or most thought-out metadata system... Which is to say, I'll probably put it in XML and introduce a client option for requesting meta-data on another file. Requesting metadata on any other type will just fail (like AVI/WAV/OGG ), in a nice way. Or... something.

Don't read my post as a personal attack, it's just my opinion, and a meta-reaction. I think it's preaching to the choir, as if you're participating in a "long" thread like this, you're probably a lot more into dialog than some of the other forum members. Once again: or... something.

Share and Enjoy!

leadenboy
Posts: 15
Joined: 2003-04-22 05:51
Location: Paris, France

Post by leadenboy » 2003-05-07 07:46

GargoyleMT wrote:Well, I'll tell you that it's got a high fun factor for me... I may support only MP3 bitrates when (if?) I first implement it, but I'll still wrap it in whatever appears to be the best or most thought-out metadata system... Which is to say, I'll probably put it in XML and introduce a client option for requesting meta-data on another file. Requesting metadata on any other type will just fail (like AVI/WAV/OGG ), in a nice way. Or... something.


This confuses me - isn't implementing a feature like this going to require everybody's (or at least many people's) clients to actively provide metadata, as part of filelists or something like that? Or are you thinking of actually downloading the first few frames of each file to get metadata from them? Won't that be an incredibly inefficient and slow way of getting the metadata, rendering this requesting-client-side feature almost useless?

leadenboy
Posts: 15
Joined: 2003-04-22 05:51
Location: Paris, France

Post by leadenboy » 2003-05-07 07:47

Not to mention defeating part of the purpose of the feature, by making it so you need a slot *before* you can decide whether to queue up a file - since you'll need one to do these partial downloads to get the metadata?

powerup25
Posts: 23
Joined: 2003-02-13 10:09

Post by powerup25 » 2003-05-08 21:46

Hi all, interesting thread here, i just want to give my vote for "show mp3 bitrate" becomes a reality. Let me comment here something, i've a net running, not very big, only 3 hubs, and all my people are claming for this feature since i implemented. Another tip, aproximately a 40% of my registered users alternated between others p2p program, they are not estable users because many times they are not on his machine downloading, they let the program downloading and in the morning check the files, many times they are downloading a lot of files with very poor quality, so they like DC community but he does not want to stay only in here for this reason and probably others. Note: if DC++ supports mp3 quality, they probably stay in DC comunity and forget the other reasons, they are music lovers. One tip more: I know there are many people who don't want to probe DC++ for this reason, i've talked with them.
Conclusion: I think this feature is really important for the DC community, believe me, if someone implement that feature DC++ becomes bigger, better for me, better for you and better for all, just thinking about is there are someone interested with this point.

yilard
Posts: 66
Joined: 2003-01-11 06:04
Location: Slovakia

Post by yilard » 2003-05-10 07:24

powerup25 wrote: Note: if DC++ supports mp3 quality, they probably stay in DC comunity and forget the other reasons, they are music lovers. One tip more: I know there are many people who don't want to probe DC++ for this reason, i've talked with them.



(Don't take this paragraph too serious :) ) To be honest, I'm not interested if someone rejects DC++ just because it doesn't contain ugly hack. I think some other developers share the same standpoint.

Having mp3 metadata does not ensure quality. To my knowledge >80% of homemade grabs, that can be found on p2p networks, are just crap (incomplete, bad rips, sync errors, strange bitrates). So metadata give you no advantage.

I recommend you to prefer releases from release groups (I collect just them). I know there are problems with getting some rare stuff from release groups. And still even well established groups have about 5% of crap mp3 releases. But there is quite big difference in getting good files. Another reason is that while everyone makes hi own homemade grabs that can't be found elsewhere if original source disappers, releases are often available from multiple sources.

So I wouldn't rely on metadata. Just know your sources.
In the age of super-boredom/hype and mediocrity/celebrate relentlessness/menace to society --KMFDM

powerup25
Posts: 23
Joined: 2003-02-13 10:09

Post by powerup25 » 2003-05-10 14:47

yilard wrote:(Don't take this paragraph too serious :) )

And don't take the following paragraph to serious too lol, i'm not going to discuss here at all, is just a different opinion, i agree with certains points and not with the rest, like many people i suppose
byesss

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-05-11 16:26

leadenboy wrote:This confuses me - isn't implementing a feature like this going to require everybody's (or at least many people's) clients to actively provide metadata, as part of filelists or something like that? Or are you thinking of actually downloading the first few frames of each file to get metadata from them? Won't that be an incredibly inefficient and slow way of getting the metadata, rendering this requesting-client-side feature almost useless?


No, it will of course require remote client support. However, the code I write is used by a 10-15% share of the MP3 hub I'm in. If the feature is novel enough, people will upgrade for it. This will let me test it, at least.

And not all Client to client commands require slots. In fact, only $Get does. $GetMetaData <filename> would very likely be free, if rate-limited to prevent it using too much bandwidth, and from becoming a command with which you can launch a deprivation of service attack on someone's client.

dieselmachine
Posts: 36
Joined: 2003-01-19 22:22
Location: Rochester, NY, USA
Contact:

Mp3 information

Post by dieselmachine » 2003-05-16 08:09

I coded this. It works perfectly. Or at least, it did, until i changed the build settings in vc98 from debug to an attempted 'optimized' build. Now i'm getting all sorts of different errors, depending on the weather and what phase of the moon is in the sky. Heap errors, precompiled header errors, linking errors, and more fun stuff.

I dont know how feasible it is, as i havent had a chance to run an optimized copy under 'stressful' conditions (sharing 350 gig of mp3s in a metal hub and getting blasted by search requests) but if someone can help me get this fucking thing compiled, i'd be more than happy to submit a diff patch to arne (and subsequently have it rejected). ;-]

I also wrote in an option to have the machine beep when my name is mentioned in the main chat. Just in case i'm coding and someone wants to talk to me :P

I want to get involved in the patch community, but as long as vc98 is behaving like a psychotic badger, i dont know how well that's going to work.

leadenboy
Posts: 15
Joined: 2003-04-22 05:51
Location: Paris, France

Yay!

Post by leadenboy » 2003-05-20 10:53

dieselmachine wrote:I coded this.

What is "this", exactly? :?

Locked