HydrogenAudio

Hydrogenaudio Forum => Validated News => Topic started by: john33 on 2004-01-07 16:01:04

Title: OggVorbis Post 1.0.1 CVS
Post by: john33 on 2004-01-07 16:01:04
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.
Title: OggVorbis Post 1.0.1 CVS
Post by: JohnV on 2004-01-07 16:25:03
John33's irc quote moved here:

Quote

20:07 < purple_haese> Monty has recently revamped the bitrate management code in vorbis...
20:07 < purple_haese> The changes are on CVS HEAD, and we need people to test the changes.
20:08 < purple_haese> Monty is worried that something is wrong because it worked right off the bat
20:08 < volsung> I didn't quite catch the purpose of the change... Speed or quality improvement?
20:08 < katabatic_> No.
20:08 < katabatic_> Real CBR.
20:09 < purple_haese> It doesn't seem faster. The log entry said something about reduced latency and memory usage
20:09 < purple_haese> and real CBR.
20:09 < volsung> Oh, for the chinese folks.
20:09 < dev0> hmmm
20:09 < volsung> Ah, reduced memory usage is good.
20:09 < dev0> If testing is needed I could do some kind of "test experimental vorbis cbr" sticky thread at HA.org...
20:10 < dev0> if that would be of any help
20:10 < katabatic_> Monty did ask for testing.
Title: OggVorbis Post 1.0.1 CVS
Post by: dev0 on 2004-01-07 16:55:09
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 (http://www.saunalahti.fi/cse/temp/oggenc.zip).

More Random IRC quotes:
Quote
2004-01-07 15:21:21 <dev0>   I'll do some ABC/HR testing comparing "new managed" vs. "old managed" at around 128kbps
2004-01-07 15:21:34 <xiphmont>   It took two months to tune the second rev of the bitmanager and two months to tune the first.  The third should not have worked in 1 week of planning + one night of coding.
2004-01-07 15:22:03 <xiphmont>   ABR is likely to be used at lower rates than that.  But yeah, logic bugs are my main concern.
2004-01-07 15:22:19 <dev0>   lower = easier
2004-01-07 15:22:24 <dev0>   64kbps then :)
2004-01-07 15:22:27 <xiphmont>   that too
2004-01-07 15:22:29 <xiphmont>   yeah
2004-01-07 15:22:38 <xiphmont>   that's the sweet spot of real usage I expect.
2004-01-07 15:22:46 <dev0>   I'll just do some tests and report if there's anything obvious
2004-01-07 15:22:47 <xiphmont>   I was surprised to find it as robust as it was.
2004-01-07 15:22:59 <xiphmont>   It deals well with some frighteningly small bit reservoirs.
2004-01-07 15:23:44 <xiphmont>   (The lowest actual reservoir it can use is one byte.  Scary)
2004-01-07 15:23:57 <Misirlou>   Will there be a new release with the code in the next few weeks or months?
2004-01-07 15:24:01 <xiphmont>   yes.
2004-01-07 15:24:06 <xiphmont>   I hope sooner than months.
2004-01-07 15:24:21 <xiphmont>   Oggfile and 5.1 are my current tasks.
2004-01-07 15:24:35 <Misirlou>   me too
2004-01-07 15:25:04 <Misirlou>   I'm worried that there aren't enough releases.
2004-01-07 15:25:20 <xiphmont>   I think 1.0.2 should be in progress approximately now.
2004-01-07 15:25:26 <xiphmont>   We had build system issues to fix.


Try some of my samples (http://www.rc55.com/friends/tobias/files/audio/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>
Title: OggVorbis Post 1.0.1 CVS
Post by: Q! on 2004-01-08 01:08:36
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.
Title: OggVorbis Post 1.0.1 CVS
Post by: QuantumKnot on 2004-01-08 02:09:12
Quote
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
Title: OggVorbis Post 1.0.1 CVS
Post by: OggZealot on 2004-01-08 06:20:29
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
Title: OggVorbis Post 1.0.1 CVS
Post by: dev0 on 2004-01-08 15:03:18
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
Title: OggVorbis Post 1.0.1 CVS
Post by: OggZealot on 2004-01-08 16:30:33
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 ...
Title: OggVorbis Post 1.0.1 CVS
Post by: Moguta on 2004-01-08 19:50:52
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
Title: OggVorbis Post 1.0.1 CVS
Post by: maikmerten on 2004-01-08 20:19:07
Quote
What does Vorbis gain by allowing CBR?


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

Quote
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.


Vorbis CBR also uses a "bit-reservoir".

Quote
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)...


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

Quote
Or maybe I'm just being paranoid.  =p


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

Maik
Title: OggVorbis Post 1.0.1 CVS
Post by: HMage on 2004-01-08 20:25:08
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. :)
Title: OggVorbis Post 1.0.1 CVS
Post by: Moguta on 2004-01-08 20:37:11
Quote
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.

What is the Chinese EVD?  Sounds like they have a bit of influence for a request to become an immediate Vorbis priority.

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.
Title: OggVorbis Post 1.0.1 CVS
Post by: QuantumKnot on 2004-01-08 23:19:30
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:

Code: [Select]
d:\listeningTests>oggenc2 -b 64 --managed Waiting.flac
Enabling bitrate management engine
Opening with flac module: FLAC file reader
Encoding "Waiting.flac" to
        "Waiting.ogg"
at average bitrate 64 kbps (no min or max),
using full bitrate management engine
       [ 99.1%] [ 0m00s remaining] \

Done encoding file "Waiting.ogg"

       File length:  0m 20.0s
       Elapsed time: 0m 05.0s
       Rate:         4.0310
       Average bitrate: 65.6 kb/s


Case's oggenc output:

Code: [Select]
d:\listeningTests>oggenc3 -b 64 --managed Waiting.flac
Enabling bitrate management engine
Opening with flac module: FLAC file reader
Encoding "Waiting.flac" to
        "Waiting.ogg"
at average bitrate 64 kbps (no min or max),
using full bitrate management engine
       [ 99.1%] [ 0m00s remaining] \

Done encoding file "Waiting.ogg"

       File length:  0m 20.0s
       Elapsed time: 0m 08.0s
       Rate:         2.5194
       Average bitrate: 65.6 kb/s


Playing it in Winamp shows the birate jump from 65 to 66 to 67.  So is Winamp telling fibs and this is true CBR?
Title: OggVorbis Post 1.0.1 CVS
Post by: msmith on 2004-01-09 02:41:10
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.
Title: OggVorbis Post 1.0.1 CVS
Post by: QuantumKnot on 2004-01-09 05:07:14
Thanks for clarifying  I've never used CBR or even ABR before in oggenc so I'm not familiar with all these switches. 
Title: OggVorbis Post 1.0.1 CVS
Post by: tangent on 2004-01-09 08:37:13
I remember Monty mentioning in irc that the bitrate management engine does not take into account Ogg frame overheads
Title: OggVorbis Post 1.0.1 CVS
Post by: john33 on 2004-01-09 09:10:02
Quote
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.

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.