On 02.11.2005, Bluechip wrote:
>> >> > > 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
>> >> 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
>>>>> 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
>>>> bit loss occurs. Without, your recording is toast after
>>>> 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.
Yes it's possible with enough effort.
> I guess all your program does is insert/remove N bits at
> offset X in a file.
Almost. It allows to shift a certain range within a file by a
certain amount of bits (-7 <= shift <= +7). Bits shifted out at
one end of the block are lost, bits shifted in at the other end
are zero. The total file size isn't changed.
> 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.
We don't need to walk bitwise. We need to figure the shift
amount anyway, and if we know that, the frame headers in the
shifted part of the stream are recognisable.
This glitch isn't about one (or a few) shifted frames. When it
happens, *all* subsequent frames are bitshifted by the same
amount, unless the glitch happens again (after hours), then
there will be a new shift amount. I even observed one occasion
where the second shift corrected the first one, after two hours
> 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?
As I already mentioned, there were no residual glitches after
reparing my test recordings, so it seems no corrupt frame
remains once the shift is corrected. It seems that the shift
change always happens at frame boundaries.
> 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 Thu Nov 3 01:46:21 2005