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

Re: exhale - Open Source USAC 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 USAC 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 USAC 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).

Quote from: Gravitator on
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 USAC encoder

Reply #879 –
Quote from: C.R.Helmrich on
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.
Quote from: C.R.Helmrich on
I will not implement a parametric stereo or a better (enhanced) SBR into exhale
Chris

Re: exhale - Open Source USAC encoder

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

Quote from: Gravitator on
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 USAC encoder

Reply #882 –
Quote from: C.R.Helmrich on
Quote from: john33 on
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 USAC encoder

Reply #884 –
Quote from: C.R.Helmrich on
Quote from: john33 on
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 USAC 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 USAC 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 USAC encoder

Reply #887 –
Quote from: Jurgga on

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 USAC encoder

Reply #888 –
Quote from: wyup on
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 USAC 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 USAC 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 USAC encoder

Reply #891 –
Thanks very much, guruboolez, for this summary!
Quote from: guruboolez on
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.

Re: exhale - Open Source USAC encoder

Reply #892 –
Hello Kode54 (or other ?)

Have you one  idea for found one driver for read  xHE-AAC in audio mode with one old android 4.4 for example.
I see exist in new android version (9 & more) natively read but how make this with my old 4.4 (kitkat) for example.
I not update possible the phone it's the last firmare (after nothing) , the processor is too low & memory too edge for put one 9 or more.

Or other possibility, a reader/player know read natilvely with his internal decoder  ,
 i ask this because i many search and haven't found.

I check so Foobar for android and it's not read xhe-acc, and for android not plugin external exist (sigh)
Or one idea with one extrernal driver (android) type for per example this wonderfull dsp named "viper4android"
and Viper4Android is only one driver Dsp for AUDIO effects, but one "in this idea" for one driver of decode xHE-ACC

For pc (win + x64) all is right with your last driver & foobar (pc)
Regards,

Re: exhale - Open Source USAC encoder

Reply #893 –
Quote from: Jpt on
Hello Kode54 (or other ?)

Have you one  idea for found one driver for read  xHE-AAC in audio mode with one old android 4.4 for example.
I see exist in new android version (9 & more) natively read but how make this with my old 4.4 (kitkat) for example.
I not update possible the phone it's the last firmare (after nothing) , the processor is too low & memory too edge for put one 9 or more.

Or other possibility, a reader/player know read natilvely with his internal decoder  ,
 i ask this because i many search and haven't found.

I check so Foobar for android and it's not read xhe-acc, and for android not plugin external exist (sigh)
Or one idea with one extrernal driver (android) type for per example this wonderfull dsp named "viper4android"
and Viper4Android is only one driver Dsp for AUDIO effects, but one "in this idea" for one driver of decode xHE-ACC

For pc (win + x64) all is right with your last driver & foobar (pc)
Regards,

GoneMAD Music Player (GMMP) uses FFMpeg 4.4 as audio engine, according to latest changelog. It might be able to decode xhe-aac, but I don't know.


I remember I could play Opus with GMMP before I got an Android version that supported Opus natively. So if any player is able to play xhe-aac on older Android versions, GMMP would be a good bet IMO. :)

Re: exhale - Open Source USAC encoder

Reply #894 –
@Jpt @o-l-a-v
Soon you'll be able to run GoneMAD Music Player in Win11.

"PC users will no longer have to use a third-party solution to run Android apps on Windows 11.
The OS will run Android apps natively."   :)

EZ CD Audio Converter / FLAC or WavPack

Re: exhale - Open Source USAC encoder

Reply #895 –
FFmpeg only supports xHE-AAC if you link in libfdk-aac, and it doesn't take over support for the AAC decoding from the built-in decoder unless it's explicitly requested, so it will still report the files as unsupported.

Re: exhale - Open Source USAC encoder

Reply #896 –
Hi alls,
In first many thank's for your response & added info for others users.
Gonemad runs natively in Android 5.0or more, For kitkat only versions <= to 2.15 is possible to install (Cf: see Download section).
I check it, and him NOT read xHE (sigh) but read the AAC v2+SBR+PS, and for info my others players read so this format.

@Soundping:Thank's from you info about w11, but push one "windows 11" in my samsung s4 mini seems hard & difficult  :))
and for windows 7 no sp1, Foobar & the driver of kode54 in download section is fully top !
But others user is maybe interesting from your info for runs his *.apk directly for check

@kode54
How push Libfdk-acc (My S4mini is fully open, may be have idea ?) and how "explicitly requested" him.
It's this i search .

And i think a new format of audio if it's nort read easy in many's players has no succes.. or difficult
I'm remember the mp3PRO Format (by Thomson), it's good but not read in player...This format is lost
Same so for the sony format audio i forget his name...
 
Or built one player audio with integrate decoder of xhe-acc may be for popular/acces alls this format.
or built one driver for foobar Android ? (same of Foobar from pc) etc..

B.regards