I remember getting the link for oggenc.exe daily compiled binaries somewhere, it is this:

http://www.din.or.jp/~glit/TheOddStage/Pro.../autobuild.html

I would like to ask what these binaries exactly are? Are they something like continuously updating LAME 3.90 alpha builds or something completely different?

It seems that the oggenc.exe file provided by that site is 1/8th size of the official rc2 oggenc.exe. And it only seems to encode 128 kb/s files regardless of -b setting.

Is this whole site just for "128kb/s tweaking" or what?

Best wishes,
niktheblak

They are appearently built from the latest Vorbis CVS sources.

[b]In theory, the main CVS sources should always be identical to the latest release, save perhaps some minor bugfixes. So there's not much use to doing daily Vorbis builds.

It's only due to an accident that some experimental code got into the main CVS tree.

That experimental code only has an 128kbps mode implemented (which is why it's so small), as well as some improvements but also a load of bugs.

I don't think that anyone is actually tweaking Vorbis besides me and Monty.

--
GCP

Thanks for the info, Garf!

So understood correctly, using daily compiled binaries of OGG (unlike LAME's) isn't worthwhile. Error was on my side, I thought they would be comparable to latest LAME alphas, in which always using the latest build is recommended!

niktheblak

Currently it may be worthwhile to give the experimental version a try, but if it breaks you get to keep the pieces

Generally, experimental versions of Vorbis aren't published until it's certain everything works as expected. Even then, they go into branches of the CVS tree, not the head trunk.

--
GCP

:confused:

I know that there is a lot of other work going on besides tweaking for best sound quality, but I thought that a larger part of the Vorbis-developers were involved in something as crucial as this.

Don't get me wrong, I'm not suggesting that Monty and you, Garf, isn't up to the job - - it just strikes me as odd.

Is it because Monty prefers it this way?

Regards stoff

It's not actually that unusual to develop open source software this way -- basically because there are only a couple of people who fully understand the deep magic of the encoding part of the code. Once the (mythical version 1 is out, I imagine we'll see a lot of people put effort into looking at the code and the algorithms, and the development will become more widespread.

At that point, it's also possible to document the encoder setup for other people that want to do timing. If I would do so right now, I'd have to start all over again with each new release candidate.

--
GCP

I in fact have given the latest binaries a try and ended up with some strange results. I have this one clip (metal, don't be scared!) which I have been using for encoder testing quite a bit.

Now what's weird is that on this clip the latest CVS build of oggenc.exe with -b 128 gives MUCH better results than rc2 oggenc.exe with -b 160!

Given that the only "artifacts" I'm able to hear are FhG 128kb/s flanging and distortion and loss of over 16kHz frequencies due too low bit rate, this is really worth a look.

With the rc2 oggenc.exe and -b 160 the hi-hats and cymbals are horribly distorted. Using -b 192 or -b 256 fixes the problem completely.

But the latest CVS build oggenc.exe sounds nearly transparent to me at 128kb/s with much less distortion! Give the rc2 encoder a push and you see that ABX isn't really necessary here.

I do realize that too low bitrate causes distortion no matter how good the encoder is, but when 128kb/s is sounding better than 160kb/s there's probably something to examine.

LPAC-archived clip is at this address if you are willing to give it a try;

http://www.hytti.uku.fi/~tnkorhon/Tristania-test.pac

Cheers,
niktheblak

Not that surprising. Some of the experimental changes that accidentally made it in were:

a) Stereo hiss fixes
b) Lowpass moved up to 20kHz
c) New noise masking

(a) and (b) don't matter if you are using near 192-256kbps, but for lower rates it will be an improvement
© is considered unstable...sometimes it might do wonders, but it may goof up too

I personally wouldn't use it right now...not with RC3 being ' real soon now'

My tuned version tackles (a) and © but in a less efficient way.

--
GCP

Well, if some "experimental code" version of rc3, averaging 126kb/s, yields superior output over 177kb/s rc2-encoder, then rc3 is definetely something to wait for

niktheblak

I have another sample that I'm intimately famaliar with and I'm able to ABX the difference between --r3mix and --dm-preset standard quite easily.

http://www.h0neyshammock.com/Hermeticum.pac

It's a few second clip from Daemonarch - Corpus Hermeticum.

You might want to give this a try, it's a real killer sample.

Have you tried using Garf's tuned RC2 build? It's ~160kbps output will usually beat out the standard ~160kbps and ~192kbps modes that RC2 provides.

Edit: Garf, are you planning to released a new VBR mode for RC3 when it's released? I'd be interested in seeing what you can do with it.

How soon is real soon?

I'll use this "daily binarie" anyway. I need to squeeze some 10 hours of sound on a single CDR. I need to do it 'til wednesday.
So I'll just trust that it sounds ok.

I will NOT use mp3! 'Cos I want to turn as much friends as possible to the OGG way.

new version :

http://www.hogera.com/dee/oggenc_auto/oggenc20011007.zip

happy testing , it really sounds decent at 128 kbps

It does sound OK for 128kbps!

Thanx

Note: i didn't say perfect

not perfect, but very good.

OK, 128 Kb is standard mid-range.
I really want see how OGG plays at 40 Kb / 32 Khz, mono.
The procedure i used:
1. Decoding from MP3 at 24 bit (winamp 2.77+MAD 0.13b)
2. Processed with Batch Converter:
- DC remove
- Chan conv. (Stereo to mono)
- Normalization
- Resampling
- Bit depth conv.
3. Encoded with Monkey's 3.92 beta 2
4. Converted directly from APE by "Peter Pawlowski's Ogg Vorbis encoder plug-in v1.31 (uses libvorbis v1.0 RC2)"
5. Played by winamp (+ Ogg Vorbis plug-in v1.16)

Well it does't sound so bad... but i think is too "humming".
Does anyone plan to optimize OGG for thoose low-bitrates ??

Bzzzzt. You lose.

Never ever transcode, especially if you will be making a judgement about quality afterwards.



That's what is being done continously.

--
GCP

I finally got time to try out the 'rc 2 and a third' that's in CVS at the moment -- and I'm impressed. The cymbals & other high pitched noises that RC2 really had trouble with sound *much* better now (would that be because of the 20kHz rather than 16kHz limit, or the better noise masking?). It also sounds better when there is a lot going on musically than RC2... still not transparent though . Cymbals seem a touch over-emphasised when compared to the original, although I've not had a chance to ABX (and don't want to until the actual RC3 is out).

Damn these music boards... since I've started listening to my music more carefully I've started noticing problems in music files that previously I would just have listened to . 160kpbs was fine for me with LAME, so I suppose I'll be using 160kpbs with Vorbis as well.

More likely noise masking than the higher lowpass.

Could depend on your hearing of course.

--
GCP

I'll see what I can do. Depends also on how much time I have.

Who knows RC3 might be so good it doesn't need tuned modes

--
GCP

hi garf
why do you publish a document about OGG standard?
so we can be familliar to the codec more.
thanks.