similar to: Speex support in ogg123

Installment #3 on my coding binge: The latest CVS version of ogg123 (in vorbis-tools) now plays FLAC and Ogg FLAC files. The FLAC support is optional, so if you don't have FLAC 1.0.4 and the header files, ogg123 will still build without it. Please give it a whirl and let me know how it works for you. --- Stan Seibert <p>--- >8 ---- List archives: http://www.xiph.org/archives/

A branch of ogg123 is in CVS now which you can use to test the libao prerelease. Because of the way I did the branch, checkout is a little screwy (as Monty once said: "Know thy tools!"). (I am assuming here that you already have CVSROOT set correctly.) cvs co vorbis-tools # Notice there is no tag here! cd vorbis-tools/ogg123 cvs update -r volsung_20010721 Or, if you already have

------- Forwarded Message Return-Path: owner-vorbis-dev@xiph.org Delivery-Date: Mon Jul 10 01:38:16 2000 Delivered-To: xiphmont@localhost.xiph.org Received: from localhost (localhost [127.0.0.1]) by bloopfish.xiph.org (Postfix) with ESMTP id 1A4A48882F for <xiphmont@localhost>; Mon, 10 Jul 2000 01:38:15 -0700 (PDT) Delivered-To: xiphmont@xiph.org Received: from xiph.org

Hi, I have made a small patch for enabling repeating in ogg123. It adds the parameter "--repeat n" or "r n" where n indicates how many times it repeats the playlists. Zero in forever. Apply it if you like, I find it very convenient. -- Regards Niels Sandmann Jabber: sandmann@jabber.dk, Email: sandm@nn.dk -------------- next part -------------- Only in ogg123: .deps Only in

Kenneth mentioned he wanted a cross-platform audio library to use for ogg123. So, I've spent the last week hacking up the libao from ac3dec that someone suggested earlier. It bears little resemblance to the old code, but now does what I want. libao now supports OSS and WAV file output, with the infrastructure in place to expand further. There are Solaris and IRIX drivers that I inherited

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

The problem I noted earlier about segfaulting at the end of playback and the problem about mangled wav files have the same cause. The playback buffer in ogg123 is freed without checking if it has even been allocated. Ken probably didn't notice because he was using a buffer (which is optional). :) A patch for ogg123.c is attached. (Probably takes the record for the smallest patch

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'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

Now that FLAC has officionally joined the Xiph family, there are three different free audio codecs, which can be stored/transported using the ogg container. Would it be possible to create an API and/or a library that would cover them all? If my understanding of the situation is correct, if an application wants to support vorbis, speex and flac, it has to use three different interfaces.

Now that FLAC has officionally joined the Xiph family, there are three different free audio codecs, which can be stored/transported using the ogg container. Would it be possible to create an API and/or a library that would cover them all? If my understanding of the situation is correct, if an application wants to support vorbis, speex and flac, it has to use three different interfaces.

Now that FLAC has officionally joined the Xiph family, there are three different free audio codecs, which can be stored/transported using the ogg container. Would it be possible to create an API and/or a library that would cover them all? If my understanding of the situation is correct, if an application wants to support vorbis, speex and flac, it has to use three different interfaces.

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

Bear with the text-based format for a bit. I'll make it nicer over time, but for now it's just a lynx -dump of the html one. As always you can find these at http://www.vorbis.com/ot/ and http://www.vorbis.com/ot/latest.html for the latest one. ---- Ogg Traffic for Tuesday, October 30, 2001 Jack Moffitt <[1]jack@xiph.org>

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

I just committed what will eventually become the next version of libao. I've made some major changes: renamed stuff, redesigned the API, actually documented things. It *will* break any current libao applications (like ogg123). It is on its own branch, so it shouldn't affect the mainline libao code for a while. But beware: I want to land this branch before Vorbis 1.0 goes out. Please

Daniel: thought you'd like to know that I'm forwarding this to the vorbis-dev mailing list. <p><p>Hey vorbis-dev (after a very long time!), I got the attached message sent to just 3 of the people who have worked on ogg123, and thought it would probably due better good on the mailing list. It seems to concern http://bugs.xiph.org/show_bug.cgi?id=250 by casual search. For

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

Hi everybody, below is the latest installment of news from the Xiph.org community. The HTML version is at http://www.vorbis.com/ot/20030820.html. Enjoy! -Carsten <p>Ogg Traffic for Wednesday, August 20, 2003 Author: Carsten "Purple" Haese Contact: [1]carsten@xiph.org Date: August 20, 2003 Table of Contents 1 Status Updates 1.1 Monty