Thanks, those are actually pretty useful suggestions! I was not aware there is a double precision version of pure data. Right now my patch is vanilla, so there may be a good chance it might work. If not I can still try tabread4 (or pre-cut my soundfiles to 6min).

This is dependant on the pd external and has nothing to do with the OS or the kernel version. 64 bit numbers (double & long) are optional in the OSC 1.0 standard, so not every library implements this. I'm not sure if there is one for pd that supports the data type you need, the osc library by mrpeach doesn't document the version and subset of OSC it supports as far as I can tell, unfortunately.

Seems like I'm not the only person with this problem...
https://forum.pdpatchrepo.info/topic/5/tabread-object-troubles

Suggestions for a workaround are still appreciated.

EDIT: with double we would have 6640.29 years of audio we could address by sample, shame it wasn't used as a base datatype...

Hi,
I'm working on an audio slicer in pure data right now. I noticed when opening rather large files ~30min, that my addition logic to move the sample start- and endpoints does not work any more. Basically I'm incrementing a large number x_new = x + 1, the result however is x not being increased, so x_new - x = 0. I need this number to be precise, because I use [tabread] and [tabwrite] to manipulate my data.
To check if this is dependent on float32 behavior or a bug, I've written a python script using numpy to find the smallest integer y, for which float32(y)+1.0=float32(y). This seems to be 16777216.
I attached a screenshot of a minimal patch that reproduces this behavior in pure data, so this is an intrinsic problem of float32 being the only numerical data type in pd.
Banging 50 into the arithmetic chain yields 1, as expected, banging 16777216 yields 0, however.

Unfortunately this number equates to only ~6:20min of audio. Has anyone here done a similar project? The only idea I have right now is to pre-slice the file into different tables, but I can't do this in pd either, because I can't access every sample, and this would be a pretty ugly workaround anyways (That stacks on top of my already existing workarounds to make navigation more responsive, because rendering table content is so slow).