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 389918 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

IETF Opus codec now ready for testing

Reply #50
Quote
It's linked above— https://people.xiph.org/~greg/opus-tools.zip
Are you using this one?

Code: [Select]
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)

IETF Opus codec now ready for testing

Reply #51
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.

IETF Opus codec now ready for testing

Reply #52
Quote
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


IETF Opus codec now ready for testing

Reply #54
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.

IETF Opus codec now ready for testing

Reply #55
aoTuV Q -1 is 48kbps.
Sorry for my English.

IETF Opus codec now ready for testing

Reply #56
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.

IETF Opus codec now ready for testing

Reply #57
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?

IETF Opus codec now ready for testing

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

IETF Opus codec now ready for testing

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

Audio Link

IETF Opus codec now ready for testing

Reply #60
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.

IETF Opus codec now ready for testing

Reply #61
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.

IETF Opus codec now ready for testing

Reply #62
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...

IETF Opus codec now ready for testing

Reply #63
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.

IETF Opus codec now ready for testing

Reply #64
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

IETF Opus codec now ready for testing

Reply #65


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)

IETF Opus codec now ready for testing

Reply #66
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.

IETF Opus codec now ready for testing

Reply #67
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:)

IETF Opus codec now ready for testing

Reply #68
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).


IETF Opus codec now ready for testing

Reply #69
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.

IETF Opus codec now ready for testing

Reply #70
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.

IETF Opus codec now ready for testing

Reply #71
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

IETF Opus codec now ready for testing

Reply #72
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.

Quote
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.

IETF Opus codec now ready for testing

Reply #73
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: [Select]
I:\>opusdec.exe 05.opus
Decoding 44100 Hz audio (2 channels)
Cannot open output: No such file or directory
Sorry for my English.

IETF Opus codec now ready for testing

Reply #74
Code: [Select]
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...