How to get exact length of a buffer in samples?
Hello,
atm I am trying to make some non-realtime-calculation of audiofiles, and for it I need to know exactly the length in samples of a loaded buffer. The objects [info~] and [sfinfo~] just give me the lenght in ms (and both give slightly different answers). So my question is: Is there a possibility to get this information directly in samples?
Thank you,
Matthias
you can send the getSize message to [mxj buf.Op your_buffer_name] - a very nice thing almost hidden in the Max distribution.
cheers
aa
thank you, i didn't know this before. But it is still not accurate enough.
I'll give you an example with 1 testing file (44.1kHz):
[info~]
gives me a length of 7470 ms
-> 329427 samples
[sfinfo~]
gives me a length of 7470.476074 ms
-> 329447.96875 samples
[mxj buf.Op]
gives me a length of
329427 samples
Audacity
gives me a length of
329448 samples
i tested now a lot and I found out, that I need as number the 329448 samples as length. this number seems to be the correct one. so, there is still no method in max, to give me the correct number...? Atm the only way I see is to round the number of the [sfinfo~],but i can't believe this is the only way to get the correct information in max...?
Regards,
Matthias
EDIT:
i found out, that even with the other numbers calculated my program works well now (there were a few other bugs). but still wondering about my last concern.
Well, the fact that the actual size is smaller in buffer~ objects than in sfinfo~ and audacity makes me think of a bug... I might be wrong of course.
If you found out that the Audacity value is reliable (are you sure of this?), I would suggest you to try what happens with much larger files... if you see that rounding the sfinfo~ output still gives you the correct value, I don't think there's anything wrong with using it. If not, well, we're in some trouble!
aa
the sfinfo~ output also behaves with larger files in the same way as audacity.
but it is really strange, that all methods in maxMSP give me different results (at least with bigger files (180mb)).. here the patch to test it. (maybe I myself did some mistake there)
just round it up, 10.001 ms at 44.1 khz require 442 samples.