I think iemlib/soundfile_info is less buggy than ext13/wavinfo these
days.

.hc

On Nov 23, 2010, at 3:44 AM, João Pais wrote:

I usually use the [wavinfo] to know how big a file is, and then
maxsize $1 to set an array to the necessary size.

Maybe it would make sense to remove this 4M samples boundary from
Pd? there are more and more people for whom that's just in the way.

João

...

Check the help patch for soundfiler, you'll need to use the - maxsize flag in your [read( message and set it to something bigger.

.hc

On Nov 22, 2010, at 8:24 PM, ronni montoya wrote:

...

hello, when i load a big .wav file with sounfiler i get this
message:

soundfiler_read: truncated to 4000000 elements ?

and i cant load the complety sound , just a part.

Is there any way of loading complete .wav files?

thanks

R.

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp

Programs should be written for people to read, and only incidentally
for machines to execute.

• from Structure and Interpretation of Computer Programs

didn't know about that, which interpolation are you speaking about? in the
table everything should be correct, right? do you have any precise description of that problem?

And keep in mind that sound quality goes down as file size goes up. This
is because of the interpolation. You might do better cutting your file
up and putting it into several different arrays.

D.

On 11/23/10 4:16 AM, Hans-Christoph Steiner wrote:

...

Check the help patch for soundfiler, you'll need to use the -maxsize flag in your [read( message and set it to something bigger.

.hc

On Nov 22, 2010, at 8:24 PM, ronni montoya wrote:

...

hello, when i load a big .wav file with sounfiler i get this message:

soundfiler_read: truncated to 4000000 elements ?

On Tue, 23 Nov 2010, Derek Holzer wrote:

And keep in mind that sound quality goes down as file size goes up. This is because of the interpolation. You might do better cutting your file up and putting it into several different arrays.

If you play at normal speed with [tabread~] (not 4), you hit that problem anyway at index 16777216, and it's not because of any interpolation.

However, if you do use [tabread4~] with fractional floats, you hit the problem at much lower indices, because fractions disappear gradually first, then odd numbers disappear, etc.

Overall, it's because for a float, the numerator has to be between 8388608 and 16777215, while the denominator (or the multiplier) is a power of two... so each time you cross a new power of two, you lose half of the details, as the tiniest steps double in size.

| Mathieu Bouchard ------------------------------------- Aix-en-Provence

On Fri, 26 Nov 2010, Derek Holzer wrote:

So what could the max size of a file be without losing any detail with [tabread4~]?

There is no such thing... It's completely relative to the amount of detail you want to have. If you want a million points between sample 1 and sample 2 you can have them, but if you go between 100 and 101 you already can't have that anymore. If you want to be able to use sixteenths of samples, you can up to sample 1048576, but after that it's only eights, until the double of that size, etc.

[tabread4~] is made to read between the samples, but there's no standard on how many points between the samples one might want... it depends on what you decide to do with the data, and the maximum error you can tolerate in that situation.

Is that the hardcoded 4000000 elements limitation?

I think that it's just so that you don't load something too big, for the typical amounts of RAM that people had back when [soundfiler] was written.

| Mathieu Bouchard ------------------------------------- Aix-en-Provence

On Sat, 2010-11-27 at 11:20 +0100, Derek Holzer wrote:

That's a nice theoretical explanation Mathieu (no sarcasm intended), but let's think practical for a second. If you were going to give some simple advice to Pd newcomers about the length of a soundfile they should load to be read by [tabread4~] without noticeable distortions, what would it be? Please no "what do you consider noticeable" discussions, let's just think friendly suggestion ;-)

I _guess_ there is probably no rule of thumb here. I also believe this is dependent on the content of the table. Consider very low frequencies: A small error in time won't lead to a small error in amplitude, whereas for high frequencies a tiny error in time will probably cause a huge error in amplitude. What I am trying to say is that the "noticability" is likely different with each sound file.

When playing a table at Pd's native rate, you can play tables error-free with up to 16777215 samples. At 44.1kHz, this would translate to ~6min20s length in time.

When using interpolation, you might have to use your ears to decide what's O.K. for you. The problem is, though, that the interpolation algorithm used in [tabread4~] some consider as bad (me included) and adds some unnecessary distortion (i.e. discontinuities in the first derivate). This makes it hard to distinguish errors introduced by precision problem from errors introduced by the 'bad' algorithm.

Roman

On 11/27/10 7:40 AM, Mathieu Bouchard wrote:

...

On Fri, 26 Nov 2010, Derek Holzer wrote:

...

So what could the max size of a file be without losing any detail with [tabread4~]?

There is no such thing... It's completely relative to the amount of detail you want to have. If you want a million points between sample 1 and sample 2 you can have them, but if you go between 100 and 101 you already can't have that anymore. If you want to be able to use sixteenths of samples, you can up to sample 1048576, but after that it's only eights, until the double of that size, etc.

[tabread4~] is made to read between the samples, but there's no standard on how many points between the samples one might want... it depends on what you decide to do with the data, and the maximum error you can tolerate in that situation.

...

Is that the hardcoded 4000000 elements limitation?

I think that it's just so that you don't load something too big, for the typical amounts of RAM that people had back when [soundfiler] was written.

---

| Mathieu Bouchard ------------------------------------- Aix-en-Provence

On Sat, 27 Nov 2010, Derek Holzer wrote:

Thank you Roman, this is exactly the kind of concise and clear information I was looking for to include in the chapters on sample playback in the Pd FLOSS Manual!

But that is relevant to [tabread~] and [tabread], NOT [tabread4~], which is normally used with more resolution : in the latter case, you divide the 6 minutes into the number of steps you expect to need between samples. If you play at speed 1.125, that's 9/8, so, you need 1/8 steps, so, divide 6m20s by 8. With different denominators (1.1 = 11/10) it can get complicated though.

| Mathieu Bouchard ------------------------------------- Aix-en-Provence

do I interpret it correct if I assume that a solution for [tabread~]-ing big files without quality loss would be to make a counter and split one big [line~] movement into small segments ?

something like:

[metro 100] | [f]X[+ 4410] | [s adder]

and

[r adder] | [t b f] | | [0, 4410 100( | | / [line~] / | ______ / [+~] | [tabread~]

? gr, Tim

2010/11/29 IOhannes m zmölnig zmoelnig@iem.at

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 11/28/2010 08:40 PM, Mathieu Bouchard wrote:

...

On Sat, 27 Nov 2010, Derek Holzer wrote:

...

Thank you Roman, this is exactly the kind of concise and clear information I was looking for to include in the chapters on sample playback in the Pd FLOSS Manual!

But that is relevant to [tabread~] and [tabread], NOT [tabread4~], which

furthermore, if you only need to play back without transposing, you might also want to consider [tabplay~] (depending on your problem of course), which does not has this problem at all.

fgart IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzzak8ACgkQkX2Xpv6ydvQiSwCfdb+dAzFq4rSAET5bP3C3aBoU iM8AniFQx104laXpsXIhra5NbUXXc/vU =XH3S -----END PGP SIGNATURE-----

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

2010/11/29 IOhannes m zmoelnig zmoelnig@iem.at

On 2010-11-29 14:45, tim vets wrote:

...

do I interpret it correct if I assume that a solution for [tabread~]-ing

big

...

files without quality loss would be to make a counter and split one big [line~] movement into small segments ?

something like:

[metro 100] | [f]X[+ 4410] | [s adder]

and

[r adder] | [t b f] | | [0, 4410 100( | | / [line~] / | ______ / [+~]

??? you are still hitting the problem that the output of [+~] has probably to little precision.

your patch will thus not give you any benefit.

...

| [tabread~]

i was _not_ talking about [tabread~] but about [tabplay~]

sorry if I was not clear, I was in fact thinking of Mathieu's message:

"If you have to play a very large file in RAM, you can do it by emptying your signal-rate counter into a message-rate counter that takes care of the big digits while the signal-rate counter keeps on taking care of the small digits and fractions. (do you want an example ?) "

which afaict he didn't give an example for yet. I'm not sure what he meant, but that was what I made up of it...probably wrong :)

Tim

[bang(

| [tabplay~]

alternatively you can use the send inlet (message!) of [tabread4~] for better precision. the help-patch directs you to B15.tabread4~-onset.pd

msdfrt# IOhannes

On Mon, 29 Nov 2010, tim vets wrote:

"If you have to play a very large file in RAM, you can do it by emptying your signal-rate counter into a message-rate counter that takes care of the big digits while the signal-rate counter keeps on taking care of the small digits and fractions. (do you want an example ?) " which afaict he didn't give an example for yet. I'm not sure what he meant, but that was what I made up of it...probably wrong :)

Done...

The idea is that if you want very precise [tabread4~] on large sounds, you have to do the lookup relatively to a recently looked-up point, so, at every block boundary, the newest point becomes the new reference point, such that the signal-rate read-head stays in low values (high precision), whereas the message-rate read-head does all the large motion. That way, you can get up to twice the number of precision bits (but usually less than that).

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

Yes please! D.

On 11/25/10 1:57 PM, Mathieu Bouchard wrote:

On Tue, 23 Nov 2010, Derek Holzer wrote:

...

And keep in mind that sound quality goes down as file size goes up. This is because of the interpolation. You might do better cutting your file up and putting it into several different arrays.

Oh, and isn't it the case that [tabread~] 0.42 has an extra inlet for the purpose of getting more precision ? The read point is now relative to a message-rate setting.

If you have to play a very large file in RAM, you can do it by emptying your signal-rate counter into a message-rate counter that takes care of the big digits while the signal-rate counter keeps on taking care of the small digits and fractions. (do you want an example ?)

---

| Mathieu Bouchard ------------------------------------- Aix-en-Provence

how about removing the expXXX numbers, and use only concrete floats? or is
there any software reason that doesn't let that happen?

On Tue, 23 Nov 2010, Derek Holzer wrote:

...

And keep in mind that sound quality goes down as file size goes up.
This is because of the interpolation. You might do better cutting your
file up and putting it into several different arrays.

Oh, and isn't it the case that [tabread~] 0.42 has an extra inlet for
the purpose of getting more precision ? The read point is now relative
to a message-rate setting.

If you have to play a very large file in RAM, you can do it by emptying
your signal-rate counter into a message-rate counter that takes care of
the big digits while the signal-rate counter keeps on taking care of the
small digits and fractions. (do you want an example ?)

---

| Mathieu Bouchard ------------------------------------- Aix-en-Provence

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

On Fri, 26 Nov 2010, Roman Haefeli wrote:

Anyway, I think the solution would be to use 64bit float as the index. In 64-bit Pd, this isn't an issue anymore (or more correct: It will be with _much_ larger tables).

If using the full 64-bit range, we won't have enough RAM in year 2040 to reach the limit. That's unless we start using mmap() like crazy, to waste a lot of RAM indices (possible pointers).

| Mathieu Bouchard ------------------------------------- Aix-en-Provence

On Fri, 2010-11-26 at 10:30 +0100, IOhannes m zmölnig wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 11/26/2010 08:34 AM, Roman Haefeli wrote:

...

Anyway, I think the solution would be to use 64bit float as the index.

true.

...

In 64-bit Pd, this isn't an issue anymore (or more correct: It will be with _much_ larger tables).

what do you mean by "64-bit Pd"? it _could_ mean 2 thing (for me):

• • any (newish) Pd compiled on 64bit platform
• • a Pd that uses 64bit (double-precision) floats for it's internal

t_sample/t_float type, regardless of the architecture it runs on

#1 is simply wrong, as all "proper" Pd's (that is, _not_ Pd-anywhere) use 32bit (single precision) float for numbers. so on my amd64 system, i still have the same issue

#2 would be the solution, but even though i started double-ifying Pd some time ago, i haven't done anything in the last 2 years or so, which made the project stall. so Pd is not double-precision ready yet (i think it is still only the sound-generators like [phasor~] and [osc~] that are missing)

Thanks for the clarification. Indeed, I was believing, that Pd compiled on an amd64 maschine would operate with 64bit floating point numbers internally. Too bad, this isn't the case.

Roman

Those internal floats are somewhat more precise than the printed floats, because pd doesn't print enough digits.

my problem is with the printed format. sometimes it's also a problem when
getting those numbers from some operation, and they have to be worked in
symbols or something (don't have a concrete example). but I thought that
something like that wouldn't be just a design error.

On 2010-11-26 04:04, Mathieu Bouchard wrote:

Those internal floats are somewhat more precise than the printed floats, because pd doesn't print enough digits.

...and if you save your patch any floats in it will be printed out the same way so you end up with effectively about 24-bit floats next time you open it.

Martin