> Just noticed something that may be of interest. With reference
> to the dump attached below:
> Notice how there is a difference of 3 between the Xing-Hdr
> frame count and the actual number of audio frames.
The Xing frame count in rockbox recordings was never exact so
far, as it just uses the internal frame counter of the MAS. This
doesn't always match the number of transferred frames, there
seems to be some buffering going on in the MAS itself. The error
is usually 1..3 frames.
With older rockbox, long recordings which overflow the MAS frame
counter as well as recordings made with prerecording active had
no Xing frame count at all.
The MAS frame counter is a 20bit signed counter which doesn't
wrap but saturate (!!) at 0x7ffff.
OMG! Surely you can't code that by accident!?
The stupidity of signing the number I can accept as a typo or one of the
enginners using a time machine and recording -2104 frames of audio. But:
if (cnt<0x7FFFF) cnt++; ...LOL
Newer rockbox versions always write a Xing frame count, tracking
the MAS frame counter during prerecording and estimating the
count for long recordings using the recording time. When rockbox
resorts to estimation, the error increases, but it's still
better than nothing for estimating playtime and average bitrate.
Oh well. I thought I may have spotted a solution, but it's all pretty
academic anyway as the Xing/TOC is invalid, and correcting that, even
on-the-fly, would be (possibly unacceptably) memory hungry.
All this will change when framewalking during recording gets
implemented (something that is on my list) as we won't use the
MAS frame counter any more.
AIS, storing enough data to build a correct TOC might be an unacceptable
overhead. So it could be a lot of effort for little payback.
I think I'll attack the WAV codec on the Archos when I've finished my
latest little project - lots of fun to be had once that is done :)
Regards, Jens
Happy new thing,
BC
