From: Jens Arnold <arnold-j_at_t-online.de>
Date: Wed, 02 Nov 2005 21:35:30 +0100

On 02.11.2005, [IDC]Dragon wrote:

> LinusN wrote:

>> There is a bug in the MP3 encoding chip that makes it lose a
>> few bits in the stream, and the recorded data will be
>> shifted, i.e not byte-aligned anymore. This is more likely to
>> happen if you record with a high quality setting.

>> There is unfortunately nothing we can do about it.

> Not exactly true, probably Linus didn't want to spur too high
> expectations. ;-)

> The MAS has a bug, you could solder in a more recent chip to
> really resolve the problem. All Archos have the older, buggy
> version.

> Or Rockbox does a similar workaround like the Archos firmware
> does: It tracks the frames of incoming mp3 data. In case of a
> mismatch the MAS gets restarted. Results in a minor glitch in
> the recording, but will hardly get noticed, as rare as it
> happens.

I'll try to explain the nature of the problem a bit more:

The MAS encodes the audio data to an mp3 bitstream. The data is
then transferred to the main CPU via a parallel interface using
a special protocol. Occasionally the MAS loses a few bits during
an internal transfer, so even though the external interface is
parallel, the data is bit-shifted after the bit loss. While the
data is still a correct mp3 bitstream, the fact that it is no
longer aligned to the byte boundaries makes most players choke
on it. The MAS itself is able to play such streams, but playback
stutters.

>From really extensive recording tests (rough estimate: several
weeks of recorded data) I found that the probability of such a
glitch occurring increases with:

- increasing quality setting (there must be a reason why the
  *recommended* quality setting of the MAS is 5, *not* 7)

- increasing recording level (Note: this does not mean that only
  overdriving triggers it!)

- increasing transfer speed at the parallel interface. This is
  the reason why rockbox 2.3 and 2.4 are worse than 2.2 and 2.5.
  2.3 and 2.4 contained an assembler optimised transfer loop for
  the recording data - which was a bad idea considering the now-
  known facts.

The probability varies a lot, I observed intervals of ~10
minutes to several hours between two glitches - if they happen
at all.

It's impossible to avoid this glitch, but a workaround is
possible. Rockbox will need to continuously scan the bitstream
for frame headers while recording ("do the frame-walk"), and
restart the encoder if it finds an error. This will cause a
small glitch at the point where the encoder is restarted, but
imho that's still much better than hours of unusable (without
repair work) recordings.

I also tried some long recordings with the archos firmware, and
although I didn't get corrupted recordings with it, I believe
the archos recorder firmware does not work around the problem,
although it seems to do the frame-walk. Usually the archos
firmware shut down or hung at some point - i think that
happened when the glitch occurred.

> The latter has been discussed on IRC, perhaps will get
> implemented one day. (Jens? ;-)

Yes, one day, probably before the next release. I'm a bit fed up
with the MAS, otherwise I would have tackled the PCM codec
already... :-/

Regards, Jens
Received on 2005-11-02