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: 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: 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:

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: 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:

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.

Edit: removed "www.rarewares.org/files/aac/" from link description
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-25 01:32:35
Now the different AAC encoders without SBR.

AAC - 8 kHz mono - 130.222 byte

AAC - 12 kHz mono - 165.189 byte

AAC - 16 kHz mono - 194.513 byte

AAC - 24 kHz mono - 260.545 byte

AAC - 32 kHz mono - 390.844 byte

AAC - 48 kHz mono - 516.253 byte

AAC-LD - 16 kHz mono - 195.989 byte

AAC-LD - 24 kHz mono - 261.083 byte

AAC-LD - 32 kHz mono - 386.941 byte

AAC-LD - 48 kHz mono - 530.478 byte

AAC-ELD - 16 kHz mono - 196.455 byte

AAC-ELD - 24 kHz mono - 259.128 byte

AAC-ELD - 32 kHz mono - 385.691 byte

AAC-ELD - 48 kHz mono - 525.075 byte
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-25 02:19:35
Now the different AAC encoders with SBR and LD-SBR.

All MPEG encoders when used at insufficient bitrates produce annoying and unheard voices. I should have already written it in the previous block that from this point of view we must consider AAC-ELD encoders as a new and different generation of encoders that has clear advantages in human voices. Another advantage comes from the fact that AAC-ELD offers excellent compatibility and can be reproduced by obsolete operating systems, such as Android 4.2 or Mac OS X 10.7 Lion. In addition, this encoder can be used in videos that use the ISO container, even if YouTube does not yet support it to avoid having to pay royalties. Even with browsers like Firefox, it is possible to use the HTML audio tag, because the support is given by the operating system; AAC-ELD allows you to keep the audio in one format, for any use and this is a considerable advantage.

AAC-HE SBR - 16 kHz mono - 195.604 byte

AAC-HE SBR - 24 kHz mono - 196.417 byte

AAC-HE SBR - 32 kHz mono - 226.244 byte

AAC-HE SBR - 48 kHz mono - 257.456 byte

In the above case it is clear that it makes no sense to use AAC-HE with sampling frequencies below 24 kHz.

AAC-ELD LD-SBR - 16 kHz mono - 188.817 byte

AAC-ELD LD-SBR - 24 kHz mono - 258.762 byte

AAC-ELD LD-SBR - 32 kHz mono - 327.187 byte

AAC-ELD LD-SBR - 48 kHz mono - 408.953 byte

I wanted to insert the voice of a soprano in the test not only to cover the entire extension of the human voice, but also because it is the one that lends itself best to show the disasters that LD-SBR can do with music, especially with samples from 48 at 32 kHz. AAC-LD with LD-SBR is an excellent choice for conferences, long debates by voice, both in video and in audio only, but it is not a format suitable for music. At lower sampling rates the problem is not evident.
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-25 02:46:46
Now, to finish, the AAC-xHE or USAC created with the Exhale encoder.

The encoder allows you to use all the test sampling frequencies (even 44.1kHz that I have excluded) and for the frequencies lower than 32kHz the Exhale 1 encoder setting has been chosen.

AAC-xHE USAC - 8 kHz mono - 121.890 byte

AAC-xHE USAC - 12 kHz mono - 167.985 byte

AAC-xHE USAC - 16 kHz mono - 224.140 byte

AAC-xHE USAC - 24 kHz mono - 230.070 byte

For frequencies equal to or greater than 32kHz, not being able to do otherwise, the setting of the Exhale 2 encoder was chosen. In this case it can be noted that it makes no sense to use USAC with a sampling frequency of 16kHz because the size obtained is almost identical to 24kHz sampling.

AAC-xHE USAC - 32 kHz mono - 306.581 byte

AAC-xHE USAC - 48 kHz mono - 304.017 byte

Also in this case it can be noted that it makes no sense to use USAC with a sampling frequency lower than 48kHz because the size obtained at 32kHz sampling is even greater. Compared to AAC-ELD with LD-SBR, sampling frequencies greater than or equal to 32kHz do not decline in quality. Before the conclusions it will be necessary to verify the encoders also with stereophonic signals.
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-05-25 07:58:43
opus not only at 26, even at 43 kbps has good quality
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-26 02:51:23
Probably nobody cares about it. For a limited period of time it will be possible to ask for the files.

Stereo8 kHz12 kHz16 kHz24 kHz32 kHz48 kHzEncoder
AAC-LC258 kB325 kB392 kB502 kB749 kB1024 kBafconvert
AAC-LD318 kB339 kB362 kB504 kB726 kB1024 kBafconvert
AAC-ELD319 kB336 kB360 kB503 kB726 kB1024 kBafconvert
AAC-ELD LD-SBR326 kB346 kB355 kB474 kB629 kB765 kBafconvert
AAC-ELD LD-SBR PS240 kB248 kB254 kB267 kB383 kB369 kBafconvert
AAC-HE SBR384 kB386 kB386 kB392 kB446 kB509 kBafconvert
AAC-HE SBR PS303 kB314 kB327 kB324 kB326 kB395 kBafconvert
AAC-xHE USAC269 kB383 kB528 kB656 kB740 kB706 kBexhale # (commit a8511608)
Ogg Vorbis196 kB280 kB307 kB401 kB685 kB737 kBoggenc
Opus --music447 kB490 kB604 kB552 kB600 kB750 kBopusenc
Opus --speech285 kB327 kB466 kB551 kB600 kB750 kBopusenc
Wave (original)1.9 MB2.9 MB3.8 MB5.8 MB7.7 MB11.5 MBffmpeg

Ogg Vorbis - 8 kHz stereo - 196.496 byte

AAC-HE SBR PS - 32 kHz - 326.220 byte

AAC-ELD LD-SBR PS - 8 kHz - 240.307 byte

AAC-ELD LD-SBR PS - 12 kHz - 247.733 byte

AAC-ELD LD-SBR PS - 16 kHz - 254.144 byte

AAC-ELD LD-SBR PS - 24 kHz - 266.693 byte

AAC-ELD LD-SBR PS - 32 kHz - 383.063 byte

AAC-ELD LD-SBR PS - 48 kHz - 369.473 byte
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-05-26 09:32:08
ok, how to decode AAC-ELD in foobar, it is possible with xheaac plugin?
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-26 11:16:18
ok, how to decode AAC-ELD in foobar, it is possible with xheaac plugin?

You need to add this decoder:
http://www.foobar2000.org/components/view/foo_pd_aac

I provide to you some other files to compare them:

Speex - 8 kHz stereo - 124.019 byte

Opus - 8 kHz stereo - 284.700 byte

Opus - 12 kHz stereo - 327.184 byte

Opus - 16 kHz stereo - 466.342 byte

Opus - 24 kHz stereo - 550.770 byte

Opus - 32 kHz stereo - 599.715 byte

Opus - 48 kHz stereo - 750.131 byte

You will hear that Opus --speech has unacceptable distortion on the voice due to its smaller size. Sampling frequencies equal to or greater than 24 kHz produce practically identical results between the - music and --speech optimizations.
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-05-26 13:03:14
no, I'm not interested in unknown formats. Thanks the same.
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-26 13:48:58
@celona
Can I ask you? What this all bitrate tables vs sampling rates about?
It's trivial to indicate the bitrate/file size to some particular sampling rate of one particular codec by changing settings.  What is not trivial is too see which quality it produces for a given codec (and your table doesn't show that).

Higher sampling rate doesn't mean higher quality in context of lossy formats.

Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-26 14:02:07
no, I'm not interested in unknown formats. Thanks the same.

Right observation, I provided the source files in a previous message, you can get the result and compare it with yours from the terminal with the command:
opusenc --speech source target
or:
opusenc --music source target

Doing so will not remain unknown even the unacceptable distortion that the Opus encoder inserts where our hearing is most sensitive.

I propose them here again:
8 kHz - https://hydrogenaud.io/index.php?action=dlattach;attach=17022
12 kHz - https://hydrogenaud.io/index.php?action=dlattach;attach=17023
16 kHz - https://hydrogenaud.io/index.php?action=dlattach;attach=17024
24 kHz - https://hydrogenaud.io/index.php?action=dlattach;attach=17025
32 kHz - https://hydrogenaud.io/index.php?action=dlattach;attach=17026
48 kHz - https://hydrogenaud.io/index.php?action=dlattach;attach=17027
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-26 19:36:19
@celona
Can I ask you? What this all bitrate tables vs sampling rates about?

I will reply by showing the meaning of the experiment with the numbers. For now sorry.
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-26 19:45:48
Exhale @a8511608

# 8 12 16 24 32 48 kHz

1
2
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-26 19:51:01
Exhale @a8511608

# 8 12 16 24 32 48 kHz

3
4
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-26 19:58:23
Exhale @a8511608

# 8 12 16 24 32 48 kHz

5
6
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-26 20:04:53
Exhale @a8511608

# 8 12 16 24 32 48 kHz

7
8
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-26 20:08:08
Exhale @a8511608

# 8 12 16 24 32 48 kHz

9
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: The Irish Man on 2020-05-26 20:37:38
Sorry, how long is this to continue?

Please, get to the point.
Title: Re: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-26 20:43:29
Exhale @a8511608

I'm done, in the previous messages I have linked the file to feel the differences that I will write in the future.

Stereo8 kHz12 kHz16 kHz24 kHz32 kHz48 kHzEncoder
AAC-xHE USAC187 kB260 kB351 kB428 kB476 kBNoneexhale 1
AAC-xHE USAC208 kB291 kB396 kB484 kB584 kB572 kB exhale 2
AAC-xHE USAC269 kB383 kB528 kB656 kB740 kB706 kB exhale 3
AAC-xHE USAC303 kB435 kB597 kB740 kB795 kB789 kB exhale 4
AAC-xHE USAC415 kB600 kB816 kB994 kB958 kB951 kBexhale 5
AAC-xHE USAC521 kB762 kB1 MB1.2 MB1 MB1 MBexhale 6
AAC-xHE USAC1.1 MB1.6 MB2.1 MB1.6 MB1.1 MB1.1 MBexhale 7
AAC-xHE USAC29 kB43 kB55 kB78 kB1.2 MB1.3 MBexhale 8
AAC-xHE USAC29 kB43 kB55 kB77 kB1.2 MB1.4 MBexhale 9
Opus --music447 kB490 kB604 kB552 kB600 kB750 kBopusenc
Opus --speech285 kB327 kB466 kB551 kB600 kB750 kBopusenc
Wave (original)1.9 MB2.9 MB3.8 MB5.8 MB7.7 MB11.5 MBffmpeg

When the file size changes significantly something went wrong and the quality collapsed. Typically when the bitrate drops, as in the case of Opus --speech, the artifacts become evident.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-26 22:10:43
Thanks, celona. I skimmed through your posts and collected some mono files for comparison which are similar in file size and not obviously broken/buggy in sound quality:

The first five files I got from one of your earlier posts, the last one was created with a 1.0.4 beta version of exhale from the 32-kHz mono original you posted here (https://hydrogenaud.io/index.php?topic=119272) and is attached to this post (exhale can encode 32 kHz at mode 1 now, and the resulting bit-rate is closer to the 32 kbps target for this example than with 24 kHz sampling rate).

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-27 04:40:14
Blather and related discussion has been split to the Recycle Bin.

You are very polite, I will remember before writing again.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-05-27 21:54:16
Sorry, I was told to do it. I should have just left it.

@celona You can reply, I should just leave well enough alone.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-27 23:26:30
Last commits have significant imrpovements, especially on transient files (at least for my ears.) https://gitlab.com/ecodis/exhale/-/commits/master

It would be great if someone else will perform some blind tests on attached samples (EIG and castanets) and  confirm this.
Thanks.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-05-28 11:06:16
It would be great if someone else will perform some blind tests on attached samples (EIG and castanets) and  confirm this.
Thanks.
After a short test I have the same impression. Tonight I will listen again.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-28 20:57:59
@celona
Great. You can use ABCHR application for blind tests. It is included in package here https://hydrogenaud.io/index.php?topic=119227.msg983586;topicseen
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-05-29 00:56:02
celona's previous tests were of remote usefulness, in tracking general data complexity, but not necessarily for how audible the compression is or is not. Sudden size changes across commits could be a sign of a regression, or simply a new optimization that improves compression without affecting audio quality.

Yes, it is best to perform ABCHR or similar double blind tests to verify whether such changes are actually audible, or if it's just a side benefit of improvements.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-29 01:00:37
celona's previous tests were of remote usefulness, in tracking general data complexity... Sudden size changes across commits could be a sign of a regression...
Indeed, he pointed me to an issue with combinations of high bit-rate and low sampling rate. Thanks, Christian! I just forbid that in exhale. Please check the latest Git version (https://gitlab.com/ecodis/exhale/-/commit/a7a5204a) for compilation issues and crashes, I'll update the documentation and will tag this as release 1.0.4 on the weekend.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-29 14:38:02
It's time to compile binaries of latest git  and run 1.0.4 beta on a large number of files to check for possible crashes or any other issues.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-05-29 15:25:07
As requested:

www.rarewares.org/files/aac/exhaleApp-v.1.0.4b-a7a5204a_x64.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.4b-a7a5204a_x64.zip)

www.rarewares.org/files/aac/exhaleApp-v.1.0.4b-a7a5204a_x86.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.4b-a7a5204a_x86.zip)

Intel 19 compiles.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-05-29 16:19:44
exhale support unicode?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-30 18:30:34
Apparently it doesn't :( I checked myself. Will take a look at this later.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-30 18:30:59
exhale version 1.0.4 has been released today, see
https://gitlab.com/ecodis/exhale/-/releases/v1.0.4

exhale 1.0.4 - Change Log
- finalized basic joint-stereo and TNS coding functionality, quality and stability fixes
- exhaleApp: support for 32000 Hz with CVBR mode 1, added '-v' version command
- exhaleLib: completed audio quality fine-tuning for very tonal and transient signals
- compilation: support for MinGW (issue #5) & cmake (via CMakeLists files, issue #6)

This release completes my general audio quality tuning for all CVBR modes. I'm not planning further major changes in bit allocation, only sample-specific adjustments if severe audio quality issues are reported (that is, for samples other than Fatboy, Girl, and Linchpin). The next release will focus on reducing the mean bit-rate resulting from 32-kHz audio coding with mode 1 (which is slightly higher than the targeted 64 kbit/s stereo at the moment) by 1 or 2 kbit/s without affecting the audio quality. I'll also try to add automatic downsampling to 32 kHz for that mode, which I wasn't able to finish in time for this release, and take a look at the Unicode issue reported by m14u yesterday.

By the way, I call this release the "E" release since this is the fifth public release of exhale. E is also the initial of a former colleague of mine at Fraunhofer, a kind and gentle person and brilliant mind who passed away two weeks ago, much too young. I dedicate this exhale version to him.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-05-30 19:03:01
amm... unicode issue is not a exhale's issue , but "john's exhaleapp.exe win64 in wine64".
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-05-30 19:04:29
del
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-05-30 20:05:07
exhale v1.0.4-63b919d2
Built on May 30, 2020, GCC 10.1.0
-------

Binaries removed. New compile will come after Chris fix the current issue.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-05-30 20:13:29
netranger's too
"ERROR while trying to open input file Z:\╟руЁєчъш\exhale v1.0.4-63b919d2\Win64\/╠єч√ър/wav/Loreena McKennitt - An Ancient Muse.wav! Does it already exist?"
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-30 20:19:09
It's an issue of the exhaleApp source code, m14u.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-05-30 20:23:11
It's an issue of the exhaleApp source code, m14u.

Chris

Will make a new compile when the issue have been fixed. ;)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-05-30 20:38:46
As I wrote above, I'll try to fix that for the next release. Please don't wait for that, it might take some time. Alternatively somebody else could fix it.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-30 21:37:14
By the way, I call this release the "E" release since this is the fifth public release of exhale. E is also the initial of a former colleague of mine at Fraunhofer, a kind and gentle person and brilliant mind who passed away two weeks ago, much too young. I dedicate this exhale version to him.

Chris

Sorry for your loss, Chris.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-05-31 01:02:18
As requested:

www.rarewares.org/files/aac/exhaleApp-v.1.0.4b-a7a5204a_x64.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.4b-a7a5204a_x64.zip)

www.rarewares.org/files/aac/exhaleApp-v.1.0.4b-a7a5204a_x86.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.4b-a7a5204a_x86.zip)

Intel 19 compiles.
Thank You. That was fast.

Early I've managed to run 38 hours  of music on this beta build ,CVBR mode 3. No issues were found.

P.S.  It's time for  binaries of 1.0.4 final

This release completes my general audio quality tuning for all CVBR modes. I'm not planning further major changes in bit allocation, only sample-specific adjustments if severe audio quality issues are reported (that is, for samples other than Fatboy, Girl, and Linchpin).
All right.  As for the last test@80 kbps, exhale can be very usable ( previous 1.0.3.x) (https://i.ibb.co/L9p4ZzT/exhale-32k-Hz-vs-44k-Hz-80kbps-CVBR.png) even at this bitrate once Linchpin, Fatboy and equivalent samples would be tuned, hopefully, in some future. I wouldn't mind to use it at 80kbps for mobile use also when outside, driving, etc.
As for now, 1.0.4 looks solid. 
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-05-31 12:15:40
1.0.4 Release binaries:

www.rarewares.org/files/aac/exhaleApp-v.1.0.4-63b919d2_x64.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.4-63b919d2_x64.zip)

www.rarewares.org/files/aac/exhaleApp-v.1.0.4-63b919d2_x86.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.4-63b919d2_x86.zip)

Christian: Would you like these added to the 'aac' page at Rarewares? If so, perhaps you would be kind enough to provide a suitable description? TIA.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-05-31 13:19:58
Just had some time to test the v1.0.4 binaries i compiled and they work just fine in foobar2000 when converting. No issues at all.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-06-01 02:13:36
They would work fine with foobar2000 converter because it changes the current working directory to the output location and simply emits a relative path to the output file, which it uses an ASCII safe temporary name for.

I can try to implement Unicode support using the same piece of code as the Windows FLAC uses. That makes it quite simple, as it implements support for both command line arguments and fopen with UTF-8 strings, and converts them to UTF-16 for Windows' Unicode API.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-06-01 14:44:45
They would work fine with foobar2000 converter because it changes the current working directory to the output location and simply emits a relative path to the output file, which it uses an ASCII safe temporary name for.

Thnx for the reply/info kode54 :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: andrew.46 on 2020-06-07 10:39:37
Exhale 1.0.3 is settled into SBo (https://slackbuilds.org/repository/14.2/audio/exhale/)  (the Slackware repository for 3rd party scripts) and I am preparing to update to 1.0.4. Two questions have come up though:


And thanks again for a working xHE-AAC encoder  :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Rollin on 2020-06-09 19:58:51
Usually, i have no problems with using command-line encoders. But i cannot make exhale for windows work.
Code: [Select]
D:\Downloaded\exhaleApp-v.1.0.4-63b919d2_x86\exhaleApp.exe D:\Downloaded\exhaleApp-v.1.0.4-63b919d2_x86\1.wav D:\Downloaded\exhaleApp-v.1.0.4-63b919d2_x86\1.m4a
doesn't work

Code: [Select]
cd /d D:\Downloaded\exhaleApp-v.1.0.4-63b919d2_x86
exhaleApp.exe 1.wav 1.m4a
doesn't work also

Can someone give me full working example of command to use?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Anakunda on 2020-06-09 20:14:07
Can someone give me full working example of command to use?

You need to provide a preset:

exhaleApp.exe 5 1.wav 1.m4a
Also foobar2000 converter preset works fine with parameters <preset> %d

Having additional question if there's an Adroid player cabable playing this format, and how goes this compared to Opus.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-06-09 23:23:36
Having additional question if there's an Adroid player cabable playing this format...

https://www.audioblog.iis.fraunhofer.com/xheaac-mpeg-d-drc-android-pie
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-06-10 12:14:32
D:\Setup\Programmiportable\exhaleApp-v.1.0.4-63b919d2_x64\exhaleApp.exe  1 "C:\Users\User\Documents\1\no.wav" "C:\Users\User\Documents\1\no.m4a"
First to use mode 1, you need to resample the wav file (only format supported), you can do with foobar2000 in processing and you add the resampler.
To me it worked even if you use the same name in m4a file as the wav file.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Anakunda on 2020-06-10 20:44:17
Can someone confirm plentiful fails to encode 24 bit sources? I get encoded only few track of an album, while when downscaling the source to 16 bit, all tracks are converted.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-06-10 21:11:16
I tried with a 24/96 file and exhale immediately failed (mode 4 if that matters). Then I downsampled the file to 24/44.1 WAV, and then exhale encoded this WAV file without issue.
On my side 24 bit seems fine, but not 96000 Hz
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-10 23:40:24
I can try to implement Unicode support using the same piece of code as the Windows FLAC uses. That makes it quite simple, as it implements support for both command line arguments and fopen with UTF-8 strings, and converts them to UTF-16 for Windows' Unicode API.
Thanks very much for the offer, that would be great! Even a PM with some quoted reference code on how to use 'wchar_t' instead of 'char' (I assume that's part of the issue) would already be very helpful, I don't have much time for this at the moment.

A simple 'make release'  creates two executables in bin: exhale and exhaled.
That's strange, 'make release' should only create exhale, only 'make debug' should create the debug build exhaled.

Can someone confirm plentiful fails to encode 24 bit sources? I get encoded only few track of an album, while when downscaling the source to 16 bit, all tracks are converted.
88.2 and 96 kHz should work from CVBR mode 5 or 6 upwards, and 24 (or even 32) bits should work in any case. Do you have a short 24-bit WAV file for me which doesn't work, to identify the issue?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Ohdengoh on 2020-06-11 05:36:00
Hi, I have been trying out exhale, and so far so good, but to make things easier I noticed exhale is apparently capable of taking input from stdin, so I had assumed I should be able to pipe to exhale from ffmpeg instead of having to convert everything to wav first?  Anyway below is the command (one of the ones I have tried anyway) I am trying to use:

Code: [Select]
ffmpeg.exe -i input.??? -f wav - | exhale.exe 5  "output.m4a"

Which isn't working, so my question is, is piping from ffmpeg possible or should I give up on this method?. And if it isn't currently implemented, could I add it as a feature wish, if it isn't already on the todo list.

Thanks
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-06-11 10:29:55
Hi,

Try to add:
Code: [Select]
-map_metadata -1 -bitexact
parameters to ffmpeg.

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Ohdengoh on 2020-06-11 12:45:23
Thanks very much, nice to have this working.
I had actually tried the metadata flag in my trials but had removed it for simplicity of the posted version, but have never had to use the bitexact flag before, so that was the missing ingredient I hadn't tried, anyway, thanks again, AiZ.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-06-11 14:59:37
Update (preset 3).
1.0.01.0.11.0.21.0.31.0.41e41f670
castanets106107100106105105
fatboy_30sec111112111115115115
eig99101102114113113
Bachpsichord106105111117121121
Enola110110108106107107
trumpet101100106105105105
applaud104106107107107107
velvet108109109107107107
Linchpin939495929393
spill_the_blood102102106108109108
female_speech10410597978685
French_Ad104104101103102102

1.0.01.0.11.0.21.0.31.0.41e41f670
41_30sec109110112115114114
finalfantasy10110010098104104
ATrain106106110114113113
BigYellow109110109105106106
FloorEssence105106105107109109
macabre9695100107107107
mybloodrusts9797101959595
Quizas103104107110110110
VelvetRealm106105108114113113
Amefuribana100100101105105105
Trust99100102101102101
Waiting103103106109111110
experiencia107108104101103103
HearttoHeart105105108103102102
Tom'sDiner115115102104107106
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: jarsonic on 2020-06-12 15:14:25
C.R.Helmrich, can you clarify exactly what you are seeing in the fb2k metadata writing that is corrupted, per this note?

Quote
The reason is an incompatibility between exhale's file write-out routine and foobar2000's metadata transfer routine, with the latter writing the metadata only partially and/or at the wrong location in the MPEG-4 file generated by exhale.

I'm encoding in fb2k 1.5.5 beta 1, and I'm not seeing any of these errors in the metadata; the files are still playing fine with no issues, at least using kode54's fdk-aac decoder.  If you can detail what you are seeing that is wrong, I can pass it back to Peter and he can try to fix what's wrong in the fb2k metadata writer.  :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Anakunda on 2020-06-12 19:13:48
88.2 and 96 kHz should work from CVBR mode 5 or 6 upwards, and 24 (or even 32) bits should work in any case. Do you have a short 24-bit WAV file for me which doesn't work, to identify the issue?

I don't have a short sample, the issue seems random because all tracks which failed encoding 24 bit album in batch, encoded with varying result when I encoded them repeatedly to reproduce the fail. The conclusion is clear if you encode album and compare list of failed tracks with failed lists of another runs. It clearly identifies uninitialized data if running same code on same input with same parameters and varying results.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-12 23:00:45
Regarding the Unicode issue, I just added support for Unicode file names in the exhale application when running on Windows (sorry, not on Linux yet). Turns out it was much less work than I thought... assuming, of course, I did it correctly :) The corresponding source code macro is in line 33 in src/app/exhaleApp.cpp:
Code: [Select]
#define EXHALE_APP_WCHAR  (defined (_MSC_VER) || defined (__MINGW32__))
Please let me know if this works when running exhaleApp.exe stand-alone or through foobar2000. If you're building the application with a compiler other than Visual Studio, try appending the corresponding macro (e.g. "|| defined (__INTEL_COMPILER)" to that line and report back if it compiles and runs correctly, so I can complete the list before the next release. And, in case anyone still has a Windows XP installation, please tell me if it works on that version as well. Thanks!

Update (preset 3)...
Thanks, AiZ, for the cross-check. I'm not planning any further changes at CVBR mode 3 for now, so your table will probably stay the same after the next release.

C.R.Helmrich, can you clarify exactly what you are seeing in the fb2k metadata writing that is corrupted, per this note?
...
the files are still playing fine with no issues, at least using kode54's fdk-aac decoder.
You mean the Wiki entry (https://gitlab.com/ecodis/exhale/-/wikis/faq#i-get-corrupted-files-when-encoding-using-exhale-via-foobar2000-why)? This used to be an issue a few months back, it seems that, fortunately, with the newer versions of foobar2000 and/or kode54's FDK-AAC based packet decoder (https://www.foobar2000.org/components/view/foo_pd_aac), that problem went away. Not sure what happens when kode54's decoder is not installed in foobar2000, though. And, as the on-the-fly resampling and 24-bit (?) issues reported by guruboolez, Anakunda, and others show, there's still something fishy going on.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-06-12 23:24:42
[...] not on Linux yet [...]
you mean wine?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-12 23:30:55
I meant with Linux binaries. Don't now if it works on wine.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-06-12 23:44:46
i dont understand. i "make release" on gitlabs download. no names issue. only win version in wine.

ps. now understanding. :)
it is good to have someone who is more knowledgeable and patient to explain...
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-06-12 23:45:33
Linux binaries should have automatically supported Unicode filenames from the start, as should macOS. Since both platforms use UTF-8 as their default 8 bit encoding, you don't need to do anything special to support it there.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-13 00:00:31
Ah, good to know, didn't know that (I'm a Windows guy and don't use Linux much). Then everything's fine on Linux, I guess, and we can complete the Unicode support for Windows by just extending the EXHALE_APP_WCHAR macro which I mentioned above.

One more thing I noticed: when using exhale for converting to USAC directly during CD ripping, foobar2000 1.5.4 fails just after completing each track rip. Strange. Can anyone confirm this?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: 2012 on 2020-06-13 09:08:08
Since both platforms use UTF-8 as their default 8 bit encoding

There is no encoding used at all. It's just raw bytes.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-06-13 09:46:29
Hello,

One more thing I noticed: when using exhale for converting to USAC directly during CD ripping, foobar2000 1.5.4 fails just after completing each track rip. Strange. Can anyone confirm this?

Confirmed with v1.5.4.

Code: [Select]
Converting: "cdda://00BF3150" / index: 1
Audio CD extraction setup: drive: "ATAPI - iHBS112   2", sample offset: 6, security: standard
Destination: "F:\DAE\Warren G - Regulate - USAC\01. Warren G, Nate Dogg - Regulate.m4a"
CLI encoder: exhale.exe
Destination file: F:\DAE\Warren G - Regulate - USAC\01. Warren G, Nate Dogg - Regulate.m4a
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Program Files\exhale\exhale.exe" 3 "01. Warren G, Nate Dogg - Regulate.m4a"
Working folder: F:\DAE\Warren G - Regulate - USAC\
Encoder process still running, waiting...
Encoder process terminated cleanly.
Object "mdat" at 44560
Media data is truncated, the file may not be playable completely.
Writing tags to encoded file failed: invalid or incomplete data
An error occurred while finalizing the encoding process (invalid or incomplete data) : "F:\DAE\Warren G - Regulate - USAC\01. Warren G, Nate Dogg - Regulate.m4a"
Conversion failed: invalid or incomplete data
Converting: "cdda://00BF3150" / index: 2
Audio CD extraction setup: drive: "ATAPI - iHBS112   2", sample offset: 6, security: standard
Destination: "F:\DAE\Warren G - Regulate - USAC\02. Warren G - Do You See.m4a"
CLI encoder: exhale.exe
Destination file: F:\DAE\Warren G - Regulate - USAC\02. Warren G - Do You See.m4a
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Program Files\exhale\exhale.exe" 3 "02. Warren G - Do You See.m4a"
Working folder: F:\DAE\Warren G - Regulate - USAC\
Encoder process still running, waiting...
Encoder process terminated cleanly.
Object "mdat" at 42860
Media data is truncated, the file may not be playable completely.
Writing tags to encoded file failed: invalid or incomplete data
An error occurred while finalizing the encoding process (invalid or incomplete data) : "F:\DAE\Warren G - Regulate - USAC\02. Warren G - Do You See.m4a"
Conversion failed: invalid or incomplete data
Converting: "cdda://00BF3150" / index: 3

etc.

Same behaviour with v1.5.5 beta 1.

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-13 16:39:27
Thanks for the detailed report! I think I found the culprit. Please try the newest code (https://gitlab.com/ecodis/exhale/-/commit/d280767) from Git. The exhale application assumed 1024 new samples per channel are always available when encoding a new frame, which isn't necessarily the case when ripping from CD (which uses sectors of 588 samples per channel). I tried to re-tune the PCM reading code in exhale accordingly.

Edit: This might actually also fix the on-the-fly downsampling and 24-bit issues. Please check if you may.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-06-13 18:49:02
Works Ok with commit b83a3c48 and foobar v1.5.5 beta 1 for CDDA to USAC

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-06-13 21:15:14
I have downloaded one 24/88.2 file from this site (http://www.2l.no/hires/).
- FLAC -> USAC direct conversion with foobar (v1.5.5 beta 1) to 24/88.2 or 24/44.1 is Ok.
- WAV -> USAC conversion, using CLI, at 24/88.2, 24/44.1, 16/88.2 or 16/44.1 is Ok. Seems legit, as all the FLAC to WAV conversions are made with foobar.
But:
- exhale doesn't like WAV files above 16/48 written by ffmpeg (16/88.2, 24/44.1 or 24/88.2).
- exhale doesn't like 24-bit WAV files written by sox.

foobar can read all the WAV files generated above.

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-06-13 21:59:59
to AiZ
are unicode is worked?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-06-13 23:01:08
Well, seems to...

Code: [Select]
D:\temp\aac\exhale\test>"c:\Program Files\exhale\exhale.exe" 5 .\Ťęşť_ʄīŀė.wav .\┴ǝsʇ‾ɟᴉlǝ˙m4a

  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.0.4 (x64, built on Jun 13 2020) - written by C.R.Helmrich |
  ---------------------------------------------------------------------

 Encoding 44-kHz 2-channel 16-bit WAVE to low-complexity xHE-AAC at 128 kbit/s

 Progress: --------------------------------- Done, actual average 139.8 kbit/s

 Input statistics: Mobile loudness -23.68 LUFS, sample peak level -6.17 dBFS

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-13 23:47:52
Wonderful, thanks for testing! One more question, though (emphasis mine):
I have downloaded one 24/88.2 file from this site (http://www.2l.no/hires/).
- FLAC -> USAC direct conversion with foobar (v1.5.5 beta 1) to 24/88.2 or 24/44.1 is Ok.
Does that mean on-the-fly downsampling while encoding works now with exhale?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-06-14 02:44:32
Since both platforms use UTF-8 as their default 8 bit encoding

There is no encoding used at all. It's just raw bytes.
It's raw bytes, in a specific encoding. The encoding depends on the locale setting used by the OS. For most, this defaults to UTF-8, because there is no point in making the default anything less Unicode compatible these days. Windows is really the only modern OS that uses anything but UTF-8 for its 8 bit strings these days.

Don't give me any crap about "raw bytes", if you want to manipulate these strings in any way, you have to know how they're encoded. It's only by standards that the path separators are ASCII compatible, therefore manipulating UTF-8 strings for path operations doesn't require understanding anything but ASCII. Maybe some other 8 bit encodings mix ASCII alike characters into their multi-byte encoding, but UTF-8 does not.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-06-14 11:12:34
Hello,

Does that mean on-the-fly downsampling while encoding works now with exhale?
I've tested various combinations on the same (previous) file at 96, 64, 48, 44, 32Khz etc. with the three resamplers installed in my foobar, everything went Ok.
But...  :D

I've downloaded another 24/96 file (the smallest one) to build the table below:

123456
16/1654648194131*
16/22.56779104123172222
16/246779102118157198
16/327588105113130139
16/44.17791109119139151
16/48-90107117137149
16/64--110121141155
16/88.2----197219
16/96----210233
24/1654638194130*
24/22.56779104123171222
24/246779102118157198
24/327588105113130138
24/44.17791109119139151
24/48-90106117137149
24/64--110122141155
24/88.2----197219
24/96----210232

*: ERROR while trying to initialize xHE-AAC encoder: error value 33 was returned!

From preset 3 or 4, there's a problem with 22.5 and 24Khz files. And perhaps with 16Khz ones at preset 5 and above.

Files are encoded with commit 7d9e0db9, I discovered that preset 1 can now encode 44.1 files. Cool!

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-14 22:31:06
I've tested various combinations on the same (previous) file at 96, 64, 48, 44, 32Khz etc. with the three resamplers installed in my foobar, everything went Ok.
Awesome, thanks! So I can stop adding automatic downsampling to exhale for now.
Quote
But...  :D
From preset 3 or 4, there's a problem with 22.5 and 24Khz files. And perhaps with 16Khz ones at preset 5 and above.
Good catch, that should be fixed with the latest version (https://gitlab.com/ecodis/exhale/-/commit/28ba11cf). Could you try the 16-44.1 kHz configurations again for verification, please?
Quote
Files are encoded with commit 7d9e0db9, I discovered that preset 1 can now encode 44.1 files. Cool!
Another good catch ;) But keep in mind that, at such a low target bit-rate and without SBR support, strong compromises had to be made (only 14.5 kHz audio bandwidth, and audible spectral holes on some samples). So 44.1 kHz probably doesn't sound better than 32 kHz on average, actually, it may sometimes sound worse.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-06-14 23:07:01
Updated with commit 28ba11cf

123456
16/1654638189112*
16/22.56779104115145168
16/246779102112136153
16/327588105113130139
16/44.17591109119139151
16/48-90107117137149
16/64--110121141155
16/88.2----197219
16/96----210233
24/1654638189112*
24/22.56779104115145167
24/246779102112135153
24/327588105113130138
24/44.17591109119139151
24/48-90106117137149
24/64--110122141155
24/88.2----197219
24/96----210232

*: ERROR while trying to initialize xHE-AAC encoder: error value 33 was returned!

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Peter on 2020-06-16 08:23:11
Confirmed problem with exhale vs foobar2000 using exhale git from a few days ago, fixed in latest exhale. Can you please correct the wiki entry, since it's not a foobar2000 problem? Thanks.

I'll look into making exhale supported out of the box in near future so no manual settings are needed.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-06-16 12:49:56
I'll look into making exhale supported out of the box in near future so no manual settings are needed.

 8)  8)  8)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-06-16 21:01:08
I wonder how long it would take ffmpeg to support xHE-AAC decoding.  Someting to do with license and legal considerations.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Rollin on 2020-06-16 21:54:30
I wonder how long it would take ffmpeg to support xHE-AAC decoding.
Support for USAC has "wish" priority (lowest), so, probably, it will take very long. https://trac.ffmpeg.org/ticket/8411
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-17 01:00:45
A beta version of exhale 1.0.5 has been released today, see
https://gitlab.com/ecodis/exhale

exhale 1.0.5 - Change Log
- slightly reduced bit-rates with lower modes, better compatibility when using stdin
- exhaleApp: support for Unicode text on Windows™, 44100 Hz with CVBR mode 1
- exhaleApp: automatic upsampling of low-sample-rate input*, better WAVE reading
- exhaleLib: optimized noise filling tool for slightly lower bit-rates at CVBR mode <4

There's also a new version 1.12 of kode54's FDK-AAC packet decoder available here (https://foobar2000.org/components/view/foo_pd_aac).

Note that using an input sampling rate of 44.1 kHz at CVBR mode 1 might not actually sound better than using 32 kHz input, but I found it to sound acceptable at both sampling rates (although I'd recommend to use CVBR mode 2 or 3 instead, unless you really have to restrict yourself to ~64 kbit/s stereo or ~32 kbit/s mono on average). Note, also, that the functionality marked with a * above is not finished yet but will, hopefully, make it into the final version, due at the end of the month. That will circumvent the "error 33" issue reported by AiZ here (https://hydrogenaud.io/index.php?topic=118888.msg984233#msg984233) in the unlikely case when exhale is used to encode sampling rates lower than 32 kHz with high CVBR modes.

Support for Unicode can be checked by running the Windows executable as "exhale.exe -V". If supported, the output string contains the word "Unicode".

And finally, I also managed to speed up the encoder by roughly 10% at the lower CVBR modes, and even more than that when encoding 32-kHz content.

Quote from: Peter
Can you please correct the wiki entry, since it's not a foobar2000 problem? Thanks. I'll look into making exhale supported out of the box in near future so no manual settings are needed.
Done. Thanks very much, built-in configuration via foobar2000's GUI would be great!

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-06-17 06:20:24
exhale v1.0.5b-cd4ebeb1
Built on June 16, 2020, GCC 10.1.0

https://gitlab.com/ecodis/exhale
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-06-17 09:45:37
exhaleApp-v.1.0.5b-cd4ebeb1 Intel 19 compiles:

www.rarewares.org/files/aac/exhaleApp-v.1.0.5b-cd4ebeb1_x64.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.5b-cd4ebeb1_x64.zip)

www.rarewares.org/files/aac/exhaleApp-v.1.0.5b-cd4ebeb1_x86.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.5b-cd4ebeb1_x86.zip)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-06-17 12:55:04
For unknown reason, I can't use your x64 compile, John33. But Netranger's x64 is working fine (with the same encoder setting: I only changed the encoder's path). Your previous compiles always worked fine.
Am I alone?

Intel Core i7-3610QM


Code: [Select]
1 out of 1 tracks converted with major problems.

Source: "D:\ABX renaissance\bitrate\Bitrate Test 85CD\A.01. Brahms [Claudio Abbado & Wiener Philharmoniker] 21 Ungarische Tanze (DG, CD, 1983).flac"
  An error occurred while writing to file (The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters) : "D:\A.01. Brahms [Claudio Abbado & Wiener Philharmoniker] 21 Ungarische Tanze (DG, CD, 1983).m4a"
  Additional information:
  Encoder stream format: 44100Hz / 2ch / 16bps
  Command line: "C:\CODEC\exhale xHE-AAC\exhaleApp-v.1.0.5b-cd4ebeb1_x64\exhaleApp.exe" 2 "A.01. Brahms [Claudio Abbado & Wiener Philharmoniker] 21 Ungarische Tanze (DG, CD, 1983).m4a"
  Working folder: D:\
 
  Conversion failed: The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-06-17 13:50:32
Strange! Both x86 and x64 compiles run normally either stand-alone, or within foobar here. (i7 4790k and Ryzen 7 3700X.)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-06-17 15:15:31
I tried again: same error
Then I tried with x86 compile or yours (exhaleApp-v.1.0.5b-cd4ebeb1): encoding starts fine. I stopped it.
Finally, I changed again the encoder path in foobar to use x64, same source file, same destination: error

Code: [Select]
1 out of 1 tracks converted with major problems.

Source: "D:\ABX renaissance\bitrate\Bitrate Test 85CD\A.10. VA [Placido Domingo, Carlo Maria Giulini & LA Philharmonic Orchestra] Opern-Gala (DG, CD, 1981).flac"
  An error occurred while writing to file (The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters) : "Z:\A.10. VA [Placido Domingo, Carlo Maria Giulini & LA Philharmonic Orchestra] Opern-Gala (DG, CD, 1981).m4a"
  Additional information:
  Encoder stream format: 44100Hz / 2ch / 16bps
  Command line: "C:\CODEC\exhale xHE-AAC\exhaleApp-v.1.0.5b-cd4ebeb1_x64\exhaleApp.exe" 5 "A.10. VA [Placido Domingo, Carlo Maria Giulini & LA Philharmonic Orchestra] Opern-Gala (DG, CD, 1981).m4a"
  Working folder: Z:\
 
  Conversion failed: The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-06-17 15:29:42
No issues here with John33's exhale 1.0.5b binaries in foobar2000. Working smooth as usual
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-06-17 15:57:24
both version via foobar (wine) work norm, but as "CLI" via wine(/64) not work by different resons.
upd.
core2duo t5600
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-06-17 16:11:57
Strange! Both x86 and x64 compiles run normally either stand-alone, or within foobar here. (i7 4790k and Ryzen 7 3700X.)
Not sure but  maybe the case that i7 3000 supports AVX only, while i7 4000 does  AVX2.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-06-17 18:12:24
Strange! Both x86 and x64 compiles run normally either stand-alone, or within foobar here. (i7 4790k and Ryzen 7 3700X.)
Not sure but  maybe the case that i7 3000 supports AVX only, while i7 4000 does  AVX2.
Possibly, but I try to make sure that CPU specific optimisations are not invoked in the compiler, and the compile options used are no different to any of the recent builds so a bit of a puzzle!?!
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: capma on 2020-06-17 19:38:06
Same problem as guruboolez; processor is i5-2400, OS Windows 7 Enterprise x64.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-06-17 20:11:13
maybe version of foobar and/or decoder? my case (ok) - 1.5.4/1.12
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-06-17 20:35:11
I have foobar2000 1.54 and 1.12 decoder.
I tried different time ; I even download the archive again and extracted it in a shorter path. I tried different file, different size, basic output path…

Code: [Select]
1 out of 1 tracks converted with major problems.

Source: "D:\essai.wav"
  An error occurred while writing to file (The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters) : "D:\essai.m4a"
  Additional information:
  Encoder stream format: 44100Hz / 2ch / 16bps
  Command line: "C:\CODEC\exhaleApp 1.0.5b.exe" 4 "essai.m4a"
  Working folder: D:\
 
  Conversion failed: The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters

It's very curious.
Anyway, don't waste your time on this. I'm maybe alone on to have this issue. Previous compiles were all good. And I can use x86 or Netranger's 64 bit for this exhale version. Maybe next compile will be fine again :)
Thanks having checked on your side.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Case on 2020-06-17 21:07:11
IgorC appears to have been correct. The error code refers to illegal instruction and disassembly of the binary shows it contains AVX2 instructions.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-06-17 21:23:53
Sorry folks!! Having rechecked the 64bit compile, I realised that I had enabled AVX2 on an earlier test build and completely forget to revert it! So, again, sorry to have caused a problem and the x64 link, above, should now give you a generic build.  :-[
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-06-17 21:28:46
Don't apologise! I owe you so much for all your compiles for more than a decade! Thanks John33 :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: capma on 2020-06-17 21:34:53
No need to apologise... just to confirm that everything works now. Thanks :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-06-17 21:35:33
Great, thanks ! :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-06-18 15:13:21
Now that 1.0.5 beta allow 44.1 KHz sampling rate with mode 1 at ~64 kbps, I was very curious to check how it sounds. Especially after my big 64 kbps personal blind test (https://hydrogenaud.io/index.php?topic=119333.0).

Few words about the tested samples.
I have tested exhale with 40 samples (in fact, 39 because I included the same sample twice) divided in four groups:

The first three groups are rather "normal" music or common samples ; the last group is maybe a bit more exceptional and is for the most part pre-echo/smearing oriented. For the anecdote, the sample named "41_30sec" was also include in this last group. I removed it during the test when I noticed that I tested it few hours ago in the group 3…

Listening Test Methodology & bitrate
I only performed one ABX test to check the difference of smearing. For all other samples I only gave a score before testing the next file. There are no anchor and therefore scoring is unconstrained.
Bitrate is nearly the same between 32KHz and  44.1KHz (1 kbps difference on full discs/tracks). Even on short samples the gap is unsignificant (69.1 kbps for 32 KHz and 68.1 for 44 KHz). I can put a bitrate table on demand.




RESULTS



(https://zupimages.net/up/20/25/k31d.png) (https://zupimages.net/viewer.php?id=20/25/k31d.png)

(https://zupimages.net/up/20/25/nkea.png) (https://zupimages.net/viewer.php?id=20/25/nkea.png)

Difference isn't significant from a statistical point of vue. But 44.1 Khz has often a lower score than 32 KHz especially on the first three groups. 44.1 KHz has more distortions, so basic I can't really describe them. The kind of acid sound you can hear since decades on low bitrate/starving encodings. Maybe lowpass (which is stronger than with 32KHz) explain this but I'm quite sure there's something else responsible of this. Sometimes it sounds a bit like a kind of noise reduction. Anyway it's a sound I usually dislike: it's a bit WMA-isch/MPEG-isch.
But when transients are involved in the sample, smearing and pre-echo is usually better with 44.1 KHz than with 32 KHz. But I found a small artifact especially audible on eig sample (I'll describe it on another post).

Now, if I dissociate the three groups of "normal" samples from the last group, the results are a bit different:

(https://zupimages.net/up/20/25/hrjz.png) (https://zupimages.net/viewer.php?id=20/25/hrjz.png)

(https://zupimages.net/up/20/25/80t6.png) (https://zupimages.net/viewer.php?id=20/25/80t6.png)

This time, 32KHz is statistically better for the 30 first samples. 44.1 KHz looks stronger on problem samples which is mainly due to its lesser pre-echo.
I remind: it's a personal listening test and evaluation.


Links

samples are available here:
https://www.dropbox.com/sh/zjephy3g54j4gur/AACjGhM9tabl26n7s4ihYl2Ra?dl=0
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-06-18 15:48:35
To complete my test:

I noticed two curious artifacts.
The first one only occured on 44.1 KHz sampling rate with eig sample.
The sample has several time the same transient sound but with exhale 1.0.5b mode 1 at 44.1 KHz some transients are sounding weird and differently than others.
Here is my log file:

Quote
ABC/HR for Java, Version 0.53a, 18 juin 2020
Testname:

Tester: guruboolez

1L = D:\ABX EXHALE 32-44\Problem 03. eig.exhale v1.0.5b-cd4ebeb1.mode1.44khz.wav
2L = D:\ABX EXHALE 32-44\Problem 03. eig.exhale v1.0.5b-cd4ebeb1.mode1.32khz.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\ABX EXHALE 32-44\Problem 03. eig.exhale v1.0.5b-cd4ebeb1.mode1.44khz.wav
1L Rating: 2.5
1L Comment: weird artefacts :
1.60 sec
3.80 sec
6.00 sec
12.5 sec
Much sharper than other file

---------------------------------------
2L File: D:\ABX EXHALE 32-44\Problem 03. eig.exhale v1.0.5b-cd4ebeb1.mode1.32khz.wav
2L Rating: 1.5
2L Comment:
---------------------------------------

ABX Results:

44.1 KHz is sharper than 32 KHz but produces some artifacts at precise moments.
I looked into the spectrum to see if something appears. I made an animated gif.

(https://zupimages.net/up/20/25/3jjp.gif) (https://zupimages.net/viewer.php?id=20/25/3jjp.gif)
As you can see in the spectrum there are three attacks. They sound almost identical so we can imagine they should look the same. It's the case for the 32 KHz encoding but the 44.1 KHz shows a much different image for the first attack. There is indeed much more energy or noise after the transient, a bit like post-echo. Is this noise which makes this moment sound so differently? I don't know. Anyway, it's clearly audible I would say. To share the experience I join the encoded m4a files and the decoded one in this post.


Second issue, audible with both 32 and 44.1 KHz encoding: the Glockenspiel sample (it's an MPEG sample IIRC).
My log file:

Quote
ABC/HR for Java, Version 0.53a, 18 juin 2020
Testname:

Tester: guruboolez

1L = D:\ABX EXHALE 32-44\Problem 09. 35_SQAM_glockenspiel_cut.exhale v1.0.5b-cd4ebeb1.mode1.32khz.wav
2L = D:\ABX EXHALE 32-44\Problem 09. 35_SQAM_glockenspiel_cut.exhale v1.0.5b-cd4ebeb1.mode1.44khz.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\ABX EXHALE 32-44\Problem 09. 35_SQAM_glockenspiel_cut.exhale v1.0.5b-cd4ebeb1.mode1.32khz.wav
1L Rating: 2.0
1L Comment: low frequency artifacts after each attack
---------------------------------------
2L File: D:\ABX EXHALE 32-44\Problem 09. 35_SQAM_glockenspiel_cut.exhale v1.0.5b-cd4ebeb1.mode1.44khz.wav
2L Rating: 2.5
2L Comment: low frequency artifacts after each attack, stronger I think than previous file (but they seem to mask smearing: it seems sharper).
---------------------------------------

ABX Results:

I really hear some artifacts (but I must say that's at high volume playback, 100% of my laptop and a AKG q701 62 Ω impedence headphone) which sounds like small low/mid frequency "plops" which all comes with all glockenspiel note. I join the m4a files and the original FLAC sample if someone can check. I can't illustrate this phenomenon with a graphical analysis.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: anbo on 2020-06-18 20:47:07
Hello, when I convert in foobar2000 from flac image with embedded cuesheet and turn off „Do not convert in multiple threads” option, then there is no errors. But when I turn on this option, then I have errors. When I bit-compare tracks from both conversions I have errors too. My CPU is Intel Core i5-4300U (4 threads).
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-06-18 22:39:54
I noticed two curious artifacts.
The first one only occured on 44.1 KHz sampling rate with eig sample.
Those are exactly the same artifacts which were noticed  on 1.0.4 beta.  But with some important observaitons:
Audible intensity  of different type of artifacts  (plops and pre-echo) seem to swap on different bitrates. Plops artifacts are more ok at 96 kbps but as I can see (and hear as well)  it's less ok at 64 kbps.  And sincerely I haven't submit one single test sample at 64 kbps because lack of time and interest at this bitrate point.

I guess when 96 kbps was tuned then 64 kbps got sorta  untuned. I have seen this happened with some codecs in past.

P.S. Not sure what Chris has in plans for exhale but it might be useful to have in mind most popular bitrate points of Opus as this codec and exhale have similar compresison efficiency https://hydrogenaud.io/index.php?topic=115386.0
Sure, ideally all bitrate points should be tuned as much as possible, but  resources as time are always [very] limited. So it's good to define priorities (personal or someone else's) :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: diizzy on 2020-06-20 15:14:26
Great work!

Anyone else running into issues compiling this for aarch64 (runs fine on amd64)?
https://pastebin.ubuntu.com/p/mBb3D9ZrRK/

FreeBSD 13-CURRENT, aarch64 (rockpro64) using cmake
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: 2012 on 2020-06-20 19:16:01
Great work!

Anyone else running into issues compiling this for aarch64 (runs fine on amd64)?
https://pastebin.ubuntu.com/p/mBb3D9ZrRK/

FreeBSD 13-CURRENT, aarch64 (rockpro64) using cmake

Looks like the infamous "char is unsigned on ARM" issue. Maybe, as a simple experiment, try to replace all `char` occurrences  with `int8_t` and see what happens?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-21 00:00:22
Hello, when I convert in foobar2000 from flac image with embedded cuesheet and turn off „Do not convert in multiple threads” option, then there is no errors. But when I turn on this option, then I have errors. When I bit-compare tracks from both conversions I have errors too. My CPU is Intel Core i5-4300U (4 threads).
That seems to be an issue not so easy to fix (the error value that the encoder returns means "file I/O error"). I'll have to take a look at that later this year, sorry.
I guess when 96 kbps was tuned then 64 kbps got sorta  untuned. I have seen this happened with some codecs in past.
So far I haven't done many CVBR mode specific tunings, so I'm quite sure this is not the case. It's just too low of a bit-rate for 44.1 kHz sampling rate, I would say.
Looks like the infamous "char is unsigned on ARM" issue.
Oh, ARM support hasn't been on my radar at all! If you find a fix, please let me know!

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-21 00:00:54
A release candidate version of exhale 1.0.5 has been made available today, see
https://gitlab.com/ecodis/exhale

Changes since the beta version of exhale 1.0.5 from last week:
- changed the names of the release-mode Visual Studio output executables from "exhaleApp.exe" to "exhale.exe", for consistency with CMake behavior (thanks to NetRanger for reporting this!)
- fixed writing of the creation and modification times into the MPEG-4 file header, the previous timestamps were exactly 1970-1904 = 66 years in the past (thanks to kamedo2 for reporting this!)
- fine-tuning of the average bit-rate resulting from 44.1-kHz coding at CVBR mode 1, it was 1 kbit/s lower than that resulting from 32-kHz coding (thanks to guruboolez and m14u for checking!)
- print a warning message when CVBR mode 1 is used with 44.1 kHz input, since guruboolez's personal test verifies that 44.1 kHz sounds worse than 32 kHz on average (thanks a lot for testing!)
- added automatic 2x upsampling of low sampling rates (fs) at high bit-rates when CVBR mode > fs / 4000. To reach the given target rate, the CVBR mode is increased by one when upsampling
- minor speed-up when encoding 22.05 or 24 kHz and automatic upsampling is not used, and a few other minor editorial changes here and there.

What I haven't yet been able to take a look at is the issue reported by AiZ here (https://hydrogenaud.io/index.php?topic=118888.msg984209#msg984209). I suspect that the WAVE files which exhale doesn't like are Broadcast/Extensible-WAV format files, which is a format exhale currently doesn't support. Can anyone confirm this?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Pabl on 2020-06-21 06:34:09
Guys, exhale CVBR mode 9 is better than QAAC CVBR 192? :o
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: diizzy on 2020-06-21 07:06:20
Great work!

Anyone else running into issues compiling this for aarch64 (runs fine on amd64)?
https://pastebin.ubuntu.com/p/mBb3D9ZrRK/

FreeBSD 13-CURRENT, aarch64 (rockpro64) using cmake

Looks like the infamous "char is unsigned on ARM" issue. Maybe, as a simple experiment, try to replace all `char` occurrences  with `int8_t` and see what happens?

That seems to fail on my end but I might be doing something wrong...
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-06-21 08:30:26
Intel 19 RC1 compiles for testing:

www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc1-fd32557d_x64.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc1-fd32557d_x64.zip)

www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc1-fd32557d_x86.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc1-fd32557d_x86.zip)

Multi-thread foobar conversion works here without issue.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-06-21 15:58:23
So far I haven't done many CVBR mode specific tunings, so I'm quite sure this is not the case. It's just too low of a bit-rate for 44.1 kHz sampling rate, I would say.
Yes, You're right. I should probably just mention that different artifacts are less/more audible at different bitrates and sampling rates. And leave it there.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: 2012 on 2020-06-22 02:09:58
@diizzy

Try this patch (https://gist.github.com/MoSal/4e3308951291315a9576609cec9769a8/raw/44cbf63e06099649b843505d85b75f8aa863242d/0001-Explicitly-use-signed-char-instead-of-char-where-nee.patch).
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-06-22 14:35:39
My bitrate table is updated. Some data are still missing for 1.0.4 final. 1.0.5 RC1 tests are far from completion but include full data for mode 1 to 4 (and 5 to 9 for a smaller group of non-classical samples).

Small change: I'm now using the two classical boxset (55+29=84CD) alone as reference for classical music and not the 91 CD anymore (84 CD+7 extreme bitrate CD).
Small addition: I add the 25 tracks from a popular music Billboard chart in a separate collumn. It's really tiny set of file (92 minutes) but it may give an idea of how perform the encoder with something else than Bach or Beethoven, flute or orchestra…



Code: [Select]
[code]
                                   |               C L A S S I C A L  M U S I C                 ||  NON-CLASSICAL
------------------------------------------------------------------------------------------------||--------------------
    ENCODER & PRESET               |   BITRATE    |               BONUS STEREO      BONUS       ||    BILLBOARD
                                   |   2 BOXSET   |    MONO       LOW BITRATE    HIGH BITRATE   || 2010…2020 hits
                                   |   (84 CD)    |   (3 CD)         (4 CD)        (3 CD)       ||   (25 tracks)
------------------------------------------------------------------------------------------------||--------------------
FLAC CUEtools       -8             |  579.2 kbps  |   467.7 kbps   264.0 kbps   1028.7 kbps     ||   921.3 kbps
------------------------------------------------------------------------------------------------||--------------------
exhale 1.0.3 [24KHz SOX]   mode 1  |   61.8 kbps  |    61.7 kbps    38.3 kbps     72.0 kbps     ||    68.0 kbps
exhale 1.0.4 [32KHz SOX]   mode 1  |   65.3 kbps  |    56.3 kbps    40.5 kbps     86.0 kbps     ||    ---------
exhale 1.0.4 [32KHz SSRC]  mode 1  |   65.2 kbps  |    50.3 kbps    40.3 kbps     85.0 kbps     ||    69.5 kbps
exhale 1.0.5 RC1 [32KSSRC] mode 1  |   64.4 kbps  |    49.3 kbps    38.8 kbps     85.0 kbps     ||    68.6 kbps
exhale 1.0.5 RC1 [44K]     mode 1  |   64.5 kbps  |    49.7 kbps    42.0 kbps     86.7 kbps     ||    68.2 kbps
                                                                                                ||  
exhale 1.0.3  [32 KHz SOX] mode 2  |   81.3 kbps  |    85.7 kbps    54.3 kbps     96.0 kbps     ||    83.5 kbps
exhale 1.0.4  [32 KHzSSRC] mode 2  |   79.9 kbps  |    66.3 kbps    49.0 kbps     97.0 kbps     ||    84.5 kbps
exhale 1.0.4  [44 KHz]     mode 2  |   78.7 kbps  |    65.0 kbps    51.0 kbps    101.7 kbps     ||    82.9 kbps
exhale 1.0.5 RC1 [44 KHz]  mode 2  |   78.5 kbps  |    64.3 kbps    50.0 kbps    101.7 kbps     ||    82.5 kbps
                                                                                                ||  
exhale 1.0.3               mode 3  |  100.5 kbps  |   100.7 kbps    62.8 kbps    115.0 kbps     ||   101.8 kbps
exhale 1.0.4               mode 3  |   98.6 kbps  |    84.7 kbps    61.8 kbps    119.0 kbps     ||   102.3 kbps
exhale 1.0.5 RC1           mode 3  |   98.4 kbps  |    84.3 kbps    60.3 kbps    119.0 kbps     ||   102.0 kbps
                                                                                                ||  
exhale 1.0.3               mode 4  |  112.0 kbps  |   110.0 kbps    67.5 kbps    126.7 kbps     ||   113.5 kbps
exhale 1.0.4               mode 4  |  110.0 kbps  |    92.3 kbps    65.5 kbps    131.0 kbps     ||   113.9 kbps
exhale 1.0.5 RC1           mode 4  |  110.0 kbps  |    92.3 kbps    65.5 kbps    131.0 kbps     ||   113.9 kbps
                                                                                                ||  
exhale 1.0.3               mode 5  |  133.2 kbps  |   123.7 kbps    77.3 kbps    145.3 kbps     ||   130.8 kbps
exhale 1.0.4               mode 5  |  131.9 kbps  |   122.7 kbps    76.3 kbps    144.3 kbps     ||   130.4 kbps
exhale 1.0.5 RC1           mode 5  |        kbps  |         kbps         kbps          kbps     ||   130.4 kbps
                                                                                                ||  
exhale 1.0.3               mode 6  |  145.8 kbps  |   130.7 kbps    82.5 kbps    157.3 kbps     ||   142.6 kbps
exhale 1.0.4               mode 6  |  144.5 kbps  |   130.7 kbps    82.5 kbps    157.3 kbps     ||   142.2 kbps
exhale 1.0.5 RC1           mode 6  |        kbps  |         kbps         kbps          kbps     ||   142.2 kbps

exhale 1.0.3               mode 7  |  162.6 kbps  |   143.3 kbps    89.5 kbps    174.0 kbps     ||   158.8 kbps
exhale 1.0.4               mode 7  |  161.2 kbps  |   143.0 kbps    89.0 kbps    173.3 kbps     ||   158.5 kbps
exhale 1.0.5 RC1           mode 7  |        kbps  |         kbps         kbps          kbps     ||   158.5 kbps

exhale 1.0.3               mode 8  |  179.5 kbps  |   153.3 kbps    97.3 kbps    193.7 kbps     ||   177.7 kbps
exhale 1.0.4               mode 8  |        kbps  |         kbps         kbps          kbps     ||   177.3 kbps
exhale 1.0.5 RC1           mode 8  |        kbps  |         kbps         kbps          kbps     ||   177.3 kbps

exhale 1.0.3               mode 9  |  193.0 kbps  |   163.0 kbps   102.5 kbps    207.7 kbps     ||   191.0 kbps
exhale 1.0.4               mode 9  |        kbps  |         kbps         kbps          kbps     ||   190.5 kbps
exhale 1.0.5 RC1           mode 9  |        kbps  |         kbps         kbps          kbps     ||   190.5 kbps


• mode 1 and 2 are ~1 kbps smaller with 1.0.5 RC1 compared to 1.0.4 “E”. Difference is even smaller with mode 3. From mode 4 to mode 9, bitrate is or seems identical (based on "Billboard" group).
• the small "billboard" group (non-classical) shows higher bitrate for mode 1 to 4 compared to the larger classical music group (on average, + 4 kbps).
• high bitrate stereo discs (harpsichord) are twice bigger than low bitrate stereo discs (quiet piano), which is a satisfying ratio for VBR/CVBR.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-22 20:59:36
Try this patch (https://gist.github.com/MoSal/4e3308951291315a9576609cec9769a8/raw/44cbf63e06099649b843505d85b75f8aa863242d/0001-Explicitly-use-signed-char-instead-of-char-where-nee.patch).
Thanks. I took this patch, added some more "char" related fixes, and included everything in my most recent commit (https://gitlab.com/ecodis/exhale/-/commit/12bb5715) to the exhale repository. Does that work for you and diizzy?
My bitrate table is updated. Some data are still missing for 1.0.4 final. 1.0.5 RC1 tests are far from completion but include full data for mode 1 to 4 (and 5 to 9 for a smaller group of non-classical samples).
Wonderful, thanks! Looks good to me.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: diizzy on 2020-06-23 00:03:46
Try this patch (https://gist.github.com/MoSal/4e3308951291315a9576609cec9769a8/raw/44cbf63e06099649b843505d85b75f8aa863242d/0001-Explicitly-use-signed-char-instead-of-char-where-nee.patch).
Thanks. I took this patch, added some more "char" related fixes, and included everything in my most recent commit (https://gitlab.com/ecodis/exhale/-/commit/12bb5715) to the exhale repository. Does that work for you and diizzy?
My bitrate table is updated. Some data are still missing for 1.0.4 final. 1.0.5 RC1 tests are far from completion but include full data for mode 1 to 4 (and 5 to 9 for a smaller group of non-classical samples).
Wonderful, thanks! Looks good to me.

Chris

Confirmed working, many thanks!

If it's of any interest, about 2.7x encoding speed using preset 5 on my RockPro64 board (44.1kHz WAV(E) file as input).
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-23 12:42:11
If it's of any interest, about 2.7x encoding speed using preset 5 on my RockPro64 board (44.1kHz WAV(E) file as input).
Interesting, thanks for the info! Still faster than real-time, that's nice to see. And ARM support may become more important in the future, since Apple is planning to switch from Intel to ARM based processors (https://www.theguardian.com/technology/2020/jun/22/apple-ditches-intel-for-arm-processors-in-big-sur-computers) in its desktop computers.

By the way, is anyone compiling exhale on MacOS (clang)? Does it still work?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-06-24 14:49:25
Yes, it still works.

 exhale@12bb5715.zip  (104.78 KB)




MOD edit: change attachment tag (attach > attachurl)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-06-24 22:16:47
Hello,

What I haven't yet been able to take a look at is the issue reported by AiZ here (https://hydrogenaud.io/index.php?topic=118888.msg984209#msg984209). I suspect that the WAVE files which exhale doesn't like are Broadcast/Extensible-WAV format files, which is a format exhale currently doesn't support. Can anyone confirm this?

You're right : after a bit of Googling and extracting information with MediaInfo, all problematic files have the '00000001-0000-0010-8000-00AA00389B71' Codec ID, sign of Extensible Wave-Format.

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-06-25 00:14:23
Yes, it still works.

[attachurl]17389[/attachurl]


The same version of Exhale for macOS compiled with the newly released beta version
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-06-25 09:59:25
Current Release Candidate, I've designated it RC3 just to differentiate it, not sure it's the correct version. ;)

www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc3-74518cae_x64.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc3-74518cae_x64.zip)

www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc3-74518cae_x86.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc3-74518cae_x86.zip)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-25 11:21:01
Counting all commits since the first release candidate above, RC3 is correct. For all those using the exhale application stand-alone or through foobar2000: this is likely to become the final version next week, and there were several bugfixes and compatibility improvements since version 1.0.4, so reencoding of any music collections is encouraged.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-06-25 19:01:52
Interesting, thanks for the info! Still faster than real-time, that's nice to see. And ARM support may become more important in the future, since Apple is planning to switch from Intel to ARM based processors (https://www.theguardian.com/technology/2020/jun/22/apple-ditches-intel-for-arm-processors-in-big-sur-computers) in its desktop computers.

Yesterday Apple have suggested to the developers to encode everything in xHE-AAC using previous encoders only for interoperability. This means that afconvert will no longer be limited to only playing MPEG-D USAC.

https://developer.apple.com/videos/play/wwdc2020/10636/
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-26 00:30:41
Hi, I have been trying out exhale, and so far so good, but to make things easier I noticed exhale is apparently capable of taking input from stdin, so I had assumed I should be able to pipe to exhale from ffmpeg instead of having to convert everything to wav first?  Anyway below is the command (one of the ones I have tried anyway) I am trying to use:
Code: [Select]
ffmpeg.exe -i input.??? -f wav - | exhale.exe 5  "output.m4a"
Which isn't working, so my question is, is piping from ffmpeg possible or should I give up on this method?
Try to add:
Code: [Select]
-map_metadata -1 -bitexact
parameters to ffmpeg.
I just realized that exhale had a bug when reading WAVE audio from stdin that contains metadata (which exhale must skip but didn't do so properly). Please try again with the latest Git commit (https://gitlab.com/ecodis/exhale/-/commit/9393d8eb), it should now work even without specifying -map_metadata or -bitexact anymore.

Yesterday Apple have suggested to the developers to encode everything in xHE-AAC using previous encoders only for interoperability. This means that afconvert will no longer be limited to only playing MPEG-D USAC.

https://developer.apple.com/videos/play/wwdc2020/10636/
Interesting! Is this afconvert version already available?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-06-26 09:32:53
@celona Even 10.15 already supported USAC in both MPEG-4 and CAFF containers. As does iOS/iPadOS 13.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-06-26 11:47:45
And, RC4 (Intel 19 compiles):

www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc4-9393d8eb_x64.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc4-9393d8eb_x64.zip)

www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc4-9393d8eb_x86.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc4-9393d8eb_x86.zip)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: synclagz on 2020-06-26 12:36:37
I'm following this thread from beginning with great interest. :)
I made few encodes from flac with foobar2000 just to see how it goes...
I don't know is it already mentioned somewhere but one thing I noticed when scanning for ReplayGain with foobar2000, that track peak value on converted files is never above 0.98 which is a good thing (I think). Usually other lossy like vorbis/opus/mp3 end up with peak values above 1.00.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-06-26 13:38:10
@celona Even 10.15 already supported USAC in both MPEG-4 and CAFF containers. As does iOS/iPadOS 13.
Until now, only decoding was supported.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-06-26 13:49:20
Interesting! Is this afconvert version already available?
The afconvert version for Apple SoC is only available for developers who pay for the transition kit, the 64-bit version for Intel is downloadable from registered developers who pay about $ 100 a year.

In fact, afconvert has not changed, it could be the same as openDarwin, it only allows you to use codecs supported by macOS.

From July anyone can download beta versions of Apple software for free; also in other videos they suggested the use of xHE-AAC for streaming in fMP4.

https://developer.apple.com/videos/play/wwdc2020/10158/
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-06-26 15:56:43
I just like to submit an old issue that still occurs with 1.0.5 RC4 but with some improvements: corrupted or incorrect files when encoded with foobar2000 with resampling on the fly. There are some progress with 1.0.5 RC4 but problem is not fully solved.

The issue usually occurs with long files (full tracks/album) and I had hard times to find short samples sharing the same issues. But I managed to isolate three short samples (30 seconds) among hundreds for which exhale used to struggle when they have to be encoded and resampled in the same process with foobar2000 1.54. But with 1.0.5 RC4 issues are now gone with these 3 short samples (1.0.4 and 1.0.3 have this issue). Problem solved? Unfortunately not. If I encode larger albums with 1.0.5 RC4 with resampling on the fly I still get many errors:

(https://zupimages.net/up/20/26/nfc9.png) (https://zupimages.net/viewer.php?id=20/26/nfc9.png)

Files marked as M4A are corrupted ; AAC/USAC are good. I get these results with 1.0.5 RC4, SSRC resampling 32000 Hz with foobar2000 1.54.

____
Below I joined the three FLAC samples which may help to understand the issue with larger files.
Odd things: I duplicate these three samples many times with explorer and encoded all copies with exhale 1.0.4 and foobar2000/SSRC and I managed to get few valid files among a lot of corruption. In other words, bit-identical files are sometime OK and often WRONG when encoded in the same batch with foobar2000 :

(https://zupimages.net/up/20/26/sy3x.png) (https://zupimages.net/viewer.php?id=20/26/sy3x.png)
(on this picture, two files are file, all others identical copies are M4A and unreadable).

I also uploaded two encoded files from this batch (1.0.4 mode 1): one corrupted and one which is playable. Both should be identical because source files are also identical. Maybe these files may help to understand from where the differences and the issue come from.

As said, the problem is solved with 1.0.5 for short samples but still occurs with longer ones which are not so easy to share in public.

I submitted it because I tried today to encode a ISO-SACD file (DSD set to PCM 88200Hz for playback/decoding) with exhale mode 9 and while encoding seems to work the resulted files are sometimes corrupted.

N.B. Curious fact I just noticed few seconds ago: only the first track of SACD is corrupted (tested with three different SACD: issue occurs with 2 of them). And it's maybe not a coincidence, all three short samples submitted here are also the very beginning of the CD (seconds 0 to 30 from the first track). Any idea? Could the very beginning of a disc have an impact?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-06-26 22:45:31
@celona Even 10.15 already supported USAC in both MPEG-4 and CAFF containers. As does iOS/iPadOS 13.
Until now, only decoding was supported.
And even now, only decoding is supported.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-27 01:20:04
From July anyone can download beta versions of Apple software for free
Thanks for the information, let's see if afconvert will be freely accessible then as well, at least for a short time.

when scanning for ReplayGain with foobar2000, that track peak value on converted files is never above 0.98 which is a good thing (I think). Usually other lossy like vorbis/opus/mp3 end up with peak values above 1.00.
This is a feature of the xHE-AAC decoding standard and kode54's packet decoder in particular, it applies a limiter to the decoded waveforms at -0.1 dBFS.

Thanks for the report, guruboolez! Before I change exhale in a rush at the last minute before the upcoming 1.0.5 release (i just fixed the last urgent issue I'm currently aware of, a minor WAVE metadata related read-in hickup here (https://gitlab.com/ecodis/exhale/-/commit/ce3641dc)), let's try a potential fix privately first. I'll PM you.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-06-27 03:45:47
From July anyone can download beta versions of Apple software for free
Thanks for the information, let's see if afconvert will be freely accessible then as well, at least for a short time.
I don't know about whatever public beta they have planned for July, but the first Developer Beta I have now, refuses to encode xHE-AAC with afconvert. It is not a problem with the source material. It just outright refuses to accept the default settings, and I don't see any documentation of what bitrates or settings they support.

when scanning for ReplayGain with foobar2000, that track peak value on converted files is never above 0.98 which is a good thing (I think). Usually other lossy like vorbis/opus/mp3 end up with peak values above 1.00.
This is a feature of the xHE-AAC decoding standard and kode54's packet decoder in particular, it applies a limiter to the decoded waveforms at -0.1 dBFS.
Not just a feature of the encoding standard. The decoder I use literally can't output over ±1.0. Android's decoder library outputs 16 bit integer PCM. It can be configured at compile time to output 32 bit integer PCM, also with the same range limit, at the expense of also doing all the fixed point math in 32/64 bit precision instead of just 32 bit.

The only way this will ever change is if there are system codecs which don't suck.

foobar2000 for Mac has also recently added USAC support, using system codecs, so that functionality requires Catalina or newer. Apple's system codecs don't suck. Microsoft's kind of do, and they also don't support USAC yet, with no announced plans for support that I've seen anywhere.

We're limited to either system codecs or FDK-AAC. System codecs *may* support unclipped output, except on Android, and FDK-AAC anywhere else does not.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-27 10:52:02
Not just a feature of the encoding standard. The decoder I use literally can't output over ±1.0. Android's decoder library outputs 16 bit integer PCM. It can be configured at compile time to output 32 bit integer PCM, also with the same range limit, at the expense of also doing all the fixed point math in 32/64 bit precision instead of just 32 bit.
Thanks for the clarification! Would it be possible for you to, without much extra work, share such a 32-bit version of your packet decoder for me to test? exhale theoretically can encode dynamic ranges of more than 120 dB, but due to the rounding to 16 bits during decoding, it's hard for me to figure out if things work properly in very quiet signal passages during encoding. The increase in the required decoding resources wouldn't be an issue for me, your packet decoder already runs at almost 100x realtime per thread.
Quote
Apple's system codecs don't suck. Microsoft's kind of do, and they also don't support USAC yet, with no announced plans for support that I've seen anywhere.
This is an interesting point. Microsoft added FLAC decoding support a few years ago, so maybe they would be open to support xHE-AAC decoding, especially now that Apple and Google support it. There is a Feedback Hub (https://support.microsoft.com/en-us/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app) in Windows 10 which allows to search for, and add new, feature requests to "improve the Windows experience". Maybe someone has already requested it there or could do so if not?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Ohdengoh on 2020-06-27 13:42:55
I just realized that exhale had a bug when reading WAVE audio from stdin that contains metadata (which exhale must skip but didn't do so properly). Please try again with the latest Git commit (https://gitlab.com/ecodis/exhale/-/commit/9393d8eb),

I just tried piping using the RC5 binaries just posted above, and while it works now without the extra ffmpeg flags, it fails on some files now, whereas previously it worked on all files when using the ffmpeg flags.  The error message displayed says "audio too short", and I don't know if it is significant but one thing I noticed that was common between all the files that it did fail on was that it always failed after 5kb, but that may just be the chunk size it reads IDK. If it helps here is an excerpt of one of the error messages (BTW the files it fails on were all 3+ min long):

Code: [Select]
 ERROR while trying to encode input audio data! The audio stream is too short!

av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
size=       5kB time=00:00:00.07 bitrate= 497.6kbits/s speed=15.7x
video:0kB audio:9kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Conversion failed!
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-27 14:41:05
Thanks for rechecking! For clarification: does it still work on all of your tested files when specifying the additional ffmpeg flags?

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Ohdengoh on 2020-06-27 15:35:49
After further testing just now though, strangely this issue seems intermittent.

With the exact same audio file, same batch file launcher, same version of exhale, run repetitively, it fails sometimes, and works other times???  I am confused, about every approx 5th attempt with everything EXACTLY the same (input audio, ffmpeg/exhale version all matching etc), it does actually work, and I've tested both both with/without the flags same result.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-06-27 15:56:29
OK, this issue seems to be somehow related to the one guruboolez reported yesterday (https://hydrogenaud.io/index.php?topic=118888.msg984735#msg984735). I'll also contact you privately with a possible fix of which I don't know if it will fully cure the issue (that's why I don't want to change the source code at this point, without being sure).

Update: After some googling, I found that, as an alternative to Windows' _read (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/read?view=vs-2019) function which I'm currently using, there's fread (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fread?view=vs-2019) which, apparently, does the same but the documentation notes that the latter "locks out other threads". I'm new to those specifics, does anyone know if using fread (or fread_s) instead of _read would solve the stdin issues reported by guruboolez and Ohdengoh?

Edit: I found a "fix" which works for both guruboolez and Ohdengoh. I disabled buffered reading of the WAVE input by changing line 17 of source file src/app/basicWavReader.h (https://gitlab.com/ecodis/exhale/-/blob/master/src/app/basicWavReader.h) to
Code: [Select]
#define BWR_BUFFERED_READ        0 // faster reader
So if you're compiling exhale yourself and you run into problems when using exhale through foobar2000 or ffmpeg, try changing that line as well. I don't really like this change, though, since it slows down the reading unnecessarily, especially when encoding WAVE files via the command-line (instead of stdin), so I decided not to include it into the 1.0.5 release. I'll work on it some more for version 1.0.6 and hope to get a better fix done.

So that means that John's RC5 version is actually the final version 1.0.5, the "F" release. But John, please include the latest Release.htm and rename the executable to exhale.exe, since that's now the intended compiler independent naming.

On a personal note: people, I'm impressed :) Half a year after the first public release of exhale, the project is in a much more stable and compatible state than I expected at this point in time. That's mainly because many of you contributed a lot of testing and listening effort. Thanks a lot, and keep doing so in the future, please :)

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: andrew.46 on 2020-07-01 00:36:50
exhale 1.0.5 (x64) compiles and runs nicely on Linux. I dimly remember there being an issue with FFmpeg pipes so I tested the following  on a flac file:

Code: [Select]
ffmpeg -i luckynight.flac -f wav pipe:1 | exhale 5 testing.m4a

This worked without error and as well I learnt a little more about the required piping syntax for FFmpeg; always a good day when you learn something new  :D.

Now if only there was playback for these files using a native Linux application...
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Destroid on 2020-07-01 12:13:48
Now if only there was playback for these files using a native Linux application...

If I may intrude, what about fb2k mobile of xHE support because that would be nice too :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-07-01 16:33:48
Update: After some googling, I found that, as an alternative to Windows' _read (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/read?view=vs-2019) function which I'm currently using, there's fread (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fread?view=vs-2019) which, apparently, does the same but the documentation notes that the latter "locks out other threads". I'm new to those specifics, does anyone know if using fread (or fread_s) instead of _read would solve the stdin issues reported by guruboolez and Ohdengoh?
read() can result in partial read (especially when reading from network or pipe). Therefore, code like this is not good:
Code: [Select]
  if ((m_bytesRead = _READ (m_fileHandle, b, FILE_HEADER_SIZE)) != FILE_HEADER_SIZE) return false; // error
Instead of giving up, you'd have to repeat reading until all bytes are read. Practically, you have to write some wrapper function around read() to do that.
As for fread(), it does repeated read by default. So, no need to write wrapper.

And one more note: If I remember correctly, fseek(), lseek() or something doesn't return -1 on attempt to seek pipe on Windows.
Therefore, testing seekability by seeking doesn't work properly on Windows. Instead, we have to test if the file is regular file (using stat() or something).
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-07-04 03:37:40
If I may intrude, what about fb2k mobile of xHE support because that would be nice too :)
Already does, on iOS 13 and newer. No clue what magic would be needed to get that working on Android.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Destroid on 2020-07-04 05:30:26
Already does, on iOS 13 and newer. No clue what magic would be needed to get that working on Android.
Me neither, on Android 9 it can playback xHE from a generic file manager but not from the fb2kmobile app. I should get to the correct forum.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-07-05 07:09:23
This time, 32KHz is statistically better for the 30 first samples. 44.1 KHz looks stronger on problem samples which is mainly due to its lesser pre-echo.
Interesting observation. It puts previous 80 kbps test (https://hydrogenaud.io/index.php?topic=119227.0) into perspective. I'm doing some additional test at 80 kbps and 32 kHz isn't that much worse than 44.1 kHz on non-killer samples. I guess it's also matter of preference: better overall performance vs better handling of corner cases (killer samples), this one last can be quite noticeable.

It's clear from your test that 32 kHz is an optimal sampling rate for exhale@64ks. Also 80k > 64k so differences between two sampling rates (32 vs 44 kHz)  are considerably smaller.

P.S. There is another difficult sample which (I think) is similar to 'Linchpin' as exhale produces similar pattern of artifacts (smearing + pre-echo) AND doesn't increase bitrate much, hence kinda doesn't detect as a 'difficult' to encode.
Sample is attached.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-07-06 01:11:43
- exhale doesn't like WAV files above 16/48 written by ffmpeg (16/88.2, 24/44.1 or 24/88.2).
- exhale doesn't like 24-bit WAV files written by sox.
I just added basic support for mono and stereo, 24-bit and 32-bit "extensible" WAVE files in commit 92e14850 (https://gitlab.com/ecodis/exhale/-/commit/92e14850), so this should be fixed. If not, please let me know.

read() can result in partial read (especially when reading from network or pipe). ...
Instead of giving up, you'd have to repeat reading until all bytes are read. Practically, you have to write some wrapper function around read() to do that.
...
If I remember correctly, fseek(), lseek() or something doesn't return -1 on attempt to seek pipe on Windows.
Therefore, testing seekability by seeking doesn't work properly on Windows. Instead, we have to test if the file is regular file (using stat() or something).
Thanks very much for the clarification. Indeed, the seek related code didn't work on stdin, just reading input instead of seeking in it with stdin was one of the last fixes towards the 1.0.5 release.

Interesting observation. It puts previous 80 kbps test (https://hydrogenaud.io/index.php?topic=119227.0) into perspective. I'm doing some additional test at 80 kbps and 32 kHz isn't that much worse than 44.1 kHz on non-killer samples. I guess it's also matter of preference: better overall performance vs better handling of corner cases (killer samples), this one last can be quite noticeable.
...
P.S. There is another difficult sample which (I think) is similar to 'Linchpin' as exhale produces similar pattern of artifacts (smearing + pre-echo) AND doesn't increase bitrate much, hence kinda doesn't detect as a 'difficult' to encode.
Thanks! Yes, this issue will also be fixed once I find a good solution for the Linchpin issue.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-07-06 04:14:23
Exhale uses a variant of PNS  as sort of  replacement to SBR at low bitrates.
So I've tested it at 64 kbps

Files (https://drive.google.com/file/d/1ItlY_gnzYaOflWJ-yGRJM2yS_XVDCSCk/view?usp=sharing)


(https://i.ibb.co/Cts8qGk/Results.png)

Thanks! Yes, this issue will also be fixed once I find a good solution for the Linchpin issue.
Great. Thank you too. So I count on it. No pressure  :D

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-07-06 09:56:09
version of opus used? 1.3, 1.3.1 or libopus latest to now 2020-06-28?
1.3 sounds the best to me even if it has difficulty at encoding the details.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-07-06 12:03:08
Exhale w/PNS performs on par with HE-AAC encoders at 64 kbps

[This time  samples weren't killers but selected from different albums/different musical genres from my extensive collection.I've stopped at 12 samples as results have converged very quickly

Highly interesting! Thank you for this test :)
It's very intersting to see (again) USAC competitive with SBR-AAC without using SBR. SBRed-USAC can be listened on webradios here (https://hydrogenaud.io/index.php?topic=119374.0). I guess SBR is enabled because sound has typical SBR artifacts.

The comparison between three HE-AAC encoders is also precious. Good overall performance of FDK-AAC. On my side with classical music (full albums) FHG-AAC (Winamp's encoder) reaches 59 kbps on average and FDK-AAC 69 kbps with both VBR mode 2. The latter benefits from a bitrate boost which may explain the superiority. Anyway it's good to see that FDK is similar if not better than FHG :)
Using Apple's encoder even if it's not TVBR seems to be the best solution for testing HE-AAC at the best level.

On this test Opus is also not significantly better than HE-AAC at 64 kbps, which is also interesting to note.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-07-06 12:52:33
Using Apple's encoder even if it's not TVBR seems to be the best solution for testing HE-AAC at the best level.
On this test Opus is also not significantly better than HE-AAC at 64 kbps, which is also interesting to note.

I believe that Opus is better than the Apple HE-AAC encoder because it worsens at lower bitrates, but at the same time I am convinced that these comparisons don't make sense anymore, Apple's best encoder at these bitrates is definitely ELD-AAC v1 or v2 (aacf or aacg), despite use LD-SBR.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-07-06 13:06:32
I believe that Opus is better than the Apple HE-AAC encoder because it worsens at lower bitrates, but at the same time I am convinced that these comparisons don't make sense anymore, Apple's best encoder at these bitrates is definitely ELD-AAC v1 or v2 (aacf or aacg), despite use LD-SBR.
I'm not sure to understand. Every encoder is getting worse at lower bitrate so I don't understand what you mean.

I must say that I don't know ELD-AAC. Is the format compatible with common AAC profile (LC-AAC, HE-AAC)? Using HE-AAC as competitor makes a lot of sense to me because the format is widely supported. Are there tests available?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-07-06 14:31:55
I must say that I don't know ELD-AAC. Is the format compatible with common AAC profile (LC-AAC, HE-AAC)? Using HE-AAC as competitor makes a lot of sense to me because the format is widely supported. Are there tests available?

The decoder for xHE-AAC also decodes the previous formats and the Apple ELD-AAC encoder is present in all versions of MacOS after 10.7 (Lion) which can only decode it. I am also curious to know your opinion, send me the tracks to compress so you can evaluate them yourself. I also use AAC in general because today you can't transcode a file for each destination and you can't distribute formats that for 20% of your users don't work right away.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-07-06 15:00:00
ELD-AAC where ELD stands for enhanced low delay. ELD-AAC is a low delay version of HE-AAC. 
As ELD-AAC  is low delay codec (32ms)  and  it doesn't reach quality of HE-AAC wich has no delay constraints (100-200ms).
ELD v2 is ELDv1 + low delay PS so it's still less efficient than HE-AACv2.

ELDv1/v2 is for real time applications which require low delay. It's main task is low delay, so it means that quality is a second priority hence it's not as good as HE-AACv1/v2.


@celona
Please use google  and get your facts right next  time before saying  that someone's labour is useless, alright?
ELD-AAC is clearly inferior comparing to HE-AAC. Here is an information https://www.iis.fraunhofer.de/content/dam/iis/de/doc/ame/conference/AES-125-Convention_AAC-ELD-NewStandardForHighQualityCommunication_AES7503.pdf

version of opus used? 1.3, 1.3.1 or libopus latest to now 2020-06-28?
It was latest and greatest 1.3.1
Regarding new builds,  libopus 1.3 (Oct 18, 2018) was the last build which contained improvements of audio quality. No more quality improvements since 2018, capisce? https://github.com/xiph/opus/commits/master
All newer builds contain fixes, new features related to  programme itself but  there are no audio quality enhancements for the way  which most of us use the codec.


Highly interesting! Thank you for this test :)
The comparison between three HE-AAC encoders is also precious. Good overall performance of FDK-AAC. On my side with classical music (full albums) FHG-AAC (Winamp's encoder) reaches 59 kbps on average and FDK-AAC 69 kbps with both VBR mode 2. The latter benefits from a bitrate boost which may explain the superiority. Anyway it's good to see that FDK is similar if not better than FHG :)
Using Apple's encoder even if it's not TVBR seems to be the best solution for testing HE-AAC at the best level.
I see. Well, FDK produces way higher bitrate than target 64 kbps.   Aslo Apple CVBR is kindy tricky to test. I don't know if You remeber we have seen and You have posted about it too that Apple CVBR produces higher bitrate during first 5 seconds and then  in order to keep bitrate  it can go deep down (eig is a good sample to see how quality/bitrate varies drastically ). I was careful enough to test the whole samples.  On the other hand, exhale hits target bitrate without issues and doesn't do tricks behind. So it's a good achivement for exhale to be on par with HE-AAC encoders with such bitrate behavior.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-07-06 15:44:41
Talking about opus, Libopus 1.3 is still the best sounding and more stable, less generation loss in my opinion for example at 169 kbps. Even 1.3.1 is good enough. But I don't know what YT use. Opus still can have improvements in the 71 kbps or 116 kbps range.
The FFmpeg Zeranoe build is a bit slow (about 1 minute) even if is newer. For comparison Opus 1.3.1-41 takes 25 seconds for 48 minutes of music with 2 threads.
But don't know if they were speed optimizations after 1.3..
64 kbps is very low, if you want 86 kbps peaks for example.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-07-06 16:02:53
eig fatboy is a good sample to see how quality/bitrate varies drastically ). I was careful enough to test the whole samples.  On the other hand, exhale hits target bitrate without issues and doesn't do tricks behind. So it's a good achivement for exhale to be on par with HE-AAC encoders with such bitrate behavior.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-07-06 17:17:17
I am also curious to know your opinion, send me the tracks to compress so you can evaluate them yourself.

If you want you can send me the tracks in use for my latest tests:
https://www.dropbox.com/sh/zjephy3g54j4gur/AACjGhM9tabl26n7s4ihYl2Ra?dl=0
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-07-06 17:34:36
I see. Well, FDK produces way higher bitrate than target 64 kbps.   Aslo Apple CVBR is kindy tricky to test. I don't know if You remeber we have seen and You have posted about it too that Apple CVBR produces higher bitrate during first 5 seconds and then  in order to keep bitrate  it can go deep down (eig is a good sample to see how quality/bitrate varies drastically ). I was careful enough to test the whole samples. 
FDK is a bit higher than 64 kbps, and FHG is a bit lower. Comparing each against any 64 kbps contender is not a problem in my opinion; but comparing each other may be more questionable.

Quote
On the other hand, exhale hits target bitrate without issues and doesn't do tricks behind. So it's a good achivement for exhale to be on par with HE-AAC encoders with such bitrate behavior.
It's exactly my point. SBR has a positive effect on overall quality when bitrate starvation occurs; but SBR also lead to artefacts on its own. So keeping a similar quality without SBR is a very good thing. OPUS has a different encoding technique than SBR which also bring serious issues. It was very clear by testing classical music but sound quality but much less with louder music.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-07-06 18:04:07
OPUS has a different encoding technique than SBR which also bring serious issues. It was very clear by testing classical music but sound quality but much less with louder music.
Opus has 'band folding' which is similar SBR but it's not a cause of low performance on classic music.  If that was a case then 'band folding' would perform bad  on your set of 25 smaples of popular music.

It's low-overlap design to keep low-delay.  Pretty every low delay format suffers from lower frequency resolution (those harsh artifacts)

Sorry, we're  offtopic here.  Next time I'll open a new topic for my personal tests.
Let's back to exhale

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-07-06 21:30:23
Hello,

I just added basic support for mono and stereo, 24-bit and 32-bit "extensible" WAVE files in commit 92e14850 (https://gitlab.com/ecodis/exhale/-/commit/92e14850), so this should be fixed. If not, please let me know.

Just have tested it with previous problematic files and some on-the-fly FLAC to WAV conversions with ffmpeg (without additional metadata-related parameters) piped in exhale: all went Ok. Thanks!  :)

    AiZ
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-07-10 01:12:55
exhale v1.0.5-92e14850
GCC 10.1.0 / Clang 10.0.0.2
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Anakunda on 2020-07-12 07:09:50
Thx @NetRanger, can you explain what's the difference between GCC and Clang build?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-07-12 08:26:01
Literally only the compiler used to build the encoder, it would seem.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-07-12 10:35:13
Intel compiles exhaleApp-v.1.0.5-92e14850:

www.rarewares.org/files/aac/exhaleApp-v.1.0.5-92e14850_x64.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.5-92e14850_x64.zip)

www.rarewares.org/files/aac/exhaleApp-v.1.0.5-92e14850_x86.zip (http://www.rarewares.org/files/aac/exhaleApp-v.1.0.5-92e14850_x86.zip)

I have removed all the previous builds, so the links to the older versions above will no longer work. If anyone needs an older version I can make it available.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-07-12 14:42:12
Thx @NetRanger, can you explain what's the difference between GCC and Clang build?

Different compilers. Was asked by a friend if i could make a Clang compilation and i made it available here also
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-07-13 03:00:02
fyi, I just integrated some enhancements and fixes (https://gitlab.com/ecodis/exhale/-/commit/be52276f) to exhale's built-in resampler. Input sampled at 48 kHz is now automatically downsampled to 32 kHz when using CVBR mode 1, the interpolation filter for the automatic 2x upsampling of 22.05 and 24 kHz audio was improved very slightly, and some rare cases where the decoded xHE-AAC audio was a few milliseconds shorter than the original input audio have been fixed. There was also a very minor change in bit allocation for 48-kHz audio with CVBR modes 2 and 3. If you're encoding only 44.1-kHz audio or are resampling externally through, e.g., foobar2000, you don't need to worry about any of this.

By the way, to avoid possible misunderstandings about release dates, please consult https://gitlab.com/ecodis/exhale/-/releases. Only the Git revisions mentioned on that page are thoroughly tested.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-07-13 12:56:50
Intel compiles exhale-v.1.0.5-be52276f:

www.rarewares.org/files/aac/exhale-v.1.0.5-be52276f_x64.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.5-be52276f_x64.zip)

www.rarewares.org/files/aac/exhale-v.1.0.5-be52276f_x86.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.5-be52276f_x86.zip)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-07-13 13:59:14
[...] But John, please [...] rename the executable to exhale.exe, since that's now the intended compiler independent naming [...]
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-07-13 14:07:08
[...] But John, please [...] rename the executable to exhale.exe, since that's now the intended compiler independent naming [...]
Thanks!! ;) I had forgotten that. Duly amended compiles on the same links as above. :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-07-16 02:00:10
Thanks, John and m14u! I made some minor adjustments (https://gitlab.com/ecodis/exhale/-/commit/86ba7b8a) to exhale's psychoacoustic model today, which causes the average bit-rates of the lower CVBR modes to increase by 1 or 2 kbit/s (at least on my test set). If it increases by more than that on anyone's music collections, please let me know.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-07-16 07:43:13
Intel 19 compiles exhale-v.1.0.6b-86ba7b8a:

www.rarewares.org/files/aac/exhale-v.1.0.6b-86ba7b8a_x64.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.6b-86ba7b8a_x64.zip)

www.rarewares.org/files/aac/exhale-v.1.0.6b-86ba7b8a_x86.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.6b-86ba7b8a_x86.zip)

:)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-07-16 09:20:18
Intel 19 compiles exhale-v.1.0.5-86ba7b8a:
:)

Hi John

Looks like commit 86ba7b8a is v1.0.6 Beta
https://gitlab.com/ecodis/exhale/-/commit/86ba7b8af61fe4dcdab6aa96b7affb57998a9a07
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-07-16 09:40:49
Intel 19 compiles exhale-v.1.0.5-86ba7b8a:
:)

Hi John

Looks like commit 86ba7b8a is v1.0.6 Beta
https://gitlab.com/ecodis/exhale/-/commit/86ba7b8af61fe4dcdab6aa96b7affb57998a9a07
Ah, OK, thanks. Just about to go out so I'll deal with it later. ;)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-07-16 09:57:49
exhale v1.0.6b-86ba7b8a
Built on July 16, 2020, GCC 10.1.0
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-07-16 14:09:47
Thanks, John and m14u! I made some minor adjustments (https://gitlab.com/ecodis/exhale/-/commit/86ba7b8a) to exhale's psychoacoustic model today, which causes the average bit-rates of the lower CVBR modes to increase by 1 or 2 kbit/s (at least on my test set). If it increases by more than that on anyone's music collections, please let me know.

Chris

Compared with 91 CD (classical music only) between 1.05 and v1.0.6 Beta 86ba7b8a mode 1:
— bitrate varies from -1 kbps and +2 kbps (bitrate is 1 kbps lower on the four low volume/low bitrate/quiet piano albums and only these discs).
— 64 kbps on average with 1.0.5 mode 1 (44 Khz) and 66 kbps with 1.0.6 beta

I'll also try with mode #5
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-07-16 19:53:33
mode 5:
— 1.0.5 = 130 kbps (5.55 GB for 4d 5:12:53.333)
— 1.0.6b = 129 kbps (5.53 GB)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-07-19 02:54:10
Yes, this issue will also be fixed once I find a good solution for the Linchpin issue.
1.0.6b1 has fixed Linchpin sample at 96 kbps. 

— 64 kbps on average with 1.0.5 mode 1 (44 Khz) and 66 kbps with 1.0.6 beta
Same here but with mode 2.   81 kbps -  1.0.5, 83 kbps - 1.0.6b1.
exhale 1.0.6b1 still produces pretty comparable bitrates  with other popular encoders like Apple AAC and Opus.  Looks good to me.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-07-20 01:00:37
Great, thanks very much!

bitrate is 1 kbps lower on the four low volume/low bitrate/quiet piano albums and only these discs
This actually wasn't intended. I'll try to find out the reason. Anyway, it doesn't seem to cause any problems.

Edit (July 25): I just committed (https://gitlab.com/ecodis/exhale/-/commit/f8ad0b3) the last changes for the exhale 1.0.6 release, so we have a release candidate now. I managed to get the average bit-rates back to the level of the 1.0.5 release and also fixed some more rarely occurring bugs (thanks to Igor for reporting one of them!).

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-07-26 01:45:27
Great, Chris
Hopefully there is still time to test 1.0.6 RC before a final release.

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-07-26 08:39:16
Intel compiles of exhale-v.1.0.6rc1-f8ad0b34:

www.rarewares.org/files/aac/exhale-v.1.0.6rc1-f8ad0b34_x64.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.6rc1-f8ad0b34_x64.zip)

www.rarewares.org/files/aac/exhale-v.1.0.6rc1-f8ad0b34_x86.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.6rc1-f8ad0b34_x86.zip)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-07-26 15:11:49
Hi! Do any app support USAC decoding in Android. I have android 5.0
like foobar2000 and Vlc, exoplayer?
Does fraunhofer or c.r heinrich have plans?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-07-26 18:20:26
it's a plane... it's a bird... NO! it is a ->c.r heinrich<- !!!  :P
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-07-26 21:12:50
Sorry if I mispelled the name. but I want to know if there is a chance to have more widely decoding support.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-07-27 01:25:46
The decoders depend on the following:

Windows: Must either use FDK-AAC's decoder, or hold out for Microsoft to bundle a system decoder and implement support for it, and if the latter, you're probably stuck with Windows 10.
- foobar2000 uses FDK-AAC, if you install my decoder plugin

macOS: You must either use FDK-AAC's decoder, or use the system AAC or Core Audio library, and then you're stuck requiring Catalina or newer.
- Cog uses the system codec
- foobar2000 for macOS uses the system codec

Linux: You must use FDK-AAC's decoder, until such time as FFmpeg finally implements a decoder, but I wouldn't hold out, the priority for this request is "Wish", which is the lowest priority a request can have.
- foobar2000 in Wine, with my plugin, is about all you'll get
- DeaDBeeF was supposed to implement something like this, but it's been years since it was allegedly started, and nothing is done yet

iOS: Best using the system libraries, which require iOS 13 or newer.
- foobar2000 supports this
- The system Music app should support files as well
- Other apps which use the system codecs should also work

Android: System supports this as of, 9? I think. FDK-AAC actually originates from the Android system source code.
- foobar2000 for Android doesn't yet support this, I don't think? Maybe wait patiently for this one to get dealt with.
- Other Android players which use the system codecs should support this.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-07-27 08:27:46
Thanks.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: 2012 on 2020-07-27 11:56:25
Linux: You must use FDK-AAC's decoder, until such time as FFmpeg finally implements a decoder, but I wouldn't hold out, the priority for this request is "Wish", which is the lowest priority a request can have.

Code: [Select]
% mpv --ad=help | rg aac
aac - AAC (Advanced Audio Coding)
aac_fixed (aac) - AAC (Advanced Audio Coding)
aac_latm - AAC LATM (Advanced Audio Coding LATM syntax)
libfdk_aac (aac) - Fraunhofer FDK AAC

And yes, it works.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-07-27 12:36:48
mint 20
mpv 0.32.0 Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
ffmpeg library versions:
   libavutil       56.31.100
   libavcodec      58.54.100
   libavformat     58.29.100
   libswscale      5.5.100
   libavfilter     7.57.100
   libswresample   3.5.100
ffmpeg version: 4.2.4-1ubuntu0.1
without "libfdk_aac (aac) - Fraunhofer FDK AAC"
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: 2012 on 2020-07-27 23:02:49
@m14u It has to be enabled in ffmpeg/libav at build time.

Code: [Select]
% ffmpeg -decoders 2>/dev/null | rg fdk
A....D libfdk_aac           Fraunhofer FDK AAC (codec aac)

ffplay/ffmpeg work too of course. But the decoder must be set explicitly by passing -codec:a libfdk_aac (before -i in the case of ffmpeg to apply it to input).

mpv just works because it falls-through from one decoder to another.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-07-28 01:04:51
[...]It has to be enabled in [...] at build time. [...]
not interesting for a millions...
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: 2012 on 2020-07-28 08:20:17
@m14u It's one --enable-libfdk-aac away from being supported is the point. No native ffmpeg decoder strictly needed. And the glue code to use libfdk as a decoder was already written.

Ubuntu not enabling support in ffmpeg despite libfdk being already available in their repositories is their problem. And it's an easily fixable one.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-07-28 08:35:22
Ubuntu not enabling support in ffmpeg despite libfdk being already available in their repositories is their problem. And it's an easily fixable one.
No, it's not.
ffmpeg requires --enable-nonfree for --enable-libfdk-aac, which means that fdk-aac enabled ffmpeg binary is not redistributable.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: 2012 on 2020-07-28 09:16:30
ffmpeg requires --enable-nonfree for --enable-libfdk-aac, which means that fdk-aac enabled ffmpeg binary is not redistributable.

ugh, fair enough.

Code: [Select]
EXTERNAL_LIBRARY_NONFREE_LIST="
decklink
libfdk_aac
openssl
libtls
"

I remember the list of libraries being larger (and Arch not caring). But things have changed/improved apparently. I may try to convince Arch to not care again.

As for Mint, deb-multimedia has it enabled (http://deb-multimedia.org/dists/unstable/main/binary-amd64/package/libavcodec58.php). Or maybe some ppa can be used if deb-multimedia is not compatible with Ubuntu/Mint.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-07-28 09:22:03
Intel compiles of exhale-v.1.0.6rc2-c7299609:

www.rarewares.org/files/aac/exhale-v.1.0.6rc2-c7299609_x64.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.6rc2-c7299609_x64.zip)

www.rarewares.org/files/aac/exhale-v.1.0.6rc2-c7299609_x86.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.6rc2-c7299609_x86.zip)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-07-29 03:56:01
ffmpeg requires --enable-nonfree for --enable-libfdk-aac, which means that fdk-aac enabled ffmpeg binary is not redistributable.

Same goes for Arch Linux, which distributes fdk-aac by itself, but does not distribute non-free FFmpeg. You have to do something like build the ABS package modified to enable it, or build the FFmpeg-everything package from AUR, which enables bloody everything, including installing the >1.5GB CUDA package to enable CUDA support.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: LithosZA on 2020-07-29 07:06:25
How difficult will it be to create a built-in decoder for ffmpeg?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-07-30 12:00:56
exhale version 1.0.6 (identical to John's RC2 above) has been released today, see https://gitlab.com/ecodis/exhale/-/releases
Compared with RC1, this version fixed two more rarely occurring bugs. Thanks to guruboolez for reporting one of them and to m14u for testing.

Changes since exhale 1.0.5 from last month:
- bugfixes, improved quality on some transient signals, better decoder compatibility
- exhaleApp: support for Extensible WAVE format, write MP4 «prol» data (issue #10 (https://gitlab.com/ecodis/exhale/-/issues/10))
- exhaleApp: automatic downsampling of 48-kHz input to 32 kHz for CVBR mode 1
- exhaleLib: fine-tuning of psychoacoustic model for difficult transient input signals

@kode54, Peter: What do you think about this? https://gitlab.com/ecodis/exhale/-/issues/12

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-07-30 12:45:46
Intel compiles of exhale-v.1.0.6-c7299609 now at Rarewares. :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-07-30 16:05:48
https://gitlab.com/ecodis/exhale/-/issues/10 was an interesting read.

So, if I understand correctly, USAC decoder is only able to start decoding from an independent AU where usacIndependencyFlag is set, and current default of exhale lib is once per 45 frames (but it can be arbitrary), right?

Is that mean, USAC decoder has to seek back (preroll) unpredictable number of frames on seek in order to find an independent AU where it can start decoding without the help of preroll sample group added by the patch?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-07-30 19:20:34
So, if I understand correctly, USAC decoder is only able to start decoding from an independent AU where usacIndependencyFlag is set, and current default of exhale lib is once per 45 frames (but it can be arbitrary), right?
All correct. As a rule of thumb, there should be a tune-in point every second or so and, if possible, it should be synchronized with any video tune-in frames which may accompany the audio stream. With 50-Hz video, you usually have random-access points every 48 frames, and with an audio sampling rate of 48000 Hz this gives you a preferred period of (48 * 48000) / (50 * 1024) = 45 audio access units (AUs). For 60-Hz video (random-access point every 64 frames) it would be 50 AUs.

Quote
Is that mean, USAC decoder has to seek back (preroll) unpredictable number of frames on seek in order to find an independent AU where it can start decoding without the help of preroll sample group added by the patch?
If I understand the author of that issue correctly, no, but something similarly bad: the decoder would have to search through all AUs before or at the current seek point (start offsets of each AU are stored in the MPEG-4 file header, so that's still quite cheap) and find the closest one which is independently decodable (which may not be cheap!). The solution was to add another box to the MPEG-4 file header containing the period between successive tune-in AUs, allowing the decoder to simply pick out the independently decodable AU closest in time to the current seek point.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-07-30 19:33:53
exhale v1.0.6-c7299609
Built on July 29, 2020, GCC 10.2.0
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-07-31 01:19:09
If I understand the author of that issue correctly, no, but something similarly bad: the decoder would have to search through all AUs before or at the current seek point (start offsets of each AU are stored in the MPEG-4 file header, so that's still quite cheap) and find the closest one which is independently decodable (which may not be cheap!). The solution was to add another box to the MPEG-4 file header containing the period between successive tune-in AUs, allowing the decoder to simply pick out the independently decodable AU closest in time to the current seek point.
Thanks for clearing this up.
For me it looks like conceptually similar to key frames of video, and I wonder if it's also possible to simply use good old Sync Sample Box (stss) to indicate them.

I'm also curious how fb2k decoder plugin implements the seek.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-07-31 03:40:11
foobar2000 packet decoders implement seek for their callers by reporting the maximum dependency in floating point seconds, and in frame counts. The frontend, be it MP4, ADTS, ADIF, Matroska/WebM, etc, will seek backwards by this amount, ask the decoder to start decoding, then discard the dependency time from the start of the samples. Not terribly flexible, and definitely doesn't support keyframes to my knowledge.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-07-31 04:37:59
foobar2000 packet decoders implement seek for their callers by reporting the maximum dependency in floating point seconds, and in frame counts. The frontend, be it MP4, ADTS, ADIF, Matroska/WebM, etc, will seek backwards by this amount, ask the decoder to start decoding, then discard the dependency time from the start of the samples. Not terribly flexible, and definitely doesn't support keyframes to my knowledge.
Yeah, it should have been enough for traditional audio codecs. For proper USAC support (seek/cut edit), more works on container level seem to be required.

Strictly speaking, SBR/PS decoder also cannot start decoding without seeing SBR/PS header which comes only occasionally (somewhat similar to the situation of USAC indep flag), but in AAC case, LC part can be decoded anyway, so I believe this has been neglected.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-08-02 21:21:39
For me it looks like conceptually similar to key frames of video, and I wonder if it's also possible to simply use good old Sync Sample Box (stss) to indicate them.
Yes, those are basically key frames. Don't know about the 'stss' part, the only use of that box that I know of (the one used by the exhale application) is to signal to the decoder, by means of entryCount = 0, that not every sample is a sync sample.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-08-03 00:20:28
So wait, we basically have to just feed every packet to the decoder and hope it outputs something, or else just expand our search to double the number of packets and keep searching for keyframes?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-08-03 01:52:13
Yes, those are basically key frames. Don't know about the 'stss' part, the only use of that box that I know of (the one used by the exhale application) is to signal to the decoder, by means of entryCount = 0, that not every sample is a sync sample.
stss(SyncSampleBox) is a box defined by ISOBMFF. It contains a list of every "sync sample" (= key frame) for a track.
It's quite common for video tracks and I believe it's also suitable for indicating independent frames of usac... but I'm not perfectly sure.

Formally, "key frame" or "random access point" is defined as "Stream Access Point" in Annex I of ISO/IEC 14496-12.
They define six types of stream access point. Two simplest case of stream access point are considered as random access point and  can be indicated by SyncSampleBox.
Apparently these types are considered video codecs in mind (Closed GOP, Open GOP, gradual decoding refresh or something) but it's not restricted for video.



Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-08-03 04:24:21
According to this doc, A/342 Part 3: MPEG-H System seems to use stss to signal random access points: https://www.atsc.org/wp-content/uploads/2017/03/A342-3-2017-MPEG-H-System-2.pdf (5.2.2.2 Random Access Point and Stream Access Point).
So, I believe USAC can/should do the same.

Quote
5.2.2.2 Random Access Point and Stream Access Point

A File Format sample containing a Random Access Point (RAP), i.e., a RAP into an MPEG-H
Audio Stream, is a “sync sample” in the ISOBMFF and shall consist of the following MHAS
packets, in the following order:
• PACTYP_MPEGH3DACFG
• PACTYP_AUDIOSCENEINFO (if Audio Scene Information is present)
• PACTYP_BUFFERINFO
• PACTYP_MPEGH3DAFRAME
Note that additional MHAS packets may be present between the MHAS packets listed above
or after the MHAS packet PACTYP_MPEGH3DAFRAME, with one exception: when present, the
PACTYP_AUDIOSCENEINFO packet shall directly follow the PACTYP_MPEGH3DACFG
packet, as defined in ISO/IEC 23008-3 Amendment 3 [4] Clause 14.4.
Additionally, the following constraints shall apply for sync samples:
• The audio data encapsulated in the MHAS packet PACTYP_MPEGH3DAFRAME shall
follow the rules for random access points as defined in ISO/IEC 23008-3, Clause 5.7 [2].
• All rules defined in ISO/IEC 23008-3 Amendment 2, Clause 20.6.1 [3] regarding sync
samples shall apply.
• The first sample of an ISOBMFF file shall be a RAP. In cases of fragmented ISOBMFF
files, the first sample of each Fragment shall be a RAP.
• In case of non-fragmented ISOBMFF files, a RAP shall be signaled by means of the File
Format sync sample box “stss,” as defined in ISO/IEC 23008-3 Amendment 2, Clause 20.2
[3].
• In case of fragmented ISOBMFF files, the sample flags in the Track Run Box ('trun') are
used to describe the sync samples. The “sample_is_non_sync_sample” flag SHALL be set
to “0” for a RAP; it shall be set to “1” for all other samples.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-08-03 04:46:02
The problem is, I gave this encoder to Peter, and some test files, and he cannot find any STSS boxes in any of them.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-08-04 00:01:22
• In case of non-fragmented ISOBMFF files, a RAP shall be signaled by means of the File
Format sync sample box “stss,” as defined in ISO/IEC 23008-3 Amendment 2, Clause 20.2
[3].
Is that really necessary? I'm writing chunk information ('stsc' and 'stco' boxes), with each chunk starting with an independently decodable frame and a length up to the next independently decodable frame. I thought this is sufficient.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-08-04 01:51:07
Is that really necessary? I'm writing chunk information ('stsc' and 'stco' boxes), with each chunk starting with an independently decodable frame and a length up to the next independently decodable frame. I thought this is sufficient.

Oh, I see.. so, exhale expects decoders to always preroll from the beginning of the chunk where the target sample is located?
I understood your intention, and it should be indeed possible, but I'm afraid no decoders do seek in such a way, and also it's kind of fragile.
I mean, when mp4 file is re-multiplexed, chunking / interleaving is done in whatever interval they like.
It may be per-sample (costly, big overhead) or may be 1sec or so. In other words, original chunk interval/boundaries are not expected to be preserved.

The very basic procedure to seek is written in ISO IEC 14496-12 Annex A.7 Random Access.
Using stts (and optionally, stss), the target sample number is already determined.
Knowing which sample to retrieve, decoder will fetch sample directly using stco/stsc.
stco/stsc is considered to be lowest level of structure for media storage. So it's not usually be exposed by mp4 demuxing library, but your implementation will require it known by the decoder.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-08-04 16:01:58
OK, thanks for the info. After reading my own https://gitlab.com/ecodis/exhale/-/issues/1,
I think I understand this now. The Fraunhofer whitepaper on xHE-AAC says:
Quote
All IPFs {which are frame types that exhale doesn't write yet} are signaled by means of the SyncSampleBox.
{...}
In addition to the rather expensive IPFs, all AUs that have the usacIndependencyFlag set to 1 can be used to enable random access, e.g. for seeking operations. While these Independency Frames (IF) can be used to start decoding, a full audio signal is guaranteed only after decoding a certain number of AUs. This is referred to as roll distance in file format terms and can be signaled using the AudioPreRollEntry and the AudioSampleGroupEntry, respectively.
So I could write a proper 'stss' box with entries 1, 1 + independency period, 1 + 2 * independency period, ...
However, John Calhoun, the reporter of issue #10, commented on July 4:
Quote
I've been testing the serialized 'csgp' atom for interoperability with Apple's current macOS developer preview, which is capable of parsing these atoms and of decoding xHE-AAC audio, by creating relatively lengthy encodings and seeking to a random access point near the end. Playback can proceed with little delay only if Apple's implementation has located an independently decodable frame near the point of resumption after a seek. Without 'csgp', a considerable amount of time is required to decode from the start before playback can resume.
It's also possible for me to use tools built upon Apple's APIs to convert exhale-produced .mp4 files to Apple-produced .mp4 files, which will contain the same information that the 'csgp' atom contains in the form of an 'sbgp' atom. These will accurately reflect the same random access interval.
So it seems that at least the Apple decoder is already happy with the current exhale bitstreams.

Oh, I see.. so, exhale expects decoders to always preroll from the beginning of the chunk where the target sample is located?
Well, my intention was not to expect this behavior from all decoders, I thought decoders do it this way anyway. But yes, in combination with the new 'sgpd'/'csgp' code from issue #10, that was the idea. But I understand now that chunks are actually intended for something else.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-08-04 16:58:33
Chris, I've just created a patch to write stss.

Without stss, seek on ffmpeg based player behaved pretty badly (I've tried ffplay and mpv, built with --enable-libfdk-aac).
This is some expected result.

With stts, it was good. I mean, ffmpeg already knows how to handle stss, and things work without any modification on ffmpeg side.
I believe this is the way to go.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-08-05 00:16:50
Thanks very much! OK, you convinced me, I was hoping I could avoid those extra bytes in the MPEG-4 header, but it seems I can't. I had already started writing my own fix, which is slightly more compact in terms of code changes (no need for changes in the header file). Please check out commit 051900fe (https://gitlab.com/ecodis/exhale/-/commit/051900fe) and let me know if this fixes the playback issue with ffmpeg/FDK based decoders as well. The old behavior, which has been fixed to identify at least the very first AU in each file as being an IF, can be reactivated by defining NO_FIX_FOR_ISSUE_13 in the exhale application.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-08-05 12:15:20
Intel compiles of exhale-v.1.0.7-051900fe:

www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x64.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x64.zip)

www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x86.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x86.zip)

I have elected to name these as 1.0.7 but I'm sure I'll be told if that is incorrect!! ;)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-08-05 15:00:35
exhale v1.0.6-051900fe
Built on August 05, 2020, GCC 10.2.0
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-08-05 16:20:38
Please check out commit 051900fe (https://gitlab.com/ecodis/exhale/-/commit/051900fe) and let me know if this fixes the playback issue with ffmpeg/FDK based decoders as well.
051900fe is OK. seek is working on ffmpeg+FDK-AAC combo.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: ani_Jackal3 on 2020-08-05 17:01:03
Wanna try this but I'm confused on what the Foobar encoder settings are?.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: jaybeee on 2020-08-05 19:35:22
Wanna try this but I'm confused on what the Foobar encoder settings are?.
(https://snipboard.io/2LU4X8.jpg)

You can use 1 to 9
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: jarsonic on 2020-08-05 19:36:23
Wanna try this but I'm confused on what the Foobar encoder settings are?.

Something like this.

Also, for reference:

CBR mode 1 = ~64 kbps (stereo)
CBR mode 2 = ~80 kbps (stereo)
CBR mode 3 = ~96 kbps (stereo)
CBR mode 4 = ~112 kbps (stereo)
CBR mode 5 = ~128 kbps (stereo)
CBR mode 6 = ~144 kbps (stereo)
CBR mode 7 = ~160 kbps (stereo)
CBR mode 8 = ~176 kbps (stereo)
CBR mode 9 = ~192 kbps (stereo)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-08-05 19:37:35
Wanna try this but I'm confused on what the Foobar encoder settings are?.

https://gitlab.com/ecodis/exhale#usage
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: ani_Jackal3 on 2020-08-05 22:45:02
Thanks.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-08-09 19:41:49
exhale version 1.0.6 ...

Changes since exhale 1.0.5 from last month:
- bugfixes, improved quality on some transient signals, better decoder compatibility
- exhaleApp: support for Extensible WAVE format, write MP4 «prol» data (issue #10 (https://gitlab.com/ecodis/exhale/-/issues/10))
- exhaleApp: automatic downsampling of 48-kHz input to 32 kHz for CVBR mode 1
- exhaleLib: fine-tuning of psychoacoustic model for difficult transient input signals

I thought it was important to mention that starting from 1.0.6. release for the first time exhale outperforms every LC-AAC encoder at 80-96 kbps (and higher).

Also despite exhale having CVBR bitrate control now 1.0.6 performs on par with Opus with unconstrained VBR at those rates. Means that now You get a same quality and more predictable bitrate/filesize with exhale.

Great work.

Intel compiles of exhale-v.1.0.7-051900fe:

www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x64.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x64.zip)

www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x86.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x86.zip)

I have elected to name these as 1.0.7 but I'm sure I'll be told if that is incorrect!! ;)
I think 1.0.7 is correct as it's a first alpha after the last 1.0.6 stable release.
BTW thank you for builds.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: tousealypo on 2020-08-10 02:57:37
Are there any other xHE-AAC encoders to compare with? I've heard of the StreamS Live Encoder which appears to be the industry-standard according to Wikipedia (https://en.wikipedia.org/wiki/High-Efficiency_Advanced_Audio_Coding#Encoding), but it isn't marketed to or priced for home users.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-08-10 03:51:15
And Apple claims to support xHE-AAC in their systems, starting with Catalina, and recommend programming to involve it in your workflow. But... they don't provide an encoder. Only a decoder.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: yarrix on 2020-08-14 20:07:47
Greetings from the lurking darkness,

Signed up just to post this question, any help by the esteemed experts here would be awesome!

Are we able to use exhale for streaming to stdout? Like with a shoutcast/icecast server being driven by Breakaway's encoding section via custom encoders? It's possible to do so with the other aac+ command line encoders (ie: qaac, fdkaacenc, fhgaacenc, and even the older enc_aacplus) , i just couldn't find any switches to indicate stdout for the output (ie: '-').

Much thanks for the great codec work goes to Mr. Helmrich!  :-D

-Y

 
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: rogeriol on 2020-08-15 01:17:17
Hi all,

For some time I was looking for an xhe encoder in order to try very low bitrate for some audio books (tried 16kbps he-aacv2 but this results in metallic voice). Any chance in supporting such bitrates?
Also for some stereo music I'm curious if xhe can keep some quality below 24kpbs, like he-aacv2 does in 24k.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: LithosZA on 2020-08-15 11:30:51
Hi all,

For some time I was looking for an xhe encoder in order to try very low bitrate for some audio books (tried 16kbps he-aacv2 but this results in metallic voice). Any chance in supporting such bitrates?
Also for some stereo music I'm curious if xhe can keep some quality below 24kpbs, like he-aacv2 does in 24k.
Not at the moment:
Quote
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.
If those features are implemented then technically xHE-AAC should sound better than HE-AACv2 at 24kbps. For now your best bet will be HE-AACv2 for music and also trying Opus for voice only at those bitrates.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-08-15 12:50:40
Are we able to use exhale for streaming to stdout? Like with a shoutcast/icecast server being driven by Breakaway's encoding section via custom encoders? It's possible to do so with the other aac+ command line encoders (ie: qaac, fdkaacenc, fhgaacenc, and even the older enc_aacplus) , i just couldn't find any switches to indicate stdout for the output (ie: '-').
This is currently not supported by the exhale application because, after finishing an encoding, it goes back to the beginning of the file to write the final MPEG-4 file header. It's written to the beginning of the file to optimize the resulting .m4a files for streaming (fast start of playback and seeking). AFAIK this approach is not possible with stdout. However, one could use the exhale library to build a custom solution doing exactly what you're looking for.

For some time I was looking for an xhe encoder in order to try very low bitrate for some audio books (tried 16kbps he-aacv2 but this results in metallic voice). Any chance in supporting such bitrates?
Also for some stereo music I'm curious if xhe can keep some quality below 24kpbs, like he-aacv2 does in 24k.
Regarding support for bit-rates lower than, say, 48 kbit/s stereo (or 24 kbit/s mono), I commented on this in an earlier post (https://hydrogenaud.io/index.php?topic=118888.msg980837#msg980837). Summary: sorry, too much work for me, I do this in my free time.
Regarding the 24 kbit/s stereo music quality, the xHE-AAC standard does very well there, see the USAC verification test report (https://www.ietf.org/lib/dt/documents/LIAISON/file1298.doc) from 2011. Figure 2 of that report is attached.

I thought it was important to mention that starting from 1.0.6 release for the first time exhale outperforms every LC-AAC encoder at 80-96 kbps (and higher).
Awesome, that's great to hear! Thanks very much for testing, Igor!

I have elected to name these as 1.0.7 but I'm sure I'll be told if that is incorrect
That's OK, but to avoid confusion in the future, please always use the version number written in include/version.h (https://gitlab.com/ecodis/exhale/-/blob/master/include/version.h) in exhale's source directory.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: yarrix on 2020-08-16 14:33:53
Are we able to use exhale for streaming to stdout? Like with a shoutcast/icecast server being driven by Breakaway's encoding section via custom encoders? It's possible to do so with the other aac+ command line encoders (ie: qaac, fdkaacenc, fhgaacenc, and even the older enc_aacplus) , i just couldn't find any switches to indicate stdout for the output (ie: '-').
This is currently not supported by the exhale application because, after finishing an encoding, it goes back to the beginning of the file to write the final MPEG-4 file header. It's written to the beginning of the file to optimize the resulting .m4a files for streaming (fast start of playback and seeking). AFAIK this approach is not possible with stdout. However, one could use the exhale library to build a custom solution doing exactly what you're looking for.

Chris

Thanks for the detailed info Chris, your suggestion is beyond me personally, but I'm sure that a lot of streamers would be extremely interested in such a 'library' version for streaming. Maybe some of the folks who kindly 'compile' your source could take a shot at it? Or maybe even you could decide to do this, as the use case is way more than obvious. Hint hint! ;-D

Nevertheless, with my limited knowledge of these things, I see two main hurdles; first is raw/pcm on stdin input (not just orderly wav), and adts on output to stdout (not m4a output). Am I on the right track? Thanks again for any pointers, highly appreciated!
 

-Y
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-08-18 00:10:44
Nevertheless, with my limited knowledge of these things, I see two main hurdles; first is raw/pcm on stdin input (not just orderly wav), and adts on output to stdout (not m4a output). Am I on the right track?
I don't know, you tell me. Is that how the workflow with Shoutcast/Icecast is? Does it require ADTS output from the encoder?

By the way, I just committed some minor fixes (https://gitlab.com/ecodis/exhale/-/commit/b0332871) to the exhale source code (mostly affecting 32-kHz encoding especially at CVBR modes 4 and higher, which is what most people probably don't do), so we have a 1.0.7 beta now.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: nu774 on 2020-08-18 01:41:14
According to the following doc, ADTS is deprecated.
LATM/LOAS shall be used instead.
MPEG-TS or fragmented MP4 can also be used for streaming purpose.
https://www.iis.fraunhofer.de/content/dam/iis/de/doc/ame/wp/FraunhoferIIS_xHE-AAC_Whitepaper.pdf
Quote
LATM/LOAS
When xHE-AAC is stored or transmitted “raw”, i.e. without an additional container, multiplexing and streaming is enabled by the MPEG-4 Low Overhead Audio Transport Multiplex (LATM) and the Low Overhead Audio Stream (LOAS) [MP4A]. Support for the alternative Audio Data Transport Stream (ADTS), which was common for AAC-LC and HE-AAC,
is deprecated with xHE-AAC and not supported anymore. LATM/LOAS is typically used in
SHOUTcast deployments.
Also, the following was  interesting:
Quote
File-format (ISOBMFF/MP4FF)
Storage of xHE-AAC in the ISO base media file format (ISOBMFF)[ISOBMFF] follows the
same principles as AAC-LC and HE-AAC, i.e. the MP4 file format [MP4FF] is used.
All IPFs are signaled by means of the “SyncSampleBox”. IPFs allow the decoder to fully
reconstruct the signal without any previous AUs, which enables true random access at any
sync sample. This is particularly useful when a flat MP4 file is used as input to a streaming
system for subsequent fragmentation. Signaling of IPF is mandatory for xHE-AAC.
Since the xHE-AAC encoder works on a fixed “granule” of e.g. 2048 audio samples, the
last AU of an MP4 file usually represents only the last few samples of the original WAV
file. In order to restore this original file length, an edit-list can be used to trim the MP4 file
accordingly. It is recommended that an xHE-AAC file starts with an IPF, which addresses
the “priming” issue (see above) and removes the need for edit lists at the start of the
item.
In addition to the rather expensive IPFs, all AUs that have the usacIndependencyFlag set
to 1 can be used to enable random access, e.g. for seeking operations. While these Independency Frames (IF) can be used to start decoding, a full audio signal is guaranteed only
after decoding a certain number of AUs. This is referred to as roll distance in file format
terms and can be signaled using the AudioPreRollEntry and the AudioSampleGroupEntry
respectively.
So, if exhale is generating IPF(immediate playout frame)s, using stss is the right thing to do.
Otherwise, the doc doesn't clearly say if stts is mandatory or not.

If I understand correctly, you still need to seek to one of independency frame(IF)s from where you can start decoding. So, I believe you still need stss.
If they are not IPFs, decoder can start from there, but IFs are dependent to the preceding frames (due to by nature of MDCT).
So, if you want full/accurate reconstruction from the exact seek point, you have to also take prerolling into account.
AudioPreRollEntry can be used to let player know how many preroll they need, and this is what doc says.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-08-18 08:54:02
Intel compiles of exhale-v.1.0.7b1-b0332871:

www.rarewares.org/files/aac/exhale-v.1.0.7b1-b0332871_x64.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.7b1-b0332871_x64.zip)

www.rarewares.org/files/aac/exhale-v.1.0.7b1-b0332871_x86.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.7b1-b0332871_x86.zip)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-08-18 11:11:57
So, if exhale is generating IPF(immediate playout frame)s, using stss is the right thing to do.
Otherwise, the doc doesn't clearly say if stts is mandatory or not.
...
AudioPreRollEntry can be used to let player know how many preroll they need, and this is what doc says.
Exactly. I agree that the 'stss' box should be used and, according to my understanding, the AudioPreRollEntry ('prol' of one sample, i.e., one AU, 1024 audio samples) was added in the context of issue 10. Please let me know if that is unrelated or incorrect.

By the way, just had to fix a Linux compilation error, so there's a new commit (https://gitlab.com/ecodis/exhale/-/commit/399a5b7) (thanks, m14u!). John, no need to update, doesn't affect Windows.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-08-18 17:02:53
aa44938c
caramba!
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-08-19 22:23:55
exhale v1.0.6-aa44938c (18 Aug, 2020)
Built on August 19, 2020, GCC 10.2.0

https://gitlab.com/ecodis/exhale
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: soundping on 2020-08-20 09:07:50
Thanks, NR   ;D
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-08-20 19:32:35
I have found new software based on Exhale:
https://www.poikosoft.com/xhe-aac-converter
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-08-20 19:58:11
"Free 21 day trial"
burn in hell
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: includemeout on 2020-08-21 02:02:54
burn in hell
 
 A bit rough on the edges, huh?

Why using such unnecessary colorful language - specially towards another fellow member - whether they've been here for a couple months or eons!?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-08-21 03:03:46
I believe they are telling the opportunist software developer to burn in hell, not the poster who brought the news of said software.

Lest they also forget that Spoon is also an opportunist software developer, and he develops dBPowerAMP, and he keeps the lights on for our forum, and he also employs Peter to work on his software as well, for such tasks as maintaining the macOS and Linux ports of Asset UPnP and the macOS port of dBPowerAMP.

Never forget, this software that has to be paid for to perform a task easily, that you yourself could do for free with alternative choices, was probably not made for you. It was made for people who will happily pay for such a solution to their problems, without even knowing that alternatives exist, alternatives that may or may not be harder to set up once, or even set up every time they use them.

You're welcome to continue teaching people how to use the free solution, as long as you're willing to put up with being their technical support whenever problems arise with that solution. This developer who is charging money, also has to act as support for anyone using their software, lest word get out that they're not supporting their users, and their reputation tanks. They can also act as a support distillery, reducing the amount of redundant bug reports that find their way to this Chris. Assuming they don't intend to just keep all their personal fixes and not share them upstream to Exhale. Does the license require them to share any fixes they make upstream?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-08-21 07:51:04
I meant that if you have "extra" money, then there are great examples of free/open software that could be sponsored. without any "21 day trial". I didn't mean any people.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-08-21 08:53:19
Right, and if there were an open source equivalent to that, I'm sure its authors would be happy to accept donations.

A closed source alternative, right now, is foobar2000's converter component, coupled with a compiled copy of Exhale, which itself is open source, from this topic.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: includemeout on 2020-08-21 16:04:22
Yeah, got it totally t*ts up. Sorry!
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: soundping on 2020-08-22 00:55:57
I must have stumbled into the flame room.  :))
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-08-23 04:11:59
I hope not, although I have different points of view. My interest in Exhale is aimed at distributing spoken content; as xHE-AAC is patented I need a license. Fraunhofer and Via Licensing responded to my inquiries with the list of their partners.

So despite having compiled Exhale many times to test it, my needs are as an end user and if I buy the software provided by Poikosoft (which I verified to be Via's licensee, see https://www.via-corp.com/licensing/aac/licensees/ ) I don't need to get any more licenses to distribute my content, I pay 30 euros once and I'm fine forever.

There are no patent license fees due for the distribution of bit-streams encoded in AAC, whether such bit-streams are broadcast, streamed over a network, or provided on physical media. This is not the first time I buy an encoder just for the license, it costs me less than having unnecessary litigation in the future.

As you may have noticed from my posts, I don't use Windows and I prefer the CLI (which I can manage with simple scripts), so I buy it because it is the cheapest way to satisfy my license needs (which is not included in open source software).

Regarding Poikosoft, probably the use of Exhale will be only temporary, in the forum of the company it reports to be in discussion with Fraunhofer about possibility to license their xHE-AAC implementation and I guess I won't be able to use it again without Windows.

I tried EZ CD Audio Converter and I can confirm that it has made some improvements, in particular at low bitrate it produces smaller files and provides combinations between sample rates and bitrates excluded by Exhale.

On the developer you define as an opportunist, I believe that to do this job he must give his users what they may need and he achieves the purpose with the EBU R128 loudness normalization (necessary for those who make podcasts but at different level). The free 21 day trial for me it is just an advantage that allows to understand what you are buying.

In my opinion the developer proves to be intelligent: he understood that the licensing conditions offer a 15x advantage for small entities with fifteen or fewer employees and with annual gross revenues of less than US $1 million.

So I'm the first who wants to financially support Christian R. Helmrich, but my help alone cannot be enough to make Exhale an encoder capable of withstanding the comparison with Fraunhofer's. Poikosoft is a good systems integrator but to improve Exhale it is necessary that Dr. Helmrich can devote more time to them, to make them proactive and to complete the missing parts of USAC. It will not be the contribution of one person that will make him change his mind.

And if we pay him the initial $ 1,000, he could also finance himself in the future by selling licenses. If you do not leave me alone I am willing to finance the development of Exhale, I am waiting to read your intentions, but I have not found any page of the Ecodis website (see http://www.ecodis.de/index.htm) indicates how financing the author, so I believe that it won't be easy.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-08-23 09:35:54
comrades! my careless comment caused a "fire" that created a "flood". I suggest you ignore it and stop.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-08-23 14:42:54
I don't see any "fire" and no "flooding", I just follow Exhale's license (see http://www.ecodis.de/exhale/license.htm ).

Licensor's Copyright Notice
Copyright © 2018–2020 Christian R. Helmrich, ecodis (Licensor). All rights reserved.
Quote
Patent licenses required for the use of this Software to generate digital bit-streams according to any specifications of ISO/IEC 23003-3 may be obtained through Via Licensing and/or the corresponding patent holders individually.

If Poikosoft manages to make an agreement with Fraunhofer it will be very expensive for him and he will surely have to raise the prices of his software, so I wasted no time and bought a license that will allow me to use Exhale in the future.

As you can see I want to use Exhale now and in the future and I am waiting to know if there are other people among us interested in financing its development. Surely it would be better to be able to help Christian R. Helmrich also in writing the code, but in any case, financial support is better than nothing and will allow a person who has proven to have a lot of talent to be able to devote more time to the development of Exhale.

So it is not time to ignore your message and stop, if anyone really want to support open source projects can join to me and have to make them grow well by obtaining all the necessary conditions. If someone wants to move from words that cost and produce nothing to something more substantial, now is the time to step forward, otherwise Dr. Helmrich will soon be content to have created Exhale for educational purposes only.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: itisljar on 2020-08-23 20:41:12
I am confused. Isn't exhale open-source application, and why would you need a licence to encode stuff with it? I understand if you want to use Fraunhoffer's software and you pay for it, but this is free; to play it, you need software which can decode that stream, free or non-free. Can someone explain to me?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-08-23 20:57:28
Patent covers ideas and gives to its owner the legal right to exclude others from making, using, or selling an invention for a limited period of years in exchange for publishing an enabling public disclosure of the invention. It's very simple and I want to distributing spoken content so it's not something that can remain hidden in my data. I have pay the right to making and use the encoder, now I'm free. Time is also a non-renewable resource.

I like open source software but at the same time where I live only people have rights (software can only be free like a beer) and those covered by patents need to be payed for some years, fortunately not much in this case. Patents for ACELP (AMR-WB) will expire in 2021 and xHE-AAC or USAC plans to use them, even if they are not implemented in Exhale at this moment.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-08-24 01:03:03
Let's go back to talking about Exhale in its alleged distributions, the first of Ecodis and the second of Poikosoft.

<- click to download
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '20200823-Ecodis.m4a': 1.969.641 byte
Metadata:
major_brand     : mp42
minor_version   : 0
compatible_brands: mp42isom
Duration: 00:08:07.35, start: 0.000000, bitrate: 32 kb/s
Stream #0:0(und): Audio: aac (mp4a / 0x6134706D), 32000 Hz, 1 channels, fltp, 31 kb/s (default)
Metadata:
handler_name    : crh

<- click to download
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '20200823-Poikosoft.m4a': 2.028.191 byte
Metadata:
major_brand     : mp42
minor_version   : 0
compatible_brands: mp42isom
replaygain_originator_code: 011011000000
replaygain_track_gain: -5.88 dB
replaygain_track_peak: 0.900042
title           : 20200823
artist          : Giuseppe Sala
album_artist    : Comune di Milano
album           : Rimini
date            : 2020
Duration: 00:08:07.35, start: 0.000000, bitrate: 33 kb/s
Stream #0:0(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, 1 channels, fltp, 31 kb/s (default)
Metadata:
Side data:
replaygain: track gain - -5.880000, track peak - 0.000021, album gain - unknown, album peak - unknown

In my opinion there are no substantial differences; the version created with Exhale provided by Ecodis has been resampled to 32kHz, while the version created with Exhale provided by Poikosoft is apparently sampled at 48kHz but the content seems to be the same (but I should hear it again tomorrow, now I'm very tired and don't want to do many test, the last time I did this I confused the files and came to completely wrong conclusions).

It probably behaves like Opus, eliminating data in the upper bands to always show the same sample rate. This is a good idea because you can use it for any destination (even as an audio track of a video) without having to resample it to 48kHz. In general with xHE-AAC I can use the same container for storage and the same content for emergency warning functionality, music, next TV audio (MPEG-H is based on USAC), DRM (next digital LW, AM and FM), podcast, HTML 5 audio tag, and I'm sure even the next DAB (until now called epic fail). Also can be used for fMP4 streaming and for extend the autonomy of mobile devices.

I am writing this only because I believe it is important to finance the development of what will be an essential format for the years to come. But it makes sense to do it now, not when the patents expire.

The version created with Exhale provided by Poikosoft added some metadata (you can also do it differently and later) but analyzed the mitigation to be applied in general on content optimized to be used on mobile devices (see https://www.aes.org/technical/documents/AESTD1004_1_15_10.pdf ) and therefore with a maximum peak level -1 dBTP (EBU R128) and a target loudness for podcast too (-16 LUFS).

I see more of the work of a systems integrator than substantial changes to the Exhale code, but surely there are people among you who are more competent than me to understand it from the two examples that I hope I have attached correctly.

Goodnight, I'm going to dream that I'm not the only one who wants to create a fund for the development of Exhale.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: kode54 on 2020-08-24 02:14:48
Software patents and those who hold them are the scum of the earth.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-08-24 03:14:08
Software patents and those who hold them are the scum of the earth.

There are software patents, we can't hide this just because we have lost.
Okay, let's think about something else because this wound still burns.

The result is that the patents now pay off only for a few years (see https://www.iso.org/standard/59635.html ).
I prefer to look ahead, today many developers active in open source software are paid by patent holders (IBM has been the first for 27 years), which is why I think the developers who are passionate about it in their spare time should be supported.

Christian R. Helmrich don't own any patents, but without Exhale and without the time it took him to build the skills to make it today I would have had to pay a much higher bill, about $ 1,000 more.

At the same time, I recognize that he now has to devote time to his family and the work that allowed him to write Exhale in his spare time, and at least half of the benefit it gave me I want to go back to him.

So Helmrich will be able to dedicate more time to Exhale and create other benefits for me and for other users, starting from those who cannot pay for a license even at a low cost.

Unfortunately my effort alone will be in vain, a community that supports a project even with small amounts creates a considerable leverage for developers and it's also a public admission that you love what you have.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: francesco on 2020-08-24 10:23:54
Wanna try this but I'm confused on what the Foobar encoder settings are?.

Something like this.

Also, for reference:

CBR mode 1 = ~64 kbps (stereo)
CBR mode 2 = ~80 kbps (stereo)
CBR mode 3 = ~96 kbps (stereo)
CBR mode 4 = ~112 kbps (stereo)
CBR mode 5 = ~128 kbps (stereo)
CBR mode 6 = ~144 kbps (stereo)
CBR mode 7 = ~160 kbps (stereo)
CBR mode 8 = ~176 kbps (stereo)
CBR mode 9 = ~192 kbps (stereo)
hi @jarsonic
i will start to make some blind tests with qaac
thanks for the infomartion  , cbr mode 9 is the max ,isn't it?



Intel compiles of exhale-v.1.0.7-051900fe:

www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x64.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x64.zip)

www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x86.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x86.zip)

I have elected to name these as 1.0.7 but I'm sure I'll be told if that is incorrect!! ;)
hi @john33
you are number 1 , thanks for the compiled version , i have tried several time to compile lame without luck
thanks again!
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-08-24 11:06:37
I don't know why the author doesn't mention it, but I'll take the "sin" - the last commit has mode #0 ~48kbps at <=32khz
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: includemeout on 2020-08-24 11:09:42
Software patents and those who hold them are the scum of the earth.
 
 




Family estates and ad hoc wealthy heirs and lawyers living off royalties from long-deceased family members they merely see now as their cash cow, whilst contributing absolutely nilch to society, are the Earth's pariah, IMHO.




Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-08-24 22:32:05
Everything we have comes from expired patents, the point is that you have to start working on them first to be ready at the right time; Speex also derives from CELP, of which ACELP is only an improvement. Go on.

I tried to compare the voice rendering between Exhale and AMR-WB that comes from ACELP, a part that Helmrich plans not to implement.

Honestly now I can't blame him (sadly I'm a bit slow to understand), AMR-WB encodes a mono sampled 16kHz file in just under 24kbps. The quality of AMR-WB is superior to what is achieved with AAC or HE-AAC.

Exhale performs better in the 0 mode at 24kHz for just over 24kbps and in the mode 1 at 32kHz for just over 32kbps; at the moment it doesn't make me regret other options.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-08-25 02:20:18
I don't know why the author doesn't mention it, but I'll take the "sin" - the last commit has mode #0 ~48kbps at <=32khz
Yes, I've noticed that too  :-X
I did some blind tests and exhale 1.0.7 beta @48 kbps, stereo  outperforms best HE-AAC encoders such as FhG Winamp, Nero, Apple and FDK.
I don't understand how exhale managed to outperform  without SBR.  Probably tuned PNS does a good job there.

I found 32 kHz (SoX 99% passband) is optimal for exhale@48 kbps ... at least for my ears.
22 kHz and 24 kHz sound  clearly worse and dull!

Results of Exhale vs HE-AAC
Code: [Select]
	48 kbps, stereo
Exhale_1.0.7beta FhG_Wnmp_HE-AAC
01 Castanets 3.1 1.8
02 Highway to Hell 3.6 3.5
03 EIG 2.8 1.8
04 Bachpsichord 3.4 2.9
05 Enola 3 2.7
06 Trumpet 2.7 3.2
07 applaud 2.7 2.8
08 Velvet 3.1 2.2
09 Linchpin 2.8 3
10 spill_the_blood 2.4 2.6
11 female_speech 4.4 3
12 french ad 2.6 3
13 fatboy 1.8 2

MOS (Mean Opinion Score) 2.95 2.65
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-08-25 11:13:11
I don't know why the author doesn't mention it, but I'll take the "sin" - the last commit has mode #0 ~48kbps at <=32khz
I don't know why the author doesn't mention it, but I'll take the "sin" - the last commit has mode #0 ~48kbps at <=32khz
Yes, I've noticed that too  :-X
I did some blind tests and exhale 1.0.7 beta @48 kbps, stereo  outperforms best HE-AAC encoders such as FhG Winamp, Nero, Apple and FDK.
I don't understand how exhale managed to outperform  without SBR.  Probably tuned PNS does a good job there.
Well, first I forgot to mention this, then I wanted to wait until the exhale-unrelated discussion stopped. And yes, I was also surprised to hear (for myself) that exhale can now compete with SBRish codecs at CVBR mode 0, which is why I decided to activate this in the exhale application for the 1.0.7 release (the exhale library already supported this since version 1.0.0).

For the record, theres a new commit d2bede2 (https://gitlab.com/ecodis/exhale/-/commit/d2bede2) which fixes a very minor issue in the bit-rate control and updates the release notes (I forgot to mention the CVBR mode 0 thing). This will probably be tagged as the final 1.0.7 release on the weekend.

Btw, technically, it's not PNS that's used in xHE-AAC (it's simply called noise filling, with PNS this performance wouldn't be possible).

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-08-25 14:17:25
Intel compiles of what I will call exhale-v.1.0.7rc1-d2bede24 until there is a formal release:

www.rarewares.org/files/aac/exhale-v.1.0.7rc1-d2bede24_x64.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.7rc1-d2bede24_x64.zip)

www.rarewares.org/files/aac/exhale-v.1.0.7rc1-d2bede24_x86.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.7rc1-d2bede24_x86.zip)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-08-26 05:02:17
Probably when the internal SRC reduces the sampling rate from 48kHz to 32kHz, because the user asked to use mode 0 or 1, after the resampling Exhale uses the next mode.


This is the original wave file sampled at 48kHz.


This file is produced by Exhale starting from a 32kHz sampled wave file.

-> exhale 0 spoken-m-32k.wav spoken-m-32k.m4a

exhale - ecodis extended high-efficiency and low-complexity encoder
version 1.0.7 (x64, built on Aug 25 2020) - written by C.R.Helmrich

Encoding 32-kHz 1-channel 32-bit WAVE to low-complexity xHE-AAC at 24 kbit/s
Progress: --------------------------------- Done, actual average 26.6 kbit/s
Input statistics: Mobile loudness -19.67 LUFS, sample peak level -0.96 dBFS


This file is produced by Exhale starting from the original wave file sampled at 48kHz; in this case the internal SRC was used.

-> exhale 1 spoken-m-48k.wav spoken-m-48k.m4a

exhale - ecodis extended high-efficiency and low-complexity encoder
version 1.0.7 (x64, built on Aug 25 2020) - written by C.R.Helmrich

NOTE: Downsampling the input audio from 48 kHz to 32 kHz with preset mode 1

Encoding 32-kHz 1-channel 32-bit WAVE to low-complexity xHE-AAC at 32 kbit/s
Progress: --------------------------------- Done, actual average 32.7 kbit/s
Input statistics: Mobile loudness -19.67 LUFS, sample peak level -0.97 dBFS

The resulting bitrate is completely different and the sample peak level is similar but not the same.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Destroid on 2020-08-27 09:27:37
Quick question:
I noticed with all x86 binaries that mode 4 (at 44khz sampling rate) is about 10% slower. Probably not a big deal since exhale is focusing on <128kbps.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-08-27 10:27:15
slower than what?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Destroid on 2020-08-28 04:41:59
Slower than all the other modes.

And I made a mistake. It's mode 5 at 128kbps that's slower.

On the new 1.0.7 RC1, mode 0 is clearly faster than all the modes (x86 binary).
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-08-28 04:57:03
I have come to completely wrong conclusions in the past because I did a lot of testing and have confused the files produced by myself. The forum terms of service in point 8 state that graphs, non-blind listening tests, waveform difference comparisons, and so on, are not acceptable. Or at least that's what I understand.

Wanting to avoid myself further ugly figures, I thought of writing directly to the developer, although I have enormous doubts about the graphics provided. I hope not to irritate the administrators if I use this scam to show a software bug, but I consider your opinions very important and otherwise I would not be a regular reader of this forum.

I ask forgiveness in advance, thank you.

https://gitlab.com/ecodis/exhale/-/issues/14
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Octocontrabass on 2020-08-28 17:45:05
Your graphs show that exhale's resampler is different from the other resampler you compared it against, but that's all. They don't show that one is better than the other by any metric.

If you want to compare the technical merits of resamplers, you need graphs like these (https://src.infinitewave.ca/).

If you want to know which one sounds better, you need blind listening tests.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-08-28 21:17:25
Final commit for this release (https://gitlab.com/ecodis/exhale/-/commit/54a7bcd7), I was informed of an inaccuracy in exhale's loudness estimation and corrected that, at least for 44.1 and 48 kHz sampling rate it should now be quite accurate. If you manage to compile this release without errors, please call it version 1.0.7. I'll tag this later, after having run it through my own test suite. Btw, the audio quality hasn't changed since the last release candidate, only the loudness value inside the file header might have.

It's mode 5 at 128kbps that's slower.
On the new 1.0.7 RC1, mode 0 is clearly faster than all the modes (x86 binary).
Two reasons for this. First, at the lower CVBR modes where a sampling rate of 32 kHz or less is used, the encoder needs to process fewer samples (i.e., frames) per second. Second, the more frequency coefficients are quantized to zero, which of course happens a lot at mode 0, the faster exhale's entropy coder can run. Regarding mode 5 being the slowest mode: I configured the higher modes such that they are roughly as fast/slow as modes 4 or 5, but that configuration is quite coarse. Do you have a detailed table of speeds per CVBR mode and sampling rate by any chance?

Your graphs show that exhale's resampler is different from the other resampler you compared it against, but that's all.
What I believe I can read from celona's screenshots (the waveform display in the background) is that his resampler has a slightly lower (possibly unnecessarily low) cutoff frequency. But to be sure, Christian, can you share your manually 32-kHz downsampled sweep WAV file, i.e., the one you used to obtain the Sweep20-20_20sec_-6dB_32k.wav.png screenshot in the Git issue?

A note on the loudness metadata: xHE-AAC has built-in loudness and sample peak value metadata according to ISO/IEC 23003-4 (DRC standard) similar to ReplayGain, so it should not be necessary to write ReplayGain tags to xHE-AAC files (with that file format, doing so is considered obsolete). Still, exhale cannot write album loudness information since it doesn't know about albums, only files (where each file is considered an "audio program"). If there is interest in extending the xHE-AAC file headers written by exhale with ISO/IEC 23003-4 album loudness values (and, possibly, album sample peak values), I'm open to disuss this, e.g. with Peter and Christopher in the context of foobar2000.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-08-28 21:45:52
Intel compiles of exhale-v.1.0.7-54a7bcd7 now available at Rarewares. :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: celona on 2020-08-28 23:54:38
Christian, can you share your manually 32-kHz downsampled sweep WAV file, i.e., the one you used to obtain the Sweep20-20_20sec_-6dB_32k.wav.png screenshot in the Git issue?


Obtained with afconvert --src-complexity norm, I can supply also the best quality version (bats) but my purpose was not to evaluate the quality of the encoder, but only to evaluate whether to use internal SRC or other.


I also add the compressed version obtained, of only 31,688 bytes.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-08-29 01:10:30
... my purpose was not to evaluate the quality of the encoder, but only to evaluate whether to use internal SRC or other.
Well, that I can easily answer: if your original source material is in 48 kHz, use exhale's built-in resampler ;) Seriously, don't worry about the resampling if you don't have to. exhale's 48-to-32-kHz resampler was specifically designed to run fast, have a high cutoff frequency (it starts rolling off around 15 kHz IIRC while your afconvert version starts rolling off already at 14 kHz), avoid unnecessary stop-band and near-Nyquist aliasing rejection which will be masked by the low-rate compression errors, and always result in the maximum bit-depth entering the encoding process (around 24 bits per sample). Oh, and you would either have to use some on-the-fly resampling with a stdout-to-stdin cascade or you'd need to create temporary 32-kHz resampled files which you then feed into exhale.

Lots of things I wouldn't want to worry about if I were you :)

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Destroid on 2020-08-29 03:04:42
Do you have a detailed table of speeds per CVBR mode and sampling rate by any chance?

I can PM my entire benchmark history going back to 1.0.2.

If my memory serves, my machine encodes most modes with 44 khz material at 10.5x to 11, and even mode 1 is close to the same speed despite its resampled by SoX at 24khz. Mode 5 encodes slower at about 9.5x. Mode 0 (resampled by SoX to 24khz) in 1.0.7 RC1 encodes faster at over 13x. These test were with 86 binaries. (Thanks again, john33 :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: itisljar on 2020-09-06 20:58:24
OK, I've encoded some music with exhale 1.07 and tested it on my Samsung A50, with latest updates, It runs Android 10.
PowerAmp won't play these files, which is expected as its decoders are based on ffmpeg. Samsung Music plays these files, but I can't jump inside some position in song, just says it is not playable (and it was playing that exact file!) and skips to next song.
Didn't test any other player, because I don't really know which one should work - does anyone has suggestions?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-09-06 22:52:01
whats about playing this files on PC ?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: itisljar on 2020-09-06 22:55:57
Everything as expected. playing in foobar2000, with that extra decoder installed. can play, can jump around the song.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-09-26 19:40:45
If my memory serves, my machine encodes most modes with 44 khz material at 10.5x to 11, and even mode 1 is close to the same speed despite its resampled by SoX at 24khz. Mode 5 encodes slower at about 9.5x. Mode 0 (resampled by SoX to 24khz) in 1.0.7 RC1 encodes faster at over 13x.
Thanks for the benchmarking, Destroid! I reconfigured CVBR mode 0 to do slightly "more exhaustive" parameter searching during the quantization step, so it should run a bit slower now. At the same time, I also shaved off around 1 additional kbit/s for 32-kHz encoding at mode 0 (with the previous version, the bit-rates tended to be a bit higher than the 48 kbit/s target rate).

The new version (https://gitlab.com/ecodis/exhale/-/commit/e9bd99b) is still version 1.0.7 since the changes are so minor.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-09-26 21:33:10
New compiles on the Rarewares-aac encoders page. :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: LithosZA on 2020-09-27 19:24:33
This might be a little off-topic, but between MPEG-H, Dolby AC-4 and xHE-AAC which codec do you guys think is more efficient in theory?
There doesn't seem to be publicly available encoders for MPEG-H and Dolby AC-4 to compare with.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-09-27 20:15:50
xHE-AAC and Dolby AC4 have similar  tools. I would say xHE-AAC has a  slight edge.

MPEG-H (3DA) format is considerably more efficient that xHE-AAC as it replaces SBR by IGF (much better BW extension)  and introduction of  better and similar  [semi]-parametric tools  like stereo filling etc. 

 As a rule of thumb, MPEG-H provides ~16 kbps  bitrate reduction comparing to xHE-AAC/USAC. But there is no encoder/decoder around afaik.  Plus xHE-AAC is still struggling to get  decoding support  in ffmpeg, that's when in my opinion  it will be usable.



Title: Re: exhale - Open Source xHE-AAC encoder
Post by: itisljar on 2020-09-28 11:48:44
How to play it on linux? I've compiled it from the source and moved bin to /usr/bin, made it executable, tested, it works; but I am struggling to find player to play it. Have you found something to play it in Linux? I am using Mint... I think it's 20.04 :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: hardrain on 2020-09-28 14:33:26
For players like strawberry, try installing gst-plugins-bad or whatever the equivalent of it is in linux mint. I'm guessing libgstreamer-plugins-bad?
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: AiZ on 2020-09-28 20:01:03
How to play it on linux? [...] I am using Mint... I think it's 20.04 :)
https://hydrogenaud.io/index.php?PHPSESSID=pef44dodcldmtcqire5vm4mmq5&topic=54933.0 (https://hydrogenaud.io/index.php?PHPSESSID=pef44dodcldmtcqire5vm4mmq5&topic=54933.0)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-09-28 20:21:49
exhale v1.0.7-9323a9d0
Built on September 28, 2020, GCC 10.2.0
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: Kamedo2 on 2020-09-28 20:48:44
New compiles on the Rarewares-aac encoders page. :)

Thanks. You may want to update the News section.  https://rarewares.org/index.php
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: andrew.46 on 2020-10-03 05:04:58
How to play it on linux? I've compiled it from the source and moved bin to /usr/bin, made it executable, tested, it works; but I am struggling to find player to play it. Have you found something to play it in Linux?

I think it has been mentioned elsewhere in this thread but if you copy of FFmpeg has been compiled against fdkaac the following will work from the command line:

Code: [Select]
ffplay -hide_banner -loglevel 0 -autoexit -codec:a libfdk_aac test.m4a

Perhaps a bit cumbersome but it works well enough...

Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-10-10 22:50:14
Just did a quick number crunching experiment where I tried to fit a simple function through the mean opinion score (MOS) values recently posted for exhale on this forum, in order to estimate the stereo audio quality exhale would roughly produce on mixed-genre music for an experienced listener (like those on HA). I came up with the function 2.09 * log10(target bit-rate in kbit/s), see the attached graphic. For comparison I added, with the corresponding 95% confidence intervals, the MOS of


(http://www.ecodis.de/exhale_quality_estim.png)

Interestingly, the average predicted quality at CVBR mode 9 is lower than what Igor reported. Also, all confidence intervals cross the curve, which means that it is a quite accurate approximation, and the curve crosses the 4.0 quality score (perceptible, but not annoying quality degradations) at 82 kbit/s, which is almost exactly the bit-rate you get with CVBR mode 2. So that mode seems to be quite a good choice for casual listening.

And, finally, the MOS predicted for the new CVBR mode 0 @ 32 kHz, averaging at roughly 50 kbit/s, is 3.55. I'm curious if that's reasonable ;)

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-10-11 18:55:30
  • IgorC's 192-kbit/s high-rate test archived here (https://hydrogenaud.io/index.php?topic=120007) (CVBR mode 9, actual bit-rate unknown to me - Igor, is it exactly 192 kbit/s?)
196 kbps  on my bitrate calibration set of multi genre music.

And, finally, the MOS predicted for the new CVBR mode 0 @ 32 kHz, averaging at roughly 50 kbit/s, is 3.55. I'm curious if that's reasonable ;)
Yes, it's very reasonable. According to this test xHE-AAC outperformed the best HE-AAC encoders at 48 kbps (https://hydrogenaud.io/index.php?topic=118888.msg987155#msg987155) .
And HE-AAC@48 kbps has  landed at ~ 3.3-3.6 range in previous public tests (https://en.wikipedia.org/wiki/Codec_listening_test)
So, yes, it's in line with other tests.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-10-20 18:13:17
I'm back in the thread.

Exhale 1.07 at mode 0 (48 kbps at 32000 Hz) was tested against OPUS and HE-AAC, and it's really competitive!


(https://www.zupimages.net/up/20/43/lhss.png)

Code: [Select]
FRIEDMAN version 1.24 (Jan 17, 2002) http://ff123.net/
Blocked ANOVA analysis

Number of listeners: 60
Critical significance:  0.05
Significance of data: 0.00E+000 (highly significant)
---------------------------------------------------------------
ANOVA Table for Randomized Block Designs Using Ratings

Source of         Degrees     Sum of    Mean
variation         of Freedom  squares   Square    F      p

Total              299         455.02
Testers (blocks)    59          57.64
Codecs eval'd        4         299.02   74.75   179.36  0.00E+000
Error              236          98.36    0.42
---------------------------------------------------------------
Fisher's protected LSD for ANOVA:   0.232

Means:

HIGH     USAC     OPUS     HE-AAC   LOW     
  4.74     3.08     3.07     2.69     1.64  

---------------------------- p-value Matrix ---------------------------

         USAC     OPUS     HE-AAC   LOW     
HIGH     0.000*   0.000*   0.000*   0.000*  
USAC              0.910    0.001*   0.000*  
OPUS                       0.001*   0.000*  
HE-AAC                              0.000*  
-----------------------------------------------------------------------

HIGH is better than USAC, OPUS, HE-AAC, LOW
USAC is better than HE-AAC, LOW
OPUS is better than HE-AAC, LOW
HE-AAC is better than LOW
https://hydrogenaud.io/index.php?topic=120081.msg989570;topicseen#new
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-10-20 20:11:02
Exhale 1.07 at mode 0 (48 kbps at 32000 Hz) was tested against OPUS and HE-AAC, and it's really competitive!
(https://www.zupimages.net/up/20/43/lhss.png)
Code: [Select]
FRIEDMAN version 1.24 (Jan 17, 2002) http://ff123.net/
Blocked ANOVA analysis
...
HIGH is better than USAC, OPUS, HE-AAC, LOW
USAC is better than HE-AAC, LOW
OPUS is better than HE-AAC, LOW
HE-AAC is better than LOW
https://hydrogenaud.io/index.php?topic=120081.msg989570;topicseen#new
Awesome, thanks for testing so thoroughly again! The comparison with HE-AAC is perfectly in line with Igor's results, it seems.

I calculated an average score of your results from the Billboard, Classical, and Speech subsets (each weighted by 1/3 into the average) to get a less "killer" sample collection similar to what you had in your 64-kbit/s test and updated my plot from the previous page. Not quite the 3.55 score that I had predicted, but then again, you're an extremely experienced listener ;)
 
(http://www.ecodis.de/audio/exhale_quality_estim.png)

Still, at 48 kbit/s stereo, exhale is about 0.2-0.3 score points short of the predicted 3.55. I'll spend the rest of the year checking if a basic SBR implementation would close that gap.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: guruboolez on 2020-10-20 20:48:18
I'll spend the rest of the year checking if a basic SBR implementation would close that gap.
Yeah! That sounds great!!
Just a question: does USAC have the SBR tool than HE-AAC? On Poikosoft forum the developer mentioned  something he named enhanced SBR (https://www.poikosoft.com/support/viewtopic.php?p=30980#p30980).
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: fabiorug on 2020-10-20 21:04:40
it isn't integrated.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-10-20 23:23:11
Yes, xHE-AAC supports the SBR tool known from HE-AAC and added a few improvements/extensions to it. That's why it is called enhanced SBR (eSBR). But to clarify: I'm still not sure whether this will, overall, increase the audio quality at this bit-rate. As you (and Igor previously) noted, transient audio parts will likely get a bit worse with SBR since the exhale core audio codec will have to run at 24 or 22.05 kHz. As I said, I'll have to do a basic check first.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-10-20 23:27:08
Correct me if I'am wrong or I might be not precise enough, enhanced SBR (eSBR) was considered better than classic SBR at bitrates lower than 48 kbps.
eSBR was only somewhat/slightly better than  SBR at 48 kbps and higher.

exhale uses Noise Filling (NS) as substitution to SBR. NS actually does excelent  in exhale.
[e]SBR does great on average and tonal material but fails noticebly on transients.
Whether eSBR will be beneficial at ~48-64 kbps is a thing to try.

IGF is considerably better than both SBR/eSBR but it's not part of xHE-AAC rather than its successor (MPEG-H 3D audio).


Congratulations to Chris for outstanding performance of exhale  :) :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-10-20 23:32:37
All correct, I would say. That's also why "basic" SBR functionality should be enough for CVBR mode 0 (if it turns out to improve the quality on average, that is).

I don't think mode 1 would sound better with SBR, that's why I'll focus on mode 0. I'll keep you updated.

P.S.: Thanks very much :)

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-10-24 00:23:12
I finished a release candidate for exhale version 1.0.8 ("i" release) today. Compared with the last changes about one month ago, only very minor quality tweaking was done (mostly for the Fatboy sample at CVBR modes 8 and 9, see also Igor's recent test (https://hydrogenaud.io/index.php?topic=120007.msg989148#msg989148)).

Changes since exhale 1.0.7 from two months ago:
- minor quality improvements at low and high rates, some license text clarifications
- exhaleApp: slightly improved loudness calculation for low and high sampling rates
- exhaleLib: improved audio quality a bit for the lower and higher-rate CVBR modes
- License: removed references to BSD text, clarified disclaimer and contributor text

The clarifications to the license text are minor and were mostly made to make it simpler and safer for people to contribute to the project.

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-10-24 13:38:31
exhale v1.0.8-39dc1852-RC
Built on October 24, 2020, GCC 10.2.0
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-10-24 22:05:13
Intel compiles of exhale-v.1.0.8.rc-39dc1852available here:

www.rarewares.org/files/aac/exhale-v.1.0.8.rc-39dc1852_x64.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.8.rc-39dc1852_x64.zip)

www.rarewares.org/files/aac/exhale-v.1.0.8.rc-39dc1852_x86.zip (http://www.rarewares.org/files/aac/exhale-v.1.0.8.rc-39dc1852_x86.zip)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: C.R.Helmrich on 2020-10-28 11:37:45
I just finalized version 1.0.8 ("i" release, Git commit 8b56192 (https://gitlab.com/ecodis/exhale/-/commit/8b56192)), there was a very minor editorial issue where a "downsampling to 32 kHz" notification print-out was missing when encoding 48-kHz audio at CVBR mode 0. So no changes to the encoding process itself since the release candidate above. I'll tag this release tonight.

The next version 1.0.9 ("J" release) will be a bugfix-only release and the last one in the 1.0.x version path. I'll keep you updated on future development on exhale, which will most likely involve addressing the two things mentioned in exhale's issue tracker (https://gitlab.com/ecodis/exhale/-/issues) (#7 and #11).

Chris
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: IgorC on 2020-10-28 16:02:28
Chris, good to see  that 1.0.8.0 improves that Fatboy sample and hopefully some other transient samples.

I just finalized version 1.0.8 ("i" release, Git commit 8b56192 (https://gitlab.com/ecodis/exhale/-/commit/8b56192)),
That "i" release could stand for "igor" . For no particular reason   :D
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-10-28 22:21:54
I just finalized version 1.0.8 ("i" release, Git commit 8b56192 (https://gitlab.com/ecodis/exhale/-/commit/8b56192)), there was a very minor editorial issue where a "downsampling to 32 kHz" notification print-out was missing when encoding 48-kHz audio at CVBR mode 0. So no changes to the encoding process itself since the release candidate above. I'll tag this release tonight.

Don't forget to att v1.0.8 to https://gitlab.com/ecodis/exhale/-/releases
;)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: m14u on 2020-10-28 22:49:16
in the name of Justice!
8b561924
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: ani_Jackal3 on 2020-10-29 07:44:19
Wait is it possible for Mobile Foobar to have USAC support by using the FDK2 decoders on Android?.
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: john33 on 2020-10-29 08:09:20
Intel compiles of exhale-v.1.0.8-8b561924 now available at Rarewares. :)
Title: Re: exhale - Open Source xHE-AAC encoder
Post by: NetRanger on 2020-10-29 09:12:14
exhale v1.0.8-8b561924 (Stable)
Built on October 28, 2020, GCC 10.2.0

https://gitlab.com/ecodis/exhale/-/releases/v1.0.8
SimplePortal 1.0.0 RC1 © 2008-2020