I'm looking for suggested features to get into opus-tools prior to the libopus 1.1 release.

Before I get 1001 suggestions for it: One frequently requested feature which was recently added is flac input in opusenc. I'm contemplating changing opusdec to use the new opusfile library— which would give it seeking and integrated http(s) streaming support. Also already on my todo list are default comment packet padding so updating metadata doesn't require rewriting the files and adding a replaygain tool.

Some people would really like it if opusenc/opusdec supported taking multiple input files e.g. opusenc *.flac but the implicit output file naming is pretty ununixy, and would break the interface and I got flamed all to heck last time I changed the opusenc interface.... so I'm not sure if/how I want to accommodate that usage.

Can't really think of anything atm except maybe a quality based switch for lazy people, it's not hard to implement and I can't see the harm in doing so.

Easiest way is just to allow "quality" as the equivalent to the existing "bitrate," so you could then specify, for example, quality=64. If that doesn't solve your problem, it's because you don't accept that vbr is quality based.

Currently opusenc requires the output filename and doesn't have short options. I'd like to type

CODE

opusenc -b 96 filename.wav

instead of current:

CODE

opusenc --bitrate 96 filename.wav filename.opus

+1. In general, Opus and Vorbis encoders having the same interface as much as is reasonable would be nice.

QUOTE (DonP @ Jan 23 2013, 13:14)

QUOTE (Seren @ Jan 23 2013, 06:04)

Can't really think of anything atm except maybe a quality based switch for lazy people, it's not hard to implement and I can't see the harm in doing so.

Easiest way is just to allow "quality" as the equivalent to the existing "bitrate," so you could then specify, for example, quality=64. If that doesn't solve your problem, it's because you don't accept that vbr is quality based.

Well, it doesn't look to me that it's quality based. For me, "quality based" would mean that the minimum quality setting giving a transparent encode is more or less the same for all files. That doesn't seem to be the case with Opus.

Well, it doesn't look to me that it's quality based. For me, "quality based" would mean that the minimum quality setting giving a transparent encode is more or less the same for all files. That doesn't seem to be the case with Opus.

That can only be true with a "perfect" lossy encoder— it's not true for any existing one. If you're aware of bit discrepancies in libopus 1.1a they'd be interesting to know about.

In any case, VBR mode is a quality mode. The quality scale is bitrate indexed against some arbitrary large diverse collection, so the quality value scale has ~some~ meaning instead of being completely meaningless as it is for Vorbis.

Well, it doesn't look to me that it's quality based. For me, "quality based" would mean that the minimum quality setting giving a transparent encode is more or less the same for all files. That doesn't seem to be the case with Opus.

That can only be true with a "perfect" lossy encoder— it's not true for any existing one. If you're aware of bit discrepancies in libopus 1.1a they'd be interesting to know about.

Where do I report these?

QUOTE (NullC @ Jan 23 2013, 21:31)

In any case, VBR mode is a quality mode. The quality scale is bitrate indexed against some arbitrary large diverse collection, so the quality value scale has ~some~ meaning instead of being completely meaningless as it is for Vorbis.

Is that related to first part of your post? I never objected to the idea of using average bitrate on some collection as a quality measure.