IPB

Welcome Guest ( Log In | Register )

6 Pages V   1 2 3 > »   
Reply to this topicStart new topic
Opus 1.1-beta, Officially released
eahm
post Jul 12 2013, 20:45
Post #1





Group: Members
Posts: 1056
Joined: 11-February 12
Member No.: 97076



http://lists.xiph.org/pipermail/opus/2013-July/002158.html

Please can anyone compile it for Windows so I can start testing?

I may just need to learn how to at least compile.

Thanks.


--------------------
/lwAsIimz
Go to the top of the page
+Quote Post
NullC
post Jul 13 2013, 00:29
Post #2





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



QUOTE (eahm @ Jul 12 2013, 12:45) *
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!

Go to the top of the page
+Quote Post
Anakunda
post Jul 13 2013, 00:39
Post #3





Group: Members
Posts: 456
Joined: 24-November 08
Member No.: 63072



Here:
I think U need Win7 or newer
Don't forget to post results
Attached File(s)
Attached File  opus-tools-0.1.6.7z ( 6.29MB ) Number of downloads: 306
 
Go to the top of the page
+Quote Post
NullC
post Jul 13 2013, 01:21
Post #4





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



QUOTE (Anakunda @ Jul 12 2013, 16:39) *
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.
Go to the top of the page
+Quote Post
Anakunda
post Jul 13 2013, 01:25
Post #5





Group: Members
Posts: 456
Joined: 24-November 08
Member No.: 63072



What obfuscation do you mean?
Check opusenc --version
Go to the top of the page
+Quote Post
eahm
post Jul 13 2013, 01:57
Post #6





Group: Members
Posts: 1056
Joined: 11-February 12
Member No.: 97076



QUOTE (NullC @ Jul 12 2013, 16:29) *
QUOTE (eahm @ Jul 12 2013, 12:45) *
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

Thanks.

Do you have an index page for /~greg/...?


--------------------
/lwAsIimz
Go to the top of the page
+Quote Post
NullC
post Jul 13 2013, 05:30
Post #7





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



QUOTE (Anakunda @ Jul 12 2013, 17:25) *
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.
Go to the top of the page
+Quote Post
RobertM
post Jul 13 2013, 08:38
Post #8





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



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.
Go to the top of the page
+Quote Post
Lear
post Jul 13 2013, 08:47
Post #9


VorbisGain developer


Group: Developer
Posts: 140
Joined: 10-January 02
Member No.: 973



QUOTE (NullC @ Jul 13 2013, 06:30) *
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.
Go to the top of the page
+Quote Post
Anakunda
post Jul 13 2013, 09:14
Post #10





Group: Members
Posts: 456
Joined: 24-November 08
Member No.: 63072



QUOTE (Lear @ Jul 13 2013, 09:47) *
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?
Go to the top of the page
+Quote Post
zerowalker
post Jul 13 2013, 10:06
Post #11





Group: Members
Posts: 266
Joined: 6-August 11
Member No.: 92828



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.
Go to the top of the page
+Quote Post
Gainless
post Jul 13 2013, 12:15
Post #12





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



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?

This post has been edited by Gainless: Jul 13 2013, 12:18
Go to the top of the page
+Quote Post
IgorC
post Jul 14 2013, 03:33
Post #13





Group: Members
Posts: 1554
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (RobertM @ Jul 13 2013, 04:38) *
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.
Go to the top of the page
+Quote Post
alter4
post Jul 14 2013, 11:23
Post #14





Group: Members
Posts: 109
Joined: 14-September 04
From: Belarus, Vitebsk
Member No.: 16992



That is good news actually! smile.gif 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!

This post has been edited by alter4: Jul 14 2013, 11:24
Go to the top of the page
+Quote Post
me7
post Jul 14 2013, 14:01
Post #15





Group: Members
Posts: 177
Joined: 23-August 06
Member No.: 34375



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.
Go to the top of the page
+Quote Post
IgorC
post Jul 15 2013, 17:39
Post #16





Group: Members
Posts: 1554
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (alter4 @ Jul 14 2013, 07:23) *
That is good news actually! smile.gif 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. wink.gif


QUOTE (alter4 @ Jul 14 2013, 07:23) *
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.
Go to the top of the page
+Quote Post
ChronoSphere
post Jul 15 2013, 19:12
Post #17





Group: Members
Posts: 489
Joined: 11-March 07
Member No.: 41384



QUOTE (IgorC @ Jul 15 2013, 18:39) *
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...
Go to the top of the page
+Quote Post
saratoga
post Jul 15 2013, 19:57
Post #18





Group: Members
Posts: 4907
Joined: 2-September 02
Member No.: 3264



QUOTE (ChronoSphere @ Jul 15 2013, 14:12) *
QUOTE (IgorC @ Jul 15 2013, 18:39) *
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.
Go to the top of the page
+Quote Post
eahm
post Jul 15 2013, 20:16
Post #19





Group: Members
Posts: 1056
Joined: 11-February 12
Member No.: 97076



QUOTE (ChronoSphere @ Jul 15 2013, 11:12) *
QUOTE (IgorC @ Jul 15 2013, 18:39) *
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.

This post has been edited by eahm: Jul 15 2013, 20:19


--------------------
/lwAsIimz
Go to the top of the page
+Quote Post
saratoga
post Jul 15 2013, 20:23
Post #20





Group: Members
Posts: 4907
Joined: 2-September 02
Member No.: 3264



QUOTE (eahm @ Jul 15 2013, 15:16) *
QUOTE (ChronoSphere @ Jul 15 2013, 11:12) *
QUOTE (IgorC @ Jul 15 2013, 18:39) *
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).
Go to the top of the page
+Quote Post
eahm
post Jul 15 2013, 20:44
Post #21





Group: Members
Posts: 1056
Joined: 11-February 12
Member No.: 97076



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

This post has been edited by eahm: Jul 15 2013, 20:45


--------------------
/lwAsIimz
Go to the top of the page
+Quote Post
ChronoSphere
post Jul 15 2013, 23:18
Post #22





Group: Members
Posts: 489
Joined: 11-March 07
Member No.: 41384



QUOTE (saratoga @ Jul 15 2013, 20:57) *
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
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 (eahm @ Jul 15 2013, 21:16) *
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.
Go to the top of the page
+Quote Post
jensend
post Jul 16 2013, 16:32
Post #23





Group: Members
Posts: 143
Joined: 21-May 05
Member No.: 22191



QUOTE (ChronoSphere @ Jul 15 2013, 16:18) *
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.
Go to the top of the page
+Quote Post
saratoga
post Jul 16 2013, 18:08
Post #24





Group: Members
Posts: 4907
Joined: 2-September 02
Member No.: 3264



QUOTE (jensend @ Jul 16 2013, 11:32) *
QUOTE (ChronoSphere @ Jul 15 2013, 16:18) *
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 (jensend @ Jul 16 2013, 11:32) *
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 (jensend @ Jul 16 2013, 11:32) *
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.
Go to the top of the page
+Quote Post
ChronoSphere
post Jul 16 2013, 19:06
Post #25





Group: Members
Posts: 489
Joined: 11-March 07
Member No.: 41384



QUOTE (jensend @ Jul 16 2013, 17:32) *
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
--bitrate 160 --vbr --ignorelength - %d

Should be using default frame size.

QUOTE (saratoga @ Jul 16 2013, 19:08) *
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
Go to the top of the page
+Quote Post

6 Pages V   1 2 3 > » 
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: 23rd August 2014 - 08:55