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 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/
@Oliver
The only problem I know with [soundfile_info] is that it counts as samples any metadata in the file. Is not common to find metadata in wav files but there might be some.
It would be really nice if [soundfiler] just extracts n of samples only by reading the header.
@Dan:
Oliver's patch shows that [soundfiler] does not just "read the header".
--
Mensaje telepatico asistido por maquinas.
On 1/28/2022 5:19 PM, Dan Wilcox 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 wrote:
Message: 1 Date: Fri, 28 Jan 2022 20:29:44 +0100 From: oliver oliver@klingt.org Cc: Pd-List pd-list@lists.iem.at Subject: Re: [PD] [sfinfo~] Message-ID: 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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
In d_soundfile.c around line 1207 we could see if there is only 1 arg left as a else if. If that’s the case, we could just bail down to done: and bob’s your uncle...
On 28 Jan 2022, at 20:30, Lucas Cordiviola lucarda27@hotmail.com wrote:
@Oliver
The only problem I know with [soundfile_info] is that it counts as samples any metadata in the file. Is not common to find metadata in wav files but there might be some.
It would be really nice if [soundfiler] just extracts n of samples only by reading the header.
@Dan:
Oliver's patch shows that [soundfiler] does not just "read the header".
--
Mensaje telepatico asistido por maquinas.
On 1/28/2022 5:19 PM, Dan Wilcox 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 wrote:
Message: 1 Date: Fri, 28 Jan 2022 20:29:44 +0100 From: oliver oliver@klingt.org Cc: Pd-List pd-list@lists.iem.at Subject: Re: [PD] [sfinfo~] Message-ID: 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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> 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
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/
-
Dan Wilcox -
Lucas Cordiviola -
Pierre Alexandre Tremblay