similar to: vorbis-tools comment cleanup

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

Hi there. First of all, I'd like to congratulate to developers for making a free specification and LGPLed decoder/encoder. :-). I did some test, ripping 17 tracks of my CD and converting them to both MP3 and OGG format. MP3 encoder/player was Lame 3.70 OGG encoder/player was from a Saturday nightly tgz package. ------------------------------------ MP3: LAME-3.70 mpg123-0.59r-4 MP3: lame -S

Hi there. First of all, I'd like to congratulate to developers for making a free specification and LGPLed decoder/encoder. :-). I did some test, ripping 17 tracks of my CD and converting them to both MP3 and OGG format. MP3 encoder/player was Lame 3.70 OGG encoder/player was from a Saturday nightly tgz package. ------------------------------------ MP3: LAME-3.70 mpg123-0.59r-4 MP3: lame -S

------- Forwarded Message The following patches should fix vorbis-tools to build on NetBSD. I'm not including the diff to the configure scripts, so you'll need to rerun autoconf in the toplevel and libao directory after applying these patches to the configure.in files. It also appears that vorbis-tools/libao/ao_libs.inc is automatically generated by a configure script but checked into

Here is patch with manpages for ogg123(1), mp3tovorbis(1) and vorbize(1). Manpages are in pod format, because it is the most readable man source, and are compiled by pod2man. all and clean for man/ work. Install and uninstall for man/ seem to work. Manpages are GPLed of course. <HR NOSHADE> <UL> <LI>text/plain attachment: manpages.diff </UL> -------------- next part

Hey. Last night I hacked grip so that it'd allow me to use vorbize and comments with grip. It's very ugly because grip'd need a bit of rearrangement in order to facilitate the way the vorbis comments work (that is, the comments are not added in after the encoded file has been written). Any one who wants to use it should patch grip-2.94 (http://www.nostatic.org/grip), and make sure you

I've fixed a heck of a lot of stuff in the time frame of just over ten minutes. And you all care... right. I actually ran Vorbize, and discovered some stupid bugs (e.g., segfault???). Fixed. Both Vorbize and Ogg123 should now speak fluently in Monty's comment-eese. I'll be working on getting both to implement all the comment tags; I'm seriously considering dropping all comment

I just commited my modifications: vorbis-tools is back in the main build, but ogg123 is out of the vorbis-tools build. I am investigating the cross-platform libraries suggested. ogg123 silences "Clipping in frame x", can now play multiple files at once, and has a new stream handling format (resolves the get_stream() bug mentioned earlier). Vorbize has options for no comment and

Hello ppl! I asked some time ago how about adding the option to control ogg123 interactively from command line, similar to mpg123. So I got fed up waiting and added it myself today. The code initially comes from mpg123, I already adapted it to work with aviplay and vlc so it's proven and shouldn't introduce many problems. The only problems I see now: - in order to compile ogg123 now

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

A small patch (attached) to the ogg123 source (dec 15 nightly build from CVS) that implements ranged playback a la: ogg123 -r 12:10-13:00 file.ogg to playback 12m:10s-13m:00s fragment from the file.ogg soundfile. Usage: ogg123 -r hours:minutes:seconds.fraction-hours:minutes:seconds.fraction anything can be pretty much omitted (within reason) [although it does not support hh:mm:ss.hh- ]

I first downloaded Vorbis about a month ago, around the time Rok Papez posted comparisons of Ogg and Lame [*]. Here's my much rougher test on a single file. CPU: AMD K6-233 MP3: LAME 3.70, mp3blaster 2.0b6 Ogg: Vorbize 0.6 (Xiphophorus libVorbis I 20000718), ogg123-0.1 Data set: Ministry, "The Fall" (51,955,724 byte WAV) * * * Ogg Vorbis command line: time vorbize -v -w

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

Here's yet another ogg123 patch that: 1) Adds a command-line parameter "--prebuffer n" or "-p n" that decodes "n" chunks into the buffer before even forking off the writer thread. 2) Moves the buffer_shutdown call in ogg123.c to its proper place. 3) Doesn't use signals ;) This way, the default behavior is to start playing immediately, while allowing the user

Hi all, Ralph Giles pointed me here for my ogg123 patch. I had mail'd the authors (listed in ogg123.1) and Xiph about this but I recieved no response - and here is probably a better place for it. I decided to work on ogg123 when I wanted to work on Ogg Vorbis support in Nautilus (if you don't know what it is, it is the new Graphical File Manager for GNOME). Currently Nautilus has mp3

Again, Hi All, Thanks for your replies. I probably should've mentioned that I'm not subscribed to the list but I found your answers on the archives. I just wanted to go on record and mention that I do in fact have all the original CD's and that by re-encoding I meant repeating the entire process of ripping the original CD's (with cdparanoia (of course ;)) and then encoding them

I'm updating my vorbis rpm spec file, and when I try to do "make -C vorbis-tools ogg123", due to rpm's build environment, I get lots of: gcc ogg123.o -o ogg123 -lm ../lib/libvorbis.a ../lib/vorbisfile.a ../lib/vorbisfile.a(vorbisfile.o): In function `_get_prev_page': vorbisfile.o(.text+0x54): undefined reference to `ogg_sync_reset' vorbisfile.o(.text+0xa9): undefined

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

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

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