similar to: flac problems (update)

--- Josh Coalson <xflac@yahoo.com> wrote: > --- pritpaul@svaudio.org wrote: > > I still have the > > first > > problem though (flac adding 12 "00" bytes to the beginning of the > > decoded > > file when the original input to create the flac was a raw file), > and > > would > > realy appreciate help. :) > > OK, I will look into

--- pritpaul@svaudio.org wrote: > Is there anything else new in CVS that would warrant an upgrade? i.e. > any > bugfixes or new features? Also, does CVS tend to be clean-compiling? > (without changing a million Makefiles :) ) so far there have only been minor fixes/improvements. the one you found is only one that affects encoding. I try to keep CVS compilable. if not, just post a

So there is no way around having to re-encode them all? --Pritpaul --- Geoff Shang <gshang@uq.net.au> wrote: > Hi: > > My guess is that ices can't handle 16000 or 32000hz > sampling rates. The > 32kbps file is 22050hz and the 80kbps file is > 32000hz. I couldn't get > mpg123 to play test2 remotely, but lame defaults to > 32000hz with 40kbps > mono and

I got a new Athlon recently, and to my surprise, FLAC started segfaulting, even when recompiled. The problem goes away if I build with --disable-asm-optimizations. Has anyone else had problems of this sort? Here are the specs on the processor: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping :

Hi! I would really appreciate if someone could try to help me out with this... i've been struggling with it for quite a while now. :( Anyway, I was trying to use ices to broadcast mp3s with icecast2 (a recent cvs snapshot of all 3 components from brendan's site). I have it working fine for some of my mp3s (encoded with lame -b 32) but with the other mp3s which are actually the ones that

--- Asheesh Laroia <PaulProteus@technologist.com> wrote: > I'm running your debian packages on a K7 currently. They seem to be > working fine, including the xmms-flac package. I seem to be > experiencing > the same flac decoding problems > (state=6:FLAC__FILE_DECODER_STREAM_ERROR) > as Pritpaul Mahal, however. I'll see if I can reproduce these. It > could

Hello, I am having some problems with flac. I remember using an older version a year or so ago and I don't remember having any problems. 1.) When I encode a raw file and then decode it to raw, it seems to add 12 bytes of nulls (this may not always be just nulls, i have only tested on one file and it starts with nulls anyway) 2.) When I try to encode a WAV and then decode it, it fails at

I'm running your debian packages on a K7 currently. They seem to be working fine, including the xmms-flac package. I seem to be experiencing the same flac decoding problems (state=6:FLAC__FILE_DECODER_STREAM_ERROR) as Pritpaul Mahal, however. I'll see if I can reproduce these. It could just be a problem with my old FLAC files (from 0.9 and before). This K7 doesn't segfault on flac

Hi all, I've just released beta 2 of libshout 2.0, the icecast 2 compatible streaming library. http://xiph.org/~brendan/beta/libshout-2.0b2.tar.gz Libshout 2.0 adds support for icecast 2, Ogg streaming, and IPv6. Ogg and Vorbis are now prerequisites. Changes since beta 1: * lots and lots of autoconf. Thanks to Karl Heyes for his help here. * a fix for unusual MP3 bitrates contributed by

Hi all, I've just released beta 2 of libshout 2.0, the icecast 2 compatible streaming library. http://xiph.org/~brendan/beta/libshout-2.0b2.tar.gz Libshout 2.0 adds support for icecast 2, Ogg streaming, and IPv6. Ogg and Vorbis are now prerequisites. Changes since beta 1: * lots and lots of autoconf. Thanks to Karl Heyes for his help here. * a fix for unusual MP3 bitrates contributed by

* Josh Coalson <xflac@yahoo.com> shaped the electrons to say... >yep, that will work too. but just writing skipping code is >pretty simple: > >is_last=0 >read 'fLaC' string >while (!is_last) { > read 1 byte metadata block type > read 3 byte metadata block length > is_last = type & 0x80 > fseek(file,length,SEEK_CUR) >}

* Josh Coalson <xflac@yahoo.com> shaped the electrons to say... >not exactly. the metadata interface won't tell you, but you >can create a decoder (say file decoder), set it up, then call > > FLAC__file_decoder_process_until_end_of_metadata(...) > FLAC__file_decoder_get_decode_position(...) > >and that will tell you. the decode position is relative to >the

On Fri, Apr 4, 2008 at 12:19 AM, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> wrote: > Jahn, Ray (R.) a ?crit : > > > Dear Speex codec community: > > > > I am working on conversion of voice files. I could not figure out how to use speexdec.exe 1.2.3 in piped mode in order to avoid the creation of the potentially large intermediate *.wav or *.pcm files. Any

Hi, I have a problem when I try to open a file, which is not a FLAC file. When I open a non-flac file with the stream decoder API, one of the first things called is FLAC__stream_decoder_process_metadata, which itself calls stream_decoder_find_metadata_. Unfortunately the non-flac file contains some content, which leads to the state set to FLAC__STREAM_DECODER_READ_FRAME. However in

1. What to do with the last frame that is smaller then frame size? During encoding, the last frame is often smaller than the required frame size. In the sample code, proper number of zeros are padded at the end. So if I don't want those padded zero after decoding, I assume that it is up to me to keep track of the number of zeros. Is it right? 2. What does SPEEX_GET_LOOKAHEAD do? How to

On Tue, Dec 16, 2014 at 03:40:08PM +0100, Nacho del Rey wrote: > Hi there > > In an Oracle RAC cluster using ACFS (as file-system) where we have a samba > server for sharing files to windows clients, we are suffering a strange > issue, from time to time, which it causes the Windows clients lock for a > while (10 min or a bit more) or even indefinitely when they are working >

Hi list, I have 3 Citrix Xenserver 5.6  and currently building a a VM backup server. I took the xe client on one of the server and installed it on the backup server (gentoo based) installed the stunnel package to make XE work. now when running, I get this error message : [server ­~ #] ./xe help -debug -s 192.168.111.17 -u user -pw pass Connecting via stunnel to [192.168.111.17] port [443]

> A minor point. Would it not be better if flac defaulted to .wav input > rather than raw samples. I think it's going to get wav input an order > of > magnitude more than raw samples? It saves always having to put the > -fw in > there, on these: > > $ flac -fw - mj.flac < mj.wav > $ cat mj.wav | flac -fw - mj.flac > > For that matter it should be able to

Jean-Marc, What exactly does the speex code do to calculate the granulepos? With vorbis it's the 'count of decodable samples including this packet'. So if you had a packet that allowed you to decode 1024 samples since the beginning of playback, the granulepos is 1024, not for example 1023 which would be the *index* of the last sample assuming C-style array indicies starting at

Hi, I was hoping to get some clarification on the meaning of algorithmic latency in Speex. For wideband signals, algorithmic delay is specified to be 34 ms (20 ms is the frame size and 14 ms is the lookahead). Does this number (34 ms) account for the double-buffering on the input? Assuming that the computation time and sound wave propagation time are negligible, should I expect compressed