search for: cwolf

Yes, it works now. Thank you very much. -----Original Message----- From: Chris Wolf [mailto:cwolf@starclass.com] Sent: 05 September 2001 10:12 To: vorbis-dev@xiph.org Subject: Re: [vorbis-dev] Problems trying to run the examples in windows vorbis sdk On 9/4/2001 at 6:00 PM Pablos-Sanchez, Rolando wrote: >I have just downloaded the vorbis sdk for windows, for researching >purposes. >...

I made some changes to the win32 build environment. The build scripts now use msdev to build all the projects (kind of like Jack originally had it.) If building with nmake and makefiles is desired, such as if it is expected that the sdk will be copied to an environment which has a version of MSVC older then version 6 -- simply set the environment variable USENMAKE to any value and the

I performed a minor amount of refactoring of the build environment for oggdrop. These include: Action: Added a workspace to manage project files and dependencies Purpose: To build all dependent libraries before attempting to build oggdrop -- i.e. provide one-step build process. Instead of opening "oggdrop.dsp", open "oggdrop.dsw" Action: Added

I'm trying to implement vorbis into our game engine as a substitute to mp3 and wma encoding. And I have some questions/suggestions in how #includes are done in vorbis. Right now ogg and vorbis stuff relies on ogg and vorbis include paths being in global (or local) include path environment. This could easily be avoided by using relative includes in vorbis: #include

I was looking at the doc pages and noticed that the PNG files were corrupt. It looks like they were not added to CVS with "-kb" (binary) I re-converted the on-line GIF versions back to PNG, then are attached. I advise a cvs "remove", followed by cvs add -kb for these. -Chris <HR NOSHADE> <UL> <LI>image/png attachment: white-xifish.png </UL>

Jack, Where you able to use those patches for oggdrop I posted? -Chris >>This is correct. I forgot to tag win32sdk, but win32-tools wasn't >>modified. >> >>> It looks like "oggdrop" in contained in win32-tools. That module has an >>old version >>> of audio.c, which will only accept 16 "fmt" chunks, i.e. only the older

I updated the win32sdk build environment. To summarize: 1.) Added a "mkmak.bat" script to create, install and run an automation macro to perform makefile export from the command line. 2.) Updated makesdk.bat to utilize "nmake" and generated makefiles for performing builds. 3.) Added "sdk\build" which contains a complete build environment for building all the

Is the inclusion of "../lib/misc.h" necesarry for this example program on Linux? It builds and runs on win32 without it. Maybe this is left over from debugging? Thanks, Chris --- >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

I added support for supplying file name(s) in the command line for i/o in the examples in "vorbis/examples". If no arguments are supplied, then the current filter pipline mode (stdin/stdout for i/o) is used. The primary reason for this, is to be able to run these in a debugging session. Additionally, in the encoder example, instead of a hard-coded "data" chunk offset of 44,

Per conversation last week with Rich and Matt, while we want to have a Guestconv C API which is relatively easy to bind to across different languages, for the sake of expediency we want to the do the actual work in Python. The idea is that the C API will spawn a python process when guestconv_create is called and ultimately be responsible for terminating the process. Communication between

Hello, I have found that there are some WAV files which have a "fmt" chunk size greater then 16 bytes (length indicator greater then 16). The patch is attached. What is the normal method for submiting patches? Regards, Chris Wolf <HR NOSHADE> <UL> <LI>application/octet-stream attachment: audio.c.patch </UL> -------------- next part -------------- A non-text

I've noticed that certain binary files had been checked into cvs with the default expansion mode. For example *.png and *.bmp files. The line ending problem not withstanding, there is still the possiblity that these files can be corrupted if the binary data happens to contain byte sequences that just happen to match RCS keywords, e.g. "$Id:$", etc. For that reason, they should

It was recently brought to my attention by "Ram'on Garc'ia Fern'andez <ramon@jl1.quim.ucm.es>" that there is yet an even simpler solution to the issue of cross-DLL access of variables in the data segment. Although a variable may be exported either from the module definition file, or explicitly via _cdeclspec(dllexport) -- unlike procedures (functions), it is mandatory