Skip to main content

Topic: Opus 1.1-beta (Read 61756 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • jmvalin
  • [*][*][*][*][*]
  • Developer
Opus 1.1-beta
Reply #100
Yes, I am still having the same issue.
Is there somebody here who can build opus-tools with GCC instead?


Actually, I would still like to investigate what's going on with that build. I have been able to compare your Opus file with one on my machine and they diverge only after 10 frames, then converge again when the encoder switches to CELT. So I'd like to make sure that it's not a bug in Opus that only affects some compilers. That's why I'd need more information on the compiler, compile options, ...

  • Anakunda
  • [*][*][*][*][*]
Opus 1.1-beta
Reply #101
If so, Anakunda can you give more info on your build.


I don't know about anything except extended floating point precision. Now I'm to make a build with standard floating point and only minimum optimizations (those -O... and no Intel advanced optimizations like elevated architecture features or interprocedural things).
If this produces the same issues then I can't do anything more with that (or is a bug of codec self)

  • o-l-a-v
  • [*][*][*]
Opus 1.1-beta
Reply #102
If so, Anakunda can you give more info on your build.


I don't know about anything except extended floating point precision. Now I'm to make a build with standard floating point and only minimum optimizations (those -O... and no Intel advanced optimizations like elevated architecture features or interprocedural things).
If this produces the same issues then I can't do anything more with that (or is a bug of codec self)


My god. The quality at just 100kbps is amazing.
I've found no bugs yet.

  • Ajaja
  • [*]
Opus 1.1-beta
Reply #103
Is there somebody here who can build opus-tools with GCC instead?


  • LithosZA
  • [*][*][*]
Opus 1.1-beta
Reply #104
I am at work now and tested both Anakunda's and Ajaja's builds. Both seem to work except Anakunda couldn't accept FLAC input.
I will test again when I get home on the laptop that gave problems.

It still will be useful to know what compiler options + the exact compiler that was used that caused the issue. Just to determine if something can be changed in the code to be more friendly with that compiler.

  • Case
  • [*][*][*][*][*]
  • Developer (Donating)
Opus 1.1-beta
Reply #105
GCC 4.82 compile: [ Specified attachment is not available ]
MSVC 2013 compile: [ Specified attachment is not available ]
MSVC version seems quite a bit faster here. It requires SSE2 support from the processor.

  • LithosZA
  • [*][*][*]
Opus 1.1-beta
Reply #106
Ok, I have tested the new builds from Anakunda, Ajaja and Case and they all seem to work correctly.
EDIT: Ajaja and Case's builds support FLAC input. Had to use WAV input for Anakunda's build.
  • Last Edit: 27 November, 2013, 11:39:30 AM by LithosZA

  • eahm
  • [*][*][*][*][*]
Opus 1.1-beta
Reply #107
Thank you Case. Testing ASAP.
  • Last Edit: 27 November, 2013, 11:58:39 AM by eahm

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Opus 1.1-beta
Reply #108
I don't know about anything except extended floating point precision. Now I'm to make a build with standard floating point and only minimum optimizations (those -O... and no Intel advanced optimizations like elevated architecture features or interprocedural things).
If this produces the same issues then I can't do anything more with that (or is a bug of codec self)


Any way you can isolate which option was causing the problem using LithosZA's test? Also, could you try reproducing the original bad build and removing the following lines in celt/pitch.h:

#if defined(__SSE__) && !defined(FIXED_POINT)
#include "x86/pitch_sse.h"
#endif

That would help verifying that there's no issue with the SSE optimizations.

  • Anakunda
  • [*][*][*][*][*]
Opus 1.1-beta
Reply #109
Any way you can isolate which option was causing the problem using LithosZA's test?

I'd like to isolate it, can LithosZA give me some information how to reproduce the bug? and possibly upload the sample somewhere...

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Opus 1.1-beta
Reply #110
Any way you can isolate which option was causing the problem using LithosZA's test?

I'd like to isolate it, can LithosZA give me some information how to reproduce the bug? and possibly upload the sample somewhere...


So you can get the sample here. Then, run the command line:
opusenc --save-range range.txt --bitrate 24 smallProblem.flac output.opus

You can then compare the range.txt output. This is the broken range that LithosZA was generating, and here's the working range that I get on my machine. You can see that the two differ between lines 10 and 38.

  • lithoc
  • [*][*]
Opus 1.1-beta
Reply #111
hold your horses .... rc2 just released
  • Last Edit: 28 November, 2013, 03:42:21 AM by lithoc

  • zerowalker
  • [*][*][*][*]
Opus 1.1-beta
Reply #112
Are there any tests on how Opus competes against other codecs in overall with newer releases?

I doubt as it will probably wait till 1.1 is completed, but it seems to be fairly more active now which makes things interesting:)

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Opus 1.1-beta
Reply #113
hold your horses .... rc2 just released


rc2 is fixing issues with ARM assembly. For x86, there's absolutely no change compared to rc1.

  • darkbyte
  • [*][*][*]
Opus 1.1-beta
Reply #114
I wonder if this release fixes the IS stereo to mono downmix problem where channels cancels each other? Or this is entirely depends on the decoder being used?
WavPack -b4x4hc
Opus --cvbr --bitrate 256 --framesize 5

  • Anakunda
  • [*][*][*][*][*]
Opus 1.1-beta
Reply #115
Here's rc2 build, hopefully the issues are gone


  • jmvalin
  • [*][*][*][*][*]
  • Developer
Opus 1.1-beta
Reply #116
Here's rc2 build, hopefully the issues are gone


I don't have a Windows machine to test, but that would be surprising since the only thing that changed in rc2 compared to rc1 is ARM assembly.

  • the_weirdo
  • [*]
Opus 1.1-beta
Reply #117
I tested those builds by Case, Ajaja and Anakunda with command line posted by jmvalin here, and they all produce different results (and they are different from "working range").

I also tested with my build and it produces same results as "working range". I've attached my build in case someone want to try it out.
[ Specified attachment is not available ]
  • Last Edit: 29 November, 2013, 01:52:31 AM by the_weirdo

  • Brazil2
  • [*][*][*]
Opus 1.1-beta
Reply #118
I tested those builds by Case, Ajaja and Anakunda with command line posted by jmvalin here, and they all produce different results

A quick test encoding the same WAV 453 MB file on two 'old' Core2Duo has shown that not only Case's GCC build is always slower than Ajaja's GCC build but it also writes 1 byte more:

Ajaja's:
Code: [Select]
       Encoded: 44 minutes and 53.6 seconds
       Runtime: 1 minute and 43 seconds
                (26.15x realtime)
         Wrote: 43510600 bytes, 134680 packets, 2696 pages


Case's:
Code: [Select]
       Encoded: 44 minutes and 53.6 seconds
       Runtime: 1 minute and 47 seconds
                (25.17x realtime)
         Wrote: 43510601 bytes, 134680 packets, 2696 pages

  • eahm
  • [*][*][*][*][*]
Opus 1.1-beta
Reply #119
Thanks the_weirdo, using yours.
  • Last Edit: 02 December, 2013, 01:00:15 AM by eahm

  • Anakunda
  • [*][*][*][*][*]
Opus 1.1-beta
Reply #120
Last RC is released, some bugfixes here:

Quote
3 December, 2013

This is the third and likely last release candidate for 1.1. It fixes several bugs in the fixed-point build. Floating point is unaffected.



  • eahm
  • [*][*][*][*][*]
Opus 1.1-beta
Reply #121
Thanks Anakunda, could you also create a build with just opusenc.exe or explain to me please why your way is better?
  • Last Edit: 03 December, 2013, 05:44:41 PM by eahm

  • Anakunda
  • [*][*][*][*][*]
Opus 1.1-beta
Reply #122
Oh yes, I can, but dont be worried it's up to pair to single file, so it's no better nor worse. I'm just tried to convert same song using the same encoder on two PCs with two different processors and the result is not same which proves that for different CPUs different level of optimizations is used which affects the resulting audio data in some way. I can't say if these changes affect the quality also or even produce hearable artifacts.
  • Last Edit: 03 December, 2013, 05:58:19 PM by Anakunda

  • eahm
  • [*][*][*][*][*]
Opus 1.1-beta
Reply #123
Also ~5 MB (your x86 or x64 pack) vs ~450 kB (standard single build).
  • Last Edit: 03 December, 2013, 06:13:32 PM by eahm

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Opus 1.1-beta
Reply #124
Oh yes, I can, but dont be worried it's up to pair to single file, so it's no better nor worse. I'm just tried to convert same song using the same encoder on two PCs with two different processors and the result is not same which proves that for different CPUs different level of optimizations is used which affects the resulting audio data in some way. I can't say if these changes affect the quality also or even produce hearable artifacts.


Be careful what you compare. The file has a stream ID which is chosen randomly by the encoder. So it's normal for Opus files to not be identical. You'd have to either compare the decoded output or look at the output of --save-range.