Bug 10564 - Bitrate limiting should use Ogg Vorbis
: Bitrate limiting should use Ogg Vorbis
Status: RESOLVED WONTFIX
Product: Logitech Media Server
Classification: Unclassified
Component: Transcoding
: unspecified
: All All
: -- enhancement (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-06 17:13 UTC by Keith Briscoe
Modified: 2011-01-17 11:41 UTC (History)
0 users

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Keith Briscoe 2009-01-06 17:13:19 UTC
I think it's safe to say that Ogg Vorbis sounds as good or better than MP3, especially at low bitrates (I can provide links to many public listening tests if needed).  As I understand it, the only requirements for the bitrate limiting format are that it must be capable of extremely low bitrates, supported in firmware, and an encoder must be freely available and redistributable on many platforms.  Wouldn't it be more suitable for bitrate limiting to use oggenc rather than LAME?

Technical issues:

1) Ogg is inherently VBR, but you can cap bitrates with the --max-bitrate=x encoding parameter.  For example, to limit to 192k, you could use oggenc -q6 --max-bitrate=192, although there may be some benefit in choosing a different -q value.

2) Ogg may be more resource-intensive for encoding.  Testing would need to be done on NAS devices to ensure it would work as well as LAME.

3) Ogg may not have native decoders on older hardware.  This may be a showstopper for this entire idea.

4) Ogg has no definitive encoder (no different than MP3 on this regard).  Just as LAME is reputedly better than Frauenhofer, aoTuV is reputedly better than Xiph.org (particularly at low bitrates).
Comment 1 Keith Briscoe 2009-01-28 08:59:22 UTC
Comments to bug#4418 indicate that native Ogg decoding won't work at less than 64K (-q0), so that'd be the absolute floor.
Comment 2 Keith Briscoe 2009-01-28 19:43:04 UTC
Looks like the standard transcoding framework is pretty format-agnostic, but there are some format-specific things that need to be passed to the encoder.  I'll call these "vorbisargs" in the symbolic non-Perl code below:

if bitrate<=128 { vorbisquality=bitrate/16-4 }
else if bitrate<=256 { vorbisquality=bitrate/32 }
else vorbisquality=9 /* we could go higher but 320 seems quite high enough */

if vorbisquality<2 { vorbisargs="-q%vorbisquality% --max-bitrate=%bitrate%" }
else { vorbisargs="-q%vorbisquality% --max-bitrate=%bitrate% --advanced-encode-option lowpass_frequency=16.5" }

The quality level can be more-or-less derived from the bitrate.  Above, I'm just doing a very uneducated mapping of max bitrates to nominal/average bitrates.  There's a possibility that a lower or higher Q level may sound better, but I honestly don't know enough to say, and it probably varies based on the sample.

Low-bitrate Vorbis encoding has improved a lot over the years (thanks Aoyumi!), but the original default lowpass filters have stayed the same.  Thus, for extremely low bitrates (under 96K), in my opinion the default lowpass filters are now much more annoying than the compression artifacts.  So given the choice I'd personally set 16.5 as the lowest possible lowpass filter.
Comment 3 Keith Briscoe 2009-01-28 19:45:08 UTC
Err switch that code around:

if vorbisquality<2 { vorbisargs="-q%vorbisquality% --max-bitrate=%bitrate% --advanced-encode-option lowpass_frequency=16.5" }
else { vorbisargs="-q%vorbisquality% --max-bitrate=%bitrate%" }

The manual lowpass setting should be for LOW quality encoding...
Comment 4 Keith Briscoe 2011-01-17 11:41:00 UTC
bug#16242 was marked WONTFIX, making this feature request unworkable