[MPlayer-users] mencoder bug? (mp3 codec detection)

[phoen][x]

hey.

well i started writing an avi parser a few days ago and i did see some
odd behaviour of mencoder (i use it as reference program for the parser,
cause its able to read every header (pretty nice))

okay here is what i did:
in order to find the mp3 header in an avi file, i search through the
file till i find an "fffb" (MPEG1.0 Layer3 w/o crc) or "fff3" (MPEG2.0
Layer3 w/o crc). i start at offset 0x1000 (cause i dont want to find a
random piece of data). i know that this is not a nice way to do mp3
header parsing, but hey - its my first try (and i'm not good at c, so i
dont understand ~any~ of the *demux.c files - seriously, i tried to
understand them.

a few of my media files (divx of course) are parsed as
"MPEG 1.0 L3 Bitrate 96kbps Frequency 48khz" (my scripts output)

mencoder interpretes it as:
mp3lib: using 3DNow!Ex optimized decore!
MPEG 1.0, Layer III, 44100 Hz 320 kbit Joint-Stereo, BPF: 1044
Channels: 2, copyright: Yes, original: Yes, CRC: No, emphasis: 0
AUDIO: srate=44100  chans=2  bps=2  sfmt=0x10  ratio: 40000->176400

i got confused and did recalc the informations of mencoder to octal
values:

mp3 headers start with 12bits sync:
>>1111.1111.1111

after that 1 bit for version (1=mpeg1), 2bits for layer (01=layer3), 1
bit for errorprotection (1=off)
>>1011

lets continue with the 4 bitrate index bits: mpeg1, layer3, 320kbps
thats a 14, converted to binary:
>>1110

sampling frequency is 2bits long (44.1khz in mpeg1 is 00), 1bit for
padding (0=no) and 1bit for extension (0=none)
>>0000

next step is the mode(2bits). we are in joint stereo, so its 01. after 
that, 2bits for mode_extension: 00.
>>0100

1bit for copyright (0=no), 1bit for original (1=yes), 2bits for emphasis
(00=none)
>>0100

now we have the following 4 bytes:
1111.1111 1111.1011 1110.0000 0100.0100
recalced to octal, thats:
 F    F    F    B    E    0    4    4

"FFFBE044"
fine, with that knowledge i started my `hexdump`
(the bytes are kinda twisted in hexdumps view - if you want to look for
FFFB you have to search for FBFF instead. kinda weird (i bet that theres
a parameter for it, but i cant be bothered to find it now))
anyways:
`hexdump foo.avi | grep 'fbff 44e0'`
returned not a single hit. 
`hexdump foo.avi | grep 'fbff' | more`
returns tonsa hits, but everything is completely bollox and far from an
mp3 header :)

so, i wonder whats wrong? can it be that the mp3 header is fragmented or
something? or is mencoders 320kbps guessed (i played the file, and i
cant hear a difference to 128 (i know that it means nothing :)))

if you need the first few megabytes of the file, say so and i'll upload
them.

-phoen][x-
p.s.: or am i completely wrong? :/