IPB

Welcome Guest ( Log In | Register )

2 Pages V  < 1 2  
Reply to this topicStart new topic
New opus test build
Gainless
post May 12 2013, 12:26
Post #26





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



Igor, you may also take this sample into consideration, has the same issues:
Attached File  DnB_Beat_Sample.flac ( 473.1K ) Number of downloads: 66


This post has been edited by Gainless: May 12 2013, 12:26
Go to the top of the page
+Quote Post
IgorC
post May 12 2013, 21:42
Post #27





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



Gainless,

Yes, 1.0.2 was better than the experimental build (exp) on your "DnB beat" sample. Though there was no bandwidth variation.

The exp reduces bitrate on "DnB beat" as well as on many rock or electronic music tracks and it's actually to expect this behavior because Opus does very good on these styles and can donate saved bits to tonal parts where it really needs some extra bitrate. The exp has also better transition detection, that pays off some bitrate reduction on such samples.

Not sure but I think the exp has the same kind of artifacts for both, "DnB beat" sample and previously posted one in the post #15 , sample01.
Both samples have some metalic artifacts.


From my previous post, the "Iron Man" sample was well encoded by the experimental build, it's how bandwidth detection works.
Go to the top of the page
+Quote Post
Gainless
post May 13 2013, 20:33
Post #28





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



Maybe some framesize otpimation/detector can be done, the artifacts improve a lot with a forced size of 5 ms.
Btw, there is an issue with the new version on the "Sycho Active" sample either. Like in Muse Breaks the distortion on the kicks finally got fixed, but in exchange the cymbal sounds worse than with 1.0.2 and 1.1, quite nasty at 128 kbps, probably due to the little framesize.

This post has been edited by Gainless: May 13 2013, 21:12
Go to the top of the page
+Quote Post
jmvalin
post May 14 2013, 04:52
Post #29


Xiph.org Speex developer


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



QUOTE (Gainless @ May 13 2013, 15:33) *
Btw, there is an issue with the new version on the "Sycho Active" sample either. Like in Muse Breaks the distortion on the kicks finally got fixed, but in exchange the cymbal sounds worse than with 1.0.2 and 1.1, quite nasty at 128 kbps, probably due to the little framesize.


Just trying to understand... you're saying that cymbals in Sycho Active are worse now than before Muse got fixed, or are you saying they are worse with 5 ms frames than with the default (20 ms)? Also, how does 1.1 compare to 1.0.2?
Go to the top of the page
+Quote Post
Gainless
post May 14 2013, 08:10
Post #30





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



Sorry^1000 to Jmvalin and Igor, was my fault with wrong settings in the encoder, I accidentally still had chosen forced framesizes for some testing with the DnB Beat sample, that was the issue after all sad.gif
So SA sounds fine, the new test buid is actually quite transparent at 128 kbps (if not forced to 5 ms framesizes) and better than prior versions by far, which introduced distortions on the kicks, especially 1.1. I'll keep a better eye on what I'm doing now.

QUOTE (jmvalin @ May 14 2013, 05:52) *
QUOTE (Gainless @ May 13 2013, 15:33) *
Btw, there is an issue with the new version on the "Sycho Active" sample either. Like in Muse Breaks the distortion on the kicks finally got fixed, but in exchange the cymbal sounds worse than with 1.0.2 and 1.1, quite nasty at 128 kbps, probably due to the little framesize.


Just trying to understand... you're saying that cymbals in Sycho Active are worse now than before Muse got fixed, or are you saying they are worse with 5 ms frames than with the default (20 ms)? Also, how does 1.1 compare to 1.0.2?

I thought that the fix on Muse Breaks in this new build introduces problems on the Cymbal in SA (which was fine with prior versions), due to smaller framesizes, but that's (fortunately) wrong after all.

This post has been edited by Gainless: May 14 2013, 08:28
Go to the top of the page
+Quote Post
Gainless
post May 23 2013, 17:15
Post #31





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



Here's another sample that could benefit from shorter framesizes:

Attached File  Reloaded_Part_2__Sample_.flac ( 851.04K ) Number of downloads: 62

It has artifacts on the right channel, noticeable as distortions on the faded in rythm sound, quite easy to ABX with no real differences to 1.1 and 1.0.2.
With a forced framesize of 5 ms though the artifacts get more subtle, and finally really hard to ABX at 224 kb/s CBR, so I think that everything above should be transparent for me. I'm not sure about 2.5 ms ones, it might be even better for the artifact itself, but in exchange the frequency resolution suffers.

This post has been edited by Gainless: May 23 2013, 17:26
Go to the top of the page
+Quote Post
jmvalin
post May 24 2013, 08:43
Post #32


Xiph.org Speex developer


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



QUOTE (Gainless @ May 23 2013, 12:15) *
Here's another sample that could benefit from shorter framesizes:

Attached File  Reloaded_Part_2__Sample_.flac ( 851.04K ) Number of downloads: 62

It has artifacts on the right channel, noticeable as distortions on the faded in rythm sound, quite easy to ABX with no real differences to 1.1 and 1.0.2.
With a forced framesize of 5 ms though the artifacts get more subtle, and finally really hard to ABX at 224 kb/s CBR, so I think that everything above should be transparent for me. I'm not sure about 2.5 ms ones, it might be even better for the artifact itself, but in exchange the frequency resolution suffers.


For 20 ms frames, up to what bitrate can you ABX? Also, if you swap the left and right channels on the input, do you now hear the artefact on the left?
Go to the top of the page
+Quote Post
Gainless
post Jun 2 2013, 21:41
Post #33





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



QUOTE (jmvalin @ May 24 2013, 09:43) *
QUOTE (Gainless @ May 23 2013, 12:15) *
Here's another sample that could benefit from shorter framesizes:

Attached File  Reloaded_Part_2__Sample_.flac ( 851.04K ) Number of downloads: 62

It has artifacts on the right channel, noticeable as distortions on the faded in rythm sound, quite easy to ABX with no real differences to 1.1 and 1.0.2.
With a forced framesize of 5 ms though the artifacts get more subtle, and finally really hard to ABX at 224 kb/s CBR, so I think that everything above should be transparent for me. I'm not sure about 2.5 ms ones, it might be even better for the artifact itself, but in exchange the frequency resolution suffers.


For 20 ms frames, up to what bitrate can you ABX? Also, if you swap the left and right channels on the input, do you now hear the artefact on the left?

Sorry for answering so late, had a bit of problems with ear fatigue and decided to rest them a bit.
Anyway, at the last tests I could ABX the sample with 20 ms framesizes at 192 kb/s (CBR), but not with 5 ms ones. The 20 ms frames also produce other artifacts at lower bitrates, so I guess the winner is quite clear. As for swapping the channels, I've just done a quick test at 160 kb/s CBR and 5 ms frames and could quite easily ABX it, so I'm not significantly worse on that side. My hearing is indeed often a bit right panned though, so I tend to get artifacts on this side easier.
Btw a little question, is there any special type of artifacts you guys prefer to get pointed out, e.g. something that might respond better to some detector fixes?
Go to the top of the page
+Quote Post
ChristianK
post Jun 14 2013, 19:02
Post #34





Group: Members
Posts: 8
Joined: 14-June 13
Member No.: 108661



Hi, is this the place to also discus the latest version from the git or should it stick to the attached test build?
Go to the top of the page
+Quote Post
ChristianK
post Jun 16 2013, 22:02
Post #35





Group: Members
Posts: 8
Joined: 14-June 13
Member No.: 108661



Well, I'll just go ahead and post my question and findings here.

I have compiled opus and opus-tools from the git a few days back and compared it to the latest stable version (libopus 1.0.2).
Overall it's a really nice codec which performs very good (especially when you compare it with AAC hev1/2. Where AAC makes music sound a little different Opus still sounds natural).
However I've noticed that at around 42 Kbps it tends to lose a lot of stereo information, is this where Silk kicks in?

When comparing git with the latest stable (libopus 1.1-alpha-161-g28733d1 and 1.0.2) you can really hear a difference at 42 Kbps (git sounds better, no weird distortion but stable still has more stereo).
When going lower than that it now really just sounds like mono to me whereas AAC hev2 still sounds acceptable stereo-wise (and overall too for bitrates like 24 Kbps).

At Wikipedia I read that silk goes from 6 to 40 kbit/s and Celt supports 24 kbit/s to 128 kbit/s.
Although these are probably old figures from before the Opus merge, shouldn't there be more stereo information left at about 32 Kbps?

I've mainly tested this with My God Is the Sun from Queens of the Stone Age and some other songs of that album which seems pretty decent to test for compression artefacts.
Go to the top of the page
+Quote Post
jmvalin
post Jun 16 2013, 22:16
Post #36


Xiph.org Speex developer


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



QUOTE (ChristianK @ Jun 16 2013, 17:02) *
I have compiled opus and opus-tools from the git a few days back and compared it to the latest stable version (libopus 1.0.2).
Overall it's a really nice codec which performs very good (especially when you compare it with AAC hev1/2. Where AAC makes music sound a little different Opus still sounds natural).
However I've noticed that at around 42 Kbps it tends to lose a lot of stereo information, is this where Silk kicks in?

When comparing git with the latest stable (libopus 1.1-alpha-161-g28733d1 and 1.0.2) you can really hear a difference at 42 Kbps (git sounds better, no weird distortion but stable still has more stereo).
When going lower than that it now really just sounds like mono to me whereas AAC hev2 still sounds acceptable stereo-wise (and overall too for bitrates like 24 Kbps).


Actually, this has nothing to do with SILK and it's actually done on purpose. The newer version of the encoder gradually reduces the stereo width as the bitrate goes below 48 kbps. The exact amount hasn't been subject to much tuning yet and right now it's just linear between 48 kbps and 32 kb/s (at which point it's all mono). If you're interested in doing testing on this, I can show you how to control the width reduction. Also note that he-aac v2 works very differently from Opus when it comes to stereo because it only encodes a mono stream and then codes some "stereo cues" to fake the stereo effect on the decoder side. This is called parametric stereo and is not something Opus supports.
Go to the top of the page
+Quote Post
ChristianK
post Jun 17 2013, 19:10
Post #37





Group: Members
Posts: 8
Joined: 14-June 13
Member No.: 108661



Yes, I'm curious on how to control the stereo.
Do I need to patch something or is there a switch for it?
Go to the top of the page
+Quote Post
jmvalin
post Jun 17 2013, 19:25
Post #38


Xiph.org Speex developer


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



QUOTE (ChristianK @ Jun 17 2013, 14:10) *
Yes, I'm curious on how to control the stereo.
Do I need to patch something or is there a switch for it?


You actually need to patch the code. In src/opus_encoder.c, around line 1633, you should see:

QUOTE
if (st->mode != MODE_HYBRID || st->stream_channels==1)
st->silk_mode.stereoWidth_Q14 = IMIN((1<<14),IMAX(0,st->bitrate_bps-32000));


You should replace the second line simply with:
st->silk_mode.stereoWidth_Q14 = your_value;

Where your_value should be between 0 and 16384 where 0 mean "collapse to mono" and 16384 means "keep stereo without width reduction".

If you can figure out the optimal width for several bit-rates, I can change the code to reflect that.
Go to the top of the page
+Quote Post
ChristianK
post Jun 17 2013, 21:22
Post #39





Group: Members
Posts: 8
Joined: 14-June 13
Member No.: 108661



QUOTE (jmvalin @ Jun 17 2013, 20:25) *
Where your_value should be between 0 and 16384 where 0 mean "collapse to mono" and 16384 means "keep stereo without width reduction".

If you can figure out the optimal width for several bit-rates, I can change the code to reflect that.

Tried it out and it works just like you said.
I'll try to find some time to play with that number and see if I figure out what sounds best.
A quick test suggests that it could be lowered a bit.

One quick question: does or could it hurt that I decode these newer files with libopus 1.0.2 through gstreamer or should I use the new opusdec?
(I've made the git compiled version portable in order to easily compare side by side.)
Go to the top of the page
+Quote Post
jmvalin
post Jun 18 2013, 00:23
Post #40


Xiph.org Speex developer


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



QUOTE (ChristianK @ Jun 17 2013, 16:22) *
One quick question: does or could it hurt that I decode these newer files with libopus 1.0.2 through gstreamer or should I use the new opusdec?
(I've made the git compiled version portable in order to easily compare side by side.)


You can decode with any version of the decoder. The Opus format is frozen and any change we make is just encoder-side improvements.
Go to the top of the page
+Quote Post
kabal4e
post Jun 18 2013, 23:06
Post #41





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



QUOTE
You should replace the second line simply with:
st->silk_mode.stereoWidth_Q14 = your_value;

Hi there!
To encourage a wider audience of people with poor compilation skills, such as myself, to fine-tune the stereo width. Could you guys post a win32 build of opus-tools with that 'stereo-width' paratemtre adjustable through the comand line? So, instead of tweaking the code every time we could change this value by hand and if it's not set up by user it would use standard OPUS behaviour.

Cheers,
A

This post has been edited by kabal4e: Jun 18 2013, 23:13
Go to the top of the page
+Quote Post
Bostedclog
post Jun 25 2013, 18:00
Post #42





Group: Members
Posts: 14
Joined: 29-December 11
Member No.: 96111



Could you tell me which opus encoder we should be using now.The link in the Pre Beta build thread
Greg posted a new win32 build of opus-tools at https://people.xiph.org/~greg/opus-tools_58d80ab.zip (updated build with bugfix

Or the one in this thread? Many thanks.
Go to the top of the page
+Quote Post
ChristianK
post Jun 30 2013, 20:50
Post #43





Group: Members
Posts: 8
Joined: 14-June 13
Member No.: 108661



QUOTE (jmvalin @ Jun 18 2013, 01:23) *
You can decode with any version of the decoder. The Opus format is frozen and any change we make is just encoder-side improvements.

Good, I was under that impression but it couldn't hurt to ask.
I have to excuse for the fact that I have not come up with any real results yet, I've been quite busy and it is actually a lot harder than I initially thought.
I've tried a lot of encodes to point that it almost drove me mad and I think that around a bitrate of 42 Kbps music does sound a little bit better with just a bit more stereo.
Lower than that (<40) currently doesn't seem favourable because it makes the sound crackle more.
Go to the top of the page
+Quote Post
IgorC
post Jul 1 2013, 04:40
Post #44





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



Previously I gave a try to new temporal VBR at 48 kbps. It supposedly should be better at 48 kbps and less useful at higher bitrate. For a good surprise it's usefull at 64 kbps too, the same way as at 48 kbps.
Tested material "Opus temporal VBR 64 kbps.zip" from https://drive.google.com/folderview?id=0Byv...amp;usp=sharing
Go to the top of the page
+Quote Post
Gainless
post Jul 4 2013, 15:03
Post #45





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



A question:
Does the tonality detector inside Opus differentiate between "harder" and "easier" tonal stuff?
I'm asking because I've seen that there are e.g. some notes on acoustic guitars that seem to be harder for Opus than other ones, mostly somewhere in the low mid section. Here's an example:

Attached File  Velvet_Black__Sample_.flac ( 1.3MB ) Number of downloads: 96
(The full track can be downloaded here)

The two repeating notes from the low mid, starting after the first half second, stick out as the ones with the obviously loudest distortions, no matter if encoded in VBR or CBR. Maybe quantization noise due to the low voulme plays a role here either, but it's also the same type of tonal character that makes problems in all the other acoustic guitar samples that I've heard so far, the rest of the strings ever sounded noticeably better.

This post has been edited by Gainless: Jul 4 2013, 15:40
Go to the top of the page
+Quote Post

2 Pages V  < 1 2
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: 17th April 2014 - 23:25