IETF Opus codec now ready for testing, That's CELT 0.11 Options

[Atak_Snajpera]

By the way why is the sample rate always 48khz and does this make it possible for aliasing IF the decoder somehow resamples it back to 44.1khz? Another question is if 96kHz is or will be supported?

Regards.

Input sample rate

This is not the sample rate to use for playback of the encoded data.

Opus has a handful of coding modes, with internal audio bandwidths of 4, 6, 8, 12, and 20 kHz. Each packet in the stream may have a different audio bandwidth. Regardless of the audio bandwidth, the reference decoder supports decoding any stream at a sample rate of 8, 12, 16, 24, or 48 kHz. The original sample rate of the encoder input is not preserved by the lossy compression.

An Ogg Opus player SHOULD select the playback sample rate according to the following procedure:

If the hardware supports 48 kHz playback, decode at 48 kHz,
else if the hardware's highest available sample rate is a supported rate, decode at this sample rate,
else if the hardware's highest available sample rate is less than 48 kHz, decode at the next higher supported rate and resample,
else decode at 48 kHz and resample.

However, the 'input sample rate' field allows the encoder to pass the sample rate of the original input stream as metadata. This may be useful when the user requires the output sample rate to match the input sample rate. For example, a non-player decoder writing PCM format to disk might choose to resample the output audio back to the original input rate to reduce surprise to the user, who might reasonably expect to get back a file with the same sample rate as the one they fed to the encoder.

A value of zero indicates 'unspecified'. Encoders SHOULD write the actual input rate or zero, but decoder implementations which do something with this field SHOULD take care to behave sanely if given crazy values (e.g. don't actually upsample the output to 10 MHz if requested).

http://wiki.xiph.org/OggOpus

This post has been edited by Atak_Snajpera: Aug 16 2012, 18:54

[jensend]

I've tested the latest exp version and I am so surprised of the quality. Ten years years ago companies said that wma and aac sounded like mp3 128kbps at half the bitrate. That was not true, but now, Opus is almost there in my opinion.

By the way why is the sample rate always 48khz and does this make it possible for aliasing IF the decoder somehow resamples it back to 44.1khz? Another question is if 96kHz is or will be supported?

Opus uses 48kHz internally. This simplifies a lot of things about the design of the format and allows it to be more efficient.

Since a lossy audio format's goal is to provide a version which sounds like the original to human listeners, Opus doesn't waste any bits on information about frequencies above 20 kHz, which are inaudible to humans. That's pretty much the case for any other intelligent lossy audio format. If you want to encode lossy audio for bats' higher frequency hearing range, you may need to come up with a new format designed around bat psychoacoustics.

The opus-tools encoder records the sample rate and exact number of samples from your original file, and the opus-tools decoder uses a quality resampler and returns a file with the same sample rate and exact same number of samples. So 96kHz is supported in that the encoder will accept such a file and the decoder will give you a 96kHz file back, but the decoded file will have no >20kHz content.

No halfway decent resampler will have aliasing problems if used correctly. You generally get aliasing problems either with extremely poor quality resampling filters or if you're trying to use too narrow of a transition band for the resampler's filter. Downsampling to 44.1 with a 20kHz passband leaves a wide enough transition band (from 20kHz to the nyquist limit of 22.05kHz) for any good resampler to avoid aliasing.

[Gecko]

Jmvalin has been working on some doubly experimental stuff that we hope improves the transient response.
It would be helpful if people could test it and compare it against the prior EXP builds: https://people.xiph.org/~greg/opus-tools_exp_tfsel5.zip (and against master, if you like but the comparison with regular exp is most important).

I could not ABX build tfsel5 against dc4f83be at 64 kbps on the Pendulum sample on either headphones or PC speakers. The tfsel5 file is about 0.1% larger. As per the metadata, both files identify the encoder as libopus 0.9.11-146-gdc4f83b-exp_analysis.

[kode54]

MSVC x64 build, which should be faster:

http://kode54.foobar2000.org/opus-tools_ex...l5_MSVC_x64.zip

[IgorC]

Speed:
official build - 47x
MSVC buiild - 51x

foobar, 2 threads, AMD Turion II P540, Windows 7 Enterprise 64 bits.

[kode54]

It should be even faster when it's actually resampling the input.

[IgorC]

OK, it was a native 48 kHz input.

This post has been edited by IgorC: Aug 17 2012, 04:42

[lvqcl]

Encoding time of a test album (68m 22s):

44.1 kHz:
1.0.1-rc: 90.0 s
experim.: 104.0 s
tfsel-x32: 105.7 s
tfsel-x64: 97.5 s

after resampling to 48 kHz:
1.0.1-rc: 68.3 s
experim.: 90.4 s
tfsel-x32: 92.1 s
tfsel-x64: 82.0 s

[2304p]

hello!

I downloaded the lastest one of opus and my antivirus reports: opus-tools.2012.08-16.zip is an infact file "Virus.JS.Psyme"

http://code.google.com/p/mulder/downloads/...;sort=-uploaded

This post has been edited by 2304p: Aug 17 2012, 22:45

[LigH]

False positives are always possible. Some antivirus tools are rather notorious...

VirusTotal reports 2/42, so it's most probably a false positive.

Emsisoft? Ikarus? They are not even known as most reliable detectors. Well possible they are provoked by generical CPU optimizations.

This post has been edited by LigH: Aug 17 2012, 22:56

[saratoga]

hello!

I downloaded the lastest one of opus and my antivirus reports: opus-tools.2012.08-16.zip is an infact file "Virus.JS.Psyme"

http://code.google.com/p/mulder/downloads/...;sort=-uploaded

Get a better antivirus.

[LigH]

There is no "perfect" antivirus. They are all "snake oil" you would trust until they fail. They all didn't find Flame early, rated it at most "suspicious" for years; and even worse are the over-optimistic false positive heuristic results which detect usual Windows kernel features as malware (e.g. Avira kept users from logging in not only once).

But well ... this is an Audio forum.

[Clifoo]

I've found out that Opus with --music switch and without it produces same output (music is default). A hybid mode would be useful.
Anyway, I'd like to be able to switch between music/speech and stereo/mono at certain times of one stream by hand. On the main Opus page there was a statement that some options are dynamically adjustable.
Any chances for such features?

This post has been edited by Clifoo: Aug 18 2012, 18:43

[El Stew]

By looking at the code, the signal type is set to OPUS_AUTO (as opposed to OPUS_SIGNAL_MUSIC or OPUS_SIGNAL_VOICE) when neither --music nor --speech has been specified.

I haven't looked into actual encoder lib deep enough to see what happens internally, but one would assume Opus selects the "suitable" signal type automatically in that case...

[2012]

It looks like the developers are busy. So, I will try to answer to the best of my understanding.

IIUC, Opus operates in 3 modes:

1) SILK only.
2) Hybrid.
3) CELT only.

The mode is selected based on requested bitrate/quality. Not based on the nature of content as one might think.

All --speech and --music do (at this point) is shift the mode decision lower or higher (in that order).

e.g. If you pass --music, CELT mode might be chosen instead of hybrid at a certain requested bitrate/quality.

This post has been edited by 2012: Aug 19 2012, 00:02

[m45t3r]

I compiled rockbox-opus for Sansa Clip+ and did some performance tests as described on this page. I transcoded flac_5.flac from Rockbox test_files to Opus, starting with 8 kbps and doubling the bitrate up to the maximum (512 kbps), always using default mode. I used this compiled version of exp branch, forget to update my encoder before creating the files (there is a new compile fixing a bug) but shouldn't matter to much since is only a decode test. The vorbis_96.ogg and flac_5.flac are only references from test_files and a complete test can be obtained here (it's for Sansa Clip v2, but it shouldn't be too much different, since they use the same chipset).

It should be noted that Opus support on Rockbox is still very early and optimizations are expected. I'm trying to compile to Android too but I'm having some issues. If I can get it I will make some tests too.

CODE

vorbis_096.ogg
175906 of 175906
Decode time - 35.85s
File duration - 175.90s
490.65% realtime
48.91MHz needed for realtime

flac_5.flac
175906 of 175906
Decode time - 6.51s
File duration - 175.90s
2701.99% realtime
8.88MHz needed for realtime

opus_008.opus
176786 of 175914
Decode time - 11.98s
File duration - 175.91s
1468.36% realtime
16.34MHz needed for realtime

opus_016.opus
176786 of 175914
Decode time - 18.60s
File duration - 175.91s
945.75% realtime
25.37MHz needed for realtime

opus_032.opus
176786 of 175914
Decode time - 77.33s
File duration - 175.91s
227.47% realtime
105.50MHz needed for realtime

opus_064.opus
176786 of 175914
Decode time - 88.68s
File duration - 175.91s
198.36% realtime
120.99MHz needed for realtime

opus_128.opus
176786 of 175914
Decode time - 95.57s
File duration - 175.91s
184.06% realtime
130.39MHz needed for realtime

opus_256.opus
176786 of 175914
Decode time - 106.60s
File duration - 175.91s
165.01% realtime
145.44MHz needed for realtime

opus_512.opus
176006 of 175914
Decode time - 129.43s
File duration - 175.91s
135.91% realtime
176.58MHz needed for realtime

This post has been edited by db1989: Aug 19 2012, 17:34

Reason for edit: [code] = [codebox]

[Garf]

The mode is selected based on requested bitrate/quality. Not based on the nature of content as one might think.

This is the case only in the master branch, not in the exp encoder.

[NullC]

I've found out that Opus with --music switch and without it produces same output (music is default). A hybid mode would be useful.
Anyway, I'd like to be able to switch between music/speech and stereo/mono at certain times of one stream by hand. On the main Opus page there was a statement that some options are dynamically adjustable.
Any chances for such features?

I've now removed the --music and --speech options from opusenc, so they'll be gone in the next release. 2012's description (with Garf's addition) is accurate. They don't really do much of anything useful, and I've yet to see evidence of people using them in a productive way: instead it seems that almost everyone assumes that they switch between MDCT and LP modes which isn't actually sensible as options.

What do you actually wish to accomplish with your hand switching? In libopus all options are dynamically adjustable, though that mostly makes sense in realtime usage e.g. to adapt to network conditions changing or having the ability to change settings without dropping your call. Without a use-case I don't know what kind of interface I'd provide for that in opusenc.

[NullC]

hello!
I downloaded the lastest one of opus and my antivirus reports: opus-tools.2012.08-16.zip is an infact file "Virus.JS.Psyme"

Uh. The opus-tools on the opus site report no such thing: https://www.virustotal.com/file/56092827e2a...a4806/analysis/

The file you linked to is not the official opus site, I don't know where they came from. The executables have been passed through some kind encryption/obfuscation (none of the normal strings are visible in the binaries) which has made them _substantially_ larger (e.g. opusinfo.exe has gone from 60k to 211k), I would not be too surprised if they were in fact malware infected.

This post has been edited by NullC: Aug 19 2012, 21:36

[LigH]

LoRd MuldeR will be notified.

[lvqcl]

The file you linked to is not the official opus site, I don't know where they came from. The executables have been passed through some kind encryption/obfuscation (none of the normal strings are visible in the binaries) which has made them _substantially_ larger (e.g. opusinfo.exe has gone from 60k to 211k), I would not be too surprised if they were in fact malware infected.

They are packed with UPX. ~470 kb after unpacking, but I think that's because they were compiled with Intel C/C++ Compiler.

[m45t3r]

So here I have the results of rockbox-opus on Android. The device used was a Samsung Galaxy S II I9100. I compiled using the default settings, what it means it compiled for ARMv5 instructions, but the SGS II support the ARMv7 instructions. I'll try to compile for ARMv7 later. Since there is no reference to this processor, I did a full test, including all samples on test_files page.

One note, the phone a little hot and drains the battery very fast when using Opus. This test shows that the cause is Opus using way more CPU time than other codecs. It's normal since Opus isn't optimized yet.

CODE

opus_512.opus
176006 of 175914
Decode time - 12.76s
File duration - 175.91s
1378.60% realtime

opus_256.opus
176786 of 175914
Decode time - 9.88s
File duration - 175.91s
1780.46% realtime

opus_128.opus
176786 of 175914
Decode time - 8.02s
File duration - 175.91s
2193.39% realtime

opus_064.opus
176786 of 175914
Decode time - 6.56s
File duration - 175.91s
2681.55% realtime

opus_032.opus
176786 of 175914
Decode time - 5.50s
File duration - 175.91s
3198.36% realtime

opus_016.opus
176786 of 175914
Decode time - 1.94s
File duration - 175.91s
9067.52% realtime

opus_008.opus
176786 of 175914
Decode time - 1.22s
File duration - 175.91s
14418.85% realtime

vorbis_096.ogg
175906 of 175906
Decode time - 1.94s
File duration - 175.90s
9067.01% realtime

flac_5.flac
175906 of 175906
Decode time - 1.01s
File duration - 175.90s
17415.84% realtime

pegase_l2_192.mp2
175897 of 175908
Decode time - 2.33s
File duration - 175.90s
7549.35% realtime

lame_192.mp3
175909 of 175960
Decode time - 2.69s
File duration - 175.96s
6541.26% realtime

wv_normx4.wv
175900 of 175906
Decode time - 2.89s
File duration - 175.90s
6086.50% realtime

wv_fastx3.wv
175900 of 175906
Decode time - 2.47s
File duration - 175.90s
7121.45% realtime

wma_96.wma
174294 of 177504
Decode time - 1.99s
File duration - 177.50s
8919.59% realtime

wma_320.wma
174294 of 177504
Decode time - 2.17s
File duration - 177.50s
8179.72% realtime

wma_256.wma
174294 of 177504
Decode time - 2.11s
File duration - 177.50s
8412.32% realtime

wma_192.wma
174294 of 177504
Decode time - 2.42s
File duration - 177.50s
7334.71% realtime

wma_128.wma
174294 of 177504
Decode time - 2.50s
File duration - 177.50s
7100.00% realtime

wmapro_80k.wma
174248 of 178941
Decode time - 2.31s
File duration - 178.94s
7746.32% realtime

wmapro_55k.wma
174248 of 178941
Decode time - 2.29s
File duration - 178.94s
7813.97% realtime

wmapro_271k.wma
174248 of 178941
Decode time - 2.79s
File duration - 178.94s
6413.62% realtime

wmapro_173k.wma
174248 of 178941
Decode time - 2.58s
File duration - 178.94s
6935.65% realtime

wmapro_141k.wma
174248 of 178941
Decode time - 2.40s
File duration - 178.94s
7455.83% realtime

vorbis_500.ogg
175906 of 175906
Decode time - 2.92s
File duration - 175.90s
6023.97% realtime

vorbis_350.ogg
175906 of 175906
Decode time - 3.37s
File duration - 175.90s
5219.58% realtime

vorbis_256.ogg
175906 of 175906
Decode time - 2.49s
File duration - 175.90s
7064.25% realtime

vorbis_192.ogg
175906 of 175906
Decode time - 2.48s
File duration - 175.90s
7092.74% realtime

vorbis_128.ogg
175906 of 175906
Decode time - 2.07s
File duration - 175.90s
8497.58% realtime

true_audio.tta
175000 of 175000
Decode time - 4.37s
File duration - 175.00s
4004.57% realtime

pegase_l2_384.mp2
175897 of 175908
Decode time - 2.34s
File duration - 175.90s
7517.09% realtime

pegase_l2_256.mp2
175897 of 175908
Decode time - 2.38s
File duration - 175.90s
7390.75% realtime

pegase_l2_128.mp2
175897 of 175908
Decode time - 1.84s
File duration - 175.90s
9559.78% realtime

pegase_l1_448.mp1
175908 of 175908
Decode time - 2.43s
File duration - 175.90s
7238.68% realtime

pegase_l1_352.mp1
175908 of 175908
Decode time - 2.16s
File duration - 175.90s
8143.51% realtime

pegase_l1_256.mp1
175908 of 175908
Decode time - 2.07s
File duration - 175.90s
8497.58% realtime

pegase_l1_192.mp1
175908 of 175908
Decode time - 2.26s
File duration - 175.90s
7783.18% realtime

nero_he_64.m4a
175906 of 176017
Decode time - 7.33s
File duration - 176.01s
2401.22% realtime

nero_hev2_64.m4a
175906 of 176034
Decode time - 8.06s
File duration - 176.03s
2183.99% realtime

nero_400.m4a
175906 of 175966
Decode time - 3.56s
File duration - 175.96s
4942.69% realtime

nero_320.m4a
175906 of 175966
Decode time - 3.48s
File duration - 175.96s
5056.32% realtime

nero_256.m4a
175906 of 175966
Decode time - 2.94s
File duration - 175.96s
5985.03% realtime

nero_192.m4a
175906 of 175966
Decode time - 3.01s
File duration - 175.96s
5845.84% realtime

nero_128.m4a
175906 of 175966
Decode time - 2.46s
File duration - 175.96s
7152.84% realtime

nero_096.m4a
175906 of 175966
Decode time - 2.30s
File duration - 175.96s
7650.43% realtime

mpc_350.mpc
175906 of 175906
Decode time - 1.86s
File duration - 175.90s
9456.98% realtime

mpc_300.mpc
175906 of 175906
Decode time - 1.85s
File duration - 175.90s
9508.10% realtime

mpc_224.mpc
175906 of 175906
Decode time - 1.64s
File duration - 175.90s
10725.60% realtime

mpc_170.mpc
175906 of 175906
Decode time - 1.82s
File duration - 175.90s
9664.83% realtime

mpc_128.mpc
175906 of 175906
Decode time - 1.53s
File duration - 175.90s
11496.73% realtime

mpc_096.mpc
175906 of 175906
Decode time - 1.39s
File duration - 175.90s
12654.67% realtime

lame_320.mp3
175909 of 175960
Decode time - 3.07s
File duration - 175.96s
5731.59% realtime

lame_256.mp3
175909 of 175960
Decode time - 3.06s
File duration - 175.96s
5750.32% realtime

lame_128.mp3
175909 of 175960
Decode time - 2.76s
File duration - 175.96s
6375.36% realtime

lame_096.mp3
175951 of 175968
Decode time - 1.96s
File duration - 175.96s
8977.55% realtime

flac_8.flac
175906 of 175906
Decode time - 1.07s
File duration - 175.90s
16439.25% realtime

cook_stereo_96.ra
176431 of 175906
Decode time - 3.21s
File duration - 175.90s
5479.75% realtime

cook_stereo_64.ra
176431 of 175906
Decode time - 3.13s
File duration - 175.90s
5619.80% realtime

cook_stereo_32.ra
176431 of 175904
Decode time - 1.24s
File duration - 175.90s
14185.48% realtime

cook_mono_64.ra
176431 of 175904
Decode time - 1.51s
File duration - 175.90s
11649.00% realtime

cook_mono_32.ra
177449 of 175904
Decode time - 1.39s
File duration - 175.90s
12654.67% realtime

atrac3_lp2_132.oma
174294 of 176360
Decode time - 3.11s
File duration - 176.36s
5670.73% realtime

applelossless.m4a
175906 of 175906
Decode time - 5.00s
File duration - 175.90s
3518.00% realtime

ape_c5000.ape
175906 of 175906
Decode time - 126.73s
File duration - 175.90s
138.79% realtime

ape_c4000.ape
175906 of 175906
Decode time - 34.91s
File duration - 175.90s
503.86% realtime

ape_c3000.ape
175906 of 175906
Decode time - 11.58s
File duration - 175.90s
1518.99% realtime

ape_c2000.ape
175906 of 175906
Decode time - 9.91s
File duration - 175.90s
1774.97% realtime

ape_c1000.ape
175906 of 175906
Decode time - 9.08s
File duration - 175.90s
1937.22% realtime

a52_stereo_192.ac3
176325 of 176000
Decode time - 1.89s
File duration - 176.00s
9312.16% realtime

[Brazil2]

There already is: bass_opus.dll (still experimental, but seems to be working great) in combination with BassAudio.

But it seems to be a complete channels mayhem with 5.1 files or is it only me ?
I've encoded 6_Channel_ID.wav with opus-tools-0.1.4-win32 but I've found nothing using BASSOPUS.dll which can properly play it back. And same goes with the release version of the DLL. However decoding back to WAV creates a working file.

[LoRd_MuldeR]

hello!
I downloaded the lastest one of opus and my antivirus reports: opus-tools.2012.08-16.zip is an infact file "Virus.JS.Psyme"

Uh. The opus-tools on the opus site report no such thing: https://www.virustotal.com/file/56092827e2a...a4806/analysis/

The file you linked to is not the official opus site, I don't know where they came from. The executables have been passed through some kind encryption/obfuscation (none of the normal strings are visible in the binaries) which has made them _substantially_ larger (e.g. opusinfo.exe has gone from 60k to 211k), I would not be too surprised if they were in fact malware infected.

Please see:
http://lamexp.sourceforge.net/doc/FAQ.html#96205e91

[mamboman]

In the man page for opusenc it says that bigger framesizes yield more quality at a given bitrate but it also says:

"Sizes greater than 20ms are only interesting at fairly low bitrates."

In this context, what is regarded as a low bitrate?
Is it worth increasing framesize at the default bitrate of 96kbps or will this have a negligible impact upon quality?
I am not sure whether 96kbps is considered to be a fairly low bitrate or not given that opus can go as low as 6kbps.

Presumably what is considered a low bitrate for music would probably not be considered a low bitrate for speech?

Also, is there a Debian package of the Xiph ABX program Squishyball available to download anywhere? I would like to do some ABX tests with opus but, as I use Linux, foobar is not an option.