Opus 1.1a BABYEATER build Options

[NullC]

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.

This post has been edited by NullC: Feb 13 2013, 01:07

[Gainless]

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.
 Muse_Breaks_Rmx__Sample_.flac ( 1.13MB ) Number of downloads: 59


This post has been edited by Gainless: Feb 12 2013, 13:36

[NullC]

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?

This post has been edited by NullC: Feb 13 2013, 01:52

[Gainless]

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.

This post has been edited by Gainless: Feb 13 2013, 21:57

[jmvalin]

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?

[Gainless]

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.

[jmvalin]

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.

[Gainless]

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.

This post has been edited by Gainless: Feb 15 2013, 20:44

[jmvalin]

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)?

[Gainless]

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.

[jmvalin]

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.