-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [To: flac-dev@lists.sourceforge.net] On Sun, 10 Nov 2002, Josh Coalson wrote:> Hmm, that's how the plugins work. They are using the file > decoder layer but that's a pretty trivial wrapper around > the seekable stream decoder. Without seeing your code there's > not much else I can say.Do you want to see my code ;-)> When it loses sync, is the file still completely decoded without > gaps or errors in the data? It may be a buggy sync message > (which wouldn't show up in the plugins since they are ignored).The decoded audio has burps in it. As you would expect if some frames aren't decoded. I also have another problem. free(bb->buffer) in FLAC__bitbuffer_free, eventually called by the seekable stream decoder delete causes my application to crash. Very strange. I wounder if my two problems are related. The bitbuffer gets data moved around when read it called, so maybe they are related. It really seems like there is some memory craziness going on. I really hate C. - -- Russell O'Connor <math.berkeley.edu/~roconnor> ``[Law enforcement officials] suggested that the activists were stopped not because their names are on the list, but because their names resemble those of suspected criminals or terrorists.'' -- SFGate.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see gnupg.org iD8DBQE9z3peuZUa0PWVyWQRApMiAJ4qHIgB1tDexSYDAr6GcvtL0UxBXACfYNMY Lu7QYYYCnErKgpiuYMpjJoc=P184 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [To: flac-dev@lists.sourceforge.net] On Mon, 11 Nov 2002, Josh Coalson wrote:> > Very strange. I wounder if my two problems are related. The > > bitbuffer > > gets data moved around when read it called, so maybe they are > > related. > > It really seems like there is some memory craziness going on. > > Gets moved by who? It's hard for me to tell without seeing > your code.By libflac. Libflac has it's own buffer called a bitbuffer. When the buffer needs to be filled, there is usually some data at the end of the buffer (a part of a frame, may include parts of bits) that needs to be moved to the beginning of the buffer. (see FLAC__bool bitbuffer_read_from_client_). I thought this was using memmove but it seems that it doesn't. ... So maybe I was wrong about the relation between my two problems. It is all very strange. Something very fishy is going on. I've been trying to see if my CRT is to blame. Linking different versions at different times, but no luck yet. When I get time I'll fire up GDB to see if I can track down these problems. - -- Russell O'Connor <math.berkeley.edu/~roconnor> ``[Law enforcement officials] suggested that the activists were stopped not because their names are on the list, but because their names resemble those of suspected criminals or terrorists.'' -- SFGate.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see gnupg.org iD8DBQE90LenuZUa0PWVyWQRAoPHAJ9JJeDOMbncmtBIhiKae/f0UB5uDgCfZ61M 4s3q4IowdvCpoYgs3c5q5gU=VT4W -----END PGP SIGNATURE-----
--- Russell O'Connor <roconnor@Math.Berkeley.EDU> wrote:> > When it loses sync, is the file still completely decoded without > > gaps or errors in the data? It may be a buggy sync message > > (which wouldn't show up in the plugins since they are ignored). > > The decoded audio has burps in it. As you would expect if some > frames > aren't decoded. > > I also have another problem. free(bb->buffer) in > FLAC__bitbuffer_free, > eventually called by the seekable stream decoder delete causes my > application to crash. > > Very strange. I wounder if my two problems are related. The > bitbuffer > gets data moved around when read it called, so maybe they are > related. > It really seems like there is some memory craziness going on.Gets moved by who? It's hard for me to tell without seeing your code. Josh __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos launch.yahoo.com/u2