similar to: RES: Newbie question

Hi, This is my 1st time working with ogg-vorbis software. I tried to run vorbisfile_example.c (using a valid ogg file as input) and got the following error during the ov_open call: "Unhandled exception in vorbis_example.exe (KERNEL32.DLL): 0xC0000005: Access Violation." My working environment is Windows 98-SE and Visual Studio 6.0. Any ideas/thoughts, or where else to look would be

Greetings, I'm having some sort of problem using ov_read_float(). Everything looks good to me, but I'm trashing memory somehow, so clearly I'm screwing something up. What confuses me is why it takes a ***float for the buffer. I call it like so: float **buffer bytes_read = ov_read_float(&vf, &buffer, 0) memcpy (b, *buffer, 0); This compiles fine, but after a few reads,

Hello, hope you're fine. And hopefully someone can help me. I wrote a short demonstration to show you my problem (see below). I'm asking always for 64 samples. When "ov_read_float()" is finished, I want to seek back to sample 1, and ask immediately for the next 64 samples. But when I run this small app, I get an totally high CPU load. Is there a way to it speed up? Or do I

Hello, Am I missing something? float** pcm_channels; int bitstream; int where = ov_pcm_tell(&vf); -> The Result is "0"; ov_read_float(&vf, &pcm_channels, 1, &bitstream); -> pcm_channels[0][0] is "0.000338580" ov_pcm_seek(&vf, 0); char* buffer = new char[2]; ov_read(&vf, buffer, sizeof(buffer), 0, 2, 1, &bitstream); short temp =

Hello. I noticed that when reading data with ov_read_float(), you can get values outside [-1..1] when the stream is encoded at lower quality, but with higher quality, the values trim down to inside [-1..1]. Looking at the plot from -q10, the data from ov_read_float seems clipped. I've made some plots of encoding the start of Rammsteins Feuer from the xXx soundtrack (it's a pretty loud

Hello, I forgot in my last reply that my DWT implementation can be speed up, for example I'm doing for now: for (;_X1<_E_;_X1++,_RES+=2) //dilatation { _RES[0]=_X1[0]<<3; _RES[1]=(_X1[1]+_X1[0])<<2; } then for (;_X2<_E_;_X2++,_RES+=2) //details { _RES[0]-=(_X2[1]+_X2[0])<<1; _RES[1]+=6*_X2[1]-_X2[2]-_X2[0];

Hi, in ov_read_float.html there is a small mistake: long ov_read(OggVorbis_File *vf, float ***pcm_channels, int *bitstream); hould read: long ov_read_float(OggVorbis_File *vf, float ***pcm_channels, int samples, int *bitstream); It seems this function has been changed (compared to the RC3). Anything else worked fine for me with the 1.0 release. Olaf <p>--- >8 ---- List archives:

I always assumed that ov_read_float() would get me samples in the range of [-1,1), and anything below or above that can be clamped (or clipped in the final conversion to an integer format.) However, I recently saw this: https://github.com/LaurentGomila/SFML/issues/310#issuecomment-9974550 Apparently, there are Vorbis streams that use float samples with values in the range of [-32768,

I've been experimenting with the ideas of Replay Gain[1] and find that ogg123 doesn't have a way of specifying the scaling applied to replayed samples (like -f in mpg123). Looking at libvorbisfile, I see no function exactly matching this possibly desirable behaviour. ov_read() scales by either 128 (byte output) or 32768 (word output), but there's nothing in between. ov_read_float()

Drear there: The problem I have is to lower an intrinsic function like this ” float @llvm.write.arg(flaot %src, float* %dst) “ I am lowering it with INTRINSIC_W_CHAIN, so the return value and the value to write to dst are generated with some operations using src: " // it is the frame index node corresponding to input pointer SDvalue frindex = Op.getoperand(3); … SDValue returnValue =

Hi! I solved the problem using ov_read_float instead ov_read. Still do not know why ov_read returned garbage, but ov_read_float works fine! Thanks! El 17 de julio de 2011 10:41, Juan Miguel Mart?n Mu?oz <jmcubo at gmail.com>escribi?: > Hi, thanks for your replies! > > ogg.k, I'm sure MACOSX is defined. When I'm debugging line by line the > program runs into ov_read.

Here's a patch to vorbisfile.c in libvorbis that splits the float to integer pcm packing out of ov_read into it's own function. The good stuff: - ov_pack_pcm can be used by folks who decode to float pcm with ov_read_float to do various sound manipulations (eg, preamp, fades, replaygain). No more need to roll your own, which will really begin to pay off when 24 bit output gets

FROM NT \\firewall.surson runs perfectly WHY??? root@firewall init.d]# ./smb status smbd (pid 12183) est? rodando... nmbd (pid 1397) est? rodando... [root@firewall init.d]# smbclient //firewall.surson/profile -Ucatena%motpock added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0 Domain=[SURSON] OS=[Unix] Server=[Samba 2.2.3a] tree connect failed: NT_STATUS_BAD_NETWORK_NAME

(w. quotes from the xiphmeet: <http://westfish.xiph.org/~giles/200603_meeting.txt>, I've tried to strip it down to relevant stuff) <xiphmont> "Is there any interest in extending vcedit/libvorbisfile to do basic handling of Vorbis streams from concurrently multiplexed Ogg?" < xiphmont> Yes, but that work was *also* tied to OggFile from way back when, and one

Comments? ---------------------------------------- "Mark Taylor" <mt@sulaco.org> wrote: [...] > This is related to one minor objection I have to vector quantization > based codecs like Vorbis and the MPEG4 VQ codec: they do not compute > the quantization noise during the encoding process. The choice of > codebooks (use a big codebook: low quantization noise, use a

Dear Stefan, In the paper "Improved Forward-Adaptive Prediction for MPEG-4 Audio Lossless Coding", a non-linear compander is applied to the parcor coefficients prior to quantization. This compander is designed in order to minimize quantization error, especially for magnitudes close to unity. If you determine the typical distribution of magnitudes of the LPC coefficients, you could

Is there any particular reason why ov_read() packs floats to integer PCM inline, rather than being implemented in terms of ov_read_float() and a separate packing fucntion? There are obviously many advantages doing audio manipulation on the floats before packing, but right now you have to reinvent the packing stage yourself - in a replaygain backend that I'm working on, I ended up copying

I had completely forgotten about Replay Gain until Mr. Seibert reminded me. Wasn't there talk of adding this to vorbis-tools? Anyway, I went here: http://sjeng.sourceforge.net/ftp/vorbis/ And downloaded the source for the replay gain tool. Unfortunately, I cannot compile it. The errors regard parameters to ov_read_float. Is there updated source somewhere else? -- -:-:-

Hi. I have been talking with Psytel MPEG-4 AAC developer (www.psytel.com) about various compression formats, and to make it short he said that one of the main drawbacks of Vorbis is its vector quantization - it introduces more error then other quantization methods (like non-uniform scalar quantization, if I got it right), probably used in AAC and other similar codecs. I know vector quantization

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Celts, I've become intrigued by the problem of spherical quantizers, so I decided to see if I could come up with something better than PVQ. What I wound up writing is something I call an "octagon quantizer. In two dimensions, PVQ uses a "diamond" (square) shape. An octagon code (OVQ) uses an octagon, which is a much better