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: Opus 1.1 alpha version (not BABYEATER) (Read 32574 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.


Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

Reply #4
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 [a href='index.php?act=findpost&pid=823909']here[/a].

 

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

Reply #12
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!  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.

Opus 1.1 alpha version (not BABYEATER)

Reply #13
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.  I always use spectrograms because they give me additional information about work of encoder.

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.

Opus 1.1 alpha version (not BABYEATER)

Reply #14
Do not understand, why these pictures produced such an interest.
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.

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

Reply #17
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:
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.

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

Reply #19
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: [Select]
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

Opus 1.1 alpha version (not BABYEATER)

Reply #20
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)

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

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

Opus 1.1 alpha version (not BABYEATER)

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