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: exhale - Open Source USAC encoder (Read 312455 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.
 

Re: exhale - Open Source USAC encoder

Reply #1101 –
Yeah but that is SBR frequencies... not the same thing
the distortion I'm hearing is below the SBR frequency range
Also, oof, that 15khz tone sounds really quiet.. my ears suck.. in my right ear above 12.75khz volume starts dropping pretty quick and in my left ear 13.25khz

Re: exhale - Open Source USAC encoder

Reply #1102 –
Hey,
Does anyone know of a way to view the spectrogram of xHE-AAC tracks?
Audition, Audacity, and Spek do not support it.

Re: exhale - Open Source USAC encoder

Reply #1103 –
Convert your xHE-AAC audio files to wav.
EZ CD Audio Converter / FLAC or WavPack

Re: exhale - Open Source USAC encoder

Reply #1104 –
Thanks for the tip soundping. That works.

Re: exhale - Open Source USAC encoder

Reply #1105 –
I just committed a small change to exhale's CVBR modes f, g, and 5, 6, see https://gitlab.com/ecodis/exhale. The primary purpose is to remove some old macro-encapsulation code and to bring the average encoding bit-rates of those modes closer to the target rates (96, 108, 128, and 144 kbps, respectively, for stereo). Thanks very much to guruboolez for thorough checking of the encoding bit-rates, and for sharing the results in his public table. Encoding at the other modes hasn't changed at all since release 1.1.9.

Literally, this is a 1.1.9.2 sub-release, but you can also call it an exhale 1.2.0 beta release since I'll tag a final 1.2.0 release at the end of the year and the encoding results probably won't change anymore.

Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #1109 –
the contents of 'version.h' in the code remain unchanged although the changes referred to above are implemented. Not really within my remit to change the version number. ;)

Re: exhale - Open Source USAC encoder

Reply #1110 –
Yeah, I was still trying some speedups when I committed this, which I finished today. So here's a new commit with updated 'version.h' for an official exhale 1.2.0 release candidate, including several code improvements (thanks again, jprjr and NetRanger!).

Changes since exhale 1.1.9, released one year ago:
  • C API correction, some code sanitizing (issue #24, merge requests !8–!11, J. Regan)
  • exhaleLib: code cleanup, very minor quality improvements in CVBR modes f and 5
  • exhaleLib: 5% speedup of all modes, better target rate matching in CVBR mode g

More speedup might be possible with Visual Studio compiles (see macro SFB_QUANT_SSE in lib/quantization.h), but that's probably still suboptimal.

Please compile and test as usual.

Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #1111 –
Errors when compiling from macOS:

/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.cpp:13:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
#if SFB_QUANT_SSE
    ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.h:29:29: note: expanded from macro 'SFB_QUANT_SSE'
#define SFB_QUANT_SSE (0 && defined (_MSC_VER))
                            ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.cpp:49:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
#if SFB_QUANT_SSE
    ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.h:29:29: note: expanded from macro 'SFB_QUANT_SSE'
#define SFB_QUANT_SSE (0 && defined (_MSC_VER))
                            ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.cpp:226:6: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
# if SFB_QUANT_SSE
     ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.h:29:29: note: expanded from macro 'SFB_QUANT_SSE'
#define SFB_QUANT_SSE (0 && defined (_MSC_VER))
                            ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.cpp:283:12: error: variable 'tempBitCount' set but not used [-Werror,-Wunused-but-set-variable]
  unsigned tempBitCount, tuple, is;
           ^
4 errors generated.
make[1]: *** [../../build/quantization.r.o] Error 1
make: *** [release] Error 2

Re: exhale - Open Source USAC encoder

Reply #1112 –
Version 1.2RC (ARM, built on Oct 24 2022) compile without errors on Linux (64bit).

Re: exhale - Open Source USAC encoder

Reply #1114 –
The latest revision (46ae72aa) is compiled without errors even on macOS.

Re: exhale - Open Source USAC encoder

Reply #1116 –
NetRanger is the goat, thank you for your builds!
Opus VBR 256 + SoX

Re: exhale - Open Source USAC encoder

Reply #1118 –
Quote from: zmashine on
Quote from: NetRanger on
exhale v1.1.9.1-4ef4bc3c
Built on June 30, 2022, GCC 12.1.0
with this build and preset 9 output files have avg bitrate ~128 kbps.
Argh, thanks for reminding me about this. This still happens with NetRanger's GCC compile of the 1.2.0 release candidate, so two things to mention here:

  • Please do not use NetRanger's GCC 12.2.0 compile since that still has the high-bit-rate issue reported here! Use his CLANG 15.0.3 binaries or John's Intel 2022 binaries instead.
  • I submitted a corresponding issue #26 on GitLab, summarizing the issue and asking for help. Again, experts on this wanted since I don't work with GCC/Msys2 myself, only VS.

For the record: The last known good GCC compile for the Windows platform here on HA is this one (exhale 1.1.9, compiled with GCC 11.2.0).

Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #1119 –
Quote from: C.R.Helmrich on
Argh, thanks for reminding me about this. This still happens with NetRanger's GCC compile of the 1.2.0 release candidate, so two things to mention here:

  • Please do not use NetRanger's GCC 12.2.0 compile since that still has the high-bit-rate issue reported here! Use his CLANG 15.0.3 binaries or John's Intel 2022 binaries instead.
  • I submitted a corresponding issue #26 on GitLab, summarizing the issue and asking for help. Again, experts on this wanted since I don't work with GCC/Msys2 myself, only VS.

I mean, since this is a known ongoing issue, perhaps @NetRanger should just not publish GCC builds of exhale until it's resolved?

Re: exhale - Open Source USAC encoder

Reply #1120 –
Quote from: C.R.Helmrich on
Can you please try again with the latest revision?

version 1.2RC (x64, built on Oct 24 2022) compile without errors on macOS Ventura 13.0 (64bit).
Apple clang version 14.0.0 (clang-1400.0.29.102)
Target: x86_64-apple-darwin22.1.0

Re: exhale - Open Source USAC encoder

Reply #1121 –
Thanks very much for the info, celona!

Quote from: doccolinni on
I mean, since this is a known ongoing issue, perhaps @NetRanger should just not publish GCC builds of exhale until it's resolved?
It seems it's been resolved very quickly on GitLab, thanks for C. Degawa. And NetRanger's compiles are always appreciated to identify such issues. Strange "signed/unsigned" interplay between GCC and MSYS2 was the cause, it seems, and not really exhale's fault, but oh well, rewrote one line of code anyway. NetRanger, feel free to give it another try with GCC 12.2.0 and the new revision.

(Note to myself:: don't forget to mention the fix of issue #26 in the release notes before tagging the final 1.2.0 release!)

Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #1123 –
Tested the newly compiled GCC exhale binary on a few files now and it looks fine. Rather big change after the latest commit.

Great work on the quick fix. :)