The situation - since flash doesn't exist in iOS and is going away in Android, I've been tasked with building html5 jukebox.

Biggest issue may be solved by going to CDN in production but it appears to be file size.If the file is too big. sometimes the browser chokes while playing a song.

I'm thinking that aoTuV may also help because it will allow decent quality audio at a lower quality encoding. Say oggenc with q2 or maybe even q1. Hell, even if a CDN solves the problem - using a smaller file size will reduce network costs and so that's a plus anyway.

So I took source rpm for CentOS libvorbis (at version 1.2.3) and modified it to use aoTuV beta6.03 source (which looks like patch to libvorbis 1.3.2)

The major version of the library has not changed, so it appears I can just use the resulting rpm as drop in replacement for stock libvorbis since CentOS oggenc binary is dynamically linked against libvorbisenc.so.2

Am I correct or should I rebuild the vorbis-tools rpm as well?

Is there any test I can do with an encoding to make sure all benefits of the aoTuV patch are in fact realized in the ogg encoding process?

-=-

Finally, kind of related but not really, if the appropriate xiph.org plugins for QuickTime and Windows Media are installed, will Safari and IE9 handle ogg vorbis in html5 audio?

We are planning to provide mp3 encodings as well (currently via lame for testing) but I'm worried about the damn software patents and we can't afford to license them outright, so unless we find a decent licensed encoder we can shell script from *nix, I don't know that we'll even want mp3 as part of the equation, may be better to point users of Safari and IE9 to plugin *if* it adds html5 audio vorbis support. 2017 is still a ways away.