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

[LithosZA]

It's linked above— https://people.xiph.org/~greg/opus-tools.zip

Are you using this one?

CODE

C:\opus-tools>opusenc.exe
Usage: opusenc [options] input_file output_file.opus

Encodes input_file using Opus. It can read the WAV, AIFF, or raw files.

General options:
-h, --help This help
-v, --version Version information
--quiet Quiet mode

input_file can be:
filename.wav file
- stdin

output_file can be:
filename.opus compressed file
- stdout

Encoding options:
--speech Optimize for speech
--music Optimize for music
--bitrate n.nnn Encoding bitrate in kbit/sec (6-256 per channel)
--vbr Use variable bitrate encoding (default)
--cvbr Use constrained variable bitrate encoding
--hard-cbr Use hard constant bitrate encoding
--comp n Encoding complexity (0-10, default: 10)
--framesize n Maximum frame size in milliseconds
(2.5, 5, 10, 20, 40, 60, default: 20)
--expect-loss Percentage packet loss to expect (default: 0)
--downmix-mono Downmix to mono
--downmix-stereo Downmix to stereo (if >2 channels)
--max-delay n Maximum container delay in milliseconds
(0-1000, default: 1000)

Diagnostic options:
--save-range file Saves check values for every frame to a file
--set-ctl-int x=y Pass the encoder control x with value y (advanced)
Preface with s: to direct the ctl to multistream s
This may be used multiple times
--uncoupled Use one mono stream per channel

Metadata options:
--comment Add the given string as an extra comment
This may be used multiple times
--artist Author of this track
--title Title for this track

Input options:
--raw Raw input
--raw-bits n Set bits/sample for raw input (default: 16)
--raw-rate n Set sampling rate for raw input (default: 48000)
--raw-chan n Set number of channels for raw input (default: 2)
--raw-endianness n 1 for bigendian, 0 for little (defaults to 0)

This post has been edited by db1989: Jul 3 2012, 17:30

Reason for edit: Please use [codebox] for large items, not [quote].

[punkrockdude]

I can't seem to playback an encoded opus file with Foobar2000. I have changed the extension from opus to ogg and then to celt without it working. I have also download the foo_input_celt.dll but not managed to playback it successfully. What am I missing? Regards.

[LithosZA]

I can't seem to playback an encoded opus file with Foobar2000. I have changed the extension from opus to ogg and then to celt without it working. I have also download the foo_input_celt.dll but not managed to playback it successfully. What am I missing? Regards.

foobar2000 Opus support seems to be on the todo list:

OPUS TODO

[punkrockdude]

foobar2000 Opus support seems to be on the todo list:

OPUS TODO

Thank you for the help but do you know any player that can play it in realtime?

[zerowalker]

Had done something entirely else XD

But got it working with that one now, using cmd etc.

And from my tests,

OPUS Is better than Autov with keeping details on characteristic things, like a singers dark voice etc, while Autov fails here and "blend" everything to make it smooth or something.

The Good thing with this is, you get more detail on these parts, the bad thing is, you get more "cracks etc" in the "surroundings".


Sorry for bad explanation, not the best listener nor explainer on this kind of stuff.
But that´s atleast what i got out of it on my tests.


EDIT:

I may take back my statement on which i prefer.

When i listen once again on them, the OPUS does have a Fuller more Concrete sound, while Autov like i said about, pretty much smooth things out to keep it "transparent".
I think that if i just play awhile i will ignore those crack sounds and it will be pretty pleasent really.

Though it´s not like i am going to sit and listen to 45 kbit music here, but it´s really neat that it´s moving forward on the Transparent/Size scale.

From what i would prefer, i think i would go with Autov as it´s more Transparent with the cracks and overall smoothness in the sound, though i really like the way opus keeps the details on stuff, but sadly the cracks is to much to be pleasent.

Settings where for one example: --framesize 60 --music --bitrate 45, Autov = q-1
Went after the filesize.

This post has been edited by zerowalker: Jun 1 2012, 00:48

[rt87]

aoTuV Q -1 is 48kbps.

This post has been edited by db1989: Jul 3 2012, 17:29

Reason for edit: deleting pointless full quote of above post

[kode54]

Thank you for the help but do you know any player that can play it in realtime?

opusdec will play it in real time if you don't pass an output path.

[NullC]

Options:
--bitrate n Encoding bit-rate in kbit/sec
--cbr Use constant bitrate encoding

Can you tell me where you got this binary so I can take it down or add a note that it's years old and people shouldn't use it?

[CoRoNe]

Does Opus have, or will Opus get an option equivalent to Vorbis's --ignorelength for use with Foobar?
Works fine on WinXP!

[Gainless]

Already found a sort of bug sample with a loud distortion on a kick, even with 128 kbps/framesize 60.

Audio Link

This post has been edited by Gainless: Jun 1 2012, 23:34

[2012]

Already found a sort of bug sample with a loud distortion on a kick, even with 128 kbps/framesize 60.

Audio Link

FWIW, If you resample to 48000 with sox before encoding. The problem will go away.

Opus operates with 48000 internally. But the result is resampled back after encoding to the original rate so people don't get confused. Someone disagreed with that reasoning in the IRC channel and I agree with that someone.

P.S. Acording to the devs, 60ms frames are not supposed to help. Not at those bitrates anyway.

This post has been edited by 2012: Jun 1 2012, 23:58

[2012]

Opus operates with 48000 internally. But the result is resampled back after encoding to the original rate so people don't get confused. Someone disagreed with that reasoning in the IRC channel and I agree with that someone.

And my hunch was right. If you call opusdec with --rate 48000 so It doesn't downsample, the problem will go away.

This post has been edited by 2012: Jun 2 2012, 00:09

[Gainless]

Already found a sort of bug sample with a loud distortion on a kick, even with 128 kbps/framesize 60.

Audio Link

FWIW, If you resample to 48000 with sox before encoding. The problem will go away.

Opus operates with 48000 internally. But the result is resampled back after encoding to the original rate so people don't get confused. Someone disagreed with that reasoning in the IRC channel and I agree with that someone.

P.S. Acording to the devs, 60ms frames are not supposed to help. Not at those bitrates anyway.

Ok, I've set the "raw-rate" to 44100 now, sounds better but there are still pre-echos. I Hope I won't have to resample everything before encoding...

This post has been edited by Gainless: Jun 2 2012, 00:56

[NullC]

Ok, I've set the "raw-rate" to 44100 now, sounds better but there are still pre-echos. I Hope I won't have to resample everything before encoding...

All setting raw-rate would do is switch it from interpreting your input as a wav file and instead interpret it as raw PCM, so the wav header becomes a dozen junk samples at the beginning and your audio is all slid down that many samples.

Based on your description I was guessing that you're just clipping, which might come or go if you were right on the edge and you changed the offset— but your sample isn't that loud and I'm actually unable to reproduce your results.

/opusenc --bitrate 128 --framesize 60 Frozen\ Babylon\ \(Sample\).wav - | ./opusdec - coded.wav

I don't think I can ABX these files, I'm certainly not hearing an obvious artifact.

This post has been edited by NullC: Jun 2 2012, 06:29

[2012]

Based on your description I was guessing that you're just clipping, which might come or go if you were right on the edge and you changed the offset— but your sample isn't that loud and I'm actually unable to reproduce your results.

I don't think I can ABX these files, I'm certainly not hearing an obvious artifact.

The clip is definitely audible here when opusdec downsamples.

opusdec


opusdec --rate 48000


Look around 0.9-1.0

This post has been edited by 2012: Jun 2 2012, 10:19

[lvqcl]

upper channel: opusenc --bitrate 128 --framesize 60 + opusdec (bug between 0.950 and 0.955)
lower channel: opusenc --bitrate 128 + opusdec (bug between 0.990 and 0.995)

[Gainless]

Ok, I've set the "raw-rate" to 44100 now, sounds better but there are still pre-echos. I Hope I won't have to resample everything before encoding...

All setting raw-rate would do is switch it from interpreting your input as a wav file and instead interpret it as raw PCM, so the wav header becomes a dozen junk samples at the beginning and your audio is all slid down that many samples.

Based on your description I was guessing that you're just clipping, which might come or go if you were right on the edge and you changed the offset— but your sample isn't that loud and I'm actually unable to reproduce your results.

/opusenc --bitrate 128 --framesize 60 Frozen\ Babylon\ \(Sample\).wav - | ./opusdec - coded.wav

I don't think I can ABX these files, I'm certainly not hearing an obvious artifact.

Oh, sorry then I got confused with the meaning of the settings. The artifact (as 2012 mentioned) is definately there nonetheless if the decoder is not forced to keep the sample rate at 48 khz. Well, at least the file itself is not the problem but just the decoder.

This post has been edited by Gainless: Jun 2 2012, 13:00

[zerowalker]

Maybe a stupid question, but can someone say, what Latency has for relevance on Audio Codec?
I understand, low latency is good for speech, but what i don´t get it, where is the latency coming from, is it the decoding latency or what?

Thanks:)

[NullC]

Maybe a stupid question, but can someone say, what Latency has for relevance on Audio Codec?
I understand, low latency is good for speech, but what i don´t get it, where is the latency coming from, is it the decoding latency or what?
Thanks:)

In order to get useful compression codecs work with multiple samples at a time. They read in some samples enough to fill a code frame plus potentially some more for psycho-acoustic analysis 'lookahead', then they process it and emit a packet of compressed data. On the far end the decoder reverses the process.

So even if your computer is infinitely fast a codec must have a least a frame size worth of delay and more if the frames overlap or the encoder needs lookahead for analysis (e.g. for transient switching). Popular music codec like Vorbis and AAC have delays of hundreds of milliseconds which makes them not very suitable for interactive/communication uses. Larger frames are generally better for compression because they enable higher coding gain and more precise psycho-acoustic models, though they also tend to have more pre-echo liability. Opus has basic frame frame sizes from 2.5 to 20ms and and lows as 2.5ms, so 5-22.5ms codec latency (there are larger frame sizes, but they only pack multiple smaller frames to save a few bytes of header space/entropy coder overhead). Through a lot of hard work and a little luck it can get quality competitive with high latency coders at mid to high rates. Though at low bitrates (e.g. <=48 for music) I still expect high latency codecs to do better (except for speech).

[NullC]

upper channel: opusenc --bitrate 128 --framesize 60 + opusdec (bug between 0.950 and 0.955)
lower channel: opusenc --bitrate 128 + opusdec (bug between 0.990 and 0.995)

oh yea, it's super obvious without the --framesize 60.

I'll fix.

[zerowalker]

Maybe a stupid question, but can someone say, what Latency has for relevance on Audio Codec?
I understand, low latency is good for speech, but what i don´t get it, where is the latency coming from, is it the decoding latency or what?
Thanks:)

In order to get useful compression codecs work with multiple samples at a time. They read in some samples enough to fill a code frame plus potentially some more for psycho-acoustic analysis 'lookahead', then they process it and emit a packet of compressed data. On the far end the decoder reverses the process.

So even if your computer is infinitely fast a codec must have a least a frame size worth of delay and more if the frames overlap or the encoder needs lookahead for analysis (e.g. for transient switching). Popular music codec like Vorbis and AAC have delays of hundreds of milliseconds which makes them not very suitable for interactive/communication uses. Larger frames are generally better for compression because they enable higher coding gain and more precise psycho-acoustic models, though they also tend to have more pre-echo liability. Opus has basic frame frame sizes from 2.5 to 20ms and and lows as 2.5ms, so 5-22.5ms codec latency (there are larger frame sizes, but they only pack multiple smaller frames to save a few bytes of header space/entropy coder overhead). Through a lot of hard work and a little luck it can get quality competitive with high latency coders at mid to high rates. Though at low bitrates (e.g. <=48 for music) I still expect high latency codecs to do better (except for speech).

Ah so for example Skype, if i speak, it will collect some voice data in a framesieze, then send it, and the lower that framesize is, the faster it goes, but the less Accurate it will be?

But for Vorbis etc, does it even needa frame size, can´t it be unlimited?
If it´s better i mean?

But don´t you think Opus will dominate Vorbis at all?
Cause it would be lovely if Vorbis and AAC got knocked down from the throne letting new codecs and probably pushing the lossy codecs even more.

[NullC]

Okay, the fix for the click on the opusdec 44.1kHz output is up!

The fix is in opusdec with the version string "opus-tools 0.1.0-9-gac7490c (based on libopus 0.9.11-75-gc64f4a4)"
http://git.xiph.org/?p=opus-tools.git;a=co...c8518af24336091

Sorry about that, and thanks so much for testing and reporting!

New windows binaries are at:
http://people.xiph.org/~greg/opus-tools.zip

This post has been edited by NullC: Jun 3 2012, 04:16

[NullC]

Ah so for example Skype, if i speak, it will collect some voice data in a framesieze, then send it, and the lower that framesize is, the faster it goes, but the less Accurate it will be?

Basically.

But for Vorbis etc, does it even needa frame size, can´t it be unlimited?
If it´s better i mean?

But don´t you think Opus will dominate Vorbis at all?
Cause it would be lovely if Vorbis and AAC got knocked down from the throne letting new codecs and probably pushing the lossy codecs even more.

Even if you don't care about delay bigger frames also mean more memory required and usually more computing power, as well as files which are more sensitive to damage and/or aren't good for seeking. For any design beyond a certain point the quality stops going up and you also get more pre-echo problems, so there is diminishing returns.

In listening tests Opus has done substantially better than Vorbis and HE-AAC (e.g. at 64k http://listening-tests.hydrogenaudio.org/igorc/results.html), smaller more informal tests have also showed superior performance at 96k (though testing at 96k is harder). At lower rates I expect opus to hold up well for speech, but for music I expect it to be worse than AoTuV vorbis, at least depending on personal artifact preference, and or HE-AAC.

[rt87]

Okay, the fix for the click on the opusdec 44.1kHz output is up!

The fix is in opusdec with the version string "opus-tools 0.1.0-9-gac7490c (based on libopus 0.9.11-75-gc64f4a4)"
http://git.xiph.org/?p=opus-tools.git;a=co...c8518af24336091

Sorry about that, and thanks so much for testing and reporting!

New windows binaries are at:
http://people.xiph.org/~greg/opus-tools.zip

new opusdec can't output to wave device:

CODE

I:\>opusdec.exe 05.opus
Decoding 44100 Hz audio (2 channels)
Cannot open output: No such file or directory

This post has been edited by rt87: Jun 3 2012, 09:45

[lvqcl]

CODE

Decoding 44100 Hz audio (1 channel)
Cannot open output: No error

Also: I tried to subtract original 44.1 audio from this audio after encoding+decoding. It turns out that the latter is shifted by ~0.42 sampling intervals...