[PD] readanysf~ error

Hans-Christoph Steiner hans at at.or.at
Thu Jul 8 01:05:35 CEST 2010


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
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



----------------------------------------------------------------------------

Computer science is no more related to the computer than astronomy is  
related to the telescope.      -Edsger Dykstra





More information about the Pd-list mailing list