|
Rockbox mail archiveSubject: Re: Recording problemRe: 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 |