> >> > > 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.
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
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?
Received on Wed Nov 2 22:53:47 2005