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