[PD] readanysf~ error
august
august at alien.mur.at
Mon Jun 21 09:52:06 CEST 2010
Okay, glad to hear you have it solved.
If you can, please post an example of the soundfile that didn't work so
that I can test it.
thanks-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
>>> --
>>> ::: derek holzer ::: http://macumbista.net :::
>>> ---Oblique Strategy # 136:
>>> "Remove specifics and convert to ambiguities"
>>>
>>
>>
>>
>
> --
> ::: derek holzer ::: http://macumbista.net :::
> ---Oblique Strategy # 6:
> "Abandon normal instruments"
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
-------------------
http://aug.ment.org
More information about the Pd-list
mailing list