similar to: Documentation Suggestions

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'm in the final throes of debugging (hopefully) and the last thing I'm trying to do is figure out why I'm getting static instead of usable data. I have a verified Ogg file (it plays fine in WMA); I've visibly inspected the info struct and it matches my output format; I've verified my audio playback code by using a generated sine wave (sounds correct). So that leads to a

OK, I have a minor problem with the 'vorbisfile' libraries. I copied both the normal and dynamic DLLs to my program directory, and they load fine. Thing is, if I link with 'vorbisfile.lib' and use 'ov_open', the application just locks up. If I link with 'vorbisfile_d.lib' and use the function, Windows brings up a standard crash window, and I can just use that to

I have a problem i suspect to be a bug in ogg: Assume i have a simple archive "chou_s_test1_test2.pak", created by simply concatenating binary files together: chou_s.jpg (3403 bytes) test1.ogg (5196 bytes) test2.ogg (6128 bytes) If i place the a filepointer passed to ov_open to the beginning of test1.ogg, this ogg gets opened and decoded correctly. But if i place it to the beginning

Hi all, While reading through various bits of libvorbis and vorbisfile, and then thinking about how to implement other features in the xmms and winamp plugins, I had some thoughts... Vorbisfile is very useful, and very easy to use. It is, however, tied to stdio - which means you can't use it for lots of other stuff where it'd be useful - like streaming, or (under win32) avoiding stdio

Hello, All. First, I want to thank Ian Malone and Ralph Giles, thanks for your kind replies. But I still have problems about seek. As you suggested, I could use ov_open_callbacks() to supply my own read/write/seek functions. So, can you give me an example? I?m sorry for my ignorance, because I haven?t used callbacks before. I analyzed the vorbisfile.c in Tremor, and I think I

Hello folks, This is a ping to see what folks are up to and planning to work on in the near future. I'm mostly just curious.... Personal goals in the next week: Handle any incoming bugs on the vorbisfile API/library Hone the LPC approximation routines a bit more. Get the command line player functional (Mike Whitson is also planning to put some time in here). Verify that I understand the

I am having one frustrating time trying to decipher why ov_read is failing in my MFC/C++ application, and I see in Google results that others have had difficulty as well. These google discussions generally involve libraries, dll's and linking options, as though there are perhaps some basic incompatibilities between ogg vorbis and win32 and/or MFC/C++. Very confusing. If I pass fopen a

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

Should I ov_clear a failed ov_open/test/test_open call? The xmms plugin does an fclose on failure, and that seems to work, but I thought I ought to know for certain. (An observation: I think the quantity of questions and bugs raised along the lines of "I did open file, ov_open, ov_read, close file, open another file, ov_read, and it exploded", or "I tried to make vorbisfile go

Hello, I'm currently trying to implement streaming off ogg-files out of an archive file using SDL and SDL_mixer for playback. Therefore i create a FILE * filepointer, place it to the beginning of an ogg file inside the archive and hand over the filepointer to ov_open. ( command: ov_open(fp, &music->vf, NULL, 0) ). This works fine so far. The problem is: if i put many oggs together in

#include <stdio.h> #include "vorbis/codec.h" #include "vorbis/vorbisfile.h" #include <io.h> #include <fcntl.h> #pragma comment(lib, "vorbisfile_d") int main(int argc, char **argv) { FILE *fp; OggVorbis_File obf; if(argc < 1) return -1; if((fp = fopen("f:\\testogg.ogg", "rb")) == NULL) { printf("Open Files

If I do something similar to the below ov_open always causes an access violation. The call to fopen is successful. Can anybody tell me why? (and how to fix it?) OggVorbis_File vf; int eof=0; int current_section; FILE *fd = fopen("c:\\test.ogg","rb"); if (!fd){ AfxTrace("fopen failed\n"); exit(0); } if(ov_open(fd, &vf, NULL, 0) < 0) {

I'm considering patching my copy of ogg123 to support vorbisgain tags. Is there any interest in folding this sort of patch into the main line ogg123? Has anyone done this already (or to another command line ogg player)? John --- >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

Ivo, Your patch number 16347 uses _fseeki64 when _WIN32 is defined. Unfortunately, MinGW (or at least the Linux -> Win32 cross compiler I'm using) defines _WIN32 but isn't aware of _fseeki64. I have therefore modified your solution a little and commited it as rev 15376. The code now looks like this: #ifdef __MINGW32__ return fseeko64(f,off,whence); #elif defined

I'm working on an application where I need to record the current playing position and return to it later. and I need this to be done the most efficient way, so I used ov_raw_tell() and ov_raw_seek() because the documentation says they are the best when speed is a concern. but the problem is that sometimes ov_raw_tell returns the same value before and after calling ov_read; here's an

Just noticed this article on Slashdot: http://ask.slashdot.org/article.pl?sid=04/05/18/0432202 ...about the feasibility and efficiency of reading id3v2 tags out of mp3's over http. I know that vorbisfile's callback model is well suited to handling this sort of scenario, but I'm curious to know whether ov_open will try to read enough stream to pull the comments out on a

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

Hi, I've just got around to moving from version 1.0 to 1.0.1. Now when I run my program, at least on Windoze, (haven't tried Linux yet), I get an Access Exception on the ov_open. Nothing else has changed. All I did was replace the lib and dll files that are in the win32sdk zip and re-build all, so it's the same the project files for for both builds. Here the snippet of code that

When call isohybrid with option '-u', it overflows on a 32 bits host. It seeks to 512 bytes before the end of the image to install gpt header. If the size of image is larger than LONG_MAX, it overflows fseek() and cause error: isohybrid: wrlinux-image-x86-64-20140505110100.iso: seek error - 8: Invalid argument Check the offset and call fseek() multi-times if offset is too large.