From: Bluechip <csbluechip_at_gmail.com>
Date: Wed, 02 Nov 2005 21:52:48 +0000

> >> > > 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 mostly record concerts, typically 2-4 hours at a go.
> >> > Less than half my files make it through MP3Fixer
> >> > unscathed.
> >> > It's not rare in my experience.
>
> >> No, misunderstanding:
> >> The workaround would cause a minor glitch every few hours
> >> (that's something I could live with and call rare), when the
> >> bit loss occurs. Without, your recording is toast after that,
> >> or has to be rescued with Jens' very special tool.
>
> > From where does one obtain a copy of Jens' tool?
>
> >From nowhere so far. This isn't because I don't want to disclose
>the sources, but because the tool is far from user-friendly.
>All it can do is to shift a certain range of bytes within a file
>by a certain number of bits.
>
>It is possible to repair recordings suffering from the MAS
>glitch with it, but the procedure isn't automatic. First, one
>would need to analyse the broken recording with a hex editor,
>and find the exact starting point(s) of the glitch(es), and the
>shift amount. Then this tool can be used to undo the bitshift(s)
>in the file, effectively repairing the recording.
>
>I tested this method with a few of my lengthy test recordings,
>and repaired them successfully. It might happen that a small
>glitch remains at the point(s) where the bit shift(s) originally
>started, but in my tests I didn't notice any remaining glitches.
>
>You see, the method is tedious, but maybe it's still worth a try
>for valuable recordings.

Hey Jens,

Do you think that it is possible to automate the procedure? I mean, within
the realms of reasonable.

I guess all your program does is insert/remove N bits at offset X in a file.

The clever bit is knowing where the error starts - could this be done by
"frame-walking" until we find a bad frame?

And secondly knowing where the next good frame starts - which I guess would
be a bit-wise "frame-walk" rather than a byte-wise walk as in the first
half of the problem.

Finally what to do about the corrupt frame - strip it?
Can we know what data is missing? Ie. is it header data or audio date that
gets corrupted?

I guess it's not a 2 minute job or tou would have already done it! But as
it would be a third-party tool rather than an enhancement to rockbox -
perhaps I could help?

BC
Received on 2005-11-02