Audiophiles: aoTuV and Slackware
 

I am not sure if anybody will be interested but those audiophiles who are keen on the best ogg files might be interested in the small modifications to the stock 13.37 slackbuild and large patch for libvorbis 1.3.2 and aoTuV beta 6.03 that I have placed here:

http://www.andrews-corner.org/slackb...bvorbis_aoTuV/

Obviously this replaces the slackware libvorbus package so just be aware of that! Works well against the git FFmpeg and vlc and I have had no problems with other media applications although I would be very interested to hear of any issues.

Upstream vorbis already includes most of the aoTuV changes. aoTuV is better at low bitrate encodes, little to no difference at higher bitrates.
http://wiki.xiph.org/Vorbis_Encoders

Wouldnt audiophiles have moved on to a lossless codec years ago?

I am hoping that at least a few people find this useful :)

I sure did :)
Even though I did not say so in my first post, I find aoTuV's enhancements great for low bit rate encodings. I tend to use these lower bitrates for my media player. Allows me to stuff 2x the songs on the smallish 1GiB storage.

Though for my personal music collection, I use flac for backup and archival, then oggvorbis at q7. I find it difficult to hear a difference between q7 and flac on most recordings. At q5, I find differences often. Perhaps my low quality speakers, sound card, or ears (:)) aid in the detection.

For those that don't know what aoTuV is http://wiki.hydrogenaudio.org/index.php?title=AoTuV

Thanks! I'm trying this out right now and will post back if I have issues.

Finally organised myself to redo the patch + slackbuild for Slackware 14 (-current) and libvorbis 1.3.3. Seems to be working well enough on my system, good if somebody else can test it as well?

http://www.andrews-corner.org/slackb...bvorbis_aoTuV/

A bit more controversial as the aoTuV work was designed against 1.3.2 and 1.3.3 has a few bugfixes....

And updated again for libvorbis 1.3.5 and Slackware 14.2 Beta 2 :)

Also from Xiph, opus is superior, i assume.

I suspect that Opus has a slightly different target audio (streaming music, speech as well as general usage) as well as massively less market penetration that Ogg Vorbis. But I would be the first to agree that there are simply too many audio codecs around...

Ogg may be still more wide spreaded, but i won't stick to it, as opus is better(for my ears) also for cd-archiving than ogg. Every recent Android-Phone/Tablet has opus-support, all vids on youtube(webm) have an opus-audiotrack ...

Thing that concerns me about Opus is the lack of 44,100Hz (CD-Audio) samplerate support without resampling to 48kHz. Resampling is usually very bad for quality. Whether that matters as much in what is admittedly a lossy format is worth consideration.

I've just built and installed opus/opusfile/opus-tools packages, so I might do some experimenting.


BTW, only 500K of packages, BSD licensed and trivial to build. Is it worth adding them to stock Slackware?

If i get this discussion right, there is no drawback with the samplerate.

I would like that. To have real benefit from it, progs like audacious/mplayer/xine would need to be compiled against a libopus-enabled ffmpeg. For some reason, ffmpeg is not shipped as separately package.

Have a read of the 'sox' manpage, specifically the bit about the 'rate' effect and resampling, note the stuff about pre/post-echo. In short, you can't convert a 44,100Hz sample to 48000Hz without introducing artifacts. But as I said, its a lossy format anyway, so you're going to get artifacts anyway, and for sources that are already at 48K such as DVD resampling isn't going to be needed anyway.

Another interesting consideration which the Xiph guys mention on their faq is that some hardware isn't very good at doing 44,100hz anyway and so you may get better results at your earbuds with 48000.


As for ffmpeg, I suspect Pat doesn't include it because of patent issues. He'd have to disable so much stuff that you wouldn't want to use it in that state anyway. Better to leave people to build it themselves and choose which codecs they want it to support.

P.S. I've only tried listening to opus on some crappy earbuds plugged into an even crappier AC97 based motherboard that picks up all manner of system noises, so its not an ideal platform from which to form an opinion, but what I have heard seemed at least "reasonable", especially at lower bit rates.

There is no quality-loss because of resampling in opus, in the xiph mailinglist link above is statet This is not the same as upsampling and downsampling again.

Most soundcards i know are only capable doing 48hz, not 44,100hz. But that's not of interrest for a encoder.

ffmpeg without patents-issues/less features is shipped already embedded in Mplayer/Xine.
With the same configure-options, ffmpeg could also be shipped as singel package.
I asked about it here

Yes, but then anyone who wanted to build their own ffmpeg with additional options would end up having to rebuild all the stuff that links with it (the ffmpeg api/abi has a habit of changing frequently). I use ffmpeg and mpv, and I'm glad I can add those to my system without breaking other parts that I would have to rebuild if a system level ffmpeg library were used.

This is only the case if another ffmpeg-version is used, you could stick with that ffmpeg that would come as stock package, adding options without further player-recompilation. If you really need a bleeding edge ffmpeg, than you'll have to recompile your player against ffmpeg anyway to be able to playback the files.

MPlayer/Xine could break, of what interest are these if one uses mpv?
If Mplayer/Xine are really wanted with the limited ffmpeg(thats the current case), you could build them statically with ffmpeg. I think most people would be happier with adding codecs to alle players using a stock ffmpeg.

Maybe there are multiple users on the system that prefer to use different players, or perhaps the choice is dependent on the media being played: Xine is still better at DVD menu's than the others, which is what I use it for.

Yes, I could rebuild everything impacted if necessary. I was merely pointing out that the static/in-tree builds simply mean that I don't have to (admittedly at the cost of them becoming 'stale' over time).

On my flash-drive with Alien's Live-Slak (the latest Plasma), this is what I got when trying to build it...

@ftio Hmmm.... can't reproduce this. I have altered the slackbuild a little to avoid picking up the wrong archive in the build folder but this should have no bearing on what is happening on your system...

rename the folder where you are building from without spaces.

That was the ticket! Thank you, ponce!

Giving this old thread a boot with an updated version, this time with aotuv and lancer:

http://www.andrews-corner.org/slackb..._aotuv_lancer/

Remember that this replaces the stock libvorbis that comes with -current. Test run here demonstrates typically:

And with both a nice sound and a fast encode....