similar to: A few questions about libvorbis from a newbie

Hello Martin, > how a number of samples with no defined size is translated into 8, 16, or 32 bit values in my buffer Although I do not know in detail about the actual implementation of libvorbis, most of the decoders should internally produce single-precision (32bit) floating point values, or 32bit integers as the result of PCM decoding. They are downcast to PCM samples with 8bit, 16bit, or

Echoing Hiroka, who is likely on the right track. Simply telling the encoder 'one channel' and then passing stereo data will not convert the stereo data to mono. The encoder encodes whatever it is given... Monty On Tue, Jan 3, 2017 at 6:51 PM, IHARA Hiroka <ihara_h at live.jp> wrote: > Hello Ross, > > The attachment appears at least to me as a valid monaural Vorbis

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

Hello, I have three questions, though all of which already mentioned by other people in the mailing list, about the accuracy of the Vorbis I Specification published on Feb 27. 1. On page 34 section 4.3.4., explanation of the situation where there are only one submap is omitted, and it is difficult to understand that the decoder should assume in such cases that all the audio channels belong to

Hello Ross, The attachment appears at least to me as a valid monaural Vorbis audio. It says in its header that there is only one audio channel, no stereo mapping is in use, and there is only one audio vector per frame. Actually it does not sound well, in a way that makes me wonder if two channels are unexpectedly merged into one... (thus it might sound like half-speed) I guess there is

First off, I don't even know if this is the right place to ask these kind of questions, but I haven't been able to find answers anywhere else, so 1. I have found that "pcmTotal * vorbisInfo->channels * 2" gives the uncompressed size of every ogg vorbis file I have used. What is a more robust way of getting the full uncompressed file size? 2. How do I read a certain amount of

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

I’m using a Windows development component which uses vorbis.dll, ogg.dll, vorbisenc.dll for encoding an Ogg Vorbis file. It's all working well except for one user occasionally has a 1 hour file appear as 2 hours and it plays at half speed. It is being converted from stereo to mono before feeding the encoder with a channels=1 configuration. Here is an example file which will be available for

I am wondering if buffer size for my decoding to pcm can be predicted dependably as follows. So far, the one problem I have had is when I have played a file of only about 5k. The buffer was a little less than 10% too small. I "solved" that by padding the result with an extra 20 percent. However, I have been told that I should be able to rely on the value of ov_pcm_total. char*

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 have this code to decode ogg data: unsigned long PSS_OggStream::DecodeOggVorbis(OggVorbis_File *psOggVorbisFile, char *pDecodeBuffer, unsigned long ulBufferSize, unsigned long ulChannels) { int current_section; long lDecodeSize; unsigned long ulSamples; short *pSamples; unsigned long ulBytesDone = 0; while (true) { #ifdef WIN32 lDecodeSize = ov_read(psOggVorbisFile,

I have a wav file which has been converted to an ogg file with libvorbis via ffmpeg. However I've tested a few files just to make sure. I run a standard while loop to using ov_read to pull all the data out of ogg file. Using 4096 as the size to read each call. Watching my debug logs it is reading 2048 bytes each call. When I load the wav file the data chunk for the pcm data is 167680

Hi all, Perhaps a stupid question, but I just need pieces of audio from a file. I know I have to use vorbisfile, and the example compiles, but I don't know how to read the buffer. In fact, it's not even documented (or I'm looking at the wrong place). I assumed it was a interleaved buffer containing unsigned shorts, but that didn't work. I also tried the normal decode example,

Ok here is the breakdown. I am trying to impliment streaming into our game using openAL and ogg-vorbis. In the non-streaming function when I call ov_read on the file I should be streaming the buffer gets filled with the correct data. However, when I run ov_read on the same OggVorbis_File when I read the buffer gets filled with 0's. The buffer has not been zero'd and starts filled

The documentation for ov_read states: "ov_read() will decode at most one vorbis packet per invocation". Can I increase the packet size in my encoder so my decoder makes fewer calls to ov_read? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20131103/d334e7d2/attachment.htm

How does one deal with the case when an fread callback doesn't have any more data but is going to get more data in the future? In particular, this is an issue when reading an incoming Ogg stream from a socket (icecast2, in this case). The issue is that the fread can't return 0 (that signals EOF and hoses everything), and it doesn't have a negative code that says come back later

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

Hi, Please excuse my ignorance but I'm having trouble with a very basic matter: I'm using vorbisfile to stream audio to the waveout device in Win32 (using waveOutWrite). I'm basically reading packets from an ogg file and streaming them using a simple buffering scheme. The thing is, this works great when the bitrate is more or less constant but the audio sounds garbled if there is a

When I call ov_read ( ) I cannot get more then 1024 bytes decoded even when the buffer size is 4K. The function only decodes 1024 bytes max even when I tell it to decode 4096 bytes. Does anyone has an idea what is going on. <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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! First, sorry if my english is not very correct :-) I'm a spanish student making a streaming project under Linux and I'd like to use Vorbis format but I have a problem. I want to capture live audio from the sound card and stream it in real time to the server. Actually I have installed Icecast, LiveIce and the Lame encoder and they