similar to: vq diffs

Hello! First of all a question: When you make the encoder tables (ie: mode_e.h) do you use the mapping0_forward function? Because you made the encoder tables, and after this you did a minor correction in the final beta4 ... (this correction was: additional[0]=fabs(additional[0]*scale); in the mapping0_forward function) (I see this was a bug, and the modification was correct, but this correction

There are some missing fixes for reading floats and a few unused variables Now I have the postbeta2 branch behaving like the main one, at least! diff -bBu2 branch_postbeta2/vq/bookutil.c vorbis-postb2/vq/bookutil.c --- branch_postbeta2/vq/bookutil.c Thu Aug 31 05:00:02 2000 +++ vorbis-postb2/vq/bookutil.c Wed Sep 13 17:59:15 2000 @@ -309,5 +309,5 @@

Hi, As far as I see in libvorbis most of the places where _ogg_malloc(), _ogg_realloc and _ogg_calloc() is called the return value is not checked for out of memory condition. Is there any plan to change this? For my use-case the application is not allowed to crash. So if libvorbis can not handle this condition, I guess I would need to preallocate a large enough custom memory heap for all kind of

I work for Terra Soft Solutions (makers of Yellow Dog Linux) and I'm trying to compile the latest cvs snapshot for inclusion in our next release, but I'm running into some problems... I'm using modified versions of the SRPMs included in RedHat's Rawhide distro (I only updated to the latest cvs, but the old version also experienced this problem), which compile fine on an x86 box I

ltconfig placeholder shoud be removed. Makefile.am : some stuff copied from branch_beta3 ogg lib must be added only where necesary. vq subdir Makefile.am'ized, (but installs nothing) made distclean target slightly more clean -- check it by hand first, please --- also you'll want to remove vq/Makefile if the ...am passes inspection ------------------------------------------------- diff

Hello! Some minor bugfixes... source: psy.c function: _vp_psy_init 1. '-' or '+' in this line? maxoc=toOC((n*.5f - .25f)*rate/n)*(1<<(p->shiftoc+1))+.5f; maxoc=toOC((n*.5f + .25f)*rate/n)*(1<<(p->shiftoc+1))+.5f; 2. I know: sizeof(float *) and sizeof(float) are 4 bytes long, but... old lines: p->noisemedian=_ogg_malloc(n*sizeof(float *));

It seems that the configure script in CVS does not check the CFLAGS environment variable at all. Indeed, on line 121 of configure.in, CFLAGS is explicitly set to be blank. Is this done for a reason? I see that several sets of CFLAGS are passed into the Makefiles by configure based upon specific architecture/compiler combinations -- perhaps this is the reason...? I ask because users may wish to

The theora_unpack_comment casts a pointer-to-int to pointer-to-long. This is incorrect on AMD64, where ints and longs are of different size. On my system (Debian unstable, gcc 4.1) this causes players to crash when they reach the end of a movie. The patch below fixes this bug. --- libtheora-0.0.0.alpha7/lib/toplevel.c 2006-06-13 00:57:36.000000000 +0200 +++ libtheora-pdw/lib/toplevel.c

Hi all, I tend to compile my code with all GCC warnings turned on. However, when I do this : vorbis_comment_add_tag(&vdata->vc,"ENCODER","libsndfile"); I get the following warning messages: warning: passing argument 2 of 'vorbis_comment_add_tag' discards qualifiers from pointer target type warning: passing argument 3 of

Package: libtheora0 Version: 0.0.0.alpha7-1 Severity: important Tags: patch The theora_unpack_comment casts a pointer-to-int to a pointer-to-long, which breaks badly if ints and longs are different sizes. The attached patch fixes this. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture:

Hi all. In lib\encoder_toplevel.c , row 1123-1128: #ifndef LIBOGG2 /* So we're expecting the application with free this? */ op->packet=malloc(oggpack_bytes(opb)); memcpy(op->packet, oggpack_get_buffer(opb), oggpack_bytes(opb)); oggpack_writeclear(opb); #else In my small testing application my debugger says there are 50 bytes of memory lost and it refers to

Hi all. In lib\encoder_toplevel.c , row 1123-1128: #ifndef LIBOGG2 /* So we're expecting the application with free this? */ op->packet=malloc(oggpack_bytes(opb)); memcpy(op->packet, oggpack_get_buffer(opb), oggpack_bytes(opb)); oggpack_writeclear(opb); #else In my small testing application my debugger says there are 50 bytes of memory lost and it refers to

Dear Vorbis devs, I'm Robert Kausch, author of fre:ac - free audio converter. Please consider using _ogg_malloc/_ogg_free in place of alloca in vorbis_comment_add_tag. alloca will cause undefined behaviour/crashing when it causes a stack overflow which can easily happen when adding cover art in a METADATA_BLOCK_PICTURE comment. I had a user trying to convert a FLAC file with a 2 MB

Good morning, On Tue Apr 28 2009 at 10:34:24 CEST, Jelte Jansen wrote: > We are looking into it (if only because the question comes up about once a > week now) It's been a little more than a week since the question last turned up :) I'd also like to know if any progress has been made to allow NSD to have zones added/removed on the fly, somewhat along the lines of BIND's

Hello, I've been looking to the libvorbisfile and got into troubles when trying to use it: I need to compile it on a PalmOS and the libvorbisfile must be compiled in ARM whereas calling code is in 68K. This implies that the interface ov_open_callback is not usable because the OggVorbis_File *vf must point to something in the target architecture (ARM) whereas the caller cannot do that. As

On 06/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > I've had a second look, and I believe there really was a bug there, > though my patch may not be optimal. > > As an example of an off by one bug: > > On the first run through the code, message_header_fields will be NULL, > so _ogg_calloc will be called. Assume header_key and header_value

hi all I found that in the revision 10730 of the libogg2 library it is impossible to do bitpacking. this is due to the implementation of the (at least) two functions oggpack_writeinit() and oggpack_readinit(). they both take an (oggpack_buffer *) as an argument and immediately erase all it's contents: void oggpack_readinit(oggpack_buffer *b,ogg_reference *r){ memset(b,0,sizeof(*b));

I've been trying to get oggdec to work with input streamed in through a pipe or a socket. This seems to work on Linux and OS X, but not on Windows. I've found that code in vorbisfile.c tests the input stream for seekability by invoking fseek in the following way: int offsettest=(f?callbacks.seek_func(f,0,SEEK_CUR) : -1); Unfortunately, fseek succeeds for a socket on Windows (even

Hi. I'm trying to implement Ogg/Vorbis support for the MPEG4IP project. The goal is to support Ogg/Vorbis audio for MPEG-4 streaming. So far I have managed to make the encoder save Ogg packets as an Audio object in an .mp4 file. As a side effect, it can also save Ogg pages in an .ogg file playable by xmms, but that's no big deal. So what I'm doing is this. First the init part. a)

hi, i am porting ogg vorbis decoder on to a24- bit dsp platform. i would like to know how he is arranging the binary tree into an array form. i think this process is done in _make_words in tremer code. i would be if some one could explain me the exact algorithm or where can i get it? i am attaching the code here for your reference. static int _make_words(char *l,long n,ogg_uint32_t *r,long