@Jens: embedded below
@users: If I could collect half a dozen dodgy files from people that would
be great - send them to me directly at my gmail account (I'll just _hope_ I
don't get 200MB of them sent to me) each with a brief description of the
problem (maybe just "stops playing at about 2:20") ...feel free to include
tagged and/or untagged files (mention please if the file has tags. And if
so, what type id3v1/id3v2/apev1/apev2/etc)
If I can get (the) one which corrects itself again, that would be useful
...and if there is one known to have two errors which does not cause a self
correction - also great.
> > 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.
OK, so LSL/LSR within a range of file.
> > The clever bit is knowing where the error starts - could this
> > be done by "frame-walking" until we find a bad frame?
Reading mp3 spec now.
> > 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.
Hmmm. I think I need to see a couple of files to understand that.
Do we know if the DAC always ADDS or always LOSES bits or A MIX of both?
Do you believe the problem to be a corruption of the frame which has just
finished or a corruption of the frame which is about to start?
> > 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 Fri Nov 4 05:53:16 2005