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 xHE-AAC encoder (Read 93420 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: exhale - Open Source xHE-AAC encoder

Reply #875
There is an improvement when downgraded to 44.1 kHz! I hear a cricket on the speakers with weak bass.
#a - a crunch appears.

Re: exhale - Open Source xHE-AAC encoder

Reply #876
Will there be an upgrade from PS for low bitrate? The synthesis of high frequency recovery is very poor.


Re: exhale - Open Source xHE-AAC encoder

Reply #878
The 'Guano Apes' sample is very similar to the 'Vangelis' sample you reported a few weeks back, and I verified that exhale 1.1.6 already sounds much better than, e.g., exhale 1.1.4 on that kind of content.

The 'Sandra' sample is yet another sample with some constant high-frequency tone, and as I said previously, exhale's SBR encoder can't deal with such weird content (those tones actually have no musical meaning, they are interference in the original recordings which shouldn't really be there in the first place).

Will there be an upgrade from PS for low bitrate? The synthesis of high frequency recovery is very poor.
PS (parametric stereo) has nothing to do with high-frequency reconstruction (that's SBR's job), and as the very first post of this thread points out, I will not implement a parametric stereo or a better (enhanced) SBR into exhale - too much work.

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

Re: exhale - Open Source xHE-AAC encoder

Reply #879
The 'Sandra' sample is yet another sample with some constant high-frequency tone, and as I said previously, exhale's SBR encoder can't deal with such weird content (those tones actually have no musical meaning, they are interference in the original recordings which shouldn't really be there in the first place).
Chris
Just remove such complex high frequencies or reduce echo? The graph shows how the straight line becomes stepped.

Does the encoder have tools for analyzing and restoring stereo panoramas? An additional echo moves the sound from the center to the sides.
I will not implement a parametric stereo or a better (enhanced) SBR into exhale
Chris


Re: exhale - Open Source xHE-AAC encoder

Reply #881
Intel compiles of exhale-V1.1.6-RC2-b11042a0:
That's actually the final 1.1.6 release of exhale, I just tagged it.

Just remove such complex high frequencies ...?
Yes, removing those extra interference tones before encoding would be an option, yes, but it's not trivial to implement (you would have to analyze the entire song before encoding). But Gravitator, since you seem to be very sensitive to high frequencies: have you considered just using exhale's non-SBR modes or Fraunhofer's encoder?

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

Re: exhale - Open Source xHE-AAC encoder

Reply #882
Intel compiles of exhale-V1.1.6-RC2-b11042a0:
That's actually the final 1.1.6 release of exhale, I just tagged it.

Chris
OK, I'll update Rarewares shortly.

Edit: Updated. :)


Re: exhale - Open Source xHE-AAC encoder

Reply #884
Intel compiles of exhale-V1.1.6-RC2-b11042a0:
That's actually the final 1.1.6 release of exhale, I just tagged it.

Thank You, Chris, for keeping work on an open source encoder and for this new release!   :)  :D

https://gitlab.com/ecodis/exhale/-/releases
v1.1.6
  • minor quality tuning and support for delayless operation (media time=0) with SBR
  • exhaleApp: fixed very rare output file corruption after finishing encoding with SBR
  • exhaleApp: fixed compilation error under Fedora (issue #20) and stdin hickup issue
  • exhaleLib: fixed some quality issues in SBR modes, no changes in non-SBR modes

Re: exhale - Open Source xHE-AAC encoder

Reply #885
Chris, what DR information does xHE-ACC store on the files and how could your foobar2000 decoder component read these tags and apply them?
I think I read the compressor sort of peak limits or apply -0.01 dBFS maximization. How does foobar then find different peaks per file when ReplayGain scanning?

Re: exhale - Open Source xHE-AAC encoder

Reply #886
Exhale 1.1.6 updated to EZ CD Audio Converter 9.3.2 installer (download again from https://www.poikosoft.com and reinstall to get it)

- Delayless operation (media time=0) with SBR enabled by default in EZ CD Audio Converter's implementation
- Passes the xHE-AAC™ Codec compliancy tests developed by Fraunhofer

Exhale is not enabled by default in EZ CD Audio Converter (there's another default xHE-AAC™ encoder). Exhale can be enabled with the CTRL+F shortcut for testing purposes

Re: exhale - Open Source xHE-AAC encoder

Reply #887

Exhale is not enabled by default in EZ CD Audio Converter (there's another default xHE-AAC™ encoder). Exhale can be enabled with the CTRL+F shortcut for testing purposes


CTRL+E that is (my typo)

Re: exhale - Open Source xHE-AAC encoder

Reply #888
Chris, what DR information does xHE-ACC store on the files and how could your foobar2000 decoder component read these tags and apply them?
I think I read the compressor sort of peak limits or apply -0.01 dBFS maximization. How does foobar then find different peaks per file when ReplayGain scanning?
exhale stores track loudness and sample peak (but not true peak) value data into xHE-AAC files during encoding (as MPEG-D LoudnessInfo data, not traditional ReplayGain tags), measured on the original input PCM data. Note that the FDK-AAC packet decoder is (or, rather, was) developed by kode54, not myself, and IIRC, he disabled the peak limiter recently.

I once mentioned to Peter and kode54 how foobar2000 could read/write also album loudness and sample peak data to xHE-AAC files, in the same MPEG-D standardized way, thus allowing full compatibility with foobar2000's ReplayGain scanner. But I think the conclusion was that, without direct xHE-AAC support in foobar2000 (the decoder component is still required), getting that to work currently would require an infeasible amount of extra work.

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

Re: exhale - Open Source xHE-AAC encoder

Reply #889
FDK packet decoder is on life support, it will get emergency fixes with a few days of reporting if necessary, but I don't expect to do that loudnessinfo data support myself. Especially since that's outside the scope of a packet decoder. That's a feature that Peter will have to look into supporting in the MP4 input itself.

Even if it is exposed to my packet decoder just through the raw bitstream, I have no way to alter it, and the player will not share tag updates with the packet decoder, either. Exposing that info as RG tags, and exposing a means to alter them when the player rewrites those tags, would have to be something handled by the MP4 input.

A scanner which applies values to those tags would also need to flag to the decoder to somehow disable all normalization and peak limiting as well, which there currently is no flag for.

 

Re: exhale - Open Source xHE-AAC encoder

Reply #890
I made a cross comparison of three tests I made these last months with Exhale :





xHE-AAC Exhale 48: https://hydrogenaud.io/index.php?topic=118888.msg997431#msg997431
xHE-AAC Exhale 64: https://hydrogenaud.io/index.php?topic=118888.msg997431#msg997431
xHE-AAC Exhale 80: https://hydrogenaud.io/index.php?topic=118888.msg997434#msg997434
xHE-AAC Exhale 96¹: https://hydrogenaud.io/index.php?topic=120997.0
xHE-AAC Exhale 96²: https://hydrogenaud.io/index.php?topic=121099.msg998706;topicseen#new

A comparison to other competitors is joined as attached picture (and opened to debate in this topic).

In my opinion Exhale gives the best of itself at 96 kbps: there is a huge gap between preset 2 and preset 3. My explanation is that preset 2 is still a bit fragile without SBR with audible starvation at ~80 kbps. At 96 kbps most of these issues are solved to my ears.

Re: exhale - Open Source xHE-AAC encoder

Reply #891
Thanks very much, guruboolez, for this summary!
In my opinion Exhale gives the best of itself at 96 kbps: there is a huge gap between preset 2 and preset 3. My explanation is that preset 2 is still a bit fragile without SBR with audible starvation at ~80 kbps. At 96 kbps most of these issues are solved to my ears.
Maybe, in that case, it would after all make sense to, with "typical" easy-to-code music, either 1) use SBR at ~80 kbps (mode e) or 2) downsample the input to 32 kHz with non-SBR mode 2. Both approaches will prevent starvation, i.e., audible spectral holes. But not everyone is as sensitive to bit-rate starvation artifacts as you are, and in both cases, transient samples will be degraded in quality since the time-frequency transforms are longer in time.

Edit: Kamedo2, in his recent blind listening test, tended to prefer exhale's non-SBR mode 2 at ~80 kbps on his sample set, which contains many hard-to-code samples.

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

 
SimplePortal 1.0.0 RC1 © 2008-2021