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

Opus 1.1 released

Reply #25
If the minimum bitrate is 6 kbps per channel (as stated in opusenc.html), then minimum bitrate for stereo encoding is 6*2=12 kbps. But in fact we get a mono encoding (one channel) at 12 kbps (and even up to 30 kbps).

The quality is also minimum at 6kbps. If I have only 12kbps of bandwidth, I'd like to use that additional 6kbps to increase the audibility, rather than to get the fancy stereo effect, while retaining the minimal quality.

Opus 1.1 released

Reply #26
If the minimum bitrate is 6 kbps per channel (as stated in opusenc.html), then minimum bitrate for stereo encoding is 6*2=12 kbps. But in fact we get a mono encoding (one channel) at 12 kbps (and even up to 30 kbps).

The quality is also minimum at 6kbps. If I have only 12kbps of bandwidth, I'd like to use that additional 6kbps to increase the audibility, rather than to get the fancy stereo effect, while retaining the minimal quality.


Agree. But I'm saying just that statement in documentation is incorrect and some correction (or notes maybe) are needed.
🇺🇦 Glory to Ukraine!

Opus 1.1 released

Reply #27
Can you test AAC? Particularly Apple's AAC?

If you can tell me how to set it up without installing iTunes/Quicktime, I would. Personally, I don't really have any interest in AAC, it was pretty intransparent up to a high bitrate for me (the nero aac encoder) a few years ago. Haven't tested it recently though, so not going to claim anything

Opus 1.1 released

Reply #28
Can you test AAC? Particularly Apple's AAC?

If you can tell me how to set it up without installing iTunes/Quicktime, I would. Personally, I don't really have any interest in AAC, it was pretty intransparent up to a high bitrate for me (the nero aac encoder) a few years ago. Haven't tested it recently though, so not going to claim anything

If you download qaac 2.27 and makeportable  from here https://sites.google.com/site/qaacpage/cabinet you can make it portable.

Opus 1.1 released

Reply #29
Is there any improvement in sound quality from 1.1 beta to the 1.1 final release? Thanks 


Opus 1.1 released

Reply #31
I wish the tagging of Opus could include using more efficient image formats for album art. Like WebP.
Is this something to develop in future releases? (I guess this would be an extension of OGG container?)
Opus is all about hq at low bitrate, I think that "vision" should include album art too.

WebP is a google format. Devices on Android can read it native afaik. Would be very usefull


Opus 1.1 released

Reply #33
I think you can already put any image you want in Ogg.  At least people keep reporting "broken" Ogg files with all kinds of embedded images that they expect to work.

Opus 1.1 released

Reply #34
I wish the tagging of Opus could include using more efficient image formats for album art.


Does Opus even include album art in the specification?

The "advantages" of WebP are rather controversial in the first place:
http://people.mozilla.org/~josh/lossy_comp...y_october_2013/

I think wait until WebP is based off VP9, in it's current state it's really not that much of an advantage.

Opus 1.1 released

Reply #35
If the minimum bitrate is 6 kbps per channel (as stated in opusenc.html), then minimum bitrate for stereo encoding is 6*2=12 kbps. But in fact we get a mono encoding (one channel) at 12 kbps (and even up to 30 kbps).


I think it actually says 6kbps is the minimum "target" bitrate. I think for low-frequency in surround sound it gets less than that, so 6kbps doesn't seem to be a technical limitation.

Opus 1.1 released

Reply #36
I think it actually says 6kbps is the minimum "target" bitrate. I think for low-frequency in surround sound it gets less than that, so 6kbps doesn't seem to be a technical limitation.


The 6 kb/s we generally quote is the lowest "usable rate", i.e. the lowest we think someone sane might want to use. If you want you can reduce the rate down to 2 kb/s, but at that rate all you get is modulated low-frequency noise. We can even losslessly encode digital silence at 1.2 kb/s.

Opus 1.1 released

Reply #37
I'm very angry now for the Poweramp guy to not include the decoder in it's player. We've asked for that more than a year ago. 

Have you looked into http://www.bsplayer.com/ ?  They were very responsive to my request and added it to their Android app several months after I made the request.



Opus 1.1 released

Reply #40
I've decided to encode my collection into Opus 1.1 @ 256kbps unconstrained VBR which sounds like an overkill but i've just listened to the U96 sample which i reported earlier as a problematic one for Opus-1.1 beta and i can confirm that i can still ABX it at this setting with the release encoder:

Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.2.9
2014/01/04 01:17:48

File A: D:\sample.flac
File B: D:\sample.opus

01:17:48 : Test started.
01:18:48 : 01/01  50.0%
01:19:53 : 02/02  25.0%
01:20:25 : 03/03  12.5%
01:24:19 : 04/04  6.3%
01:24:43 : 05/05  3.1%
01:24:46 : Test finished.

----------
Total: 5/5 (3.1%)


Opus notices the difficulty and with the --vbr 256 setting the final bitrate is 303kbps but it still produces noticeable pre-echo noises.
It's a lot easier to understand the problem if it's encoded at a lower bitrate, like 96kbps.

Opus 1.1 released

Reply #41
I was experimenting more today with Opus and found out that encoding the U96 problematic sample with the --framesize 10 setting makes the pre-echo artifact almost completely gone away at 256kbps and i haven't done an ABX yet, but it seems impossible for me to detect it at --framesize 5.
If i understood it correctly the percussion error is coming from the transient problem the babyeater build tried to solved earlier by varying the frame size if a transient was detected. So it's not a suprise that forcing a decrease in framesize makes things better by this sample.

I've read on the Hydrogenaudio wiki that decreasing the frame size hurts frequency resolution and bitrate have to be increased to keep the quality level. At 5ms frames 32.5% bitrate increase is required to keep up with the changes. This means that instead of 256kbps i had to use 339,2 kbps, but i was going with 320kbps since it's not that far away from that and it's approaching the common 320kbps CBR mp3 bitrate more so the final file size is comparable.
So i've came up with a --vbr --framesize 5 --bitrate 320 setting right now and i'm willing to test it with a longer encode of my collection.

I'm interested about what kind of artifacts will arise if i'm using the --framesize 5 setting, what should i looking for?

Also i'm thinking about using --cvbr instead of --vbr at this bitrate. Some of my tracks are getting very huge bitrate boost from the tonal estimator (mostly chiptune music or electronic music with saw-wave like sound) and it might be not necessary at such high bitrates.

A very good example for this is Benny Benassi's track: Able To Love (from the Album: Hypnotica) which has a strong synth sound in the beginning for a long period. Sometimes it even peaks to >=450kbps when encoded at 256kbps VBR according to the foobar2000's realtime bitrate display.

Another example comes from from farbrausch 64kb music disk. It's track four which is the soundtrack of fr-010 which a cover of the famour Sanxion tune by Rob Hubbard. Encoded at 256kbps the final bitrate is 378kbps and bitrate is always near 400kbps, except the intro passage. Encoded with this new 320kbps setting (using unconstrained VBR) it ends up at 420kbps. 

I will do a test anyway but i thought to share my thinking here so you might be able to say if i'm doing stupid things

 

Opus 1.1 released

Reply #42
Yes,  the samples which contain transients should benefit from use of  a shorter frames.   

Have tried this sample. http://www.rarewares.org/test_samples/velvet.wv
From best to worst: 5 ms, 10 ms, 20 ms, 2.5 ms. 

Though there is a side effect as some distortion in low frequency range, not that noticeable on 10 ms, somewhat on 5 ms and clearly audible on 2.5 ms. A good solution can be variable/adaptive frame size.  A good implementation of variable frame size would be most optimal for all kind of signals.


Opus 1.1 released

Reply #43
Though there is a side effect as some distortion in low frequency range, not that noticeable on 10 ms, somewhat on 5 ms and clearly audible on 2.5 ms.

Is this even true for such high bitrate encode modes like --vbr 320 --framesize 5 I've described? Can you notice low frequency distortion even at this setting?

A variable frame length capable encoder would be really good but the BABYEATER build sadly came out as a dead end  I hope there's still some way to resurrect this feature.

Opus 1.1 released

Reply #44
darkbyte,

I'll try higher bitrate  tommorow or so.

Here's the log of 128 kbps. http://pastebin.com/Z3UbLiSm

Opus 1.1 released

Reply #45
I'll try higher bitrate  tommorow or so.


Thanks! I'm curious. Based on your test --framesize 10 seems to be a good choice on mid range bitrates (~128-160kbps)

Opus 1.1 released

Reply #46
After some additional tests on Velvet sample I can say that 5/10/20 ms have similar performance at 160 kbps. It's very hard to prefer one of them as they all do pretty good.
And all 5/10/20 ms frame sizes were transparent at 192 kbps. At least it will require very critical listening to spot some artifacts there.

Except 2.5 ms which still had low frequency distortion on bass drum at 160-192 kbps.