.Ogg Vorbis aotuv, Question for Aoyumi Options

[naylor83]

Aoyumi or anyone else who knows, what are the significant differences between libvorbis 1.3.2 and AoTuV b6.03?

[alter4]

Please read what s new from beta 3 to beta 6 (aotuv beta2 ~ libvorbis 1.3.2 in terms of quality)
http://www.geocities.jp/aoyoume/aotuv/
What about technical changes and differences in it - I don't mind.

[naylor83]

Please read what s new from beta 3 to beta 6 (aotuv beta2 ~ libvorbis 1.3.2 in terms of quality)
http://www.geocities.jp/aoyoume/aotuv/

Hm, I'm confused. I've seen that page, but I thought Aoyumi's tweaks have been moved into libvorbis much more recently than beta 3?

Edit: If I read things correctly, aotuv was merged into libvorbis 1.3.2 at b5.7 or b6. Not sure which.

This post has been edited by naylor83: Jul 21 2011, 20:52

[IgorC]

Here is an interesting blind test of 5.7 and 6.0 from one Japanese guy/woman
http://d.hatena.ne.jp/kamedo2/20110409/1302373616

[AshenTech]

was wondering if anybody whos skilled at compiling would be interested/willing to give this compiler a go(its free)

http://developer.amd.com/tools/open64/Page...t.aspx#whatsnew

apparently its x86-32 and x86-64 paths for amd chips are better on both intel and amd then gcc's or ms's (from what i have been reading).

would be interesting to see results of something other then MS/Intel compilers at least

[Destroid]

Would be interesting indeed, possibly something more agnostic than *cough* other compiler(s). Would be willing to try compiles with my old Athlon64.

Here's a shortcut to the current download page: http://www.open64.net/download/open64-4x-releases.html

[AshenTech]

http://developer.amd.com/tools/open64/Page...fault.aspx#four

also can get it there.

This post has been edited by db1989: Oct 26 2011, 15:01

Reason for edit: deleting pointless full quote of last post

[_m²_]

I don't think it's the same...isn't it a different branch?

This post has been edited by db1989: Oct 26 2011, 15:01

Reason for edit: as above

[Didjeridoo]

Hello
Is it possible to make a couple of additional settings oggenc.
I am interested in the integration settings of mpcenc - 1.30
parameters:

== Masking thresholds ======
- quality x set Quality to x
- nmt x set NMT value to x dB
- tmn x ​​set TMN value to x dB
- pns x set PNS value to x dB

[alter4]

I have two question, guys)

The first one to the Aoyumi. What is your plans for the future aotuv version? Could you please clarify?


And the second one to everyone. Is there anybody here informed about libvorbis 1.4.0 development?

[Aoyumi]

Hello
Is it possible to make a couple of additional settings oggenc.
I am interested in the integration settings of mpcenc - 1.30
parameters:

There is not the plan of such an expansion for the moment.
I don't feel the need of the function very much...

I have two question, guys)
The first one to the Aoyumi. What is your plans for the future aotuv version? Could you please clarify?

There is the plan. It is not yet the stage that I can announce.

[morbit]

Hi Aoyumi,

There is new libvorbis release at http://downloads.xiph.org/releases/vorbis/ ,
for now I'm feeling forced t switch to it, as newest aoutv is based on older
releases and there were some security fixes. Nonetheless, thanks for superb
work

[Lear]

From the change log of libvorbis 1.3.3:

additional proofing against invalid/malicious streams in decode

Since aotuv is used for encoding, it should still be safe to use it.

[forart.eu]

There is not the plan of such an expansion for the moment.
I don't feel the need of the function very much...

Agree.

It would be great to have a different downmix to mono procedure (not just L+R).

Stereo Tool's image manipulator-like algorithm would be great, IMHO.

[AliceWonder]

From the change log of libvorbis 1.3.3:

additional proofing against invalid/malicious streams in decode

Since aotuv is used for encoding, it should still be safe to use it.

I'm not sure that is true. Safe to use for encoding, yes, but it probably would be a good idea to apply the patch that fixes the 1.3.2 decode bug to the aoTuV source if you have decoding software that end up using the decoding library provided by aoTuV. If using a binary based on aoTuV for encoding only then probably safe.

I will see if I can find the specific patch because I'm now using aoTuV on my systems having replaced the patched vendor library, thus more than likely re-introducing the vulnerability on my systems.

[rt87]

From the change log of libvorbis 1.3.3:

additional proofing against invalid/malicious streams in decode

Since aotuv is used for encoding, it should still be safe to use it.

I'm not sure that is true. Safe to use for encoding, yes, but it probably would be a good idea to apply the patch that fixes the 1.3.2 decode bug to the aoTuV source if you have decoding software that end up using the decoding library provided by aoTuV. If using a binary based on aoTuV for encoding only then probably safe.

I will see if I can find the specific patch because I'm now using aoTuV on my systems having replaced the patched vendor library, thus more than likely re-introducing the vulnerability on my systems.

So this is the change between 1.3.2 and 1.3.3:
https://trac.xiph.org/changeset?new=18186%4...%2Fvorbis%2Flib

[AliceWonder]

Here is a diff that applies most of them :

http://yum.domblogger.net/dblog/aotuv-b6.0..._1.3.3.diff.txt

It does NOT patch the lib/psy.c file as aoTuV is different there from upstream libvorbis.
I don't think that's where the security issue was anyway.

It also does NOT patch the GENERAL_VENDOR_STRING or ENCODE_VENDOR_STRING - leaves former at 1.3.2 and latter at what aoTuV set it to.

Everything else is applied.

An rpm spec file that builds in RHEL/CentOS 6.x :

http://yum.domblogger.net/dblog/aotuv.spec

[softrunner]

Can someone explain why "oggenc2.exe -q 2.5 test.wav" produces the same result as "oggenc2.exe -q 2.0 test.wav"? In Help it is said "Fractional qualities (e.g. 2.72) are permitted". And foobar2000 also allows to encode into q2.5.

[lvqcl]

Use decimal comma:

CODE

oggenc2.exe -q 2,5 test.wav

[softrunner]

Use decimal comma

Thank you. This is strange that they did it this nonstandart way...

[Porcus]

Use decimal comma

Thank you. This is strange that they did it this nonstandart way...

Comma as decimal separator is actually ISO standard (ISO 31). In fact, it was the only permitted decimal separator under the standard until 2003, when one also decided to permit the point on the line (but not the mid dot of pre-typewriter English).

(Not that I ever cared ... for maths, I would use the full stop whenever I had to make a list (comma-separated), and comma whenever I needed to use the mid dot as multiplication sign.)


Aren't there some applications which carelessly uses the computer locale to pick numbers, and hence screw up big time in scripting?

[LigH]

The german locale uses the comma as decimal separator.

But PCs and their software were founded in Silicon Valley in USA, where the english-based decimal points are usual, so it became the default when ignoring locales.

[morbit]

I wonder if Aoyumi have lost interest in developing of his fork... Last time we have seen him was in 2011.

In any case, he made a tremendous contribution and would like to thank him once more.

I'm waiting for full acknowledgement of importance of his work by inclusion of his latest code in mainline vorbis.

[mamboman]

I wonder if Aoyumi have lost interest in developing of his fork... Last time we have seen him was in 2011. :(

I would like to see aoyumi try his hand at tuning opus!

In any case, he made a tremendous contribution and would like to thank him once more.

Amen to that... aoyumi's work has been magnificent. We have to remember that he has developed aotuv for many years unpaid in his own time as a labour of love and if he now needs or wishes to concentrate his time upon other commitments we must surely understand this and be grateful for what he has done that has given pleasure to many of us around the world.

I'm waiting for full acknowledgement of importance of his work by inclusion of his latest code in mainline vorbis.

This is where I am curious and would be grateful if someone could clarify. My understanding was that the then current aotuv was merged into libvorbis 1.1 in 2004 and that since, although further aotuv merges were on the to do list, Monty was too busy working on other things to be able to do the merges. However, the release notes to libvorbis 1.3.2 state:

vorbisenc: Back out an [old] AoTuV HF weighting that was
first enabled in 1.3.0; there are a few samples where I
really don't like the effect it causes.

So from that it sounds as though aotuv tunings have been getting merged into libvorbis after all (albeit selectively)?

I realise that listening tests have provided strong evidence that aotuv is superior to libvorbis, but the listening tests in question all seem to be from many years ago.
Assuming that aotuv tunings have been getting merged into libvorbis in the succeeding years, as the quote above suggests, would the assertion that aotuv is considerably better than libvorbis still be valid?
Has libvorbis caught up?

Finally, my understanding is that aotuv is tuned predominantly for low bitrates.
As storage space on mobile devices continues to increase, I find myself able to transcode my flac files to vorbis at higher bitrates than I used to.
If I were to encode at a higher bitrate (I am thinking of q 6) would I still be better off using aotuv or would I be better off using libvorbis?
What would folks recommend?

[azaqiel]

This is where I am curious and would be grateful if someone could clarify.

libvorbis SVN r18889 (or r18951, for that matter) does not have aoTuV b6.03. I am in possession of the relevant unified diff of the two trees.

Finally, my understanding is that aotuv is tuned predominantly for low bitrates.

this is true, but tuning lower quality settings (if I understand correctly) changes higher quality settings also.