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 310721 times) previous topic - next topic
jaybeee, Thundik81 and 2 Guests are viewing this topic.

Re: exhale - Open Source USAC encoder

Reply #525 –
Hello !
Prompt settings for work in Exact Audio Copy

Re: exhale - Open Source USAC encoder

Reply #526 –
The sound quality at ~40 kbps (mode a) is incredible.

Re: exhale - Open Source USAC encoder

Reply #527 –
Quote from: sld on
The sound quality at ~40 kbps (mode a) is incredible.
At least if you compare it to HE-ACC without ParametricStereo.

I found some of my old test-encodings using HE-ACCv2, which I did about 10 years ago.
These were with SBR and ParametricStereo enabled while using only 24kbps.
They sound only slightly worse than the 40kbps Exhale mode A encoding I made for comparison.
Of course the comparison is unfair (PS versus non-PS)

So I suspect lots of effort needs to be put into xHE-ACC to make it work more efficient than HE-ACCv2 (PS&SBR) at very low bitrates.

Re: exhale - Open Source USAC encoder

Reply #528 –
Quote from: scharfis_brain on
They sound only slightly worse than the 40kbps Exhale mode A encoding I made for comparison.
HE-AACv2, 24 kbps can only be on par with HE-AACv1 32 kbps. And it's already optimistic.

There is not  a single chance that HE-AACv2 24 kbps sounds only slightly worse than exhale ~40 kbps.
No.
 

Re: exhale - Open Source USAC encoder

Reply #529 –
It only was a single sample I tested.  Maybe that sample was easy on HE-AACv2.

Re: exhale - Open Source USAC encoder

Reply #530 –
OK, today I was greeted with this error on Windows 10 machine; not exhale, but the decoder was the culprit:

Foobar gave this error:
Failed to load DLL: foo_pd_aac.dll
Reason: I/O error (win32 #225)

Windows Defender gave this:
Alert level: Severe
Trojan: Win32/CryptInject!ml
Status: Active
Date: 23.12.2020. 9:11
Category: Trojan
Details: This program is dangerous and executes commands from an attacker.
Affected items:
file: C:\Users\(username)\AppData\Roaming\foobar2000\user-components\foo_pd_aac\foo_pd_aac.dll


So, what's up there?
Error 404; signature server not available.

Re: exhale - Open Source USAC encoder

Reply #531 –
Same here.

Re: exhale - Open Source USAC encoder

Reply #532 –
Might carry more weight to get kode54 to comment, but my simple analysis says it's a false positive. Those happen way too often.
There's another thread on the foobar2000 forum: https://hydrogenaud.io/index.php?topic=120328.0.

Re: exhale - Open Source USAC encoder

Reply #533 –
I'm sure you're right, I was just confirming it wasn't a 'one off'. ;)

Re: exhale - Open Source USAC encoder

Reply #534 –
Hello,

New version 1.1.1 in develop branch.
3-subband SBR mode : what I vaguely understand guess is that you're allocating more bits to lower frequencies in SBR range?

Jeez... No vacation in Germany? Or lockdown perhaps... :D

    AiZ

Re: exhale - Open Source USAC encoder

Reply #535 –
Quickly spotted :) Yes, I just finished a 1.1.1 release candidate of exhale, see this commit. "3-subband SBR" means that that the SBR spectral range (11-16 kHz with 44.1 kHz sampling rate, e.g.) is now divided into 3 subbands, so the SBR frequency resolution increased compared to exhale 1.1.0. The bit allocation among these subbands is chosen optimally, but due to slightly more efficient coding of the SBR parameters, the overall bit-rates increased by only 0.1 kbit/s or so, even though we effectively now have two SBR frequency bands more.

As planned and previously announced, this completes the audio quality tuning for exhale. Future versions will focus only on bugfixes and severe audio quality issues (which, fortunately, have become unlikely). Please check whether this version compiles and works as expected. I'll merge this version to the master branch on Dec. 31, 2020.

Quote from: dimonspb on
Prompt settings for work in Exact Audio Copy
I'm not using EAC. Does somebody else know? See also https://gitlab.com/ecodis/exhale#third-party-stdin-foobar2000 for basic command-line usage with stdin.

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

Re: exhale - Open Source USAC encoder

Reply #536 –
I am testing 1.1.0 and there is already 1.1.1    :-\
That's actually great :)

So, I am testing 1.1.0 SBR 48 kbps and not sure when will be able to finish that.  However right now it's already clear that 48 kHz produces superior quality for this bitrate+mode than 44.1 kHz, at least for difficult samples. The second part of test will have more realistic average material (Kamedo2's set of samples and maybe some of  Guru's as well). 

Speaking of 48 kbps bitrate point, it's seems like my ears prefer more wider non-SBR range (up to 11.625kHz) at 48 kHz sampling rate rather than range (up to 11.025kHz) at 44.1 kHz sampling range.  48 kHz helps most where SBR does it worst, transients.


Re: exhale - Open Source USAC encoder

Reply #537 –
mode 2@32khz do not work now (?). or do...
dont panic! release the Kraken! All work fine.

Re: exhale - Open Source USAC encoder

Reply #539 –
Quote from: IgorC on
I am testing 1.1.0 and there is already 1.1.1    :-\
That's actually great :)
Great, thanks very much! Don't worry, your test won't be obsolete, the core coded signal below the SBR range hasn't changed at all since version 1.1.0. Which also means that all non-SBR modes (0-9) haven't changed. However, exhale 1.1.1 also includes a workaround for an issue discovered by celona (see here and here, thanks to celona and kode54 for help in identifying this issue!). Therefore, I'm afraid I have to recommend to reencode your music even when not using SBR in order to prevent audio glitches under current Apple software versions.

To clarify my previous post: with exhale 1.1.0, some SBR encodings of audio having a downward spectral tilt towards higher frequencies (which is what most audio is like) might sound a bit dull, similar to having a lowpass filter applied around the start of the SBR range. The reason was that the single-subband SBR implementation could not follow the spectral tilt very well, see the red averaged frequency response in the following screenshot (made with preset e). exhale 1.1.1, with its 3-subband SBR improvement, does better here, see the green frequency response. The blue curve shows the target response (of the original waveform).



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

Re: exhale - Open Source USAC encoder

Reply #540 –
Chris, I don't see any image with red/green/blue.  Maybe it's just me.

Re: exhale - Open Source USAC encoder

Reply #542 –
Hmm, maybe it is blocked on your side because it's coming from http (and not https like this site). Anyway, I attached it here again for convenience.

Reading my previous post again, I noticed that I hadn't mentioned exhale's new command-line presets a - g in the Read-me file. I fixed that in the last commit for this year. I also addressed an "overlapping memcpy" warning which Valgrind reported. This version will be merged to the master branch and tagged as the final 1.1.1 release tomorrow, after some final overnight testing.

By the way, is anyone interested in faster xHE-AAC encoding? Something in the "5 times faster than the current exhale version" ballpark, with some slight losses in audio quality being acceptable?

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

Re: exhale - Open Source USAC encoder

Reply #543 –
Quote from: C.R.Helmrich on
By the way, is anyone interested in faster xHE-AAC encoding? Something in the "10 times faster than the current exhale version" ballpark, with some slight losses in audio quality being acceptable?
Sure, why not :D Maybe merged with current exhale version, with quality switch to select speed or quality...
BTW, congratulations on the new version and thanks for NY present :)
--------------------

Re: exhale - Open Source USAC encoder

Reply #544 –
Thanks, and you're very welcome :) Regarding my question, see this exhale Wiki entry, which explains how to compile exhale in a faster mode. Feel free to try it out and report your observations. On my laptop that version is about 5 times faster than the default compile. I don't want to offer a switch for this, though, since on some audio the quality degradation is quite noticeable.

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

Re: exhale - Open Source USAC encoder

Reply #545 –
@jaybeee @Chris
Thank You for the image.

As of a faster build, IMHO, it's a double-edged. 
On the one hand you get a faster encoding on the other hand  somebody  will use it in his/her applications without even knowing it  and a lot of people will end with a lower audio quality.  Remember old mp3 encoders with enabled fast switch?

xHE-AAC is meant to provide a better compression ratio comparing to LC/HE-AAC, even if it comes with speed penalty.  And, sincerely, today CPUs are fast enough. I get more than 100x speed with exhale on my laptop. 

Re: exhale - Open Source USAC encoder

Reply #546 –
Quote from: C.R.Helmrich on
However, exhale 1.1.1 also includes a workaround for an issue discovered by celona (see here and here, thanks to celona and kode54 for help in identifying this issue!).

I think I have to thank C.R. Helmrich and kode54, found a problem isn't difficult as solving it. You should also make a change to the readme file before the new year. As you know, commercial encoders have a limitation: they are only available for computers with Windows, macOS or Linux. Exhale in 2020 was the first native encoder for the new ARM M1 SoC, even Apple still offers only the decoder for the final user and Fraunhofer IIS has also made the encoder available only for Intel CPU (see Fraunhofer xHE-AAC encoder ).

Exhale built for ARM now is the first xHE-AAC encoder that works also in a phone. Happy New Year to all!

Re: exhale - Open Source USAC encoder

Reply #548 –
@celona

That ARM demo is amazing :) Now l have to learn to get a terminal emulator running on Android in order to try this.

@C.R.Helmrich
As you know, I'm a speed-freak when dealing with encoders :) But with exhale I think slower (quality) makes the most sense. (But I'd really like to try benching some non-trellis x86 compiles :) :) )
"Something bothering you, Mister Spock?"

Re: exhale - Open Source USAC encoder

Reply #549 –
Quote from: IgorC on
On the one hand you get a faster encoding on the other hand  somebody will use it in his/her applications without even knowing it and a lot of people will end with a lower audio quality.
Exactly, and that's what I'm trying to avoid. So having that compiler macro as a solution seems the best approach to me.

Quote from: celona on
Exhale built for ARM now is the first xHE-AAC encoder that works also in a phone. Happy New Year to all!

Wow, that looks awesome! Thanks very much! :) I just merged exhale 1.1.1 to the master branch and cleaned up one final sentence in the introductory part of the Read-me. Please note that your develop compiles don't include the Apple related fix, that was initially added only in the master branch. So you should recompile from master now.

Happy New Year to everyone!

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