include aoTuV patch

Bug #57797 reported by Oibaf on 2006-08-26
86
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Medibuntu
Undecided
Unassigned
vorbis
Confirmed
Unknown
libvorbis (Debian)
Fix Released
Unknown
libvorbis (Ubuntu)
Wishlist
Sebastian Dröge
Nominated for Lucid by Ryan

Bug Description

Would be nice to include aoTuV [1] Release 1 patch to libvorbis. aoTuV is an improved libvorbis encoder, that, while keeping ABI compatibility, gives many improvement:
* better quality at all bitrates versus libvorbis-1.1.2 [2], giving aoTuV better quality than other codec (AAC, MP3, MPC, WMA, ...) [3];
* support of quality down to -2 (32kb/s at 44kHz stereo), versus -1 (45kb/s at 44kHz stereo) of libvorbis-1.1.x;
* encoding speed 10% better thanks to the included Vorbis-OptSort patch (improve ordering loop);

aoTuV Release 1 have just been releases. aoTuV Release 1 is the same as of beta4.51 (released on 2005-11), renamed after a lot of testing of the audio community (especially on hydrogenaudio forum [4]) and this is the reccomended vorbis encoder [5].

[1] aoTuV site: http://www.geocities.jp/aoyoume/aotuv/
[2] comparison of aoTuV beta 4 vs libvorbis-1.1.x: http://wiki.xiph.org/index.php/VorbisEncoders
[3] Wikipedia test of vorbis vs other codecs: http://en.wikipedia.org/wiki/Vorbis#Codec_comparisons
[4] hydrogenaudio forum: http://www.hydrogenaudio.org
[5] Recommended Ogg Vorbis: http://wiki.hydrogenaudio.org/index.php?title=Recommended_Ogg_Vorbis

Igor Goldenberg (igold) wrote :

Yes, it will be very good to have aoTuV version of vorbis library in Ubuntu. As Ogg Vorbis in Linux world is the main lossy audio codec - having best version of it by default in Ubuntu will give great motive to use this brilliant open source and patent free format. It's completely in the spirit of Ubuntu.
Vote for inclusion!

Sebastian Dröge (slomo) wrote :

Thanks, I'll take care of this... but will talk to upstream about it first.

Changed in libvorbis:
assignee: nobody → slomo
status: Unconfirmed → Confirmed
Sebastian Dröge (slomo) wrote :

Upstream is aware of this patchset and wants to merge it at some point. We will wait until then because we can't do as extensive tests as necessary to really guarantee complete compatibility and no quality regressions.

Igor Goldenberg (igold) wrote :

Well, will wait merging by upstream. Thank you for the info.

Changed in libvorbis:
importance: Undecided → Wishlist
Artem Popov (artfwo) wrote :

Just tried building the latest Hardy libvorbis with aoTuV patch, builds and runs very nice in fact :) Here's the debdiff against Debian/Hardy package, and the binaries may be found in my PPA:

https://launchpad.net/~artfwo/+archive

Chris Clonch (cacack) wrote :

Seems like this one has gone stagnat for a while. Any plans (upstream or otherwise) to move to the aoTUV patched releases?

bmhm (bmhm) wrote :

I'd like to give this bug another chance. Артём Попов did a build of aotuv.

Changed in medibuntu:
status: New → Invalid
Anzenketh (anzenketh) wrote :

Added Debian Upstream.

@Anzenketh: As said a few times in this report, they want to wait for upstream to actually merge it. Which is perfectly understandable if upstream will ever actually merge it.

Sebastian Dröge may have been under the impression that this merger was going to be forthcoming (as of the end of 2006), but it's 2010 now and I see no sign of upstream imminently planning to fix this.

Usptreams only releases since 2004 have been the addition of minor bug patches, fixing of a security issue (Also fixed in AoTuv), etc.

Perhaps someone can convince upstream to go ahead with the merge? I don't like the idea of forks anymore than anybody and forks are often a sign that it's easier to not work with upstream than it is to wait on them to drag themselves forward which I feel is what has happened here.

I should also point out that the last time upstream merged the AoTuv fork was AoTuv beta 2, to produce Xiph.org libvorbis 1.1, this was back in 2004.

AoTuv beta 5.7, released March of 2009 is now the current release, with maybe a new one on the way too. (test builds anyway)

How long is it reasonable to wait on upstream? Also I'm not sure mine is a duplicate of this. Right now I'd be asking to include AoTuv beta 5.7.

Can this bug be renamed?

summary: - Should include aoTuV Release 1 patch
+ include aoTuV patch
Changed in libvorbis (Debian):
status: Unknown → Confirmed
Changed in libvorbis (Debian):
status: Confirmed → Fix Released
Thucydides411 (gregreen) wrote :

Why hasn't this bug been addressed yet? I'd hate to have to log into windows just to be able to use the best lossy open source audio codec. Debian has had 9 years to address this problem, and hasn't. Ubuntu should just go ahead on its own.

hdante (hdante) wrote :

1) reporting a bug in Ubuntu is like trying to have a serious conversation with /dev/null
2) Xiph vorbis encoder merged AoTuV tunings
3) the best lossy open source audio codec is opus: http://xiph.org/press/2012/rfc-6716/

Changed in vorbis:
status: Unknown → Confirmed
Russian redneck (otaku-8) wrote :

> 2) Xiph vorbis encoder merged AoTuV tunings
(X)ubuntu 13.10, still an issue]
> 3) the best lossy open source audio codec is opus
Not many devices support Opus; and however aoTuV has better quality/bitrate factor

Thucydides411 (gregreen) wrote :

hdante, just a few comments/questions:

> 2) Xiph vorbis encoder merged AoTuV tunings

What version of the AoTuV tunings have been merged into the Xiph encoder? The version of oggenc that ships with Ubuntu can't go down to 32 kb/s, which is a sign that it's using the old, unpatched reference encoder, rather than the AoTuV tunings.

> 3) the best lossy open source audio codec is opus: http://xiph.org/press/2012/rfc-6716/

Opus and Vorbis have different uses. Opus is superior in certain applications, like streaming over a variable-bitrate channel in the presence of substantial packet loss, and VOIP with low latency. But Vorbis with AoTuV tunings has far superior sound quality for music, especially at low bitrates, than the reference Opus encoder, and has better support on a range of devices. The fact that Opus is better for some applications shouldn't prevent Ubuntu from shipping with the best free/open source encoder available.

Oibaf (oibaf) wrote :

Vorbis merged an old version of aotuv, latest aotuv is not in vorbis however.

Also, according to listening tests, opus is known to be better than vorbis in every tested scenario, see:
http://jmspeex.livejournal.com/13547.html

bmhm (bmhm) wrote :

Please do not discuss OPUS. Most hw players have no opus support, thus it is not an option.

Also, we will not drop kino because cinallera is better.

Make existing software as good as possible, as long as it has its purpose. Vorbis definitely has one.

Please merge the current patch sets.

Oibaf (oibaf) wrote :

I think the best approach here is to discuss and do this upstream. Feel free to do a petition or whatever. No known distribution add aotuv as an added patch to libvorbis. If properly merged upstream every distribution will then get aotuv in standard libvorbis.

Unless someone is really motivated on merging aotuv in Ubuntu libvorbis this 8+ years old request could be closed.

hdante (hdante) wrote :

I use Arch Linux now. Arch has libvorbis 1.3.4, libvorbis-aotuv b6.03 and opus 1.1.

Bye,

Thucydides411 (gregreen) wrote :

> Also, according to listening tests, opus is known to be better than vorbis in every tested scenario, see: http://jmspeex.livejournal.com/13547.html

I can say from the experience of ABX testing classical music at low bitrates, 32 kb/s to 64 kb/s, that there's basically no comparison between AoTuV and Opus, in that AoTuV performs vastly better. That can be important for devices with limited storage, like smartphones. I know Xiph consistently claims Opus to be superior, but I've had a very different experience with the music I've tested, and in any case, this isn't a question of Opus vs. AoTuV. This is a question of the latest AoTuV vs. an old version, and we know which is better.

I understand that getting the patch applied upstream would be preferred, but realistically, that's not going to happen. This has been a known issue in Debian for years, and nothing has been done about it. It's a simple enough patch to apply that I would say Ubuntu should just go ahead and do it.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.