Ah, sorry, I meant "read" not "open." If calling read without an array takes the same amount of time as reading into an array, please open a bug report.
On Jan 28, 2022, at 9:19 PM, Dan Wilcox danomatika@gmail.com wrote:
Don't pass an array name when calling open and it reports the info without reading any samples, ie. just reads the header info then closes the file.
On Jan 28, 2022, at 8:37 PM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
Message: 1 Date: Fri, 28 Jan 2022 20:29:44 +0100 From: oliver <oliver@klingt.org mailto:oliver@klingt.org> Cc: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] [sfinfo~] Message-ID: <32ea001b-5109-cb72-2397-cb820d930bad@klingt.org mailto:32ea001b-5109-cb72-2397-cb820d930bad@klingt.org> Content-Type: text/plain; charset=UTF-8; format=flowed
Miller Puckette via Pd-list wrote:
Hi PA -
Are you doing stuff that "soundfiler" doesn't? If so, it would be better to add to the soundfiler object than to add a new object with its own name.
The one thing that [soundfiler] can not do, is to report the length of a soundfile WITHOUT fully loading it into an array.
That would be a great feature to have for [soundfiler]'s right outlet, especially in the case of big files.
You can get all the other information (channels, samplerate etc.) by loading just a small sniplet of the source file (even 1 sample is sufficient IIRC) into a buffer, but not the length. you would need to add "-resize" to the load flags, which is not useful for (very) long files
i still use IEMLIB's [soundfile_info] for that purpose.
best
oliver
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/