[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rockbox-dev
Subject:    Re: Corrupt Recordings
From:       Bluechip <csbluechip () gmail ! com>
Date:       2005-12-29 0:40:07
Message-ID: 6.1.2.0.2.20051229003409.05cf6ca0 () pop ! gmail ! com
[Download RAW message or body]


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

[prev in list] [next in list] [prev in thread] [next in thread]