Ability to view file info prior to downloading

Use this forum to flesh out your feature request before you enter it in <a href="http://dcpp.net/bugzilla/">Bugzilla</a>.

Moderator: Moderators

Locked
charly123
Posts: 7
Joined: 2006-06-12 18:20

Ability to view file info prior to downloading

Post by charly123 » 2006-06-13 12:42

Like, if you search for an MP3/Video/etc., it tells you what bitrate was used to encode it, how long the song/video is, etc., in the search info prior to you selecting which file to download from a bunch of otherwise similar-looking files returned from the search query.

Other P2P programs such as WinMX, SoulSeek, Audio Galaxy, Kazaa etc. used to have this as standard.

Thanks

Quattro
Posts: 166
Joined: 2006-01-11 09:23

Post by Quattro » 2006-06-13 13:59

either DC++ should do this alongside hashing which takes a lot of resources as it is... let alone accessing ID3 tags and getting the info, if there is any.

or the user should include a file with this info with the files... which probably isn't going to happen.

also take a look here...
http://dcpp.net/forum/viewtopic.php?t=16144
You can send a message around the world in 1/7 of a second; yet it may take several years to move a simple idea through a 1/4 inch of human skull.

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2006-06-13 15:04

and btw, depending on version id3-tags can be extremly complicated. You can even have pictures of the album-covers as parts of the tag. ;))
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

Quattro
Posts: 166
Joined: 2006-01-11 09:23

Post by Quattro » 2006-06-13 15:10

ivulfusbar wrote:and btw, depending on version id3-tags can be extremly complicated. You can even have pictures of the album-covers as parts of the tag. ;))
the exact same thing was in the other thread... so why copy paste it ;-) :P
You can send a message around the world in 1/7 of a second; yet it may take several years to move a simple idea through a 1/4 inch of human skull.

charly123
Posts: 7
Joined: 2006-06-12 18:20

Post by charly123 » 2006-06-13 18:24

Hiya guys.

No, not ID3 tags, just the song/video's length and the bitrate (from the file properties). Actually, I don't believe song lengths or bitrates are even contained in ID3 tags?

Anyway, my reason being when you search for a song, for example, the only thing you have to go on (to decide which to download) apart from the file name is the file size, which means you often have to download several before you discover the song's properties (length, bitrate) and decide which one to keep (and discard the others), which is a fairly inefficient way of doing things.
If you were given just a little more information from the search results - merely the bitrate, and the song-length - you'd be in a much better position to pick out a more accurate file to download, first time.

When you searched in WinMX/SoulSeek/Kazaa, it'd list all of the bitrates and song lengths with the returned file search results there and then, fairly quickly (no hashing).

PseudonympH
Forum Moderator
Posts: 366
Joined: 2004-03-06 02:46

Post by PseudonympH » 2006-06-13 20:49

This is not possible under the NMDC protocol, due to the rigidity of the search result format. Under ADC, it's perfectly possible, but doing it for each and every media file type would result in a lot of code bloat that arne (the creator of DC++) would most likely find unacceptable.

charly123
Posts: 7
Joined: 2006-06-12 18:20

Post by charly123 » 2006-06-14 09:47

Thanks for the reply.

How did WinMX, Napster (the original), SoulSeek, Kazaa, Audio Galaxy etc. do it so easily, then? (without hashing)?

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2006-06-14 10:29

hashing has nothing todo what you want to achieve. You can always decode this kind of info, but then you need general search-replies that can contain any metainfo or filelist containing any metainfo. The cost of this is essential. Lets consider a mp3-file, for example a untschackahackaunts.mp3 (a sound from a specific SAAB in the early 2000).

What kind of meta-info can be achieved:
Artist-name: ivulfusbar
Album-name: chackahackaunts
Track #: 23
Title of song: untschackahckaunts
Genre: CarSounds/Effects
Year: 2000

and more and more, then the vbr can also be estimated... and so on..
All this information will double the memory used by a dc++ clients for holding the info (upto some factor). This factor will not be neglictable. Most users doesn't want this. There have been clones of DC++ supporting these kind of meta-info, but they have never grown large in terms of usage. Its therefor a conjecture that the need for this in the DC++ is neglictable. Espesially to the cost of getting it and maintaing it.

And btw? Did you work on WinMX, Napster or SoulSeek... since you seem to know that they made this easily? ;)

Ofcourse, if you will send us a well defined logic on which meta-info and or a general approach together with an implimentation i will certainly consider it and try it. ;))
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

poy
Posts: 83
Joined: 2006-04-03 15:55

Post by poy » 2006-06-14 10:44

PseudonympH wrote:This is not possible under the NMDC protocol, due to the rigidity of the search result format. Under ADC, it's perfectly possible, but doing it for each and every media file type would result in a lot of code bloat that arne (the creator of DC++) would most likely find unacceptable.
not so sure, i once wrote a thing that read ID3 v2 tags of MP3 files, and it was very "short" (you just have to put the file pointer on the right place, and read the contents there). it was in PHP, but since it's mostly string manipulation functions, and C++ does have them too, this could really be done and it wouldn't take so much code IMHO.

edit: i realise there are some other media types too, and holding them all would indeed be a lot of work. but only reading ID3 tags can give a lot since many users keep their musics under the mp3 format.

Todi
Forum Moderator
Posts: 699
Joined: 2003-03-04 12:16
Contact:

Post by Todi » 2006-06-15 01:51

I have never had a need to know much about an mp3 file outside of what it contains, i.e it's filename. You can usually tell what encoding it is based on filesize, so you pick one that's reasonable in size = good quality. More information like you want is something a very tiny portion of DC++'s users would need, imho.

poy
Posts: 83
Joined: 2006-04-03 15:55

Post by poy » 2006-06-15 10:53

the thing about mp3 filenames is that they are sometimes (often?) incorrect, or they don't give enough informations. from my own experience, i think ID3 tags usually contain more accurate information that the filenames do.
but i agree this would benefit few users, and it would ask too much work on the "protocol side".

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

Post by GargoyleMT » 2006-06-15 20:57

charly123 wrote:How did WinMX, Napster (the original), SoulSeek, Kazaa, Audio Galaxy etc. do it so easily, then? (without hashing)?
They either designed the protocol for such data (NMDC was not) or simply changed the server and clients and forced everyone to download the new version that did support metadata.

It's not about hashing, it's about being able to communicate the data to other people via the protocol.

poy wrote:not so sure, i once wrote a thing that read ID3 v2 tags of MP3 files, and it was very "short" (you just have to put the file pointer on the right place, and read the contents there). it was in PHP, but since it's mostly string manipulation functions, and C++ does have them too, this could really be done and it wouldn't take so much code IMHO.
I take it you never ran into a compressed or syncronized ID3v2 tag? There are a lot of versions, and if you want to properly support all of them (how else can you explain to a user why their metadata isn't showing up), it will require some work. My ID3v2 program was more complicated than yours, apparently. And I know mine would have fallen on its face with some of the files I've seen over the years.

(The moral? Use a library that specializes in this.)

poy
Posts: 83
Joined: 2006-04-03 15:55

Post by poy » 2006-06-16 10:57

you are right, since it was just to be applied to my own files, wich all had the same type of headers, my work was much easier. and it's sure that when it comes to supporting all the other types of headers, things are way more complicated...

Locked