I checked some MP3 files I created using Lame 3.97 and found that the bitrate is 319 not 320 kbps. What's wrong?

P.S. I used EncSpot for checking...

I take it you were using -b 320? I guess there are some samples with 'digital silence' that are encoded with 32kbps.

Unfortunately Encspot is hopelessly outdatet and could therefore be wrong. What you could do is to look at the bitrate distribution (double click on a mp3). If there is a small graph at '32' then SoleBastard is right.

Yeah, I used -b 320. No, there's no small graph at 32 kbps. BTW when I choose "Complete Scan" from the EncSpot context menu the bitrate value changes to 320.

It's interesting that this problem also appears on some files encoded with Lame 3.96.

i used an mp4 optimization program(can't remember the name) which reduced the filesize of mp3s losslessly by making the frames shorter. this made an mp3 go from 320kbps to 314kbps(this time in VBR...).

so i highly doubt it, but it could have been an encodement bug.\

I use no optimization programs just Lame 3.97 (and RazorLame as a front end). I don't think it's an encodement bug.

Can anybody encode a couple of files using Lame 3.97 (320 kbps CBR) and view them with EncSpot? It might be helpful for me. Thanks in advance!

I guess you're right:





Using Encspot Pro 2.1 beta 1

So, now what?

Blame it on Encspot, at least it works corecctly when you press complete scan. I wouldn't worry since everything is correct isn't it? (The prescan function in encspot is not working correctly but since you know that you can avoid it and always fully scan your mp3/mpc files.) Additionally the development of Encspot has stopped so they won't fix it anyway.

Well, not completely. As you can see at the 'Frames' table I have set Encspot to always do a complete scan after the initial 1000 frame scan. So even with the complete frame scan Enscpot still list the files as 319kbps .

So nothing. I thought there's a problem with my Lame settings. Hopefully I was wrong. Thank you and other good guys on HA for help!

And sometimes when I encode WMA's foobar tells me that it is 129 Kbps or 127 Kbps when they are 128kbps CBR.

Could it have something to do with the way bytes are calculated? (1000/1024)

By the way... All the files I purchased from Beatport (they use Lame 3.96) are of 320 kbps (according to EncSpot). May be it depends on the build of the Lame. I tried different builds though and the result is the same - 319 kbps. What do you think?

Winamp sometimes reports files as +/-1kbps from what they were encoded with as well so I wouldn't worry about it. Probably just something to do with they way the overall rate is calculated?

You know something I don't?

http://www.guerillasoft.co.uk/encspot/pro.html

"The professional version of EncSpot is temporarily unavailable. Soon it will be distributed free of charge."

That's what the page has said for probably a year at this point. Stick a fork in it, it's dead.

IIRC most codecs use 1000 bits = 1 kilobit, but for WMA 1024 bits = 1 kilobit. My few 128 kbps WMAs show up as 129 kbps in foobar.


I for one am holding out hope! EncSpot is a great little app that continues to serve me well to this day, despite it's few limitations. I realize this is probably wishful thinking, but I'd love to see it's functionality extended to other codecs/formats...

-RS

Many versions of the Fraunhofer codec don't use padding. Think about it. A frame holds 1152 samples. 44100 samples per second => the size of a frame for a CBR stream must be exactly 320*125*1152/44100=1044.898 bytes. That's where padding comes in. It's possible to create 320 kbps frames of size 1044 (non-padded) and 1045 (padded). If you use non-padded frames mostly and throw in a padded frame once in a while you could get exactly to 320 kbps.

If your encoder doesn't do padding in this case you'll get to a bitrate of 319.725 kbps. It's likely that EncSpot computed the exact bitrate (including padding) and rounded this just to 319 via integer division: filesize/frame_count

Even if the encoder is using padding, bitrate is usually slightly lower than 320kbps (44.1kHz), and goes back to 320kbps on the padded frame.
So for a random track length, the exact bitrate is way more likely to be just under 320kbps than exactly 320kbps.

Add to this a truncation to integer in the bitrate calculation (as pointed by Sebastian), and you're likely to end up with 319kbps reported.

Got same results (191 kbps instead of 192, 127 instead of 128 etc) in EncSpot. This is definetly a bug of EncSpot, because Mr Questionman, Winamp, Windows Media Player foobar etc shows me that it is 192 cbr 128 cbr etc.

I think EncSpot shows 127 191 etc when Lame header is used and no Id3 Tag is available... (Encoding with Lame.exe without using any ID3 tags -> EncSpot shows me 191 kbps, Encoding with Lame.dll in CBR mode and using ID3 Tags --> EncSpot shows me 192 kbps... DLL and EXE are the same version of course.)

I think encspot includes the tag in its calculation of the file size.Try stripping the tags and try again.

Just a rounding error of some sort..........

Assuming that I understand you correctly, that doesn't make a lot of sense. Tags increase file sizes and thus bitrates computed from them!

No sense, yes. I don't know why EncSpot does that, I'm surprisingly not the writer of the app

although EncSpot sometimes show CBR or VBR bitrates 1 bitrate lower / higher than it is in reality, I must say it's one of the greatest apps ever made for advanced mp3 file-informations.

When the option "show average bitrate in VBR files" is checked in Winamp this occur too. I had noticied a case that the bitrate displayed is 325 in a mp3 encoded at 320 kbps.In the tag the bitrate showed is ok.

EncSpot is indeed very useful but the lack of updates is starting to hurt it a bit... is there any newer, better (by this I mean giving more accurate results) and updated app that is at least as practical when scanning for sync errors in mp3s?