> > 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 :)
Happy new thing,
Received on Thu Dec 29 01:46:06 2005