From: Bluechip <csbluechip_at_gmail.com>
Date: Sat, 19 Nov 2005 13:32:23 +0000

> > Is there any reason why the Audio frame which contains the
> > Xing header should be at the same sample rate (32K, 44.1K,
> > 48K) as the main Audio data?
>
>Yes.
>
>First, there may be players which don't support xing headers, so
>they treat them as a standard audio frame. That's the reason why
>the xing header mimics a standard frame in the first place.

I will go with the advice of you and Linus on this and maintain the
samplerate in the fix util (which is almost done - "at last" I hear you say
- "critical typo in the source, sorry" I reply.)

I do wonder how far we should be taking backward-compatability. I find it
hard to believe that there still exist players - which are in any way
relevant to users of rockbox - which do not support such ageing standards
...says the man emailing you from a windoze98 machine. Perhaps not a topic
for here, but I thought it, and I thought I'd share <shrugs>

>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?

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.

> > 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?

When will the world adopt Adler32 ...equal in efficiency, cheaper in code
AND faster! Invented by the guy responisble for gzip (Mark Adler) ...so,
for validity, that'll do for me! ...another off topic comment - my brain is
working overtime today.

> > BC
>
>Regards, Jens

Thanks again for your help Jens,

BC
Received on 2005-11-19