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 (https://people.xiph.org/~greg/opus-tools_babyeater.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.
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
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).
(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.
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.
At 192 kbps it does slightly better at this sample:
Sycho Active (http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=7217)
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]
OK, I was able to identify at least one bug. See if this new build (https://people.xiph.org/~greg/opus-tools_babyeater-deluxe.zip) is any better.
It's getting better
http://pastebin.com/KGLCyMRJ (http://pastebin.com/KGLCyMRJ)
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?
OK, I was able to identify at least one bug. See if this new build (https://people.xiph.org/~greg/opus-tools_babyeater-deluxe.zip) 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.
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?
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.
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.
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.
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)?
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.
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.
That's nice to hear, would be great if it could get fixed in the next version
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.
Sound both pretty transparent, thanks for the effort!
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.
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
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:
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?
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/ (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.
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.
what kind of problems did you hear?
It sounds intermitently and tinkling as compared with others. I think everybody can hear some kind of noise if listen carefully.
I think I've noticed a minor issue in the encoder, but I'm not familiar enough with the tech to understand exactly why it happens. See the attached files for an example. I created the sound a long time ago so it's not copyright in any way.
Sample 1: The 44.1kHz wav file shows some distortion in the output .opus file (and .wav file when decoded).
Sample 2: When the same original wav file from Sample 1 is first resampled to 48kHz using a different tool (Audacity), the encoded result sounds basically perfect, except for a small click at the beginning, but I suspect that's due to my player - the decoded wav output has no click.
Is this related to the resampler in the Opus encoder?
Edit: Updated attachment
Another sample making issues:
DWK Sample (http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=7484)
A sweeping sound in the background occurs synchronical to the bassline. I haven't tested it with the latest git version, though, but with the one here from the topic.
I can't reproduce your problem on mainline builds. Haven't tried with the babyeater build.
jmvalin has asked that people now use mainstream pre-1.1 builds and not the babyeater build (http://www.hydrogenaudio.org/forums/index.php?showtopic=99033&view=findpost&p=827269). The Babyeater builds were an experiment in variable frame sizes; jmvalin and NullC needed some feedback on their experiment, people responded, some major issues were found, and there's a good bit of work to be done before they ask people to test that again. In the meantime there are plenty of other innovations etc in the master builds that need more testing.
This again highlights the need for very visible instructions and warnings for prospective testers and an up-to-date link to builds (and possibly source snapshots/git revision numbers) the Opus devs would prefer people use for testing. I've proposed before that this be done with a sticky in the Opus subforum- indeed that's one of the main reasons I pushed for having a dedicated Opus subforum. When those instructions and warnings aren't very visible, we all have to keep correcting misconceptions. When people who want to help test don't know which builds to test, they may be wasting their time, and responding to their reports may waste developers' time. Simple steps to improve communication can go a long way to help.
The above post has been moved from the associated thread in Uploads (http://hydrogenaudio.org/forums/index.php?showtopic=100327).
Thanks for pointing out jmvalin’s request. It would have made sense for him or NullC to post that here, but better late and posted by someone else than never, I suppose. Should this thread be closed until further notice, in that case?
jmvalin has asked that people now use mainstream pre-1.1 builds and not the babyeater build (http://www.hydrogenaudio.org/forums/index.php?showtopic=99033&view=findpost&p=827269). The Babyeater builds were an experiment in variable frame sizes; jmvalin and NullC needed some feedback on their experiment, people responded, some major issues were found, and there's a good bit of work to be done before they ask people to test that again. In the meantime there are plenty of other innovations etc in the master builds that need more testing.
Actually, I recommended that people stop testing babyeater, but testing of 1.1-alpha and git is still very appreciated. The more testing we get, the quicker we can get to a final 1.1 release. We're interested in cases where 1.1 performs poorly, but what's even more useful is when 1.1 performs worse than 1.0.x, i.e. regressions.
I can't reproduce your problem on mainline builds. Haven't tried with the babyeater build.
I can't spot it anymore either since I switched to Direct Sound as output,
seems to be a problem with WASAPI (which I use in general) or my audio drivers, didn't take that possibility into account lol. Anyway, I'm very sorry for putting that "blinder", Opus is indeed fine on this one.
This again highlights the need for very visible instructions and warnings for prospective testers and an up-to-date link to builds (and possibly source snapshots/git revision numbers) the Opus devs would prefer people use for testing. I've proposed before that this be done with a sticky in the Opus subforum- indeed that's one of the main reasons I pushed for having a dedicated Opus subforum. When those instructions and warnings aren't very visible, we all have to keep correcting misconceptions. When people who want to help test don't know which builds to test, they may be wasting their time, and responding to their reports may waste developers' time. Simple steps to improve communication can go a long way to help.
Regularly updated builds would indeed be great, though.
The version 1.1a is the last testing build that works fine for me.
Opus 1.1 alpha version (not BABYEATER) (http://www.hydrogenaudio.org/forums/index.php?showtopic=99495)
In my opinion Opus 1.1a is already very good and there is still a room for improvements. But I think the development of a new video codec Daala should have a highest priority as bandwith savings are much higher for video.
Actually, I recommended that people stop testing babyeater, but testing of 1.1-alpha and git is still very appreciated.
I'm confused. By starting with 'Actually,' you give the impression that I said something false which you're correcting, but you apparently go on to repeat what I just said. Maybe by "pre-1.1" you thought I meant "1.0.x"? I meant "development versions leading up to 1.1," as could be seen from my mention of the innovations in git master.
Regularly updated builds would indeed be great, though.
Sure, it would, but that's not quite what I was asking for, and perhaps I didn't do well at making that clear.
Regardless of how frequent/up-to-date the
builds are, the
link needs to be up-to-date. In other words, whether they set up a Jenkins windows build artifact and prefer that testers use those bleeding edge builds or whether they only sporadically provide "blessed" builds for testers every few months, they need to communicate clearly about which builds prospective testers should use.
Right now, the most up-to-date advice on which build to test is quite frequently buried in some thread somewhere or stated in the (ephemeral, no public logs) IRC channel. In other words, it's effectively invisible to most people. This puts prospective testers, especially those on platforms like Windows where setting up a build environment takes knowledge and effort, at a real disadvantage. It is an unnecessary barrier, and it causes confusion, frustration, and useless bug reports.
Actually, I recommended that people stop testing babyeater, but testing of 1.1-alpha and git is still very appreciated.
I'm confused. By starting with 'Actually,' you give the impression that I said something false which you're correcting, but you apparently go on to repeat what I just said. Maybe by "pre-1.1" you thought I meant "1.0.x"? I meant "development versions leading up to 1.1," as could be seen from my mention of the innovations in git master.
Yeah, I thought you meant 1.0.x. Sorry for the confusion.