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 100244 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Opus 1.1-beta

Reply #125
Thanks jmvalin. is there a measure which justifies which changes in saved range are yet acceptable and which not? It seems that speed optimizations really affect these and now I'm not too sure which degree of optimizations is yet affordable and which not, so that I could make build fully conforming to opus standard.

Opus 1.1-beta

Reply #126
For the record, my GCC compile, which doesn't match jmvalin's range file, was compiled with no manual adjustments. I just ran configure and make in mingw environment.

Opus 1.1-beta

Reply #127
Case, do you have any time to compile rc3? Thanks.

Opus 1.1-beta

Reply #128
My build was compilied with "-O3 -flto". And it does match jmvalin's range file on Core 2 Duo (WinXP x86) where I built it, but doesn't match on Core i5 (Win7 x64).

Opus v1.1rc3 build for x64 Core i3/i5/i7 (GCC 4.8.2 with "-O3 -flto -march=native -mtune=native") in attachment.

Opus 1.1-beta

Reply #129
Opus v1.1rc3 build for x64 Core i3/i5/i7 (GCC 4.8.2 with "-O3 -flto -march=native -mtune=native") in attachment.

Thank you, this still produces different range from range_working.txt on Quad Core with SSE4.2, I can't compare on old Core2Duo since it's crushing on it.

Opus 1.1-beta

Reply #130
Opus v1.1rc3 build for x64 Core i3/i5/i7 (GCC 4.8.2 with "-O3 -flto -march=native -mtune=native") in attachment.

Thanks, but why x64 only ? Any chance you could build both x86 and x64 versions ?

Opus 1.1-beta

Reply #131
Thanks jmvalin. is there a measure which justifies which changes in saved range are yet acceptable and which not? It seems that speed optimizations really affect these and now I'm not too sure which degree of optimizations is yet affordable and which not, so that I could make build fully conforming to opus standard.


The --save-range trick is just a quick way of checking which frames are identical. The range value is simply the final state of the range coder, which acts as a sort of checksum. With float builds, it's normal to not always have identical files due to rounding behaviour. If you look at the broken file I was talking about earlier, the range file also shows that the bitrate suddenly goes very high and when you listen to it, there's loud noise for a while. If you're still able to reproduce that BTW, I'm still interested in finding the cause to make sure it doesn't happen again.

Opus 1.1-beta

Reply #132
If you look at the broken file I was talking about earlier, the range file also shows that the bitrate suddenly goes very high and when you listen to it, there's loud noise for a while.


Strange, if I try now Ajajaj's build on PC with Quad Core and SSE4.2 it produces exactly same range listing like mine build (regardless on bitness version). This points me like both independent builds are working well, but the range report gives unusually high bitrates all the time tho.
This: http://pastebin.com/1a92JaTr
Try if there's still the loud noise, I don't notice it:

Opus 1.1-beta

Reply #133
If you look at the broken file I was talking about earlier, the range file also shows that the bitrate suddenly goes very high and when you listen to it, there's loud noise for a while.


Strange, if I try now Ajajaj's build on PC with Quad Core and SSE4.2 it produces exactly same range listing like mine build (regardless on bitness version). This points me like both independent builds are working well, but the range report gives unusually high bitrates all the time tho.
This: http://pastebin.com/1a92JaTr
Try if there's still the loud noise, I don't notice it:


Looks normal and the bitrate rate appears to be (roughly) in the same range. The previous broken file was encoded with --bitrate 24 and for some frames had really high bitrate.



Opus 1.1-beta

Reply #136
Just to mention Opus 1.1 RC3 is officially confirmed to be final version 



 

Opus 1.1-beta

Reply #139
How am i supposed to build it?
Is there a guide somewhere?

I want to build an x64 version which is optimized for my CPU or something (not sure how these optimization ad compile works).



Opus 1.1-beta

Reply #142
0.1.8 refers to the package (opustools), while 1.1 refers to the opus version included.
x86 and x64 has nothing to do with being unicode, btw.

Opus 1.1-beta

Reply #143
How am i supposed to build it?
Is there a guide somewhere?

I want to build an x64 version which is optimized for my CPU or something (not sure how these optimization ad compile works).


If you have to ask those questions you should really download a build made by someone who actually knows what he's doing.



Opus 1.1-beta

Reply #146
0.1.8 refers to the package (opustools), while 1.1 refers to the opus version included.
x86 and x64 has nothing to do with being unicode, btw.


Ah that explains it.

Hmm didn´t unicode mean x64 and x86 compatible?
Though i think there is some text / web encoding by the same name.

Opus 1.1-beta

Reply #147
Hmm didn´t unicode mean x64 and x86 compatible?
Though i think there is some text / web encoding by the same name.


Unicode has only ever referred to the big text standardisation and encoding effort.
You may be conflating it with OSX-style "universal binaries" or "fat binaries", which bundle code for more than one architecture into the same executable.
Stay sane, exile.