similar to: Changing "What do all the names mean?"

Okay, before I submit my patch to make libao produce sorta-streamable wav files, I want to know what these partial wav files do to various players. I've posted two sample wav files on my webserver: http://volsung.dhcp.asu.edu/~stan/infinite.wav http://volsung.dhcp.asu.edu/~stan/zero.wav The first uses a riff and data length of 0xFFFFFFFF (approximately infinite) and second uses a riff and

I've been kind of busy lately, but I wanted to see what's up with ao after the build change. I was able to check out the vorbis module, but when I tried to check out the ao module I saw this: [stan@volsung vorbis]$ cvs -d:pserver:anoncvs@cvs.xiph.org:/usr/local/cvsroot co -r branch_postbeta2 ao cvs server: Updating ao cvs server: Updating ao/doc cvs server: Updating ao/include cvs

Okay, here's the patch that should fix byte-ordering madness. The basic rule with libao is that samples have to be in native byte order. All of the drivers will assume this, and libao provides a ao_is_big_endian() function for library clients (and sometimes drivers) to test their byte ordering. I would appreciate it if someone on a big endian platform test ogg123 and make sure that it works

I just moved a bunch of shared code (like 4 copies of getopt) into a share directory within vorbis-tools. I also moved the UTF-8 code from oggenc into the vorbis-tools/share directory as well so that it could be used by all of the tools, since they all need to handle UTF-8 comments correctly. Header files for the shared code are stored in vorbis-tools/include. I have already fixed vorbiscomment

Using the following command cvs -d :pserver:anoncvs@xiph.org:/usr/local/cvsroot login and anoncvs as the password, I get the following response cvs [login aborted]: connect to xiph.org(198.136.36.245):2401 failed: Connection refused can anyone clue me in? D Sledge __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software

> Does anyone object to the attached patches? The main change is to be able > to call > > ao_append_option(&opts, "key", "value"); > I'm all for this one. The original form of the function is really poor design on my part. I hope this gets committed. --- Stan Seibert --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project

Hi, I'm whining again about the inclusion of the raw driver in libao. Can someone please commit the patch I posted in message: http://www.xiph.org/archives/vorbis-dev/0098.html (which will turn into http://www.xiph.org/archives/vorbis-dev/200103/0098.html in 4 days.) I've got people who want it included asking me what's the hold up. --- Stan Seibert --- >8 ---- List archives:

Can someone apply this patch? It corrects a silly typo on my part. --- Stan Seibert ---------- Forwarded message ---------- Date: Wed, 07 Mar 2001 01:20:48 +0100 From: Markus Keller <markus@mercury.net.dhis.org> To: indigo@aztec.asu.edu Subject: ao patch Hi, I just noticed a small typo in ao_esd.c. Here is a patch for it: --- ao_esd.c~ Sun Feb 25 03:06:05 2001 +++ ao_esd.c Wed

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

I am about to commit HTTP streaming code for ogg123. This has no relation to the discussion about "real" steaming Ogg; it just downloads and plays at the same time. But unless you have a direct T3 connection, it'll almost definately break up quite frequently. Solution? Buffer. But I have other things to work on for the rest of the day... Any screaming objections? This has been

I've been trying to tackle the vorbis source. I ran across what I think is a missing dependency in the vorbis-tools directory. Since ogg123 and vorbize are staticly linked to libvorbis and vorbisfile, when those file change, the executables should be rebuilt. Below I've attached a patch. (I hope it works. I am sort of new to patch and diff.) BTW, I've been trying to find a good

Ok, this patch replaces the old patch I sent, and it does a bit more. For one, it sorts the linked list of drivers based on the priority values, highest valued ones coming first. That allows the _find_default_driver_id code to stop looping (break) immediately when it finds a driver that works, because it already knows it's the working driver with the highest priority (what it normally

I did some testing of vorbis codec (Winamp plugin) on a Pentium 166 MMX, and found that the performance is pretty good. I got 3 % cpu utisization if I turned dithering off, and 5 % otherwise. This was with a 138 kbit song. It's pretty long to mp3 performance that was 0 to 1 % on that machine for a 128 kbit song. Also vorbis seems to have a larger working set, because if I play two songs at

Since 1.0rc2 was released i have found that ogg@64k sounds almost like mp3@128k (in 95% of the 3000 files i encoded...) I tested 1.0rc3 and 64k bitrate (quality=0.0) gives less good quality than before. And bad : it takes longer to encode ! (1.7x vs. 2.0x on a P2/500MHz) Effectively 64k ogg files encoded with rc3 are smaller than files encoded with rc2. I hear people debatting on how satisfied

I'm reordering the code in ao_wav.c that writes wav files to prevent the problem we had earlier. If ogg123 was improperly terminated (Segfault, kill -9, etc.), the output wav file was not even recognizable because the header was totally blank. I have found that at the start of playback (from libao's perspective), I know all of the wav header info except two things: 1) The length of the

The latest patch to allow oggenc to read FLAC files is up at: http://www.ph.utexas.edu/~volsung/patches/ Now both native FLAC and Ogg FLAC files can be read. Comments should in theory be preserved coming from either FLAC or Ogg FLAC. I cannot figure out how to make an Ogg FLAC file that has comments, so I've only tested it with normal FLAC. (Any tips would be appreciated here.) Note the

I was wondering if there was a way to recompile ogg123 so that it didnt look for "Ogg" at the start of each file. Ie change it so it looked for "Dog" or something. Why you ask? because in theory Im not ment to have any music files on my work computer NFI why but just cant. If I could mask an ogg file to look like another file then I could beat the system. Assuming that they

For those of you who want to be able to decode Ogg Vorbis files into other formats, SoX (the swiss army knife of audio programs) now has Ogg Vorbis support in CVS. It can read Ogg Vorbis files and export the audio in any format SoX supports. You can also write Ogg Vorbis with it, but, because of limitations in the design of SoX, only output at 128kbps is supported. Note: Instructions on how to

[I'm still poking around in vorbis-tools. Here's another trivial patch.] In ogg123.c, the function get_stream goes down a linked list looking for the nth stream. Currently it will run off the end of the list and dereference the NULL pointer if the list is smaller than n. Attached is a patch to check for a null list and abort. Would assert() be a better way to do this? -=-=- Stan