With larger sound files, I've seen soundfiler fail to resize arrays, even with an appropriate -maxsize value. For instance, with a .wav file that's 45205253 samples long (about 17 minutes), this message produces a "resize failed" error:
[read -resize -maxsize 4.52053e+07 test.wav sf-test(
But if I resize the table to 45205253 points directly beforehand, a regular read message to soundfiler loads the complete file properly. I've searched the list to see if this has been brought up before, but didn't find anything... Am I missing something?
I've seen the same problem
2010/1/30 William Brent william.brent@gmail.com
With larger sound files, I've seen soundfiler fail to resize arrays, even with an appropriate -maxsize value. For instance, with a .wav file that's 45205253 samples long (about 17 minutes), this message produces a "resize failed" error:
[read -resize -maxsize 4.52053e+07 test.wav sf-test(
But if I resize the table to 45205253 points directly beforehand, a regular read message to soundfiler loads the complete file properly. I've searched the list to see if this has been brought up before, but didn't find anything... Am I missing something?
-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thomas thiery wrote:
I've seen the same problem
this is a "known" bug (at least i reported it and a way to fix it; have a look at the bug tracker).
currently, the length of an array is returned as a single precision float, which makes soundfiler think that the resize failed, as the requested size and the resized size seem to differ (due to precision problems)
the problem with solving the bug is, that it would actually require an API change of Pd.
fmasdr IOhannes
-
IOhannes m zmölnig -
thomas thiery -
William Brent