mp3 bitrate

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

Moderator: Moderators

distiller
Posts: 66
Joined: 2003-01-05 18:05
Location: Sweden
Contact:

Post by distiller » 2003-05-21 19:50

Probably not the metadata extension where looking for?? =)

Boxie
Posts: 8
Joined: 2003-04-14 11:12

Post by Boxie » 2003-05-22 10:34

hrmm... just a thought... instead of caching the info on load / file list refresh

why not have it as an "on-request" function...
eg, you search for an MP3... say

abbagabba

you get a few responses, you right-click and say get-info

DC++ then gets the ID3v1 & ID3v2 tags if present and grabs a couple of frames from the MP3 and tells you the bitrate / ID3 Information

This could also be used in AVI files... but i am not sure on what their format is...

once the information for an MP3 is gathered (in both clients) they can be cached with the file info...

this saves on excrutiating startup / file refresh times and could be a valuable feature later on...

btw - to calculate a bitrate on a VBR MP3 can be time consuming, cos the first frame might be 64k during the intro silence... then everything else maybe >128k

mind you - i would see this feature more as a "Plugin" than anything else...

btw - will there be plugin support for DC++ eventually? cos i can see alot of people writing extentions for if there is...

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

mp3 data

Post by dieselmachine » 2003-05-23 18:16

ok, to go into a bit of detail. (some technical stuff included)

i coded an extension which functions like this. When a client sends a search request and the request is distributed to each client, each individual client checks it's own share to determine if it has any files matching the search criteria. IF my client finds a file, it checks if it's an mp3. If it IS an mp3, it uses some id3 libraries to extract info from the file (bitrate, artist, album, track name, year of release) and appends them to the $SR before it sends it back to the searcher.

The format is the normal search request, followed by the various fields seperated by a '0x06' character. Thus, non-compliant clients still receive the search results, they just dont know what to do with the extra info. This is wasteful, yes. Several bytes of added info. hahaha.

Anyway, the obvious problem with this is that both clients need to support the extension otherwise the transmission is in vain. If youre that desperate for the info, you can download my client at http://while1.net/~jt/DCPlusPlus.exe and encourage others to use it so there are more bitrate compliant clients out there. If you want to give it a test, you can swing by paladin.sublevels.net and search for Anthrax. Me (JayTee or JT) will return results, including bitrate info.

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

important note

Post by dieselmachine » 2003-05-23 18:24

If anyone actually DOES download this, be wary of the op functions. if you arent an op, dont fuck with the 'crowd control' tab, or you'll probably get kicked for flooding. :P If you ARE an op, and you turn this shit on, dont join other hubs. You'll probably get kicked for flooding. To put it simply, unless you plan on being in one hub, and an op in that hub, dont check the last three boxes. and the aliases for the ban commands are %ip for IP addy and %n for nickname.

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

Post by sarf » 2003-05-24 04:34

Care to share the code, dieselmachine (preferably in another thread, I guess) ?

Sarf
---
We learn from history that we do not learn anything from history.

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

code

Post by dieselmachine » 2003-05-24 04:58

i would, but i dont keep a backup and i already have mangled it in an attempt to make it better. the ghetto id3 library i was using before wasnt very good (only supported id3v1 tags. im working with another one now). i'll see if i can delete the recent changes and get it to compile. gimme a day or so and i'll get back to you.

of note is the fact that i had to uncomment a line in the stlport user config file that had been commented out for some reason. something like USE_IO_STREAMS. i dunno. i'll get back to you.

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

Post by GargoyleMT » 2003-05-24 13:45

Boxie wrote:btw - to calculate a bitrate on a VBR MP3 can be time consuming, cos the first frame might be 64k during the intro silence... then everything else maybe >128k
In the modern world, you'll find that every newly encoded VBR mp3 has a Xing header. Those that do not will have a VBRI header, which is what Frunhoffer's encoder uses.

I don't see how your way has any advantage over a background thread crawling your collection at a low priority. (Especially if the queued files can be modified by, say, them getting hit by a search request.
Boxie wrote: their priority so they're next to get meta-data extracted.)
Boxie wrote:btw - will there be plugin support for DC++ eventually? cos i can see alot of people writing extentions for if there is...
If more programmers write plugins for DC++ than hack on the DC++ source, I'll be surprised. Good programmers are always welcome to make contributions... especially of user-requested features.

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

mp3 data, continued

Post by dieselmachine » 2003-05-26 23:26

ok, here's the deal thus far. I have successfully integrated the libid3tag library into my dc++ and have used it to access file info, and send it with search request responses. search results still show up in official clients, but my client will process the added info and display it in the search frame.

when i get back from work tomorrow, i will put the compiled binary and the source code on my website. i'll post a link here for anyone who wants to check it out. the source will likely be a little hard to understand, as i've added a LOT of things to the base code. i actually designed it as an anti-cheating mod, so there will be lots of stuff useless to non-ops.

thanks to sarf for the excellent threaded filelist checker (fucking awesome)

thanks to gargoyle for the winamp quoter (also fucking awesome)

thanks to me for everything else (awesome again)

i'll be adding a FIFO queue to the setup tomorrow also.

For reference, since this client doesnt seem to generate a lot of interest, it's designed by me, for me. all the features are things that i want or need as an op in a hub where nothing is automatically handled. :P However... the cheater finding will soon be expanded, and will be an effective client side method of stopping cheaters from getting files. Thats my plan at least. If i cant kick a cheater, he wont be getting anything from me. ;-]

frodoontop
Posts: 2
Joined: 2003-05-28 05:19

Post by frodoontop » 2003-05-28 05:30

Why still bother with mp3, it's already very old. There is a much better compression format available, called Musepack(.mpc). At www.hydrogenaudio.org, a very professional audio forum, they commonly agreed that MPC is the best format for high quality lossy audio. Musepack is said to be transparent at bitrates 160-240 kbit/s for 99,9% of all files. Something which can't be said for MP3, not even at 320 kbit/s.

You can find a professional guide for ripping (and playing) MPC-files at www.rex-guide.de.vu. Please rip some of your own albums and join the public mpc-hub at hub.alienIRC.de. I know the hub isn't really big, but I think quality is more important.

Anyway, if you have enough albums ripped in high quality you can be contacted there to join private hubs. (hint)
High quality audio sharing? Look for a public mpc-hub at hub.amoose.com.

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

as previously mentioned...

Post by dieselmachine » 2003-05-28 10:04

http://www.while1.net/~jt/DCPlusPlus.exe (binary)
http://www.while1.net/~jt/DCPlusPlus(JT).rar (source code)

In order to get this to compile, you will need to open up stl_user_config.h in your stlport folder and comment out this line:

#define _STLP_NO_IOSTREAMS 1

other than that, it should all be cool.

peace.

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

Post by GargoyleMT » 2003-05-28 19:13

frodoontop wrote:Why still bother with mp3, it's already very old.
Good luck getting rid of MPEG Layer 3. :) MPC may gain the upper hand, I have seen some stuff in it. If software and hardware support becomes extensive, people will use it. Or if demand becomes great enough, programmers will step in with software. I, for one, would like to have widespread OGG Vorbis support a little bit before MPC support.

dieselmachine wrote:http://www.while1.net/~jt/DCPlusPlus(JT).rar (source code)
w00t!

frodoontop
Posts: 2
Joined: 2003-05-28 05:19

Post by frodoontop » 2003-06-05 09:56

I know it's hard to get rid of MP3, and it's not my intention. I know some people think that 128k/bit MP3 is already very good and I respect that. Just wanted to point out for those who like high quality music, there is a public hub available.

BTW, the old adress doesn't work anymore somehow. Look in my .sig for the address. (touchup - GargoyleMT)
High quality audio sharing? Look for a public mpc-hub at hub.amoose.com.

SirPlus
Posts: 11
Joined: 2003-04-12 13:41
Location: Australia

KISS

Post by SirPlus » 2003-06-10 00:09

It doesn/t sound like it will happen
I tend to dl the larger mp3.
Usually this is enough.

Briden
Posts: 1
Joined: 2003-11-22 15:51

Post by Briden » 2004-01-18 19:54

For what it's worth, i think showing the bitrate of MP3 files is a terrific idea, and would greatly improve the both the usuability of the client.

more importantly, i think it would eventually mean better files on the networks, and that is what it is all about right?

I am considering downloading this version above, but as I am not an op, nor want to be one, i'm not sure if i want this or not.

but, i just want to add one more to the list of people that think this would be a good thing to have in the main DC client.
~Briden~

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

Post by GargoyleMT » 2004-01-19 19:53

Briden wrote:but, i just want to add one more to the list of people that think this would be a good thing to have in the main DC client.
I know, they keep opening new RFEs in the sourceforge tracker. ;)

This isn't a particularly good way to return meta-data... and it only works with mp3s - if you handed out information on info on avis, mpegs, jpegs, etc. JT's mod wouldn't work.

This is something best addressed in a new protocol (which is being discussed), not trying to hack it into the current one.

Locked