#87 Imported .wav file data loss
GLAME version: 0.6.3
I have a rather large .wav file with the following
characteristics:
fmt chunk
format type: WAVE_FORMAT_PCM (0x0001)
channels: 2
samples/s: 44100
ave bytes/s: 176400
block align: 4
bits/sample: 16
data chunk
bytes: 182419456
Now when I import this into glame, it tells me that I've got
17:14 of audio (correct) and seems to import alright.
When the import is done, track 0 has 1034.124s of audio
(correct) and track 1 has 747.497s of audio (wrong).
And when I pull up an edit window the data is gone from
both the edit window and audio playback.
I've experienced a similar problem with GLAME 0.6.1
also (it was the track 0 instead of track 1 that was being
truncated).
Software configuration: SuSE Linux 8.0
Linux version 2.4.18-64GB-SMP
(root@SMP_X86.suse.de) (gcc version 2.95.3 20010315
(SuSE)) #1 SMP Wed Mar 27 13:58:12 UTC 2002
using KDE 3.0
CPU: dual Athlon
audio card: SBLive! 5.1
Logged In: YES
user_id=7575
Looks like bug #527631 - but still no clue as I cant
reproduce this. It would be useful to know wether you use
internal libaudiofile replacement or the version of
libaudiofile [check glame/config.h for HAVE_AUDIOFILE, check
the version of your installed libaudiofile library, probably
/usr/lib/libaudiofile.so.X.X.X]
Lowered priority, as very few people are actually seeing
this bug.
Logged In: YES
user_id=560196
HAVE_AUDIOFILE is #defined in config.h, using
/usr/lib/libaudiofile.so.0.0.2, I would guess.
I compiled it with --enable-debug and got this when I
import:
ie_filename_cb: Got filename sample_02.wav
read_file_set_filename: ftype = 4, version = 0
read_file_set_filename: File sample_02.wav: 2
channel(s) 16 bit signed at 44100 Hz, framecount
45604864, framesize 4.
ie_update_plabels: Here
ie_update_plabels: format property: 4 0, ftype=4,
version=0
ie_filename_cb: Got filename sample_02.wav
read_file_set_filename: ftype = 4, version = 0
read_file_set_filename: File sample_02.wav: 2
channel(s) 16 bit signed at 44100 Hz, framecount
45604864, framesize 4.
ie_update_plabels: Here
ie_update_plabels: format property: 4 0, ftype=4,
version=0
ie_filename_cb: Got filename sample_02.wav
read_file_set_filename: ftype = 4, version = 0
read_file_set_filename: File sample_02.wav: 2
channel(s) 16 bit signed at 44100 Hz, framecount
45604864, framesize 4.
ie_update_plabels: Here
ie_update_plabels: format property: 4 0, ftype=4,
version=0
ie_filename_cb: Got filename sample_02.wav
read_file_set_filename: ftype = 4, version = 0
read_file_set_filename: File sample_02.wav: 2
channel(s) 16 bit signed at 44100 Hz, framecount
45604864, framesize 4.
ie_update_plabels: Here
ie_update_plabels: format property: 4 0, ftype=4,
version=0
ie_import_cb: 1 file 0x82cf490
read_file_set_filename: ftype = 4, version = 0
read_file_set_filename: File sample_02.wav: 2
channel(s) 16 bit signed at 44100 Hz, framecount
45604864, framesize 4.
filter_launch: initting nodes
filter_launch: launching nodes
launch_node: issuing pthread_create for node track-1
launcher: track-1 launched (pid 32061)
launch_node: issuing pthread_create for node track-0
filter_after_init_hook: track-1 seems ready for signalling
launcher: track-0 launched (pid 32062)
filter_after_init_hook: track-0 seems ready for signalling
launch_node: issuing pthread_create for node readfile
launcher: readfile launched (pid 32063)
filter_after_init_hook: readfile seems ready for signalling
filter_launch: waiting for nodes to complete initialization
filter_launch: launching waiter
wait_node: Waiting for track-1.
filter_launch: all nodes launched.
filter_start: waiting for nodes to complete initialization.
swapfile_out_f: track-1 is ready now.
read_file_f: readfile is ready now.
swapfile_out_f: track-0 is ready now.
launcher: filter track-0 completed.
launcher: filter readfile completed.
launcher: filter track-1 completed.
wait_node: Waiting for track-0.
wait_node: Waiting for readfile.
waiter: starting cleanup
postprocess_node: freed 2 buffers created by readfile
waiter: finished
gpsm_vbox_insert: WARNING: doing ordinary remove
on vbox_insert
This time track 0 was short, not track 1. The actual
number of samples missing seems to vary when I
import the file repeatedly.
Logged In: YES
user_id=7575
Ok, this is very likely the same bug as #527631 - notice the
line
> postprocess_node: freed 2 buffers created by readfile
where it says it dropped 2 buffers read.
Can you #undef HAVE_AUDIOFILE in your config.h, re-build and
check if the problem persists (this way its easier to debug
for us). Also as it looks it may be libc (pthread) related,
what is the exact libc version on your system?
Thanx for feedback, Richard.
Logged In: YES
user_id=560196
I added #undef HAVE_AUDIOFILE to config.h and rebuilt.
I've tried importing that file a few times and have not had
truncated audio since. The libc I have is libc.so.6 from the
SuSE RPM glibc-2.2.5-38.
Logged In: YES
user_id=7575
Ok, so it seems to be a libaudiofile problem... which I cant
think of having such a problem... oh well.
Just keep your eye for the problem re-appear with the
internal audiofile replacement (#undef HAVE_AUDIOFILE).
Logged In: YES
user_id=7575
I believe I fixed this in CVS HEAD. A fix may be appear in
0.6.4, too.