If somebody hasn't seen there is an official Opus 1.1 alpha.
https://ftp.mozilla.org/pub/mozilla.org/opu...alpha-win32.zip (https://ftp.mozilla.org/pub/mozilla.org/opus/win32/opus-tools-0.1.6-opus-1.1-alpha-win32.zip)
Also some kinda settings to play with
https://wiki.xiph.org/Opus_tuning (https://wiki.xiph.org/Opus_tuning)
If somebody hasn't seen there is an official Opus 1.1 alpha.
https://ftp.mozilla.org/pub/mozilla.org/opu...alpha-win32.zip (https://ftp.mozilla.org/pub/mozilla.org/opus/win32/opus-tools-0.1.6-opus-1.1-alpha-win32.zip)
Also some kinda settings to play with
https://wiki.xiph.org/Opus_tuning (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.
I compiled opus-tools with libopus 1.1-alpha using the sources posted at http://www.opus-codec.org/downloads/ (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 compiled opus-tools with libopus 1.1-alpha using the sources posted at http://www.opus-codec.org/downloads/ (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.
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].
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=93824). For example, at 16-24 kbps Opus gives this:
(http://s11.postimage.org/xzv494v6n/16_24_kbps.jpg) (http://postimage.org/image/xzv494v6n/)
and for 32-40 kbps it gives this:
(http://s9.postimage.org/c4likc1ej/32_40_kbps.jpg) (http://postimage.org/image/c4likc1ej/)
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 (http://www.mediafire.com/?i4dfzlik2u412kr) (problematic sampes are marked with exclamation mark). Hope, developers will use this samples in their work.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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 (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.
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?
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 (http://hydrogenaudio.org/forums/?showtopic=86580)] which do not continue existing discussion here be split off, as Opus has it own subforum.
Opus 1.1 alpha version (not BABYEATER) (http://hydrogenaudio.org/forums/?showtopic=99495) [= this thread], including softrunner’s post about this version and spectrograms.
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.
A single result for sample http://www.rarewares.org/test_samples/EnolaGay.wv (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.
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
Is it normal to get weird gap/crackly artifacts at low bitrates (40 kbps). Because with one music track (http://www.last.fm/music/Michael+Giacchino/_/Locating+Enemy+Positions) I got some. (0:01;0:44;2:01)
A single result for sample http://www.rarewares.org/test_samples/EnolaGay.wv (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?
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.
Is it normal to get weird gap/crackly artifacts at low bitrates (40 kbps). Because with one music track (http://www.last.fm/music/Michael+Giacchino/_/Locating+Enemy+Positions) 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.
Is it normal to get weird gap/crackly artifacts at low bitrates (40 kbps). Because with one music track (http://www.last.fm/music/Michael+Giacchino/_/Locating+Enemy+Positions) 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.
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.
Well, I listened to the encoded file at 64 kb/s (70 kb/s actual output) and I could barely ABX (wasn't with headphones, but still). I can revisit this later, but at this point I doubt there will be much I can do for the artefacts you've been hearing at 96 kb/s. Note that I'm not saying it's perfect, just that there was nothing that struck me as obviously wrong (i.e. a bug) with that file.
OK. And yes, You're right. This isn't a day and night difference but still.
Also the sample of harpsichord hasn't constant quality but rather it starts with the same constant noise and then go to high quality. Generally Opus 1.1a is smart to increase a rate on difficult parts (on tonal samples in this case) but the encoder doesn't react instantly and only slowly increases the rate from begining of this sample.
Also the sample of harpsichord hasn't constant quality but rather it starts with the same constant noise and then go to high quality. Generally Opus 1.1a is smart to increase a rate on difficult parts (on tonal samples in this case) but the encoder doesn't react instantly and only slowly increases the rate from begining of this sample.
Haven't listened to the file, but one thing I'm currently working on is adding (optional) look-ahead to help reacting faster to changes. So in theory that could help here. Just curious, what happens if you create a file that repeats the segment twice and encode it? Is the beginning of each segment worse, or just the beginning of the first one?
It behaves exactly the same. Both beginnings have the same artifacts on 2x concatenated source.
P.S. Forgot to mention, there is a silence during the first second. Might be useful.
It behaves exactly the same. Both beginnings have the same artifacts on 2x concatenated source.
Had a closer look and I now understand the issue. The pitch of the first three notes is too low for the tone detector (too low resolution). It's only at the fourth note that it realizes there's something tonal here. There isn't much I can do about that one at least for now.
No hurry at all. If it will be improved at some point it will be great . Anyway as for now I can't find any audio format that will be any better overall than Opus at 64-96 kbps and higher. (those are not just beautiful words and pink pony stuff or so, actually have made tests)
I wonder if there's any new builds we can try.
I'm already very pleased with Opus @80kbps but there's always room for improvements.
I wonder if there's any new builds we can try.
I'm already very pleased with Opus @80kbps but there's always room for improvements.
I'm trying 48-64kbps. So far 48kbps impressed me how they preserve the details at such low bitrate.
But I think we are at different ball game comparing with MP3 or AAC as we already know how to spot their weakness.
This is new codec and really know how to trick our ears
May be aging takes into consideration as well due to hearing loss.
Kudos to the developer who bring this codec free to the world!!!
Every codec knows how to trick our earing, don't get into the hype because placebo gets stronger (against others) when hype is high.
Opus is good but still new like you said, they released three versions in few months and 1.1 is coming. I still like AAC the most, it's amazing how low you can go with AAC as well...and it's compatible with almost everything.
It's time for MP3 to disappear for sure, Amazon and Google should have picked AAC.
I'm sitting here telling myself that Google Music will soon be switching to Opus for streaming.
Coffee. Oh and as long as Starbucks coffee exists, so will mp3. As long as the mobile market is split between Android/iPhone/windows phone it will always be around.
As I wrote before, Opus 1.1 alpha has some bugs, though version 1.0.2 is not perfect also. Check these (http://www.hydrogenaudio.org/forums/index.php?showtopic=100313) samples. Some examples:
(http://s23.postimg.org/qp7qhbv53/Chirp0to24k_Hz.jpg) (http://postimg.org/image/qp7qhbv53/) (http://s10.postimg.org/q6i81h5qt/Chirp0to24k_Hz_Opus1_0_2_2_5ms_96kbps.jpg) (http://postimg.org/image/q6i81h5qt/) (http://s17.postimg.org/bot2efbsr/Chirp0to24k_Hz_Opus1_1a_20ms_256kbps.jpg) (http://postimg.org/image/bot2efbsr/)
For 1.1 alpha at some frequencies the signal just disappears, while for both versions a lot of loud artefacts are present. Of course, all this is audible, I posted 408 Opus samples at the link above (someone needs ABX logs?).
Another problem: Opus increases bitrate even if there is no progress in quality, while Vorbis on q10 has 20 kbps, and it is perfectly OK on 15 kbps.
What I want to know is whether these artefacts can be removed in future versions, or they are the part of Opus algorithm? For example, Musepack also failed on this samples, though it is developed for many years...
What I want to know is whether these artefacts can be removed in future versions, or they are the part of Opus algorithm? For example, Musepack also failed on this samples, though it is developed for many years...
Sure, representing stuff like this is doable in an MDCT codec like vorbis or opus. But samples like this aren't music, so its probably not something encoders are made to deal with.
Sure, representing stuff like this is doable in an MDCT codec like vorbis or opus. But samples like this aren't music, so its probably not something encoders are made to deal with.
Have to double my post:
Well, electronic music may contain whatever signals possible, there are thousands of various plugins/generators etc...
It should be respected also.
Sure, representing stuff like this is doable in an MDCT codec like vorbis or opus. But samples like this aren't music, so its probably not something encoders are made to deal with.
Have to double my post: Well, electronic music may contain whatever signals possible, there are thousands of various plugins/generators etc...
It should be respected also.
If you find an example of electronic music that breaks one of those encoders, you should report it. Until then, its a bit premature.
For 1.1 alpha at some frequencies the signal just disappears, while for both versions a lot of loud artefacts are present. Of course, all this is audible, I posted 408 Opus samples at the link above (someone needs ABX logs?).
Another problem: Opus increases bitrate even if there is no progress in quality, while Vorbis on q10 has 20 kbps, and it is perfectly OK on 15 kbps.
What I want to know is whether these artefacts can be removed in future versions, or they are the part of Opus algorithm? For example, Musepack also failed on this samples, though it is developed for many years...
Yes, that problem was reported before and is not fixed in git. See this post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=99841&view=findpost&p=827137) (and related) for more details. I don't care about wasting bits on artificial signals like that, but the tone disappearing was not acceptable. If you try the latest git, it should all work.
Ok, so here's another ABXable issue with tonality:
[attachment=7490:Albibeno...ample_1_.flac]
[attachment=7491:Albibeno...ample_2_.flac]
Interesting about it is, that the first one is totally fine, but the second has a tonal distortion (around second 2,3 on the right channel), although the tonal input is the same in both, just set into a different sound stage. Tested it with the official 1.1 alpha and 1.0.5. build (which performed worse btw) at 192 kb/s.
I've played a bit around with different framesizes for the two Albibeno samples and found that the issue of the 2nd one (a distortion on the right channel around second 2,2) is improved with a forced size of 10 ms, used CBR for the comparison of course. Maybe worth a fix?