There have been some changes in the Advanced Encode Options since 1.0.1. Mention is made in the last of the Xiph.org Monthly Meetings.

I have posted a new compile of oggenc2.3 at Rarewares to allow such testing to take place. The download includes an explanation of the Advanced Encode Options in RTF format.

John33's irc quote moved here:

Just to make this clear: Activate the code through --managed just as before. The old ABR code has been completely replaced.
Using the advanced options is not recommended, if you don't exactly know what they do.
Everything else remains unchanged, so this build should be relatively save to use and will lead to 1.0.2 sooner than you might think.
Case was kind enough to do a MSVC build of the latest code for me, grab it here.

More Random IRC quotes:


Try some of my samples (or whatever samples you like) to test the new code and report back here. Especially old vs. new managed code tests at bitrates < 128kbps (you might want to include a q setting with a similiar bitrate for reference) are of interest.

<note>I should read (= double check) my posts before posting.</note>

ok, i give up. how the hell do i encode in cbr? i've read the readme and from what i understand the commandline should be:

--managed --advanced-encode-option bitrate_average=64 --advanced-encode-option bitrate_hard_max=64 --advanced-encode-option bitrate_hard_min=64

but that doesn't do anything, it just encodes at -q 3.

Try

--managed -b 64

Q! ==>
After reading the .rtf doc I also understund it your way, & also tryed :
--managed --advanced-encode-option bitrate_average=80 --advanced-encode-option bitrate_hard_max=80 --advanced-encode-option bitrate_hard_min=80
& get basic default Q3 so you're not alone

then I tryed :
--managed -b 80
& get a "true average" 80 but the bitrate seems to move from +3/-3kbps (in winamp kbps indicator ... dunno how accurate it is)

so I tryed to get not only "true average 80" but "true always CBR 80" & get rid of the +3/-3kbps so I tryed:
--managed -b 80 --advanced-encode-option bitrate_hard_max=80 --advanced-encode-option bitrate_hard_min=80
but I "at first look" get "almost" the same result as with --managed -b 80 thou the files are differents

Is there a way to get true CBR with a Kbps that don't move ? cauz if the CBR ogg vorbis mode ouputs files with a kbps that varies & "only" a fix average Kbps it's gonna be difficult to differ a single song in CBR with average 160 from a single song in ABR with average 160 ... I guess it will be easy with external toolz or with a full album (as an ABR rip will never have a fix XXX average on all songs) but for a single song this doesn't seem to be very practical ?

What are we supposed to test ? quality (ears+graph) ? size ? artefacts ? anything ?
Can't tell my feelings on it as I didn't listen much to the files yet but is there anything bad in the swichtes I used ? I am not sure at all I understand all I do

OggZealot: Are you using John33's oogenc2.3 build? Please try the original CVS build from my post before reporting bugs that seem to be related to the front end.
Also make sure to read my note about the advanced switches.

dev0

Quote: dev0
"Are you using John33's oogenc2.3 build?"
Yes, I made my first try with John33 build version, but I just retryed with the Case build & I get the same result ... I get the fix targeted CBR bitrate on average in the winamp ogg tag info windows but the winamp kbps indicator move up & down +3/-3 as if ABR & don't show a constant number as with MP3 CBR files ...

"related to the front end"
I didn't use a front ... only the oggenc2.exe command line & winXP Dos windows

"make sure to read my note"
I read all I found ... but I may not have understund all

... nevermind I may not be the most skilled user to test ...

What does Vorbis gain by allowing CBR?

Also, why *true* CBR? From what I understand even 128Kbps MP3 isn't constant bitrate, and having some bits to shift around helps the quality.

It seems like a step back. Now people can answer the question "how to encode OGG 128 plz??" and be unconcerned with this new VeeBeeAre. Which means most users' quality comparisions will be done in CBR, which will undoubtedly not be Vorbis's strong point (and even the VBR presently needs further tweaking & tuning)...

Or maybe I'm just being paranoid. =p

CBR was a request from chinese EVD (righ abbreviation?) consortium. Vorbis is one of their candidate systems. They want CBR for dull reasons ;-)



Vorbis CBR also uses a "bit-reservoir".



There should be a "ATTENTION: Encoder working in idiot mode!" message when using CBR.



I doubt it. Your technical concerns are valid. However, CBR will never ever become a "recommended" mode.

Maik

Yes, I am concerned too about the CBR, if it's needed by someone particular, let it be hidden somewhere in advanced modes that's not the normal user will be able to find.

I treat CBR as an evil thing to do, and vote as a 'step back'.

And in GUI-based encoders, where all options basically should be visible, hide that 'evil' CBR somewhere backbackback, behind 100 confirmation dialogs before being able to use it. :) Probably that user will at least think twice before using it. :)

Oh, come on! =p That's just pig-headed.

Better to have a concise warning about why CBR is the worse, non-recommended mode than to make it a total pain-in-the-ass to get to. Because *some* people will probably have legitimate reasons to use even the less-than-great CBR mode once it exists.

I also tried it with both John33's build as well as Case's and they both give average bitrates higher than what I give it (64 kbps)

John33's oggenc output:



Case's oggenc output:



Playing it in Winamp shows the birate jump from 65 to 66 to 67. So is Winamp telling fibs and this is true CBR?

A whole lot of people here are wondering about how to use this to encode 'real' CBR mode, and/or ABR mode, and why the output bitrate is slightly higher.

So, I thought I'd join in with some useful information.

CBR:
oggenc -m 64 -M 64 -b 64 file.wav
This set minimum AND maximum bitrate to the same as the average bitrate - true CBR. You can do this using the --advanced-encode-option stuff as well, but that's not recommended.

ABR:
oggenc --managed -b 64 file.wav
This uses the same bitrate management as the CBR version above, but doesn't have hard boundaries. Notably, this means that a) if it goes under the target bitrate, it won't add padding, and b) if it goes over the target bitrate, and can't encode it any lower, it won't just truncate the packets (this case is rarer, underrunning the target bitrate is much more common).

Next: why the bitrate is higher than that requested.
There are several reasons for this:
1) This controls only the vorbis bitrate. The ogg framing layer is added on on top of this. That should cause a constant (more or less - there are special cases where it might not be precisely constant) overhead.
2) Headers at the start aren't included in the bitrate calculation (the 3 vorbis header packets).
3) In 'true CBR' mode, extra padding is NOT added at the very end of the stream - the bit reservoir (which isn't like the mp3 one, don't get them confused!) isn't flushed.
4) The target bitrate is not neccesarily identical to the requested bitrate. Internally, various things are rounded off to the nearest integer value. This means that, although it is real, constant, bitrate, the chosen bitrate won't be exactly what you requested.

Hope this helps.

Mike Smith

p.s. I've heard one report that john33's "oggenc2" compile here introduces artifacts at the end of encoding mono files. Not having easy access to windows machines, I can't test this. Anyone using mono files might want to take care to test this before using it.

Thanks for clarifying I've never used CBR or even ABR before in oggenc so I'm not familiar with all these switches.

I remember Monty mentioning in irc that the bitrate management engine does not take into account Ogg frame overheads

Given that the encoding process and libraries are unchanged from the standard oggenc, this surprises me. This has not been reported to me, but if anyone can provide samples where this occurs, I'll happily look into it.