Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: IETF Opus codec now ready for testing (Read 389956 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

IETF Opus codec now ready for testing

Reply #151
So, I didn't follow the development of this codec but I see everyone excited and I have to ask. Why? Is Opus supposed to be the "patent free AAC LC/HE/HEv2" quality as OGG Vorbis was supposed to be the "patent free MP3"?


Opus does that— which is probably most of the excitement here on HA, see also: http://listening-tests.hydrogenaudio.org/igorc/results.html (and also see my spin on those results)— and Opus also has low to very low latency, so it's useful for a whole variety of realtime applications where HE AAC is totally inapplicable, including completely replacing speex.

IETF Opus codec now ready for testing

Reply #152
So, I didn't follow the development of this codec but I see everyone excited and I have to ask. Why? Is Opus supposed to be the "patent free AAC LC/HE/HEv2" quality as OGG Vorbis was supposed to be the "patent free MP3"?


Opus does that— which is probably most of the excitement here on HA, see also: http://listening-tests.hydrogenaudio.org/igorc/results.html (and also see my spin on those results)— and Opus also has low to very low latency, so it's useful for a whole variety of realtime applications where HE AAC is totally inapplicable, including completely replacing speex.

Awesome, I've read everything and this is going to be amazing. Thank you.

IETF Opus codec now ready for testing

Reply #153
From http://tools.ietf.org/html/draft-terriberry-oggopus-01 :

Quote
3.  Else if the hardware's highest available sample rate is less
          than 48 kHz, decode at the highest supported rate above this
          and resample.

I thought it should be "decode at the higher supported rate above this"..?

IETF Opus codec now ready for testing

Reply #154
Opus does that— which is probably most of the excitement here on HA, see also: http://listening-tests.hydrogenaudio.org/igorc/results.html (and also see my spin on those results)— and Opus also has low to very low latency, so it's useful for a whole variety of realtime applications where HE AAC is totally inapplicable, including completely replacing speex.

While I'm really happy to see my name in link to that test I'm in favour of that next public tests will be descentralized and transparent as much as possible and won't contain a name of responsable person. This is why it should be  another person next time. Last time the members Steve Forte Rio and /mnt have helped to prepare random process of sample selection (doh, don't mention what Garf has lived to teach me to conduct and helped with the test.) I can organize discussion, prepare packages etc.  The organizator(s) should only work with listeners.

IETF Opus codec now ready for testing

Reply #155
Where could I get a win32 (or win64) build of the last Opus version?
🇺🇦 Glory to Ukraine!

IETF Opus codec now ready for testing

Reply #156
Post #121 of this thread, is where I got mine.
Dynamic – the artist formerly known as DickD



IETF Opus codec now ready for testing

Reply #159
I noticed a few things about the behaviour in playing with opustools (exclusively in --music mode, i.e CELT-derived operation, using Win32 binaries from opus-tools_exp_1a50ad0b.zip, an experimental encoder).

These are not critical listening tests yet. I used the stereo CD format sample provided by Gainless in post #122

I used a commandline with most things left to default (i.e. 20ms frames, vbr on, no expected packet loss), such as:
opusenc.exe --music --bitrate 48 afterburn.wav test_m048.opus

First, I observed that pushing it to extremes, setting --bitrate 4 and --bitrate 5 produced bit-identical output at about 5.7 kbps actual bitrate. This accords with the low limit being 6 kbps but is nice behaviour for an encoder to do its best when given a non-permitted bitrate.

Effective bandwidth
An apparent lowpass effect seemed to jump in steps with different target bitrate settings. I didn't test to every transition point. This might be to do with the modified bark bands used to transmit coarse band energy information, and where it's worthwhile activating a new band, so may not be a true lowpass. I played back on fb2k v1.1.14 beta 1 with OPUS support built in - thanks Peter - and lowered my preamp for non-ReplayGained material to ensure no clipping or limiting (I could have used the volume control, but already had RG pre-amp set). I resample to 48000 Hz to compare the 44.1kHz source with the 48 kHz OPUS decode on a level playing-field.

for --bitrate settings 5, 6, 8, 10, 12 effective lowpass was about 4kHz (typical AM radio audio bandwidth)

for --bitrate setting 16 it lifted to about 6 kHz (hi-hats really became distinct from the noise)

for --bitrate settings 24, 28, 32, 38, 40, 44, 46, 47, and 47.999 it was about 12 kHz (quite reasonable brightness, fairly crisp hi-hats - similar to standard audio cassette bandwidth - would sound good enough for musical intros and 'stings' in many talk-oriented podcasts, though the beauty of OPUS is seamless switching, so podcasters & radio producers could insert interstitials at higher settings and even use speech mode when it suits them)

for --bitrate setting 48 and on up to 512 kbps there was content to around 20 kHz - i.e. well above the lowpass I can detect in music. The source WAV had minuscule content at 21kHz too, which OPUS didn't output.

Packet loss simulation
The decoder can simulate packet loss.

I took the file test_m048.opus which I'd created using this commandline:

opusenc.exe --music --bitrate 48 afterburn.wav test_m048.opus

i.e. without indicating an expected packet loss to the encoder - the normal setting for local playback on a PC or player.

The decoder with simulated packet loss reported an error at 0.2% packet loss and above but still produced a WAV (with a beep/blip in it at 0.2% and 146 samples@44.1kHz shorter in duration).

But at 0.1% simulated packet loss, it produced no error message and produced a pretty nice sounding output WAV. Presumably if the encoder is told to expect n% packet loss (--expect-loss n), it will be more resilient at the expense of quality of perfect playback compared to the default setting at the same bitrate. I may need to test that, but I'll probably get the latest build first.

It may be that I was lucky with 0.1% packet loss, but given 1501 packets used for this sample, there should be about 15 packets dropped at random on average, so I suspect there must be a little resilience built in even when no extra is requested from the encoder.

I might try various expected loss scenarios later and see how they compare. Could be useful to try out marginal radio links to see how gracefully quality would tail off. In many applications, I'd imagine that a warning indicator or tone could indicate packet loss has started, yet OPUS wouldn't suddenly drop out, which could be useful for real-time applications, such as radio microphones and digital radio broadcast receivers.

For future digital radio, it might be rather useful to have packet-loss or packet-corruption resilience of this sort. I guess ideally it could be coupled with the physical layer, to broadcast a basic low-bitrate stream over a highly-error-corrected longer-range multiplex for areas of weak reception, with a more bandwidth-efficient but less resilient scheme packing in either a higher-bitrate alternative stream (or if bitrate peeling is possible, a difference stream) to provide high quality for those near the transmitter or with high-grade rooftop aerials further afield.

Simulated packet loss Command Prompt window:
Code: [Select]
C:\Users\Public\Music\Test>"C:\Program Files\opus\opusdec.exe" --packet-loss 0.1
test_m048.opus test_m048_pl00_1.wav
Decoding 44100 Hz audio (2 channels)
Encoded with libopus 0.9.11-119-g1a50ad0-exp_analysis
ENCODER=opusenc from opus-tools 0.1.2-7-g1f30973


C:\Users\Public\Music\Test>"C:\Program Files\opus\opusdec.exe" --packet-loss 0.5
test_m048.opus test_m048_pl00_5.wav
Decoding 44100 Hz audio (2 channels)
Encoded with libopus 0.9.11-119-g1a50ad0-exp_analysis
ENCODER=opusenc from opus-tools 0.1.2-7-g1f30973

Error playing audio.

C:\Users\Public\Music\Test>"C:\Program Files\opus\opusdec.exe" --packet-loss 0.2
test_m048.opus test_m048_pl00_2.wav
Decoding 44100 Hz audio (2 channels)
Encoded with libopus 0.9.11-119-g1a50ad0-exp_analysis
ENCODER=opusenc from opus-tools 0.1.2-7-g1f30973

Error playing audio.

C:\Users\Public\Music\Test>
Dynamic – the artist formerly known as DickD

IETF Opus codec now ready for testing

Reply #160
Why don't it push down bitrate to zero for silenced moments? Actually VBR mode is absolutely not flexible (+/- 10 kbps). Seems like this vbr is not true vbr :\

Also: why does it encode all files with  48000 Hz samplerate?
🇺🇦 Glory to Ukraine!


IETF Opus codec now ready for testing

Reply #162
Opus does that— which is probably most of the excitement here on HA, see also: http://listening-tests.hydrogenaudio.org/igorc/results.html (and also see my spin on those results)— and Opus also has low to very low latency, so it's useful for a whole variety of realtime applications where HE AAC is totally inapplicable, including completely replacing speex.

While I'm really happy to see my name in link to that test I'm in favour of that next public tests will be descentralized and transparent as much as possible and won't contain a name of responsable person. This is why it should be  another person next time. Last time the members Steve Forte Rio and /mnt have helped to prepare random process of sample selection (doh, don't mention what Garf has lived to teach me to conduct and helped with the test.) I can organize discussion, prepare packages etc.  The organizator(s) should only work with listeners.


It would be interesting to know what the requirements for the inclusion of a specific sample into a listening test are. Does it have to be some kind of "killer" sample or representative for a certain music genre?

IETF Opus codec now ready for testing

Reply #163
The file in post #121 is the experimental encoder. It should deliver much higher quality, on average, though it's less well tested. Feedback is still very much appreciated.

Here is the sample where experimental encoder fails at --bitrate 64: [attachment=7058:test01.mp3]

IETF Opus codec now ready for testing

Reply #164
Dynamic:
0.1% of 1501 is 1.501, not 15.01 as you said, so your “luck” is not as good as you might have thought.
Interesting write-up, though!

IETF Opus codec now ready for testing

Reply #165
Quote
Now is really the time to get support into applications (well, this was also true for some time, but doubly so now). If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

I really hope to see Opus decoder in the following version of Rockbox.

Getting a usable decoder in rockbox will probably be a fair amount of work, and right now no one is working on it, so I think it'll be a little longer then that.  But hopefully we'll have it eventually.

I hope for that too, considering the listening tests. And, searching for "Opus" on Rockbox website, it seems the project is at least more or less aware of the new codec...

BTW, promising quality is clear enough, but how to interpret its performance goals in the context of offline playback on a portable audio player? What can be roughly expected, relative to other low-bitrate codecs supported by Rockbox?

IETF Opus codec now ready for testing

Reply #166
Why don't it push down bitrate to zero for silenced moments?


It does, on digital silence. On non-digital "silence" (very quiet but not all zeros) it doesn't know if perhaps the decoder side will be turning the volume up to compensate for the low gain. Outputting silence frames in that case would destroy the quality.

Quote
Actually VBR mode is absolutely not flexible (+/- 10 kbps). Seems like this vbr is not true vbr :\


You're looking at overall files. VBR uses significantly more bits on transient frames, but on the span of a whole file it doesn't matter much.

The EXP encoder significantly increases the VBRness of VBR, with rate modifications depending on more than just transients.

Quote
Also: why does it encode all files with  48000 Hz samplerate?


Opus doesn't really have a "sampling rate" (unless you want to count the 16Hz,25,50,100,200,400Hz frame rates ) there are several rates which can be most efficiently encoded or decoded from which are all integer relative to 48000— 8000,12000,16000,24000, and 48000, so those are what the libopus library exposes. The rates of the encoder and decoder are independent and don't change the bitstream (except presumably a 8kHz encoder wouldn't be encoding sound at 20kHz)— this eliminates rate incompatibilities, rate negotiation, makes smaller decoder (lower memory footprint) implementations possible, etc.  But it does mean that rates like 44.1kHz need to be reached by resampling. Considering how much audio hw out there sounds like crud at 44.1kHz this is probably just as well.

.Opus files store the original rate, so that file tools can avoid surprising users with decoded files that change rate. The _exact_ file durations are also preserved for all rates 48k and below including 44.1k.

IETF Opus codec now ready for testing

Reply #167
BTW, promising quality is clear enough, but how to interpret its performance goals in the context of offline playback on a portable audio player? What can be roughly expected, relative to other low-bitrate codecs supported by Rockbox?


I'm not sure.  From what I've seen its a fairly unique codec, so I'm not sure what to compare it to. My guess is that initially it will be fairly slow since I don't see much ARM optimization in the source, but people will work on it and speed things up.  FLAC was the same way, it used to be very slow.  Now we can decode it in about 10 Mhz worth of CPU on lots of targets.

IETF Opus codec now ready for testing

Reply #168
I noticed a few things about the behaviour in playing with opustools (exclusively in --music mode, i.e CELT-derived operation, using Win32 binaries from opus-tools_exp_1a50ad0b.zip, an experimental encoder).

Great.

FWIW  --music does _not_ mean "use CELT". It shifts the bitrates at which it will use CELT a bit lower... but at low enough rates you're better off with the LP modes even for music.
Quote
First, I observed that pushing it to extremes, setting --bitrate 4 and --bitrate 5 produced bit-identical output at about 5.7 kbps actual bitrate. This accords with the low limit being 6 kbps but is nice behaviour for an encoder to do its best when given a non-permitted bitrate.

CBR will actually obey your requests, though you'll end up getting silence if you go too low.
Quote
But at 0.1% simulated packet loss, it produced no error message and produced a pretty nice sounding output WAV. Presumably if the encoder is told to expect n% packet loss (--expect-loss n), it will be more resilient at the expense of quality of perfect playback compared to the default setting at the same bitrate. I may need to test that, but I'll probably get the latest build first.

The decoder has loss concealment, and it works pretty well. You an get pretty intelligible audio with fairly high random loss rates. A main application for Opus is realtime e.g. RTP usage, so the loss concealment is pretty important there. Though the simulation of it is a bit odd in opusdec and I probably ought to improve that.

You actually triggered a bug in opus-tools causing the "Error playing audio." on Win32, on files with certain durations when decoding to a file (rather than audio output), which I just fixed. Thanks for the testing.

IETF Opus codec now ready for testing

Reply #169
The file in post #121 is the experimental encoder. It should deliver much higher quality, on average, though it's less well tested. Feedback is still very much appreciated.

Here is the sample where experimental encoder fails at --bitrate 64: [attachment=7058:test01.mp3]


Good find, thanks.

IETF Opus codec now ready for testing

Reply #170
Opus seems to have problems at certain points of time when encoding with 64 kbit/s + framesize 60. I've had 2 samples with obvious bugs at 2:00 that disappeared when I cut these moments out in Audacity and encoded it again. Is that behaviour normal/expected?

IETF Opus codec now ready for testing

Reply #171
Opus seems to have problems at certain points of time when encoding with 64 kbit/s + framesize 60. I've had 2 samples with obvious bugs at 2:00 that disappeared when I cut these moments out in Audacity and encoded it again. Is that behaviour normal/expected?


Details please.  What version of the software are you using? Can you post test inputs and command-lines (and the .opus output would be nice too).  There was a bug in old opus-tools that would cause something like that, but I'm not aware of anything currently.

IETF Opus codec now ready for testing

Reply #172
Actually VBR mode is absolutely not flexible (+/- 10 kbps). Seems like this vbr is not true vbr :\

Opus experimental build  VBR 96 kbps, 243 files:
min 61 kbps
max 157 kbps
average 92 kbps.





IETF Opus codec now ready for testing

Reply #173
I'm finally testing it!

If I try encoding at 2kbps, VBR or CBR, at anything other than 20ms packets (I tested 10ms and 60ms), the encoder fails. And more than that, it reports a successful encode, with crazy speed like that:

Code: [Select]
F:\Test\Opus\opus-tools_exp_1a50ad0b\opus-tools>opusenc --hard-cbr --bitrate 2
--framesize 60 t1.wav t1-cbr-2kbps-60ms.opus
Encoding using libopus 0.9.11-119-g1a50ad0-exp_analysis (audio)
-----------------------------------------------------
   Input: 48kHz 2 channels
  Output: 2 channels (2 coupled)
          60ms packets, 2kbit/sec CBR
Preskip: 312

Encoding complete
-----------------------------------------------------
    Encoded: 29 minutes and 4.8 seconds
    Runtime: 0.6471 seconds
             (2696x real-time)
      Wrote: 107430 bytes, 29080 packets, 1820 pages
    Bitrate: 0.133333kbit/s (without overhead)
Rate range: 0.133333kbit/s to 0.133333kbit/s
             (1 to 1 bytes per packet)
   Overhead: 72.9% (container+metadata)

At 3kbps things already run fine with with all modes that I tested.

BTW, how do I know if Opus is using the Silk or Celt mode for encoding? I don't see this info in the opusenc or opusinfo. It would be good to know, especially if it overrides your choice. I don't want to memorize a table with the heuristics/allowed combinations (even thought I may end up memorizing it).

It seems that the minimum bitrate supported is indeed 6~7kbps. Even at this bitrate the voices are still very clear, and the music gets interesting analog-like noise/artifacts (better than metallic sound of most codecs close to their limits). 60ms packets are better overall at those bitrates.  But if I try to force it under that with --hard-cbr it falls completely apart... That means I can't put 50 minutes of audio in a floppy, like AAC and speex could (well, AAC was also a train-wreck at 2~3kbps, but still better than opus)...

One less way I can show off opus, but don't really impact in practical uses.   

IETF Opus codec now ready for testing

Reply #174
Now that Opus was approved by the IETF, will it also appear on RareWares? -- poking john33