similar to: ogginfo speed

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

If anyone is interested, I smushed the less than 0 quality rate setting into oggdrop. The diff is below. Alan <p><p>Index: encthread.c =================================================================== RCS file: /usr/local/cvsroot/win32-tools/oggdrop/encthread.c,v retrieving revision 1.9 diff -r1.9 encthread.c 117,118c117,118 < if (quality < 0) < quality = 1; ---

I have undertaken a small project of writing a Vorbis decoder completely from the spec, with the goal of catching any errors, both typographically and algorithmically, in the spec. My "reference" decoder is also being written in an extremely methodical style, with practically no algorithmic optimization, such that it will be clear that every step has been copied exactly from the spec.

I've just done some rudimentary testing to see how Vorbis degrades at absurdly low bitrates without downsampling. In summary, don't hope for anything decent below -q 0 for now. I tried oggenc -b <bitrate> -M <bitrate> for the below and a few in between: 24k - spectral energy "floor" captured decently, but many pure-tone blips (think old computer movie sound effects)

1.0rc3, OpenBSD/i386 & FreeBSD/alpha. ogg123 segfaults after playing a file. This will not happen if I specify multiple songs and skip (^C) to the next one. Seems to be independent of buffering (-b) and output device (oss, esd, raw). -- Christian "naddy" Weisgerber naddy@mips.inka.de --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg

-------------- next part -------------- A non-text attachment was scrubbed... Name: part Type: text/enriched Size: 816 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20020719/dce04a57/part-0001.bin

I am not too familiar with the specs for the .ogg format but have some ideas.. Maybe the existing format already addresses these but as others here would know better, I write this problem: with hundreds or thousands of songs/speeches it is hard to do a word search for a recalled verse or phrase. I suggest adding a linked or imbedded text field. for speeches, a transcript could be attached to

Coming out of a long (but definately needed) silence for a moment: A few things for vorbis-tools, since I no longer have CVS access (I think I just misplaced that key): 1. Before anything, put oggchain out of its misery. Please. It's a pile of junk that should have never been committed. Any smidgen of usefulness from it belongs in ogginfo anyway (and it's already there). 2. ./autogen.sh

I finally managed to compile ogg123 under MacOS X, after creating a PB project for it. Rillian, do you want to include the PB project in cvs? (it needs a LOT of polishing, though). ---------- Ogg123 from PACKAGE VERSION by Kenneth Arnold <kcarnold@arnoldnet.net> and others Usage: ogg123 [<options>] <input file> ... -h, --help this help -V, --version display

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

Hi, I have a bunch of old radio programs (mystery/drama shows, not music) encoded at 32 kbit (and some 48kbit) mp3 (mono). I want to reencode them in ogg and make them available over gnutella. My question is this. What is the best quality level (-q) for transcoding them. I want to preserve quality, but I want to be sensitive to the many modem based gnutella users. I also want to to

Hi Joane, I think AMDs are 'preferable' of cost/'performance unit'. For standard applications you will have to compare a Duron-900 to a P-III-933; and AMDs will perform much better when it comes to number crunching. And now -- have a look at the prices...! I wouldn't buy any Intel chip today... this may be a 'European' habit, but I think it isn't / shouldn't

As far as I could find, nowhere in the documentation or even source does it actually explain how to use vorbiscomment. Just a simple "vorbiscomment reads TAG=VALUE pairs on separate lines from stdin" would save people a lot of time. Of course, this is still a painful tool to use, and since I had some .ogg's lying around with broken comments (from my first ogg vorbis patch to grip),

I was just about to commit a big buffer overhaul when I realized that it would probably break a lot of stuff and I'd get yelled at, so it's in the kcarnold_work tag (or will be momentarily...). Have a look at it, try to make it deadlock. If I messed up the CVS tagging, also let me know -- I know only enough about CVS to be dangerous :) This should also reduce CPU usage noticably. The

A feature request that sounds reasonable and a bug report. ----- Forwarded message from Frank Klemm <pfk@fuchs.offl.uni-jena.de> ----- Delivery-Date: Sat Jan 6 06:35:21 2001 Date: Sat, 6 Jan 2001 15:26:43 +0100 From: Frank Klemm <pfk@fuchs.offl.uni-jena.de> To: xiphmont@xiph.org Subject: ogg123 X-Mailer: Mutt 1.0.1i For ogg123 I need the following feature: - Decode one .ogg file

This is a proposal for Ogg MIDI streams. It will also help other stream additions to Vorbis, as they should follow a similar model. Ralph has done much of the work on this, and also is working on MNG Ogg streams. Background ---------- I was contracted to do this work, so even if you can't think of a use for this, there is one ;) Basically with midi in Ogg, we can have a synchronized

This idea is so simple that I'm sure it must have been thought of before, and discarded, since AFAIK it's not used anywhere. I did a quick web search but that didn't turn up much, so I figured I'd put it up for discussion here anyway. How about using large-scale repetition in audio compression? I'm thinking of redundancy in repeated pieces of a song, ie a chorus.

A few more notes on the specs -- I just spent a few minutes and did up floor 1 header decode. Short and sweet, but still important. Monty, please read these and my several earliers -- I'm trying to improve and validate the spec for your codec, and though I understand you were taking a break before, a reply would be appreciated. Note (again, if you read my other emails) that if you help me get

We have a French translation (and general gettext-ization) of vorbis-tools! Still needs to be merged, though. Perhaps I'll tackle that tomorrow. See below. <p>----- Forwarded message from Fr?d?ric Boiteux <furgarat@free.fr> ----- From: Fr?d?ric Boiteux <furgarat@free.fr> To: "Kenneth C. Arnold" <kcarnold@yahoo.com> Subject: Re: Internationalization of

http://surf.chimie.uqam.ca/~kruus/vorbis/ now contain branch_beta3 and trunk subdirs that are updated daily (until branch_beta3 becomes historical next week, like the other snapshots at that URL). to web-browse the source code, go to http://surf.chimie.uqam.ca/~kruus/vorbis/lxr/http/source erik (back after audio-video sync miniproject. Yay!) --- >8 ---- List archives: