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

Opus 1.1-beta

Reply #50
Jmvalin, while the new beta sounds in general pretty good there are still the old problems with tonality, especially sharp guitar strikes. It aren't a few killer samples, but a lot of acoustic guitar stuff that just isn't transparent at 192 kbps because of that, despite the use of the tonality detector. Do you see anything still possible for improvement on that?


Gainless,

While your post was addressed to developer, let me express my humble observations about current development of Opus.

To begin with, there are not that much people who test Opus seriously and it's reviving seeing as You report and submit some samples/issues.


In my opinion during a development of codec it's necessary to compare to 2 things. 1) Previous versions and 2) Other lossy codecs.  After all, it's lossy compression.  There always be problematic samples and absence of  these references  ( (1) and (2) ) will always lead to conclusion that codec isn't enough good.

So let's see how current 1.1 beta does until now.
1)  Comparison to previous 1.0 version. 
1.1 beta is clearly better than 1.0, especially on tonal stuff.  Of course it's possible to do better. You (and me too) have subscribed some samples where 1.1 isn't enough good on low frequency tonal parts. Perfection can take years while it's probably good to get 1.1 release quite soon as it's already significantly better. After all, 1.1 is a first development cycle after 1.0.

2) Comparison to other formats.
As far as I can say Opus is very competetive comparing to state-of-art  AAC/HE-AAC, Vorbis and Musepack encoders at 64 kbps and higher (not so at rates  <48 kbps where HE-AAC have strong positions). There is no actually format that can do any better than Opus overall and for an average listener with average preferences & hearing at 64 kbps and higher.


But then again, yes, Opus has a potential to do better. Let's hope for a  comparable development after 1.1, too.

Hi Igor,

Of course we all hope to see further improvements with Opus, I for example what happened to the "Baby Eater" experiment that somehow got discarded again. At the moment the issues with tonality seem to be some kind of achilles heel, though, as it's really a certain style of material instead of a variety of killer samples that makes problems.
To explain it a bit further, I think it's in the way Opus introduces distortions: The higher you go up with the bitrate the more quiet these become, but they barely seem to disappear within a range of 192 kbps (I talk of problem samples of course). So If I'm listening with "fresh" ears on low volumes a bitrate like 96 kbps can be very sufficient. But with the time, when I lean to turn up the volume a bit due to beginning ear fatigue, it happens that suddenly distortions become obvious. It's like a kind of artifact threshold that improves only relatively slowly with higher bitrates. It also happens with other codecs, but far less often and the artifacts are mostly not that static as the ones Opus introduces at tonality.

Opus 1.1-beta

Reply #51
Of course we all hope to see further improvements with Opus, I for example what happened to the "Baby Eater" experiment that somehow got discarded again. At the moment the issues with tonality seem to be some kind of achilles heel, though, as it's really a certain style of material instead of a variety of killer samples that makes problems.


The babyeater experiment showed that the improvement I was working on didn't work, so it's currently on hold until I can figure out why. But this was meant as a way of improving transients, which Opus generally handles well already. So it's not high on my priority list.

To explain it a bit further, I think it's in the way Opus introduces distortions: The higher you go up with the bitrate the more quiet these become, but they barely seem to disappear within a range of 192 kbps (I talk of problem samples of course). So If I'm listening with "fresh" ears on low volumes a bitrate like 96 kbps can be very sufficient. But with the time, when I lean to turn up the volume a bit due to beginning ear fatigue, it happens that suddenly distortions become obvious. It's like a kind of artifact threshold that improves only relatively slowly with higher bitrates. It also happens with other codecs, but far less often and the artifacts are mostly not that static as the ones Opus introduces at tonality.


Can you come up with one sample that best demonstrates the problem you're talking about? Ideally, it should be a sample where the artefact is obviously worse than with other codecs, and one that's representative of the music people listen to (i.e. not a synthetic test or specially crafted signal). That would make it easier for me to investigate what's going on in more details.

Opus 1.1-beta

Reply #52
Of course we all hope to see further improvements with Opus, I for example what happened to the "Baby Eater" experiment that somehow got discarded again. At the moment the issues with tonality seem to be some kind of achilles heel, though, as it's really a certain style of material instead of a variety of killer samples that makes problems.


The babyeater experiment showed that the improvement I was working on didn't work, so it's currently on hold until I can figure out why. But this was meant as a way of improving transients, which Opus generally handles well already. So it's not high on my priority list.

To explain it a bit further, I think it's in the way Opus introduces distortions: The higher you go up with the bitrate the more quiet these become, but they barely seem to disappear within a range of 192 kbps (I talk of problem samples of course). So If I'm listening with "fresh" ears on low volumes a bitrate like 96 kbps can be very sufficient. But with the time, when I lean to turn up the volume a bit due to beginning ear fatigue, it happens that suddenly distortions become obvious. It's like a kind of artifact threshold that improves only relatively slowly with higher bitrates. It also happens with other codecs, but far less often and the artifacts are mostly not that static as the ones Opus introduces at tonality.


Can you come up with one sample that best demonstrates the problem you're talking about? Ideally, it should be a sample where the artefact is obviously worse than with other codecs, and one that's representative of the music people listen to (i.e. not a synthetic test or specially crafted signal). That would make it easier for me to investigate what's going on in more details.

For instance I would take this one:
[attachment=7588:Streamli..._Sample_.flac]
At 96 kbps the typical tonal distortion like on other samples is already quite obvious at the harder plucked strings if you listen a bit closer, but I wouldn't call it that striking for that rate. On higher bitrates the distortion becomes more and more quiet and softened, but I have to double it to 192 kbps before the artifact gets really harder to spot, so that I have to turn up the volume. Quicktime AAC with TVBR seems to perform better here, as it got already hard for me at 128 kbps.

You can also check these samples, similar story there, with the difference that it are the lower tones that make problems:
Girl In The Fire
Velvet Black Rmx

Opus 1.1-beta

Reply #53
Gainless, when you press reply the editor starts out with a fullquote of the post you're replying to, but please don't leave it that way. The post you're replying to is already in the thread for everyone to see; repeating the entire post, as you've done with every post in this thread, just wastes space and makes the conversation more difficult to follow. If you think you need to quote something to make things clear, just quote the part you're directly replying to at the point in your post where you're replying to it, as jmvalin did. In this instance the only part of jmvalin's post which made any sense for you to quote was the sentence "Can you come up with one sample that best demonstrates the problem you're talking about?" But you really didn't even need to quote that, as it was obvious that was what you were replying to (e.g. no other posts were made between his and yours).

Could you pinpoint the artifacts a little more? It may be just because I'm not the most artifact-sensitive listener, but I can't seem to find what you're talking about on any of the three clips.

Opus 1.1-beta

Reply #54
Yeah, sorry, wasn't the best idea with full quote. The artifact on Streamline I ABXed is at the string around 2,5 seconds. For the other samples you just need to listen to the lowest notes with the most fuzz/resonance, it should be pretty obvious at 96 kbps and below.

Opus 1.1-beta

Reply #55
Gainless,
Have performed a few fast ABC/HR sessions on your sample (Streamline) .
Well,  it's  tonal sample and it's to expect  that Opus has some disadvantage here.  Opus 1.1 was  much better than 1.0 and not that far from AAC on this particular sample.
Duuno, it depends on individual.

Logs.
Try 1º
Code: [Select]
ABC/HR Version 1.1 beta 2, 18 June 2004
Testname:

1L = E:\Audio\gainless samples Opus\Streamline\Streamline QAAC CVBR 96 kbps.wav
2L = E:\Audio\gainless samples Opus\Streamline\Streamline QAAC TVBR 96 kbps.wav
3R = E:\Audio\gainless samples Opus\Streamline\Streamline_ Opus 1.1.wav

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

---------------------------------------
1L File: E:\Audio\gainless samples Opus\Streamline\Streamline QAAC CVBR 96 kbps.wav
1L Rating: 4.1
1L Comment: wavy, but ok
---------------------------------------
2L File: E:\Audio\gainless samples Opus\Streamline\Streamline QAAC TVBR 96 kbps.wav
2L Rating: 4.0
2L Comment:
---------------------------------------
3R File: E:\Audio\gainless samples Opus\Streamline\Streamline_ Opus 1.1.wav
3R Rating: 3.8
3R Comment:
---------------------------------------
ABX Results:

Try 2º
Code: [Select]
ABC/HR Version 1.1 beta 2, 18 June 2004
Testname:

1L = E:\Audio\gainless samples Opus\Streamline\Streamline Opus 1.0.2 96 kbps.wav
2L = E:\Audio\gainless samples Opus\Streamline\Streamline QAAC TVBR 96 kbps.wav
3L = E:\Audio\gainless samples Opus\Streamline\Streamline QAAC CVBR 96 kbps.wav
4R = E:\Audio\gainless samples Opus\Streamline\Streamline_ Opus 1.1 96 kbps.wav

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

---------------------------------------
1L File: E:\Audio\gainless samples Opus\Streamline\Streamline Opus 1.0.2 96 kbps.wav
1L Rating: 3.3
1L Comment:
---------------------------------------
2L File: E:\Audio\gainless samples Opus\Streamline\Streamline QAAC TVBR 96 kbps.wav
2L Rating: 4.2
2L Comment:
---------------------------------------
3L File: E:\Audio\gainless samples Opus\Streamline\Streamline QAAC CVBR 96 kbps.wav
3L Rating: 4.1
3L Comment:
---------------------------------------
4R File: E:\Audio\gainless samples Opus\Streamline\Streamline_ Opus 1.1 96 kbps.wav
4R Rating: 3.8
4R Comment:
---------------------------------------
ABX Results:


Opus 1.1-beta

Reply #56
meh. please delete.

Opus 1.1-beta

Reply #57
Gainless,
Have performed a few fast ABC/HR sessions on your sample (Streamline) .
Well,  it's  tonal sample and it's to expect  that Opus has some disadvantage here.  Opus 1.1 was  much better than 1.0 and not that far from AAC on this particular sample.
Duuno, it depends on individual.

Thanks for your effort with the testing, Igor. My aim with the sample is mainly to demonstrate that even more or less mild artifacts can get preserved up to really high bitrates, like I said, I could ABX it at 192 kbps although the distortion wasn't already that bad at half the rate. Although I doubt that it's of any use for Jmvalin, maybe people can understand a bit better how I catch up all the issues with examples like this.

Or my hearing is just fucked up and an unfortunate exception for the Psymodel...

Opus 1.1-beta

Reply #58
Thanks for your effort with the testing, Igor. My aim with the sample is mainly to demonstrate that even more or less mild artifacts can get preserved up to really high bitrates, like I said, I could ABX it at 192 kbps although the distortion wasn't already that bad at half the rate. Although I doubt that it's of any use for Jmvalin, maybe people can understand a bit better how I catch up all the issues with examples like this.

Or my hearing is just fucked up and an unfortunate exception for the Psymodel...


I had a quick look at that sample and I suspect the issue is that the tonal content is heavily shifted to the right, which probably messes with the analysis (which uses a mono downmix to save CPU). It's probably possibly to improve this in the future, but don't hold your breath.

Opus 1.1-beta

Reply #59
I've found a sample that has unusual artifacts when I encode it at 32 kbps. It seems to rapidly switch between mono and stereo at around 6 seconds, and again at around 9 seconds.

[attachment=7621:qualia-sample.flac]

Opus 1.1-beta

Reply #60
I've found a sample that has unusual artifacts when I encode it at 32 kbps. It seems to rapidly switch between mono and stereo at around 6 seconds, and again at around 9 seconds.

Hi there,
According to file info there is no switching between mono and stereo, but many switching between MDCT & Hybrid and back. Although sometimes stereo picture is a bit 'narrow'.

Code: [Select]
...
960, 72, [[1, 71], MDCT, SWB, S, 960, 49376256]
960, 112, [[1, 111], HYB, SWB, S, 960, 1539135826]
960, 70, [[1, 69], HYB, SWB, S, 960, 352694272]
...
960, 85, [[1, 84], HYB, SWB, S, 960, 469718528]
960, 102, [[1, 101], HYB, SWB, S, 960, 61356043]
960, 97, [[1, 96], MDCT, SWB, S, 960, 319249408]
...

BTW, nice sample, what band is that?

Cheers, A

 

Opus 1.1-beta

Reply #61
According to file info there is no switching between mono and stereo, but many switching between MDCT & Hybrid and back. Although sometimes stereo picture is a bit 'narrow'.

It looks like that's just the frame type, though. Do any of those columns tell you if any bits are spent on coding the difference between left and right?

Try encoding something else at 32 kbps. All of the other music I've tried ends up completely mono.

BTW, nice sample, what band is that?

It's Iosys. The sample is from track 9 of Rockin’ On Touhou Vol. 1.

Opus 1.1-beta

Reply #62
I've found a sample that has unusual artifacts when I encode it at 32 kbps. It seems to rapidly switch between mono and stereo at around 6 seconds, and again at around 9 seconds.


As kabal4e pointed out, it's not stereo being switched on/off, but mode transitions. Basically, part of the singing is being identified as speech, which causes the mode to change between SILK and CELT, which have slightly different stereo characteristics. At 32 kb/s, I doubt we can do much better.

Opus 1.1-beta

Reply #63
Aha, so the problem I have with this sample is that the SILK frames are stereo but the CELT frames are mono. I'm not familiar with Opus's VBR algorithm at all, but would it make sense to use the same "stereo amount" decision for both CELT and SILK?

Opus 1.1-beta

Reply #64
What causes fixed frame size of 20 ms to sound "noisy" at 128 kbps, whereas 10 ms and variable frame size tend to sound "metallic"? These are very subtle effects, which are not always noticeable and ABX-able, but they definitely exist. So I would like to hear a possible theoretical explanation.

Opus 1.1-beta

Reply #65
At 20 ms you can use all transform sizes.  At 10 ms, I believe the largest transform size is disabled to hit the latency target, hence compression is not as good.

Opus 1.1-beta

Reply #66
At 20 ms you can use all transform sizes.  At 10 ms, I believe the largest transform size is disabled to hit the latency target, hence compression is not as good.

This is rather consistent, and that noise is more interesting. It's audible below 160 kbps and depends on music. Most songs encoded at 128kbps are not particularly noisy, but one or two on an album can be easily ABX-able based on noise and "prefer" either variable or (in rare cases) fixed frame size of 20 ms to sound good.

Opus 1.1-beta

Reply #67
If you're forcing the encoder to work within narrower constraints, you should expect to have to give it a higher bitrate to achieve the same quality. 10ms lower latency definitely comes at a cost.

On the other hand, if forcing the encoder to use a fixed frame size gives you results that are ABXably superior to the encoder defaults, you may have found a bug, and posting a short sample of the music in question might help pinpoint the problem.

Opus 1.1-beta

Reply #68
Well, 10 and 20 ms have similar quality at 128k. The first google link for "opus codec 4 pdf", pg 25.

Opus 1.1-beta

Reply #69
At some sufficiently high rate I expect 10ms to become frequently better than 20ms, but I expect that the rate that this happens is high enough that determining the exact rate is hard, and that its somewhat content dependent... and the encoder isn't yet smart enough to do this.

Opus 1.1-beta

Reply #70
I think the main drawback of variable frame size (or any other adaptive variable technique) is that the variation of artifact (or mixing different artifacts) calls more attention than the artifact itself.  There were some AAC encoders with "variable lowpass" and I  perceive its variation as  a "metallic" artifact or a hiss. AFAIK  a hysteresis algorithms are used to solve this.

Opus 1.1-beta

Reply #71
I think the main drawback of variable frame size (or any other adaptive variable technique) is that the variation of artifact (or mixing different artifacts) calls more attention than the artifact itself.  There were some AAC encoders with "variable lowpass" and I  perceive its variation as  a "metallic" artifact or a hiss. AFAIK  a hysteresis algorithms are used to solve this.


The variable frame size implementation is currently buggy and will not be enabled in 1.1. Opus can encode transients just fine without it, so there's no rush to enable it.

Opus 1.1-beta

Reply #72
I must say, Opus is kind of exciting with what it can achieve!
Be a false negative of yourself!

Opus 1.1-beta

Reply #73
The variable frame size implementation is currently buggy and will not be enabled in 1.1

Are you referring to the poor results with 40/60 ms lookup time?

Opus 1.1-beta

Reply #74
Have tried a last surround fork (build g6b9087a). Due to lack of time only two samples for now. Transient sample EIG and some mixed (tonal+transients) sample .
Quality is the same as of beta 1.1 at 96 kbps.

EIG
Code: [Select]
ABC/HR Version 1.1 beta 2, 18 June 2004
Testname:

1R = E:\Audio\EIG_1\eig_1.1_beta.wav
2R = E:\Audio\EIG_1\eig_1.1surround.wav
3R = E:\Audio\EIG_1\eig 1.0.2.wav

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

---------------------------------------
1R File: E:\Audio\EIG_1\eig_1.1_beta.wav
1R Rating: 4.4
1R Comment:
---------------------------------------
2R File: E:\Audio\EIG_1\eig_1.1surround.wav
2R Rating: 4.4
2R Comment:
---------------------------------------
3R File: E:\Audio\EIG_1\eig 1.0.2.wav
3R Rating: 4.0
3R Comment:
---------------------------------------
ABX Results:

Spiral architect
Code: [Select]
ABC/HR Version 1.1 beta 2, 18 June 2004
Testname:

1R = E:\Audio\Opus_test1\01 Spiral Architect\spiral architect _1.1_beta.wav
2R = E:\Audio\Opus_test1\01 Spiral Architect\spiral architect _1.1surround.wav

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

---------------------------------------
1R File: E:\Audio\Opus_test1\01 Spiral Architect\spiral architect _1.1_beta.wav
1R Rating: 4.4
1R Comment:
---------------------------------------
2R File: E:\Audio\Opus_test1\01 Spiral Architect\spiral architect _1.1surround.wav
2R Rating: 4.4
2R Comment:
---------------------------------------
ABX Results: