So (donc) What are uniform parameters of a soundfile? Only these are necessary to enhance soundfiler.
1) Channels is primary - an audio file can be any number of channels, but the soundfiler object needs to know in advance how many arrays to write to. This is non-negotiable i.e. an absolute fact. 2) Sample rate is secondary, and any file recorded at a particular sample rate can be played back at any other rate, but it would be nice to know this, but it is negotiable within the patch. 3) Bit rate - perhaps for saving this might be useful, although since saving is a generated process rather than a parameter specified within the header of a file (discuss), it is probably of little importance. The soundfiler object can already read 16, 24 and 32 bit files, and I can't see a future for 64 bit audio (although electronics manufacturers will certainly try to sell this in the future, despite the fact that most DA conversions are Sigma-Delta making bit-depth more-or-less irrelevant). Thoughts?Ed _-_-_-_-_-_-_-^-_-_-_-_-_-_-_ For Lone Shark releases, Pure Data software and published Research, go to http://sharktracks.co.uk On Wednesday, 22 February 2017, 12:09, Lucas Cordiviola <[email protected]> wrote: #yiv3468639400 #yiv3468639400 -- P {margin-top:0;margin-bottom:0;}#yiv3468639400 >[soundfile_info] seems the better choice andis able to read all files that are >read by [readsf~]/[soundfiler], fromwhat 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 <[email protected]> on behalf of Roman Haefeli <[email protected]> Sent: Wednesday, February 22, 2017 8:19 AM To: [email protected] 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
