[soundfile_info] seems the better choice and
is able to read all files that are read by [readsf~]/[soundfiler], from
what I can tell.
In the past I found discrepancies on *sound file length*:
[soundfiler] != [sounfile_info] [soundfiler] == soundforge
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Roman Haefeli reduzent@gmail.com Sent: Wednesday, February 22, 2017 8:19 AM To: pd-list@lists.iem.at Subject: Re: [PD] soundfiler features
On Die, 2017-02-21 at 11:01 +0000, Ed Kelly via Pd-list wrote:
Since this information is contained within the header of each file (although it's a pain with the different formats), would it not be sensible to have a second outlet in soundfiler that delivers the number of channels, before the number of samples in the file is delivered from the left outlet? Perhaps also other info, but what would be relevant to a patch? I think channels is a necessary piece of information.
I, too, think that [soundfiler] should output some sound file properties instead using them only internally. It would be good to be able to make patches where the patch creator doesn't need to know beforehand what exact formats are going to be opened by the patch user.
I'd like to know the following properties (in descending order of necessity):
- number of channels
- sample rate
- bit depth
There are at least two externals, that provide this info: ext13's [wavinfo] and [soundfile_info] from iemlib. In my experience, the former doesn't read correctly all wav files that are read by other programs or by Pd, I believe it assumes a certain layout instead of truly parsing the header. [soundfile_info] seems the better choice and is able to read all files that are read by [readsf~]/[soundfiler], from what I can tell.
Roman