On 19.11.2005, Bluechip wrote:
>> Second, the xing header should provide as much information
>> about the audio stream as possible. It contains the frame
>> count, but in order to compute the playtime, you also need
>> the frametime which depends on the sample rate.
> frametime? Should I infer that:
> http://www.mp3-converter.com/mp3codec/frames.htm "Just as the
> movie industry has a standard that specifies the number of
> frames per second in a film in order to guarantee a constant
> rate of playback on any projector, the MP3 spec employs a
> similar standard. Regardless of the bitrate of the file, a
> frame in an MPEG-1 file lasts for 26ms (26/1000 of a second).
> This works out to around 38fps. If the bitrate is higher, the
> frame size is simply larger, and vice versa. In addition, the
> number of samples stored in an MP3 frame is constant, at 1,152
> samples per frame."
> ...is wrong, or at the least, misleading?
It *is* wrong. First, 1152 frames is only correct for MPEG1
layer 3 and MPEG1/2 layer 2. MPEG2/2.5 layer 3 has 576 samples
per frame, and MPEG1/2 layer 1 has 384 samples per frame.
Second, 26 ms/frame is (1) rounded and (2) only valid for
44.1kHz sample rate. The equation is dead simple:
frametime = samplesperframe / samplerate
whic yields 26.122448979... ms/frame for 44.1 kHz layer 3
> When I print the time at the end of the walker, I simply do
> totAudioFrames*0.26 ...which I have noticed disagrees with
> WinAmp (my time is shorter than WinAmp) ....and my test files
> have been at 48K recently ...maybe 0.26 is only correct for
> 44.1K files?
> Another question which I have yet to locate an answer for. The
> "file length in bytes" entry in the Xing header ...is that the
> total of all Audio Frames, or the literal Size Of The .MP3
> File ...I can theorise it both ways in my head, but as I hope
> to put some "VbrFix" code in the fixing util, it seems
> sensible to be right first time if possible.
The standard is vague, but all non-rockbox files I checked show
me that it is the length *including* the Xing header but
*excluding* any id3v1 and id3v2 tags.
>> > That is, (by example) what if my Xing header were in an
>> > Audio frame which claimed to be at 48K ...but the first
>> > _real_ Audio frame (and all subsequent Audio frames) are
>> > actually 44.1K ...would any-body or more to the point
>> > any-software complain?
>> Many mp3 frame analysers complain if the sample rate or mpeg
>> version changes mid-stream. I found no written standards for
>> this, but I think only the following fields in the frame
>> headers are allowed to change within one stream: Bitrate,
>> Padding bit, Private bit, Mode extension. One more field may
>> change between xing header and the rest of the stream: the
>> Protection bit.
> Yes, protection ...my code has a sarcastic comment in it about
> writing a CRC algorithm - do we know the initialiser,
> polynomial, and suffixor for the CRC algorithm used in MP3?
Yes we have. It's a CRC-16, the polynomial is standard 0x8005,
initialiser is 0xffff. The CRC is computed across the frame
content excluding the header and the CRC field itself and
stored as big endian value.
Note: If you encounter a frame which is marked as protected but
the CRC field is zero, it was encoded by an old ISO encoder.
Also note that the protection bit is negated; 0 means protected.
(found it in the lame sources iirc)
Received on Sun Nov 20 00:41:38 2005