Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Recording problem

Re: Recording problem

From: Bluechip <csbluechip_at_gmail.com>
Date: Fri, 04 Nov 2005 04:48:46 +0000

_at_Jens: embedded below

_at_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.

<snips>

> > 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?
>
>Yes.

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
>or so.
>
> > 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?
>
>Sure.

On it.

>Regards, Jens

BC
Received on 2005-11-04

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy