similar to: A few questions about libvorbis from a newbie

Sorry about the personal reply Ian. I hope keeping the subject the same is the way to reply to the list (I have never used a mailing list before). The last thing I am not grasping is how *pcm_total *works without a concept of sample size? If the sample size is whatever I decide to read it as, how does it calculate the number of samples (of one channel I'm assuming because we have to multiply

I wonder if anyone would have a comment on an experiment I have pretty much completed in my MFC/C++ project. With my simple libvorbis implementation, ogg decoding works just fine for files that are 10kb or larger. For anything smaller (actually, I don't have a 9kb file, so <= 8), it seems that I get an inaccurate value for ov_pcm_total. Though ov_read returns zero, I overflow the buffer

Hi, Maybe this is documented somewhere, if so, please send me a link to the documentation. My question is: how to set up different (VBR, CBR, ABR) modes when calling the Ogg Vorbis API? Currently I do: CBR: ret = vorbis_encode_setup_managed( &vorbisInfo, getInChannel(), getOutSampleRate(),

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,

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()

Hi, I need to adjust the output volume from ogg123 the same way that mpg123 has the "-f n change scalefactor [32768]" option. I need to do this within ogg123, instead of alternatives that involve pipes, such as piping the output to sox. I do not believe that this is currently possible in ogg123, and I'm looking for some suggestions as to how it can be accomplished by modifying

Hi, I need to adjust the output volume from ogg123 the same way that mpg123 has the "-f n change scalefactor [32768]" option. I need to do this within ogg123, instead of alternatives that involve pipes, such as piping the output to sox. I do not believe that this is currently possible in ogg123, and I'm looking for some suggestions as to how it can be accomplished by modifying

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

Subj!. Kind Regards, Michail. _________________________________ Michail A.Baikov, Linderdaum Team http://www.gamedot.ru http://linderdaum.gamedot.ru <p><p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word

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:

For those of you not of the commit mailing list, I wanted to point out that monty has checked the fixed-point 'tremor' vorbis decoder into xiph.org cvs, under the usual (free) xiph license. This was developed for use in embedded devices, so if you've been waiting for an interger-only (no fpu) implementation, you might want to give it a try. The code is in the 'Tremor' cvs

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'm experimenting with IceCast2, using DarkIce to generate the stream. I have found some peculiarities with the vorbis bitrates. In DarkIce, I call vorbis_encode_init() with about the following values: vorbis_encode_init( &vorbisInfo, 2, 44100, 96, 96, 96); which by all reasons should generate a 96 kb/s stream, as all max_bitrate, nominal_bitrate and min_bitrate are set to 96.

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 =

I am deeply sorry about the corrupt message just being sent; there seems to have been a compatibility issue with my mailer and my browser. This is an identical copy of the previous message: Hello Martin, Vorbis encoders are lossy, which is in a sense equivalent to converting the sample size of the raw PCM stream into something that would result in the desired bitrate. The "sample size"

Hi, I'm experimenting with managed mode encoding with specifying maximum bitrate. I call: vorbis_encode_init( &vorbisInfo, 2, 44100, -1, 96000, 96000); to initialize the encoding. To my surprise, it seems the maxbitrate value of 96000 doesn't have an effect, the bitrate of the

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

Hi, It's a bit offtopic for this list, but you might be able to help. For libvorbis rc3, what is the correct bitrate parametrization for the call vorbis_encode_init()? For rc2, it worked calling it the following way: vorbis_encode_init( &vorbisInfo, 2, // two channels 44100, // 44.1kHz

My compiler isn't locating 'ov_read_float' from the prebuilt vorbisfile.dll. Was that function missed from vorbisfile.def before compilation of the Windows SDK files? <p><p>J. <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to