Batuhan Bozkurt wrote:
David Schaffer wrote:
Hello, Does anyone know the size limit of a 44.1k stereo wav file that "soundfiler" can handle? So far, I haven't been able to write more than 36562276 samples to a table (which represents 829 seconds of sound if I get it right). What can I do in order to be able to read larger files?
You should be able to load fairly large files to tables with the -resize option combined with -maxsize option. But there is obviously a limit. I remember being able to load more than 1 hours of 441.k "mono" files through soundfiler.
So sending [read -resize -maxsize 99999999 soundfile.wav(
to soundfiler object should work. obviously there is a limit to that maxsize sample length, and I'm not really sure about the number(and what limits it), but this limit may have something to do with your memory limits set in /etc/security/limits.conf if you are on linux but its just a guess.
16777215 ,aka (2^24) - 1, is the last sequential integer that can be accurately represented by a 32-bit float, the kind used in pd, so the 99999999 in the message, which pd processes as a 32-bit float, would probably end up as another value. (Some larger integers can be accurately represented but they are separated by increasingly large runs of unrepresentable integers). Perhaps you could split the file into several smaller tables?
Martin
martin.peach@sympatico.ca wrote:
Batuhan Bozkurt wrote:
David Schaffer wrote:
Hello, Does anyone know the size limit of a 44.1k stereo wav file that "soundfiler" can handle? So far, I haven't been able to write more than 36562276 samples to a table (which represents 829 seconds of sound if I get it right). What can I do in order to be able to read larger files?
You should be able to load fairly large files to tables with the -resize option combined with -maxsize option. But there is obviously a limit. I remember being able to load more than 1 hours of 441.k "mono" files through soundfiler.
So sending [read -resize -maxsize 99999999 soundfile.wav(
to soundfiler object should work. obviously there is a limit to that maxsize sample length, and I'm not really sure about the number(and what limits it), but this limit may have something to do with your memory limits set in /etc/security/limits.conf if you are on linux but its just a guess.
16777215 ,aka (2^24) - 1, is the last sequential integer that can be accurately represented by a 32-bit float, the kind used in pd, so the 99999999 in the message, which pd processes as a 32-bit float, would probably end up as another value. (Some larger integers can be accurately represented but they are separated by increasingly large runs of unrepresentable integers). Perhaps you could split the file into several smaller tables?
Martin
Yes Martin, you are right. The purpose of 99999999 number there was to make the maxsize as big as possible(one more digit and soundfiler was returning an error message afair). But I think I can load files that are bigger than 16777215 samples long(which makes approx. 6.3 minutes of 44.1kHz mono file). I'll check tonight and report.
On Tue, 11 Sep 2007, Batuhan Bozkurt wrote:
Yes Martin, you are right. The purpose of 99999999 number there was to make the maxsize as big as possible(one more digit and soundfiler was returning an error message afair). But I think I can load files that are bigger than 16777215 samples long(which makes approx. 6.3 minutes of 44.1kHz mono file). I'll check tonight and report.
What we're saying is that, even if you can do it, many objects will fail at supporting you in the reading of that data.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Tue, 2007-09-11 at 15:28 -0400, Mathieu Bouchard wrote:
On Tue, 11 Sep 2007, Batuhan Bozkurt wrote:
Yes Martin, you are right. The purpose of 99999999 number there was to make the maxsize as big as possible(one more digit and soundfiler was returning an error message afair). But I think I can load files that are bigger than 16777215 samples long(which makes approx. 6.3 minutes of 44.1kHz mono file). I'll check tonight and report.
What we're saying is that, even if you can do it, many objects will fail at supporting you in the reading of that data.
and when reading from a table (at least with the tabread~ objects) in that area, it will sound bad, because the index jumps from even to even number or, in higher ranges, only from multiples of 4 to multiples of 4 etc. in short: it'll sound bad. that is why using huge tables isn't a good idea, anyway.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
On Tue, 2007-09-11 at 15:28 -0400, Mathieu Bouchard wrote:
On Tue, 11 Sep 2007, Batuhan Bozkurt wrote:
Yes Martin, you are right. The purpose of 99999999 number there was to make the maxsize as big as possible(one more digit and soundfiler was returning an error message afair). But I think I can load files that are bigger than 16777215 samples long(which makes approx. 6.3 minutes of 44.1kHz mono file). I'll check tonight and report.
What we're saying is that, even if you can do it, many objects will fail at supporting you in the reading of that data.
and when reading from a table (at least with the tabread~ objects) in that area, it will sound bad, because the index jumps from even to even number or, in higher ranges, only from multiples of 4 to multiples of 4 etc. in short: it'll sound bad. that is why using huge tables isn't a good idea, anyway.
roman
Yes, I've tried how it works in an isolated way and you are right. thanks Batuhan
On Tue, 11 Sep 2007, martin.peach@sympatico.ca wrote:
16777215 ,aka (2^24) - 1, is the last sequential integer that can be accurately represented by a 32-bit float,
Starting with 16777216, only even numbers are representable, but 16777216 is an even number, so 16777216 is the last sequential integer that can be accurately represented by a 32-bit float.
the kind used in pd, so the 99999999 in the message, which pd processes as a 32-bit float, would probably end up as another value.
It would *certainly* become 100000000 exactly, because representable numbers in that range are only multiples of 8, and 100000000 is the closest one.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Batuhan Bozkurt -
martin.peach＠sympatico.ca -
Mathieu Bouchard -
Roman Haefeli