IPB

Welcome Guest ( Log In | Register )

23 Pages V  « < 5 6 7 8 9 > »   
Closed TopicStart new topic
IETF Opus codec now ready for testing, That's CELT 0.11
mdefranc
post Jul 16 2012, 21:42
Post #151





Group: Members (Donating)
Posts: 49
Joined: 15-October 01
From: Midwest
Member No.: 295



Why is "everyone excited"? Because http://listening-tests.hydrogenaudio.org/igorc/results.html
Go to the top of the page
+Quote Post
NullC
post Jul 16 2012, 21:54
Post #152





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (eahm @ Jul 16 2012, 12:32) *
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.

This post has been edited by NullC: Jul 16 2012, 21:58
Go to the top of the page
+Quote Post
eahm
post Jul 16 2012, 22:09
Post #153





Group: Members
Posts: 1085
Joined: 11-February 12
Member No.: 97076



QUOTE (NullC @ Jul 16 2012, 13:54) *
QUOTE (eahm @ Jul 16 2012, 12:32) *
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.


--------------------
/lwAsIimz
Go to the top of the page
+Quote Post
lvqcl
post Jul 17 2012, 00:00
Post #154





Group: Developer
Posts: 3385
Joined: 2-December 07
Member No.: 49183



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"..?

This post has been edited by lvqcl: Jul 17 2012, 15:45
Go to the top of the page
+Quote Post
IgorC
post Jul 17 2012, 04:36
Post #155





Group: Members
Posts: 1576
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (NullC @ Jul 16 2012, 17:54) *
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.

This post has been edited by IgorC: Jul 17 2012, 04:37
Go to the top of the page
+Quote Post
Steve Forte Rio
post Jul 17 2012, 07:20
Post #156





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



Where could I get a win32 (or win64) build of the last Opus version?

This post has been edited by Steve Forte Rio: Jul 17 2012, 07:25
Go to the top of the page
+Quote Post
Dynamic
post Jul 17 2012, 09:43
Post #157





Group: Members
Posts: 821
Joined: 17-September 06
Member No.: 35307



Post #121 of this thread, is where I got mine.
Go to the top of the page
+Quote Post
adamjk
post Jul 17 2012, 11:18
Post #158





Group: Members
Posts: 113
Joined: 30-September 01
Member No.: 116



Or even newer from http://opus-codec.org/downloads/
Go to the top of the page
+Quote Post
NullC
post Jul 17 2012, 13:15
Post #159





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (adamjk @ Jul 17 2012, 03:18) *


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.

This post has been edited by NullC: Jul 17 2012, 13:24
Go to the top of the page
+Quote Post
Dynamic
post Jul 17 2012, 14:32
Post #160





Group: Members
Posts: 821
Joined: 17-September 06
Member No.: 35307



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
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
Go to the top of the page
+Quote Post
Steve Forte Rio
post Jul 17 2012, 15:40
Post #161





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



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?

This post has been edited by Steve Forte Rio: Jul 17 2012, 15:47
Go to the top of the page
+Quote Post
IgorC
post Jul 17 2012, 16:03
Post #162





Group: Members
Posts: 1576
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



I have tried this https://people.xiph.org/~greg/opus-tools_exp.zip and it goes down to 1 kbps on silence.
Go to the top of the page
+Quote Post
Gainless
post Jul 17 2012, 16:27
Post #163





Group: Members
Posts: 173
Joined: 28-October 11
Member No.: 94764



QUOTE (IgorC @ Jul 17 2012, 05:36) *
QUOTE (NullC @ Jul 16 2012, 17:54) *
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?

This post has been edited by Gainless: Jul 17 2012, 16:27
Go to the top of the page
+Quote Post
lvqcl
post Jul 17 2012, 16:29
Post #164





Group: Developer
Posts: 3385
Joined: 2-December 07
Member No.: 49183



QUOTE (NullC @ Jul 17 2012, 16:15) *
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]
Go to the top of the page
+Quote Post
db1989
post Jul 17 2012, 16:43
Post #165





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



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. tongue.gif
Interesting write-up, though!

This post has been edited by db1989: Jul 17 2012, 16:45
Go to the top of the page
+Quote Post
zima
post Jul 17 2012, 17:00
Post #166





Group: Members
Posts: 136
Joined: 3-July 03
From: Pomerania
Member No.: 7541



QUOTE (saratoga @ Jul 14 2012, 22:23) *
QUOTE (Clifoo @ Jul 14 2012, 10:08) *
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?

This post has been edited by zima: Jul 17 2012, 17:00


--------------------
http://last.fm/user/zima
Go to the top of the page
+Quote Post
NullC
post Jul 17 2012, 19:28
Post #167





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (Steve Forte Rio @ Jul 17 2012, 07:40) *
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 smile.gif) 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.

This post has been edited by NullC: Jul 17 2012, 19:50
Go to the top of the page
+Quote Post
saratoga
post Jul 17 2012, 19:34
Post #168





Group: Members
Posts: 4972
Joined: 2-September 02
Member No.: 3264



QUOTE (zima @ Jul 17 2012, 12:00) *
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.
Go to the top of the page
+Quote Post
NullC
post Jul 17 2012, 19:43
Post #169





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (Dynamic @ Jul 17 2012, 06:32) *
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.

This post has been edited by NullC: Jul 17 2012, 19:45
Go to the top of the page
+Quote Post
Garf
post Jul 17 2012, 20:21
Post #170


Server Admin


Group: Admin
Posts: 4885
Joined: 24-September 01
Member No.: 13



QUOTE (lvqcl @ Jul 17 2012, 17:29) *
QUOTE (NullC @ Jul 17 2012, 16:15) *
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.
Go to the top of the page
+Quote Post
Gainless
post Jul 17 2012, 20:40
Post #171





Group: Members
Posts: 173
Joined: 28-October 11
Member No.: 94764



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?
Go to the top of the page
+Quote Post
NullC
post Jul 17 2012, 20:59
Post #172





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (Gainless @ Jul 17 2012, 12:40) *
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.
Go to the top of the page
+Quote Post
IgorC
post Jul 18 2012, 01:24
Post #173





Group: Members
Posts: 1576
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (Steve Forte Rio @ Jul 17 2012, 11:40) *
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.




Go to the top of the page
+Quote Post
Caroliano
post Jul 18 2012, 06:22
Post #174





Group: Members
Posts: 67
Joined: 21-December 05
Member No.: 26559



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
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. wink.gif tongue.gif

This post has been edited by Caroliano: Jul 18 2012, 06:24
Go to the top of the page
+Quote Post
LigH
post Jul 18 2012, 07:45
Post #175





Group: Members
Posts: 157
Joined: 20-November 01
Member No.: 503



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


--------------------
http://forum.gleitz.info - das deutsche doom9/Gleitz-Forum
Go to the top of the page
+Quote Post

23 Pages V  « < 5 6 7 8 9 > » 
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd September 2014 - 09:48