IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
Opus 1.1 alpha version (not BABYEATER), [split from the good old megathread]
IgorC
post Feb 10 2013, 02:00
Post #1





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



If somebody hasn't seen there is an official Opus 1.1 alpha.

https://ftp.mozilla.org/pub/mozilla.org/opu...alpha-win32.zip

Also some kinda settings to play with
https://wiki.xiph.org/Opus_tuning
Go to the top of the page
+Quote Post
Seren
post Feb 10 2013, 10:53
Post #2





Group: Members
Posts: 56
Joined: 1-November 12
Member No.: 104244



QUOTE (IgorC @ Feb 10 2013, 09:00) *
If somebody hasn't seen there is an official Opus 1.1 alpha.

https://ftp.mozilla.org/pub/mozilla.org/opu...alpha-win32.zip

Also some kinda settings to play with
https://wiki.xiph.org/Opus_tuning


Imo official opus binaries should be stickied in a thread of it's own. As posting on a topic like this could likely cause it to be buried.
Go to the top of the page
+Quote Post
moosehunter
post Feb 13 2013, 04:54
Post #3





Group: Members
Posts: 11
Joined: 10-February 13
Member No.: 106534



I compiled opus-tools with libopus 1.1-alpha using the sources posted at http://www.opus-codec.org/downloads/
I expected to see the same results as the 1.1 builds posted a page or two ago, but the encodes with my build are different. The files encoded with the build I compiled have a much greater range of bitrates within the file. At the default 96kbps you might have a bitrate range of 50 to 510 kbps, and on average, files encoded with my build had an average bitrate of about 5 kbps greater than the other 1.1-alpha builds. It's not just one or two frames encoded at 510 kbps that drives the range up either. Looking at a listing of bitrates of each frame, it seems to be driving up the bitrate fairly often compared to the other builds.

I encoded the eig test sample at the default 96kbps bitrate just to see what it would do, and the resulting opus file had an average bitrate of 222 kbps for some reason.

Is this intended behavior, or did something just not turn out right on my end?
Go to the top of the page
+Quote Post
LithosZA
post Feb 13 2013, 06:39
Post #4





Group: Members
Posts: 199
Joined: 26-February 11
Member No.: 88525



QUOTE
I compiled opus-tools with libopus 1.1-alpha using the sources posted at http://www.opus-codec.org/downloads/
I expected to see the same results as the 1.1 builds posted a page or two ago, but the encodes with my build are different. The files encoded with the build I compiled have a much greater range of bitrates within the file. At the default 96kbps you might have a bitrate range of 50 to 510 kbps, and on average, files encoded with my build had an average bitrate of about 5 kbps greater than the other 1.1-alpha builds. It's not just one or two frames encoded at 510 kbps that drives the range up either. Looking at a listing of bitrates of each frame, it seems to be driving up the bitrate fairly often compared to the other builds.

I encoded the eig test sample at the default 96kbps bitrate just to see what it would do, and the resulting opus file had an average bitrate of 222 kbps for some reason.

Is this intended behavior, or did something just not turn out right on my end?


I am not sure why your alpha build would produce different results, but you are using VBR. It should average around 96Kbps on a large set of files. If you want to target exactly around 96Kbps then you have to use CVBR.
Go to the top of the page
+Quote Post
Jplus
post Feb 13 2013, 10:05
Post #5





Group: Members
Posts: 41
Joined: 7-February 13
Member No.: 106471



Since eig is known to be a hard sample it shouldn't be a surprise that it's encoded at higher bitrate than the target. What might be playing a role in addition to that, is that Opus is as young as a fat-cheeked little baby. The devs probably didn't manage yet to determine a more accurate expected bitrate for each preset in unconstrained VBR mode. Perhaps it would be too early to start fine-tuning anyway since probably all code is still subject to change.

In my recent listening test QT AAC and LAME would sink below the expected bitrate for some samples while Opus would not go under the target bitrate for those same samples or any other. It might be the case that the expected bitrate for Opus 1.1a at the 96kbps preset is rather more like 110-120kbps. You can find the post with the bitrates here.
Go to the top of the page
+Quote Post
softrunner
post Feb 14 2013, 02:33
Post #6





Group: Members
Posts: 48
Joined: 19-July 12
Member No.: 101579



QUOTE (Martel @ Jan 1 2013, 14:46) *
QUOTE (softrunner @ Dec 29 2012, 04:50) *
I don't know weather it is possible for encoder to do such an analysis of a source audio, but it would be great it yes.
It's only a matter of finding the right formula/algorithm.

x264 video encoder has encoding mode called Constant Rate Factor. In this mode number (16, 17, etc) is used to define desired quality (lower - better quality and higher bitrate), and encoder does not care about bitrate, only about keeping rate factor constant. It is a question, why nobody has invented something similar for audio encoding (except lossyWAV, which needs too much bitrate for acceptable quality)?
----------------
Opus 1.1 Alpha has some bugs, which can be found using samples from thread High Frequency Listening Test Samples. For example, at 16-24 kbps Opus gives this:

and for 32-40 kbps it gives this:

For samples 1_12kHz, 1_20kHz, 2_8kHz, 2_12kHz and 2_20kHz Opus sounds wrongly even at 512 kbps.
Full set of files is here (problematic sampes are marked with exclamation mark). Hope, developers will use this samples in their work.

This post has been edited by softrunner: Feb 14 2013, 02:34
Go to the top of the page
+Quote Post
Banned
post Feb 14 2013, 07:19
Post #7





Group: Members
Posts: 13
Joined: 12-January 13
Member No.: 105821



And what are these graphs supposed to show? Why do you even think this is a bug?

Edit: I propose that new posts in this thread which do not continue existing discussion here be split off, as Opus has it own subforum.

This post has been edited by Banned: Feb 14 2013, 07:45
Go to the top of the page
+Quote Post
softrunner
post Feb 14 2013, 09:15
Post #8





Group: Members
Posts: 48
Joined: 19-July 12
Member No.: 101579



QUOTE (Banned @ Feb 14 2013, 10:19) *
And what are these graphs supposed to show? Why do you even think this is a bug?

Signal should be constant, as source. First spectrogram demonstrates growing frequency cutoff, and second - dramatic signal change at the beginning of the sample.
Go to the top of the page
+Quote Post
saratoga
post Feb 14 2013, 20:16
Post #9





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



QUOTE (softrunner @ Feb 14 2013, 03:15) *
QUOTE (Banned @ Feb 14 2013, 10:19) *
And what are these graphs supposed to show? Why do you even think this is a bug?

Signal should be constant, as source. First spectrogram demonstrates growing frequency cutoff, and second - dramatic signal change at the beginning of the sample.


Spectrograms are basically meaningless for looking at lossy audio.
Go to the top of the page
+Quote Post
lvqcl
post Feb 14 2013, 20:18
Post #10





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



QUOTE (db1989 @ Feb 14 2013, 23:03) *
QUOTE
Opus 1.1 Alpha has some bugs[Ö] [pictures of spectrograms]
Right. But how does it sound? Not that I expect transparency at 32 kbps, but visual images are of scant relevance to audio.

1_12kHz and 2_12kHz tracks sound really strange, even at max. bitrate.
Go to the top of the page
+Quote Post
db1989
post Feb 14 2013, 20:25
Post #11





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



QUOTE (saratoga @ Feb 14 2013, 19:16) *
QUOTE (softrunner @ Feb 14 2013, 03:15) *
QUOTE (Banned @ Feb 14 2013, 10:19) *
And what are these graphs supposed to show? Why do you even think this is a bug?
Signal should be constant, as source. First spectrogram demonstrates growing frequency cutoff, and second - dramatic signal change at the beginning of the sample.

Spectrograms are basically meaningless for looking at lossy audio.

This, and the Terms of Service make it clear that weíre not interested in assessing perceptual encoders visually.

Itís a paradoxical thing to do: itís their purpose to do whatever they want to the signal in order to compress it as well as possible with the lowest probability of us noticing, so in a way, you should welcome visual differences, or at least not care about them until theyíre reflected in what you hear.
Go to the top of the page
+Quote Post
jensend
post Feb 15 2013, 00:02
Post #12





Group: Members
Posts: 145
Joined: 21-May 05
Member No.: 22191



Plenty of people ready to ream the guy with knee-jerk responses to seeing spectrograms, but only lvqcl gives any indication of having downloaded and examined anything.

There's normally good reason to expect that feeding an encoder a basically constant signal will result in basically constant output, and finding something else might lead one to think there's a bug. Of course spectrograms are not a quality measure, but the spectrograms are perfectly legitimate as a way of showing at a glance that his reasonable expectation of near-constancy has been completely upset in the case of his test samples. You can verify that by downloading his 7z and doing a bunch of listening but he's tried to help people be able to see this more easily and quickly. That didn't get communicated as well as one might have hoped, since we didn't know the nature of his test signals and his little b/w log(f) spectrograms

Right now, those of us who are just a little more familiar with Opus don't have that expectation. The pre-1.1 encoder changes a lot of parameters- certainly including mode and bandwidth - to adapt to its input. Because encoder work thus far has been aimed largely at real-time uses, there's very little encoder lookahead; it's just looking at the current frame and its past analysis. Thus the encoder may encode at non-optimal settings for a little while before it settles on better parameters.

Apparently the encoder starts off with parameters that are too optimistic for these signals, and has those parameters confirmed by the simplicity of encoding the initial silence. When the fade-in hits it starts hunting around for a new mode and bandwidth to try to preserve less of the audio but do a better job with what it does preserve. In the 32-40kbps one there's a very audible glitchy click, probably as it's switching from an MDCT mode to hybrid mode. I can't reproduce the click on the 1.1a build I have, though it does waffle between different modes and show other interesting behaviors.
Go to the top of the page
+Quote Post
db1989
post Feb 15 2013, 16:39
Post #13





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



QUOTE (jensend @ Feb 14 2013, 23:02) *
Plenty of people ready to ream the guy with knee-jerk responses to seeing spectrograms, but only lvqcl gives any indication of having downloaded and examined anything.
Right, and I appreciate the fact that lvqcl did that. I didn’t intend to scare softrunner away! smile.gif I’m glad that some useful discussion has come out of the report, and so I also appreciate the fact that softrunner posted it.

I guess it’s just difficult to assess whether posts backed up by visual data are actually relevant, at least without stopping being lazy and checking things ourselves, so yeah, “knee-jerk responses” can happen. A lot of the time they turn out to be justified, but not always, of course.

This post has been edited by db1989: Feb 15 2013, 16:39
Go to the top of the page
+Quote Post
softrunner
post Feb 16 2013, 02:11
Post #14





Group: Members
Posts: 48
Joined: 19-July 12
Member No.: 101579



QUOTE (saratoga @ Feb 14 2013, 23:16) *
Spectrograms are basically meaningless for looking at lossy audio.

I am not substituting audio listening for looking at spectrograms. These spectrograms were posted for those who do no want to download and listen audio samples, just to allow them to realize, that Opus can give some bad result for some samples for now. Do not understand, why these pictures produced such an interest. blink.gif I always use spectrograms because they give me additional information about work of encoder.

QUOTE (jensend @ Feb 15 2013, 03:02) *
There's normally good reason to expect that feeding an encoder a basically constant signal will result in basically constant output, and finding something else might lead one to think there's a bug.
...

I do not know much about work of Opus encoder, but, definitely, if encoder cannot produce constant result, there must be some bug: eigther logical error in it's algorithm or mayby it is just some arithmetic mistake. Also I can say, that Opus 1.0.2 doesn't have these two bugs.
Go to the top of the page
+Quote Post
db1989
post Feb 16 2013, 03:48
Post #15





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



QUOTE (softrunner @ Feb 16 2013, 01:11) *
Do not understand, why these pictures produced such an interest. blink.gif
Then read #8 of the Terms of Service if you havenít already. I already explained this, too: If a perceptual encoder is doing its job, all the pictures in the world are meaningless.

QUOTE
I always use spectrograms because they give me additional information about work of encoder.
As above. This may be informative in edge cases, but you are liable to draw inaccurate conclusions from visual summaries of audio, for the obvious reason that you donít listen to music with your eyes.

I already said that I was glad that your post led to some useful discussion and the potential for improvement in Opus. That doesnít mean you should put too much faith in spectrograms et al. in all cases.
Go to the top of the page
+Quote Post
IgorC
post Feb 23 2013, 19:12
Post #16





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



After performing some blind tests on Opus 1.1a and comparing it to Apple AAC at 96 kbps, I should say I'm quite impressed by Opus. Previously I've performed the tests on experimental branches of Opus and it was very close to AAC (no real statistical difference). But it's a first time when the average score for Opus was very slightly better, though still no real statistical difference. The test was done on these samples (mostly from the last public test) http://uploading.com/files/get/mb98d734/LAME_MP3.zip

The only sample on which Opus was clearly inferior is 04 ("Enola Gay"). The tones sound quite noisy.
Go to the top of the page
+Quote Post
CoRoNe
post Feb 23 2013, 23:06
Post #17





Group: Members
Posts: 185
Joined: 31-May 05
From: Netherlands
Member No.: 22417



Although I'm no expert in detecting audible differences, and while at first I encoded these files for other testing purposes, I could clearly detect a regression in libopus 1.1alpha over libopus 1.0.2, so I thought I'd report about it.
The moment that matters in those 3 files is at 2 seconds from the start; "Center".
libopus 1.0.2 is ok, libopus 1.1a is 'muffled', libopus 1.1a-39 "Cen" is 'muffled' and "ter" is a little less 'muffled'. The remaining 57 seconds are fine.

A --bitrate 192 for libopus 1.0.2 resulted in 70kbps, while for libopus 1.1a it became 115kbps and libopus 1.1a-39 116kbps. I take it libopus 1.0.2 is way too low?
Btw, why is --bitrate 192 the lowest possible bitrate for 6ch?
Attached File(s)
Attached File  AC3___6Ch__Speaker_Test__File_Avisynth__libopus_1.0.2_.opus ( 514.15K ) Number of downloads: 105
Attached File  AC3___6Ch__Speaker_Test__File_Avisynth__libopus_1.1a_.opus ( 839.08K ) Number of downloads: 93
Attached File  AC3___6Ch__Speaker_Test__File_Avisynth__libopus_1.1a_39_.opus ( 847.69K ) Number of downloads: 97
 


--------------------
DC-Bass Source Mod: http://reino.degeelebosch.nl
Go to the top of the page
+Quote Post
db1989
post Feb 23 2013, 23:26
Post #18





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



Please consider reporting issues regarding 1.1a to the thread specifically about 1.1a, not the ancient catch-all thread that is now redundant since Opus was given its own subforum. It was mentioned in the very last reply before yours, even:
QUOTE (db1989 @ Feb 15 2013, 15:35) *
QUOTE (Banned @ Feb 14 2013, 06:19) *
I propose that new posts in this thread [= that thread] which do not continue existing discussion here be split off, as Opus has it own subforum.
Opus 1.1 alpha version (not BABYEATER) [= this thread], including softrunnerís post about this version and spectrograms.
Go to the top of the page
+Quote Post
CoRoNe
post Feb 23 2013, 23:51
Post #19





Group: Members
Posts: 185
Joined: 31-May 05
From: Netherlands
Member No.: 22417



I didn't think my post would fit in either of those specific threads, and I thought that when those specific threads would "dry out", the conversation would continue in the catch all thread. Guess I was wrong.
Perhaps better to close it then.


--------------------
DC-Bass Source Mod: http://reino.degeelebosch.nl
Go to the top of the page
+Quote Post
IgorC
post Mar 14 2013, 03:14
Post #20





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



A single result for sample http://www.rarewares.org/test_samples/EnolaGay.wv

AFAICT so far it's only the sample where Opus performs subpar comparing to AAC. Still 1.1a was better than 1.0.
CODE

1R = D:\Audio\Sample04 AAC test\sample04 Opus 1.1a 96 kbps.wav
2R = D:\Audio\Sample04 AAC test\sample04 Opus 1.0.2 96 kbps.wav
3L = D:\Audio\Sample04 AAC test\sample04 Apple AAC CVBR 96 kbps.wav

---------------------------------------
General Comments:

---------------------------------------
1R File: D:\Audio\Sample04 AAC test\sample04 Opus 1.1a 96 kbps.wav
1R Rating: 4.0
1R Comment: There is still some noise.
---------------------------------------
2R File: D:\Audio\Sample04 AAC test\sample04 Opus 1.0.2 96 kbps.wav
2R Rating: 3.5
2R Comment: Very noisy on tones
---------------------------------------
3L File: D:\Audio\Sample04 AAC test\sample04 Apple AAC CVBR 96 kbps.wav
3L Rating: 4.5
3L Comment: Perceptible but it's very good overall
---------------------------------------
ABX Results:
D:\Audio\Sample04 AAC test\sample04 Opus 1.1a 96 kbps.wav vs D:\Audio\Sample04 AAC test\sample04 Opus 1.0.2 96 kbps.wav
5 out of 5, pval = 0.031
D:\Audio\Sample04 AAC test\sample04 Opus 1.1a 96 kbps.wav vs D:\Audio\Sample04 AAC test\sample04 Apple AAC CVBR 96 kbps.wav
5 out of 5, pval = 0.031
Go to the top of the page
+Quote Post
mzso
post Mar 14 2013, 20:32
Post #21





Group: Members
Posts: 177
Joined: 2-May 07
Member No.: 43131



Is it normal to get weird gap/crackly artifacts at low bitrates (40 kbps). Because with one music track I got some. (0:01;0:44;2:01)

This post has been edited by mzso: Mar 14 2013, 20:34
Go to the top of the page
+Quote Post
jmvalin
post Mar 14 2013, 21:41
Post #22


Xiph.org Speex developer


Group: Developer
Posts: 481
Joined: 21-August 02
Member No.: 3134



QUOTE (IgorC @ Mar 13 2013, 22:14) *
A single result for sample http://www.rarewares.org/test_samples/EnolaGay.wv

AFAICT so far it's only the sample where Opus performs subpar comparing to AAC. Still 1.1a was better than 1.0.


Is the noise mostly constant throughout the file or is there more/less in some sections? Also, is it constant throughout notes or is there more noise close to the attacks? Also, in what frequency range is it most audible?
Go to the top of the page
+Quote Post
IgorC
post Mar 15 2013, 03:37
Post #23





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



The noise is constant during the whole tonal part (1.5-15 sec)
Those are not an attacks but the constant noise at notes. The tones sound more "hairy".
That's the only appropriate description that comes to mind right now.
The quantitative part is hard. Not sure but I _think_ there is some noise in 4-8 kHz and 12-14 kHz ranges.
Both are enough audible.

If later You will have a few files I'm willing to listen them.
Go to the top of the page
+Quote Post
IgorC
post Mar 15 2013, 03:59
Post #24





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



QUOTE (mzso @ Mar 14 2013, 16:32) *
Is it normal to get weird gap/crackly artifacts at low bitrates (40 kbps). Because with one music track I got some. (0:01;0:44;2:01)

You can post a short sample (up to 30 seconds) in upload section or any other place.
Go to the top of the page
+Quote Post
mzso
post Mar 15 2013, 09:45
Post #25





Group: Members
Posts: 177
Joined: 2-May 07
Member No.: 43131



QUOTE (IgorC @ Mar 15 2013, 04:59) *
QUOTE (mzso @ Mar 14 2013, 16:32) *
Is it normal to get weird gap/crackly artifacts at low bitrates (40 kbps). Because with one music track I got some. (0:01;0:44;2:01)

You can post a short sample (up to 30 seconds) in upload section or any other place.


I split the parts with mkvmerge. I guess this will suffice then. They seem to be out of place to me and not just plain quality loss.
Attached File(s)
Attached File  MOH_02_-_opus_artifacts_-_wav_-_1.mka ( 32.4K ) Number of downloads: 91
Attached File  MOH_02_-_opus_artifacts_-_wav_-_2.mka ( 24.85K ) Number of downloads: 72
Attached File  MOH_02_-_opus_artifacts_-_wav_-_3.mka ( 29.63K ) Number of downloads: 76
 
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this 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: 2nd October 2014 - 01:31