-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We just released Opus 1.1-rc, which should be the last step before the final 1.1 release. Compared to 1.1-beta, this new release further improves surround encoding quality. It also includes better tuning of surround and stereo for lower bitrates. The complexity has been reduced on all CPUs, but especially ARM, which now has Neon assembly for the encoder. At last, there are a few bugfixes. As usual, the code can be downloaded from: http://opus-codec.org/downloads/ Please give this release a try and report any issues on the mailing list or by joining the #opus channel on irc.freenode.net. The more testing we get, the faster we'll be able to release 1.1-final. Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlEhoAAoJEJ6/8sItn9q9LPQIAKT7j3SxEF6I+UvI9gGxJfKr B0rKrbj9/6PYRQ3VaZoxguPz0pdJNcKNV1r3b5GKU3aVZlB6v+sQTGwAti3e5dva YoRc8r5RS5dqMi0waIO94x3a+u4tuqSdw7X3nydyua0N2Svo52tmnrcRZd5ua1yD Z6oIiG/YFC/E1jS8c5Ac8F6MQ9O+QCoh4xpdvLrrLnmYQpQPlTNDLFNnPIwkirU/ hG8mz6pQCuJancy7rREjNPE8u5QrFmGrz0n7e2tkSgw4tTDbqT0TQv+JD2vUvSKf 0PMAASEGMZ50eq/A2lJAeS7Gbz0ywK+lphwHXAbRhjG46uYWqb1lrV3gaONueOQ=854e -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We just discovered some issues with the ARMv5E and Neon optimizations and have released 1.1-rc2 to address those. Other platforms are unaffected. Jean-Marc On 11/26/2013 02:06 AM, Jean-Marc Valin wrote:> We just released Opus 1.1-rc, which should be the last step before > the final 1.1 release. Compared to 1.1-beta, this new release > further improves surround encoding quality. It also includes better > tuning of surround and stereo for lower bitrates. The complexity > has been reduced on all CPUs, but especially ARM, which now has > Neon assembly for the encoder. At last, there are a few bugfixes. > > As usual, the code can be downloaded from: > http://opus-codec.org/downloads/ > > Please give this release a try and report any issues on the mailing > list or by joining the #opus channel on irc.freenode.net. The more > testing we get, the faster we'll be able to release 1.1-final. > > Cheers, > > Jean-Marc _______________________________________________ opus > mailing list opus at xiph.org > http://lists.xiph.org/mailman/listinfo/opus >-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSll14AAoJEJ6/8sItn9q9a2EIALXr3flnfkxCVCMEBQ1GHFqj pbmTIagk/Cu4KqKa+83gC0RAaoV+WVR0qlq1jFyx3JurIsUrjJBxH0BnWNB38A5W E6KDQrOVxCTHlbKgz3dKFARQXHYKnOxUNmOgKvAGoPBfHLXNM8Wfv0xTlIXa85Pg yvzUv1pC4Lq+jkMrVu9JcOviBZ/6vCpanAdcTbPiSrd84L9fjGLCKPVDo3kfy+K/ 2dMbnyBBm0kj2ykMaBRf9yeTF7FYr9NiLJ5qsLNz8Uv6tPDDu/neyXu6K0uvVMa0 xt3sMIazSKImaZnWxSehi/qI1OhQGc6mttjFonJSdq1n3nmSkRKpYSflTR3UqXs=ka39 -----END PGP SIGNATURE-----
We have now released a third release candidate. This one addressed issues with the fixed-point build, including a bad bug with CELT stereo. Floating-point builds were unaffected. Unless we discover other issues, expect the final 1.1 release real soon. In the mean time, please give this a try and report any problems. Jean-Marc On 11/27/2013 04:00 PM, Jean-Marc Valin wrote:> We just discovered some issues with the ARMv5E and Neon optimizations > and have released 1.1-rc2 to address those. Other platforms are > unaffected. > > Jean-Marc > > > On 11/26/2013 02:06 AM, Jean-Marc Valin wrote: >> We just released Opus 1.1-rc, which should be the last step before >> the final 1.1 release. Compared to 1.1-beta, this new release >> further improves surround encoding quality. It also includes better >> tuning of surround and stereo for lower bitrates. The complexity >> has been reduced on all CPUs, but especially ARM, which now has >> Neon assembly for the encoder. At last, there are a few bugfixes. > >> As usual, the code can be downloaded from: >> http://opus-codec.org/downloads/ > >> Please give this release a try and report any issues on the mailing >> list or by joining the #opus channel on irc.freenode.net. The more >> testing we get, the faster we'll be able to release 1.1-final. > >> Cheers, > >> Jean-Marc _______________________________________________ opus >> mailing list opus at xiph.org >> http://lists.xiph.org/mailman/listinfo/opus > > > _______________________________________________ > opus mailing list > opus at xiph.org > http://lists.xiph.org/mailman/listinfo/opus >
Hi list I'm writing some unit tests for a piece of software using the opus library for audio encoding before transfering though RTP. In order to test my RTP implementation I thought I would transfer an encoded 440Hz sinus, and then do a diff of the received/decoded signal. However, my strategy seems to fail completely since the recreated sinus looks nothing like the one in the decoded signal. So my question is; is the phase not likely to be preserved during opus encoding/decoding or did I simply make an error in my test code? I am aware that the diff should not be binary equivalent to the input signal, but my thought is to do an error calculation and accept the test if under a certain threshold. Kind regards Bent Bisballe Nyeng
Hi, You have just failed to take into account the fact that Opus introduces a fixed delay. Put in a more complex signal and you will see that it's not a phase change but a simple delay due to the look-ahead of the encoder. All (non-trivial) codecs do that. Jean-Marc On 12/04/2013 04:53 AM, Bent Bisballe Nyeng wrote:> Hi list > > I'm writing some unit tests for a piece of software using the opus > library for audio encoding before transfering though RTP. > In order to test my RTP implementation I thought I would transfer an > encoded 440Hz sinus, and then do a diff of the received/decoded signal. > However, my strategy seems to fail completely since the recreated sinus > looks nothing like the one in the decoded signal. > > So my question is; is the phase not likely to be preserved during opus > encoding/decoding or did I simply make an error in my test code? > > I am aware that the diff should not be binary equivalent to the input > signal, but my thought is to do an error calculation and accept the test > if under a certain threshold. > > Kind regards > Bent Bisballe Nyeng > _______________________________________________ > opus mailing list > opus at xiph.org > http://lists.xiph.org/mailman/listinfo/opus >