What features would you like to see in opus-tools? Options

[NullC]

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.

What other things have you found missing?

[skamp]

What I'd like:

• an equivalent to vorbiscomment, with the ability to add, remove, replace tags, from the command line or from a text file
• an equivalent to vorbisgain, with the ability to compute and display track gains individually, and the ability to store an arbitrary album gain in the headers of .opus files (so-called "playback gain" as reported by opusinfo). I have a vested interest in this, with caudec's replaygain scanner, which currently cannot support Opus as no tools are yet available.

Slightly off-topic: I'd also like to know the meaning of the R128_TRACK_GAIN field and how it relates to a dB gain value.

[CoRoNe]

Perhaps totally off-topic, but could you lend the Matroska-Opus devs a hand?! Being able to put an Opus-stream into a Matroska container is really what I'm looking forward to.

[Seren]

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.

Perhaps totally off-topic, but could you lend the Matroska-Opus devs a hand?! Being able to put an Opus-stream into a Matroska container is really what I'm looking forward to.

2012-12-31 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Added experimental support for the Opus
audio codec. Parts of an implementation of #779.

[mamboman]

Yes, converting flac to opus will be a very common use case so support for that would be terrific.

Important in relation to this I believe is to be able to preserve all tag info.

One problem with oggenc was that it did not preserve embedded album art (see link below).

http://superuser.com/questions/169151/embe...d-line-in-linux

However, some folks may not want to have album art embedded in their opus files for space saving reasons or whatever, so i suggest there might be a command line switch to prevent album art embedded in flac files from being embedded in the opus files if so desired.

[nu774]

Slightly off-topic: I'd also like to know the meaning of the R128_TRACK_GAIN field and how it relates to a dB gain value.

If I remember correctly, it was something like the following:

CODE

replaygain_album_gain = OpusHead.output_gain / 256.0 + 5.0
replaygain_track_gain = R128_TRACK_GAIN / 256.0 + replaygain_album_gain

[DonP]

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.

[nu774]

If I remember correctly, it was something like the following:

CODE

replaygain_album_gain = OpusHead.output_gain / 256.0 + 5.0
replaygain_track_gain = R128_TRACK_GAIN / 256.0 + replaygain_album_gain

Maybe I should explain more...
OpusHead.output_gain and R128_TRACK_GAIN are 16bit signed integer, but actually are Q7.8 fixed point decimal values. So you have to divide by 256.0 to obtain actual value.
As for R128_TRACK_GAIN, opusinfo prints raw (integer) value.
On the other hand, "Playback gain" shown by opusinfo is already divided, and is equals to OpusHead.output_gain / 256.0.
5.0 offset in the equation above is due to difference of normalize level between replaygain and R128.

[lvqcl]

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

[.alexander.]

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

Do you accept feature request for codec itself? I would love to have fixed point version providing the same encoding quality as floating point (now fixed point is certainly worse - tested on SAQM recordings at 6-12 kbps). Also I would love to have complexities 11-20 as everything below complexity 8 seem to cause shorter call duration compared to ISAC.

[gottkaiser]

...converting flac to opus ... would be terrific...
...preserve all tag info...
...preserve embedded album art...

second that

[Banned]

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.

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.

[DonP]

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.

I don't think any of the encoders using ie q0-5 (vorbis) or V5-0 (lame) have that perfectly nailed either. Look at the public listening tests and you will generally see that both the transparency of a given encoder and the relative ranking of encoders varies with the test sample.

[NullC]

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.

[Dynamic]

I think there was a time when VBR quality scales tended to be tuned for transparency only at one specific, 'standard' setting and often didn't have much of a variable quality scale above and below that, although they often offered extreme or insane settings too.

I guess historically, that was LAME --alt-preset standard (now -V2) and Musepack standard (aka q 5) where the respective psymodels were extensively tuned.

There's maybe some idea that Vorbis -q5 is sort of equivalent and that neroaacenc at 0.5 might be in the same ballpark, but both formats have toolkits that greatly help in obscuring artifacts without the sudden degradation in quality at lower bitrates. Even LAME now does very nicely at -V4 (formerly medium) and -V5 despite having fewer tools to hide artifacts of encode with great-efficiency than more modern codecs.

In many ways the typical generalised graphs that show a sort of rising quality reaching some sort of 'knee' before rolling over to a fairly flat region of diminishing gains with bitrate are a reasonable picture, and I suspect that the special low-bitrate tricks like Contrained Energy per critical band (very well implemented in Opus/CELT, fairly well in Vorbis) and PNS and SBR have reduced the rate of deterioration 'below the knee' in the most modern music codecs so that artifacts and stereo changes can be discerned but are rarely annoying (though for AAC+v2, I find 32kbps stereo high end pretty annoying and much prefer Opus at 32)

SPEECH/MUSIC mixes
I would say that a difference arises in Opus (and to some extent other codecs) depending on whether one is encoding speech or music. Speech seems to be remarkably good at much lower quality settings and much lower audio bandwidths than music, which offer more codec-killing sounds, more stereo separation and more high frequency content than speech. I'd guess that certain VBR codecs would dip their bitrate during speech faster than opus does, albeit from a higher starting point - often LAME -V5 would dip a lot just thanks to the monophonic content of most speech, as it does with a lot of vintage material that's mono or hard-panned stereo. I'd guess that Opus's efficiency in low-rate stereo encoding wouldn't allow so much of a dip because it's better in the first place.

In Opus I can imagine that if I were after highly acceptable speech coupled with very good sounding stereo music for, say, a podcast, my optimum might be around 24 to 32 kbps for the speech segments and around 64 kbps for the music, or 80 to 96 for really rather good music reproduction for music enthusiasts. Then again, for normal podcasts with only incidental music, 32kbps produces nice sounding music (quite like cassette tape without the hiss) and great speech, and from about 48 kbps things really start to sound fairly good with music - superficially very nice, having full bandwidth and stereo and no egregious artifacts like warbling or splashy applause that codecs like RealAudio used to produce.

I could see some advantage in a future switch for podcasts and audiobooks (or a mode built into a podcast/radio-show creation program) that automatically switches between quite a high bitrate target for stingers and music sections (32, 48, 64, 80, 96, 128 say) and a much lower bitrate target for speech sections (16, 20, 24, 32, say). Essentially, that mode is telling Opus that quality preservation isn't the main aim so long as speech is fairly good and music pretty nice, and that bitrate economy is more important. The easiest solution (if we wish to optimize more than using 32 kbps) is to put it in a podcast editor, of course, which can be told which clips are music or can have these clips ready-encoded to Opus at the optimum bitrate target (e.g. theme music and stingers) and can simply take advantage of the seamless switching of any Opus decoder.

Many talk podcasts I listen to now, would be awesome at a steady 32kbps target like now. Some could save costly hosting bandwidth by using 16/32 mix (and being talk would barely average over 16) or plain 16 or 24 target with theme music carefully selected so as not to sound awful (try transcoding the Windows 7 sample tune "C:\Users\Public\Music\Sample Music\Sleep Away.mp3" to 32 kbps or less to hear awful, with the brused snares especially in SILK mode, whereas "Ninja Tuna.mp3" and "Maid With The Flaxen Hair.mp3" in the same folder transcode to sound OK at 32kbps - all with libopus 1.0.2, that is).

[saratoga]

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

Do you accept feature request for codec itself? I would love to have fixed point version providing the same encoding quality as floating point (now fixed point is certainly worse - tested on SAQM recordings at 6-12 kbps).

Thats probably not realistic. Or at least an enormous amount of work.

[.alexander.]

Thats probably not realistic. Or at least an enormous amount of work.

That may be, but fixed point research required for this should be much easier than designing a codec.

This post has been edited by .alexander.: Jan 24 2013, 00:12

[jmvalin]

Do you accept feature request for codec itself? I would love to have fixed point version providing the same encoding quality as floating point (now fixed point is certainly worse - tested on SAQM recordings at 6-12 kbps). Also I would love to have complexities 11-20 as everything below complexity 8 seem to cause shorter call duration compared to ISAC.

What's your concern with the fixed-point code. As of 1.0.2, we've never observed much of a quality difference between float and fixed-point. In 1.1-alpha, there's a new feature that's float-only, but the fixed-point should still be at least as good (if not better) than 1.0.2.

[azaqiel]

I would like an opus gain tool that ONLY TAGS the R128 value(s). tagging instead of altering the actual audio is what I'm referring to. I would also like a command-line tagging tool.

as far as going from lossless to Opus, I use WavPack, but I'm not going to request WavPack input because I use foobar2000 anyway.

[LithosZA]

A maximum bandwidth setting. In libopus the bandwidth seems to lower automatically when I lower the bitrate, but it seems to be different with opusenc?

If these are possible otherwise please ignore:
- Intensity Stereo threshold setting; tweaking it for low bitrates.
- Force CELT/SILK/Hybrid setting.

[IgorC]

Intensity stereo (IS) setting as all other phsycoacoustic settigns shouldn't be visible for user imo. LAME was a good example of that. Remember q0, k settings mess? Those are dangerous to play with.

P.S. You still can try it for testing purpose.

This post has been edited by IgorC: Jan 26 2013, 13:42

[bat_guano]

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

Hi
In my other thread here ---> other thread
I have problems with dumped opus files.
There's something wrong with the timestamps (or whatever).

Could a tool be included to re-mux opus files and clean up these errors?


Perhaps this might utilize opusinfo, which seems to give accurate information.

CODE

timeout 30 \
mplayer -nocache -dumpstream -dumpfile SmoothJazz3.opus \
"http://radioserver1.delfa.net/64.opus"

See below, opusinfo shows correct duration, bitrates etc but mediainfo is confused.

@ubuntu:~$ opusinfo SmoothJazz3.opus
Processing file "SmoothJazz3.opus"...

New logical stream (#1, serial: 1aca3133): type opus
Encoded with libopus 1.0.2
User comments section follows...
ENCODER=scripts
TITLE=Eyes Down
TRACKNUMBER=7
TRACKTOTAL=9
GENRE=Smooth Jazz
DATE=2010
COMMENT=From RAW PCM to opus
ARTIST=Shilts
ALBUM=Going Underground
WARNING: sequence number gap in stream 1. Got page 36 when expecting page 2. Indicates missing data. (normal for live streams)
WARNING: discontinuity in stream (1)
WARNING: EOS not set on stream 1 (normal for live streams)
Opus stream 1:
Pre-skip: 356
Playback gain: 0 dB
Channels: 2
Original sample rate: 44100Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 1000.0ms (avg), 1000.0ms (min)
Total data length: 269093 bytes (overhead: 1.05%)
Playback length: 0m:32.992s
Average bitrate: 65.25 kb/s, w/o overhead: 64.56 kb/s

@ubuntu:~$ mediainfo SmoothJazz3.opus
General
Complete name : SmoothJazz3.opus
Format : OGG
File size : 263 KiB
Duration : 1mn 7s
Overall bit rate : 32.1 Kbps
Album : Going Underground
Track name : Eyes Down
Track name/Position : 7
Track name/Total : 9
Performer : Shilts
Genre : Smooth Jazz
Recorded date : 2010
Writing application : scripts
Comment : From RAW PCM to opus

Audio
ID : 449458483 (0x1ACA3133)
Format : Opus
Duration : 1mn 7s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Writing library : libopus 1.0.2

This post has been edited by bat_guano: Jan 26 2013, 19:08

[nu774]

Bitrate might be surely enough when one is working only with constant (say, redbook) format.
However, if bitrate is the only way for quality contorl and when one is working with varying formats, one will have to take several parameters (such as # of channels, channel coupling, input sampling rate) into account, and manually scale bitrate by hand to obtain desired quality.
Therefore, I think quality scale would be useful.

[Dynamic]

I think QAAC's TVBR settings are roughly half the stereo bitrate in kbps, essentially amounting to bitrate-per-channel.

If people get accustomed to Opus quality in stereo mode (but maybe mono for speech) maybe a stereo-equivalent bitrate switch would suffice for surround (amounting to constant quality regardless of channel count).

[Banned]

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?

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.