IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
Opus 1.1a BABYEATER build
NullC
post Feb 11 2013, 21:51
Post #1





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



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
Go to the top of the page
+Quote Post
C.R.Helmrich
post Feb 11 2013, 22:57
Post #2





Group: Developer
Posts: 681
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



QUOTE (NullC @ Feb 11 2013, 21:51) *
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.
Go to the top of the page
+Quote Post
jmvalin
post Feb 11 2013, 23:24
Post #3


Xiph.org Speex developer


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



QUOTE (C.R.Helmrich @ Feb 11 2013, 16:57) *
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).
Go to the top of the page
+Quote Post
NullC
post Feb 12 2013, 00:46
Post #4





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



QUOTE (jmvalin @ Feb 11 2013, 14:24) *
(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.
Go to the top of the page
+Quote Post
IgorC
post Feb 12 2013, 09:45
Post #5





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



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.

This post has been edited by IgorC: Feb 12 2013, 09:54
Go to the top of the page
+Quote Post
Gainless
post Feb 12 2013, 12:52
Post #6





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



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


This post has been edited by Gainless: Feb 12 2013, 13:36
Go to the top of the page
+Quote Post
jmvalin
post Feb 12 2013, 23:23
Post #7


Xiph.org Speex developer


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



OK, I was able to identify at least one bug. See if this new build is any better.
Go to the top of the page
+Quote Post
IgorC
post Feb 12 2013, 23:51
Post #8





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



It's getting better
http://pastebin.com/KGLCyMRJ
Go to the top of the page
+Quote Post
NullC
post Feb 13 2013, 01:16
Post #9





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



QUOTE (Gainless @ Feb 12 2013, 03:52) *
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
Go to the top of the page
+Quote Post
Gainless
post Feb 13 2013, 21:54
Post #10





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



QUOTE (jmvalin @ Feb 12 2013, 23:23) *
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.

QUOTE (NullC @ Feb 13 2013, 01:16) *
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.

QUOTE (NullC @ Feb 13 2013, 01:16) *
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
Go to the top of the page
+Quote Post
jmvalin
post Feb 13 2013, 22:17
Post #11


Xiph.org Speex developer


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



QUOTE (Gainless @ Feb 13 2013, 15:54) *
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?
Go to the top of the page
+Quote Post
Gainless
post Feb 14 2013, 13:35
Post #12





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



QUOTE (jmvalin @ Feb 13 2013, 22:17) *
QUOTE (Gainless @ Feb 13 2013, 15:54) *
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.
Go to the top of the page
+Quote Post
jmvalin
post Feb 14 2013, 20:00
Post #13


Xiph.org Speex developer


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



QUOTE (Gainless @ Feb 14 2013, 07:35) *
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.
Go to the top of the page
+Quote Post
Gainless
post Feb 15 2013, 20:42
Post #14





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



QUOTE (jmvalin @ Feb 14 2013, 20:00) *
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.
QUOTE (jmvalin @ Feb 14 2013, 20:00) *
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
Go to the top of the page
+Quote Post
jmvalin
post Feb 16 2013, 04:58
Post #15


Xiph.org Speex developer


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



QUOTE (Gainless @ Feb 15 2013, 14:42) *
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)?
Go to the top of the page
+Quote Post
Gainless
post Feb 16 2013, 11:56
Post #16





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



QUOTE (jmvalin @ Feb 16 2013, 04:58) *
QUOTE (Gainless @ Feb 15 2013, 14:42) *
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)?

blink.gif 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.
Go to the top of the page
+Quote Post
jmvalin
post Feb 16 2013, 19:42
Post #17


Xiph.org Speex developer


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



QUOTE (Gainless @ Feb 16 2013, 05:56) *
QUOTE (jmvalin @ Feb 16 2013, 04:58) *
QUOTE (Gainless @ Feb 15 2013, 14:42) *
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)?

blink.gif 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.
Go to the top of the page
+Quote Post
Gainless
post Feb 16 2013, 20:40
Post #18





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



That's nice to hear, would be great if it could get fixed in the next version smile.gif
Go to the top of the page
+Quote Post
jmvalin
post Feb 18 2013, 06:43
Post #19


Xiph.org Speex developer


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



QUOTE (Gainless @ Feb 16 2013, 14:40) *
That's nice to hear, would be great if it could get fixed in the next version smile.gif


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.
Attached File(s)
Attached File  Muse_128_kbps.wav ( 3.06MB ) Number of downloads: 98
Attached File  Muse_192_kbps.wav ( 3.06MB ) Number of downloads: 80
 
Go to the top of the page
+Quote Post
Gainless
post Feb 18 2013, 22:12
Post #20





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



Sound both pretty transparent, thanks for the effort!

This post has been edited by Gainless: Feb 18 2013, 22:13
Go to the top of the page
+Quote Post
jmvalin
post Feb 18 2013, 23:53
Post #21


Xiph.org Speex developer


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



QUOTE (Gainless @ Feb 18 2013, 16:12) *
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.
Go to the top of the page
+Quote Post
Omicron
post Feb 21 2013, 13:01
Post #22





Group: Members
Posts: 9
Joined: 17-February 13
From: Kishinev
Member No.: 106693



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

This post has been edited by Omicron: Feb 21 2013, 13:02
Attached File(s)
Attached File  16KHz.rar ( 2.82MB ) Number of downloads: 90
 
Go to the top of the page
+Quote Post
RobertM
post Feb 25 2013, 11:21
Post #23





Group: Members
Posts: 12
Joined: 17-February 13
Member No.: 106691



QUOTE (Omicron @ Feb 21 2013, 22:01) *
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
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?
Go to the top of the page
+Quote Post
RobertM
post Feb 25 2013, 12:13
Post #24





Group: Members
Posts: 12
Joined: 17-February 13
Member No.: 106691



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.

This post has been edited by RobertM: Feb 25 2013, 12:18
Go to the top of the page
+Quote Post
RobertM
post Feb 26 2013, 06:55
Post #25





Group: Members
Posts: 12
Joined: 17-February 13
Member No.: 106691



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.
Attached File(s)
Attached File  Opus_samples_retest.zip ( 569.74K ) Number of downloads: 103
 
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: 19th April 2014 - 03:03