Menu
▾
▴
[ glame-Bugs-527631 ] Import WAV broken
|
From: <no...@so...> - 2002-03-25 14:39:00
|
Bugs item #527631, was opened at 2002-03-08 23:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=101627&aid=527631&group_id=1627 Category: Midlayer Group: normal Status: Open Resolution: Works For Me Priority: 1 Submitted By: Michael Schwendt (mschwendt) Assigned to: Daniel Kobras (nold) Summary: Import WAV broken Initial Comment: I'm running glame 0.6.1 (and 0.6.0) from http://enigma.freshrpms.net on Red Hat Linux 7.2 (Enigma). That binary is compiled with --enable-low-latency. I've found an mp3 which, after converted to WAV with xmms's disk writer, is truncated to random lengths when imported with glame. The mp3 is this one: http://remix64.phatsites.de/?tune=1195 While the source file is 4:11 long, the first time I tried to reproduce this bug and imported the file several times, it ended at 166.441s, the second time at 98.081s, the third time at 203.593s, and so on. These lengths change each time. The exported files are also truncated to those lengths. This is 100% reproducible with this particular file. ---------------------------------------------------------------------- >Comment By: Richard Guenther (richi) Date: 2002-03-25 14:38 Message: Logged In: YES user_id=7575 Also, can you try out the current stable (v0_6 branch) CVS? It has a cleanup'ed file import from the unstable branch - it shouldnt fix anything, but who knows (at least it adds error handling). Thanx again, Richard. ---------------------------------------------------------------------- Comment By: Richard Guenther (richi) Date: 2002-03-25 14:26 Message: Logged In: YES user_id=7575 To help us reproduce the bug, can you tell us something about your machine? I.e. is it rather fast (new Athlon/P4) or very slow (old Pentium, etc.)? Anything unusual (not ix86 architecture)? Very strange bug... Richard. ---------------------------------------------------------------------- Comment By: Michael Schwendt (mschwendt) Date: 2002-03-25 14:16 Message: Logged In: YES user_id=62241 Didn't fix it. Again, the first bad import had this extra line in debug output: waiter: starting cleanup -> fbuf_free_buffers: freed 4 buffers waiter: finished All others were good and didn't have that line. Also, the activity in the progress bar pretends the complete file was imported. Nevertheless, the final result is truncated (both according to number of samples and length in seconds). Btw, I'll later try it again on Red Hat Linux beta version, mounting a partition on the same hard-drive. I bet timing is an issue here. ---------------------------------------------------------------------- Comment By: Richard Guenther (richi) Date: 2002-03-25 13:43 Message: Logged In: YES user_id=7575 Can you try to apply the attached patch? It fixes a possible race on import. Thanx, Richard. ---------------------------------------------------------------------- Comment By: Michael Schwendt (mschwendt) Date: 2002-03-25 10:41 Message: Logged In: YES user_id=62241 A second typescript attached. Same symptoms. ---------------------------------------------------------------------- Comment By: Michael Schwendt (mschwendt) Date: 2002-03-25 10:40 Message: Logged In: YES user_id=62241 Good tip. I can reproduce the problem also with the internal audiofile replacement. Complete typescript is attached. I've rebuilt glame 0.6.1 with the libaudiofile code in "configure" taken out. config.h ends with undefined HAVE_AUDIOFILE. libaudiofile is linked only for ESD/GNOME, I think. Additionally, I've set --enable-debug and --enable-swapfiledebug. Debug output is a bit confusing. Seems libaudiofile is still used for taking a first peek at a WAV header. But "afOpenFile: Using internal audiofile replacement." suggests, it is not used for the actual reading. The typescript includes a few _good_ import/delete operations and ends with a last truncated import operation. An 8:11 minutes long file ends at 227.370s. "df" proves that enough space is left in $HOME. A bad import has waiter: starting cleanup -> fbuf_free_buffers: freed 4 buffers waiter: finished in the debug log while a good import has just: waiter: starting cleanup waiter: finished Any further ideas? pthreads an issue? ---------------------------------------------------------------------- Comment By: Daniel Kobras (nold) Date: 2002-03-24 23:38 Message: Logged In: YES user_id=7832 It's really hard to tell what causes this bug for we can't reproduce this behaviour so far. Since bleeding-edge RH works okay, apparently, this really sounds like some weirdness in a lib, rather than in glame itself. You're absolutely positive that glame on RH 7.2 used the uptodate audiofile, rather than some ancient version still lurking on the drive? Furthermore, you can try to comment out the '#define HAVE_AUDIOFILE 1' in config.h just after running configure, and re-compile glame (make clean, make), so it will use a basic internal wav loader instead of audiofile's. In short, I don't have the faintest idea what might be going on. ---------------------------------------------------------------------- Comment By: Michael Schwendt (mschwendt) Date: 2002-03-24 16:51 Message: Logged In: YES user_id=62241 Upgrading libaudiofile to 0.2.3 _and_ rebuilding glame 0.6.1 didn't help on Red Hat Linux 7.2 (same stable machine, just a different hard-drive). While I'm typing this I have two other WAV files with which the problem is top reproducible, even when I start from scratch (rm -rf ~/.glamerc ~/.glameswap). I import the first one. Okay. I import the second one. It ends truncated, 20s missing. Lots of free space available. I import the second one another time without deleting the previous track. It ends with an even different truncated size (216.967s instead of 8:22 minutes). I import it again as the fourth track, it imports completely. Absolutely weird. Something is terribly wrong here with glame 0.6.1 on Red Hat Linux 7.2. I'll keep an eye on this... ---------------------------------------------------------------------- Comment By: Michael Schwendt (mschwendt) Date: 2002-03-24 15:51 Message: Logged In: YES user_id=62241 Two corrections: - it is NOT 100% reproducible unfortunately - it can happen with other WAV files, too I was happy to find that WAV file mentioned in the first comment, because I could import it arbitrary times, and it would always end up with a different length. It was my assumption that internal calculations on this specific WAV file would be the cause of these import errors. Other WAV files worked fine at the same time. However, I just found that it needs more than just importing this file one or multiple times. On Red Hat Linux 7.2 (fully updated) I just had to import, delete, empty deleted, a couple of files until the error occured for track 0 of 1 of a newly imported file. That track ended up shorter than the second. Lack of glame swap space is surely not a problem on that machine. /home, where glameswap is located, has plenty of space. Right now on Red Hat Linux 7.2.92 (beta), with libaudiofile 0.2.3 I seem unable to reproduce this bug so far. I've gone through a loop of importing, deleting, etc. several WAVs a dozen times, but without errors. :) I'll probably go and see how Red Hat 7.2 behaves when it try to update libaudiofile 0.2.1 there. ---------------------------------------------------------------------- Comment By: Michael Schwendt (mschwendt) Date: 2002-03-24 14:11 Message: Logged In: YES user_id=62241 Hmmm, so you think it is a bug in libaudiofile? $ rpm -q audiofile audiofile-0.2.1-2 Because creating/saving the WAV with XMMS is fine. I'll try it later on Red Hat's current beta version. ---------------------------------------------------------------------- Comment By: Richard Guenther (richi) Date: 2002-03-24 13:34 Message: Logged In: YES user_id=7575 Seems to be libaudiofile version (for the loading part) or xmms version (for the saving part) related. At least I'm not able to reproduce this behavior. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=101627&aid=527631&group_id=1627 |