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: New opus test build (Read 38894 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

New opus test build

Reply #25
Igor, you may also take this sample into consideration, has the same issues:
[attachment=7527:DnB_Beat_Sample.flac]

New opus test build

Reply #26
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.

New opus test build

Reply #27
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.

New opus test build

Reply #28
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?

New opus test build

Reply #29
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 
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.

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.

 

New opus test build

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

[attachment=7532:Reloaded..._Sample_.flac]
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.

New opus test build

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

[attachment=7532:Reloaded..._Sample_.flac]
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?

New opus test build

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

[attachment=7532:Reloaded..._Sample_.flac]
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?

New opus test build

Reply #33
Hi, is this the place to also discus the latest version from the git or should it stick to the attached test build?

New opus test build

Reply #34
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.

New opus test build

Reply #35
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.

New opus test build

Reply #36
Yes, I'm curious on how to control the stereo.
Do I need to patch something or is there a switch for it?

New opus test build

Reply #37
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.

New opus test build

Reply #38
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.)

New opus test build

Reply #39
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.

New opus test build

Reply #40
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

New opus test build

Reply #41
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.

New opus test build

Reply #42
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.

New opus test build

Reply #43
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

New opus test build

Reply #44
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:

[attachment=7550:Velvet_B..._Sample_.flac] (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.