[PD] readanysf~ error
Hans-Christoph Steiner
hans at at.or.at
Thu Jul 22 04:47:00 CEST 2010
So I looked at the files again, this worked for me (I just added the
last step):
cd externals/august/readanysf~
make -f Makefile.darwin
./embed-MacOSX-dependencies.sh
If you want to make the same package as me, then just:
cd ..
zip -9r readanysf~.zip readanysf~
That folder just drops into /Library/Pd to install. :) I'll update
gavl and gmerlin on Mac OS X once Pd-extended 0.42.5 is released.
.hc
On Jul 10, 2010, at 6:07 AM, august wrote:
>
> No, I didn't receive the build system changes. Do you remember how
> you
> packaged everything into one Mac bundle? I should be able to just
> reuse the gavl, gemerlin, ffmpeg, etc libs.
>
> I'll write to the dev list and ask for access to the pdlab.
>
> -a
>
>> I don't remember, hopefully I sent you my build system changes. I
>> won't
>> have time to do it in the near future, but I can answer questions.
>> Also,
>> you could request access to the PdLab build machines if you need to
>> build
>> on Mac OS X, Debian, Ubuntu and Windows.
>>
>> http://puredata.info/docs/developer/PdLab
>>
>> .hc
>>
>> On Jul 8, 2010, at 4:25 AM, august wrote:
>>
>>>
>>> It may take a little while for Burkhard to update his stuff. I
>>> have a
>>> feeling he is busy now with work, and also with adding webm and
>>> other
>>> features to gmerlin_avdec.
>>>
>>> How about compiling a new readanysf~ for Mac? Do you still have it
>>> set up to do it (is it just a matter of putting in the new code)?
>>> Do
>>> you have a build system for putting it all together?
>>>
>>> -a
>>>
>>>> Any idea when this will be released? I can update the Fink package
>>>> then.
>>>>
>>>> .hc
>>>>
>>>> On Jul 3, 2010, at 5:50 AM, august wrote:
>>>>
>>>>>
>>>>> okay,
>>>>>
>>>>> This error should no longer occur in the next release of
>>>>> gavl/gmerlin_avdecode.
>>>>>
>>>>> -august.
>>>>>
>>>>>> Hi August,
>>>>>>
>>>>>> thanks for your quick reply and sorry for my slow one ;-) The
>>>>>> short
>>>>>> answer is that cleaning up the headers of the soundfiles by re-
>>>>>> encoding
>>>>>> with sndfile-convert did the trick. Celine, the student I am
>>>>>> working
>>>>>> with, promised to write you a bit later with more details.
>>>>>>
>>>>>> Best!
>>>>>> Derek
>>>>>>
>>>>>> On 6/15/10 5:31 PM, august wrote:
>>>>>>>
>>>>>>> Derek,
>>>>>>>
>>>>>>> Are you using MacOS X? What version of readanysf~? What
>>>>>>> version
>>>>>>> of gavl and gmerlin_avdec are packaged with it/used with it?
>>>>>>>
>>>>>>> I don't suspect it is the soundfile itself, but just in case,
>>>>>>> can
>>>>>>> you
>>>>>>> put an example online for me. This is going to be a tough
>>>>>>> bug to
>>>>>>> find, unless you see some sort of regularity in how the sound
>>>>>>> turns
>>>>>>> to noise for you and can report that to me?
>>>>>>>
>>>>>>> can you make a simple patch that isolates the bug?
>>>>>>>
>>>>>>> Also, 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.
>>>>>>> In
>>>>>>> other words, when you hear noise, can you also hear the other
>>>>>>> readanysf's playing....or can you also make a simple osc~ and
>>>>>>> hear it
>>>>>>> play correctly?
>>>>>>>
>>>>>>> The "Current file is either invalid or an unsupported codec."
>>>>>>> warning
>>>>>>> can also come if you send "play" to the readanysf object
>>>>>>> without it
>>>>>>> having a file loaded. I assume this is what is happening.
>>>>>>>
>>>>>>> -a.
>>>>>>>
>>>>>>>> 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
>>>>>
>>
>>
>>
>>
>> ----------------------------------------------------------------------------
>>
>> All mankind is of one author, and is one volume; when one man dies,
>> one
>> chapter is not torn out of the book, but translated into a better
>> language; and every chapter must be so translated.... -John Donne
>>
>>
>
> --
> -------------------
> http://aug.ment.org
>
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
More information about the Pd-list
mailing list