Hi Folks!

Im new to this forum.
Since I am developing a MP3Tool along with three friends, sooner or later it was clear that we would need particular information about technical stuff 'bout MP3.

I have written a function which gives me Information about the MP3Header but it only works when the Header is located @ Byte 0 @ the Mp3-File. Does anybody know how to find out where exactly the Mp3Header lies? It maybe would be information enough if the Header has a special string which leads to the Header....

*hopefullysomeonecanhelpout*

It is very easy to locate the sync-block of the header. It consists of 11 set bits. So just serach for 0xFF, it you found it, check if the next byte have the first 3 bits set (byte&0xE0 == 0xE0), if yes you found it. otherwise go on searching for 0xFF. A spec about mpeg audio header (how to find out bitrate, samplerate etc..) is here: http://www.mp3-tech.org/programmer/frame_header.html

Thanks dude!
I will try to figure out what u described.

Ok, I have written the Code and it works fine.
But if I use a VBR mp3, the Bitrate output is wrong.
What do I gotta do??

The VBR files need a seek table, i guess. Play around a bit with this tool: http://www.willwap.co.uk/Programs/vbrfix.html
Maybe it can give you some insight.

Does anybody know how to calculate the VBR Bitrate???

You can divide filesize by filelength to get an average bitrate for the VBR file... I think this isn't 100% accurate but maybe it's accurate enough for you purpose...

You cannot get the vbr-bitrate by that, bevcause you don´t know file-length (time). Best thing would be to scan entire file. You read the first header, then you know how big this frame is (don´t forget padding!!) and skip to the next frame. During this you have to count the frames. At the end you have the number of frames (make sure it ignores a ID3-tag at the end). Now you divide the total file length in byte (without ID3-tag) through the total frames. You get the average framesize. Divide this float/double varible through 128 (*8 and then / 1024). That´s now the average framesize in Kbit. Because one frame contains 1152 samples you have to multiple it with the samplearte and then you divide it through 1152. That´s then the average bitrate in KBit/s.
Here in c++ what to do:

long frames=0, filelength, samplerate, id3length;
double bitrate;
.... (your framecount code)
bitrate = filelength-id3length;
bitrate *= samplerate;
bitrate /= frames*147456; // 147456 = 1152 * 128


Edit: Warum zum Teufel quäle ich mich hier eingentlich ab und schreib das alles in meinem schlechten englisch??

If you use the filesize given in LAME header, you get the size of the actual audio without headers or tags. Dividing this by the total # of frames (also found in the LAME header, or was it in the Xing, well one of the two...) gives you an exact average bitrate.

@ S_O: Ok ich hab das ganze jetzt ausprobiert und mal von hand nachgerechnet.
Winamp sagt mir bei einer VBR File 178Kbit, ich kam auf 174 - passt also.
wie ermittle ich genau die anzahl der frames?

Please keep your posts in english, rule 10, TOS.

just scan through the whole file and count the frames. When you found a frame header seek for the next one - until EOF

edit: there is no need for a "dumb" search for 0xFFF throughout the whole file.
When you found the first valid frame header you can calculate the length of this frame and jump to the next one, calculate the length of this frame and so on

@Sunhillow: But how to I find a frame??? And first off: what is a frame?

Well, I guess you need some basic information for finishing your program.
Go to Mitiok's site and download iso11172-3. In part 2.4 you will find the bit-by-bit description of MP1-, MP2- and MP3 bitstreams, 2.4.2 describes the particular elements of a frame.

Frame - this is a closed chunk of data containing the information for 1152 audio samples

Ive read this document.
When it comes to "Frames" the document declares a frame as the following:

frame()
{
header()
error_check()
audio_data()
ancillary_data()
}

IMHO this aint the thing I need to count *lol*
cause as u can see a mp3 consists of ~13000 frames (depending on lenght).

Well, if you want to determine the bitrate of a VBR file, what else do you want to count? You have to know the exact running time and the size (size if data without ID3 tags!). Counting the no. of frames is the fastest way to get the running time of VBR MP3s.

edit: ... if you don't have a Xing header/LAME Tag

Well sure I wanna count frames!
Dont get me wrong, please.
But as u can see the ISO says a frame looks like that:

frame()
{
header()
error_check()
audio_data()
ancillary_data()
}


that means there is only one frame.
But this aint right...
I simply dont get it

hi!

first of all, consider that i'm no mp3-format guru.
just some things i have "stored in my memory at some time or the other".
so consider when reading this...

@all:

i'd suggest counting samples.
somehow one has to adjust for long/short frames.
or am i mistaken?
think not.

one could count short and long frames with 2 distinct counters,
or just count samples.

@Peter Piksa:

there are multiple frames!
only the paragraph

frame()
{
header()
error_check()
audio_data()
ancillary_data()
}

describes only ONE frame.
they are simply smashed together to form the mp3-stream.
simple as that.

in the frame-header the length of the frame is encoded.
normally parsing an mp3 looks like...

1) look for the first frame-header-candidate (= look for 11x"1" bit-sequence, byte-aligned)
2) try to decode the frame - if it does not work out (i.e. if there are any severe errors, goto 1)
(if you are only interested in bitrate, bit-allocation or whatever then of course you don't need to
decode all the sample-values)
3) take the frame-size, and jump to the first byte after the current frame
4) goto 1

whenever you get "behind EOF" your done.
if you rely on too much things like the next frame starting immediately after the current one, or
that the bitrate encoded in the frame-header does not change or whatever,
you'll get poor compatibility with "broken" mp3s.

for a player you might want to account for "broken" frames (or anything you cannot decode) by repeating the last frame, substituting silence, or decoding an "average frame" between the last good and the next goot frame.
whatever.

-------------------

there are several things i don't exactly know:
* is the length encoded in the file somewhere?
* is there a time-code for seeking?
* if not, WHY not ? :'( (ok, just joking)

bye,
have a nice day,
--hustbaer