My code for calculating the frame length in bytes for MPEGv2/v2.5 Layer II and III was:

(144/2)* (bitrate * 1000 / samplerate + padding bit)

This was working fine, except for one MPEGv2 Layer II file, but it works ok if I double the frame length

144* (bitrate * 1000 / samplerate + padding bit)

but of course then breaks my MPEGv2 layer III files ( I dont have nay other layer II files)

I dont know why I divided by two in the first place, it doesnt seem to mentioned in the specs, but cant work if should should just be for Layer III or could be for either but dependent on something else

Can anyone please put me staright on this.


Paul

Has it anything to do with the number of channels in the files?

I think you might be right, divide by two if mono dont if not mono. maybe I should be doing this for Layer I as well.

The bitrate (or frame size) is specified for the whole stream regardless of number of channels.

Just to clarify Im calculating frame length, and when I say frame length I mean how many physical bytes the frame take up in the file, not frame size in terms of slots or whatever.

Each frame codes a fixed number of samples. How large the frame will be is determined by bitrate.

Perhaps you can make the problematic file available on the Internet?

MPEG-2 layer 3 has 576 samples per frame, MPEG-2 layer 2 has 1152 (like MPEG-1), that's probably where the need for removing /2 comes from.

Possibly this is the problem ,my code has at as 1152 for layer II and III as in this doc:
http://mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm

I do appear to have fixed it based on the stereo/mono but maybe this is just a coincidence. I think there are a few loose definitions that are interpreted differently by different people but normally give the same results.

All my files test files are already available online as part of the http://www.jaudiotagger.net project, but Ive uploaded this specific one here:http://www.jthink.net/jaudiotagger/testV2L2.mp3

Also, Im using LAME to create LIII file, M2Enc to create LII files, but what can I use to create LI files.

thanks Paul

That document is wrong then, it doesn't say anything about MPEG-1 or 2 in calculating the frame length, it's only valid for MPEG-1.
Layer 3 has only one granule per frame for MPEG-2 (instead of 2 for MPEG-1) and therefore only half the samples per frame. Layer 2 does not have granules so the number of samples are the same for MPEG-1 and MPEG-2.
Mono or stereo has nothing to do with the framesize.

Actually samples per frame might correct an issue with calculating the lngth of a frame in seconds but is not actually used to calculate the frame length in bytes

My calculation was:
(144/2)* (bitrate * 1000 / samplerate + padding bit)

e.g
(144/2) * (128 * 1000 / 24000 + 0) = 384

So I think the question is when you have stereo instead of mono, do you have twice as many frames or is each frame twice as long ?

A sample is an n-tuple depending on channels used. But you don't need that information for your calculation:
a) a frame represents 576 or 1152 samples (you know it from MPEG version and Layer information)
b) you know the samplerate in 1/s
c) you know the bitrate in 1000 bits/s

samples * bitrate / samplerate = bits per frame

samples * bitrate / 8 / samplerate = bytes per frame


No, you don't have twice as many frames and frame size is independant of channel mode used.


PS: in case you wonder where the magic number 144 comes from: 1152/8=144; 576/8=72

Ok , understand calculation and things getting clearer but I dont understand if there are no extra frames, and frame size doesnt increase when you use stereo rather mono, where the extra audio information is stored ?

Thanks that does help lot

IIRC, scmpx allows you to create Layer-I files.

Say you have n bytes available for storing your audio data.
In case of mono, audio data can use all n bytes.
In case of stereo, you have to split the n bytes like a+b=n. Now you have a bytes available for storing first channel audio data and b bytes available for storing second channel audio data.

That's why you can encode mono like signals at lower bitrates.

Im sorry but this explanation seems back to front to me. When you encode a file you dont decide upfront how many byte are available, you decide the bitrate to encode it at and then it use the apropriate number of bytes to encode doesnt it?

A specific bitrate tells you the amount of bits per second for the whole file. If you increase/decrease the amount of channels (or the sameplerate), you will simply have less/more bits per sample to store data.

Ok, thanks for your patience.

Thank you, menno, for the information about granules and Layer 2. I did not know this.