Skip to main content

Topic: .Ogg Vorbis aotuv (Read 327723 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • naylor83
  • [*][*][*]
.Ogg Vorbis aotuv
Reply #525
Aoyumi or anyone else who knows, what are the significant differences between libvorbis 1.3.2 and AoTuV b6.03?
davidnaylor.org

  • alter4
  • [*][*][*]
.Ogg Vorbis aotuv
Reply #526
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
  • [*][*][*]
.Ogg Vorbis aotuv
Reply #527
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.
  • Last Edit: 21 July, 2011, 03:52:38 PM by naylor83
davidnaylor.org

  • IgorC
  • [*][*][*][*][*]
.Ogg Vorbis aotuv
Reply #528
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
  • [*][*]
.Ogg Vorbis aotuv
Reply #529
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
  • [*][*][*][*][*]
.Ogg Vorbis aotuv
Reply #530
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
"Something bothering you, Mister Spock?"

  • AshenTech
  • [*][*]
.Ogg Vorbis aotuv
Reply #531
  • Last Edit: 26 October, 2011, 10:01:31 AM by db1989

  • _m²_
  • [*][*][*]
.Ogg Vorbis aotuv
Reply #532
I don't think it's the same...isn't it a different branch?
  • Last Edit: 26 October, 2011, 10:01:45 AM by db1989

.Ogg Vorbis aotuv
Reply #533
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
MPC --quality 10 --tmn 20 --nmt 20 - %d || WV -miqhnb5x3 - %d

  • alter4
  • [*][*][*]
.Ogg Vorbis aotuv
Reply #534
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
  • [*][*][*]
.Ogg Vorbis aotuv
Reply #535
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
  • [*]
.Ogg Vorbis aotuv
Reply #536
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
  • [*][*][*]
  • Developer
.Ogg Vorbis aotuv
Reply #537
From the change log of libvorbis 1.3.3:

Quote
additional proofing against invalid/malicious streams in decode

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

  • forart.eu
  • [*][*]
.Ogg Vorbis aotuv
Reply #538
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
  • [*][*][*]
.Ogg Vorbis aotuv
Reply #539
From the change log of libvorbis 1.3.3:

Quote
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
  • [*][*]
.Ogg Vorbis aotuv
Reply #540
From the change log of libvorbis 1.3.3:

Quote
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
Sorry for my English.

  • AliceWonder
  • [*][*][*]
.Ogg Vorbis aotuv
Reply #541
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

.Ogg Vorbis aotuv
Reply #542
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
  • [*][*][*][*][*]
  • Developer
.Ogg Vorbis aotuv
Reply #543
Use decimal comma:
Code: [Select]
oggenc2.exe -q 2,5 test.wav

.Ogg Vorbis aotuv
Reply #544
Quote
Use decimal comma

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

  • Porcus
  • [*][*][*][*][*]
.Ogg Vorbis aotuv
Reply #545
Quote
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
  • [*][*][*]
.Ogg Vorbis aotuv
Reply #546
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.
http://forum.gleitz.info - das deutsche doom9/Gleitz-Forum

  • morbit
  • [*]
.Ogg Vorbis aotuv
Reply #547
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
  • [*]
.Ogg Vorbis aotuv
Reply #548
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!

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

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

Quote
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
  • [*]
.Ogg Vorbis aotuv
Reply #549
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.