[PD] FW: Fwd: Re: readanysf~ error

Kim Cascone kim at anechoicmedia.com
Sat Jun 19 17:36:39 CEST 2010


Celine
glad to hear the problem was resolved!
:)
KIM

Celine Berger wrote:
> Hello August,
> Hello Kim,
> List,
>
> thanks a lot for your very fast reaction to the Email of Derek concerning the issues we had with my installations'pd-patch and the readanysf ~ error.
>
> Derek could solve the problem by cleaning up the headers of the wav files, removing the markers by re-encoding with sndfile-convert as Kim suggested. 
>
> For the sake of completeness here the answer to the other questions: 
>
> - Are you using MacOS X?   
> mac osx 10.6
>
> - What version of readanysf~?  / gav/ gmerlin_avdec packages? 
> The one packed in Hans-Cristoph Steiner's binary package for MacOsX Intel (http://puredata.info/Members/hans/ReadAnySf)
> libgmerlin_avdec.1.dylib, libgavl.1.dylib
>
> - When the sound goes to noise, is it just that one particular soundfile that is used in readanysf or is it PD's entire output?
> First we had individual files, but in a random way (not a particular one) the other one were playing correctly. After a certain amount of time all the readanysf~ would eventually be "playing noise".
>
> Many thanks again for your fast support!
> All the best,
>
> Celine Berger
>
>   
>>> Hello August, list....
>>>
>>> I'm helping a student's installation, and we have created a patch which
>>> uses 24 instances of readanysf~ to read from 24 different soundfiles
>>> between 15min and one hour in length. All sound files are mono, 16 bit,
>>> 44.1KHz WAV_PCM format.
>>>
>>> The problem is that, after a length of time, the readanysf~ objects
>>> output noise rather than the soundfile. It is not the result of any
>>> single soundfile, and many or all of the readanysf~ objects can be
>>> affected by this simultaneously.
>>>
>>> I have attached the abstraction in question. The object is instantiated
>>> as [readanysf~ 1], in other words the block size and and buffer size are
>>> defaults.
>>>
>>> Sample terminal output is as follows while the patch is running:
>>>
>>> Created new readanysf~ with 1 channels and internal buffer of 24 * 64 = 1536
>>> Current file is either invalid or an unsupported codec.
>>> Current file is either invalid or an unsupported codec.
>>> Current file is either invalid or an unsupported codec.
>>> Current file is either invalid or an unsupported codec.
>>> Current file is either invalid or an unsupported codec.
>>> Current file is either invalid or an unsupported codec.
>>> Current file is either invalid or an unsupported codec.
>>>
>>> Opening each soundfile individually with readanysf~ and sending "play"
>>> and "pause" messages reports no errors whatsoever, however.
>>>
>>> I have sndfile-info data for all of the soundfiles. The only
>>> irregularity I see in this is one file which reports:
>>>
>>>   Unknown chunk marker at position 6087587. Resynching.
>>>
>>> Besides that, most of the files report something like this:
>>>
>>> File : F_DOK6.wav
>>> Length : 146725772
>>> RIFF : 146725764
>>> WAVE
>>> bext : 602
>>> fmt  : 16
>>>   Format        : 0x1 => WAVE_FORMAT_PCM
>>>   Channels      : 1
>>>   Sample Rate   : 44100
>>>   Block Align   : 2
>>>   Bit Width     : 16
>>>   Bytes/sec     : 88200
>>> *** minf : 16 (unknown marker)
>>> *** elm1 : 7506 (unknown marker)
>>> data : 140114520
>>> *** regn : 92 (unknown marker)
>>> *** umid : 24 (unknown marker)
>>> *** DGDA : 6602919 (unknown marker)
>>> End
>>>
>>> ----------------------------------------
>>> Sample Rate : 44100
>>> Frames      : 70057260
>>> Channels    : 1
>>> Format      : 0x00010002
>>> Sections    : 1
>>> Seekable    : TRUE
>>> Duration    : 00:26:28.600
>>> Signal Max  : 11627 (-9.00 dB)
>>>
>>> Someone suggested the noisy output may be the result of a buffer
>>> problem, but I am not sure who I could verify or correct this.
>>>
>>> I checked with "top" while the noise was happening and saw no evidence
>>> that Pd was using any more memory than usual, and the CPU meter reported
>>> 30%.
>>>
>>> Hardware is an Intel Mac Mini, software is Pd-Extended 0.41.4.
>>>
>>> Any suggestions or other diagnostics I could run are appreciated.
>>>
>>> Best!
>>> Derek
>>> --
>>> ::: derek holzer ::: http://macumbista.net :::
>>> ---Oblique Strategy # 136:
>>> "Remove specifics and convert to ambiguities"
>>>
>>>       
>>     
>
>   




More information about the Pd-list mailing list