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

Opus 1.1a BABYEATER build

Ever mindful of the world's population problems, the Opus development team is excited to present a new highly experimental build of Opus which is expected to eat 100% more babies than prior editions. It is also expected have (potentially) improved transient handling performance:

https://people.xiph.org/~greg/opus-tools_ba...ater-deluxe.zip  (Edit: replaced with updated version, see below)

What this does is adapts the frame-size dynamically based on transient analysis prior to encoding.  Leave the opus-tools framesize knob alone (in this test build it controls the amount of look-ahead used for the analysis, and 60ms is the default and only tested value).

It would be super-helpful to compare this with the regular 1.1 alpha at various rates and point us to any interesting results you find (e.g. where it does obviously worse or better, or where it catches fire and/or eats household pets instead of babies). Obviously you shouldn't be encoding your music archives with this stuff yet.

Opus 1.1a BABYEATER build

Reply #1
What this does is adapts the frame-size dynamically based on transient analysis prior to encoding.  Leave the opus-tools framesize knob alone (in this test build it controls the amount of look-ahead used for the analysis, and 60ms is the default and only tested value).

Interesting. Does this apply only to the MDCT coding at > 32 kbps, or also to the low-bitrate speech coder? And: is this encoder tuning an attempt to exploit some of the freedom of higher-delay codecs? What's the codec delay then? 60 ms look-ahead + 20 ms framing = 80 ms?

Chris
If I don't reply to your reply, it means I agree with you.

Opus 1.1a BABYEATER build

Reply #2
Interesting. Does this apply only to the MDCT coding at > 32 kbps, or also to the low-bitrate speech coder? And: is this encoder tuning an attempt to exploit some of the freedom of higher-delay codecs? What's the codec delay then? 60 ms look-ahead + 20 ms framing = 80 ms?


This is only for MDCT (not sure what this even does to SILK mode right now). And indeed it's an attempt to exploit higher delays. In the current version, it means the frame size is variable between 2.5 and 20 ms, with 42.5 ms of theoretical lookahead. In practice, I guess the fact that the frame size varies probably brings the look ahead to 60 ms. The libopus  code is actually flexible BTW (unlike this early version of opusenc), you can make use of variable frame size even with no extra "theoretical look-ahead" (though you obviously still pay for the cost of having the frame size change).

Opus 1.1a BABYEATER build

Reply #3
(unlike this early version of opusenc), you can make use of variable frame size even with no extra "theoretical look-ahead" (though you obviously still pay for the cost of having the frame size change).
You can request a smaller "frame size" (which, in this means framesize + analysis lookahead) from opusenc and it should do the right thing. I just didn't test it, and I didn't think results from that would be interesting yet.

Opus 1.1a BABYEATER build

Reply #4
eig sample has the issue.

_http://depositfiles.org/files/geu06nlcu
Opus 1.1a --bitrate 95 kbps
Opus BE (babyeater) --bitrate 96 kbps

First two samples are just there for warming up.

Opus 1.1a BABYEATER build

Reply #5
At 192 kbps it does slightly better at this sample:
Sycho Active

The artifact at the 2nd kick is still pretty clear, but seems to be a resampling issue (SoX gives the same audible results)

With Muse Breaks it still gives the same old glitches, though, I think even a few more.
[attachment=7351:Muse_Bre..._Sample_.flac]

Opus 1.1a BABYEATER build

Reply #6
OK, I was able to identify at least one bug. See if this new build is any better.


Opus 1.1a BABYEATER build

Reply #8
The artifact at the 2nd kick is still pretty clear, but seems to be a resampling issue (SoX gives the same audible results)


If you're getting audible issues with good resampling, then the problem is clipping— codec can't help that.  Try opusdec -gain -6  to attenuate it a bit.

What rate setting are you hearing artifacts at for muse?

Opus 1.1a BABYEATER build

Reply #9
OK, I was able to identify at least one bug. See if this new build is any better.

Nope, sorry, still the same artifacts at 192 kbps for both samples.

If you're getting audible issues with good resampling, then the problem is clipping— codec can't help that.  Try opusdec -gain -6  to attenuate it a bit.

Have tried it didn't change anything. I've also done another SoX conversion with a gain reduced version of the sample, so there would be no clipping at all (at least according to the RG peak) and found that I could still ABX it. Clipping doesn't seem to be the problem, but maybe some flaw in general? I'm not that familiar with resampling, so I just used "best" quality, without touching the Passband and Phase response.

What rate setting are you hearing artifacts at for muse?

192 kbps VBR. The glitches appear at some kicks, when some kind of cymbal like (a bit like sand paper) sound is faded in.

Opus 1.1a BABYEATER build

Reply #10
192 kbps VBR. The glitches appear at some kicks, when some kind of cymbal like (a bit like sand paper) sound is faded in.


Can you try all three versions (1.0.x, 1.1-alpha and babyeater) and tell us how they compare on that sample? Also, does the artefact eventually goes away as the bitrate increases?

Opus 1.1a BABYEATER build

Reply #11
192 kbps VBR. The glitches appear at some kicks, when some kind of cymbal like (a bit like sand paper) sound is faded in.


Can you try all three versions (1.0.x, 1.1-alpha and babyeater) and tell us how they compare on that sample? Also, does the artefact eventually goes away as the bitrate increases?

Sure, done a little test with all three versions now (1.0.1, 1.1 alpha, BE deluxe). 1.0.1 performed better than the other two, pretty close to transparency at 192 kbps and not ABXable at 320 kbps, while 1.1 and BE couldn't achieve transparency even at that high bitrate.

Opus 1.1a BABYEATER build

Reply #12
Sure, done a little test with all three versions now (1.0.1, 1.1 alpha, BE deluxe). 1.0.1 performed better than the other two, pretty close to transparency at 192 kbps and not ABXable at 320 kbps, while 1.1 and BE couldn't achieve transparency even at that high bitrate.


That information is very useful. Could you try comparing just 1.0.x to 1.1 alpha, but in CBR mode? That will tell us whether the problem is rate related or somewhere else (e.g. transient detector). Also, it's not always possible, but if you were able to pinpoint the most obvious artefact with ms accuracy, it would give me a better chance to investigate.

Opus 1.1a BABYEATER build

Reply #13
That information is very useful. Could you try comparing just 1.0.x to 1.1 alpha, but in CBR mode? That will tell us whether the problem is rate related or somewhere else (e.g. transient detector).

Ok, after a bit a bit more testing I can't really tell for sure which of them wins at CBR. 1.1 was the one I could still ABX at 320 kbps, so maybe 1.0.1 is a bit better, but it was pretty hard with both above 256 kbps.
Also, it's not always possible, but if you were able to pinpoint the most obvious artefact with ms accuracy, it would give me a better chance to investigate.

It's around second 7,490. Visually I can't see any differences between the WAV and the Opus encodes, so the exact place might differ a few ms.

Opus 1.1a BABYEATER build

Reply #14
It's around second 7,490. Visually I can't see any differences between the WAV and the Opus encodes, so the exact place might differ a few ms.


Thanks, this is actually very helpful. There's a transient around there, but it doesn't seem to be detected. Can you try encoding with --framesize 5 or --framesize 2.5 and see if this particular artefact is still present (it may cause other artefacts)?

Opus 1.1a BABYEATER build

Reply #15
It's around second 7,490. Visually I can't see any differences between the WAV and the Opus encodes, so the exact place might differ a few ms.


Thanks, this is actually very helpful. There's a transient around there, but it doesn't seem to be detected. Can you try encoding with --framesize 5 or --framesize 2.5 and see if this particular artefact is still present (it may cause other artefacts)?

  Switching to 5 ms framesize and VBR made the artifact almost totally disappear, now it's quite subtle at 128 kb/s and barely ABXable 192 kb/s anymore with both versions, pretty amazing.

Opus 1.1a BABYEATER build

Reply #16
It's around second 7,490. Visually I can't see any differences between the WAV and the Opus encodes, so the exact place might differ a few ms.


Thanks, this is actually very helpful. There's a transient around there, but it doesn't seem to be detected. Can you try encoding with --framesize 5 or --framesize 2.5 and see if this particular artefact is still present (it may cause other artefacts)?

  Switching to 5 ms framesize and VBR made the artifact almost totally disappear, now it's quite subtle at 128 kb/s and barely ABXable 192 kb/s anymore with both versions, pretty amazing.



This confirms what I suspected. The transient detector just missed the transient, so it ended up using a long MDCT. That's why forcing a shorter frame size made the problem go away. Of course it's not a fix since 5 ms frames could cause other issues. I'll work on this a bit more.

Opus 1.1a BABYEATER build

Reply #17
That's nice to hear, would be great if it could get fixed in the next version

Opus 1.1a BABYEATER build

Reply #18
That's nice to hear, would be great if it could get fixed in the next version


I just checked in a fix in git. It's basically a second (simplified) frequency-domain transient detector that catches a few of the transients that are missed by the main detector. In the case of the transient at 7.5s in your file, the reason it wasn't caught by the main detector is that the transient was in the mid-range, but drowned in HF noise. Anyway, until I can get you actual builds, here's what it sounds like with the fix at 128 kb/s and 192 kb/s.

Opus 1.1a BABYEATER build

Reply #19
Sound both pretty transparent, thanks for the effort!

Opus 1.1a BABYEATER build

Reply #20
Sound both pretty transparent, thanks for the effort!


Good to hear :-) Thanks very much for your help on this. It's an important part of how we improve Opus over time -- fixing one minor issue at a time.

Opus 1.1a BABYEATER build

Reply #21
Hello!
I have some files: original wav 16khz ultrasound - 48khz file and others recorded in aac, vorbis, mp3, opus. I know that it is not a real music, but opus sounds very bad here. Also it takes too much space unlike the others. There are 5 audio files and 5 spectrograms for each file. In cause of Spek doesn't support OPUS, I encoded it back to wav. What do you think about it? Is that a problem or not?

P.S.:Opus was encoded with the latest babyeater) and all the same is with 1.1.x

Opus 1.1a BABYEATER build

Reply #22
Hello!
I have some files: original wav 16khz ultrasound - 48khz file and others recorded in aac, vorbis, mp3, opus. I know that it is not a real music, but opus sounds very bad here. Also it takes too much space unlike the others. There are 5 audio files and 5 spectrograms for each file. In cause of Spek doesn't support OPUS, I encoded it back to wav. What do you think about it? Is that a problem or not?

P.S.:Opus was encoded with the latest babyeater) and all the same is with 1.1.x

Managed to compile the latest opusenc.exe, so I'll attempt to answer your post.

I noticed that in the files you provided, the .opus file used the following options:
Code: [Select]
ENCODER_OPTIONS                : --bitrate 512 --vbr --ignorelength

That bitrate would inflate the file size unnecessarily. However, when I used the default settings (I think it defaults to --bitrate 64) the opus filesize came out to be 458KB, which is still a fair bit higher than your MP3 file. I'm putting that down to the codec finding it difficult to compress pure sine waves.

There didn't seem to be any quality loss with the opus file though - it didn't sound terrible to me. I was unable to tell the difference between playing the WAV, Opus and MP3 files. I'm no listening expert though - what kind of problems did you hear?

Opus 1.1a BABYEATER build

Reply #23
I'm not a listening expert. However, I was interested in seeing how the progress made in Opus has progressed over the last few months. Using the latest code from opus-tools (from git://git.xiph.org/opus-tools.git ) I compiled the binary, obtained the the three previously-worst Opus samples from the hydrogenaudio listening test and re-encoded the lossless samples at 64kb/s.
http://people.xiph.org/~greg/opus/ha2011/

The samples chosen were numbers 1, 2 and 26. Here are the results of my (unofficial) ABX listening test.

Sample 1 - Acoustic guitar solo:
In the original Opus encoding there was quite a bit of distortion on the guitar notes. It was very noticeable and was significantly worse than the lossless version.

With the new opusenc, the distortion virtually disappeared. I could still just barely differentiate between the lossless and opus versions of the file, but it was very close to a perfect score.


Sample 2 - Harpsichord solo:
There is a large amount of distortion on the harpsichord notes in the original encoding.

Again, with the new opusenc the distortion disappeared. Similarly to sample 1, could just barely tell the difference between the opus-encoded version and the lossless one.

Sample 26 - Guitar mix (acoustic and electric):
In the original opus encoding, the acoustic guitar sounds very tinny and the electric guitar loses some depth.

I wasn't able to tell the difference between the new opus version and the lossless version.

Conclusion
My amateur conclusion is that the latest version of the encoder (af25999bbd6aef6defcefebd489e1cf4abbcd867, 2013-02-25) fixes some significant issues which were causing distortion in some samples encoded with the version used for the listening test (CELT 0.11.2, March 2011).

I didn't test further to see whether the previously good samples had regressed at all. It would be interesting to see the results of another listening test take place once the Opus encoder v1.1 is officially released.

Opus 1.1a BABYEATER build

Reply #24
The samples encoded with the latest Opus version are attached, for those who are interested in listening to the difference. The samples encoded with an earlier Opus version and the lossless samples are available from the link in the previous post.