similar to: vorbis/ltconfig

Happy new millenium! Summary: I'm having a problem queueing up the ogg_packet results of vorbis_analyze() for later writing to an .ogg stream. The docs don't seem to say if this is permissable or not. Hence, I don't know if I'm using the API incorrectly, or if this is an actual bug. ----- Attached is a short patch to vorbis-tools/oggenc/encode.c (from CVS head, 01/01/01... I

Without "no-dependencies" in every single Makefile.am's AUTOMAKE_OPTIONS line, automake will put gnu-specific instructions that will barf a) if you don't use gmake, and b) don't use gcc. This is actually in the automake manual, section 7.11, page 26 -- it's not an unexpected thing: "Currently, this support [automatic dependency generation] requires

>From /., here's the URL with the announcement of mp3PRO http://www.twice.com/html/pagebeta.cfm?InputKey=2853 {+} Jeff Squyres {+} squyres@cse.nd.edu {+} Perpetual Obsessive Notre Dame Student Craving Utter Madness {+} "I came to ND for 4 years and ended up staying for a decade" --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage:

vorbis/lib/vorbisenc.c:138 and 157 have "//" comments. Patch included for the lazy (like me!). {+} Jeff Squyres {+} squyres@cse.nd.edu {+} Perpetual Obsessive Notre Dame Student Craving Utter Madness {+} "I came to ND for 4 years and ended up staying for a decade" Index: vorbis/lib/vorbisenc.c =================================================================== RCS file:

Per Monty's suggestions from a while ago, I have [finally] gotten around to playing with different schemes for parallel oggenc. Monty's main suggestion was to have a single thread loop over reading samples and calling vorbis_analysis_blockout(), and then queueing up the resulting blocks to be processed through vorbis_analysis() in other threads (in parallel). To verify that this works, I

So it looks like the Frauenhoffer boys are issuing an updated format -- MP3pro. They claim that it will give 128kbps/MP3 quality in 64kbps. I'm interested to see what others think of this. I'm also curious: I've seen others on the list say that Ogg/Vorbis' sound quality is "better" than MP3. Can this be quantified (or is this already on a web page somewhere)? I kinda

It seems that the configure script in CVS does not check the CFLAGS environment variable at all. Indeed, on line 121 of configure.in, CFLAGS is explicitly set to be blank. Is this done for a reason? I see that several sets of CFLAGS are passed into the Makefiles by configure based upon specific architecture/compiler combinations -- perhaps this is the reason...? I ask because users may wish to

Since vorbiscomment is being resurrected in a new form, can someone please fix the vorbis-tools/vorbiscomment/Makefile.am? There's two things wrong: 1. Using _LDFLAGS doesn't allow the user to specify their own LDFLAGS. _LDADD or _LIBS should be used instead. 2. The order of libraries is wrong such that it won't link properly when compiled statically. Here's a trivial

I have sent some patches to some Makefile.am's as well as to some configure.in's, particularly for building without gcc and gmake. Can someone review those patches, and/or commit them? (we are working at the CVS head these days, no?) I cannot build in Solaris without gcc/gmake, for example -- running "autogen.sh" in the ao project with the native Solaris compilers causes

Speaking of ogg123 fixes and Solaris... <getopt.h> doesn't appear to exist in Solaris. Hence, ogg123 won't compile on Solaris at all (even with gcc). I originally mentioned this back in November (http://www.xiph.org/archives/vorbis-dev/200011/0291.html). Can this be fixed? {+} Jeff Squyres {+} squyres@cse.nd.edu {+} Perpetual Obsessive Notre Dame Student Craving Utter Madness

I sent a message about 2 weeks ago about build problems at the head of the CVS tree with non-gcc compilers on POSIX systems, although I didn't correctly identify the link problems as being static-library only (see my previous mail about "static link broken"). Some problems have been fixed, but some still seem to be there. I have edited my original mail to list the problems that

I notice that the user is not able to set their own CFLAGS or LDFLAGS in the ao, ogg, vorbis, and voribs-tools projects. Is there a reason for this? I understand the fact that these modules want to set extremely high optimization flags, and that most users won't know what these are offhand, but there are times when it is useful for the user to specify their own CFLAGS/LDFLAGS. For example,

vorbis-tools/oggenc/utf8.c:164 has a //-style comment; it should be /* ... */ so that non-gcc compilers won't barf (e.g., solaris Forte 6.1 cc). Patch included, if you're really lazy. :-) {+} Jeff Squyres {+} squyres@cse.nd.edu {+} Perpetual Obsessive Notre Dame Student Craving Utter Madness {+} "I came to ND for 4 years and ended up staying for a decade" Index: oggenc/utf8.c

This time in vcut: vorbis-tools/vcut/vcut.h:23 and 24. No, I'm not spending quality time with grep; I'm trying to compile vorbis with the native Sun Forte compilers. Much badness, of which these // issues are only part. :-( More details to follow... Patch/inc/lazy. {+} Jeff Squyres {+} squyres@cse.nd.edu {+} Perpetual Obsessive Notre Dame Student Craving Utter Madness {+} "I

I don't think that the getopt_long() situation is handled correctly in the vorbis-tools module. Here's my take (comments welcome!). ----- This applies to oggenc, ogg123, and vorbiscomment. See http://www.xiph.org/archives/vorbis-dev/200012/0359.html for background and prior discussion on this issue. There are 2 issues: 1. Summary: getopt() is a POSIX function. It will already be on

Many of you probably remember the flurry of posts that I created a few weeks ago about writing a parallel vorbis encoder. Here's what I have been doing since... Someone (I can't remember who offhand -- might have been Greg) mentioned using threads instead of MPI for parallelism on the argument that more people have SMPs than who have (and know how to use) an MPI implementation. Good

Greetings everyone. I have 2 quick questions about ao/ao.m4, ogg/ogg.m4, and vorbis/vorbis.m4. 1. Is there any reason that the macros are named AM_PATH_AO, AM_PATH_OGG, and AM_PATH_VORBIS? Can we change them to something else? I ran into a problem when trying to add support for ogg/vorbis into a package today: Automake assumes that anything beginning with AM_ belongs to automake -- these two

It seems that configuring/building with "--enable-static --disable-shared" causes some problems with building vorbis-tools -- the Makefile.am's in oggenc and ogg123 do not appear to be correct. That is, if you build ao, ogg, and vorbis statically and try to compile oggenc or ogg123, you'll get unresolved symbol linker errors. This happens on all POSIX architectures and

The configure script for vorbis-tools requires one to manually specify: --with-ogg-prefix=PATH --with-vorbis-prefix=PATH --with-ao-prefix=PATH This is quite a pain to type. It would seem that most people will be installing all of these packages into the same $prefix. So in the absense of specifying these flags, it would seem suitable to just check for the appropriate

getopt() seems to be on all the Unix flavors that I can check (Solaris, IRIX, AIX, HP-UX, Linux). getopt() may be a standardized POSIX function...? I'm not sure offhand. Regardless, I think it's safe to assume that it's in all flavors of Unix -- oggenc/ogg123 need not include a local version of it for POSIX builds. Indeed, the getopt.c that is in oggenc is not friendly to the Sun