Hey Oliver,

I will admit to not fully digesting your patch, but from skim reading it I'm assuming it loops over the sample data by incrementing the -skip argument until you reach the end of the file. For my purposes memory usage isn't really an issue, so I'd imagine it would be far quicker to just load the whole sample into the table. 

What would be nice is if [soundfiler] additionally read the data chunk size property in the wav header for the number of samples. I imagine that's why [soundfile_info] was created in the first place.

Cheers,
Joe

On 24 May 2018 at 14:38, oliver <oliver@klingt.org> wrote:
On 2018-05-24 15:03, Joe White wrote:
Hey Oliver,

This is a neat trick, however for my purposes [soundfle_info] was
being used to extract both the sample rate and sample length to
calculate the duration of the file.

Looks like in order to switch to [soundfiler] I'd have to load the
whole file to memory regardless, as the `-skip 1` flag means the left
outlet (sample length) of [soundfiler] only outputs '1'.

have a look again.

in the middle of the patch, i use soundfiler's right outlet (available since PD 0.48, so make sure you are using this !) to get the file's samplerate, even though it is just reading 1 sample of it. so, no need to load the whole thing.

the left part of the patch gives you the file's length in samples, which you can then re-calculate (using the file's samplerate) to ms or whatever you need.

yes, the left outlet always only puts out 1 or 0, which i use to narrow down the last valid sample position, which is then the file's length in samples (endpoint).

i send the patch again to illustrate what i mean (unless i misunderstood something)

best

oliver


Cheers,
Joe

On 12 May 2018 at 19:37, Alexandre Torres Porres <porres@gmail.com>
wrote:

a new flag for [soundfiler] will make this easier without the need
of a dummy buffer

see https://github.com/pure-data/pure-data/pull/193 [1]

2018-05-12 14:06 GMT-03:00 oliver <oliver@klingt.org>:

Joe White wrote:
Hi all,

I recently spent a bit of time tracking down why a patch wasn't
loading a couple of externals in a windows application that embeds
libpd.

The patch was using /vbap/ [0] and /soundfile_info/ from iemlib [1].

hi,

just the other night i was hacking together a [sound_file] info
alternative with purely vanilla objects WITHOUT loading an entire
file into RAM.

the method is basically to use [soundfiler] to load 1 sample of a
file into a table with a -skip message, and recalculate the skip
position until [soundfiler]'s left outlet outputs 1 (instead of 0).

all of [soundfile_info]'s other values are also output from
[soundfiler]'s right outlet as of PD version 0.48.

it takes a tad longer than [soundfile_info] to output the
soundfile's length, but it's acceptable imho. plus you can use .aiff
too !

best

oliver

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list [2]

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list [2]



Links:
------
[1] https://github.com/pure-data/pure-data/pull/193
[2] https://lists.puredata.info/listinfo/pd-list

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