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

Opus 1.1-beta

Reply #100 –
Quote from: LithosZA on
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, ...

Opus 1.1-beta

Reply #101 –
Quote from: jmvalin on
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)

Opus 1.1-beta

Reply #102 –
Quote from: Anakunda on
Quote from: jmvalin on
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.

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.

Opus 1.1-beta

Reply #105 –
GCC 4.82 compile: [attachment=7708:opus-1.1-rc-gcc482.zip]
MSVC 2013 compile: [attachment=7709:opus-1.1...msvc2013.zip]
MSVC version seems quite a bit faster here. It requires SSE2 support from the processor.

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.

Opus 1.1-beta

Reply #107 –
Thank you Case. Testing ASAP.

Opus 1.1-beta

Reply #108 –
Quote from: Anakunda on
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.

Opus 1.1-beta

Reply #109 –
Quote from: jmvalin on
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...

Opus 1.1-beta

Reply #110 –
Quote from: Anakunda on
Quote from: jmvalin on
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.

Opus 1.1-beta

Reply #111 –
hold your horses .... rc2 just released

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:)

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?

Opus 1.1-beta

Reply #115 –
Here's rc2 build, hopefully the issues are gone

Opus 1.1-beta

Reply #116 –
Quote from: Anakunda on
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.

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.
[attachment=7712:Opus-1.1-rc2.7z]

Opus 1.1-beta

Reply #118 –
Quote from: the_weirdo on
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

Opus 1.1-beta

Reply #119 –
Thanks the_weirdo, using yours.

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.


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?

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.

Opus 1.1-beta

Reply #123 –
Also ~5 MB (your x86 or x64 pack) vs ~450 kB (standard single build).

Opus 1.1-beta

Reply #124 –
Quote from: Anakunda on
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.