Hydrogenaudio Forums

Lossy Audio Compression => Other Lossy Codecs => Topic started by: IgorC on 2020-02-25 22:57:44

Title: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-02-25 22:57:44
https://gitlab.com/ecodis/exhale

https://gitlab.com/ecodis/exhale/-/wikis/faq

Quote
exhale, which is an acronym for "Ecodis eXtended High-efficiency And
Low-complexity Encoder", is a lightweight library and application to
encode uncompressed WAVE-format audio files into MPEG-4-format files
complying with the ISO/IEC 23003-3 (MPEG-D) Unified Speech and Audio
Coding (USAC, also known as Extended High-Efficiency AAC) standard.
exhale currently makes use of all frequency-domain (FD) coding tools
in the scalefactor based MDCT processing path, except for predictive
joint stereo, which is still being integrated. Its objective is high
quality mono, stereo, and multichannel coding at medium and high bit
rates, so the lower-rate USAC coding tools (ACELP, TCX, Enhanced SBR
and MPEG Surround with Unified Stereo coding) won't be integrated.

Looks promising. 
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-02-26 13:52:02
Nice to finally see an open-sourced USAC encoder.

Two trivial patches were needed to build exhale on Linux (patches attached).
I could play encoded USAC file with a Samsung Galaxy Tab that runs Android 9 Pie.
Since ffmpeg's native AAC decoder doesn't support USAC yet, I guess almost nothing can play it other than what is based on FDKv2 decoder.
You can still build libfdk-aac enabled ffmpeg on your own, though.

It seems that by defining RESTRICT_TO_AAC=1 you may build exhale as a plain AAC encoder,  I haven't try this.

As is written in README, exhale doesn't target low bitrate ranges. VBR mode 1(lowest) result in like 64kbps.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-02-27 02:24:28
Nice to finally see an open-sourced USAC encoder.
Indeed

As is written in README, exhale doesn't target low bitrate ranges. VBR mode 1(lowest) result in like 64kbps.
Instead of wasting time on a high number  of low-bitrate tools (those rates aren't a target nowdays)  it's a wise decision to concentrate on  high and middle rates those actually count.

Let's hope that ffmpeg will support xHE decoding soonish.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: LithosZA on 2020-03-02 14:57:04
Quote
...at medium and high bit
rates, so the lower-rate USAC coding tools (ACELP, TCX, Enhanced SBR
and MPEG Surround with Unified Stereo coding) won't be integrated.
What is considered medium bit-rates? I'm more interested in the rates below 64Kbps where Opus starts struggling.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Klimis on 2020-03-04 00:31:39
I still think that low bit rates are, will and should be a target.
You see through a quite narrow lens which is like personal use, which can still be argued that people still care about really low bitrates hence low bitrates are, will and should be a target, but on a wider lens like big companies, radio stations, streaming services and the list goes on, care alot on reducing their bandwith and storage footprint because on a larger scale the slightest saving you can do has a massive impact on your running costs and profit.
So unless something extremelly revolutional happens in the computing world, focus on lowering bitrates on any type of media content is always the best interest of any healthy and self respecting project.
So in the case of xHE-AAC the whole idea of it's existance is targeting bitrates where other existing codecs are struggling, and 64Kbps+ bitrate ranges are not one of them. Not that there is no room of improvement but it's definitely not a "struggling range" per se. On the contrary 32-64 or maybe 16-64 sounds like a better target.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: shadowking on 2020-03-04 09:33:52
Nice to finally see an open-sourced USAC encoder.
Indeed

As is written in README, exhale doesn't target low bitrate ranges. VBR mode 1(lowest) result in like 64kbps.
Instead of wasting time on a high number  of low-bitrate tools (those rates aren't a target nowdays)  it's a wise decision to concentrate on  high and middle rates those actually count.

Let's hope that ffmpeg will support xHE decoding soonish.

  I agree.  Below 100k lossy becomes complex in decoding, stereo imaging, too aggressive psychoacoustics..  (audible or not  - i don't want it)

I will go further that at home with unmetered connections lossless audio should be used (local and streaming) . I would like to see more in this area and even mid-high bitrate lossy (for streaming metered connections) . I like to see people with a quality 1st approach.  IMO this very low bitrate like he-aac opus should not be touched except for very specific cases where compression 1st might be acceptable - voice / news / podcast  etc..
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-03-04 15:25:46
Instead of wasting time on a high number  of low-bitrate tools (those rates aren't a target nowdays)  it's a wise decision to concentrate on  high and middle rates those actually count.
Considering all the labors to implement low-bitrate tools, I agree that it's "wise" to avoid them.
Although it was a bit of surprise because  USAC is considered to be superior than AAC mainly in low-bitrate area.

Personally, I'm not interested in speech codec part so much.
However, MPEG surround, that's a diffrent story... It's not only for low-bitate, and it can drastically reduce bitrate.
I'd like to try it as an alternative to Dolby Prologic II or something (although it doesn't necessarily be as part of USAC)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-03-05 06:08:02
But why bother with mid to high bitrate? Isn’t MP3 already perfect for that? Also the patents have expired.

Also, don’t get me started on the travesty of surround mixes.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Klimis on 2020-03-05 16:52:17
But why bother with mid to high bitrate? Isn’t MP3 already perfect for that? Also the patents have expired.

Also, don’t get me started on the travesty of surround mixes.
Exactly.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-03-05 23:34:09
Thanks, all, for your comments on exhale and my work! For the record, I pushed a fix to the current release today (commit 7135623a) which recovers the encoding speed of version 1.0.0 but keeps the slightly improved segmental SNR of 1.0.1 (the encoder is still pretty slow, though). That version also contains a fix for a minor issue (see https://gitlab.com/ecodis/exhale/issues/2), plus you don't have to apply nu774's patches anymore.

It seems people here associate very different value ranges with the terms "medium" and "high" bit-rate. What I meant in exhale's Read-Me is, at least for stereo, the following. I consider

- high bit-rates those at and above the sweetspot of (1990s) MPEG-2 AAC-LC, i.e., 128 kbit/s stereo
- medium bit-rates those at and above the sweetspot of (2000s) HE-AAC, i.e., 64 kbit/s stereo, up to 128 kbit/s stereo
- low bit-rates those at and above the sweetspot of the more recent (2010s) codecs, i.e., 32 kbit/s stereo or lower, up to 64 kbit/s stereo.

Also, I initially intended exhale for file-based personal encoding - including for my own use - and as a proof-of-concept and personal challenge :) But of course, its primary purpose, beside file-based storage, is medium-rate streaming, e.g., Web radio. So yes, xHE-AAC targets the low and very low bit-rates but, as any codec should, it also performs pretty well at high bit-rates.

Quote
Considering all the labors to implement low-bitrate tools, ...

Indeed, this is the major reason why exhale starts only at 64 kbit/s stereo. xHE-AAC's advantage over its ancestors is much more obvious at rates lower than that. Adding the algorithms necessary for such low-rate coding would roughly triple the amount of source code and, possibly, work-hours (I like to write my source code from scratch and work on exhale in my free-time), and I won't be able to manage that. So I decided to leave the low rates to commercial encoders.

Quote
It seems that by defining RESTRICT_TO_AAC=1 you may build exhale as a plain AAC encoder.

No, the idea here was only to disable some specific coding tool extensions which didn't exist in (HE-)AAC. Generating AAC files with exhale is not possible because exhale only implements USAC's entropy coding, noise substitution, and TNS variant, not those of AAC.

Quote
But why bother with mid to high bitrate? Isn’t MP3 already perfect for that?

exhale's medium-rate modes (1-4 for my above definition of "medium") cover a bit-rate range on which I wouldn't consider MP3 "perfect". See also Kamedo2's personal test here: https://hydrogenaud.io/index.php?topic=117489.0
 

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-03-06 01:26:24
Sorry. I was mistaken on your intentions. I should have actually acquired your source code and put it to the test, since I am capable of doing things like that.

I wrongly assumed the medium (128-192, wrong) to high (224+, also wrong) bitrates from current popular codecs, and did not even consider the much lower scale you were actually aiming for. So, by all means, go forth and advance the world in ways I hadn't considered.

(For the record, I already consider Opus's 32-48 "low" and unusable for much more than voice or mixed media VOIP, 64-80 "medium" and approaching usable (since I have a hard time discerning it in casual listening without encoding difficult samples and outright looking for errors), and 128+ "high" and probably transparent for most of my use cases, so I don't know where the hell I got off expecting your descriptions to be applied to common MP3.)

E: Okay, I've tested encoding at least, and see that it requires a preset of 3 or higher for 44100Hz material, and won't drop to 2 without a downsample to 32 kHz or lower. I'll test those two presets out anyway, just to see how they handle this one test file I'm going to throw at it, just for casual listening. I'll be using libfdk-aac to decode it.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-03-07 02:58:25
Quick bump for a new issue: I tested this on a single track album, Secret of Mana +, which I have in lossless. I used the 3 preset, and the resulting USAC/xHE-AAC file decodes with a much lower amplitude than the original file.

Original FLAC:
Track Gain: -4.72 dB
Track Peak: 0.999969

FDK-AAC v2 decoded USAC:
Track Gain: +2.14 dB
Track Peak: 0.459747

Meanwhile, a different track, Level 3 from the cut down Intel demo of Rebel Moon Rising:

Original:
Track Gain: -5.32 dB
Track Peak: 0.93689

USAC decoded by FDK-AAC v2:
Track Gain: -5.31 dB
Track Peak: 0.891266

I can supply FLACs of both privately if you need them.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-03-07 10:30:29
Quick bump for a new issue: I tested this on a single track album, Secret of Mana +, which I have in lossless. I used the 3 preset, and the resulting USAC/xHE-AAC file decodes with a much lower amplitude than the original file.
...
USAC decoded by FDK-AAC v2:
I don't know if this addresses the issue, but exhale writes its own track loudness metadata (MPEG-D Dynamic Range Control, DRC loudnessInfo), which are an integral part of xHE-AAC, to the encoded files. For the record, I use the MPEG reference software decoder for USAC to decode exhale's bit-streams, and there you need to use the command-line

"-if in.m4a -of out.wav -targetLoudnessLevel L",

where L is the "mobile loudness" value reported by the exhale application when encoding of in.m4a has finished. Does your FDK-AAC v2 compile have a similar functionality?

If that doesn't solve the issue, let's try to fix this privately. On a different topic, which I missed commenting on in my last reply:

... at home with unmetered connections lossless audio should be used (local and streaming) . I would like to see more in this area and even mid-high bitrate lossy (for streaming metered connections).
Given the different understandings of "mid" and "high", what does it mean to you? Do you consider exhale's CVBR mode 9 (roughly 200 kbit/s for stereo, half that for mono) sufficient or are you looking for even higher bit-rates in the lossy case?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-03-07 15:43:45
  I agree.  Below 100k lossy becomes complex in decoding, stereo imaging, too aggressive psychoacoustics..  (audible or not  - i don't want it)
I don't have numbers for xHE decoding but HE-AAC and Opus decoding was optimized a long time ago.

Today even old smartphones will play HE-AAC/Opus as efficiently (battery life speaking) as uncompressed .wav 44.1k/16 or any other lossy format like  MP3, LC-AAC,  Vorbis or Musepack.

Audio decoders  consume much less CPU than phones's audio DAC+AMP and  Andoid OS in idle state.


Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-03-08 01:06:41
I tested FDK-AAC v2's USAC decoding, which does indeed include a submodule, "libDRCdec", which appears to handle the volume leveling for it. It appears to default to a target level of -24 dBFS, which is close to our -23 LUFS R128 level.

As for performance numbers, on my Ryzen 7 2700, a single decode thread of preset 3 USAC appears to use ~1% of a single core, or on Windows, it would be less than 1% of the total CPU resources. This probably scales somewhat higher on mobile processors, but it appears Fraunhofer has this somewhat taken care of already.

E: Hmm, is this thing tuned for gapless encoding yet? I tested a couple of gapless transition files, and they failed marvelously.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-03-09 02:15:08
E: Hmm, is this thing tuned for gapless encoding yet? I tested a couple of gapless transition files, and they failed marvelously.
exhale definitely should allow for gapless decoding. With the MPEG reference software decoder (see my previous post) I get perfectly gapless decodings of the exhale .m4a files. Maybe the FDK-AAC v2 decoder requires more info in the MPEG-4 file header? I'll check.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-03-09 10:34:21
Maybe the FDK-AAC v2 decoder requires more info in the MPEG-4 file header? I'll check.

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-03-10 04:32:32
foobar2000 only supports two gapless info methods. First added was the method devised by Nero’s encoder, Nero chapters. The second method added was iTunSMPB, since Apple’s encoder doesn’t write the Nero metadata. I’ll see if I can get Peter to add this edit list method. It would be helpful if you link to the line(s) of code where you write this information, if only for my personal perusal.

I’ll link to my evil decoder here later. I just recently disabled Dynamic Range Compression in my decoder, as it’s results can cause unpredictable effects when comparing input to output, especially huge volume differences. It needs a bit of work though, and it would be nice if foobar supported edit lists as gapless information first.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-03-10 05:43:21
Document: https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
My implementation (for decoding): https://github.com/nu774/qaac/blob/master/input/MP4Source.cpp

You'd better consult with ISO document if possible, though.

The following will output gapless information in elst box:
qaac --gapless-mode=1
fdkaac --gapless-mode=1

Edit list is beter than iTuneSMPB/Nero chapters since this is per-track information, not to mention that this is the ISO standard way.
Both of iTunSMPB/Nero chapters are file-global metadata, so it's only suitable for single track audio files.

However, edit list has it's own problem:


As far as I know, typical video-oriented applications (including ffmpeg) are only concerned with the following two cases to handle A/V sync, and doesn't trim end padding:

And almost nothing can correctly handle multiple edit lists. As the name implies, it was originally used by QuickTime to support editing video files at arbitrary points (not limited to GOP boundaries).
Of course actual video stream can only be cut at GOP boundaries (otherwise delta frames cannot be properly decoded), so video frames need trimming after decode to allow edits in arbitrary points.
Edit list was used for that purpose.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-03-10 07:15:31
I see there are two combined fields that are relevant, or combined may be consulted to make sure the file is sane. Both the Edit List and the Time to Sample (STTS) box contain valid data, but isn't necessary for this.

I have verified the files I wanted to test play back gaplessly on macOS, using my own macOS player, Cog. This requires a version of macOS which supports USAC, and is not limited to just Cog, but any player which decodes MP4 files with the system codecs.

I'll try to get MP4 streaming working eventually, but Apple kind of broke that for me by not offering a custom reader Audio Toolbox interface that also supports arbitrary streams, not just seekable and perfectly error free static files.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-03-10 10:38:15
Thanks a lot, nu774, for the info and the help!

I’ll see if I can get Peter to add this edit list method. ... it would be nice if foobar supported edit lists as gapless information first.
Thanks, that would be awesome!
Quote from: kode54
It would be helpful if you link to the line(s) of code where you write this information, if only for my personal perusal. ... Both the Edit List and the Time to Sample (STTS) box contain valid data...
Search for the comment elst in app/basicMP4Writer.cpp. Two 4-byte values are written to the edit list box:

The STTS stuff is a bit harder to find (forgot to add an "stts" comment), search for comment 2 entries used in basicMP4Writer.cpp.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-03-11 06:45:35
I already found them all, also by examining a file I encoded, locating the offsets, and searching for them in your code. It also helps that I was comparing against Apple's documentation of the format. I outlined the changes to him, but I'm not sure if he's noticed yet.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-03-14 00:55:09
Bump: Curses, foiled again. No WAVEFORMATEXTENSIBLE support. Have fun supporting that!

Edit: Curses, foiled twice. FDK-AAC doesn't support decoding USAC channel configurations other than mono and stereo.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-03-14 18:09:49
FDK-AAC doesn't support decoding USAC channel configurations other than mono and stereo.
Does it specifically disallow decoding of more than two channels, or does it only allow decoding of only one channel-type element (SCE, CPE)? I'm asking since the exhale library also supports dual-mono encoding of a stereo signal using two SCEs (Edit: channel configuration 8, if I'm not mistaken).

And one more question: how does foobar2000 calculate the mean bit-rate across an MPEG-4 file? In exhale I calculate it as (file size in bytes - static header part in bytes) * 8 / (actual input audio length in seconds), which is also written to the MPEG-4 file header, but Windows Explorer e.g. reports very different values.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-03-14 23:17:01
I'm not sure, since I don't have the source. I only control a packet decoder.

This is the relevant code from FDK-AAC:

https://github.com/mstorsjo/fdk-aac/blob/master/libMpegTPDec/src/tpdec_asc.cpp#L1959
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: hyaudio on 2020-03-19 06:54:23
Exhale has more restrictions than I expected.

It doesn't support 44.1 and 48 kHz for Stereo@64 and 80 kbps, and even no 32 kHz support for Stereo@64 kbps, although AAC-LC, HE-AAC and Opus support 48 kHz at those bit rates.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-03-19 10:50:21
Although Apple's AAC-LC encoder can encode 44.1kHz signal at 64kbps / 80kbps, the result is band-limited to 12kHz / 15kHz, respectively.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-03-19 12:49:57
exhale is at an early stage of development. It will take time to get a proper quality.
I think it's worth to test at 96 kbps and higher at this point.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-03-19 21:54:09
Exhale ... doesn't support 44.1 and 48 kHz for Stereo@64 and 80 kbps ... although AAC-LC ... and Opus support 48 kHz at those bit rates.
Supporting those sampling/bit-rate combinations doesn't mean those will sound good, i.e., better than the same bit-rate with a lower sampling rate. In fact, with AAC-LC they don't. exhale, like AAC-LC, doesn't implement Spectral Band Replication (SBR) as a means for bandwidth extension (see also my first post, #9, in this thread), so the best average sound quality you can get with CVBR preset 1 is with a sampling rate of 22.05 or 24 kHz.

That being said, the <=32-kHz restriction for CVBR preset 2 is imposed by the exhale application, not the coding library. I just removed that constraint in the Git source code so you can encode 44.1-kHz audio at roughly 80 kbit/s stereo and an audio bandwidth of 15.2 kHz. However, this is not a recommended configuration since, to my ears, at this rate exhale sounds a bit better with an input sampling rate of 32 kHz. So I added a WARNING print-out during encoding if you use that configuration.

By the way, are people interested in automatic downsampling of >32 kHz audio for encoding with CVBR modes 1 and 2? Then I'll add this to my To-Do list for a later release version.

Edit: I just released version 1.0.2 of exhale with basic joint-stereo coding support for CVBR modes below 5 and some speed-up over the previous version, see

https://gitlab.com/ecodis/exhale/-/releases/v1.0.2

Regarding the mid-quality range (CVBR modes 1 - 4), we're slowly but steadily getting to a point where I'm actually beginning to like exhale's audio quality ;) But there are some issues left to address. Most importantly, I hear some rare plops and clicks which obviously need to be fixed. At this point I don't know, though, whether these are a result of a bug or some shortcoming in exhale's psychoacoustic model. If there is anyone interested in testing exhale (e.g. with the latest foobar2000 version 1.5.3 and kode54's decoder component from https://www.foobar2000.org/components/view/foo_pd_aac, you can play xHE-AAC files in foobar2000), please help me out by reporting here any occurrences of

- signal amplifications (plops, clicks, hiss, noise bursts, etc.) or attenuations (spectral holes, drop-outs, stereo image collapse, etc.)
- undercoding (average bit-rate much lower than CVBR target rate) or overcoding (average bit-rate much higher than target rate)

on any file or audio sample in your collection. All these cases are unintended at any target rate and, therefore, indicate an issue.

Thanks and stay healthy!

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-04-02 02:24:42
Chris, kode54

Thank You for foobar2000 xHE decoder.  That was fast.  :)
I will try to give a try to a new release now that  real-part joint stereo was implemented.

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: sPeziFisH on 2020-04-02 11:17:11
@Christian/C.R.Helmrich
reg. https://gitlab.com/ecodis/exhale (https://gitlab.com/ecodis/exhale) > Readme.md
after reading some notes in this topic..maybe it makes sense to optimise pointing out what exhale is aimed at, maybe also the notes about bitrate-assessments and maybe to add a chapter with simple recommendations or a list of some quote-snippets - just to better put things into a frame and as it still happens that interesting notes might get unnoted in existing evolving forum-discussions, and beside the wiki.
Of course there is https://www.iis.fraunhofer.de/de/ff/amm/rundfunk-streaming/xheaac.html (https://www.iis.fraunhofer.de/de/ff/amm/rundfunk-streaming/xheaac.html), their Audio-Blog and much more.
From a user point of view it is sometimes challenging to accurately class things - there are always tech-interested-users following advancing topics 8)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-04-02 12:05:18
If anyone is interested, there are win32 and x64 compiles available here:

exhaleApp_v1.0.2_win32.rar (http://www.rarewares.org/files/aac/exhaleApp_v1.0.2_win32.rar)

exhaleApp_v1.0.2_x64.rar (http://www.rarewares.org/files/aac/exhaleApp_v1.0.2_x64.rar)

 :)

Edit to add version munber.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-04-02 13:21:14
@Christian/C.R.Helmrich
reg. https://gitlab.com/ecodis/exhale (https://gitlab.com/ecodis/exhale) > Readme.md
after reading some notes in this topic..maybe it makes sense to optimise pointing out what exhale is aimed at, maybe also the notes about bitrate-assessments and maybe to add a chapter with simple recommendations or a list of some quote-snippets - just to better put things into a frame and as it still happens that interesting notes might get unnoted in existing evolving forum-discussions, and beside the wiki.
You mean summarizing, e.g. in the Read-Me, things like the fact that SBR is not implemented in exhale, some notes of my first post in this thread (https://hydrogenaud.io/index.php?topic=118888.msg980837#msg980837), and how to decode xHE-AAC files? I'll add some of that information into the exhale Wiki (https://gitlab.com/ecodis/exhale/-/wikis/home), but I guess you're right, I could link to more information in the Read-Me. Thanks for the suggestion!

I will try to give a try to a new release now that real-part joint stereo was implemented.
Note that only a basic full-frame version of that tool is implemented so far. I'll add a bit more joint stereo functionality to fully exploit what the USAC standard allows, hopefully during the next few weeks.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-04-03 02:02:23
Bug in the Windows version: If you give it a relative path for the input files (and possibly also the output files), it will resolve that path against the current working directory, which the executable appears to set to its own location, rather than whatever it was when it was invoked. Thus, I find I need to give it absolute paths.

This also breaks use with the foobar2000 converter, which uses CWD plus pathless filename, rather than absolute paths, when invoking converters.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-04-03 03:46:22
Note that only a basic full-frame version of that tool is implemented so far. I'll add a bit more joint stereo functionality to fully exploit what the USAC standard allows, hopefully during the next few weeks.
Yes,  it's true. xHE-AAC also implements complex-value (MDST) joint stereo.

I haven't performed critical listening test yet, hopefully will get into it sooner.  But I have encoded few albums +critical samples  at ~96 kbps (CVBR 3)  and quality actually is very good!  Maybe it's not perfect-perfect (considering bitrate) but it's on high side, that's for sure.  I hear some HF flushing, smearing and slightly metallic noise that's typical to AAC family codecs, some minor transients artifacts. But it's  just very slightly and only in some situations, so no showstopper .  :)  I haven't noticed any heavy stereo coupling either.

Some numbers. Right now exhale codes up to 15.6-15.8 kHz at 96 kbps, similar as for high-quality LC-AAC encoders.

Encoding speed on my i7-9750H
1 thread - ~13-14x
all 12 threads - ~90x

Decoding speed - ~174x

As for my hardware it's fast enough.

All in all, it's a good release and definitely great start.

Thank You.

P.S. Bitrate distribution (CVBR) is fair and conservative, similar to Apple AAC CVBR.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-04-05 20:52:03
 First and fast test of xHE at ~96 kbps. I just jumped to compare exhale xHE-AAC encoder with today best performers, Opus and Apple AAC.

Files exhale 1.0.2.1  test 96 kbps (https://drive.google.com/file/d/16lz26_DEaEKqur1WuOe9kUMdjucPzcFw/view?usp=sharing)

TL;DR

Opus performs best on transients
Apple AAC and exhale xHE-AAC  perform best on tonal samples.
xHE-AAC exhale is in active development, so quality will improve.

Q: Why AAC and Opus are on par in my personal test while  Opus outperforms  AAC in public test (https://listening-test.coresv.net/results.htm)?
A: Because my particular perception is somewhat different from a perfectly representative listener.  https://listening-test.coresv.net/s/donator_IgorC.svg

I think other members of Hydrogenaudio forum can try and report issues, bugs and hard samples  while exhale is in active development.  You can find everything in previous posts, binaries of encoder and foobar decoder.

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: LithosZA on 2020-04-13 09:26:44
I was wondering how much does the 'low complexity' part of xHE-AAC differ from normal LC-AAC?
The reason why I'm asking is, if there isn't any difference then can exhale be modified to also generate files compatible with older LC-AAC decoders?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-04-13 14:19:05
USAC has some additional tools such as time-warped filter bank, noise filling or something (which can be disabled by defining RESTRICT_TO_AAC when building exhale), and also uses arithmetic coder while AAC uses Huffman (which is not implemented in exhale).
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-04-13 16:45:53
Add on top of that  MDST  joint-stereo prediction so, yes,  'low complexity' xHE-AAC is quite different from LC-AAC.

And it's not interesting anymore to develop LC-AAC encoders  :-\ .  Patents have expired   :D

BTW there were some interesting changes.  Current version 1.0.2.5  brings some improvements, especially to transients. https://gitlab.com/ecodis/exhale/-/commits/master


Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-04-26 12:52:18
LithosZA, on top of what nu774 and IgorC mentioned, the USAC bitstream format is also quite different from that of (HE-)AAC, and only the USAC one is implemented in exhale.

IgorC, thanks a lot for your careful listening above! I analyzed your encodings and comments and released exhale version 1.0.3 today, see https://gitlab.com/ecodis/exhale/-/releases/v1.0.3

exhale 1.0.3 - Change Log
- extended basic joint-stereo coding functionality for mid/high rates, minor bugfixes
- exhaleLib: band adaptive joint-stereo coding for all CVBR modes, fixed rare crash
- exhaleLib: audio quality fine-tuning, especially for very tonal and transient signals
- makefile: -std=c++11 to allow for compilation with older versions of gcc (issue #4)

There is also an updated version 1.9 of kode54's foobar2000 packet decoder available at https://www.foobar2000.org/components/view/foo_pd_aac so I highly recommend updating both the encoder and decoder.

I'm still not totally happy with the way exhale handles click-like transients in some electronic music, but overall, all quality critical mid/high-rate xHE-AAC coding components are now implemented in exhale, so I believe we can focus on sample specific "killer sample tuning" now. For help with that I'd like to repeat my previous call for volunteers doing what Igor has done, and reporting any quality issues or crashes (see also my previous post above). Of course you can use whatever audio samples you like for that purpose.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-04-26 16:03:15
Hello,

1.0.3 (http://aiz.free.fr/exhale-v1.0.3.zip) binaries (win32 & win64, MSYS2/GCC 9.3.0).

AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-04-26 16:46:48
MSVS2015 win32 and x64 compiles available here:

www.rarewares.org/files/aac/exhaleApp-v.1.0.3_x86.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.3_x86.zip)

www.rarewares.org/files/aac/exhaleApp-v.1.0.3_x64.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.3_x64.zip)

:)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Destroid on 2020-04-27 06:47:38
Hi, I compared the 1.0.2 x86 to the john33 1.0.3 binary. System is i5-core 32-bit OS:
Code: [Select]
exhale  1.0.2 win32   enc     1.0.3 x86               enc
 mode    filesize    speed     filesize (vs. 1.0.2)  speed (vs. 1.0.2)
------  -----------  -----    ----------- ---------  ----- ---------
mode 1   68.72 kbps  6.81x     64.38 kbps  (-6.32%)  7.44x  (+9.15%)
mode 2   79.08 kbps  6.67x     74.97 kbps  (-5.20%)  7.17x  (+9.30%)
mode 3   93.89 kbps  6.07x     90.44 kbps  (-3.67%)  6.46x  (+9.40%)
mode 4  106.01 kbps  5.70x     98.43 kbps  (-7.15%)  6.18x  (+9.22%)
mode 5  120.88 kbps  5.12x    111.25 kbps  (-8.00%)  5.84x  (+8.77%)
mode 6  137.75 kbps  5.98x    120.21 kbps (-12.73%)  6.92x  (+8.64%)
mode 7  143.44 kbps  5.90x    131.57 kbps  (-8.30%)  6.66x  (+8.56%)
mode 8  159.53 kbps  5.74x    146.43 kbps  (-8.21%)  6.41x  (+9.00%)
mode 9  168.30 kbps  5.68x    154.58 kbps  (-8.15%)  6.28x  (+9.04%)

For what I can tell the files sound fine for their given bitrates (I primarily use lossless in studio projects, but getting back into speed benchmarks lately).

@AiZ: Is your x86 compile all 32-bit? I get an error "Entry point Not Found (GetTickCount64)."
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-04-27 11:45:26
Hi, I compared the 1.0.2 x86 to the john33 1.0.3 binary. System is i5-core 32-bit OS
...
For what I can tell the files sound fine for their given bitrates (I primarily use lossless in studio projects, but getting back into speed benchmarks lately).
Thanks very much for testing, especially the 32-bit compile (I tend to focus on 64-bit in my own tests since that's a bit faster). But your reported bit-rates scare me a bit, for all modes above 1 they are much lower than the target rate (e.g., mode 9 should average at 192 kbit/s). What kind of audio content are you compressing here, and how much of it (duration)? Is it particularly easy to compress, e.g., does it contain a lot of silence or is it mono-signal-in-stereo-channel audio?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-04-27 14:18:46
Damn,
@AiZ: Is your x86 compile all 32-bit? I get an error "Entry point Not Found (GetTickCount64)."
Are you still running Windows XP? Can you download and try again (archive updated)?

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Destroid on 2020-04-27 20:33:32
@C.R. Helmrich: I admit for not trying many types of music in the previous test, I used mixes of my studio tracks (3-piece group, alternative/hard rock). The material is monophonic to a point, but at the same time it's not. I thought if quality didn't suffer you would have been happier about the drop in bitrate between 1.0.2 and 1.0.3, especially since 1.0.2 mode 6 and mode 7 were fairly close in bitrate (which seems corrected in 1.0.3).

Instead of using unknown/unheard material I retried with a couple CD's I had nearby that other users might also have.

Here's some data on the tested material, then the results:

Code: [Select]
Foobar 2000 1.5.1 Replay Gain / Album Gain scan:

studio tracks {WIP, unreleased}            -10.82 dB
Dire Straits "Brothers In Arms" [W2 25264]  +4.81 dB
Legion Of The Damned "Feel The Blade"      -14.13 dB
Code: [Select]
exhale
v1.0.3  Brothers In Arms      Feel The Blade
 x86     filesize    speed     filesize    speed
------  -----------  -----    -----------  -----
mode 1   63.89 kbps  7.48x     57.97 kbps  7.08x
mode 2   78.39 kbps  7.08x     68.48 kbps  7.08x
mode 3   90.71 kbps  6.59x     82.68 kbps  6.40x
mode 4   97.05 kbps  6.37x     89.97 kbps  6.12x
mode 5  109.47 kbps  6.04x    104.02 kbps  5.71x
mode 6  118.19 kbps  7.19x    113.52 kbps  6.70x
mode 7  129.49 kbps  6.91x    125.69 kbps  6.39x
mode 8  143.91 kbps  6.63x    141.39 kbps  6.10x
mode 9  151.60 kbps  6.47x    150.04 kbps  5.96x

These results are not what I expected: most of the modes had bitrates less than the previous test. I seriously doubt the CD's tested are more monophonic than my studio works.

@AiZ: You're right, Im running WinXP x86 to several factors too boring to explain :/ (All cards on the table, I have to change the Minimum OS Version of the john33 binaries so they can run on my machine.) Also, I re-downloaded the x86 from the link  afew hours ago and and ended up with the same binary.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-04-27 21:36:43
Well,

Put my hands on a Pentium4 running Windows XP so I could test the win32 binary. Should be Ok now (archive updated again).

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-04-27 22:03:29
The link for the x86 version at Reply #41, above, has been recompiled and re-uploaded and should now be 'XP friendly'. ;)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-04-27 23:53:52
@C.R. Helmrich: I admit for not trying many types of music in the previous test, I used mixes of my studio tracks (3-piece group, alternative/hard rock). The material is monophonic to a point, but at the same time it's not. I thought if quality didn't suffer you would have been happier about the drop in bitrate between 1.0.2 and 1.0.3, especially since 1.0.2 mode 6 and mode 7 were fairly close in bitrate (which seems corrected in 1.0.3).
...
These results are not what I expected: most of the modes had bitrates less than the previous test.
Thanks for the clarification. The slightly lower bit-rate for "easy to code" stereo audio in exhale 1.0.3 can be expected because the joint-stereo coding implementation in exhale got a bit more efficient in version 1.0.3. I also have the Dire Straits "Brothers In Arms" CD (mid-1990s remaster) and just tried it myself. I have to say, I get totally different bit-rates: for CVBR modes 2, 3, 4, 5, 6, 7, 8, and 9 and 44.1 kHz sampling rate, I get 79, 98, 110, 128, 140, 157, 176, and 189 kbit/s, respectively. Are you encoding at a different sampling rate?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: itisljar on 2020-04-27 23:55:19
I am sorry if I am intruding, but what is this codec, exactly? Some sort of upgrade over traditional LC-AAC codecs? Are old AAC decoders capable of decoding this stream? I've tested few songs, and at L3 they sound OK, I didn't do any ABX, will wait for a bit for that.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Destroid on 2020-04-28 03:16:21
Are you encoding at a different sampling rate?
Yes, exactly. 24khz for mode 1 and 32khz modes 2 through 9. Did I misread those were the maximum sample rates for those modes? Or maybe that was just for version 1.0.2.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-04-28 04:35:25
Destroid,

exhale doesn't need resampling starting  from CVBR mode 3 (~96 kbps) all way up to  mode 9 (~192 kbps). 
Even decent LC-AAC encoders  does 44.1 kHz (without resampling) at 96 kbps and higher. Add to it that  xHE format has higher compression efficiency than LC-AAC at any rate.  So it wont be bad idea  to keep 44.1 kHz even for mode 2.

I am sorry if I am intruding, but what is this codec, exactly? Some sort of upgrade over traditional LC-AAC codecs? Are old AAC decoders capable of decoding this stream? I've tested few songs, and at L3 they sound OK, I didn't do any ABX, will wait for a bit for that.
Your apology is unnecessary :)
Basically exhale  is an encoder of a newer generation audio standard USAC/xHE-AAC, which is not the same thing as LC-AAC nor HE-AAC.
Here You will find the answer. https://hydrogenaud.io/index.php?topic=118888.msg982087#msg982087

IgorC, thanks a lot for your careful listening above! I analyzed your encodings and comments and released exhale version 1.0.3 today, see https://gitlab.com/ecodis/exhale/-/releases/v1.0.3
Great!

If somebody could submit a few tests or observations that would be even better and more representative.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Destroid on 2020-04-28 17:05:20
@IgorC
Thanks for getting me on track. When I first started benching with 1.0.2 I saw mode 2 warning and made a bad assumption.

Here's the summary of re-testing:
Code: [Select]
mode         exhaleApp       exhaleApp      exhale GCC
   sample    1.0.2 x86       1.0.3 x86      1.0.3 win32
   rate     kbps  speed     kbps  speed     kbps  speed
-- -----   ------ ------   ------ ------   ------ ------
1  24kHz    68.74  6.80x    64.42  7.38x    64.37  7.47x
2  44kHz    79.44  9.70x    75.82 10.12x    75.82 10.92x
3  44kHz    96.73  8.64x    94.34  8.87x    94.34  9.52x
4  44kHz   114.71  7.86x   106.50  8.34x   106.50  8.89x
5  44kHz   131.36  7.08x   121.91  7.90x   121.91  8.34x
6  44kHz   150.47  8.57x   133.35  9.57x   133.35 10.27x
7  44kHz   159.69  8.37x   148.19  9.14x   148.19  9.79x
8  44kHz   179.60  8.16x   166.88  8.83x   166.88  9.4x1
9  44kHz   192.47  8.06x   179.19  8.67x   179.19  9.15x
Interestingly (to me) are the encode speeds are much faster with 44kHz than 32kHz sources.

I'll stop clogging this thread with speed benchmarks to get on with the real testing (the listening tests, that is until I read about new speed improvements :) ). Mostly I've tinkering with scripts during a time when performing live shows is not happening much.

@AiZ
Thanks for the updated binaries. I know it's not fun to support outdated OS'es. I like that GCC has a performance edge on the 32-bit platform. :)

@john33
Another thanks for the update, as always you're awesome with getting compiled out there. :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-04-29 02:38:04
Yes, exhale allows encoding 44.1-kHz audio starting at CVBR mode 2. In fact, it can handle up to 96 kHz sampling rate from mode 3 or 4 upwards, with a maximum coded audio bandwidth of 27 kHz at mode 4 and 96 kHz input which increases by 3 kHz with each further mode (i.e., up to 42 kHz at mode 9). I don't recommend using exhale that way, though. Just fyi, for the curious or secret audiophiles among us ;)

Unfortunately, I broke that feature some time ago (causing exhale to crash on >48 kHz sampling rates) and had to commit a fix today. John33, AiZ: fyi, since that fix doesn't seem to change "normal" encoding in any way, I'll probably move the 1.0.3 release tag soon to include that high-sampling-rate fix.

Destroid, your testing is much appreciated! In fact, it led me to check more sampling rates as input, and to get them working again :) For completeness of your testing, would it be possible for you to post your mean bit-rates for only the Dire Straits album, so I can cross-check with my results?

Btw, 32-kHz audio triggers a different encoding speed level than higher sampling rates, so that speed difference is somewhat intended.

Quote
So it wont be bad idea to keep 44.1 kHz even for mode 2.
That's actually something I'm trying to figure out currently: What sounds better with mode 2 on average, 44.1 or 32 kHz sampling rate? So all those for whom evaluating mode 3 is too difficult, feel free to focus on mode 2 now.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-04-29 17:20:46
Ok,

John33, AiZ: fyi, since that fix doesn't seem to change "normal" encoding in any way, I'll probably move the 1.0.3 release tag soon to include that high-sampling-rate fix.
Archive updated with current master.

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Destroid on 2020-04-29 19:11:47
@C.R.Helmrich

I have the average bitrates for "Brothers In Arms." Note the results are those reported by exhaleApp.exe (more about this below):
Code: [Select]
mode Track1 Track2 Track3 Track4 Track5 Track6 Track7 Track8 Track9
     +3.60  +3.29  +3.29  +6.27  +10.92 +5.44  +3.81  +2.48  +5.81
--   -----  -----  -----  -----  -----  -----  -----  -----  -----
1     66.8   67.1   61.2   66.5   63.5   67.3   66.6   65.4   63.0
2     79.1   79.1   76.6   82.7   81.4   84.0   80.3   80.2   80.7
3     99.5   98.4   94.0  100.6  100.1  104.6  100.0   97.1   99.6
4    111.9  110.0  103.6  111.5  110.8  117.4  112.1  107.4  110.3
5    131.0  128.6  120.4  128.8  129.2  138.1  131.0  122.9  129.5
6    144.0  140.8  132.0  140.4  141.3  151.0  143.4  133.5  142.2
7    161.0  157.1  147.8  156.5  157.7  167.8  159.8  148.8  159.1
8    180.2  175.7  165.4  175.7  175.6  187.5  179.0  166.5  176.5
9    193.6  188.7  178.2  188.9  188.9  201.1  192.2  178.8  189.9

Note: The replaygain values in the table for each track were derived from the WAV files scanned Foobar2000 1.5.1 (no WAV processing except Mode 1 resampled to 24kHz by SoX). I assure any users out there the replaygain values are correct :) (proven by Track5 being the quietest song on the album).

As to the bitrate anomaly,

All my previous benches I reported encoder's speed and bitrates via math equations in my script. Sorry I failed to mention this before.

During the album testing above, I noticed a discrepancy with the bitrate values from the exhaleApp.exe and my script. I think this accounts for the low values you noticed since my script is agnostic to the values outputted by the encoder. I had written the script to account for any encoder lacking to report speed ( WAV_duration / encoder_time ) or bitrate (below), or just simply the binary does not output to CON via redirect ( > or >>). In this case, the discrepancy of my script is based on my equation:

bitrate = ( xHE_filesize * 8 ) / ( WAV_total_samples / WAV_sample_rate ) / 1024

Obviously the last constant caused the discrepancy, and is exacerbated by higher bitrate modes. Also, there's a slightly lower average bitrate for not taking in account the file container/metadata although no tags were entered when encoding strictly from the command line.

Any comments are welcome! (Flames can be sent PM. :) )
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-04-29 23:08:19
OK, now we have explanations for everything. No need for flaming ;) Note that, unlike with file sizes, it's common practice to measure data rates in "lower-case kilobits" as multiples of 1000, not 2^10. So multiplying your former bit-rate results with 1.024 leads to bit-rates which are very close to the respective target rates. So everything looks good now, I think. Thanks again for the clarification!

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-04-30 19:23:16
del. my bad. wrong resamling.  O:)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-05-01 22:00:33
Hello,

Being stuck at home, I make silly things. Like encoding samples from this thread (https://hydrogenaud.io/index.php?topic=113985.0), with all released versions of exhale (plus latest commit), at level 3 and list resulting bitrates.

1.0.01.0.11.0.21.0.3a3be5338
41_30sec109110112115114
finalfantasy10110010098101
ATrain106106110114113
BigYellow109110109105105
FloorEssence105106105107108
macabre9695100107107
mybloodrusts97971019596
Quizas103104107110110
VelvetRealm106105108114113
Amefuribana100100101105104
Trust99100102101101
Waiting103103106109109
experiencia107108104101101
HearttoHeart105105108103103
Tom'sDiner115115102104104

1.0.01.0.11.0.21.0.3a3be5338
castanets106107100106106
fatboy_30sec111112111115115
eig99101102114113
Bachpsichord106105111117122
Enola110110108106105
trumpet101100106105102
applaud104106107107107
velvet108109109107107
Linchpin9394959292
spill_the_blood102102106108109
female_speech104105979796
French_Ad104104101103103

I'll (try to) update this post with newer versions.

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-02 07:58:02
 AiZ,
Those samples are actually killers so it's normal if encoder codes them at significantly higher rate.
I also have checked  1.0.2.1 and 1.0.3.0 on several albums. Both produce less or more the same bitrate.


Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-02 08:05:41
Comparison of 1.0.3.0 vs 1.0.2.1 at 96 kbps (CVBR mode 3).

Congrats, Chris, 1.0.3.0 performs very well. Quality is stellar!
exhale is, at least, inline with best encoders .
Thank You for opening the sources of the encoder.

Most of these samples are killlers, so, in a real-life scenario quality is in "excellent" zone for big majority of albums. 
Files on My Drive (https://drive.google.com/file/d/1XQoHPQWGGc_5ULTtr1NzheOYhl0j2FKV/view?usp=sharing)
(https://i.ibb.co/qM21ght/exhale-1-0-3-0-vs-1-0-2-1-new-graph.png)

Credits for graphmaker are Kamedo2's
https://listening-test.coresv.net/graphmaker4.htm
https://listening-test.coresv.net/graphmaker5.htm



Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-05-02 13:20:31
Hi,

Those samples are actually killers so it's normal if encoder codes them at significantly higher rate.
Of course. I was not doing this to say that level 3 encoding was way above 96kbit/s, but to monitor the evolution of Chris' tuning of this wonderful encoder. Hence the use of this kind of samples.

I also have checked  1.0.2.1 and 1.0.3.0 on several albums. Both produce less or more the same bitrate.
Exactly.
I would even go with level 2 setting, more than enough for my hearing and usage.

Have a nice day,

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: itisljar on 2020-05-02 16:33:17
Is there possibility to add this encoder to foobar2000? I tried and miserably failed :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-05-02 16:50:58
https://www.foobar2000.org/components/view/foo_pd_aac
oh, encoder...
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-05-02 16:52:39
Hello,

Is there possibility to add this encoder to foobar2000? I tried and miserably failed :)
It is explained here (https://gitlab.com/ecodis/exhale#third-party-stdin-foobar2000).

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: itisljar on 2020-05-02 17:35:40
Hello,
It is explained here (https://gitlab.com/ecodis/exhale#third-party-stdin-foobar2000).
    AiZ

Jeez, I'm such an eejit! I've been there to see usage for command line :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-02 23:40:25
Interestingly (to me) are the encode speeds are much faster with 44kHz than 32kHz sources.
Indeed, the 32-kHz and 24-kHz encoding was a bit slower than necessary. I changed that last night in the master source.

Of course. I was not doing this to say that level 3 encoding was way above 96kbit/s, but to monitor the evolution of Chris' tuning of this wonderful encoder. Hence the use of this kind of samples.
Thanks, AiZ, for the praise :) And for verifying that I didn't break anything in exhale's bit allocation algorithm recently.

Congrats, Chris, 1.0.3.0 performs very well. Quality is stellar!
exhale is, at least, inline with best encoders .
Thank You for opening the sources of the encoder.
Thanks also to you, Igor, for the praise :) Now that mode 3 seems in good shape, I'll focus on improving mode 2.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-03 02:04:56
Of course. I was not doing this to say that level 3 encoding was way above 96kbit/s, but to monitor the evolution of Chris' tuning of this wonderful encoder. Hence the use of this kind of samples.
Yes, You know that.   I was being precautious before anybody would mention about bitrate deviation on some particular sample and aren't familiar how VBR works.

I would even go with level 2 setting, more than enough for my hearing and usage.
It's not only You.   :)  Many people say that 80 kbps is their limit as well (obviously using the last generation codecs Opus and now  xHE-AAC will go that way too) https://hydrogenaud.io/index.php?topic=114656.msg945200#msg945200

Mode 2 (~80 kbps)  is where most of the people might start to perceive something substantial.

Now that mode 3 seems in good shape, I'll focus on improving mode 2
+1
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-03 03:05:02
Chris,

Do You consider to add unrestricted VBR mode (true VBR)?  I understand that true VBR would require to dedicate some additional time for its development. CVBR is good for certain cases so is TVBR.

It's not a coincidence that all popular (and good) encoders have unrestricted VBR . LAME, Helix MP3,  Apple TVBR, Vorbis, Opus and I think your FhG AAC encoder from Winamp as well (?). It means it works for the most of people.

LAME V5(~128kbps)  goes up to 320 kbps on a transients frames. That's 2.5x of a target bitrate!

Maybe 15+ years ago CVBR was a big deal though today most of connections are stable and very fast to admit virtually any variation of unrestricted VBR.  For example, I have  4G connection ~10-100 Mbps  on my mobile but  it's capped to 4 GB per month.  So momentary bitrate peaks isn't an issue.  And if  96 kbps TVBR prevents me to go higher, lets say, to CVBR 112 kbps then it's a good deal to use TVBR (even if some files will end up with somewhat higher bitrate)

As for storage, TVBR is way to go as well.

Cheers.

P.S. Mode 2 can benefit from unrestricted VBR as 80 kbps is where a non-parametric coding is  started to being pushed to its limits.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: andrew.46 on 2020-05-03 05:14:49
There is some joy for Linux users who are interested in using exhale:


What is missing at the moment in the Linux world is availability of playback. Current solution of using Foobar either with Wine or by using a Virtual Machine is fine but native playback would definitely seal the deal.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-05-03 08:46:02
DeaDBeeF was supposed to get a decoder based on FDK-AAC, three years ago. It still hasn't seen the light of day.

Therefore, DeaDBeeF's AAC plugin is not only still libFAAD, but it's also not gapless.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-03 11:09:25
Thank you very very much Christian for working on this project!

I played a bit with this yesterday, at mode #3 (~96 kbps) and indeed quality is far from a basic proof of concept tool and is already better than usable. I listened to a full album with headphone and I quickly forgot that I’m listening to lossy below 100 kbps. Artifacts are audible from time to time but it’s still really nice.

I’m currently building a bitrate table with classical music albums only. It’s based on 91 full discs and my CPU isn’t so young; encoding is therefore a bit long. Speed is between ×30 and ×40 on my i7-3610QM@2,30GHz quad-core laptop for over 100 hours of music. I won’t test all 10 presets but I will compare to other lossy VBR encoders for curiosity.
Example: for mode #3, the average bitrate is 99…100 kbps. Extreme cases are 57 kbps for the lowest and 117 kbps for the highest. For mode #2, average is 81 kbps (min: 50kbps — max: 98). Values are those reported by foobar2000.
Just for comparison, Opus 1.31 VBR 96 deviates a bit more on classical music and it reach 103…104 kbps on the full set (min: 73kbps — max: 121).
I'll post a full table when ready.

Something I noticed is exhale behaviour on monophonic albums (three monophonic discs are included in the set). Average bitrate for monophonic is the same than for stereo album with exhale. But other lossy VBR encoders I’m currently testing have all a huge drop in bitrate with these three discs. Is it intended behaviour?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-03 19:21:20
BITRATE TABLE: CLASSICAL MUSIC ONLY (91 discs, over 100 hours)

Code: [Select]
ENCODER   PRESET            |   BITRATE    |                 STEREO
                            |   FULL SET   |    MONO       LOW BITRATE    HIGH BITRATE
                            |   (91 CD)    |   (3 CD)         (4 CD)        (3 CD)
------------------------------------------------------------------------------------
FLAC CUEtools       -8      |  580.2 kbps  |   467.7 kbps   264.0 kbps   1028.7 kbps
------------------------------------------------------------------------------------
exhale 1.0.3 x64    mode 2  |   80.6 kbps  |    85.7 kbps    54.3 kbps     96.0 kbps
exhale 1.0.3 x64    mode 3  |   99.3 kbps  |   100.7 kbps    62.8 kbps    115.0 kbps
exhale 1.0.3 x64    mode 4  |  110.5 kbps  |   110.0 kbps    67.5 kbps    126.7 kbps
exhale 1.0.3 x64    mode 5  |  131.2 kbps  |   123.7 kbps    77.3 kbps    145.3 kbps


Small comparison between exhale mode #3 and other tools at similar target

Code: [Select]
-------------------------------------------------------------------------------------
  (VBR settings ~96 kbps)   |   BITRATE    |                 (stereo)
                            |   FULL SET   |    MONO       LOW BITRATE    HIGH BITRATE
ENCODER            PRESET   |   (91 CD)    |   (3 CD)         (4 CD)        (3 CD)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
OGG libVorbis I 20150105 q2 |   85.9 kbps  |    72.0 kbps    76.5 kbps    106.3 kbps
MP3 LAME 3.100      V6      |   89.6 kbps  |    60.3 kbps    52.5 kbps    115.7 kbps 
AAC iTunes 7.10.9.0 tvbr45  |   96.8 kbps  |    54.7 kbps    81.0 kbps     99.7 kbps
AAC FAAC 1.29.9.2   -q 120  |   97.4 kbps  |    73.7 kbps    61.0 kbps    158.3 kbps
exhale 1.0.3 x64    mode 3  |   99.3 kbps  |   100.7 kbps    62.8 kbps    115.0 kbps
OPUS 1.3.1 x64      vbr 96  |  103.4 kbps  |    78.7 kbps   104.5 kbps    117.3 kbps
AAC fdkaac 4.0.0 LC mode 3  |  110.6 kbps  |    66.0 kbps    94.0 kbps    108.0 kbps   

In this table you can see that exhale seems quite unefficient with my monophonic records.

_______
About these 91 discs:

I have a very large library with classical music only. Very large means insanely large (the kind of playlist that last several years). Everything is encoded to FLAC (CUETools -8) and the average bitrate for 44.1 KHz/16bit is 581 kbps.
For obvious reason I can’t encode the whole library to get average bitrate for different encoders/settings. Testing means selecting.

Thus my plan was to reduce this huge library to something easier to handle. My first though was to find myself 50 to 100 albums that end with an average bitrate at 581 kbps. But I finally tried something different.
These last 20 years many labels released countless large boxset (All Mozart, All Karajan, Greatest Concerto, 150 years of <choose city> Orchestra, 100 greatest recordings from <label>, etc…). I tried to find one or two boxset and get my ~580 kbps. Bingo! Deutsche Grammophon released a 111 Years anniversary boxset of 55 discs ; Harmonia Mundi a 29 discs anniversary boxset. With both sets I reached 581 kbps (579 kbps on an Excel table). Every classical subgenres and every musical periods are represented. There are three mono albums and recordings from beginning of stereo to 2007. It seems that I found my reference for future tests.

To these 84 CD I also add extreme albums: those which need very little bitrate in lossless (<300 kbps in stereo) and those which requires more than 1000 kbps (which is really rare with classical music). These extremes might be useful to spot how other VBR encoders handles these kind of signals. Consequently I add 4 low bitrate discs and 3 high bitrate discs to the 84 first CD.

The average bitrate for this 91 CD test collection is 582 kbps (weighted by duration) of 580.2 kbps (average values with Excel), values that are very close to my entire library (581 kbps).
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-03 23:22:50
Chris, Do You consider to add unrestricted VBR mode (true VBR)?
Short answer: no.
Longer one: The CVBR algorithm already spends 25% more or less than the target bit-rate on some samples, see, e.g., AiZ's statistics (https://hydrogenaud.io/index.php?topic=118888.msg982740#msg982740) above (Bachpsichord sample). That's already more than the ±20% range I initially planned for. Also, apart from such harpsichord samples, I haven't found any other content so far for which, at a sampling rate of 44.1 kHz or more and CVBR mode 3 or less, high sound quality can only be reached by pumping bits into the encoding*. Finally, the "C" in exhale's CVBR algorithm actually does a more subtle job than you might think, see also the following answer.

Average bitrate for monophonic is the same than for stereo album with exhale. But other lossy VBR encoders I’m currently testing have all a huge drop in bitrate with these three discs. Is it intended behaviour?

... exhale seems quite unefficient with my monophonic records.
Thanks very much for testing! This is intended behavior and represents the most noticeable part of the "C" in exhale's CVBR approach. Having said that, it seems to have worked better for modes > 4 than for the lower modes, so I just committed a minor change (https://gitlab.com/ecodis/exhale/-/commit/c7de6bb9) to the source which reduces the bit-rate on such mono-in-stereo content. Would it be possible for you to recollect your statistics for modes 2 - 4 with the latest Git master version? If you're short on time, doing that only for mode 3 would also be fine.

Chris

* The sound quality on, e.g., the Fatboy and Linchpin samples could, in principle, be improved in different ways, without increasing the bit-rate.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-05-04 01:26:12
Here, have some binaries with that commit added. Built with MSVC 2015, settings modified to use "fast" math, and the 32 bit build modified to use the v140_xp SDK and only IA32 math, so it should technically work on something fairly old.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-04 09:32:26
Would it be possible for you to recollect your statistics for modes 2 - 4 with the latest Git master version? If you're short on time, doing that only for mode 3 would also be fine.

Hi, thank you for your reply. I have no problem with measuring the bitrate evolution.
I add mode 1 and mode 6 in the table (with exhale 1.03, before change) :

Code: [Select]
ENCODER   PRESET            |   BITRATE    |                 STEREO
                            |   FULL SET   |    MONO       LOW BITRATE    HIGH BITRATE
                            |   (91 CD)    |   (3 CD)         (4 CD)        (3 CD)
------------------------------------------------------------------------------------
FLAC CUEtools       -8      |  580.2 kbps  |   467.7 kbps   264.0 kbps   1028.7 kbps
------------------------------------------------------------------------------------
exhale 1.0.3 x64    mode 1  |   61.1 kbps  |    61.7 kbps    38.3 kbps     72.0 kbps
exhale 1.0.3 x64    mode 2  |   80.6 kbps  |    85.7 kbps    54.3 kbps     96.0 kbps
exhale 1.0.3 x64    mode 3  |   99.3 kbps  |   100.7 kbps    62.8 kbps    115.0 kbps
exhale 1.0.3 x64    mode 4  |  110.5 kbps  |   110.0 kbps    67.5 kbps    126.7 kbps
exhale 1.0.3 x64    mode 5  |  131.2 kbps  |   123.7 kbps    77.3 kbps    145.3 kbps
exhale 1.0.3 x64    mode 6  |  143.4 kbps  |   130.7 kbps    82.5 kbps    157.3 kbps

I'm currently running a batch encoding for mode 3. Twenty albums are already encoded. The trend is that stereo discs are now slightly smaller (-3 kbps on average for the first discs) and mono discs drop from 100.7 kbps to 81 kbps. It's still a bit higher than all competitor I tested but it's way better :)
I'll continue the test :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-05-04 19:16:30
exhale v1.0.3-dea328b1
Built on May 04, 2020, GCC 9.3.0

https://gitlab.com/ecodis/exhale
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-04 20:25:06
Few words: my previous post is totally wrong. I still had 24 KHz resampling enabled (from my mode #1 test) so it explains why bitrate was also lower on stereo on the modified exhale version. I just launched a bew batch… Sorry
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-05 16:37:30
Quote
So it wont be bad idea to keep 44.1 kHz even for mode 2.
That's actually something I'm trying to figure out currently: What sounds better with mode 2 on average, 44.1 or 32 kHz sampling rate?
I think it would be useful to arrange a test in this topic with multiple listeners to test  CVBR mode 2 (~ 80 kbps) -  32 kHz vs 44.1 kHz on these samples (https://hydrogenaud.io/index.php?topic=117489.0)

If somebody is interested feel free to comment  :) . Later I'll upload encoded and lossless samples.  Even a single result from one particular participant will be useful.


Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-05 18:59:45
Here is a table for mode #2 to mode #4, comparing exhale 1.03 and the modified version with mono patch compiled by kode54:

Code: [Select]
                            |   BITRATE    |                 STEREO
ENCODER            PRESET   |   FULL SET   |    MONO       LOW BITRATE    HIGH BITRATE
                            |   (91 CD)    |   (3 CD)         (4 CD)        (3 CD)
------------------------------------------------------------------------------------
FLAC CUEtools       -8      |  580.2 kbps  |   467.7 kbps   264.0 kbps   1028.7 kbps
------------------------------------------------------------------------------------
exhale 1.0.3 x64    mode 2  |   80.6 kbps  |    85.7 kbps    54.3 kbps     96.0 kbps
exhale 1.0.3 mod    mode 2  |   78.5 kbps  |    65.0 kbps    51.0 kbps    102.0 kbps

exhale 1.0.3 x64    mode 3  |   99.3 kbps  |   100.7 kbps    62.8 kbps    115.0 kbps
exhale 1.0.3 mod    mode 3  |   97.8 kbps  |    84.7 kbps    61.8 kbps    119.7 kbps

exhale 1.0.3 x64    mode 4  |  110.5 kbps  |   110.0 kbps    67.5 kbps    126.7 kbps
exhale 1.0.3 mod    mode 4  |  108.9 kbps  |    92.3 kbps    66.5 kbps    132.0 kbps

Monophonic recordings seem now much more efficiently encoded. Most discs are marginally smaller with this patched version. Curiosity: the three “high bitrate discs” (which are three pure harpsichord recordings with exceptionnally high bitrate when encoded with FLAC) are now significantly bigger.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-05 19:29:09
Hi, guruboolez

As of harpsichord, it was mentioned here.
https://hydrogenaud.io/index.php?topic=118888.msg982817#msg982817
Longer one: The CVBR algorithm already spends 25% more or less than the target bit-rate on some samples, see, e.g., AiZ's statistics (https://hydrogenaud.io/index.php?topic=118888.msg982740#msg982740) above (Bachpsichord sample). That's already more than the ±20% range I initially planned for.

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-06 00:03:05
Quote
So it wont be bad idea to keep 44.1 kHz even for mode 2.
That's actually something I'm trying to figure out currently: What sounds better with mode 2 on average, 44.1 or 32 kHz sampling rate?
I think it would be useful to arrange a test in this topic with multiple listeners to test  CVBR mode 2 (~ 80 kbps) -  32 kHz vs 44.1 kHz on these samples (https://hydrogenaud.io/index.php?topic=117489.0)

If somebody is interested feel free to comment  :) . Later I'll upload encoded and lossless samples.  Even a single result from one particular participant will be useful.
Indeed, since the two encoder configurations seem to sound almost identical to my ears and I'm not as sensitive to pre-echo artifacts as some other people on this forum, some "further ears" would be great. But before you start encoding, Igor, please use the same exhale code version as guruboolez to avoid confusion, and please wait for some more results on the following topic:

Here is a table for mode #2 to mode #4, comparing exhale 1.03 and the modified version with mono patch compiled by kode54:
Thanks very much! So it seems for 44.1 kHz sampling rate, the version you tested (https://gitlab.com/ecodis/exhale/-/commit/c7de6bb9) gets the bit allocation right now (on a 10-hour collection of rockish Genesis songs, I get e.g. 80-81 kbit/s on average with mode 2). Now, since Igor proposed to compare 44.1 and 32 kHz sampling rate for mode 2, would you be so kind and run a final batch to collect statisticcs for mode 2 with 32 kHz input sampling rate?  O:) Just to verify that the bit-rate statistics are roughly the same.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-06 12:35:24
would you be so kind and run a final batch to collect statisticcs for mode 2 with 32 kHz input sampling rate?  O:) Just to verify that the bit-rate statistics are roughly the same.
I'll do this! Expect partial results in two hours (then I'll leave)  and final later today.

N.B. I'm in for the listening test :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-06 14:28:48
The batch is still running. On average bitrate is 1 kbps lower by using 32 KHz resampling. Final results later.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-05-06 14:55:57
little more
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-05-06 15:59:29
Just to add to the fun  :)) , Intel 19 compiles:

www.rarewares.org/files/aac/exhaleApp-v.1.0.3-dea328b1_x64.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.3-dea328b1_x64.zip)

www.rarewares.org/files/aac/exhaleApp-v.1.0.3-dea328b1_x86.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.3-dea328b1_x86.zip)

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-06 20:19:55
I have the results for the 32KHz resampled mod2. Bitrate is 0.8 kbps higher on 32 KHz.
Resampling was done with Sox mod on foobar2000, mode normal, with 95% passband.
Weird thing: many files are unlistenable on fb2k. Good files are labeled as AAC / USAC while "corrupted" ones appear as M4A. No codec found on property box. I encoded some files again: one is cured (bitrate unchanged), the other not. I also had 3 or four blue screen. Maybe faulty RAM?

I'll try with john33 Compiles.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-06 21:26:54
Thanks, m14u and guruboolez! Strange, I haven't observed a single blue screen on Windows 7-10 since 2010 or so. And the exhale application shouldn't cause such severe issues. True, sounds like a hardware defect. But for testing, have you tried this Wiki fix (https://gitlab.com/ecodis/exhale/-/wikis/faq#i-get-corrupted-files-when-encoding-using-exhale-via-foobar2000-why)?

Anyway, your reported 0.8 kbit/s bit-rate increase when switching from 44.1 to 32 kHz sampling rate is consistent with m14u's and my own findings, on average the three of us get almost exactly 1 kbit/s bit-rate difference. Which is small enough for me to give the comparative listening test a go.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-07 01:47:42
N.B. I'm in for the listening test :)
Great.

Folks,
I have following points in my mind for this exhale@80 kbps '32 kHz  vs 44.1kHz' test :

- 12-15 samples
- No stricts rules and listener is free to  submit his/her own results in format he/she wants while it's a valid result of a blind test.  There is no strict need for statistical significance ( p<0.05 or any other) , just  ratings of codecs as a result of a blind test would be already fine.
- ABC/HR  Java  of any other suitable application for such purpose.  Choose yours

Suggestions...

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-05-08 02:56:26
exhale v1.0.3-db682d52
Built on May 08, 2020, GCC 9.3.0

https://gitlab.com/ecodis/exhale
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-05-08 21:34:43
mk.II
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-10 00:54:18
I have the results for the 32KHz resampled mod2. Bitrate is 0.8 kbps higher on 32 KHz.
Resampling was done with Sox mod on foobar2000, mode normal, with 95% passband.
I have the same issue with exhale on 32 kHz material.
Also, when SoX 32 kHz passband is gradually increased from 95% to 99% the amount of files on which exhale produces broken output increases too.


Chris,
I will PM to you some of these files which exhale can't digest  .WAV produced with SoX 32 kHz,  99% passband. ( other encoders don't have this issue)

SoX  with parameters 32 kHz, passband 95% is more stable for exhale but also a bit  'too lowpassed' as exhale capable to code ~98-99% passband of 32 kHz sampling rate.
Let us know whether we can proceed with 32 kHz/44.1 kHz test or should we wait for a fix. If an answer is to proceed then I guess we should go with  SoX 98-99% passband for 32 kHz resampling.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-10 02:11:07
Ouch, that's not good. Then we should definitely wait with the 32-vs-44.1 test until we have a solution (or at least an explanation) for this.

Thanks for PMing some files to reproduce this. For clarification, are you guys using SoX on-the-fly in foobar2000 while converting to xHE-AAC? And Igor, m14u, do you also observe crashes like guruboolez did?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-10 02:39:08
Chris,

Yes, I was  using SoX on-the-fly. Issue is gone when SoX isn't used on-the-fly.
As of crashes, I haven't them on my laptop.

Cheers.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-05-10 05:39:09
i am use ffmpeg -ar. linux x64.
failed to beat the sox in the matter of resampling... :)
add report "bit rate" and "maximum  bit rate" by mediainfo.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-10 22:05:55
OK, thanks for the info. Not sure why this happens, but it seems to be related to exhale's way of handling stdin when the input is provided relatively slowly (I assume SoX runs slower when the passband is increased from 95 to 99%).

Anyway, I just commited another stereo cleanup (Git eceadce2 (https://gitlab.com/ecodis/exhale/-/commit/eceadce2)) which hopefully completes the stereo code. I'm still in the process of re-encoding my 10-hour Genesis testset, but so far things seem OK for a listening test to start with that intermediate version. While it's running, I'll take a look into adding some automatic resampling to the exhale application for modes lower than 3.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-05-10 22:33:42
Updated.

1.0.01.0.11.0.21.0.3eceadce2
41_30sec109110112115114
finalfantasy10110010098104
ATrain106106110114113
BigYellow109110109105106
FloorEssence105106105107109
macabre9695100107107
mybloodrusts97971019595
Quizas103104107110110
VelvetRealm106105108114113
Amefuribana100100101105105
Trust99100102101101
Waiting103103106109110
experiencia107108104101103
HearttoHeart105105108103102
Tom'sDiner115115102104110

1.0.01.0.11.0.21.0.3eceadce2
castanets106107100106105
fatboy_30sec111112111115115
eig99101102114113
Bachpsichord106105111117121
Enola110110108106107
trumpet101100106105105
applaud104106107107107
velvet108109109107107
Linchpin9394959293
spill_the_blood102102106108108
female_speech104105979786
French_Ad104104101103102
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-05-11 07:17:18
another little more
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-11 23:16:07
Thanks. I just fine-tuned the mean bit-rate constants for CVBR mode 1 so that, hopefully, both 22.05 and 24 kHz input should result in roughly the same average bit-rates (Git ea74e99). The change also affects modes 2-4, but very rarely. For example, in AiZ's two tables, the only samples for which the bit-rates change are Tom'sDiner (from 110 to 107) and female_speech (from 86 to 85). So no need for re-encoding.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-05-12 04:07:59
I am now publicly listing my foobar2000 decoder component, which will always support USAC, and with a little hackery, should take priority for normal AAC as well, just to verify its decoder is sound for all purposes, except for the rare cases you may need peaks exceeding ±1.0.

This will effectively require foobar2000 version 1.5.4.

I'm also taking an opportunity to report on a possible bug, which won't affect exhale encoded files, but will affect anything encoded with FFmpeg.

The elst chunk is currently interpreted to always be in sample time scale, and disregards the time scale specified in the mvhd box. This is acceptable for exhale encoded files, as they always write a time scale equivalent to the sample rate.

This is unacceptable for FFmpeg encoded files, as FFmpeg always writes MP4/MOV time scale in units of 1000, or milliseconds. This also means that FFmpeg encoded files will not be perfectly gapless, either, as they'll either truncate or round all cue points to the nearest millisecond, even when writing audio files. This also goes for simply processing and rewriting your MOV/MP4 containers with FFmpeg, without doing any additional transcoding.

foobar2000 currently works around an issue with this by disregarding elst blocks when my packet decoder is missing, but this is not correct, either. Even if foobar2000 corrects this, FFmpeg is still doing something rather silly here, in not special casing audio-only streams in its MOV/MP4 container encoder.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-05-12 05:28:56
exhale v1.0.3-ea74e998
Built on May 12, 2020, GCC 10.1.0

https://gitlab.com/ecodis/exhale
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-12 19:00:47
Thanks very much, kode54, for the info! Since this thread has already gotten surprisingly long, let me try to summarize a few things for newly arriving readers. Let me know if I forgot anything.

The current stable version of exhale is still 1.0.3, but the new Git version mentioned in the previous post might result in slightly improved
audio quality at the lower bit-rates (CVBR modes 1-4). I also referenced this thread and another web page on the xHE-AAC format itself on
exhale's Wiki page (https://gitlab.com/ecodis/exhale/-/wikis/) now.

As reported by kode54 yesterday, version 1.5.4 of the audio playback and management software foobar2000 is now available at
https://www.foobar2000.org/download

kode54's AAC packet decoder, allowing gapless playback of xHE-AAC files in foobar2000 version 1.5.4 or newer, can be found at
https://www.foobar2000.org/components/view/foo_pd_aac

I also found an announcement of an exhale GUI, as an alternative to the foobar2000 solution, for easy file/folder-wise encoding:
https://moisescardona.me/collaborating-in-the-exhale-project-part-2

The above options are mostly for the Windows operating system. There are, however, also some options for Linux users, as summarized
by andrew.46 in this post (https://hydrogenaud.io/index.php?topic=118888.msg982787#msg982787).

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-12 19:32:08
I have a complete set of 1.03 encoding now for my 91 CD collection:

Code: [Select]
ENCODER   PRESET            |   BITRATE    |                 STEREO
                            |   FULL SET   |    MONO       LOW BITRATE    HIGH BITRATE
                            |   (91 CD)    |   (3 CD)         (4 CD)        (3 CD)
------------------------------------------------------------------------------------
FLAC CUEtools       -8      |  580.2 kbps  |   467.7 kbps   264.0 kbps   1028.7 kbps
------------------------------------------------------------------------------------
exhale 1.0.3 x64    mode 1  |   61.1 kbps  |    61.7 kbps    38.3 kbps     72.0 kbps
exhale 1.0.3 x64    mode 2  |   80.6 kbps  |    85.7 kbps    54.3 kbps     96.0 kbps
exhale 1.0.3 x64    mode 3  |   99.3 kbps  |   100.7 kbps    62.8 kbps    115.0 kbps
exhale 1.0.3 x64    mode 4  |  110.5 kbps  |   110.0 kbps    67.5 kbps    126.7 kbps
exhale 1.0.3 x64    mode 5  |  131.2 kbps  |   123.7 kbps    77.3 kbps    145.3 kbps
exhale 1.0.3 x64    mode 6  |  143.4 kbps  |   130.7 kbps    82.5 kbps    157.3 kbps
exhale 1.0.3 x64    mode 7  |  159.8 kbps  |   143.3 kbps    89.5 kbps    174.0 kbps
exhale 1.0.3 x64    mode 8  |  176.3 kbps  |   153.3 kbps    97.3 kbps    193.7 kbps
exhale 1.0.3 x64    mode 9  |  189.5 kbps  |   163.0 kbps   102.5 kbps    207.7 kbps

Here are a comparison at mode 2 between 1.03, ea74e998 GCC from NetRanger (2020.05.12) and ea74e998 GCC resampled at 32 KHz:
Code: [Select]
ENCODER   PRESET            |   BITRATE    |                 STEREO
                            |   FULL SET   |    MONO       LOW BITRATE    HIGH BITRATE
                            |   (91 CD)    |   (3 CD)         (4 CD)        (3 CD)
------------------------------------------------------------------------------------
exhale 1.0.3 x64    mode 2  |   80.6 kbps  |    85.7 kbps    54.3 kbps     96.0 kbps
exhale ea74e998 GCC mode 2  |   78.3 kbps  |    65.0 kbps    51.0 kbps    101.7 kbps
exhale ea74e998 GCC m2@32KHz|   79.0 kbps  |    66.7 kbps    48.8 kbps     97.7 kbps


I didn't encounter any blue screen since last time. RAM is apparently OK.
Many mode 2 at 32 KHz are still "corrupted". As I'm not alone to have this problem I haven't investigate further.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-12 20:20:35
I don't know if it helps...

1_ I take a file (CDimage) => encoded with exhale at 32 KHz ==> corrupted

2_ I take the same file  => segmented in 30sec short files & then encoded at 32 KHz ==> all segments are fine

3_ I take the lossless segments => encoded with exhale@32KHz and merged into one file with fb2K ==> it's fine

It's curious: the resulting output should be the same for step 1 and step 3 but the first is corrupted and the second is OK.
I also can't catch any 30 seconds samples which will be corrupted with exhale at 32 KHz...
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-13 02:14:24
I've prepared a test package for 'Sample01'. If everything is ok  and no complaints received then tomorrow (or next day ) we will have a complete bundle for 12-15 samples and new topic for this test.  So let me know if it works for eveyrbody.

Testing conditions:
Version - exhale v1.0.3-ea74e998 (Netranger's build)
Bitrate - CVBR mode 2 (~80 kbps)

Files:
Original 44.1 kHz
exhale 80 kbps 44.1 kHz
exhale 80 kbps 32 kHz 
There was no need to set gains nor offsets as exhale doesn't shift nor change loudness of files (as of last foobar 1.5.4, nice work, kode54).


Chain used for exhale 80 kbps 32 kHz:
Original WAV 44.1 kHz, 16 bits  ->
-> Resampler SoX VHQ, 32 kHz, 32 bits WAV  99% passband which is the highest and still recommended value ->
-> decoded to 44.1 kHz, 16 bits to have the same sampling rate and bid depth as Original and exhale_80kbps_44.1kHz files.

SAMPLE01 contains:

The package was done to run a test on Sample01 without any additional steps (decoding, copy etc). Listeners can choose which application to use (ABCHR Java or ABCHR Win) or any other.

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-14 02:44:51
Thanks very much, Igor! Sorry, I had a very busy day and was able to only check the .m4a files. I noticed that my own Win64 executable produces very slightly different MPEG-4 files than the ones you provided (based on NetRanger's builds), which I guess is due to the use of gcc vs. Visual Studio). That difference doesn't seem to be problematic, though, but I'll check the remaining samples the same way, just to be on the safe side.

I didn't have time to check the ABC-HR setup. Can anyone else confirm that it works for them?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-14 05:27:08
I noticed that my own Win64 executable produces very slightly different MPEG-4 files than the ones you provided (based on NetRanger's builds), which I guess is due to the use of gcc vs. Visual Studio). That difference doesn't seem to be problematic, though, but I'll check the remaining samples the same way, just to be on the safe side.
Agree.  I will proceed with NetRanger's build then.

Thank You.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-05-14 15:56:50
Hello,

Can anyone else confirm that it works for them?
Tested it and seems Ok, albeit I've never used ABC/HR before, only informal ABX with foobar2000.
I'm definitively getting old, unable to hear a single difference between all versions of Sample01.

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-14 17:14:25
@AiZ

Don't worry, it's easy.  ABC/HR is  pretty the same thing as ABX.

The main difference is that You will have two columns in ABC/HR:
1."exhale 80 kbps 44.1 kHz" vs "Original"
2."exhale 80 kbps 32 kHz"  vs "Original" 

I have also included this link in readme.txt. It explains how to perform ABC/HR test
https://web.archive.org/web/20120204073842/http://ff123.net/64test/practice.html



Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-14 20:46:20
I'm definitively getting old, unable to hear a single difference between all versions of Sample01.
Sample01 isn't difficult for exhale, this explains why You don't hear much.

There will be a bunch of difficult  samples where artifacts will pop up easily.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-15 18:47:17

I didn't have time to check the ABC-HR setup. Can anyone else confirm that it works for them?

Tested with ABC-HR for Windows (not JAVA) : no issue.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: samidare1234 on 2020-05-15 19:32:40
Hello,

As far as I know,
Due to many tests.
LC-AAC (QAAC) is good on high bitrates(192kbps↑)
Opus is good at low to mid bitrates(192kbps↓)
HE-AACv2(NERO AAC) is good at extremely low bitrates (48kbps↓)

And due to the information on the internet,
xHE-AAC is look like better then HE-AACv2 on very low bitrates.
http://i.imgur.com/AKAu07I.png

which look like is not the range that exhale-Encoder aims.

So could anyone tell me what bitrante rangs would this encoder is most superior than other best encoders in 2020?

Or it is just an alternative?

Is it good enough for us to convert all music into this codec for the replacement on opus and LC-aac?
 (After searching , doesn't see any comparison yet.)

Thanks a lot !
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-15 23:50:14
Quote
So could anyone tell me what bitrante rangs would this encoder is most superior than other best encoders in 2020?
Or it is just an alternative?
Is it good enough for us to convert all music into this codec for the replacement on opus and LC-aac?
Hi, exhale is just a few months old, and there are no comparisons to other encoders so far (except for Igor's personal tests which he reported earlier in this thread). Before converting your entire music collection, I suggest you wait until more people here have checked the audio quality. But feel free to try it out on a few albums, e.g. at CVBR mode 2, to get your own impression and report any issues you come across.

Quote
And due to the information on the internet, xHE-AAC is look like better then HE-AACv2 on very low bitrates.
http://i.imgur.com/AKAu07I.png
which look like is not the range that exhale-Encoder aims.
xHE-AAC is better that HE-AAC v2 across a quite large bit-rate range, but yes, mostly so at very low rates. Regarding the second part of your sentence, I addressed that in a previous post of mine in this thread, see here (https://hydrogenaud.io/index.php?topic=118888.msg980837#msg980837).

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-16 02:57:04
A new topic was open
Public Test - xHE-AAC exhale encoder, CVBR 80 kbps [32 kHz vs 44.1 kHz] (https://hydrogenaud.io/index.php?topic=119227.msg983192;topicseen#new)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-16 18:29:30
Due to many tests.
Where?
Provide a link for such tests.

LC-AAC (QAAC) is good on high bitrates(192kbps↑)
Opus is good at low to mid bitrates(192kbps↓)
I suggest you to do your own test and You will see  those are  just a fancy comments and, so called, anecdotal evidences. Otherwise  an internet is such a serious thing, right?  When You kindly ask such posters to provide tests or some  information  they get angry or simply don't provide anything.
Any test with bitrate higher than ~96-128 kbps shoud be taken with a big grain of salt and a lot of precaution.
The big majority of people have trouble already at  those rates, 96-128 kbps. https://en.wikipedia.org/wiki/Codec_listening_test

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: samidare1234 on 2020-05-16 21:07:30

Where?
Provide a link for such tests.


Thanks for the information.  :)

On a different note...Different to Audio Codec, Those Image Codec doesn't rely on the human test.
They use many of SNR resault for control the quality on how many differencial to the original one.
On the develoment for a new codec/encoder they almost have a clear aim
(Example: Same quality half size to jpg or some what)
But look like that the audio codec is quite different.

Well, OK, I should correct to "due many test I read for years And my experence"
These is my total resault .
I read many many test and article in many languages of the comparision for the personal interest.
Some of them analyze from the spectrum. Some are the personal test resaults.
And One of parts is like the information from the publick sound test.

For higher bitrates, As least I can take the difference much easily in Limited environment.
For example, the WASAPI/ASIO mode (*Bit-Exact) on a not too bad audio system with good SNR and Dynamic Ranges.

And the age is a big facter.(Some children can sound 20Khz) Those ABXtest I think is on there normal environment.
And Some of the people lose there Hearing acuity due to the loud sound in there lives (Example: go to movie, Play loud music on earphone)

So I agree for most of the time about 128~192 is already a cut off point for good enough
Public use or say normally use especially for streaming.
Lower than that is a trade-off.

For the above reasons,
 I think that all sound tests are not a decisive evidence.
They can only be a reference.

But We know that HE-AACv2 is one of best at low rate.
Opus is one of best modern codec at wide-range bitrates. (That Youtube and most streaming shift to)

In mid-high bitrate, Opus has the SRC problem which many of my cd is on 44.1khz.(Movie or some what is at 48Khz so no problem)
I can here the artifact on them So I leave the LC-AAC better than opus on my comment.

Anyway, I will Give A try on xHE-AAC. ;D  Thanks!

(Sorry for my English)

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-17 18:21:45
Thanks very much for preparing the public test, Igor! While it's running, I took another look at CVBR mode 1 (~64 kbit/s stereo) and now allow it to be coded with 32 kHz sampling rate (Git 41751381 (https://gitlab.com/ecodis/exhale/-/commit/41751381)). CVBR mode 2 and 3 shouldn't have changed.

@samidare1234
Quote
On a different note...Different to Audio Codec, Those Image Codec doesn't rely on the human test.
Actually, they do. I know because my daytime job currently involves the standardization of a new video codec, VVC (http://www.ecodis.de/video.htm#h266).

Quote
They use many of SNR resault for control the quality on how many differencial to the original one.
On the develoment for a new codec/encoder they almost have a clear aim
(Example: Same quality half size to jpg or some what)
But look like that the audio codec is quite different.
That's because things like SNR don't tell you much any more in the audio coding world. See also the following comment.

Quote
I read many many test and article in many languages of the comparision for the personal interest.
Some of them analyze from the spectrum.
This kind of analysis might have worked in the 1990s with codecs like MP3. It hasn't worked for the last 20 years, which is why we don't do this on this forum. Nowadays, the only analysis that works reasonably well with lossy audio codecs is double-blind subjective evaluation with many human listeners, which is why we do this regularly on this forum.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-05-18 14:32:08
v.1.0.3-41751381:

www.rarewares.org/files/aac/exhaleApp-v.1.0.3-41751381_x64.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.3-41751381_x64.zip)

www.rarewares.org/files/aac/exhaleApp-v.1.0.3-41751381_x86.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.3-41751381_x86.zip)

:)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-19 17:26:32
v.1.0.3-41751381:

www.rarewares.org/files/aac/exhaleMac-v.1.0.3-41751381_x64.zip (https://gofile.io/d/wdaQei)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-05-19 20:18:32
excellent quality.
But consider  vbr and cbr options in the future to force a low bitrate.
It is excellent for music, but I like also speech options and not always 64 kbps.
I know to now the focus is music and the encoder is still new.
Also when we will have USAC decoder on VLC, lav filters or Foobar (even of mobile, now is only with a component in PC)?

Still I'd like an encoder that rarely goes more than 63 kbps.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-19 20:44:23
Right now the mobile devices are the ones that don't have problems, Android and iOS have the decoder from at least 2 years.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-05-19 21:26:42
v.1.0.3-41751381:

www.rarewares.org/files/aac/exhaleMac-v.1.0.3-41751381_x64.zip (https://gofile.io/d/wdaQei)
You may be well intentioned, but please do not use a pseudo URL to which you are not entitled. You give the impression that this file is hosted by Rarewares which it is not.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-19 23:30:05
Sorry, I was a fool, I copied and pasted your text and then I only added Mac instead of App without removing the path.

I just wanted to integrate your message in the same style, I sent you a PM with the file that I compiled on my Mac because otherwise I would have been excluded from the tests.

In the end I didn't finish anything because I miss the other programs, but at least I was able to try the encoder.

v.1.0.3-41751381:
exhaleMac-v.1.0.3-41751381_x64.zip (https://www.celona.it/exhaleMac-v.1.0.3-41751381_x64.zip)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-05-20 07:48:23
No problem, thanks for the explanation. Once the encoder is finalised, I'm sure we would be happy to host a Mac compile at Rarewares if you would like us to do so.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-05-20 10:17:54
For example I can't use VBR 79 kbps or vbr 121 kbps.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-05-20 11:09:24
the VBR is not a panacea
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-20 22:33:44
But consider  vbr and cbr options in the future to force a low bitrate.

It is excellent for music, but I like also speech options and not always 64 kbps.

Still I'd like an encoder that rarely goes more than 63 kbps.

the VBR is not a panacea
When I was a teen I wanted to go out with Claudia Schiffer. But... she seemed not to be interested in.  :-[

I’m also very excited like You about this new encoder, guys, but  it’s also a  good time to put myself on someone's shoes and see that there  is an open test (https://hydrogenaud.io/index.php?topic=119227.msg983258;topicseen#new) which would help somewhat to a development. Then, maybe,  if there is a possibility  I would kindly ask for some feature .
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-21 00:20:09
Thanks, Igor! Yes, some more volunteers in the 32-vs-44.1-kHz test would be very nice.

It is excellent for music, but I like also speech options and not always 64 kbps.
...
Still I'd like an encoder that rarely goes more than 63 kbps.
May I ask for what application? Audio books? For that purpose CVBR mode 1 might actually do the job. Near-mono audio should end up quite a bit below the target rate (64 kbit/s for mode 1), as guruboolez has shown.

m14u, since you've done nice analysis tables in the past: would it be possible for you to generate a new table for CVBR modes 1 and 2, with 22.05-32 kHz input sampling rate, for the latest Git version (https://gitlab.com/ecodis/exhale/-/commit/90b8af55)? For those posting executables here: no need to post another round, please wait for the final release at the end of the month.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-21 04:38:04
May I ask for what application? Audio books? For that purpose CVBR mode 1 might actually do the job. Near-mono audio should end up quite a bit below the target rate (64 kbit/s for mode 1)

Good morning Mr. Christian R. Helmrich,
first of all I want to thank you for the work you have done and which I appreciate very much.

In my opinion, in the next few years we will still see an increase in the bandwidth used on the cellular network and more of the video on small screens will increase the consumption of very long audio recordings. In my country it is still not uncommon to find radio stations that for example still release podcasts in mp3 format and above all for those who make information or who keep the sessions of parliaments the conservation of audio recordings will become a problem to solve. So let's take an example with local information, take the latest news from my area and observe the result (I'm sure that in some conditions the use of AAC-ELD is still advantageous).

Our source will be the file:
https://pod.radiopopolare.it/metroregione_20_05_2020_19_48.mp3
listed on the page:
https://www.radiopopolare.it/trasmissione/metroregione/

I will convert the file in multiple steps using macOS from the terminal with the command
afconvert /Users/ufficio/Downloads/metroregione_20_05_2020_19_48.mp3 -d LEF32 -c 1 -f caff --soundcheck-generate --anchor-generate --src-complexity bats -r 127 /Users/ufficio/Downloads/metroregione_20_05_2020_19_48.caf
and then
afconvert /Users/ufficio/Downloads/metroregione_20_05_2020_19_48.caf -d LEF32@[fs] -f WAVE --soundcheck-read /Users/ufficio/Downloads/metroregione_20_05_2020_19_48-[fs].wav

Then I compile your software, commit 90b8af55, for modern Mac, downloadable from here (https://www.celona.it/exhale-commit90b8af55.zip).

So I created three very compressed versions to have examples of quality that is no longer acceptable today.

1 ch,  8.000 Hz, aac, 17.662 bps (https://www.celona.it/metroregione_20_05_2020_19_48-8kHz.aac) - 1.728.129 byte
1 ch,  8.000 Hz, Qclp, 14.000 bps (https://www.celona.it/metroregione_20_05_2020_19_48-8kHz.aifc) - 1.347.222 byte
1 ch,  8.000 Hz, samr, 12.796 bps (https://www.celona.it/metroregione_20_05_2020_19_48-8kHz.amr) - 1.228.006 byte

Later I created the tracks with exhale #1 and the quality obtained is superior to my expectations.

1 ch,  8.000 Hz, usac, 18.123 bps (https://www.celona.it/metroregione_20_05_2020_19_48-8kHz-#1.m4a) - 1.767.687 byte
1 ch,  12.000 Hz, usac, 25.062 bps (https://www.celona.it/metroregione_20_05_2020_19_48-12kHz-#1.m4a) - 2.445.115 byte
1 ch,  16.000 Hz, usac, 32.162 bps (https://www.celona.it/metroregione_20_05_2020_19_48-16kHz-#1.m4a) - 3.138.174 byte
1 ch,  24.000 Hz, usac, 34.163 bps (https://www.celona.it/metroregione_20_05_2020_19_48-24kHz-#1.m4a) - 3.353.821 byte
1 ch,  32.000 Hz, usac, 34.958 bps (https://www.celona.it/metroregione_20_05_2020_19_48-32kHz-#1.m4a) - 3.453.941 byte

Finally the same tracks created with exhale #2.

1 ch,  8.000 Hz, usac, 21.957 bps (https://www.celona.it/metroregione_20_05_2020_19_48-8kHz-#2.m4a) - 2.135.627 byte
1 ch,  12.000 Hz, usac, 31.130 bps (https://www.celona.it/metroregione_20_05_2020_19_48-12kHz-#2.m4a) - 3.027.507 byte
1 ch,  16.000 Hz, usac, 40.562 bps (https://www.celona.it/metroregione_20_05_2020_19_48-16kHz-#2.m4a) - 3.944.230 byte
1 ch,  24.000 Hz, usac, 39.281 bps (https://www.celona.it/metroregione_20_05_2020_19_48-24kHz-#2.m4a) - 3.844.930 byte
1 ch,  32.000 Hz, usac, 40.802 bps (https://www.celona.it/metroregione_20_05_2020_19_48-32kHz-#2.m4a) - 4.014.612 byte
1 ch,  44.100 Hz, usac, 41.397 bps (https://www.celona.it/metroregione_20_05_2020_19_48-44kHz-#2.m4a) - 4.107.824 byte
1 ch,  48.000 Hz, usac, 41.511 bps (https://www.celona.it/metroregione_20_05_2020_19_48-48kHz-#2.m4a) - 4.130.556 byte

In conclusion, although exhale offers a much better quality, but in terms of bitrate it is still superior to first 8kHz AAC, so there is room for further improvements. Today all mobile phones with Android or iOS, and all Macintosh, have the USAC decoder already installed. For Windows 10, the manufacturer needs to adapt and I will urge the European Union to intervene so that the USAC decoder become quickly mandatory in supplies for the Public Administration. For Linux, users of this OS are generally more autonomous and this is an important difference compared to the past because if today I publish a content that is not immediately decoded, many users will simply do nothing to get around the obstacle and I will have to take this into consideration before making any choices.

I provide to you my files; with exhaxe #1 the bitrate does not change substantially from 16 to 24 kHz while with exhale #2 it does not change from 16 to 48kHz and even at 24kHz we obtain bitrates lower than 16kHz. I remember that Opus also doesn't like 16kHz sampled files, but this shows the need to reconsider some choices made for the encoder.

Thanks again and I will come back to write more as soon as I have time.

Christian
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-05-21 08:15:42
a serious question. How stereo works in Usac or in exhale? Is there joint stereo at certain bitrate, or stereo like opus that uses very few kbps like 2 kbps, or normal stereo so 32+32 kbps vbr, 32 kbps if the track is mono or 64 kbps stereo. I haven't test much the program so I don't know very well what are the bitrates for mono.
Celona, how to install usac in afconvert. How much it costs?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-21 10:17:22
How stereo works in Usac or in exhale?

For now exhale doubles the bitrate when input has a stereo file, in a similar way to uncompressed files.

I have used afconvert only to create the needed wav files to be compressed later by exhale and I did a test to see how the bitrate changes, not to evaluate the sound quality, in fact the original file (https://pod.radiopopolare.it/metroregione_20_05_2020_19_48.mp3) is an already compressed mp3.

With the first step afconvert creates an uncompressed intermediate file containing a 32 bit little endian floating point linear PCM audio, so as not to have clipping and to obtain the best performance with the encoders. This time we will get a stereo file.

afconvert /Users/ufficio/Downloads/metroregione_20_05_2020_19_48.mp3 -d LEF32 -c 2 -f caff --soundcheck-generate --anchor-generate --src-complexity bats -r 127 /Users/ufficio/Downloads/metroregione_20_05_2020_19_48.caf

With the second step, the input file ends up in the WAVE container with some additional information.

afconvert /Users/ufficio/Downloads/metroregione_20_05_2020_19_48.caf -d LEF32 -f WAVE --soundcheck-read /Users/ufficio/Downloads/metroregione_20_05_2020_19_48-44kHz-stereo.wav

The result compared to the previous test is:
1 ch, 44100 Hz, lpcm, 1.411.200 bps - 135.389.628 byte
2 ch, 44100 Hz, lpcm, 2.822.400 bps - 270.775.160 byte

where the second file (stereo) divided by the first file (mono) = 2 exactly.

Now in the end we get the two files compressed with exhale #2.

1 ch, 44.100 Hz, usac, 41.397 bps (https://www.celona.it/metroregione_20_05_2020_19_48-44kHz-#2.m4a) - 4.107.824 byte
2 ch, 44.100 Hz, usac, 73.563 bps (https://www.celona.it/metroregione_20_05_2020_19_48-44kHz-#2-stereo.m4a) - 7.194.052 byte

where the second file (stereo) divided by the first file (mono) = 1,75 approx.

Celona, how to install usac in afconvert. How much it costs?

At the moment afconvert can only decode the USAC audio and there is no ability of obtaining the encoder from Apple even for a fee.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-05-21 11:13:58
90b8af55
p.s.
small fix by mediainfo v18.12 (instead v17.12)  O:)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-21 11:24:24
Thanks very much, m14u! For sampling rates between 22.05 and 44.1 kHz, the resulting bit-rates seem to be quite balanced now, so I think I can stop adjusting here. For lower sampling rates, see the following answer.

Hello Christian (celona), thanks very much for telling me about your interesting use case and for testing low input sampling rates.
...those who make information or who keep the sessions of parliaments the conservation of audio recordings...1 ch,  8.000 Hz, aac, 17.662 bps (https://www.celona.it/metroregione_20_05_2020_19_48-8kHz.aac) - 1.728.129 byte
Later I created the tracks with exhale #1 and the quality obtained is superior to my expectations.
1 ch,  8.000 Hz, usac, 18.123 bps (https://www.celona.it/metroregione_20_05_2020_19_48-8kHz-#1.m4a) - 1.767.687 byte
...
In conclusion, although exhale offers a much better quality, but in terms of bitrate it is still superior to first 8kHz AAC, so there is room for further improvements.
...
I provide to you my files; with exhaxe #1 the bitrate does not change substantially from 16 to 24 kHz while with exhale #2 it does not change from 16 to 48kHz and even at 24kHz we obtain bitrates lower than 16kHz.
The behavior you described in the last sentence was actually intentional, I tried to make the resulting bit-rate somewhat more independent of the input sampling rate when going below 22.05 kHz. But given your very interesting use case where, if I understand correctly, low data rate is more important than highest quality (especially since the source audio is usually pre-compressed), I removed the respective code in a new Git commit (https://gitlab.com/ecodis/exhale/-/commit/a8511608). If you try again at sampling rates smaller than 22.05 kHz, you should now get slightly lower bit-rates. But please understand this: the USAC/xHE-AAC standard provides a dedicated speech coding method (ACELP) which exhale does not implement, see also this previous post of mine (https://hydrogenaud.io/index.php?topic=118888.msg980837#msg980837). An xHE-AAC encoder supporting coding in this mode will sound much better than exhale and will also be able to run at 32 kHz or more even at the lowest bit-rates. AFAIK there are commercial encoders available which support this configuration.

a serious question. How stereo works in Usac or in exhale? Is there joint stereo at certain bitrate, or stereo like opus that uses very few kbps like 2 kbps, or normal stereo so 32+32 kbps vbr, 32 kbps if the track is mono or 64 kbps stereo.
How about this: you answer the question I asked you earlier (may I ask for what application would you like to use exhale at bit-rates below 64 kbit/s stereo? Audio books?) and I'll answer yours :)

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-05-21 16:51:34
v.1.0.3-41751381 built on 18-05-2020
I meant the quality is good at 80 kbps but for example at 79 kbps or mode 1, it isn't very good, it sounds muffled because isn't very optimized, for example I tested a track of muse, dig down, the one with kitara instrument and the bass part is too compressed, 52 kbps that is very low. So not audiobooks, maybe compilation music. Now I understand why less than 64 kbps stereo isn't optimal.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-21 17:12:14
v.1.0.3-41751381 built on 18-05-2020
I meant the quality is good at 80 kbps but for example at 79 kbps or mode 1, it isn't very good, it sounds muffled because isn't very optimized

mode 1 is near 60…64 kbps on average. It's also resampled at 24000 Hz that's why output sounds muffled. If I understand correctly, there are some advanced coding tools (like SBR) that are not (yet?) implemented in exhale. For these reasons (resampling + missing tools) exhale can't really compete now at ~64 kbps against Opus or HE-AAC (which both offers the immediate satisfaction of high frequencies).
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-05-21 17:13:56
no, now it works at 32000 hz which can be a bit better. Ok thanks for your answer. I know opus recreates frequencies from sub bands and stereo from the frequencies but I'm not deeply interested to compare the two codecs. People like opus even at 48 kbps.
Maybe what you mean is that encoding with an encoder, the file is resampled another time. from 32000 hz wav to 32000 hz exhale.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-21 18:00:42
Thanks for the clarification. I think I understand what you mean now, though I'm still not sure where you got the number "79" from. CVBR mode 1 should average at 64 kbit/s. But indeed, mode 1 can now be used with 32 kHz sampling rate (since, from the first results of the 32-vs-44.1 kHz test with mode 2, I guess some users may prefer 32 over 24 kHz with mode 1). But guruboolez is right, exhale doesn't have SBR, and I'm not sure if/when I'll be able to implement that (it's a lot of extra work).

Regarding stereo:
a serious question. How stereo works in Usac or in exhale? Is there joint stereo at certain bitrate, or stereo like opus that uses very few kbps like 2 kbps, or normal stereo so 32+32 kbps vbr, 32 kbps if the track is mono or 64 kbps stereo.
None of the above ;) Well, there is a bit of stereo image narrowing at CVBR modes 4 and lower (to save bits which are better spent elsewhere), but overall, the joint stereo coding method is highly input adaptive - it uses just as many bits as necessary to increase the overall quality, at any bit-rate. celona gave some numbers above (https://hydrogenaud.io/index.php?topic=118888.msg983349#msg983349). So, no fixed bit-rate assigment to the left and right channel or something like that.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-05-21 18:31:47
Indeed, I forgot that in latest builds 32KHz is now possible for mode 1. It should be less muffled than 24 KHz.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-21 19:06:54
a serious question. How stereo works in Usac or in exhale? Is there joint stereo at certain bitrate, or stereo like opus that uses very few kbps like 2 kbps, or normal stereo so 32+32 kbps vbr, 32 kbps if the track is mono or 64 kbps stereo. I haven't test much the program so I don't know very well what are the bitrates for mono.
Celona, how to install usac in afconvert. How much it costs?

I'm not sure where You got this "2 kbps" stereo. Even HE-AACv2's parametric stereo is 3 kbps but low frequency range of both channels is still coded at much higher bitrate. There is no such thing as "stereo @2 kbps" for any codec. 
 All encoders LC-AAC, exhale and Opus have similar implementations of  joint stereo and intensity stereo.   Also You mention 64 kpbs range,  it's worth to mention that ...  Opus is still the best publicly available encoder at @64 kbps and it has no any critic flaw or whatsoever on stereo image. Even at 32 kbps  Opus still codes stereo with higher quality than any other publicly available codec.
You had already clear explanation how lossy encoder works.  https://hydrogenaud.io/index.php?topic=117721.msg972091#msg972091
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-21 19:19:02
Sorry, today I am very busy with my job. C.R. Helmrich asked me for further tests, which I will not be able to comment on today.

Previous tests were made with other encoders from file:
https://pod.radiopopolare.it/metroregione_20_05_2020_19_48.mp3 (https://pod.radiopopolare.it/metroregione_20_05_2020_19_48.mp3)

1 ch, 8.000 Hz, samr, 12.796 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-8kHz.amr) - 1.228.006 byte
1 ch, 8.000 Hz, Qclp, 14.000 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-8kHz.aifc) - 1.347.222 byte
1 ch, 8.000 Hz, aac, 17.662 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-8kHz.aac) - 1.728.129 byte

Previous tests were made on macOS with exhale@90b8af55 (https://www.celona.it/exhale@90b8af55/exhale@90b8af55.zip) #1 and #2 from the same file

1 ch, 8.000 Hz, usac, 18.123 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-8kHz-1.m4a) - 1.767.687 byte
1 ch, 11.025 Hz, usac, 23.228 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-11kHz-1.m4a) - 2.266.293 byte
1 ch, 12.000 Hz, usac, 25.062 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-12kHz-1.m4a) - 2.445.115 byte
1 ch, 16.000 Hz, usac, 32.162 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-16kHz-1.m4a) - 3.138.174 byte
1 ch, 22.050 Hz, usac, 34.301 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-22kHz-1.m4a) - 3.361.215 byte
1 ch, 24.000 Hz, usac, 34.163 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-24kHz-1.m4a) - 3.353.821 byte
1 ch, 32.000 Hz, usac, 34.958 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-32kHz-1.m4a) - 3.453.941 byte

1 ch, 44.100 Hz, usac, 41.397 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-44kHz-2.m4a) - 4.107.824 byte
1 ch, 48.000 Hz, usac, 41.511 bps (https://www.celona.it/exhale@90b8af55/metroregione_20_05_2020_19_48-48kHz-2.m4a) - 4.130.556 byte

Newer tests were made on macOS with exhale@a8511608 (https://www.celona.it/exhale@a8511608/exhale@a8511608.zip) #1 and #2 from the same file

1 ch, 8.000 Hz, usac, 15.899 bps (https://www.celona.it/exhale@a8511608/metroregione_20_05_2020_19_48-8kHz-1.m4a) - 1.554.165 byte
1 ch, 11.025 Hz, usac, 20.356 bps (https://www.celona.it/exhale@a8511608/metroregione_20_05_2020_19_48-11kHz-1.m4a) - 1.990.647 byte
1 ch, 12.000 Hz, usac, 21.963 bps (https://www.celona.it/exhale@a8511608/metroregione_20_05_2020_19_48-12kHz-1.m4a) - 2.147.755 byte
1 ch, 16.000 Hz, usac, 28.141 bps (https://www.celona.it/exhale@a8511608/metroregione_20_05_2020_19_48-16kHz-1.m4a) - 2.752.371 byte
1 ch, 22.050 Hz, usac, 34.301 bps (https://www.celona.it/exhale@a8511608/metroregione_20_05_2020_19_48-22kHz-1.m4a) - 3.361.215 byte
1 ch, 24.000 Hz, usac, 34.163 bps (https://www.celona.it/exhale@a8511608/metroregione_20_05_2020_19_48-24kHz-1.m4a) - 3.353.821 byte
1 ch, 32.000 Hz, usac, 34.958 bps (https://www.celona.it/exhale@a8511608/metroregione_20_05_2020_19_48-32kHz-1.m4a) - 3.453.941 byte

1 ch, 44.100 Hz, usac, 41.397 bps (https://www.celona.it/exhale@a8511608/metroregione_20_05_2020_19_48-44kHz-2.m4a) - 4.107.824 byte
1 ch, 48.000 Hz, usac, 41.511 bps (https://www.celona.it/exhale@a8511608/metroregione_20_05_2020_19_48-48kHz-2.m4a) - 4.130.556 byte
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-05-21 20:21:47
I prefer m4a to vorbis, even if opus developer said that opus uses a better technology than sbr.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-05-24 16:39:10
Now to have exhale benefits (even if there aren't very high frequencies) I suggest preset 6 144 kbps.
yes opus focus much on high frequencies.
If you try with foobar a new build like these new one https://jeremylee.sh/bin.html  even at 26 kbps it tries to preserve high frequencies.
It is difficult to hear differences between two codecs.
Sorry to all, I'm too off topic, i can't delete the post.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-24 21:54:56
I have created two sets of files, one mono and one stereo, for testing Exhale and other encoders in the case of the human voice only.

Each file contains at different sampling frequencies, obtained from the same SRC, in 4 part, a male voice with background music and a female voice from files 11 and 12 of your set, a very short sound, and the voice of a soprano from the EBU tests.

The name of each file begins with spoken followed by m for mono audio or s for stereo audio and ends with the sampling frequency in kHz.

The length of each piece is deliberately one minute.

I have already converted the files in many ways which will give you in subsequent posts to get around the forum limit of 16.

8 kHz mono|8 kHz stereo
12 kHz mono|12 kHz stereo
16 kHz mono|16 kHz stereo
24 kHz mono|24 kHz stereo
32 kHz mono|32 kHz stereo
48 kHz mono|48 kHz stereo
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-24 23:19:15
I will start with some particular formats. Since I want to test the effectiveness and quality of the encoders I do not limit the bitrate in any case.

The AMR format can also be used as audio for movies, even on YouTube, even if the NB quality today is hardly acceptable. It can also be reproduced from the first 3G phones, also with extensions .3gp, .3ga, or .3g2. It cannot be used with the HTML audio tag, despite the support of all operating systems.

AMR-NB - 8 kHz mono - 96.038 byte

AMR-WB - 16 kHz mono - 183.009 byte

Speex today, probably has no reason to exist, it cannot be used with the HTML audio tag, and nobody can use it with the commonly supplied codecs.

Speex - 8 kHz mono - 118.811 byte

Speex - 16 kHz mono - 214.811 byte

The following files compressed with Opus are in a CAF container and are provided for those who use Apple operating systems that are able of coding and decoding natively in Opus, limited to CELP, they do not use SILK for speech. The quality is valid, but decreasing the bitrate the voices become shaky. Apple's macOS does not allow creating Opus files sampled at 32 kHz, but as we will see later it is a condition that often does not make sense even with Exhale.

The detection between speech and music is automatic, but when SILK is missing it is always music. Using the CAF container with products other than Apple is possible but not within everyone's reach.

Opus - 8 kHz mono - 125.111 byte

Opus - 12 kHz mono - 152.936 byte

Opus - 16 kHz mono - 180.917 byte

Opus - 24 kHz mono - 241.385 byte

Opus - 48 kHz mono - 423.360 byte

To finish we have Opus in an ISO container, but it can only be used by FFMPEG based products. In this case the file size is reduced because FFMPEG allows you to set the optimization for VOIP.

Opus - 48 kHz mono - 363.901 byte
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-25 00:34:07
Now with Opus, this time divided by --music and --speech optimization.

Opus --music - 8 kHz mono - 281.277 byte

Opus --music - 12 kHz mono - 308.396 byte

Opus --music - 16 kHz mono - 380.725 byte

Opus --music - 24 kHz mono - 365.539 byte

Opus --music - 32 kHz mono - 412.990 byte

Opus --music - 48 kHz mono - 529.854 byte

Opus --speech - 8 kHz mono - 194.194 byte

Opus --speech - 12 kHz mono - 221.215 byte

Opus --speech - 16 kHz mono - 251.974 byte

Opus --speech - 24 kHz mono - 308.009 byte

Opus --speech - 32 kHz mono - 361.494 byte

Opus --speech - 48 kHz mono - 529.854 byte
SimplePortal 1.0.0 RC1 © 2008-2020