similar to: (Yet another) ogg123 buffer patch

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

I know you're tired of hearing me complain about ogg123, but this time I noticed that some of the error messages are a bit inconsistant. Also, I noticed that some things (like "Error connecting to server") are fatal errors that kill ogg123, while I think they should simply go on to the next file in the list like "input not an Ogg Vorbis audio stream" does. Another problem

I tried to use ogg123 -b to play from a slow HTTP server, and I realized that ogg123 starts to play immediately even if the buffer isn't full, so if it can't read the ogg fast enough it skips, even with a huge buffer. Is this the way it's supposed to work? It seems to me like the buffer shouldn't start playing until it's full. Am I misunderstanding the purpose of having a

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

There seem to be a couple of problems with the buffering code just checked in: 1. buffer_shutdown(NULL) is called when the bitrate changes and you're not using a buffer. 2. The buffer is not used for anything but the first file. 3. The buffer isn't explicitly closed when playback is finished, sometimes leaving an ogg123 process sitting sucking up 100% CPU time. Here's a patch that

Hi Here is another patch regarding time in ogg123 which is more controvercial than the other one I send some days ago. (see attachment) When working with Daisy/SMIL [1] files it would be helpfull if the user could stop play at a specific time. Currently .ogg files are not allowed in the Daisy format but that will hopefully happen one day if I work hard at it. A clip in a Daisy file could look

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

Is anyone looking at bugs.xiph.org? There are several bugs that are easy to fix (bugs 2,3,4,7, and 9) or have already been fixed (Bugs 5 and 6). Bug 8 I think is a Multi/single -threaded issue and Bug 15 is a problem with ogg123, not with libao. Some of these bugs are pretty old. Is anyone going to fix them? I'd do it, but I don't have CVS write access. Aaron Plattner <HR

I just used ogg123 to play back a file encoded from a 22.5 KHz WAV, and it played twice too fast. Looking at the source, it seems that the sampling rate and number of channels are hard-coded into it. What´s the best way of fixing this? I quickly hacked together something that closes and reopens the devices before each file (diff attached). Is there a better solution? Aaron Plattner <HR

I noticed that ogg123 still has its problem opening multiple devices. Here´s a patch that fixes that. I made it considerably easier by changing append_device to return the new device struct instead of the head of the list each time. This way, the options for the device are modified with the structure already in the list, instead of building up options before doing so. I also moved an fprintf

Looking at it, I think this patch is actually better than the one I sent before, mainly because it keeps from adding a bunch of weird parameters to functions at the expense of a single global variable (globals... ick). Aaron Plattner <HR NOSHADE> <UL> <LI>text/plain attachment: ogg123.diff.2 </UL> -------------- next part -------------- A non-text attachment was

Hi, I've been working on ogg123 to see if i could add a remote interface compatible with the one in mpg123. This remote interface is used mainly by mp3 players which use mpg123 as their backend. The reason i did this was that i have recently encoded some of my cd's in ogg vorbis format but wanted to keep using my favourite player (playmp3list,

I was just playing with GDict, and I tried looking up Xiphophorous. The closest entry is for "Xyphophorous helleri". Why the difference in spelling? Was this on purpose? (In my opinion, Xiphophorous looks cooler than Xyphophorous). Aaron Plattner --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this

Hi. I have two CDs that the artists inteded for simultaneous listening. They even provide instructions on how to start two CD players with the minimal time shift. (for those interested - the CDs are Neurosis/Times Of Grace and Tribes Of Neurot/Grace) I've heard that Vorbis can encode multiple streams. I've already encoded both albums into regular 2-channel .ogg files. The questions

Hi, I noticed there was some discussion on this list about the desire for ogg123 to support output to stdout via Sun's .au file format, so I decided to give implementing an AU driver for libao a shot. Here is my first attempt. To test the driver: * Apply the patch below (against ao in CVS) * Copy the attached ao_au.c into ao/src * Run ao/autogen.sh, compile, and

After accidentally ogginfo-ing a WAV file, I'm wondering if there's any reason I shouldn't commit my fix that breaks out of the current file test if header integrity fails. Is there any case where the header integrity will fail but there is still any useful information to get out of the stream? I don't think so... -- Kenneth Arnold <ken@arnoldnet.net> - "Know

In the vorbis-tools of the 20010710 version of CVS snapshot, ogg123/ogg123.c causes error on FreeBSD: <sys/types.h> is required. This *HAS NOT BEEN FIXED SINCE THE 20010601 VERSION*. I would appreciate if you just add an #include line - or let me know why you do not want to do so. // Kenji Rikitake *** ogg123.c.FCS Sun Apr 8 11:33:08 2001 --- ogg123.c Sat Jun 2 00:40:08 2001

P { margin-bottom: 0.08in; }A:link { } Hi Ogg Fans, I have a puzzle. When I'm getting ready to plan a larger program, I often do some little experiments to see whether what I'm thinking is going to be able to happen in the way that I anticipate. My next project involves some playing .ogg files in a random order. I have three brief files which I have used in this experiment. I am

Hi, Regarding ticket 523 "ogg123 can no longer play from stdin": http://trac.xiph.org/cgi-bin/trac.cgi/ticket/523 It seems that 'cat sample.ogg | ogg123 -' works for me, for ogg123 from svn. Can anyone verify that code has been committed to fix this bug, or is there a different usage that triggers the bug? Conrad.

Ulrich Windl wrote: > Hi! > > Recently I made some recordings (44.1kH/24bit WAV), and after > post-processing (normalization, noide reduction) I saved them as flac (still > 44.1kHz/24bit). > I noticed that ogg123 can decode these, but it will output 24 bit only. > Specifically there's no option to transform the output to 16bit. > When trying to pipe the 24bit WAV output