I am working on an application that will be responsible for on-the-fly encoding and delivering mp3 files over an http connection. in order to cut down on latency for larger files, and conserve on memory usage, i'd like to begin sending the encoded file as it becomes available from the encoder, rather than waiting until the entire file is encoded.

in order to do this i would like to be able to compute the content-length header before the encoding process begins.

i have read in several places that it is possible to accurately predict the file size of a cbr mp3 file. for example, in the lame.h header file it says:

* The required mp3buf_size can be computed from num_samples,
* samplerate and encoding rate, but here is a worst case estimate:
*
* mp3buf_size in bytes = 1.25*num_samples + 7200

however, i have spent a great deal of time searching and have not been able to locate the actual formula for such a computation. i was hoping somebody who knows more than myself about the mp3 file format could help me out.

this is what i've been able to come up with so far:

total_size = (number_of_mp3_frames) * (size_of_each_frame) + (file_headers)

file_headers, as far as i know, is just the id3 tag (128 bytes for v1)

number_of_mp3_frames = number_samples / samples_per_mp3_frame
samples_per_mp3_frame should be 1152 for kbps > 32000, else 576
number_samples i know from my input file

size_of_each_frame = frame_header + samples_per_mp3_frame *
bitrate / samplerate / 8
bitrate and samplerate i specify as encoding parameters
frame_header is 4 bytes (6 if CRC enabled, which i dont think it is)

in my tests so far, though, this seems to produce results that are ~3-4kB less than the actual result.


any help anyone can provide would be greatly appreciated.

Reply via email to