similar to: More on getopt/getopt_long

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

1. ogg123 still won't build systems that don't have <getopt.h>. Was anything ever decided on how to procede with that? oggenc supplies its own getopt implementation. The only function really in question is getopt_long(), because getopt() is standard POSIX. See http://www.xiph.org/archives/vorbis-dev/200012/0359.html for a discussion of this issue. 2. Also, NAME_MAX is used in

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

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

There's some compilation issues on Solaris with the native compilers with the current CVS head. OGGENC: ======= -- "oggenc.c", line 202: warning: improper pointer/integer combination: op "=" I believe the problem here is that rindex() is prototyped in <strings.h>, which is not included. This may be a sun-specific thing. OGG123: ======= -- "ogg123.c",

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

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

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

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 have a small feature request for oggenc: Can a command line option be added to allow the user to set the first serial number to be used for the output ogg stream? This only takes a few lines of code, actually. Rationale: it is quite helpful for debugging other encoders. If oggenc is the "reference" encoder, ensuring that your new whiz-bang encoder has diffable output to oggenc is a

I'm running into memory leak and read-from/write-to unallocated errors in the cleanup phase of parallel oggenc. I see in vorbis_block_clear() that it references some fields on the vorbis_dsp_state that it cached during vorbis_block_init(), and conditionally does some cleanup based on the values of those fields. Does this fact effectively mean that you can't have multiple vorbis_block

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

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

After downloading the nightly snapshot last night, I've spent a good part of the day trying to build the package with Borland C++Builder 4. I have some things to report, and also need some help. [Note: this message is long and messy :)] {Converting DSP files to BPR files} I made the necessary BPR files from the DSP files with the Visual C++ Project Conversion Utility. This works okay

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

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

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

A variation on questions that I've asked before... In working on the parallel version of oggenc (both threaded and MPI), a profiling run shows that the function vorbis_analysis() takes up the majority of the run time. This seems to be an obvious choice for parallelization -- send each vorbis_block to a different processor, and let them call vorbis_analsis() in parallel with each other.

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