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