P2P Clients and VBR MP3
 

;( Some may know this, so don't crow at me please...

I always tend to go for the better quality high bit rate files in my searches for music, but it seems that some clients are incorrectly reporting real bit rates where VBR encoding is used (Variable Bit Rate)

I've been searching for some rare tracks, and I always sort in bit rate order, high first, so it was with much disgust, that in desparation I had to grab a track registered at 48kbits, just to see if it was the one I was after, surprise, the encoder had set the minimum to 48k, and this was what registered in the list, on playing the bit rate soared up above 224 and it sounded superb, so all is not lost, if you cannot find that illusive track, checkup some of the lower bit rate ones, you may be surprised?

The Clue in this case was in the playing length and the file size, a 6 megabyte file at 48k would be around 20 minutes long, not the usual length for a 6meg file of say 5 minutes.

Well worth a check of some of the 48 & 96k files, afterall who in their right mind would encode the top quality band Ambrosia at 48k?

Until we get a client that can correctly calculate the playing time and median bitrate of VBR's, best to check these odd balls..

:RE:

Snark.

I wonder if there are any p2p clients reporting VBR bitrates correctly... :PO:

- tg ;)

VBR
 

Hi TG,

Yes I was going to post that as a question too, thanks.

I use WinMx mainly here, that gets it wrong sometimes, Blubster too has a problem, or at least it seems to.

With WinMx there are many different servers versions on the OPenNap networks, hard to say if these corruptions are just a whimsey of the server Elites or a common problem, I do know for a fact that some operators reject odd bit rate files, and these are usually bad interpretations of the median bitrate of VBR's

I suppose its all part of the fussy server op syndrome, client not accepted, file too small, wrong bit-rate, and a pletheror of other reasons to ban you or your content, strange, I thought server operators would be proud to have the most users, not turn them away over petty foibles.

There is no doubt we should all be greatfull to those that put on servers for us, but there is no place for Ego in my opinion.

I await with interest any reports from other client users...

Hey, when you going to give up the Weed? couch cough!!!

Snark. :LF:

:J: thanx for posting in my thread before snark !
i will be definitly changing my email reader...hehe
i wonder if the start files and the signiture files
can determine the bit rate of different music files
it seems like they could
but indianna_jones would be the one to ask
about that
id say if some one posted a startfile of a certain song
at a certain bit rate that is what you would end up getting

48 is the tip off usually, even on morpheus, it's just a strange bit-rate to pick. i mean, why not go for 32? i always take a look.

- js.

Strange bitrates are usually tip-off for VBR files
 

Hi,

I found that mp3s that are reported with 'strange' bitrates are usually VBR encoded. And yes, most if not all p2p clients I have used lately seems to report VBR encoded mp3s incorrectly. Maybe they report the bitrate of the first frame or something, but that's no indication of the quality.

And if you think about it, what bitrate SHOULD a client report when dealing with VBR files? There's not much else that would make sense... :dz:

Ciao for now,
Stoepsel

It said "Insert disk #3", but only 2 will fit!?!

Re: Strange bitrates are usually tip-off for VBR files
 

That's a good point. Even with CBR a high bitrate is not a guarantee of good quality as much depends on the decoder being used but with VBR there are many more variables... I myself would think that highest bitrate being used would be more indicative than the average bitrate of the frames.

If I remember correctly the Nap/OpenNap protocol uses just a single number for bitrate and there is no extra parameter to indicate whether it is CBR/VBR (correct me if I am wrong). Perhaps if you have a VBR with 192 kbs as top bitrate, the client should report it as 191, similarly 256 VBR could be reported as 255. This practice would make a good use of the single figure available... :BL:

- tg ;)

ps. Welcome to the board Stoepsel! :beer:

Re: Re: Strange bitrates are usually tip-off for VBR files
 

Well, that would imply that the client would have to scan each and every frame of each and every mp3 you share. Even if this would only be done for VBR files (assuming there is some way to tell that from the header of the files or by scanning the first few frames), it still would mean scanning a helluva lot of data when creating the meta data of all shared mp3s. I don't think it would be a good idea to let the client do all that work to get the maximum bitrate of a VBR file.

Quote:

Originally posted by TankGirl ps. Welcome to the board Stoepsel! :beer:

Why thank you! :hiya:

Stoepsel

As there is no common header specifying the frame statistics of an mp3 file it seems indeed that scanning through all frames is the only way to determine reliably both the highest/lowest bitrates as well as the average bitrate. This may not be as heavy though as it sounds - we would not be decoding the mp3 file, just reading the bitrate figures from the individual frames. This might be wise to do at the same time when we calculate the hash number for the file contents.

- tg ;)

ps. the lack of common header info is probably the reason why my WinAmp keeps guessing the remaining playtime for the VBR mp3s I play....

Hmmmm, in my case that would mean scanning through roughly 6 gigs of mp3 files. Of course you don't have to decode all of that data but just rushing through it still needs a bit of time. Maybe a few minutes or so. And since it's an IO intensive operation, you will notice your computer almost come grinding to a halt.

But not everyone shares as many mp3s as I do, but some share even more. Maybe doing that scanning in a background low-priority task could be a workable solution...

Stoepsel

this is the point, why i surely think, that it's part of a quality ripping,
simply to put the

• name of the encoder, i.e. "LAME"
• version of encoder i.e. "3.91"
• primary settings i.e. "standard"
• ripper i.e. "EAC" or "cdex140b9"

into the comment field of the ID3 TAGs and have a look that it is
not truncated due to the limited length of that TAG.
btw. cdex offers this feature in its settings and i think all other
tool will have it too.
and as usual, this idea is not really new:) if you search for
"LAME r3mix", you will get a lot of results for this
- maybe in future it's "LAME standard"

@bitrate:
i suppose, that since mp3 is coded in frames, that the p2p tools simply
take the bitrate of the 1. frame. if you look in winamp (double click on the
title display) you get an average bitrate.
i really dont know how it gets it. if the first frame is a silent frame, it's
default allowed to code it with a very low bitrate,
regardless the value you set as lowest bitrate.

@search:
i think one, must differ between textual search and search
in download window:

• textual search (in search window) goes after parameters
  like titel, artist, comment etc. (maybe there's even a way to search
  for the signature, that would be fun :)
• search in download window looks only for signature,
  so i'm sure that it's useless to enter some parameters into the dat files.

indy

Exactly what I had in mind... even present Nap clients and Morpheus take a good while to crunch through a few thousand freshly shared files and calculate the hash codes. There is rarely any need to get all the new stuff immediately visible to others... the client could well keep scanning & analyzing the shared files in a low-priority background thread and report the results to servers / supernodes in reasonably sized batches.

- tg ;)

Just one that I know of Filenavigator 3.0

3.0 feature list