mp3 bitrate
Moderator: Moderators
mp3 bitrate
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?
Will this be added in the feature?
-
- Posts: 80
- Joined: 2003-03-21 10:17
- Location: Concepcion, Chile.
Never heard Napster, Kazaa, ,win MX?Wrath wrote:How can that be done?
Never heard of a filesharing prog that has that option.
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.
-
- Posts: 73
- Joined: 2003-01-06 09:32
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 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.
-
- Posts: 73
- Joined: 2003-01-06 09:32
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.)
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 wincueGargoyleMT 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.)
http://cd-rw.org/software/audio_softwar ... ncspot.cfm
The bitrate/quality/encoder guessing is allmost realtime
i mean encspot instead of wincueWisp 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
(why cant you edit ur posts here?)
Re: mp3 bitrate
What about joining a high quality mp3 hub?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?
It couldn't be easier
Up with MP3 bitrate encoding!
Ohhhhhh yes it could.What about joining a high quality mp3 hub?
It couldn't be easier
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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.Wisp wrote:It would be nice to also add theguessed encoder and quality just like in encspot
Re: Up with MP3 bitrate encoding!
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".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.
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
Re: Up with MP3 bitrate encoding!
Barring Xing from a vast majority of users, will make this world a better place to live.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.
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.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.
What I know for sure is that a hub with crappy Xing mp3 is doomed.
Well, ops can kickleadenboy 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?
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.
High quality MP3
Don't we call them Ogg Vorbis ?mai9 wrote:high quality (...) mp3
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: Up with MP3 bitrate encoding!
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.mai9 wrote:Barring Xing from a vast majority of users, will make this world a better place to live.
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.
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:I feel the potential users for that hub are very huge.
Like form specific topic hubs? There are certain benefits to DC/DC++. There are also drawbacks.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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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:Which videogames' soundtracks are you looking for?
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:Maybe adding specific files functions in dc++ will make it slower? and if dc++ has some mp3 features, ogg users will ask the same.
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 wrote:btw, could dc++ build your filelist once the program is loaded? My DC++ take ages to start.
GargoyleMT previously wrote:Try just finding some albums in non-Xing format. For instance, certain Video Game soundtracks.
I understood that you couldn't find them. I thought that that was my chance to motivate you for the 'Offline Searches'GargoyleMT wrote: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:Which videogames' soundtracks are you looking for?
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 meGargoyleMT wrote: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 wrote:btw, could dc++ build your filelist once the program is loaded? My DC++ take ages to start.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.mai9 wrote:I understood that you couldn't find them. I thought that that was my chance to motivate you for the 'Offline Searches'
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.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
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.
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.
(How do you show who a quote comes from?)
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.
Nope. I've already been using DC++ a lot, checking out quite a few hubs, and I'm comparing it to itself.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.
(How do you show who a quote comes from?)
o_0
I am not discussing your idea, but where did you get the '97' number?leadenboy wrote:The simple truth is that the vast majority of DC++ users - say, 97%, but it's probably higher than that
Well, I only use DC++ on a eac+lame hub, but you never knowleadenboy 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.
There's a button called 'quote' at the top-right of every post.leadenboy wrote:(How do you show who a quote comes from?)
yes, I forgot thatGargoyleMT 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.
And I really like itGargoyleMT wrote:This might be an ugly hack, and arnetheduck has a pre-disposition against ugly or inelegant patches.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.
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.
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 wrote:Note: the above is how I see things. It may not be the way they actually are.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.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
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
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.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
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
Only when DC++ is loading the hublist it may take some more time, I can live with thatyilard wrote: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.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
Forget elegance and comprehensiveness!
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?yilard wrote: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.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
Re: Forget elegance and comprehensiveness!
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?
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
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
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.
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.
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.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).
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!
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
Uhm... probably, yes.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"?
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.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]
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
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
not true
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.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.
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.
Re: not true
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.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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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!
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!
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?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.
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.
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.
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
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.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?
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.
-
- Posts: 36
- Joined: 2003-01-19 22:22
- Location: Rochester, NY, USA
- Contact:
Mp3 information
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
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.
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
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.