I compiled aoTuV beta 4 on my FC4 machine, which has gcc4 installed and tested oggenc on one of ff123's samples at -q 3. The resultant file was 161 kbps and I heard very noticeable artifacts. I then switched to using gcc 3.2 (gcc32) and the problem went away (now the bitrate is 106 kbps).

I've uploaded the corrupted sample HERE

Very strange

Sounds fine to me, assuming the original recording was made while twirling the microphone rapidly through the air on it's cord.

Playing it in Foobar I see the real-time bitrate display is fluctuating madly, never seen anything like that before.

Does this happen even with no optimizations or with "-fno-strict-aliasing"?

Edit: ppc-darwin gcc 4.0.1, Bach 94kbps @ -q3, 106 kbps @ -q4.

I just did a compile with optimizations turned off (I just used the DEBUG flags) and the problems are gone. Maybe I should try updating my gcc. At the moment, its gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)

I just updated my gcc to version 4.0.1 and the problem still remains

There's a terrible form of ringing in this encoder. It's maybe a consequence of the yo-yo you described (I also noticed it).

Yeah, I know its terrible. Something must be wrong with gcc 4 in Fedora Core 4. I just compiled libvorbis using Intel C++ compiler 9 (icc) and there were no quality problems (bitrates seem to be normal). I'll just stick with the icc compile for now.

I wonder if this is a floating point optimization bug, or something more general? I'd hate to see an integer only gcc compiled program outputting: "Halio; wO1ld?"

Did you try "-fno-strict-aliasing"? Strict-aliasing is not enabled in gcc 3.x for optimization profiles, but is included in gcc 4.x for profiles -O2 and up. It breaks a lot of code (at least it does on ppc/darwin, even apple removed it from the profiles in its own gcc4 release) including libvorbis (abnormally high bitrates) and musepack (source file gets mangled, hence garbage out- ~900kbps for --standard).

Yep, you're right. I just tried putting "-fno-strict-aliasing" and now the problem is gone. That is very strange (and dangerous too, since I wouldn't have noticed it on other code).

I've just committed a fix for this problem to libvorbis SVN. Thanks for the reports. It was, in fact, a libvorbis bug - gcc4 just exposes this buggy code where it didn't in older releases. strict-aliasing is fine on working code :-)

We'll probably do a release soon.

seems our union trick did the job here too

I just tried to install aoTuV compiled from scratch and I noticed this problem of ridiculously high bitrates and horrible sound. Fortunately I found this thread! Thanks! I wouldn't have found this cause on my own.

I added an entry on the wiki, Compiling aoTuV. (and I rewrote Channel coupling since the original was mostly incomprehensible to me)

Or you could just apply the 4.51 diff to Vorbis 1.1.2 since the problem is fixed in that version and you get the small bug fixes since 1.1.1 (AFAICT there were no quality changes in 1.1.2 aside from this bug, only documentation changes)

I see, c15zyx, but HA has written all over the place that aoTuV beta 4 is the officially recommended best vorbis encoder, and that 4.51 is not yet peer reviewed, so that's why I wanted to stick with beta 4.

By the way, does anyone know where I should start if I want to understand the Vorbis encoding? The official Vorbis documentation only describes the decoder without giving much hints on how the encoder should use it and why Vorbis is so suitable for removing inaudible data.

[edit: typo]

Delurking. (maybe even to true activity, who knows)

b4.51 should be very similar to b4, except being much better in lower bit rates/quality levels.

The big news is the high frequency noise compander (q <5) (linked with current lo-freq one), which deprecates the psy-model HF reduction, and mid-frequency point stereo (weighted of course) (q <3).
Of course it fixes that bug surfacing with GCC 4.x, but libvorbis 1.1.2 also does that.

Anyway, it doesn't sound worse *to me* at any quality level I've tried with my tracks. Didn't bother to ABX.

I was about to point something out... GCC4 is a very strict compiler, so things that would have been allowed with less rigorous compilers (like msvc, icc, gcc3.x) will now either result in compile-time errors (hopefully) or bugs (not as good). The benefit to this behaviour is that it encourages proper coding, and discourages the use of compiler-specific hacks. It also (like in this case) exposes some bugs that would have otherwise gone unreported.