[PD] getting sample rate of file loaded into an array

[Roman Haefeli]

On Thu, 2012-10-04 at 12:05 -0400, Hans-Christoph Steiner wrote:
> On 10/04/2012 11:27 AM, Patrice Colet wrote:
> > 
> >> De: "Roman Haefeli" <reduzent at gmail.com>
> >>
> >> On Thu, 2012-10-04 at 16:23 +0200, Patrice Colet wrote:
> >>> Thank you roman, didn't try this one...
> >>>
> >>> I'd like to know what was the bug
> >>
> >> http://sourceforge.net/tracker/?func=detail&atid=478070&aid=2950978&group_id=55736
> >>
> >>>  because it gives wrong sample resolution
> >>
> >> Didn't know about this one. Please report it, so that hopefully it
> >> gets
> >> fixed. Does it work correctly with [ext13/wavinfo]?
> > 
> > Yes it does,
> > 
> > but anyway, my bad, I didn't read carefuly enough the help file that is saying sample resolution in *bytes*, not in *bits*.
> > 
> > maybe one day [soundfile_info] will read aiff files as well...
> 
> There are two separate issues here:
> 
> 1. it would be lovely to have a single [soundfile_info] that gets the
> meta data from any soundfile, like how [readanysf~] will play any soundfile

Agreed.

> 2. People should be free to write whatever software they want.  If
> existing objects don't work for them, they write new ones.  Therefore we
> have [wavinfo] and [soundfile_info].

That is someone speaking from a developers point of view. Of course, it
seems feasible to write your own class, if you have the abilities.
However, it (IMHO, at least) creates major pains for future users, as
they have to deal with the specifics of every class. I, as a receiver of
patches from others, might have to several implementations installed,
because the patch authors decided to use different advantages in this.
I'm all for freedom of the developers - don't get me wrong, but I think
some mechanism to "forget" stuff that does not seem to proof useful is
crucial. Otherwise we end up with a whole lot of half-working cruft in
the future. In my opinion, it is already the case now: so many libraries
that are not maintained anymore or which are broken in one way or the
other. It all boils down: How to get rid of stuff? Certainly not by
packaging everything into Pd-extended and saying we cannot remove stuff
because of backwards compatibility. This is not at all a rant. But I'm
convinced we will need to figure this out at some point in the future. 

Probably this analogy is way off, but I think it is not unlike the issue
with space debris in low earth orbit. The later you think about that,
the more expensive it is going to be to deal with it.  

> So really, I think the best solution would be to leave both  [wavinfo]
> and [soundfile_info] as they are, and focus efforts on making a
> [anysfinfo] based on gmerlin using [readanysf~] as a template.

Actually, I think [readanysf~]  could do it. It already provides
information about length of the audio file and its original samplerate.
However, there are some pieces missing like number of channels.

Roman