Are there any news about current ogg vorbis development? Does anyone know when there is going to be next release? Will there be any improvement on high bitrate handling? And one more question : should I use official release or should I go with aoTuV beta 3 (I am interested only in encoding at q6) ?

this thread gives you the recommend version and whatnot. i dont know anything about vorbis' future plans or release dates or anything. sorry

http://www.hydrogenaudio.org/forums/index....showtopic=15049

Progress from Xiph.org can be described as very slow to non-existant, though I've heard Monty is twiddling with Vorbis (and complained about the broken builds ). Aoyumi is probably working on aoTuV and we should hear from him soon. I haven't heard much from nyaochi, though he is probably in a similar situation to yours truly, and can't find the time.

Currently, vorbis 1.1 is the recommended build since it was based on aoTuV beta 2, which has been rigorously tested. aoTuV beta 3 may have some better pre-echo handling code so I guess the best way is to do some listening tests, comparing the two and let your ears make the decision.

What broken builds? Like, the ones at RareWares?

I guess that, if it's the case, Xiph can be 100% blamed for it. They should be the ones providing official builds, and not leave vorbis.com at that pathetic state of abandon!

They mean broken build processes. They need people who can update their win32 build procedures.

edit: If I'm not mistaken, that is.

Ah, I see. Thanks for clarifying.

But my rant about vorbis.com being abandonated remains valid :B

Yep, there was some talk about that at the most recent Xiph monthly meeting too. They're going to revamp their websites with new logos.

Yes, to be sure, although development of my aoTuV is slow, it is progressing.

According to web of nyaochi, he is busy. .
It seems that Monty is doing basic research of VorbisII.

I am also waiting for QK's new encoder.

M..m.. I used vorbis since 2001. Now seems vorbis is yield to pressure AAC codecs.
But I don't want betray open and free audio technology.
It strange for me vorbis development is so slow....
May be people is not need free audio?

Good luck! (and sorry if bad english )

I wait for 2 years for XIPH but now very disappointted. How can they did so bad to their projects? Seems no one take care of these projects because they're FREE?

If they want money, please ask for donation, I don't mind to pay 50 or 100 dollar to speed up the projects. To battle the evil commercial army. This is an important CASTLE that we can't fall.

They've had a donate page on the website for a loooong time.
You could also target what your money is spent on by putting it towards a bounty.

About Vorbis Development....

when is Vorbis going to let us choose the desired stereo mode?
or at least, someone hack the Vorbis code?
at -q 4, vorbis has stereo problem

http://www.hydrogenaudio.org/forums/index....ype=post&id=700

stereo problem at mid bitrate is not acceptable,
I've tried it with Nero AAC, no stereo problem at all

I donate them some $$$ already (of course not 100, because I want to see some result before paying a lot of $$$).

But I feel disappointed, if they don't have some 'Public Relation' work I'll hold my cash. I'm not rich so I want to use the money wisely.

Purely theoretical: If someone would register a domain, claim it being the official site for vorbis development, and then some people actually developing it..... i wonder if anyone would care when xiph would complain.

They've done some nice stuff in the previous 2 years - vorbis was not among it.

- Lyx

Don't worry, that is on my to-do list when I'm free from March onwards. Can you describe what sort of stereo problem you are hearing with the sample? Reduced stereo separation?

Actually, some guy that was very much into Xiph had this idea.

We discussed this over AIM for some time, but then he decided his own stuff had higher priority in his life.

I tested this 1-2 months ago, I'll try to describe it....

NOTHING WRONG with low frequencies, only high frequencies

there is a part of the song which the "tone" should sweep from LEFT to RIGHT
Vorbis seem to change it a bit, from LEFT to CENTRE

note = there is nothing wrong at -q 5 ( I cannot ABX it), the problem occurs only at -q 4 and below

For bleeding-edge folk, I see that an unofficial very-experimental post-b3 aotuv version has been posted at http://www.geocities.jp/aoyoume/comp_co/index.html (link in 01/03/2004 section). As far as I can gather, it's .exe-only and it's only optimized for -q-1 and -q-2 (though I can't hear the difference from aotuvb3, though my ears aren't very good).

This sample encoder is the version which mainly changed stereo processing.
Probably this changed part will be efficiently employed with the following experiment version.

I released the now new experiment version (aoTuV experiment [20050225]).

This includes an important change of channel coupling. Therefore, it becomes the release as a test version.
As a result of your using this version, please tell me, if a problem peculiar to this version is found.

http://www.geocities.jp/aoyoume/aotuv/test.html

EDIT:URL TYPO

Cool, thanks alot

does channel coupling also work for multichannel?

No, multi channel is not still supported. The code which I added is also premised on processing by 2ch stereo.

I tested oggenc.exe [20050225 aoTuV experiment] with this sample: Originalsmall.flac from here

ABX results:

oggenc -q5: ( 8/8 ) Very easy to ABX

oggenc -q6: ( 8/8 ) Very easy to ABX again..

I grasp about the phenomenon.
It is a problem common to all the present Vorbis encoders.

With this version, a problem of this sort will not be solved, though regrettable.

(I found a serious bug in the first binary I posted here so here is the corrected version)

Time is finally on my side, or at least enough to try out some ideas I've had for fixing the block switching deficiencies of Vorbis 1.1 on microattack samples.

Here is a win32 binary of QKTune Experimental [20050227]:
http://rarewares.org/quantumknot/oggenc-qktune20050227.exe
http://steve8988.homestead.com/files/vorbi...une20050227.zip

For linux:
http://rarewares.org/quantumknot/oggenc-qktune20050227.gz

Features include:

- based on Vorbis 1.1 (no ITP)
- New temporal-based block switching algorithm that assists (not replace) the current Vorbis one (so it can't do any worse than vanilla Vorbis 1.1, I hope)

I've tested this on the Originalsmall.flac (provided by rotellian) and Bloch_Formule.wv (provided by guruboolez) and it seems to reduce the smearing encountered on both samples at q 4. Please test this on other samples (esp. those with microattacks) and tell me if something breaks, bitrates fluctuate unusually, etc. The main focus of this experimental version is for microattacks only and hopefully the bitrate fluctuations in other sections of music are minimised.

Note that the new block switching algorithm has slowed down the encoding somewhat but I'll address that soon.

I will provide a linux binary soon (as soon as a sort out these build problems in vorbis-tools ). Also since this is work-in-progress (I've got some more ideas to implement that address coarse rendering and stereo), I'll release the sources when everything is cleaned up and finalised.

Thank you,

QK.

EDIT: Added static linux binary and second link to win32 binary
EDIT2: Added observation of slower encoding

QuantumKnot: It's not possible for me download your binary

hmm.....I just tested the link and it seems to work. Do you have problems access rarewares.org?

not that I know... I am going to reinitiate my PC.

Download link works for me.

If it still doesn't work, try the 2nd link.

The link works now . The problem was my PC.

I tested oggenc-qktune20050227.exe -q6: transparent for me [Originalsmall.flac]

Thank you for the test. I'm also interested in the performance at lower q's, so if you have time, a test of q 4 and 5 would be great

oggenc-qktune20050227.exe -q4: ( 8/8 ) [Originalsmall.flac]; a little smearing.. but a lot better than 1.1RC1

Quantum Knot: I tried both samples with oggenc-qktune20050227.exe -q3 and it seems to me main problems disappeared here:

Bloch_Formule.wv - no block switching problem anymore

Originalsmall.flac - I can't hear this noisy artifact (even with equalizer on in high frequencies). It seems to me there are also some block switching tunings, because there are short blocks here from the very biginning of the sample, not like when encoded with AoTuv b3.

No time to ABX, but in fact I don't no what to ABX.
Great!

Anyway I'v got a question: Foobar info displays this:
vorbis_vendor = Xiph.Org libVorbis I 20040920 (QKTune Experimental [20050227])
Does it mean no orher tunings except these "block switching" ones were made?

Thanks for your work

Yes, nothing from Vorbis 1.1 was touched except for the addition of the new block switching algorithm.

QuantumKnot, is this version the long-waited wavelet-aided block switching one?

No, this is not wavelet-based but it seems to do what I originally intended the wavelet-based one to do quite well.

I've found some special samples (low-pass tonal samples) where the block switching algorithm is choosing short-blocks and the bitrate become excessives, but I've managed to fix this problem and will release it shortly. However, Block_Formule is the only sample where it fails, so I need to work out how. It is a very strange sample

Without eleborating to much and getting thrown off track can you even use wavelet's in transform domain via block switching, etc? Everytime I see wavelet papers here and there they are always associate with subband coding . I don't know that much about wavelet's (nor advanced signal processing for that matter) except for the fact that their scale and translation properties make them mathmatically ellogant for transients in general, but their basis function's just aren't suited for stationary signals. Math people love talking about these things from a theoretical standpoint and engineer's want to apply them to real world.

To be frank, wavelets weren't as impressive as I had expected them to be, unlike in image coding. For images, wavelets are quite effective at detecting and separating out the edge information from the smooth regions. But audio is not as smooth as images. I was testing wavelet packets, where I performed multiple dyadic decompositions with the scaling functions to smooth out the audio and then decomposed the result using the wavelets. For the Originalsmall.flac and castanets sample, it picked out the transients perfectly. But I needed do a LOT of dyadic decompositions and the short block size of Vorbis (128) was simply not enough.



Certainly for tonal content, MDCT is the best, while wavelets have advantage with short and sharp transients.

Anyway, I'm happy with my current method of dealing with the switch blocking problem for now. I wasn't planning on using wavelets just because it was 'trendy' to do so.

Really good news since my last post!
Thanks a lot for all!!!!!
But this news bring me some reflection
Now vorbis development is really disunite.
Some people made some fine :-) encoder changes... this is all
But nobody rule and mix the tweaks and changes.


With respect alter4.

QKTune Experimental [20050228]

Changes:

- Fixed excessive high bitrates on low freq. tonals such as this one
- Slightly lower bitrate fluctuations (thanks to above fix)
- Slightly faster encoding (yay!!)

Issues:

- Due to the low freq. tonal fix, block switching on the sample Bloch_Formule is now broken. I still have no idea why this sample is so strange.


Here is the win32 binary:

http://rarewares.org/quantumknot/oggenc-qktune20050228.exe


And a static linux binary:

http://rarewares.org/quantumknot/oggenc-qktune20050228.gz


Any feedback would be much appreciated

QK

I tried it with some samples of general music and generated-waveforms rather than known 'problem' samples. It didn't do anything terrible to bitrate (usually much less than 1% increase over oggenc-1.1, at most around 2%) but didn't seem noticably better on these non-problem samples either (note: not ABX'd).

Good stuff QK, really solves the problem. I can still ABX it at Q5 (didnt try above this) but not due to the problem. Tried it at q4 and q3 quickly and again huge improvement over previous encoders of this generation. Nice one (but is 228 better than 227 if it doesnt handle Bloch_Formule ?)

I tried ABX Originalsmall.flac against oggenc-qktune20050228.exe -q3.



Wasn't able to hear any differences in the beginning, definitely not these noisy artifacts. Then I started to differ the samples somehow, but very hard to say where's the difference... Bitrate is slightly smaller 131 against 137 with oggenc-qktune20050228.exe -q3

I tried to encode some other samples and "excessive high bitrates on low freqencies" disapeared (jazz music sample with deep bass).

I hope it helps

It is regrettable, but the compromise is acceptable, I think. Either we fix the problem with one sample (Bloch_Formule) and have excessive bitrates on others (227) or break one sample and have normal operation in others (228). I suspect the problem is deeper than just a block switching one for this sample. *shrugs*

Many thanks to the above posters for the feedback

New Aoyumi experimental Ogg Vorbis encoder
http://www.geocities.jp/aoyoume/aotuv/test.html

I still see [20050225] on top, and this was already mentioned ?

Opps, i misred this thread
sorry,
May be i will edit my post...