I'm trying to play back long audio files (18 minutes) from tables, and I managed to load them and they're playing back properly. But the waveform display is truncated around 1/3 of the lenght of audio sample. Since I'm building a kind of multichannel player with ability to play from a specific point based on waveform display, this is quite essential. I red that there are some limith of array/table size in pd, but it seems that the whole sample loads properly into table, only the display is incorrect. Any ideas? Thanks in advance.

Hi Krysztof,

I never tried loading such file, but you can do a little test to check if the sample is really not being loaded properly in the table.

If your sample rate is 44100, then you have 44100 samples per second. Therefore 18 minutes = 1080 seconds = 47628000 samples. So a table would need to have that minimal size in order to save the whole content of your audio file.

So try doing this: load a file into a table and then using [tabread] you can check for the content of the table. To do so, simply connect one number box to the inlet of [tabread] and another one to the outlet. Then gradually change the value of the one at the top and see if you continuously receive results. If at around 15000000 (that is, one third of your file) you stop receiving values from [tabread] then it very likely means your table isn't saving the whole contents, very likely due to some limitation of this object. In that case, I would suggest contacting the developers in the mailing list to ask for a suggestion of what to do.

Cheers,
Gilberto

@Krzysztof-Cybulski Always a problem... It has been discussed before.
http://forum.pdpatchrepo.info/topic/3260/long-soundfiles-in-pd/9
But unfortunately Katjav's solution has disappeared from that page.
There has been some work done on double precision....
http://puredata.info/downloads/pd-double .... but it is not finished.
You should take a look at the links....
http://www.katjaas.nl/doubleprecision/doubleprecision.html (Katjav's page) is especially interesting, and you might find the solution there. In fact, if you have a week or two to spare that site is a very good read!
I imagine that editors work by varying the sample rate for displays above a certain size (just for the waveform display) and then calculating the edit points, or they hold some approximation in memory and only write the detailed array as you zoom to your "selection".

If you try to push -maxsize for [soundfiler] beyond 4e+007 elements it usually crashes Pd.
You could use the -skip 4e007 flag to load a second soundfiler that starts at the point that the first ends, and then stitch the arrays together visually by placing them alongside each other. Of course you could add and a third and a 4th etc.
Then use [readsf~] to actually play back the file (any length is possible) and link the array positions chosen to a calculated "header size to skip" message for [readsf~] as it will open the file pretty much instantaneously (unlike soundfiler)... ??
David.

I had a similar problem a long time ago if i remember correctly i had to change the size of the array to the correct samples BEFORE using soundfiler to load in. I think you have to do away with the -resize in the message box.

I'll see if i can recreate it and upload the patch.

Ok, so i did a quick test with a very long audio file and it didn't work. It does work for medium length files though as -resize didn't always work.

Here's the patch anyway if you want to have a look.

long audio test.pd

@Krzysztof-Cybulski Come on guys.... show us something that can't be done in Pd..........
Here is just over 24 minutes of 44.1 stereo 16bit with just the 1st channel loaded (for simplicity). It does not eat ram or cpu. You can extend it as required by adding "slices" and by adding channels but you should be ok with the slice "bite" size no matter how many channels you have. It needs some extra logic to correctly size the last slice used (depending upon the file size.... added to "todo" list) and so at some point I might rebuild it as a truly dynamic patch...............
lo____ng.pd
The accuracy of the slider in the last slice can be addressed in a dynamic patch as the -maxsize flag can be calculated to scale the waveform correctly in the window.
Somewhere I have managed to introduce a glitch at the change points between slices that was not there before introducing the slider control (+"todo"). .... But it works!.......
David.

Hahaha, this is awesome David. There isn't even a click when the track moves from one slice to the next. You're right--we should never say it's impossible in PD!

@Krzysztof-Cybulski Here is a more/or/less finished patch. It will open 1h06m (at least) of stereo 16bit 44.1k.......... but be patient...... it takes a couple of minutes to open and display such a big file (see pictures below).
More ram (tested with 4Gb) might help... untested as yet.
It will open and scale multichannel recordings dynamically, but if there are many channels (4, 6, 7, 8, 10?) the possible track length might be less.....untested as yet.....
If I update it then I will replace the following zip file and add an incremented tag (eg waaaav2.zip)
waaaav2.zip
David.