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

Opus 1.1-beta

Reply #1 –
Quote from: eahm on
http://lists.xiph.org/pipermail/opus/2013-July/002158.html
Please can anyone compile it for Windows so I can start testing?
https://people.xiph.org/~greg/opus-tools_11beta.zip

Let me know if it works at all— I just rebuilt my main system so I'm building that with a new toolchain.
Quote
I may just need to learn how to at least compile.

Thats always a good idea!

Opus 1.1-beta

Reply #2 –
Here:
I think U need Win7 or newer
Don't forget to post results

Opus 1.1-beta

Reply #3 –
Quote from: Anakunda on
Here:
I think U need Win7 or newer
Don't forget to post results
Hm I was going to check to make sure your executable was the right version, but I can't tell because its been put through some kind of binary obfuscation.

Opus 1.1-beta

Reply #4 –
What obfuscation do you mean?
Check opusenc --version

Opus 1.1-beta

Reply #6 –
Quote from: Anakunda on
What obfuscation do you mean?
Check opusenc --version
Sorry, I generally don't run third party binaries, especially not ones which have been through some kind of encryption which hides all the strings in them.  The substring libopus shows up nowhere in the DLL— but there isn't any way to build opus without that string.  I'm not sure what was done to those binaries, but they're gigantic and opaque.

Opus 1.1-beta

Reply #7 –
I've tried out a few samples and happy to report that the new beta sounds fantastic. To my ears, most samples sound close to transparent at 64 Kbps and completely transparent at 96 Kbps, except for a few known difficult ones which still sound pretty great. The new features make a big quality improvement in some cases (looking at you, harpsichord) and the previous glitches relating to extreme cases (e.g. sine wave sweeps) seem to have been ironed out.

Very impressed guys. This deserves to get adopted very quickly and I'd highly recommend it becomes the default choice for all new projects requiring non-lossless audio compression.
 

Opus 1.1-beta

Reply #8 –
Quote from: NullC on
Sorry, I generally don't run third party binaries, especially not ones which have been through some kind of encryption which hides all the strings in them.  The substring libopus shows up nowhere in the DLL— but there isn't any way to build opus without that string.  I'm not sure what was done to those binaries, but they're gigantic and opaque.

They're UPX-compressed. Only the x86 version though, the amd64 files are not compressed.

Opus 1.1-beta

Reply #9 –
Quote from: Lear on
They're UPX-compressed. Only the x86 version though, the amd64 files are not compressed.


Exactly

One question though, which version of the routines fixed vs. float introduce better psychoaccoustic model?

Opus 1.1-beta

Reply #10 –
Lovely, been waiting for Opus to update it, was some time ago.

Hope that it improve low bitrate peformance, read through, and didn´t quite get the lot of it, but it seems they have made quite the optimization on different scenarios.

Opus 1.1-beta

Reply #11 –
Nice to see the beta finally up here. Apart from the temporal VBR and surround tunings there doesn't seem to be much of a difference to the exp build from this topic though, same peaks and bitrates.
NullC, what's about the several tonal samples that are ABXable up to 192 kbps, are they maybe fixable in the future? I've also made more or less a suggestion here about handling tonality a bit more varied by giving more bits to certain notes than to other ones, how realistic/sensible does that seem to you?

Opus 1.1-beta

Reply #12 –
Quote from: RobertM on
I've tried out a few samples and happy to report that the new beta sounds fantastic. To my ears, most samples sound close to transparent at 64 Kbps and completely transparent at 96 Kbps, except for a few known difficult ones which still sound pretty great. The new features make a big quality improvement in some cases (looking at you, harpsichord) and the previous glitches relating to extreme cases (e.g. sine wave sweeps) seem to have been ironed out.

1.1 beta was simply fantastic here too at 96 kbps on my smartphone using Rockbox for Android.
In my experience Opus 1.1 beta @ 80 kbps is on par with the best MP3 encoders (LAME -V 5  and Helix) @ 128 kbps VBR. That's the first time when alternative format can go that low.

Opus 1.1-beta

Reply #13 –
That is good news actually!    But what is necessary to make Opus real competitor to MP3 & AAC from my point of view:
1) Beat AAC in low and high bitrates
2) Have good implementation of decoder for different hardware devices
3) Be well supported in hardware area (car audio, portable players etc if 2) is satisfied)
4) Wide promotion of Opus benefits

It is very difficult to take a worthy share on the market.
I'd like to say many thanks to Opus developers and good luck for all open source fans!

Opus 1.1-beta

Reply #14 –
For music playback, they need native support in Android. Native support in iPhoneOS would be nice as well, but it's unlikely that Apple would care.

Opus 1.1-beta

Reply #15 –
Quote from: alter4 on
That is good news actually!    But what is necessary to make Opus real competitor to MP3 & AAC from my point of view:
1) Beat AAC in low and high bitrates

You can set your own test and find out a current state. 


Quote from: alter4 on
2) Have good implementation of decoder for different hardware devices

While there is a room for performance optimizations it was already 3 generations of smartphones and tablets those can decode Opus using less than 5% of CPU resources  (and that is only a single core) resulting in very long battery life.
The exception is Sansa portable media players and so. It comes with an old ARM9 family processors.  They could replace it with an economic Cortex A5 which is much faster and more energy efficient.


Also Google has announced support for Opus in WebM media format. It means Android OS will have Opus support in a future versions as WebM is part of it.

Opus 1.1-beta

Reply #16 –
Quote from: IgorC on
The exception is Sansa portable media players and so. It comes with an old ARM9 family processors.  They could replace it with an economic Cortex A5 which is much faster and more energy efficient.

Yeah, on my clip+ mpc runs for 16h, same as flac, while vobis only manages 12h and opus only 10h...

Opus 1.1-beta

Reply #17 –
Quote from: ChronoSphere on
Quote from: IgorC on
The exception is Sansa portable media players and so. It comes with an old ARM9 family processors.  They could replace it with an economic Cortex A5 which is much faster and more energy efficient.

Yeah, on my clip+ mpc runs for 16h, same as flac, while vobis only manages 12h and opus only 10h...


I'm surprised theres such a small difference between Vorbis and Opus.  Vorbis and MPC are pretty similar, while opus is probably 3-4x slower since we haven't optimized it too much yet.

Opus 1.1-beta

Reply #18 –
Quote from: ChronoSphere on
Quote from: IgorC on
The exception is Sansa portable media players and so. It comes with an old ARM9 family processors.  They could replace it with an economic Cortex A5 which is much faster and more energy efficient.

Yeah, on my clip+ mpc runs for 16h, same as flac, while vobis only manages 12h and opus only 10h...

You must test AAC and Opus 1.1 beta, please. I would actually like to buy a Clip Zip just to test codecs.

I have a Sansa E200, is there a plugin or app to test CPU usage, battery and running times? I don't really use it and it was a gift.

Opus 1.1-beta

Reply #19 –
Quote from: eahm on
Quote from: ChronoSphere on
Quote from: IgorC on
The exception is Sansa portable media players and so. It comes with an old ARM9 family processors.  They could replace it with an economic Cortex A5 which is much faster and more energy efficient.

Yeah, on my clip+ mpc runs for 16h, same as flac, while vobis only manages 12h and opus only 10h...

You must test AAC and Opus 1.1 beta, please. I would actually like to buy a Clip Zip just to test codecs.

I have a Sansa E200, is there a plugin or app to test CPU usage, battery and running times? I don't really use it and it was a gift.


http://www.rockbox.org/wiki/CodecPerforman...ARM926EJ_45S_41

http://www.hydrogenaudio.org/forums/index....showtopic=82125

Both use the same processor as the plus, but with the memory at different speeds (which hurts vorbis a lot).

Opus 1.1-beta

Reply #20 –
I knew about these test but codecs improved a lot since 2010, isn't time to test again?

Opus 1.1-beta

Reply #21 –
Quote from: saratoga on
I'm surprised theres such a small difference between Vorbis and Opus.  Vorbis and MPC are pretty similar, while opus is probably 3-4x slower since we haven't optimized it too much yet.
It might be because I tested them at different bitrates after completing a series of ABX tests. Here are the runtimes I'm getting atm:
Code: [Select]
Flac -8: 		16:09:49
mpc -192:		16:13:47
Wv -hh -b384Mx:	11:17:12
mp3 v0:			11:48:20
vorbis q5:		12:17:56
opus 160:		10:17:00
I usually take the preset trasparent to me +1 for my test (except for lossless, obviously). I wish opus would get to the same runtime as FLAC later on, but that's probably only going to happen after opus leaves beta status.

Quote from: eahm on
You must test AAC and Opus 1.1 beta, please. I would actually like to buy a Clip Zip just to test codecs.
I'm not sure re-testing with beta 1.1 will be of any use since as far as I know the decoding part is already frozen and there were no updates to rockbox. AAC was around mp3's performance from what I remember.

Opus 1.1-beta

Reply #22 –
Quote from: ChronoSphere on
I'm not sure re-testing with beta 1.1 will be of any use since as far as I know the decoding part is already frozen and there were no updates to rockbox.

Normative decoder output was "frozen" ~ 2 years ago with the bitstream freeze, but the decoder implementation is far from frozen. Aurélien Zanelli of Parrot SA got the ball rolling on some ARM optimization work. Monty said in his 1.1-beta demo that 64kbps stereo decode is now 74% faster on some ARM targets.

It is true that Rockbox hasn't yet incorporated the changes from upstream. In fact, AFAIK there are still a number of patches which Rockbox developer Nils Wallménius (n1s) sent to Xiph which were merged into Opus mainline > 9 months ago but haven't found their way into Rockbox yet.

From what I understand, 1.1-beta still has a good bit of room for improvement in the ARM ifft/imdct code.

There'd be some more savings (6-9MHz on a Clip?? ask saratoga) if Rockbox could build 48kHz-native firmware images and thus never have to resample Opus rather than always resampling to 44.1. That would also improve quality (saratoga's new cubic resampler is better and a little slower than the linear resampling they used to do, but it still impacts quality). Rockbox devs have said this is doable and expressed some interest but I'm not aware of any progress yet. At one point I was building my own rockbox and trying to familiarize myself enough with the code to see what I would need to work on, but I haven't done enough C lately to be quick at reading other people's code, and I ended up realizing I didn't have time to tackle it then.

If you're listening to low-bitrate audiobooks, you can already get good Opus battery life on current Rockbox-- the LP mode ("SILK mode"), for which no ifft/imdct is necessary, decodes so quickly (<18MHz) that even with the resampler it should be comparable to other codecs. In some cases passing ctls to try to give the encoder a hint that it should stick to LP mode will help battery life (though it may have some cost in quality).

Also, be sure to use the default 20ms max framesize (or larger - but larger frames are only worth thinking about at < ~16kbps or for things like RTP). Smaller frames can cost a lot more CPU to decode, and not having 20ms frames available causes worse quality at the same bitrate. The only benefit of a smaller max framesize is latency and that's not going to matter for stored file use.

Opus 1.1-beta

Reply #23 –
Quote from: jensend on
Quote from: ChronoSphere on
I'm not sure re-testing with beta 1.1 will be of any use since as far as I know the decoding part is already frozen and there were no updates to rockbox.

Normative decoder output was "frozen" ~ 2 years ago with the bitstream freeze, but the decoder implementation is far from frozen. Aurélien Zanelli of Parrot SA got the ball rolling on some ARM optimization work. Monty said in his 1.1-beta demo that 64kbps stereo decode is now 74% faster on some ARM targets.

It is true that Rockbox hasn't yet incorporated the changes from upstream. In fact, AFAIK there are still a number of patches which Rockbox developer Nils Wallménius (n1s) sent to Xiph which were merged into Opus mainline > 9 months ago but haven't found their way into Rockbox yet.


As far as I know, all of Nils work went into Rockbox first, so it should be there. Aurélien's stuff looks like a duplicate of the generic fixed point ASM code we have in rockbox. 

Quote from: jensend on
From what I understand, 1.1-beta still has a good bit of room for improvement in the ARM ifft/imdct code.


Yes, thats the main work to be done.  Opus does not use power of 2 FFTs, and so pretty much all the ARM optimized fixed point FFT code in existence can't be used because it can't do 60,120,240 and 480 point FFTs.  Fixing that would probably bring Opus decoding speed fairly close to Vorbis/MP3 (which have all assembly Fourier transforms and filterbanks in rockbox).

Quote from: jensend on
There'd be some more savings (6-9MHz on a Clip?? ask saratoga) if Rockbox could build 48kHz-native firmware images and thus never have to resample Opus rather than always resampling to 44.1.


This is now committed, and 48k output works on most devices.  Keep in mind though its either/or, so don't use 48k as the mixer frequency if you have a lot of 44.1k mp3 files.

Opus 1.1-beta

Reply #24 –
Quote from: jensend on
Also, be sure to use the default 20ms max framesize (or larger - but larger frames are only worth thinking about at < ~16kbps or for things like RTP). Smaller frames can cost a lot more CPU to decode, and not having 20ms frames available causes worse quality at the same bitrate. The only benefit of a smaller max framesize is latency and that's not going to matter for stored file use.

I simply use foobar's preset to encode at 160kbps, setting it to "custom" shows the command line
Code: [Select]
--bitrate 160 --vbr --ignorelength - %d

Should be using default frame size.

Quote from: saratoga on
This is now committed, and 48k output works on most devices.  Keep in mind though its either/or, so don't use 48k as the mixer frequency if you have a lot of 44.1k mp3 files.

I got the dev build for clip+, the option is "frequency" in "playback settings", right? Is it planned to make the behaviour more flexible, i.e. switch mixer frequency automatically depending on input? Sorry for OT, but why does that have to be a manual switch process in the first place