IPB

Welcome Guest ( Log In | Register )

6 Pages V  < 1 2 3 4 5 > »   
Reply to this topicStart new topic
Opus 1.1-beta, Officially released
Gainless
post Aug 12 2013, 17:21
Post #51





Group: Members
Posts: 169
Joined: 28-October 11
Member No.: 94764



QUOTE (IgorC @ Aug 11 2013, 19:48) *
QUOTE (Gainless @ Aug 1 2013, 18:21) *
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.

This post has been edited by Gainless: Aug 12 2013, 17:53
Go to the top of the page
+Quote Post
jmvalin
post Aug 13 2013, 03:11
Post #52


Xiph.org Speex developer


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



QUOTE (Gainless @ Aug 12 2013, 12:21) *
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.

QUOTE (Gainless @ Aug 12 2013, 12:21) *
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.
Go to the top of the page
+Quote Post
Gainless
post Aug 13 2013, 14:39
Post #53





Group: Members
Posts: 169
Joined: 28-October 11
Member No.: 94764



QUOTE (jmvalin @ Aug 13 2013, 04:11) *
QUOTE (Gainless @ Aug 12 2013, 12:21) *
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.

QUOTE (Gainless @ Aug 12 2013, 12:21) *
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:
Attached File  Streamline__Sample_.flac ( 1.07MB ) Number of downloads: 90

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

This post has been edited by Gainless: Aug 13 2013, 14:39
Go to the top of the page
+Quote Post
jensend
post Aug 13 2013, 16:33
Post #54





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



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.
Go to the top of the page
+Quote Post
Gainless
post Aug 13 2013, 16:51
Post #55





Group: Members
Posts: 169
Joined: 28-October 11
Member No.: 94764



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.

This post has been edited by Gainless: Aug 13 2013, 17:11
Go to the top of the page
+Quote Post
IgorC
post Aug 14 2013, 05:54
Post #56





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



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

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

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:



This post has been edited by IgorC: Aug 14 2013, 05:57
Go to the top of the page
+Quote Post
eahm
post Aug 14 2013, 06:10
Post #57





Group: Members
Posts: 884
Joined: 11-February 12
Member No.: 97076



meh. please delete.

This post has been edited by eahm: Aug 14 2013, 06:13
Go to the top of the page
+Quote Post
Gainless
post Aug 15 2013, 21:06
Post #58





Group: Members
Posts: 169
Joined: 28-October 11
Member No.: 94764



QUOTE (IgorC @ Aug 14 2013, 06:54) *
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...

This post has been edited by Gainless: Aug 15 2013, 21:08
Go to the top of the page
+Quote Post
jmvalin
post Aug 15 2013, 21:11
Post #59


Xiph.org Speex developer


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



QUOTE (Gainless @ Aug 15 2013, 16:06) *
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.
Go to the top of the page
+Quote Post
Octocontrabass
post Sep 9 2013, 08:37
Post #60





Group: Members
Posts: 22
Joined: 9-September 13
Member No.: 110004



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.

Attached File  qualia-sample.flac ( 1.44MB ) Number of downloads: 108
Go to the top of the page
+Quote Post
kabal4e
post Sep 10 2013, 00:58
Post #61





Group: Members
Posts: 8
Joined: 10-March 13
From: Waikato, NZ
Member No.: 107144



QUOTE (Octocontrabass @ Sep 9 2013, 19:37) *
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
...
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
Go to the top of the page
+Quote Post
Octocontrabass
post Sep 10 2013, 03:57
Post #62





Group: Members
Posts: 22
Joined: 9-September 13
Member No.: 110004



QUOTE (kabal4e @ Sep 9 2013, 16:58) *
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.

QUOTE (kabal4e @ Sep 9 2013, 16:58) *
BTW, nice sample, what band is that?

It's Iosys. The sample is from track 9 of Rockin’ On Touhou Vol. 1.
Go to the top of the page
+Quote Post
jmvalin
post Sep 10 2013, 06:20
Post #63


Xiph.org Speex developer


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



QUOTE (Octocontrabass @ Sep 9 2013, 03:37) *
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.
Go to the top of the page
+Quote Post
Octocontrabass
post Sep 10 2013, 08:02
Post #64





Group: Members
Posts: 22
Joined: 9-September 13
Member No.: 110004



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?
Go to the top of the page
+Quote Post
qduaty
post Oct 2 2013, 14:19
Post #65





Group: Members
Posts: 9
Joined: 10-July 13
Member No.: 109045



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.
Go to the top of the page
+Quote Post
saratoga
post Oct 2 2013, 16:45
Post #66





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



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.
Go to the top of the page
+Quote Post
qduaty
post Oct 4 2013, 20:06
Post #67





Group: Members
Posts: 9
Joined: 10-July 13
Member No.: 109045



QUOTE (saratoga @ Oct 2 2013, 17:45) *
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.
Go to the top of the page
+Quote Post
jensend
post Oct 4 2013, 22:02
Post #68





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



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.
Go to the top of the page
+Quote Post
IgorC
post Oct 4 2013, 23:06
Post #69





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



Well, 10 and 20 ms have similar quality at 128k. The first google link for "opus codec 4 pdf", pg 25.
Go to the top of the page
+Quote Post
NullC
post Oct 8 2013, 20:24
Post #70





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



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.
Go to the top of the page
+Quote Post
IgorC
post Oct 12 2013, 17:04
Post #71





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



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.

This post has been edited by IgorC: Oct 12 2013, 17:06
Go to the top of the page
+Quote Post
jmvalin
post Oct 13 2013, 03:07
Post #72


Xiph.org Speex developer


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



QUOTE (IgorC @ Oct 12 2013, 12:04) *
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.
Go to the top of the page
+Quote Post
Nystagmus
post Oct 13 2013, 16:38
Post #73





Group: Members
Posts: 22
Joined: 13-October 13
Member No.: 110926



I must say, Opus is kind of exciting with what it can achieve!
Go to the top of the page
+Quote Post
qduaty
post Oct 13 2013, 23:12
Post #74





Group: Members
Posts: 9
Joined: 10-July 13
Member No.: 109045



QUOTE (jmvalin @ Oct 13 2013, 04:07) *
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?
Go to the top of the page
+Quote Post
IgorC
post Oct 14 2013, 09:17
Post #75





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



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

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
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:

Go to the top of the page
+Quote Post

6 Pages V  < 1 2 3 4 5 > » 
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: 20th April 2014 - 17:37