[Hpr] Opus parameters, and embedded pictures for .opus/.ogg

dg dg at deepgeek.us
Thu May 30 20:17:14 PDT 2013

I'd like to recommend a bitrate of 24000 on .opus, as I've been using
this for my speex feed. Nothing like an hour of audio at 7-9 mb, and
I've had no complaints from those who use speex.  I'd also like to see
somebody volunteer for doing a test of our (now classic) hpr theme
music at this as well 48000 bitrate, preferably by somebody with
younger ears than mine.


On Wed, 15 May 2013 13:46:39 -0400
epicanis+hpr at dogphilosophy.net wrote:

> For a hypothetical opus feed for hpr, I'd suggest a bitrate of 48kbps
> (a little bigger than the speex feed, but should be substantially
> higher quality) for the typical episode. 56kpbs for the occasional
> stereo episode, or 64kbps for "musical" episodes, if any. (The
> default bitrate of 92kbps tends to be as good or better than
> 128k-160k mp3 or 128k Ogg Vorbis, in general).
> Judging by the listening tests, we could probably go all the way down
> to 32kbps and still be quite high quality for speech, but personally
> I think it's worth a few extra bits keep the quality up. (I'm not
> real comfortable overall with the trend I feel like I'm seeing around
> the web lately of treating Ogg Vorbis as the "cheap bandwidth" codec
> rather than the "higher quality" codec - I'd rather not have that
> sort of impression slowing down Opus adoption in the near future.)
> So far I'm seeing some inconsistency in the way feed-readers treat
> multi-enclosure atom feeds. Firefox shows (correctly) all enclosure
> links if you point the browser at the atom feed. Akregator shows only
> the first one. Antennapod only uses the last one (that it recognizes
> as a media file type). I suspect in the long run this won't be an
> issue as more multi-enclosure atom feeds get published and these
> issues get reported as bugs (I already reported the Antennapod bug)
> and fixed, but in the short term it's something to watch for. 
> I've been working on the web-based-encoder project I mentioned in
> HPR#1033 again. One of the holdups for me has been getting "album
> art" working. Embedded images in ogg files (opus/ogg/spx) require a
> specific base64-encoded data structure (and not just base64-encoded
> picture file, nor an id3v2.3 frame). I finally got that working now.
> If anybody but me has a use for it, I've now also built a standalone
> script that takes a jpeg or png image and an optional "picture type"
> parameter (same "picture types" as specified in the id3v2.3 APIC
> frame[1]) and returns a correctly-constructed
> "METADATA_BLOCK_PICTURE=(base64-encoded-structure)" line of text that
> can be inserted directly as a vorbiscomment into ogg vorbis, opus, or
> (I believe) speex file.
> (The script is written such that it can be invoked as a web form or
> just run directly from the command-line. You can also use the web
> version in a shell script using curl to push the image file to the
> script, e.g. 
> opusenc --comment title='Ogg Embedded Art Test' --comment
> artist='Epicanis' --comment `curl -F
> AlbumArt=@/home/epicanis/audioshow/general/hpr/hpr_feed_140px.png -F
> pictype=20 http://hpr.dogphilosophy.net/oggpicture.php`
> AnotherHPRInTheCan.wav AnotherHPRInTheCan.opus )
> If anybody else wants to use the script or wants a copy of it, let me
> know.  The only thing it's currently missing is an option to specify
> the "Picture Description" (also part of the id3v2.3
> APIC/METADATA_BLOCK_PICTURE structure), which I'll add when I get a
> chance.
> [1] http://id3.org/id3v2.3.0#Attached_picture
> _______________________________________________
> Hpr mailing list
> Hpr at hackerpublicradio.org
> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

More information about the Hpr mailing list