On Saturday, May 25, 2002, at 06:36 PM, Russell O'Connor wrote:
I see. The number of bytes per sample is of course arbitrary, which is why I counted samples instead of bytes.
Why do you say the number of bytes per sample is arbitrary (I guess I don't know much about mp3). I always thought it is 16 bits per sample per channel. Is this not always the case?
MP3s do not contain any sample size information; when decoding, samples are calculated with arbitrary precision. MAD decodes samples with 28+1 fractional bits and 3 bits of headroom, which is why you have to clip and scale these to your desired output sample size. 16 bits is common, but there's nothing to stop you from producing 24-bit or other sized output.
There is a common misunderstanding that the sample size of the source material from which MP3s are encoded has relevance to the sample size of the decoded output. If MP3 were a lossless codec, this might be true, but since MP3s reconstruct a signal from quantized subband values, the output signal does not necessarily fall neatly into the same precision samples as the original.
Additional precision is helpful when you want to further manipulate a signal before output, for example scaling up or down or mixing with another signal. Manipulating 16-bit samples directly would introduce too many rounding errors and degrade the signal unnecessarily.
Since frames always have the same playing time for any given layer and sampling frequency, you don't have to read headers all the way to your seek point. You can calculate n * the duration of one frame, subtract this from the time of your seek point, and stop scanning when you reach the frame containing this time point.
Wouldn't variable bit rate files have differnt durations per frame depending on the frame?
No. For a given layer and sampling frequency, the number of samples per frame (per channel) is fixed. See this chart:
http://board.mp3-tech.org/view.php3?bn=agora_mp3techorg&key=1019510889
The playing time duration is simply the number of samples divided by the sampling frequency.
-- Rob Leslie rob@mars.org